Software Cost estimation

Size: px

Start display at page:

Download "Software Cost estimation"

Robert Logan
5 years ago
Views:

1 Software Cost estimation

32 COCOMO II COCOMOII was developed in 1995 It could overcome the limitations of calculating the costs for non-sequential, rapid development, reengineering and reuse models of software. It has 3 modules Application composition: - good for projects with GUI interface for rapid development of project. Early design: - Prepare a rough picture of what is to be designed. Done before the architecture is designed.

33 Post architecture: - Prepared after the architecture has been designed. COCOMO II USES Helps in making decisions based on business and financial calculations of the project. Establishes the cost and schedule of the project under development, this provides a plan for the project. Provides a more reliable cost and schedule, hence the risk mitigation is easy to accomplish. It overcomes the problem of reengineering and reuse of software modules. Develops a process at each level. Hence takes care of the capability maturity model

35 Decision Tree Means 30% probability Estimated path cost

36 Decision Tree Expected value of cost computed along each branch of the decision tree is: expected cost = Σ (path probability) i x (estimated path cost) i where i is the decision tree path, for example, For Build path expected cost = 0.30($380K)+0.70($450K) = $429K Similarly, for Reuse path, expected cost is $382K; for Buy path, it is $267K; for Contract path, it is $410K. So the obvious choice is to buy

37 Outsourcing Acquisition of software (or components) from a source outside the organization Software engineering activities are contracted to a third party who does the work at lower cost and (hopefully) at higher quality Software work within the company is reduced to contract management activity Outsourcing is often a financial decision Positive side Cost saving can usually be achieved by reducing own resources (people & infrastructure) Negative side Company loses some control over the software and bears the risk of putting its fate in hands of a third party

38 What is estimation? The project manager must set expectations about the time required to complete the software among the stakeholders, the team, and the organization s management. If those expectations are not realistic from the beginning of the project, the stakeholders will not trust the team or the project manager. 38

39 Elements of a Sound Estimate To generate a sound estimate, a project manager must have: A work breakdown structure (WBS), or a list of tasks which, if completed, will produce the final product An effort estimate for each task A list of assumptions which were necessary for making the estimate Consensus among the project team that the estimate is accurate 39

40 Assumptions Make Estimates More Accurate Team members make assumptions about the work to be done in order to deal with incomplete information Any time an estimate must be based on a decision that has not yet been made, team members can assume the answer for the sake of the estimate Assumptions must be written down so that if they prove to be incorrect and cause the estimate to be inaccurate, everyone understands what happened Assumptions bring the team together very early on in the project so they can make progress on important decisions that will affect development 40

41 Wideband Delphi Wideband Delphi is a process that a team can use to generate an estimate The project manager chooses an estimation team, and gains consensus among that team on the results Wideband Delphi is a repeatable estimation process because it consists of a straightforward set of steps that can be performed the same way each time 41

42 The Wideband Delphi Process Step 1: Choose the team The project manager selects the estimation team and a moderator. The team should consist of 3 to 7 project team members. The moderator should be familiar with the Delphi process, but should not have a stake in the outcome of the session if possible. If possible, the project manager should not be the moderator because he should ideally be part of the estimation team. 42

43 The Wideband Delphi Process Step 2: Kickoff Meeting The project manager must make sure that each team member understands the Delphi process, has read the vision and scope document and any other documentation, and is familiar with the project background and needs. The team brainstorms and writes down assumptions. The team generates a WBS with tasks. The team agrees on a unit of estimation. 43

44 The Wideband Delphi Process Step 3: Individual Preparation Each team member independently generates a set of preparation results. For each task, the team member writes down an estimate for the effort required to complete the task, and any additional assumptions he needed to make in order to generate the estimate. 44

45 The Wideband Delphi Process Step 4: Estimation Session During the estimation session, the team comes to a consensus on the effort required for each task in the WBS. Each team member fills out an estimation form which contains his estimates. The rest of the estimation session is divided into rounds during which each estimation team member revises her estimates based on a group discussion. Individual numbers are not dicsussed. 45

46 The Wideband Delphi Process Step 4: Estimation Session (continued) The moderator collects the estimation forms and plots the sum of the effort from each form on a line: 46

47 The Wideband Delphi Process Step 4: Estimation Session (continued) The team resolves any issues or disagreements that are brought up. Individual estimate times are not discussed. These disagreements are usually about the tasks themselves. Disagreements are often resolved by adding assumptions. The estimators all revise their individual estimates. The moderator updates the plot with the new total: 47

48 The Wideband Delphi Process Step 4: Estimation Session (continued): The moderator leads the team through several rounds of estimates to gain consensus on the estimates. The estimation session continues until the estimates converge or the team is unwilling to revise estimates. Step 5: Assemble Tasks The project manager works with the team to collect the estimates from the team members at the end of the meeting and compiles the final task list, estimates and assumptions. Step 6: Review Results The project manager reviews the final task list with the estimation team. 48

49 Work Breakdown Structure WBS describes a break down of project goal into intermediate goals Each in turn broken down in a hierarchical structure Ch. 8 49

50 Example: a compiler project Compiler project Design Code Integrate and test Write manual Scanner Parser Code generator Ch. 8 50

51 Organization structure Client and future user, as enterprises have their own organization. And we will have problems with them. It's interesting for us identify the organization structure and understand their authority and knowledge distribution. Typical structures are: Functional organization Project organization Matrix organization GpiI-3A Organizing a Software Project 51

52 Organization assigns: Tasks and activities to people groups. Objectives to each group. Responsibilities to groups and coordinators Authorities between groups and their member's. Formal communication channels. GpiI-3A Organizing a Software Project 52

53 Functional organization (I) Is the more known structure (military, church,...) Is the typical pyramidal structure. Each new level introduces a type of specialization. It can be: type of work (functional), geographic localization (Territorial), Size of clients (Clients oriented), product (Product oriented). GpiI-3A Organizing a Software Project 53

54 Functional organization (II) Communication is allowed between: People at under the same boss (same level). Boss and subordinate. Formal communication between two people in different areas must follow a long trip. Worker to boss, boss to boss until a pint in the pyramid were starts to down until boss to worker. GpiI-3A Organizing a Software Project 54

55 Functional Organization Pros Clear definition of authority Eliminates duplication Encourages specialization Clear career paths Cons Walls : can lack customer orientation Silos create longer decisions cycles Conflicts across functional areas Project leaders have little power Q7503 Principles of Project Management, Fall

56 Project organization (I) Objectives attainment in a quick manner. Enterprise organization depends on the actual projects Each project has their own team and all the necessary resources. The project manager has decision capacity. Team duration depends on the project duration. GpiI-3A Organizing a Software Project 56

57 Project Organization Pros Unity of command Effective inter-project communication Cons Duplication of facilities Career path Examples: defense avionics, construction Q7503 Principles of Project Management, Fall

58 Matrix organization (I) It's a multidimensional structure. Try to take the best of both. First we create functional structure and over this we put a project structure. GpiI-3A Organizing a Software Project 58

59 Matrix Organization Pros Project integration across functional lines Efficient use of resources Retains functional teams Cons Two bosses for personnel Complexity Resource & priority conflicts Q7503 Principles of Project Management, Fall

60 Matrix Forms Weak, Strong, Balanced Degree of relative power Weak: functional-centric Strong: project-centric Q7503 Principles of Project Management, Fall

61 Teams Structure The development of software projects usually requires: Small teams. Classical structures aren t an appropriate reference Specialists in different areas: Software technical knowledge Knowledge about the implied area. (Multifunctional teams). GpiI-3A Organizing a Software Project 61

62 Team Structure in software projects Three team structures are popular in this field: Egoless programming team (Weinberg) Chief programming team. Controlled decentralized team structure.» Marilyn Mantei (1981) GpiI-3A Organizing a Software Project 62

63 Egoless programming team (Weinberg) Ten or fewer programmers Exchange their code with other team members for error examination. Goals are set by group consensus. Group leadership is a rotating function, becoming the responsibility of the individual with the abilities that are currently needed. GpiI-3A Organizing a Software Project 63

64 Egoless team: Management Structure. People are in different knowledge areas and experience levels. GpiI-3A Organizing a Software Project 64

65 Egoless team: Communication exchanges that occur. Everybody can communicate with everybody. GpiI-3A Organizing a Software Project 65

66 Chief programming team. Use to be little teams. It have a chief programmer who: manages all technical aspects. Takes problem solutions and and goal decisions. Assign well defined (but large and complex) to the team members. GpiI-3A Organizing a Software Project 66

67 Chief programming team. Management Structure. Is a centralized autocratic structure. Chief programmer Programmer Data Bases Specialist GpiI-3A Organizing a Software Project 67

68 Chief programming team: Communication exchanges that occur. All the communications past throw the chief. GpiI-3A Organizing a Software Project 68

69 Controlled Decentralized Team. Teams can be large teams. Has a project leader who governs a group of senior programmers. Each senior programmer in turn, manages a group of junior programmers. The objective is to maintain other teams the best characteristics. GpiI-3A Organizing a Software Project 69

70 Controlled Decentralized Team: Management Structure. Responsibility is shared by the project leader and the seniors programmers. Project Leader Senior Programmer Junior Programmers GpiI-3A Organizing a Software Project 70

71 Controlled Decentralized Team: Communication exchanges. People at he same level and their boss is decentralized. GpiI-3A Organizing a Software Project 71

72 Relations between team structures: Group structures Democratic decentralized Controlled decentralized Diff icult y H i g h L o w Size Dur atio n L a r g e S m a ll S h o r t L o n g Mod ulari ty H i g h L o w Reli abili ty H i g h L o w Time requir ed S tr ic t Soci abili ty GpiI-3A Organizing a Software Project 72 L a x H i g h X X X X X X X L o w X X X X X X X Controlled centralized X X X X X X X

73 Communication in the software project. Communicating in harmony In software development projects, the inability of people to communicate effectively with one another represents one of the more common obstacles to the achievement of: High product quality, and High productivity. GpiI-3A Organizing a Software Project 73

74 Hierarchical team organization Large projects often distinguish levels of management: Leaf nodes is where most development gets done; rest of tree is management Different levels do different kinds of work a good programmer may not be a good manager Status and rewards depend on your level in the organization Works well when projects have high degree of certainty, stability and repetition But tends to produce overly positive reports on project progress, e.g.: Bottom level: We are having severe trouble implementing module X. Level 1: There are some problems with module X. Level 2: Progress is steady; I do not foresee any real problems. Top: Everything is proceeding according to our plan.

75 Chief Programmer Team What do the graphics imply about this team structure? Chief programmer makes all important decisions Must be an expert analyst and architect, and a strong leader Assistant Chief Programmer can stand in for chief, if needed Librarian takes care of administration and documentation Additional developers have specialized roles Pros and cons of this team structure? Will you use this organization?

76 Matrix organization Organize people in terms of specialties Matrix of projects and specialist groups People from different departments allocated to software development, possibly part-time Pros and cons? Project structure may not match organizational structure Individuals have multiple bosses Difficult to control a project s progress