Software development team collaboration across disciplines using UML/SysMLIn the classic game of Telephone, players whisper a message to one another until it gets to the last person who retells the message. By the time it reaches the last player, the message has usually morphed into something completely different, often with humorous results.
For companies developing embedded systems, poor communication between teams can result in missed requirements and the wrong product for the market, which is no laughing matter. Without collaboration between each phase of development, information can be lost or incorrectly interpreted, often resulting in a product with incorrect or missing functionality.
Using a model driven development approach helps teams break down barriers between development phases and maintain consistency across the product team.
Collaborating to deliver innovation
Innovative products today are increasingly interconnected, instrumented and intelligent, leveraging electronics and software to perform key functionality integrating with mechanical components. Delivering these complex smart products to market requires a multi disciplined team, spanning diverse backgrounds, expertise and culture that must collectively work together to produce a product meeting often vague or misleading requirements.
Consider the development of a robotic surgical system: Surgeons provide the capabilities and medical insight needed for a safe and successful operation in medical terms. A surgeon probably will not understand the nuances of object-oriented programming or the electro-mechanical characteristics of a robot however. Similarly, the engineers will be largely unaware of the details of human physiology.
Yet the doctor and the engineer must be able to collaborate to deliver a safe and effective surgical system. High-level requirements may be obtained through discussions with surgeons to determine the user requirements for the system which could include functional, performance, clinical, safety or other specifications. The engineer must interpret those requirements to design a system that meets those needs.
But how can the engineer really be sure that he or she is producing the correct system and has interpreted the requirements correctly? Typically this is done with a design review with the customer or other stakeholders. However, problems can arise as the developer is often working in code, which may not be understood by the customer who is more familiar with the problem domain.
The developer can produce presentations that convey the content of the code or try to explain the behavior of the code to the customer. This can lead to a myriad of communication problems as the design is translated back to the requirements. Maintaining consistency between the high level and detailed engineering views is a manual and error prone process.