SOFTWARE PROJECT PLANNING - PowerPoint PPT Presentation

Loading...

PPT – SOFTWARE PROJECT PLANNING PowerPoint presentation | free to download - id: 4314e1-MzQzO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

SOFTWARE PROJECT PLANNING

Description:

SOFTWARE PROJECT PLANNING Overview Fundamentals of project planning and estimating Metrics for software productivity assessment Different techniques that can be used ... – PowerPoint PPT presentation

Number of Views:87
Avg rating:3.0/5.0
Slides: 51
Provided by: Wal21
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SOFTWARE PROJECT PLANNING


1
SOFTWARE PROJECT PLANNING
2
Overview
  • Fundamentals of project planning and estimating
  • Metrics for software productivity assessment
  • Different techniques that can be used for
    estimation
  • Algorithmic cost estimation method -COCOMO
  • Project scheduling and tracking
  • Framework for Software Project Management Plan
    (SPMP)

3
Fundamental estimation questions
  • How much effort is required to complete an
    activity?
  • How much calendar time is needed to complete an
    activity?
  • What is the total cost of an activity?
  • Project estimation and scheduling and interleaved
    management activities

4
Planning and estimating
  • Ideally, we would like to plan the entire
    software project at the very beginning of the
    process
  • The earliest possible detailed planning is after
    the specification phase
  • Accuracy of estimation increases as the process
    proceeds
  • Accurate duration estimation is critical
  • Accurate cost estimation is critical
  • Internal cost
  • External cost
  • There are too many variables for accurate
    estimate of cost or duration

5
Software pricing factors
There is not a simple relationship between the
development cost and the price charged to the
customer
6
Overview
  • Fundamentals of project planning and estimating
  • Metrics for software productivity assessment
  • Different techniques that can be used for
    estimation
  • Algorithmic cost estimation method -COCOMO
  • Project scheduling and tracking
  • Framework for Software Project Management Plan
    (SPMP)

7
Programmer productivity
  • A measure of the rate at which individual
    engineers involved in software development
    produce software and associated documentation
  • Not quality-oriented although quality assurance
    is a factor in productivity assessment
  • Essentially, we want to measure useful
    functionality produced per time unit

8
Productivity measures
  • Size related measures based on some output from
    the software process. This may be lines of
    delivered source code, object code instructions,
    etc.
  • Function-related measures based on an estimate of
    the functionality of the delivered software.
    Function-points are the best known of this type
    of measure

9
Lines of code
  • Lines of code (LOC), or
  • Thousand delivered source instructions (KDSI)
  • Source code is only a small part of total
    software effort
  • Different languages ? different lengths of code
  • LOC not defined for nonprocedural languages (like
    LISP)
  • It is not clear how to count lines of code
  • Executable lines of code?
  • Data definitions?
  • Comments?
  • Changed/deleted lines?
  • Not everything written is delivered to the client

10
Function points (FP)
  • Based on a combination of program characteristics
  • external inputs and outputs
  • user interactions
  • external interfaces
  • files used by the system
  • A weight is associated with each of these
  • The function point count is computed by
    multiplying each raw count by the weight and
    summing all values

11
Function points (contd.)
  • For example
  • FP 4 Inp 5 Out 4 Inq 10 Maf 7
    Inf
  • Inp - number of inputs
  • Out number of outputs
  • Inq - inquiries
  • Maf - master files
  • Inf - interfaces
  • FPsmay be subjective

12
Object points
  • Object points are an alternative function-related
    measure to function points when 4Gls or similar
    languages are used for development
  • Object points are NOT the same as object classes
  • The number of object points in a program is a
    weighted estimate of
  • The number of separate screens that are displayed
  • The number of reports that are produced by the
    system
  • The number of 3GL modules that must be developed
    to supplement the 4GL code

13
Object point estimation
  • Object points are easier to estimate from a
    specification than function points as they are
    simply concerned with screens, reports and 3GL
    modules
  • They can therefore be estimated at an early point
    in the development process. At this stage, it is
    very difficult to estimate the number of lines of
    code in a system
  • Object points are used in the COCOMO II
    estimation model

14
Productivity estimates
  • Real-time embedded systems, 40-160 LOC/month
  • Systems programs, 150-400 LOC/month
  • Commercial applications, 200-800 LOC/month
  • In object points, productivity has been measured
    between 4 and 50 object points/month depending on
    tool support and developer capability

15
Quality and productivity
  • All metrics based on volume/unit time are flawed
    because they do not take quality into account
  • Productivity may generally be increased at the
    cost of quality
  • It is not clear how productivity/quality metrics
    are related

16
Overview
  • Fundamentals of project planning and estimating
  • Metrics for software productivity assessment
  • Different techniques that can be used for
    estimation
  • Algorithmic cost estimation method -COCOMO
  • Project scheduling and tracking
  • Framework for Software Project Management Plan
    (SPMP)

17
Estimation techniques
  • Expert judgment
  • Estimation by analogy
  • Pricing to win
  • Algorithmic cost modeling

18
Expert judgment
  • One or more experts in both software development
    and the application domain use their experience
    to predict software costs
  • Process iterates until some consensus is reached
  • Advantages
  • Relatively cheap estimation method
  • Can be accurate if experts have direct experience
    of similar systems
  • Disadvantages
  • Very inaccurate if there are no experts!

19
Estimation by analogy
  • The cost of a project is computed by comparing
    the project to a similar project in the same
    application domain
  • Advantages
  • Accurate if project data available
  • Disadvantages
  • Impossible if no comparable project has been
    tackled
  • Needs systematically maintained cost database

20
Pricing to win
  • The project costs whatever the customer has to
    spend on it
  • This approach may seem unethical and
    un-businesslike. However, when detailed
    information is lacking it may be the only
    appropriate strategy
  • Advantages
  • You get the contract
  • Disadvantages
  • The probability that the customer gets the system
    he or she wants is small
  • Costs do not accurately reflect the work required

21
Top-down and bottom-up estimation
  • Any of these approaches may be used top-down or
    bottom-up
  • Top-down
  • Usable without knowledge of the system
    architecture and the components that might be
    part of the system
  • Takes into account costs such as integration,
    configuration management and documentation
  • Can underestimate the cost of solving difficult
    low-level technical problems
  • Bottom-up
  • Usable when the architecture of the system is
    known and components identified
  • Accurate method if the system has been designed
    in detail
  • May underestimate costs of system level
    activities such as integration and documentation

22
Algorithmic cost modeling
  • Cost is estimated as a mathematical function of
    product, project and process attributes whose
    values are estimated by project managers
  • Effort A SizeB M
  • A is an organization-dependent constant
  • B reflects the disproportionate effort for large
    projects
  • M is a multiplier reflecting product, process and
    people attributes
  • Most commonly used product attribute for cost
    estimation is code size
  • Most models are basically similar but with
    different values for A, B and M

23
Estimation accuracy
  • The size of a software system can only be known
    accurately when it is finished
  • Several factors influence the final size
  • Use of COTS and reused components
  • Programming language
  • Distribution of system
  • As the development process progresses the size
    estimate becomes more accurate

24
Overview
  • Fundamentals of project planning and estimating
  • Metrics for software productivity assessment
  • Different techniques that can be used for
    estimation
  • Algorithmic cost estimation method -COCOMO
  • Project scheduling and tracking
  • Framework for Software Project Management Plan
    (SPMP)

25
The COCOMO model
  • Constructive COst MOdel-an empirical model based
    on project experience
  • http//sunset.usc.edu/csse/research/COCOMOII/cocom
    o_main.html
  • Well-documented, independent model which is not
    tied to a specific software vendor
  • Long history from initial version published in
    1981 (COCOMO-81) through various instantiations
    to COCOMO II
  • COCOMO II takes into account modern SE
    technologies, various life cycle models, rapid
    prototyping, reuse, and COTS software

26
COCOMO 81
27
COCOMO II
  • COCOMO II has three levels that allow
    increasingly detailed estimates to be prepared as
    development progresses
  • Early prototyping level
  • Estimates based on object points and a simple
    formula is used for effort estimation
  • Early design level
  • Estimates based on function points that are then
    translated to LOC
  • Post-architecture level
  • Estimates based on lines of source code

28
Early prototyping level
  • Supports prototyping projects and projects where
    there is extensive reuse
  • Based on standard estimates of developer
    productivity in object points/month
  • Takes CASE tool use into account
  • Formula is PM ( NOP(1 -reuse/100 ) ) / PROD
  • PM is the effort in person-months
  • NOP is the number of object points
  • PROD is the productivity

29
Early prototyping level -Object point productivity
30
Early design level
  • Estimates can be made after the requirements have
    been agreed
  • Based on standard formula for algorithmic models
  • PM A SizeB M PMm
  • where
  • A 2.5 in initial calibration
  • Size in KLOC
  • B varies from 1.1 to 1.24 depending on novelty of
    the project, development flexibility, risk
    management approaches and the process maturity
  • M is multiplier
  • PMm reflects the amount of automatically
    generated code

31
Early design level -Multipliers
  • Multipliers reflect the capability of the
    developers, the non-functional requirements, the
    familiarity with the development platform, etc.
  • M PERS RCPX RUSE PDIF PREX FCIL SCED
  • where
  • PERS - personnel capability
  • RCPX - product reliability and complexity
  • RUSE - the reuse required
  • PDIF - platform difficulty
  • PREX - personnel experience
  • FCIL - the team support facilities
  • SCED - required schedule

32
Post-architecture level -Size
  • Uses same formula as early design estimates
  • Estimate of size is adjusted to take into account
  • Requirements volatility -rework required to
    support change
  • Extent of possible reuse -reuse is non-linear and
    has associated costs so this is not a simple
    reduction in LOC
  • ESLOC ASLOC (AA SU 0.4DM 0.3CM 0.3IM) /
    100
  • ESLOC is equivalent number of lines of new code
  • ASLOC is the number of lines of reusable code
    which must be modified
  • AA is a factor which reflects the initial
    assessment costs of deciding if software may be
    reused
  • SU is a factor based on the cost of software
    understanding
  • DM is the percentage of design modified
  • CM is the percentage of the code that is modified
  • IM is the percentage of the original integration
    effort required for integrating the reused
    software

33
Post-architecture level -Exponent term
  • Sum of 5 scale factors /100 1.01

34
Post-architecture level -Exponent term
  • Example
  • Precedenteness new project Low 4
  • Development flexibility no client involvement
    Very high 1
  • Architecture/risk resolution no risk analysis
    Very low 5
  • Team cohesion new team Nominal 3
  • Process maturity some control nominal 3
  • Scale factor is therefore 1.17

35
Project cost drivers
36
Effects of cost drivers
37
Project duration
  • Calendar time can be estimated using a COCOMO II
    formula
  • TDEV 3 (PM)(0.330.2(B-1.01))
  • PM is the effort computation
  • B is the exponent computed as discussed above (B
    is 1 for the early prototyping model
  • The time required is function of the total
    effort it is independent of the number of people
    working on the project
  • Adding more people to a project that is behind
    schedule is unlikely to help

38
Overview
  • Fundamentals of project planning and estimating
  • Metrics for software productivity assessment
  • Different techniques that can be used for
    estimation
  • Algorithmic cost estimation method -COCOMO
  • Project scheduling and tracking
  • Framework for Software Project Management Plan
    (SPMP)

39
Why are projects late?
  • An unrealistic deadline established by someone
    outside the software development group
  • Changing customer requirements that are not
    reflected in schedule changes
  • An honest underestimate of the amount of effort
    and/or the number of resources that will be
    required to do the job
  • Predictable and/or unpredictable risks that were
    not considered when the project commenced
  • Technical difficulties that could not have been
    foreseen in advance
  • Human difficulties that could not have been
    foreseen in advance
  • Miscommunication among project staff that results
    in delays
  • A failure by project management to recognize that
    the project is falling behind schedule and a lack
    of action to correct the problem

40
Software project scheduling
  • Compartmentalization
  • define a number of manageable distinct tasks
  • Interdependency
  • Determine interdependency of each task
  • Some tasks must occur in sequence, other can
    occur in parallel
  • Time allocation
  • Each task must be allocated a number of work
    units, a start date a completion date
  • Define responsibilities
  • Team members should be assigned to every
    scheduled task
  • Defined outcomes
  • Every task should have a defined outcome (work
    product)
  • Defined milestones
  • Every task or group of tasks should be associated
    with a project milestone work products are
    reviewed for quality and approved

41
Relationship between staff effort
  • Man month as a unit for measuring the size of a
    job is dangerous and deceptive myth
  • Man months are interchangeable only when a task
    can be partitioned among many workers with no
    communication among them some tasks can not be
    partitioned because of sequential constraints
  • The number of people working on a project varies
    depending on the phase of the project
  • Adding people late in a project often causes
    schedules to slip even further

42
Effort allocation 40-20-40 rule
  • Front end activities
  • customer communication
  • analysis
  • design
  • review and modification

40- 50
  • Construction activities
  • coding or code generation

15- 20
  • Testing and installation
  • unit, integration
  • black-box, white-box
  • regression

30- 40
43
Defining a task network
  • Task network (activity network) is a graphic
    representation of the task flow for a project

44
Scheduling
  • Scheduling of software project does not differ
    greatly from scheduling of any multitask
    engineering effort
  • Driven by
  • Estimates of effort
  • A decomposition of the product function
  • The selection of the appropriate process model
    task set
  • Decomposition of tasks

45
Scheduling
  • Tools allow software planner to
  • Determine the critical path (e.g. the chain of
    tasks) that determines the duration of the
    project
  • Establish most likely time estimates for
    individual tasks by applying statistical models
  • Calculate boundary times that define a time
    window for a particular task
  • The earliest time that a task can begin when all
    preceding tasks are completed in the shortest
    possible time
  • The latest time for task initiation before the
    minimum project time completion time is delayed
  • The earliest finish time
  • The latest finish time
  • The total float the amount of surplus time
    allowed in scheduling tasks so that the critical
    path is maintained on schedule

46
Timeline charts
47
Tracking the schedule
  • Conduct periodic project status meetings in which
    each team member reports progress and problems
  • Determine whether formal project milestones have
    been accomplished
  • Compare actual start date to planned start date
    for each project task
  • Meet informally with practitioners to obtain
    their subjective assessment of progress to date
    and problems on the horizon
  • Assess progress quantitatively (e.g., earned
    value analysis)

48
Overview
  • Fundamentals of project planning and estimating
  • Metrics for software productivity assessment
  • Different techniques that can be used for
    estimation
  • Algorithmic cost estimation method -COCOMO
  • Project scheduling and tracking
  • Framework for Software Project Management Plan
    (SPMP)

49
Framework for SPMP -IEEE Standard 1058.1
  • 1. Introduction
  • 1.1. Project overview
  • 1.2. Project deliverables
  • 1.3. Evolution of the SPMP
  • 1.4. Reference materials
  • 1.5. Definitions and acronyms
  • 2. Project organization
  • 2.1. Process model
  • 2.2. Organizational structure
  • 2.3. Organizational boundaries
  • and Interfaces
  • 2.4. Project responsibilities
  • 3. Managerial process
  • 3.1.Management objectives and priorities
  • 3.2. Assumptions, dependencies,
  • and constraints
  • 3.3. Risk management
  • 3.4. Monitoring and controlling mechanisms
  • 3.5. Staffing plan
  • 4. Technical process
  • 4.1. Methods, tools, and techniques
  • 4.2. Software documentation
  • 4.3. Project support function
  • 5. Work packages, schedule, and budget
  • 5.1. Work packages
  • 5.2. Dependencies
  • 5.3. Resources requirements
  • 5.4. Budget and resource allocation
  • 5.5. Schedule
  • Additional components

50
CASE tools for the planning
  • Word processor, spreadsheet
  • Automated intermediate COCOMO/COCOMO II
  • Management tools assist with planning and
    monitoring
  • Mac Project
  • Microsoft Project
About PowerShow.com