s123.pdf

IT- 440 - Week 7
System Architecture
Introduction
v Systems architecting has been defined as the process of creating complex, unprecedented
systems.
v This description fits well for many of the systems that are being created or planned today,
whether in industry, government, or academia.
v The requirements of the marketplace are ill-defined; rapidly evolving technology has allowed
new services to be offered at a global level.
v One thinks of system architectures when the system in question consists of many diverse
components.
v A system architect, while knowledgeable about the individual components, needs to have a
good understanding of the interrelationships among the components.
DEFINITION OF ARCHITECTURES
In defining an architecture, especially of an information system, what needs to be described:
v First, there is an operational concept that describes in broad terms what the system or the
system of systems is expected to accomplish in support of the enterprise goals.
v In both cases, there are processes that need to take place in order that the intended mission be
accomplished; the individual processes transform either data or materials that “flow”
between them.
v It is also necessary to describe the components.
v that will implement the design: the hardware, software, personnel, and facilities that will be
the system.
v In the system of systems case, a higher order problem exists: the selection of the systems that
are brought together, possibly for a finite period of time, to support the mission.
There are two architectural constructs:
v Functional architecture: is a set of activities or functions, arranged in a specified partial order
that, when activated, achieves a set of requirements.
v Physical architecture: is a representation of the physical resources, expressed as nodes, that
constitute the system and their connectivity, expressed in the form of links.
v Before even attempting to develop these representations, the operational concept must be
defined.
v This is the first step in the architecture development process. An operational concept is a
concise statement that describes how the goal will be met.
v There are no analytical procedures for deriving an operational concept for complex,
unprecedented systems.
v A good operational concept is based on a simple idea of how the overriding goal is to be met.
v
v Use Case: One approach to bridge the wide gap between the operational concept and the
functional architecture is the development of use cases. While use cases are usually
Khloud alsehli

associated with object orientation, they are much broader in concept and can be used with
any methodology.
v A use case captures an interaction between a user and the system.
v A technical (standards) architecture: is a minimal set of rules governing the arrangement,
interaction, and interdependence of the parts or elements whose purpose is to ensure that a
conformant system satisfies a specified set of requirements. It provides the framework upon
which engineering specifications can be derived, guiding the implementation of the system.
Structured analysis approach
v Starting with a verb or verb phrase that articulates the function of the system, a first-level
decomposition is done, separating into functions that are part of the top-level function.
v These first-level functions are mutually exclusive and could be totally exhaustive.
v The decomposition is carried out to as many levels as is necessary, always guided by the
operational concept and the use cases.
What are the reasons under which levels as few possible are recommended?
§ each additional level increases substantially the complexity of the problem
§ a multilevel decomposition may introduce implicitly a physical architecture
v Two features of structed analysis approach:
§ This approach can be characterized as a process-oriented in that it considers as the
starting point the functions or activities that the system must perform.
§ A second characterizing feature is the use of functional decompositions and the resulting
hierarchically structured diagrams
What are the models that used in structured analysis approach?
1- Functional Decomposition and Activity Model:
v In a process-oriented approach such as structured analysis, the architecture development
process can start with a very abstract operational concept.
v As the analysis evolves, the operational concept becomes more specific; like, the use cases
are a reification of the operational concept.
2- Data Model:
v The arcs in the activity model represent flows of data or objects.
v the purpose of a data model, the second pillar, is to analyze the data structures and their
relationships independently of the processing that takes place.
There are two main approaches with associated tools for data modeling:
- IDEF1x (IDEF1 extended):
§ structure and semantics of the information in a system.
§ the elements of IDEF1x are the entities, their relationships or associations
- Entity-relationship (E-R) diagrams:
§ An entity is the representation of a set of real or abstract objects that share the same
characteristics and can participate in the same relationships
§ An individual member of the set is called an entity instance.
§ An entity is depicted by a box; it has a unique name and a unique identifier.
3- Rule Model:
Khloud alsehli

§ In a rule-oriented model, knowledge about the behavior of the architecture is represented
by a set of assertions that describe what is to be done when a set of conditions evaluates
as true.
4- Dynamics Model:
§ The fourth pillar of the structured analysis approach characterizes the dynamic behavior
of the architecture.
§ This is not an executable model, but one that shows the transition of the system state as a
result of events that take place.
§ The state space is the set of all possible values that the state can take.
5- System Dictionary and Concordance of Models:
§ Underlying four models for Structured analysis approach, is the system dictionary.
§ These functions appear in the activity model (IDEF0), the rule model (as actions), and the
state transition diagrams.
§ The rules, in turn, are associated with activities; they specify the conditions that must
hold for the activity to take place.
The executable model
v Information systems are dynamic in nature
v An accurate representation of an information architecture should be executable.
v There exist some graphical modeling approaches that allow a dynamic representation of a
system. Behavior Diagrams and Colored Petri (CP) nets are examples of such approaches.
v The solution, therefore, is to derive from the static representations a dynamic representation
of the system, that is, to develop a discrete event dynamical model of an architecture that can
be traced back to the four models(Structured Analysis Models).
Physical architecture
v To complete the analysis phase of the procedure , the physical architecture needs to be
developed.
v There is no standardized way to represent the physical systems, existing ones as well as
planned ones, that will be used to implement the architecture.
v The humans in the organization cannot be thought of simply as users
Performance evaluation
How to evaluate the performance?
1- Measures of performance (MOPs) are obtained either analytically or by executing the
model in simulation mode.
2- For example, if deterministic or stochastic time delays are associated with the various
activities, it is possible to compute the overall delay or to obtain it through simulation
Khloud alsehli

v Depending on the questions to be answered, realistic scenarios of inputs that are consistent
with the operational concept need to be defined.
v This phase allows for functional and performance requirements to be validated, if the results
obtained from the simulations show that the measures of performance are within the required
range.
v This is actually an iterative process.
v The executable model can be used at both the logical and behavioral level, as well as the
performance level.
v Evaluation requires an understanding of the purpose and desired use of the systems or system
of systems that would be built that are conformant to the architecture.
v Generally, this is expressed as requirements. These can be decomposed into internal
requirements and external requirements.
Object-oriented approach
v The Unified Modeling Language (UML) has become the standard for visualizing, specifying,
constructing, and documenting many software systems
v It is a modeling language that has a vocabulary (symbols), semantics, and syntax.
v Within the language, there are two classes of modeling constructs called diagrams.
§ Structural diagrams
§ (i.e. class, object, component, deployment, package, and composite structure diagrams)
document the static aspects of the system being modeled.
§ Behavioral diagrams
§ (i.e. activity, communication, sequence, state machine, sequence, timing, and use case
diagrams) portray the dynamic behavior of the system.
Architecture evaluation
What are the under taking aspects that should be consider when evaluating Architecture?
1- Verification
2- Logical Consistency
3- Behavioral Correctness
4- Performance Requirements
THE DoD ARCHITECTURE FRAMEWORK
v In all three versions, an integrated architecture is defined as consisting of three architecture
views: the operational view of the architecture, the systems view, and the technical
standards view.
v A number of artifacts, or products, are defined to describe each one of the three views.
v In the decade since the original framework was issued, its approach has become pervasive
not only in the United States but in many other countries.
v The DoDAF v. 1.5 enables the use of either structured analysis or object orientation for the
representation of an architecture.
v It defines alternative representations for the various products.
Khloud alsehli

What is the decomposition principle that the DoD architecture framework use it?
v The first on functional decomposition
v The second on entity (classes and objects) decomposition.
v An alternative approach that is appropriate for loosely coupled systems is a decomposition
based on services.
Khloud alsehli

Week 9
Functional analysis
Introduction
• Functional analysis is performed in systems engineering, software systems
engineering, and business process reengineering as a portion of the design
process. These design processes typically involve the steps of requirements
definition and analysis, functional analysis, physical or resource definition, and
operational analysis.
• Functional analysis addresses the activities that the system, software, or
organization must perform to achieve its desired outputs; that is, what
transformations are necessary to turn the available inputs into the
desired outputs.
• Additional elements include the flow of data or items between
functions, the processing instructions that are available to guide the
transformations, and the control logic that dictates the activation and
termination of functions.
ELEMENTS OF FUNCTIONAL ANALYSIS:
There are four elements to be addressed by any specific functional
analysis approach.
1. functions: are represented as a hierarchical decomposition, in which
there is a top-level function for the system or organization.
This top-level function is partitioned into a set of subfunctions that use
the same inputs and produce the same outputs as the top-level function.
Each of these subfunctions can then be partitioned further, with the
decomposition process continuing as often as it is useful.
2. functional analysis diagrams: can represent the flow of data or items
among the functions within any portion of the functional decomposition.
it is common for one function to produce outputs that are not useful
outside the boundaries of the system or organizations. These outputs
are needed by other functions in order to produce the needed and
expected external outputs.

3. Processing instructions: appear in some functional analysis diagrams.
These instructions contain the needed information for the functions to
transform the inputs to the outputs. Also included here are the activation and
termination conditions associated with each function in the functional
hierarchy.
4. control flow: that sequences the termination and activation of the functions
so that the process is both efficient and effective.
a) Can these functions work serially, or must they be processed concurrently?
b) Are these functions activated once or a series of times?
c) What circumstances dictate that one function be activated rather than
another function?
Functional Decomposition
• We first define the concept of system modes, followed by simple and
complete functionalities.
System modes are defined here to be distinct operating states of the system
during which some or all of the system’s functions may be performed to a full
or limited degree.
All systems have at least one standard or fully operational mode. For example,
an elevator system has a maintenance mode during which one or more of the
elevator cars can be stopped for maintenance, while the others continue in
operation. Often systems have a start-up and/or shutdown mode.
‫ﻣ‬
‫ﮭ‬
‫ﻢ‬
‫ا‬
‫ﻟ‬
‫ﻔ‬
‫ﺮ‬
‫ق‬
‫ﺑ‬
‫ﯿ‬
‫ﻦ‬
‫ا‬
‫ل‬
simple functionality & complete Functionality
Simple Functionality: is an ordered sequence of functional processes that
operates on a single input to produce a specific output.
While there may be many inputs required to produce the output in question,
this simple functionality only addresses one of the inputs.
Complete Functionality: is a complete set of coordinated processes that
operate on all of the necessary inputs for producing a specific output.

A functional architecture can be defined at several levels of detail:
1. A logical architecture that defines what the system must do
a decomposition of the system’s top-level function. This definition of the
functional architecture is represented as a directed tree.
2. A logical model that defines how the system transforms its inputs into its
outputs.
3. A logical model to which input/output requirements have been traced to
specific functions.
Decomposition Versus Composition ‫ﻣ‬
‫ﻬ‬
‫ﻢ‬
‫ا‬
‫ﻟ‬
‫ﻔ‬
‫ﺮ‬
‫ق‬
‫ﺑ‬
c
‫ﻨ‬
‫ﻬ‬
‫ﻢ‬
Decomposition, often referred to as top–down structuring, begins with the
top-level system function and partitions it into several subfunctions.
The success of decomposition is predicated on having a sound definition of the
top-level function of the system and the associated inputs and outputs, that is,
a complete set of requirements.
composition, is a bottom–up approach. With composition one starts by
identifying the simple functionalities-associated simple scenarios involving only
one of the outputs of the system.
The advantage of this approach is that the composition process can be
performed in parallel with the development of the physical architecture so that
the functional and physical hierarchies match each other.
There is no empirical evidence that either approach is better than the other.
Ultimately, it is wisest to use a combination of decomposition and composition
A generic partition of six subfunctions are suggested for any function of the
functional architecture: ‫ﻣ‬
‫ﻬ‬
‫ﻢ‬
‫ﺟ‬
‫ﺪ‬
‫ا‬
1- Provide User Interface. These are functions associated with requesting and
obtaining inputs from users, providing feedback that the inputs were received,
providing outputs to users, and responding to queries of those users.
2- Format Inputs. These functions are needed to receive inputs from external
interfaces (nonhumans) and other system components and to process (e.g.,

analog to digital conversion) those inputs to put them into a format needed by
the system’s processing functions.
3- Transform Inputs into Outputs. These are the major functions of the system.
4- Control Processing. These functions are needed to control the processing
resources or the order in which these processing functions should be
conducted.
5- Format Outputs. These functions are needed to convert the system’s
outputs into the format needed by the external interfaces or other system
components and then place those outputs onto the appropriate interface
6-Enable Maintenance, Conduct Self-test, and Manage Redundancy Processing.
These functions are needed to respond to external diagnostic tests, to monitor
its own functionality, to detect errors, and to enable the activation of stand-by
resources.
A functional architecture can be evaluated for shortfalls and overlaps.
‫ﻣ‬
‫ﻬ‬
‫ﻢ‬
‫ا‬
‫ﻟ‬
‫ﻔ‬
‫ﺮ‬
‫ق‬
‫ﺑ‬
c
‫ﻨ‬
‫ﻬ‬
‫ﻢ‬
A shortfall: is the absence of a functionality that is required to produce an
output.

The most common types of shortfall are responses to unexpected inputs and
to failure modes within the system.
Functional overlaps: unlike physical overlaps for redundancy, are not needed
and therefore can only cause problems.
THE SYSTEMS ENGINEERING REQUIREMENTS STATEMENT AND FUNCTIONAL
ANALYSIS
The development of requirements involves: creating an operational concept,
defining the system’s boundaries and external systems, and explicating the
system’s objectives.
• Requirements Taxonomy
• Requirements Criteria
• Operational Concept
• System’s Boundary and External Systems
• System’s Objectives
• Requirements Development Finally, the stakeholders must approve the
requirements documents
STATEMENT AND FUNCTIONAL ANALYSIS
Requirements Taxonomy )
‫ﺗ‬
‫ﺼ‬
9
:
‫ﻒ‬
‫ا‬
‫ﻟ‬
‫ﻤ‬
‫ﺘ‬
‫ﻄ‬
‫ﻠ‬
B
‫ﺎ‬
‫ت‬
( ‫ﻣ‬
‫ﻬ‬
‫ﻢ‬
‫ﺟ‬
‫ﺪ‬
‫ا‬
K
Wymore (1993) identifies six types of system design requirements. We will
incorporate these six types of requirements into each relevant phase of the
system’s life cycle (development, production, deployment, training, operation
and maintenance, refinement, and retirement)
1.Input/output requirements include sets of acceptable inputs and outputs,
trajectories of inputs to and outputs from the system, interface constraints
imposed by the external systems, and eligibility functions that match system
inputs with system outputs for the life- cycle phase of interest.
We can partition the input/output requirements into four subsets:
(a) inputs
(b) outputs
(c) external interface constraints
(d) functional requirements.

2. Technology and systemwide requirements consist of constraints and
performance index thresholds, that are placed on the physical resources of the
system.
This category can be partitioned into four subsets:
(a) technology
(b) the ilities
(c) cost
(d) schedule ---(e.g., development time period, operational life of the system).
Ilities: an attribute that characterize a system's ability to respond to changes
3. Performance requirement is an algorithm that defines how the relative
performance of any two alternate designs can be compared in terms of the
system’s performance requirements.
4. Cost requirement is an algorithm that defines how the relative cost of any
two alternate designs can be compared across all cost parameters (life-cycle
phases) of interest to the stakeholders.
5. Trade-off requirement is an algorithm for comparing any two alternate
designs on the aggregation of cost and performance.
6. System test requirements have four primary elements:
(a) observance—to state how the estimates (test data) for each input/output,
systemwide, performance, cost, and trade-off requirement will be obtained;
(b) verification plan—to state how the test data will be used to determine that
the real system conforms to the design that was developed;
(c) validation plan—to state how the test data will be used to determine that
the real system complies with the originating performance, cost, and trade-off
requirements; and
(d) acceptability—to state how the test data will be used to determine that the
real system is acceptable to the stakeholders.
Figure 25.3 Objectives hierarchy, requirements partition, and trade space.

Requirements Criteria
In any systems engineering effort, we must develop as many correct
requirements as possible; these correct requirements are being defined to be
verifiable. In addition, we must try to eliminate as many incorrect
requirements as possible. The requirements document should contain a
complete, consistent, comparable, design- independent, modifiable, and
attainable statement of the design problem.
Operational Concept
An operational concept is a shared vision from the perspective of the system’s
stakeholders of how the system will be developed, produced, deployed,
trained, used and maintained, refined, and retired to achieve the stakeholders’
operational needs and objectives.it contains a number of external systems and
has a certain context.
System’s Boundary and External Systems
The single, largest issue in defining a new system is where to draw the system’s
boundaries. Everything within the boundaries is open to change, subject to the

requirements, and nothing outside the boundaries can be changed, leading to
many of the system’s constraint requirements.
The inputs to the system are those items that cross the system’s boundaries
from the outside.
the system’s outputs are those items that the external systems are expecting
to receive.
Every functional modeling technique (e.g., IDEF0, behavior diagrams, data flow
diagrams) can be used to define the system boundary
System’s Objectives
Traditionally, systems engineers have used the terms measure of effectiveness
(MOE) and measure of performance (MOP) or figure of merit (FOM).
A measure of effectiveness describes how well a system carries out a task or
set of tasks within a specific context;
an MOE is measured outside the system for a defined environment and state
of the context variables. Note that the further outside the system that the
MOE measurement process is established, the more influence the external
systems have inside the measurement window, yielding less sensitivity in the
measurement process for evaluating the effectiveness of the system.
An MOP (or FOM) describes a specific system property or attribute for a given
environment and context;
an MOP is measured from within the system. There are many possible and
relevant MOPs for a specific system output; examples include accuracy,
timeliness, distance, throughput, workload, and time to complete.
The objectives hierarchy (a directed tree) usually has two to five levels. The
objectives in the hierarchy may include stakeholders explicitly and often
include context (environmental) variables (e.g., weather conditions, peak vs.
nonpeak loading) from the scenarios in the operational concept. If present,
these scenarios are usually at the top of the hierarchy.
Figure 25.4 Objectives hierarchy for an automatic teller machine.

Requirements Development
The systems engineering team must examine each input, control, and output
in detail to discover every requirement associated with it.
The following questions are typically addressed:
1. What elements of the environment matter?
2. How much variation in the environmental elements must be planned for? At
what priority?
3. How well can these variations be forecast (predicted)? Can these forecasts
be part of the system?
4. Can the environment be controlled by the system or external system? Must
the system protect itself from the environment?
5. How do the answers for these questions impact the functions of the system?
The following are key points concerning the systems engineering design
process: u
‫ﺎ‬
‫ن‬
‫ﺳ‬
‫ﺆ‬
‫ا‬
‫ل‬
{
|
}
‫ا‬
‫ﻟ‬
‫ﻮ‬
‫ا‬
‫ﺟ‬
‫ﺐ‬

(1) All stakeholders have originating requirements, which, taken together,
address every stage of the system’s life cycle. Capturing the complete set of
originating requirements ensures a concurrent engineering process.
(2) The set of originating requirements should ensure a decision-rich design
process by not over constraining the design.
The following attributes of requirements are meant to ensure the process is
not over constrained: traceable, correct, unambiguous, understandable, design
independent, attainable, comparable, and consistent.
(3) At the same time, the originating requirements should not under constrain
the design because we want the stakeholders to be happy with the system that
we create. Complete, verifiable, and traceable requirements should guarantee
this.
THE SYSTEMS ENGINEERING REQUIREMENTS STATEMENT AND FUNCTIONAL
ANALYSIS (Continued)
• A requirement is one of many statements that constrain or guide the
system’s development in such a way that it is useful to one or more of its
stakeholders.
A specification: is a collection of requirements that completely define the
constraints and performance requirements for a specific physical entity that is
part of the system.
• Originating requirements are found in the Operational Needs or
Requirements Document (ORD). This document is produced with or by the
stakeholders and is written in their language(s).
Systems engineers need to be involved in a substantial way in this activity,
although not all systems engineers share this view. Experience has shown that
if this document is left to the stakeholders it will be incomplete.
Getting the requirements right is probably the most difficult task, and
therefore a task that is fraught with errors. Unfortunately, many of these
errors are not caught until much later in the life cycle, causing the expenditure
of significant money.
TABLE 25.4. Comparison of the Relative Cost to Fix Software in Various Life
Cycle Phases

DIAGRAMS AND SOFTWARE FOR FUNCTIONAL ANALYSIS
• In Diagrammatic Methods, we address the three-primary modeling
approaches used as part of systems engineering:
*data modeling
* process modeling
* behavior modeling
Object-oriented approaches to systems engineering is also addressed.
TABLE 25.5. Modeling Approaches and Methods

Data Modeling
Entity-relationship (ER) diagrams model the data structure or relationships
between data entities.
Entity types are shown in boxes, relationships are shown in diamonds or as
labels on the arcs. If diamonds are used, the graph has no directed edges and
the relationships are read from left to right or from top to bottom; otherwise
the edges are directed. A unique relationship is that of supertype/subtype,
which has become known as class/ subclass relationship
• IDEF1 models data using entity classes and relationships among entity
classes. An entity class has attributes that describe the entity. The relationships
that are possible between classes come from entity- relationship diagrams and
address mainly one-to-one, one-to-many, and so on.
• IDEF1X also models data using entity classes and relationships among the
classes. IDEF1X allows for a fuller definition of subtypes and attributes in terms
of their aliases, data type, length, definition, primary key, discriminator,
alternate keys, and inversion entities.
Process Modeling
Structured Analysis The structured analysis and design technique (SADT) is a
graphical modeling language and a comprehensive methodology for
developing models.
IDEF0 focuses on functional models of a system. Within IDEF0, a function or
activity is represented by a box, described by a verb–noun phrase, and
numbered to provide context within the model. Inputs enter from the left of
the box, controls enter from the top, mechanisms (or resources) enter from
the bottom, and outputs leave from the right. A flow of material or data is
represented by an arrow or arc that is labeled by a noun phrase. The label is
connected to the arrow by an attached line, unless the association is obvious.
Data Flow Diagrams (DFDs): are one of the original diagramming techniques
used in the software and information systems communities.
The basic constructs of DFDs are:
(1) function or activity (2) data flow
(3) store (4) terminator

N2 Charts were created with the behavior method, function flow block diagrams
(FFBDs), to depict the data or items that are the inputs and outputs of the functions
in the functional architecture. The charts are called N2 because for a set of N
functions the chart contains N2 boxes to show the flow of items within (or internal
to) the N functions. The N functions are placed along the diagonal.
Behavior Modeling
Control Flow Diagrams (CFDs): are sometimes used in conjunction with DFDs,
either as separate but parallel diagrams or superimposed on DFDs.
Control flow is information that is transmitted between functions or between a
function and the outside to determine how the functional processes must
operate under specific changes in the operating modes. These operating
modes may dictate that certain functions are present or absent or change the
way in which these functions perform.
Function Flow Block Diagrams (FFBDs): This was the original approach to
functional decomposition in systems engineering,
Function flow block diagrams show the functions at a given level and a control
structure that dictates the order in which the functions can be executed.
Functions are typically shown in boxes with their associated number.
Behavior Diagrams: originated as part of the Distributed Computer Design
System of the Department of Defense.
System behavior is described through a progressive hierarchical 2326
decomposition of a time sequence of functions and their inputs and outputs.
Functions are represented as verb phrases inside boxes. There is a control
structure represented by lines that flow vertically, from top to bottom,
through the boxes.
Finite State Machines (FSMs): are a subset of machines that have only discrete-
valued inputs, outputs, and internal items. Continuous machines, the second
and last subset in the partition of machines, allow continuous and discrete
inputs, outputs, and internal items.
Object-Oriented Modeling
Object-oriented analysis focuses on the concept of objects that act. The object-
oriented view is that a system is composed of individual agents that have a
well- defined behavior. These objects do things, and they are asked to do

things by messages that are sent to them. When they accomplish their activity,
they may respond with a message if that is the nature of their behavior. The
Unified Modeling Language (UML) was created to bring the many disparate
modeling approaches for object-oriented design together.
Haneen shagroon

Week 10
Systems Design
Introduction
 Design is central to the practice of systems engineering and systems engineers understand that design is
a creative, iterative, decision-making process. The steps in the design process include the specification of
measurable goals, objectives, and constraints for the design; the conceptualization and parameterization
of alternative candidate designs that meet or surpass specifications; the analysis and ranking of design
alternatives; and, finally, the selection, implementation, and testing of the most preferred alternative.
 Design for manufacture (DFM) is a systems approach to improving the competitiveness of a
manufacturing enterprise by developing products that are easier, faster, and less expensive to make,
while maintaining required standards of functionality, quality, and marketability. DFM focuses on
understanding how the design of a product interacts with the various processes and facilities available to
make that product. The objective is to conceive and refine design alternatives that tend to optimize the
product in the context of existing or projected manufacturing capabilities.
 Design for manufacture (DFM) is a systems approach to improving the competitiveness of a
manufacturing enterprise by developing products that are easier, faster, and less expensive to make,
while maintaining required standards of functionality, quality, and marketability. DFM focuses on
understanding how the design of a product interacts with the various processes and facilities available to
make that product. The objective is to conceive and refine design alternatives that tend to optimize the
product in the context of existing or projected manufacturing capabilities.
WHAT IS SYSTEMS DESIGN?
Design is the essence of engineering. Broadly defined, design is the creative process by which our
understanding of logic and science is joined with our understanding of human needs and wants to
conceive and refine artifacts that serve specific human purposes. Such a sweeping definition clearly might
serve as well to define the whole of engineering as a human effort. As a profession, therefore,
engineering is concerned primarily with design—the design of processes, structures, machines, circuits,
and software—and with the combinations of these elements we call systems.
STEPS IN THE DESIGN PROCESS
 The result of the engineering design process typically is a set of drawings (now most typically in a digital,
computer-aided design (CAD) format), which detail the structure of the system—including the size,
shape, materials, and quantities of components and the interrelationships among these design
elements—together with the surveys, data, calculations, analyses, interpretations, and reports required
to support the selection of a particular design and to enable its eventual fabrication.
• The specification of measurable goals, objectives, and constraints for the design; the conceptualization
and parameterization of alternative candidate designs that meet or surpass specifications; the analysis
and ranking of design alternatives; and, finally, the selection, implementation, and testing of the most
preferred alternative.

• There is no universal theory describing exactly how all of these activities do or should come together in
the design process. • However, because the translation from human needs to final design invariably
involves the experience, intuition, skill, and creativity of the designer or design team, and because there
is no unique solution to a given design problem, design is universally understood to be a creative,
iterative, decision-making process.
Figure 13.1 Design as an iterative
process.

Problem Definition
• Defining the problem is as much a part of design as is defining the artifact itself. The most elegant and
efficient solution to the wrong problem is worse than useless.
• It may seem unlikely to the novice systems analyst that a client would not understand his own problem,
but this is often the case. In practice the converse is true.
• In the context of design: Needs are vaguely stated, usually tacit, often latent, and sometimes wrong
(people aren’t sure want they want). Requirements are wishfully overstated, and it is in the process of
design that these are cut back to what is realistic.
• The client always lie; to instill in the design engineer a sense of freedom, not one of constraint. We want
the engineer to think of the design process not as a process of seeking to satisfy a set of [functional]
constraints at minimum cost but rather as a process of freely taking advantage of an opportunity through
the ability to manipulate
nature.
Gibson et al. (2007) recommend seven steps for the systematic development of goals:
1. Generalize the question in order to provide a correct problem statement placing the problem in its
proper context.
2. Develop a descriptive scenario honestly assessing where you are now.
3. Develop a normative scenario describing where you want to be at some time in the future.
4. Develop the axiological component setting out the values of the sponsor.
5. Prepare an objectives tree, containing the most general goals at the top and successively more specific
and measurable objectives in the branches below.
6. Validate the goals and objectives developed in the preceding steps.
7. Iterate through several passes to refine and perfect the objectives tree.

Figure 13.2 A nonlinear
model for determining
system objectives.
STEPS IN THE DESIGN PROCESS (Continued)
Design Synthesis
 The next task in the design process is to generate alternative designs, or design options, which might
reasonably satisfy system specifications. There are usually a host of adequate solutions, some of which
may be identified as better than others. Moreover, because the objectives of design are many (and
conflicting and noncommensurate), some solutions may be preferred with respect to certain objectives,
while other solutions are preferable with respect to different objectives.

The options space is the set of possible system configurations and decisions and represents the full range
of choices available to the designer. For complex problems, defining (and paring down) the options space
can be a very difficult task. This task can be eased by decomposing it into two component subtasks—
design synthesis and parameterization—which can be addressed sequentially, but iteratively.
 Decisions made at preliminary stage generally affect the final appearance, performance, and cost of the
system. At the end of the preliminary design phase, a few promising concepts needing further analysis are
identified.
Creativity is the product of divergent thinking, which is nothing more than the ability to seek and discover
many alternatives, as opposed to convergent thinking, which follows a determined path to a unique
answer.
 Brainstorming is a group process designed to stimulate the discovery of new solutions to problems. In
essence, it is a structured “bull session” under the supervision of a trained facilitator in which participants
throw out ideas and build on and add to the ideas of one another. Under the right set of conditions,
brainstorming has proved successful in applications spanning the past four decades.
 The rules are few:
 A trained leader, called a “facilitator,” is absolutely necessary.
 Sessions are kept informal, with no bosses; use first names.
 Sessions are held away from the usual place of work; dress is casual.
 Interruptions are not allowed.
 Ideas are not criticized, categorized, or organized during sessions.
 Building on “main ideas” with “helpers” is encouraged.
 Everybody talks as they please, but positively.
 A break is taken after an hour or so, when idea creation slows.
 After one or two sessions, move on to an evaluation and categorization mode.
Gibson also cautions about the known drawbacks of the technique:
• Brainstorming can be emotional and stressful and the possibilities for interpersonal conflict are real.
• Individuals uncomfortable with verbal free-for-all can resent being drawn into the process.
• Slow-talking individuals risk being shut out by more vocal individuals.
• More vocal individuals may enjoy the process but are difficult to cut off without dampening the
process.
• Only one person can talk at a time and other participants must idle while waiting their turn.
Given these drawbacks, brainwriting is an attractive alternative that reduces the potential for domination
by vocal or empowered participants and minimizes the likelihood of interpersonal conflicts. Instead of
loud talking and

laughter, a brainwriting session is conducted in silence. Five or six participants sit around a table. In the
center of the table are sheets of paper, each headed by a so-called trigger question. Each individual takes
one of the sheets, writes a sentence that responds to the corresponding trigger question, returns the
sheet to the center, and takes another sheet. After reading the trigger question and prior comments by
other participants, the individual adds his/her own positive comment. The process continues until useful
comments are exhausted, then the ideas are edited, classified, and compiled into a narrative by the
group.
Dynamic confrontation is an adversarial group process. In stark contrast to brainstorming and
brainwriting, in which no criticism is allowed, the essence of dynamic confrontation is to criticize every
idea. A presentation is made and then each main claim or assumption presented is deliberately and
intensely challenged. The idea is to test conventional wisdom and require each participant to think
through every claim.
Parameterization and Analysis
• Parameterization consists of identifying the numerical quantities that specify each element in the
system and their permissible ranges. A system specification consists of a set of values for the system
parameters together with the system configuration. Alternatively, we could view this as the specification
of a set of parts and the instructions to assemble and put these to use.
• Parameterization of a conceptual design and analysis of the performance of the resulting detailed
design typically are tightly coupled in an iterative loop. The iterative process of parameterization and
analysis of performance continues until the designer is satisfied that the parameter space has been
explored sufficiently.
• The design parameters for subsystems must be identified. Systematic optimization methods can aid the
designer in accelerating the detailed design process. At the end of the process, a description of the
system is available in the form of reports or drawings.
Ranking and Selection
The ranking of design alternatives and the ultimate selection of the most preferred design involves the
selection of the best parameterization of the best conceptual design. While the best parameterization of
a given design concept can sometimes be determined by the solution of a deterministic optimization
problem, as suggested by Arora (1989), in general this step must be caste as a multiple-objective decision
problem under uncertainty
Prototype and Testing
The ultimate step in the design process involves the fabrication and testing of aprototype or system. For
large and costly or one-of-a-kind systems, it may not be possible or feasible to construct a prototype.

Nevertheless, it is not unusual that specifications and design elements are revised during fabrication and
operational tests. Such revisions may be made to improve producibility, operability, or functionality; to
reduce unenvisioned production, operating, or maintenance costs; or to remedy unwanted legal,
societal, or environmental impacts.
Of course, design changes made at this last step typically are far more expensive and time consuming
than changes made earlier in the design cycle.
The introduction of computer-aided design (CAD) tools and computer-basedsimulation has contributed
greatly to the ease of discovering functional design problems “on the drawing board,” while design for
manufacture (DFM) and concurrent engineering concepts have helped to anticipate the number of
conceptual, production-related, and postproduction design flaws.
DESIGN TOOLS
CAD, CAE, CAM, and CIM
Computer-aided design (CAD) refers to the use of modern computing hardware and software in
converting the initial idea for a product into a detailed engineering design. In CAD, computer graphics
replace the traditional sketches and engineering drawings used to visualize products and communicate
design information.
Engineers also use specialized computer-based analysis programs to estimate the performance and cost
of design prototypes and to calculate optimal values for design parameters. When combined with CAD,
these automated analysis and optimization capabilities are called computer-aided engineering (CAE).
DESIGN TOOLS (Continued)
Computer-aided manufacturing (CAM) refers to the use of computers in converting engineering designs
into finished products. In CAM, computers assist managers, manufacturing engineers, and production
workers by automating many of these production tasks. Computers help to develop process plans, order
and track materials, and monitor production schedules. Computers also help to control the operation of
machines, industrial robots, test equipment, and the systems that move and store materials in the
factory.
The goal of computer-integrated manufacturing (CIM) is a common database, created and maintained on
a factory-wide computer network, that will be used
for design, engineering analysis and optimization, process planning and production scheduling, part and
robot programming, material handling, inventory control, maintenance, and marketing.
DESIGN TOOLS (Continued)
CAD Workstations
The CAD system allows the designer to create a model of the product in computer memory, display
different views of the model on the terminal, modify the model as desired, save different models in a
database for later recall, and make hardcopies of design notes and engineering drawings as need.

Solids modeling is the basis for most current CAD systems, because the information in the model
database represents a distinct solid object, completely and unambiguously. Complicated solid objects are
built up by adding and subtracting simpler geometric shapes—cubes, slabs, cylinders, and cones—called
primitives.
Many CAD systems currently are used as sophisticated, electronic drafting devices. This has many time-
and labor-saving advantages. In the future, as CAD, CAE, and CAM are integrated into CIM,
The CAD model will become part of a common database for the entire design and manufacturing product
cycle.
DESIGN AND CONCURRENT ENGINEERING
Design for manufacture (DFM) applies the systems method to the manufacturing enterprise by
simultaneously considering all design goals and constraints for the products and systems that will be
produced. In many industries, DFM has become a central concept for survival in increasingly competitive
global markets. One of the important lessons of DFM is that consideration of manufacturing issues early
in the design phase can reap
substantial benefits. These include savings in set-up and production costs, reduction of lead times
required to bring a new product to market, reduction of parts inventories and associated overhead, and
improvements in overall
product quality and reliability. Successful applications clearly demand a great deal of domain-specific
expertise.
DESIGN AND CONCURRENT ENGINEERING(Continued)
DFM Philosophy
DFM is born from the recognition that the delivery of a product to market typically requires complex
interactions among a number of distinct activities, including the following:
• Market analysis and product selection
• Product and component design
• Material selection
• Component and material purchasing and inventory
• Fabrication technology and tool selection
• Material handling and process control
• Assembly
• Test and rework
• Marketing, sales, and distribution

• These activities, individually and in combination, ultimately determine the quality and cost of a product,
as well as the time-to-market of new or improved products.
• DFM is synonymous with concurrent or simultaneous engineering, or integrated product development.
• More narrowly, DFM focuses on the specific subset of interactions between the product design process
and each of the various manufacturing subsystems, in order to develop products that are easier, faster,
and less expensive to make, service, and retire, while maintaining required standards of quality and
functionality.
• For many different kinds of products, as much as 70% of the ultimate manufacturing cost is established
during the design phase. By designing aproduct in such a way as to minimize the effort required for its
manufacture, very often it is possible to reduce costs, while improving the quality of the product, without
loss in functionality or performance.
• The basic goal of value engineering is maximum performance per unit cost. This goal is pursued, first, by
altering the detailed design in ways that reduce cost while maintaining performance and, second, by
identifying and modifying manufacturing methods that realize additional savings.
• Value engineering and producibility engineering are artifacts of a serial view of the
design/manufacturing product cycle illustrated in Figure 13.5. Issues of product function and life are
addressed by the design section and result in detailed design concepts.
Figure 13.5 Classical (linear) model of product development
Salomone (1995) discusses key organizational issues in the implementation of concurrent engineering:
1081
• Collaboration Among Team Members. Collaboration—literally, “working together”—is usually expre
• Virtual Teams. Effective collaboration should occur beyond the team, including the full function of
organizations within the firm, as well as suppliers, customers, consultants, resellers, and distributors, and

in some cases collaboration with other companies on the development of a single product or technology.
ssed in terms of teams and teamwork.
• Establishment of Formal Concurrent Processes. The fundamental thought process of concurrent
engineering is a process of convergence, where large scale collaborative thinking leads to innovative
ideas, market understanding, and product and process knowledge [ultimately resulting in] an engineered
product and processes for manufacturing and marketing [that product]
• Implementation of Information Technology. “Information technology has become the foundation
enabler that allows concurrent engineering to happen.” This extends beyond the use of shared CAD
(computer-aided design), CAM (computer-aided manufacturing), and CAE (computer-aided engineering)
systems, which provide automated design, drafting, and analysis functions, to include:
Simulation technologies
Rapid modeling and prototyping
Data libraries
Communication technologies
Network technologies linking external collaborators
Network technologies linking customers
Ettlie and Reifus (cited by Stoll, 1986) report that the following innovations characterize the
organizational shift to DFM in many industries:
• Design manufacturing teams
• Shared CAD systems for design and tooling
• Common reporting positions for computerization
• Philosophical shift to DFM
• Development and promotion of the engineering generalist or systems engineer

Given their common origins in the observations of experienced designers, the general principles for DFM
most often cited are tellingly similar to the design axioms and corollaries outlined in the preceding
section. These include the following:
• Minimize Total Number of Parts.
• Develop a Modular Design.
• Use Standard Components.
• Design Parts to be Multifunctional.
• Design Parts for Multiuse.
• Design Parts for Ease of Fabrication.
• Avoid Separate Fasteners.
• Minimize Assembly Directions.
• Maximize Compliance.
• Minimize Handling.
Design for X
Product design can be viewed as an optimization problem, with multiple design objectives and
constraints. These objectives very often conflict and in many cases are noncommensurate (performance
cannot be measured in the same units). Narrowly interpreted, DFM can be viewed as a reformation of
the design problem, where the designer seeks to minimize manufacturing costs, subject to constraints
imposed by performance requirements, as well as by the available materials, purchased parts and
components, and manufacturing technologies.
Viewed in this way, it should be clear that the objectives of product design should not be limited to just
functional and manufacturing issues.
All phases ofthe product life cycle—from product concept to retirement—should be considered in the
early design phase and corresponding methodologies developed to facilitate this end. This more inclusive
interpretation of DFM is sometimes called Design for X (DFX), where “X” can be taken from any of a long
list of relevant design objectives, with all other objectives (perhaps) treated as constraints.

Recent work includes component (if still isolated) aspects of a total DFX vision:
• Design for disassembly (product disposability)
• Design for green, or design for environmentally conscious manufacture
• Design for maintainability and service evaluation
• Design for inspection
• Design for reliability
• Design for quality
• Life-cycle design
• Some of these design objectives are compatible and some are not.
• For example, design for disassembly is clearly compatible with design for green and design for
maintainability, since recycling and maintenance typically involve disassembly, albeit to differing degrees.
• On the other hand, designing for ease of service can adversely impact ease of assembly, since
assemblies that are easy to put together are not always easy to take apart. In many such cases, different
aspects of the product’s life
cycle cannot be optimized simultaneously and the designers must make trade-offs.

IT440 – Week11
Software Design and Software Implementation
Software Design
v Purpose: develops software requirements in defined designs of a work product.
§ Used by software designers
§ documented according to program and project plans, ideas, processes, and procedures and
applicable internal work instructions.
Development plan
v Purpose: a well-defined process useful for implementation and applicable standards.
v Tasks: identify major software functions (components), functional hierarchy diagrams, and
hardware/software interfaces.
Software design decision
Explain design decision?
v provides design concepts and decisions for a work product.
§ Analysis and integration of software requirements definition and the software operational
concepts identify the capabilities and characteristics required to make key design decisions.
§ Software designer uses software design tools for requirements, code development,
configuration management (CM), and software documentation.
Software Requirements Evaluation
Purpose: defines software operational scenarios to ensure problems affecting software design
are identified, evaluated, and resolved.
§ A risk analysis using prototype software is performed to support early requirements
evaluations and design feasibility.
§ If requirement is proven unusable and not to be implemented for use, data from evaluations is
fed back into the output of the software requirements development phase.
Software Reuse
v Purpose: identifies evaluations by software architecture definitions on how to decide on the
incorporation of components into the software design.
peer reviews
v Purpose: to find and correct as many errors as possible before test team integration or
customers find problems.
§ Starts with requirements, design models, and uninterrupted code and unit tests for the
software designer.
§ Applied at various stages during the software design/development life cycle
§ Creates clean software work products and provides assurance that issues or errors are
discovered and resolved.
Khloud alsehli

Examples Of Peer Review Methods
List of Example of peer review methods?
Peer Reviews Criteria
Software design/development methods
List and compare between the two methods used for Software design/development?
v Concurrent Software/Design Development
§ Requirement: software design expertise to anticipate where the defined design is going
§ Con: possible to delay commitment until the last moment when failure to make a
decision eliminates an important alternative or decision
v Lean Software Design/Developmen
§ Objective: to move as many changes as possible from the top curve to the bottom curve.
§ Delays the freezing of all design decisions as long as possible.
§ Emphasizes designing and managing changes throughout the life cycle.
§ Provides a better understanding of software engineering and quick delivery to customers
Inspections Structured walk - throughs Deliberate refactoring Pair programming
Schedule the
Peer reviews
At a convenient
time
Assign
reviews
Prepare / update
Materials
Provide
checklists
Introduce training
materials
Select
software
Work
products
Provide
Entry And
exit criteria
Khloud alsehli

AGILE SOFTWARE PROCESSES
What are the features or properties for agile software process?
§ Provides fewer defects.
§ Supports numerous initiatives
§ Provides a program and project with a manager’s approach to emphasize short-term
program and project planning.
§ Adopts values that are consistently depicts processes and makes decisions that may
reject a software design.
§ More effective than the traditional models due to perfection versus good-enough
concepts for software design practices
§ Provides capability to understand information first before jumping into software design
and development.
Four Key Elements Of Agile Software Engineering
1. The team has control of work assignments
2. Communication with team members and customers is needed
3. Change is good: “Think outside the box”
4. Customer satisfaction and expectations are achieved
Configuration management
v CM methods are a supporting discipline not directly involved in creating executable code. In
the Agile process, CM methods are not referenced for specific routines.
v CM Purpose: trim process and provide more automation in tools
v When Agile processes lack configuration control, Lean principles are a waste of time and
lead to chaos. As a result, there is no progress in software design/development.
SOFTWARE STANDARDS
v Purpose: ensures development processes are in accordance with identified process models.
v Minimum software standards consist of the following:
§ Documented and maintained plans and procedures
§ Peer reviews
§ Standard software tools
CAPABILITY MATURITY MODEL INTEGRATION
v Purpose: provides opportunity to address software design/development with support to
customers after delivery.
§ Provides a systematic approach to software engineering tasks in programs and projects.
§ Enhance the knowledge base for software designers.
§ Provides content for performance during the software life cycle
Khloud alsehli

CMMI Software Engineering Tasks
What are the CMMI software engineering tasks?
§ Identify internal and external interfaces
§ Establish infrastructure abilities with software design
§ Develop plans, processes, and procedures
§ Reuse capabilities for identified software
Lean Six Sigma
v Purpose: reduces process variation, resulting in fewer errors and defects.
v Six Sigma Process:
1. Define
2. Measure
3. Analyze
4. Improve
Lean Goal: Eliminate eight wastes
What are the eight wastes that Lean Goal Eliminate?
1. Defects
2. Overproduction
3. Waiting
4. Nonutilized talent
5. Transportation
6. Inventory
7. Motion
8. Excess processing
Software Design/Development
v Purpose: secure databases related to software.
Software Implementation methods
v Purpose: provides assurance that software engineering builds function as expected and
enables smooth execution for verification and validation activities.
CONFIGURATION MANAGEMENT
v Purpose: ensures configuration management practices are applied consistently throughout
the software life cycle for programs/products.
v Team Focus: identifies and manages changes and maintains software configuration and
documentation visibility.
v Processes: controls storage, access, changes, archive, and release of the software work
products.
v Procedures: describes implementation of processes required to meet requirements and
direction provided under plan association and documentation.
Khloud alsehli

Build Requests
v Purpose: provides checklists to assemble, compile, link source code, build archive copies,
and provide listings for use in software design/development, test, and work product
customer delivery.
v Processes: include the capability to package builds and documentation together.
§ Requires coordinated communication between internal and external teams to be
efficient and available for scheduled tests or configuration checkouts.
BUILD ENGINEER ROLE
§ Creates build folders to store documentation of software building
§ Provides source code changes and control of the source code
§ Maintains and controls records during program and project development
CONFIGURATION MANAGEMENT TOOLS
What is the purpose of configuration management tools?
v Purpose: provides the capabilities for adding new files to a software design/development
environment in addition to providing version control to directories and files.
What are the essential elements?
v Essential Elements:
1. File sharing
2. parallel software design/development
3. multiple team support
4. software reuse to ensure integration test activities demanded by the schedule.
IBM Rational ClearCase
Compare between the IBM relational ClearCase and IBM Rational ClearQuest?
v Definition: An object-oriented database utility provided to establish software product
archiving, automation, identification, version/change control, engineering building, product
releases, status accounting, and auditing activities.
v Purpose: provides an open architecture to implement configuration management and
control solutions.
IBM Rational ClearQuest
v Purpose: provides support for change request management processes and is a ClearCase
complementary tool.
v Use: recording, tracking, and reporting and provides internal access control mechanisms for
permitting the restriction of work product updates throughout the various stages of
software design/development, integration and test, and production processes.
Khloud alsehli

ClearCase Roles
§ Architect
§ Configuration manager
§ Lead
§ Software design engineer
§ Build engineer
SOFTWARE MEDIA AND DATA
v Physical software media identification and labeling must be in accordance with program
and project documented media requirements.
v Media Label Documentation Items:
What is media label documentation items?
§ Date: Day/month/year format
§ Title: Document the title of the software being produced
§ Derived from: Program and project
§ Special handling: Distribution requirements
§ Contract number: Document contract number
§ Part number: Document software identifier
§ Software version: Media version
Khloud alsehli

Week 12
Rawan...
It440 System Integration Summary
1. Systems Integration
Systems Integration is a logical, objective procedure for applying new
and/ or expanded performance requirements in an efficient, timely
manner to the design, procurement, installation, and operation of an
operation configuration consisting of distinct modules (or subsystems),
each of which may embody inherent constraints or limitations.
2. Systems Integration in Large, Complex Engineered Systems and a
Systems Integration Life Cycle
• The methodologies of systems engineering and systems management
are incorporated to form a formal approach to carry out SI programs.
• The organizational approach to SI is to view the program from the
perspective of a systems development life cycle.
• The SI life cycle is both interactive and iterative.
A Seven-phase life cycle
1) Requirements definition and specification – The goal is to
completely define and correctly interpret the client’s real needs.
2) Feasibility analysis
• system performance criteria must be established
• The risk potential should be assessed.
• The criteria must be developed on a functional basis
3) Systems architecture development – Establish required technical
expertise.

Week 12
Rawan...
4) Management plan – Program and project plan
5) Systems design – Logical and physical design
6) Implementation – Design implementation, system tests, and
operational development
7) Evaluation – System review and plan for replacement /
retirement.
3. Systems Integration Management and Technical Skills and Training
Requirements
Functional activities performed by Systems integration professionals include:
• Conduct general studies of needs to realize improved system
performance
• Develop detailed specifications and designs
• Conduct risk studies and implement risk minimization strategies
• Perform system analysis and design
• Develop hardware and software design
• Employ project planning and control
• Perform business management and accounting
• Develop and nurture relationships with customers and
subcontractors
• Develop hardware design and specification
• Carry out configuration management
• Accomplish testing
• Implement technology-based solutions to business needs
• Train users of new systems

Week 12
Rawan...
4. Systems Integration Strategy for Success
• The client and the corporation should have a well-articulated strategy
for development and implementation of the systems integration
program
• Strategy must be business oriented and cost effective
• Prior to develop or accept an systems integration program, strategic
plan must be developed
• It is necessary to know how to start with requirements specifications
for the client
• Both the client and contractor must be skilled in systems integration
Rules for Success
• Have a Commitment by Client and SI Organization
• Understand the Objectives of the Program and How to Measure
Progress Toward These Objectives
• Have an Overall Strategic Design Plan
• Have an Overall Management Strategy
• Have a Quality Assurance Strategy in Place
• Provide for Personnel Preparation
• Have In-place Cost Management and Control Procedures
• Have a Plan to Manage Subcontractors
• Have a Plan for Handling Exigencies
• Have a Risk Assessment Plan
• Have an Action Plan for Development of an Audit Trail
• Have a Performance Evaluation Plan

Week 12
Rawan...
Strategy Implementation
• Top-down approach
Concerned with long-term issues related to the structure and
architecture of the overall system.
• Bottom-up approach
Concerned with detailed designs and with parallel efforts to make
existing systems more efficient and effective.
Also consider the existing hardware and software that are not subject
to change.
Risk Management as Part of the Strategic Plan
• Provisions for risk assessment must be included.
• The corporation and the client must included processes and
procedures that examine and assess the impact of risk.
5. The Audit Trail
Essential tasks to ensure that an audit trail is properly developed and
embedded in SI program plan
• Review the requirements in detail that are accepted from the client
• Track program progress
• Resolve problems that occur
• Assign metrics to determine when these problems have been resolved
satisfactorily
• Establish requirements for subcontractors to procure, deliver, and
install the items called for in the subcontract
• Document all of this in a database, and update this over time

Week 12
Rawan...
Embedding the audit trail with the three-step process:
• Issue identification
• Issue formulation
• Issue resolution
Steps to Embed an Audit Trail in SI program:
• Document system-level requirements into a database
• Establish whether or not issues are present and, if so, resolve them
• Assign appropriate validation and verification metrics
• Establish guidelines for subcontractors
• Provide solid unambiguous procurement instruments
• Track these activities from specifications through installation and
operation
6. Quality Assurance in Systems Integration
• Quality is a subjective term
• Quality means different things to different observers
• According to Department of Defense, USA
Software quality is the degree to which the attributes of the software
enable it to perform its specified end-item use
• According to IEEE
Quality assurance is a planned and systematic pattern of all actions
necessary to provide adequate confidence that the item or product
conforms to established technical requirements.
Quality assurance is concerned primarily with
• Detection of the existence of faults
• Diagnosis of the type and location of the fault
• Correction of the fault

Week 12
Rawan...
Quality assurance and testing can be conducted from either
• A structural perspective
The system is tested in terms of micro-level details that involve
attributes such as throughput capability, cycle time etc.
• A functional perspective
Quality assurance and testing involves treating the system as a black box
and determining whether the performance conforms to the technical
requirements specifications.
• A purposeful perspective
The system must be tested to determine whether it does what the client
really wishes it to do. Also known as validation testing.
(Verification and validation) ‫بينهم‬ ‫نفرق‬ ‫مهم‬
• Verification and validation are quality control techniques and a part of
quality assurance.
• The verification seeks to determine whether the software product is
being built correctly whereas validation seeks to determine whether the
right product has been produced from an assumed set of correct
specifications.
SI programs undergo the following steps
• Identification of need and specification of requirements
• Initial design and development
• Controlled introduction to a client
• Release to client
• Modification to meet evolving needs
• Transition to a new environment
7. Subcontractor Management for Systems Integration
• Have a set of processes and procedures that are directly related to the
activities of subcontractors (T/F)
• Terms and conditions should clearly state the needs and requirements
of the SI project that are to be fulfilled by the subcontractor (T/F)

Week 12
Rawan...
The Systems Integrator is responsible
• To elaborate the functional point of view of the organization and
procurement efforts to the subcontractor.
• To help the subcontractor in establishing a parallel technical auditing
process.
8. Subsystem Integration and Delivery
Some of the more important activities include:
• Organize overall team support for the subsystem integration and test
activity
• Validate incremental deliveries as these are made by a subcontractor
• Prepare the various subsystems for test and evaluation prior to
integration
• Integrate hardware/software subsystems from subcontractors with
systems developed by the corporation and legacy systems.
• Monitor test activity and assure that all tests conform to the system
testing regimens agreed by the client
• Provide for both Alpha and Beta site tests
• Conduct necessary posttest activities to review outcomes with all
concerned parties
• Conduct formal reviews and review documentation
• Provide for failure recovery and error correction in the event
subcontractors are unable to meet design specifications
Validation Test Document contains a conceptual discussion of items including:
• Traceability
• Potential conflicts and resolution procedures
• Risk analysis and management
• Consistency of requirements
• Potential ambiguities in evaluation procedures
• Testability

Week 12
Rawan...
9. Risk Management
Risk to an SI program originates from
• Functional requirements
These sources are determined by technical aspects of the project such as
architecture, design, performance, and test
• Nonfunctional requirements
These sources include parameters such as management, political
climate, team capability, and cost.
Risk assessment is obtained by taking the product of two parameters
• The probability of occurrence
• The severity of impact
Components of a Risk Management Plan for SI
• Identification of “at-risk” system components
• Risk analysis
• Risk avoidance measures
• Risk management
• Internal processes and procedures to handle risk
10.The Lead Systems Integrator
• Lead System Integrator (LSI) is an organization that plans and
coordinates development activities for engineering a system of systems
(SOS).
• LSI can be a government, a contractor, or a contractor team
LSI defines
• The scope of the system of systems
• Plan activities to be performed
• Analyzes the requirements
• Starts developing the system of systems architecture
LSI is faced with several key management issues
• Large number of stakeholders
• Large number of development organizations
• Many concurrent development efforts and their associated
dependencies
• Many decisions “approvers”
• Risks that cut across organizational boundaries

By Amal Khoja
IT440 System Integration
Week 13
Human Systems Integration
1.HSI Concept:
Human Systems Integration (HSI) includes formal processes and programs designed to
integrate people into systems engineering and management processes.
HSI concept can be defined and illustrated in four ways:
1- Key benefit areas
2- Organizational and technical domains
3- Conceptual model
4- HSI in systems acquisition
Key Benefit Areas
• Management and organization
• Operational processes
• Product design
• These benefit areas represent three types of audiences who could benefit from HIS
applications and have different needs
1- Managers having high levels of responsibility for systems decisions
2- Individuals concerned with the operational processes within the organization
having day-to-day concerns of system progress
3- People close to the technology and engineering disciplines having direct roles
in designing and testing a product

By Amal Khoja
TABLE 31.1. HSI Activities by Benefit Areas
In this table Compares three examples of HIS applications (user focus, integration,
performance, measures) for the different systems engineering audiences
HSI Domains
• Organizations define their programs in terms of the organizational and
technical domains already inherent in their organizations.
Organization domain functions that are internationally recognized as disciplines or fields
and these four domains are:
• Manpower
• Personnel
• Training
• Human factors engineering
Three primary lessons have been learned from defining HSI by domains:
• Domain definition is necessary for any organization attempting
to develop and apply the HSI concept to its institution
• The domains having critical human factors influence on
systems under the jurisdiction of a particular institution must
vary to fit the organization
• An HSI integrator of the domains is necessary
HSI Conceptual Model
HSI process is central to the systems engineering and management process.

By Amal Khoja
HSI process is essential for three fundamental stages of systems processing including:
• Systems definition
• Systems development
• Systems deployment
• HSI process must be passed through to create resultant systems integration of people,
technology, and organization.
HSI in Systems Acquisition
HSI is defined as a comprehensive management and technical program that focuses on
the integration of human considerations into the systems acquisition process
• Both management and technical aspects must be considered collectively
• If any of the three factors (focus, integration, human), the program is not an HSI
program
• Only those systems and products are included that are developed, used, and operated
under a formal acquisition process
2. HSI Assessment Principles and Factors
HSI principles that can be used as criteria for building an HSI program or in assessing the
program effectiveness.
Ten principles as crucial to effective HSI:
1. Top-level leadership
2. Focus on human-centered design
3. Source selection policy
4. Organizational integration of all HSI domains
5. Documentation integration into procurement process
6. Quantification of human parameters
7. Human systems integration technology
8. Test and evaluation/assessments
9. Highly qualified practitioners
10. Education and training program
3.HSI Business Case
The primary strategy of HSI for an organization is to introduce key processes and
capabilities relate to people that enable acquisition programs to optimize total systems
performance while minimizing total cost of ownership

By Amal Khoja
4. HSI Process in Systems Engineering
Process Models
Incremental Commitment Model (ICM) is the best process model for HSI systems
development
ICM identifies:
• concurrently engineered life-cycle phases
• the stakeholder commitment review points
• their use of feasibility rationales to assess the compatibility, feasibility and risk
associated with the concurrently engineered artifacts
• and the major focus of each life-cycle phase.
Principles of System Development:
1- Stakeholder satisficing
2-Incremental growth of system development and stakeholder commitment
3-Iterative system definition and development
4-Concurrent system definition and development
5-Risk management – risk driven activity levels and anchor point milestones
System Acquisition Phases and Milestones
There are three overarching phases:
1- Pre-systems acquisition
2-Systems acquisition
3-Sustainment
Figure 31.4 System acquisition phases with principal activities.

By Amal Khoja
Requirements, Design, and Verification Loops
• The relationship of requirements, design, and verification functions of a system
development process is shown in Figure 31.5.
• Requirements always precede and drive design and development, and verification
determine if the design is meeting the requirements.
• Iterative loops are continually refining requirements and design but at some point a
decision must be made to settle on a design that is made into something physical with the
goal of producing the system or product.
Figure 31.5. HSI activities in systems engineering process
HSI/ SE Interfaces:
• Risk management
• Critical system documents
• Shared representations
• Function allocation
• Performance measures
Risk Management: Decisions at critical milestones lead to four possible outcomes
• The risks are negligible
• The risks are acceptable
• The risks are high but addressable
• The risks are too high and not addressable

By Amal Khoja
Critical System Documents that govern the acquisition process:
1. Initial Capabilities Document (ICD)
2. Concept Development Document (CDD)
3. Request for Proposals (RFP)
4. T&E Master Plan (TEMP)
5. Cost–Benefit Analysis
6. System Training Plan (STRAP)
7. Capability Production Development (CPD)
Shared Representations:
Communication among the various systems engineering disciplines is accomplished with
a variety of methods including:
• Written text through specifications and standards
• Engineering drawings
• Computer and physical models
HSI analysis products need to be communicated in such a way that all engineering
disciplines and project stakeholders can understand the HSI issues and design
recommendations.
• Representations that can be shared by teams of people from different perspectives allow
a medium through which the thinking behind the representation can be examined
critically and reduce working memory load
• Shared representations also play a role in collaborative and iterative construction of
knowledge in the design process and in creating innovative solutions.
• The best representations are those that can be used to establish a shared language and
facilitate a social process
Function Allocation is the assignment of systems functions to hardware, software,or
people.
• Hardware and software engineers are responsible to determine the capabilities of
designs to accomplish hardware / software functions.
Two major roles for HSI participation in function allocation decisions:
1- Recommend those functions that are best allocated to people because of performance,
safety, or policy reasons.
2- Evaluate of hardware / software functions for constraints imposed on the user
Performance Measures for a system or product
• Cost
• Schedule
• Performance
• HSI measures

By Amal Khoja
• Human performance
• Industrial engineering
• Human physiology
• Subjective measure
• Team measures
HSI Expertise include:
• HSI communities’ areas of expertise:
Specialized HSI expertise is drawn from two major sources:
(1) the domains that make up the human-related activities like manpower, personnel,
training, and human factors engineering
(2) special HSI integrating activities that cut across domains.
• HSI documents and working groups
there are several critical documents and working groups that involve HSI leadership roles
HSI Methods and Tools
Extensive tools are available supporting different purposes at the highest level, the main
purposes of HSI analytical aids are to facilitate systems and equipment that
• Incorporate human-system interfaces
• Make realistic and economical demands on personnel numbers, skills, and need for
training
• Minimize total cost of ownership
• Manage risk of loss, injury, and damage to personnel, equipment, or
the environment
HSI methods and tools can be classified in three ways
1-Techniques that apply to various activities in the systems
acquisition process
2-Techniques that apply to specific HSI domains
3-Techniques that have unique system design purposes
Representative HSI Tools
• IMPRINT
• JACK
• WinCrew

Week 14
Rawan...
It440 System Integration Summary
1. Software Media and Data Delivery
• Software work products are identified in program and project
development plans. (T/F)
• Identification approach assigned to released software and
accompanying software documentation. (T/F)
Software Documentation
• Purpose: provides defined/documented releases for varying levels of
software and systems integration.
Use:
• Systems engineering plan (SEP)
• Development plan (DP)
• Software configuration management plan (SCMP)
• Software test plans and procedures
• Software and systems integration plan (SSIP)
• Quality plan (QP)
• Documentation for version control
• Build and installation procedure
Version Control Documentation
• Documentation: provides version control to identify and describe
software versions of existing work products.
• Use: release, track, and control software versions at software and
system levels.

Week 14
Rawan...
Build and Installation Procedure
• Purpose: details description of how to build and install software for
systems integration.
• Responsibility: configuration management team, with input from
software designers, procedures for software and systems integration
builds.
• The CM organization is responsible for the development, control,
and release of build and installation procedures.
Delivery Package
• Consists of software media and documentation associated with the
version of the software, printed copies, and identified system work
products or hardware packages.
• Purpose: used to meet contract delivery requirements program
agreed to accomplish.
• Responsible Parties: senior management and program/project
managers in addition to identified teams
Final Software and Systems Delivery
• This is the last delivery after program and projects have completed
the FAI and FCA/PCA.
• Purpose: provides processes and procedures to ensure all aspects
are correctly accomplished.
• Result: programs and projects are able to sustain continuous
improvement.
• Risks: ineffective delivery systems.
• Global Market Survival: programs and projects must continuously
improve their work products, services, and delivery systems.
• Programs and Projects: create work products and services to meet the
needs of the customer.
(FAI and FCA/PCA) ‫بينهم‬ ‫نفرق‬ ‫مهم‬

Week 14
Rawan...
2. First Article Inspection (FAI)
• Purpose: examines subcontractor production units and determines
whether the software is ready for delivery to the customer.
• Subcontractors: work with customer’s engineering teams to finalize
regression analysis.
Checklists
✓ Verification requirements
✓ Data package
✓ Version control document
✓ Verification process
✓ Product release
✓ Acceptance test
✓ FAI completion
3. Functional Configuration Audit (FCA)
• Purpose: verifies work product performance complies with the
hardware, software, and interface requirements specification (IRS).
• Requirement: test data must be reviewed and verified in addition to
showing that the hardware and software perform as required by
configuration identification.
• Must have a technical understanding to accomplish the concerning
the validation/ verification per the TP concerning software,
• Use: to provide the prerequisite to acceptance of a configuration
item.
Activities
• Verifies work product performs to required configurations.
• Changes release for major or minor engineering
• Establishes baseline for product and configuration

Week 14
Rawan...
4. Physical Configuration Audit (PCA)
• Purpose: identifies the baseline for production and acceptance of the
work product configuration
• Ensures acceptance test requirements are comprehensive and meet
the necessary requirements for acceptance.
• Demonstrates management systems for quality, engineering, and
configuration management information accurately control configuration
of subsequent production units.
• Option: current conduction with the FCA.
Activities
• As-built configuration in correlation with the as-designed product
configuration.
• Determine acceptance test requirements in accordance with quality
assurance.
• Release engineering changes.
• Establish final product baseline.
5. Quality Assurance
• Purpose: provides product evaluation processes and specific quality
assurance for effective software engineering methods and software
tool use.
• Team Responsibility: to ensure compliance to software
design/development standards and control work products.
• Application: throughout the software design/development
processes.
• Management: summarized in engineering reviews, change control, or
subcontractor audits and compliance to standards, verification, and
validation.

Week 14
Rawan...
Software Quality Plan
• Purpose: describes/documents software quality assurance
roles/responsibilities
• ensures programs and projects are following procedures and processes
• provides a documented process for assessing software life-cycle
processes and their outputs
• Audits: ensure compliance with released processes and AS9100C for
measurement, analysis, and improvement activities to be conducted
Program and Project Managers
• Definition: an example list that program and project managers are
responsible for producing.
• Includes: issues relating to team objectives, risk mitigation issues and
concerns, root cause (RC) analysis, Corrective Action (CA) plans, and
significant accomplishments.
• Focus: team, processes, and work product.
6. Product Evaluation Schedule
• Purpose: performs product evaluations and ensures software
design/development.
• Test and integration phases: conducted according to a product evaluation
schedule.
7. Artifacts
• Include: software configuration records, testing records, and other
artifacts associated with activities.
• Additional Components of Inclusion:
• Audit records (i.e., electronic or paper) associated with product
evaluations
• Audit and product evaluation checklists
• Audit results and audit reports

Week 14
Rawan...
8. Audit Findings
• Purpose: utilize criteria audit finding derived from software plans and
internal procedures to perform scheduled product evaluations.
• Product Evaluations: include a review of plans and procedures that
oversee programs and projects, a review and analysis of the results of
previous product evaluations, an assessment of whether implemented
processes are compliant, clearly defined issues or opportunities for
improvement, and any additional product evaluations that are required.
• Results: recorded in evaluation plans and added into databases
recording summary information from evaluation performance.
• Quality Team Use: to indicate if processes are compliant, noncompliant,
or if there is an opportunity for improvement.
9. Corrective Actions
• Purpose: to eliminate the cause of a detected nonconformity or other
undesirable situations and prevent recurrences during product
evaluation.
• Two Types of Initiated Corrective Actions:
• The root cause: requires root cause analysis and actions taken to
address the analysis.
• The immediate action: taken to address a direct cause and prevent
recurrence of a specific nonconformity.
10.Quality Metrics
• Purpose: ensures program and project’s delivery schedules, what is in-
work, and completed product evaluations
• Achievement Requirements: effective methods and current software tools
must be used
• Measurement Responsibility: trained senior managers and program and
project managers

Week 14
Rawan...
11.Quality Management System
• Required to have processes documented and executed with
knowledgeable people and teams
• Purpose: provides the framework for philosophy of “do what you say,
prove it, and show improvement”
• Standards: AS9100, AS9100C, AS9100D, SAE AS9110, and ISO 900
• Support Basis: conducting product evaluations, reviews, and audits for
compliance to requirements insurance
12.Software Process
• Purpose: enforces process needs and follows these processes when
product evaluations are conducted
• Assessment: ensures process meets a set of basic criteria to show
successful software engineering practices
• Leads to effective software and systems integration to improve
processes
Software Reviews
• Purpose: provide the framework and detailed requirements for
verifying/validating design/development efforts
• Process Improvement: entails communication, understanding, discipline
and deployment
‫مارك‬ ‫الفل‬ ‫وفالكم‬ ‫موفقين‬
.
..
‫دعواتكم‬ ‫من‬ ‫تنسونا‬ ‫ال‬
...

s123.pdf

Recommended

Recommended

More Related Content

Similar to s123.pdf

Similar to s123.pdf (20)

Recently uploaded

Recently uploaded (20)

s123.pdf