Software project management
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

Software Project Management PowerPoint PPT Presentation


  • 61 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Software Project Management

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Software project management

Software Project Management

Lecture # 6


Outline

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

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 estimation1

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

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

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 cont1

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

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

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

Decision Tree

Means 30% probability

Estimated path cost


Decision tree1

Decision Tree

  • 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”

expected cost =

Σ (path probability)i x (estimated path cost)i


Outsourcing

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

Project Scheduling (Chap. 24 )


Introduction

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

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

What is Tracking?

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


Overview proper scheduling

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

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

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:

    • Perform a detailed estimate using historical data from past projects. Determine effort and time required.

    • 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 deadlines1

Dealing With Project Deadlines

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

  • 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 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

    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 principles1

    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

    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 effort1

    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


    Software project management

    • 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

    Effort Cost

    Ed

    Eo

    Impossible

    Region

    Tmin=0.75Td td to Development Time


    Pnr curve software eqn

    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


  • Login