2.1 planning &estimation module 2. topic covered 2.1.1 product metrics 2.1.2 estimation- loc,...

2.1 PLANNING &ESTIMATION

MODULE 2

Topic Covered

2.1.1 PRODUCT METRICS2.1.2 ESTIMATION- LOC, FP, COCOMO MODELS

Process, project and measurement

Process Metrics:- Are collected across all projects and over long periods of time. Their intent is to provide a set of process indicator that lead to

long term software process improvement.

Project Metrics:- enables a software project manager to Assess the status of an ongoing project Track potential risks. Uncover problem areas before they go “Critical” Adjust work flow or tasks Evaluate the project team’s ability to control quality of

software work products.

Measurement :- Are collected by a project team and converted into process

metrics during software process improvement.

Process Metrics and Software Process Improvement

Process Metrics and Software Process Improvement

Process at the center connecting 3 factors that have a profound influence on software quality and organizational performance.

Process triangle exists within a circle of environmental conditions that include the development environment, business conditions and customer characteristics.

We measure the efficacy of a software process indirectly. That is, we derive a set of metrics based on the outcomes that can be

derived from the process. Outcomes include

measures of errors uncovered before release of the software defects delivered to and reported by end-users work products delivered (productivity) human effort expended (spend) calendar time expended schedule conformance other measures.

We also derive process metrics by measuring the characteristics of specific software engineering tasks.

Project Metrics

Used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks

Used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality.

Every project should measure: Inputs—measures of the resources (e.g., people, tools)

required to do the work. Outputs—measures of the deliverables or work products

created during the software engineering process. Results—measures that indicate the effectiveness of the

deliverables.

Software Measurement

Categories : Direct measure of the software process &

Product E.g. Lines of code (LOC), execution speed,

and defect) Indirect measures of the product

functionality, complexity, efficiency, reliability, maintainability etc.

Size oriented metrics

Size-Oriented metrics

Size-oriented metrics measures on LOC as normalization value.

Errors per KLOC (thousand lines of code)Defects per KLOC$ per LOCPages of documentation per KLOCErrors per person-monthErrors per review hourLOC per person-month$ per page of documentation

Function-Oriented Metrics

It use a measure of functionality delivered by the application as a normalization value.

Since ‘functionality’ cannot be measured directly, it must be derived indirectly using other direct measures

Function Point (FP) is widely used as function oriented metrics.

FP derived using an empirical relationship based on countable (direct) measures of software’s information domain and assessments of software complexity.

FP is based on characteristic of Software information domain and complexity.

Like LOC measure, FP is controversial. FP is programming language independent.It is ideal for applications using conventional and

nonprocedural languages.

Problem-Based Estimation

Lines of code(LOC) and function point(FP) are described as measures from which productivity metrics can be computed.

LOC and FP data are used in two ways during software project estimation: (1) as an estimation variable to "size“ each element of

the software and (2) as baseline metrics collected from past projects

and used in conjunction with estimation variables to develop cost and effort projections.

An Example of LOC-Based Estimation

As an example of LOC and FP problem-based estimation techniques, let us consider a software package to be developed for a computer-aided design application for mechanical components.

A review of the System Specification indicates that the software is to execute on an engineering workstation and must interface with various computer graphics peripherals including a mouse, digitizer, high resolution colour display and laser printer.

Using the System Specification as a guide, a preliminary statement of software scope can be developed:

The CAD software will accept two- and three-dimensional geometric data from an engineer.

The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design.

All geometric data and other supporting information will be maintained in a CAD database.

Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices.

The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer, and plotter.

For our purposes, we assume that further refinement has occurred and that the following major software functions are identified:• User interface and control facilities (UICF)• Two-dimensional geometric analysis (2DGA)• Three-dimensional geometric analysis (3DGA)• Database management (DBM)• Computer graphics display facilities (CGDF)• Peripheral control function (PCF)• Design analysis modules (DAM)

•Following the decomposition technique for LOC, an estimation table, shown in Figure is developed.

•A range of LOC estimates is developed for each function.

•For example, the range of LOC estimates for the 3D geometric analysis function is

optimistic—4600 LOC, most likely—6900 LOC, and pessimistic—8600 LOC.

•A three-point or expected value can then be computed.

•The expected value for the estimation variable (size), S, can be computed as a weighted average of the optimistic (sopt), most likely (sm), and pessimistic (spess) estimates.

For example, S = (sopt + 4sm + spess)/6

•Applying Equation, the expected value for the 3D geometric analysis function is 6800 LOC.

S = (sopt + 4sm + spess)/6 = (4600 + 4*6900 + 8600)/6 = 6800

•Other estimates are derived in a similar fashion.

•By summing vertically in the estimated LOC column, an estimate of 33,200 lines of code is established for the CAD system.

FUNCTION POINT

For FP estimates, decomposition works differently.

Rather than focusing on function, each of the information domain characteristics—inputs, outputs, data files, inquiries, and external interfaces—as well as the 14 complexity adjustment values are estimated.

The resultant estimates can then be used to derive a FP value that can be tied to past data and used to generate an estimate.

•Function points are computed by completing the table.

•Five information domain characteristics are determined and counts are provided in the appropriate table location.

•Information domain values are defined in the following manner

Number of user inputs - Each user input that provides distinct application-oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately.

Number of user outputs - Each user output that provides application oriented information to the user is counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately.

Number of user inquiries - An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.

Number of files - Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted.

Number of external interfaces - All machine readable interfaces (e.g., data files on storage media) that are used to transmit information to another system are counted.

•Once these data have been collected, a complexity value is associated with each count. •Organizations that use function point methods develop criteria for determining whether a particular entry is simple, average, or complex. •Nonetheless, the determination of complexity is somewhat subjective.•To compute function points (FP), the following relationship is used:

FP = count total [0.65 + 0.01 Σ(Fi)] where count total is the sum of all FP entries obtained from the table

The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions 1. Does the system require reliable backup and recovery?2. Are data communications required?3. Are there distributed processing functions?4. Is performance critical?5. Will the system run in an existing, heavily utilized operational environment?6. Does the system require on-line data entry?7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?8. Are the master files updated on-line?9. Are the inputs, outputs, files, or inquiries complex?10. Is the internal processing complex?

11. Is the code designed to be reusable?12. Are conversion and installation included in the design?13. Is the system designed for multiple installations in different organizations?14. Is the application designed to facilitate change and ease of use by the user?

•Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential).•The constant values in Equation and the weighting factors that are applied to information domain counts are determined empirically.

An Example of FP-Based Estimation

Each of the complexity weighting factors is estimated and the complexity adjustmentfactor Factor ValueBackup and recovery 4Data communications 2Distributed processing 0Performance critical 4Existing operating environment 3On-line data entry 4Input transaction over multiple screens 5Master files updated on-line 3Information Domain values complex 5Internal processing complex 5Code designed for reuse 4Conversion/installation in design 3Multiple installations 5Application designed for change 5

Complexity adjustment factor 1.17Finally, the estimated number of FP is derived:FPestimated = count-total x [0.65 + 0.01 x (Fi)]

= 337 * 1.17FPestimated = 395

An Example of FP-Based Estimation

Decomposition for FP-based estimation focuses on information domain values rather than software functions.

Referring to the function point calculation table presented in Figure, the project planner estimates inputs, outputs, inquiries, files, and external interfaces for the CAD software.

For the purposes of this estimate, the complexity weighting factor is assumed to be average.

Figure presents the results of this estimate.

PLANNING, SCHEDULING ANDTRACKING

2.2 PROJECT MANAGEMENT

2.2 Planning

Probably the most time-consuming project management activity

Continuous activity from initial concept through to system delivery

Plans must be regularly revised as new information becomes available

Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget

Types of project plan

Plan DescriptionQuality plan Describes the quality procedures and

standards that will be used in a project.Validation plan Describes the approach, resources and

schedule used for system validation. Configurationmanagement plan

Describes the configuration managementprocedures and structures to be used.

Maintenance plan Predicts the maintenance requirements ofthe system, maintenance costs and effortrequired.

Staff development plan. Describes how the skills and experience ofthe project team members will bedeveloped.

2.2 SCHEDULING

Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks.

During early stages of project planning, a macroscopic schedule is developed.

This type of schedule identifies all major software engineering activities and the product functions to which they are applied.

As the project gets under way, each entry on the macroscopic schedule is refined into a detailed schedule.

Basic Concept

Why software is delivered late? An unrealistic deadline established Changing customer requirements that are not reflected

in schedule changes. underestimate of the amount of effort and/or the

number of resources that will be required to do the job. Predictable and/or unpredictable risks that were not

considered when the project commenced. Technical difficulties that could not have been foreseen

in advance. Human difficulties that could not have been foreseen in

advance. Miscommunication among project staff that results in

delays. A failure by project management to recognize that the

project is falling behind schedule and a lack of action to correct the problem.

What should we do when management demands that make a deadline that is

impossible?Perform a detailed estimate using historical data

from past projects. Determine the estimated effort and duration for the project.

Using an incremental process model that will deliver critical functionality by the imposed deadline. Document the plan.

Meet with the customer and (using the detailed estimate), explain why the imposed deadline is unrealistic.

Offer the incremental development strategy as an alternative

Basic principle

Compartmentalization: The project must be compartmentalized into a number of manageable activities and tasks.

To accomplish compartmentalization, both the product and the process are decomposed.

Interdependency. The interdependency of each compartmentalized activity or task must be determined.

Some tasks must occur in sequence while others can occur in parallel.

Some activities cannot commence until the work product produced by another is available.

Contd.Time allocation. Each task to be scheduled must

be allocated some number of work units (e.g., person-days of effort).

In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies

Effort validation. As time allocation occurs, the project manager must ensure that no more than the allocated number of people have been scheduled at any given time.

Defined responsibilities. Every task that is scheduled should be assigned to a specific team member.

Defined outcomes. Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally a work product or deliverable.

Defined milestones. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved.

SCHEDULINGTwo project scheduling methods

Program evaluation and review technique (PERT) critical path method (CPM)

Both techniques are driven by information already developed in earlier project planning activities: Estimates of effort A decomposition of the product function The selection of the appropriate process model

and task set Decomposition of tasks

Interdependencies among tasks may be defined using a task network.

Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a whole or for individual functions.

PERT and CPM provide quantitative tools that allow the software planner to Determine the critical path—the chain of tasks

that determines the duration of the project Establish “most likely” time estimates for

individual tasks by applying statistical models; Calculate “Boundary times” that define a time

"window" for a particular task.Both PERT and CPM have been

implemented in a wide variety of automated tools that are available for the personal computerE.g. Primevera software

Timeline ChartsThe planner always begins with a set of tasks (the work

breakdown structure). If automated tools are used, the work breakdown is input

as a task network or task outline.Effort, duration, and start date are then input for each

task. In addition, tasks may be assigned to specific individuals.

A timeline chart enables you to determine what tasks will be conducted at a given point in time.

A timeline chart can be developed for the entire project. Alternatively, separate charts can be developed for each

project function or for each individual working on the project.

Contd.All project tasks are listed in the left-hand column.The horizontal bars indicate the duration of each

task.When multiple bars occur at the same time on the

calendar, task concurrency is implied.The diamonds indicate milestones.Once the information necessary for the generation

of a timeline chart has been input, the majority of software project scheduling tools produce project tables

It is a tabular listing of all project tasks, their planned and actual start- and end-dates, and a variety of related information.

Project tables enable the project manager to track progress.

Project Table

2.3 Tracking

Project schedule defines the tasks and milestones that must be tracked and controlled as the project proceeds.

Tracking can be accomplished in a number of different ways: Conducting periodic project status meetings in which each

team member reports progress and problems. Evaluating the results of all reviews conducted Determining whether formal project milestones (i.e.

diamonds) have been accomplished by the scheduled date. Comparing actual start-date to planned start-date for each

project task listed in the resource table. Using earned value analysis to evaluate progress

quantitatively.

EARNED VALUE ANALYSIS

The earned value system provides a common value scale for every task, regardless of the type of work being performed.

Simply stated, earned value is a measure of progress.

It enables us to assess the “percent of completeness” of a project using quantitative analysis

The total hours to do the whole project are estimated, and every task is given an earned value based on its estimated percentage of the total.