Chapter 2

The Software Process

- Software engineering defined
- A layered technology
- Process, methods, and tools
- Generic process framework
- Umbrella activities
- Capability Maturity Model (SW-CMM)

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

 Software Engineering - Defined

• (1969) Software engineering is the establishment and use of sound

engineering principles in order to obtain economically software that is
reliable and works efficiently on real machines
• (IEEE) The application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that is, the
application of engineering to software

2
Software Engineering is a
Layered Technology

Tools

Methods

Processes

Quality Focus
3
 Software Engineering is a Layered
Technology
• Quality Focus
Any engineering approach rest on the organizational commitment to
quality. Total quality measurement, six sigma and similar philosophy
foster a continuous process improvement culture.
• Process
– Provides the glue that holds the layers together and enables rational
and timely development;
– Process define framework for effective delivery of technology;
– forms the basis for management control and provides the context
for technical methods,
– work products(models, documents, reports etc) are produced,
milestones are established, quality measures, and change
management

4
 Software Engineering is a
Layered Technology
• Methods
– Provide the technical "how to" for building software;
– rely on a set of basic principles that govern each activity;
– encompass a broad array of tasks(five framework
activities) ;
• Tools
– Provide automated or semi-automated support for the
process and methods

5
SOFTWARE PROCESS

6
7
8
 Generic Process Framework
• Communication
– Involves communication among the customer and other stake holders;
encompasses requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule
• Modeling (Analyze, Design)
– Encompasses the creation of models to better understand the requirements
and the design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and feedback

9
10
 Umbrella Activities
• Software requirements management
• Software project planning
• Software project tracking and oversight
• Software quality assurance
• Software configuration management
• Software subcontract management
• Formal technical reviews
• Risk management
• Measurement – process, project, product
• Reusability management (component reuse)
• Work product preparation and production

11
 What is a Process?
• (Webster) A system of operations in producing something; a series of
actions, changes, or functions that achieve an end or a result
• (IEEE) A sequence of steps performed for a given purpose

12
 What is a Software Process?

• (SEI) A set of activities, methods, practices, and transformations that

people use to develop and maintain software and the associated
products (e.g., project plans, design documents, code, test cases, and
user manuals)
• As an organization matures, the software process becomes better
defined and more consistently implemented throughout the
organization
• Software process maturity is the extent to which a specific process is
explicitly defined, managed, measured, controlled, and effective

13
 Capability Maturity Model
(SW-CMM)
• Developed in 1987 by the Software Engineering Institute (SEI) at Carnegie-
Mellon University under the sponsorship of DARPA
• Described in the book Managing the Software Process in 1989 by Watts
Humphrey
• Published as a separate document: Capability Maturity Model for Software in
1991

14
Immature Software Organizations
• Software processes are generally unplanned.
• If a process is specified, it is not rigorously followed or enforced
• The software organization is conservative
• Managers only focus on solving immediate (crisis) problems
• Schedules and budgets are routinely exceeded because they are not based
on realistic estimates
• When hard deadlines are imposed, product functionality and quality are
often compromised
• There is no basis for judging process quality or for solving product or
process problems
• Activities such as reviews and testing are shortened or eliminated when
projects fall behind schedule

15
Five Levels of Software Process
Maturity

16
 Characteristics of Each Level

• Initial Level (Level 1)

– Characterized as ad hoc, and occasionally even chaotic
– Few processes are defined, and success depends on individual effort
• Repeatable (Level 2)
– Basic project management processes are established to track cost,
schedule, and functionality
– The necessary process discipline is in place to repeat earlier successes on
projects with similar applications

17
 Characteristics of Each Level
(continued)
• Defined (Level 3)
– The software process for both management and engineering activities is
documented, standardized, and integrated into a standard software process
for the organization
– All projects use an approved, tailored version of the organization's
standard software process for developing and maintaining software
• Managed (Level 4)
– Detailed measures of the software process and product quality are
collected
– Both the software process and products are quantitatively understood and
controlled

18
 Characteristics of Each Level
(continued)

• Optimized (Level 5)
– Continuous process improvement is enabled by quantitative feedback
from the process and from showing innovative ideas and technologies

19
PROCESS PATTERNS

Software Process is defined as collection of Patterns.

Process pattern provides a template.
It comprises of
• Process Template
-Pattern Name
-Intent (Resolved)
-Types
-Task pattern
- Stage pattern
-Phase Pattern
• Initial Context
• Problem
• Solution
• Resulting Context
• Related Patterns
20
PROCESS ASSESSMENT

Does not specify the quality of the software or whether the software
will be delivered on time or will it stand up to the user requirements.
It attempts to keep a check on the current state of the software
process with the intention of improving it.

PROCESS ASSESSMENT

Software Process Assessment Software Process improvement

Motivates Capability determination
APPROACHES TO SOFTWARE ASSESSMENT
• Standard CMMI assessment (SCAMPI)
• CMM based appraisal for internal process improvement
• SPICE(ISO/IEC 15504)
• ISO 9001:2000 for software
21
A "personal and team process software process"
refers to a framework where individual developers utilize a
structured "Personal Software Process (PSP)" to improve their
own work practices,

while the entire team collaborates using a "Team Software

Process (TSP)" to optimize their collective development efforts,
leading to better overall software quality and efficiency

22
Personal and Team Software Process
Personal software process
 PLANNING
 HIGH LEVEL DESIGN
 HIGH LEVEL DESIGN REVIEW
 DEVELOPMENT
 POSTMORTEM

Personal and Team Software Process

Team software process Goal of TSP
-Build self-directed teams
-Motivate the teams
-Acceptance of CMM level 5 behavior as normal to accelerate
software process improvement
-Provide improvement guidance to high maturity organization

23
 Generic Process Framework
• Communication
– Involves communication among the customer and other stake holders; encompasses
requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule
• Modeling (Analyze, Design)
– Encompasses the creation of models to better under the requirements and the
design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and feedback

24
 Waterfall Model
(Diagram)
Communication
Project initiation
Requirements gathering

Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
25
 Waterfall Model
(Description)
• Oldest software lifecycle model and best understood by upper management
• Used when requirements are well understood and risk is low
• Work flow is in a linear (i.e., sequential) fashion
• Used often with well-defined adaptations or enhancements to current
software

26
 Waterfall Model
(Problems)
• Doesn't support iteration, so changes can cause confusion
• Difficult for customers to state all requirements explicitly and up front
• Requires customer patience because a working version of the program
doesn't occur until the final phase
• Problems can be somewhat alleviated in the model through the addition of
feedback loops (see the next slide)

27
 Spiral Model
(Diagram)
Planning

Communication

Start Modeling

Start

Deployment Construction

28
 Spiral Model
(Description)
• Invented by Dr. Barry Boehm in 1988 while working at TRW
• Follows an evolutionary approach
• Used when requirements are not well understood and risks are high
• Inner spirals focus on identifying software requirements and project risks; may
also incorporate prototyping
• Outer spirals take on a classical waterfall approach after requirements have been
defined, but permit iterative growth of the software
• Operates as a risk-driven model…a go/no-go decision occurs after each
complete spiral in order to react to risk determinations
• Requires considerable expertise in risk assessment
• Serves as a realistic model for large-scale software development

29
 General Weaknesses of
Evolutionary Process Models
1) Prototyping poses a problem to project planning because of the
uncertain number of iterations required to construct the product
2) Evolutionary software processes do not establish the maximum speed of
the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and extensibility, and
second on high quality
• We should prioritize the speed of the development over zero defects
• Extending the development in order to reach higher quality could result in
late delivery

30
The Spiral Model

The spiral model, originally proposed by Boehm

[BOE88], is an evolutionary software process
model that couples the iterative nature of
prototyping with the controlled and
systematic aspects of the linear sequential model

It provides the potential for rapid development of incremental

versions of the software. Using the spiral model, software
is developed in a series of incremental releases.

During early iterations, the incremental release might be a

paper model or prototype. During later iterations, increasingly
more complete versions of the engineered system are produced
31
A spiral model is divided into a number of framework
activities, also called task regions.

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 and training). 32
Customer evaluation—tasks required to obtain customer feedback
based on evaluation of the software representations created during
the engineering stage and implemented during the installation stage.

33
As this evolutionary process begins, the software
engineering team moves around the spiral in a
clockwise direction, beginning at the center.

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.

34
Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are
adjusted based on
feedback derived from customer evaluation.

the project entry point axis, also shown in Figure 2.8. Each
cube placed along the axis can be used to represent the
starting point for different types of projects.

The spiral model is a realistic approach to the

development of large-scale systems and
software.

The spiral model uses prototyping as a risk reduction

mechanism. 35
THE PROTOTYPING MODEL

36
customer defines a set of general objectives for
software but does not identify detailed input,
processing, or output requirements.

the developer may be unsure of the efficiency of an algorithm, the

adaptability of an operating system, or the form that human/machine
interaction should take. In these, and many other situations, a
prototyping paradigm may offer the best approach

begins with requirements gathering. Developer and customer meet

and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further
definition is mandatory. A "quick design" then occurs, that will be
visible to the customer/user

37
The prototype is evaluated by the customer/user and
used to refine Requirements

Iteration occurs as the prototype is tuned to satisfy the needs of the

customer, while at the same time enabling the developer
to better understand what needs to be done.

If a working prototype is built, the developer attempts to use

existing program fragments or applies tools (e.g., report generators,
window managers) that enable working programs to be generated
quickly.

38
prototyping can also be problematic for the following
reasons:

1.The customer sees what appears to be a working

version of the software, unaware that the prototype is
held together “with chewing gum and baling wire,”

2. The developer often makes implementation compromises in order

to get a prototype working quickly

39
THE RAD MODEL

Rapid application development (RAD) is an incremental software

development process model that emphasizes an extremely short
development cycle. The RAD model is a “high-speed” adaptation of
the linear sequential model

If requirements are well understood and project scope is

constrained(controlled), the RAD process enables a development
team to create a “fully functional system” within very short time
periods (e.g., 60 to 90 days)

Business modeling. The information flow among business functions

is modeled that What information drives the business process? What
information is generated? Who generates it? Where does the
information go? Who processes it?
40
41
Data modeling. The information flow defined as part
of the business modeling phase is refined into a set of
data objects that are needed to support the business

Process modeling. The data objects defined in the data modeling

phase are transformed to achieve the information flow necessary to
implement a business function.

Application generation. the RAD process works to reuse existing

program components (when possible) or create reusable components
(when necessary)

42
Testing and turnover. Since reusable, many of the
program components have already been tested. This
reduces overall testing time. However, new
components must be tested and all interfaces must be
fully exercised.

Each major function can be addressed by a separate RAD team and

then integrated to form a whole

43
the RAD approach has drawbacks [BUT94]:

• For large but scalable projects, RAD requires

sufficient human resources to create the right number
of RAD teams.

• RAD requires developers and customers who are

committed to the rapid-fire activities necessary to get a
system complete in a much abbreviated time frame.

• Not all types of applications are appropriate for RAD.

If a system cannot be properly modularized, building
the components necessary for RAD will be problematic.

•If high performance is an issue, the RAD approach

may not work.
44
The Incremental Model

The incremental model combines elements of the

linear sequential model (applied repetitively) with the
iterative philosophy of prototyping

The incremental model applies linear sequences in a staggered

fashion as calendar time progresses. Each linear sequence produces a
deliverable “increment” of the software.

For example, word-processing software developed using the

incremental paradigm might deliver basic file management, editing,
and document production functions in the first increment; more
sophisticated editing and document production capabilities in the
second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth
increment. 45
When an incremental model is used, the first
increment is often a core product. That is, basic
requirements are addressed

The core product is used by the customer (or undergoes detailed

review). As a result of use and/or evaluation, a plan is developed for
the next increment.

The plan addresses the modification of the core product to better

meet the needs of the customer and the delivery of additional
features and functionality.

46
47
Incremental development is particularly useful when
staffing is unavailable for a complete implementation.

Early increments can be implemented with fewer

people. If the core product is well received, then
additional staff (if required) can be added to
implement the next increment.

48
Agile Methodology

The Agile method is a project management framework for software

development that emphasizes collaboration, rapid delivery, and
customer feedback.

It's based on the idea that delivering small pieces of working software
quickly can improve customer satisfaction.

Agile is a project management and software development approach

that aims to be more effective.

It focuses on delivering smaller pieces of work regularly instead of

one big launch. This allows teams to adapt to changes quickly and
provide customer value faster.

49
How does Agile work?

•Break down tasks: Divide large tasks into smaller

pieces so they can be completed quickly

•Deliver working software: Focus on delivering

working software with minimal or no errors
•
•Embrace(hold) change: Welcome changes to
requirements and deliveries, even late in the project

•Test continuously: Test code throughout

development to identify issues and make changes

•Get customer feedback: Receive feedback from

customers regularly to improve the product
50
51
values of Agile

•Individuals and interactions: Value individuals

and interactions over processes and tools

•Working software: Value working software over

comprehensive documentation

•Customer collaboration: Value customer

collaboration over contract negotiation

•Responding to change: Value responding to

change by following a plan

52
some Agile frameworks

•Scrum: Builds a product in a series of fixed-length

iterations called sprints

•Kanban: a visual project management framework that helps

teams visualize their work and improve efficiency

•Extreme Programming (XP): Outlines values like

communication, simplicity, Continuous feedback,
courage, and respect

53