THE MANAGEMENT SPECTRUM

1. THE MANAGEMENT SPECTRUM • Effective software project management focuses on the four P’s: people, product, process, and project. • The People • “every organization needs to continually improve its ability to attract, develop, motivate, organize, and retain the workforce needed to accomplish its strategic business objectives”. • The people capability maturity model defines the following key practice areas for software people: staffing, communication and coordination, work environment, performance management, training, compensation, competency analysis and development, career development, workgroup development, team/culture development, and others. • Organizations that achieve high levels of People-CMM maturity have a higher likelihood of implementing effective software project management practices. • The People-CMM is a companion to the Software Capability Maturity Model–Integration that guides organizations in the creation of a mature

2. 2. The Product • Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. • Without this information, it is impossible to define reasonable(and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress. • Once the product objectives and scope are understood, alternative solutions are considered. the alternatives enable managers and practitioners to select a “best” approach. 3. The process • software process provides the framework from which a comprehensive plan for software development can be established. A small number of framework activities are applicable to all software projects, regardless of their size or complexity.

3. A number of different task sets—tasks, milestones, work products, and quality assurance points—enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. • Finally, umbrella activities—such as software quality assurance, software configuration management, and measurement—overlay the process model • Umbrella activities are independent of any one framework activity and occur throughout the process. 4. The Project • We conduct planned and controlled software projects for one primary reason—it is the only known way to manage complexity. • To avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring, and controlling the project.

4. PEOPLE • The Software Team • Mantei suggests three generic team organizations: • Democratic decentralized (DD) • This software engineering team has no permanent leader. Rather, "task coordinators are appointed for short durations and then replaced by others who may coordinate different tasks." • Decisions on problems and approach are made by group consensus. Communication among team members is horizontal. • Controlled decentralized (CD) • This software engineering team has a defined leader who coordinates specific tasks and secondary leaders that have responsibility for subtasks. • Problem solving remains a group activity, but implementation of solutions is partitioned among subgroups by the team leader. • Communication among subgroups and individuals is horizontal. Vertical communication along the control hierarchy also occurs.

5. Controlled Centralized (CC) • Top-level problem solving and internal team coordination are managed by a team leader. • Communication between the leader and team members is vertical. - -Mantei describes seven project factors that should be considered when planning the structure of software engineering teams: • 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.

6. The Stakeholders -The software process is populated by stakeholders who can be categorized into one of five constituencies: • Senior managers - who define the business issues that often have a significant influence on the project. 2. Project (technical) managers - who must plan, motivate, organize, and control the practitioners who do software work. 3. Practitioners - who deliver the technical skills that are necessary to engineer a product or application. 4. Customers -who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. 5. End users - who interact with the software once it is released for production use.

7. Team Leaders - MOI model of leadership: • Motivation - The ability to encourage (by “push or pull”) technical people to produce to their best ability. 2. Organization. - The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. 3. Ideas or innovation. • The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. • Another view of the characteristics that define an effective project manager emphasizes four key traits: • Problem solving. - An effective software project manager can diagnose the technical and organizational issues that are most relevant, systematically structure a solution or properly motivate other practitioners to develop the solution, apply lessons learned from past projects to new situations, and

8. -remain flexible enough to change direction if initial attempts at problem solution are fruitless. • Managerial identity. - A good project manager must take charge of the project. She must have the confidence to assume control when necessary and the assurance to allow good technical people to follow their instincts. • Achievement. -A competent manager must reward initiative and accomplishment to optimize the productivity of a project team. She must demonstrate through her own actions that controlled risk taking will not be punished. • Influence and team building. - An effective project manager must be ableto “read” people; she must be able to understand verbal and nonverbal signals and react to the needs of the people sending these signals. The managermust remain under control in high-stress situations.

9. Coordination and Communication Issues • The scale of many development efforts is large, leading to complexity, confusion, and significant difficulties in coordinating team members. • Uncertainty is common, resulting in a continuing stream of changes that ratchets the project team. • Interoperability has become a key characteristic of many systems. New software must communicate with existing software and conform to predefined constraints imposed by the system or product. - Kraul and Streeter [KRA95] examine a collection of project coordination techniques that are categorized in the following manner: • Formal, impersonal approaches • include software engineering documents and deliverables (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation , error tracking reports, and repository data . • Formal, interpersonal procedures -focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections. • Informal, interpersonal procedures -include group meetings for information dissemination and problem solving and “collocation of requirements and development staff.”

10. Electronic communication -encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. • Interpersonal networking -includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members.

12. CRITICAL PRACTICES • These practices are “consistently used by, and considered critical by, highly successful software projects and organizations whose ‘bottom line’ performance is consistently much better than industry averages”. • In an effort to enable a software organization to determine whether a specific project has implemented critical practices, the Airlie Council has developed a set of “QuickLook” questions for a project- • Formal risk management. -What are the top ten risks for this project? For each of the risks, what is the chance that the risk will become a problem and what is the impact if it does? • Empirical cost and schedule estimation. • What is the current estimated size of the application software (excluding system software) that will be delivered into operation? How was it derived?. • Metric-based project management. - Do you have in place a metrics program to give an early indication of evolving problems? If so, what is the current requirements volatility?

13. Earned value tracking. -Do you report monthly earned value metrics? If so, are these metrics computed from an activity network of tasks for the entire effort to the next delivery? • Defect tracking against quality targets. - Do you track and periodically report the number of defects found by each inspection (formal technical review) and execution test from program inception and the number of defects currently closed and open? • People-aware program management. -What is the average staff turnover for the past three months for each of the suppliers/developers involved in the development of software for this system?

14. Estimation for software project • 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. • These estimates are made within a limited time frame at the beginning of a software project and should be updated regularly as the project progresses. • Estimates should attempt to define best case and worst case scenarios. • SOFTWARE SCOPE -Software scope describes the data and control to be processed, function, performance,constraints, interfaces, and reliability. Functions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. - analyst start by asking context-free questions; that is, a set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution desired, and the effectiveness of the first encounter itself.

15. Feasibility • Can we build software to meet this scope? Is the project feasible?” • not everything imaginable is feasible, not even in software, • software feasibility has four solid dimensions: Technology— • Is a project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application’s needs? • Finance—Is it financially feasible? Can development be completed at a cost the software organization, its client, or the market can afford? • Time—Will the project’s time-to-market beat the competition? • Resources—Does the organization have the resources needed to succeed? • A Scoping Example Conveyor Line Sorting System (CLSS).

17. - The project planner examines the statement of scope and extracts all important software functions. This process, called decomposition, and results in the following functions: • Read bar code input. • Read pulse tachometer. • Decode part code data. • Do database look-up. • Determine bin location. • Produce control signal for shunt. • Maintain record of box destinations.

18. RESOURCES • three major categories of software engineering resources— 1.People 2. reusable software components 3.development environment (hardware and software tools) • Human Resources • The planner begins by evaluating software scope and selecting the skills required to complete development. • Both organizational position (e.g., manager, senior software engineer) and specialty (e.g., telecommunications, database, client-server) are specified. • For relatively small projects (a few person-months), a single individual may perform all software engineering tasks, consulting with specialists as required. For larger projects, the software team may be geographically dispersed across a number of different locations. • location of each human resource is specified. • The number of people required for a software project can be determined only after an estimate of development effort (e.g., person-months) is made.

19. 2. Reusable Software Resources • Component-based software engineering (CBSE)4 emphasizes reusability—that is, the creation and reuse of software building blocks. Such building blocks, often called components. • Off-the-shelf components. Existing software that can be acquired from a third party or from a past project. • COTS (commercial off-the-shelf) components are purchased from a third party, are ready for use on the current project, and have been fully validated. • Full-experience components. Existing specifications, designs, code, or test data developed for past projects that are similar to the software to be built for the current project. • Members of the current software team have had full experience in the application area represented by these components. Therefore, modifications required for full-experience components will be relatively low risk. • Partial-experience components. Existing specifications, designs, code, or test data developed for past projects that are related to the software to be built for the current project but will require substantial modification. Members of the current software team have only limited experience in the application area represented by these components. Therefore, modifications required for partial-experience components have a fair degree of risk. • New components. Software components must be built by the software team specifically for the needs of the current project.

20. 3. Environmental Resources • The environment that supports a software project, often called the software engineering environment (SEE), incorporates hardware and software. • Hardware provides a platform that supports the tools (software) required to produce the work products that are an outcome of good software engineering practice. Because most software organizations have multiple constituencies that require access to the SEE, you must prescribe the time window required for hardware and software and verify that these resources will be available. • When a computer-based system (incorporating specialized hardware and software) is to be engineered, the software team may require access to hardware elements being developed by other engineering teams. • For example, software for a robotic device used within a manufacturing cell may require a specific robot (e.g., a robotic welder) as part of the validation test step; a software project for advanced page layout may need a high-speed digital printing system at some point during development. Each hardware element must be specified as part of planning.

21. SOFTWARE PROJECT ESTIMATION To achieve reliable cost and effort estimates, a number of options arise: • Delay estimation until late in the project (obviously, we can achieve 100% accurate estimates after the project is complete!). • Base estimates on similar projects that have already been completed. • Use relatively simple decomposition techniques to generate project cost and effort estimates. • Use one or more empirical models for software cost and effort estimation.

22. SOFTWARE PROJECT ESTIMATION • DECOMPOSITION TECHNIQUES • decompose the problem, recharacterizing it as a set of smaller problems. • Software Sizing • size refers to a quantifiable outcome of the software project. If a direct approach is taken, size can be measured in lines of code (LOC). If an indirect approach is chosen, size is represented as function points (FP). • Putnam and Myers [Put92] suggest four different approaches to the sizing problem: • “Fuzzy logic” sizing. - This approach uses the approximate reasoning techniques that are the cornerstone of fuzzy logic. To apply this approach, the planner must identify the type of application, establish its magnitude on a qualitative scale, and then refine the magnitude within the original range. • Function point sizing. • Standard component sizing. - Software is composed of a number of different“standard components” that are generic to a particular application area.

23. For example, the standard components for an information system are subsystems, modules, screens, reports, interactive programs, batch programs, files, LOC, and object-level instructions. -The project planner estimates the number of occurrences of each standard component and then uses historical project data to estimate the delivered size per standard component. • Change sizing. - This approach is used when a project encompasses the use of existing software that must be modified in some way as part of a project. The planner estimates the number and type (e.g., reuse, adding code, changing code, deleting code) of modifications that must be accomplished.

24. Problem-Based Estimation • An Example of LOC-Based Estimation • An Example of FP-Based Estimation -The organizational average productivity for systems of this type is 6.5 FP/pm. Based on a burdened labor rate of $8000 per month, the cost per FP is approximately $1230. - Based on the FP estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months.

26. Process-Based Estimation • process is decomposed into a relatively small set of tasks and the effort required to accomplish each task is estimated. • begins with a delineation of software functions obtained from the project scope. A series of framework activities must be performed for each function. • Functions and related framework activities may be represented as part of a table similar to the one presented in Figure.

27. Estimation with Use Cases -Unlike an LOC or a function point, one person’s “use case” may require months of effort while another person’s use case may be implemented in a day or two. -Although a number of investigators have considered use cases as an estimation input, no proven estimation method has emerged to date.

28. Reconciling Estimates - reevaluation of information used to make the estimates. Widely divergent estimates can often be traced to one of two causes: (1) the scope of the project is not adequately understood or has been misinterpreted by the planner, or (2) productivity data used for problem-based estimation techniques is inappropriate for the application, obsolete (in that it no longer accurately reflects the software engineering organization), or has been misapplied. You should determine the cause of divergence and then reconcile the estimates.

29. EMPIRICAL ESTIMATION MODELS • no estimation model is appropriate for all classes of software and in all development environments. Therefore, you should use the results obtained from such models judiciously. • An estimation model should be calibrated to reflect local conditions. • The model should be tested by applying data collected from completed projects, plugging the data into the model, and then comparing actual to predicted results. • If agreement is poor, the model must be tuned and retested before it can be used. • The Structure of Estimation Models • A typical estimation model is derived using regression analysis on data collected from past software projects. • The overall structure of such models takes the form - E =A + B * (ev)C • where A, B, and C are empirically derived constants, E is effort in person-months, and ev is the estimation variable (either LOC or FP).

30. Among the many LOC-oriented estimation models proposed in the literature are

31. COCOMO May be applied to three classes of s/w projects using Boehm terminology these are • Organic Mode • Semi-Detached Mode • Embedded Mode The basic COCOMO equation takes the form E=ab(KLOC)bb D=cb(E)db

32. The COCOMO II Model • Barry Boehm introduced a hierarchy of software estimation models bearing the name COCOMO, for COnstructive COst MOdel. • The original COCOMO model became one of the most widely used and discussed software cost estimation models in the industry. • It has evolved into a more comprehensive estimation model, calledCOCOMO- II. • COCOMO II models require sizing information. Three different sizing options are available as part of the model hierarchy: object points, function points, and lines of source code. • object point is an indirect software measure that is computed using counts of the number of (1) screens (at the user interface), (2) reports, and (3) components likely to be required to build the application. Each object instance (e.g., a screen or report) is classified into one of three complexity levels (i.e., simple, medium, or difficult) using criteria suggested by Boehm

33. The Software Equation

34. Putnam and Myers suggest a set of equations derived from the software equation.Minimum development time is defined as

36. THE MAKE/BUY DECISION • In many software application areas, it is often more cost effective to acquire rather than develop computer software. • Software engineering managers are faced with a make/buy decision that can be further complicated by a number of acquisition options: • software may be purchased (or licensed) off-the-shelf, • (2) “full-experience” or “partial-experience” software 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. • Creating a Decision Tree • Figure depicts a decision tree for a softwarebased system X. In this case, the software engineering organization can (1) build system X from scratch, (2) reuse existing partial-experience components to construct the system, (3) buy an available software product and modify it to meet local needs, or (4) contract the software development to an outside vendor.

38. Based on the probability and projected costs that have been noted in Figure 26.8, the lowest expected cost is the “buy” option. expected cost = (path probability)i x (estimated path cost)i where i is the decision tree path. For the build path, expected costbuild = 0.30 ($380K) + 0.70 ($450K) = $429K expected costreuse=? expected costbuy=? expected costcontract=?

39. Project Scheduling • Task set for Software project • Software project scheduling is an action that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. • It is important to note, however, that the schedule evolves over time. • During early stages of project planning, a macroscopic schedule is developed. This type of schedule identifies all major process framework 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. Here, specific software actions and tasks (required to accomplish an activity) are identified and scheduled. • Basic Principles

40. Compartmentalization. -The project must be compartmentalized into a number of manageable activities and tasks. To accomplish compartmentalization, both the product and the process are refined. • 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. Other activities can occur independently. • 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 and whether work will be conducted on a full-time or part-time basis. • Effort validation. Every project has a defined number of people on the software team. As time allocation occurs, you must ensure that no more than the allocated number of people has been scheduled at any given time. For example, consider a project that has three assigned software engineers (e.g., three person-days are available per day of assigned effort). On a given day, seven concurrent tasks must be accomplished. Each task requires 0.50 person-days of effort. More effort has been allocated than there are people to do the work.

41. 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 (e.g., the design of a component) or a part of a work product. Work products are often combined in deliverables. • Defined milestones. Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved. • Each of these principles is applied as the project schedule evolves.

42. A TASK SET FOR THE SOFTWARE PROJECT • a software team performs is achieved through a set of tasks that enable you to define, develop, and ultimately support computer software. No single task set is appropriate for all projects. • The set of tasks that would be appropriate for a large, complex system would likely be perceived as overkill for a small, relatively simple software product. Therefore, an effective software process should define a collection of task sets, each designed to meet the needs of different types of projects. • In order to develop a project schedule, a task set must be distributed on the project time line. • The task set will vary depending upon the project type and the degree of rigor with which the software team decides to do its work. • most software organizations encounter the following projects:

43. 1. Concept development projects that are initiated to explore some new business concept or application of some new technology. 2. New application development projects that are undertaken as a consequence of a specific customer request. 3. Application enhancement projects that occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end user. 4. Application maintenance projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end user. 5. Reengineering projects that are undertaken with the intent of rebuilding an existing (legacy) system in whole or in part.

44. A Task Set Example - Concept development projects are approached by applying the following actions: 1.1 Concept scoping determines the overall scope of the project. 1.2 Preliminary concept planning establishes the organization’s ability to undertake the work implied by the project scope. 1.3 Technology risk assessment evaluates the risk associated with the technology to be implemented as part of the project scope. 1.4 Proof of concept demonstrates the viability of a new technology in the software context. 1.5 Concept implementation implements the concept representation in a manner that can be reviewed by a customer and is used for “marketing” purposes when a concept must be sold to other customers or management. 1.6 Customer reaction to the concept solicits feedback on a new technology concept and targets specific customer applications.

45. Defining a task network • task network, also called an activity network, is a graphic representation of the task flow for a project. • It is sometimes used as the mechanism through which task sequence and dependencies are input to an automated project scheduling tool. • In its simplest form (used when creating a macroscopic schedule), the task network depicts major software engineering actions. • Figure 27.2 shows a schematic task network for a concept development project.

46. Scheduling Project scheduling methods • Program evaluation and review technique (PERT) • critical path method (CPM) Both PERT and CPM provide quantitative tools that allow the software planner to • determine the critical path • establish “most likely” time estimates • calculate “boundary times” • Time-Line Charts - a time-line chart, also called a Gantt chart, is generated. A time-line 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.

47. Timeline Charts

49. EARNED VALUE ANALYSIS • The earned value system provides a common value scale for every [software project] task, regardless of the type of work being performed. 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. • It enables you to assess the “percent of completeness” of a project using quantitative analysis rather than rely on a gut feeling. • “provides accurate and reliable readings of performance from as early as 15 percent into the project.” To determine the earned value, the following steps are performed: 1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. During estimation, the work (in person-hours or person-days) of each software engineering task is planned. - Hence, BCWSi is the effort planned for work task i. To determine progress at a given point along the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule.

50. 2. The BCWS values for all work tasks are summed to derive the budget at completion (BAC). Hence, BAC (BCWSk) for all tasks k 3. Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule. -Given values for BCWS, BAC, and BCWP, important progress indicators can be computed: -Schedule performance index, SPI= BCWP/ BCWS -Schedule variance, SV =BCWP- BCWS. - SPI is an indication of the efficiency with which the project is utilizing scheduled resources. An SPI value close to 1.0 indicates efficient execution of the project schedule. -SV is simply an absolute indication of variance from the planned schedule. Percent complete =BCWP/BAC