Introduction to Software

Development Process

Lecture - 2

1
 References
• Chapter 12: Software Lifecycle from Object
Oriented Software Engineering: Conquering
Complex and Changing Systems.

• IEEE Std 1074-1997, IEEE Standard for

Developing Software Life Cycle Processes,
Software Engineering Standards Committee,
December 1997.
2
 Software Lifecycle (SLC) Models
• Represent all the activities and work products
necessary to develop a software system.
• Enable managers and developers to deal with
the complexity of the process of developing
software in the same way as an analysis or a
design model assists a developer in dealing
with the complexity of a software system.
• Used to better understand, measure and control
the development process by making the
activities and their dependencies visible and
manageable.
3
 Modeling the Software Lifecycle
• Activity centered models
– Models focusing on the activities of software
development.
• Entity centered models
– Models focusing on work products created by the
software development activities.
• Activity centered view leads participants to
focus on how work products are created.
• Entity centered view leads participants to focus
on the content and structure of work products.
4
 A Simple Activity Centered SLC

Problem System System

Definition Development Operations
Activity Activity Activity

Sequential Activities in SLC

System
Development
Activity
System
Market Upgrade
Creation Activity
Activity
Concurrent Activities in SLC 5
 A Simple Entity Centered SLC
Market Survey Executable
Document System

Consists of Consists of
System
Development
Project

Consists of Consists of

Specification
Test Results
Document 6
Relationship Between Types
of SLC Models
• Complementary views of SLC.

• Each work product has one or more

activity associated with it.

• Every activity may generate one or

more work products.

7
 Relationship Between Types
of SLC Models (Contd.)
Activity Associated Work
Products
Problem Definition Market Survey (Input),
System Specs (Output)
System Development System Specs (Input),
Executable System
(Output)
System Operation Lessons Learnt

8
 IEEE 1074: Standard for
Developing Lifecycle Processes
• Describes sets of activities and processes
mandatory for development and maintenance
of software.
• Focuses on the establishment of a common
framework for developing lifecycle models and
providing examples for typical situations.
• Lists 17 processes grouped into 6 process
groups.
• Each process consists of activities.
9
 Software Processes Defined in
IEEE 1074
Process Groups Processes
Lifecycle Modeling Selection of a lifecycle model

Project Management Project Initiation, Project Monitoring & Control,

Software Quality Management
Pre-Development Concept Exploration, System Exploration

Development Requirements, Design, Implementation

Post-Development Installation, Operations & Support, Maintenance,

Retirement
Integral Processes Verification & Validation, Software Configuration
Management, Documentation, Training 10
 Lifecycle Modeling
• Project manager customises activities
defined in IEEE 1074 for a specific project.

• Not all projects require same activities and

the same sequence of activities.

• Selected lifecycle models serve as inputs to

the project initiation phase.
11
 Project Management
Activities that allow the project manager to initiate, monitor
and control the project throughout the project lifecycle
Process Activities
Project Initiation Map Activities to Software Life Cycle Model
Allocate Project Resources
Establish Project Environment
Plan Project Management
Project Monitoring Analyse Risks
Perform Contingency Planning
and Control Manage Project, Retain Records
Implement Problem Reporting Model
Software Quality Plan Software Quality Management
Define Metrics
Management Manage Software Quality
12
Identify Quality Improvement Needs
 Pre-Development
A concept or an idea for development is formalised and its
requirements are analysed to develop an architecture

Process Activities

Concept Identify Ideas or Needs

Formulate Potential Approaches
Exploration
Conduct Feasibility Studies
Plan System Transition (If Applicable)
Refine or Finalise the Idea or Need

System Analyse Functions

Develop System Architecture
Allocation
Decompose System Architecture

13
 Development
Directed towards the construction of the system. Results in
the definition of design objects, their attributes, their
operations and their organisation into packages
Process Activities
Requirements Define and Develop Software Requirements
Define Interface Requirements
Prioritise and Integrate Software Requirements

Design Perform Architectural Design

Design Database (If Applicable)
Design Interfaces, Select or Develop Algorithms,
Perform Detailed Design
Implementation Create Test Data, Create Source Code,
Generate Object Code, Create Operating
Documentation,
Plan Integration,
14
Perform Integration
 Post-Development
Consists of installation, maintenance, operations, support
and retirement processes
Process Activities
Installation Plan Installation,
Distribution of Software,
Installation of Software,
Accept Software in Operational Environment

Operation Operate the System,

Provide Technical Assistance and Consulting,
and Support
Maintain Support Request Log

Maintenance Reapply Software Lifecycle

Retirement Notify Users,

Conduct Parallel Operations,
Retire Systems 15
 Integral Processes
(Cross Development)
Activities that take place through out the project

Process Activities
Verification and Plan Verification and Validation,
Execute Verification and Validation Tasks,
Validation
Collect and Analyse Metric Data,
Plan Testing,
Develop Test Requirements,
Execute the Tests

Software Plan Configuration Management,

Develop Configuration Identification,
Configuration
Perform Configuration Control,
Management Perform Status Accounting 16
 Integral Processes
(Cross Development)
Process Activities
Documentation Plan Documentation,
Implement Documentation,
Development
Produce and Distribute Documentation

Training Plan the Training Programme,

Develop Training Materials,
Validate the Training Programme,
Implement the Training Programme

17
 Software Lifecycle Models
• Dependencies exist between processes defined
in IEEE-1074

• Each process generates a work product that is

consumed by another.

• Each dependency represents a formal

communication channel between project
participants supported by relevant work
products.
18
 Software Lifecycle Models (Contd.)
• Software Lifecycle Models (SLCMs) form basic
framework from which Software Lifecycle
Processes (SLCPs) are developed.
• SLCMs define the framework for the selection
of activities and the order of their execution.
• Different projects require different SLCMs, e.g.,
– Development based heavily on reuse may involve a
largely sequential lifecycle.
– Development of a new product may involve iterative
processes with substantial concurrency.
19
 Waterfall SLCM

• An activity centered SLCM prescribing a

sequential execution of a subset of the
development and management processes.
• Requirements elicitation and analysis activities
are completed before system design activity
starts.
• A constant verification and validation activity
required to ensure the development of
functionally correct and error-free software.
20
 Waterfall SLCM (Contd.)
• Provides a simplistic view of the software
development activity, measuring progress
by the number of tasks that have been
completed.

• Assumes that software development can

be scheduled as a step by step process
that transforms user needs into code.

21
Waterfall SLCM (Contd.)

22
 DoD 2167A Waterfall SLCM
• Each development activity is followed by a
review.
• Starts from the system requirements analysis
activity with a goal to generate unambiguous
system requirements.
• Design only starts once the requirements are
considered to be complete, consistent and clear
by the System Requirements Review.
• System design forms a basis for the software
requirements analysis.
23
 DoD 2167A Waterfall SLCM(Contd.)
• Software requirements form the basis for
software design and implementation activities.

• Implementation starts with the preliminary

design activity.

• Preliminary design is followed by detailed

design.

• Coding starts after a Critical Design Review. 24

DoD 2167A
Waterfall Model
(Contd.)

25
 Spiral SLCM
• An activity centered SLCM devised to address
the source of weaknesses in the Waterfall
SLCM.

• Accommodates infrequent changes during the

software development process.

• Adds activities related to risk management,

reuse and prototyping to each activity.

• Activities are termed as cycles or rounds.

26
 Spiral SLCM (Contd.)
• Each quadrant of a cycle specifies particular
tasks, i.e.,
– Top left: Determine objectives, alternatives and
constraints.
– Top right: Evaluate alternatives, identify and
resolve risks.
– Bottom right: Develop and verify next level of the
product.
– Bottom left: Plan next phase.

• Rounds follow the Waterfall SLCM.

27
 Spiral SLCM (Contd.)
• Distance from the center indicates the
cost accumulated by the project.

• Angular distance indicates the progress

accomplished in each phase

28
Spiral SLCM (Contd.)

29
 Shark Tooth SLCM
• Waterfall and Spiral SLCMs emphasize the
management of software developers and do not
address the needs of customers and users.
• These models assume that software
requirements do not change drastically within
the duration of the project.
• Clients and users do not see an executing
system before the clients’ acceptance test and
therefore cannot correct any requirement
errors.
30
 Shark Tooth SLCM (Contd.)
• At the requirements stage, developers and
clients are at the same level of abstraction.
• While the users remain at the same level of
abstraction, the developers’ perspective shifts.
• This model aims to reduce the gap between the
users’ level of abstraction and the developers’
level of abstraction.
• A revolutionary (throwaway) prototype is
demonstrated to the users early in the
development stages.
31
 Shark Tooth SLCM (Contd.)
• The second evolutionary prototype is based on
the design and is demonstrated later in the
project when some functionality has been
implemented.
• Design reviews and demonstrations of
integration prototypes are held with the project
manager.
• A simple integration prototype demonstrates
the interaction between major components of
the system.
32
Shark Tooth SLCM (Contd.)

33
 Prototyping
• Process of using a prototype to seek
information needed to make decisions.
• Reduces the risk of making mistakes in setting
requirements or in designing system
architecture.
• Prototype is a preliminary, intentionally
incomplete or scaled down version of a system.
– Used for demonstrating certain essential artifacts of
the system being developed.
• Prototypes are not as robust or functionally
complete as are the deliverable products. 34
 Prototyping (Contd.)
• Characteristics of prototypes
– A requirements definition medium.
– Means of providing the users with a physical
representation of key parts of the system before
its complete implementation.
– Functional after a modest amount of effort.
– Flexible to allow modifications conveniently.
– Not necessarily complete or intended to be the
final system.

35
 Categories of Prototypes
• Analysis prototypes
– Partially executable mockups of the product.
– Assists in clarification of requirements and
solicitation of new ideas.
• Design prototypes
– Developed to explore and understand a system’s
implementation and architecture.
– Forms the basis for storage and performance
evaluations.
– Assists in detecting redundancies and
inconsistencies in the design. 36
 Categories of Prototypes (Contd.)
• Vertical prototyping
– Used to understand a specific partition of a problem and
to suggest a suitable solution.
– Required for components whose concepts are not well
understood and a complete functional model is required
for explanatory and exploratory purposes.
• Feasibility prototyping
– Used to demonstrate the applicability of a specific
architecture, process or an implementation technique .
– Used to measure and evaluate performance under
specific load.
– Used to evaluate the application of a specific
technology in the product.
37