Introduction to Software Engineering

• Layered Technology
•Process

•Process Models
 Software
(1) instructions (programs) that when executed
provide desired function and performance,
(2) data structures that enable the programs to
adequately manipulate information,
(3) documents that describe the operation and use of
the programs.

Computer software is developed by applying a process that leads to a

high quality result that meets the needs of the people who will use the
product and the approach is called software engineering .
Engineering
Engineering is the
1.analysis,

2.design,

3.construction,

4.verification, and

5.management of technical (or social) entities

Software Engineering
(1) The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software;

(2) the application of engineering to software.

Software Engg: A Layered Technology
Software Engg: A Layered Tech.
1. Quality: Any engineering approach must rest
on commitment to quality. A continuous
process improvement fosters quality in a
product.

2. Process: defines a framework that establishes

the context in which technical methods are
applied, work products are produced,
milestones are established, quality is ensured.
Methods
Software engineering methods provide the
technical how-to's for building software.
Methods encompass a broad array of tasks
that include requirements analysis, design,
program construction, testing, and support.
Tools
Software engineering tools provide automated
or semi-automated support for the process
and the methods.
CASE combines software, hardware, and a
software engineering database (a repository
containing important information about
analysis, design, program construction, and
testing) to create a software engineering
environment.
Process Framework

A process framework establishes the foundation for a
complete software engineering process by identifying a
small number of framework activities that are applicable
to all software projects, regardless of their size or
complexity.

Each framework activity is populated by a set of SE
actions- a collection of related tasks that produces a
major SE work product.

In addition, the process framework encompasses a set of
umbrella activities that are applicable across the entire
software process.
Process Framework
Elements of a Software Process

A process is a collection of activities, actions, and tasks
that are performed when some work product is to be
created.

An activity strives to achieve a broad objective (e.g.,
communication with stakeholders) and is applied
regardless of the application domain, size of the project,
complexity of the effort.

An action (e.g., architectural design) encompasses a set of
tasks that produce a major work product (e.g., an
architectural model).

A task focuses on a small, but well-defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.
Activity, Action and Task Set
TaskSet: Defines actual work to be done to accomplish the
objective of a SE action.
e.g. Requirement Gathering is a SE action that occurs
during Communication (Activity).
Task set: 1. Make a list of stakeholders
2. Discuss the requirements with them
3. Prioritize the requirements
4. Note areas of Uncertainty
 Generic Framework Activities
1. Communication: The intent is to understand stakeholders’
objectives for the project and to gather requirements that help defi
ne software features and functions
2. Planning: A software project plan—defines the software
engineering work by describing the technical tasks to be conducted,
the risks that are likely, the resources that will be required, the work
products to be produced, and a work schedule.
3. Modeling: A software engineer creates models to understand

software requirements and the design that will achieve those

requirements.
4. Construction: This activity combines code generation and the

testing that is required to uncover errors in the code.

5. Deployment: The software is delivered to the customer who

evaluates the delivered product and provides feedback based on the

evaluation.
 Umbrella Activities
Umbrella activities are applied throughout a software project and help
a software team manage and control progress, quality, change, and risk.

Typical umbrella activities include are:

•Software project tracking and control: allows the software team to
assess progress against the project plan and take any necessary action
to maintain the schedule.
•Risk management—assesses risks that may affect the outcome of the
project or the quality of the product.
•Software quality assurance—defines and conducts the activities
required to ensure software quality.
•Technical reviews—assess software engineering work products in an
effort to uncover and remove errors before they are propagated to the
next activity.
 Umbrella Activities Contd.

• Measurement—defines and collects process, project, and product

measures that assist the team in delivering software that meets
stakeholders’ needs; can be used in conjunction with all other
framework and umbrella activities.
• Software configuration management—manages the effects of
change throughout the software process.
• Reusability management—defines criteria for work product reuse
(including software components) and establishes mechanisms to
achieve reusable components.
• Work product preparation and production—encompass the
activities required to create work products such as models,
documents, logs, forms, and lists.
 Process Flow
Process flow describes how the framework activities and the actions
and tasks that occur within each framework activity are organized
with respect to sequence and time.
1.A linear process flow executes each of the five framework
activities in sequence, beginning with communication and
culminating with deployment.
2.An iterative process flow repeats one or more of the activities
before proceeding to the next.
3. 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.
4.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)
Process Flows
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 might encompass little more than a
phone call or email with the appropriate stakeholder. Therefore,
the only necessary action is phone conversation, and the work
tasks (the task set) that this action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and develop notes.
3. Organize notes into a brief written statement of requirements.
4. Email to stakeholder for review and approval.
 How does a framework activity change as the nature of
the project changes? Contd.

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,

elaboration,

negotiation, specification, and

validation.
Each of these software engineering actions would have
many work tasks and a number of distinct work products.
Prescriptive Process model

The prescriptive process models prescribe a
set of process elements—framework
activities, software engineering actions, tasks,
work products, quality assurance, and change
control mechanisms for each project.

Each process model also prescribes a process
flow (also called a work flow)—that is, the
manner in which the process elements are
interrelated to one another.
Waterfall/Sequential model

The waterfall model, sometimes called the classic life cycle,

suggests a systematic, sequential approach to software development
that begins with customer specification of requirements and
progresses through planning, modeling, construction, and
deployment, culminating in ongoing support of the completed
software.
 Why does the waterfall model sometimes fail?
1.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.
2. 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.
3.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 undetected until the working program is reviewed,
can be disastrous.
4.Linear nature of the classic life cycle leads to “blocking states” in
which some project team members must wait for other members of
the team to complete dependent tasks.
V-Model
The Incremental Model
Incremental Model

Rather than deliver the system as a single
delivery, the development and delivery is broken
down into increments with each increment
delivering part of the required functionality.

User requirements are prioritised and the highest
priority requirements are included in early
increments.

Once the development of an increment is started,
the requirements are frozen though requirements
for later increments can continue to evolve.
Incremental Model

Customer value can be delivered with each increment so
system functionality is available earlier

Early increments act as a prototype to help elicit
requirements for later increments

Lower risk of overall project failure

The highest priority system services tend to receive the most
testing
 Evolutionary Process Models

Evolutionary process models produce an increasingly more
complete version of the software with each iteration.

Business and product requirements often change as development
proceeds, making a straight line path to an end product
unrealistic.

Process model that has been explicitly designed to accommodate
a product that grows and changes, is needed.

Evolutionary models are iterative.
• Prototyping Model
• Spiral Model
Prototyping
Prototyping

The prototyping paradigm begins with communication. You meet
with other 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 design”) occurs.

A quick design focuses on a representation of those aspects of the
software 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.
 Prototyping

Gather requirements

Developer & customer define overall
objectives, identify areas needing more
investigation – risky requirements

Quick design focusing on what will be visible
to user – input & output formats

Use existing program fragments, program
generators to throw together working
version

Prototype evaluated and requirements refined
 Prototyping

Iteration occurs as the prototype is tuned to satisfy
the needs of various stakeholders, while at the same
time enabling you to better understand what needs
to be done.

The process is iterated until customer & developer
satisfied
• then throw away prototype and rebuild system
to high quality
• alternatively can have evolutionary prototyping
– start with well understood requirements
 Prototyping Drawbacks

Customer may want to hang onto first version, may
want a few fixes rather than rebuild. First version
will have compromises

Developer may make implementation compromises
to get prototype working quickly. Later on
developer may become comfortable with
compromises and forget why they are inappropriate
Spiral development
 Spiral Model

The spiral model uses prototyping as a risk reduction mechanism
but, enables to apply the prototyping approach at any stage in the
evolution of the product. It maintains the systematic stepwise
approach suggested by the classic life cycle

The spiral model demands a direct consideration of technical risks
at all stages of the project and, if properly applied, should reduce
risks before they become problem.

Process is represented as a spiral rather than as a sequence of
activities with backtracking.

The spiral model is a realistic approach to the development of
large-scale systems and software.
 Spiral Model

Customer Communication – tasks required to establish
effective communication between developer and customer

Planning – tasks required to define resources, timelines and
other project related information

Risk Analysis – tasks required to assess both technical and
management risks

Engineering – tasks required to build one or more
representations of the application

Construction and Release – tasks required to construct, test,
install and provide user support (e.g. documentation & training)

Deployment/customer evaluation – tasks required to get
customer feedback on evaluation of the software representations
created during the engineering stage and implemented during the
installation stage
Spirals in Model

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 prototype and then progressively more
sophisticated versions of the software.

Each pass through the planning region results in adjustments
to the project plan. Cost and schedule are adjusted based on
feedback derived from the customer after delivery.

In addition, the project manager adjusts the planned number
of iterations required to complete the software.
 Agile Process
Agility means quick to respond.
Agility is dynamic, content specific, aggressively change embracing,
and growth oriented.”
Agile process should respond to followings:
1. It is difficult to predict in advance which software requirements will
persist and which will change. It is equally difficult to predict how
customer priorities will change as the project proceeds.
2. For many types of software, design and construction are
interleaved. It is difficult to predict how much design is necessary
before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable.
 Characteristics of an Agile Process
1. Unpredictability can be resolved by adaptability (to rapidly
changing project and technical conditions). An agile process, must
be adaptable.
2. An agile software process must adapt incrementally. An agile team

requires customer feedback so that the appropriate adaptations can

be made. An effective catalyst for customer feedback is an
operational prototype or a portion of an operational system.
3. Hence, an incremental development strategy should be instituted.

Software increments must be delivered in short time periods so that

adaptation keeps pace with change (unpredictability).
4. This iterative approach enables the customer to evaluate the
software increment regularly, provide necessary feedback to the
software team, and influence the process adaptations that are made
to accommodate the feedback.
 12 Agility Principles
1.Highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
6.The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
 Agility Principles
7.Working software is the primary measure of progress.
8.Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity—the art of maximizing the amount of work, not done
—is essential.
11. The best architectures, requirements, and designs emerge from
self-organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
Scrum

Scrum is an agile software development method

Framework activities include:

Requirements analysis, design, evolution, and delivery.

Work tasks is called a sprint. The work conducted within a
sprint and the number of sprints required for each framework
activity will vary depending on product complexity and size.

Scrum incorporates a set of process patterns that emphasize
project priorities, compartmentalized work units,
communication, and frequent customer feedback.
Scrum Process Flow
 Scrum Process Flow
Scrum incorporates a set of process patterns that emphasize project
priorities, compartmentalized work units, communication, and frequent
customer feedback.

Backlog—a prioritized list of project requirements or features that
provide business value for the customer. Items can be added to the
backlog at any time (this is how changes are introduced). The product
manager assesses the backlog and updates priorities as required.

Sprints—consist of work units that are required to achieve a
requirement defined in the backlog that must be fit into a predefi ned
time-box 10 (typically 30 days). Changes (e.g., backlog work items) are
not introduced during the sprint. Hence, the sprint allows team
members to work in a short-term, but stable environment.

 Scrum Process Flow
Scrum meetings—are short (typically 15-minute) meetings held
daily by the Scrum team. Three key questions are asked and
answered by all team members
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
A team leader, called a Scrum master, leads the meeting and
assesses the responses from each person. The Scrum meeting helps
the team to uncover potential problems as early as possible. Demos
—deliver the software increment to the customer so that
implemented functionality can be demonstrated and evaluated by
the customer.