IBM Software

Technical White Paper

Three imperatives for advancing product and systems development

Contents
1 The challenge 2 Applying systems engineering 3 Traceability across the lifecycle 5 Access to all engineering information 6 Collaboration across engineering disciplines 8 Conclusion

The challenge
The engineering of complex products and systems involves significant challenges. To survive and prosper organizations must focus not only on engineering and technical excellence, but also on increasingly challenging business objectives. Organizations across all industries are reprioritizing to become more competitive by reducing cost and compressing development timelines. At the same time, quality levels and compliance with mandated or self-imposed standards must be maintained. Organizations are doing their best to do more with less. Business that rely on product and systems development must find ways to: 1. Reduce cost 2. Reduce development time 3. Reduce rework 4. Maintain or increase quality 5. Comply with standards 6. Manage change Product and systems development must become more efficient and effective to meet these goals. It is less clear how this can be done. We believe it will require a new kind of thinking. A systems thinking approach to the challenge suggests that that the product and systems development world be thought of as several related systems. One system is the development organization itself, made up of

IBM Software

Technical White Paper

engineering disciplines and other organizational structures. This system seeks to design, create and produce other systemsproducts such as vehicles, smart phones, drones and spacecraft. Increasingly, complex products are not produced in isolation but in product lines with complex feature mixes. In the past producing technical products was simpler. All an organization needed was good engineers and some simple office tools and they could produce amazing products. With the dramatic rise in software-driven functionality, products are now much more complex. An organization needs a system in order to be more efficient at producing the products and systems its customers require. So the picture that emerges is a system, using a system, to create other systems. In thinking this way, an organization can examine more closely the interconnections and functional dependencies that make this process efficient and productive, or that contribute to extra cost, time, and waste.

understood or improved by considering only the functions of its parts in isolation. A society cannot be understood by considering only the behavior of individuals. What its like to drive a car cannot be understood by looking only at the functions of the engine, suspension and infotainment system. An engineering organization cannot be understood or optimized by only considering each engineering discipline in isolation. By taking a systems approach across the lifecycle and throughout all levels of systems development from the highest system level to subsystem and component levels, development programs are more likely to meet their cost and schedule targets. Recent research shows that a typical program might be investing in systems engineering at about 8.5 percent of total program cost. If the program increased its systems engineering effort level to an optimum of 14.4 percent, the USD $200,000 investment would save the program USD $500,000 on average.1 In taking this systems approach and seeking to advance product and systems development to achieve current business objectives, three imperatives emerge as key focus areas, as described in Table 1.

Applying systems thinking

The application of a systems viewpoint to advancing product and systems development means taking a holistic viewpoint. The essence of systems thinking is that no system can be
Traceability across the lifecycle

Capabilities must be tightly integrated across all functions in the engineering lifecycle, to ensure design integrity and demonstrate compliance. Requirements must connect to change requests and to models and then to workflow tasks, to verification and validation procedures, and even into the operations, maintenance and product evolution phases. Automated traceability across the lifecycle saves time and cost when changes occur, reduces engineering overhead and rework caused by misunderstandings. Engineers can spend more time engineering.

Access to all engineering information Collaboration across engineering disciplines

Engineers must be able to query, organize, and reuse engineering informationregardless of the location or sourceacross product lines so that everyone has a common understanding of the products and systems they are building. Open access raises engineer productivity and reduces the time to engineer new product configurations. Engineers of all kindselectrical, mechanical, software and othersmust collaborate in real time and work together in new ways even if they use different tools from different vendors. Product innovation cycles can be accelerated by more virtual, model-based development. Trusted collaboration between disciplines enables more frequent delivery of working systems. Flexible, automated collaboration makes an engineering organization more agile and scalable across geographical, organizational and cultural boundaries.

Table 1. Three imperatives for advancing product and systems development

IBM Software

Technical White Paper

Traceability across the lifecycle

Traditionally, the concept of traceability has had the objective of showing the relationships between requirements. Different kinds of relationships may be characterized as traceability linkagesthere isnt a single, universal meaning for a traceability link. While traceability began with requirements, it is also applied to other related information in an engineering organization, such as model elements, change requests, test cases, defects, configurations, product variants, work tasks and compliance standards. Traceability of requirements is used to meet one or more of these three main purposes: 1. Prove that requirements were met by tracing these requirements to verification and test procedures. 2. Provide the linkages required by development or compliance standards, such as those for safety-critical or life-critical systems. 3. Link requirements for better documentation of requirements decomposition, more complete analysis of changes, and improved understanding of how the system was designed. All of the imperatives identified in the previous section concerning traceability, collaboration, and informationcan be thought of in three developmental ages: the stone age, the industrial age, and the systems age. Regarding traceability, in the early stone age links were recorded in static office tools such as spreadsheets and word processing documents. Such links were staticthat is, they were created once and then recorded. If a requirement changed, traceability links had to be updated manually, if at all. In practice, such traceability matrices were often created once, to meet a required deliverable, but then not referred to again, since subsequent changes, if not manually incorporated, rendered traceability matrices obsolete and useless.

In the industrial age of traceability, requirements management tools became available and automated much of the work of creating and maintaining traceability links, at least for requirements. This was certainly an improvement, because these systems made it possible to keep traceability links current throughout a program lifecycle, assisting engineers in managing the impact of changes to requirements. The disadvantage to these closed systems was that they could not link requirements to items outside the requirements database itself. The need to link requirements to verification and test cases often caused engineers to store the test cases in the requirements database. Doing this was helpful, but it had the disadvantage that requirements systems were not designed to manage tests, especially tests that occurred in downstream, discipline-specific engineering activities. Organizations relied on an export/import process, where requirements were copied out of the requirements repository used at the top level by systems engineers, then imported into other requirements systems or office tools used by downstream engineering disciplines. At the time of the export, the traceability links are broken and must be re-established manually or, more often, not at all. Many organizations find that their requirements management processes, methods, and tools are effectively implemented at the top systems engineering level, but break down as requirements are decomposed and f lowed down using export/import into the disciplines. In the systems age of traceability, requirements may be freely linked to many other kinds of information in the engineering process for varied purposes. A requirement may be linked not only to its upstream source requirement and downstream derived requirements, but also to a model element in the design, a change request, a test procedure, a defect, a task assignment, and a product baseline. Such linkages exist conceptually in every engineering process, but they are often

IBM Software

Technical White Paper

managed in free-form text documents, informal communications, or simply by human memory. In the systems age, organizations shift from relying on human memory to relying on networks of traced information, which grow organically, so to speak, as the development program proceeds.

As a change is received from the customer, it is captured and linked to relevant requirements that may change as a result, along with assignable work tasks to carry out this change. It should also be linked to verification and validation procedures, required processes and other connected engineering information. In the systems age, traceability takes on a new richness as links represent dependency, derivation, fulfillment, verification, impact, or assignment to a product variant or configuration. Each link has some kind of rationale for its existence; this rationale itself is often an important part of the engineering information. Long-running engineering efforts such as those in military and space programs risk losing this rationale as senior engineers age and retire. Capturing such information as text, symbolic models, even audio and video commentary, then linking it into the evolving network of linked information turns informal knowledge into a valuable organizational asset. It also shortens the startup time and learning curve when the system must be maintained, changed, or evolved into something new. Traceability becomes more significant as complex products evolve over time. Industries like automotive and consumer electronics have always classified products in product linessets of related products, released over time, sharing some aspects of design or applicability. Even in the highly customized world of aerospace and defense systems, new products are developed as evolutions of previous products. The ability to effectively reuse engineering information across such sets of related products is a key to cost effective, low-waste product development. Traceability is essential to this kind of reuse. Instead of making a new, disconnected copy of the information, the better approach is to create dynamic traceability links to the original information, showing the changes and unifying the engineering approach across the product line.

Source Requirements Derived Requirements

Task

Defect

Rationale

Change Request Verication & Test Procedures

Models, Designs, Architecture

delivery.

Figure 1. The evolution of all three imperatives for product and systems

It is vital that this information be captured as it is createdin fact, the creation and the capture should not even be different activities. As an analogy, a building architect does not design a building and then capture it in drawingsthe drawings are the design. As a new requirement is uncovered, for example, it is both captured and linked to other relevant requirements, models, verification and planned product versions and baselines.

IBM Software

Technical White Paper

Stone Age Traceability

Static, afterthought, ofce tools

Industrial Age
Proprietary databases, private requirements links

Systems Age
Comprehensive linking of multiplatform crossdiscipline engineering information Rich task workows, integrated systems Linked data, dynamic relationships, search

Collaboration

Meetings, telephones, documents Assembling unstructured information into documents

Email, document repositories

Information Integration

Separate database silos, import/export

and systems development. In the stone age of product information, which is only perhaps a half-dozen decades old, product information was created, housed, and maintained entirely on paper. Copies were printed or special rooms created to give everyone access to the information; cross-referencing was done by annotation or through manually created traceability matrices. As development standards evolved, they naturally focused on what documents should be created, and what each must contain. The entire development process was document-driven. Later, of course, documents moved from being on paper to being electronic, but they were still documents. In the industrial age of product information, specialized engineering software tools emerged for various engineering tasks and disciplines, each with its own database, information format, and internal data relationships. This was the age of the information silo. Tools did not integrate with each other, but even more importantly, the information stored in each of them could not be connected, except perhaps by reverting to the stone age, and writing new documents to explain the relationships, connections, and dependencies. The disparate tools and information of each discipline may have even increased the separation distance of already separate disciplines. In the systems age, products and systems engineers build more complex products, which requires more connection between what were previously quite separate disciplines. What were once purely mechanical devices now contain electronics and embedded software. What was once a dedicated electronic circuit is now a small computer with an operating system and application software. As what engineers build becomes more interconnected across disciplines, so must the product information.

Table 2. Traceability relationships in the systems age.

Section summary
To achieve traceability across the lifecycle in the systems age, teams must: 1. Develop an information architecture, using a systems thinking approach. Consider all engineering activities as potential contributors to the information architecture and plan how information will link and connect, and what those links will mean. 2. Capture information and linkages as they are created, not as an afterthought or separate process. 3. Use traceability to capture senior engineer knowledge about the product and the workflow process. Links are knowledge! 4. Avoid relying on export/import since it breaks traceability links and causes extensive rework to re-establish them later.

Access to all engineering information

Engineering product informationincluding requirements, designs, architectures, functional descriptions, operational scenarios, and test proceduresis the lifeblood of product

IBM Software

Technical White Paper

Achieving this kind of access to engineering information requires a new, systems thinking approach. Simply reducing all engineering information to documents and storing the documents in a single repository may provide a single point of access and some level of coordination, but it doesnt allow the information to be interconnected in ways that match the complexity of the product. Trying to design a single master database into which all engineering data of all kinds can be stored using some kind of master schema is impractical in the rapidly evolving, multi-vendor world of engineering design. Schemas based solely on mechanical parts structures are only useful once the mechanical design is finalized; and even then they lack the logical architecture and product line perspective vital to reuse and modularity. The two main strategies for organizing engineering information in the system age are the use of models and the linking of data. Engineering disciplines have been using models for years. Mechanical engineers have CAD/CAM models, electrical engineers have electronic design models, and software engineers have UML models. With the need to connect such models into a conceptual model of models, higher level modeling languagesnotably the Systems Modeling Language (SysML)have been developed to provide a non-discipline specific way of expressing system behavior, structure, and performance. Such system models provide a lingua franca for all engineers and facilitate communication and reasoning about multi-disciplinary system functionality. The practice of model-based systems engineering (MBSE) is increasingly being embraced as the best way to deal with product complexity at the systems level. The success of the Internet illustrates the other strategy for achieving engineering information integrationthe linking of data. The Internet is designed around the concept of leaving information where it is, and linking to it in place, rather than trying to force it into a common format and location.

Engineering information can be maintained in various tools and technologies, both discipline-specific and multi-disciplinary, and linked in place to represent product designs, versions, variants and configurations. By providing universal query capabilities engineers can reduce the time they spend looking for related information and spend more time doing engineering.

Section summary
To effectively access all engineering information in the delivery process, teams must: 1. Store information in models with built-in relationships and interconnections, rather than in static documents. 2. Link information in place, across disciplines to manage product, and product line complexity

Collaboration across engineering disciplines

Everyone recognizes the relative effectiveness of small, co-located engineering teams. Scaling this effectiveness to larger or distributed teams, however, brings a new set of challenges. Small teams are effective mostly because they communicate in natural ways. Being in the same location, they communicate often, both formally and informally, and each team member maintains a general awareness of what his or her colleagues are doing. Potential issues and misunderstandings of requirements, designs, and constraints are discovered sooner and resolved before time is invested in work that must later be re-done. It is easy for most to recall the days when virtually all communication was real-time, either in person or on the telephone. This had a certain effectiveness, but also had limitations, mainly time and persistence. Live meetings, whether in person or on the phone, take everyones time and, unless detailed meeting records are kept, result only in transient communication. If someone missed the meeting, they were literally out of the communication loop.

IBM Software

Technical White Paper

The era of email brought improvement in the ability to communicate asynchronously among a large number of engineers. But email, too, has limitations. For one, email is an inherently open-ended form of communication. When email is used to assign a work task, there is no built-in way to track that task for status updates or to assure completion. Also, email communications do not become part of the engineering information set. They are stored in a different place, often in a different format, not linked to program information; they may even be automatically purged at pre-set time intervals! The communication and collaboration challenge is even more daunting when crossing tribal lines of engineering teams and their diverse disciplinessystems, electrical, mechanical, and software engineers. While usually not hostile toward each other, these engineering disciplines often speak different languages, use different notation in drawings and models, and even have differing or competing priorities. Aligning on common terminology at the systems level, adopting common diagrams and formats, and using a generic, common modeling language like SysML, can facilitate communication and collaboration. In the systems age of collaboration, engineers use systematic but f lexible workflows and collaborations, based on organizational processes and standards to improve communication and agility in the development process. By analogy, social networks like Facebook and Google+ are more effective than email for keeping in touch with friends and family because they systematically automate common social practices such as exchanging messages in a conversation, sharing photos, events, invitations, and games. The result is social scalabilityusers can keep in touch with many more friends effectively than with more traditional means of social communication like email. In an effective engineering organization, collaboration systems must automate the ways that engineers communicate, share information, and manage tasks. Instead of emailing disconnected work products, such systems can enable rich tasks. A rich task is one that, when it is assigned to an engineer, carries with it all of the information needed to perform, verify, and complete

that task. A study by the Aberdeen Group showed that as much as 30 percent of an engineers time can be spent looking for information to do his or her job. With a rich task environment, the information is right there, attached to the task. For example, a task might be linked to a change request, some related requirements, a model, a verification procedure, and the processes needed to perform the task. This related information is linked, not copied, so it is always current. Collaboration also means enabling and automating different working styles in teams. Teams in both software development and other engineering disciplines are seeking to become more agile, more flexible, and to apply newer, faster ways of working. To scale such agile methods across a large engineering program requires quick, flexible, real-time communication about what engineers are doingwho has capacity, who is overloaded, or who needs help. Development becomes more of a team sport like soccer, with quick real time interaction, and less like gymnastics where individual results are more important than teamwork. An important aspect of teamwork and agility is the ability for teams to work concurrently on the same or closely related engineering artifacts. This ability is crucial to the faster product release cycles needed to stay competitive in most industries. For instance, two teams may be working on a subsystem that is needed, in slightly different versions by more than one system. The simplest way to manage this is to allow the teams to work independently until each version of the subsystem reaches a releasable state, but this is wasteful and redundant. Instead, design revisions should be shared between the teams regularly, accelerating the progress of both. Similarly, disciplines like electrical and embedded software must co-develop in parallel, so they reach completion together in an integrated way, rather than sequentially. As engineering product lines become more complex and interrelated, the discipline of product line engineering (PLE) becomes a critical enabler. PLE organizes the version and variant management of requirements, designs, models, and test results across engineering disciplines, allowing engineers to manage both the common aspects and the variations without wasteful redundancy.

A comprehensive collaboration approach also means capturing important ad-hoc communication typically lost in transient emails and integrating this information with the evolving body of engineering information. This helps capture the complete history, as well as the thought processes and rationale, thus facilitating later issue analysis, maintenance, system evolution, and reuse.

Copyright IBM Corporation 2013 IBM Corporation Software Group Route 100 Somers, NY 10589 Produced in the United States of America May 2013 IBM, the IBM logo, ibm.com, and Rational are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at Copyright and trademark information at ibm.com/legal/copytrade.shtml This document is current as of the initial date of publication and may be changed by IBM at any time. Not all offerings are available in every country in which IBM operates. THE INFORMATION IN THIS DOCUMENT IS PROVIDED AS IS WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT. IBM products are warranted according to the terms and conditions of the agreements under which they are provided.
1

Section summary
To achieve collaboration across engineering disciplines, teams must: 1. Use collaboration to scale small-team communication effectiveness to large, distributed teams 2. Replace email with flexible, rich task workflow management 3. Capture relevant informal communication in the engineering canon 4. Use common terms and generic modeling languages to aid in cross-discipline communication

Conclusion
Its an exciting time to be an engineer, especially in the product and systems development industry. The necessity of delivering increasingly complex and smarter products in less time and at a lower cost can be the mother of invention for new strategies and development technologies. Building smarter products and systems means using smarter systems to build them. The implementation of strategies like those described here, based on a sophisticated engineering solution platform, can be a bridge to a new level of engineer productivity and innovation.

Honour, Eric, Systems Engineering Return on Investment, University of South Australia, 2013, p.180 Please Recycle

For more information

To learn more product and systems solutions from IBM, please contact your IBM representative or IBM Business Partner, or visit the following website:
ibm.com/software/products/us/en/category/SWV00

Additionally, IBM Global Financing can help you acquire the software capabilities that your business needs in the most cost-effective and strategic way possible. Well partner with credit-qualified clients to customize a financing solution to suit your business and development goals, enable effective cash management, and improve your total cost of ownership. Fund your critical IT investment and propel your business forward with IBM Global Financing. For more information, visit:
ibm.com/financing

RAW14325-USEN-00