268
Engineering Systems Integration
up front are ill-formed, incomplete, or deemed unnecessary may have importance as the systems engineering activities begin to discover and detail
trade-offs and derive new requirements. The iterative nature of systems
engineering inculcates the maxim, “If at first you don’t succeed, try and try
again.” The trade-off for systems engineering is to live with an error and deal
with it later. Intentionally letting an error pass is unacceptable because something that is known to not work properly will bedevil integration work.
Functionality and performance will suffer.
Scalability is about doing what needs to be done with more people or
being able to do more with one person. Scalability in the first instance
(more people doing what needs to be done) is enabled by providing services to support the people. Scalability in the second instance (enabling
people to do more is through efficiencies). The systems engineering process
model needs to work effectively in both instances. The desired scalability
is achieved when an economy of scale is reached. This economy is related
by the output level of the team per unit cost increasing at a nonlinear rate.
If the resources and the process model are as described above, an effective
scalability is achievable. Economies of scale result from both members of
the project team working in concert as well as the development objects
being synergistically integrated. One of the key factors in achieving such
an economy of scale is to instill a recognition of scalability by accessing the
processes through synthesis at the unit level first in development, and
again early in the integration work while at the same time supplanting
iterative actions with recursive thinking. One of the key factors in stimulating scalability is through the use of tools that are not limited by their access
to a single instance in a database. Multiple users of the same data through
single-threaded access thwart people in achieving economies of scale and
are therefore scalable. This way of thinking about scalability is the same as
enabling greater capability with respect to multiple simultaneous uses of
common tools and data. When magnified across the development or integration work, an improved use of resources results. In essence, the networking of process through common access provides scalability from very
small projects to diverse, multiple domain programs (NIST Special
Publication 1108 2010).
Checklist for Scalability
Satisfying the two key conditions (resources available at start of project and
scalability) is essential to realizing an economy of scale. The checklist for
scalability is as follows:
• Mandates, preferences, or desires of the key stakeholders (e.g.,
acquirers and users)
• Experience of the project manager and the business enterprise
Engineering Systems Integration
up front are ill-formed, incomplete, or deemed unnecessary may have importance as the systems engineering activities begin to discover and detail
trade-offs and derive new requirements. The iterative nature of systems
engineering inculcates the maxim, “If at first you don’t succeed, try and try
again.” The trade-off for systems engineering is to live with an error and deal
with it later. Intentionally letting an error pass is unacceptable because something that is known to not work properly will bedevil integration work.
Functionality and performance will suffer.
Scalability is about doing what needs to be done with more people or
being able to do more with one person. Scalability in the first instance
(more people doing what needs to be done) is enabled by providing services to support the people. Scalability in the second instance (enabling
people to do more is through efficiencies). The systems engineering process
model needs to work effectively in both instances. The desired scalability
is achieved when an economy of scale is reached. This economy is related
by the output level of the team per unit cost increasing at a nonlinear rate.
If the resources and the process model are as described above, an effective
scalability is achievable. Economies of scale result from both members of
the project team working in concert as well as the development objects
being synergistically integrated. One of the key factors in achieving such
an economy of scale is to instill a recognition of scalability by accessing the
processes through synthesis at the unit level first in development, and
again early in the integration work while at the same time supplanting
iterative actions with recursive thinking. One of the key factors in stimulating scalability is through the use of tools that are not limited by their access
to a single instance in a database. Multiple users of the same data through
single-threaded access thwart people in achieving economies of scale and
are therefore scalable. This way of thinking about scalability is the same as
enabling greater capability with respect to multiple simultaneous uses of
common tools and data. When magnified across the development or integration work, an improved use of resources results. In essence, the networking of process through common access provides scalability from very
small projects to diverse, multiple domain programs (NIST Special
Publication 1108 2010).
Checklist for Scalability
Satisfying the two key conditions (resources available at start of project and
scalability) is essential to realizing an economy of scale. The checklist for
scalability is as follows:
• Mandates, preferences, or desires of the key stakeholders (e.g.,
acquirers and users)
• Experience of the project manager and the business enterprise