267
Integration in Systems Engineering Context
process models dominate the work, many adapted to the particulars of the
project or as an accommodation of the business enterprise. All have a highlevel graphical presentation that defines the organization of processes. All
relate that organization to milestones, progress reviews, and decision
points. All imply coordination, process architecture, requirements management, and goals and objectives. Some process models are designed to
work with particular standards, while some standards help to orchestrate
process models. There are literally dozens of process models and many hundreds of references (IEEE 1220-1998 1998; Martin 1998; ANSI/IEEE 2000; Sage
and Rouse 1999; Sheard 2001; ISO/IEC-15288 2002; INCOSE 2010), including a
systems integration process model (Jain et al. 2010). All these models can be
adapted to virtually any project given enough understanding of the relations
and time to communicate both the intentions and the methods that will be
used for all stakeholders.*
Scalable Process Models
The effectiveness of a process model is at worst dependent on a preference
for one model over another and at best based on the circumstances surrounding the project. While the process model must be tailored to the needs
of the acquirer (e.g., in their reporting to others, in their review of the work,
in their perception of risk, and in their decision to continue support) and
must also be matched to the skills of the project team, the process model
should always serve to improve and facilitate the problem solving and decision making, rather than in itself become the problem that must be worked
around. Assuming that the needs of the acquirer and the project team are
met, success with the chosen systems engineering process model depends
on satisfying two conditions. First and foremost, the resources needed to
succeed with the project must be available at the start of the project (GAO
2001). Second and nearly equal, the process model must be scalable. The
meaning of scalable for process models is the relation between the time it
takes to complete the project using the systems engineering process model
and the size of the problem that is to be solved (given that the two conditions are satisfied). If the requirements are known in detail and the only
derived requirements are those that expound on the detail provided by the
acquirer, then a process model that begins with certainty (e.g., the iterative
waterfall model and like-kind kin † ) will provide varying degrees of success). All waterfall derivatives are scalable. The more requirements are
detailed up front, the more definite the outcome of development. The characteristic of scalability that is important for systems engineering is the capability to cope and perform under changing requirements. Requirements that
* Stakeholders include the project staff.
† Example derivatives of the waterfall process model include the spiral and the vee process
models.
Integration in Systems Engineering Context
process models dominate the work, many adapted to the particulars of the
project or as an accommodation of the business enterprise. All have a highlevel graphical presentation that defines the organization of processes. All
relate that organization to milestones, progress reviews, and decision
points. All imply coordination, process architecture, requirements management, and goals and objectives. Some process models are designed to
work with particular standards, while some standards help to orchestrate
process models. There are literally dozens of process models and many hundreds of references (IEEE 1220-1998 1998; Martin 1998; ANSI/IEEE 2000; Sage
and Rouse 1999; Sheard 2001; ISO/IEC-15288 2002; INCOSE 2010), including a
systems integration process model (Jain et al. 2010). All these models can be
adapted to virtually any project given enough understanding of the relations
and time to communicate both the intentions and the methods that will be
used for all stakeholders.*
Scalable Process Models
The effectiveness of a process model is at worst dependent on a preference
for one model over another and at best based on the circumstances surrounding the project. While the process model must be tailored to the needs
of the acquirer (e.g., in their reporting to others, in their review of the work,
in their perception of risk, and in their decision to continue support) and
must also be matched to the skills of the project team, the process model
should always serve to improve and facilitate the problem solving and decision making, rather than in itself become the problem that must be worked
around. Assuming that the needs of the acquirer and the project team are
met, success with the chosen systems engineering process model depends
on satisfying two conditions. First and foremost, the resources needed to
succeed with the project must be available at the start of the project (GAO
2001). Second and nearly equal, the process model must be scalable. The
meaning of scalable for process models is the relation between the time it
takes to complete the project using the systems engineering process model
and the size of the problem that is to be solved (given that the two conditions are satisfied). If the requirements are known in detail and the only
derived requirements are those that expound on the detail provided by the
acquirer, then a process model that begins with certainty (e.g., the iterative
waterfall model and like-kind kin † ) will provide varying degrees of success). All waterfall derivatives are scalable. The more requirements are
detailed up front, the more definite the outcome of development. The characteristic of scalability that is important for systems engineering is the capability to cope and perform under changing requirements. Requirements that
* Stakeholders include the project staff.
† Example derivatives of the waterfall process model include the spiral and the vee process
models.