A wall separates subject matter experts from the actual design process which includes disparate teams using different tools and traditional source control systems to share and trace information.
Design management capabilities of IBM Rational Rhapsody allow The Mathworks Simulink and Rational Rhapsody models to be stored in a central location for searching, linking and reviewing.
After months of hard work, the team was finally ready to flip the switch on the new heads- up display on a vehicle prototype. The system would be supplied to a major automotive manufacturer and would make or break the company. The CEO and VP of engineering were present to see it working for the first time. All the subsystem tests were flawless and it should only be academic at this point. Just flip a switch and time to celebrate. But something was amiss and no display was seen. After several hours of debugging it was discovered that the display team missed a change in the angle of the windshield causing the display to not work. The supply contract was awarded to the competition and the team started working on their resumes. This fictional story is one that plays out all too often in developing today’s complex systems.
Delivering innovative products to market requires diverse teams to collaborate, including technical and non-technical disciplines such as hardware, software, testing, mechanical, management, marketing, and sales. However, development teams each use a diverse set of tools and applications to suit their own particular department, often with a proprietary data format. The team shares information by manually creating document based reports or point to point tool integrations.
Collaborative Design Management (CDM) allows teams to share, search, link, analyze, and review design information across tools using linked lifecycle data and principles from the Open Services for Lifecycle Collaboration (OSLC) community. CDM also helps cross-discipline teams collaborate earlier in the development process to avoid design pitfalls and costly errors uncovered later during integration.
Innovation in a Complex World
As technology consumes our lives, the complexity of the designs realizing innovative product concepts grows with it. Consumers expect high quality products using the latest technology. Companies need to deliver or face the fury of a social networking onslaught. Complexity is one of the biggest challenges facing companies as found in a report from a 2010 IBM global survey “Today's complexity is only expected to rise, and more than half of CEOs doubt their ability to manage it." (Source: Capitalizing on Complexity: Insights from the IBM 2010 Global CEO Study)
While the physical size of many products is getting smaller the number of features, functions and interconnections are also increasing, making the designs themselves more complex. The architecture of software and systems, as well as the behavioral characteristics, are increasingly difficult to understand. Each new requirement for extended functionality increases the complexity. Add to this the need to interconnect software and systems to other systems, and the design complexity rises even further.
The complexity is evident and shows itself with the inability to rapidly assess the impact of a potential change on the design due to a limited understanding of the design by those who are often most deeply affected by the result of a change: the stakeholders and customers that are external to the development team. Trying to design these systems through traditional code-centric approaches, pounding out code, can lead to a fragile architecture that can be difficult to maintain, further compounding the complexity.
Organization and Process Complexity
The environment and organization of development teams today also increases the complexity facing companies. Barriers exist both internally (among divisions, locations, disciplines, and teams) and externally (with suppliers, customers, and other organizations) that influence the products, software, and systems that are being built.
Decisions about the direction of the business, the priorities of the organization, line of business structure, and IT infrastructure needs are often made without the right information being available and without collaboration with the right stakeholders in a timely fashion. This is due to a number of factors, such as manual, error-prone updates to relevant information, disconnected and undocumented plans and teams, and reports that contain either too little information or a wealth of information that hides the relevant content.
The organizational structure is often complex and misaligned. People who need to work together often work in their own disjoint silos with little communication while making assumptions of what the other team is doing. Too often problems arise during system integration because of teams incorrectly interpreting a requirement and delivering inconsistent interfaces. Reporting chains hinder the flow of information between teams, and it is often difficult to determine the right stakeholders to involve in discussions because of these problematic organizational structures.
Different organizations also may have different processes and procedures which need to somehow mesh together and align at critical junctures, whether software only or software-intensive systems involving hardware and software. From agile development, to hybrid iterative, to heavily regulated waterfall approaches, teams involved in design, development, delivery and maintenance activities face challenges with the process. Various types of processes need to integrate across organizations. Business processes, software and systems development processes, and operational processes all need to flow seamlessly into each other.
In some cases government, industry or process guidelines must also be met, such as CMMI, DO-178B for commercial avionics systems or ISO-26262 for automotive electronics, adding another layer to the complexity in the development process. The increasing complexity of the designs makes passing audits and demonstrating compliance with regulatory and corporate standards more difficult. Processes need to scale to manage the increase in information and artifacts required to track the design during its lifecycle.
Manual processes, lack of integrations of tools throughout the lifecycle, and a lack of traceability of artifacts used in specifying, designing, constructing, deploying, and maintaining software and systems all hinder the ability to deliver the right information in the right format to document compliance and satisfy regulatory requirements.
Breaking Down Development Silos
The first step in a typical design process may start with high level requirements based on a new concept or idea, often driven by the needs of the market or business - more energy efficient cars, safer medical devices using latest medical technology, or faster network performance for example. Understanding and listening to the customer needs are a critical factor in delivering a successful product. For example, the requirements for a medical device may come from the input of doctors or nurses who work with the device on a daily basis. Their acceptance of the device will drive the demand for it, the use of it, and ultimately the overall success of the device. Unfortunately, the customer requirements are often changing or subject to interpretation on the best solution that provides the most value and market impact.
The high level requirements are analyzed and derived requirements are created that are allocated across the different development teams such as electrical, mechanical, and software. Each team may receive a document indicating their requirements and proceed to work on them in their own development silos with their own set of tools. Periodic reviews, sometimes with customers or management, are established to bring the teams together as a check point on the progress of the development. To prepare for the reviews teams spend a great deal of time preparing review packages with documentation, reports, and presentations. During the review, errors may be uncovered, often due to misinterpretation or lack of understanding of requirements, which are manually noted and work undertaken to correct.
Many tools are used in the development process, each with its own purpose and strength applied to solve a particular need in the development lifecycle. The development reality is that no tool can satisfy the needs of all the different development facets such as software, electrical, mechanical, requirements management, or change management, nor should there be one only one tool. Teams need to use the right tool for the job.
Best-in-class companies are often turning to modeling the system architecture as well as various components, mechanical, electrical and even software, as a means to visualize for better understanding of the design at all levels of abstraction, communicate across teams, and simulate the designs early to validate design functionality and interfaces. A variety of models may be used: requirements, safety, functional, control system, power or others. Each serves its own purpose but dependencies exist between each that needs to be consistent. For example, moving an electrical function to software can alter the power requirements of the system. However, even with the best design tools, significant challenges still exist. These problems can be grouped into the following five areas:
- Design teams working in isolation from a significant portion of project stakeholders (Fig. 1). This too often results in designs and delivered software and systems not meeting expectations, and this is symptomatic of design and organizational complexity.
- Design elements are loosely tied to other artifacts in the lifecycle, such as project plans, requirements, test plans, test cases, operation and maintenance guides, and customer guides and manuals. This makes the impact of change uncertain, which is symptomatic of process complexity.
- Designs are difficult to review and are seldom maintained after development begins. Often, they are abandoned. This causes a significant disconnect between the requirements and the delivered product, which is a symptom of design and process complexity.
- Predictability and effectiveness in the design process is uncertain. This leads to delays in release and inefficient use of the development resources, which are directly related to process complexity issues.
- Reporting and documenting of the design, as it relates to the entire project, is labor-intensive and error-prone. This results in audit failures and an inability to show compliance with standards and regulations. Again, this is symptomatic of process complexity.
Using Web Principles in the Development Lifecycle
The OSLC community (open-services.net) is an industry initiative to make it easier for the sharing of information across tools. The principle behind OSLC is to allow teams to continue to use their existing software tools and instead of creating point to point integrations between the tools. Web architectural principles are used to provide loosely coupled integrations between the tools. The OSLC makes tool integrations easier by:
- Using standard internet protocols for public specifications of resources and services for sharing critical information that development teams rely on such as change requests, test cases, defects, requirements, and architecture.
- Loosely coupling architecture that allows information from a tool to be URL addressable, making it easy to navigate, report access and analyze the data across lifecycle using standard web protocols.
- Allowing individual tools can continue storing information in their own proprietary formats but use a standard interface to share and represent information.
The IBM Jazz platform implements the specifications defined with OSLC and adds integration services to provide a platform for lifecycle tools to share and trace design and lifecycle information together. Design and modeling tool information can be integrated with artifacts from the rest of the software and systems development lifecycle, from requirements definition through testing, even to operational assets. Additionally, the design artifacts are treated like web resources making them available to all relevant stakeholders through a web client providing broader access and transparency of the development process across the development team including extended stakeholders.
Better collaboration to address complexity
Collaborative Design Management’s goal is to help address the challenge of increasing design complexity by providing:
- Central design location that is accessible through traditional desktop clients and a web client to store design artifacts such as models.
- Access to stakeholder of design information.
- Traceability and navigation across the lifecycle artifacts and design disciplines is using OSLC
- Automated documentation generation and reporting across the discipline
A central location to share all the different types of design information creates a common location for developers and stakeholders to access and provide feedback during the development lifecycle to help avoid misinterpretation of requirements so that design objectives can be met. Access to the latest design information can be provided to customers, analysts, quality assurance professionals, suppliers, and operations personnel, along with architects and developers. For example, it is possible today to store design information from IBM Rational and The Mathworks tools in a central location using the design management capabilities of IBM Rational Rhapsody allowing a common location to access, and link, architecture and control algorithm information.
External stakeholders like customers, marketing, or subcontractors and even many internal stakeholders like management may not be able or want to install a design tool to view data. Often reports are created from each particular tool with a dump of data, usually at the time of a design review. These reports can be time consuming to produce and also may not reflect the current state of the design. Being able to gain access to the design information through a web client makes the design information readily accessible from anywhere at any time (Fig. 2). Through the web, reviewers external to the design team can search, review, comment on, and mark up designs stored in the central design hub in real time. The actions from design reviews can be stored and managed in an electronic system associated with the actual design artifacts, instead of manually captured in an external document.
Design teams no longer work in isolation but can collaborate with fellow developers and stakeholders throughout the design and development process. Stakeholders are able to gain a view of the current design status as needed, which improves their understanding and the quality of designs. Stakeholders can determine how their tasks and areas of concern relate to designs with traceable links to work items, requirements, and test cases.
The design information from multiple sources can be linked together using the OSLC. Links from design elements to requirements, test plans, test cases, project plans, and tasks are possible. Links are not restricted to a single tool but can go to any tool supporting the OSLC standard and also web pages. Additionally, the links can be typed to specify the nature of the relationship between the elements. For example, links can be created tracing requirements to a use case that elaborates the requirement. A link of type “satisfies” could be created from the use case to a state diagram that shows the modes of operation that will implement the use case. This makes it possible to navigate the design artifacts similar to navigating links on web pages allowing the teams to gain a better understanding of the overall architect and the interrelations of the various design components.
Changes in requirements are inevitable during the development lifecycle. Using the link information, a graphical view can show all the relations to a design element. This can help analyze the impact a change would have on the design and because links can be go across tools a more complete view of the impact can be observed. Filters can be established based on the link type information to simplify the view for a particular interest of a stakeholder. For example, a safety engineer can filter link types only related to hazard analysis.
Documentation is usually a tedious task for developers left at the end of the project. Most tools have the ability of generating their own reports or exporting data to help the process but creating documentation that includes information from multiple tools is a manual process. A major benefit of models is the ability to produce documentation that helps teams gain insight into the workings of the system. The central location of design information and links between artifacts provides a mechanism that automatic documentation generation tools can use to produce cross product documentation automatically. A report could be produced showing all requirements and the design elements that are intended to satisfy those requirements. This can serve as a way to ensure and validate compliance with industry standards during development audits.
Maximizing, Improving and Accelerating Development
Collaborative Design Management brings stakeholders together around the design process by breaking down development silos and to share, search and review design information even across tools. The OSLC community provides a mechanism to avoid the pitfalls of point to point tool integrations and allow for the sharing, tracing and navigation of data across proprietary tool boundaries. Teams can collaborate with a broad set of stakeholders, gain a better understanding of the impact of changes, perform analysis and produce cross tool documentation. This helps drive improved quality and increases the likelihood of achieving desired business outcomes by:
- Maximizing productivity and lower costs by providing a central location for designs, enabling reviewers to search, view, analyze, and identify reuse opportunities across multiple designs from a variety of sources
- Improving solution quality through collaboration on design reviews that involve all stakeholders
- Accelerating project delivery through living, dynamic designs, and reports
As applications, systems and products continue to become increasingly complex and often interconnected, greater capabilities and improved performance is required, while maintaining high quality. Collaborative design management enables an organization to bring together a broad set of stakeholders—customers, line-of-business managers, operations, development teams, and others—to contribute to and influence the design of products, software and systems. This new level of collaboration helps drive improved quality and achieve successful business outcomes.