MCA641 CU-MCA-SEM-IV-Software_Project_Management_26-10-20 Modified-converted-converted

UNIVEESITY INSTITUTE OF Discover. Learn. Empower. DISTANCE & ONLINE LEARNING SOFTWARE PROJECT NANAGEMENT

MASTER OF COMPUTER APPLICATIONS SEMESTER-IV SOFTWARE PROJECT MANAGEMENT MCA64 1 CU IDOL SELF LEARNING MATERIAL (SLM)

CHANDIGARH UNIVERSITY Institute of Distance and Online Learning Course Development Committee Prof. (Dr.) R.S.Bawa Pro Chancellor, Chandigarh University, Gharuan, Punjab Advisors Prof. (Dr.) Bharat Bhushan, Director – IGNOU Prof. (Dr.) Majulika Srivastava, Director – CIQA, IGNOU Programme Coordinators & Editing Team Master of Business Administration (MBA) Bachelor of Business Administration (BBA) Coordinator – Dr. Rupali Arora Coordinator – Dr. Simran Jewandah Master of Computer Applications (MCA) Bachelor of Computer Applications (BCA) Coordinator – Dr. Raju Kumar Coordinator – Dr. Manisha Malhotra Master of Commerce (M.Com.) Bachelor of Commerce (B.Com.) Coordinator – Dr. Aman Jindal Coordinator – Dr. Minakshi Garg Master of Arts (Psychology) Bachelor of Science (Travel &Tourism Management) Coordinator – Dr. Samerjeet Kaur Coordinator – Dr. Shikha Sharma Master of Arts (English) Bachelor of Arts (General) Coordinator – Dr. Ashita Chadha Coordinator – Ms. Neeraj Gohlan Academic and Administrative Management Prof. (Dr.) R. M. Bhagat Prof. (Dr.) S.S. Sehgal Executive Director – Sciences Registrar Prof. (Dr.) Manaswini Acharya Prof. (Dr.) Gurpreet Singh Executive Director – Liberal Arts Director – IDOL © No part of this publication should be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording and/or otherwise without the prior written permission of the authors and the publisher. SLM SPECIALLY PREPARED FOR CU IDOL STUDENTS Printed and Published by: TeamLease Edtech Limited www.teamleaseedtech.com CONTACT NO:- 01133002345 For: CHANDIGARH UNIVERSITY 2 Institute of Distance and Online Learning CU IDOL SELF LEARNING MATERIAL (SLM)

3 CU IDOL SELF LEARNING MATERIAL (SLM)

First Published in 2020 All rights reserved. No Part of this book may be reproduced or transmitted, in any form or by any means, without permission in writing from Chandigarh University. Any person who does any unauthorized act in relation to this book may be liable to criminal prosecution and civil claims for damages. This book is meant for educational and learning purpose. The authors of the book has/have taken all reasonable care to ensure that the contents of the book do not violate any existing copyright or other intellectual property rights of any person in any manner whatsoever. In the even the Authors has/ have been unable to track any source and if any copyright has been inadvertently infringed, please notify the publisher in writing for corrective action. 3 CU IDOL SELF LEARNING MATERIAL (SLM)

CONTENT Unit 1- Project Management Framework ..................................................................................4 Unit 2- Risk Management ........................................................................................................21 Unit 3- Software Project Estimation........................................................................................34 Unit 4- Project Management Tools & Techniques ..................................................................54 Unit 5- Software Quality Management....................................................................................70 Unit 6- Software Testing..........................................................................................................78 Unit 7- Configuration Management.........................................................................................91 Unit 8- Software Team Management 1..................................................................................106 Unit 9- Software Team Management 2..................................................................................114 Unit 10: ROLE of User in Projects ........................................................................................127 3 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 1- PROJECT MANAGEMENT FRAMEWORK Structure Learning Objective Introduction Overview of Project Management, Definition of a Project Project Characteristics Project Attributes The Process of Project Management Project Organization Planning Factors In Designing A Project Structure: S/W Project management life cycle Project Planning Scope Management Project Estimation Summary Keywords Learning Activity Unit End Questions References 1. 0 LEARNING OBJECTIVES After studying this unit, you should be able to • Explain the concept of Project Management and how it’s a systematic approach of defining, planning, strategizing, communicating, and controlling a project. • Recognize the Project Organization and its planning function • Comprehend Software Project Management Life Cycle INTRODUCTION The need for project management has been driven by businesses that have realized the benefits of organizing work around projects and the crucial need to communicate and coordinate work across departments and professions. Let’s understand the project- A project is generally initiated by a perceived need in an organization. Being a one off undertaking, it will have a start and an end, constraints of budgets, time and resources and involves a purpose built team. Project teams are made up of many different team members, for example, end users/customers (of a product or service), representatives from Information Technology (IT), a project leader, business analysts, trainers, the project sponsor and other stakeholders. 4 CU IDOL SELF LEARNING MATERIAL (SLM)

Project management is the discipline of managing all the different resources and aspects of the project in such a way that the resources will deliver all the output that is required to complete the project within the defined scope, time, and cost constraints. Software project management refers to the branch of project management dedicated to the planning, scheduling, resource allocation, execution, tracking and delivery of software and web projects. Project management in software engineering is distinct from traditional project management in that software projects have a unique lifecycle process that requires multiple rounds of testing, updating, and customer feedback. Most IT-related projects are managed in the agile style, in order to keep up with the increasing pace of business, and iterate based on customer and stakeholder feedback. OVERVIEW OF PROJECT MANAGEMENT The starting point in discussing how projects should be properly managed is to first understand what a project is and, just as importantly, what it is not. People have been undertaking projects since the earliest days of organized human activity. The hunting parties of our prehistoric ancestors were projects, for example; they were temporary undertakings directed at the goal of obtaining meat for the community. Large complex projects have also been with us for a long time. The pyramids and the Great Wall of China were in their day of roughly the same dimensions as the Apollo project to send men to the moon. We use the term “project” frequently in our daily conversations. A husband, for example may tell his wife, “My main project for this weekend is to straighten out the garage.” Going hunting, building pyramids, and fixing faucets all share certain features that make them projects. Definition of a Project There are many written definitions of a project. All of them contain the key elements described above. For those looking for a formal definition of a project, the Project Management Institute (PMI) defines a project as a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates a definite beginning and end. The end is reached when the project’s objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists. Project management is the application of processes, methods, skills, knowledge and experience to achieve specific project objectives according to the project acceptance criteria within agreed parameters. Project management has final deliverables that are constrained to a finite timescale and budget. A key factor that distinguishes project management from just 'management' is that it has this final deliverable and a finite timespan, unlike management which is an ongoing process. Because of this a project professional needs a wide range of skills; often technical skills, and certainly people management skills and good business awareness. 5 CU IDOL SELF LEARNING MATERIAL (SLM)

Project Characteristics When considering whether or not you have a project on your hands, there are some things to keep in mind. First, is it a project or an ongoing operation? Second, if it is a project, who are the stakeholders? And third, what characteristics distinguish this endeavor as a project? Projects have several characteristics: • Projects are unique. • Projects are temporary in nature and have a definite beginning and ending date. • Projects are completed when the project goals are achieved or it’s determined the project is no longer viable. A successful project is one that meets or exceeds the expectations of the stakeholders. Consider the following scenario: The vice-president (VP) of marketing approaches you with a fabulous idea. (Obviously it must be “fabulous” because he thought of it.) He wants to set up kiosks in local grocery stores as mini-offices. These offices will offer customers the ability to sign up for car and home insurance services as well as make their bill payments. He believes that the exposure in grocery stores will increase awareness of the company’s offerings. He told you that senior management has already cleared the project, and he’ll dedicate as many resources to this as he can. He wants the new kiosks in place in 12 selected stores in a major city by the end of the year. Finally, he has assigned you to head up this project. Your first question should be, “Is it a project?” This may seem elementary, but confusing projects with ongoing operations happens often. Projects are temporary in nature, have definite start and end dates, result in the creation of a unique product or service, and are completed when their goals and objectives have been met and signed off by the stakeholders. Using these criteria, let’s examine the assignment from the VP of marketing to determine if it is a project: • Is it unique? Yes, because the kiosks don’t exist in the local grocery stores. This is a new way of offering the company’s services to its customer base. While the service the company is offering isn’t new, the way it is presenting its services is. • Does the product have a limited timeframe? Yes, the start date of this project is today, and the end date is the end of next year. It is a temporary endeavor. • Is there a way to determine when the project is completed? Yes, the kiosks will be installed and the services will be offered from them. Once all the kiosks are installed and operating, the project will come to a close. • Is there a way to determine stakeholder satisfaction? Yes, the expectations of the stakeholders will be documented in the form of requirements during the planning processes. These requirements will be compared to the finished product to determine if it meets the expectations of the stakeholder. If the answer is yes to all these questions, then we have a project. Project Attributes 6 CU IDOL SELF LEARNING MATERIAL (SLM)

A project has distinctive attributes that distinguish it from ongoing work or business operations. Projects are temporary in nature. They are not an everyday business process and have definitive start dates and end dates. This characteristic is important because a large part of the project effort is dedicated to ensuring that the project is completed at the appointed time. To do this, schedules are created showing when tasks should begin and end. Projects can last minutes, hours, days, weeks, months, or years. Projects exist to bring about a product or service that hasn’t existed before. In this sense, a project is unique. Unique means that this is new; this has never been done before. Maybe it’s been done in a very similar fashion before but never exactly in this way. For example, Ford Motor Company is in the business of designing and assembling cars. Each model that Ford designs and produces can be considered a project. The models differ from each other in their features and are marketed to people with various needs. An SUV serves a different purpose and clientele than a luxury car. The design and marketing of these two models are unique projects. However, the actual assembly of the cars is considered an operation (i.e., a repetitive process that is followed for most makes and models). In contrast with projects, operations are ongoing and repetitive. They involve work that is continuous without an ending date and with the same processes repeated to produce the same results. The purpose of operations is to keep the organization functioning while the purpose of a project is to meet its goals and conclude. Therefore, operations are ongoing while projects are unique and temporary. A project is completed when its goals and objectives are accomplished. It is these goals that drive the project, and all the planning and implementation efforts undertaken to achieve them. Sometimes projects end when it is determined that the goals and objectives cannot be accomplished or when the product or service of the project is no longer needed and the project is cancelled. The Following are the attributes of Project: a. Time frame: Because a project is a temporary endeavor, it must have a definite beginning and end. Many projects begin on a specific date and the date of completion is estimated. Some project has an immovable date when the project must be completed. b. Purpose: An IT Project can produce any number of results such as a system, a software package, or a recommendation based on a study. Therefore a project’s goal must be to produce something tangible and of value to the organization. A Project must have a goal to drive the project in terms of defining the work to be done. c. Ownership: The project must provide something of value to an individual or group who will own the project product after it is completed. Determining who owns this project is not always easy. For example, different groups may fight over the does and does not own the system, the data, the support, and the final cost of implementing and maintaining thesystem. d. Resources: IT project require time, money, people, and technology. Resources provide the means for achieving a project’s goal and also act as a constraint. For example, the project’s scope, or work to be accomplished is determined directly by the project’s goal. If project 7 CU IDOL SELF LEARNING MATERIAL (SLM)

sponsor asks that an additional feature to be added to the system, however, this will required additional resources in terms of more work on the part of project team. e. Roles: IT Projects require different individuals with different skills set, they are listed below. 1. Project Manager: She/he is responsible for ensuring that all of the project management and technical development processes are in place and being carried out properly. 2. Project sponsor: The project sponsor may be the client, customer, or organizational resources manager who will act as champion for the project. 3. Subject matter experts: The subject matter expert may be user or client who has specific knowledge, expertise, or insight in a specific functional area. 4. Technical Expert: Technical expert is needed to provide a technical solution to organization problems. • Risks and Assumptions: All projects have an element risk. Risk can arise from many sources, both and external and internal to the project team. For example, internal risk may arise from estimation process. On other hand, external risk may arise due to dependencies on other contractors or vendors. • Interdependent Tasks: Project work requires many interdependent tasks. For example, a network cannot an installed until the hardware is delivered. Or certain requirements cannot be incorporated into design until key user is interviewed. • Organizational Change: Project is planned organizational change. Change must be understood and managed because implementation of the IT project will change the ways people work. • Operating in an Environment Larger than the project itself: Organization chooses projects for a number of reasons, and the projects chosen can impact the organization. The Process of Project Management The five main project management processes in detail. 1 - Project Initiation Project initiation is the starting point of any project. In this process, all the activities related to winning a project takes place. Usually, the main activity of this phase is the pre-sale. During the pre-sale period, the service provider proves the eligibility and ability of completing the project to the client and eventually wins the business. Then, it is the detailed requirements gathering which comes next. During the requirements gathering activity, all the client requirements are gathered and analyzed for implementation. In this activity, negotiations may take place to change certain requirements or remove certain requirements altogether. Usually, project initiation process ends with requirements sign-off. 2 - Project Planning 8 CU IDOL SELF LEARNING MATERIAL (SLM)

Project planning is one of the main project management processes. If the project management team gets this step wrong, there could be heavy negative consequences during the next phases of the project. Therefore, the project management team will have to pay detailed attention to this process of the project. In this process, the project plan is derived in order to address the project requirements such as, requirements scope, budget and timelines. Once the project plan is derived, then the project schedule is developed. Depending on the budget and the schedule, the resources are then allocated to the project. This phase is the most important phase when it comes to project cost and effort. 3 - Project Execution After all paperwork is done, in this phase, the project management executes the project in order to achieve project objectives. When it comes to execution, each member of the team carries out their own assignments within the given deadline for each activity. The detailed project schedule will be used for tracking the project progress. During the project execution, there are many reporting activities to be done. The senior management of the company will require daily or weekly status updates on the project progress. In addition to that, the client may also want to track the progress of the project. During the project execution, it is a must to track the effort and cost of the project in order to determine whether the project is progressing in the right direction or not. In addition to reporting, there are multiple deliveries to be made during the project execution. Usually, project deliveries are not onetime deliveries made at the end of the project. Instead, the deliveries are scattered throughout the project execution period and delivered upon agreed timelines. 4 - Control and Validation During the project life cycle, the project activities should be thoroughly controlled and validated. The controlling can be mainly done by adhering to the initial protocols such as project plan, quality assurance test plan and communication plan for the project. Sometimes, there can be instances that are not covered by such protocols. In such cases, the project manager should use adequate and necessary measurements in order to control such situations. Validation is a supporting activity that runs from first day to the last day of a project. Each and every activity and delivery should have its own validation criteria in order to verify the successful outcome or the successful completion. When it comes to project deliveries and requirements, a separate team called 'quality assurance team' will assist the project team for validation and verification functions. 5 - Closeout and Evaluation 9 CU IDOL SELF LEARNING MATERIAL (SLM)

Once all the project requirements are achieved, it is time to hand over the implemented system and closeout the project. If the project deliveries are in par with the acceptance criteria defined by the client, the project will be duly accepted and paid by the customer. Once the project closeout takes place, it is time to evaluate the entire project. In this evaluation, the mistakes made by the project team will be identified and will take necessary steps to avoid them in the future projects. During the project evaluation process, the service provider may notice that they haven't gained the expected margins for the project and may have exceeded the timelines planned at the beginning. In such cases, the project is not a 100% success to the service provider. Therefore, such instances should be studied carefully and should take necessary actions to avoid in the future. On any project, you will have a number of project constraints that are competing for your attention. They are cost, scope, quality, risk, resources, and time. • Cost is the budget approved for the project including all necessary expenses needed to deliver the project. Within organizations, project managers have to balance between not running out of money and not underspending because many projects receive funds or grants that have contract clauses with a “use it or lose it” approach to project funds. Poorly executed budget plans can result in a last-minute rush to spend the allocated funds. For virtually all projects, cost is ultimately a limiting constraint; few projects can go over budget without eventually requiring a corrective action. • Scope is what the project is trying to achieve. It entails all the work involved in delivering the project outcomes and the processes used to produce them. It is the reason and the purpose of the project. • Quality is a combination of the standards and criteria to which the project’s products must be delivered for them to perform effectively. The product must perform to provide the functionality expected, solve the identified problem, and deliver the benefit and value expected. It must also meet other performance requirements, or service levels, such as availability, reliability, and maintainability, and have acceptable finish and polish. Quality on a project is controlled through quality assurance (QA), which is the process of evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards. • Risk is defined by potential external events that will have a negative impact on your project if they occur. Risk refers to the combination of the probability the event will occur and the impact on the project if the event occurs. If the combination of the probability of the occurrence and the impact on the project is too high, you should identify the potential event as a risk and put a proactive plan in place to manage the risk. • Resources are required to carry out the project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition (usually other than labour) required for the completion of a project activity. 10 CU IDOL SELF LEARNING MATERIAL (SLM)

• Time is defined as the time to complete the project. Time is often the most frequent project oversight in developing projects. This is reflected in missed deadlines and incomplete deliverables. Proper control of the schedule requires the careful identification of tasks to be performed and accurate estimations of their durations, the sequence in which they are going to be done, and how people and other resources are to be allocated. Any schedule should take into account vacations and holidays. You may have heard of the term “triple constraint,” which traditionally consisted of only time, cost, and scope. These are the primary competing project constraints that you have to be most aware of. The triple constraint is illustrated in the form of a triangle to visualize the project work and see the relationship between the scope/quality, schedule/time, and cost/resource (Figure 1.1). In this triangle, each side represents one of the constraints (or related constraints) wherein any changes to any one side cause a change in the other sides. The best projects have a perfectly balanced triangle. Maintaining this balance is difficult because projects are prone to change. For example, if scope increases, cost and time may increase disproportionately. Alternatively, if the amount of money you have for your project decreases, you may be able to do as much, but your time may increase. Figure 1.1: A schematic of the triple constraint triangle. Your project may have additional constraints that you must face, and as the project manager, you have to balance the needs of these constraints against the needs of the stakeholders and your project goals. For instance, if your sponsor wants to add functionality to the original scope, you will very likely need more money to finish the project, or if they cut the budget, you will have to reduce the quality of your scope, and if you don’t get the appropriate resources to work on your project tasks, you will have to extend your schedule because the resources you have taken much longer to finish the work. The constraints are all dependent on each other. PROJECT ORGANIZATION PLANNING A project organization is a structure that facilitates the coordination and implementation of project activities. Its main reason is to create an environment that fosters interactions among 11 CU IDOL SELF LEARNING MATERIAL (SLM)

the team members with a minimum amount of disruptions, overlaps and conflict. One of the important decisions of project management is the form of organizational structure that will be used for the project. Each project has its unique characteristics and the design of an organizational structure should consider the organizational environment, the project characteristics in which it will operate, and the level of authority the project manager is given. A project structure can take on various forms with each form having its own advantages and disadvantages. One of the main objectives of the structure is to reduce uncertainty and confusion that typically occurs at the project initiation phase. The structure defines the relationships among members of the project management and the relationships with the external environment. The structure defines the authority by means of a graphical illustration called an organization chart. A properly designed project organization chart is essential to project success. An organization chart shows where each person is placed in the project structure. An organization chart is drawn in pyramid form where individuals located closer to the top of the pyramid have more authority and responsibility than members located toward the bottom. It is the relative locations of the individuals on the organization chart that specifies the working relationships, and the lines connecting the boxes designate formal supervision and lines of communication between the individuals. Fig 1.2 Project Organization Chart Creating the project structure is only a part of organizing the project; it is the actual implementation and application that takes the most effort. The project organization chart establishes the formal relationships among project manager, the project team members, the development organization, the project, beneficiaries and other project stakeholders. This organization must facilitate an effective interaction and integration among all the major project participants and achieve open and effective communication among them. The project manager must create a project structure that will meet the various project needs at different 12 CU IDOL SELF LEARNING MATERIAL (SLM)

phases of the project. The structure cannot be designed too rigid or too lose, since the project organization's purpose is to facilitate the interaction of people to achieve the project ultimate goals within the specified constraints of scope, schedule, budget and quality. The objective in designing a project structure is to provide a formal environment that the project manager can use to influence team members to do their best in completing their assignment and duties. The structure needs to be designed to help develop collaboration among individual team members; all in a cost effective way with a minimum of duplication of effort and overlaps. The organization chart has a limited functionality; it only shows the hierarchical relationship among the team members but does not shows how the project organization will work, it is for that reason that the design should consider factors that will facilitate the operation of the structure; these include communications, information flows, coordination and collaboration among its members. Factors In Designing A Project Structure: There are two design factors that significantly influence the process of developing a project management structure. These are the level of specialization and the need for coordination. The project manager should consider these factors at the moment of designing the project organization in order to maximize the effectiveness of the structure. Specialization affects the project structure by the degree of specialty in technical areas or development focus; projects can be highly specialized and focus on a specific area of development, or have different broad specializations in many areas of development. For large projects that have multiple specializations or technical areas, each area may have a different need; from differences in goals, approaches and methodologies, all of which influence the way the project will implement its activities. A project that has two components, a reconstruction and education, will need to manage different approaches based on the specialization of each one. In the education component, the needs is for a structure more open and informal, where the time horizon is longer, with more emphasis on sharing and generation of new ideas in order to achieve innovation and creativity. In a reconstruction component, there are specific goals, a need for a rigid, hierarchical structure, and there is a defined time horizon with little sharing of ideas. While specialization allows each project component to maximize their productivity to attain their departmental goals, the dissimilarities may lead to conflict among the members or leads of each component. In general, the greater the differences, the more problems project managers have in getting them to work together. Coordination is required to bring unity to the various elements that make up a project. The project work is organized around a work breakdown structure (WBS) that divides the overall project goals into specific activities or tasks for each project area or component; the project manager must design an organizational structure that ensure that the various components are integrated so that their efforts contribute to the overall project goal. Integration is the degree of collaboration and mutual understanding required among the 13 CU IDOL SELF LEARNING MATERIAL (SLM)

various project components to achieve project goals. Most projects are characterized by the division of labor and task interdependencies, creating the need for integration to meet project objectives. This need is greatest when there are many project components that have different specializations. The goal of the project management structure is the achievement of harmony of individual efforts toward the accomplishment of the group goals. The project manager's principal responsibility is to develop integrating strategies to ensure that a particular component or activity is organized in a way that all of the components, parts, subsystems, and organizational units fit together as a functioning, integrated whole according to the project master plan. S/W PROJECT MANAGEMENT LIFE CYCLE The software project management life cycle is usually broken down into four phases: initiation, planning, execution, and closure. These phases make up the path that takes your project from the beginning to the end. Fig 1.4: Phases of Software Project Management Life Cycle 1. Initiation First, you need to identify a business need, problem, or opportunity and brainstorm ways that your team can meet this need, solve this problem, or seize this opportunity. During this step, 14 CU IDOL SELF LEARNING MATERIAL (SLM)

you figure out an objective for your project, determine whether the project is feasible, and identify the major deliverables for the project. Instead of waiting to have the project strategy decided for you, Moira Alexander advocates for a mental switch from being a project \"manager\" to becoming a project \"leader\": \"Project managers must be able to sell business leaders on the intrinsic value they offer to the business at a strategic level when they are at the table from the start of strategic planning instead of after the fact decision-making. Project managers effectiveness is drastically muted when offering a \"fix-it\" or \"workaround\" once high-level directional business decisions are made without their expertise.\" Clearly, it's worth it to do what it takes to make your voice heard early—before the strategy is set in stone. Project management steps for the initiation phase Steps for the project initiation phase may include the following: • Undertaking a feasibility study: Identify the primary problem your project will solve and whether your project will deliver a solution to that problem • Identifying scope: Define the depth and breadth of the project • Identifying deliverables: Define the product or service to provide • Identifying project stakeholders: Figure out whom the project affects and what their needs may be • Developing a business case: Use the above criteria to compare the potential costs and benefits for the project to determine if it moves forward • Developing a statement of work: Document the project’s objectives, scope, and deliverables that you have identified previously as a working agreement between the project owner and those working on the project 2. Planning Once the project is approved to move forward based on your business case, statement of work, or project initiation document, you move into the planning phase. During this phase of the project management life cycle, you break down the larger project into smaller tasks, build your team, and prepare a schedule for the completion of assignments. Create smaller goals within the larger project, making sure each is achievable within the time frame. Smaller goals should have a high potential for success. Project management steps for the planning phase Steps for the project planning phase may include the following: 15 CU IDOL SELF LEARNING MATERIAL (SLM)

• Creating a project plan: Identify the project timeline, including the phases of the project, the tasks to be performed, and possible constraints • Creating workflow diagrams: Visualize your processes using swim lanes to makesure team members clearly understand their role in a project • Estimating budget and creating a financial plan: Use cost estimates to determine how much to spend on the project to get the maximum return on investment • Gathering resources: Build your functional team from internal and external talent pools while making sure everyone has the necessary tools (software, hardware, etc.) to complete their tasks • Anticipating risks and potential quality roadblocks: Identify issues that may cause your project to stall while planning to mitigate those risks and maintain theproject’s quality and timeline • Holding a project kickoff meeting: Bring your team on board and outline the project so they can quickly get to work 3. Execution You’ve received business approval, developed a plan, and built your team. Now it’s time to get to work. The execution phase turns your plan into action. The project manager’s job in this phase of the project management life cycle is to keep work on track, organize team members, manage timelines, and make sure the work is done according to the original plan. Project management steps for the execution phase Steps for the project execution phase may include the following: • Creating tasks and organizing workflows: Assign granular aspects of the projects to the appropriate team members, making sure team members are not overworked • Briefing team members on tasks: Explain tasks to team members, providing necessary guidance on how they should be completed, and organizing process-related training if necessary • Communicating with team members, clients, and upper management: Provide updates to project stakeholders at all levels • Monitoring quality of work: Ensure that team members are meeting their time and quality goals for tasks • Managing budget: Monitor spending and keeping the project on track in terms of assets and resources 16 CU IDOL SELF LEARNING MATERIAL (SLM)

If you have a properly documented process already in place, executing the project will be much easier. 4. Closure Once your team has completed work on a project, you enter the closure phase. In the closure phase, you provide final deliverables, release project resources, and determine the success of the project. Just because the major project work is over, that doesn’t mean the project manager’s job is done—there are still important things to do, including evaluating what did and did not work with the project. Project management steps for the closure phase Steps for the project closure phase may include the following: • Analyzing project performance: Determine whether the project's goals were met (tasks completed, on time and on budget) and the initial problem solved using a prepared checklist. • Analyzing team performance: Evaluate how team members performed, including whether they met their goals along with timeliness and quality of work • Documenting project closure: Make sure that all aspects of the project are completed with no loose ends remaining and providing reports to key stakeholders • Conducting post-implementation reviews: Conduct a final analysis of the project, taking into account lessons learned for similar projects in the future • Accounting for used and unused budget: Allocate remaining resources for future projects Summary • A project can be defined as a temporary endeavour undertaken to accomplish a unique product, services or results. • Project Management: Project management is the applications of knowledge, skills, tools and techniques to project activities to meet project requirements. The planning and organization of an organization's resources in order to move a specific task, event or duty toward completion. Project management typically involves a one-time project rather than an ongoing activity, and resources managed include both human and financial capital • Projects have several characteristics: • Projects are unique. • Projects are temporary in nature and have a definite beginning and ending date. 17 CU IDOL SELF LEARNING MATERIAL (SLM)

• Projects are completed when the project goals are achieved or it’s determined the project is no longer viable. • Project Attributes: A project has distinctive attributes that distinguish it from ongoing work or business operations. Projects are temporary in nature. The attributes of project are – time frame, purpose, ownership, resources, roles, risks and assumptions, interdependent tasks, Organizational Change, Operating in an Environment Larger than the project itself. • A project organization is a structure that facilitates the coordination and implementation of project activities. • Factors in designing a project structure: Level of specialization and the need for coordination • The software project management life cycle is usually broken down into four phases: initiation, planning, execution, and closure. These phases make up the path that takes your project from the beginning to the end. Keywords • Effort Estimation: Personnel requirement and man-hour required to produce the software • Time Estimation: the time required to produce the software • Kilo Line of Code: KLOC is a measure of the size of a computer program. The size is determined by measuring the number of lines of source code a program has • Scope of Software Project: defines the scope of project; this includes all the activities, process need to be done in order to make a deliverable software product. • Innovation: a new method, idea, product, etc. LEARNING ACTIVITY 1. Prepare a project report on any current issue. 2. Differentiate between Project Management and Software Project Management. UNIT END QUESTIONS 18 A. Descriptive Type Questions 1. Explain the concept of Project Estimation. CU IDOL SELF LEARNING MATERIAL (SLM)

2. Illustrate the Software Project management life cycle in details. 3. What is Project Management? What should be the role of Project Manager that can be easily implied from Project Attributes? 4. Illustrate the factors in designing a project structure. 5. Project Management needs totake care of support Functions. Write a note on Project Organization highlighting the support functions necessary for smooth operations. B. Multiple Choice Question 1. Which of the following is not project management goal? a) Keeping overall costs within budget b) Delivering the software to the customer at the agreed time c) Maintaining a happy and well-functioning development team d) Avoiding customer complaints 2. Which of the following is not considered as a risk in project management? a) Specification delays b) Product competition c) Testing d) Staff turnover 3. The process each manager follows during the life of a project is known as a) Project Management b) Manager life cycle c) Project Management Life Cycle d) All of the mentioned 4. Which of the following is/are main parameters that you should use when computing the costs of a software development project? a) travel and training costs b) hardware and software costs c) effort costs (the costs of paying software engineers and managers) d) all of the mentioned 5. involves anticipating risks that might affect the project schedule or the quality of the software being developed, and then taking action to avoid these risks a) Risk Management b) Planning c) Scheduling’ d) Delivery 19 CU IDOL SELF LEARNING MATERIAL (SLM)

Answers: 1 -d; 2 -c; 3 -c; 4 -d; 5- a REFERENCES • Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition Sixth Edition, Sixth edition, Project Management Institute • Bob Hughes, Mike Cotterell and Rajib Mall, ‘Software Project Management’- Tata McGrawHill. • Bennatan E. (1994).Software Project Management.London: McGraw-Hill. • Anna P. Murray, The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond , Wiley • Terry T. Kidd , Handbook of Research on Technology Project Management, Planning, and Operations (Advances in IT Personnel and Project Management), Information Science Reference • Eric Verzuh, The Fast Forward MBA in Project Management, Wiley • Harold Kerzner , Project Management: A Systems Approach to Planning, Scheduling, and Controlling 11th Edition, Wiley • G. L. Rexing, \"Software project management: Moving beyond project plans,\" in AT&T Technical Journal, vol. 70, no. 2, pp. 40-48, March-April 1991. • Marcelo Marinho , Suzana Sampaio , Telma Lima and Hermano de Moura, “A SYSTEMATIC REVIEW OF UNCERTAINTIES IN SOFTWARE PROJECT MANAGEMENT”, in International Journal of Software Engineering & Applications (IJSEA), Vol.5, No.6, November 2014. 20 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 2- RISK MANAGEMENT Structure Learning Objective Introduction Identification of Risks Risk Analysis Benefits of risk analysis Steps in risk analysis process Qualitative vs. Quantitative risk analysis Software Risk Planning Software Risk Monitoring Summary Keywords Learning Activity Unit End Questions References LEARNING OBJECTIVES After studying this unit, you should be able to - • Explain the concept of risk and its need to identify. • Outline the method for Risk Analysis • Incorporate the concept of Risk Planning & Monitoring. INTRODUCTION Every project has risks—uncertain events or conditions that, if they occur, have a positive or negative effect on one or more of the project objectives. So, the purpose of project risk management is \"to increase the probability and/or impact of the opportunities and decrease the probability and/or impact of the threats\" As a minimum, there is the risk that the project does not accomplish its objectives. Since a project is a “capital” expenditure (as opposed to an ongoing “operational” one) risks are always present and need to be managed. There is usually some sort of primary risk factor under which the project was defined, such as market risk for the development of a new product, or technical risk for an assembly line improvement project (will it speed up the line, etc?). After that, a host of secondary risks present themselves which, if ignored, can trip up a project. The more risk planning you do, the safer your projects. For that reason risk management is joined at the hip to project management. Of course, a project manager’s time is valuable too, 21 CU IDOL SELF LEARNING MATERIAL (SLM)

and since many have other technical duties to attend to, it is important to arrive at the correct amount of risk planning. As, there is close relationship between risk and Project Management, we will identify the risk and understand its analysis. We will also study in detail about risk planning and monitoring IDENTIFICATION OF RISKS A strong risk identification process is important to the successful completion of the critical success factors. This is particularly true for large or inherently risky projects, like nuclear power plants. But if it’s beneficial for large projects, an appropriately sized risk planning process will benefit small projects too. A Risk Management Plan is prepared which includes items such as: ▪ Risk Register ▪ Risk Breakdown Structure ▪ Risk Analysis The risk register is the itemized listing of most important risks and it becomes the cornerstone of the Risk Management Plan. It requires careful consideration of the project risks and what could affect the project’s critical success factors. Here are a few ideas to ensure that each risk is identified: 1. Use a Risk Breakdown Structure. Dividing risks into categories is intuitive and allows for better organization. Since many risks are unrelated to each other (the wrong chemical is delivered vs. the forklift operator quits), the systematic categorization of risks helps to ensure strong identification. 2. Develop a checklist. Every business is different, and you are best suited to develop a checklist for yours. That being said, we have developed a generic one. 3. Look at Assumptions. Every project operates under a set of assumptions. The business climate, client willingness, customer attitudes, etc. which, together, result in the creation of the project. What are the assumptions, and what happens if they change mid-project? 4. Previous Project Experience. Many project based organizations have similar projects in their past history. What types of issues did they experience? On a related note, if there is no lessons learned database within the organization, maybe it’s time to start one. 5. Expert judgment. Although I left this one for last, it can’t be understated. A subject matter expert will be able to identify most of the risks and know what to do about them. The project organizer needs to anticipate the risk in the project as early as possible so that the impact of risk can be reduced by making effective risk management planning. A project can be of use by a large variety of risk. To identify the significant risk, this might affect a project. It is necessary to categories into the different risk of classes. 22 CU IDOL SELF LEARNING MATERIAL (SLM)

There are different types of risks which can affect a software project: 1. Technology risks: Risks that assume from the software or hardware technologies that are used to develop the system. 2. People risks: Risks that are connected with the person in the development team. 3. Organizational risks: Risks that assume from the organizational environment where the software is being developed. 4. Tools risks: Risks that assume from the software tools and other support software used to create the system. 5. Requirement risks: Risks that assume from the changes to the customer requirement and the process of managing the requirements change. 6. Estimation risks: Risks that assume from the management estimates of the resources required to build the system Risk Identification: Tools and Techniques - Documentation Reviews The standard practice to identify risks is reviewing project related documents such as lessons learned, articles, organizational process assets, etc Information Gathering Techniques The given techniques are similar to the techniques used to collect requirements. Let's look at a few of them: Brainstorming Brainstorming is done with a group of people who focus on the identification of risk for the project. Delphi Technique A team of experts has consulted anonymously. A list of required information is sent to experts, responses are compiled, and results are sent back to them for further review until a consensus is reached. Interviewing An interview is conducted with project participants, stakeholders, experts, etc to identify risks. Root Cause Analysis Root causes are determined for the identified risks. These root causes are further used to identify additional risks. Swot Analysis (Strength, Weakness, Opportunities, and Threats) 23 CU IDOL SELF LEARNING MATERIAL (SLM)

Strengths and weaknesses are identified for the project and thus, risks are determined. Checklist Analysis The checklist of risk categories is used to come up with additional risks for the project. Assumption Analysis Identification of different assumptions of the project and determining their validity further helps in identifying risks for the project. Outputs to Identify Risks This process of Risk Identification results in the creation of Risk Register. Risk Register A Risk Register is a living document that is updated regularly throughout the life cycle of the project. It becomes a part of project documents and is included in the historical records that are used for future projects. The risk register includes: • List of Risks • List of Potential Responses • Root Causes of Risks • Updated Risk Categories RISK ANALYSIS Risk analysis is the process of identifying and analyzing potential issues that could negatively impact key business initiatives or projects. This process is done in order to help organizations avoid or mitigate those risks. Performing a risk analysis includes considering the possibility of adverse events caused by either natural processes, like severe storms, earthquakes or floods, or adverse events caused by malicious or inadvertent human activities. An important part of risk analysis is identifying the potential for harm from these events, as well During the risk analysis process, you have to consider every identified risk and make a perception of the probability and seriousness of that risk. There is no simple way to do this. You have to rely on your perception and experience of previous projects and the problems that arise in them. It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk. Instead, you should authorize the risk to one of several bands: 24 CU IDOL SELF LEARNING MATERIAL (SLM)

1. The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-50%), high (50-75%) or very high (+75%). 2. The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious (would cause significant delays), tolerable (delays are within allowed contingency), or insignificant. Enterprises and other organizations use risk analysis to: • anticipate and reduce the effect of harmful results from adverse events. • evaluate whether the potential risks of a project are balanced by its benefits to aid in the decision process when evaluating whether to move forward with the project; • plan responses for technology or equipment failure or loss from adverse events, both natural and human-caused; and • identify the impact of and prepare for changes in the enterprise environment, including the likelihood of new competitors entering the market or changes to government regulatory policy. Benefits of risk analysis Organizations must understand the risks associated with the use of their information systems to effectively and efficiently protect their information assets. Risk analysis can help an organization improve its security in a number of ways. Depending on the type and extent of the risk analysis, organizations can use the results to help: • identify, rate and compare the overall impact of risks to the organization, in terms of both financial and organizational impacts; • identify gaps in security and determine the next steps to eliminate the weaknesses and strengthen security; • enhance communication and decision-making processes as they relate to information security; • improve security policies and procedures and develop cost-effective methods for implementing these information security policies and procedures; • put security controls in place to mitigate the most important risks; • increase employee awareness about security measures and risks by highlighting best practices during the risk analysis process; and • understand the financial impacts of potential security risks. 25 CU IDOL SELF LEARNING MATERIAL (SLM)

Risk analysis is an important tool for managing costs associated with risks, as well as for aiding an organization's decision-making process. Steps in risk analysis process The risk analysis process usually follows these basic steps: 1. Conduct a risk assessment survey: This first step, getting input from management and department heads, is critical to the risk assessment process. The risk assessment survey is a way to begin documenting specific risks or threats within each department. 2. Identify the risks: The reason for performing risk assessment is to evaluate an IT system or other aspect of the organization and then ask: What are the risks to the software, hardware, data and IT employees? What are the possible adverse events that could occur, such as human error, fire, flooding or earthquakes? What is the potential that the integrity of the system will be compromised or that it won't be available? 3. Analyze the risks: Once the risks are identified, the risk analysis process should determine the likelihood that each risk will occur, as well as the consequences linked to each risk and how they might affect the objectives of a project. 4. Develop a risk management plan: Based on an analysis of which assets are valuable and which threats will probably affect those assets negatively, the risk analysis should produce control recommendations that can be used to mitigate, transfer, accept or avoid the risk. 5. Implement the risk management plan: The ultimate goal of risk assessment is to implement measures to remove or reduce the risks. Starting with the highest-priority risk, resolve or at least mitigate each risk so it's no longer a threat. 6. Monitor the risks: The ongoing process of identifying, treating and managing risks should be an important part of any risk analysis process. The focus of the analysis, as well as the format of the results, will vary depending on the type of risk analysis being carried out. Qualitative vs. Quantitative risk analysis The two main approaches to risk analysis are qualitative and quantitative. Qualitative risk analysis typically means assessing the likelihood that a risk will occur based on subjective qualities and the impact it could have on an organization using predefined ranking scales. The impact of risks is often categorized into three levels: low, medium or high. The probability 26 CU IDOL SELF LEARNING MATERIAL (SLM)

that a risk will occur can also be expressed the same way or categorized as the likelihood it will occur, ranging from 0% to 100%. Quantitative risk analysis, on the other hand, attempts to assign a specific financial amount to adverse events, representing the potential cost to an organization if that event actually occurs, as well as the likelihood that the event will occur in a given year. In other words, if the anticipated cost of a significant cyberattack is $10 million and the likelihood of the attack occurring during the current year is 10%, the cost of that risk would be $1 million for the current year. A qualitative risk analysis produces subjective results because it gathers data from participants in the risk analysis process based on their perceptions of the probability of a risk and the risk's likely consequences. Categorizing risks in this way helps organizations and/or project teams decide which risks can be considered low priority and which have to be actively managed to reduce the effect on the enterprise or the project. A quantitative risk analysis, in contrast, examines the overall risk of a project and generally is conducted after a qualitative risk analysis. The quantitative risk analysis numerically analyzes the probability of each risk and its consequences. The goal of a quantitative risk analysis is to associate a specific financial amount to each risk that has been identified, representing the potential cost to an organization if that risk actually occurs. So, an organization that has done a quantitative risk analysis and is then hit with a data breach should be able to easily determine the financial impact of the incident on its operations. A quantitative risk analysis provides an organization with more objective information and data than the qualitative analysis process, thus aiding in its value to the decision-making process. SOFTWARE RISK PLANNING Software risk planning is all about: 1. Defining preventive measure that would lower down the likelihood or probability of various risks. 2. Define measures that would reduce the impact in case a risk happens. 3. Constant monitoring of processes to identify risks as early as possible. 27 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 2.1 Software Risk Planning SOFTWARE RISK MONITORING Risk monitoring can be defined as: “activities focused on understanding changes to the environment and specific risks to the organization.” The “environment” is anything the risk is linked to. Internally, the environment can include objectives, practices, and processes. External environment examples include (but are definitely not limited to) regulations, competition, economic factors, geopolitical concerns, and vendors. Monitoring a risk and relevant issues surrounding it focuses on looking for three things: 1. How the risk is changing; 2. The effect those change(s) will have on objectives or other factors of the internal or external operating environment; and 3. Whether the organization took enough risk to achieve its objectives. Software risk monitoring is integrated into project activities and regular checks are conducted on top risks. Software risk monitoring comprises of: • Tracking of risk plans for any major changes in actual plan, attribute, etc. 28 • Preparation of status reports for project management. CU IDOL SELF LEARNING MATERIAL (SLM)

• Review risks and risks whose impact or likelihood has reached the lowest possible level should be closed. • Regularly search for new risks Purpose of Risk Monitoring: –To confirm risk responses are implemented as planned. – To determine if risk responses are effective or if new responses are needed. –To determine the validity of the project assumptions. – To determine if risk exposure has changed, evolved, or declined due to trends in the project progression. –To confirm policies and procedures happen as planned. –To monitor the project for new risks. –To monitor risk triggers. • Risk triggers are those events that will cause the threat of a risk to become a reality. For example, you have identified the fact that you only have one pump set available and the replacement takes six weeks to arrive. In the middle of your irrigation and recycling process tests, you discover that water pressure tends to fluctuate beyond pump tolerance levels. If you do not find a way to solve this problem, your risk will become a reality. • Make sure that for each identified risk, you must provide a response plan. It is not much help to you if the risk becomes a reality or issue and you do not have an alternate execution path or some other emergency procurement plan. • Main inputs to effectively monitor and control risks: • – Risk management plan – Risk Register / Risk Tracker – Risk response plan – Project communications – New risk identification – Scope changes Benefits of Risk Monitoring and Risk Control: 29 – Workaround plans – Corrective / Preventive actions CU IDOL SELF LEARNING MATERIAL (SLM)

– Change requests – Risk response plan updates – Risk database – Checklist updates SUMMARY • For a project manager, risk management is a key process for project control. Armed with a risk log and a switched on team, the project manager can plan for any eventuality. • Risk is any unexpected event that can affect your project — for better or for worse • Risk management is the process of making and carrying out decisions that will minimize the adverse effects of risk on an organization. • Types of Risks- Technology risks, People risks, Organizational risks, Tools risks, Requirement risks and Estimation risks • Risk Register: A Risk Register is a living document that is updated regularly throughout the life cycle of the project • Risk analysis is the process of identifying and analyzing potential issues that could negatively impact key business initiatives or projects • Qualitative risk analysis typically means assessing the likelihood that a risk will occur based on subjective qualities and the impact it could have on an organization using predefined ranking scales. • Quantitative risk analysis provides an organization with more objective information and data than the qualitative analysis process, thus aiding in its value to the decision- making process. • Software risk planning is all about defining preventive measure, define measures and constant monitoring. • Software risk monitoring is integrated into project activities and regular checks are conducted on top risks KEYWORDS • Root Cause Analysis: Root cause analysis (RCA) is defined as a collective term that describes a wide range of approaches, tools, and techniques used to uncover causes of problems. • Delphi Technique: The Delphi method is a process used to arrive at a group opinion or decision by surveying a panel of experts 30 CU IDOL SELF LEARNING MATERIAL (SLM)

• Brain storming: Brainstorming is the name given to a situation when a group of people meet to generate new ideas around a specific area of interest • Risk Register: is a living document that is updated regularly throughout the life cycle of the project. • Risk analysis is the process of identifying and analyzing potential issues that could negatively impact key business initiatives or projects. LEARNING ACTIVITY 1. Consider a task of appearing for driving exam. Analyze the risk involve in the same. 2. Compare Risk Identification and Risk Analysis. UNIT END QUESTIONS A. Descriptive Type Questions 1. What is Risk? Assuming that you are project manager of Mobile App Company so what measures will be undertaken by you to identify the risks. 2. State different types of risks. 3. How the Risk Analysis process is executed. 4. Differentiate between Qualitative and Quantitative risk analysis. 5. Define Risk Planning and Monitoring. State its importance and correlate it to the importance of Project Management. B. Multiple Choice Questions 1. Risk management is one of the most important jobs for a a) Client b) Investor c) Production team d) Project manager 2. What assess the risk and your plans for risk mitigation and revise these when you learn more about the risk? a) Risk monitoring b) Risk planning c) Risk analysis d) Risk identification 31 CU IDOL SELF LEARNING MATERIAL (SLM)

3. Which of the following risks are derived from the organizational environment where the software is being developed? a) People risks b) Technology risks c) Estimation risks d) Organizational risks 4. is now recognized as one of the most important project management tasks a. Project Management b. Risk Management’ c. Staff Management’ d. Performance Management 5. Which of the following term is best defined by the statement: “Derive traceability information to maximize information hiding in the design.”? a) Underestimated development time b) Organizational restructuring c) Requirements changes d) None of the mentioned Answers: 1 - d; 2 -a; 3 -d; 4 -b; 5-c REFERENCES • Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition Sixth Edition, Sixth edition, Project Management Institute • Bob Hughes, Mike Cotterell and Rajib Mall, ‘Software Project Management’- Tata McGrawHill. • Bennatan E. (1994).Software Project Management.London: McGraw-Hill. • Anna P. Murray, The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond , Wiley • Terry T. Kidd , Handbook of Research on Technology Project Management, Planning, and Operations (Advances in IT Personnel and Project Management), Information Science Reference • Phillip Bruce , Sam M. Pederson The Software Development Project: Planning and Management, Wiley • Greg Horine , Project Management Absolute Beginner's Guide (3rd Edition), Que Publishing 32 CU IDOL SELF LEARNING MATERIAL (SLM)

• G. L. Rexing, \"Software project management: Moving beyond project plans,\" in AT&T Technical Journal, vol. 70, no. 2, pp. 40-48, March-April 1991. 33 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 3- SOFTWARE PROJECT ESTIMATION Structure Learning Objective Introduction Project Estimation Different methods of estimation COCOMO model Delphi cost estimation Function point analysis Objectives of FPA Summary Keywords Learning Activity Units End Questions References LEARNING OBJECTIVES After studying this unit, you should be able to • Explain the concept of project estimation. • Describe different methods of project estimation • Elaborate COCOMO model • Discuss Delphi cost estimation & Function point analysis INTRODUCTION Estimating is a critical part of project planning, involving a quantitative estimate of project costs, resources or duration. Every business has a budget and wants to know the costs before they're willing to begin a project. A project estimate is your prediction of how much time and money is needed to complete a project. Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable. Estimation determines how much money, effort, resources, and time it will take to build a specific system or product. Estimation is based on − • Past Data/Past Experience • Available Documents/Knowledge • Assumptions 34 CU IDOL SELF LEARNING MATERIAL (SLM)

• Identified Risks The four basic steps in Software Project Estimation are − • Estimate the size of the development product. • Estimate the effort in person-months or person-hours. • Estimate the schedule in calendar months. • Estimate the project cost in agreed currency. • Estimation need not be a one-time task in a project. It can take place during − o Acquiring a Project. o Planning the Project. o Execution of the Project as the need arises. Project scope must be understood before the estimation process begins. It will be helpful to have historical Project Data. Project metrics can provide a historical perspective and valuable input for generation of quantitative estimates. Planning requires technical managers and the software team to make an initial commitment as it leads to responsibility and accountability. Past experience can aid greatly. Use at least two estimation techniques to arrive at the estimates and reconcile the resulting values. Plans should be iterative and allow adjustments as time passes and more details are known. PROJECT ESTIMATION Project Estimation is a process to predict the time and the cost that a project requires to be finished appropriately. But in term of software development, it also means of the consideration of the experience of the software development company; the technique they employ; the process they may go through to finish the task. This whole process requires the use of complex tools and good mathematical background knowledge. It is in some cases is the accomplishment of hard work of a whole team. The error margin is, consequently, guaranteed possibly around 5-10%. The whole process of estimation would cost the company rather considerable cost and time at the very first stage of building an app. But this will make the final result more credible, realistic, and customer-satisfying. Projects especially big ones are advisable to employ this crucial step to avoid unpredictable failure. 1. Determining the goals and commitments: Similar to going on the road, you should be very clear about your final destination before setting off. Communicating clearly the goals or the needs of yours with the estimation team would well guide the whole process to the right place it is expected to be. Communication of the goals clearly also allows both the estimation team and the software development company to vision the reality of all the requirements. They, therefore, would 35 CU IDOL SELF LEARNING MATERIAL (SLM)

plan an appropriate timeline, personnel and employ the suitable technologies to achieve the goals in the most fruitful way. Basing on those mentioned, terms and agreements between the customers and the app developing team would be set. 2. Comprehending the functional scope of the project: The most essential factor for sizing a project is to determine what you want to develop and what would it reach. In some cases, there would be breakdowns in functions according to reference documentation. This lets you know in-depth about the possible extent and elements of the system which will be estimated. However, in some cases, the estimation task become much more uncertain and complex. Then, it is necessary that the estimator should follow the following steps to get out. • Foster communication to enhance comprehension. • Learn from the existing similar system. • Spend more effort in studying the industry and the type of project. • Review the validation and prioritize created functional requirements created. 3. Paying attention to non-functional needs: These functions focus on the “how” the project might work to meet the requirements of the customers which are usually left un-addressed when determining the functional requirements. Followings are some of typical non-function requirements software estimation process usually left unattended: • Maintainability • Scalability • Security • Interoperability • Performance • High availability • Usability These non-functional requirements may account for different importance depending on the type of project or industry. Also, the complexity and the context of different projects could vary the role of the about mentioned functions. 4. Setting clear priorities: The estimations and limits of the project as money, time, or personnel make obtaining the planned goals much more complex. In these situations, it is important to clarify the utmost importance of each functional priority in order to focus on the most essential ones. Estimating clearly the priorities from the beginning would also keep the project more on track. Not many changes and additional requirements occur during the time of making the software, which would save a lot of time and effort. 36 CU IDOL SELF LEARNING MATERIAL (SLM)

5. Considering goals and commitments in agile plans: Agile methodology is a contemporary developing method that allows customers and app development center to continuously communicate and make changes to their product throughout the process of developing. Iterative sprints of delivery enable customers to see their final product as well how it functions. They, then, could make modifications to their requirement which have been agreed on the previous stages. This method provides flexibility to the customers but requires the company to have a highly-skilled development team to continuously adapt to the changing needs. Also, Agile is most likely suit to the small-scale projects. 6. Choosing estimation strategies: Depending on the type of project, its complexity, the information present, the number of requirements, and the delivery times of the estimation, it is necessary to think and choose the right strategy. We can look at some of these here: There are plenty of estimation strategies that estimators could employ. But, firstly, they could take into consideration the complexity of the project, the amount of information acquired, and time constraint. An appropriate combination of those things could result in the estimating approaches as follows: Classic estimation (expert judgment): This is likely the most common way, and it includes of selecting a requirement and allocates it a time value based on the difficulty and how experienced the estimators are in the required field. Estimation team is advised to break down the requirements into more detailed components including business, presentation, and database. Then, a suitable amount of time will be allocated for each of them. The final estimation is then the combination of smaller ones from the mentioned elements. Note: This strategy is favorable and advisable to be used when a sufficient amount of time is allowed and the number of requirement to estimate is considerable. Estimation by order of complexity: • This is just the process of ordering the requirement based on their complexity. • Then, use the traditional model to estimate a representative sample of all the requirements. • Next the value of the traditional estimations from the requirements from the previous step would be extrapolated, also according to complexity order. For instance, we have 100 requirements and the estimation process is as the following steps: 1. Complexity order assigned for all the requirements (e.g., Scalability: 1,2,3,5,7,12). 2. Use traditional estimation to evaluate the representative requirements (e.g., 11). 3. The complexity of the overall project is the average of the subset requirements (e.g., 3 representatives have the complexity of 2, these 3 estimations are averaged). 4. The estimation value of non-estimated requirements is also taken and assigned. 37 CU IDOL SELF LEARNING MATERIAL (SLM)

Note: This strategy of estimation is suitable for the projects with the large number of requirements. Estimation based on analogy: This estimation strategy is an approach that allows company build estimation of current project based on the similar one or ones they have carry on before. This to some extent will save a great deal of time and resources but also requires the company to have the followings to ensure a similar outcome: • Hand-on and extensive experience. • A good and comprehensive record of the previous projects. • Knowledgebase to analyze and recognize similar projects. • The estimators must be trained to adapt the analogous estimations and manage the knowledge repository. • Adapt of the analogous estimations and management of knowledge repository Estimation by team: This approach is partially similar to the classic one. The only difference is that the smaller components as system module, business, presentation, etc., will be delegated to separate teams. Each team will independently offer their estimation. And the final result will be consolidated by the combination of individual results of theteams. Note: This strategy of estimation is use for the projects with average number of requirements. 7. Recognizing AND address possible assumptions: It is not possible to list down all the possible assumptions during the estimation process. But it is advisable to address the more of them the better to avoid possibilities of uncertainties. This will enhance the common understanding of the parties involving in the process of estimation. 8. Revising estimations: Two heads are better than one. Revision with other estimators during the software estimation project help foresee the possibility of the projects, the possible assumptions, and the best estimation strategy. The only downside of this could be that the time constraint. More people, more ideas. You are, then, have to be strong enough to selectively choose which advice and change to carry on. 9. Employing estimation tools: Software project estimation companies now could make use of tools to facilitate their estimating. With the assistance of tools, their work would be more systematic, and automatic. The process of estimation would cost less time and make it much easier to make reports and store data for future projects. 38 CU IDOL SELF LEARNING MATERIAL (SLM)

10. Noting for special projects: The projects with a number of special requirements require of course more specialized hands to be accomplished appropriately. Then, the common tasks – software testing, analysis, infrastructure, development-which are usually taken care by estimation team have to be exclusively cared for by the high-profiled testers, designers, analysts. DIFFERENT METHODS OF ESTIMATION COCOMO model Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is one of the most generally used software estimation models in the world. COCOMO predicts the efforts and schedule of a software product based on the size of the software. The necessary steps in this model are: 1. Get an initial estimate of the development effort from evaluation of thousands of delivered lines of source code (KDLOC). 2. Determine a set of 15 multiplying factors from various attributes of the project. 3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e., multiply the values in step1 and step2. The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static single variable models, using KDLOC as the measure of the size. To determine the initial effort Ei in person-months the equation used is of the type is shown below Ei=a*(KDLOC)b The value of the constant a and b are depending on the project type. In COCOMO, projects are categorized into three types: 1. Organic 2. Semidetached 3. Embedded 1. Organic: A development project can be treated of the organic type, if the project deals with developing a well-understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar methods of projects. Examples of this type of projects are simple business systems, simple inventory management systems, and data processing systems. 2. Semidetached: A development project can be treated with semidetached type if the development consists of a mixture of experienced and inexperienced staff. Team members may have finite experience in related systems but may be unfamiliar with some aspects of the 39 CU IDOL SELF LEARNING MATERIAL (SLM)

order being developed. Example of Semidetached system includes developing a new operating system (OS), a Database Management System (DBMS), and complex inventory management system. 3. Embedded: A development project is treated to be of an embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational method exist. For Example: ATM, Air Traffic control. For three product categories, Bohem provides a different set of expression to predict effort (in a unit of person month)and development time from the size of estimation in KLOC(Kilo Line of code) efforts estimation takes into account the productivity loss due to holidays, weekly off, coffee breaks, etc. According to Boehm, software cost estimation should be done through three stages: 1. Basic Model 2. Intermediate Model 3. Detailed Model 1. Basic COCOMO Model: The basic COCOMO model provides an accurate size of the project parameters. The following expressions give the basic COCOMO estimation model: Effort=a1*(KLOC) a2 PM Tdev=b1*(efforts)b2 Months Where KLOC is the estimated size of the software product indicate in Kilo Lines of Code, a1, a2, b1, b2 are constants for each group of software products, Tdev is the estimated time to develop the software, expressed in months, Effort is the total effort required to develop the software product, expressed in person months (PMs). Estimation of development effort For the three classes of software products, the formulas for estimating the effort based on the code size are shown below: Organic: Effort = 2.4(KLOC) 1.05 PM Semi-detached: Effort = 3.0(KLOC) 1.12 PM Embedded: Effort = 3.6(KLOC) 1.20 PM Estimation of development time For the three classes of software products, the formulas for estimating the development time based on the effort are given below: Organic: Tdev = 2.5(Effort) 0.38 Months Semi-detached: Tdev = 2.5(Effort) 0.35 Months Embedded: Tdev = 2.5(Effort) 0.32 Months Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for different software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can observe that the effort is somewhat superliner in the size of the 40 CU IDOL SELF LEARNING MATERIAL (SLM)

software product. Thus, the effort required to develop a product increases very rapidly with project size. Fig 3.1: Effort Versus product size The development time versus the product size in KLOC is plotted in fig. From fig it can be observed that the development time is a sub linear function of the size of the product, i.e. when the size of the product increases by two times, the time to develop the product does not double but rises moderately. This can be explained by the fact that for larger products, a larger number of activities which can be carried out concurrently can be identified. The parallel activities can be carried out simultaneously by the engineers. This reduces the time to complete the project. Further, from fig, it can be observed that the development time is roughly the same for all three categories of products. For example, a 60 KLOC program can be developed in approximately 18 months, regardless of whether it is of organic, semidetached, or embedded type. Fig 3.2: Development time versus size. From the effort estimation, the project cost can be obtained by multiplying the required effort by the manpower cost per month. But, implicit in this project cost computation is the assumption that the entire project cost is incurred on account of the manpower cost alone. In addition to manpower cost, a project would incur costs due to hardware and software required for the project and the company overheads for administration, office space, etc. 41 CU IDOL SELF LEARNING MATERIAL (SLM)

It is important to note that the effort and the duration estimations obtained using the COCOMO model are called a nominal effort estimate and nominal duration estimate. The term nominal implies that if anyone tries to complete the project in a time shorter than the estimated duration, then the cost will increase drastically. But, if anyone completes the project over a longer period of time than the estimated, then there is almost no decrease in the estimated cost value. Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for each of the three model i.e., organic, semi-detached & embedded. Solution: The basic COCOMO equation takes the form: Effort=a1*(KLOC) a2 PM Tdev=b1*(efforts)b2 Months Estimated Size of project= 400 KLOC (i) Organic Mode E = 2.4 * (400)1.05 = 1295.31 PM D = 2.5 * (1295.31)0.38=38.07 PM (ii) Semidetached Mode E = 3.0 * (400)1.12=2462.79 PM D = 2.5 * (2462.79)0.35=38.45 PM (iii) Embedded Mode E = 3.6 * (400)1.20 = 4772.81 PM D = 2.5 * (4772.8)0.32 = 38 PM Example2: A project size of 200 KLOC is to be developed. Software development team has average experience on similar type of projects. The project schedule is not very tight. Calculate the Effort, development time, average staff size, and productivity of the project. Solution: The semidetached mode is the most appropriate mode, keeping in view the size, schedule and experience of development time. Hence E=3.0(200)1.12=1133.12PM D=2.5(1133.12)0.35=29.3PM Productivity = 176 LOC/PM 42 CU IDOL SELF LEARNING MATERIAL (SLM)

2. Intermediate Model: The intermediate model estimates software development effort in terms of size of the program and other related cost drivers parameters (product parameter, hardware parameter, resource parameter, and project parameter) of the project. The estimated effort and scheduled time are given by the relationship: Effort (E) = a*(KLOC)b *EAF MM Scheduled Time (D) = c*(E)d Months(M) Where, • E = Total effort required for the project in Man-Months (MM). • D = Total time required for project development in Months (M). • KLOC = The size of the code for the project in Kilo lines of code. • a, b, c, d = The constant parameters for the software project. EAF = It is an Effort Adjustment Factor, which is calculated by multiplying the parameter values of different cost driver parameters. For ideal, the value is 1. COST DRIVERS VERY LOW NOMINAL HIGH VERY PARAMETERS LOW 1.15 HIGH Required Software Product Parameter 1.4 0.75 0.88 Size of Project Database NA 0.94 1 1.08 1.16 1.15 1.3 Complexity of The 0.7 0.85 Project Hardware Parameter 43 CU IDOL SELF LEARNING MATERIAL (SLM)

Performance Restriction NA NA 1.11 1.3 1.06 1.21 Memory Restriction NA NA 1 1.15 1.3 virtual Machine NA 0.87 1.07 1.15 Environment NA 0.94 0.86 0.71 Required Turnabout 0.91 0.82 Time Personnel Parameter 0.86 0.7 1.46 1.19 0.9 NA Analysis Capability 0.95 NA Application Experience 1.29 1.13 0.91 0.82 Software Engineer 1.42 1.17 1 0.91 0.83 Capability 1.21 1.1 1.04 1.1 Virtual Machine Experience Programming Experience 1.14 1.07 Project Parameter Software Engineering 1.24 1.1 1 Methods 1.24 1.1 Use of Software Tools Development Time 1.23 1.08 Example: For a given project was estimated with a size of 300 KLOC. Calculate the Effort, Scheduled time for development by considering developer having high application experience and very low experience in programming. Ans: Given the estimated size of the project is: 300 KLOC Developer having highly application experience: 0.82 (as per above table) Developer having very low experience in programming: 1.14(as per above table) EAF = 0.82*1.14 = 0.9348 Effort (E) = a*(KLOC)b *EAF = 3.0*(300)1.12*0.9348 = 1668.07 MM Scheduled Time (D) = c*(E)d = 2.5*(1668.07)0.35 = 33.55 Months(M) 3. Detailed COCOMO Model: Detailed COCOMO incorporates all qualities of the standard version with an assessment of the cost drivers effect on each method of the software engineering process. The detailed model uses various effort multipliers for each cost driver property. In detailed cocomo, the whole software is differentiated into multiple modules, and then we apply COCOMO in various modules to estimate effort and then sum the effort. The Six phases of detailed COCOMO are: 44 CU IDOL SELF LEARNING MATERIAL (SLM)

1. Planning and requirements 2. System structure 3. Complete structure 4. Module code and test 5. Integration and test 6. Cost Constructive model The effort is determined as a function of program estimate, and a set of cost drivers are given according to every phase of the software lifecycle. Delphi technique of software estimation In software estimation, the project specifications are allotted to the experts and they convey their views/opinions about the same. The total number of experts chosen depends on their availability and the size of the project. Delphi in software estimation takes into account the following key points: • Expert's Selection. • Briefing about the project to the experts. • Gathering an idea/estimate from the experts. • Assimilate the ideas and finalize it. Selection of Experts: Expert selection must be based on the relevant amount of experience they have in software development. The experts can be within or without the organization. The number of experts varies according to their availability in the required knowledge domain, complexity involved in the project etc. Briefing Experts: Once the team is set, it is time to brief the experts regarding the various aspects of the project like objectives of the estimation, explaining the scope of the project, competition involved in the project, estimated deadline and expected deliverables from the experts. According to the information, the experts prepare their schedule and devise plan to carry forward the software estimation. Gather idea/estimate from the experts: Based on the inputs provided, the experts offer an approximation about the size, effort and time to be allocated to the project. Expert Name Size Effort Expert 1 x K Expert 2 1 A CU IDOL SELF LEARNING MATERIAL (SLM) 45

Table 3.1: Experts view on size and efforts Assimilation of ideas: Now when the estimates are defined, we can arrive at a conclusion to combine these estimates. Based on high and low estimates, an average estimate can be drawn, which can be actually used to serve the intended purpose. Advantages of Delphi Technique: • A useful technique in the absence of experts within the organization, as Delphi allows hiring experts from external sources with required domain knowledge for the project. • It is a quick technique to arrive at an estimate. • Delphi technique is popular for its simplicity Disadvantages of Delphi Technique: • Sometimes it becomes difficult to find and analyze the right expert. • Difficulty in deciding the number of experts required. • The estimates derived, are not auditable. • This technique can only estimate the size and effort of the project but not the time. Conclusion: Out of many other techniques available for software estimation, Delphi is an easy alternative. Every estimation technique offers its own ways of solving issues; hence a wise selection is needed as per the project requirements. This shall deliver the best results. Functional Point (FP) Analysis Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been further modified by the International Function Point Users Group (IFPUG). FPA is used to make estimate of the software project, including its testing in terms of functionality or function size of the software product. However, functional point analysis may be used for the test estimation of the product. The functional size of the product is measured in terms of the function point, which is a standard of measurement to measure the software application. OBJECTIVES OF FPA The basic and primary purpose of the functional point analysis is to measure and provide the software application functional size to the client, customer, and the stakeholder on their request. Further, it is used to measure the software project development along with its maintenance, consistently throughout the project irrespective of the tools and the technologies. Following are the points regarding FPs 46 CU IDOL SELF LEARNING MATERIAL (SLM)

1. FPs of an application is found out by counting the number and types of functions used in the applications. Various functions used in an application can be put under five types, as shown in Table: Table 3.2: Types of FP Attributes Measurements Parameters Examples 1.Number of External Inputs(EI) Input screen and tables 2. Number of External Output (EO) Output screens and reports 3. Number of external inquiries (EQ) Prompts and interrupts. 4. Number of internal files (ILF) Databases and directories 5. Number of external interfaces (EIF) Shared databases and shared routines. All these parameters are then individually assessed for complexity. 2. FP characterizes the complexity of the software system and hence can be used to depict the project time and the manpower requirement. 3. The effort required to develop the project depends on what the software does. 4. FP is programming language independent. 5. FP method is used for data processing systems, business systems like information systems. 6. The five parameters mentioned above are also known as information domain characteristics. 7. All the parameters mentioned above are assigned some weights that have been experimentally determined and are shown in Table Table 3.3: Weights of 5-FP Attributes Measurement Parameter Low Average High 15 1. Number of external inputs (EI) 7 10 10 2. Number of external outputs (EO) 57 6 3. Number of external inquiries (EQ) 34 7 4. Number of internal files (ILF) 45 6 5. Number of external interfaces (EIF) 34 47 CU IDOL SELF LEARNING MATERIAL (SLM)