Read 98 SE Stds Models.doc text version

Systems Engineering Standards and Models Compared

Sarah A. Sheard Software Productivity Consortium 2214 Rock Hill Road, Herndon, VA 20170 (703) 742-7106; fax: (703) 742-7200 [email protected] Dr. Jerome (Jerry) G. Lake Systems Management international 281 So. Pickett Street #401 Alexandria, VA 22304 (703) 751-7987; fax: (703) 751-5189 [email protected]

MIL-STD 499B 1992 Draft EIA/IS 632 1994 IEEE 1220-1994 Trial Use SW-CMM ISO 15504* (SPICE) IPDCMM* SSECMM

* Not Yet Released Derived From Influenced By

Abstract. Currently there are five systems engineering standards in various stages of release and three systems engineering capability models. This makes it difficult to know what to use as a basis for process improvement. This paper discusses the similarities and differences among the standards and models. The standards have been evolving from the U.S. Military to international and commercial, with recent standards taking a broader scope. Two capability maturity models have been merged into a third, which is tied to the standards.

SECAM IEEE (1.5) 1996 EIA 632* 1220* 1998? 1998?

SE-CMM (1.1) 1995


In the last 5 years, five systems engineering standards and three systems engineering capability models have been published or begun. It is difficult for a systems engineering practitioner to stay current with the various models, understanding what is current, how it differs from others, and when and why each version ought to be used. A 1997 INCOSE symposium tutorial included a module that addressed the similarities and differences [Sheard 1997a]. This paper updates that material.

ISO/IEC 15288* 2000?

SECM EIA/IS 731 1998?

Figure 1. SE Standards and Models History MIL-STD-499B [MIL-STD-499B 1992] was distributed to reviewers. This would have updated and significantly rewritten MIL-STD-499A, Engineering Management, and the name would have become Systems Engineering. However, industry lacked consensus about what ought to be included in a standard on systems engineering, which delayed approval, and there was a change of administrations in the Pentagon. In June 1994, a Department of Defense initiative decreed the end of military standards other than performance specifications, thereby guaranteeing that MILSTD-499B would never be released as such. At the request of a new Director for Systems Engineering within the Office of Secretary for Defense (OSD), an Electronic Industries Alliance (EIA)2 working group composed of representatives from the Aircraft Industry Asferred to as IEEE P1220 (R) D1.1, 27 January 1998. These two standards are expected to be very similar. They are treated as one standard, called IEEE 1220, for the purpose of this paper. The EIA and the Institute of Electrical and Electronics Engineers (IEEE ) are two bodies approved to set standards by the United States' official standards-setting body, the American National Standards Institute (ANSI).


The Frameworks Quagmire [Sheard 1997b] excerpt shown in Figure 1 clearly indicates that confusion over systems engineering (SE) standards and models is likely. Various standards and models have been released that build on each other and on other available standards and models, particularly those in the software world. Some have been heavily publicized but not released (MIL-STD-499B and more recently, EIA 632) and others have been less well known but released and endorsed by INCOSE (such as [SECAM 1996]). MIL-STD-499B, EIA/IS 632, IEEE 12201. In May of 1992, a "Coordination Copy" of the proposed



The released version of IEEE 1220 is also referred to as IEEE 1220-1994. This is a "Trial-Use" standard. This is being updated in 1998, with the most recent version re-

sociation, Department of Defense, National Security Industries Association, EIA, Institute of Electrical and Electronics Engineers (IEEE), and INCOSE released in December 1994 a "commercialized" version of MILSTD-499B as EIA Interim Standard (IS) 632, [EIA/IS 632 1994]. This was done with the understanding that considerably more industry input would go into a replacement version, to be called EIA 632. In parallel, the IEEE also released in February 1995 a commercial "Trial-Use" standard IEEE 1220-1994 [IEEE 12201994 1995]. IEEE 1220-1994 states that it will be merged with EIA/IS 632 into a single American National Standards Institute (ANSI) standard on systems engineering to be jointly published by the EIA, IEEE, and INCOSE.3 EIA 632 and ISO 15288. A ballot version of the new EIA 632 was made available to reviewers in August 1997. Comments were submitted, and the EIA Technical Committee is expected to complete the work on the revision with the expectation of a summer 1998 publication. One of the intents of the revision is to use EIA 632 as an early U.S. implementation of processes for engineering a system that are expected to be covered in the evolving ISO standard 15288. [Martin 1998a] and [Martin 1998b] describe the new standard and how it has evolved from the interim standard. The ISO standard for system life cycle processes, ISO 152884, is being coordinated by the same international committee that created the software life cycle processes standard, ISO 12207. Working Draft #2 was released for national body review in January 1998. A first committee draft is anticipated as early as October 1998 with publication of the International Standard as early as December 1999. SECAM. INCOSE sponsored a working group that began in 1992 to address the assessment of systems engineering capability. This Capability Assessment Working Group (CAWG) delivered several incremental products. The most recent Version 1.5 of the Systems Engineering Capability Assessment Model [SECAM 1996] was released in July of 1996. Several large corporations have found this model helpful in improving their systems engineering work. SE-CMM. Meanwhile, in December 1993, a group spun off from the INCOSE SECAM working group. This group included eight organizations who agreed to provide full-time authors for a systems engineering capability maturity model [SE-CMM 1995] to be released in one year's time.

This group, later called EPIC (for Enterprise Process Improvement Collaboration), used the Software Engineering Institute (SEI) of Carnegie Mellon University for project management and administrative support. Thus, EPIC products were released as SEI documents. Version 1.0 of the SE-CMM was released in December 1994, and an associated appraisal method was released in March 1995. Version 1.1 of both were released in February and June 1996, respectively. Unfortunately, this meant there were now two systems engineering models on the market. On the one hand, the SE-CMM had the SEI's Software CMM [SWCMM 1993] legacy in its favor. Other organizations took an opposite approach: some INCOSE members believed that anyone with a first name of "Software" should not be speaking for systems engineering. To say there was disagreement in the field is an understatement. SECM (EIA/IS 731). INCOSE's Corporate Advisory Board, and the Director for Systems Engineering in OSD, agreed that the two models had to come together. EPIC and INCOSE agreed to work toward a merged model, eventually called the Systems Engineering Capability Model, and given the number EIA/IS 731, since the EIA sponsored and facilitated the merger effort. Monthly meetings took place over a period of years, and the initial review copy of the SECM was distributed at the 1997 INCOSE symposium. There is considerable overlap among the models' contents, so the technical merging of the two models turned out to be considerably easier than determining sponsorship, requirements, and the best architecture. In 1998, a new initiative was undertaken by a new organization formed by the Director of Systems Engineering in OSD. The group formed of industry and government representatives is looking at the common aspects of all the capability models, including Integrated Product Development, Software, and Systems Engineering. The outcome of this group's effort will have an impact on current models.


The following sections address first, what are the similarities and differences between standards and capability models in general, then, what are the similarities and differences among the five systems engineering standards and then, the three systems engineering capability models. Standard vs. Capability Model. Standards and Capability models both describe good systems engineering, but do so somewhat differently. While standards must go through a defined industry-approval process, in order to meet a nation's guidelines, such as those estab-

3 4

See Table 1 for a discussion of the outcome of this. Officially, ISO/IEC 15288.

lished by ANSI, capability models can be created by anyone with the resources. Other comparisons are shown below. What, not How. Both standards and capability models say what should be done, but try not to say how to do it. However, some interpret a "what" as a "how." Often it is a matter of perspective. Recent standards and capability models have both attempted to avoid the problem by focusing on processes and their related activities and tasks or requirements (the "whats"), not on methods and tools (the "hows"). Purpose. Capability models provide a way to evaluate an enterprise's or project's systems engineering capability. They provide a multi-point scale, in each of these cases containing six levels, showing a road map along which an organization's process improvement effort can progress. U.S. military standards originally supported contracts, to aid the government in delivery of quality products or to ensure utilization of consistent processes by contractors. In general, commercial standards are not imposed on contracts. In the case of commercial systems engineering standards (EIA 632 or IEEE 1220), use by an enterprise is ordinarily voluntary, as is imposing a standard on a supplier as a basis for competition or performance. Capability models theoretically are also voluntary, though certainly with the SW-CMM it is evident that the practices called out by a capability model have been imposed. U.S. government contracting for software has in some cases imposed a requirement that contractors demonstrate a minimum of Level 2 or Level 3 ranking in the SW-CMM. Life Cycle. Standards may prescribe a life cycle (although most specify theirs as "typical" or "example" life cycles). In general, models do not. They are intended to apply to any system life cycle. A discussion on the INCOSE list server about life cycles led to two observations: 1) that many people are sure that they know the one correct life cycle, and 2) that these people differ on what that life cycle is. It varies not only by industry (those making nuclear submarines naturally have a different time-based life cycle than those making cellular telephones), but also by whether the person speaking is a customer (an acquisition life cycle), a contractor (a development life cycle), or even a user (a maintenance life cycle) [Lake 1997].

Given these variations, it is probably a good thing that the capability models are meant to be used with any life cycle. However, it is probably also a good thing that standards define the life cycles they are assuming. Otherwise, the "things to do" are without a context. Number of Elements. Most standards have fewer than ten process elements, but the systems engineering capability models have 18 or 19. MIL-STD-499B and (EIA/IS 632) show four interrelated process steps, including Requirements Analysis, Functional Analysis, and Synthesis, all tied to System Analysis and Control (Balance). This last step includes processes such as trade studies, interface and risk management, and configuration and data management. IEEE 1220 separates Analysis, which is tied to all other process steps, from Control, which it considers to be one of the process steps. EIA 632 (see Figure 2, from the January 1998 version) discusses not one "Systems Engineering Process," but thirteen processes, in five interrelated groupings: Acquisition and Supply (two processes), Technical Management (three processes), System Design (two processes), Product Realization (two processes), and Technical Support (four processes). These processes are intended to be implemented by a single developer during any phase of a system's life cycle, as applicable.

Technical Management Planning Process

Plans Status Products Agreement

Assessment Process

Plans Directives

Control Process


Acquisition Request

Acquisition & Supply Supply Process Acquisition Process


Solution Definition Process

Transition To Use Process

Technical Support System Analysis Process Requirements Validation Process Product Verification Process Product Validation Process

Figure 2. The Processes of EIA 632 Like EIA 632, the capability models separate out the pieces of System Analysis and Control as process elements, and place Control in a "project" or "management" category (see Table 1). Capability models also add a third set of elements, those which establish organizational support for systems engineering, such as training, process management, and tool support. These are included in the Application Context clause of EIA 632.

System Products

System Design Requirements Definition Process

Product Realization Implementation Process

Table 1. Comparison of Process, Focus, and Key Focus Areas in the Three SE Capability Models SE-CMM (PAs)

PA06 PA02 PA03 PA01 PA05 PA07 PA04 PA12 PA11

SECM(EIA/IS 731) (FAs)


System Concept Definition Requirements and Functional Analysis System Design Integrated Engineering Analysis System Integration System Verification System Validation (see 1.4 below) Planning Tracking and Oversight Intergroup Coordination Subcontract Management Risk Management Data Management Configuration Management Quality Management Process Management and Improvement Competency Development Technology Management Environment and Tool Support (see 1.3 above)

PA10 PA09 PA08 PA13 PA14 PA17 PA15 PA16 PA18

Engineering, Technical, or Systems Engineering Areas Understand Customer Needs 1.1 Define Stakeholder and System 3.1 and Expectations Level Requirements Derive and Allocate Require1.2 Define Technical Requirements 3.2 ments Evolve System Architecture 1.3 Define Solution 3.3 Analyze Candidate Solutions 1.4 Assess and Select 3.4 Integrate System 1.5 Integrate System 3.5 Verify and Validate System 1.6 Verify System 3.6 1.7 Validate System 3.7 Integrate Disciplines (see 2.3 below) Project or Management Areas Plan Technical Effort 2.1 Plan and Organize 1.1 Monitor and Control Technical 2.2 Monitor and Control 1.2 Effort (PA04 above) 2.3 Integrate Disciplines 1.4 (PA18 below) 2.4 Coordinate with Suppliers 1.3 Manage Risk 2.5 Manage Risk 1.7 (none) 2.6 Manage Data 1.8 Manage Configurations 2.7 Manage Configurations 1.5 Ensure Quality 2.8 Ensure Quality 1.6 Organization or Environment Areas Define Organization's SE Proc3.1 Define and Improve the Systems 2.1 ess Engineering Process Improve Organization's SE Process Provide Ongoing Knowledge 3.2 Manage Competency 2.2 and Skills Manage Product Line Evolution 3.3 Manage Technology 2.3 Manage Systems Engineering 3.4 Manage Systems Engineering 2.4 Support Environment Support Environment Coordinate With Suppliers (see 2.4 above)

Is EIA/IS 731 a standard or a model? In EIA/IS 731, the distinction between standards and models blurs. This is the SECM, a capability model that has been submitted as a standard. Fortunately, it is a model heavily tied to the existing standards, notably EIA 632, but also IEEE 1220. Thus, the release of EIA 632 and EIA/IS 731 is the first time two consistent standards have been in operation, one for "What to do in engineering systems" (632) and one for "How to measure and improve your systems engineering capability" (731). Similarities and differences among SE standards. The similarities among standards are summarized in Table 2, the differences in Table 3. What is a systems engineering standard? Some authors of EIA 632 and ISO 15288 do not consider these to be "systems engineering standards" at all. Neither one uses the term "systems engineering."

Table 2. SE Standards Commonalities

Common Authors: John Kordik (1,2) Blake Andrews (7,8) Ken Ptack (3a,5) Don Barber (7,8) Richard Schmidt (3a,3b,5) Curt Wells (6,8) Jerry Lake (1,2,3a,3b,4,5) Rich Widman (7,8) Jim Armstrong (3a), (3b), (8) (1) MIL-STD-499B, (2) EIA/IS 632, (3a) IEEE 1220-1994, (3b) IEEE 1220, (4) EIA632, (5) ISO 15288, (6) SE-CMM, (7) SECAM, (8) SECM History: Figure 1 illustrates the interrelationships of the standards. Standards and capability models have been influenced by prior ones. Evolution: The systems engineering standards have evolved from a military-contract-centric approach to a commercial, voluntary-compliance approach. The focus has changed from a management to a process orientation. And, although the nature remained a total system approach, the name has changed from "systems engineering" to the "engineering of systems" to reflect that nature better.

Table 3. SE Standard Differences MIL-STD-499B

Defines total system approach for the development of defense systems. Specification on "the performing activity".

EIA/IS 632

Defines total system approach for the development of systems. Definition of what "the performing activity" does. This standard was the demilitarized version of MIL-STD-499B, which was never officially approved by, but used extensively by industry and the Air Force.

IEEE 1220 Scope of Standard

Defines the interdisciplinary tasks that are required throughout a system's life cycle to transform customer needs, requirements, and constraints into a system solution. Specifies the requirements for the systems engineering process and its application throughout the system's life cycle.

EIA 632

Defines thirteen processes and 34 requirements for engineering a system. The focus is on implementing the requirements of the standard within a defined engineering life cycle, which can be applied in any enterprise-based life cycle phase to engineer or reengineer a system.

ISO/IEC 15288

Will address both system engineering and management (business) processes. The focus is on the "system" versus the "components," where component standards like ISO/IEC 12207 Software Life Cycle Processes will apply.

Level of Abstraction

Medium level of abstraction -- Activity level Same as 499B More detailed than 499B - Detailed Task level Higher level of abstraction than previous standards, less than 15288. Highest level of abstraction.

System Life Cycle

Example: · Pre-Concept · Concept Exploration and Definition · Demonstration and Validation · Engineering and Manufacturing Development · Production and Deployment · Operations and Support 2-page section on SEMP in the Detailed Requirements section and a template in Appendix B. Appendix on guidance for developing a SE Master Schedule. Example: · Market Requirements · Concept Definition and Feasibility · Concept Validation · Design and Verification · Production and Deployment · Operations and Support Typical: · System Definition · Subsystem Definition · Preliminary Design · Detailed Design · Fabrication, Assembly, Integration, and Test · Production · Customer Support Enterprise-Based: · Assessment of Opportunities · Solicitation and Contract Award · System Concept Development · Subsystem Design and Pre-Deployment · Deployment/ Installation and Operations and Support Life Cycle Processes: · Concept Process · Development Process · Production Process · Operations Process · Support Process · Decommissioning or Disposal Process

SEMP Guidance

2-page section on SEMP in the Detailed Requirements section and an 8 page template in Appendix B. Appendix on guidance for developing a SE Master Schedule. Ten-page "informative" Annex gives SEMP template. One requirement calls for the creation of an engineering plan. The expected outcomes (or expected content) of this plan is provided in Annex C. Will not be a specific engineering plan, more than likely. But, planning the system life cycle and application of the generic processes will likely be required.

In the case of EIA 632, this was because the author group could not come to consensus on what systems engineering was, in order to create a standard for it. But they did detect a need for a standard on how to create systems, and were able to come to consensus on the content. If an organization chooses to use something called "systems engineering" in performing the processes in EIA 632, that is acceptable, but it is not required. Similarly, ISO 15288 is not a systems engineering standard. In this case, the scope is really higher than a systems engineering organization would encompass, and higher even than an engineering organization's

normal scope, although the standard is written from an engineering view (rather than, say, a "contracts" view). A systems engineering standard might be invoked at a lower level, as would software or hardware standards. Nevertheless, these two standards were considered in this paper, precisely because of all the confusion. Focus. Standards vary in their focus in a way that mirrors the change in industry outlook. MIL-STD-499B was clearly focused on a single military procurement and a contractual agreement between contractor and acquirer. EIA/IS 632 focused on systems and products in general, and IEEE 1220 added focus on the enterprise (larger organization) as well. EIA 632 has an enterprise

context for the application of processes on whatever system it is that one is engineering when one uses EIA 632. ISO 15288 is likely to take the same approach as its software predecessor ISO/IEC 12207, where the focus is on a set of generic processes applied as appropriate to accomplish the purposes of any one of the phases of a system's life cycle. Definitions. Table 4 shows the different definitions of system and systems engineering in the standards and models. The definitions show that the standards are addressing somewhat different problems. Phraseology. MIL-STD-499B used "shall" to detail what the contractor was responsible for doing. When EIA/IS 632 was created from MIL-STD-499B, it kept most of the same content. Two overall changes were to replace the word "shall" with the present tense of the verb and to replace the term "contractor" with "performing activity." Thus, instead of saying, "the contractor shall develop items that are survivable," EIA/IS 632 says, "the performing activity identifies and defines requirements to ensure that items are survivable." This approach in EIA/IS 632 reduced the number of "shalls" to four. However, one of the "shall" statements called for a Systems Engineering Management Plan (SEMP) and referenced an annex which provided a comprehensive outline of the content. IEEE 1220 also uses the "performing activity" rather than contractor as the performer of standard requirements. EIA 632 uses the term "developer" for the performing activity. Similarities and Differences among SE Capability Models. Table 5 shows that the three capability models are similar in architecture and intent. Indeed, the content and scope of all three models are similar. Primary differences, shown in Table 6, are that the SE-CMM

considered all process area content (in that case, called base practices) to be necessary to reach Level 1, whereas the other two limited what was needed for Level 1 and added more practices at higher levels. The SECAM and SECM also included process effectiveness and product value considerations, where the SE-CMM did not. The SECM maturity scale specifies "generic attributes" which rate these non-process aspects. Finally, the SECM traces closely to the systems engineering standards. Table 5. SE Capability Models Commonality

Architecture: All three use the six-level SPICE architecture, including 18 or 19 process (or focus) areas on one axis, measured by Levels 0-5 capability on the other axis. What vs. How: All three models do not prescribe "how", just characteristics of good processes. Role: All three models do not prescribe "who" (Role independence) General Categories: All three models have separate categories for technical, management, and organizational elements. Life Cycle Considerations: None address logistics and operations very well. All three models address most other of the 12 systems engineering roles [Sheard 1996].

Elements of the Models. Table 1 shows that the Focus Areas (FAs) of the SECM are almost a 1:1 derivation from both the source models. SECM FAs 1.1, 1.2, and 1.3 changed emphasis in that the SECM kept all problem-domain ideas in 1.1 and 1.2, and all solution domain ideas in 1.3, whereas both source models mixed these somewhat. Content of other areas was shifted slightly, but in general all three models have nearly identical process content. Data Management is not present in SE-CMM.

Table 4. Definitions of System and Systems Engineering in SE Standards and Capability Models Standard or Model


Definition of System

An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.

Definition of Systems Engineering

An interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system people, product, and process solutions that satisfy customer needs. Systems engineering encompasses: a) the technical efforts related to the development, manufacturing, verification, deployment, operations, support, disposal of, and user training for, system products and processes; b) the definition and management of the system configuration; c) the translation of the system definition into work breakdown structures; and d) development of information for management decision-making.

Table 4. (continued) Standard or Model

EIA/IS 632 IEEE 1220

Definition of System

Same as MIL-STD -499B The top element of the system architecture, specification tree, or systems breakdown structure that is comprised of one or more products and associated life cycle processes and their products and services. The aggregation of end products and enabling products that achieves a given purpose. An integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. (ISO 12207 definition adopted for ISO 15288) An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective. (MIL-STD-499B definition)

Definition of Systems Engineering

Same as MIL-STD-499B An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability.

EIA 632

None--the term is not used or referred to in the standard.

ISO 15288

None--the term is not used or referred to in the standard.


Systems engineering is the selective application of scientific and engineering efforts to · Transform an operational need into a description of the system configuration which best satisfies the operational need according to the measures of effectiveness, · Integrate related technical parameters and ensure compatibility of all physical, functional, and technical program interfaces in a manner which optimizes the total system definition and design, · Integrate the efforts of all engineering disciplines and specialties into the total engineering effort. An interdisciplinary approach and means to enable the realization of successful systems.


The aggregation of end products and enabling products that achieves a given purpose. A set of interrelated components working together to accomplish a common purpose (CAWG). An interacting combination of elements viewed in relation to function (INCOSE).

An interdisciplinary approach and means to enable the realization of successful systems.

Table 6. Capability Model Differences Attribute

Focus Smallest elements Level of elements Integer ratings? Generic practices


Process only Practices All practices at Level 1 Yes Generic practices apply to all Process Areas Influenced by


Process, plus process effectiveness and product value Practices Basic practices at Level 1 Advanced practices at Levels 2-5 Not clear in draft of model Generic practices apply to all Focus Areas. Two Generic Attributes apply to non-process characteristics. Influenced by, and more explicitly tied to


Process, plus process effectiveness and product value Questions Questions at all levels No Generic questions tailored for each Key Focus Area Influenced by

Tie to standards


Although the systems engineering and capability models arena currently looks complicated, there is good news. Two models have been merged into a third, which is likely to replace the others and is similar enough to both that transition should be relatively easy. This paper discusses the similarities and differences among the standards and models. The comparison should help individuals and organizations doing systems engineering to understand which standards and models are current and which are likely to be most useful in the future. The working groups of INCOSE can use the information in this paper for identifying potential new efforts such as preparing guides and handbooks to implement the processes of the standards, or preparing models to fill the gaps identified.

Model for Software, Version 1.1, Software Engineering Institute, February 1993.


Sarah A. Sheard has eighteen years experience in systems engineering, including hardware systems (satellites) and software systems such as air traffic control. Currently, as a systems engineer at the Software Productivity Consortium, Ms. Sheard helps companies start systems engineering process improvement efforts and integrate software and systems engineering work and process improvement efforts. Ms. Sheard was on the original author team for the SE-CMM model and served as an author of EIA 731 for half a year. Ms. Sheard is an author of the FAA-iCMM, an integrated CMM merging the Software CMM, the Systems Engineering CMM, and the Software Acquisition CMM for the FAA. Ms. Sheard received a B.A. in Chemistry from the University of Rochester and an M.S. from the California Institute of Technology. Dr. Jerome G. Lake is the co-founder and chief scientist of Systems Management international (SMi), a consulting and training company. Dr. Lake is one of the founders of INCOSE and has served on the board of directors for seven years as the first president and director-at-large. He received the Founders Award in 1996. Dr. Lake is an aerospace engineer by degree. His former positions include: pilot and R&D manager in the U.s. Air Force; industry consultant/project manager for cruise missile testing; dean at two business schools; director of technology and engineering management at the University of Maryland, and faculty member at the Defense Systems Management College. Dr. Lake represents INCOSE as a technical expert for the ISO 15288 effort.


EIA/IS 632, Interim Standard: Systems Engineering. 1994. Electronic Industries Alliance, December 1994. IEEE 1220-1994. IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process, IEEE Computer Society, Institute of Electrical and Electronics Engineers, February 28, 1995. Lake 97: "Thoughts about Life Cycle Phases: How a System is Developed Incrementally," Dr. Jerome G. Lake, Proceedings of INCOSE, 1997. Martin, James N. "Evolution of EIA 632 from an Interim Standard to a Full Standard," Proceedings of INCOSE, 1998. Martin, James N. "Overview of EIA 632: Processes for Engineering a System," Proceedings of INCOSE, 1998. MIL-STD-499B, Draft Military Standard: Systems Engineering. HQ/AFSC/ EN, Department of Defense, "For Coordination Review" draft, May 6, 1992. Quagmire: Web site at SECAM: Systems Engineering Capability Assessment Model (version 1.50), INCOSE, June 1996. SE-CMM: Bate, Roger, et. al., Systems Engineering Capability Maturity Model (version 1.1), Software Engineering Institute, Carnegie Mellon University, November 1995. Sheard, Sarah A. "Twelve Systems Engineering Roles," Proceedings of INCOSE, 1996. Sheard, Sarah A. "Navigating the Compliance Frameworks Quagmire," Tutorial, INCOSE 1997a. Sheard, Sarah A. "The Frameworks Quagmire, A Brief Look," Proceedings of INCOSE, 1997b. SW-CMM: Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. Capability Maturity


98 SE Stds Models.doc

8 pages

Find more like this

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate


You might also be interested in

Microsoft Word - Module 5 DoDAF 2.0 Viewpoints and Models.docx
Enterprise Architect 9.3 Reviewer's Guide