1

Introduction to Software Development Process

Lecture - 2

2

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.

3

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.

4

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.

5

A Simple Activity Centered SLC

Problem DefinitionActivity

SystemDevelopment

Activity

SystemOperations

Activity

Sequential Activities in SLC

Market Creation Activity

SystemDevelopment

Activity

SystemUpgradeActivity

Concurrent Activities in SLC

6

A Simple Entity Centered SLC

System Development

Project

Market Survey Document

Specification Document

ExecutableSystem

Test Results

Consists of

Consists of Consists of

Consists of

7

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.

8

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

9

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.

10

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

11

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.

12

Project ManagementActivities 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

and Control

Analyse Risks

Perform Contingency Planning

Manage Project, Retain Records

Implement Problem Reporting Model

Software Quality

Management

Plan Software Quality Management

Define Metrics

Manage Software Quality

Identify Quality Improvement Needs

13

Pre-DevelopmentA concept or an idea for development is formalised and its requirements are analysed to develop an architecture

Process Activities

Concept Exploration

Identify Ideas or Needs

Formulate Potential Approaches

Conduct Feasibility Studies

Plan System Transition (If Applicable)

Refine or Finalise the Idea or Need

System Allocation

Analyse Functions

Develop System Architecture

Decompose System Architecture

14

DevelopmentDirected 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,

Perform Integration

15

Post-DevelopmentConsists 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 and Support

Operate the System,

Provide Technical Assistance and Consulting,

Maintain Support Request Log

Maintenance Reapply Software Lifecycle

Retirement Notify Users,

Conduct Parallel Operations,

Retire Systems

16

Integral Processes (Cross Development)

Activities that take place through out the project

Process Activities

Verification and Validation

Plan Verification and Validation,

Execute Verification and Validation Tasks,

Collect and Analyse Metric Data,

Plan Testing,

Develop Test Requirements,

Execute the Tests

Software Configuration Management

Plan Configuration Management,

Develop Configuration Identification,

Perform Configuration Control,

Perform Status Accounting

17

Integral Processes (Cross Development)

Process Activities

Documentation Development

Plan Documentation,

Implement Documentation,

Produce and Distribute Documentation

Training Plan the Training Programme,

Develop Training Materials,

Validate the Training Programme,

Implement the Training Programme

18

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.

19

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.

20

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.

21

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.

22

Waterfall SLCM (Contd.)

23

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.

24

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.

25

DoD 2167A Waterfall Model (Contd.)

26

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.

27

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.

28

Spiral SLCM (Contd.)

• Distance from the center indicates the cost accumulated by the project.

• Angular distance indicates the progress accomplished in each phase

29

Spiral SLCM (Contd.)

30

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.

31

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.

32

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.

33

Shark Tooth SLCM (Contd.)

34

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.

35

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.

36

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.

37

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.