1. MODULE 2
2.1 PLANNING &ESTIMATION

2. Topic Covered 2.1.1 PRODUCT METRICS
2.1.2 ESTIMATION- LOC, FP, COCOMO MODELS

3. 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.

4. Process Metrics and Software Process Improvement

5. 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.

6. 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.

7. 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.

8. Size oriented metrics

9. Size-Oriented metrics
Size-oriented metrics measures on LOC as normalization value.
Errors per KLOC (thousand lines of code)
Defects per KLOC
$ per LOC
Pages of documentation per KLOC
Errors per person-month
Errors per review hour
LOC per person-month
$ per page of documentation

10. 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.

11. 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.

12. 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:

13. 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.

14. 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)

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

16. 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

17. Applying Equation, the expected value for the 3D geometric analysis function is 6800 LOC.
S = (sopt + 4sm + spess)/6
= ( * )/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.

18. 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.

20. 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.

21. 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.

22. 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 [ Σ(Fi)]
where count total is the sum of all FP entries obtained from the table

23. 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?

24. 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.

25. An Example of FP-Based Estimation

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

27. Complexity adjustment factor 1.17
Finally, the estimated number of FP is derived:
FPestimated = count-total x [ x (Fi)]
= 337 * 1.17
FPestimated = 395

28. 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.

29. PLANNING, SCHEDULING AND TRACKING
2.2 PROJECT MANAGEMENT
PLANNING, SCHEDULING AND TRACKING

30. 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

31. Types of project plan

32. 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.

33. 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.

34. 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

35. 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.

36. 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.

37. SCHEDULING Two 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.

38. 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 computer
E.g. Primevera software

39. Timeline Charts
The 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.

41. 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.

42. Project Table

43. 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.

44. 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.