UNIT I

INTRODUCTION TO
SOFTWARE ENGINEERING
 Process Models
What is it? Process Model
• When you work to build a product or system, it’s important to go through a series
of predictable steps—a road map that helps you create a timely, high-quality
result. The road map that you follow is called a “software process.”
Who does it?
Software engineers and their managers adapt the process to their needs and then
follow it.
In addition, the people who have requested the software have a role to play in the
process of defining, building, and testing it.
 Process Models
Process
A process is a collection of work activities, actions, and tasks that are
performed when some work product is to be created.
Software Process
• a software process is a framework for the activities, actions, and tasks that are
required to build high-quality software.
• A software process defines the approach that is taken as software is engineered
Why is it important?
It provides stability, control, and organization to an activity that
can, if left uncontrolled, become quite chaotic.
It must apply only those activities, controls, and work products that are appropriate
for the project team and the product that is to be produced.
• What is the work product?
• • From the point of view of a software engineer, the work products are the
programs, documents, and data that are produced as a consequence of the
activities and tasks defined by the process.
• • How do I ensure that I’ve done it right?
• The quality, timeliness, and long-term viability of the product you build are the
best
• indicators of the efficacy of the process that you use
What is the work product?
• From the point of view of a software engineer, the work products are the
programs, documents, and data that are produced as a consequence of the
activities and tasks defined by the process.

How do I ensure that I’ve done it right?

• The quality, timeliness, and long-term viability of the product you build are the best
• indicators of the efficacy of the process that you use
Process
A process is a collection of work activities, actions, and
tasks that are performed when some work product is to be
created.
• Each of these activities, actions, and
• tasks reside within a framework or model that defines their
relationship with the process and with one another.
• Each framework activity is populated by a set of software
engineering actions. Each software engineering action is
defined by a task set
• Task Set identifies the work tasks that are to be completed,
the work products that will be produced, the quality assurance
points that will be required, and the milestones that will be
used to indicate progress.
 Types of Process
Flow
• process flow—describes how the frame- work activities
and the actions and tasks that occur within each
framework activity are organized with respect to sequence
and time

• A linear process flow executes each of the five

framework activities in sequence, beginning with
communication and culminating with deployment
 Process Flow
• An iterative process flow repeats one or more of the activities
before proceeding to the next
• An evolutionary process flow executes the activities in a
“circular” manner. Each circuit through the five activities
leads to a more complete version of the software
• A parallel process flow executes one or more activities in
parallel with other activities (e.g., modeling for one aspect of
the software might be executed in parallel with construction
of another aspect of the software).
 Defining a Framework Activity
What actions are appropriate for a framework activity, given the nature of the
problem to be solved, the characteristics of the people doing the work, and the
stakeholders who are sponsoring the project?

How does a framework

activity change as the nature of the project changes?
• For a small software project requested by one person (at a remote location)
with simple, straightforward requirements.
• the communication activity is to make a phone call with the appropriate
stakeholder.
• The work tasks (the task set) that this action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

• If the project was considerably more complex with many stakeholders, each
with a different set of (sometime conflicting) requirements, the
communication activity might have six distinct actions
• inception,
• elicitation,
• elabo- ration,
• negotiation,
• specification
• validation
 Identifying a Task Set
• Each task set is a collection of
• software engineering work tasks,
• related work products,
• quality assurance points
• project milestones.
• Choose a task set that best accommodates the needs of the
project and the characteristics of your team.
• Software engineering action can be adapted to the spe- cific
needs of the software project and the characteristics of the
project team.
 Example of Task Set
• For a small, relatively simple project, the task set for requirements gathering
might look like this:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and
4. functions required.
5. Discuss requirements and build a final list.
6. Prioritize requirements.
7. Note areas of uncertainty.
.

•For a larger, more complex software project, a

different task set would be required. It include s
the following work tasks:
1.Make a list of stakeholders for the project.
2.Interview each stakeholder separately to determine
overall wants and needs
Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each
meeting.
7. Refine user scenarios based on stakeholder
feedback.
8. Build a revised list of stakeholder requirements. 9. Use quality function
deployment techniques to
prioritize requirements.
10. Package requirements so that they can be delivered
incrementally.
11. Note constraints and restrictions that will be placed
on the system.
12. Discuss methods for validating the system.
 Process Pattern
• A process pattern describes a process-related problem that is
encountered during software en- gineering work, identifies the
environment in which the problem has been encoun- tered, and
suggests one or more proven solutions to the problem.
• a process pattern provides you with template
• a consis- tent method for describing problem solutions within the
context of the software process.
• By combining patterns, a software team can
solve problems and construct a process that
best meets the needs of a project
• a pattern might be used to describe a problem
(and solution) associated with a complete
process model (e.g., prototyping).
• patterns can be used to describe a prob- lem
(and solution) associated with a framework
activity (e.g., planning) or an action within a
framework activity (e.g., project estimating).
 Template for Process Pattern
• Pattern Name. The pattern is given a meaningful name describing it
• within the context of the software process
• Forces. The environment in which the pattern is encountered and the
• issues that make the problem visible and may affect its solution.
• Type- The pattern type is specified
• Stage pattern—defines a problem associated with a framework
activity for the process. Since a framework activity encompasses
multiple actions and work tasks, a stage pattern incorporates
multiple task patterns (see the fol- lowing) that are relevant to the
stage (framework activity).
• Task pattern—defines a problem associated with a software
engineering action or work task and relevant to successful software
engineering practice
• Phase pattern—define the sequence of framework activities that
occurs within the process, even when the overall flow of activities is
iterative in nature.
• Initial context. Describes the conditions under which the pattern applies.
Prior to the initiation of the pattern:
(1) What organizational or team-related ac- tivities have already occurred? (2) What is
the entry state for the process?
(3) What software engineering information or project information already exists?
• Problem. The specific problem to be solved by the pattern.
• Solution. Describes how to implement the pattern successfully.
• This sec-tion describes how the initial state of the process (that exists before the
pattern is implemented) is modified as a consequence of the initiation of the
pattern.
• It also describes how software engineering information or project information that
is available before the initiation of the pattern is transformed as a consequence of
the successful execution of the pattern.
• Resulting Context. Describes the conditions that will result once the pat- tern has
been successfully implemented.
• Related Patterns. Provide a list of all process patterns that are directly related to
this one.
• Known Uses and Examples. Indicate the specific instances in which the pattern
is applicable.
 Prescriptive Process Model
Prescriptive process models define a prescribed set of process elements
and a predictable process work flow.
prescriptive” because they prescribe a set of process elements—
framework activities,
software engineering actions,
tasks,
work products,
quality assurance,
change control mechanisms for each project.
Each process model also prescribes a process flow (work flow)
the manner in which the process elements are interrelated to one another.
The Waterfall
Model
 Waterfall Model
• The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development
• begins with customer specifica- tion of requirements and progresses
through planning, modeling, construction, and deployment,
culminating in ongoing support of the completed software
• Used when well-defined adaptations or en- hancements to an existing
system must be made
• (e.g., an adaptation to accounting software that has been mandated
because of changes to government regulations).
• It may also occur in a limited number of new development efforts, but
only when requirements are well defined and reasonably stable.
• A variation in the representation of the waterfall model is called the V-
model.
• V-model depicts the relationship of quality assurance actions to the
actions associated with communication, modeling, and early
construction activities.
• As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and techni-
cal representations of the problem and its solution.
• Once code has been generated, the team moves up the right side of
the V, essentially performing a series of tests (quality assurance
actions) that validate each of the models created as the team moved
down the left side.
 Problems with Waterfall Model
• Real projects rarely follow the sequential flow that the model proposes. Although
the linear model can accommodate iteration, it does so indirectly. As a result,
changes can cause confusion as the project team proceeds.

• It is often difficult for the customer to state all requirements

explicitly. The waterfall model requires this and has difficulty
accommodating the natural uncertainty that exists at the beginning
of many projects.

• The customer must have patience. A working version of the

program(s) will not be available until late in the project time span. A major
blunder, if unde- tected until the working program is reviewed, can be
disastrous.
 Incremental Process Model
• There are situations where
• initial software requirements are reasonably well defined, but the overall scope of
the development effort precludes a purely linear process.
• there may be a compelling need to provide a limited set of soft- ware functionality
to users quickly
• then refine and expand on that functionality in later software releases.
• Choose a process model that is designed to produce the
software in increments.
• The incremental model combines elements of linear and parallel process flows
• For example, word-processing software developed using the incremental (REFER
Chapter 2,2.3.2 in Textbook)
 Evolutionary Process
Models

• a process model that has been explicitly designed

to accommodate a product that evolves over time.
• Protyping:
• starts With communication.
• meet the stakeholders to define the overall
objectives for the software, identify whatever
requirements are known, and outline areas where
further definition is mandatory.
• A prototyping iteration is planned quickly, and
modeling (in the form of a “quick de- sign”)
occurs.
• A quick design focuses on a representation of those aspects of the soft- ware that
will be visible to end users (e.g., human interface layout or output display
formats).
• The quick design leads to the construction of a prototype. The prototype is
deployed and evaluated by stakeholders, who provide feedback that is used to
further refine requirements.
• Iteration occurs as the prototype is tuned to satisfy the needs of various
stakeholders, while at the same time enabling you to better under- stand what
needs to be done.
• The Spiral Model - the spiral model is an
evolutionary software process model that
couples the iterative nature of proto- typing
with the controlled and systematic aspects of
the waterfall model
 Spiral Model
• A spiral model is divided into a set of framework activities defined by the
software engineering team.
• Each of the framework activities represent one segment of the spi- ral path
• As this evolutionary process begins, the software team performs activities that are
implied by a circuit around the spiral in a clockwise direction, beginning at the
centre
• Anchor point milestones—a combination of work products and conditions that are
attained along the path of the spiral—are noted for each evolutionary pass.
• The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a pro-
totype and then progressively more sophisticated versions of the software