Elements of Systems Engineering Decision Making Analysis Paper A minimum of 400 words is required. As the demand for systems and applications continues to

Elements of Systems Engineering Decision Making Analysis Paper A minimum of 400 words is required. As the demand for systems and applications continues to grow, organizations are striving to get things correct the first time as barriers are high and alternatives are plentiful. Review the elements systems engineering discussed in Chapter 2 and select the most critical element and one most commonly overlooked.References Jacobs, S. (2016). Systems Engineering. In S. Jacobs, Engineering Information Security: The Application of Systems Engineering Concepts to Achieve Information (2nd ed., pp. 31-60). Hoboken, NJ, USA: John Wiley & Sons, Inc. Retrieved April 13, 2020, from https://ebookcentral.proquest.com/lib/apus/reader…. 2
SYSTEMS ENGINEERING
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
2.1 SO WHAT IS SYSTEMS ENGINEERING?
Systems engineering is a methodical approach to the speci?cation, design, creation, and
operation of a function. In simple terms, systems engineering consists of:
• identi?cation and quanti?cation of system goals and objectives;
• development of functional and performance requirement statements that capture
those capabilities necessary to ful?ll the identi?ed goals and objectives;
• creation of alternative system design concepts that comply with the functional and
performance requirements;
• performance, cost–bene?t, and trade-off analyses for each alternative design;
• selection, implementation, and deployment of the chosen design;
• veri?cation that the design is properly built, integrated, deployed, operated/
managed; and
• post-deployment assessment of how well the system meets (or met) the
goals.
Engineering Information Security: The Application of Systems Engineering Concepts to Achieve Information
Assurance, Second Edition. Stuart Jacobs.
? 2016 by The Institute of Electrical and Electronics Engineers, Inc. Published 2016 by John Wiley & Sons, Inc.
Companion Website: www.wiley.com/go/informationsecurity2jacobs
31
Jacobs, Stuart. Engineering Information Security : The Application of Systems Engineering Concepts to Achieve Information
Assurance, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=4187172.
Created from apus on 2020-04-13 02:35:02.
SYSTEMS ENGINEERING
32
Let us start with a couple of general de?nitions of systems engineering:
The concept from the engineering standpoint is the evolution of the engineering scientist,
i.e., the scienti?c generalist who maintains a broad outlook. The method is that of the team
approach. On large-scale system problems, teams of scientists and engineers, generalists as
well as specialists, exert their joint efforts to ?nd a solution and physically realize it . . . .
The technique has been variously called the systems approach or the team development
method.1
and
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
The Systems Engineering method recognizes each system as an integrated whole even
though composed of diverse, specialized structures and sub-functions. It further recognizes
that any system has a number of objectives and that the balance between to optimize the
overall system functions according to the weighted objectives and to achieve maximum
compatibility of its parts.2
Systems engineering focuses on de?ning customer needs and required functionality
early in the development cycle and then re?ning and documenting requirements that
represent those needs. This approach continues into design synthesis, development,
system validation, deployment, operation, and retirement while considering the complete
problem (system life cycle).
The systems engineering process is decomposed into a systems engineering
technical process and a systems engineering management process.3 Within this model,
the goal of the management process is to organize the technical effort in the life cycle,
while the technical process includes assessing available information, and de?ning
effectiveness measures, to create a behavioral model, create a structure model, perform
trade-off analysis, and create sequential build and test plans. Although there are several
models (the waterfall model, modi?ed waterfall models, the sashimi model, the spiral
model, etc.) that are used in the industry, all of them aim to identify the relation between
the various stages mentioned above and incorporate feedback. Whether a sequential,
spiral, or waterfall approach is followed, the methodological engineering process should
include the results shown in Figure 2.1.
2.1.1 SIMILAR Systems Engineering Process
To quote the International Council on Systems Engineering (http://www.incose.org):
“Systems Engineering is an engineering discipline whose responsibility is creating and
executing an interdisciplinary process to ensure that the customer and stakeholder’s needs
are satis?ed in a high quality, trustworthy, cost ef?cient and schedule compliant manner
1
NASA Systems Engineering Handbook, NASA, SP-610S, 1995.
2
Systems Engineering Methods, H. Chestnut, Wiley, 1967.
3
Engineering Complex Systems with Models and Objects, D. W. Oliver, T. P. Kelliher, J. G. Keegan, Jr.,
McGraw-Hill, 1997, pp. 85–94.
Jacobs, Stuart. Engineering Information Security : The Application of Systems Engineering Concepts to Achieve Information
Assurance, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=4187172.
Created from apus on 2020-04-13 02:35:02.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
Jacobs, Stuart. Engineering Information Security : The Application of Systems Engineering Concepts to Achieve Information
Assurance, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=4187172.
Created from apus on 2020-04-13 02:35:02.
34
SYSTEMS ENGINEERING
Figure 2.2. SIMILAR systems engineering process
throughout a system’s entire life cycle. This process is usually comprised of the following
seven tasks: State the problem, Investigate alternatives, Model the system, Integrate,
Launch the system, Assess performance, and Re-evaluate. These functions can be summa­
rized with the acronym SIMILAR: State, Investigate, Model, Integrate, Launch, Assess and
Re-evaluate. This Systems Engineering Process is shown in Figure 2.2. It is important to
note that the Systems Engineering Process is not sequential. The functions are performed in
a parallel and iterative manner.”4
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
Let us examine the six SIMILAR process tasks in more detail.
2.1.1.1 Stating the Problem. The process starts with a problem statement
describing the top-level functions that the system must perform. This statement can be in
the form of a mission statement, a concept of operations, or even a description of the
de?ciency that must be removed. The problem statement should be in terms of what must
be done, not how to do it. How to implement, or provide required functionality, is not
addressed here; the “how” items get addressed in the develop/integrate task step. The
problem statement should document the customer requirements in functional or behav­
ioral terms. Prose descriptions are frequently combined with graphics, and these
descriptions may include conceptual “use-cases.” The primary inputs come from end
users, operators, maintainers, acquirers, owners, and other stakeholders.
From the problem statement the major mandatory and preferred (desirable) require­
ments are derived so that these requirements can be traced (linked) back to elements
within the Problem Statement document(s). These major requirements are subsequently
analyzed and decomposed into basic elements (detailed/atomic requirements). A wellformed detailed requirement follows a number of simple rules:
1. Each detailed requirement should have only one noun, a verb, and an object
consistent with the following:
X will be capable of A
X will perform B
X will not allow C to occur
“Re-evaluating System Engineering Concepts Using Systems Thinking,” A. T. Bahill and B. Gissing, IEEE
Trans. Syst. Man Cybern. 28(4), 516–527, 1998.
4
Jacobs, Stuart. Engineering Information Security : The Application of Systems Engineering Concepts to Achieve Information
Assurance, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=4187172.
Created from apus on 2020-04-13 02:35:02.
SO WHAT IS SYSTEMS ENGINEERING?
35
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
2. When a thing X needs to be capable of multiple functionality, one should Not
write:
X will be capable of D, E, and F
rather it should be stated as
X will be capable of D
X will be capable of E
X will be capable of F
so as to capture each capability of X uniquely. This approach also simpli?es the act of
verifying that all the capabilities of X are met.
3. Each detailed requirement should be veri?able in some manner; veri?cation can
be via inspection, testing, analysis, or other documentable and repeatable
technique or methodology.
An acceptable system (regardless of in-house development or acquisition of an intergraded solution) should satisfy all the mandatory requirements derived from the Problem
Statement. The desirable requirements are quite often traded off to ?nd the preferred
alternatives. A robust classi?cation of requirements and recommended language, which
covers most business needs, is contained in RFC 2119.5
All organizations run the risk of not controlling the requirements analysis process
later in the process, thereby having to cope with a never ending stream of requested
changes without proper reconciliation against existing requirements. This problem is
usually called “requirements creep,” and this can cause schedules to stretch well beyond
the planned completion dates. The requirements developed should cover functional
capabilities, performance capabilities, and operational capabilities.
There is signi?cant value in recording the veri?cation approach for each detailed
requirement. This record can serve as the basis for the test plans and test procedures used
during the integration/acquisition, deployment/?elding, and assessment phases.
What tools are used to capture the requirements analysis results can range from MS
Word documents, Excel spreadsheets, to database systems that provide specialized require­
ments analysis and traceability applications. Each tool approach should be considered in a
cost–bene?t trade-off. Word and Excel are low cost and fairly easy for requirements capture
but have virtually no analysis capabilities, cross-referencing, revision control, or con?gurable
reporting. Database-oriented requirements tracking systems have greater capabilities and
greater cost to deploy, yet can improve ef?ciency of the actual analysis work. These
specialized applications have signi?cant deployment costs that usually cannot be justi?ed
unless system failures can cause/threaten loss of life or signi?cant destruction.
2.1.1.2 Investigate Alternatives and Model the System. The optimal
approach for these two process tasks is really to combine them by creating a number
of alternative designs and evaluate each design based on compliance with functionality
and performance requirements, along with schedule and life-cycle costs. No design is
RFC 2119, “Key words for use in RFCs to indicate requirement levels,” BCP: 14, S. Bradner, IETF, March
1997.
5
Jacobs, Stuart. Engineering Information Security : The Application of Systems Engineering Concepts to Achieve Information
Assurance, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=4187172.
Created from apus on 2020-04-13 02:35:02.
SYSTEMS ENGINEERING
36
likely to be best on all criteria, so use of decision-aiding techniques/applications should
be considered. Other analysis tools to consider using are discrete event simulations; these
can provide detailed and precise understanding of component/subsystem interactions and
possible performance “bottlenecks.” These analyses and simulations should be re?ned
and re-performed as more data become available. Some optimal points to reanalyze the
design alternatives are:
•
•
•
•
initially based on estimates by the design engineers;
later based on simulation data derived from models;
after measurements are obtained from prototypes; and
after tests run on the real system prior to deployment.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
Many types of system models are used, such as physical analogs, analytic equations, state
machines, block diagrams, functional ?ow diagrams, message ?ow diagrams, objectoriented models, and discrete event simulations. Systems engineering is responsible for
creating a product and also a process for producing it. So models should be constructed
for both the product and the process (project/program management). As previously
stated, the systems engineering process is not sequential: it is parallel and iterative.
2.1.1.3 Develop/Integrate. Systems, processes, and people must be integrated
so that they interact with one another in a predictable and reliable manner. Integration
means bringing all together so that they work as a whole. The mapping of requirements to
functional elements (FEs) occurs here with functional elements aggregated into func­
tional groups (FGs) of elements. A critical component of this task is the mapping of
detailed requirements to individual FEs. Interfaces between FEs and FGs should be
speci?ed and designed. FGs are frequently organized into subsystems at this point.
Subsystems should be de?ned along logical boundaries and to minimize the amount of
information to be exchanged among the subsystems. Well-designed subsystems send
?nished products to other subsystems.
The (sub-)system components being integrated can take a number of forms:
•
•
•
•
•
Build in-house (development);
Acquire subsystems and integrate using in-house personnel (integration);
Acquire subsystems and integrate using third-party integration (prime contractor);
Acquire a “turnkey” system from a single supplier; or
“Outsource” the system functionality to a third-party service provider.
When considering which approach to employ, consider that the costs signi?cantly vary
and the degree of control retained also varies. The more work retained in-house, the more
direct control is necessary for ensuring requirement compliance. Turnkey and outsourced
solutions frequently force compromise or decreasing the number of requirements that can
or will be complied with. The approaches also differ regarding in-house resources
required, acquisition costs, operational costs, schedules, and technical complexity,
Jacobs, Stuart. Engineering Information Security : The Application of Systems Engineering Concepts to Achieve Information
Assurance, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=4187172.
Created from apus on 2020-04-13 02:35:02.
SO WHAT IS SYSTEMS ENGINEERING?
37
among other constraints. This is the phase where the preferred alternative is designed in
detail; the parts are built or bought, and the parts are integrated and tested at various levels
leading to the target solution. In designing and producing the solution, due consideration
needs to be given to its interfaces with operators/administrators (humans who will need to
be trained in the complexities of the solution and necessary operational/maintenance
procedures), users/customers (humans who will need to be instructed on system usage and
capabilities), and other systems with which the solution will interface (interact with). In
some instances, this will cause interfaced systems to require modi?cation. The process of
designing and producing the solution is often iterative, as new knowledge developed along
the way may necessitate a reconsideration and modi?cation of earlier steps.
The systems engineering products that should be produced from these activities
include:
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
•
•
•
•
•
•
•
mission statement;
requirements document(s) including veri?cation methodologies;
descriptions of functions and objects;
test plans and test procedures;
drawings of system boundaries and organizational domains;
interface control document; and
other documents (including listing of deliverables, trade-off studies, risk analyses,
life-cycle analyses, and a physical architecture description).
The requirements should be validated and veri?ed during every step of development and
integration. The mapping of functions to physical components can be one to one or many
to one. One valid reason for assigning a function to more than one component would be
deliberate redundancy to enhance reliability, allowing one portion of the solution to take
on a function if another portion fails, capabilities are degraded, or has to be taken off-line
for servicing.
2.1.1.4 Launch the System. Launching the system means putting the solution
into operation, which includes deployment planning, acceptance testing, trouble man­
agement and escalation, rollout into the ?eld, and ongoing production operations,
administration, and maintenance (OA&M). Deployment planning should be tied to
product delivery time frames, version schedules, ?elding plans, personnel preparation,
and facilities readiness. The schedules should allow for slippages and denote critical
milestone dates.
Acceptance testing can take multiple forms, such as:
• veri?cation of requirements compliance of supplier components and subsystems
upon delivery to staging area(s);
• veri?cation of operational processes and procedures at staging area(s); and
• veri?cation of operational functionality and performance capabilities in a “?eld
trial.”
Jacobs, Stuart. Engineering Information Security : The Application of Systems Engineering Concepts to Achieve Information
Assurance, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=4187172.
Created from apus on 2020-04-13 02:35:02.
38
SYSTEMS ENGINEERING
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
Trouble management and escalation should not be ignored. Problems will arise during
deployment. Problems with vendor-supplied components will need remediation tracking
to avoid schedule impacts, as well as compliance with contract terms and conditions.
Procedural problems require resolution given that operational errors can have major
reliability and availability consequences.
The rollout into the ?eld should allow for the size and complexity of the system/
solution being deployed. The larger or more complex, the better it is to use a
staged ?elding approach such as initial ?eld trial with a constrained set of service
subscribers/users and live traf?c, followed by a rollout trial serving a more
general population of service subscribers/users, and concluding with general availa­
bility of the product or service to the marketplace/customer base or within the
organization.
Production operations, administration, and maintenance (OA&M) spans the proce­
dures, processes, personnel, and management tools required to ensure the ongoing
operation of the system/solution to deliver the service as speci?ed by the requirements
derived from the mission statement.
2.1.1.5 Assess Performance. Technical performance measures are used to
mitigate risk during design, development/integration, and system launch/deployment.
Metrics (customer satisfaction comments, productivity, number of problem reports, or
other attributes critical to the business, etc.) are used to help manage a company’s
processes. Measurement is the key: if it cannot be measured, then it cannot be controlled.
If uncontrolled, then it cannot be improved. Important system resources such as
processing capacity, storage capacity, communications bandwidth, and power consump­
tion should be evaluated. Each subsystem is allocated a portion of the total budget for
each of these resource areas, and these resource budgets should be managed/tracked
throughout the system’s life cycle.
2.1.1.6 Re-evaluate. Re-evaluation is a fundamental engineering tool. Re­
evaluation…
Purchase answer to see full
attachment