Unit 1_1_merged.pdf

UNIT 1 SOFTWARE PROJECT MANAGEMENT FRAME WORK Objectives After studying this unit, you will be able to: Explain the growing need for better project management, especially for information technology project. Describe what project management is and discuss key elements of the project management framework. Discuss how project management relates to other disciplines. Describe the umbrella activity of software project management. Describe the project management life cycle. Structure: 1.1 introduction 1.2 Project Attributes 1.3 Project Constraints: Time, Cost, Scope 1.4 Project Management 1.5 Project management function 1.6 Defining Software Project Management 1.7 Umbrella Activities under Software Project Management 1.8 The Role of the Software Project Manager 1.9 Project management life cycle 1.10 Keywords 1.11 Summary 1.1 INTRODUCTION Project management is defined as the application of knowledge, skills, tools, and techniques to project activities in order to meet project requirements. Project management is the discipline of defining and achieving a set of goals while optimizing the use of allocated resources (time, money, people, space, etc). This includes planning, scheduling and maintaining progress of the activities that comprise the project. Project management is normally reserved for focused, non-repetitive, time- limited activities with some degree of risk and that are beyond the usual scope of program (operational) activities for which the organization is responsible. Project management software describes the tools to efficiently coordinate and automate the various project management component processes. Project management software generally offers extensive reporting features, such as day-to- day status updates of project progress, scheduling and dependency trees, and system-generated alerts when schedules slip beyond pre-set tolerances. Most project management tools include web- accessible interfaces so that employees can access features of the software relevant to their needs, and functionality to allow managers to share resource pools without overbooking. Before to learn the activity of project management we must know what is project? A project, technically, is a temporary endeavor to create a unique product or service. For some people, everything is a project; for others, projects are special, lofty activities that occur infrequently. A project is a unique entity. In other words, the creation of a new application is unique, whereas the maintenance and day-to-day support of an existing application is not so unique. Project Definition: A project can be defined in many ways: A project― a temporary endeavor, undertaken to create a unique product, service, or result Operations, on the other hand, is work done in organizations, to sustain the business. Projects are different from operations in that they end when their objectives have been reached or the project has been terminated. A project is temporary. A project‘s duration might be just one week or it might go on for years, but every project has an end date. You might not know that end date when the project begins, but it‘s there somewhere in the future. Projects are not the same as ongoing operations, although the two have a great deal in common. A project is an endeavor. Resources, such as people and equipment, need to do work. The endeavor is undertaken by a team or an organization, and therefore projects have a sense of being intentional, planned events. Successful projects do not happen spontaneously; some amount of preparation and planning happens first. Finally, every project creates a unique product or service. This is the deliverable for the project and the reason, why that project was undertaken. 1.2 PROJECT ATTRIBUTES Projects come in all shapes and sizes. The following attributes help us to define a project further: A project has a unique purpose: Every project should have a well-defined objective. For example, many people hire firms to design and build a new house, but each house, like each person, is unique. Project is temporary: A project has a definite beginning and a definite end. For a home construction project, owners usually have a date in mind when they‘d like to move into their new homes. The end is reached when the project's objectives have been achieved, or it becomes clear that the project objectives will not or cannot be met, or the need for the project no longer exists and the project is terminated. Temporary does not necessarily mean short in duration; many projects last for several years. In every case, however, the duration of a project is finite; projects are not ongoing efforts. A project is developed using progressive elaboration or in an iterative fashion: Projects are often defined broadly when they begin, and as time passes, the specific details of the project become clearer. For example, there are many decisions that must be made in planning and building a new house. It works best to draft preliminary plans for owners to approve before more detailed plans are developed. A project requires resources, often from various areas: Resources include people, hardware, software, or other assets. Many different types of people, skill sets, and resources are needed to build a home. A project should have a primary customer or sponsor: Most projects have many interested parties or stakeholders, but someone must take the primary role of sponsorship. The project sponsor usually provides the direction and funding for the project. A project involves uncertainty: Because every project is unique, it is sometimes difficult to define the project‘s objectives clearly, estimate exactly how long it will take to complete, or determine how much it will cost. External factors also cause uncertainty, such as a supplier going out of business or a project team member needing unplanned time off. This uncertainty is one of the main reasons project management is so challenging. Product Service or Result: A product or artifact that is produced, is quantifiable and can be either an end item in itself or a component item ·A capability to perform a service, such as business functions supporting production or distribution A result, such as new knowledge. For example, a research and development project develops knowledge that can be used to determine whether or not a trend is present or a new process will benefit society 1.3 PROJECT CONSTRAINTS Like any human undertaking, projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as scope, time, and cost. These are also referred to as the Project Management Triangle, where each side represents a constraint. One side of the triangle cannot be changed without impacting the others. A further refinement of the constraints separates product 'quality' or 'performance' from scope, and turns quality into a fourth constraint. The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope. The discipline of project management is about providing the tools and techniques that enable the project team (not just the project manager) to organize their work to meet these constraints. Another approach to project management is to consider the three constraints as finance, time and human resources. If you need to finish a job in a shorter time, you can allocate more people at the problem, which in turn will raise the cost of the project, unless by doing this task quicker we will reduce costs elsewhere in the project by an equal amount. Time: For analytical purposes, the time required to produce a product or service is estimated using several techniques. One method is to identify tasks needed to produce the deliverables documented in a work breakdown structure or WBS. The work effort for each task is estimated and those estimates are rolled up into the final deliverable estimate. The tasks are also prioritized, dependencies between tasks are identified, and this information is documented in a project schedule. The dependencies between the tasks can affect the length of the overall project (dependency constraint), as can the availability of resources (resource constraint). Time is not considered a cost nor a resource since the project manager cannot control the rate at which it is expended. This makes it different from all other resources and cost categories. Cost: Cost to develop a project depends on several variables including: labor rates, material rates, risk management, plant (buildings, machines, etc.), equipment, and profit. When hiring an independent consultant for a project, cost will typically be determined by the consultant's or firms per diem rate multiplied by an estimated quantity for completion. Fig. 1.1 The Project management triangle Scope: Scope is requirement specified for the end result. The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish can be said to be the scope of the project. A major component of scope is the quality of the final product. The amount of time put into individual tasks determines the overall quality of the project. Some tasks may require a given amount of time to complete adequately, but given more time could be completed exceptionally. Over the course of a large project, quality can have a significant impact on time and cost or vice versa. Together, these three constraints viz. Scope, Schedule & Resources have given rise to the phrase "On Time, On Spec, On Budget". In this case, the term "scope" is substituted with "specification" 1.4 WHAT IS PROJECT MANAGEMENT Project management is ―the application of knowledge, skills, tools and techniques to project activities to meet the project requirements.‖ The effectiveness of project management is critical in assuring the success of any substantial activity. Areas of responsibility for the person handling the project include planning, control and implementation. A project should be initiated with a feasibility study, where a clear definition of the goals and ultimate benefits need to be determined. Senior managers' support for projects is important so as to ensure authority and direction throughout the project's progress and, also to ensure that the goals of the organization are effectively achieved in this process. Knowledge, skills, goals and personalities are the factors that need to be considered within project management. The project manager and his/her team should collectively possess the necessary and requisite interpersonal and technical skills to facilitate control over the various activities within the project. Projects normally involve the introduction of a new system of some kind and, in almost all cases, new methods and ways of doing things. This impacts the work of others: the "users". User interaction is an important factor in the success of projects and, indeed, the degree of user involvement can influence the extent of support for the project or its implementation plan. A project manager is the one who is responsible for establishing a communication in between the project team and the user. Thus one of the most essential qualities of the project manager are that of being a good communicator, not just within the project team itself, but with the rest of the organization and outside world as well. Features of projects: Projects are often carried out by a team of people who have been assembled for that specific purpose. The activities of this team may be coordinated by a project manager. Project teams may consist of people from different backgrounds and different parts of the organization. In some cases project teams may consist of people from different organizations. Project teams may be inter-disciplinary groups and are likely to lie outside the normal organization hierarchies. The project team will be responsible for delivery of the project end product to some sponsor within or outside the organization. The full benefit of any project will not become available until the project has been completed. Project Success Factors: The successful design, development, and implementation of information technology (IT) projects is a very difficult and complex process. However, although developing IT projects can be difficult, the reality is that a relatively small number of factors control the success or failure of every IT project, regardless of its size or complexity. The problem is not that the factors are unknown; it is that they seldom form an integral part of the IT development process. Some of the factors that influence projects and may help them succeed are: Executive Support User involvement Experienced project managers Limited scope Clear basic requirements Formal methodology Reliable estimates 1.5 PROJECT MANAGEMENT FUNCTION The functions of project management include: Defining what needs to be done in order to achieve project goals. Establishing the boundaries and extent of work. Determining, planning, estimating and allocating the resources required. Planning and implementing the work. Monitoring the progress of work Managing risk, adjusting and accommodating deviations from the plan. Key Objectives of Effective Management Project Management is generally seen as a key component of successful software projects. Together with software techniques it can produce software of high quality with following things S -pacific M -measurable A -assignable R -realistic T -time related Deliver successful software projects that support organization's strategic goals Match organizational needs to the most effective software development model Plan and manage projects at each stage of the software development life cycle (SDLC) Create project plans that address real-world management challenges Develop the skills for tracking and controlling software deliverables Also software development manager must keep in mind quality, productivity, and risk reduction throughout the planning and execution of product development is an outstanding overview of these concepts. Quality: Quality is best achieved by careful adherence to standards, effective development techniques, and periodic technical review throughout the process. Management must cooperate and coordinate with quality assurance organizations, if they exist continuous quality improvement and its remark able results offer important lessons for software for software. Productivity: Increased productivity lowers costs. In the current scenario of development technology, the most important productivity factors are the ability of the individual software engineers, the tools they. Work with, and the work environment. Risk reduction: Managers should identify the most difficult parts of a particular development and systematically come to grips with efficient solutions. Requirements that can become “show-stoppers” later must be dealt with early in the process. 1.6 DEFINING SOFTWARE PROJECT MANAGEMENT The software project management is defined as sub discipline of project management where we plan, control the project. Fig. 1.1 The Project management triangle illustrates the Project Management Framework. As depicted in the framework, stakeholders are the people involved or affected by project activities and include the project sponsor, project team, support staff, customers, users, supplies, and even opponents to the project. Fig. 1.2 Project Management frame work Framework in Fig. 1.2 Project Management frame work, there is 9 project management knowledge areas, which describe project management knowledge and practice in terms of their component processes. Fig. 1.2 Project Management frame work illustrates the overview of project management knowledge areas and project management processes. The four core knowledge areas are brieﬂy described below: discipline framework inTable 1, there is 9 project management knowledge areas, which describe project management knowledge and practice in terms of their component processes. Error! Reference source not found. illustrates in the table 1.1 the overview of project management knowledge areas and project management processes Table 1.1 Knowledge Area What It Does Project Scope Management Controlling the planning, execution, and content of the project is essential. You need to pay special attention to both project and product scope so that the software you end up with is what you intended to make in the first place. Project Time Management Managing everything that affects the project’s schedule is crucial Project Cost Management Projects cost money, and this knowledge area centers on cost estimating, budgeting, and control. Project Quality Management No project is a good project if the deliverable stinks. Quality doesn’t happen by accident, so this knowledge area works to ensure that the product you are producing is a quality product that meets customer expectations Project Human Resources Management The members of the project team must get their work done. Hiring or assigning people who are competent and managing them well are at the center of this knowledge area. Project Communications Management Project managers spend 90 percent of their time communicating. Communications management focuses on who needs what information and when. Project Risk Management This knowledge area is about avoiding doom. The focus is on how to anticipate risks, handle them when they arise, and take advantage of the opportunities that can help a project Knowledge Area What It Does Project Procurement Management Sometimes during the course of your software project, you may be required to work with vendors to purchase goods and/or services. You may even be the vendor that someone else is contracting for their project. This knowledge area is concerned with the processes to create vendor contracts and to purchase goods and services. Project Integration Management What happens in one knowledge area affects attributes of the other knowledge areas. The ninth knowledge area is fan-freakin-tastic because its purpose is to ensure the coordination of all the other knowledge areas. 1.7 UMBRELLA ACTIVITIES UNDER SOFTWARE PROJECT MANAGEMENT Umbrella Activities of Software Project Management is Software development process software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect, such as software tools. These processes exist primarily for supporting the management of software development. Many software development processes can be run in a similar way to general project management processes is as follows: Risk Management This is the process of measuring or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Risk management in software project management begins with the business case for starting the project, which includes a cost-benefit analysis as well as a list of fallback options for project failure, called a contingency plan. A subset of risk management that is gaining more and more attention is Opportunity Management, which means the same thing, except that the potential risk outcome will have a positive, rather than a negative impact. Though theoretically handled in the same way, using the term "opportunity" rather than the somewhat negative term "risk" helps to keep a team focused on possible positive outcomes of any given risk register in their projects, such as spin-off projects, windfalls, and free extra resources. Requirements Management This is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. New or altered computer system Requirements management, which includes Requirements analysis, is an important part of the software engineering process; whereby business analysts or software developers identify the needs or requirements of a Client; having identified these requirements they are then in a position to design a solution. Change Management This is the process of identifying, documenting, analyzing, prioritizing and agreeing on changes to scope (project management) and then controlling changes and communicating to relevant stakeholders. Change impact analysis of new or altered scope, which includes Requirements analysis at the change level, is an important part of the software engineering process; whereby business analysts or software developers identify the altered needs or requirements of a client; having identified these requirements they are then in a position to re-design or modify a solution. Theoretically, each change can impact the timeline and budget of a software project, and therefore by definition must include risk-benefit analysis before approval. Software Configuration Management The process of identifying, and documenting the scope itself, which is the software product underway, including all sub-products and changes and enabling communication of these to relevant stakeholders. In general, the processes employed include version control, naming convention (programming), and software archival agreements. Release Management The process of identifying, documenting, prioritizing and agreeing on releases of software and then controlling the release schedule and communicating to relevant stakeholders. Most software projects have access to three software environments to which software can be released; Development, Test, and Production. In very large projects, where distributed teams need to integrate their work before release to users, there will often be more environments for testing, called unit testing, system testing, or integration testing, before release to User acceptance testing (UAT). A subset of release management that is gaining more and more attention is Data Management, as obviously the users can only test based on data that they know, and "real" data is only in the software environment called "production". In order to test their work, programmers must therefore also often create "dummy data" or "data stubs". Traditionally, older versions of a production system were once used for this purpose, but as companies rely more and more on outside contributors for software development, company data may not be released to development teams. In complex environments, datasets may be created that are then migrated across test environments according to a test release schedule, much like the overall software release schedule. 1.8 THE ROLE OF THE SOFTWARE PROJECT MANAGER Why do so many professionals say they are project managing, when what they are actually doing is firefighting?" - Colin Bentley The project manager is accountable for ensuring that everyone on the team knows and executes his or her role, feels empowered and supported in the role, knows the roles of the other team members and acts upon the belief that those roles will be performed. The specific responsibilities of the Project Manager may vary depending on the industry, the company size, the company maturity, and the company culture. However, there are some responsibilities that are common to all Project Managers, noting. Developing the project plan. Project management excellence goes beyond producing project charters, detailed schedules and colorful status reports. Today's project managers must acquire the skills necessary to accept of modern challenges, factors such as downsizing, restricted finances, an accelerated business pace. Project manager is one, who looks into the application of knowledge, skills, tools, and techniques to describe, organize, oversee and control the various project processes, having said that, the roles and responsibilities of a project manager differ from company to company. It is important to understand what role a particular project manager will play in a certain company or organization. A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm he/she is representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality, and above all, client satisfaction, can be realized. When they are appointed, project managers should be given terms of reference that define their: Objectives Responsibilities Limits of authority Responsibilities of a Project Manager: The objective of every project manager is to deliver the product on time, within budget and with the required quality. Although the precise responsibilities of a project manager will vary from company to company and from project to project, they should always include planning and forecasting. Three additional areas of management responsibility are: interpersonal responsibilities, which include: leading the project team; liaising with initiators, senior management and suppliers; being the 'figurehead', i.e. setting the example to the project team and representing the project on formal occasions informational responsibilities, which include: Monitoring the performance of staff and the implementation of the project plan; disseminating information about tasks to the project team; disseminating information about project status to initiators and senior management; acting as the spokesman for the project team. Decisional responsibilities, which include: allocating resources according to the project plan, and adjusting those allocations when circumstances dictate (i.e. the project manager has responsibility for the budget);negotiating with the initiator about the optimum interpretation of contractual obligations, with the company management for resources, and with project staff about their tasks; handling disturbances to the smooth progress of the project such as equipment failures and personnel problems in short. Managing the project stakeholders. Managing the project team. Managing the project risk. Managing the project schedule. Managing the project budget. Managing the project conflicts. 1.9 PROJECT MANAGEMENT LIFE CYCLE The project lifecycle describes the tasks that must be completed to produce a software or service. Different project lifecycles exist for specific software and services. For example, the lifecycle followed to build a house is very different from the lifecycle followed to develop a software package. The project management lifecycle defines how to manage a project. It will always be same, regardless of the project lifecycle being employed. All projects, from your software creations to building the bridge over the River, pass through five process groups as defined by the Project Management Institute. A process group is a mini life cycle that moves the project one step closer to completion. Process groups are cycles because the processes don’t just happen once; they are repeated throughout the project as many times as needed. Figure 1.3demonstrates a sequence for process groups; the processes flow organically, in the order that best suits the needs of the project. Although we hope you don’t have to keep repeating some of these stages, if your project isn’t going according to plan you will have to do just that. All projects, software and otherwise, go through these project management processes. Fig. 1.3 Project Management Life Cycle Initiating: That’s really where you are now. The project is in the process of getting selected, sponsored, funded, and launched. Planning: As you can see in Figure 1.3, planning is an iterative process. Planning basically determines how the project work will get accomplished. Executing: After you get a plan, your project team does the work. Controlling: Your project team does the work, but you control them. Closing: Ah, paradise. After the project work has been completed, you tie up loose ends and close out the software project Project initiation: Initiation involves starting up the project, by documenting a business case, feasibility study, and terms of reference, appointing the team and setting up a Project Office. Considered; it hasn’t been officially launched. Projects get initiated to fulfill many different needs, some of which we’re sure you’ve experienced, and most of which can be addressed with software: A problem needs to be solved. An opportunity needs to be captured. A profit needs to be made. An existing environment needs to be improved. A process needs to be speeded up and/or made more efficient. At the initiation stage, the PM must make an effort to understand the reasons the project is necessary. Empathizing with the project customer (the person paying for the project) and the key stakeholders now can help you stay on track later. Knowing why the project is being created will help you ask the right questions to help the customer get to the desired solution. After you identify the need that the software project is engineered to answer, your need to deal with some mechanics of project management: Conducting a feasibility study: In formal project management a feasibility study examines the high- level goals of the project, the needed resources, and any other factors that could influence the project’s success. The point of a feasibility study is to determine whether this project can feasibly accomplish the time, cost, and scope objectives. Sometimes the project isn’t feasible and the idea is tanked, outsourced, sent back to the drawing board, or even broken down into multiple projects. Determining the project deliverable: If the project is deemed feasible, then a product description is created. The product description is an early rendition of the product scope. The product scope for most software projects consists of the design documents that detail the end result of the software project. In some instances, the product scope is very detailed — down to the color scheme, button fonts, and graphics. In other instances, the customer leaves the details to the project team, choosing instead to focus the product description on detailing the ideal functions of the software. Creating the project charter: A project charter is written by the person who has the authority within an organization to authorize the project to move forward. This individual has the positional power to authorize resources and funds. The outcome of the project initiation phase is as follows: The purpose of the project The business needs to be targeted and met The functionality of the software A description of what the project will deliver to the customer An understanding of the desired future state (what the organization will be like once the deliverable is in production) Planning the project: The second process group, the planning process, determines how the project will move forward after the project feasibility, description, and charter are complete. The planning process group gets the project rolling in a big way. Planning isn’t a one-time deal. Planning is an iterative (or repeated) process that happens as many times as it must throughout the project life cycle. You instinctively plan and restructure your plan all the time, stepping back, examining the problem, and then creating and refining the solution. The point of planning in software project management is to communicate exactly what you’ll be doing in the project. It’s a guide for all future project decisions. During the planning phase of your project, create a spreadsheet of mistakes and successes so that you can add information to it on an ongoing basis. The information you include in the spreadsheet can easily be translated later into a lessons learned document. After you create the template for the spreadsheet and share it with your team, be sure to make documenting lessons learned a regular agenda item for your team meetings. Project management planning methodologies: Rolling wave planning: Waves crest before they fall. The concept of the rolling wave approach is to crest with planning and then go do the work. You have several successions of planning and executing your plan. This is a fine approach in a software project. Scrum: You may have heard of the software project management approach of scrum, named after the rugby term for getting a ball into play. Scrum calls for quick, daily meetings with members of the project team. The focus of these meetings is simple. You identify what each team member has done so far, what team members will be doing today, and what issues need to be solved in the next week or so. Extreme programming: This software creation approach calls for rounds of planning, testing, team involvement, and execution. Communication and teamwork are paramount in this approach, which puts a primary focus on customer satisfaction. If you’re interested in learning more details about extreme programming, you may want to read extreme Programming in Action Executing the project: Execution, the third process group, is all about getting things done. You authorize the project work to begin and your project team goes about the business of designing, building, and testing the project’s creation. This is the meat of the project doing the work. In this process group, you’re also tackling some other key activities: Beginning your procurement activities, if needed Working with your organization’s quality assurance programs Communicating project information to appropriate stakeholders Managing project risk assessments Developing the project team Managing conflicts among the team and among stakeholders Controlling Phase: The executing process group’s twin process is controlling, which is the fourth process group. Controlling is all about ensuring the project is done according to plan. You control stuff quality, scope, budgets, the schedule, risks and you get to monitor performance. It’s fun, fun, fun. Don’t forget to document all these changes in performance so that you can write up a thorough lessons learned document later. The reason we relate controlling and executing is that they (more than all the other process groups) depend on each other. As your project team executes the project plan, you control the work by ensuring the quality is present as planned. You ensure that the costs are kept in check, and that the schedule is consistent, as planned. And if there’s trouble afoot, you go back to the planning process group. Closing the project: At some point, the project, like a bad date, has to come to its merciful end.(“See ya! Bye.”) The fifth process group, closing, for good project managers, involves lots of activities, including the following: Tying up loose financial ends: Doing your final math to see where the project stands financially, verifying the procurement documents, verifying the deliverables, and so on. Unveiling the product to the customer for final acceptance: When the customer is happy, he or she signs off on the project. Finalizing the project documentation: Final reports on the project team, including time spent on the project, final costs, and so on, need to be completed, as well as the lessons learned documentation. Finally, you can archive the project records, and if you’ve been working on gathering historical documentation all along, this part should go surprisingly smoothly Moving on: And then the project manager and the project team go on to other projects. Well, not yet. Don’t forget to celebrate with your project team for a job well done! 1.10 KEYWORDS SPM; Software project management, PDLC: project management life cycle UAT.: User acceptance testing 1.11 SUMMARY In this unit, we have looked into some fundamental concepts of Software project management. The requirement and scope of the software project management. All important process related to project management areas that are being used are explained. Brief discussion was provided on project management life cycle development methodologies. The concepts of project planning and control were introduced. The roles and responsibility of project management was also explained. UNIT 2 SOFTWARE RISK MANAGEMENT Objectives After studying this unit, you will be able to: Discuss what risk is and the importance of good project risk management. Discuss the elements involved in risk management planning list common sources of risks on information technology projects. Describe the risk identification process and tools and techniques to help identify Project risks. Discuss the qualitative risk analysis process and explain how to calculate risk factors. Structure 2.1 Introduction 2.2 Risk management process 2.3 Risk management planning 2.4 Common Sources of Risk for Information Technology Projects 2.5 Risk Management 2.6 Create a risk management plan 2.7 Keywords 2.8 Summary 2.1 INTRODUCTION Is risk management up to the task of improving outcomes in software projects? If you believe some of the industry surveys on project success rates you could be excused for being unsure. Software projects are high risk activities, generating variable performance outcomes Industry surveys suggest that only about a quarter of software projects succeed outright that is, they complete as scheduled, budgeted and speciﬁed ,and billions of dollars are lost annually through project failures or projects that do not deliver promised beneﬁts. Evidence suggests that this is a global issue, impacting private and public sector organizations alike. The promise of risk management in commercial software projects is that it can improve project outcomes. “What is risk management?” before that first we need to ask, “What is risk?” To define risk, we need to consider both the uncertainty of future outcomes and the utility or benefit of those outcomes. Risk combines both the uncertainty of outcomes and the utility or benefit of outcomes.risk management expecting about what might go wrong in project before it becomes a threat to successful completion and implementation of project involves the process of identifying evaluating and controlling the project. 2.2 RISK MANAGEMENT PROCESS Risk is defined as an event that has a probability of occurring, and could have either a positive or negative impact to a project should that risk occur. A risk may have one or more causes and, if it occurs, one or more impacts Risk management is an ongoing process that continues through the life of a project. It includes processes for risk management planning, identification, analysis, monitoring and control. Many of these processes are updated throughout the project lifecycle as new risks can be identified at any time. It’s the objective of risk management to decrease the probability and impact of events adverse to the project. On the other hand, any event that could have a positive impact should be exploited. Risk is inevitable in a business organization when undertaking projects. However, the project manager needs to ensure that risks are kept to a minimal. Risks can be mainly between two types; negative impact risk and positive impact risk. Not all the time would project managers be facing negative impact risks, as there are, positive impact risks also. Once the risk has been identified, project managers need to come up with a mitigation plan or any other solution to counter attack the risk. Overview of project risk management is as below: Fig. 2.1: Overview of risk management process Project risk management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives. All industries, especially the software development industry, tend to neglect the importance of project risk management. The general dictionary meaning of risk is possibility of loss or injury. Project risk involves understanding potential problems that might occur on the project and how they might impede project success. Risk management should be regarded as an investment, with costs associated. The benefit of the investment is to lessen the impact of potentially adverse events on a project. In any case, the cost for risk management should not exceed the potential Benefits. Risk utility or risk tolerance is the amount of satisfaction or pleasure received from a potential payoff. Depending on their attitude towards risk, people are divided into the following three categories: 1. Risk-averse: people who see utility rise at a decreasing rate of potential payoff. 2. Risk-seeking: people who see utility rise at an increasing rate of potential payoff. 3. Risk-neutral: people who achieve a balance between risk and payoff. There are six major processes included in project risk management: Risk management planning: involves deciding how to approach and plan the risk management activities for the project. Risk identification: involves determining which risks are likely to affect a project and documenting the characteristics of each. Qualitative risk analysis: involves characterizing and analyzing risks and prioritizing their effects on project objectives. Quantitative risk analysis: measuring the probability and consequences of risks and estimating their effects on project objectives. Risk response planning: involves taking steps to enhance opportunities and reduce threats to meeting project objectives. Risk monitoring and control: involves monitoring known risks, identifying new risks, reducing risks, and evaluating the effectiveness of risk reduction throughout the life of the project. Importance of Project Risk Management Project risk management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives. All industries, especially the software development industry, tend to neglect the importance of project risk management. A survey conducted by KPMG revealed that 55% of runaway projects did no risk management at all, 38% did some, and 7% did not know whether they did risk management or not.The general dictionary meaning of risk is possibility of loss or injury. Project risk involves understanding potential problems that might occur on the project and how they might impede project success. Risk management should be regarded as an investment, with costs associated. The benefit of the investment is to lessen the impact of potentially adverse events on a project. In any case, the cost for risk management should not exceed the potential benefits. Risk utility or risk tolerance is the amount of satisfaction or pleasure received from a potential payoff. 2.3 RISK MANAGEMENT PLANNING Risk Management Planning The main output of risk management planning is a risk management plan, which documents the procedures for managing risk throughout the project. A risk management plan summarizes the results of the risk identification, qualitative analysis, quantitative analysis, response planning, and monitoring and control processes. Risk management plan should address the following questions. Why is it important to take/not take this risk in relation to the project objectives? What is the specific risk, and what are the risk mitigation deliverables? What risk mitigation approach is to be used? Who are the individuals responsible for implementing the risk management plan? When will the milestones associated with the risk mitigation approach occur? How much is required in terms of resources to mitigate risk? The risk management plan can include the following contents: A methodology for risk management. Roles and responsibilities for activities involved in risk management. Budgets and schedules for the risk management activities. Descriptions of scoring and interpretation methods used for the qualitative and quantitative analysis of risk. Threshold criteria for risks. Reporting formats for risk management activities. A description of how the project team will track and document risk activities. In addition to a risk management plan, many projects also include the following items: Contingency plan: predefined actions that the project team will take if an identified risk event occurs. Fallback plan: developed for risks that have a high impact on meeting project. Objectives, and are put into effect if attempts to reduce risk are not effective. Contingency reserves or contingency allowance: provisions held by the project. Sponsor that can be used to mitigate cost or schedule risk if changes in project scope or quality occur. 2.4 COMMON SOURCES OF RISK FOR INFORMATION TECHNOLOGY PROJECTS Several studies have shown some common sources of risks on software development and information technology projects are as follows: Lack of user involvement Insufficient executive management support Clear statement of requirements Poor planning Unrealistic expectations Too few project milestones Lack of competent staff Unclear ownership Unclear visions and objectives Lack of hardworking, focused staff. Other broad categories of risk include: Market risk Financial risk Technology risk. People risk. Market risk: If the information technology project is to produce a new product or service will be it useful to the organization or marketable to others? Will user accept the product or service? Will someone else make a better product or service faster, making the project a waste of time and money? Financial risk: Can the organization afford to undertake the project?. How confident are the stakeholders in the financial projections? Will the project meet NPV, ROI, and payback estimates?. If not van the organization afford to proceed the project?. Is this project the best way to use the organization‘s financial resources? Technology risk: Is the project technically feasible? Will it use mature, leading edge or bleeding edge technologies? When will decisions be made on which technology to use? Will H/w, S/w and network function properly?. You can also breakdown the technology risk into h/w, s/w, and network technology if required. People risk: Does the organization have or can they find people with appropriate skills to complete the project successfully? Do they have enough experience?. Does senior management support the project? Is the organization familiar sponsor/customer for the project?. How good is the relationship with the sponsor/customer? 2.5 RISK MANAGEMENT LIFE CYCLE “What is risk management?” we need to ask, “What is risk?” To define risk, we need to consider both the uncertainty of future outcomes and the utility or benefit of those outcomes. Risk combines both the uncertainty of outcomes and the utility or benefit of outcomes.risk management expecting about what might go wrong in project before it becomes a threat to successful completion and implementation of project involves the process of identifying evaluating and controlling the project. Risk is defined as an event that has a probability of occurring, and could have either a positive or negative impact to a project should that risk occur. A risk may have one or more causes and, if it occurs, one or more impacts Risk management is an ongoing process that continues through the life of a project. It includes processes for risk management planning, identification, analysis, monitoring and control. Many of these processes are updated throughout the project lifecycle as new risks can be identified at any time. It’s the objective of risk management to decrease the probability and impact of events adverse to the project. On the other hand, any event that could have a positive impact should be exploited. Risk is inevitable in a business organization when undertaking projects. However, the project manager needs to ensure that risks are kept to a minimal. Risks can be mainly between two types; negative impact risk and positive impact risk. Not all the time would project managers be facing negative impact risks as there are positive impact risks too. Once the risk has been identified, project managers need to come up with a mitigation plan or any other solution to counter attack the risk. Purpose This plan documents the processes, tools and procedures that will be used to manage and control those events that could have a negative impact on the Project. It’s the controlling document for managing and controlling all project risks. This plan will address: Risk Identification Risk Assessment Risk Mitigation Risk Planning & Monitoring The working area of above five phases are shown in figure Fig. 2.2: Risk Management Risk Identification A risk is any event that could prevent the project from progressing as planned, or from successful completion. Risks can be identified from a number of different sources. Some may be quite obvious and will be identified prior to project kickoff. Others will be identified during the project lifecycle, and a risk can be identified by anyone associated with the project. Some risk will be inherent to the project itself, while others will be the result of external influences that are completely outside the control of the project team. The Project Manager has overall responsibility for managing project risk. Project team members may be assigned specific areas of responsibility for reporting to the project manager. Throughout all phases of the project, a specific topic of discussion will be risk identification. The intent is to instruct the project team in the need for risk awareness, identification, documentation and communication. Risk awareness requires that every project team member be aware of what constitutes a risk to the project, and being sensitive to specific events or factors that could potentially impact the project in a positive or negative way. Risk identification consists of determining which risks are likely to affect the project and documenting the characteristics of each. Risk communication involves bringing risk factors or events to the attention of the project manager and project team. The project manager will identify and document known risk factors during creation of the Risk Register. It is the project manager’s responsibility to assist the project team and other stakeholders with risk identification, and to document the known and potential risks in the Risk Register. Updates to the risk register will occur as risk factors change. The project team will discuss any new risk factors or events, and these will be reviewed with the project manager. The project manager will determine if any of the newly identified risk factors or events warrants further evaluation. Those that do will undergo risk quantification and risk response development, as appropriate, and the action item will be closed. Risk Assessment Risk assessment is the act of determining the probability that a risk will occur and the impact that event would have, should it occur. This is basically a “cause and effect” analysis. The “cause” is the event that might occur, while the “effect” is the potential impact to a project, should the event occur. Assessment of a risk involves two factors. First is the probability which is the measure of certainty that an event, or risk, will occur. This can be measured in a number of ways, but for the project will be assigned a probability as defined in the table below. Table 1 Definitio Meaning Value n Occurs frequently Frequent Will be continuously experienced unless action is 4 taken to change events Occur less frequently if process is corrected Issues identified with minimal audit activity Likely 5 Process performance failures evident to trained auditors or regulators. Unlikely to occur. The Seldom Minimal issue identification during focused 2 review Improbab Highly unlikely to occur 1 le fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for intangible assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is: rate (or probability) of occurrence multiplied by the impact of the event equals risk magnitude. Risk Planning & Monitoring Goal review Risk Risk monitor identification Risk Risk control analysis Risk plan Fig. 2.3: Risk Planning and Monitoring. Risk Mitigation Risk mitigation measures are usually formulated according to one or more of the following major risk options, which are: Once risks have been identified and assessed risks can be evaluated based on quantity. Project managers need to analyze the likely chances of a risk occurring with the help of a matrix. 4 Medium Critical 3 2 Probability Low High 1 1 2 3 4 Impact Fig. 2.4 Risk Mitigation Using the matrix, the project manager can categorize the risk into four categories as Low, Medium, High, and Critical. The probability of occurrence and the impact on the project are the two parameters used for placing the risk in the matrix categories. As an example, if a risk occurrence is low (probability = 2) and it has the highest impact (impact = 4), the risk can be categorized as 'High'. Risk Response When it comes to risk management, it depends on the project manager to choose strategies that will reduce the risk to minimal. Project managers can choose between the four risk response strategies which are outlined below. Risks can be avoided Reduction Sharing Retention Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not acceptable to the organization or person making the risk management decisions. Risk avoidance This includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the legal liability that comes with it. Another would be not flying in order not to take the risk that the airplane was to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits. Risk reduction Risk reduction or "optimization" involves reducing the severity of the loss or the likelihood of the loss from occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration. Outsourcing could be an example of risk reduction if the outsourcer can demonstrate higher capability at managing or reducing risks. For example, a company may outsource only its software development, the manufacturing of hard goods, or customer support needs to another company, while handling the business management itself. This way, the company can concentrate more on business development without having to worry as much about the manufacturing process, managing the development team, or finding a physical location for a call center. Risk sharing It is briefly defined as "sharing with another party the burden of loss or the benefit of gain, from a risk, and the measures to reduce a risk." The term of 'risk transfer' is often used in place of risk sharing in the mistaken belief that you can transfer a risk to a third party through insurance or outsourcing. In practice if the insurance company or contractor go bankrupt or end up in court, the original risk is likely to still revert to the first party. As such in the terminology of practitioners and scholars alike, the purchase of an insurance contract is often described as a "transfer of risk." However, technically speaking, the buyer of the contract generally retains legal responsibility for the losses "transferred", meaning that insurance may be described more accurately as a post-event compensatory mechanism. For example, a personal injuries insurance policy does not transfer the risk of a car accident to the insurance company. The risk still lies with the policy holder namely the person who has been in the accident. The insurance policy simply provides that if an accident (the event) occurs involving the policy holder then some compensation may be payable to the policy holder that is commensurate to the suffering/damage. Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group. Risk retention Involves accepting the loss, or benefit of gain, from a risk when it occurs. True self- insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War is an example since most property and risks are not insured against war, so the loss attributed by war is retained by the insured. Also any amount of potential loss (risk) over the amount insured is retained risk. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much. 2.6 CREATE RISK MANAGEMENT PLAN Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For instance, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks. The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions. According to, the stage immediately after completion of the risk assessment phase consists of preparing a Risk Treatment Plan, which should document the decisions about how each of the identified risks should be handled. Mitigation of risks often means selection of security controls, which should be documented in a Statement of Applicability, which identifies which particular control objectives and controls from the standard have been selected, and why. Risk analysis results and management plans should be updated periodically. There are two primary reasons for this: To evaluate whether the previously selected security controls are still applicable and effective To evaluate the possible risk level changes in the business environment. For example, Design a new business process with adequate built-in risk control and containment measures from the start. Periodically re-assess risks that are accepted in ongoing processes as a normal feature of business operations and modify mitigation measures. Transfer risks to an external agency (e.g. an insurance company) Avoid risks altogether (e.g. by closing down a particular high-risk business area) 2.7 KEYWORDS Risk Management: To manage a risk Risk identification: to identify risk in risk management process Risk quantification: try to minimize risk or remove risk Risk response : responding to the risk after applying the risk management plan 2.8 SUMMARY Risk Management is always forgotten when managing projects but the irony is that all projects have risk. People in general think that risk management is just a blaming session to uncover flaws in a particular project. This perception has to be abolished. Management and Project managers have to understand that Risk Management is the one of the few practical way to manage uncertainties and doubts towards a particular project. Risk can never be abolished, but can only be reduced to an acceptable level. Risk Management is a must for any projects and it has to be done from the initiation phase throughout the project lifecycle. Risk Management is not free, and it isn‘t cheap. There may need to have third party audits which incur cost. There must always be continual management support and commitment to ensure the success of projects. This chapter we discussed the importance of risk management in the projects and also were able to understand the different processes in the risk management, which consists of the following actions project risk management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives. Main processes include: Risk management planning Risk identification Qualitative risk analysis Risk response planning Risk monitoring and control Risk management planning Risk monitoring and control. UNIT 3 SOFTWARE COST ESTIMATION TECHNIQUE Objectives On successful completion of this unit, you will be able to: Describe the importance of good project cost management. Explain basic project cost management principles, concepts, and terms. Describe how resource planning relates directly to project cost management. Explain cost estimating using definitive, budgetary, and rough order of magnitude. Discuss the processes involved in cost budgeting and preparing a cost estimate for an information technology project. Structure 3.1 Introduction 3.2 Project cost management 3.3 Basic Principles of Cost Management 3.4 Resources planning 3.5 Cost estimating 3.6 Parametric models 3.7 Cost budgeting 3.8 Functional Point Analysis 3.9 Delphi Cost Model 3.10 Keywords 3.11 Summary 3.1 INTRODUCTION This unit provides an introduction on the constraint-project cost management. Important topics include basic project cost management, different cost estimation technique principles, concepts, and terms, resources planning, budgeting, project various methods and techniques are available for software project management. This Unit discusses some methods for the activities described in Unit 2 like: Project planning Project risk management Project development life cycle 3.2 PROJECT COST MANAGEMENT The objective of a process modeling method for cost management is to construct a model of the software process roles, responsibilities, activities, inputs and outputs. This is often referred to as the 'workflow'. Process models have been traditionally defined using text or simple diagrams. This model help to cost estimating, cost budgeting, cost control is as shown in figure 3.1. It provides an overview as to what processes, inputs, tools and techniques, and outputs project cost management Fig. 3.1: Project Cost Management Importance of Project Cost Management: Project cost can easily get out of control if no appropriate project cost management is in place. As revealed by 1995 CHAOS report (see the reference in Schwab’s text), the average cost overrun that is the additional percentage or dollar amount by which actual cost exceed estimates for information technology was 189% of their original estimates. Project cost management includes the processes required to ensure that a project team completes a project within an approved budget. Project cost management includes four main processes as follows: Resource planning: involves determining what resources, e.g., people, equipment, and materials, a project team should use to perform project activities and quantities of each resource. Cost estimating: involves developing an approximation or estimate of the costs of the resources needed to complete a project. Cost budgeting: involves allocating the overall cost estimate to individual work items to establish a baseline for measuring performance. Cost control: involves controlling changes to the project budget. 3.3 BASIC PRINCIPLES OF COST MANAGEMENT In order to perform effective project cost management, there are a few financial terms related to project cost management one needs to understand. Table 3.1 lists the financial terms that are of interest in this module. Table 3.1 Lists of the financial elements. Financial terms What is Cost Archives specific objective Profit Revenue minus expenses Profit margin Ratio between profit and revenue Costing Port cost for project Life cycle Port per cost Cash flow Method for determining estimating annual cost Benefit analysis those cost that organization can Tangible cost measure easily in dollar Those cost that organization cannot measure easily Intangible cost dollar 3.4 RESOURCE PLANNING Resource planning is a crucial part of project cost management. Physical resources for software projects include people, equipment, and materials. Labor costs constitute a large percentage of total project costs, so most projects involve many human resources. It is important and effective to solicit ideas from people involved in the project on cost-related issues at an early stage of the project. The major inputs to resource planning include a project’s work breakdown structure, scope statement, historical information, resource information, and policies. The main output of the resource planning processing is a list of resource requirements, including people, equipment, and materials. 3.5 COST ESTIMATING Accurate cost estimating is very important as it provides the basis for cost budgetingand cost control. Types of Cost Estimates The main outputs of project cost management are a cost estimate, supporting details and a cost management plan. There are three types of cost estimates namely as Rough order of magnitude (rom) estimate Budgetary estimate Definitive estimate All these three types of estimation used when, how and why are given in table 3.2 as shown in below. Table 3.2: Types of cost estimates Types of How Sr.No. When Done Why Done Estimate Accurate Rough order of Very earlier Provide estimate of cost 1 25%,+%75 magnitude In project life cycle For selection for decision Puts dollars in the 2 Budgetary Early 1-2 years out 10%,%25 budget plan Later in the Provides details for 3 Definitive project, less than purchase estimates actual 5%,10% 1 year cost Cost estimation tools, techniques and typical problems There are three basic cost estimating techniques, i.e., analogous estimates, bottom-up estimating, and parametric modeling. Table 3.3 lists the three techniques and their respective advantages and disadvantages Table 3.3: Three techniques for cost estimation S.No. Technique Description Advantage Disadvantage Also called top down estimates, use the actual 1 Analogous Less costly Less accurate cost of previous, similar project Involve estimating Time intensive Bottom up individual work items and Reasonably and therefore 2 estimating summing them to get a reliable expensive to project total develop Uses project characteristics Parametric Most More 3 in a mathematical model to modeling reliable complicated estimate project cost Some module are defined depending upon the above technique 3.6 PARAMETRIC MODELING For estimating software development costs, Constructive Cost Model (COCOMO), developedby Barry Boehm, is one popular parametric model that is based on parameters such as the source lines of code or function points. Function points are technology independent assessments of the functions involved in developing a system, e.g., the number of inputs and outputs, the number of files maintained, and the number of updates. COCOMO II is a newer version of COCOMO. Boehm proposed three levels of the model: COCOMO Model The basic COCOMO'81 model: It is a single-valued, static model that computes software development effort (and cost) as a function of program size expressed in estimated thousand delivered source instructions (KDSI). - Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs. - It does not account for differences in hardware constraints, personnel quality and experience. - It uses modern tools and techniques, and other project attributes known to have a significant influence on software costs, which limits its accuracy. The intermediate COCOMO'81 model: computes software development effort as a function of program size and a set of fifteen "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes. The advanced or detailed COCOMO'81 model incorporates all characteristics of the intermediate version with an assessment of the cost driver’s impact on each step (analysis, design, etc.) of the software engineering process. 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. Embedded Mode - Software projects that must be developed within a set of tight hardware, software, and operational constraints. - Requirement are rigid 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 below. Software project ab bb cb db Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32 Advantages of Cocomo'81: COCOMO is transparent, one can see how it works unlike other models such as SLIM Drivers are particularly helpful to the estimator to understand the impact of different factors that affect project costs Drawbacks of Cocomo'81 It is hard to accurately estimate KDSI early on in the project, when most effort estimates are required KDSI, actually, is not a size measure it is a length measure Extremely vulnerable to miss-classification of the development mode Success depends largely on tuning the model to the needs of the organization, Using historical data which is not always available Cost driver are not taking in to consideration COCOMO-II: The Scale Drivers In the COCOMO II model, some of the most important factors contributing to a project's duration and cost are the Scale Drivers. You set each Scale Driver to describe your project; these Scale Drivers determine the exponent used in the Effort Equation. COCOMO II provides three stage series of models for estimation of software projects: Application Composition Model: for earliest phases or spiral cycles [prototyping, and any other prototyping occurring later in the life cycle. Early Design Model: for next phases or spiral cycles. Involves exploration of architectural alternatives or incremental development strategies. Level of detail consistent with level of information available and the general level of estimation accuracy needed at this stage. Post-Architecture Model: once the project is ready to develop and sustain a fielded system it should have a life-cycle architecture, which provides more accurate information on cost driver inputs, and enables more accurate cost estimates Note: The Scale Drivers have replaced the Development Mode of COCOMO 81. The first two Scale Drivers, Precedentedness and Development Flexibility actually describe much the same influences that the original Development Mode did. Cost Drivers COCOMO II has 17 cost drivers ï¿½ you assess your project, development environment, and team to set each cost driver. The cost drivers are multiplicative factors that determine the effort required to complete your software project. For example, if your project will develop software that controls an airplane's flight, you would set the Required Software Reliability (RELY) cost driver to Very High. That rating corresponds to an effort multiplier of 1.26, meaning that your project will require 26% more effort than a typical software project. COCOMO II defines each of the cost drivers, and the Effort Multiplier associated with each rating. Check the Costar help for details about the definitions and how to set the cost drivers. COCOMO II Effort Equation The COCOMO II model makes its estimates of required effort (measured in Person-Months ï¿½ PM) based primarily on your estimate of the software project's size (as measured in thousands of SLOC, KSLOC)): Effort=2.94* EAF* (KSLOC)E Where, EAF Is the Effort Adjustment Factor derived from the Cost Drivers E Is an exponent derived from the five Scale Drivers COCOMO II Schedule Equation The COCOMO II schedule equation predicts the number of months required to complete your software project. 3.7 COST BUDGETING The main goal of the cost budgeting process is to prepare budgetary estimates and to produce a cost baseline for measuring project performance. Project cost budgeting involves allocating the project cost estimate to individual work items based on the work breakdown structure (WBS) of the project. It is typical for IT projects to have compensation costs as the largest part of cost estimates, because human resources are major costs for software projects. Human resources are usually measured by the number of full-time equivalent (FTE) staff (also referred to as headcount). A cost baseline, as the other important output of cost budgeting, is a time- phased budget that project managers use to measure and monitor cost performance. The cost baseline provides the foundation to project managers and top management - a foundation for project cost control. Cost Control: The main components, inputs and outputs of the project cost control are summarizedas follows: Includes: Monitoring cost performance, ensuring that only appropriate project changes are included in a revised cost baseline, and informing projects stakeholders of authorized changes to the project that will affect costs. Inputs: Cost baseline, performance reports, and cost management plan. Outputs: Revised cost estimates, budget updates, corrective action, revised estimates for project completion and lessons learned. The cost change control is part of the integrated change control system of the Project Integration Management described in unit 6. Performance measurement is another important tool for cost control. Earned value management (EVM) is the main costcontrol method used for measuring project performance. 3.8 FUNCTIONAL POINT ANALYSIS Function Point Analysis was developed first by Allan J. Albrecht in the mid- 1970s. It was an attempt to overcome difficulties associated with lines of code as a measure of software size, and to assist in developing a mechanism to predict effort associated with software development. The method was first published in 1979, then later in 1983. In 1984 Albrecht refined the method and since 1986, when the International Function Point User Group (IFPUG) was set up, several versions of the Function Point Counting Practices Manual have been published by IFPUG. Most practitioners of Function Point Analysis (FPA) will probably agree that there are three main objectives within the process of FPA: Measure software by quantifying the functionality requested by and provided to the customer. Measure software development and maintenance independently of technology used for implementation. Measure software development and maintenance consistently across all projects and organizations. One of the first questions I'm always asked is a logical one: "What is a function point?" Simply stated, function points are a standard unit of measure that represents the functional size of a software application. In the same way that a house is measured by the square feet it provides, the size of an application can be measured by the number of function points it delivers to the users of the application. A good example is when I had my house built two years ago. I worked with a very straightforward home builder and he basically said ``Al, you have two choices here. First, how many square feet do you want to build? Second, what quality of materials do you want to use?'' He continued ``let’s say that you want to build a house that is 2,000 square feet. If you want to use cheap materials we can build it for $80 per square feet. That's $160,000. If you want to go top of the line then you're looking at more like $110 per square foot, and that's $220,000. What would you like?'' FP practitioners look at a software application in terms of five standard functions. Five standard "functions" In counting FPs there are five standard "functions" that you count. The first two of these are called Data Functions, and last three are called Transaction Functions. The names of these functions are listed below. Data Functions: Internal logical files External interface files Transactional Functions: External Inputs External Outputs External Inquiries Using this terminology, when a person that counts FPs looks at a software system, they see something like this: The benefits of Function Point Analysis Now that you have a little understanding of what FPA is, we can discuss the important things that they bring to your overall software development process. From my experience, I've found that with a small amount of experience, understanding the functional size of your applications leads to a gold mine of other information that will help you run a successful software development business, including: The ability to accurately estimate: Project cost Project duration Project staffing size An understanding of other important metrics, such as: Project defect rate Cost per FP FP's per hour (what I refer to as ``velocity'') The productivity benefits of using new or different tools As an example of what FPs can do for you, my company can now tackle projects on a fixed-price basis, whereas in the last five years we've had only one other fixed price effort. This gives us a significant competitive advantage against our competition, because most people think it's impossible to develop software on a fixed price basis. To start at a high level, there are five steps in the process of counting FPs. They are: Determine the type of count. Identify the scope and boundary of the count. Determine the unadjusted FP count. Determine the Value Adjustment Factor. Calculate the Adjusted FP Count. I'll introduce steps 1, 2, 4, and 5 during our sample count, because they are most easily introduced by using an example. At this point I'll get into the heart of step 3 in our process, FP practitioners look at a software application in terms of five standard functions. Five standard "functions" In counting FPs there are five standard "functions" that you count. The first two of these are called Data Functions, and last three are called Transaction Functions. The names of these functions are listed below. Data Functions: - Internal logical files - External interface files Transactional Functions: - External Inputs - External Outputs - External Inquiries Using this terminology, when a person that counts FPs looks at a software system, they see something like this in figure 3.2: Fig. 3.2 Details on the Five Data and Transactional Functions This section provides more detailed information and definitions on the five Data and Transactional Functions. Before getting into the details of the five functions there are several terms that you need to understand, because they'll be used in each of the subsequent definitions. These are taken directly from the CPM.Since it is common for computer systems to interact with other computer systems, a boundary must be drawn around each system to be measured prior to classifying components. This boundary must be drawn according to the user’s point of view. In short, the boundary indicates the border between the project or application being measured and the external applications or user domain. Once the border has been established, components can be classified, ranked and tallied. External Inputs (EI) - is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files. The data can be either control information or business information. If the data is control information it does not have to update an internal logical file. The graphic represents a simple EI that updates 2 ILF's (internal logical file)(FTR's). Fig 3.3 External Inputs External Outputs (EO) - an elementary process in which derived data passes across the boundary from inside to outside. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications. These reports and files are created from one or more internal logical files and external interface file. The following graphic represents on EO with 2 FTR's there is derived information that has been derived from the ILF's. Fig. 3.4 External output External Inquiry (EQ) - an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files. The input process does not update any Internal Logical Files, and the output side does not contain derived data. The graphic below represents an EQ with two ILF's and no derived data. Fig. 3.5 Internal Logical Files Internal Logical Files (ILF’s) - a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through external inputs. External Interface Files (EIF’s) - a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The external interface file is an internal logical file for another application. The counts for each level of complexity for each type of component can be entered into a table such as the following one. Each count is multiplied by the numerical rating shown to determine the rated value. The rated values on each row are summed across the table, giving a total value for each type of component. These totals are then summed across the table, giving a total value for each type of component. These totals are then summoned down to arrive at the Total Number of Unadjusted Function Points. Table 4 Value for unadjusted factor Type of Complexity of Components Component Low Average High Total External Inputs _ x 3= _x4= _x6= External Outputs _ x 4= _x5= _x7= External Inquiries _x3= _x4= _x6= Internal Logical Files _x7= _ x 10 = _ x 15 = External Internal Files _x5= _x7= _ x 10 = Total Number of Unadjusted Function points Multiplied Value Adjustment Factor Total Adjusted Function Points The value adjustment factor (VAF) is based on 14 general system characteristics (GSC's) that rate the general functionality of the application being counted. Each characteristic has associated descriptions that help determine the degrees of influence of the characteristics. The degrees of influence range on a scale of zero to five. The ratings are: Scale Degree of Influence 0 Not present or no influence 1 Incidental influence 2 Moderate influences 3 Average influences 4 Significant influences 5 Strong influences throughout To compute FP the following relationship is used. FP=UFP*[0.65+0.01∑14 1 Fi] Where UFP is value of unadjusted factor Fi is (1 to 14) value of adjusted factor Benefits of Function Point Analysis: Can be used to size software applications accurately. Sizing is an important component in determining productivity (outputs/inputs). Can be an essential ingredient to measuring and managing scope creep. Can be the basis of creating estimating models, which can be explained, revised and accurate. Can be used with other metrics can help pinpoint opportunities for improvement. Can help improve communications with senior management. Can be counted by different people, at different times, to obtain the same measure within a reasonable margin of error. Are easily understood by the non-technical user. This helps communicate sizing information to a user or customer. 3.9 DELPHI COST MODEL The 'Delphi' method is a useful approach for arriving at software cost estimates the assumption of the Delphi method is that experts will independently converge on a good estimate. The method requires several cost estimation experts and acoordinator to direct the process. The basic steps are: The coordinator presents each expert with a specification and a form upon which to record estimates; The experts fill out forms anonymously, explaining their estimates (they may put questions to the coordinator, but should not discuss the problem with each other); If consensus has not been achieved, the coordinator prepares a summary of all the estimates and distributes them to the experts and the process repeats from step 1. The summary should just give the results, and not the reasoning behind the results. A common variation is to hold a review meeting after the first pass to discuss the independent estimates and arrive at a common estimate. 3.10 KEYWORDS 1. COCOMO- cost constructive model ,one of the cost model 2. UFP - value of unadjusted factor, used in functional point analysis 3. FP- Functional point , total points calculated by FPA Matrics 3.11 SUMMARY At the end of this unit we come to know awareness about the importance of software estimation. How we estimate the cost of the project. We have seen various estimation models. What are the international standards for software estimation we learnt About the cost budgeting, cost control, types of cost estimation, resources planning for cost estimation UNIT 4 SOFTWARE TIME ESTIMATION TECHNIQUE Objectives: After studying this unit, you will be able to: State the importance of project schedules and good project time management. Define activities as the basis for developing project schedules. Describe how project managers use network diagrams and dependencies to assist in activity sequencing. Explain how various tools and techniques help project managers perform activity. For, Duration estimating and schedule development: Use a Gantt chart for schedule planning and tracking schedule information use critical path analysis describe how to use several techniques for shortening project schedules Explain the basic concepts behind critical chain scheduling and Program. For, Review Technique (PERT): Discuss how reality checks and people issues are involved in controlling and managing changes to the project schedule Describe how software can assist in project time management. Structure 4.1 Introduction 4.2 Organizing Information Before You Build a Timeline 4.3 Work break

Unit 1_1_merged.pdf

Document Details

Tags

Related

Full Transcript

Upgrade to continue