The Work Breakdown Structure and Project Estimation - PowerPoint PPT Presentation

1 / 90
About This Presentation
Title:

The Work Breakdown Structure and Project Estimation

Description:

The WBS represents a logical decomposition of the work to ... Efficient code vs. code bloat. Language differences. Easier to count afterwards than to estimate ... – PowerPoint PPT presentation

Number of Views:1404
Avg rating:3.0/5.0
Slides: 91
Provided by: richeri
Category:

less

Transcript and Presenter's Notes

Title: The Work Breakdown Structure and Project Estimation


1
The Work Breakdown Structure and Project
Estimation
2
The Work Breakdown Structure (WBS)
  • The WBS represents a logical decomposition of the
    work to be performed and focuses on how the
    product, service, or result is naturally
    subdivided. It is an outline of what work is to
    be performed.
  • Gregory T. Haugan (2002)

3
The Work Breakdown Structure (WBS)
  • The WBS provides a framework for developing a
    tactical plan to structure the project work.
  • Work packages are major work items, or collection
    s of related tasks, required to produce a
    component.

4
Work Package
5
Deliverables and Milestones
  • Deliverables
  • Tangible, verifiable work products
  • Reports, presentations, prototypes, etc.
  • Milestones
  • Significant events or achievements
  • Acceptance of deliverables or phase completion
  • Cruxes (proof of concepts)
  • Quality control
  • Keeps team focused

6
Developing the WBS
  • Develop work packages for each of the phases and
    deliverables defined in the Deliverable Structure
    Chart (DSC)

7
Work Breakdown Schedule
8
Approaches to Developing WBSs
  • Using guidelines Some organizations, like the
    DoD, provide guidelines for preparing WBSs
  • The analogy approach Review WBSs of similar
    projects and tailor to your project
  • The top-down approach Start with the largest
    items of the project and break them down
  • The bottom-up approach Start with the detailed
    tasks and roll them up
  • Mind-mapping approach Write down tasks in a
    non-linear format and then create the WBS
    structure

9
Sample Mind-Mapping Approach
10
Developing the WBS- Keep in Mind
  • The WBS Should Be Deliverable-Oriented
  • Should produce something, not merely on
    completing a specified number of activities.
  • The WBS Should Support the Project's MOV
  • Ensure WBS allows for the delivery of all the
    projects deliverables as defined in project
    scope
  • The Level of Detail Should Support Planning and
    Control
  • Should support not only the development of the
    project plan but also allow the project manager
    and project team to monitor and compare the
    projects actual progress to the original plans
    schedule and budget

11
Developing the WBS- Keep in Mind
  • Developing the WBS Should Involve the People Who
    Will Be Doing the Work
  • Learning Cycles and Lessons Learned Can Support
    the Development of a WBS
  • Lessons learned from previous projects can be
    helpful in ensuring that the WBS and subsequent
    project plan are realistic and complete.

12
Project Estimation
  • The seeds of major software disasters are usually
    sown in the first three months of commencing the
    software project. Hasty scheduling,irrational
    commitments, unprofessional estimating
    techniques,and carelessness of the project
    management function are the factors that tend to
    introduce terminal problems. Once a project
    blindly lurches forward toward an impossible
    delivery date, the rest of the disaster will
    occur almost inevitably.
  • T. Capers Jones

13
Project Estimation
  • Guesstimating
  • Delphi Technique
  • Involves multiple, anonymous experts
  • Each expert makes an estimate
  • Estimates compared
  • If close, can be averaged
  • Else do another iteration until consensus is
    reached

14
Project Estimation
  • Top-Down Estimating
  • Estimate for the whole project and then break
    down
  • Often estimate in terms of what a project should
    cost and how long it should take as decreed by a
    member of top management who thinks those
    parameters are appropriate.
  • May be a response to the business environment
  • May lead to a death march project.

15
Project Estimation
  • Bottom-Up Estimating
  • Most common form of project estimation
  • Divide project into small modules and directly
    estimate time and effort in person-hours, weeks,
    or months for each module.
  • Analogous estimating based on similarity between
    current projects and others.
  • Estimates a function of activity and the
    duration is dependent on
  • complexity of module
  • structure of module
  • resources and support assigned to module

16
Software Engineering Metrics and Approaches
  • software engineering
  • focuses on the processes, tools, and methods for
    developing a quality approach to developing
    software
  • metrics
  • provide the basis for software engineering and
    refers to a broad range of measurements for
    objectively evaluating computer software.

17
Determinates of application estimate
18
The Mythical Man-Month Frederick Brooks
  • First, our techniques of estimation are poorly
    developed.More seriously, they reflect an
    unvoiced assumption which is quite untrue i.e.,
    that all will go well.
  • Second, our estimating techniques fallaciously
    confuse effort with progress, hiding the
    assumption that men and months are
    interchangeable.
  • Third, because we are uncertain of our
    estimates,software managers often lack the
    courteous stubbornness of Antoines chef) Good
    cooking takes time. If you are made to wait, it
    is to serve you better,and to please you. (From
    the menu of Antoines,a restaurant in New Orleans)

19
The Mythical Man-Month Frederick Brooks
  • Fourth, schedule progress is poorly
    monitored.Techniques proven and routine in other
    engineering disciplines are considered radical
    innovations in software engineering.
  • Fifth, when schedule slippage is recognized, the
    natural tendency (and traditional) response it to
    add more manpower. Like dousing a fire with
    gasoline,this makes matters worse, much worse.
    More fire requires more gasoline, and thus begins
    a regenerative cycle which ends in disaster.

20
The Mythical Man-Month Frederick Brooks
  • Brooks Law Adding manpower to a late software
    project makes it later.

21
Software Estimation
  • Direct measurement
  • LOC
  • Indirect measurement
  • Heuristics
  • Function point
  • Feature point
  • 3D Function point

22
Lines of Code (LOC)
  • Lines of Code (LOC)
  • Most traditionally used metric for project sizing
  • Most controversial
  • Count comments?
  • Declaring variables?
  • Efficient code vs. code bloat
  • Language differences
  • Easier to count afterwards than to estimate

23
Lines of Code (LOC)
24
Software Estimation
  • Heuristics
  • Rules of thumb approach to estimating
  • Require a predictable percentage of the overall
    effort
  • 30 planning
  • 20 coding
  • 25 component testing
  • 25 system testing
  • Estimating Software Costs -Capers

25
Function Points
  • Function Points
  • analysis based on evaluation of data and
    transactional types
  • Internal Logical File (ILF)
  • External Interface File (EIF)
  • External Input (EI)
  • External Output (EO)
  • External Inquiry (EQ)

26
The Application Boundary for Function Point
Analysis
27
Function Points
  • Application Boundaries
  • The application is planned to be developed in
    multiple stages, using more than one development
    project should be counted, estimated, and
    measured as separate projects, including all
    inputs, outputs, interfaces and inquiries
    crossing all boundaries.
  • The application is planned to be developed as a
    single application using one development project,
    but it is so large divide it into
    subapplications

28
Function Points
  • Application Boundaries (cont)
  • The subapplications should be counted separated,
    but none of the inputs, outputs, interfaces, and
    inquiries crossing the arbitrary internal
    boundaries should be counted.
  • The function points of the subapplications should
    be summed to give the total function points of
    the application.

29
Function Points- Steps
  • Classify and count the five user function types
  • 3 level of complexity
  • Adjust for processing complexity
  • Make the function point calculation

30
Function Points
31
Function Points
  • External Input Types are screen or forms through
    which human users of an application or other
    programs add new data or update existing data.
  • Count each unique user data or user control input
    type that enters the external boundary of the
    application being measured, and adds or changes
    data in a logical internal file type.
  • An external input type should be considered
    unique if it has a different format, or requires
    a processing logic different from other external
    input types of the same format.

32
Function Points
  • External Input Type
  • Simple few data element types included in the
    external input type, and few logical internal
    file types are referenced by the external input
    type. User human factors considerations are not
    significant in the design of the external input
    type.
  • Average is not clearly either simple or complex
  • Complex many data element types are included in
    the external input type, and many logical
    internal file types are referenced by the
    external input type. User human factors
    considerations significantly affect the design of
    the external input type.

33
Function Points
  • External Output Types are screens or reports, or
    messages which the application produces for
    humans use or for other programs.
  • Count each unique user data or control output
    type that leaves the external boundary of the
    application being measured.
  • An external output type should be considered
    unique if it has a different format, or requires
    a processing logic different from other external
    output types of the same format

34
Function Points
  • External Output Type
  • Simple one or more columns, simple data element
    transformation
  • Average multiple columns with subtotals,
    multiple data element transformation
  • Complexity intricate data element
    transformations, multiple and complex file
    references to be correlated, significant
    performance considerations.

35
Function Points
  • Logical Internal File Types are logical
    collections of records which the application
    modifies or updates.
  • Count each major logical group of user data or
    control information in the application, include
    logical file, or within a data base, each logical
    group of data from the viewpoint of the user,
    that is generated, used, and maintained by the
    application.

36
Function Points
  • Logical Internal File Types
  • Simple few record types, few data element types,
    no significant performance or recovery
    considerations.
  • Average is not clearly either simple or complex
  • Complex many record types, many data element
    types, performance and recovery are significant
    considerations.

37
Function Points
  • External Interface File Types are files passed or
    shared with other applications.
  • Count each major logical group of user data or
    control information that enters or leaves the
    application.
  • Complexity classification use definition similar
    to those for logical internal file types.

38
Function Points
  • External Inquiries Types are screens which allow
    users to interrogate the application and ask for
    assistance or information.
  • Count each unique input/output combination, where
    an input causes and generates an immediate
    output.
  • An external inquiry type should be considered
    unique if it has a format different from other
    external inquiry types in either its input or
    output parts, or requires a processing logic
    different from other external inquiry type of the
    same format.

39
Function Points
  • External Inquiry Types
  • classify the input part using definitions similar
    to the external input type
  • classify the output part using definition similar
    to the external output type.
  • The complexity of the external inquiry type is
    the greater of the two classifications.

40
IFPUG File Type Complexity
41
IFPUG External Input Complexity
42
IFPUG External Output Complexity
43
Processing Complexity
  • Estimate the degree of influence of each of the
    14 general characteristics
  • Sum the 14 degree of influences and develop an
    adjustment factor
  • Multiply the adjustment factor to the
    work-product measure

44
14 General Characteristics
  • End User Efficiency
  • Online Update
  • Complex Processing
  • Reusability
  • Installation Ease
  • Operational Ease
  • Multiple Sites
  • Facilitate Change
  • Data Communications
  • Distributed Data Processing
  • Performance
  • Heavily Used Configuration
  • Transaction Rate
  • Online Data Entry

45
GSC and Total Adjusted Function Point
46
Function Point - Calculation
  • Adjustment factor 0.65 0.01 X
  • Function Point count-total X adjustment factor

47
Example
48
Feature Points
  • Feature Points were originally invented to solve
    the measurement problems of classical MIS.
  • Feature Point measure accommodates applications
    in which algorithmic complexity is high such as
    real time software, systems software, embedded
    software.
  • Algorithm is defined as the set of rules which
    must be completely expressed to solve a
    significant computational problem.

49
Example Feature Points Approach
50
3D Function Point
  • Data dimension is evaluated in the same way as
    Function Point (inputs, outputs, inquiries,
    logical files, interface files)
  • Functional dimension is measured by considering
    the number of internal operations required to
    transform input to output data.
  • Input and output data may be either internal to
    the application, external application , or both.
  • Level of complexity of each transformation is a
    function of the number of processing steps and
    the number of semantic statements that control
    the processing steps.

51
3D Function Point
  • Functional dimension
  • transformation is viewed as a series of
    processing steps and semantic statements that
    cooperate to transform one set of input data into
    a set of output data.
  • semantic statements the predicated and the pre-
    and post-conditions for each step of the process.
  • Input and output do not necessarily refer to the
    input and output transactions that are part of
    the data dimension.
  • Processing that changes only the structure,
    format, or order of the data is not a
    transformation.

52
3D Function Point
  • Control dimension is measured by summing the
    counts of both states and transitions.
  • A state is a set that contains one and only one-
    value for each condition of interest in the
    application. Any time the value of any data
    element in the internal data structure changes,
    the state of the application also changes.
  • A transition is a valid path from one state to
    another, or to the same state

53
Internal Data Structure and Interface
54
Level of Complexity Table for Input
55
Level of Complexity Table for Output
56
Level of Complexity Table for Transformations
57
Weights to Calculate 3 D Function Point
58
Backfiring
  • Technique for converting function point count to
    LOC

59
COCOMO COnstructive COst MOdel
  • Developed at TRW, a US defense contractor
  • Based on a cost database of more than 60
    different projects
  • Exists in three stages
  • Basic - Gives a 'ball-park' estimate based on
    product attributes
  • Intermediate - modifies basic estimate using
    project and process attributes
  • Advanced - Estimates project phases and parts
    separately

60
COCOMO MOdel
  • Project Types
  • Organic mode small teams, familiar environment,
    well-understood applications, no difficult
    non-functional requirements (EASY)
  • Semi-detached mode Project team may have
    experience mixture, system may have more
    significant non-functional constraints,
    organization may have less familiarity with
    application (HARDER)
  • Embedded Hardware/software systems, tight
    constraints, unusual for team to have deep
    application experience (HARD)

61
COCOMO MOdel
  • Basic Formulas
  • Organic Person-Months 2.4 x (KDSI)1.05
  • Semi-detached Person-Months 3.0 x KDSI1.12
  • Embedded Person Months 3. 6 x KDSI1.20
  • KDSI thousands of delivered source
    instructions, i.e. LOC

62
COCOMO Examples
  • Organic mode project, 32KLOC
  • PM 2.4 (32) 1.05 91 person months
  • TDEV 2.5 (91) 0.38 14 months
  • N 91/15 6.5 people
  • Embedded mode project, 128KLOC
  • PM 3.6 (128)1.2 1216 person-months
  • TDEV 2.5 (1216)0.32 24 months
  • N 1216/24 51

63
COCOMO MOdel
  • Duration Formulas
  • Organic TDEV2.5(MM)0.38
  • Semidetached TDEV2.5(MM)0.35
  • Embeded TDEV2.5(MM)0.32

64
COCOMO MOdel
  • Intermediate Formulas
  • Organic
  • PM 3.2 x (KDSI)1.05 EAF
  • Semi-detached
  • PM 3.0 x KDSI1.12 EAF
  • Embedded
  • PM 2.8 x KDSI1.20 EAF
  • EAF Effort Adjustment Factor

65
Cost Driver Attributes
  • Personnel attributes
  • Analyst capability
  • Virtual machine experience
  • Programmer capability
  • Programming language experience
  • Application experience
  • Product attributes
  • Reliability requirement
  • Database size
  • Product complexity

66
Cost Driver Attributes
  • Computer attributes
  • Execution time constraints
  • Storage constraints
  • Virtual machine volatility
  • Computer turnaround time
  • Project attributes
  • Modern programming practices
  • Software tools
  • Required development schedule

67
(No Transcript)
68
(No Transcript)
69
(No Transcript)
70
(No Transcript)
71
(No Transcript)
72
COCOMO II
  • COCOMO II recognizes different approaches to
    software development such as prototyping,
    development by component composition, use of
    4GLs, etc.
  • Levels are associated with activities in the
    software process so that initial estimates may be
    made early in the process with more detailed
    estimating carried out after the system
    architecture has been defined.

73
COCOMO II
  • Models
  • The Early Prototyping Level
  • Size estimates are based on object points
  • The Early Design Level
  • Estimates are based on function points
  • The Post-architecture Level
  • Estimates use more extensive set of multipliers.

74
The Early Prototyping Level
  • Size estimates are based on object points and a
    simple size/productivity formula is used to
    estimate the effort required.
  • This level supports software developed by
    composing existing components.

75
The Early Prototyping Level
  • Formula
  • PM (NOP x (1 - reuse/100))/PROD
  • PM person-months
  • NOP New Object Point
  • reuse the percentage of reuse that is expected
  • PROD productivity

76
The Early Design Level
  • Size estimates are based on FP and multipliers
  • This estimate refers to the code that is
    implemented manually rather than generated or
    reused.
  • Formula
  • Effort A x SizeB x M
  • A 2.5
  • B 1.01 0.01 Wi
  • M PERS x RCPX x RUSE x PDIF x PREX x FCIL x
    SCED

M
77
The Early Design Level
  • Automatically Translated Code
  • Formula
  • Effort A x SizeB x M Pmauto
  • Pmauto (ASLOC x (AT/100))/ATPROD
  • ASLOC Amount of software to be adapted
  • AT of the code that is reengineered by
    automatic translation
  • ATPROD 24000

78
Rating Scheme for The COCOMO 2 Scale Factors

79
Exponent Computation
  • Precedentedness
  • similar to several previous developed projects
  • Development Flexibility
  • need for software conformance with
    pre-established requirements,
  • need for software conformance with external
    interface specification

80
Exponent Computation
  • Architecture/Risk Resolution
  • Risk management plan identifies all critical risk
    item
  • Schedule budget compatible with risk management
    plan
  • of development schedule devoted to establishing
    architecture
  • of required top software architects available
    to project
  • Tool support
  • Number of risk items

81
Exponent Computation
  • Team Cohesion
  • Consistency of stakeholder objectives
  • Ability, willingness of stakeholders to
    accommodate other stakeholders objectives
  • Experience of stakeholders in operating as a team
  • Stakeholder team building to achieve shared
    vision and commitments
  • Process Maturity
  • 5 levels of CMM

82
The Early Design Level -7 Multipliers
  • PERS Personal Capability
  • RCPX Reliability and Complexity
  • RUSE Reuse Required
  • PDIF Platform Difficulty
  • PREX Personal Experience
  • FCIL Support Facilities
  • SCED Schedule

83
The Post-architecture Level
  • The estimates are based on the same basic formula
    that is used in the early design estimates.
  • This stage uses a more extensive set of
    multipliers.
  • Formula
  • Effort A x SizeB x ESLOC x M Pmauto
  • ESLOC ASLOC x (AASU0.4DM0.3CM0.3IM)/100
  • ESLOC Equivalent number of new instructions

84
ESLOC
  • ASLOC Amount of software to be adapted
  • AA The assessment and assimilation increment
  • Determine whether a reused software module is
    appropriate to the application, and to integrate
    its description into the overall product
    description
  • SU The software understanding increment
  • Software is structured and clear, self
    descriptiveness
  • DM The percentage of design modification
  • CM The percentage of code modification
  • IM The percentage of the original integration
    effort required for integrating the reused
    software.

85
The Post-architecture Level- 17 Multipliers
  • RELY Required Software Reliability
  • DATA Data Base Size
  • CPLX Product Complexity
  • RUSE Required Reusable
  • DOCU Documentation match to life-cycle needs
  • TIME Execution Time Constraint
  • STOR Main Storage Constraint
  • PVOL Platform Volatility
  • ACAP Analyst Capability

86
The Post-architecture Level- 17 Multipliers
  • PCAP Programmer Capability
  • AEXP Applications Experience
  • PEXP Platform Experience
  • LTEX Language and Tool Experience
  • PCON Personnel Continuity
  • TOOL Use of Software Tools
  • SITE Multisite Development
  • SCED Required Development Schedule

87
Development Schedule Estimates
  • Initial baseline schedule equation for all 3
    COCOMO II
  • TDEV3.0x(PM)(0.330.2x(B-1.01)xSCED/100
  • SCED cost driver rating

88
Software Engineering Metrics and Approaches
  • Automated Estimating Tools
  • COCOMO II
  • SLIM
  • CHECKPOINT

89
Typical Problems with IT Cost Estimates
  • Developing an estimate for a large software
    project is a complex task requiring a significant
    amount of effort. Remember that estimates are
    done at various stages of the project
  • Many people doing estimates have little
    experience doing them. Try to provide training
    and mentoring
  • People have a bias toward underestimation.
    Review estimates and ask important questions to
    make sure estimates are not biased
  • Management wants a number for a bid, not a real
    estimate. Project managers must negotiate with
    project sponsors to create realistic cost
    estimates

90
What Is the Best Way to Estimate IT Projects?
  • Use more than one technique for estimating
  • If estimates from different techniques close,
    average them
  • Adjust estimate based on experience
  • Negotiation may lead to unrealistic estimations
Write a Comment
User Comments (0)
About PowerShow.com