Title: The Work Breakdown Structure and Project Estimation
1The Work Breakdown Structure and Project
Estimation
2The 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)
3The 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.
4Work Package
5Deliverables 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
6Developing the WBS
- Develop work packages for each of the phases and
deliverables defined in the Deliverable Structure
Chart (DSC)
7Work Breakdown Schedule
8Approaches 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
9Sample Mind-Mapping Approach
10Developing 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
11Developing 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.
12Project 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
13Project 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
14Project 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.
15Project 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
16Software 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.
17Determinates of application estimate
18The 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)
19The 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.
20The Mythical Man-Month Frederick Brooks
- Brooks Law Adding manpower to a late software
project makes it later.
21Software Estimation
- Direct measurement
- LOC
- Indirect measurement
- Heuristics
- Function point
- Feature point
- 3D Function point
22Lines 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
23Lines of Code (LOC)
24Software 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
25Function 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)
26The Application Boundary for Function Point
Analysis
27Function 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
28Function 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.
29Function Points- Steps
- Classify and count the five user function types
- 3 level of complexity
- Adjust for processing complexity
- Make the function point calculation
30Function Points
31Function 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.
32Function 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.
33Function 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
34Function 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.
35Function 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.
36Function 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.
37Function 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.
38Function 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.
39Function 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.
40IFPUG File Type Complexity
41IFPUG External Input Complexity
42IFPUG External Output Complexity
43Processing 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
4414 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
45GSC and Total Adjusted Function Point
46Function Point - Calculation
- Adjustment factor 0.65 0.01 X
- Function Point count-total X adjustment factor
47Example
48Feature 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.
49Example Feature Points Approach
503D 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.
513D 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.
523D 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
53Internal Data Structure and Interface
54Level of Complexity Table for Input
55Level of Complexity Table for Output
56Level of Complexity Table for Transformations
57Weights to Calculate 3 D Function Point
58Backfiring
- Technique for converting function point count to
LOC
59COCOMO 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
60COCOMO 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)
61COCOMO 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
62COCOMO 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
63COCOMO MOdel
- Duration Formulas
- Organic TDEV2.5(MM)0.38
- Semidetached TDEV2.5(MM)0.35
- Embeded TDEV2.5(MM)0.32
64COCOMO 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
65Cost Driver Attributes
- Personnel attributes
- Analyst capability
- Virtual machine experience
- Programmer capability
- Programming language experience
- Application experience
- Product attributes
- Reliability requirement
- Database size
- Product complexity
66Cost 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)
72COCOMO 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.
73COCOMO 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.
74The 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.
75The 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
76The 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
77The 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
78Rating Scheme for The COCOMO 2 Scale Factors
79Exponent 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
80Exponent 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
81Exponent 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
82The 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
83The 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
84ESLOC
- 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.
85The 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
86The 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
87Development 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
88Software Engineering Metrics and Approaches
- Automated Estimating Tools
- COCOMO II
- SLIM
- CHECKPOINT
89Typical 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
90What 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