Hardware/software codevelopment using a model-driven systems development (MDSD) approach

Document options Document options requiring JavaScript are not displayed New site feature Check out our new article design and features. Tell us what you think. Rate this page Help us improve this content

Level: Introductory

Murray Cantor, Distinguished Engineer, IBM
Gene Roose, Systems Engineering Consultant, IBM

15 Dec 2005

from The Rational Edge: This article introduces the rationale and principles behind model-driven systems development, or MDSD, a new approach to specifying and creating hardware and software for complex systems.

The product development landscape has changed appreciably in the last quarter century, largely because of technology improvements, and especially because of advances in microelectronics and software. These advances have led to greater flexibility in systems development, which presents both opportunities and challenges to systems architects, designers, and developers.

In the past, when distributed networking, software engineering, and embedded systems capabilities were immature, traditional product development focused on delivering services primarily via hardware. Today's richer capabilities enable services and functions to be implemented in hardware, firmware, software, or some combination of the three. But this freedom comes at a cost: greatly increased complexity. With all the possibilities for allocating functions to components, combined with the range of choices for implementing those functions, traditional management methods are no longer adequate.

In the face of program and project management constraints related to functionality, cost, and schedule, systems development teams need a robust methodology that can tame this mounting complexity.

This multi-part series explores joint hardware/software product development from a systems perspective and offers a model-driven systems development (MDSD) approach designed to optimize functional allocation. It applies techniques and framework elements incorporated in the current release of RUP-SE, a proven MDSD framework that is an extension of the IBM Rational Unified Process®, or RUP®, which specifically addresses systems engineering challenges. The artifacts referred to in this article are contained in the new release of the IBM Rational Method Composer (available December 2005), which provides a flexible framework for tailoring processes, along with best practices and online guidance for product development teams engaged in MDSD.

This first article in the series relates the unique challenges of hardware/software codevelopment to the limitations of traditional systems engineering approaches. After introducing MDSD and presenting an MDSD approach based on extensions to RUP-SE, it discusses IBM Rational's six principles of systems engineering as they relate to MDSD.

Subsequent articles will focus on the joint realization of requirements crossing hardware and software boundaries and multiple viewpoints. This approach provides an effective hardware/software codevelopment process that facilitates collaboration both within and among multidisciplinary teams, and guides project and program management to optimize value for stakeholders throughout the product lifecycle.

More embedded software, greater complexity

The number of products built around embedded software is rapidly growing, and the embedded software's functional capabilities grow increasingly richer and satisfy increasingly complex needs. These are predictable developments for industries such as aerospace and defense, which we typically associate with highly complex products that require systems engineering techniques to create. However, today they apply equally well to consumer products and appliances -- from high definition television (HDTV) and media players, to washers and dryers, to cell phones and PDAs.

This new, embedded software frequently displaces functions previously realized in hardware; for example, digital fly-by-wire flight control systems have superseded mechanical control systems in aircraft. Software also increasingly enables new functions, such as the intelligent cruise control, driver assistance, and collision detection systems in high-end automobiles. Indeed, the average car now contains roughly seventy computer chips and 500,000 lines of code -- more software than it took to get Apollo 11 to the Moon and back. In higher-priced cars, in which embedded software delivers many innovative and differentiating features, the code volume can be far greater.

However, high code volume itself is not a problem. What causes implementation headaches are the ever more complex interactions across components and subsystems. Bugs that emerge only after models enter production have resulted in rising warranty and quality assurance costs and damage to brand images. As Figure 1 illustrates, in the automotive industry, malfunctions in electronic components easily account for as many failures as all other automotive systems put together.

Figure 1: Percent of malfunctions caused by various automotive systems

More functions, fewer components

As software content grows in both volume and complexity, one might logically expect the number of electronic components to grow with it. In fact, the opposite is the case. Engineers are charged with achieving tighter integration among components in an effort to address cost, reliability, and packaging considerations, so they are constantly working to decrease the number of software components but deliver an ever-expanding range of capabilities (see Figure 2).

Figure 2: Number of functions compared with number of components

The trend toward increased integration among system hardware and software components introduces concerns beyond those traditionally addressed in systems development. In particular:

• Development teams must be increasingly agile in order to respond to a volatile environment, in which requirements might change even before a system that satisfies stakeholder needs can be deployed. Requirements volatility stems largely from the rapid pace at which underlying system technologies change; this leads to early obsolescence of designs and components that might otherwise be reusable.
• Tighter communication and collaboration are essential, both within and across teams and engineering disciplines. Such cross-boundary collaboration is challenging in traditional "siloed," domain-centric development organizations.

These challenges are further compounded by a conflicting demand. While components must be tightly integrated to function effectively, business requirements for product maintainability and extensibility naturally lead to loosely-coupled components that can more readily be replaced and/or reused. Satisfying these conflicting demands requires that the organization and process coevolve in order to deliver a solution that adds maximum value and delivers competitive advantage. As we will see, the model-driven systems development approach described in this article can help facilitate the coevolution process.

The traditional approach to function allocation

The pressure to add more and more functions to fewer and fewer components greatly compounds the challenge of allocating functions among components. Traditionally, we would accomplish this allocation using a two-part, requirements-driven approach:

• We would functionally decompose the system to break out functions in a hierarchy of requirements (requirements decomposition).
• At the same time, we would decompose the system into the physical component pieces from which it will be assembled (assemblage decomposition).

We would use requirements-driven systems development methods to define requirements early in the lifecycle, and then use the techniques of functional allocation to derive additional requirements and allocate them to subsystem components. At every level of the hierarchy, we would use functional analysis to derive requirements and engineering methods to derive measures of effectiveness. Once the requirements were allocated to a sufficiently deep level, detailed design activities would begin.

These methods were designed to create a point solution -- that is, a solution for a specific set of requirements. Thus, an essential assumption of this method is that requirements must be well understood before development can go forward. However, in today's hardware/software codevelopment scenarios, that's often not the case.

The requirements mapping problem

Consider the difficulty involved with mapping requirements at the bottom of the requirements hierarchy to the physical system components.

The end result of any systems development methodology is a product,¹ usually composed of many atomic sub-elements (components) that can be identified by part number and field-replaced as a unit. The development organization faces a challenge as the number of functions increases, especially in products composed of hundreds of atomic components. Requirements-driven systems development methods focus on functional decomposition, often in isolation to assemblage composition, which typically occurs late in the development lifecycle.

A requirements-driven approach also forces early technology decisions and allocation of function to hardware, firmware, and software entities. Product (think "hardware") teams normally make these decisions and pass on detailed requirements to the software and firmware developers, who develop their components separately. Engineering-level product assembly and integrated systems testing occurs after the bulk of product development has concluded; it is the final gate before manufacturing can commence.

What is the problem with this process? As development proceeds, functions must be allocated to atomic product components (see Figure 3). A single function may be allocated to several physical components. For example, collision preparation in an auto will affect the brake system, the safety system (which itself includes airbags, seatbelts, headrests, etc.), suspension, and more. Similarly, most physical components will embody many functions. A car's engine/drivetrain, for instance, includes acceleration/deceleration, engine braking, cruise control, start/stop, shifting, and more.

Figure 3: The allocation of functions to atomic product components

When complex, embedded software is involved, this leads to a many-to-many decision tree with thousands -- perhaps millions -- of possible allocations. Existing requirements-driven systems development methods do not provide guidance on how to simplify this allocation or how to optimize trade-off analysis and ultimate functional assignment to hardware, firmware, and software entities and their physical component allocations.

This lack of guidance is a major deficiency. Factor in the challenges of operational integration, increasing requirements volatility, and a need for unprecedented inter- and intra-team collaboration, as we've already discussed, and it's easy to see that traditional, requirements-driven approaches have become untenable for hardware/software codevelopment efforts.

Clearly, there is need for a more robust methodology, which we will now propose.

A new approach: model-driven systems development

In a purely software-oriented systems environment, the deficiencies of traditional, requirements-driven systems development methodologies have been understood for some time. The several alternative methodologies and frameworks that have been offered share such common traits as model-based and iterative development. Agile Modeling, eXtreme Programming (XP), and the IBM Rational Unified Process, or RUP, are three such methodologies.

However, when a system entails a combination of large, complex, and/or multisite hardware/software product developments, pure software methodologies don't generally scale well. This is precisely the reason why IBM Rational developed systems engineering extensions for RUP, more commonly known as RUP-SE. A proven example of a successful MDSD framework, RUP-SE has been used and refined by IBM Rational and its clients for more than eight years.

The MDSD solution described in this article further extends RUP-SE. It provides methods to identify key hardware/software collaborations and interfaces, and allocate both functional and supplementary requirements (such as reliability, performance, and capacity constraints) to model elements encapsulated within RUP-SE's current, multiple-view development framework. The latter is addressed in a joint realization table (JRT), an extension to RUP-SE's current service specification development artifact.

A brief overview of RUP-SE

Like other MDSD methodologies, RUP-SE builds on the techniques of requirements-driven development methods. In general, systems development is concerned with decomposing a system in order to improve our comprehension of both the system itself and how it meets stakeholder needs. The development team must further understand the business concerns, or mission, and the system's role in addressing those concerns and realizing mission goals. To ensure that the system indeed satisfies its intended purpose, the development team must establish that the top-level system requirements, and the requirements derived from them, are satisfied by the collaboration of the system's components. To be effective, model-driven systems development must address these system concerns and also provide the development team with an improved understanding of the system, its goals, and its components.

RUP-SE is a collection of well-evolved and proven techniques for addressing complex development challenges that leverages people's ability to deal with complexity through abstraction. It enables you to model complex systems at progressively more detailed levels of specificity across multiple engineering viewpoints. Table 1 shows RUP-SE's typical system modeling viewpoints, as well as sample development artifacts produced for specific model levels.

The viewpoints listed in the columns provide a separation of engineering concerns, allowing a complex system to be partitioned into either engineering disciplines or clearly delineated collections of pertinent system elements. These viewpoints are typical for a joint hardware/software system. A software-only system would not require the geometric viewpoint and might not require the physical viewpoint, whereas a system such as an automobile might require additional viewpoints to encapsulate specific aspects of its architecture, such as energy transfer or collision response.

The model levels listed in the rows address increasing levels of specificity and detail as system development progresses. The context level provides a black box view of the system, external actors, and the boundaries of system/actor interaction. These boundaries are critical early elements of architectural design, as they immediately focus the development team's initial system analysis.

Once the context level has been described, the development team "opens" the black box and begins to discern what discrete elements must be incorporated in the system to satisfy the services identified at the context level. This initial white box view allows the team to determine subsystems (in the analysis-level logical view) and localities (in the analysis-level physical view).

At the next level of detail, the team begins to realize the analysis-level elements and specifications in some combination of software, hardware, and firmware, as well as system worker entities. This transformation is from the abstract to the concrete and leads fairly directly to the final level, which describes the actual implementation of the model into a deliverable product or service.

This methodology provides the following benefits:

• Separation and integration of engineering concerns. A common set of design elements is used across the various pertinent engineering viewpoints. For example, design elements in the analysis logical view are partitioned across localities in the analysis-level physical view. Whereas the individual RUP-SE model viewpoints enable the development team to partition the overall complex system into more readily addressable collections of concerns (separation of concerns), the set of common design elements in the various views at a specific system model-level enable the system under consideration to be reconstituted as a whole (integration of concerns).
• Recursive system decomposition and transformation from the abstract to the concrete. This approach enables the development team to break apart the system into progressively smaller and unique structural elements. The recursive nature of the approach allows decomposition to occur as many times as needed to identify atomic system elements. This approach recognizes that system requirements and functions are not well understood in the early development stages of a complex system. The higher levels of abstraction contained in the context and analysis model levels foster greater development team creativity, flexibility, and responsiveness when they are most needed -- early in the development cycle. This approach addresses high-risk items such as architectural robustness and misunderstood/incomplete requirements in a manner that optimizes cost and schedule, by minimizing rework and scrapping of system components due to technology change.
• Scalability to systems of increasing scope and complexity: The basic RUP-SE framework and systematic development approach can be applied across the systems development spectrum. The viewpoints pertinent to the system under consideration (and only those viewpoints) can be specified, along with the key artifacts to be produced in each cell or view. The system under consideration could actually be a subcomponent of a larger system -- such as an automotive supplier's generic "plug-and-play" braking system -- or a business component, such as an enterprise mail room that encompasses business processes, print/mail workflow, and print/mail technology components.

As we've just seen, RUP-SE explicitly supports the unique issues that development teams face in constructing a sound architecture for complex hardware/software systems. The RUP-SE framework is one element of a comprehensive set of systems development lifecycle management principles, best practices, methods, and tools. The entire solution set is well beyond the scope of this article. In this context, however, a discussion of Rational's six systems engineering principles reinforces the value of the RUP-SE methodology and further clarifies the overall MDSD approach for successful hardware/software codevelopment efforts.

The six principles of systems engineering

IBM Rational's six principles of systems engineering are a set of high-level systems development guidelines derived from the careful analysis of successful, complex systems development engagements over the past ten years. Although they are neither comprehensive nor mutually exclusive, they serve to highlight key areas of focus for organizations interested in quickly building expertise in complex systems development. They also serve as a "measuring stick" for assessing potential problem areas and the root causes underlying symptomatic project deficiencies or failures.

It is well-known and accepted that function, schedule, and cost are three key and mutually dependent aspects of project management -- make a change to one, and the effects often ripple through the other two.

A similar relationship exists in product and program management for complex systems development. As shown in Figure 5, the three key aspects are:

1. Systems architecture
2. Organizational structure, including the systems development infrastructure
3. Process, including workflows, best practices, and the like

The six principles of systems engineering address all three aspects. The three technical principles (noted below) focus on architecture and the derivation of system models, while the remaining principles provide the complementary infrastructures and workflows needed to optimize the technical development environment.

Figure 4: Three interdependent aspects of managing complex systems development

The six systems engineering development principles are:

1. Decompose systems, not requirements (technical).
2. Enable both separation and integration of «key systems development» concerns (technical).
3. Specifications flow up and down the architecture (technical).
4. Systems and components collaborate; so should development teams.
5. Development organizations should reflect product architectures.
6. Base the «development» lifecycle on removing risk and adding value.

Let's examine each of these principles, initially from a generic systems engineering view, and then specifically in the context of joint hardware/software development.

Decompose systems, not requirements

Since systems and software engineering principles and methods have been written about, discussed, and applied in countless cases, one might think that development teams have a common understanding of such terms as "system" and "systems engineering." Unfortunately, this is not the case; neither across enterprises within a specific industry nor across the product and functional domains within an engineering development community in a single enterprise.

According to INCOSE (the International Council on Systems Engineering), systems engineering is²:

An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem:

• Operations
• Performance
• Test
• Manufacturing
• Cost and Schedule
• Training and Support
• Disposal

A system is a group of interacting, interrelated, or interdependent elements forming a complex whole, which provides a set of services that are used by an enterprise to carry out a business purpose (mission). System components consist of hardware, software, data, and workers³. Put simply, a system is a complex entity that provides some tangible result of value. Systems engineering is a disciplined approach that helps us examine desired results and determine what can satisfy them. It also helps us determine how to do this within a set of business-critical constraints (cost, schedule, testing parameters, ease of manufacturing, and so on). The "what" is the system, the "how" is the functional requirements, the "business-critical constraints" are the supplementary requirements, and the "desired results" are products of use cases.

At the highest level of abstraction, we can view the system as a single entity (complex whole), or black box. However, to build a system, we must also be able to open the box, look inside, and see what set of interacting, interrelated, or interdependent elements make up the system. This is called the white box view. The primary task of systems (and software) engineering is to recursively move from black box to white box views, opening the system box, subsystem boxes, and sub-subsystem boxes until we ultimately determine the set of interacting and interdependent elements that can provide the system's desired results.

A close look at the INCOSE definition of systems engineering does not reveal a development methodology preference for realizing systems. Traditional requirements-driven methods, with their typically rigid and rigorously defined project tasks, milestones, resources, and schedules, seem to apply. However, as noted earlier, these methods were not designed with a focus on early risk mitigation, fluid requirements, or building systems for which the solution was initially indeterminate; or even at the limits of scientific or technical knowledge.

As we noted earlier, focusing primarily on the requirements and their functional allocation leads to early (and binding) decisions about technology and architecture, even if the architecture is not explicitly addressed. These early decisions can lead to undesirable results:

• Delivery of systems that fail to meet key stakeholder needs.
• Significant rework to address changing or misinterpreted requirements.
• Expensive "heroics" in the final development stage (systems integration) to "rescue" runaway projects.
• Worst of all, scrapping the system entirely, after heroic efforts fail.

To avoid such problems, we recommend shifting the focus from immediately allocating functional system requirements to preconceived implementation-level components -- for example, an existing software module or off-the-shelf hardware component -- toward more thorough analysis of an abstraction of the ultimate system.

Requirements analysis, allocation, and validation are clearly critical elements of this approach, but they are not the focus of system analysis and synthesis. The goal is to decompose the system structurally in a set of logical steps, following this process:

1. Understand the workings of the system in its intended environment. Treating the system as a black box, identify environmental elements that interact with the system (the system actors) and the actual interactions and results (system use cases and resulting services). In RUP-SE modeling, this is system analysis at the context level.
2. Decide how to initially partition the system into elements whose collaborations will provide the services satisfying the needs placed on the system at the context level. Recursively examine elements from both black box and white box perspectives until the key functional and supplementary requirements are satisfied by the interactions of the interdependent system elements. This is investigation at the analysis level in RUP-SE.
3. Once the system architecture has been derived abstractly through this process of structural decomposition, the next step is to determine how system elements will be realized. This is a transformation from the abstract to the concrete, with the realization partitioned in some combination of hardware, software, firmware, data, and workers. RUP-SE calls this the design level of systems development.
4. Finally, the system is constructed, tested, and prepared for release. The designs specified in the previous step are implemented (optimally in "release-ready" iterative stages as defined within the RUP and RUP-SE frameworks). This final stage of development is captured in RUP-SE's systems development modeling implementation level.

As we proceed down from level to level, requirements are more precisely allocated to system elements, uncertainty is progressively addressed and eliminated, and the system can be iteratively demonstrated and assessed. Each level of decomposition forces design decisions, providing ongoing synthesis, coupling of requirements and design specifications, and increasing system detail.

Although the steps above may appear to be sequential, and investigation at a lower, more detailed model level seems to require completing activities at higher levels, this is often not the case in practice, due to a range of factors. These factors are addressed by the next two principles of systems engineering.

Enable both separation and integration of concerns

A natural way to deal with system complexity is to intelligently partition the system into smaller, less complex pieces. The way in which to do this varies, but for similar types of systems, the partitioning tends to follow the same pattern. You might partition an automobile, for example, by grouping related functional components, such as chassis, drivetrain, interior, exterior, electronics/software, and steering/braking/suspension.

However, partitioning a system from only one perspective will not likely facilitate the allocation of all stakeholder needs. Systems engineering is not narrowly focused on building a system satisfying functional needs; rather, it must holistically treat the system in its intended environment as seen by operations, manufacturing, service, system actors, and other stakeholder groups. Performance, ease-of-use, aesthetics, reliability, compliance, and all other key constraints must be addressed.

Examining a system from multiple perspectives while simultaneously trying to satisfy dozens of nonfunctional constraints might seem like a way to compound development complexity, not reduce it. Instead of dealing with one perspective with n constraints, the development team has to face m perspectives with n constraints. This is precisely the issue that the second system engineering principle addresses. It is not sufficient to merely partition a system to enable a separation of engineering concerns. The chosen systems engineering development methodology must also provide means for system re-integration.

As mentioned earlier, a combination of existing RUP-SE framework elements and the new joint realization table (JRT) construct provide for both the separation and integration of key systems development engineering concerns. This framework is flexible and robust enough to support development activities across a wide range of industries and products.

In practice, the framework is tailored to either a specific product or set of products. The process of tailoring the framework usually occurs early in the development cycle. In RUP, this would be near the end of the Inception Phase. The tailoring addresses two primary questions:

1. Which engineering viewpoints must be addressed in system modeling and development? For a joint hardware/software system, this would include at least the logical, physical, and information viewpoints. In most cases, the geometric viewpoint would also apply.
2. Which individual model views will be addressed and what artifacts will be developed for each view? For example, the Analysis Level Logical View captures the logical decomposition of the system. Here we begin opening the black box that is the system and determining the set of internal elements whose collaboration satisfies the demands actors place on the system, which were established in the Content Level Logical View. In our MDSD approach, this logical structure and its accompanying collaborations will be captured using Unified Modeling Language (UML) diagrams in the system model artifact.

The product of the MDSD framework tailoring is the development case artifact, which will guide the development team toward tangible results. These results are represented as artifacts in the individual views as development progresses through iterative cycles of system definition, analysis, design, construction, and test.

Specifications flow up and down the architecture

In a perfect systems development environment, the processes outlined above to decompose a system structurally while enabling both separation and integration of concerns should naturally proceed in a top-down fashion. However, perfection is rare. Uncertainty, misunderstanding, miscommunication, change, technical shortfalls, and other factors all inhibit a top-down flow from context to analysis to design, and ultimately to implementation, from proceeding flawlessly. Acknowledging these inhibitors and addressing them as early as possible in the system development lifecycle is ultimately the key to success and a foundational principle of model-driven systems development.

In reality, specifications flow up and down the architecture. In fact, specifications flow up, down, and sideways. Discoveries made in one view may very well radiate out to affect artifacts within other views on the same model level; they may also flow both up and down model levels within the same viewpoint. Is this an indication that the system's architecture was flawed in the first place? Not necessarily. For instance, discoveries made relatively early in the development cycle, while analyzing system or subsystem prototypes, can easily require significant modifications to the system architecture.

Here's a specific example: Typical printing system architectures include a single subsystem to transform input data into the format required by the marking (imaging) engine. This subsystem normally resides in the printing system's control unit (a single locality). Early in a particular printing system's development, prototype testing revealed that there was insufficient processor, memory, and data bandwidth available to meet specified page printing targets. Based on computing technology available at the time, the only way to meet the bandwidth requirements was to spread the data transformation across three computers and manage the work division with another subsystem. In this case, a technical constraint uncovered with a prototype led to the addition of three localities, associated new connections between localities, new interfaces, and changes/additions to the logical subsystems within the printing system's control unit.

Similar technical considerations apply to many different types of products that require designers to choose where and how to implement function. Thermal constraints could well force design decisions in computers, game consoles, and the like. Geometric constraints (shape and volume) clearly affect design decisions for devices like cell phones; each new product generation has packed more function into ever smaller forms. Physical constraints (mass and density) may also require modifications in machines such as automobiles and airplanes.

Addressing these constraints and others that manifest themselves as system development proceeds is a discovery process. As design decisions are made, it is important to capture their essence, including what effects they will have on the product under development and its model-based representation.

Systems and components collaborate; so should development teams

The first three principles outlined above provide technical guidance for system development teams. They direct us to decompose the system structurally, examining it from multiple viewpoints representing significant areas of concern. They also provide mechanisms to re-integrate the system as a whole, while recognizing that specifications will certainly be discovered not just in the planning and concept stages, but also in design and construction as well. These discoveries will lead to design decisions that may affect more system elements than those contained in the view in which the specification was initially determined, leading to changes up, down, and across the architectural levels.

As systems increase in complexity, greater demands are placed on components and subcomponents. Services are grouped logically to meet both functional and supplementary demands, and the interactions between system entities must be adequately described to allow the system to meet its intended purpose. As the model moves from abstract to concrete elements, functions are allocated to software, hardware, firmware, and workers, and the collaborations between elements are finalized.

In hardware/software codevelopment efforts, collaborations between development teams take on greater importance. Many enterprises align engineers and developers by expertise; software engineers focus primarily on software system elements, hardware engineers may be aligned with functional components (an automobile's engine or chassis, for example), and so on. This alignment can lead to stovepiping; that is, narrow bands of specialized knowledge with little interaction across the bands. Although the alignment itself may be a good practice, stovepiping is not. Hence our systems engineering principle: Systems and components collaborate, and so should development teams. This often requires direct management focus, both to encourage and facilitate development team collaborations and to determine the appropriate amount of cross-domain and higher-level resources. An example of this extra management focus might be an enterprise-level systems architecture group encompassing product architectures.

Such an MDSD framework and methodology can aid management in facilitating development team collaboration, as can software tools that automate and enforce the collection and management of system development artifacts. The latter are key to capturing design decisions and provide traceability for requirements derivation and allocation across system elements.

Whenever possible, communication and collaborations should be assessed and realigned as needed to support clear, effective, and timely exchange of knowledge and artifacts. One way to do this (which has been implemented across IBM development) is to form integrated product teams composed of key product development stakeholders, and to hold regular team meetings to report status and ensure key stakeholder needs are discussed and addressed throughout the development lifecycle.

Development organizations should reflect product architectures

The previous principle of systems engineering focuses on collaborations between development teams to ensure that interactions between system elements can be fully addressed from pertinent multiple viewpoints.

The next principle is related and clarifies a best practice for optimizing collaborations and communications. It states that development organizations should reflect product architectures.

Development organizations aligned to product architectures are both efficient and effective. The alignment naturally optimizes the communication paths between development teams, and it groups specialized sets of engineers, programmers, testers, and other development personnel together to provide in-depth skills and a deep bench of resources.

Our premise is that successful enterprises with successful products likely have succeeded in this alignment, either implicitly or explicitly. However, over time, markets and products change. When the change involves important shifts in product content and function, the enterprise must react and realign to the changing product architecture. If it doesn't, the required collaborations and communications begin to suffer and lose their effectiveness.

Consider the automotive industry. Until recently, automobiles were largely composed of hardware. Engines and drivetrains, braking systems, chassis, exterior, interior, and safety features like lights, windshield wipers, and emergency brakes were key components and subcomponents. This led to development organizations with bodies of expertise in these areas. When a new product was considered, product teams were formed by picking resources from each of these areas of competency. However, currently software is assuming greater importance in automobiles and contributes heavily to new product content. As more function is implemented in software, increased collaboration and ongoing communication between product teams, hardware domains, and software engineers is needed. This change in content hopefully will be accompanied by refinements in development organization structure to properly reflect software's growing influence.

Base the lifecycle on removing risk and adding value

The above principles collectively address the three key aspects of systems engineering: systems architecture, organizational structure, and process. The three are held together by appropriate governance: program and project management, executive steering, change and configuration management, contractor and business partner management, and so on. The governance team is responsible for ensuring the highest risks are removed first and that product or program value can be measured regularly as development progresses. This leads to the final system engineering principle: Base the lifecycle on removing risk and adding value.

For complex systems, uncertainty is usually the biggest risk a program faces in the early stages of development. A second major risk area is not validating assumptions early in the development process (which may prove to be invalid when the system is in integration testing, leading to significant rework). A third risk area is committing too early to a specific implementation of hardware, software, and firmware, resulting in brittle systems that cannot be easily extended.

How is value measured? Before the methods can be determined, a prerequisite assessment is needed to determine what "value" means on a given program or product. If the measure of value is providing a system that meets stakeholder needs, one approach is to demonstrate the developing system to key stakeholders at regular intervals. This approach is included in both RUP and RUP-SE. Systems are developed iteratively, regularly increasing in capability. The development teams solicit stakeholder review and feedback with each iteration and make appropriate system adjustments in response.

These six principles and the approach they embody are intended to remove risk and provide a framework for complex hardware/software systems codevelopment. In a future article, we will illustrate MDSD techniques by walking through the structural decomposition and joint realization of a sample printing system.

Notes

¹ This article focuses on physical products -- that is, hardware products that may also contain firmware and software -- as opposed to commercial off-the-shelf (COTS) software, for example, for which the only physical embodiment is a distribution medium such as a CD-ROM.

² Blanchard and Fabrycky, Systems Engineering and Analysis, Third Edition. Prentice Hall 1998.

³ Ibid.

About the authors

		As a leader in the IBM Rational field services group, Murray Cantor promotes and extends Rational best practices, and works closely with customers on innovative ways to build and deliver systems more efficiently. Currently, he leads the evolution of a new engagement model for transforming software development organizations, as well as Rational Unified Process for Systems Engineering® (RUP-SE®). The latter methodology is critical for organizations working at the leading edge of large-scale hardware and software system development. He also focuses on how to integrate IBM Rational field capabilities with those of other IBM brands. He has been named Distinguished Engineer both for his contributions to RUP-SE and for his successes with client enterprise transformations. A well-known thought leader, he is a sought-after keynote speaker at industry events, has published two books and numerous papers, and plays a key role on standards committees relating to UML and RUP. Murray Cantor received his Ph.D. in mathematics from the University of California at Berkeley in 1973.

		Gene Roose is a senior systems engineering consultant for IBM Rational, concentrating on model-driven systems development methods for the industrial sector. He assists clients with solution analysis and design, architectural derivation and validation, and overall project management. His collaboration with Murray Cantor on a significant systems engineering process study for a major automotive concern provided foundational material for this article. Previously, he developed, deployed, and supported IBM printing systems and document publishing products, beginning with the development of advanced function printing (AFP) software and hardware in the early 1980s. He holds a B.S. in mathematics and an M.A. in statistics from Arizona State University as well as a master's certificate in project management from George Washington University.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top