CHAPTER 21 PROJECT MANAGEMENT CONCEPTS 1 PROJECT MANAGEMENT

CHAPTER 21 PROJECT MANAGEMENT CONCEPTS 1

PROJECT MANAGEMENT � Project management involves the planning, monitoring, and control of the people, process, and events that occur as software evolves from a preliminary concept to full operational deployment. �A project plan is produced as management activities commence. The plan defines the process and tasks to be conducted, the people who will do the work, and the mechanisms for assessing risks, controlling change, and evaluating quality. 2

PROJECT MANAGEMENT SPECTRUM � Effective software project management focuses on the four P’s: �people, � product, �process, �and project 3

THE 4 P’S � People — the most important element of a successful project. � Product — the software to be built. � Process — the set of framework activities and software engineering tasks to get the job done. � Project — all work required to make the product a reality. 4

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

SOFTWARE TEAMS How to lead? How to organize? How to collaborate? How to motivate? How to create good ideas? 6

7 SOFTWARE TEAMS • The following factors must be considered when selecting a software project team structure. . . � � � � the difficulty of the problem to be solved the size of the resultant program(s) in lines of code or function points the time that the team will stay together (team lifetime) 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

PRODUCT (SCOPE STATEMENT) � A statement of software scope must be bounded. That is, quantitative data (e. g. , number of simultaneous users, target environment, maximum allowable response time) are stated explicitly, constraints or limitations (e. g. , product cost restricts memory size) are noted. � Software project scope must be unambiguous and understandable at the management and technical levels. 9

PRODUCT (PROBLEM DECOMPOSITION) � Apply a divide-and-conquer strategy when they is a complex problem. S � Once scope is defined … � It is decomposed into constituent functions � It is decomposed into user-visible data objects � or � It is decomposed into a set of problem classes � Decomposition process continues until all functions or problem classes have been defined. 10

PROCESS � The framework activities that characterize the software process are applicable to all software projects. The problem is to select the process model that is appropriate for the software to be engineered by your project team. � Your team must decide which process model is most appropriate for (1) the customers who have requested the product and the people who will do the work, (2) the characteristics of the product itself, and (3) the project environment in which the software team works. 11

PROJECT � In order to manage a successful software project, you have to understand what can go wrong so that problems can be avoided. � Projects get into trouble when … � 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 ill-defined]. � Deadlines are unrealistic. � Users are resistant (opposed/unwilling). � 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 12

CHAPTER 22 PROCESS AND PROJECT METRICS Software Engineering: A Practitioner’s Approach, 6 th edition by Roger S. Pressman 13

A GOOD MANAGER MEASURES process metrics measurement project metrics product What do we use as a basis? • size? • function? 14

WHY DO WE MEASURE? � 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. 15

WHAT IS A “MEASURE”? “Way of associating a number with some “ attribute of a physical object” height → meters temperature → degrees Celsius 16

METRIC Software Metric is a measure of anything directly related to software or its production 17

EXAMPLES OF METRICS � Effort/time per software engineering task � Errors uncovered per review hour � Scheduled vs. actual milestone dates � Changes (number) and their characteristics 18

SOFTWARE MEASUREMENT Measurement can be categorized as : � Direct � Indirect � Direct measures of the software process include cost and effort applied. Direct measures of the product include lines of code (LOC) produced, execution speed, memory size, and defects reported over some set period of time. � Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability, and many other “– abilities”. � 19

SIZE-ORIENTED METRICS � Size-oriented software metrics are derived by considering the size (LOC) of the software that has been produced. � Typical size oriented metrics are : � errors per KLOC (thousand lines of code) � defects per KLOC � $ per LOC � pages of documentation per KLOC � errors person-month � Errors per review hour � LOC person-month � $ per page of documentation 20

FUNCTION-ORIENTED METRICS � Function-oriented software metrics use a measure of the functionality (function point) delivered by the application. � Typical FP based metrics are: errors per FP (thousand lines of code) � defects per FP � $ per FP � pages of documentation per FP � FP person-month � 21

MEASURING QUALITY A project manager must also evaluate quality as the project progresses. � Correctness — Correctness is the degree to which the software performs its required function. The most common measure for correctness is defects per KLOC, where a defect is defined as a verified lack of conformance to requirements. � Maintainability—the degree to which a program is amenable to change. � � A simple time-oriented metric is mean-time-to-change (MTTC), the time it takes to analyze the change request, design an appropriate modification, implement the change, test it, and distribute the change to all users. Usability— Usability can be defined as the capability of the software to be understood, learned, and used under specified conditions. 22

� � � Integrity—the degree to which a program is resistant to outside attack, To measure integrity, two additional attributes must be defined: threat and security. The integrity of a system can then be defined as: For example, if threat (the probability that an attack will occur) is 0. 25 and security (the likelihood of repelling an attack) is 0. 95, the integrity of the system is 0. 99 (very high). If, on the other hand, the threat probability is 0. 50 and the likelihood of repelling an attack is only 0. 25, the integrity of the system is 0. 63 (unacceptably low). 23

DEFECT REMOVAL EFFICIENCY • DRE is a measure of the filtering ability of quality assurance and control actions as they are applied throughout all process framework activities. 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. • The ideal value for DRE is 1. That is, no defects are found in the software. 24

� DRE can also be used at different phases of software development. It is used to assess the software team's ability to find errors at each phase before they are passed on to the next development phase � DRE = Number of defects resolved by the development team / total number of defects at the moment of measurement. � Example For example, suppose that 100 defects were found during QA/testing stage and 84 defects were resolved by the development team at the moment of measurement. The DRE would be calculated as 84 divided by 100 = 84% 25

Chapter 23 ESTIMATION FOR SOFTWARE PROJECTS LECTURE 39 -40 26

INTRODUCTION software project management begins with a set of activities that are collectively called project planning. � Before the project can begin, the software team should estimate: � the work to be done, � the resources that will be required, � and the time that will elapse from start to finish. � � Once these activities are accomplished, the software team should establish a project schedule that defines software engineering tasks and milestones, identifies who is responsible for conducting each task, and specifies the inter task dependencies that may have a strong bearing on progress. 27

PROJECT PLANNING PROCESS � The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule. � the plan must be adapted and updated as the project proceeds. 28

PROJECT PLANNING Project Scope Estimates Risks Schedule Control strategy Software Project Plan 29

SOFTWARE SCOPE? Software scope describes � the functions and features that are to be delivered to end-users � the data that are input and output � 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 is defined using one of 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. 30 �

RESOURCES 31

SOFTWARE PROJECT ESTIMATION � For an effective management accurate estimation of various measures is a must. With correct estimation managers can manage and control the project more efficiently and effectively. � Project estimation may involve the following: � Software size estimation � Effort estimation � Time estimation � Cost estimation 32

PROJECT ESTIMATION TECHNIQUES � � � Project manager can estimate using two broadly recognized techniques – Decomposition Technique � This technique assumes the software as a product of various compositions. � There are two main models � Line of Code Estimation is done on behalf of number of line of codes in the software product. � Function Points Estimation is done on behalf of number of function points in the software product. Empirical Estimation Technique � This technique uses empirically derived formulae to make estimation. These formulae are based on LOC or FPs 33

DECOMPOSITION TECHNIQUES � Software project estimation is a form of problem solving, and in most cases, the problem to be solved (i. e. , developing a cost and effort estimate for a software project) is too complex to be considered in one piece. For this reason, you should decompose the problem, recharacterizing it as a set of smaller (and hopefully, more manageable) problems. � Two different points of view: � � � Problem based Process based But before an estimate can be made, you must understand the scope of the software to be built and generate an estimate of its “size. ” 34

PROBLEM BASED ESTIMATION use two main attributes LOC and FP � Metrics � � LOC/pm or � FP/pm 35

Size estimation based on LOC � 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 by using following formula: S = Sopt + Sm + Spess / 6 36

Example of LOC based estimation A review of historical data indicates that the organizational average productivity for systems of this type is 620 LOC/pm. Based on a burdened labor rate of $8000 per month, calculate the cost per line of code. Based on the LOC estimate and the historical productivity data, find the total estimated project cost and estimated effort ? 37

� For example, the range of LOC estimates for the 3 D geometric analysis function is optimistic, 4600 LOC; most likely, 6900 LOC; and pessimistic, 8600 LOC the expected value for the 3 D geometric analysis function is 6800 LOC. Other estimates are derived in a similar manner. 620 loc/month… 620/30 =20. 66 or 21 loc per day… � 8000/month…. 8000/30 = 266. 6 cost per day. . � Cost per loc = cost per day / Loc per day …. . 267/21 = 12. 71 or 13$ � Project cost = total loc * cost per loc …… 33200 *13 =431600 � Effort(time) = total loc / loc per month …. . 33200 / 620 = 53. 5 or 54 p-m � 38

FP BASED ESTIMATION � Or FP = UFP * [0. 65 + 0. 01 * VAF] 39

COUNT TOTAL (UFP) 40

41

42

EXAMPLE 1: ESTIMATING INFORMATION DOMAIN VALUES • assume that (sum of Fi) is 46 43

� � Lines of code in each function point depends upon language that is selected for development. You have to find LOC (Lines of Code), and you do this by choosing a programming language that you will use when developing a project: 45

EXERCISE � A system has 12 external inputs, 24 external outputs, fields 30 different external queries, manages 4 internal logical files and interfaces with 6 different legacy systems, all of this data are of average complexity and the overall system is relatively simple, compute FP for the system with moderate complexity adjustment factor. . 46

COCOMO (CONSTRUCTIVE COST MODEL) � COCOMO is one of the most widely used software estimation models in the world, It was developed by Barry Boehm in 1981. � COCOMO predicts the effort and schedule for a software product development based on inputs relating to the size of the software. � COCOMO has three different models that reflect the complexity: � the Basic Model � the Intermediate Model � and the Detailed Model 47

THE DEVELOPMENT MODES AND PROJECT CHARACTERISTICS � Organic Mode • • Relatively small, simple software projects Small teams with good application experience work to a set of less than rigid requirements Similar to the previously developed projects relatively small and requires little innovation � Semidetached Mode • Intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.

CONTD… � Embedded Mode • Software projects that must be developed within a set of tight hardware, software, and operational constraints.

BASIC COCOMO MODEL: FORMULA E=ab (KLOC or KDSI) bb D=cb (E) db P=E/D where E is the effort applied in person-months, D is the development time in chronological months, KLOC / KDSI is the estimated number of delivered lines of code for the project (expressed in thousands), and P is the number of people required. The coefficients ab, bb, cb and db are given in next slide.

VALUES OF COEFFICIENTS Development mode � Organic � Semi-detached � Embedded ab bb cb db 2. 4 1. 05 2. 5 0. 38 3. 0 1. 12 2. 5 0. 35 3. 6 1. 20 2. 5 0. 32

BASIC COCOMO MODEL: EQUATION

BASIC COCOMO MODEL: EXAMPLE � Assume that the project fits the characteristics of Semi-Detached mode and estimated Delivered Source Instructions as 32, 000. Using the formulas, we can estimate: � Effort (E) = 3. 0*(32) 1. 12 = 146 man-months � Schedule (D)= 2. 5*(146) 0. 35 = 14 months � No. of people reqd (p) = 146 MM /14 months = 10 people

PROCESS-BASED ESTIMATION Obtained from “process framework” framework activities application functions Effort required to accomplish each framework activity for each application function 54

PROCESS-BASED ESTIMATION EXAMPLE Based on an average burdened labor rate of $8, 000 per month, the total estimated project cost is $368, 000 and the estimated effort is 46 person-months. 55

THE MAKE-BUY DECISION � Software engineering managers are faced with a make/ buy decision that can be further complicated by a number of acquisition options: � (1) software may be purchased (or licensed) off-the-shelf, � (2) “full-experience” or “partial-experience” software components may be acquired and then modified and integrated to meet specific needs, or � (3) software may be custom built by an outside contractor to meet the purchaser’s specifications. 60

CREATING A DECISION TREE 61

COST CALCULATION Estimated Cost of buy is less as compared to other estimated costs so project X will be purchased 62