Improving interaction between different design and development teams
Creating a communication platform and approach to assure that everybody involved in the common project is 'speaking' the same language.
The realization of a joint HW/SW co-design project that involves HW and SW teams from different companies requires these teams to interact and cooperate both within the companies as well as in between companies. The problems encountered are the language difference (although English is used as a common language interpretation and use of the common language is different by the different teams) and the differences in the documentation flow.
The above mentioned situation results in issues with interpretation of data and specifications, issues with revision marking (document updates are done without highlighting changes – different information tracking systems – different (not-linked) data servers), issues with the understanding and the complexity of the specifications document and issues with proper understanding of underlying concepts and applications.
The issues with interpretation of data and specifications were handled by using various levels of abstractions and combining graphics and text (by for example combining different representations such as block diagrams and extensive descriptions) to improve the understanding and assure a common view.
The issues with revision marking (document updates are done without highlighting changes – different information tracking systems – different (not-linked) data servers) were handled by defining a common approach and enforcing a jointly agreed change tracking system.
The issues with the understanding and the complexity of the specifications document were resolved by meetings and detailed conference calls exploiting text, voice and data exchange capabilities (Skype, Mikogo, NetMeeting, …)
The issues with proper understanding of underlying concepts and applications were also resolved by meetings and detailed conference calls exploiting text, voice and data exchange capabilities (Skype, Mikogo, NetMeeting, …) further identifying the need for a “Murphy” workbench.
Position in the Domain
see attached document
Used Methofds and Tools
TE-WP2-QST-1-S1;TE-WP3-QST-1-S1
Experience
- The costs were considerably larger
- Time-to-market was considerably longer
- Reusability was considerably worse
- Quality was considerably degraded
| Attachment | Size |
|---|---|
| Domain_Workflow_ER_3.pdf | 82.87 KB |
- Login to post comments





















