UNIT:V Project Management Concepts

- The Management Spectrum - The People - The Product - The Process - The Project

The Management Spectrum

Effective software project management focuses on these items (in this order)
The people
Deals with the cultivation of motivated, highly skilled people Consists of the stakeholders, the team leaders, and the software team

The product
Product objectives and scope should be established before a project can be planned

The process
The software process provides the framework from which a comprehensive plan for software development can be established

The project
Planning and controlling a software project is done for one primary reasonit is the only known way to manage complexity In a 1998 survey, 26% of software projects failed outright, 46% experienced cost and schedule overruns

People Product Process Project

3

The People: The Stakeholders

Five categories of stakeholders
Senior managers define business issues that often have significant influence on the project Project (technical) managers plan, motivate, organize, and control the practitioners who do the work Practitioners deliver the technical skills that are necessary to engineer a product or application Customers specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome End users interact with the software once it is released for production use

The People: Team Leaders

Competent practitioners often fail to make good team leaders; they just dont have the right people skills Qualities to look for in a team leader
Motivation the ability to encourage technical people to produce to their best ability Organization the ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product Ideas or innovation the ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application

Team leaders should use a problem-solving management style

Concentrate on understanding the problem to be solved Manage the flow of ideas Let everyone on the team know, by words and actions, that quality counts and that it will not be compromised

(More on next slide)

The People: Team Leaders (continued)

Another set of useful leadership traits
Problem solving diagnose, structure a solution, apply lessons learned, remain flexible Managerial identity take charge of the project, have confidence to assume control, have assurance to allow good people to do their jobs Achievement reward initiative, demonstrate that controlled risk taking will not be punished Influence and team building be able to read people, understand verbal and nonverbal signals, be able to react to signals, remain under control in high-stress situations

The People: The Software Team

Seven project factors to consider when structuring a software development team
The difficulty of the problem to be solved The size of the resultant program(s) in source lines of code The time that the team will stay together The degree to which the problem can be modularized The required quality and reliability of the system to be built The rigidity of the delivery date The degree of sociability (communication) required for the project

(More on next slide)

The People: The Software Team (continued)

Four organizational paradigms for software development teams
Closed paradigm traditional hierarchy of authority; works well when producing software similar to past efforts; members are less likely to be innovative Random paradigm depends on individual initiative of team members; works well for projects requiring innovation or technological breakthrough; members may struggle when orderly performance is required Open paradigm hybrid of the closed and random paradigm; works well for solving complex problems; requires collaboration, communication, and consensus among members Synchronous paradigm organizes team members based on the natural pieces of the problem; members have little communication outside of their subgroups (More on next slide)

The People: The Software Team (continued)

Five factors that cause team toxic (i.e., a toxic team environment)
A frenzied work atmosphere High frustration that causes friction among team members A fragmented or poorly coordinated software process An unclear definition of roles on the software team Continuous and repeated exposure to failure

How to avoid these problems

Give the team access to all information required to do the job Do not modify major goals and objectives, once they are defined, unless absolutely necessary Give the team as much responsibility for decision making as possible Let the team recommend its own process model Let the team establish its own mechanisms for accountability (i.e., reviews) Establish team-based techniques for feedback and problem solving
9

The People: Coordination and Communication Issues

Key characteristics of modern software make projects fail
scale, uncertainty, interoperability

To better ensure success

Establish effective methods for coordinating the people who do the work Establish methods of formal and information communication among team members

10

Group Dynamics
Based on studies published by B. Tuckman in 1965 Updated later in 1977 Describes a four-stage model
Forming Storming Norming Performing

11

Group Dynamics Model

Forming
Group members rely on safe, patterned behavior and look to the group leader for guidance and direction Impressions are gathered and similarities and differences are noted Serious topics and feelings are avoided To grow, members must relinquish the comfort of non-threatening topics and risk the possibility of conflict

12

Group Dynamics Model

Storming
As group members organize for the tasks, conflict inevitably results in their personal relations and cliques start to form Individuals have to bend and mold their feelings to fit the group Fear of exposure or fear of failure causes an increased desire for structural clarification and commitment Conflicts arise over leadership, structure, power, and authority Member behavior may have wide swings based on emerging issues of competition and hostilities Some members remain silent while others attempt to dominate

13

Group Dynamics Model (continued)

Norming
Members engage in active acknowledgement of all members contributions, community building, and solving of group issues Members are willing to change their preconceived ideas or opinions based on facts presented by the group Leadership is shared, active listening occurs, and cliques dissolve Members began to identify with one another, which leads to a level of trust in their personal relations and contributes to cohesion Members begin to experience a sense of group belonging

14

Group Dynamics Model (continued)

Performing
The capacity, range, and depth of personal relations in the group expand to true interdependence. Members can work independently, in subgroups, or altogether with equal ability and success. The group is most productive, members become self-assuring, and the need for group approval is past. Genuine problem solving can occur leading towards optimal solutions .

15

People Product Process Project

16

The Product
The scope of the software development must be established and bounded
Context How does the software to be built fit into a larger system, product, or business context, and what constraints are imposed as a result of the context? Information objectives What customer-visible data objects are produced as output from the software? What data objects are required for input? Function and performance What functions does the software perform to transform input data into output? Are there any special performance characteristics to be addressed?

Software project scope must be unambiguous and understandable at both the managerial and technical levels

(More on next slide)

17

The Product (continued)

Problem decomposition
Also referred to as partitioning or problem elaboration Sits at the core of software requirements analysis

Two major areas of problem decomposition

The functionality that must be delivered The process that will be used to deliver it

18

People Product Process Project

19

The Process
Getting Started
The project manager must decide which process model is most appropriate based on
The customers who have requested the product and the people who will do the work The characteristics of the product itself The project environment in which the software team works

Once a process model is selected, a preliminary project plan is established based on the process framework activities Process decomposition then begins The result is a complete plan reflecting the work tasks required to populate the framework activities

Project planning begins as a melding of the product and the process based on the various framework activities

20

People Product Process Project

21

The Project: A Common Sense Approach

Start on the right foot
Understand the problem; set realistic objectives and expectations; form a good team

Maintain momentum
Provide incentives to reduce turnover of people; emphasize quality in every task; have senior management stay out of the teams way

Track progress
Track the completion of work products; collect software process and project measures; assess progress against expected averages

Make smart decisions

Keep it simple; use COTS or existing software before writing new code; follow standard approaches; identify and avoid risks; always allocate more time than you think you need to do complex or risky tasks

Conduct a post mortem analysis

Track lessons learned for each project; compare planned and actual schedules; collect and analyze software project metrics; get feedback from teams members and customers; record findings in written form
22

The Project: Signs that it is in Jeopardy

Software people don't understand their customer's needs The product scope is poorly defined Changes are managed poorly The chosen technology changes Business needs change (or are poorly defined) Deadlines are unrealistic Users are resistant Sponsorship is lost (or was never properly obtained) The project team lacks people with appropriate skills Managers (and practitioners) avoid best practices and lessons learned

23

The Project: The

5 W HH

Principle

A series of questions that lead to a definition of key project characteristics and the resultant project plan
Why is the system being developed?
Assesses the validity of business reasons and justifications

What will be done?

Establishes the task set required for the project

When will it be done?

Establishes a project schedule

Who is responsible for a function?

Defines the role and responsibility of each team member

Where are they organizationally located?

Notes the organizational location of team members, customers, and other stakeholders

How will the job be done technically and managerially?

Establishes the management and technical strategy for the project

How much of each resource is needed?

Establishes estimates based on the answers to the previous questions
24

Summary
People Project Product

Process
25

Process and Project Metrics

- Introduction - Metrics in the Process Domain - Metrics in the Project Domain - Software Measurement - Integrating Metrics within the Software Process

What are Metrics?

Software process and project metrics are quantitative measures They are a management tool They offer insight into the effectiveness of the software process and the projects that are conducted using the process as a framework Basic quality and productivity data are collected These data are analyzed, compared against past averages, and assessed The goal is to determine whether quality and productivity improvements have occurred The data can also be used to pinpoint problem areas Remedies can then be developed and the software process can be improved

27

Uses of Measurement
Can be applied to the software process with the intent of improving it on a continuous basis Can be used throughout a software project to assist in estimation, quality control, productivity assessment, and project control Can be used to help assess the quality of software work products and to assist in tactical decision making as a project proceeds

28

Reasons to Measure
To characterize in order to
Gain an understanding of processes, products, resources, and environments Establish baselines for comparisons with future assessments

To evaluate in order to
Determine status with respect to plans

To predict in order to
Gain understanding of relationships among processes and products Build models of these relationships

To improve in order to
Identify roadblocks, root causes, inefficiencies, and other opportunities for improving product quality and process performance

29

Metrics in the Process Domain

Metrics in the Process Domain

Process metrics are collected across all projects and over long periods of time They are used for making strategic decisions The intent is to provide a set of process indicators that lead to longterm software process improvement The only way to know how/where to improve any process is to
Measure specific attributes of the process Develop a set of meaningful metrics based on these attributes Use the metrics to provide indicators that will lead to a strategy for improvement

(More on next slide)

31

Metrics in the Process Domain (continued)

We measure the effectiveness of a process by deriving a set of metrics based on outcomes of the process such as
Errors uncovered before release of the software Defects delivered to and reported by the end users Work products delivered Human effort expended Calendar time expended Conformance to the schedule Time and effort to complete each generic activity

32

Etiquette of Process Metrics

Use common sense and organizational sensitivity when interpreting metrics data Provide regular feedback to the individuals and teams who collect measures and metrics Dont use metrics to evaluate individuals Work with practitioners and teams to set clear goals and metrics that will be used to achieve them Never use metrics to threaten individuals or teams Metrics data that indicate a problem should not be considered negative
Such data are merely an indicator for process improvement

Dont obsess on a single metric to the exclusion of other important metrics

33

Metrics in the Project Domain

Metrics in the Project Domain

Project metrics enable a software project manager to
Assess the status of an ongoing project Track potential risks Uncover problem areas before their status becomes critical Adjust work flow or tasks Evaluate the project teams ability to control quality of software work products

Many of the same metrics are used in both the process and project domain Project metrics are used for making tactical decisions
They are used to adapt project workflow and technical activities

35

Use of Project Metrics

The first application of project metrics occurs during estimation
Metrics from past projects are used as a basis for estimating time and effort

As a project proceeds, the amount of time and effort expended are compared to original estimates As technical work commences, other project metrics become important
Production rates are measured (represented in terms of models created, review hours, function points, and delivered source lines of code) Error uncovered during each generic framework activity (i.e, communication, planning, modeling, construction, deployment) are measured

(More on next slide)

36

Use of Project Metrics (continued)

Project metrics are used to
Minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks Assess product quality on an ongoing basis and, when necessary, to modify the technical approach to improve quality

In summary
As quality improves, defects are minimized As defects go down, the amount of rework required during the project is also reduced As rework goes down, the overall project cost is reduced

37

Software Measurement

Categories of Software Measurement

Two categories of software measurement
Direct measures of the
Software process (cost, effort, etc.) Software product (lines of code produced, execution speed, defects reported over time, etc.)

Indirect measures of the

Software product (functionality, quality, complexity, efficiency, reliability, maintainability, etc.)

Project metrics can be consolidated to create process metrics for an organization

39

Size-oriented Metrics
Derived by normalizing quality and/or productivity measures by considering the size of the software produced Thousand lines of code (KLOC) are often chosen as the normalization value Metrics include
Errors per KLOC - Errors per person-month Defects per KLOC - KLOC per person-month Dollars per KLOC - Dollars per page of documentation Pages of documentation per KLOC

(More on next slide)

40

Size-oriented Metrics (continued)

Size-oriented metrics are not universally accepted as the best way to measure the software process Opponents argue that KLOC measurements
Are dependent on the programming language Penalize well-designed but short programs Cannot easily accommodate nonprocedural languages Require a level of detail that may be difficult to achieve

41

Function-oriented Metrics
Function-oriented metrics use a measure of the functionality delivered by the application as a normalization value Most widely used metric of this type is the function point: FP = count total * [0.65 + 0.01 * sum (value adj. factors)] Material in Chapter 15 covered this in more detail Function point values on past projects can be used to compute, for example, the average number of lines of code per function point (e.g., 60)

42

Function Point Controversy

Like the KLOC measure, function point use also has proponents and opponents Proponents claim that
FP is programming language independent FP is based on data that are more likely to be known in the early stages of a project, making it more attractive as an estimation approach

Opponents claim that

FP requires some sleight of hand because the computation is based on subjective data Counts of the information domain can be difficult to collect after the fact FP has no direct physical meaningits just a number

43

Reconciling LOC and FP Metrics

Relationship between LOC and FP depends upon
The programming language that is used to implement the software The quality of the design

FP and LOC have been found to be relatively accurate predictors of software development effort and cost
However, a historical baseline of information must first be established

LOC and FP can be used to estimate object-oriented software projects

However, they do not provide enough granularity for the schedule and effort adjustments required in the iterations of an evolutionary or incremental process

The table on the next slide provides a rough estimate of the average LOC to one FP in various programming languages

44

LOC Per Function Point

Language Average Median Low High

Ada
Assembler C C++ COBOL Java PL/1 Visual Basic

154
337 162 66 77 55 78 47

-315 109 53 77 53 67 42

104
91 33 29 14 9 22 16

205
694 704 178 400 214 263 158

45

Object-oriented Metrics
Number of scenario scripts (i.e., use cases)
This number is directly related to the size of an application and to the number of test cases required to test the system

Number of key classes (the highly independent components)

Key classes are defined early in object-oriented analysis and are central to the problem domain This number indicates the amount of effort required to develop the software It also indicates the potential amount of reuse to be applied during development

Number of support classes

Support classes are required to implement the system but are not immediately related to the problem domain (e.g., user interface, database, computation) This number indicates the amount of effort and potential reuse

(More on next slide)

46

Object-oriented Metrics (continued)

Average number of support classes per key class
Key classes are identified early in a project (e.g., at requirements analysis) Estimation of the number of support classes can be made from the number of key classes GUI applications have between two and three times more support classes as key classes Non-GUI applications have between one and two times more support classes as key classes

Number of subsystems
A subsystem is an aggregation of classes that support a function that is visible to the end user of a system

47

Metrics for Software Quality

Correctness
This is the number of defects per KLOC, where a defect is a verified lack of conformance to requirements Defects are those problems reported by a program user after the program is released for general use

Maintainability
This describes the ease with which a program can be corrected if an error is found, adapted if the environment changes, or enhanced if the customer has changed requirements Mean time to change (MTTC) : the time to analyze, design, implement, test, and distribute a change to all users
Maintainable programs on average have a lower MTTC

48

Defect Removal Efficiency

Defect removal efficiency provides benefits at both the project and process level It is a measure of the filtering ability of QA activities as they are applied throughout all process framework activities
It indicates the percentage of software errors found before software release

It is defined as DRE = E / (E + D)
E is the number of errors found before delivery of the software to the end user D is the number of defects found after delivery

As D increases, DRE decreases (i.e., becomes a smaller and smaller fraction) The ideal value of DRE is 1, which means no defects are found after delivery DRE encourages a software team to institute techniques for finding as many errors as possible before delivery
49

Integrating Metrics within the Software Process

Arguments for Software Metrics

Most software developers do not measure, and most have little desire to begin Establishing a successful company-wide software metrics program can be a multi-year effort But if we do not measure, there is no real way of determining whether we are improving Measurement is used to establish a process baseline from which improvements can be assessed Software metrics help people to develop better project estimates, produce higher-quality systems, and get products out the door on time

51

Establishing a Metrics Baseline

By establishing a metrics baseline, benefits can be obtained at the software process, product, and project levels The same metrics can serve many masters The baseline consists of data collected from past projects Baseline data must have the following attributes
Data must be reasonably accurate (guesses should be avoided) Data should be collected for as many projects as possible Measures must be consistent (e.g., a line of code must be interpreted consistently across all projects) Past applications should be similar to the work that is to be estimated

After data is collected and metrics are computed, the metrics should be evaluated and applied during estimation, technical work, project control, and process improvement

52

Software Metrics Baseline Process

Software Engineering Process Measures Software Project Data Collection

Metrics
Software Product Metrics Computation Indicators Metrics Evaluation

53

Getting Started with Metrics

1) Understand your existing process 2) Define the goals to be achieved by establishing a metrics program 3) Identify metrics to achieve those goals
Keep the metrics simple Be sure the metrics add value to your process and product

4) Identify the measures to be collected to support those metrics

(More on next slide)

54

Getting Started with Metrics (continued)

5) Establish a measurement collection process
a) b) c) d) e) f) What is the source of the data? Can tools be used to collect the data? Who is responsible for collecting the data? When are the data collected and recorded? How are the data stored? What validation mechanisms are used to ensure the data are correct?

6) 7) 8)

Acquire appropriate tools to assist in collection and assessment Establish a metrics database Define appropriate feedback mechanisms on what the metrics indicate about your process so that the process and the metrics program can be improved

55

Estimation for Software Projects

- Project planning - Scope and feasibility - Project resources - Estimation of project cost and effort - Decomposition techniques - Empirical estimation models

Project Planning

Software Project Planning

Software project planning encompasses five major activities
Estimation, scheduling, risk analysis, quality management planning, and change management planning

Estimation determines how much money, effort, resources, and time it will take to build a specific system or product The software team first estimates
The work to be done The resources required The time that will elapse from start to finish

Then they establish a project schedule that

Defines tasks and milestones Identifies who is responsible for conducting each task Specifies the inter-task dependencies

58

Observations on Estimation
Planning requires technical managers and the software team to make an initial commitment Process and project metrics can provide a historical perspective and valuable input for generation of quantitative estimates Past experience can aid greatly Estimation carries inherent risk, and this risk leads to uncertainty The availability of historical information has a strong influence on estimation risk

(More on next slide)

59

Observations on Estimation (continued)

When software metrics are available from past projects
Estimates can be made with greater assurance Schedules can be established to avoid past difficulties Overall risk is reduced

Estimation risk is measured by the degree of uncertainty in the quantitative estimates for cost, schedule, and resources Nevertheless, a project manager should not become obsessive about estimation
Plans should be iterative and allow adjustments as time passes and more is made certain

"It is the mark of an instructed mind to rest satisfied with the degree of precision that the nature of the subject admits, and not to seek exactness when only an approximation of the truth is possible." ARISTOTLE

60

Task Set for Project Planning

1) 2) 3) 4) Establish project scope Determine feasibility Analyze risks Define required resources
a) b) c) Determine human resources required Define reusable software resources Identify environmental resources Decompose the problem Develop two or more estimates using different approaches Reconcile the estimates Establish a meaningful task set Define a task network Use scheduling tools to develop a timeline chart Define schedule tracking mechanisms

5)

Estimate cost and effort

a) b) c)

6)

Develop a project schedule

a) b) c) d)

61

Example Project: Campus Information Access Kiosk

Both podium-high and desk-high terminals located throughout the campus in all classroom buildings, admin buildings, labs, and dormitories Hand/Palm-login and logout (seamlessly) Voice input Optional audio/visual or just visual output Immediate access to all campus information plus
E-mail Cell phone voice messaging Text messaging

62

Scope and Feasibility

Software Scope
Software scope describes
The functions and features that are to be delivered to end users The data that are input to and output from the system The "content" that is presented to users as a consequence of using the software The performance, constraints, interfaces, and reliability that bound the system

Scope can be define using two techniques

A narrative description of software scope is developed after communication with all stakeholders A set of use cases is developed by end users

(More on next slide)

64

Software Scope (continued)

After the scope has been identified, two questions are asked
Can we build software to meet this scope? Is the project feasible?

Software engineers too often rush (or are pushed) past these questions Later they become mired in a project that is doomed from the onset

65

Feasibility
After the scope is resolved, feasibility is addressed Software feasibility has four dimensions
Technology Is the project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application's needs? Finance Is is financially feasible? Can development be completed at a cost that the software organization, its client, or the market can afford? Time Will the project's time-to-market beat the competition? Resources Does the software organization have the resources needed to succeed in doing the project?

Another view recommends the following feasibility dimensions: technological, economical, legal, operational, and schedule issues (TELOS)
66

Project Resources

Resource Estimation
Three major categories of software engineering resources
People Development environment Reusable software components
Often neglected during planning but become a paramount concern during the construction phase of the software process

Each resource is specified with

A description of the resource A statement of availability The time when the resource will be required The duration of time that the resource will be applied

Time window

68

Categories of Resources
People - Number required - Skills required - Geographical location Development Environment - Software tools - Computer hardware - Network resources

The Project

Reusable Software Components - Off-the-shelf components - Full-experience components - Partial-experience components - New components

69

Human Resources
Planners need to select the number and the kind of people skills needed to complete the project They need to specify the organizational position and job specialty for each person Small projects of a few person-months may only need one individual Large projects spanning many person-months or years require the location of the person to be specified also The number of people required can be determined only after an estimate of the development effort

70

Development Environment Resources

A software engineering environment (SEE) incorporates hardware, software, and network resources that provide platforms and tools to develop and test software work products Most software organizations have many projects that require access to the SEE provided by the organization Planners must identify the time window required for hardware and software and verify that these resources will be available

71

Reusable Software Resources

Off-the-shelf components
Components are from a third party or were developed for a previous project Ready to use; fully validated and documented; virtually no risk

Full-experience components
Components are similar to the software that needs to be built Software team has full experience in the application area of these components Modification of components will incur relatively low risk

Partial-experience components
Components are related somehow to the software that needs to be built but will require substantial modification Software team has only limited experience in the application area of these components Modifications that are required have a fair degree of risk

New components
Components must be built from scratch by the software team specifically for the needs of the current project Software team has no practical experience in the application area 72 Software development of components has a high degree of risk

Estimation of Project Cost and Effort

Factors Affecting Project Estimation

The accuracy of a software project estimate is predicated on
The degree to which the planner has properly estimated the size (e.g., KLOC) of the product to be built The ability to translate the size estimate into human effort, calendar time, and money The degree to which the project plan reflects the abilities of the software team The stability of both the product requirements and the environment that supports the software engineering effort

74

Project Estimation Options

Options for achieving reliable cost and effort estimates
1) 2) 3) 4) Delay estimation until late in the project (we should be able to achieve 100% accurate estimates after the project is complete) Base estimates on similar projects that have already been completed Use relatively simple decomposition techniques to generate project cost and effort estimates Use one or more empirical estimation models for software cost and effort estimation

Option #1 is not practical, but results in good numbers Option #2 can work reasonably well, but it also relies on other project influences being roughly equivalent Options #3 and #4 can be done in tandem to cross check each other

75

Project Estimation Approaches

Decomposition techniques
These take a "divide and conquer" approach Cost and effort estimation are performed in a stepwise fashion by breaking down a project into major functions and related software engineering activities

Empirical estimation models

Offer a potentially valuable estimation approach if the historical data used to seed the estimate is good

76

Decomposition Techniques

Introduction
Before an estimate can be made and decomposition techniques applied, the planner must
Understand the scope of the software to be built Generate an estimate of the softwares size

Then one of two approaches are used

Problem-based estimation
Based on either source lines of code or function point estimates

Process-based estimation
Based on the effort required to accomplish each task

78

Approaches to Software Sizing

Function point sizing
Develop estimates of the information domain characteristics (Ch. 15 Product Metrics for Software)

Standard component sizing

Estimate the number of occurrences of each standard component Use historical project data to determine the delivered LOC size per standard component

Change sizing
Used when changes are being made to existing software Estimate the number and type of modifications that must be accomplished Types of modifications include reuse, adding code, changing code, and deleting code An effort ratio is then used to estimate each type of change and the size of the change

The results of these estimates are used to compute an optimistic (low), a most likely, and a pessimistic (high) value for software size
79

Problem-Based Estimation
1) 2) 3) 4) 5) Start with a bounded statement of scope Decompose the software into problem functions that can each be estimated individually Compute an LOC or FP value for each function Derive cost or effort estimates by applying the LOC or FP values to your baseline productivity metrics (e.g., LOC/person-month or FP/person-month) Combine function estimates to produce an overall estimate for the entire project

(More on next slide)

80

Problem-Based Estimation (continued)

In general, the LOC/pm and FP/pm metrics should be computed by project domain
Important factors are team size, application area, and complexity

LOC and FP estimation differ in the level of detail required for decomposition with each value
For LOC, decomposition of functions is essential and should go into considerable detail (the more detail, the more accurate the estimate) For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment factors
External inputs, external outputs, external inquiries, internal logical files, external interface files

81

pm = person month

Problem-Based Estimation (continued)

For both approaches, the planner uses lessons learned to estimate an optimistic, most likely, and pessimistic size value for each function or count (for each information domain value) Then the expected size value S is computed as follows: S = (Sopt + 4Sm + Spess)/6 Historical LOC or FP data is then compared to S in order to cross-check it

82

Process-Based Estimation
1) 2) 3) Identify the set of functions that the software needs to perform as obtained from the project scope Identify the series of framework activities that need to be performed for each function Estimate the effort (in person months) that will be required to accomplish each software process activity for each function

(More on next slide)

83

Process-Based Estimation (continued)

4) 5) 6)

Apply average labor rates (i.e., cost/unit effort) to the effort estimated for each process activity Compute the total cost and effort for each function and each framework activity (See table in Pressman, p. 655) Compare the resulting values to those obtained by way of the LOC and FP estimates
If both sets of estimates agree, then your numbers are highly reliable Otherwise, conduct further investigation and analysis concerning the function and activity breakdown

This is the most commonly used of the two estimation techniques (problem and process)

84

Reconciling Estimates
The results gathered from the various estimation techniques must be reconciled to produce a single estimate of effort, project duration, and cost If widely divergent estimates occur, investigate the following causes
The scope of the project is not adequately understood or has been misinterpreted by the planner Productivity data used for problem-based estimation techniques is inappropriate for the application, obsolete (i.e., outdated for the current organization), or has been misapplied

The planner must determine the cause of divergence and then reconcile the estimates

85

Empirical Estimation Models

Introduction
Estimation models for computer software use empirically derived formulas to predict effort as a function of LOC or FP Resultant values computed for LOC or FP are entered into an estimation model The empirical data for these models are derived from a limited sample of projects
Consequently, the models should be calibrated to reflect local software development conditions

87

COCOMO
Stands for COnstructive COst MOdel Introduced by Barry Boehm in 1981 in his book Software Engineering Economics Became one of the well-known and widely-used estimation models in the industry It has evolved into a more comprehensive estimation model called COCOMO II COCOMO II is actually a hierarchy of three estimation models As with all estimation models, it requires sizing information and accepts it in three forms: object points, function points, and lines of source code

(More on next slide)

88

COCOMO Models
Application composition model - Used during the early stages of software engineering when the following are important
Prototyping of user interfaces Consideration of software and system interaction Assessment of performance Evaluation of technology maturity

Early design stage model Used once requirements have been stabilized and basic software architecture has been established Post-architecture stage model Used during the construction of the software

89

COCOMO Cost Drivers

Personnel Factors
Applications experience Programming language experience Virtual machine experience Personnel capability Personnel experience Personnel continuity Platform experience Language and tool experience Required software reliability Database size Software product complexity Required reusability Documentation match to life cycle needs Product reliability and complexity (More on next slide)
90

Product Factors

COCOMO Cost Drivers (continued)

Platform Factors
Execution time constraint Main storage constraint Computer turn-around time Virtual machine volatility Platform volatility Platform difficulty Use of software tools Use of modern programming practices Required development schedule Classified security application Multi-site development Requirements volatility
91

Project Factors

Make/Buy Decision
It is often more cost effective to acquire rather than develop software Managers have many acquisition options
Software may be purchased (or licensed) off the shelf Full-experience or partial-experience software components may be acquired and integrated to meet specific needs Software may be custom built by an outside contractor to meet the purchasers specifications

The make/buy decision can be made based on the following conditions

Will the software product be available sooner than internally developed software? Will the cost of acquisition plus the cost of customization be less than the cost of developing the software internally? Will the cost of outside support (e.g., a maintenance contract) be less than the cost of internal support?
92