Ch. 7 1

The software production process

Ch. 7 2

Questions

• What is the life cycle of a software product?

• Why do we need software process models?

• What are the goals of a software process and what makes it different from other industrial processes?

Ch. 7 3

Life cycle

• The life cycle of a software product– from inception of an idea for a

product through• requirements gathering and analysis• architecture design and specification• coding and testing• delivery and deployment• maintenance and evolution• retirement

Ch. 7 4

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

Ch. 7 5

Code&Fix

The earliest approach • Write code• Fix it to eliminate any errors that

have been detected, to enhance existing functionality, or to add new features

• Source of difficulties and deficiencies– impossible to predict– impossible to manage

Ch. 7 6

Models are needed

• Symptoms of inadequacy: 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"

Ch. 7 7

Process as a "black box"

Product

Process

Informal Requirements

Ch. 7 8

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

Ch. 7 9

Process as a "white box"

Product

Process

Informal Requirements

feedback

Ch. 7 10

Advantages

• Reduce risks by improving visibility• Allow project changes as the

project progresses– based on feedback from the customer

Ch. 7 11

The main activities

• They must be performed independently of the model

• The model simply affects the flow among activities

Ch. 7 12

Feasibility study

• Why a new project?– cost/benefits tradeoffs– buy vs make

• Requires to perform preliminary requirements analysis

• Produces a Feasibility Study Document1. Definition of the problem2. Alternative solutions and their expected

benefits3. Required resources, costs, and delivery dates

in each proposed alternative solution

Ch. 7 13

Requirements engineering activities

Ch. 7 14

Requirements engineering

• Involves – eliciting– understanding– analyzing– specifying

• Focus on– what qualities are needed, NOT on– how to achieve them

Ch. 7 15

What is needed

• Understand interface between the application and the external world

• Understand the application domain• Identify the main stakeholders and

understand expectations– different stakeholders have different

viewpoints– software engineer must integrate and

reconcile them

Ch. 7 16

The requirements specification document (1)• Provides a specification for the

interface between the application and the external world– defines the qualities to be met

• Has its own qualities– understandable, precise, complete,

consistent, unambiguous, easily modifiable

Ch. 7 17

The requirements specification document (2)• Must be analyzed and confirmed

by the stakeholders– may even include version 0 of user

manual

• May be accompanied by the system test plan document

Ch. 7 18

The requirements specification document (3)• As any large document, it must be

modular– "vertical" modularity

• the usual decomposition, which may be hierarchical

– "horizontal" modularity• different viewpoints

• Defines both functional and non functional requirements

Ch. 7 19

A case study railway automation

• Who are the stakeholders?– management of the train company– train drivers and their unions– passengers (customers)– contractors

• Each has different goals

Ch. 7 20

Case studyhow to classify requirements

• Safety requirements– the probability of accidents should be

less than 10-9 per year

• Utility requirements– level of usefulness of the system as

perceived by the various stakeholders

Ch. 7 21

Case studythe produced document

• Introduction: the “mission” of the system

• Architecture: the main structure of the system

• Specific requirements associated with each subsystem– discussion of how the subsystems’

requirements guarantee that the overall goals are indeed achieved

Ch. 7 22

Software architecture and detailed design activity

• The result of this activity is a Design Specification Document

• Usually follows a company standard, which may include a standard notation, such as UML

Ch. 7 23

Coding and module testing activity

• Company wide standards often followed for coding style

• Module testing– based on black box/white box criteria

Ch. 7 24

Integration and system test activity

• These activities may be integrated with coding and module testing

• Integration may be done incrementally through subsystems– top down vs. bottom up

• The last step is system test– may be followed by alpha testing

Ch. 7 25

Delivery, deployment, and maintenance activities

• Delivery– real delivery may be preceded by

beta testing• Deployment

– components allocated on physical architecture

• Maintenance– corrective, adaptive, perfective

Ch. 7 26

Maintenance

• Requirements errors are main cause of maintenance activities

• Late discovery of requirements errors causes increased costs

Ch. 7 27

Other software activities

• Documentation• Verification• Management

They can be considered as parts of any kind of software related activity

Ch. 7 28

Overview of software process models

Ch. 7 29

Waterfall models

• Invented in the late 1950s for large air defense systems, popularized in the 1970s

• They organize activities in a sequential flow

• Exist in many variants, all sharing sequential flow style

Ch. 7 30

Feasibility study

Requirements

Design

Coding and module testing

Integration and system testing

Delivery, deployment, and maintenance

A waterfall model

Ch. 7 31

Critical evaluation of the waterfall model

+sw process subject to discipline, planning, and management

+postpone implementation to after understanding objectives

– linear, rigid, monolithicno feedbackno parallelisma single delivery date

Ch. 7 32

Feasibility study

Requirements

Design

Coding and module testing

Integration and system testing

Delivery, deployment, and maintenance

Waterfall with feedback

Ch. 7 33

Problems with waterfall

• Estimates made when limited knowledge available

• Difficult to gather all requirements once and for all– users may not know what they want– requirements cannot be frozen

Ch. 7 34

Evolutionary models• Many variants available• Product development evolves through

increments– "do it twice" (F. Brooks, 1995)– evolutionary prototype

• Evolutionary process model (B. Boehm, 1988)"model whose stages consist of expanding

increments of an operational software product, with the direction of evolution being determined by operational experience"

Ch. 7 35

Transformation model

• Guided by formal methods• Specifications transformed into

implementations via transformations

• Still a theoretical reference model

Ch. 7 36

Requirements analysis and specification

OptimizationRequirements

Formal specifications

Verification Tuning

Lower level specifications

Recording of developmental history

Reusable components

Decisions & rationale

Transformation model

Ch. 7 37

Spiral modelB. Boehm, 1989

Ch. 7 38

A final model assessment(1)

• Waterfall– document driven

• Transformational– specification driven

• Spiral– risk driven

Ch. 7 39

A final model assessment(2)

• Flexibility needed to reduce risks– misunderstandings in requirements– unacceptable time to market

• Waterfall may be useful as a reference structure for documentation– describes the "rationale" a posteriori

(Parnas and Clements, 1989)

Ch. 7 40

Software evolution• Existing software must evolve because

requirements change• Re-engineering

– process through which an existing system undergoes an alteration, to be reconstituted in a new form

• Reverse engineering– from an existing system to its

documentation, which may not exist, or may be incomplete

– includes program understanding– preventive maintenance

Ch. 7 41

Open source

• Regulates licensed software, specifying its use, copy, modification, and distribution rights

• Business does not derive from selling software, but rather from other, indirect activities (services, accessories, advertisement, etc.)

Ch. 7 42

Methodologies to organize the process

Ch. 7 43

SA/SD

• Structured Analysis/Structured Design• 3 major conceptual tools for modeling

– data flow diagrams• functional specifications

– data dictionaries• centralized definitions

– Structured English• to describe transformation of terminal

bubbles

Ch. 7 44

DFDs: a reminder

A file

Adata

transformer

An output deviceAn input

device

Ch. 7 45

Employee_1

Registration

Employee_2

Authorization

Employee_3

Response

Request

Request

Result

Authorized_requests

Employee_4Employee_6

Employee_5

Process ProcessProcess

Order_request

Complete_order

Analysis ofoffice work

Ch. 7 46

Unified Software Development Process

(UP)

Ch. 7 47

Principles

• Development of an OO system• Uses the UML notation throughout

the process• Supports an iterative and

incremental process• Decomposes a large process into

controlled iterations (mini projects)

Ch. 7 48

Cycles and phases of a cycle

time

death

cycle1 ... cycle2 cycle n

product releases

milestone

product release Inception Elaboration Construction Transition

Ch. 7 49

Distribution of workflows over phases

inception elaboration construction transition

Iter1 Iter2 ... ... ... ... ... ... ... ... Iter n

Requirements

Analysis

Design

Implementation

Testing

Ch. 7 50

Organizing artifactsConfiguration management

Ch. 7 51

CM concepts

• Configuration– identifies components and their

versions

• Configuration management– discipline of coordinating software

development and controlling the change and evolution of software products and components

Ch. 7 52

Key CM issues

• Multiple access to shared repository

• Handling product families– different members of the family

comprise components which may have different versions

Ch. 7 53

Member 1

A

B

C1

Member 2

A

B

C2

Member 3

A

D

1

2

3

A

A

B

D

E

A

C C

1

1

2

2

3

Component database

Ch. 7 54

Versions

• Can be refined into– revisions

• new version supersedes the previous• define a linear order

– variants• e.g., alternative implementations of the

same specification for different machines, or access to different I/O devices

Ch. 7 55

Software standards

Ch. 7 56

Why standards?

• They are needed to achieve quality in both software products and processes

• They may be imposed internally or externally – e.g., MIL-STD 2167A imposed to

contractors for military applications

• Other examples: ISO series, IEEE

Ch. 7 57

Main benefits

• From the developers' viewpoint– standards enforce a uniform behavior within

an organization– they facilitate communication among people,

stabilizes the production process, and makes it easier to add new people to ongoing projects

• From the customers' viewpoint– they make it easier to assess the progress and

quality of results– they reduce the strict dependency of

customers on specific contractors