04/21/23 CS-499G 1

Costs without Maintenance

10%

10%

15%

20%

20%

25%

Requirements Specifications Design

Coding Unit Test Integration Test

04/21/23 CS-499G 2

Costs with Maintenance3% 3%

5%

7%

7%

9%

66%

Requirements Specifications Design

Coding Unit Test Integration Test

Maintenance

04/21/23 CS-499G 3

Waterfall model

Requirements Definition

System & Software Design

Implementation & Unit Testing

Integration & System Testing

Operation & Maintenance

The drawback of the waterfall model is the difficulty of accommodating change after the process is underway

04/21/23 CS-499G 4

Waterfall Model with Feedback

Requirements Definition

System & Software Design

Implementation & Unit Testing

Integration & System Testing

Operation & Maintenance

04/21/23 CS-499G 5

Iterative Models

listento

customerbuild/revise

mock-up

customertest-drivesmock-up

Prototyping

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

team #1

team #2team #3

60 - 90 days

RAD

04/21/23 CS-499G 6

An Evolutionary (Spiral) Model

CustomerCommunication

Planning

Construction & ReleaseCustomerEvaluation

Engineering

Risk Analysis

04/21/23 CS-499G 7

Why Projects Fail?

an unrealistic deadline is established changing customer requirements an honest underestimate of effort predictable and/or unpredictable risks technical difficulties miscommunication among project staff failure in project management

04/21/23 CS-499G 8

Software Teams

the difficulty of the problem to be solved the size of the resultant program(s) in lines of code or

function points the time that the team will stay together (team

lifetime) the degree to which the problem can be modularized the required quality and reliability of the system to be

built the rigidity of the delivery date the degree of sociability (communication) required for

the project

The following factors must be considered when selecting asoftware project team structure ...

04/21/23 CS-499G 9

Defining the Problem

establish scope—a narrative that bounds the problem

decomposition—establishes functional partitioning

04/21/23 CS-499G 10

To Get to the Essence of a Project

Why is the system being developed? What will be done? By when? Who is responsible for a function? How will the job be done technically and

managerially? How much of each resource (e.g.,

people, software, tools, database) will be needed?

Barry Boehm

04/21/23 CS-499G 11

Task duration and dependencies

Task Duration(days)

Dependencies

T1 8T2 15T3 15 T1T4 10T5 10 T2, T4T6 5 T1, T2T7 20 T1T8 25 T4T9 15 T3, T6T10 15 T5, T7T11 7 T9T12 10 T11

04/21/23 CS-499G 12

Activity network

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/94

8 days

14/7/94 15 days

4/8/94

15 days

25/8/94

7 days

5/9/94

10 days

19/9/94

15 days

11/8/94

25 days

10 days

20 days

5 days25/7/94

15 days

25/7/94

18/7/94

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4

04/21/23 CS-499G 13

Activity timeline4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4T1T2

M1

T7T3

M5T8

M3M2

T6T5

M4T9

M7T10

M6T11

M8T12

Start

Finish

04/21/23 CS-499G 14

Staff allocation

4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

04/21/23 CS-499G 15

Measurement & Metrics

... collecting metrics is too hard

... it's too time-consuming

... it's too political

... it won't prove anything ...

Anything that you need toquantify can be measured insome way that is superior tonot measuring it at all ..

Tom Gilb

04/21/23 CS-499G 16

Metrics Project Metrics

Effort/time per SE task Errors uncovered per review hour Error rate as a function of project time Scheduled vs. actual milestone dates Changes (number) and their characteristics Distribution of effort on SE tasks Estimated vs. actual effort required

Product Metrics focus on the quality of deliverables measures of analysis model complexity of the design

internal algorithmic complexity (e.g., McCabe) architectural complexity data flow complexity

code measures measures of process effectiveness

e.g., defect removal efficiency

04/21/23 CS-499G 17

Typical Metrics Size Oriented

errors per KLOC (thousand lines of code) defects per KLOC $ per LOC page of documentation per KLOC errors / person-month LOC per person-month $ / page of documentation

Function Oriented errors per FP (thousand lines of code) defects per FP $ per FP pages of documentation per FP FP per person-month

04/21/23 CS-499G 18

Measuring Quality Correctness — the degree to which a program

operates according to specification Maintainability—the degree to which a program is

amenable to change Integrity—the degree to which a program is

impervious to outside attack Usability—the degree to which a program is easy

to use

04/21/23 CS-499G 19

Defect Removal Efficiency

where

errors = problems found before release

defects = problems found after release

DRE = (errors) / (errors + defects)

04/21/23 CS-499G 20

Write it Down!

SoftwareProject

Plan

Project ScopeEstimatesRisksScheduleControl strategy

04/21/23 CS-499G 21

To Understand Scope ...

Understand the customers needs understand the business context understand the project boundaries understand the customer’s motivation understand the likely paths for change understand that ...

Even when you understand, nothing is guaranteed!

04/21/23 CS-499G 22

Cost Estimation

Project scope must be explicitly defined

Task and functional decomposition is necessary

Historical measures (metrics) are extremely helpful

Always use more than one metric Always use more than one technique Remember – the only certainty is

uncertainty.

04/21/23 CS-499G 23

Estimation Techniques past (similar) project experience conventional estimation techniques

task breakdown and effort estimates size (e.g., FP) estimates

tools (e.g., Checkpoint)

04/21/23 CS-499G 24

Functional Decomposition

Statementof Scope

Performsometask

functional decomposition

04/21/23 CS-499G 25

Estimation Guidelines

Estimate using at least two techniques Get estimates from independent sources Avoid over-optimism – assume difficulties

Be a pessimist not an optimist Once you obtain an estimate – sleep on it! Adjust for the people doing the job – they have

the biggest impact

Paul P’s Project Plan Guidelines

Remember that you are not doing the work, someone with less experience will be

Estimate the time needed to do each taskAdd 25% for overhead (meetings, vacation,

etc.)Add 25% for contingencyAdd 25% because everyone is always an

optimist (Murphy’s Law: If anything can go wrong, it will)

04/21/23 CS-499G 26

Example

Initial project estimate: 80 person months to complete

25% overhead: 100 PM25% contingency: 125 PM25% to cover for Murphy’s Law: 156 PMActual size of project is almost double initial

estimateWith lots of overtime (and no changes to

the project) you may get it done on schedule

04/21/23 CS-499G 27

04/21/23 CS-499G 28

Project Risks

What can go wrong?What is the likelihood?What will the damage be?What can we do about it?

04/21/23 CS-499G 29

Attributes that affect risk estimated size of the product in LOC or FP estimated size of the product in number or modules, files,

transactions percentage deviation of the size of the product from that of the

average of previous products size of the database created or used by the product number of users of the product number of projected changes to the requirements for the

product: total before delivery after delivery

amount or reused software

Risk Due to Product Size

04/21/23 CS-499G 30

Why Project Planning Pays Off

cost to find and fix a defect

100

10

logscale

1

req.design

codetest sys

testfielduse

0.751.00

1.503.00

10.00

60.00-100.00

04/21/23 CS-499G 31

Reviews & Inspections

... there is no particular reason why your friend and colleague cannot also be your sternest critic.

Jerry Weinberg

04/21/23 CS-499G 32

Reviews

A review is: a meeting conducted by technical people for

technical people a technical assessment of a work product

created during the software engineering process

a software quality assurance mechanism a training ground

A review is not: a project budget summary a scheduling assessment an overall progress report a mechanism for reprisal or political intrigue

04/21/23 CS-499G 33

Conducting the Reviewbe prepared—evaluate product before the review1.

review the product, not the producer

2.

keep your tone mild, ask questions instead of making accusations

3.

stick to the review agenda4.

raise issues, don't resolve them5.

avoid discussions of style—stick to technical correctness

6.

schedule reviews as project tasks7.

record and report all review results8.

04/21/23 CS-499G 34

Metrics Derived from Reviews

inspection time per page of documentation inspection time per KLOC or FP inspection effort per KLOC or FP errors uncovered per reviewer hour errors uncovered per preparation hour errors uncovered per SE task (e.g., design) number of minor errors (e.g., typos) number of major errors (e.g., nonconformance to

req.) number of errors found during preparation

04/21/23 CS-499G 35

Code Reviews Purpose:

Formalized approach to document reviews Intended explicitly for defect DETECTION (not

correction) Defects may be logical errors, anomalies in the code that might

indicate an erroneous condition (e.g. an uninitialized variable) or non-compliance with standards

Preconditions: A precise specification must be available Team members must be familiar with the organization

standards Syntactically correct code must be available An error checklist should be prepared Management must accept that inspection will increase costs

early in the software process Management must not use inspections for staff appraisal

04/21/23 CS-499G 36

Inspection Procedure:

System overview presented to inspection team Code and associated documents are distributed to inspection

team in advance Inspection takes place and discovered errors are noted Modifications are made to repair discovered errors Re-inspection may or may not be required

Teams Made up of at least 4 members

Author of the code being inspected Reader who reads the code to the team Inspector who finds errors, omissions and inconsistencies Moderator who chairs the meeting and notes

discovered errors Other roles are Scribe and Chief moderator