Software Project Management

1. Software Project Management By Mr. Manoj Kumar Kar

2. Introduction: • The main job of software project management is to enable a group of software engineers to work efficiently towards successful completion of the project. Job Responsibilities of a software project manager: • Project proposal writing. • Project cost estimation. • Scheduling. • Project staffing. • Software process tailoring. • Project monitoring and control. • Software configuration management. • Risk management. • Interface with client. • Managerial report writing.

3. Skills necessary for software project management: • Good qualitative judgment and decision making capabilities. • Good grasp of the latest software project management techniques. • Cost estimation. • Risk management. • Configuration management. • Good communication skills and the ability to get work done. • Tracking and controlling the progress of the project. • Customer interaction. • Managerial presentations. • Team building.

4. Project Planning: • Project planning consists of the following essential activities. • Estimating some basic attributes of the project like cost, duration and effort. • Scheduling man power and other resources. • Staff organization and staffing plans. • Risk identification, analysis and abatement planning. • Miscellaneous plans such as quality assurance plan, configuration management plan etc.

5. Precedence ordering among project planning activities. Effort Estimation Cost Estimation Size Estimation Scheduling Duration Estimation Project staffing

6. Software Project Management Plan Document: • SPMP document is prepared by the project manager after the completion of the project planning. Organization of the SPMP ducument: Introduction: • Objectives. • Major functions. • Performance issues. • Management and technical constrains. Project Estimation: • Historical data used. • Estimation techniques used. • Effort, resource, cost and project duration estimation.

7. Software Project Management Plan Document continued.. Schedule: • Work breakdown structure. • Task network representation. • Gantt chart representation. • PERT chart representation. Project resources: • People. • Hardware and software. • Special resources. Staff organization: • Team structure. • Management reporting.

8. Software Project Management Plan Document continued.. Risk management Plan: • Risk analysis. • Risk identification. • Risk estimation. • Risk abatement procedures. Project tracking and control plan: Miscellaneous Plans • Process tailoring. • Quality assurance plan. • Configuration management plan. • Validation and verification. • System testing plan. • Delivery, installation and maintenance plan.

9. Metrics for project size estimation: • A project size is a measure of the problem complexity in terms of the effort and time required to develop the product. • Broadly two types of metrics are widely used to estimate the size of a product. 1. Lines of code. 2. Function Point.

10. Lines of code: • To determine the LOC at the very beginning of a project, the project manager divides the whole project into modules and each module into sub module and so on until the size of the different leaf-level modules can be approximately predicted. Shortcomings of LOC approach: • LOC gives a numerical value of problem size that can vary widely with individual coding style. • A good problem size measure should consider the overall complexity of the problem and the effort need to solve it that is it need to consider the total effort needed to specify design, coding , testing etc. where as LOC only focuses on coding part. • LOC measure correlates poorly with the quality and efficiency of the code. • LOC metric penalizes use of higher-level programming languages. • LOC metric measures the lexical complexity of a program and does not address the more important and subtle issues of logical or structural complexity. • It is difficult to accurately estimate the LOC in the final product from the problem specification.

11. Function Point Metric: • Function point approach can be used to easily estimate the size of a software product directly from the problem specification. • The concept of the function point metric is that the size of a software product is directly dependent of the number of different functions and features it supports. • FP metric defines that the size of a software product depend upon the number of basic functions that the software performs along with the number of files and the number of interfaces.

12. Function Point Metric continued.. • Besides using the number of input and out put data values, function point metric computes the size of a software product in units of function points (FPs) using other characteristics of the product as shown below. • UFP= (Number of inputs)*4 + (Number of outputs) * 5 + (Number of inquiries) * 4 + (Number of files) * 10 + ( Number of Interfaces) * 10. • Where UFP stands for unadjusted function point.

13. Function Point Metric continued.. • After calculation of the unadjusted function point (UFP), the technical complexity factor (TCF) is computed. • The TCF is refines the UFP by considering fourteen other parameters like high transaction rate, throughput, the response time requirement etc. • Each of these 14 factors is assigned a value from 0 (Not present or no influence) to 6 (Strong influence) and the resulting numbers are summed which yields the total degree of influence (DI). • Now TCF is computed as (0.65+0.01*DI). • As DI can vary from 0 to 70, the TCF may vary from 0.65 to 1.35. • Finally the FP is calculated as FP= UFP * TCF.

14. Feature Point Metric: • The shortcoming of function point approach is that it does not take into account the algorithmic complexity of a software. • To overcome this problem, an extension of function point approach has been proposed called as feature point approach. • Feature point metric incorporates an extra parameter into algorithm complexity.

15. Project estimation techniques: • During project estimation, the different project parameters such as project size, effort required, project duration, cost etc are to be analyzed. • There are three broad categories of project estimation techniques • Empirical estimation technique. • Heuristic techniques. • Analytical estimation techniques.

16. Empirical Estimation Techniques: • Empirical estimation techniques are based on making an educated guess of the project parameters. • This approach uses two different types of estimation techniques such as • Expert judgment Technique. • Delphi cost estimation technique.

17. Empirical Estimation Techniques continued.. Expert Judgment Techniques: • In this approach an expert makes an educated guess of the problem size problem after analyzing the problem thoroughly. • The drawback of this approach is that this technique is subject to human errors and individual bias. • The more refined form of the expert judgment is the estimation made by a group of experts.

18. Empirical Estimation Techniques continued.. Delphi cost estimation: • Delphi estimation is carried out by a team composed of a group of experts and a coordinator. • The coordinator provides each estimator with a copy of the SRS document and a form for recording the individual estimation. • The coordinator prepares and distributes the summary of the responses of all the estimators, and includes any unusual rationale noted by any of the estimator. • Based on this summary re-estimation work will go on and the same process will be iterated for several rounds.

19. COCOMO- A Heuristic Estimation Techniques: • COCOMO model is the short form of Constructive Cost estimation Model. • As per this approach any software development project can be classified into one of the following three categories based on the development complexity. • Organic. • Semidetached. • Embedded. • The above mentioned product classes corresponds to application, utility and system programs respectively.

20. COCOMO model continues.. • The ratio of the relative levels of product development complexity for the three categories of products are 1:3:9. for application, utility and system programs. Organic: • The development project may be considered to be organic type, if the project deals with developing a well understood application program, the size of the development team is reasonably small and the team members are experienced in developing the same type of projects. Semidetached: • A development project may be considered as semidetached type, if the development team consists of a mixture of experienced and inexperienced staff. Team members may have limited experience on related systems but may unfamiliar with some aspects of the system being developed.

21. COCOMO model continues.. Embedded: • A development project is considered to be of embedded type, if the software being developed is strongly coupled to complex hardware, or if stringent regulations on the operational procedure exists. • This approach introduced the new approach of units for the estimation as given below • PM (Person-month): is the effort an individual can typically put in a month. • KLOC- Kilo lines of source code. This approach has to be completed through three different stages like basic COCOMO, intermediate COCOMO and complete COCOMO

22. Basic COCOMO model: • The basic COCOMO model gives an approximate estimate of the project parameters. • The basic COCOMO estimation model is given by the following expressions Effort= a1x (KLOC) a2 PM Tdev= b1 x (Effort) b2 months. Where • KLOC is the estimated size of the software product expressed in Kilo Lines of codes. • a1, a2, b1, b2 are constants for each category of software products. • Tdev is the estimated time to develop the software, expressed in months. • Effort is the total effort required to develop the software product, expressed in person-month.

23. Basic COCOMO model continued.. • According to this approach, every line of source text should be calculated as one LOC irrespective of the actual number of instruction on that line. • The values of a1, a2, b1, b2 for different categories of products are as given below. Estimation of development effort: • Organic : Effort = 2.4 (KLOC)1.05 PM • Semi-detached : Effort = 3.0 (KLOC)1.12 PM • Embedded : Effort = 3.6 (KLOC)1.20 PM

24. Basic COCOMO model continued.. Estimation of development time: • Organic : Tdev = 2.5(Effort)0.38 months. • Semi-detached: Tdev = 2.5 (Effort)0.35 months. • Embedded : Tdev = 2.5 (Effort)0.32 months. • The effort and duration estimations obtained using the COCOMO model are called nominal effort estimate and nominal duration estimate.

25. Example of basic COCOMO model • Assume that the size of an organic type software product has been estimated to be 32000 lines of source code. Assume that the average salary of software engineer is 15000 per month. Determine the effort required to develop the software product and the nominal development time. Solution: From the basic COCOMO estimation formula for organic software Effort = 2.4 x (32)1.05 PM = 91 PM Nominal development time = 2.5 x (91)0.38 = 14 month. Cost required to develop the Project = 14 x 15000 = 210000

26. Intermediate COCOMO • Intermediate COCMO model proposes that only effort and development time are not to be considered as there are so many other factors which has influence on the product development. • This approach considers a new set of 15 different parameters with a cost multiplier in a range of 1 to 3 along with the estimation of the basic COCOMO model. • The 15 parameters may be divided into four particular specifications. • Product: The characteristics of the product that are considered including the inherent complexity of the product, reliability requirements of the product etc. • Computer: The characteristics of the computer that are considered include the execution speed requirement, Storage space required etc. • Personel: The attributes of development personnel that are considered include the experience level of personnel, programming capability, analysis capability etc. • Development environment: Development environment attributes capture the development facilities available to the developers, sophistication of the automation tools used for software development.

27. Complete COCOMO model • The major shortcoming of both the basic and intermediate COCOMO model is that they consider a software product as a single homogeneous entity. • But the actual case is that as the whole project is to be decomposed into so many sub modules and the sub modules may not be of same type.

28. Halstead’s Software science- Analytical technique • Halstead’s software science is an analytical technique to measure size, development effort and development cost of software products. • According to this approach for a given program let 1. ƞ1 be the number of unique operators used in the program. 2. ƞ2 be the number of unique operands in the program. 3. N1 be the total number of operators used in the program. 4. N2 be the total number of the operands used in the program.

29. Halstead’s Software science- Analytical technique continued.. • This approach considers the following attributes for estimation • Operators and Operands: • Length and Vocabulary: The length of a program quantifies the total usage of all operators and operands in the program. N = N1 + N2 . The program vocabulary is the number of unique operators and operands used in the program. ƞ = ƞ1 + ƞ2

30. Halstead’s Software science- Analytical technique continued.. • Program volume: V = N log2ƞ 4. Potential Minimum Volume: Potential minimum volume V* is defined as the volume of the most succinct program in which a program can be coded. V* = ( 2 + ƞ2 ) log2 ( 2 + ƞ2 ) The program level L= V* / V

31. Halstead’s Software science- Analytical technique continued.. • Effort and time: • The effort required to develop a program can be obtained by dividing the program volume by the level of the programming language used to develop the code. E = V/L. E= V/ V* / V. E= V2 / V* • The programmer’s time T= E/S • Length estimation: • N = ƞ1 log2 ƞ1 + ƞ2 log2 ƞ2

32. Halstead’s Software science- Analytical technique continued.. • Length estimation: • N = ƞ1 log2 ƞ1 + ƞ2 log2 ƞ2

33. Scheduling: • Scheduling the project task involves deciding which tasks would be taken up when. • In order to schedule the project activities, a software project manager needs to do the following • Identify all the tasks needed to complete the project. • Breakdown large tasks into small activities. • Determine the dependency among different activities. • Establish the most likely estimates for the time duration necessary to complete the activities. • Allocate resource to activities. • Plan the starting and ending dates for various activities. • Determine the critical path.

34. Work Breakdown Structure: • Work breakdown structure (WBS) is used to decompose a given task set recursively into small activities. • WBS provides the notation for representing the major tasks needed to be carried out in order to solve a problem. • The root of a tree is labeled by the problem name. • Each node of the tree is broken down into smaller activities. • Each activity is recursively decomposed into smaller sub-activities until at the leaf level, the activities require approximately two weeks to develop.

35. WBS of MIS a case study MIS Application Requirement Specification Design Code Test Document Database part Graphical User Interface Database Part Graphical user interface part

36. Activity Network and critical path Method • WBS representation of a project is transformed into an activity network by representing the activities identified in WBS along with their interdependencies. • An activity network shows the different activities making up a project, their estimated duration, and interdependencies. • Each activity is represented by a rectangular node and the duration of the activity is shown alongside each task.

37. Activity network representation of MIS problem Code database part 105 Database design part 45 Integrate and test 120 Specification 15 Finish 0 Design GUI part 30 Code GUI part 45 Write user manual 60