University of Twente

Transcription

1 University of Twente EEMCS / Electrical Engineering Control Engineering Systems Engineering and Design The search for a knowledge exchange model or Wessel Ganzevoort Pre-doc Supervisors prof.dr.ir. J. van Amerongen dr.ir. J.F. Broenink October 2005 Report nr. 037CE2005 Control Engineering EE-Math-CS University of Twente P.O. Box AE Enschede The Netherlands

2

3 Systems Engineering and Design or The search for a knowledge exchange model Wessel Ganzevoort

4 The image on the previous page is a generated image based on the convergence of a sphere towards a 6 rule linear iterated function system (IFS) fractal in three dimensions with a scale ratio of 1:3.

5 Summary This document is the result of an individual assignment. The goal of this assignment was twofold. The first part was to give an overview of systems engineering as commonly used in every-day practice and to evaluate the use of the generally available process models as can be found in literature. This overview was regarded as useful because most literature only focuses on one particular process model and describes that model in detail. Although that might give a clear insight in that specific process model, it is not useful in deciding if that model is suitable for a specific problem or system. The second part of the assignment was to investigate the process of selection and development of a process model for the purpose of a knowledge exchange model. The reason for this followed partly from the first part; the results showed that selecting a general process model is not trivial and often not sufficient when a specific systems needs to be developed. The results of the first part of this assignment can be used in the course "systems engineering" to include a broader view of the systems engineering activities and process models. The results of the second part can be used as a guideline for future students doing their individual assignments. Keywords: systems engineering, process model, knowledge exchange, system life cycles, systems engineering methods and tools. Samenvatting Dit document is het resultaat van een predoctoraal-opdracht. Het doel van deze opdracht was tweeledig. Het eerste deel moest een overzicht geven van de dicipline "systems engineering, zoals deze tegenwoordig wordt bedreven. Daarnaast moest er een evaluatie worden gedaan van de algemeen beschikbare procesmodellen zoals die in de literatuur worden beschreven. Deze evaluatie werd als nuttig beschouwd omdat in de meeste literatuur slechts één processmodel in detail wordt beschreven. Hoewel dit een duidelijk beeld geeft van dat specifieke proces en al haar details, is het niet erg bruikbaar bij de keuze van een procesmodel voor een specifiek probleem. Het tweede deel van de opdracht moest dan ook het onderzoek beschrijven naar het kiezen en ontwikkelen van een procesmodel voor kennisuitwisseling. De reden hiervoor volgde deels uit het eerste deel van de opdracht waar het resultaat was dat de selectie van een generiek procesmodel niet triviaal is en vaak niet toereikend wanneer een specifiek systeem moet worden ontwikkeld. Het resultaat van het eerste deel van deze opdracht kan gebruikt worden in het vak "systems engineering", zodat een breder overzicht van de systems engineering activiteiten en processen kan worden gegeven. Het resultaat van het tweede deel kan worden gebruikt als een leidraad voor toekomstige studenten die een predoctoraal-opdracht of individuele onderzoeksopdracht (IOO) gaan doen. i

6 ii

7 Table of contents Summary Samenvatting i i 1 Introduction 1 2 The system life cycle approach The system life cycles Conceptual phase Preliminary phase Detailed and development phase Production and construction phase Product use, support and maintenance phase Phase-out and disposal phase The systems engineering activities System analysis Functional analysis Requirements analysis Architecture synthesis Requirements verification Functional verification System verification Systems engineering methods and tools Change control Baselines Requirements management Document reviews Roadmapping Final note about systems engineering methods and tools iii

8 3 Systems engineering process models Process model taxonomy Waterfall model Waterfall model with limited feedback Waterfall model with full feedback V-model Spiral model CAFCR model The search for a knowledge exchange model Choosing a systems engineering process model Developing a systems engineering process model Case study: individual assignment Process model Phase 1 Concept phase Phase 2 Pre-study phase Phase 3 Execution phase Phase 4 Reporting phase Final remarks Towards a knowledge exchange model 37 6 Conclusion and recommendations Conclusion Recommendations Acronyms 41 References 43 iv

9 1 Introduction Systems Engineering is, as stated by the International Council on Systems Engineering (INCOSE), an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle. This definition of systems engineering is only one of many definitions that can be found. This is also reflected in the way systems engineering is practised; a vast number of methods, tools and processes are available and advocated in numerous books and articles about this subject. The goal of this assignment is to give an overview of systems engineering as commonly used in every-day practice and evaluates the use of the generally available process models. However, even though there are many process models to choose from, these process models seldom fit a specific problem or system to be developed. It is for that reason that additional to the overview of these process models, also the development of a new process model is considered. In most literature, for example (Blanchard, B. and Fabricky, W. 1998), the system life cycle is seen as a process and each individual cycle or phase has a set of specific activities in order to complete that phase. In this document a slightly different approach is used and the system life cycle is taken as a given and not having the completion of the system life cycle as a goal in itself. Specific tasks are used to structure the work that needs to be done during each phase in a systematic and ordered way. The systems engineering process models can than be seen as the glue that holds the system life cycle and the systems engineering activities together in a structured way. The systems engineering methods and tools are aids to help them stick (see figure 1). Systems life cycles Systems engineering activities Methods and tools Systems engineering process Figure 1 General overview A drawback of the system life-cycle approach is that it might imply some sort of linearity over time. This is not always correct. A better approach could be a more holistic approach to see the system and its and life cycles as a set of parallel activities. A model that takes this more holistic approach of systems engineering is the CAFCR model (Muller, G. 2004) as described in chapter 3. The method described by (Hatley, D., Hruschka, P. and Pirbhai, I. 2000) also takes a more concurrent development approach. Unfortunately, it is out of the scope of this assignment to explore this holistic idea in detail. This document focuses on technical systems engineering issues only. Project management issues like planning, budget control, resource allocation and securing are not in the scope of this assignment and will not be addressed here. 1

10 Some words about the terminology used in this document are in place. This is important because a lot of different definitions are in use and stating the terms used in this document will (hopefully) remove any confusion. In this document, the word "system" is used as a general term to describe the complete set of components of an entity consisting of hardware, software, people (customers), and processes; i.e. the whole set of operational capabilities of a product. The term "product" is used to reflect any outcome of a systems engineering process. It can be a piece of hardware, a piece of software or even a process. In that sense, it is a only a part of the system. A "customer" is anyone that has an interest in the project or outcome of the project. This means that the customer can be both internal and external. External customers are not connected to the company where the product is developed and an internal customer is anyone within the company with an interest in the product. This may include the and test engineers, production engineers, project management and end-users of the product. In other documentation the word "user" is also used to indicate the customer as is meant in this document. Document outline Chapter 2 starts with a discussion of the system life cycle that a system goes through during its complete life time. Next, the chapter describes a set of systems engineering activities that help the systems engineer to let the systems life cycle move smoothly. The chapter concludes with some systems engineering methods and tools that can aid the systems engineer to implement a systems engineering process. Chapter 3 gives an overview of commonly used systems engineering processes. These "off the shelf" processes are described and their application in specific development environments is discussed. The information in chapters 2 and 3 is not intended to be complete. It merely gives an overview and summary of the life cycle phases and systems engineering activities, methods and tools. A lot of documentation and good books are available on these subjects. The documentation used for this document, can be found in the references. In some cases additional details are included based on the author s own experience. These details are included because they are important to note and are often omitted in other books and documentation on the subject. Chapter 4 challenges the use of the generally available process models for use in specific projects and environments. It describes the development of a process model to fit the environment and the system to be ed and can therefore be seen as a metasystems engineering activity. The chapter ends with a case study for the development of a process model for doing an individual assignment at the university as an example. Chapter 5 proposes the use of Hitchins formal method for the development of a new process model. The chapter gives a broad outline of the method and how it can be used to develop a model for a system that involves the knowledge exchange between universities and (private) companies. In chapter 6, the conclusions and recommendations derived from this assignment are presented. 2

11 2 The system life cycle approach Current systems engineering is almost always based on the system life cycle approach. Although other, more ad-hoc methods and approaches are still used, this document will focus on the system life cycle approach. Many different names and definitions are in use for the life cycles of a system. In this document a generalization of these names and definitions has been made. The system life cycle in this document is organized in the following phases: Conceptual phase; Preliminary phase; Detailed and development phase; Production and construction phase; Product use, support and maintenance phase; Phase-out and disposal phase. In some cases these life cycles may be subdivided into additional phases. For example, the detailed and development phase can be divided into two phases; a detailed phase to finalize all requirements, and a development phase to do the actual implementation of the product. When a concurrent approach is used, a life cycle phase tends to span a broader range of sub phases. It is not the goal of this document to specify and describe all these phases in detail. In figure 2 the system life cycles are depicted. Note that this is not a process description. The figure only shows the life cycles order. A process description is needed to deal with the complexity and the relations between the different life cycles. Processes that can be used in the life cycle approach are described in chapter 3. Conceptual Preliminary Detailed Production/ Construction Support/ Maintenance Phase-out/ Disposal Figure 2 System life cycles Systems engineering activities encompass all specific activities that need to be accomplished during the lifetime of a product. As with the description for the system life cycles, there are a lot of different definitions and names in use. Again, these names and definitions have been generalized and organized into the following categories: System analysis; Functional analysis; Requirements analysis; Architecture synthesis; Requirements verification; Functional verification; System verification. 3

12 Of course these life cycles and activities can be broken down to include more details to match specific products, projects and organizations, but that is out of scope for this document. Section 2.1 deals with the system life cycles and describes the goals of the activities, sources, means, results and outputs of the different phases of the system life cycle and can be seen as the "what-to-do" part. Section 2.2 will go into more detail about the specific activities that need to be performed during the system life cycles and can therefore be seen as the "how-to-do-it" part. Section 2.3 describes the methods and tools available for the systems engineering activities and subsequently can be seen as the "whatto-do-it-with" part. 2.1 The system life cycles System life cycles are the phases a system goes through during its complete life. This section describes these phases in more detail. An extensive and elaborate discussion of these phases is out of scope for this document and can be found elsewhere in literature Conceptual phase Goal The goal of the activities in the conceptual phase is to establish a definition of the system with a focus on system products that are required to satisfy the operational requirements based on market opportunities or customer needs. During this phase, the first ideas about functionality and useability are conceived and a collection of ideas and investigations for new products is assembled. Sources These ideas can come from a customer (market pull) or from within the organisation (technology push). To see if those ideas are of any use, the conceptual phase should answer some important questions. The information and answers for these questions can come from several different sources. For market pull, the ideas should come from (external) customer needs. Often the customer does not know exactly what he needs in terms of requirements. Only a global idea of the functionality is present. The main challenge is to translate these global ideas into a set of requirements. In case of technology push, the information can come from a series of sources. Science, fundamental technological research and applied technological research are common sources of information. It is important that this phase is conducted with an open mind and to keep all options open. Means There are several means that the systems engineer can employ to characterize the new ideas from the aforementioned sources: Discussions; Queries; Risk assessments; Reviews. In some (most) cases there will be blank spots in the required functionality. To cope with these blank spots, the systems engineer should characterize these blank spots. 4

13 This can be done by characterizing the required functions, the required performance, the interface to other systems or subsystems and the operating environment of the product. Results The results of the activities in this phase should consist of one or more concepts for new or improved systems which have been approved by formal reviews. Output At the end of the conceptual phase (at least) the following items should have been produced: System specifications for products and interfaces; Use-cases for system verification against user needs; Baselines for requirements, documentation and ; Definition of the systems engineering process that fits the system and product development. More information about output documentation of the conceptual phase can be found in (IEEE 1998) and (Stevens, R., Brook, P., Jackson, K. and Arnold, S. 1998) Preliminary phase Goal The goal of the activities in the preliminary phase is to refine the results of the conceptual with a clear positioning of their constituting system elements. During this phase the system requirements need to be developed which specify concrete and verifiable capabilities, behaviour and properties to meet customer needs. Additionally, the systems engineer should make trade-offs between performance, risk and costs of the product or project based on the output of the conceptual phase. Sources The inputs for this phase are the results of the conceptual phase. Additional discussions with customers or users may be needed to meet the goals of this phase. Means Important in this phase are risk assessments. (Bol, D. 2002) describes a useful scaling model to assess the maturity of the technologies that are applied in system elements. This technology maturity can be scaled as follows: Possible in theory; Proven by analysis or computer simulation; Working as a laboratory experiment; Already applied in a similar, but different situation; Applied in (almost) similar situation. Additional means that can be used are Failure Mode and Effect Analysis (FMEA) methods, Quality Function Deployment (QFD) methods and others. Also in this phase it is important to have regular discussions and reviews to align the viewpoints of all involved (especially the customer). Results The results of the activities in this preliminary phase should contain a recommendation with respect to system components and interfaces for the detailed 5

14 phase. These results should be based on the risk analysis and trade-offs between the concepts that where produced during the conceptual phase. This means that the system architecture is broken down into subsystems and that a (preliminary) function allocation is done. Before the activities in this phase can be concluded, formal reviews should be performed and passed with sufficient confidence to proceed to the next phase. Output At the end of the preliminary phase (at least) the following items should have been produced: Requirement specification document; Subsystem verification specifications; Configuration, system and documentation baselines Detailed and development phase Goal The goal of the activities in the detailed and development phase is to complete the (sub)system down to the (lowest) components, to a level ready for production and construction. This includes the implementation, verification and integration of all the system components. Sources During the of the system and its components, the teams can have questions about unclear requirements and non-existing or unfeasible requirements. The systems engineer should solve these uncertainties and if necessary, contact the customer to get the required information. Implementation issues can conflict with the constraints and can cause the development of the system or the components to come to a halt. It is possible that a trade-off with respect to (customer) requirements is necessary to deal with these implementation issues. The customer can still change his mind about some requirements and functionality. The organization should be able to cope with these issues in order to satisfy the customer. Means To cope with changing requirements from customers or even from within the organization or the teams, baselines can help to guide the process and to prevent adhoc solutions. Baselines, as described in section 2.3.2, that can support the detailed and development phase are: (Requirement) Specification baselines; Design baselines; Delivery baselines. All component risks should have been resolved after this phase. Possible means to resolve these risks are: Make or buy decisions on component level; Second sourcing of COTS components as a fall back solution for delivery and quality problems from manufacturers. Critical reviews should ensure that the meets the requirements. 6

15 Results At the end of this phase, the product should be ready for production. Besides a working and tested, this phase should also deliver documentation for industrialization. This means that all documents, source code, load modules, PCB layouts, production tests etc. needed for the production of the product are available for the production site. Also a production planning should have been made. Furthermore, the product should be ed for operational feasibility as described in, for instance, (Blanchard, B. and Fabricky, W. 1998). This means for: Reliability; Maintainability; Usability (human factors); Supportability (serviceability); Disposability; Affordability (life cycle cost). Output At the end of the detailed phase (at least) the following items should have been produced: Detailed functional, performance, interface and verification requirements; Design specification documentation; Design verification documentation; Phase-out and disposal plan; Operation and Maintenance (O&M) plan Production and construction phase Goal The goal of the activities in the production and construction phase is to verify that the and the end product satisfies the specifications and that the system is ready for mass-production and delivery to the customer. Furthermore, if larger and more complex systems are being developed, in this phase the complete system is integrated and assembled for the first time. Final system tests should be performed to verify compliance with the user requirements. Sources In a perfect world, the systems engineer would not have anything to do in this phase. In practice however, problems arise in several stages of this phase. When the is being produced, problems can arise for example from missing or late components, (COTS) components that do not meet the requirements, choices that are impossible or difficult to produce etc. Furthermore, additional problems with respect to the user requirements may arise; the system may fail to comply to some requirements and the systems engineer should make an analysis to assess the impact of these problems and find solutions. Means It is important that the production of the product is planned well and that the planning is agreed upon with the production site. Part of this planning should also consist of the delivery of the subsystems and components needed for assembly of the product. To cope with problems during the production and construction phase of the product, it is recommended that the company plans for (partial) res of the product. To collect, keep track of, and adequately handle production and test problems, the company can 7

16 use trouble/problem report procedures and associated databases. For the verification during the production phase it is recommended that there will be a complete set of use cases for system integration tests. Furthermore, walk-through of the production process and regular contacts about the production progress can help monitoring progress and identify possible problems in an early stage. Results The activities at the end of this phase should result in a working and producible system. Furthermore, the system documentation should be finalized and reviews should be held to verify that the system has passed all tests. Output: At the end of the production and construction phase (at least) the following items should have been produced: Final product; User guides; Manuals; Training material; Completed system specification; Production test reports. Also the documentation can be finalized during this phase, especially when a concurrent approach has been used Product use, support and maintenance phase Goal The goal of the activities in the product use, support and maintenance phase is to create a support organization and secure the possible need for the involvement of systems engineers and teams. In this phase, the product is in use and problems can arise. The support organization should deal with the problems from the customer or the user in an efficient way. This can include product updates for bug fixes and regular scheduled maintenance of the system. Sources During normal operation of the product or system, the customers and users of the system can encounter problems due to errors in the implementation or specification that were not discovered during the. If this happens, the customer will complain and the support organization should deal with these complaints. It can happen that product updates or changes are driven from within the company because of new constrains (for example lower production costs). These issues must be addressed if possible. However, every product or system update introduces new risks. It must always be kept in mind that the customer may not want or have asked for these product or system updates and a thorough risk assessment should be made before the customer is bothered with a product update that he or she did not ask for. Means During the specification and phases of the system, the systems engineers should have included reliability, maintainability, usability and supportability in the. To cope with the reported errors or problems from the customer, the organization can implement change requests (CR) and trouble report (TR) handling to keep track of the re- 8

17 ported issues from the customer. Also in this phase, the previously ed operation and maintenance plans should be executed. Results The result of the activities in this phase should aim at customer satisfaction. Fast and adequate solutions to problems will make the customer happy and will increase possibilities for new orders in the future. Careless handling of these problems may cause the customer to refrain from buying future products. Output The output of this phase may consist of product updates including updated documentation, new load modules, improved (sub)systems or system components that will be delivered to the customer Phase-out and disposal phase Goal After the product or system has completed its useful life time, it should be disposed of. The goal of the activities in this phase is to dispose and get rid of the superfluous product or system components in an orderly fashion. This applies also to serviced parts of the system that have been replaced. A disposal plan is already specified during earlier systems engineering work as an integral part of the system, so that this plan can be executed when this phase of the life cycle is reached. Sources Governments may pose requirements and regulations regarding the disposal of electronic and chemical products or components. Environmental laws and regulations can prescribe the way this should be done. Also the customer can request a proper disposal plan as part of the user requirements. Means A product or system decomposition can be made to categorize the recycling or demanufacturing of a product (see (Blanchard, B. and Fabricky, W. 1998)) in the following way: Reuse of the complete product; Remanufacturing or rebuilding (parts of) the system for new or similar products; Recovery of materials or reusable components from the product. If the product or parts of the product do not fall into one of these categories, then total destruction (annihilation) of the complete product can be considered. The company can redirect the responsibility for the disposal of the product by outsourcing it to other companies. Results The result of the activities in this phase is that the company shows that it takes responsibility for the proper disposal of its products and that by doing so minimizes the impact on the environment. Output There is no output associated with this phase, since all documentation and planning is done during earlier phases. 9

18 2.2 The systems engineering activities To let the system life cycle move smoothly, the systems engineer has several activities and tasks to complete. This section lists a number of these activities. It is not meant to be an exhaustive description of all possible tasks that can be defined, but is merely intended as an overview. During the execution of these activities, the systems engineer should produce a number of documents. This section describes the activities based on the documents that must be produced. It is obvious that all documentation produced should be carefully reviewed and approved by the customers of that document before the tasks are finished. Note that the activities do not necessarily specify roles within the company. Each activity can (and probably should) be subdivided into tasks. Different people from different disciplines can then be assigned to the different tasks and perform different roles. For example, functional specification and functional can be done by different people. Furthermore, it is assumed in this document that the, integration and verification is done by and verification engineers and that the systems engineer is only responsible for the outcome. Every activity is associated with a set of entry and exit criteria. These criteria must be met before an activity can start or before that activity is finished. It is good practice to make a checklist for these criteria and to make this part of the systems engineering process. Furthermore, all deliverables for an activity should have been reviewed and approved by all the customers of subsequent activities. It is out of scope for this document to identify these customers for each activity in detail; they are described in numerous sources on systems engineering. In general, the activities described here should be included in a development process to ensure that all activities are executed. This process can then also be used to indicate dependencies between the different activities in the development of the system and can aid the overall planning. All of these activities are, in principle, ongoing throughout the development. Only the level of effort changes over the system life cycle. In (Hatley, D., Hruschka, P. and Pirbhai, I. 2000), more can be found on concurrent development principles System analysis Purpose The purpose of the system analysis activities is to collect and define the needs of the customer. This activity can be seen as the pre-study activity. The output of this activity should be targeted towards (other) systems engineers and should be the base for further systems engineering activities. Tasks To structure the system analysis activities, several tasks can be identified: Identify all the customers and collect their needs with respect to the system; Evaluate the customers needs by establishing why they are needs and resolve any conflicts, inconsistencies, omissions or other issues arising from them; Make a cost / benefit analysis. Entry criteria The initial ideas for a product including its functions must be present to start the system analysis activity. 10

19 Exit criteria The exit criterium for this activity is, among others, that an approved list with functions and implementation items has been created. Furthermore, requirement traceability should have been started for referencing during the rest of the project. The result of the system analysis activity can be collected in a Systems Engineering Management Plan (SEMP) (see for example (Blanchard, B. and Fabricky, W. 1998) and (INCOSE 2004) for more details on a SEMP) Functional analysis Purpose The purpose of the functional analysis activities is to investigate and set requirements for critical parts of the system, more specifically, on architecture, lead-time critical hardware and lead-time critical components. The output of this activity should be targeted towards systems engineers and ers and should be the base for further system development. Tasks The tasks that can be associated with this activity are: Evaluate the top level required capabilities and constraints with regard to possible system architectures that might satisfy them; Perform analyses, trade-off studies and prototype evaluations as needed to determine the architecture that best meets the top level requirements; Make functional decomposition and function allocation into system components. Create the functional specifications and interface descriptions; Establish the overall system integration and test strategy and write top-level verification specifications based on use cases. Entry criteria To start this activity, an approved list with functions and implementation items should be available. Exit criteria Top level functions and user requirements must have been allocated to different systems Requirements analysis Purpose The purpose of this activity is to set the boundaries for the. The systems engineer must make sure that all the requirements can be implemented and tested. The output of this activity should be targeted towards and verification engineers and should be the base for and verification of the system. Tasks Tasks associated with this activity are: Complete the top-level architecture; Enhance, derive and detail the requirements and allocate them to the major system components; Develop the requirements and architectures for all the system components; 11

20 Prepare integration, verification and test plans; Write the requirements specification, constraints and rules for ; Identify open issues, assumptions and pre-conditions; Create baselines and requirement traceability information. Writing good requirements is important and literature about how to write good information is widely available. A practical way to check the quality of the requirements is by using the acronym "SMART". which stands for Specific, Measurable, Achievable, Realistic and Traceable. Good requirement should contain all aspect of these five characteristics. The correct and pre-defined use of the words "shall", "should" and "may" shall be considered. Good practice is to use references to other system documentation instead of writing them down again. This will prevent the repeating of requirement text and thus possible inconsistencies between multiple documents. Requirements can and should also be broken down in specific areas to indicate all the aspects of a specific function. A possible (and useful) breakdown can be the following categories: Functional; Performance; Capacity; Compatibility (interface); Operation and maintenance; Other. Furthermore, a requirement should have a set of attributes describing the complete requirement. Depending on the organization, customer needs or project structure the number of these attributes can vary. Attributes that should at least be present for each requirement are: Requirement text; A unique number for each requirement to ensure traceability; The source of the requirement; Allocation to subsystems or components. Optional attributes that can be included are: Increment allocation in incremental projects; Requirement status information, for example: draft, approved, rejected. Entry criteria To enter this activity, the systems engineer should have the functional specifications and interface descriptions from the functional analysis at his disposal. Exit criteria The end of this activity is marked with the delivery of an approved requirements specification document Architecture synthesis Purpose The purpose of this activity is to finalize the function specification and on subsystem and component level. The allocation from the requirements analysis is broken down for and an allocation of requirements towards use cases is made. The output of this activity should be targeted towards and verification engineers and should be the base for and verification of the system. 12

21 Tasks The systems engineering tasks during these activities are: Write functional specifications, requirements specifications and rules for the appropriate levels of subsystem and component ; Write detailed functional descriptions for each function of the system; Write top level verification specifications based on use cases. Apart from the aforementioned tasks, the systems engineer has a support responsibility towards the and verification engineers. Because this document focuses on systems engineering activities, the roles of the and verification engineer are not included here. However, since the systems engineer has the technical responsibility for the project, the activities include the support of and verification and review of the associated documents. This is probably the most important role of the systems engineer during the execution phases of the system life cycle (see sections and 2.1.4). The support tasks of the systems engineer consist (among others) of: Work with and verification engineers to coordinate their efforts, and assist them in interpreting the system requirements and in evaluating their ; Participate in the reviews of (component) specifications and descriptions; Ensure that all requirements are met; Check requirements traceability against source documents. Entry criteria This activity should be entered when the requirements specification is in the approved state and when the functional analysis has been completed. However, in practice, may already start before all the requirements are in place. In that case, there is a risk that the teams may implement functionality that is not according to the user needs. This risk must be identified and assessed. Exit criteria This activity can be concluded when the functional, requirements and verification specifications are in an approved state. Furthermore, the and verification of the product has finished and no support from the systems engineer is needed any more Requirements verification Purpose The purpose of this activity is to verify the requirements. The output of this activity should be targeted towards systems engineers performing the functional verification activities. Tasks The systems engineering tasks for this activity include the writing of requirements allocation and verification documentation. This document should state all requirements, where they are implemented and where they are verified. The documentation can be made for different levels of the system: component level, subsystem level and system level, according to the allocation that was made during the functional analysis. A requirement management tool may be used here (see section 2.3). Entry criteria This activity is entered when the architecture synthesis activities have been concluded. 13

22 Exit criteria The systems engineer has the technical responsibility for the and should therefore produce statements of compliance and verification to the subsystem and component requirements of the product Functional verification Purpose The purpose of this activity is twofold; on the one hand the functional integration and verification document is written and on the other hand the functionality of the system is verified. The output of these activities should be targeted towards system verification. Tasks For the functional verification activity the following tasks can be identified: Write functional verification specifications; Check and review integration and verification reports. Entry criteria To enter this activity, the functions to be verified must be implemented. This activity can be entered at different moments in the depending on the availability of the implemented functions. Exit criteria This activity can be concluded when all allocated requirements to a function are verified or when approved exemptions to the failure of specific requirements are available System verification Purpose As for the functional verification, this activity is also twofold; on the one hand the system verification documentation must be written and on the other hand, the system verification must be performed. The output of this activities should be targeted towards the customer. Tasks The tasks associated with this activity are: Integration plan; Top-level system tests and verification specifications; Complete set of testable use cases; System verification report; System statements of compliance and verification; Regression test plan; Check and review system verification reports. Entry criteria This activity can only be entered when all functionality is implemented and delivered to the system verification teams. 14

23 Exit criteria This activity can be completed when a sign-off of the product is done in collaboration with the customer. Only when the customer is completely satisfied with the delivered system, this activity can be concluded. Nevertheless, it must be kept in mind that when product updates, maintenance, or other agreements with the customer are made, this activity can be reopened. When new or updated functionality is added to the system, regression tests should ensure the overall system performance. 2.3 Systems engineering methods and tools Systems engineering methods and tools are often integrated in specific processes that are tailored to the way of working in the organization. A method can be considered as a pre-defined and organized collection of techniques and a set of rules which state by whom, in what order, and in what way the techniques are used to achieve or maintain some objectives. Tools are the physical entities that enables the methods to be executed. The combination of methods and tools are the aids that a systems engineer can deploy to implement a systems engineering process. This combination of methods and tools can be (and often is) seen as a subprocess within the systems engineering process Change control Change request and problem report handling are part of a configuration management process. As the project moves along, customers may change their mind about certain requirements or user needs. These changes can come from within or outside the development organization. Furthermore, during verification and integration, but also after delivery to the customers, problems may arise that cause the product to function improperly. All these issues should be tracked to ensure proper handling towards the customer. Change requests When a customer wants to change something to the initial requirements, a company might want to implement and include this change directly into the product. While this ad-hoc way might work for small and simple products or projects, for larger projects this is not the preferred way. It is better to collect a number of changes and then implement a set of these changes in a new (intermediate) release of the product. These sets can be included in work packages which in turn, could be planned using baselines. A change control board should be responsible for updating and maintaining these baselines. This control board should also prioritize the changes with respect to necessity. Some changes may not be implemented at all because they are merely nice-to-have features and might cause unacceptable delay to the project. It is good practice to have templates for issuing change requests. The templates ensure a consistent formulation of the requested change and make sure that all relevant information is available. Furthermore, the change requests can then be stored more easily in a database. Each change request should be carefully examined with respect to its need, impact, feasibility and implementation before it can be included in a work package. After implementing the changes, regression tests of the whole system should be done to ensure that the whole systems still complies to all requirements. Problem reports During the, verification and use of the product, problems may arise that were not discovered earlier. These problems may be caused by wrong or faulty require- 15

24 ments, errors or incomplete integration and verification. Although reviews are held throughout the project, problems are inevitable. As with changes, problems should in general not be solved in an ad-hoc way. The handling of these problems can be the same as for change requests and should be collected in sets of problems depending on the importance and impact of the problems. After solving and implementing the problems, regression tests of the whole system should be done to ensure that the whole system still complies with all requirements Baselines Because of the large number of documents and product releases that can and will be produced during the systems engineering process, it is important to keep track of all these documents and releases in an orderly fashion. Baselines can help to keep track of the different revisions of the documentation and product releases. A baseline is an approved unit of configuration that can be individually managed and versioned. In literature, there is no single consistent definition of the word baseline, however, the creation and maintenance of baselines is part of a configuration management process. During the development of the system, changes to requirements may be necessary and this can result in a new revision of the documents. It is important to know which documents belong to which delivery of a product. Apart from tracking changes, baselines are also useful for project planning and give clear boundaries to everyone within and outside the project with respect to the work that (still) needs to be done. A number of baselines can be kept for different purposes. Possible and often used baselines are briefly described below. Configuration baseline A Configuration baseline is the configuration of a product or system established at a specific point in time, which captures both the structure and details of a configuration. It serves as reference for further activities. A configuration baseline is used to keep track of the different levels of build configurations, which can be software, hardware, or both. Furthermore, it is used to assemble all relevant components in readiness for a change or release, and to provide the basis for a configuration audit and regression after a change. A configuration management system should be able to save, protect and report on a configuration baseline, its contents and documentation. A configuration baseline may be created for any or all of the following reasons: As a sound basis for future work; As a record of what configuration items were affected by a request for changed (RFC) and what items were actually changed; As a point you can fall back to if things go wrong. System baselines This baseline may be considered to be the final functional requirements developed for the system. By establishing and maintaining formal system baselines, project team members will not be able to add/delete requirements without the full team fully considering the ramifications. Since requirements can (and often will) change, it is not very convenient to update every single change and create a new document. To deal with this, a set of changed requirements can be collected and included in a planned update or new revision of the requirement specification. The system baseline keeps track of these different revisions of the documents along with a list of changed requirements per revision. 16

25 Documentation baselines All the documents that are written in the project should be baselined so that a consistent set of documentation can be retrieved for each delivered product. This baseline tracks the documents and their revisions including all the changes per document. Design baselines During of the product, the documentation may be updated and new or improved tools may be used. A baseline can be used to provide the ability to change or to rebuild a specific version at a later date including the associated documentation for that version. Delivery baselines To keep track of the different releases of the system with its subsystems and components, a delivery baseline can be used. This is especially useful with incremental s, to keep track of the delivered functionality and to plan for future updates or increments Requirements management During the systems engineering activities lots of requirements are collected. In the previous sections, much has already been said about requirements and how to deal with them. Requirements management is the process that manages all these requirements, both technical and nontechnical, in a structured way. Part of the management of requirements is to document requirements changes and maintain bidirectional traceability between source requirements and all product and product-component requirements. A good and complete process description for requirements management can be found in (CMMI 2002). The main issues involved in requirements management are: Obtain an understanding of requirements; Obtain commitment to requirements; Manage requirement changes; Maintain bidirectional traceability of requirements; Identify inconsistencies between project work and requirements. Change control and baselining as mentioned in the previous sections, are good practices to manage these issues. At present, several tools are available for requirements management. To integrate these tools into the requirement management process, (Jones, D. et al. 1997) have written a good overview of available tools and how to integrate them into a systems engineering process. These tools can use a database-like structure to store all requirements. This structure makes it convenient to store and maintain large amounts of requirements and to ensure good traceability of the requirements. On the (CMMI 2002) webpage, requirements traceability is divided into two categories: Vertical traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source; 17

26 Horizontal traceability identifies the relationships among related items across work groups or product components for the purpose of avoiding potential conflicts. It enables the project to anticipate potential problems (and mitigate or solve them) before integration testing. For example, horizontal traceability would follow related requirements across two work groups working on two associated components of a product. The traceability across these two work groups enables the work groups to see when and how a change in a requirement for one of the components may affect the other component. Thus, horizontal traceability enables the project to anticipate potential problems (and mitigate or solve them) before integration testing. Horizontal traceability is important, but it is not required to satisfy bidirectional traceability (Requirement-to-source and source-to-requirement traceability). Additional to these two categories, (Kotonya, G and Sommerville, I 1998) define six different types of requirements traceability: Requirements-sources traceability: Links the requirement and the people or documents which specified the requirement; Requirements-rationale traceability: Links the requirement with a description of why that requirement has been specified; Requirements-requirements traceability: Links requirements with other requirements which are, in some way, dependent on them. This should be a two-way link (dependants and is-dependent on); Requirements-architecture traceability: Links requirements with the sub-systems where these requirements are implemented. This is particularly important where sub-systems are being developed by different sub-contractors; Requirements- traceability: Links requirements with specific hardware or software components in the system which are used to implement the requirement; Requirements-interface traceability: Links requirements with the interfaces of external systems which are used in the provision of the requirements. Furthermore, requirement management tools make it possible for the systems engineer to generate (part of) the documentation that is needed for later phases in the system life cycle (for example DOORS from Telelogic) Document reviews The purpose of document reviews is to verify the compliance of the documentation with its inputs and applicable standards and to detect and correct faults in the documentation. This can be structured in a review (sub)process in which specific roles and tasks are defined. The process described here is a short description of an example process based on the author s own experience and is adapted from the review process used at Ericsson AB. Roles The roles and tasks that can be defined for a review process are: Moderator. The moderator or chairman is responsible for the correct carrying out of the process and will lead the meeting; Author. The author should be present in the review for receiving the comments on his document; Reviewers. These are the customers of the document. These can be technical experts, and verification engineers and other systems engineers to name just a few; Recorder. The recorder will only log the comments that were not handed in on the inspection record but came up during the meeting. 18

27 The process can be divided into three phases: preparation, execution and conclusion. For each of these three phases a short description is given in this section. Preparation phase For the preparation phase of the review, the subprocess should define the inputs for the review. The inputs consist of: The document under review; Specific checklists that are defined for the type of document. These checklists must guarantee that at least some basics are checked. The checklist can include items like checking the structure and layout of the document, the consistent use of language and terminology throughout the document, the correctness of the references, the clarity of the document to the intended users and the use of the correct input documents; All input documentation to the document under review. All these documents should be available to the reviewers; An inspection record to record all relevant information for the review. The moderator of the review has the responsibility to do an entry check before the review can take place. This entry check should ensure that the review is planned and that all required reviewers are available and have had enough time to read the document. Furthermore, the moderator should estimate the quality of the document. If the moderator is not satisfied with the document, he should postpone the review meeting until the document is good enough to review. The assigned reviewers use this phase to read the document thoroughly, writing down all issues in an inspection record. The issues can be categorized into missing, erroneous, improvement, superfluous and new information. Furthermore the issues should contain a classification like major or minor to prioritize the (possible) rework of the document. Execution phase The execution of the review is a logging meeting where all participants in the review are present. During this meeting, the issues that were found during the preparation are discussed briefly, to make sure the author understands the problems. New issues may also come up. It is not the purpose of this meeting to have in-depth discussions, instead, these discussions must be postponed to another moment in time and only with the people that can contribute to the issue. At the end of the review meeting, an accept decision on the document should be made. The accept decision can be either: approved, approved after rework or re-review. Conclusion phase During the conclusion phase of the review, the postponed discussions should be held and the issues should be resolved. The author of the document must update his document with all issues of the review and if he decides not to include some, he has to give an explanation and update the inspection record with the rework information. The moderator in turn will inspect the updated document together with the updated inspection record to make sure that all issues have been dealt with Roadmapping One of the tasks of a systems engineer is to make and maintain system roadmaps. A roadmap links strategy to future actions and incorporates a plan for needed capabilities and technologies to be in place at the right times. Roadmaps that can be made are: 19

28 Product-Technology Roadmaps that link market and competitive strategy to product plans to technology strategy; Industry Roadmaps that provide a shared industry vision and the path for the industry to achieve that vision; Science and Technology Roadmaps that enable teams to link applications, technical challenges, and technology development for science-driven technologies; A roadmapping process directs the systems engineer to set a strategy based on the most important market and customer needs, and to determine product feature evolution and technology plans. The roadmap includes future actions needed to implement the strategy along with the key risks. The roadmap also communicates the plan to decision makers, customers, suppliers and other stake holders. In an organization, roadmaps provide the basis for product and technology portfolios Final note about systems engineering methods and tools In the previous sections, some tools were described that can help the systems engineer to achieve his goals. The list, however, is by no means complete. There are a lot more tools around than described here. For example, the "house of quality" method, that originated in 1972 at Mitsubishi s Kobe shipyard site. A good overview of the "house of quality" tool can be found in (Hauser, J. R. and Clausing, D. 1988). The tool is part of a management approach known as quality function deployment (QFD) and includes Failure Mode and Effect Analysis-like methods to assess the risks in a project or system. Another subprocess that must be mentioned here is configuration management. The purpose of configuration management is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting and configuration audits. The process of configuration management is described in detail in (CMMI 2002). Configuration management involves the process of creating and maintaining baselines and tracking and control of changes and problems. At present, different software solutions are available to implement configuration management (for example: Clear Case from Rational). However, it is usually not the responsibility for the systems engineer to do the configuration management, he or she merely uses it as a tool to track the process of specific configuration items or gives input and feedback to the person(s) responsible for the configuration management. The term configuration management can be a little confusing at times because it is used for both related configurations as well as for product related configurations (or both). There are no names in use to distinguish between the two and the intended meaning should be clear from the context. 20

29 3 Systems engineering process models Why would we want process models to prescribe the way of working? Processes are often seen as overhead and standing in the way of creativity. People perceive them more as a burden than as an aid to accomplish the work that has to be done. Using a process has several advantages over ad-hoc development and. Furthermore, processes should not completely change the way people are working, but merely describe a good and well-established way of working so that it can be passed on to other (new) people in the organization. In (Douglass, B. P. 2003), a process is described as: "A process is the specification of a sequenced set of activities performed by a collaborating set of workers resulting in a coherent set of project artifacts, one of which is the desired system". A good process does the following: It provides a project template to guide engineers through the development and delivery of a product; It improves the product quality in terms of a decreased number of defects, a lowered severity of defects, an improved reusability and an improved stability and maintainability; It improves the project predictability in terms of the total amount of effort and the length of calendar time required for completion; It communicates project information appropriate to different users in ways that they can use effectively; It offers a method to reliably (re)produce systems with complex behavioural requirements; It offers a way to identify milestones during the developments phases, enabling intermediate corrections and decisions when necessary. An important characteristic of a process is its scalability. This means that the process should not be unnecessary complex and can be used (with, possibly, small adaptations) for both small and large projects. 3.1 Process model taxonomy Systems engineering processes can be seen as the glue that holds the system life cycles and the systems engineering tasks together in a structured way. Nowadays, a lot of models for systems engineering processes exist. This chapter gives an overview of some of these models. A complete overview would be impossible because of the sheer infinite number of models that are around or could be derived. Process names are not consistent throughout the literature. Different people use different names for the same process models and vice versa use the same names for different process models. At the risk of adding more confusion, this chapter tries to describe the models at a general level. It is out of scope of this document to go into all the details of the process models and to try and align the nomenclature. In (CTG.MFA ), a short overview of different process models is given. As an example, (CTG.MFA ) also describes a process model that is called the "prototyping development model". This is a general name that can apply to different process models mentioned in this document. To add to the confusion, the spiral model is also called an iterative development model (as in (Douglass, B. P. 2003)). 21

30 To get around this naming problem, the process model names in this document are kept generic and pure, without including the development approach that an organization can decide to use. All the described models are (more or less) derived from the same basis: the waterfall model. The main difference is the amount of feedback that is incorporated in the model. To reflect this, the models will be described with an increasing order of feedback and complexity. The models that will described here are: Waterfall model; Waterfall model with limited feedback; Waterfall model with full feedback; V-model; Spiral model; CAFCR model. The first three models could even be more generalized to one process model called something like "n-level feedback waterfall model" where n is a positive integer number. The latter three have different angles of view, but use the waterfall model implicitly. In must be noted that there is no "best" process. Each model has its own application area and depending on the complexity of the product, the project and the organization, these models can and will be combined in every-day practice. Nevertheless, this overview is necessary to develop a process for the knowledge exchange model in chapter 4. This chapter gives a short description of the aforementioned models, using (where possible) the definitions of the system life cycles and systems engineering tasks as described in sections 2.1, and 2.2 and 2.3. It is by no means the intention to describe the models in full detail. This is a very complex task (including complete process descriptions) and is way out of scope for this document. As mentioned earlier, each individual model can be adapted to specific projects and products. It is up to the organization and the systems engineers to decide upon a model and adapt it to their specific situation. This process of adaptation will not be described here. 3.2 Waterfall model The waterfall model is one of the earliest methods of structured system development and is the simplest and most basic of the models discussed. This method of analysis was the dominant approach to systems engineering during the 1980 s and it is still by far the most common way of scheduling and managing projects. The model is therefore the basis on which the other processes are build and improved upon. A schematic overview of the waterfall model is depicted in figure 3. It shows the waterfall model as a linear process in time in which the successive system life cycle phases are performed sequentially. Each phase follows the next only when that phase is completed. The process works well when the problems and solutions in the system are well understood. 22

31 Conceptual Preliminary Detailed Production/ Construction Support/ Maintenance Phase-out/ Disposal Figure 3 Waterfall model Its simplicity and rigidness is also one of the drawbacks of this model. Since each phase has to "wait" for the previous before it can start, and no feedback is present between the phases, system faults and defects are not identified and fixed until late in the process. This will not only lead to (possible) delays in the project, but can also lead to increased costs of the system. Other problems and challenges associated with the waterfall model are: Real-life projects rarely follow the sequential flow that the model proposes; At the beginning of most projects there is often a great deal of uncertainty about requirements and goals. The model does not allow these uncertainties to be diverted to later phases of the system life cycle phases and must be solved before continuing to the next phase; New and changed requirements cannot be handled easily in the model because their introduction will either lag the project s progress or stop the progress completely. This model is the most suited model where the complete system functionality and system life cycle are clear from the start, as is often the case with simple products (i.e. when an organization decides to follow a linear development of the product). 3.3 Waterfall model with limited feedback To overcome some of the problems with the waterfall model, limited feedback can be added to the model. The resulting model is basically the same as the waterfall model and has the same successive system life cycle phases performed sequentially. The main difference with the basic waterfall model is, that the feedback allows for faster response to errors, system faults and defects during the development. Furthermore, this model for developing systems could provide faster results, require less up-front information and offer greater flexibility. A schematic overview of the limited feedback model is depicted in figure 4. It illustrates the feedback loops in the model by the arrows pointing to the previous phases. 23

32 Conceptual Conceptual Preliminary Preliminary Detailed Production/ Construction Detailed Production/ Construction Support/ Maintenance Phase-out/ Disposal Figure 4 Waterfall model with limited feedback In general, this process works well, when the problems and solutions of the system are not well understood. The process model allows a certain degree of uncertainty in the project. Unclear, new or changed requirements can be diverted to a later phase or iteration in the project without too much interference in the product development. The model can be used to produce intermediate prototypes or experimental versions at the end of each step. This is especially useful for software related products, where the results can go directly into production as an incremental release. By using the limited feedback process model, a product can also iterate towards the final product. Furthermore, because of the feedback, the process allows for limited risk assessments after each iteration to determine a go or no-go decision before going to the next phase or restart a phase with the acquired feedback information. With the waterfall model with limited feedback, the project can be divided into small(er) parts. This allows the development teams to demonstrate (intermediate) results early in the process and obtain feedback from system users (customers), and give feedback to previous phases in the system life cycle. Often, some phases in the system life cycle are mini-waterfall processes by itself. For instance the linear of a software module. Problems and challenges associated with the waterfall model with limited feedback are: The customer needs to be actively involved in all the phases throughout the project. While this involvement is positive for the project, it is demanding on the time of the teams and can therefore add project delay; Good communication and coordination skills are required during project development; Informal requests for changes or improvements after each phase may lead to confusion. A good configuration management and change control process should be used to cope with these requests; This process model is often used when an organization decides to follow an iterative development approach of the product of system. When using an iterative development approach, there are some additional challenges to keep in mind: 24

33 Using different iterations to make prototypes can lead to false expectations of the customer because the customer mistakenly believes that the system is finished when in fact it is not; Iterative development can lead to increased customer demands, because the customer realizes the potential of other system capabilities which could lead to more work; When using different iterations to come to a final system, the resulting system may be poorly ed because of the layered structure. Some system components and their interactions may not be implemented in the most optimal way. 3.4 Waterfall model with full feedback Adding all feedback possibilities to the model, the waterfall with full feedback emerges. This model is most appropriate if the system can be broken down into pieces. A development based on this model can be executed as a sequential process, or one in which some of the phases may be performed in parallel. The process model is depicted in figure 5, where all the feedback possibilities are illustrated with arrows. The multitude of arrows indicate the flexibility and additional feedback possibilities in the model compared to the limited feedback case. Conceptual Preliminary Detailed Production/ Construction Conceptual Preliminary Detailed Production/ Construction Support/ Maintenance Phase-out/ Disposal Figure 5 Waterfall model with full feedback This process model is even better suited for products where the problems and solutions of the system are not well understood. The process model allows a high degree of uncertainty in the project. Unclear, new or changing requirements can be diverted to a later increment in the project without interference of the product development. Furthermore, because of the feedback, the process allows for improved risk assessments after each phase to determine a go or no-go decision before starting the next phase. Even though the waterfall model with full feedback has more flexibility and feedback possibilities, the problems and challenges associated with this development model are still the same as for the limited feedback case. The problems can even get worse, when an organization is not equipped to handle the complex nature of the process model. This model is suitable for both iterative and incremental development approach. These two development approaches are quite similar and are often mixed-up. (This is another 25

34 example of process names that are not consistent throughout literature.) The main difference between iterative and the incremental product development is that the first involves the addition of features over time whereas the latter aims for multiple product releases to the customer, with added functionality in each release. The iterative development model approach aims for one final product with full functionality in the release by means of iterating towards that final product, adding and changing functionality until the product fulfils the customers needs. Each phase in an incremental development can be a (mini) waterfall with limited feedback in itself. Incremental development is illustrated by extra feedback arrows spanning more than one phase, which show that from each phase, the development can be restarted to anticipate on new or changed requirements or to restart the development for new increments. By using the feedback information from the previous phase(s), problems can be taken into account and may be solved. 3.5 V-model The V-model is basically a folded waterfall with full feedback model but, instead of focusing on a systems life cycle approach, the V-model promotes the integration and verification aspects of product development. A graphical representation of the V-model is shown in figure 6. The model shows a top-down development and a bottom-up implementation approach. Conceptual System analysis System test spec. Feedback System verification Specification, analysis and Preliminary Detailed Production and construction Functional analysis Requirements analysis Sub-system test spec. Feedback Component test specification Feedback Architecture synthesis Implementation Requirements verification Functional verification Integration, verification and fix Figure 6 V-model The left "leg" of the "V" represents the Specification, Analysis and Design (SAD) of the system. When going down in the model, the level of detail increases; the requirements are broken down more and more to component level. The most important aspect of this model is that it enforces the test specifications to be written and ed during the SAD phase of the system. This means that for instance the sub-system test specifi- 26

35 cation is made during the functional analysis of the system. Additional feedback is included for reviews, clarifications and corrective actions. The right "leg" of the "V" represents the Integration, Verification and Fix (IVF) of the system. When going up in the model, the level of detail decreases; the system is assembled more and more into the final system. During the IVF phase of the system, feedback should be given to different phases of the development. On the one hand, feedback is given to the lower phases in the right "leg" to ensure that the problems found during IVF can be resolved. On the other hand, feedback should be given to the SAD phases at the same level to ensure that fundamental problems with the system are dealt with and to state the level of compliance with the (user) requirements. At the bottom of the "V" is the implementation part of the system. Here, all the system components are actually implemented, possible prototypes are built and preparation for production and construction of the system is done. There is no explicit mapping of the system life cycles incorporated in the model. However, an implicit mapping of the system life cycles as defined in chapter 2 can be made as shown with the dotted lines in figure 6. Note that the Product use, support and maintenance phase as well as the Phase-out and disposal phase are not mentioned. This does not imply that they are not included in the model, but merely that these phases cannot be depicted in the figure. These phases are implicitly mapped to the systems engineering activities. These dotted lines in figure 6 have a second meaning in the model. They can be used to establish the baselines for development as described in section The process model can be used for both iterative and incremental development approaches but since the model is basically a waterfall model, the problems and challenges associated with this model are also the same as for the waterfall models. However, since the V-model promotes the IVF strategy more prominently than the waterfall models, this model allows very fast response to errors, system faults and defects during the development and can therefore increase the quality of the system. The V-model is an excellent model for indicating the methods and tools as described in section 2.3. Baselining and (document and ) reviews have already been discussed, but also the other methods and tools can easily be placed in this model, for instance requirements traceability. In the left "leg", the requirements hierarchy is placed in a tree-like structure with increasing level of detail. In the right "leg", the system hierarchy is placed, also with a tree-like structure but with decreasing level of detail (up side down). From this perspective, the requirements traceability relations as defined in section can be mapped perfectly to the V-model. 3.6 Spiral model The spiral model is an attempt to capture the real-life flow of activities and, in fact, corresponds to a sequence of waterfall models (with limited feedback). It is illustrated graphically by a spiral. As with the waterfall model with limited or full feedback, the spiral model is well suited for products where the problems and solutions of the system are not well understood or where the product is critically dependent on a technology still under development. The process model is depicted in figure 7. In literature, both directions of the spiral appear. In this document the spiral moves inwards, to represent the convergence of the development cycle. (After all, the goal is to iterate towards a final system rather than to divert from a pre-defined system to its individual components!) In the spiral model, the systems engineering activities play a more prominent role then the system life cy- 27

36 cles. In this model, the systems engineering tasks are all executed during one turn of the spiral. After each turn, an evaluation of the project is made and a risk-analysis is executed to decide if it is still feasible to continue the product development. These decision points or milestones mark the end of a system life cycle. Functional verification System verification Risk analysis and decision points Conceptual Preliminary Detailed Production and construction Support and maintenance System analysis Functional analysis Phase-out and disposal Requirements verification Architecture synthesis Requirement analysis Figure 7 Spiral model The spiral model is well suited for both iterative and incremental, risk oriented, development approaches, but is mainly ed for iterative (software) development. The model involves the use of multiple prototypes before building of the final product. The spiral is the most appropriate for products where the problems and solutions of the system are not well understood. The process model allows a high degree of uncertainty in the project up to the level where it is still unknown what the system should do, or that the system cannot (yet) be easily broken down into pieces. Because of that, the model is also known as the iterative enhancement model. 3.7 CAFCR model The CAFCR process model is developed and defined in (Muller, G. 2004). The model copes with the complexity of the systems life cycles by defining a set of views and focuses on the relation between the customer world and the product. In total five views are defined: the Customer objective, Application, Functional, Conceptual and Realization view. In contrast to the waterfall models as described earlier, the views are executed in parallel and must be used concurrently. To use the model, a set of generic or basic methods are defined to aid the systems engineer in his work. These basic methods include viewpoint hopping, decomposition, decision making and modelling. Furthermore, for each view a set of sub-methods exist to guide the systems architect through the development steps by subdividing the basic methods. To relate the different views 28

37 to each other, a set of qualities is defined. Examples of these qualities are: useability, safety and testability. These qualities are the integrating concepts through the five views. The CAFCR process model is depicted in figure 8. Note that the model does not explicitly map the views on the systems life cycles, however, an implicit mapping can be given as depicted in figure 8. Conceptual Preliminary Detailed Production/ Construction Phase-out/ Disposal Support/ Maintenance Customer Product Customer objectives Application Functional Conceptual Realization usability safety testability Figure 8 CAFCR model The CAFCR process model was developed especially for embedded systems architecting and focuses on the customer s requirements. It allows for a high degree of uncertainty in the project up to the level where it is still unknown what the system should do. Additionally, the model is used iteratively, meaning that the process can fold back onto itself, to understand the customer s customer. Furthermore, the process introduces a set of activities that are the same (recursive in CAFCR terms) and concurrent within the subsequent levels of complexity of the system. These activities also provide feedback towards the higher levels of complexity of the system. 29

38 30

39 4 The search for a knowledge exchange model As can be seen from the discussion of different process models in the previous chapter, a process is not the holy grail for systems engineering. The systems engineer cannot just pick a model and let that define the way of working. Instead, the systems engineer must tailor a systems engineering process to the specific problem that needs to be solved, and choose a development approach that fits the problem. For instance, a complex software system could benefit from an iterative development approach, whereas a complex communication system could be developed using an incremental approach. An overview of the process models from chapter 3 and their relation to a development approach is given in table 1. Process name Waterfall model Waterfall model with limited feedback Waterfall model with full feedback V-model Spiral model Process deployment Discipline driven approach (Linear development) Functional driven approach (Iterative development) Solution driven approach (Incremental development) Verification driven approach Risk driven approach CAFCR User driven approach Table 1 Process models and their application areas Although the relations from table 1 can be useful, it should be used with caution; a development approach in itself does not necessarily imply a systems engineering process model. Additional factors play a role in deciding upon a process model. For example, the complexity of the organization is an important factor. A small company with only a few people would hardly benefit from a complex spiral model or V-model. In fact, it might decide to use the basic waterfall model without any feedback and follow a linear development approach even though the product or system is quite complex. This is especially true if the members of the (small) development team have a very good overview of the problem at hand and are brilliant ers as well. If a randomly picked, real life, process is examined, it will contain aspects from different processes. This implies that the taxonomy from the previous chapter might not be useful for defining a new process that is to be used for the problem at hand. A real-life process is likely to have aspects of all the described models. When trying to describe a real-life process, generalizations must be made and details are bound to disappear. These details often consist of parts of other models that are conveniently overlooked. The descriptions of the process models in chapter 3 are not detailed enough to be used in practice. Even when a process is described in full detail, it is seldom the case that a company selects that process and uses it as is. In practice, a description of the way of working in an organization is made and translated into a process model of some sort to introduce a consistent and reproducible way of working (this process model might not even fall into the given taxonomy). New employees can then get familiar with this way of working by studying the process descriptions. 31

40 4.1 Choosing a systems engineering process model So, how should the systems engineer (or the organization) decide on a process model? As described earlier, the choice of the model depends on the organization, its environment and the nature and complexity of the product. (Land, F. 1998) showed that it is possible to identify four categories of relationships between (information) systems and their organisational environment. The four categories he identifies are: The Unchanging Environment. The requirements are unchanging for the lifetime of the system (for instance those depending on scientific algorithms or physical laws). Requirements can be stated unambiguously and comprehensively and a high degree of accuracy is essential. In this environment, the waterfall and waterfall with limited feedback process models, could provide the necessary completeness and precision required by the system. Examples of this environment are paper-clip production and house-building; The Turbulent Environment. The organization is undergoing constant change and system requirements are always changing. A system developed on the basis of the conventional Waterfall Model would be already partly obsolete by the time it is implemented. Many business systems fall into this category. In this environment, process models like the waterfall with full feedback, the V-model and the spiral model could prove successful. Examples of this environment are telecommunication systems and consumer electronics; The Uncertain Environment. The requirements of the system are unknown or uncertain. It is not possible to define requirements accurately ahead of time because the situation is new or the system being employed is highly innovative. Here, the development process must emphasize learning. Experimental process models, like the waterfall with limited feedback, the spiral model and the CAFCR model, are most appropriate. Examples of this environment are universities, knowledge institutes, research departments of companies; The Adaptive Environment. The environment may change in reaction to the system being developed, thus initiating a changed set of requirements. Self-learning systems and expert systems fall into this category. For these systems, adaptation is key, and the methodology must allow for a straightforward introduction of new rules. For this environment, the waterfall with full feedback and the V-model processes could provide the required results; Even with this categorization, it is not clear or straightforward to just pick a process model. A process model must be engineered in order to fit the environment and the system to be ed. Defining the right process for a project is a systems engineering activity in itself and to execute this activity, the systems engineer can and must take the analysis from this chapter into consideration. When the development approach and the environment of a process to be developed can be determined in advance, an existing process model can be used as a starting point for the development of the new process. 4.2 Developing a systems engineering process model The search for a knowledge exchange model, is not just simply making a combination of the process models that are described in the previous section. In (Hitchins, D. K. 1992), a five-step approach to developing a process model is proposed. He describes a process model as a number of sequential phases, each marked by the achievement of an objective such that the objectives sum to be the goal of the proc- 32

41 ess represented by the model. The process model thus describes a system (or perhaps a meta-system) for producing a system (the goal). These five steps are: 1 Start at the end, that is define the end-system that the process model is intended to produce, its siblings, containing system(s) and their objectives, contained systems and environment(s); 2 Synthesize strategies and consequent activities to create the end-system's intrinsic and emergent properties and overcome threats to their achievement; 3 Consider the process as a system, that is define its system features, siblings, containing system and objectives, contained systems and environment; 4 Develop a process model strategy and framework acceptable within their containing system, harmonized with siblings; 5 Sequence end-system activities into the process model framework to achieve objectives on the path to the goal; By following these five steps, a (new) process model can be conceived. However, a thorough investigation into the goal, objectives, problems, challenges and threats for such a system is needed. Hitchins five step approach is quite formal. Another (less formal) approach is based on the system life cycles as discussed in chapter 2. In fact, this is a reduced form of Hitchins five step approach and could be used for less complex systems. A more extensive description for the development of a systems engineering process based on the system life cycles can be found in (Dean, F. F., Benz, B., Bahill, A. T. 1997). 4.3 Case study: individual assignment To illustrate the process of developing a process model, an interesting system for which to develop a process model for would be the process for doing an individual (research) assignment. However, a thorough investigation into the system is out of scope for this document, therefore, the (limited) system description that is given here is only a small set of possible issues that are of importance in this system. The system as described here is merely intended as an example to illustrate a method but can be used for further and more in-depth development of the system. The process model will be developed using a combination of the methods proposed by Hitchins and the approach based on the system life cycles Process model The first step in the development of a process model is to define the end-system that the process model is intended to produce, its siblings, containing system(s) and their objectives, contained systems and environment. The end-system (goal) will be a successful assignment. The containing system(s) is the university s educational system. The purpose of an individual assignment is described in (Brink, R. W. 2003). The objectives to achieve this goal are: Learning to formulate an assignment properly; Finding theoretical bases for solutions, opinions and statements; Motivation of choices; Distinguishing between main and side-issues; Planning of work; 33

42 Documenting and presenting of the work. Because of the nature of an individual assignment, there are no siblings of this system. The contained systems are a system for documentation and planning and a system for research activities. Finally, the environment of the system is the university s educational system. Next, the system life cycles must be identified. Because of the nature of the process only four phases are relevant and the names of the phases are chosen in such a way that they cover the activities in these phases. The process is (in general) executed by a single person, meaning that there cannot be parallel activities in the process. This does not imply that all the phases must be executed in sequence or that a specific phase must be finished before moving to the next.phase. The process must have the flexibility to stop a certain activity at any time and continue with another activity if the situation calls for it. Furthermore, the process model must incorporate feedback. For example, it can be necessary to adjust the scope of the assignment during the execution phase, re-enter the concept phase if certain problems cannot be solved or if during the documentation phase, some ambiguity arise and the execution phase must be re-entered for solving specific problems. With all this in mind, a graphical representation of the process could look like figure 9. Concept phase Pre-study phase Execution phase Reporting phase Conceptual Preliminary Detailed Production/ Construction Figure 9 Graphical representation of the process model The next step in the development of the process is to define the individual activities that must be accomplished as the project moves on. An extensive discussion of these activities is out of scope for this document and can be found in numerous sources. A good process must be connected to a management process. Although not the scope of this document, some words need to be said about this. As with most things in life, time is of important. This means that a planning should be part of the assignment. Not only the planning of the individual work, but also the activities that require more people to be at the same place at the same time (meetings) must be planned. For a smooth process, this planning must be done during the concept phase of the project. Additional to the graphical representation a process description needs to be written to support the model. This description contains all activities and deliverables per phase in the project and should be written as a guide for the people that use the process model. 34

43 How a description of the process model could look like is illustrated in the next subsections Phase 1 Concept phase Goal The goal of the concept phase is twofold. Apart from the formulation of the assignment, a time planning (with as much detail as possible) for the assignment should be made. Often for individual assignments, the conceptual phase is already finished and the work has been done by the associated supervisor. In that case, the student will start with the pre-study phase after discussing the result of the concept phases with the associated supervisor. Activities Discussions; Initial literature studies. Results This phase should result in the selection of (research) topics and give an overview of the problem. A clear description of the problem is essential and a planning must be made in order to support the activities in the following phases of the assignment. The information gathered during this phase should be described in a proposal documents similar to a project plan Phase 2 Pre-study phase Goal The goal of this phase is to narrow the topic to a feasible amount of work (research assignments tend to grow as one is getting more into the subject). Statements and questions need to be formulated that form the basis for the research in the execution phase. A distinction between main and side-issues should be made and the problems must be identified and their scope and elements must be defined. Furthermore, the choices made during this phase must be clearly motivated. Activities More discussions; Extensive literature studies; Writing a project plan. Results This phase should result in a reduced scope of the problem to fit in the time frame of the assignment and in the identification of the elements that need to be explored in detail during the execution phase. Furthermore a project plan should be made that describes how the execution phase will be realized Phase 3 Execution phase Goal During this phase, a theoretical basis for solutions, opinions and statements needs to be found. Furthermore, the evidence must be evaluated and conclusions must be made. 35

44 Activities Doing experiments; Evaluating outcome of experiments; Redoing experiments (if needed); Reviewing results (if possible) with others; Reflecting on results and possible definition of additional experiments. Results This phase should result in a set of solutions, opinions and statements of the problem defined during the conceptual and pre-study phase. The experiments should be documented clearly in order to reproduce the findings and to back up the conclusions in the documentation phase Phase 4 Reporting phase Goal The goal of this phase is to communicate the results and outline the work done to the rest of the world. It also should present the documentation and presentation of the work. Activities Write documentation and give a presentation of the work done. Results The result of the activities in this phase should result in a finalized report describing the work done during the assignment. Furthermore, a presentation should have been given. At the end of the reporting phase (at least) a final report and an oral presentation should have been produced Final remarks Because of the nature of this system, the process model is relatively simple. In fact, the resulting process model resembles the waterfall model with limited feed-back. This was to be expected, since the development approach is functional driven and the development environment is unchanging. Based on these observations, the waterfall model with limited feedback could have been selected as a starting point and changed according to the specific activities of the assignment. The process description as presented in the section is very concise. For a final and useful process description, the different phases should be described in more detail to actually function as a guide for achieving a successful assignment. Especially the activities need more attention because they describe the way of working in the project. 36

45 5 Towards a knowledge exchange model At the start of this assignment, the problems with the knowledge exchange between universities and (private) companies were discussed. Although not the direct scope of this assignment, it could prove a useful exercise to try and make a process model for that system using Hitchins five step approach, however, a thorough investigation, into the system is necessary in order to find all problems, challenges and objectives for this system. As a starting point, a (limited) system description can be given that contains only a small set of possible issues that are of importance in this system and is based on different sources found in the literature. For example, the taxonomy of science-based University-Industry collaborations as described in (Casas, R., De Gortari, R. and Luna, M. 2000), in which some objectives and threads are identified. In addition, discussions need to be held with the problem owners (managers from both university and private company) to refine the objectives and threats for this system and to find strategies to overcome these threats. (The activities for this are actually the same as for the system analysis activities as described in chapter 2.2.1). Furthermore, surveys and questionnaires are useful tool for assessing those objectives and threats. See (Casas, R. 2003) in which she describes the exchange and knowledge flows between large firms and research institutions and how that research was done. These objectives and threats should then be used in the development of the process model. The first steps in the development of such a process model could look like this: step 1 The first step in the development of a process model is to define the end-system that the process model is intended to produce, its siblings, containing system(s) and their objectives, contained systems and environment. The end-system (goal) will be a process model that describes the activities to be undertaken by the university and the industry in achieving a successful and mutually beneficial cooperation. The containing system(s) are the (internal process models from the) university and the industry. The objectives to achieve the end-system goal are for example technical personnel training, product, process and production improvements and research activities (see (Casas, R., De Gortari, R. and Luna, M. 2000)). Siblings of this system are the management system, the research system and the development system. The contained systems are the systems for documentation, planning and resource allocation (including housing, equipment etc.). And finally, the environment of the system is the scientific community as well as the competition of other industries and universities. step 2 The second step is to synthesize strategies and consequent activities to create the endsystem's intrinsic and emergent properties and overcome threats to their achievement. To do this, (Hitchins, D. K. 1992) uses a TRIAD building system for structured models. 37

46 The term TRIAD reflects the repeated three-part structure which persists throughout: objective, threat, strategy (see figure 10). The Prime Directive (Objectives) Threat to Achieving the Prime Directive Strategy for overcoming the Threat and achieving the Prime Directive Figure 10 Hitchins TRIAD building system The prime directive of the system must now be broken down into different objectives. For each objective, the TRIAD is then built to identify the threats and strategies to overcome these threats for each objective. This is where the challenging part starts and all objectives, possible threats and strategies to overcome these threats need to be identified. This will not be explored in more detail in this document. The next steps in Hitchins approach are too detailed for this document and need a thorough investigation of the problems and threats. 38

47 6 Conclusion and recommendations 6.1 Conclusion In the first part of this document, an overview has been presented using the systems life cycle and systems engineering methods and tools that are used throughout the professional world today. This overview finished with the description of available process models. In the final part of this document, the information from the first part has been evaluated. From this final part, one could deduce that the process models that are available today are not useful, however, this is not the case. The process models are, after all, not that bad and are a good starting point for the of a new process model. The systems engineer must first analyse the problem and see if one of the process models can be adapted to the problem at hand. This can be especially useful, because a lot of information about these process models are already available and activity descriptions and methods and tools can be re-used from these process models. Only if one of the available process models cannot be adapted to the problem, the systems engineer must resort to other, more formal, methods to a new process model that fits the problem. Two of these formal methods and the development of a new process model have been discussed. Based on the system life cycle approach, a new process has been developed for the purpose of doing an individual (research) assignment. This case study showed that the development of a suitable process model is not trivial. A lot of knowledge must be gained on the actual work that needs to be done and how, in general, the people are working on similar problems. When this information is available, the systems engineer can the new process and the activities, methods and tools to support that new process. So, have I now finished my search for a knowledge exchange model? I do not think so. I feel like I have only just scratched the surface of this intriguing subject and I expect to be exploring it more in the future. During the work I have done on this assignment, I came across some other concepts that were new to me and that described other ways of working. Apart from the holistic approach as mentioned in the introduction, concepts like, action research and system thinking gave me some interesting insights in other forms of systems engineering that unfortunately could not be explored because of lack of time, but could prove a useful addition to (my search for) a knowledge exchange model. 6.2 Recommendations The course "Systems Engineering" as currently given at the University of Twente has a limited scope with respect to systems engineering processes. It is therefore recommended that the course is extended to the systems engineering processes, methods and tools as described in this document to include a broader view of the systems engineering discipline. For students it is often difficult to estimate and plan the work that needs to be done on an individual assignment. A structured way of working can than help to overcome these difficulties. It is therefore recommended that students doing their individual assignments follow the process as outlined in section 4.3 of this document. This will not only enforce a structured way of working throughout the assignment, it also helps to 39

48 keep track of the work by identifying the things that (still) needs to be done. Furthermore, the (intermediate) deliverables for each phase of the process can serve as a base for further discussions with the associated supervisor. The search for a knowledge exchange model has not been finished. Based on discussion during this assignment it became apparent that there are certain challenges with the knowledge exchange between universities and (private) companies and that the interaction between these parties must be described in a more formal process. In this document, methods for developing such a process are outlined and it is recommended that these methods are employed to develop a formal process for this problem. 40

49 Acronyms CAFCR COTS IVF FMEA QFD SAD SMART SE Customer Objectives, Application, Functional, Conceptual, Realization Commercial Off The Shelf Integration, Verification and Fix Failure Mode and Effect Analysis Quality Function Deployment Specification, Analysis and Design Specific Measurable Achievable Realistic Traceable Systems Engineer(ing) 41

50 42

51 References Bol, D. 2002, R&D in systems engineering perspective, Aircraft Development & Systems Engineering company ( adse.nl/) Blanchard, B. and Fabricky, W. 1998, Systems engineering and analysis, third edition, Prentice Hall, ISBN Brink, R. W. 2003, Studiehandleiding voor HBO-ers, Elektrotechniek, Studiejaar , Universiteit Twente, BOOZ-EL/0134/03 (in Dutch) Casas, R., De Gortari, R. and Luna, M. 2000, University, knowledge production and collaborative patterns with industry, Developing innovation systems: México in a global context, Pages , Continuum, ISBN Casas, R. 2003, Exchange and knowledge flows between large firms and research institutions, Innovation: Management, Policy & Practice, Volume 7 part 2 and , econtent management Pty Ltd., ISBN X-iv CTG.MFA , A survey of system development process models, Center for Technology in Government, University of Albany / SUNY, doc. no. CTG.MFA-003 CMMI 2002, Capability Maturity Model Integration, version 1.1, Carnegie Mellon Software Engineering Institute ( Dean, F. F., Benz, B., Bahill, A. T. 1997, A road map for implementing systems engineering, New Mexico Weapons Systems Engineering Center Sandia National Laboratories Douglass, B. P. 2003, Real-time patterns, Addison-Wesley, ISBN Hatley, D., Hruschka, P. and Pirbhai, I. 2000, Process for system architecture and requirements engineering, Dorset house publishing, ISBN Hauser, J. R. and Clausing, D. 1988, The house of Quality, Harvard Business review May-June 1988 Hitchins, D. K. 1992, Putting systems to work, Wiley, Chichester, ISBN ( IEEE 1998, IEEE Standard for application and management of the systems engineering process, Institute of Electrical and Electronics Engineers inc., ISBN INCOSE 2004, Systems engineering handbook, version 2a, International Council of Systems Engineers ( Jones, D. et al. 1997, Interfacing requirements management tools in the requirements management process - A first look, Proceedings of the seventh international symposium of the INCOSE, volume 2, August 1997 Kotonya, G and Sommerville, I 1998, Requirements management, Lancaster University Computing Department, ( Land, F. 1998, A contingency based approach to requirements elicitation and systems development, Journal of Systems and Software volume 40, issue 1 January 1998, Pages

52 Muller, G. 2004, CAFCR: A multi-view method for embedded systems architecting, PhD-thesis, ISBN Stevens, R., Brook, P., Jackson, K. and Arnold, S. 1998, Systems engineering coping with complexity, Pearson education limited, ISBN