269
Integration in Systems Engineering Context
• Skills and experience of the systems engineers and the project team
• Time limitation to complete the project
• Budget limitation and schedule of payments for the project
• Economies of scale due to common access to network tools and
processes
• Applicability of approvals and milestones to the pace of development
and integration
• The level of functionality, performance, and quality desired
• The scope of the project (determines the set of heuristics necessary
to make decisions)
Without satisfying the two conditions for a successful project (i.e., resource
satisfaction at start and process model scalability), the project should be considered to have an undeterminable risk. Moreover, the view is that once a
systems engineering process model has been adopted, it should be sacrosanct. However, if the conditions warrant and the initial development work
determines that a change in the systems engineering process model would
help focus the work on a particular methodology or emphasize an aspect of
the work that is discovered to be most important, then consider tailoring the
model. Again, that change in the systems engineering process model needs
to be vetted carefully against the needs of the key stakeholders, and strict
unanimity is paramount.
Testing
Testing objects and integration are often indicted as being either related or
similar in nature. “Test and integration,” “integration and test,” or “integration test” appear frequently in reports, systems engineering documentation,
and in presentations by stakeholders involved with an acquisition activity.
Integration and developmental testing or integration and unit testing are key
to building a system. Integration has been thought of as “… progressively
linking and testing …”* The common usage of the word “integration,” while
suggestive of bringing objects together to build a system, should not be
thought of as building a system. Rather, the process of “integration” is more
accurately described as putting parts together in a particular order and fashion to demonstrate the requisite system functionalities. Whether these parts
form a system (or not) has nothing to do with the process of putting them
* Institute for Telecommunications, United States Department of Commerce.
Integration in Systems Engineering Context
• Skills and experience of the systems engineers and the project team
• Time limitation to complete the project
• Budget limitation and schedule of payments for the project
• Economies of scale due to common access to network tools and
processes
• Applicability of approvals and milestones to the pace of development
and integration
• The level of functionality, performance, and quality desired
• The scope of the project (determines the set of heuristics necessary
to make decisions)
Without satisfying the two conditions for a successful project (i.e., resource
satisfaction at start and process model scalability), the project should be considered to have an undeterminable risk. Moreover, the view is that once a
systems engineering process model has been adopted, it should be sacrosanct. However, if the conditions warrant and the initial development work
determines that a change in the systems engineering process model would
help focus the work on a particular methodology or emphasize an aspect of
the work that is discovered to be most important, then consider tailoring the
model. Again, that change in the systems engineering process model needs
to be vetted carefully against the needs of the key stakeholders, and strict
unanimity is paramount.
Testing
Testing objects and integration are often indicted as being either related or
similar in nature. “Test and integration,” “integration and test,” or “integration test” appear frequently in reports, systems engineering documentation,
and in presentations by stakeholders involved with an acquisition activity.
Integration and developmental testing or integration and unit testing are key
to building a system. Integration has been thought of as “… progressively
linking and testing …”* The common usage of the word “integration,” while
suggestive of bringing objects together to build a system, should not be
thought of as building a system. Rather, the process of “integration” is more
accurately described as putting parts together in a particular order and fashion to demonstrate the requisite system functionalities. Whether these parts
form a system (or not) has nothing to do with the process of putting them
* Institute for Telecommunications, United States Department of Commerce.