SOFTWARE ENGINEERING

UNIT – II
SOFTWARE DEVELOPMENT LIFE CYCLE
MODEL
In this chapter:
✓ Phases Of Software Project
✓ Quality, Quality Assurance And Quality Control
✓ Testing, Verification And Validation
✓ Process Model To Represent Different Phases
✓ Life Cycle Models
✓ System Engineering
✓ Computer Based Systems
✓ The System Engineering Hierarchy

PHASES OF SOFTWARE PROJECT

A Software project is made up of a series of phases. Broadly, most software

projects comprise the following phases
➢ Requirement gathering and analysis
➢ Planning
➢ Design
➢ Development or coding
➢ Testing
➢ Deployment and maintenance.
1. Requirement and analysis Phase

During requirement gathering, the specific requirements of the software to be

built are gathered and documented.
If the software is bespoke software, then there is a single customer who can give
their requirements.\
If the product is general – purpose software, then a product marketing team
within the software product organization specifies the requirements by aggregating the
requirements of multiple potential customers.
In either case, it is important to ensure that the right requirements are captured
at every stage.
The requirements get documented in the form of System Requirement
Specification(SRS) document.
This document acts a bridge between the customer and the designers chartered
to build the product.
2. Planning phase
The purpose of the planning phase is to come up with a schedule, the scope and
resource requirements for a release.
A plan explains how the requirements will be met and by which time.
It needs to take into account the requirements – what will be met and what will
not to be met - for the current release to decide on the scope for the project, look at
resource availability, and to come out with set of milestones and release date for the
project.
The planning phase is applicable for both development and testing activities.
At the end of this phase, both project plan and test plan documents are delivered.
3. Design
The purpose of the design phase is to figure out how to satisfy requirements
enumerated in the System Requirement Specification (SRS) document.
The design phase produces a representation that will be used by the following
phase, the development phase.
This representation should serve two purposes.
First, from this representation, it should be possible to verify that all the
requirements are satisfied.
Second, this representation should give sufficient information for the
development phase to proceed with the coding and implementation of the system.
Design is usually split into two levels – high level design and low-level design
or a detailed design.
The design step produces the system design description (SDD) document that
will be used by development teams to produce the programs that realize the design.
4. Development and coding
Design act as a blueprint for the actual coding to proceed.
This development or coding phase comprises coding the programs in the chosen
programming language.
 It produces the software that meets the requirements the design was meant to
satisfy.
In addition to programming, this phase also involves the creation of product
documentation.
5. Testing
As the programs are coded ,they are also tested.
In addition, after the coding is complete, the product is subjected to testing.
Testing the the process of exercising the software product in pre-defined ways
to check, if the behavior is the same as expected behavior.
By testing the product, an organization identifies and removes as many defects
as possible before shipping it out.
6. Deployment and Maintenance
Once a product is tested, it is given to the customers who deploy it in their
environment.
As the users start using the product in their environments, they may observe
discrepancies between the actual behavior of the product and what they were given to
expect.
Such discrepancies could end up as product defects, which need to be corrected.
The product now enters the maintenance phase, wherein the product is
maintained or changed to satisfy the changes that arise from customers expectations,
environmental changes, etc.
Maintenance is made up of corrective maintenance(fixing customer-reported
problems), adaptive maintenance(making the software run on a new version of an
operating system or database), and preventive maintenance (changing the application
program code to avoid a potential security hole in an operating system code).

QUALITY, QUALITY ASSURANCE AND QUALITY CONTROL

A software product is designed to satisfy certain requirements of a given
customer (or set of customers).
How can we characterize this phrase-"satisfying requirements"?
Requirements get translated into software features, each feature being
designed to meet one or more of the requirements.
For each such feature, the expected behavior is characterized by a set of test
cases. Each test case is further characterized by
1. The environment under which the test case is to be executed;
2. Inputs that should be provided for that test case;
3. How these inputs should get processed;
4. What changes should be produced in the internal state or
environment;
5. What outputs should be produced.
The actual behavior of a given software for a given test case, under a given set
of inputs, in a given environment, and in a given internal state is characterized by
1. How these inputs actually get processed;
 2. What changes are actually produced in the internal state or
environment;
3. What outputs are actually produced.
If the actual behavior and the expected behavior are identical in all their
characteristics, then that test case is said to be passed.
If not, the given software is said to have a defect on that test case.
How do we increase the chances of a product meeting the requirements
expected of it, consistently and predictably? There are two types of methods-quality
control and quality assurance.
Quality control attempts to build a product, test it for expected behavior after
it is built, and if the expected behavior is not the same as the actual behavior of the
product, fixes the product as is necessary and rebuilds the product.
This iteration is repeated till the expected behavior of the product matches the
actual behavior for the scenarios tested.
Thus quality control is defect-detection and defect-correction oriented, and
works on the product rather than on the process.
Quality assurance, on the other hand, attempts defect prevention by
concentrating on the process of producing the product rather than working on defect
detection/correction after the product is built.
For example, instead of producing and then testing a program code for proper
behavior by exercising the built product, a quality assurance approach would be to
first review the design before the product is built and correct the design errors in the
first place.
Similarly, to ensure the production of a better code, a quality assurance process
may mandate coding standards to be followed by all programmers.
As can be seen from the above examples, quality assurance normally tends to
apply to all the products that use a process.
Also, since quality assurance continues throughout the life of the product it is
everybody's responsibility; hence it is a staff function.
In contrast, the responsibility for quality control is usually localized to a
quality control team.
Difference between quality assurance and quality control

Quality Assurance Quality Control

Quality Assurance (QA) is the set of actions Quality Control (QC) is described as
including facilitation, training, measurement, the processes and methods used to
and analysis needed to provide adequate compare product quality to
confidence that processes are established and requirements and applicable standards,
continuously improved to produce products and the actions are taken when a
or services that conform to specifications and nonconformance is detected.
are fit for use.
QA is an activity that establishes and QC is an activity that demonstrates
calculates the processes that produce the whether or not the product produced
product. If there is no process, there is no role met standards.
for QA.

QA helps establish process QC relates to a particular product or

service

QA sets up a measurement program to QC verified whether particular

evaluate processes attributes exist, or do not exist, in a
explicit product or service.

QA identifies weakness in processes and QC identifies defects for the primary

improves them goals of correcting errors.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Verification is an example of QA. Validation is an example of QC.

TESTING, VERIFICATION AND VALIDATION

➢ The narrow definition of the term "testing" is the phase that follows
coding and precedes deployment.
➢ Testing is traditionally used to mean testing of the program code.
➢ However, coding is a downstream activity, as against requirements and
design that occur much earlier in a project life cycle.
➢ Given that the objective of a software project is to minimize and prevent
defects, testing of program code alone is not sufficient.
➢ Timely testing increases the chances of a product or service meeting the
customer's requirements.
➢ When a product is tested with appropriate and realistic tests that reflect
typical usage patterns by the intended users, the chances of the product
satisfying the customer's requirement is much higher.
➢ While testing does not guarantee zero defects, effective testing certainly
increases the chances of customer acceptance of the software.
➢ The purpose of testing is to uncover defects in the system (and to have
someone fix the defects).
➢ Testing is done by a set of people within a software product (or service)
organization whose goal and charter is to uncover the defects in the
product before it reaches the customer .
➢ The purpose of software testing is to find defects in a software product.
➢ Testing is NOT meant to replace other ways of ensuring quality (like
reviews).
➢ It is one of the methods to detect defects in a software product.
➢ There are other methods that achieve the same function.
➢ To be effective, testing should complement, supplement, and augment
such quality assurance methods discussed in the previous section.
 ➢ The idea of catching defects within each phase, without letting them reach
the testing phase, leads us to define two more terms-verification and
validation.
➢ During the requirements gathering phase, the requirements are faithfully
captured. The SRS document is the product of the requirements phase.
➢ To ensure that requirements are faithfully captured, the customer verifies
this document.
➢ The design phase takes the SRS document as input and maps the
requirements to a design that can drive the coding.
➢ The SDD document is the product of the design phase.
➢ The SDD is verified by the requirements team to ensure that the design
faithfully reflects the SRS, which imposed the conditions at the beginning
of the design phase.
➢ Verification takes care of activities to focus on the question "Are we
building the product right?" and validation takes care of a set of activities
to address the question "Are we building the right product?"
➢ To build the product right, certain activities/conditions/procedures are
imposed at the beginning of the life cycle.
➢ These activities are considered "proactive" as their purpose is to prevent
the defects before they take shape.
➢ The process activities carried out during various phases for each of the
product releases can be termed as verification.
➢ Requirements review, design review, and code review are some examples
of verification activities.
➢ Some examples of validation include unit testing performed to verify if
the code logic works, integration testing performed to verify the design,
and system testing performed to verify that the requirements are met.
➢ To summarize, there are different terminologies that may stand for the
same or similar concepts.
➢ For all practical purposes in this book, we can assume verification and
quality assurance to be one and the same. Similarly quality control,
validation, and testing mean the same.

PROCESS MODEL TO REPRESENT DIFFERENT PHASES

A process model is a way to represent any given phase of software
development that effectively builds in the concepts of validation and verification to
prevent and minimize the delay between defect injection and defect detection (and
eventual correction).
In this model, each phase of a software project is characterized by the
following.
➢ Entry criteria, which specify when that phase can be started. Also
included are the inputs for the phase.
 ➢ Tasks, or steps that need to be carried out in that phase, along with
measurements that characterize the tasks.
➢ Verification, which specifies methods of checking that the tasks have
been carried out correctly.
➢ Exit criteria, which stipulate the conditions under which one can consider
the phase as done. Also included are the outputs for only the phase.
This model, known as the Entry Task Verification eXit or ETVXmodel, offers
several advantages for effective verification and validation.
1. Clear entry criteria make sure that a given phase does not start prematurely.
2. The verification for each phase (or each activity in each phase) helps prevent
defects, or at least, minimizes the time delay between defect injection and defect
detection.
3. Documentation of the detailed tasks that comprise each phase reduces the
ambiguity in interpretation of the instructions and thus minimizes the variations that
can come from repeated executions of these tasks by different individuals.
4. Clear exit criteria provide a means of validation of the phase, after the phase
is done but before handing over to the next phase.

LIFE CYCLE MODELS

A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software life cycle.
A life cycle model represents all the methods required to make a software
product transit through its life cycle stages. It also captures the structure in which these
methods are to be undertaken.
In other words, a life cycle model maps the various activities performed on a
software product from its inception to retirement. Different life cycle models may plan
the necessary development activities to phases in different ways.
Thus, no element which life cycle model is followed, the essential activities are
contained in all life cycle models though the action may be carried out in distinct orders
in different life cycle models.
During any life cycle stage, more than one activity may also be carried out.
We will now look at some of the common life cycle models that are used in
software projects.
For each model, we will look at:
 1. a brief description of the model;
2. the relationship of the model to verification and validation activities; and
3. typical scenarios where that life cycle model is useful.
WATERFALL MODEL
The waterfall is a universally accepted SDLC model. In this method, the whole
process of software development is divided into various phases.
The waterfall model is a continuous software development model in which
development is seen as flowing steadily downwards (like a waterfall) through the steps
of requirements analysis, design, implementation, testing (validation), integration, and
maintenance.
Linear ordering of activities has some significant consequences.
First, to identify the end of a phase and the beginning of the next, some
certification techniques have to be employed at the end of each step.
Some verification and validation usually do this mean that will ensure that the
output of the stage is consistent with its input (which is the output of the previous step),
and that the output of the stage is consistent with the overall requirements of the system.

The sequential phases in Waterfall model are –

• Requirement Gathering and analysis − All possible requirements of the system
to be developed are captured in this phase and documented in a requirement
specification document.
• System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.
• Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality, which is referred to as Unit
Testing.
• Integration and Testing − All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done;
the product is deployed in the customer environment or released into the market.
 • Maintenance − There are some issues which come up in the client environment.
To fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment.
Waterfall Model - Advantages
Some of the major advantages of the Waterfall Model are as follows −
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Waterfall Model - Disadvantages
The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow

identifying any technological or business bottleneck or challenges early.

PROTOTYPING AND RAPID APPLICATION DEVELOPMENT MODELS
The prototype model requires that before carrying out the development of
actual software, a working prototype of the system should be built.
A prototype is a toy implementation of the system.
A prototype usually turns out to be a very crude version of the actual system,
possible exhibiting limited functional capabilities, low reliability, and inefficient
performance as compared to actual software.
In many instances, the client only has a general view of what is expected from
the software product. In such a scenario where there is an absence of detailed
information regarding the input to the system, the processing needs, and the output
requirement, the prototyping model may be employed.
Steps of Prototype Model
1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product
Advantage of Prototype Model
1. Reduce the risk of incorrect user requirement
2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.
Disadvantage of Prototype Model
1. An unstable/badly implemented prototype often becomes the final product.
2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper requirement analysis,
design, customer evaluation, and feedback.
5. Prototyping tools are expensive.
 6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

RAPID APPLICATION DEVELOPMENT MODELS

RAD is a linear sequential software development process model that emphasizes
a concise development cycle using an element based construction approach.
If the requirements are well understood and described, and the project scope is a
constraint, the RAD process enables a development team to create a fully functional
system within a concise time period.
RAD (Rapid Application Development) is a concept that products can be developed
faster and of higher quality through:
o Gathering requirements using workshops or focus groups
o Prototyping and early, reiterative user testing of designs
o The re-use of software components
o A rigidly paced schedule that refers design improvements to the next product
version
o Less formality in reviews and other team communication

The various phases of RAD are as follows:

1.Business Modelling: The information flow among business functions is defined by
answering questions like what data drives the business process, what data is generated,
who generates it, where does the information go, who process it and so on.
2. Data Modelling: The data collected from business modeling is refined into a set of
data objects (entities) that are needed to support the business. The attributes (character
of each entity) are identified, and the relation between these data objects (entities) is
defined.
3. Process Modelling: The information object defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business function.
Processing descriptions are created for adding, modifying, deleting, or retrieving a data
object.
4. Application Generation: Automated tools are used to facilitate construction of the
software; even they use the 4th GL techniques.
5. Testing & Turnover: Many of the programming components have already been
tested since RAD emphasis reuse. This reduces the overall testing time. But the new
part must be tested, and all interfaces must be fully exercised.
Advantage of RAD Model
o This model is flexible for change.
o In this model, changes are adoptable.
o Each phase in RAD brings highest priority functionality to the customer.
o It reduced development time.
o It increases the reusability of features.
Disadvantage of RAD Model
o It required highly skilled designers.
o All application is not compatible with RAD.
o For smaller projects, we cannot use the RAD model.
o On the high technical risk, it's not suitable.
o Required user involvement.
SPIRAL MODEL
The spiral model, initially proposed by Boehm, is an evolutionary software
process model that couples the iterative feature of prototyping with the controlled and
systematic aspects of the linear sequential model.
It implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of incremental
releases.
During the early iterations, the additional release may be a paper model or
prototype.
During later iterations, more and more complete versions of the engineered
system are produced.
The Spiral Model is shown in fig:
Each cycle in the spiral is divided into four parts:
Objective setting: Each cycle in the spiral starts with the identification of purpose for
that cycle, the various alternatives that are possible for achieving the targets, and the
constraints that exists.
Risk Assessment and reduction: The next phase in the cycle is to calculate these
various alternatives based on the goals and constraints. The focus of evaluation in this
stage is located on the risk perception for the project.
Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking,
simulation, and prototyping.
Planning: Finally, the next step is planned. The project is reviewed, and a choice made
whether to continue with a further period of the spiral. If it is determined to keep, plans
are drawn up for the next step of the project.
Advantages
o High amount of risk analysis
o Useful for large and mission-critical projects.
Disadvantages
o Can be a costly model to use.
o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

ITERATIVE MODEL

In this Model, you can start with some of the software specifications and develop
the first version of the software.
After the first version if there is a need to change the software, then a new version
of the software is created with a new iteration.
Every release of the Iterative Model finishes in an exact and fixed period that is
called iteration.
The Iterative Model allows the accessing earlier phases, in which the variations
made respectively.
The final output of the project renewed at the end of the Software Development
Life Cycle (SDLC) process.
The various phases of Iterative model are as follows:
1. Requirement gathering & analysis: In this phase, requirements are gathered
from customers and check by an analyst whether requirements will fulfil or not. Analyst
checks that need will achieve within budget or not. After all of this, the software team
skips to the next phase.
2. Design: In the design phase, team design the software by the different
diagrams like Data Flow diagram, activity diagram, class diagram, state transition
diagram, etc.
3. Implementation: In the implementation, requirements are written in the
coding language and transformed into computer programmes which are called
Software.
4. Testing: After completing the coding phase, software testing starts using
different test methods. There are many test methods, but the most common are white
box, black box, and grey box test methods.
5. Deployment: After completing all the phases, software is deployed to its work
environment.
6. Review: In this phase, after the product deployment, review phase is
performed to check the behaviour and validity of the developed product. And if there
are any error found then the process starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in
the working environment there may be some bugs, some errors or new updates are
required. Maintenance involves debugging and new addition options.

Advantage(Pros) of Iterative Model:

1. Testing and debugging during smaller iteration is easy.
2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.
5. Limited time spent on documentation and extra time on designing.

Disadvantage(Cons) of Iterative Model:

1. It is not suitable for smaller projects.
2. More Resources may be required.
3. Design can be changed again and again because of imperfect requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing requirements.

V-MODEL

V-Model also referred to as the Verification and Validation Model. In this, each phase
of SDLC must complete before the next phase starts. It follows a sequential design
process same as the waterfall model. Testing of the device is planned in parallel with a
corresponding stage of development.
Verification: It involves a static analysis method (review) done without executing
code. It is the process of evaluation of the product development process to find whether
specified requirements meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing

is done by executing code. Validation is the process to classify the software after the
completion of the development process to determine whether the software meets the
customer expectations and requirements.
So V-Model contains Verification phases on one side of the Validation phases on the
other side. Verification and Validation process is joined by coding phase in V-shape.
Thus it is known as V-Model.
There are the various phases of Validation Phase of V-model:
1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the
module design phase. These UTPs are executed to eliminate errors at code level
or unit level. A unit is the smallest entity which can independently exist, e.g., a
program module. Unit testing verifies that the smallest entity can function
correctly when isolated from the rest of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the
Architectural Design Phase. These tests verify that groups created and tested
independently can coexist and communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design
Phase. Unlike Unit and Integration Test Plans, System Tests Plans are composed
by the client?s business team. System Test ensures that expectations from an
application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement
analysis part. It includes testing the software product in user atmosphere.
Acceptance tests reveal the compatibility problems with the different systems,
which is available within the user atmosphere. It conjointly discovers the non-
 functional problems like load and performance defects within the real user
atmosphere.
Advantage (Pros) of V-Model:
1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall
model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.
Disadvantage (Cons) of V-Model:
1. Very rigid and least flexible.
2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes
of the software are produced.
4. If any changes happen in the midway, then the test documents along with the
required documents, has to be updated.
MODIFIED V MODEL
The V Model split the design and execution portion of the various types of tests
and attached the test design portion to the corresponding earlier phases of the software
life cycle.
An assumption made there was that even though the activity of test execution
was split into execution of tests of different types, the execution cannot happen until the
entire product is built.
For a given product, the different units and components can be in different stages
of evolution.
The V Model does not explicitly address this natural parallelism commonly
found in product development.
In the modified V Model, this parallelism is exploited. When each unit or
component or module is given explicit exit criteria to pass on to the subsequent stage,
the units or components or modules that satisfy a given phase of testing move to the
next phase of testing where possible, without Modified V Model necessarily waiting
for all the units or components or modules to move in unison from one phase of testing
to another.
While starting a phase of testing it is important to look at whether the product is
ready for testing. It is determined by a set of entry criteria.
The earliest possible quality to start the next phase of testing is denoted by entry
criteria, and to start the next phase of testing the earlier phase need not have completed.
The testing phases are also associated with a set of exit criteria to complete the
test activities for each phase.
They are determined by exit criteria. The entry and exit criteria for each of the
phases ensure that right quality of product delivered for starting the test and right
amount of testing is completed for the release.
Even though it is indicated in the picture all of the test phases finish at the same
time, practically it can have different time lines. The longest phase determines the
release date.
 SOFTWARE ENGINEERING

COMPUTER – BASED SYSTEMS

The word system is possibly the most overused and abused term in the technical
lexicon. We speak of political systems and educational systems, of avionics systems
and manufacturing systems, of banking systems and subway systems.
The word tells us little. We use the adjective describing system to understand
the context in which the word is used. Webster's Dictionary defines system in the
following way:
1. a set or arrangement of things so related as to form a unity or organic whole;
2. a set of facts, principles, rules, etc., classified and arranged in an orderly form
so as to show a logical plan linking the various parts;
3. a method or plan of classification or arrangement;
4. an established way of doing something; method; procedure . . .
Five additional definitions are provided in the dictionary, yet no precise synonym
is suggested. System is a special word.
Borrowing from Webster's definition, we define a computer-based system as
A set or arrangement of elements that are organized to accomplish some predefined goal
by processing information.
The goal may be to support some business function or to develop a product that
can be sold to generate business revenue. To accomplish the goal, a computer-based
system makes use of a variety of system elements:

✓ Software. Computer programs, data structures, and related documentation that

serve to effect the logical method, procedure, or control that is required.
✓ Hardware. Electronic devices that provide computing capability, the
interconnectivity devices (e.g., network switches, telecommunications devices)
that enable the flow of data, and electromechanical devices (e.g., sensors, motors,
pumps) that provide external world function.
✓ People. Users and operators of hardware and software.
✓ Database. A large, organized collection of information that is accessed via
software.
Documentation. Descriptive information (e.g., hardcopy manuals, on-line help
files, Web sites) that portrays the use and/or operation of the system.
 ✓ Procedures. The steps that define the specific use of each system element or
the procedural context in which the system resides.
The elements combine in a variety of ways to transform information.
For example, a marketing department transforms raw sales data into a profile of
the typical purchaser of a product; a robot transforms a command file containing
specific instructions into a set of control signals that cause some specific physical
action.
Creating an information system to assist the marketing department and control
software to support the robot both require system engineering.
One complicating characteristic of computer-based systems is that the elements
constituting one system may also represent one macro element of a still larger system.
The macro element is a computer-based system that is one part of a larger
computer-based system.
As an example, we consider a "factory automation system" that is essentially a
hierarchy of systems.
At the lowest level of the hierarchy we have a numerical control machine,
robots, and data entry devices. Each is a computer based system in its own right.
The elements of the numerical control machine include electronic and
electromechanical hardware (e.g., processor and memory, motors, sensors), software
(for communications, machine control, interpolation), people (the machine operator), a
database (the stored NC program), documentation, and procedures.
A similar decomposition could be applied to the robot and data entry device.
Each is a computer-based system.
At the next level in the hierarchy, a manufacturing cell is defined. The
manufacturing cell is a computer-based system that may have elements of its own (e.g.,
computers, mechanical fixtures) and also integrates the macro elements that we have
called numerical control machine, robot, and data entry device.
The role of the system engineer is to define the elements for a specific computer-
based system in the context of the overall hierarchy of systems (macro elements).
In the sections that follow, we examine the tasks that constitute computer system
engineering.

THE SYSTEM ENGINEERING HIERARCHY

Regardless of its domain of focus, system engineering encompasses a collection

of top-down and bottom-up methods to navigate the hierarchy illustrated in figure
below.
 The system engineering process usually begins with a “world view.”
That is, the entire business or product domain is examined to ensure that the
proper business or technology context can be established.
The world view is refined to focus more fully on specific domain of interest.
Within a specific domain, the need for targeted system elements (e.g., data, software,
hardware, people) is analyzed.
Finally, the analysis,design, and construction of a targeted system element is
initiated. At the top of the hierarchy, a very broad context is established and, at the
bottom, detailed technical activities, performed by the relevant engineering discipline
(e.g., hardware or software engineering), are conducted.

Stated in a slightly more formal manner, the world view (WV) is composed of a set of
domains (Di), which can each be a system or system of systems in its own right.

WV = {D1, D2, D3, . . . , Dn}

Each domain is composed of specific elements (Ej) each of which serves some role in
accomplishing the objective and goals of the domain or component:

Di = {E1, E2, E3, . . . , Em}

Finally, each element is implemented by specifying the technical components (Ck) that
achieve the necessary function for an element:

Ej = {C1, C2, C3, . . . , Ck}

System Modeling

System engineering is a modeling process. Whether the focus is on the world

view or the detailed view, the engineer creates models that
• Define the processes that serve the needs of the view under consideration.
• Represent the behavior of the processes and the assumptions on which the
behavior is based.
• Explicitly define both exogenous and endogenous input3 to the model.
• Represent all linkages (including output) that will enable the engineer to better
understand the view.

To construct a system model, the engineer should consider a number of restraining

factors:

1. Assumptions that reduce the number of possible permutations and variations, thus
enabling a model to reflect the problem in a reasonable manner.
As an example, consider a three-dimensional rendering product used by the
entertainment industry to create realistic animation.
One domain of the product enables the representation of 3D human forms. Input
to this domain encompasses the ability to specify movement from a live human actor,
from video, or by the creation of graphical models.
The system engineer makes certain assumptions about the range of allowable
human movement (e.g., legs cannot be wrapped around the torso) so that the range of
inputs and processing can be limited.

2. Simplifications that enable the model to be created in a timely manner.

To illustrate, consider an office products company that sells and services a broad
range of copiers, faxes, and related equipment.
The system engineer is modeling the needs of the service organization and is
working to understand the flow of information that spawns a service order.
Although a service order can be derived from many origins, the engineer
categorizes only two sources: internal demand and external request. This enables a
simplified partitioning of input that is required to generate the service order.

3. Limitations that help to bound the system. For example, an aircraft avionics system
is being modeled for a next generation aircraft.
Since the aircraft will be a two-engine design, the monitoring domain for
propulsion will be modeled to accommodate a maximum of two engines and associated
redundant systems.

4. Constraints that will guide the manner in which the model is created and the approach
taken when the model is implemented.

For example, the technology infrastructure for the three-dimensional rendering system
described previously is a single G4-based processor. The computational complexity of
problems must be constrained to fit within the processing bounds imposed by the
processor.
5. Preferences that indicate the preferred architecture for all data, functions, and
technology.
The preferred solution sometimes comes into conflict with other restraining
factors. Yet, customer satisfaction is often predicated on the degree to which the
preferred approach is realized.

The resultant system model (at any view) may call for a completely automated
solution, a semi-automated solution, or a non automated approach.
In fact, it is often possible to characterize models of each type that serve as
alternative solutions to the problem at hand.
In essence, the system engineer simply modifies the relative influence of
different system elements (people, hardware, software) to derive models of each type.

System Simulation

In the late 1960s, R. M. Graham [GRA69] made a distressing comment about

the way we build computer-based systems: "We build systems like the Wright
brothers built airplanes— build the whole thing, push it off a cliff, let it crash, and
start over again."
In fact, for at least one class of system—the reactive system—we continue to do
this today.
Many computer-based systems interact with the real world in a reactive fashion.
That is, real-world events are monitored by the hardware and software that form
the computer-based system, and based on these events, the system imposes control on
the machines, processes, and even people who cause the events to occur.
Real-time and embedded systems often fall into the reactive systems category.
Unfortunately, the developers of reactive systems sometimes struggle to make
them perform properly.
Many systems in the reactive category control machines and/or processes (e.g.,
commercial aircraft or petroleum refineries) that must operate with an extremely high
degree of reliability.
If the system fails, significant economic or human loss could occur. For this
reason, the approach described by Graham is both painful and dangerous.
Today, software tools for system modeling and simulation are being used to help
to eliminate surprises when reactive, computer-based systems are built.
These tools are applied during the system engineering process, while the role of
hardware and software, databases and people is being specified.
Modeling and simulation tools enable a system engineer to "test drive" a
specification of the system.