A review of systems engineering standards and processes

Transcription

1 Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) A review of systems engineering standards and processes Guey-Shin Chang, Horng-Linn Perng, Jer-Nan Juang * National Applied Research Laboratories, 3F, No. 106, Ho-Ping E. Road, Sec. 2, Taipei 10622, Taiwan. Abstract This report provides an overview of the evolution of systems engineering standards and guidelines, process models, and compliance assessment models from past to present. The history of the development of systems engineering is introduced in order to show the need for its development in that the traditional approach was deemed inadequate due to the difficulties associated with newer larger-scale systems. Also in this report, systems engineering standards--defining the interdisciplinary tasks that are required throughout a system s life cycle in order to transform the customer needs into a systems solution--are reviewed from the standpoint of their evolution. The various commonly used system process models are addressed in order to emphasize that the functions of the defined processes are performed in a parallel and iterative manner. The evolution of compliance assessment models--used by organizations to investigate their compliance with all standards, process models, evaluation, assessment, and certification criteria--are examined as well. Finally, this report concludes that a working knowledge of systems engineering is an absolute requirement of personnel working in modern enterprises and that the implementation of systems engineering processes must be tailored to the scope of the job at hand. 1. Introduction Systems engineering is a methodology developed to address the increasing complexity that systems acquisitions have acquired over the past several decades. The need for a systems engineering approach that is able to transfer user needs into an operational system via an interdisciplinary process is highly sought after by both government and industry. In the past, the fields of military defense, space exploration, and software engineering were most interested in acquiring this type of capability. Recently, however, many enterprises, professional societies, and other types of organizations have recognized the importance of incorporating systems engineering models into their own business models. To this end, a great deal of effort has been made * Corresponding author. Tel.: ; fax.: address: [email protected] (J. N. Juang).

2 72 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) to develop a standard for systems engineering and to promote its use on the campuses of engineering-focused universities. As stated in ANSI/EIA 632 (1999), Systems engineering is intended to enable an enterprise to strengthen its competitiveness in global markets by engineering and producing quality systems and by delivering its products on time at an affordable price or cost. The focus, therefore, is on conceptualizing, creating, and realizing a system and the products that make up a system. Many global enterprises have included systems engineering competence in their visions. Some such enterprises include: Raytheon s Vision statement: We aspire to be one of the most admired technology companies in the world, and a "System of Systems" integrator. - Dan Burnham (CEO), November 9, 2000 Lockheed Martin s Vision statement: To be recognized as the world s premier systems engineering and technology enterprise. - Dan Tellep (CEO) and Norm Augustine (President), May 5, 1995 It became evident that there was a need for the development of systems engineering standards when the traditional approach was deemed inadequate due to the difficulties associated with newer larger-scale systems. These difficulties include the increased complexity of data, the expanding role of software, the lack of traceability, and cost overruns. In order to address these issues, it was necessary that a new approach for systems management, both from a technical and programmatic viewpoint, be established. As a result, many different systems engineering standards and models have evolved over the years. This proliferation of various standards serves to accommodate systems development, compliance assessment, and certification processes and, as a consequence, has created a set of diverse terminologies. Systems engineering s beginnings can be traced back to Bell Telephone Laboratories in the 1940s. However, it was not until almost thirty years later that the first U.S. military standard, MIL-STD-499, was published in 1969 (U.S. department of Defense, 1969). Systems engineering standards and guidelines have evolved from a federal government contract-centric approach to a commercial, voluntary-compliance approach. The first professional systems engineering society, the International Council on Systems Engineering (INCOSE), was not organized until the early 1990s and the first commercial U.S. systems engineering standards, ANSI/EIA 632 (1999) and IEEE 1220 (1998), followed shortly thereafter. It should be noted that this report only addresses the evolution of systems engineering standards and guidelines, process models, and compliance assessment models from past to present. It is not intended to cover the most recent model developments or specific implementations that appear within published literature. 2. Systems and systems engineering defined For people who are interested in the field of systems engineering, the questions most often asked are, What is a system and what is systems engineering? Many different definitions can be found on websites and in systems engineering standards and guidelines but, basically, they are all the same in terms of the subject. Systems Engineering

3 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) Fundamentals, published by Defense System Management College (DSMC, 2001), provides perhaps the most useful definition: Simply stated, a system is an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective. Systems engineering consists of two significant disciplines: the technical knowledge domain in which the systems engineer operates and systems engineering management. Three commonly used definitions of systems engineering are provided by the best known technical standards that apply to the subject. They all have a common theme: A logical sequence of activities and decisions that transforms an operational need into a description of system performance parameters and a preferred system configuration. (MIL-STD-499A, Engineering Management, 1 May Now canceled (U.S. department of Defense, 1974).) An interdisciplinary approach that encompasses the entire technical effort and evolves into and verifies an integrated and life-cycle balanced set of system people, products, and process solutions that satisfy customer needs. (EIA /Standard IS-632, Systems Engineering, December 1994.) An interdisciplinary, collaborative approach that derives, evolves, and verifies a lifecycle balanced system solution which satisfies customer expectations and meets public acceptability. (IEEE P1220, Standard for Application and Management of the Systems Engineering Process, [Final Draft], 26 September 1994.) In summary, systems engineering is an interdisciplinary engineering management process that evolves and verifies an integrated, life-cycle balanced set of system solutions that satisfy customer needs. It is interesting to note that the ANSI/EIA 632 does not define systems engineering as such, rather, it tries to define what to do with respect to the processes for engineering a system. 3. Evolution of standards and guidelines Systems engineering standards define the interdisciplinary tasks that are required throughout a system s life cycle to transform the customer needs into a systems solution. US Military Standard MIL-STD-499, Engineering Management, dated July 17 th, 1969, was an early standard on the subject of systems engineering. It was produced by the United States Department of Defense (DoD) for applications within the defense industry. MIL-STD-499 provided the first definition of the scope of engineering management and was very influential in defining the scope of systems engineering at that time. Five years later, the A-version, MIL-STD-499A, was released on May 1 st, The MIL-STD- 499B draft, dated 1992, was an updated and significantly rewritten version of MIL-STD- 499A that was distributed for review. At the time of its review, however, the majority of industry did not accept the most comprehensive of these standards, that being MIL-STD- 499B. In June 1994, as part of the acquisition reform effort, DoD decreed an end to military standards other than performance specifications. Then Secretary of Defense, Dr. William J. Perry, approved the Process Action Team s recommendation to use performance and commercial specifications, unless no practical alternative exists to meet the user s needs.

4 74 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) A memorandum titled Specifications and Standards A New Way of Doing Business (1994), by Dr. William J. Perry, cited a goal for DoD to increase its access to commercial state-of-the-art technology and allow for dual-use processes and products from the commercial sector in the military as a way to expand the potential industrial base for military equipment and services. Due to this policy the revision of MIL-STD- 499A was canceled and MIL-STD-499B was not officially released. The MIL-STD-499B standard, however, had been used extensively by the Air Force as well as by other hightech industries. The Director of Systems Engineering within the Office of the Secretary of Defense (OSD) asked that a group of organizations collaborate to develop a commercial systemsengineering standard to replace the military one. The working group was called the Electronic Industries Alliance (EIA) and was composed of representatives from the DoD, the Aircraft Industry Association (AIA), the National Security Industries Association (NDIA), the Institute of Electrical and Electronics Engineers (IEEE), and INCOSE. This working group made minor wording changes in the MIL-STD-499B draft and released a commercialized version of MIL-STD-499B in December 1994 that was known as EIA Interim Standard 632 (EIA/IS 632), Systems Engineering. This draft was written using considerably more industry input and then transformed into a replacement version called ANSI/EIA , Processes for Engineering a System. It was released in January 1999 (Electronic Industry Association, 1999; Martin, 1998; Valerdi and Wheaton, 2005). At the same time, IEEE was also working on a commercialized systems engineering standard. The IEEE standard also incorporated significant industry input and was based on the MIL-STD-499B draft and an AT&T systems engineering manual. The result was a systems engineering standard called IEEE 1220 (1998), Standard for Application and Management of the Systems Engineering Process. A Trial-Use version of IEEE 1220 was released in February 1995 and a Full-Use version in January The International Organization for Standardization (ISO) along with the International Electrotechnical Commission (IEC) jointly developed ISO/IEC (2002). ISO/IEC was an effort to create an international system life-cycle standard that was initiated by the same group that created the ISO software life-cycle standard, ISO/IEC ISO/IEC was augmented by people with systems engineering expertise. These three commerciallyderived standards each addressed the systems engineering processes at various levels and all three were required to fully realize systems engineering success within the organizations that needed them. Fig. 1 shows the evolution of systems engineering standards.

5 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) MIL-STD-499 July 1969 Engineering Management MIL-STD-499A May 1974 Perry Memo Abolishes new military standards June 1994 MIL-STD-499B June 1992 Coordination Copy MIL-STD-499C May 1994 Unreleased Draft MIL-STD-499C March 2007 Draft by TAC IEEE Commercial SE Standard began IEEE 1220 Trial Use X February 1995 IEEE 1220 Full Use January 1999 EIA/IS 632 December 1994 Interim Standard After Perry Memo ANSI/EIA 632 January 1999 nation c oor d i ISO ISO/IEC ISO/IEEE Fig. 1. The evolution of systems engineering standards. In addition to standards, many guidelines and handbooks on systems engineering were released by organizations, especially in the space and military sectors. A handbook with two volumes, MSFC-HDBK-1912A, Systems Engineering Handbook was released by the National Aeronautics and Space Administration (NASA)/Marshall Space Flight Center (MSFC) in 1991 and revised in NASA-SP-6105, NASA Systems Engineering Handbook was published by NASA in 1992 and revised in A book named Systems Engineering Fundamentals was published by Defense System Management College (DSMC) in 1999 and revised in In Europe, the European Space Agency (ESA) released a series of standards on space engineering including ECSS-E-10 that was released in April Systems engineering process models The systems process model describes an enterprise s activities as they relate to its total engineering effort to achieve a given outcome (i.e., a product or service). The systems process model illustrates the sequence and/or interaction among various project activities from creation to disposal of the product/service. The most commonly used process models are the Waterfall, Spiral, and Vee (Blanchard and Wolter, 2006). The Waterfall model (Royce, 1970), introduced by Royce in 1970, initially was used for software development. This model usually consists of five to seven series of steps or phases for the systems engineering of software development. Boehm expanded this into an eight-step series of activities in A similar model splits the hardware and software into two distinct efforts. Ideally, each phase is carried out to completion in

6 76 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) sequence until the product is delivered. However, such is rarely the case. When deficiencies are found, phases must be repeated until the product is corrected. The Spiral process model of the developmental life cycle (Boehm, 1988) was introduced as a risk-driven approach for the development of products or systems. This model was an adaptation of the Waterfall model, which did not mandate the use of prototypes. The Spiral model incorporates features from other models such as feedback. The Spiral model application is iterative and proceeds through several phases each time a different type of prototype is developed. It allows for risk evaluation before proceeding to the subsequent phase. The Vee process model was developed (Forsberg and Mooz, 1992, 1995) by Forberg and Mooz and described by them as the technical aspect of the project cycle. This model begins with the user s needs on the upper left-hand side and ends with a uservalidated system on the upper right-hand side. On the left-hand side, decomposition and definition activities resolve the system architecture, thus creating the design details. Integration and verification flows up and to the right as successively higher levels of subsystems are verified, thus culminating at the system level. The Vee process model also shows the verification and validation progress from the component level to the validation of the operational system. At each level of testing, the original specifications and requirements are referenced to ensure that the components, subsystems, and the system itself all meet the original specifications. ITERATIVE TRADE-OFFS Input Requirements Functional Analysis Synthesis OR Evaluation and Decision OR Description of System Elements WHAT WHY HOW OR SOLUTIONS Fig. 2. The systems engineering process. The traditional systems engineering process for accomplishing system design tasks is often referenced in publications (Systems Engineering Management Guide, DSMC, Jan 1990). Fig. 2 illustrates the activities of the basic systems engineering process. It consists primarily of four activities: 1) functional analysis, 2) synthesis, 3) evaluation and decision, and 4) a description of systems elements. The final product is production-ready documentation of all system elements. Although this process only deals with system design activities, it is the most traditional process used in the acquisition of defense systems over the last several decades.

7 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) Fig. 3. The SIMILAR process (Bahill and Gissing, 1998). In addition to the most commonly used process models mentioned previously, Bahill and Gissing (1998) proposed the so-called SIMILAR process. This process is usually comprised of the following seven tasks: 1) state the problem, 2) investigate alternatives, 3) model the system, 4) integrate, 5) launch the system, 6) assess performance, and 7) reevaluate. These functions are summarized using the acronym SIMILAR: State, Investigate, Model, Integrate, Launch, Assess, and Re-evaluate. The SIMILAR systems engineering process is illustrated in Fig. 3. Fig. 4. The relationship between systems engineering processes.

8 78 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) ANSI/EIA 632 also defines 13 processes containing a total of 33 requirements that are used in engineering a system. ANSI/EIA 632 can be applied to the developmental process of any product. These processes can be applied to the engineering or reengineering of the end products that make up the system as well as to the development of enabling products required to provide life-cycle support to system end products. Fig. 4 shows the relationships between the processes that make up this standard. The key concepts for this standard cited from ANSI/EIA 632 are summarized as follows: This Standard defines a systematic approach to engineering or reengineering a system, incorporating best practices that have evolved during the second half of the twentieth century. The defined approach has three premises: a) A system is one or more end products and sets of related enabling products that allow end products, over their life cycle of use, to meet stakeholder needs and expectations; b) Products are an integrated composite of hierarchical elements so integrated as to meet the defined stakeholder requirements; c) The engineering of a system and its related products is accomplished by applying a set of processes to each element of the system hierarchy by a multidisciplinary team of people who have the requisite knowledge and skills. Fig. 5. The 33 Process Requirements Specified by ANSI/EIA 632.

9 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) The process model is defined as an enterprise s activities as they are related to the total engineering effort to achieve a given outcome. Regardless of any defined processes, it is important to note that the Systems Engineering Process is not sequential. The functions are all performed in a parallel and iterative manner. The previous review report can also be found in Systems Engineering Review Report (2002) by Global Intergy Corporation. 5. Compliance assessment models Organizations that want to remain competitive usually strive to comply with all possible standards, process models, evaluation, assessment, and certification criteria. Organizations use system capability and maturity models to investigate their processes as well as the quality, cost, and effectiveness of their products. Capability models define the characteristics of good processes but do not necessarily prescribe how the processes should be implemented. Capability models are not actually processes. The purpose of capability models is to establish a process improvement roadmap upon which a route can be drawn from where we are today to where we want to be. In order to determine where we are today, an organization performs an assessment, also called an appraisal, sometimes with the aid of an outsider with specific expertise in that model. They intentionally do not address a particular life-cycle or sequence of activities. The first capability model, the Software-Capability Maturity Model (SW-CMM), was developed for the field of software development, or more precisely, the management of software development projects. Based on this, the Capability Maturity Model (CMM) models expanded on and addressed systems engineering, integrated product development, as well as other aspects of organizations including human resources and organizational security. In 1992, the International Council on Systems Engineering (INCOSE) sponsored a working group that began to address the assessment of systems engineering capability. This group developed the Systems Engineering Capability Assessment Model (SECAM) that was released in July Also, in December 1993, the Enterprise Process Improvement Collaboration (EPIC) group spun off from the INCOSE SECAM working group and developed the Systems Engineering Capability Maturity Model (SE-CMM) that was released in December A service mark report on the SE-CMM Ver. 1.1 (1995) was released by Carnegie Mellon University s Software Engineering Institute (SEI) in November This standard evolved from a software legacy. The development of these two groups meant there were now two systems engineering capability maturity models on the market. INCOSE and the Director for Systems Engineering in the Office of the Secretary for Defense agreed that the two models should be combined into one single model. EPIC and INCOSE agreed to work towards a merged model that was eventually called the Systems Engineering Capability Model (SECM), EIA/IS 731. SECM was accepted as the standard model within the systems and software engineering communities. It should be emphasized that the SECM is not a process standard but actually a standard for defining and assessing the maturity of the systems engineering discipline.

10 80 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) In 1997, the Software Productivity Consortium (SPC) created a website to help organizations understand which frameworks were most important and how they related to each other. Various combinations of international and national standards bodies, governmental organizations, professional societies, and other quasi-legislative bodies have promulgated a dizzying array of system process standards, recommended practices, guidelines, and capability maturity models. The resulting quagmire has quenched the ardor of many organizations seeking accreditation for one or more frameworks. The Frameworks Quagmire (Sheard, 2001), proposed by SPC, as shown in Fig. 6, provides detailed maps of the standards evolution and adds to the potential confusion over systems engineering standards and models. In December 2000, the Capability Maturity Model Integration (CMMI) was created by SEI. CMMI integrated the capability models for software engineering, systems engineering, and integrated product and process development processes. The CMMI provided specific assessment and appraisal method for systems engineering (SE-CMM), software engineering (SW-CMM), software acquisition (SA-CMM), integrated product and process development (IPPD-CMM), EIA/IS 731 (Software Engineering Institute, Carnegie Mellon University, 1995, 2001a, 2001b, 2001c, 2001d, 2002a, 2002b, 2002c, 2002d), etc. Before CMMI released their model, however, the U.S. Federal Aviation Administration created its own integrated CMM, FAA-iCMM (1997). The FAA model combined process areas from SW-CMM, SE-CMM, SA-CMM, ISO 9000, ISO/IEC 12207, ISO/IEC 15288, EIA 632, EIA/IS 731, ISO/IEC 15939, and the CMMI. The current version for FAA-iCMM is Ver. DS2.0. Fig. 7 shows the modified Framework Quagmire after CMMI published. The new version further integrated into CMMI for Development (CMMI-SEI, 2006), CMMI for Service (CMMI-SVC, 2006) draft, and CMMI for Acquisition (2007). The latest models integrate the bodies of knowledge that are essential for development and maintenance, acquisition environment and services practices, but that have been addressed separately in the past. The modified Framework Quagmire after three published CMMI constellations is shown in Fig. 8.

11 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) People CMM SDCE SCE PSP DOD- DOD- DOD- STD- STD- Process Stds CBA IPI SW-CMM STD- 2167A TSP 2168 Quality Stds 7935A Maturity or SCAMPI ISO/IEC Capability CMMI J-STD MIL-STD- Models ISO FAA- 016 Appraisal SAiCMM # methods CMM SSE- RTCA Guidelines PSM CMM DO-178B FAM** IEEE/EIA Six IPD- SE-CMM Sigma CMM* Baldrige EIA SECAM ISO 9000 ISO/IEC SAM 731 series IEEE Q9000 EIA/IS 1220 MIL-STD 632 TL B* ISO/IEC ANSI/EIA 632 Italic = obsolete Boxed = integrating *not released **based on CBA IPI, SAM, and others # V2 also based on many others supersedes See based on uses/references Fig. 6. The Frameworks Quagmire in 2001 (Source: Sheard 2001). PSP TSP People CMM SA-CMM FAA-iCMM SE-CMM MIL-STD-1803 (1988) SW-CMM SCE ISO (SPICE) 2003 CMMI IPD-CMM* SDCCR SDCE SECM EIA/IS 731 DoD IPPD MIL-STD-1679 MIL-Q-9858A (1983) (1963) DOD-STD-2168 (1988) IEEE Stds -730, -828, -829, -830, -1012, -1016, -1028, -1058, NATO AQAP 1, 4, 9 DOD-STD-2167A (1988) DOD-STD-7935A EQA (1988) MIL-STD-498 DOD-STD-1703 Trillium Baldrige (1994) BS 5750 (1987) EIA/IEEE DO-178B ISO/IEC J-STD-016 (1995) SECAM SSE-CMM IEEE 1220 MIL-STD-499 (1998) EIA/IS 632 (1967) MIL-STD-499B* (1994) MIL-STD-499A (1974) AF IPD Guide TickIT (1993) Q9000 ISO EIA 632* Green - US DoD: MIL, DOD, AF Red - CMU-SEI: CMM, CMMI Purple - International: ISO, IEC, EC, UK Blue - US Industry: IEEE * Not yet released ISO 9000 Series IEEE 1074 (1997) ISO 15288* IEEE/EIA 12207* After: Sarah Sheard, SPC, 1997, Qua gmire is copyr ight Software Productivi ty Consor tium (SPC) Fig. 7. The Frameworks Quagmire after CMMI (Source: modified after SPC 1997).

12 82 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) CMMI-DEV PSP TSP CMMI-ACQ MIL-Q-9858A MIL-STD-1679 CMMI CMMI-SVC (1983) (1963) DOD-STD-2168 People (1988) CMM IEEE Stds -730, -828, -829, -830, -1012, -1016, -1028, NATO DOD-STD-2167A SA-CMM (1988) -1058, AQAP 1, 4, 9 ISO DOD-STD-7935A (SPICE) EQA (1988) 2003 FAA-iCMM MIL-STD-498 DOD-STD-1703 (1984) Trillium Baldrige (1987) BS 5750 (CAN) (US) SSE-CMM DO-178B ISO/IEC EIA/IEEE J-STD-016 (1995) IEEE 1220 TickIT (1998) Q9000 MIL-STD-499 EIA/IS 632 ISO (1967) MIL-STD-499B* (1994) EIA 632 (1999) MIL-STD-499A MIL-STD-499C* (1974) (Draft 2005) Green - US DoD: MIL, DOD, AF Red - CMU-SEI: CMM, CMMI Purple - International: ISO, IEC Blue - US Industry: IEEE * Not yet released ISO 9000 IEEE 1074 Series (1994) IEEE/EIA ISO (1998) (2002) ISO/IEEE ISO/IEEE (2008) (2008) After: Sarah Sheard, SPC, Quagmire is copyright Software Productivity Consortium (SPC) Fig. 8. The Frameworks Quagmire Now (Source: modified after SPC 1997). 6. Conclusions This paper provides an overview of the evolution of systems engineering standards and guidelines, process models, and compliance assessment models from past to present. The evolution of systems engineering required tremendous efforts on the part of many professional societies, enterprises, and academia. The impact that systems engineering has had on academia, government, and industry is immeasurable. It is important to note that: Systems engineering is a methodology that, by definition, assists enterprise personnel to produce an end product that meets customer needs. Systems engineering does this by helping the producer organize related processes, methods, and tools. Indeed, a methodology is primarily created by accumulating the experience of failures or overruns encountered in previous projects. Implementation of systems engineering process defined in standards does not necessarily ensure a successful project; however, it can help mitigate the risks associated with the project. Systems engineering was developed to manage the acquisition of highly complex high-end systems such as those utilized in the military, space, and software development fields, of which the government was the primary customer during early development. Various standards such as ANSI/EIA 632 and ISO/IEC have been extended to enable enterprise to strengthen its competitiveness in global markets by engineering and producing quality systems and by delivering products on time and

13 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) at an affordable cost. Systems engineering has become a discipline required for every enterprise s personnel working in technical or programmatic fields. Systems engineering has value and application well beyond the bounds of traditional engineering. Due to the different implications and objectives for each project, no single systems engineering approach or capability assessment model can be applied to all cases. It is extremely important to remember that, when implementing the systems engineering processes, it must be properly tailored to the scope and level of the job at hand. References ANSI/EIA-632, 1999, Process for Engineering a System. Electronic Industry Association. Bahill, A. T., Gissing, B., Re-evaluating systems engineering concepts using systems thinking. IEEE Transaction on Systems, Man and Cybernetics, Part C: Applications and Reviews 28, Blanchard, B. S., Fabrycky, W. J., Systems Engineering and Analysis, 4 ed. Prentice-Hall International, London. Boehm, B. W., A spiral model of software development and enhancement. Computer and Electronics in Agriculture 21, CMMI for Services, Initial Draft. Software Engineering Institute (SEI). Carnegie Mellon University, USA. CMU/SEI-95-MM-003, 1995a. A Systems Engineering Capability Maturity Model. (SE-CMM Ver. 1.1). Software Engineering Institute (SEI). Carnegie Mellon University, USA. CMU/SEI-95-MM-003, 1995b. A Systems Engineering Capability Maturity Model. (SE-CMM Ver. 1.1). Software Engineering Institute, Carnegie Mellon University, USA. CMU/SEI-2002-TR-001, 2001a. Capability Maturity Model Integration for Systems Engineering and Software Engineering. (CMMI-SE/SW Ver. 1.1), Continuous Representation. Software Engineering Institute, Carnegie Mellon University, USA. CMU/SEI-2002-TR-002, 2001b. Capability Maturity Model Integration for Systems Engineering and Software Engineering (CMMI-SE/SW Ver. 1.1), Staged Representation. Software Engineering Institute, Carnegie Mellon University, USA. CMU/SEI-2002-TR-003, 2001c. Capability Maturity Model Integration for Systems Engineering, Software Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD Ver. 1.1), Continuous Representation. Software Engineering Institute, Carnegie Mellon University, USA. CMU/SEI-2002-TR-004, 2001d. Capability Maturity Model Integration for Systems Engineering, Software Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD Ver. 1.1). Staged Representation. Software Engineering Institute, Carnegie Mellon University, USA. CMU/SEI-2002-TR-011, 2002a. Capability Maturity Model Integration for Systems Engineering, Software Engineering, Integrated Product and Process Development and Supplier Sourcing (CMMI- SE/SW/IPPD/SS Ver. 1.1), Continuous Representation. Software Engineering Institute. Carnegie Mellon University, U.S.A. CMU/SEI-2002-TR-012, 2002b. Capability Maturity Model Integration for Systems Engineering, Software Engineering, Integrated Product and Process Development and Supplier Sourcing (CMMI- SE/SW/IPPD/SS Ver. 1.1), Staged Representation. Software Engineering Institute, Carnegie Mellon University, USA.

14 84 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) CMU/SEI-2002-TR-028, 2002c. Capability Maturity Model Integration for Software (CMMI-SW Ver. 1.1), Continuous Representation. Software Engineering Institute, Carnegie Mellon University, USA. CMU/SEI-2002-TR-029, 2002d. Capability Maturity Model Integration for Software (CMMI-SW Ver. 1.1), Staged Representation. Software Engineering Institute. Carnegie Mellon University, USA. CMU/SEI-2006-TR-008, Capability Maturity Model Integration for Development (CMMI-Dev Ver. 1.2), Software Engineering Institute. Carnegie Mellon University, USA. CMU/SEI-2007-TR-017, CMMI for Acquisition Ver Software Engineering Institute, Carnegie Mellon University, USA. DSMC, Systems Engineering Management Guide. Defense Systems Management College, Department of Defence. DSMC, Systems Engineering Fundamentals. Defense System Management College, Department of Defence. ECSS-E-10A, Space Engineering- Systems Engineering. European Space Agency. EIA/IS 632, Systems Engineering, Interim Standard. Electronics Industry Association. EIA/IS 731.1, Systems Engineering Capability Model, Electronic Industry Association (EIA). EIA/IS 731.2, Systems Engineering Capability Model Appraisal Method, Electronic Industry Association (EIA). FAA-iCMM, The Federal Aviation Administration Integrated Capability Maturity Model, Ver. 1.0: An Integrated Capability Maturity Model for the Acquisition of Software Intensive Systems. Federal Aviation Administration. Forsberg, K., Mooz, H., The relationship of systems engineering to the project cycle. Engineering Management Journal 4, Forsberg, K., Mooz, H., Application of the Vee to incremental and evolutionary development. In: Proceedings of the Fifth Annual International Symposium of the National Council on Systems Engineering, St. Louis, MO., USA. Global Intergy Corporation, 2002e. Systems Engineering Process Review Report, Ver. 2. IEEE 1220, IEEE Standard for Application and Management of the Systems Engineering Process. IEEE Computer Society. INCOSE Website, A consensus of the INCOSE fellows. On-line available at ISO/IEC 12207, Systems and Software Engineering - Software Life Cycle Processes. International Organization for Standardization. ISO/IEC 15288, Systems and Software Engineering - System Life Cycle Processes. International Organization for Standardization. Martin, J. N., Overview of the EIA 632 standard: processes for engineering a system. In: Digital Avionics System Conference, Seattle, Washington, USA, October 31- November 6, 1998, B MIL-STD-499, Engineering Management. U.S. Department of Defense. MIL-STD-499A, Engineering Management. U.S. Department of Defense. MSFC-HDBK-1912A, Systems Engineering Handbook. NASA/Marshall Space Flight Center. NASA-SP-6105, 1995c. Systems Engineering Handbook. NASA. Perry, W. J., Specification and Standards a New Way of Doing Business. Memorandum from the Secretary of Defense to various military departments. Washington DC. Royce, W. W., Managing the development of large software systems. Proceedings of IEEE WESCON 26, 1-9. Sheard, S. A., The Frameworks Quagmire, A Brief Look. In: Proceedings of INCOSE.

15 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) Sheard, S. A., Evolution of the Frameworks Quagmire. Computer and Electronics in Agriculture 34, Valerdi, R., Marilee, W., ANSI/EIA 632 as a standardized WBS for COSYSMO. In: AIAA 5th Aviation Technology, Integration, and Operations Conference (ATIO), Hyatt Regency Crystal City, Arlington, Virginia, USA, September 26-28, 2005, Paper No. AIAA