Understanding Software Development Life Cycle Models, Slides of Software Development Methodologies

Download Understanding Software Development Life Cycle Models and more Slides Software Development Methodologies in PDF only on Docsity!

Software Construction &

Development

(SE-345 )

Lecture 01

Software Processes

Question

◼ Suppose you get a set of requirements to

develop a product from customer.

 What should you do?

 How should you start?

 How to make sure that the product is

delivered in the given cost and time

estimates?

Department of Software Engineering

Software Process Model

◼ Attempt to organize the software life cycle

by

◼ defining activities involved in software production

◼ order of activities and their relationships

◼ Goals of a software process

 standardization, predictability, productivity,

high product quality, ability to plan time and

budget requirements

Department of Software Engineering

A software life cycle is a

process

◼ A process involves activities, constraints and resources

that produce an intended output.

◼ Each process activity, e.g., design,

must have entry and exit criteria— why?

◼ A process uses resources, subject to constraints (e.g., a

schedule or a budget)

◼ A process is organized in some order or sequence,

structuring activities as a whole

◼ A process has a set of guiding principles or criteria that

explain the goals of each activity

Department of Software Engineering

Models are needed

◼ Symptoms (signs) of inadequacy

(lack/shortage): the software crisis

 scheduled time and cost exceeded

 user expectations not met

 poor quality

◼ The size and economic value of

software applications required

appropriate "process models"

Department of Software Engineering

Process model goals

(B. Boehm 1988)

"determine the order of stages involved in

software development and evolution,

and to establish the transition criteria for

progressing from one stage to the next.

These include completion criteria for the current

stage plus choice criteria and entrance criteria

for the next stage. Thus a process model addresses

the following software project questions:

What shall we do next?

How long shall we continue to do it?"

Department of Software Engineering

Problems

◼ The assumption is that requirements can

be fully understood prior to development

◼ Interaction with the customer occurs only

at the beginning (requirements) and end

(after delivery)

◼ Unfortunately the assumption almost

never holds

Department of Software Engineering

Process as a "white box"

Product Process Informal Requirements feedback 11

The main activities

◼ They must be performed independently of

the model

◼ The model simply affects the flow among

activities

Department of Software Engineering

Feasibility study

◼ Why a new project?

 cost/benefits tradeoffs

 buy vs make

◼ Requires to perform preliminary requirements

analysis

◼ Produces a Feasibility Study Document

1. Definition of the problem
2. Alternative solutions and their expected benefits
3. Required resources, costs, and delivery dates in each proposed alternative solution Department of Software Engineering

Waterfall Model

◼ Cascades (flow) from one stage down to

the next, in stately, lockstep, glorious order.

 Gravity only allows the waterfall to go

downstream;

 it’s very hard to swim upstream

◼ US Department of Defense contracts

prescribed this model for software

deliverables for many years, in DOD

Standard 2167-A.

Department of Software Engineering

Why would corporate manager

types like the waterfall life cycle

model?

◼ Minimizes change, maximizes predictability

◼ Costs and risks are more predictable

◼ Each stage has milestones and deliverables: project

managers can use to gauge how close project is to

completion

◼ Sets up division of labor: many software shops associate

different people with different stages:

 Systems analyst does analysis,  Architect does design,  Programmers code,  Testers validate, etc. Department of Software Engineering

V Model

Department of Software Engineering

V Model

◼ Developed by the German Ministry of Defense

◼ What does this model highlight?

 Unit and system testing verify the program design, ensuring that parts and whole work correctly  Acceptance testing, conducted by the customer rather than developers, validates the requirements, trying each system function meets a particular requirement in the specification

◼ How does this model account for cycles?

 If problems are found during verification or validation, then re- execute left side of V to make fixes and improvements  While the waterfall emphasizes documents and artifacts, the V model emphasizes activities and correctness Department of Software Engineering