Software Project Management

Lecture # 6

Outline

Recap of topics from Chapter 23 Remaining topics of Chapter 23

The Software Equation The Make/Buy Decision Outsourcing

Project Scheduling (Chapter 24) What is Scheduling? What is Tracking? Project Scheduling Late Software Delivery & Project Deadlines Project Scheduling Principles People and Effort Relationship

Recap – “Software Estimation”

Software project planner must estimate the following important things before the project begins How long it will take? How much effort will be required? How much money will be involved? How many resources will be required?

People Reusable software Software/hardware

Risk consideration In the beginning, project’s scope and feasibility are

determined. The scope helps develop estimates using one or more techniques that fall into 2 broad categories Decomposition Empirical modeling

Recap – “Software Estimation”

Decomposition involves identifying major software function followed by estimates for each

Empirical techniques use empirically derived expressions for effort and time estimation

Software estimation can never be an exact science but use of good historical data and systematic techniques can improve estimation accuracy

The Software Equation

Suggested by Putnam & Myers It is a multivariable model It assumes a specific distribution of effort over life of

s/w project It has been derived from productivity data collected

for over 4000 modern-day s/w projects E = [LOC x B0.333 / P]3 x (1/t4)

E = effort in person-months or person-years B = special skills factor P = productivity factor t = project duration (months or years)

The Software Equation (Cont.) P reflects

Overall process maturity Management practices Extent to which good s/w engg practices are used Level of prog. Languages used State of s/w environment Skills & experience of team Application complexity

Typical values of P P= 2000 - for a real-time embedded s/w P= 10,000 - for telecomm. & systems s/w P= 28,000 for business applications

Value of B increases slowly as “the need for integration, testing, quality

assurance, documentation and management skills grows”. For small programs (KLOC=5 to 15), B= 0.16, for larger

programs (KLOC=more than 70), B=0.39

The Software Equation (Cont.)

Software equation has two independent parameters LOC t

Minimum dev. Time equations derived from software equation tmin= 8.14 (LOC/P)0.43

in months for tmin> 6 months E = 180 Bt3

In person-months for E>= 20 person-months

The Make/Buy decision

Often it is more cost effective to acquire rather than develop a software

Software managers have following options while making make/buy decisions Software may be purchased (or licensed) off the shelf “Full experience” or “partial experience” software

components may be acquired and then modified as needed

Software may be custom-built by an outside contractor to meet specifications

Software criticality to be purchased and the end cost also affect acquisition process

The Make/Buy decision (Cont.)

For each of the discussed acquisition options, the Make/Buy decision is made based on following conditions Will he software product be available sooner

than internally developed software? Will the acquisition cost plus cost of

customization be less than cost of developing the software internally?

Will the cost of outside support (e.g., maintenance contract) be less than the cost of internal support?

Decision Tree

system Xsystem Xreusereuse

simple (0.30)simple (0.30)

difficult (0.70)difficult (0.70)

minorminor changeschanges

(0.40)(0.40)

majormajorchangeschanges

(0.60)(0.60)

simple (0.20)simple (0.20)

complex (0.80)complex (0.80)

majormajor changeschanges (0.30)(0.30)

minorminor changeschanges

(0.70)(0.70)

$380,000$380,000

$450,000$450,000

$275,000$275,000

$310,000$310,000

$490,000$490,000

$210,000$210,000

$400,000$400,000

buybuy

contractcontract

without changes (0.60)without changes (0.60)

with changes (0.40)with changes (0.40)

$350,000$350,000

$500,000$500,000

buildbuild

Estimated path cost

Means 30% probability

Expected value of cost computed along each branch of the decision tree is:

where i is the decision tree path, for example, For Build path

expected cost = 0.30($380K)+0.70($450K) = $429K Similarly, for Reuse path, expected cost is $382K; for Buy

path, it is $267K; for Contract path, it is $410K. So the obvious choice is “to buy”

Decision Tree

ΣΣ (path probability) (path probability)ii x (estimated path cost) x (estimated path cost)ii expected cost =expected cost =

Outsourcing

Acquisition of software (or components) from a source outside the organization

Software engineering activities are contracted to a third party who does the work at lower cost and (hopefully) at higher quality

Software work within the company is reduced to contract management activity

Outsourcing is often a financial decision Positive side

Cost saving can usually be achieved by reducing own resources (people & infrastructure)

Negative side Company loses some control over the software and bears

the risk of putting its fate in hands of a third party

Project Scheduling (Chap. 24 )

Introduction

After the following have been achieved… Process model selection S/w engg. tasks identification Estimation of amount of work & people Risk consideration and knowing deadline

… the task is to create a setup for achieving the software engineering tasks. This setup is called ‘software project scheduling and tracking’

What is scheduling?

An activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering task

Creating a network of software engineering tasks to complete the project and assign responsibilities of tasks and timing of tasks

What is Tracking?

Tracking is the process to make sure that all tasks are completed according to assigned responsibility and schedule.

Overview – Proper Scheduling

Proper Project Scheduling requires All tasks should appear in the network Interdependencies between tasks are indicated Effort and timing are intelligently allocated to

tasks Resources are allocated to tasks Closely spaced milestones are provided for

progress tracking

Reasons for late software delivery

Unrealistic deadline established by some one outside the software development group & enforced

Changing customer requirements that are not reflected in schedule change

An honest underestimate of the amount of work and/or resources required

Risks that were not considered at project commencement

Technical difficulties not foreseen in advance Miscommunication among project staff A failure by project management to recognize that

the project is falling behind schedule and a lack of action to correct the problem.

Dealing With Project Deadlines

Aggressive (actually unrealistic) deadlines are a fact of life in software business

If best estimates indicate that deadline is unrealistic Project Manager should

“Protect his/her team from undue (schedule) pressure… and reflect pressure back to its originators.”

Recommended steps for such situations:1. Perform a detailed estimate using historical data from past

projects. Determine effort and time required.2. Use incremental model, develop a strategy that will deliver

critical functionality within imposed deadline, but delay other functionality until later. Document the plan.

Dealing With Project Deadlines

3. Meet the customer and explain why deadline is unrealistic. Explain what is the new time required to complete this project.

4. Offer incremental development strategy as alternative. Offer some options.

We can increase the budget and have bring resources to get this job done in due time. But this contains increased risk of poor quality due to tight timeline.

We can remove some software functions, and provide remaining functionality later.

Dispense with reality and wish to complete software in due time.

By presenting solid estimates and references to past projects, it is likely that, negotiated version option 1 and 2 will be accepted by customer.

Project Schedule (Evolution)

Project schedules evolve over time During early stages of project planning, a

macroscopic schedule is developed This schedule identifies all major process

framework activities and the product functions to which they are applied

As the project proceeds, each entry on the macroscopic schedule gets refined into detailed schedule

Specific tasks are identified to achieve each activity and are scheduled

Project Scheduling - Basic Principles

Compartmentalization Both the product and the process are decomposed into a

number of manageable activities/tasks Interdependency

Interdependencies among decomposed activities must be identified.

Some tasks can be performed in sequence and other can be done in parallel.

Some activities can not be performed without completion of another and some can be totally independent

Time Allocation Each task must be allocated work units (person-days of

effort) Start and end time must be allocated considering

interdependencies

Project Scheduling - Basic Principles

Effort validation Project manager must ensure that no more than the

allocated no. of people have been scheduled at any given time

Defined responsibilities Every scheduled task must be assigned to a specific team

member Defined outcomes

Work products must be defined for every scheduled task Defined milestones

Every task/group of tasks must be associated with a project milestone. A milestone is accomplished after one or more related work products has been reviewed for quality and approved

Relationship of People and Effort

Common Myth … “If we fall behind schedule, we can always add

more programmers and catch up later in the project!”

Doing so is often disruptive rather than productive causing further delays. Reasons: learning time teaching takes time away from productive work added communication paths – increased

complexity

Relationship of People and Effort

Putnam-Norden-Rayleigh (PNR) Curve indicates the relationship between effort applied and delivery time for a software project.

PNR curve was used to derive the software equation

to = delivery time that will result in least effort expended As we move left to to, i.e. as we try to accelerate delivery, curve rises

nonlinearly As we try to reduce accelerate delivery, curve rises sharply to left of td

indicating, project delivery time can not be compressed much beyond 0.75td

As we try further, the project moves into impossible region and failure risk becomes high

Tmin=0.75Td td to Development Time

Effort Cost

Ed

Eo

Impossible

Region

PNR Curve & Software Eqn.

The software equation is derived from the PNR curve

It demonstrates a highly nonlinear relationship between time to complete project and human effort applied to the project

Lines of Code (L) is related to effort (E) and development time (t) as:

L = P x E 1/3 t 4/3

Rearranging the equation E = L3 / P3t4