Difference between pages "Integration of Process and Product Models" and "System Implementation"

From SEBoK
(Difference between pages)
Jump to: navigation, search
(Tech and grammar edits as discussed with Bkcase)
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
When performing systems engineering activities, it is important to consider the mutual relationship between processes and the desired system. The type of system (see [[Types of Systems]]) being produced will affect the needed processes, as indicated in [[System Life Cycle Process Drivers and Choices|system life cycle process drivers and choices]].  This may cause the {{Term|Tailoring (glossary)|tailoring}} of defined processes as described in [[Application of Systems Engineering Standards|application of systems engineering standards]].
+
{{Term|Implementation (glossary)|System Implementation}} uses the structure created during {{Term|Architecting (glossary)|architectural design}} and the results of [[System Analysis|system analysis]] to construct {{Term|System Element (glossary)|system elements}} that meet the {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}} and {{Term|System Requirement (glossary)|system requirements}} developed in the early {{Term|Life Cycle (glossary)|life cycle}} phases. These system elements are then integrated to form intermediate {{Term|Aggregate (glossary)|aggregates}} and finally the complete {{Term|System-of-Interest (glossary)|system-of-interest (SoI)}}. See [[System Integration]].  
  
==Process and Product Models==
+
==Definition and Purpose==  
Figure 1 of [[Life Cycle Models|life cycle models]] introduced the perspective of viewing stage work products provided by process execution as versions of a system-of-interest (SoI) at various life stages. The fundamental changes that take place during the life cycle of any man-made system include definition, production, and utilization. When building upon these, it is useful to consider the structure of a generic process and product life cycle stage model as portrayed in Figure 1 below.
+
Implementation is the process that actually yields the lowest-level system elements in the system hierarchy (system breakdown structure). System elements are made, bought, or reused. Production involves the hardware fabrication processes of forming, removing, joining, and finishing, the software realization processes of coding and testing, or the operational procedures development processes for operators' roles. If implementation involves a production process, a manufacturing system which uses the established technical and management processes may be required.
  
[[File:Generic_(T)_Stage_Structure_of_System_Life_Cycle_Models_(Lawson_2010,_Figure_6-2).png|frame|center|500px|'''Figure 1. Generic (T) Stage Structure of System Life Cycle (Lawson 2010).''' Reprinted with permission of Harold "Bud" Lawson. All other rights are reserved by the copyright owner.]]
+
The purpose of the implementation process is to design and create (or fabricate) a system element conforming to that element’s design properties and/or requirements. The element is constructed employing appropriate technologies and industry practices. This process bridges the [[System Definition|system definition]] processes and the integration process. Figure 1 portrays how the outputs of system definition relate to system implementation, which produces the implemented (system) elements required to produce aggregates and the SoI.
  
The (T) model indicates that a definition stage precedes a production stage where the implementation (acquisition, provisioning, or development) of two or more {{Term|System Element (glossary)|system elements}} has been accomplished. The system elements are integrated according to defined relationships into the SoI. Thus, both the process and product aspects are portrayed. The implementation and integration processes are followed in providing the primary stage results—namely, in assembled system product or service instances. However, as noted in [[Life Cycle Models|life cycle models]], the definition of the SoI when provided in a development stage can also be the result of first versions of the system. For example, a {{Term|Prototype (glossary)|prototype}}, which may be viewed as a form of production or pre-production stage. Following the production stage is a utilization stage. Further relevant stages can include support and retirement. Note that this model also displays the important distinction between definition versus implementation and integration.
+
[[File:SEBoKv05_KA-SystRealiz_how_outputs_of_Definition_relate_to_Implementation.png|thumb|600px|center|'''Figure 1. Simplification of How the Outputs of System Definition Relate to System Implementation, which Produces the System Elements Required to Produce Systems and Subsystems.''' (SEBoK Original)]]
  
According to [[ISO/IEC/IEEE 15288]] (2015), this structure is generic for any type of man-made SoI to undergo life cycle management. The production stage thus becomes the focal point of the (T) model at which system elements are implemented and integrated into system product or service instances based upon the definitions. For defined physical systems, this is the point at which product instances are manufactured and assembled (singularly or mass-produced). For non-physical systems, the implementation and integration processes are used in service preparation (establishment) prior to being instantiated to provide a service. For software systems, this is the point at which builds that combine software elements into versions, releases, or some other form of managed software product are produced.  
+
==Process Approach==
 +
===Purpose and Principle of the Approach===
 +
During the implementation process, engineers apply the design properties and/or requirements allocated to a system element to design and produce a detailed description. They then fabricate, code, or build each individual element using specified materials, processes, physical or logical arrangements, standards, technologies, and/or information flows outlined in detailed descriptions (drawings or other design documentation). A system element will be verified against the detailed description of properties and validated against its requirements.
  
Using {{Term|Recursion (glossary)|recursive decomposition}}, the implementation of each system element can involve the invocation of the standard again at the next lowest level, thus treating the system element as a SoI in its own right. A new life cycle structure is then utilized for the lower level SoIs.
+
If subsequent verification and validation (V&V) actions or configuration audits reveal discrepancies, recursive interactions occur, which includes predecessor activities or processes, as required, to mitigate those discrepancies and to modify, repair, or correct the system element in question. Figure 2 provides the context for the implementation process from the perspective of the U.S. Defense Acquisition University (DAU).  
 
This is illustrated in the Dual Vee model (Figures 2a and 2b). The Dual Vee model is a three-dimensional system development model that integrates product and process in the creation of the system and component architectures. It emphasizes
 
  
*concurrent opportunity and risk management;
+
[[File:JS_Figure_5.png|thumb|500px|center|'''Figure 2. Context Diagram for the Implementation Process (DAU 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]]
*user in-process {{Term|Validation (glossary)|validation}};
 
*{{Term|Integration (glossary)|integration}}, {{Term|Verification (glossary)|verification}}, and {{Term|Validation (glossary)|validation}} planning; and
 
*{{Term|Verification (glossary)|verification}} problem resolution.
 
  
When decomposition terminates according to the practical need and risk-benefit analysis, system elements are then implemented (acquired, provisioned, or developed) according to the type of element involved.
+
Such figures provide a useful overview of the {{Term|Systems Engineering (glossary)|systems engineering}} (SE) community’s perspectives on what is required for implementation and what the general results of implementation may be. These are further supported by the discussion of implementation inputs, outputs, and activities found in the National Aeronautics and Space Association's (NASA's) ''Systems Engineering Handbook'' (NASA 2007). It is important to understand that these views are process -oriented. While this is a useful model, examining implementation only in terms of process can be limiting.  
  
[[File:@@BKCASE_Wiki_Section_2.5_Fig_2a_PDF_110820.png|thumb|center|500px|'''Figure 2a. The Dual Vee Model (2a) (Forsberg, Mooz, Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
Depending on the technologies and systems chosen when a decision is made to produce a system element, the implementation process outcomes may generate constraints to be applied on the architecture of the higher-level system; those constraints are normally identified as derived system requirements and added to the set of system requirements applicable to this higher-level system. The architectural design has tomust take those constraints into account.
  
[[File:@@BKCASE_Wiki_Section_2.5_Fig_2b_PDF_110820.png|thumb|center|500px|'''Figure 2b. The Dual Vee Model (2b) (Forsberg, Mooz, Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
If the decision is made to purchase or reuse an existing system element, it has tomust be identified as a constraint or system requirement applicable to the architecture of the higher-level system. Conversely, the implementation process may involve some adaptation or adjustments to the system requirement in order to be integrated into a higher-level system or aggregate.  
  
A practical aspect that can impact the process and product aspect is the decision to use off-the-shelf elements in commercial-off-the-shelf (COTS) form. In this case, further decomposition of the element is not necessary. The use of COTS elements (and their internally created neighbor or non-development item (NDI)) has become widespread, and they have proven their value. However, developers must make sure that the COTS product is appropriate for their environment.  
+
Implementation also involves packaging, handling, and storage, depending on the concerned technologies and where or when the system requirement needs to be integrated into a higher-level aggregate. Developing the supporting documentation for a system requirement, such as the manuals for operation, maintenance, and/or installation, is also a part of the implementation process; these artifacts are utilized in the [[System Deployment and Use|system deployment and use]] phase. The system element requirements and the associated verification and validation criteria are inputs to this process; these inputs come from the {{Term|Architecting (glossary)|architectural design}} process detailed outputs.  
  
A known flaw which occurs infrequently in normal use of the product in its intended environment may be benign and easily dealt with. In a new situation, it could have dramatic adverse consequences, such as those that occurred on the USS Yorktown Cruiser in 1998 (Wired News Contributors 1998). The customer mandated that Windows NT be used as the primary operating system for the ship. A ''divide by zero'' fault caused the operating system to fail, and the ship was dead in the water. It had to be towed back to port on three occasions.
+
Execution of the implementation process is governed by both industrial and government standards and the terms of all applicable agreements. This may include conditions for packaging and storage, as well as preparation for use activities, such as operator training. In addition, packaging, handling, storage, and transportation (PHS&T) considerations will constrain the implementation activities. For more information, refer to the discussion of PHS&T in the [[System Deployment and Use]] article. The developing or integrating organization will likely have enterprise-level safety practices and guidelines that must also be considered.
  
Spiral models concurrently engineer not only process and product models, but also property and success models. Figure 3 shows how these models provide checks and balances, both at {{Term|Milestone (glossary)|milestone}} reviews and as individual model choices are made. Methods and tools supporting this concurrent engineering are provided in “When Models Collide: Lessons from Software System Analysis” (Boehm and Port 1999), “Avoiding the Software Model-Clash Spiderweb” (Boehm, Port, and Al-Said 2000), and “Detecting Model Clashes During Software Systems Development” (Al-Said 2003).
+
===Activities of the Process===
   
+
The following major activities and tasks are performed during this process:
[[File:Figure_3._Spiral_Model_support_for_Process_Models,_Product_Models....png|thumb|center|600px|'''Figure 3. Spiral Model Support for Process Models, Product Models, Success Models, Property Models (Boehm and Port 1999).''' Reprinted with permission of  © Copyright  IEEE – All rights reserved. All other rights are reserved by the copyright owner.]]
 
  
For software systems, entry into the production stages is the point at which builds that combine software elements (code modules) into versions, releases, or some other form of managed software product are created. Thus, the major difference between systems in general and software systems is the slight variant of the generic model as presented in Figure 4.
+
* '''Define the implementation strategy''' - Implementation process activities begin with detailed design and include developing an implementation strategy that defines fabrication and coding procedures, tools and equipment to be used, implementation tolerances, and the means and criteria for auditing configuration of resulting elements to the detailed design documentation. In the case of repeated system element implementations (such as for mass manufacturing or replacement elements), the implementation strategy is defined and refined to achieve consistent and repeatable element production; it is retained in the project decision database for future use. The implementation strategy contains the arrangements for packing, storing, and supplying the implemented element.
 +
* '''Realize the system element''' - Realize or adapt and produce the concerned system element using the implementation strategy items as defined above. Realization or adaptation is conducted with regard to standards that govern applicable safety, security, privacy, and environmental guidelines or legislation and the practices of the relevant implementation technology. This requires the fabrication of hardware elements, development of software elements, definition of training capabilities, drafting of training documentation, and the training of initial operators and maintainers.
 +
* '''Provide evidence of compliance''' - Record evidence that the system element meets its requirements and the associated verification and validation criteria as well as the legislation policy. This requires the conduction of peer reviews and unit testing, as well as inspection of operation and maintenance manuals. Acquire measured properties that characterize the implemented element (weight, capacities, effectiveness, level of performance, reliability, availability, etc.).
 +
* '''Package, store, and supply the implemented element''' - This should be defined in the implementation strategy.
  
[[File:T-Model_for_Software_System_(Lawson_2010,_Figure_6-3).png|frame|center|600px|'''Figure 4. T-Model for Software System (Lawson 2010).''' Reprinted with permission of Harold "Bud" Lawson. All other rights are reserved by the copyright owner.]]
+
===Artifacts and Ontology Elements===
 +
This process may create several artifacts such as:
 +
* an implemented system
 +
*implementation tools
 +
* implementation procedures
 +
* an implementation plan or strategy
 +
* verification reports
 +
* issue, anomaly, or trouble reports
 +
* change requests (about design)
  
==Stage Execution Order==
+
This process handles the ontology elements shown in Table 1 below.
  
A sequential execution of life cycle stages is the most straightforward. As presented in [[System Life Cycle Process Models: Vee]] and [[System Life Cycle Process Models: Iterative]], variants of the Vee model and the spiral model provide non-sequential models when practical considerations require a non-linear execution of life cycle stages. Building upon these two models, it is important to note that various types of complex systems require that the stages of the life cycle model be revisited as insight (knowledge) is gained, as well as when stakeholder requirements change. The iterations may involve necessary changes in the processes and in the product or service system. Thus, within the context of the (T) stage model, various orderings of stage execution - reflecting forms of non-sequential stage ordering - can be conveniently described, as portrayed in Figure 5.
+
{|
 
+
|+'''Table 1. Main Ontology Elements as Handled within System Element Implementation.''' (SEBoK Original)
[[File:Iteration_through_Life_Cycle_Stages_(Lawson_2010,_Figure_6-4).png|frame|center|700px|'''Figure 5. Iteration Through Life Cycle Stages (Lawson 2010).''' Reprinted with permission of Harold "Bud" Lawson. All other rights are reserved by the copyright owner.]]
+
!Element
 +
!Definition
 +
----
 +
Attributes (examples)
 +
|-
 +
|'''Implemented Element'''
 +
|An implemented element is a system element that has been implemented. In the case of hardware it is marked with a part/serial number.
 +
----
 +
Identifier, name, description, type (hardware, software application, software piece, mechanical part, electric art, electronic component, operator role, procedure, protocol, manual, etc.)
 +
|-
 +
|'''Measured Property'''
 +
|A measured property is a characteristic of the implemented element established after its implementation. The measured properties characterize the implemented system element when it is completely realized, verified, and validated. If the implemented element complies with a design property, the measured property should equal the design property. Otherwise one has tomust identify the difference or non-conformance which treatment could conclude to modify the design property and possibly the related requirements, or to modify (correct, repair) the implemented element, or to identify a deviation.
 +
----
 +
Identifier, name, description, type (effectiveness, availability, reliability, maintainability, weight, capacity, etc.), value, unit, etc.
 +
|}
  
Each pattern of stage execution involves iteration of the previous stages, perhaps with altered requirements for the processes or the system. The heavy lines in Figure 5 denote the demarcation of the revisited end points. Three are iterative forms, for which several variants can be extracted:
+
The main relationships between ontology elements are presented in Figure 3.
  
#'''Iterative development''' is quite frequently deployed in order to assess stakeholder requirements, analyze the requirements, and develop a viable architectural design. Thus, it is typical that the concept stage may be revisited during the development stage. For systems where products are based upon physical structures (electronics, mechanics, chemicals, and so on), iteration after production has begun can involve significant costs and schedule delays. It is, therefore, important to get it ''"right"'' before going to production. The early stages are thus used to build confidence (verify and validate) that the solution works properly and will meet the needs of the stakeholders. Naturally, such an approach could be used for software and human activity systems as well; however, due to their soft nature, it can be useful to go further by experimenting and evaluating various configurations of the system.
+
[[File:SEBoKv05_KA-SystRealiz_Implementation_relationships.png|thumb|300px|center|'''Figure 3. Implementation Elements Relationships with Other Engineering Elements.''' (SEBoK Original)]]
#'''Iterative development and implementation''' involves producing (defining, implementing, and integrating) various versions of the system, evaluating how well they meet stakeholder requirements, perhaps in the context of changing requirements, and then revisiting the concept and/or development stages. Such iterations are typical within software system development, where the cost of production is not as significant as for defined physical systems. A variant of this approach is the spiral model, where successive iterations fill in more detail (Boehm and May 1998). The use of this approach requires careful attention to issues related to baseline and configuration management. In this approach, significant verification (testing) should be performed on software systems in order to build confidence that the system delivered will meet stakeholder requirements.
 
#'''Incremental or progressive acquisition''' involves releasing systems in the form of products and/or services to the consumers. This approach is appropriate when structural and capability (functions) changes are anticipated in a controlled manner after deployment. The use of this approach can be due to not knowing all of the requirements at the beginning, which leads to progressive acquisition/deployment, or due to a decision to handle the complexity of the system and its utilization in increments—namely, incremental acquisition. These approaches are vital for complex systems in which software is a significant system element. Each increment involves revisiting the definition and production stages. The utilization of these approaches must be based upon well-defined, agreed relationships between the supplying and acquiring enterprises. In fact, the iteration associated with each resulting product and/or service instance may well be viewed as a joint project, with actor roles being provided by both enterprises.
 
  
In all of the approaches it is wise to use modeling and simulation techniques and related tools to assist in understanding the effect of changes made in the complex systems being life cycle managed. These techniques are typically deployed in the earlier stages; however, they can be used in gaining insight into the potential problems and opportunities associated with the latter stages of utilization and maintenance (for example, in understanding the required logistics and help-desk aspects).
+
===Methods, Techniques, and Tools===
 +
There are many software tools available in the implementation and integration phases. The most basic method would be the use of N-squared diagrams as discussed in Jeff Grady’s book ''System Integration'' (Grady 1994).
  
==Allocating and Meeting Requirements - Integration of Process and Product Models==
+
===Checking and Correctness of Implementation===
 
+
Proper implementation checking and correctness should include testing to determine if the implemented element (i.e., piece of software, hardware, or other product) works in its intended use. Testing could include mockups and breadboards, as well as modeling and simulation of a prototype or completed pieces of a system. Once this is completed successfully, the next process would be [[System Integration|system integration]].
Regardless of the order in which life cycle stages are executed, stakeholder requirements for the system, including changed requirements in each iteration, must be allocated into appropriate activities of the processes used in projects for various stages as well as to the properties of the elements of the product system or service system and their defined relationships. This distribution was illustrated in the fourth variant of Lawson’s T-model as presented in [[System Life Cycle Process Models: Iterative]] and [[System Life Cycle Process Models: Vee]].
 
 
 
Ideally, the project management team should implement proven processes that will integrate the technical process models with the project management product models to manage any of the processes discussed earlier, including incremental and evolutionary development. The processes shown are the project management flow, starting with the beginning of the development phase (Forsberg, Mooz, and Cotterman 2005, 201).
 
 
 
[[File:@@BKCASE_Sect_2.5_Fig_6A.png|thumb|center|500px|'''Figure 6a. New Product Planning Process – Getting Started (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
 
 
 
[[File:@@BKCASE_Sect_2.5_Fig_6B.png|thumb|center|500px|'''Figure 6b. New Product Planning Process Solving the Problem (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]  
 
 
 
[[File:QQBKCASE_Sect_2.5_Fig_6C.png|thumb|center|600px|'''Figure 6c. New Product Planning Process – Getting Commitment (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
 
  
 
==References==  
 
==References==  
  
 
===Works Cited===
 
===Works Cited===
 +
DAU. February 19, 2010. ''Defense acquisition guidebook (DAG)''. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense.
  
Boehm, B. and W. May. 1988. "A Spiral Model of Software Development and Enhancement."  IEEE ''Computer'' 21(5): 61-72.
+
Grady, J.O. 1994. ''System integration.'' Boca Raton, FL, USA: CRC Press, Inc.
  
Boehm, B. and D. Port. 1999. "When Models Collide: Lessons From Software System Analysis." ''IT Professional'' 1(1): 49-56.
+
NASA. 2007. ''Systems Engineering Handbook.'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
  
Boehm, B., J. Lane, S. Koolmanojwong, and R. Turner (forthcoming). ''Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model.''  New York, NY, USA: Addison Wesley.
+
===Primary References===
 
+
DAU. 2010. ''[[Defense Acquisition Guidebook (DAG)]]''. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''Visualizing Project Management.'' 3rd ed. New York, NY, USA: J. Wiley & Sons.
 
 
 
ISO/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|Systems and Software Engineering]]-- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions.[[ISO/IEC/IEEE 15288]]:2015
 
 
 
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' London, UK: College Publications.
 
 
 
Wired News Contributors. 2011. “Sunk by Windows NT,” ''Wired News'', last modified July 24, 1998. Accessed on September 11, 2011. Available at http://www.wired.com/science/discoveries/news/1998/07/13987.
 
  
===Primary References===
+
Grady, J.O. 1994. ''[[System Integration (reference)|System Integration]]''. Boca Raton, FL, USA: CRC Press, Inc.
Boehm, B. and W. May. 1988. “[[A Spiral Model of Software Development and Enhancement]].” IEEE ''Computer.'' 21(5): 61-72.  
 
  
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''[[Visualizing Project Management]],'' 3rd ed. New York, NY, USA: John Wiley & Sons.
+
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2015.
  
Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]].'' London, UK: College Publications.
+
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
  
 
===Additional References===
 
===Additional References===
 
+
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.
Al-Said, M. 2003. "Detecting Model Clashes During Software Systems Development." PhD Diss. Department of Computer Science, University of Southern California, December 2003.
 
 
 
Boehm, B., J. Lane, S. Koolmanojwong, and R. Turner. (forthcoming). ''Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model.'' New York, NY, USA: Addison Wesley.
 
 
 
Boehm, B. and D. Port. 1999. "Escaping the Software Tar Pit: Model Clashes and How to Avoid Them." ''ACM Software Engineering Notes.'' (January, 1999): p. 36-48.
 
 
 
Boehm, B. and D. Port. 1999. "When Models Collide: Lessons From Software System Analysis." ''IT Professional.'' 1(1): 49-56.
 
 
 
Boehm, B., D. Port, and M. Al-Said. 2000.  "Avoiding the Software Model-Clash Spiderweb." IEEE ''Computer.'' 33(11): 120-122.
 
 
 
Lawson, H. and M. Persson. 2010. “Portraying Aspects of System Life Cycle Models.” Proceedings of the European Systems Engineering Conference (EuSEC). 23-26 May 2010. Stockholm, Sweden.
 
  
 
----
 
----
 
+
<center>[[System Realization|< Previous Article]] | [[System Realization|Parent Article]] | [[System Integration|Next Article >]]</center>
<center>[[System Life Cycle Process Models: Iterative|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[Lean Engineering|Next Article >]]</center>
 
  
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
  
[[Category:Part 3]][[Category:Topic]]
+
[[Category: Part 3]][[Category:Topic]]
[[Category:Life Cycle Models]]
+
[[Category:System Realization]]

Revision as of 20:34, 19 October 2019

System ImplementationSystem Implementation uses the structure created during architectural designarchitectural design and the results of system analysis to construct system elementssystem elements that meet the stakeholder requirementsstakeholder requirements and system requirementssystem requirements developed in the early life cyclelife cycle phases. These system elements are then integrated to form intermediate aggregatesaggregates and finally the complete system-of-interest (SoI)system-of-interest (SoI). See System Integration.

Definition and Purpose

Implementation is the process that actually yields the lowest-level system elements in the system hierarchy (system breakdown structure). System elements are made, bought, or reused. Production involves the hardware fabrication processes of forming, removing, joining, and finishing, the software realization processes of coding and testing, or the operational procedures development processes for operators' roles. If implementation involves a production process, a manufacturing system which uses the established technical and management processes may be required.

The purpose of the implementation process is to design and create (or fabricate) a system element conforming to that element’s design properties and/or requirements. The element is constructed employing appropriate technologies and industry practices. This process bridges the system definition processes and the integration process. Figure 1 portrays how the outputs of system definition relate to system implementation, which produces the implemented (system) elements required to produce aggregates and the SoI.

Figure 1. Simplification of How the Outputs of System Definition Relate to System Implementation, which Produces the System Elements Required to Produce Systems and Subsystems. (SEBoK Original)

Process Approach

Purpose and Principle of the Approach

During the implementation process, engineers apply the design properties and/or requirements allocated to a system element to design and produce a detailed description. They then fabricate, code, or build each individual element using specified materials, processes, physical or logical arrangements, standards, technologies, and/or information flows outlined in detailed descriptions (drawings or other design documentation). A system element will be verified against the detailed description of properties and validated against its requirements.

If subsequent verification and validation (V&V) actions or configuration audits reveal discrepancies, recursive interactions occur, which includes predecessor activities or processes, as required, to mitigate those discrepancies and to modify, repair, or correct the system element in question. Figure 2 provides the context for the implementation process from the perspective of the U.S. Defense Acquisition University (DAU).

Figure 2. Context Diagram for the Implementation Process (DAU 2010). Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).

Such figures provide a useful overview of the systems engineeringsystems engineering (SE) community’s perspectives on what is required for implementation and what the general results of implementation may be. These are further supported by the discussion of implementation inputs, outputs, and activities found in the National Aeronautics and Space Association's (NASA's) Systems Engineering Handbook (NASA 2007). It is important to understand that these views are process -oriented. While this is a useful model, examining implementation only in terms of process can be limiting.

Depending on the technologies and systems chosen when a decision is made to produce a system element, the implementation process outcomes may generate constraints to be applied on the architecture of the higher-level system; those constraints are normally identified as derived system requirements and added to the set of system requirements applicable to this higher-level system. The architectural design has tomust take those constraints into account.

If the decision is made to purchase or reuse an existing system element, it has tomust be identified as a constraint or system requirement applicable to the architecture of the higher-level system. Conversely, the implementation process may involve some adaptation or adjustments to the system requirement in order to be integrated into a higher-level system or aggregate.

Implementation also involves packaging, handling, and storage, depending on the concerned technologies and where or when the system requirement needs to be integrated into a higher-level aggregate. Developing the supporting documentation for a system requirement, such as the manuals for operation, maintenance, and/or installation, is also a part of the implementation process; these artifacts are utilized in the system deployment and use phase. The system element requirements and the associated verification and validation criteria are inputs to this process; these inputs come from the architectural designarchitectural design process detailed outputs.

Execution of the implementation process is governed by both industrial and government standards and the terms of all applicable agreements. This may include conditions for packaging and storage, as well as preparation for use activities, such as operator training. In addition, packaging, handling, storage, and transportation (PHS&T) considerations will constrain the implementation activities. For more information, refer to the discussion of PHS&T in the System Deployment and Use article. The developing or integrating organization will likely have enterprise-level safety practices and guidelines that must also be considered.

Activities of the Process

The following major activities and tasks are performed during this process:

  • Define the implementation strategy - Implementation process activities begin with detailed design and include developing an implementation strategy that defines fabrication and coding procedures, tools and equipment to be used, implementation tolerances, and the means and criteria for auditing configuration of resulting elements to the detailed design documentation. In the case of repeated system element implementations (such as for mass manufacturing or replacement elements), the implementation strategy is defined and refined to achieve consistent and repeatable element production; it is retained in the project decision database for future use. The implementation strategy contains the arrangements for packing, storing, and supplying the implemented element.
  • Realize the system element - Realize or adapt and produce the concerned system element using the implementation strategy items as defined above. Realization or adaptation is conducted with regard to standards that govern applicable safety, security, privacy, and environmental guidelines or legislation and the practices of the relevant implementation technology. This requires the fabrication of hardware elements, development of software elements, definition of training capabilities, drafting of training documentation, and the training of initial operators and maintainers.
  • Provide evidence of compliance - Record evidence that the system element meets its requirements and the associated verification and validation criteria as well as the legislation policy. This requires the conduction of peer reviews and unit testing, as well as inspection of operation and maintenance manuals. Acquire measured properties that characterize the implemented element (weight, capacities, effectiveness, level of performance, reliability, availability, etc.).
  • Package, store, and supply the implemented element - This should be defined in the implementation strategy.

Artifacts and Ontology Elements

This process may create several artifacts such as:

  • an implemented system
  • implementation tools
  • implementation procedures
  • an implementation plan or strategy
  • verification reports
  • issue, anomaly, or trouble reports
  • change requests (about design)

This process handles the ontology elements shown in Table 1 below.

Table 1. Main Ontology Elements as Handled within System Element Implementation. (SEBoK Original)
Element Definition

Attributes (examples)

Implemented Element An implemented element is a system element that has been implemented. In the case of hardware it is marked with a part/serial number.

Identifier, name, description, type (hardware, software application, software piece, mechanical part, electric art, electronic component, operator role, procedure, protocol, manual, etc.)

Measured Property A measured property is a characteristic of the implemented element established after its implementation. The measured properties characterize the implemented system element when it is completely realized, verified, and validated. If the implemented element complies with a design property, the measured property should equal the design property. Otherwise one has tomust identify the difference or non-conformance which treatment could conclude to modify the design property and possibly the related requirements, or to modify (correct, repair) the implemented element, or to identify a deviation.

Identifier, name, description, type (effectiveness, availability, reliability, maintainability, weight, capacity, etc.), value, unit, etc.

The main relationships between ontology elements are presented in Figure 3.

Figure 3. Implementation Elements Relationships with Other Engineering Elements. (SEBoK Original)

Methods, Techniques, and Tools

There are many software tools available in the implementation and integration phases. The most basic method would be the use of N-squared diagrams as discussed in Jeff Grady’s book System Integration (Grady 1994).

Checking and Correctness of Implementation

Proper implementation checking and correctness should include testing to determine if the implemented element (i.e., piece of software, hardware, or other product) works in its intended use. Testing could include mockups and breadboards, as well as modeling and simulation of a prototype or completed pieces of a system. Once this is completed successfully, the next process would be system integration.

References

Works Cited

DAU. February 19, 2010. Defense acquisition guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense.

Grady, J.O. 1994. System integration. Boca Raton, FL, USA: CRC Press, Inc.

NASA. 2007. Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.

Primary References

DAU. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.

Grady, J.O. 1994. System Integration. Boca Raton, FL, USA: CRC Press, Inc.

ISO/IEC/IEEE. 2015. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

NASA. 2007. Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.

Additional References

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.0, released 1 June 2019