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