System and Software Co-Architecting

Department of Systems Engineering and Engineering Management, Stevens Institute of Technology

System and Software Co-Architecting Hermann Kaindl Vienna University of Technology, ICT Gusshausstr. 27–29, A-1040 Vienna, Austria [email protected]

Abstract Life cycle approaches for software development have become more and more flexible. For general system development, the situation is less clear. Most of the related methods involve strict requirements flowdown. This can be problematic like the waterfall model especially for software-intensive systems. The recently established CMMI proposes concurrent development in systems engineering but provides little guidance on how to define and execute specific processes for a specific project or organization. Anchor point milestones may serve for synchronization of system and software development efforts. Apart from this kind of synchronization, however, a key remaining question is, how exactly the life cycle models of software development and of more general system development depend on each other. Especially for developing highly innovative software-intensive systems, we found that architects of software and other subsystems should communicate and interact during their concurrent work. Therefore, we propose system and software co-architecting.

Introduction In recent years, software development has more and more changed from the waterfall model to iterative and incremental development (IID), e.g., according to the Unified Process (UP) (Jacobson et al. 1999). An approach with a similar spirit was published earlier under the name Spiral Model (Boehm © 2005 Stevens Institute of Technology, ISBN 0-615-12843-2 PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

1988). Later, so-called anchor point milestones have been defined for spiral development (Boehm 1996, 2000), defining progress of development similarly to the UP. While the basic approach of iterative and incremental development is established now in software engineering, this is not (yet) the case for systems engineering. In particular, software development is still considered simply a part of systems development, where defined development processes of general systems engineering typically handle software subsystems via strict requirements flowdown from system to software development (INCOSE 2004, Maier and Rechtin 2002, Rational 2003). However, software is different from electronics or mechanics! So, this can be problematic like the waterfall model, especially since more and more systems are becoming software-intensive. In fact, we may view this issue along the following two dimensions: 1. system development, 2. system decomposition. Waterfall development has a flowdown from requirements to architecture, etc. in software or system development. Traditional system development has an additional flowdown of requirements from system to (software) subsystem. Anchor point milestones may also serve for synchronization of system and software development efforts (Boehm et al. 2002). A key remaining question is, how exactly the life cycle models of software development and of more general system development depend on

each other, apart from their synchronization at the anchor point milestones. In particular, if and how is there interaction between architects of software and other subsystems during their work? In this paper, we make use of a running example as given in Figure 1, generalized from (Boehm 2000). We use it only for illustrative purposes and do not intend to put blame on anyone involved in the real development effort it is based upon. We look at it from the viewpoint of software development only first, and then from the viewpoint of engineering a software-intensive computerbased system. In a nutshell, for the development of an ambitious information query and analysis system, a system response time of less than one second was required first, leading to a cost of $100 million, as estimated later by the software architects. Only then, a prototype was developed, leading to the result that a four-second response time would satisfy users 90 percent of the time. This reduced response time dropped development costs to $30 million. Figure 1. Sketch of Running Example. The remainder of this paper is organized in the following manner. First, we review life cycle approaches in their order of increasing flexibility as background material. Then we briefly discuss both traditional and concurrent development in systems engineering of general software-intensive systems (including electronics and/or mechanical parts), where the more recent concurrent approach clearly allows for more flexibility. Finally, we present our new proposal of co-architecting system and software. It fits into concurrent development and is very flexible but provides for defined interaction between architects of software and other subsystems.

Increasing Flexibility in Life Cycle Approaches Life cycle approaches regulate the sequence for processing the phases of development. In this way, they determine the strategic way of doing the development work. In order to make this paper self-contained, we review here life cycle approaches in their order of increasing flexibility. The required flexibility for the development of a product relates to its novelty. In fact, there is a spectrum of predictable to truly new product development (Larman 2004). Somewhat ironically, there appears to be much more focus on new developments today than thirty years ago. Waterfall Model. We assume that this traditional life cycle model is well known and focus, therefore, only on an aspect that is often overlooked. While downflow is clearly dominant, there is also the possibility of upflow (see the dotted lines in Figure 2, which illustrates a simple version of the waterfall model). We think that this approach may still be applied usefully for predictable development of well-understood systems (software or more general). However, for truly new product development is has major disadvantages, such as late delivery of any running system for use. In a rapidly changing environment, the system built according to requirements dating back a few years ago will most likely not be useful any more after its release.

Figure 2. Waterfall Model. PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Application of the waterfall model may be blamed for the problems in our running example. In fact, simply accepting all wishes from potential users as requirements strictly before having seriously thought about the architectural design can easily lead to such problems. Involvement of software engineers in serious requirements engineering could help, when they have the knowledge and experience required to assess such wishes even before having to think about solutions. More realistically, even experienced software engineers would have at least to study the problems involved seriously before being able to assess the consequences of such wishes and to agree to them as requirements. Whenever a new system is at or across the boundary of the state of the art, however, a theoretical study alone will most likely not be sufficient. Exploratory Prototypes. Amending waterfall-style development with the rapid development of one or more throw-away prototypes of the software is considered a useful technique for reducing risks in standard texts of software engineering (Pfleeger 2001, Sommerville 2004). It serves two major purposes of exploration: 1. Clarifying requirements on functionality and/or user interface; 2. Figuring out about feasibility and/or performance. This is not just theory in text books. In fact, developing such prototypes has always been included analogously to solution studies, for instance, in the methods according to the Systementwicklungsmethode-Vorgehensmodell (SEM-VM) (Kaindl et al. 1998) and its predecessors at Siemens AG Austria, dating back to the early eighties. In the case of our running example, developing a prototype of the system’s user interface and representative capabilities to test was reported to have been key to finding out that four-second response time would have been satisfactory. This is exactly the first purpose

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

of exploratory requirements listed above. This prototype was apparently just built way too late. A prototype for the second purpose could have helped to find out about the cost of performance even before the design phase. Iterative and Incremental Development. This approach tries to avoid many of the problems of waterfall development by two means: • Iterative development: Repetition in the process • Incremental development: Extension of the (software) system in (small) portions It comes in several flavors, primarily as mentioned above in the context of the UP and the Spiral Model. Based on (ESA 1991), we included a form of evolutionary development into SEM-VM as given in Figure 3.

Figure 3. Evolutionary Development. More as an innovation, we devised a lifecycle model with a so-called Prototyping Phase as shown in Figure 4. This phase is actually a combination of design and implementation and allows for deliberate iterations of these activities. In order to make this a “clean” approach in spite of evolutionary prototyping, SEM-VM prescribes several conditions for its use. E.g., an architecture needs to be devised, and a documentation of solution

has to be provided before the end of the phase (which should even contain design rationale).

Figure 4. “Prototyping” Life Cycle Model. These two approaches can be usefully combined by embedding the prototyping life cycle model into evolutionary development: each development process of the latter is an instantiation of the former. It offers both • releases with more and more features, and • creation of a release through iterations of Design and Implementation. So, this combination provides even more flexibility than the usual IID approaches, since there are iterations and increments on two levels. In general, IID has several advantages for new product development over the waterfall model: • Unstable or unclear requirements are better manageable. • Continuous integration is inherent. • A running version is available “anytime” (after a certain period after start, of course). • Development risks are reduced. • Error costs are reduced through “failing fast”. Still, there are also issues involved: • A stable architecture is needed.


•

A concrete vision for development must exist. • Dynamic project management is needed. • Commissioning of projects is more difficult. In the context of our running example, IID could help as follows. Assuming the requirement of a system response time of less than one second in one of the first iterations, the design and implementation of this iteration would focus on this critical performance requirement. Finding out there about the high cost of achieving it should lead to termination of this iteration before attempting an implementing of the very costly solution satisfying this requirement. The key point is failing fast.

Systems Engineering with Embedded Software Development More and more systems including electronics and/or mechanical parts include software as well. Many of them are even software-intensive in the sense that the software is critical to the system’s success. Especially for such systems, it is crucial to have software development reasonably embedded in the overall system development effort. Let us have a look now what current systems engineering methodology has to say about this issue. (Maier and Rechtin 2002) propose a traditional waterfall approach for general systems development, but iterative and incremental development for the software subsystem(s). It is not clear, however, how these would fit together and how the software architects would communicate with the overall system architect and the architects of other non-software subsystems. In contrast, the Rational Unified Process Systems Engineering (RUP SE) Plug-In (Rational 2003) prescribes iterative and incremental development also for general systems development. Still there is requirements

flowdown, here in terms of derived use cases for the (software) subsystem(s). This flowdown is considered as a basis of concurrent design in the sense of independent development of the various subsystems. Concurrent Development in Systems Engineering. Capability Maturity Model Integration (CMMI) (Chrissis et al. 2004) proposes concurrent development in systems engineering. However, CMMI still has the flavor of “derived requirements” (see p. 466), and (by intent and not omission) it provides little guidance on how to define and execute specific processes for a specific project or organization. The so-called process areas (like Requirements Development and Technical Solution) are just roughly cross-referenced. In particular, we could not find any cues on how to synchronize system and software development. Anchor point milestones (Boehm 1996) may also serve for synchronization of system and software development efforts, and process generator approaches such as the UP or the Center for Empirically-Based Software Engineering (CeBASE) Method may redress this shortfall of CMMI (Boehm et al. 2002). Still, a key remaining question is, how exactly the life cycle models of software development and of more general system development depend on each other, apart from their synchronization at the anchor point milestones. How much flexibility is needed? How much should software development and more general system development interact? In particular, if and how is there interaction between architects of software and other subsystems during their work? In general, there is no or no defined interaction among architecting of the subsystems in all these processes and no defined way of changing the system architecture based on insights from architecting subsystems. In the course of developing highly innovative systems, however, changes of system archi-


tecture and even of system requirements may sometimes be necessary due to insights gained, e.g., during software architecting. Considering now the running example from a more general systems perspective, actually the hardware architecture had to be taken into account as well for potentially achieving the one-second response time — 25 super-midicomputers according to (Boehm 2000). So, some concurrent development is probably needed for figuring out about the software and the hardware architecture of an innovative software-intensive computer-based system. How exactly should these architecting tasks interact?

Co-Architecting of System and Software In order to allow such increased flexibility in a controlled way, we devised an approach with defined communication between subprojects that we call system and software coarchitecting. This defined process allows more interaction between software and systems architects during their work. First, there needs to be some engineering of system requirements, including all the relevant stakeholders and, in particular, software developers. This task may or may not include doing studies and/or building prototypes, depending on the difficulty of the concrete problem and previous experience. After that, flowdown of requirements to subsystems as usual should take place, also to the software subsystem(s). Instead of independent continuation of the development of the subsystems until reaching some anchor point milestone or even integration, however, our approach includes defined communication during architecting of subsystems, where software architecting needs to be included. Such an approach influences, of course, how the life cycle models of software development and of more general system development depend on each other. Strategic design

decisions in the course of architecting the various subsystems may influence each other and may be coordinated. In this way, even difficult problems may be solved without having to return to the systems level again. However, if in the course of architecting a (software) subsystem a major change of the given assumptions (in the requirements flowdown) is found to be necessary, this should lead to defined upflow of requirements-related information from this subsystem to the systems level. The consequences of such an upflow differ, depending on the life cycle approach(es) used: • If the waterfall model is used, it is analogous to the upflow shown in Figure 2, but in the other dimension. In fact, upflow will have to take place in both dimensions in this context, since the upflow to the systems level brings the overall systems development back to the Requirements phase as well. • If IID is used, such an upflow should lead to exiting the current iteration. The new situation will best be dealt with like usual requirements evolution in IID. After engineering the changed system requirements, possible changes in the system architecture may be needed as well, depending also on the design rationale for its current version. This will probably lead to changes in the flowdown of derived requirements for several subsystems, not only the one that had triggered the upflow. Still, there needs to be a stable version of subsystem requirements for a certain period, during which the subsystem release under development is to be designed in detail, developed, integrated and tested. In our approach, this is the case when after co-architecting also the various subsystem architectures are stable.


In a situation like that of our running example, such a one-second response time requirement may well be considered first on the system level during system requirements engineering. Ideally, it would be dismissed already there based on studies and/or prototypes. Due to time pressure especially in IID, however, studies and/or prototypes may not necessarily be possible. And even if a study is done and/or a prototype is built, the problems may not necessarily be resolved at this stage. So, co-architecting software and computer system seems ideally suited to figure out efficiently and quickly about the necessary computer configuration and highly customized architectural software design that together would be able to satisfy the given system requirement. In this course, also the excessive cost would be estimated relatively fast. It would violate corresponding subsystem requirements and lead to defined upflow of requirements-related information. Back on the system level in the Requirements phase, exactly the prototype as reported is to be built for finding out about the foursecond alternative. Ideally, it would have been built before as indicated above, but sometimes in the real world errors are made. The key point is that the communication and interaction during co-architecting may lead to finding such an error quickly. Figure 5 shows part of a workplan for developing an autonomous mobile robot system in our environment, using system and software co-architecting. This subproject is about software architecting and prototypical implementation of a new approach including a reflective world model and involves a few person years of effort. It is synchronized with a few other subprojects of similar size. This system is software-intensive and highly innovative. Therefore, the assumption was that during system requirements engineering and system architecting (both outside the scope of this workplan) it was close to impossible to get everything right. That is why

Figure 5. Part of a Workplan Including Co-Architecting. co-architecting came into play. This approach is reflected in the project workplan through the following tasks: • Co-Architecting Overall Structure • Co-Architecting Improvements 2nd Cycle • Co-Architecting Improvements 3rd Cycle These tasks (shown in shaded boxes) are shared among all subsystem workplans for communication among these development efforts and especially for interaction between the subsystem architects involved. The subsequent milestones, e.g., Co-Architecting First Cycle Completed synchronize the subsystem development efforts in the sense that, once reached successfully, tasks for detailed design, implementation etc. can be performed independently from similar tasks in the other subsystem development efforts.


Conclusion Depending on the novelty of a system, the life cycle approach applied needs more or less flexibility. In this paper, we propose a flexible but defined development approach of coarchitecting for developing truly new software-intensive systems. This approach fits well into concurrent development according to CMMI. We devised it for building relatively small systems first. So, we are not (yet) sure about scaling up. Still, such a novel and flexible process of co-architecting will be important for the development of software-intensive systems, especially for highly innovative systems.

Acknowledgments We thank Edin Arnautovic and Gregor Novak for useful discussions and their comments to an earlier draft. Gregor Novak codeveloped the workplan shown in Figure 5 together with this author.

References Boehm, B. A spiral model of software development and enhancement. IEEE Computer 21, 5 (May 1988), 61–72. Boehm, B. Anchoring the software process. IEEE Software 13, 4 (July 1996), 73–82. Boehm, B. Unifying software engineering and systems engineering. IEEE Computer (March 2000), 114–116. Boehm, B., Port, D., and Basili, V. Realizing the Benefits of the CMMI with the CeBASE Method. Systems Engineering 5, 1 (2002), 73–88. Chrissis, M. B., Konrad, M., and Shrum, S., CMMI: Guidelines for Process Integration and Product Improvement. AddisonWesley, Boston, MA, 2004. ESA, ESA Software Engineering Standards. Issue 2. Guide to the Software Engineering Standards. European Space Agency, 1991. INCOSE, Systems Engineering Handbook, Version 2a. International Council on Systems Engineering, Seattle, WA, July 2004. Jacobson, I., Booch, G., and Rumbaugh, J. The Unified Software Development Process. Addison-Wesley, Reading, MA, 1999. Kaindl, H., Lutz, B., and Tippold, P., Methodik der Softwareentwicklung: Vorgehensmodell und State-of-the-Art der professionellen Praxis, Braunschweig / Wiesbaden: Vieweg, 1998. Larman, C., Agile and Iterative Development: A Manager’s Guide. Addison-Wesley, Boston, MA, 2004.


Maier, M. W., and Rechtin, E., The Art of Systems Architecting, Second Edition, CRC Press, 2002. Pfleeger, S. L. Software Engineering: Theory and Practice, Second Edition, Prentice Hall, 2001. Rational. Rational Unified Process for Systems Engineering, Plug-In Version 2.0. IBM Rational, 2003. Sommerville, I. Software Engineering, Seventh Edition, Addison-Wesley, Boston, MA, 2004. Stevens, R., Brook, P., Jackson, K., and Arnold, S. Systems Engineering: coping with complexity. Prentice Hall, 1998.

Biography Hermann Kaindl has joined the Institute of Computer Technology at the Vienna University of Technology in Vienna, Austria, in early 2003. Prior to moving to academia as a full professor, he was a senior consultant with the division of program and systems engineering at Siemens AG Austria. There he has gained more than 24 years of industrial experience in software development. His current research interests include software and systems engineering focusing on requirements engineering and architecting, and humancomputer interaction as it relates to scenariobased design and hypertext. He has published four books and more than eighty papers in refereed journals, books and conference proceedings.