Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Chapter - 1 Software Project Management Introduction • Software project management is an activity crucial to the success of software projects. • Software products are more complex entities in which defects are mostly discovered during development. • Software changes are limited to changes in programs and the volume of change depends on understanding requirements of customers and developers. • In the current scenario, people working on a project to develop software are geographically distributed; hence, proper coordination and communication management is required among them. Introduction • Due to the lack of domain knowledge certain tools are needed for project size estimation, planning, software development, and so on. • Quality software can only be produced if a systematic process and appropriate techniques are followed for the development of software. • It is observed that several software projects run behind schedule, over budget, and fail to meet the customer requirements. • In a software company, many software projects run concurrently; they share resources and their activities are synchronized for optimal use of resources. Goal of SPM • Development of quality software is the primary objective of software project management. • The goal of software project management is to enable a group of people to work efficiently on a project, using a systematic process, in order to produce a quality software product. • Software project management uses a more established and specialized approach as compared to general project management. Project Management Essentials • Project management is an integrated environment where various entities are interconnected and performed together to produce a quality software product. • There are four essential elements of effective software project management: – Project – People – Process – Product • Effective software project management focuses on these elements to fulfill the customer needs. Project Management Essentials People Process Software project management Product Project Figure 3.1: Software project management essentials Project • A project is a temporary endeavor with defined starting and ending deadlines, roles and responsibilities, conditions, budgets and plans, undertaken to accomplish aim and objectives. • Each project has a unique purpose even if there are multiple projects in a single domain. • Projects are basically temporary in nature due to their flexibility to change. • Uncertainties are involved in a software project. • Requires resources (hardware, software, and human resources), typically from different areas. Project • A successful project always satisfies the project constraints expected by the customer. • Project constraints are defined in the project scope, which defines the work products to be produced in a project using processes. • The most common constraints that are employed on the project scope are project cost, time, and quality. • Project stakeholders must agree upon the defined project scope. • The main focus of project management is to satisfy the customer through production of quality products. People • People (or stakeholders) in a project are those who are either involved in or are affected by the project. • Each person in the project has certain roles and responsibilities according to their skill sets. • They should be motivated, trained, rewarded, deployed, and retained as and when required to improve their capabilities. • Poor management sometimes leads to project failures. People Involved in Project • • • • • • • • • Senior Managers Project Managers Programmers Support Staff Customers End Users Project Sponsors Competitors Suppliers Process • A software process describes the characteristics and organization of activities in order to produce software. • The general activities of software processes include – Definition – Development – Implementation • The selection of an appropriate software process model according to the project is a challenge for the project manager. • Process models ultimately affect the product quality. Product • A product is the final outcome of a project. • It is produced with an effective project management process. • The project manager must determine the requirements and the expected outcomes at the beginning of the project. • Project scope of the product must be clearly defined, which helps us to produce a quality product. • Project scope is refined into discrete functional units and the development schedule is planned for each functional units. • The quality of the product also depends on the process being used for product development. Project Management • Project management is the application of knowledge, skills, tools, and techniques for performing project activities in order to satisfy the expectations of the stakeholders from a project. • Project management is necessary to find the pitfalls and create outlets to avoid the unintended consequences of the project. • Software project management is the key to successful delivery of software projects as per customers’ expectations. Project Management Knowledge Areas • The knowledge areas are the competencies of the process, practice, tools, and techniques that the project managers must have for managing the projects. • The main knowledge areas for project management are: – – – – – – – – – Scope Time Cost Quality People Communications Risk, Procurement Project Integration Management Project Management Knowledge Areas • Each of these knowledge areas has some processes for its execution in order to achieve an effective project management program. • Project management skills include: – General Management – Human Resource Management – Procurement Management – Communication Management – Risk Management. • Project management tools and techniques assist in carrying out the activities of project managers. Project Failures • • • • • • • • • • • • • • Inability to clearly understand customer needs Lack of user involvement Unrealistic expectations Lack of top management support Incomplete requirements and specifications Lack of resources (hardware, software, and people) Lack of good planning Technical incompetence Changing business needs and requirements Changes are managed poorly Lack of best practices The chosen technology changes Ill-defined responsibility of team members Lack of communication among team members Project Success • • • • • • • • • • • • • • Strong support from the top management A sound methodology for the project Tactical and technical leadership by competent people User involvement in each activity Experienced project manager Clearly defined business goals Clearly defined project scope Feedback mechanism Sufficient resource allocation Adequate communication channels Troubleshooting capabilities Reliable estimates Clearly specified deadlines Parties sticking to the commitment Project Management Team • The people who work together on a project are referred to as a team. • A team is a cohesive group of one or more related roles and/or subordinate teams that collaborate to perform a cohesive set of tasks. • The achievement in the project depends on the collective effort of top-level management, the project manager, and the members of the project team. • Teamwork refers to a group of people working together in order to achieve a common goal. • Software work products are the results of teamwork. Project Management Team • They require skill, knowledge, and tact on the part of the leader. • There must be a strong communication channel among team members. • Organizations must develop a culture of team building. • Attitudes, interaction patterns, skills possessed by members, methods used to work on tasks, and individual contributions all contribute to the team culture. • Every team may be different from the others in the way it handles its tasks. • A project management team typically consists of Project Manager , Configuration Manager , Metrics Analyst, Process Engineer, Quality Engineer, Scheduler, Technical Leader and so on. • The team performs the overall (administrative) management and risk management for a single project. Team Structures • A team structure could consist of a number of teams, each with a team leader. • Each team and its members have an identified expertise or skill that is needed to complete the tasks. • Usually, the team is headed by the project manager. • There are three types of team structure: – Chief Programmer Team Structure – Hierarchical Team Structure – Egoless Team Structure Chief Programmer Team Structure • Chief programmer team structure Consists of : – A Chief Programmer, – Programmers, – Backup Programmers – A Programming Librarian • It is a centralized automatic structure in which all information passes through the chief programmer. • The chief programmer breaks down the task into small tasks and assigns them to the programmers and team members. • After the completion of each task, he verifies and integrates the work products. Chief Programmer Team Structure Chief programmer Back-up programmer Librarian Programmers (a) Structure (b) Communication path Figure 3.2: Chief programmer team structure Hierarchical Team Structure • Hierarchical Team Structure Consists of: – Programmers – Database Manager – Network Administrators – Testers and so on • The project manager is responsible for handling the project activities. • There will be senior programmers or project leaders who report to the project manager. • The senior programmers or project leaders will then be responsible to the project team members. • The project manager will coordinate with the project leaders to solve the problems relating to the project. Hierarchical Team Structure Project manager Senior programmers Junior programmers (a) Structure (b) Communication path Figure 3.3: Hierarchical team structure Egoless Team Structure • The egoless team structure is also known as the democratic team structure. • It does not enforce any formal team hierarchy • The manager provides the administrative leadership. • Leadership rotates among different team members at different times, which becomes the responsibility of the individual with the abilities that are currently needed. • The democratic organization structure leads to higher morale and job satisfaction. • Consequently, it suffers from less manpower turnover. • People are in different knowledge areas and have different experience levels. • Here, everybody can communicate with everybody. Egoless Team Structure (a) Structure (b) Communication path Figure 3.4: Egoless team structure Project Organization • There are several methods for allocating tasks to a team in an organization. • Typical structures are – Project Format, – Functional Format – Matrix Format Project Format • The project development staff members are divided based on the project for which they work. • Each project has its own team and all the necessary resources. • The project team is assigned to start and finish the project. • It will be responsible for planning, requirement analysis, design, development, testing, deployment, and maintenance. • The project manager has the decision-making authority. The longevity of the team depends on the project duration. Project Format Top management Project team 1 Project team 2 ... Figure 3.5: Project format Project team n Functional Format • Teams are made on the basis of functional competency to which they belong. • Different teams perform different tasks of the project and the work products pass from team to team till the completion of the project. • For example, requirement analysis will be performed by the requirement team, design by the design team, and so on. Functional Format Top management Functional groups Project progress Planning Project team 1 Analysis Project team 2 Design . . . Coding Testing Deployment Maintenance Figure 3.6: Functional format Project team n Matrix Format • It is a multidimensional structure which takes the best of the project format and the functional format. • The functional structure is designed for each project and it then proceeds in the project format. • Each development project is assigned to a project manager. • The project manager participates in most of the activities of product development. • People with similar specialization are pooled for work assignments. • Each specialist may have to work under several managers to perform his job. Matrix Format Top management Product manager 1 Analysis Design Coding Testing Sub projects Sub projects Sub projects Sub projects Product manager 2 Product manager n Figure 3.7: Matrix format Maintenance Sub projects Project Manager • Is the person who has the overall responsibility for the successful planning, execution, monitoring, control, and closure of a project. • The project manager is responsible for making decisions, handling risks, and minimizing uncertainty in product development. • Project managers use project management software to organize their tasks and workforce. • Project manager is the one who tackles all the project-related issues at both development and customer site. • During project management, project manager coordinates and communicates with upper-level managers and lower-level engineers working on the project. Project Manager’s Activities • • • • • • • • • • • • • • • • • Defining project scope, goals, and deliverables that support the business goals Project planning and sequencing Planning resources and budget Identifying and resolving the issues and conflicts within the project team Developing schedules, project timelines, and milestones Time and cost estimation Developing and delivering proposals, documentation, and presentations Identifying and resolving risks Monitoring and reporting progress reports Team leadership to coach, mentor, motivate, and supervise the stakeholders Strategic planning and influencing Business relationships for project success Performing scalability, interoperability, and portability analysis Controlling quality and defining parameters to achieve a quality product Conducting project postmortems and preparing a recommendations report in order to identify the successful and unsuccessful project elements Developing best practices and tools for project execution and management Managing the client relationship Project Manager’s Roles and Skills • Role – Leader – Manager – Facilitator – Mentor • Skills – Personal Skills – Technical Skills – Managerial Skills – Adoptive Skills Project Life Cycle • A project life cycle is a collection of project phases. • A typical project life cycle has four major phases, – Initiation – Planning – Execution – Closure • A project must successfully complete each project phase before proceeding to the next phase. Project Life Cycle Project success and review Project closing Monitoring and control Project initiation Project life cycle Project execution Figure 3.8: Project life cycle Project definition Project planning Detailed planning Project Initiation • Project is initiated by defining its purpose and scope, the justification for initiating it, and the solution to be implemented. • Once the project is confirmed, a project team is formally introduced that will work on the client's project. • A project plan is developed that defines the critical aspects of the project. • This project plan focuses on the identification of stakeholders, assumptions, contingencies, and risks. • Business objectives are set with minor and major milestones and success criteria for the project. Project Planning • The planning phase is considered the most important phase in the project life cycle. • A more detailed project plan with resource requirements, financial issues, quality parameters, and acceptance criteria is defined. • This phase minimizes the time, cost, confusion, and rework during the execution of the project. • It defines the project activities to be performed, the products that will be produced, and how these activities will be carried out and managed. • This phase also defines the major tasks. • It more accurately estimates the time, resources, and cost required and provides a framework for management review and control. Project Execution • In this phase, the deliverables are physically built and presented to the customer for acceptance. • Project management processes are undertaken to monitor and control the construction of deliverables in the project. • These processes include time, cost, quality, change, risks issues, suppliers, customers, and communication management. • Once all the deliverables have been produced and the customer has accepted the final solution, the project is ready for closure. Project Closure • It is the last major phase of the project life cycle . • The project closure phase puts emphasis on releasing the final deliverables to the customer, handing over the project documentation to the business, terminating supplier contracts, releasing project resources, and communicating the closure of the project for all stakeholders. • The organization records the lessons learned in the project, which will help the future project teams. Project v/s Product Life Cycle • Project life cycle and product life cycle both are separate processes used in every organization. • Project is executed to produce a product and product is the outcome of a project. • The product life cycle starts with a business plan with several ideas or features to be incorporated in the software product. • Software product is then developed and installed in customer site for operation. • During its operational life, it goes through maintenance activities and finally it is reengineered on modern platform. • The project life cycle goes through a series of phases to develop the product. • Project life cycle defines the tasks to be accomplished in each phase and a team is responsible for each phase defined. Project v/s Product Life Cycle Concep t Initiating Product development Plannin g Operation and maintenance Retiremen t Executing Product life cycle Closing Project life cycle Task Control Progress and monitoring Development process Figure 3.9: Relationship between project life cycle and product life cycle Project Management Process • The project management process concentrates on planning and managing a series of activities that need to be accomplished within a specific time and a budget. • Coordination among all these activities requires a systematic process for the success a project. • Project management processes govern project management activities, such as project feasibility, quality, timeliness, budget, efficiency, and resource mobilization. • The main focus of the project management process is to execute the development process in an optimal manner. Project Management Process • The project management process is a series of actions directed toward a particular result. • The Project Management Book of Knowledge (PMBOK) defines five project management process groups: – Initiating, – Planning, – Executing, – Monitoring and Controlling, – Closing. • Each of the five project management process groups is characterized by the completion of a certain task in the project. • Team members complete each phase of the project management process before beginning the next phase. Software Configuration Management • Software configuration management is concerned with identification, tracking, and change of control of software configuration. • Software configuration management (SCM) or configuration management (CM) is the discipline of identifying the configuration of a system at any time for the purpose of systematically controlling changes to the configuration throughout the system life cycle. • The purpose of CM is to establish and maintain the integrity of a software product throughout software the development life cycle. • The CM process improves product visibility, product protection, product control, customer confidence, and team communication. • A systematic CM process reduces rework, confusions, and project risks Software Configuration Management • The project management process provides a systematic CM plan and monitors the status of the SCM process. • The configuration management officer (CMO) implements and maintains the CM process according to the CM plan. • The CMO coordinates, supports, and performs the CM activities and reports to the project manager. • The Configuration Control Board (CCB) approves and disapproves the changes to be performed in the product. • The CCB consists of technical and administrative representatives for configuration planning and execution. • The approved changes are performed through the development process. Software Configuration Management Configuration management process Planning data Project management process CM plan Work products, change requests Status reports and audits results Approved change requests, controlled work products Product development process Figure 3.10: Software configuration management process Software Configuration Management • The CM process consists of the following four activities – Configuration identification – Configuration change control – Configuration status accounting – Configuration auditing Configuration identification Configuration change control Configuration status accounting Configuration audits Figure 3.11: Configuration management activities Configuration Identification • A software configuration item (SCI) or configuration item (CI) is a work product that is designated for configuration management. • The SCI activity identifies items to be controlled, establishes identification schemes for the items and their versions, and establishes the tools and techniques to be used in acquiring and managing controlled items. • The work products in SCI may include plans, process descriptions, requirements, design data and models, product specifications, source codes, compilers, product data files, etc. • The status of the CIs at a given point in time is called baseline. • Each new baseline is the sum total of an older baseline plus a series of approved changes done on the CI. • A baseline together with all approved changes to the baseline represents the current configuration. Configuration Change Control • The purpose of software configuration change control (CC) is to manage changes during the software life cycle. • The activities of CC are to identify what changes to make, the authority for approving changes, and support for the implementation of those changes. • The outcome of CC is useful in measuring change traffic, breakage, and aspects of rework. • A change request (CR) for changes to software configuration items may be originated by anyone at any point in the software life cycle and may include a suggested solution and requested priority. • The CRs are usually recorded on the software change request (SCR) form. • Once an SCR is received, a technical evaluation is performed to determine the extent of modifications that would be necessary should the change request be accepted. • An established authority, Configuration Control Board (CCB), will evaluate the technical and managerial aspects of the change request and accept, modify, reject, or defer the proposed change. Configuration Status Accounting • The software configuration status accounting records and reports the information needed for effective management of the software configuration. • It is the bookkeeping process of each release for CIs. • The CI are identified, collected, and maintained for the status accounting. • The reported information can be used by the development team, the maintenance team and for project management and quality assurance activities. • A database is maintained for providing the status accounting of configuration requests. • This procedure involves tracking what is in each version of software and the changes that lead to this version. • It keeps a record of all the changes made to the previous baseline to reach the new baseline. Configuration Auditing • Configuration auditing determines the extent to which an item satisfies the required functionalities. • Configuration audit is performed to evaluate the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures. • Auditing is performed according to a well-defined process consisting of various auditor roles and responsibilities. • Expertise of people is required and some automated tools also support the planning and conduct of an audit process. Risk Management • Risk is an unfavorable situation that may lead to an undesirable outcome. • Potential problems or losses are also called risks. Risk may include product estimation, business issues, customer, process, technology, development environment, and project planning. • Risk management is a proactive approach for minimizing the uncertainty and potential problems associated with a project by providing insights to support informed decision making. • It is an ongoing activity from the initiation to the retirement of a software product. Risk Management • Software risk management is necessary for the following reasons: – To reduce the rework caused by missing, erroneous, or ambiguous requirements, design, or code, which typically consumes 40–50% of the total cost of software development – To avoid software project disasters, including overrun of budgets and schedules, defect-ridden software products, and operational failures – To stimulate a win-win software solution where the customer receives the product they need and the vendor makes the profits they expect. – To keep provision for the detection and prevention mechanisms of risks. Risk Categories • Risks basically threaten the project, product, and hence the business. • There are basically three categories of risk occurrence: – Project Risks – Products Risks – Business Risks Risk Management Activities • Some risks have great effect and some risks may be tolerated. • Risks must be analyzed to find their potential and remedial actions. • The risk management process includes the following activities: – Risk Identification – Risk Analysis – Risk Planning – Risk Monitoring and Control Risk Management Activities Risk identification Risk analysis and evaluation Risk planning Risk monitoring and control Potential risks Risk influences Risk resolution plan Risk assessment Figure 3.11: Risk Management Process Risk Identification • Potential risks are identified with their consequences, effects, sources, root causes, and categories. • The output of this activity is a list of project-specific risks that have the potential of compromising the project's success. • There are various types of risks that may arise. – – – – – – Requirements Risks Technology Risks Organizational Risks Tools Risks Human Resources Risks Estimation Risks and so on. Risk Identification Techniques • Brainstorming is a preferred technique because of its flexibility and capability of generating a wide and diverse range of risks. • Risk identification is performed on the basis of historical data, theoretical analysis, empirical data and analysis, informed opinions of the project team and other experts, and the concerns of stakeholders. • Other techniques are: – – – – – – Interviewing Reporting Decomposition Assumption analysis Critical Path Analysis Utilization of Risk Taxonomies Risk Analysis • Each risk is analyzed independently by examining the identified risk and assessing its impact, probability, risk exposure, and seriousness. • The list of risks is then grouped and prioritized/ranked based on the results of risk analysis. • Risk prioritization helps in resource allocation and management. – RE = Probability (UO) x Loss (UO), where RE is risk exposure and UO is unexpected outcome. Risk Planning • Once the risks are identified and prioritized, an appropriate risk management plan is developed for modifying the risks. • General risk management strategies are – Risk Avoidance – Risk Minimization – Risk Acceptance – Risk Transfer Risk Monitoring and Control • Risk monitoring and control ensures new risks are detected and managed. • Risk action plans are implemented to reduce the impact of risks. • Policies and standards compliances are regularly carried out and the standard performance is reviewed to identify the opportunities for improvement. • The monitoring process provides assurance that appropriate controls have been taken for the organization’s activities and that the procedures are in place. • If needed, changes are made in the organizational environment to cope with risks. Summary • • • • • • • • • Effective project management is the key to project success and organizational growth. There are four essential elements of software project management: project, people, process, and product. The project manager is a person who has the overall responsibility for project success. There are three types of team structure: chief programmer, hierarchical, and egoless team structures. A project life cycle is a collection of project phases: initiation, planning, execution, and closure. It has five project management process groups: initiating, planning, executing, monitoring and controlling, and closing. The configuration management process consists of four activities: configuration identification, configuration change control, configuration status accounting, and configuration audits. Risk management is a proactive approach for minimizing the uncertainty and potential problems associated with a project by providing insights to support informed decision making. The risk management process includes risk identification, risk analysis, risk planning, and risk monitoring and control. Chapter - 4 Project Planning and Estimation Introduction • A successful project is possible only through good project planning. • Project planning concentrates on estimating resources, time, budgets, and monitoring and controlling the activities of project management. • At the beginning of project planning, all the project constraints, such as staff and other requirements, overall budget, starting and ending dates, schedule, etc., are defined and the project manager has their details. • During project planning, future estimates are planned for an effective project management. 67 Introduction • The project plan provides the basis for performing and managing the activities of a software project and addresses the commitment to stakeholder’s resource constraints and capabilities of the software project. • A bad project management plan leads to project failures and sometimes projects are cancelled. • The main goal of the project plan is to establish a pragmatic strategy for controlling, tracking, and monitoring a project. • A typical project plan includes project scope, project estimates, schedule, requirements, risk management plan, control strategy, and various other plans. 68 Project Planning Activities • The project planning activities include both business-level and technicallevel planning. • Business-level planning addresses the relationships with the customer. • Includes the project and business objectives, proposal writing, analysis and inclusion of functional requirements, product demand and its scope, and legal issues. • Technical-level planning focuses on performing the technical activities. • concentrates on technical issues, such as selection of the development life cycle model, planning documentation methods and tools, risk management planning, estimations, financial planning, resource allocation and management, team structuring and organization, software development life cycle plan, documentation plan, configuration management plan, quality assurance plan, transition plan, and so on. 69 Project Planning Activities • A project plan includes various activities related to project management. • A general project plan includes the following project planning activities, beginning with project initiation to project completion. – Defining business objectives and project scope – Project estimations – Project scheduling – Resource planning – Financial planning – Staffing-level planning – Development planning – Project monitoring and control plan – Risk management planning – Quality assurance planning – Configuration management planning – Miscellaneous plans 70 Project Planning Activities • Defining business objectives and project scope: – Business objective gives a clearly defined target that will be achieved through proper planning by the team. – Project scope defines the parameters of the project with constraints for what the project will attempt to do. – The need for product development and its demand in the market must be stated. – A proposal is written that will work as a contract for the project. – Functional requirements are analysed to prepare a good project plan. – Legal issues, such as patent, copyright, liability, warranty etc., Must be specified well in advance. 71 Project Planning Activities • Project estimations: – Project estimation includes cost, size, duration, project complexity, and resource requirements. – The cost involves both direct cost (i.e. efforts made directly on the project; for example, time spent on developing the code, testing, etc.) and indirect cost (i.e. the amount spent on telephone, Internet, etc.). – Estimation of size is the basis of project delivery and other estimations. – Some projects are very simple to develop and other projects are so complex that they may take considerable amount of time for development. – Project complexity determines the project duration and resource requirements. 72 Project Planning Activities • Project scheduling: – It emphasizes defining the start and completion time for each task in the project. – The tasks are decomposed into manageable pieces that can be easily developed within the stipulated time and constraints. – There are various tools and techniques used for project scheduling, such as: Work Breakdown Structures (WBS), Activity Network Diagram (AND), PERT-CPM, Gantt charts, and so on. 73 Project Planning Activities • Resource planning: – Usually multiple projects run in an organization. – Each project manager will try to reserve the resources in advance according to the project schedule and functional requirements. – The resources can be hardware, software, and people. Most of the organizations start recruiting people in advance. 74 Project Planning Activities • Financial planning: – Every project is concerned with financial plans. – These plans provide the assurance that the project has the funds to accomplish its objectives. – A cost estimation process is used to determine how money will be spent in software project management. – A cost-benefit analysis is carried out to estimate the budget for personnel expenses, purchase orders, automated items, and purchase of other items. 75 Project Planning Activities • Staffing-level planning: – Staffing-level planning organizes the team and accurately estimates the number of personnel required for the project. – A module-wise estimation is done to avoid resource conflicts. – Due to the lack of engineers, organizations may use their skills and expertise in multiple projects. • Development planning: – A software project is developed as a series of technical activities, such as analysis, design, coding, testing, verification and validation, deployment, documentation, training, maintenance, and so on. – The project plan provides details on who will perform which task, how it will be performed, what support tools are required, and various such activities. – The software development life cycle is also chosen before proceeding to development planning. 76 Project Planning Activities • Project monitoring and control plan: – The project monitoring plan assesses the progress of a project as to whether it is moving in the right direction or not. – This plan helps in controlling the execution of activities. – The project is monitored according to the project schedule for cost, time, efforts, and defects. • Risk management planning: – The risk management plan assures that problems are discovered in early stages and appropriate strategy has been made to handle the risk. – While managing risks, the cost, quality, and schedule estimates should be within constraints. – Most organizations put their efforts to minimize risks. 77 Project Planning Activities • Quality assurance planning: – Product milestones are rigorously tested to find uncovered defects. – Quality assurance aims to prevent errors and assures that the delivered product exhibits high quality. – There are some standards that provide certain guidelines and procedures to produce a quality product. 78 Project Planning Activities • Configuration management planning: – The configuration management plan encompasses the discipline that addresses identifying and controlling changes to the work products. – The configuration management plan includes configuration identification, configuration change control procedure, monitoring and tracking changes, and auditing of the changes. • Miscellaneous plans: – There are various miscellaneous plans, such as process tailoring, special testing plan, verification and validation plan, tools and environment plan, delivery plan, and maintenance plan. 79 Software Metrics and Measurements • Software metric is the unit of measurement of software product, project, and process attributes. • Software metrics are the measures that are used to quantify products, processes, and projects. • Measuring software process or project provides a foundation to predict the parameters of project planning. • Effective use of metrics helps to measure product quality, manage projects, and assess processes. • Metrics provide necessary information for monitoring the progress of the project. 80 Software Metrics and Measurements • There are three types of metrics used in software projects: – Product metrics, – Process metrics, – Project metrics. • Product metrics: – Product metrics are used to measure product characteristics such as product quality factors, such as reliability, maintainability, defects, and product operational characteristics. 81 Software Metrics and Measurements Process metrics: – Process metrics assess the effectiveness of software processes and ensure conformance of standards and guidelines. – Process metrics provide some attributes that help to improve the process maturity. Project metrics: – Project metrics are used to monitor the project plan, track progress, and estimate the project attributes. – It measures the size, cost, efforts, schedule, and risks. – Generally, projects are assessed on the basis of past project experiences and data. 82 Project Size Estimation • Size measurement is the initial step for estimating the other attributes of software. • It is a direct measurement, which is based on the problem size. • Programs written in any programming language have some size, whether the program is an assembly code, a high-level language code, a GUI code, or a component of a programming language. • There are various units of size measurement, such as – Lines of code (LOC), – Function point (FP), – Token count (TC), – Fuzzy logic sizing, – Object point (OC), – Standard component sizing, and many more. 83 Project Size Estimation Lines of Code – A line of code (LOC) metric is based on the measurement of the source lines of the code in a program. – It is simply measured by counting the program header, declarations, executable, and non-executable lines in the source program. – Comments lines, blank lines, and header lines are usually not considered during the LOC measurement. – LOC is generally counted in kilo (thousand) line of codes (KLOC) per person-month (PM). 84 Project Size Estimation Lines of Code – Size measurement of the source lines helps to measure Defects per KLOC, Errors per KLOC, Dollars per KLOC, Pages of documentation per KLOC, and so on. – Size estimation is performed by decomposing a problem into manageable modules. – Small-size modules can easily be predicted for LOC counting. – The overall project size is the sum of the sizes of all modules in the project. 85 Project Size Estimation Example of LOC /* This program finds a substring in a given start = atoi(argv[2]); string */ end = atoi(argv[3]); strncpy(temp,argv[1]+start,end); #include<stdio.h> temp[end]='\0'; #include<conio.h> printf("entered string : %s\n ",argv[1]); #include <string.h> printf("\nsubstring : %s ",temp); } void main(int argc,char * argv[]) else { char *temp; printf("incorrect arrgument "); int start, end ; getch(); clrscr(); } if(argc==4) { LOC = LOC counted as 17. Figure 4.1: A program to find a substring in a string 86 Project Size Estimation Lines of Code : Disadvantages – The value of LOC measurement varies with the programmer, programming language, and the project complexity. – Every programmer has different technical skills, programming styles, and logical ability. Therefore, the LOC value may differ during estimation. – Different programming languages have their different programming techniques. The actual number of the source lines may vary in programs. – LOC only considers the source code. But some projects are highly complex and they need much effort at the design and analysis phases. 87 Project Size Estimation Lines of Code : Disadvantages – LOC is not suitable for component or reuse- based programming technologies where the components are considered as the unit of measurement. – Also, it is very difficult to accurately estimate the project size from the requirement specification or project nature. – There is a lack of standard tools for counting the source lines. – The quality of code is the main focus for quality software, which is poorly considered during size measurement. 88 Project Size Estimation Function Point Analysis – To overcome the limitations of the LOC-based measurement, Alan Albrecht proposed another size estimation technique called the function point (FP) analysis. – The size of the project is estimated on the basis of functions or services requested by the customer in the requirement specification. – It is a structured technique that decomposes systems down into smaller components so that they can be better understood and analysed. – It relies on the product features delivered to the customer. – The actual number of function points can be verified at the end of each stage of a project. 89 Project Size Estimation Function Point Analysis : Advantages – FP measurement is programming language independent and programmer independent. – It does not have any constraint specific to the hardware, procedural or non-procedural languages. – It is very easy to predict the function points in the final product from the requirement specification. – More accurate estimates are possible in the early stages of software development. – An important aspect of FP is the consideration of user’s view through requirement specification or problem description along with developers view during requirement decomposition for the FP analysis. 90 Project Size Estimation Function Point Analysis – FP-based estimations are based on the following five information domain values and their complexities in a particular project. Number of inputs Number of outputs Number of inquiries Number of internal logical files Number of external interfaces – The value of each of these five information domains is collected and a subjective evaluation is performed to categorize them as simple, average, and complex. 91 Project Size Estimation Function Point Analysis – There are certain weights assigned at each complexity level to the information domains: Information domain Weights Simple Average Complex Number of inputs 3 4 6 Number of outputs 4 5 7 Number of inquiries 3 4 6 Number of internal logical files 7 10 15 Number of external interfaces 5 7 10 Table 4.1: Information domains and their weights 92 Project Size Estimation Function Point Analysis: Method 1. Calculate the unadjusted function point (UFP). It is calculated by simply counting the value of each information domain and multiplying it by an appropriate weight at its complexity level. 2. Compute the complexity adjustment attributes (CAA). The CAAs are complexity attributes (14) that can vary from project to project. They are computed using the following relationship: CAA = [0.65 + 0.01 × ∑ CAAi], where CAA is the complexity adjustment attributes. 3. Then, compute FP = UFP × CAA. 93 Project Size Estimation Example 4.1 Compute the FP value for the grade calculation of students. Assume that it is an average complexity size project. The information domain values are as follows: number of inputs = 13, number of outputs = 4, number of inquiries = 2, number of external files = 5, number of interfaces = 2. The total value of complexity adjustment attributes is 13. 94 Project Size Estimation Solution 4.1: Calculation of UFP for average complexity size project: = (Number of inputs) × 4 + (Number of outputs) × 5 + (Number of inquiries) × 4 + (Number of files) × 10 + (Number of interfaces) × 7 = 13 × 4 + 4 × 5 + 2 × 4 + 5 × 10 + 2 × 7 = 175 Compute CAA, which has the value = 13 = 0.65 + 0.01 × (13 × 3) = 0.65 + 0.01 × 39 = 1.04 Compute FP = UFP × CAA = 175 × 1.04 = 182 Thus, the total value of FP is 182. 95 Project Size Estimation Function Point Analysis: Benefits • It accurately estimates the project cost, project duration, and project staffing size. • It is helpful to monitor the productivity level of a project. • It is also useful in managing change of scope and in communicating the functional requirements. • The FP computation is useful to find other metrics, such as project defect per FP, cost per FP, FP per hour productivity, and so on. 96 Project Size Estimation Feature Point Metric • The feature point metric is an extension of the function points that includes the algorithmic complexity of the software. • An algorithm is a step-wise procedure with defined rules which are designed to solve a significant computational problem. • For example, a sine routine can be considered as an algorithm. Each algorithm is assigned a weight ranging from 1 (elementary) to 10 (sophisticated algorithms). • The feature point metric is the weighted sum of algorithms plus the function points. • It is especially useful for systems with a few inputs/outputs and a high algorithmic complexity, such as mathematical software, CAD, AI, discrete simulations, and military applications. 97 Effort Estimation • Effort estimation predicts how much time is required to complete a project, how much it costs, and how many engineers are required for completing the project. • The effort estimation is important for cost-benefit determination, project scheduling, and monitoring and control. • The effort estimation is a continuing activity that starts with project proposal. • More accurate estimates are possible as the project proceeds, i.e., during the feasibility study, requirement analysis, design, and subsequent phases. • There are various factors that affect cost estimation such as, capability of engineers, product complexity, product size, availability of delivery time, required reliability, and the level of technology. 98 Effort Estimation Approaches The top-down approach • The top-down approach estimates the project cost globally by estimating the system level costs of the overall project size. • The system level cost includes the cost of resources for product development, configuration management, quality assurance, integration, installation, and deployment. • It requires minimum project details and it is usually faster and easier to adopt. • This approach does not consider other technical requirements for specific modules. • In case of underestimation or overestimation, an inaccurate result of effort estimate may be produced that may lead to an under-budget or over-budget project. 99 Effort Estimation Approaches The bottom-up approach • In the bottom-up approach, the cost of individual modules is estimated and then all these costs are integrated to estimate the overall project cost. • This approach can produce more accurate estimate due to the consideration of discrete parts for estimation. • It is more stable as estimation errors in modules can be rectified and balanced. But someone may overlook the system-level costs, such as quality assurance cost, configuration management cost, etc. • Size estimate is the primary need for both top-down and bottom-up approaches. 100 Effort Estimation Techniques • There are different techniques for effort estimation. Some of the most popular estimation techniques are – Estimation by analogy, – Delphi estimation, – Algorithmic cost modelling, and – Analytical techniques 101 Effort Estimation Techniques Estimation by analogy • The estimation-by-analogy technique is based on the experiences of the past projects. • The estimation-by-analogy method involves an expert for finding the analogous situations so as to give his opinion. • This technique follows a top-down estimation approach. • The project to be assessed is characterized on certain factors that become the basis for finding similar or analogous projects which have been completed and their efforts are known. • Then the proposed project is compared with the previously completed similar projects. • These effort values are then used with some adjustments to estimate the efforts for the proposed project. 102 Effort Estimation Techniques Estimation by analogy: Problems • The estimators have to determine how best they can characterize the projects in terms of application domain, the number of inputs, the number of distinct entities referenced, the number of screens, and so on. • Another problem after project characterization is to determine similarity: how much confidence we can place in the analogies and how many projects need to be compared. • A few analogies might lead to maverick projects being used and too many analogies might lead to dilution of the effect of the closest analogies. • Lastly, it is very difficult what variables should be considered to estimate the new projects with known effort values from the analogous projects. • Means and weighted means can give more influence to the closer analogies. 103 Effort Estimation Techniques Delphi estimation • Delphi cost estimation is a group consensus technique that relies on expert judgment and follows the top-down estimation approach with certain features of the bottom-up approach. • The coordinator interacts with experts for providing necessary information and documents. • The estimators go through the requirement document and make their estimates anonymously. • The coordinator compiles the estimation reports and distributes a summary of the estimation responses. • The estimation report specifies any unusual characteristic noted by the estimators. • The coordinator can call a group meeting of experts to discuss points if the estimates vary widely. • The estimation is iterated for as many rounds as appropriate for an accurate estimate. 104 Effort Estimation Techniques Delphi estimation: Benefits • The experts use their experiences of the past projects to assess the factors in the proposed project. • Each expert applies their distinguished expertise and knowledge to assess the project. • There is less chance for bias due to group consensus. • There are rare chances of bias if only a few experts, maybe one or two, are involved in the estimation process. Delphi estimation: Problems • The team may take pain in gathering some information that may not be useful for estimation in the proposed project. • This method is very difficult to quantify. • It is hard to document the factors used by the experts or expert groups. 105 Effort Estimation Techniques Algorithmic cost models • Algorithmic cost models use size estimation model, which is based upon certain project parameters. • The value of these parameters depends on the project type: – Organic projects are very simple and can be developed with a small-size team. The team should have good application experience and should be familiar with the application environments. A simple data processing system is a good example of the organic category. – Embedded projects are very complex and have stringent constraints, for example, flight control system for aircraft. – Semidetached projects are intermediate in size and complexity. The team should have mixed experience to meet the mix of rigid and less-than-rigid requirements. A transaction processing system with fixed requirements for terminal hardware and database software is an example of the semi-detached category. 106 Effort Estimation Techniques COCOMO Model • COCOMO (COnstructive COst MOdel) is an algorithmic cost estimation technique proposed by Boehm, which works in a bottomup manner. • It is designed to provide some mathematical equations to estimate software projects. • These mathematical equations are based on historical data and use project size in the form of KLOC. • The COCOMO model uses a multivariable size estimation model for effort estimation. • A multivariable model depends on several variables, such as development environment, user involvement, memory constraints, technique used, etc. 107 Effort Estimation Techniques COCOMO Model • A single variable model is based only upon the size of the project, which is given as Effort = a × Size b • The constants a and b are derived from the historical data of the past projects in the organizations. • The values of a and b in COCOMO model vary across the three categories of projects: organic, semidetached, and embedded, as shown in Table 4.2. Project category a b Organic 3.2 1.05 Semidetached 3.0 1.12 Embedded 2.8 1.20 Table 4.2: The values of a and b constants 108 Effort Estimation Techniques COCOMO Model • COCOMO estimation is a family of hierarchical models, which includes – Basic, – Intermediate, and – Detailed COCOMO models. • Each of the models initially estimates efforts based on the total estimated KLOC. 109 Effort Estimation Techniques Basic COCOMO Model • The basic COCOMO model estimates effort in a function of the estimated KLOC in the proposed project. • The basic COCOMO model is very simple, quick, and applicable to small to medium organic-type projects. It is given as follows: Development effort (E) = a × (KLOC) b Development time (T) = c × (E) d • Where a, b, c, and d are constants and these values are determined from the historical data of the past projects. • The development time (T) is calculated from the initial development effort (E). 110 Effort Estimation Techniques Basic COCOMO Model • The values of c and d for organic-, semidetached-, and embedded-type projects are shown in Table 4.3. Project category c d Organic 2.5 0.38 Semi-detached 2.5 0.35 Embedded 2.5 0.32 Table 4.3: The values of c and d constants 111 Basic COCOMO Model • Example 4.2 Assume that a system for simple student registration in a course is planned to be developed and its estimated size is approximately 10,000 lines of code. The organization is proposed to pay Rs. 25000 per month to software engineers. Compute the development effort, development time, and the total cost for product development. 112 Basic COCOMO Model Solution 4.2: • The project can be considered an organic project. Thus, from the basic COCOMO model, Development effort (E) = 3.2 × (10) 1.05 = 35.90 PM Development time (T) = 2.5 × (35.90) 0.38 = 9.747 months • Total product development cost = Development time × Salaries of engineers = 9.747 × 25000 = Rs. 2,43,675 113 Effort Estimation Techniques Intermediate COCOMO Model • Boehm has introduced 15 cost drivers, considering the various aspects of product development environment. • These cost drivers are used to adjust the project complexity for estimation of effort and these are termed as effort adjustment factors (EAF). • These cost drivers are classified as computer attributes, product attributes, project attributes, and personnel attributes. • The intermediate COCOMO model computes software development effort as a function of the program size and a set of cost drivers. • The intermediate COCOMO model estimates the initial effort using the basic COCOMO model. Then the EAF is calculated as the product of 15 cost drivers. 114 Effort Estimation Techniques Intermediate COCOMO Model • Total effort is determined by multiplying the initial effort with the total value of EAF. The computation steps are summarized below. • Development effort (E): –Initial effort (Ei) = a × (KLOC) b –EAF= EAF1 × EAF2 ×... × EAFn –Total development effort (E)= Ei × EAF • Development time (T) = c * (E) d 115 Intermediate COCOMO Model Cost drivers Cost drivers Product attributes Software reliability (RELY) Size of database (DATA) Product complexity (CPLX) Hardware attributes Run-time performance constraints (TIME) Memory storage constraints (STORE) Virtual machine volatility (VIRT) Required turnabout time (TURN) Personnel attributes Analyst capability (ACAP) Applications experience (AEXP) Programmer capability (PCAP) Virtual machine experience (VEXP) Programming language experience (LEXP) Project attributes Modern programming practices (MODP) Use of software tools (TOOL) Development schedule (SCHED) Very low Low Ratings Nominal High 0.75 0.70 0.88 0.94 0.85 1.00 1.00 1.00 1.15 1.08 1.15 1.40 1.16 1.30 1.65 - 0.87 0.87 1.00 1.00 1.00 1.00 1.11 1.06 1.15 1.07 1.30 1.21 1.30 1.15 1.66 1.56 - 1.46 1.29 1.42 1.21 1.14 1.19 1.13 1.17 1.10 1.07 1.00 1.00 1.00 1.00 1.00 0.86 0.91 0.86 0.90 0.95 0.71 0.82 0.70 - - 1.24 1.24 1.23 1.10 1.10 1.08 1.00 1.00 1.00 0.91 0.91 1.04 0.82 0.83 1.10 - Very high Extr a high 116 Intermediate COCOMO Model Example 4.3 Suppose a library management system (LMS) is to be designed for an academic institution. From the project proposal, the following five major components are identified: Online data entry 1.0 KLOC Data update 2.0 KLOC File input and output 1.5 KLOC Library reports 2.0 KLOC Query and search 0.5 KLOC The database size and application experience are very important in this project. The use of the software tool and the main storage is highly considerable. The virtual machine experience and its volatility can be kept low. All other cost drivers have nominal requirements. Use the COCOMO model to estimate the development effort and the development time. 117 Intermediate COCOMO Model Solution 4.3: The LMS project can be considered an organic category project. The total size of the modules is 7 KLOC. The development effort and development time can be calculated as follows: Development effort Initial effort (Ei) = 3.2 × (7) 1.05 = 24.6889 PM EAF = 1.16 × 0.82 × 0.91 × 1.06 × 1.10 × 0.87 = 0.8780 Total effort (E) = Ei * EAF = 24.6889 × 0.8780 = 21.6785 PM Development time (T) = 2.5 × (E) 0.38 month = 2.5 (21.6785) 0.38 month = 8.0469 month 118 Effort Estimation Techniques Detailed COCOMO Model • The detailed COCOMO model inherits all the features of the intermediate COCOMO model for the overall estimation of the project cost. • The detailed COCOMO model uses different effort multipliers (cost drivers) for each phase of the project. • Phase-wise effort multipliers provide better estimates than the intermediate model. • The detailed COCOMO model defines five life cycle phases for effort distribution: – plan and requirement, – system design, – detailed design, – code and unit test, and – integration and test. 119 Effort Estimation Techniques Detailed COCOMO Model • In the detailed COCOMO model, effort is calculated as a function of size in terms of KLOC and the value of a set of cost drivers according to each phase of the software life cycle. • If the project size varies majorly from the value taken in the phase-wise distribution, then interpolation formula can be applied to find the more appropriate percentage value. • The detailed COCOMO model illustrates the importance of recognizing different levels of predictability at each phase of the development cycle. 120 Detailed COCOMO Model Table 4.4: Phase-wise distribution of the development effort and time Project type and size Plan and requirement System design Detailed design Code and unit test Integration and test Percentage-wise distribution of the development effort Organic (2 KLOC) 6 16 26 42 16 Organic (32 KLOC) 6 16 24 38 22 Semi-detached (32 KLOC) 7 17 25 33 25 Semi-detached (128 KLOC) 7 17 24 31 28 Embedded (128 KLOC) 8 18 25 26 31 Embedded (320 KLOC) 8 18 24 24 34 Percentage-wise distribution of the development time Organic (2 KLOC) 10 19 24 39 18 Organic (32 KLOC) 12 19 21 34 26 Semi-detached (32 KLOC) 20 26 21 27 26 Semi-detached (128 KLOC) 22 27 19 25 29 Embedded (128 KLOC) 36 36 18 18 28 Embedded (320 KLOC) 40 38 16 16 30 121 Detailed COCOMO Model Example 4.4 Compute the phase-wise development effort for the problem discussed in Example 4.3. 122 Detailed COCOMO Model Solution 4.4: There are five components in the organic project discussed in Example 4.3: online data entry, data update, file input and output, library reports, query and search. The estimated effort (E) is 21.6785 PM. The total size is 7 KLOC, which is between 2 KLOC and 32 KLOC. Thus, the actual percentage of effort can be calculated as follows: Plan and requirement (%) = 6 + (6 - 6) / (32 - 2) × 7 = 6% Effort = 0.06 × 21.6785 PM = 1.30071 PM System design = 16 + (16 - 16) / (32 - 2) × 7= 16% Effort = 0.16 × 21.6785 PM = 3.46856 PM Detailed design = 24 + (26 - 24) / (32 - 2) × 7 = 25% Effort = 0.25 × 21.6785 PM = 5.419625 PM Code and unit test = 38 + (42 - 38) / (32 - 2) × 7 = 39% Effort = 0.39 × 21.6785 PM = 8.454615 PM Integration and test = 22 + (16 - 22) / (32 - 2) × 7 = 24% = 0.24 × 21.6785 PM = 5.20284 PM 123 Effort Estimation Techniques COCOMO I Model • The basic, intermediate, and detailed COCOMO models are in the category of COCOMO I and these are collectively known as COCOMO 81. • The COCOMO I models were developed to estimate the effort, schedule, and cost of a software project. • The three variations of COCOMO I use different types of parameters for estimation. • These models are helpful to produce repeatable estimations. • It is unable to deal with exceptional conditions, such as exceptional teamwork, exceptional people involved in the estimation process, etc. • Rough sizing of projects and inaccurate cost driver rating will result in an inaccurate estimation. 124 Effort Estimation Techniques COCOMO II Model • COCOMO II is an extension to the original COCOMO 81 model. • Since the development of COCOMO 81, software development techniques have changed. • These changes have changed the development processes from linear to spiral and one-go to incremental way for developing simple to complex projects. • Programming techniques and technologies have moved from conventional to component-based software development. • Thus, a new, enhanced COCOMO II model was proposed to overcome the limitations of COCOMO 81. • It consists of sub-models, each one providing unique features for project planning and design process. These sub-models are called – The applications composition model, – Early design model, – Post-architecture model, and – Reuse model. 125 Effort Estimation Techniques Application Composition Model • The application composition model is best suitable for prototyping projects and projects where there is extensive reuse of components. • It involves prototyping efforts to resolve unexpected risks related to GUI, device interaction, performance, or technology maturity. • The estimation is based on the standard estimates of the developer productivity in object points/months and the use of CASE tools to support development. • The effort estimation in an application is computed as follows: Effort (E) = (∑AP × (1 - %reuse/100))/ PROD • ∑AP is the sum of application points in the system to be developed. PROD is the productivity of programmers from the historical data rated on some scale. • The PROD for the past projects is rated as very low = 4, low = 7, nominal = 13, high = 15, and very high = 50. Effort (E) will be measured in personmonths (PM). %reuse is the percentage of reusable components that will be reused in the application. 126 Effort Estimation Techniques Early Design Model • • • • • The early design model is used when requirements are available but design has not yet commenced. It involves exploration of an alternative architecture or concept of operation. The estimation formula based on simple COCOMO is given as follows: Effort (E) = A × Size B × EAF A and B are constants. The value of A is fixed at 2.94 from a large data set. The value of B varies with the project size and it can range from 1.1 to 1.24, depending on the project complexity, process maturity level, development flexibility, risk resolution processes, and cohesion of the development team in an organization. EAF is the effort adjustment factor based on seven characteristics of projects and processes such as, product reliability and complexity (RCPX), reuse required (RUSE), platform difficulty (PDIF), personnel capability (PERS), personnel experience (PREX), schedule (SCED) and support facilities (FCIL). 127 Effort Estimation Techniques Post-Architecture Model • This model is used once the system architecture has been designed and sufficient information is available for the development and maintenance of the system. • Estimation is determined using the estimation formula of early design model as follows: Effort (E) = A × Size B × EAF • SLOC or FP can be used for determining the project size. • There are 17 instead of 7 multiplicative cost drivers. 128 Effort Estimation Techniques Post-Architecture Model: Multiplicative cost drivers Cost drivers Attributes Category Required system reliability RELY Product Product complexity CPLX Product Required level of documentation DOCU Product Database size DATA Product Percentage of reusable components RUSE Product Execution time constraint TIME Computer Development platform volatility PVOL Computer Memory constraints STOR Computer Analysts capability ACAP Personnel Personnel continuity PCON Personnel Programmer capability PCAP Personnel Programmer experience in application PEXP Personnel Analyst experience in project domain AEXP Personnel Language and tool experience LTEX Personnel Use of software tools TOOL Project Development schedule SCED Project Multisite working SITE Project 129 Effort Estimation Techniques Post-Architecture Model • The following five factors determine the project’s scaling exponent B. The value of these factors is added (for example, here it is 16) and their value in percentage (i.e. .16) is added to 1.01 to get a value of 1.17. Precedentedness --New project --Rated low (4) Development flexibility --No client involvement --Rated very high (1) Architecture/risk resolution --No risk analysis carried out --Rated very low (5) Team cohesion --New team --Rated nominal (3) Process maturity --Process in control --Rated nominal (3) 130 Effort Estimation Techniques Reuse Model • The reuse model focuses on system development with reuse. • It helps to monitor the progress of reuse-based development and guides to the investment for producing reusable assets and reusing them in development. • The cost of system development with reuse involves the cost incurred in design, implementation, generalization, testing, documentation, library support, and integration of reusable assents. • The level of reuse in a system is defined as the total size of the system divided by the size of the reusable components in the system. • The level of reuse can be used to monitor reuse and to estimate the cost, time, quality, and productivity. 131 Effort Estimation Techniques Reuse Model • The cost of system development can be assessed by the cost of system development with reuse and without reuse. • The cost of software can be measured as: Total cost (CS) = Cost of the reused software + Cost of the software without reuse = (Relative cost of the reused software × Reused software) + (Relative cost of the software without reuse × Software without reuse) = (CR × Rѕ ) + (CRW × (1- Rѕ )) = (CR × Rѕ )+ (1× (1- Rѕ )) = 1+ Rѕ (CR - 1) 132 Effort Estimation Techniques Analytical techniques • Halstead has proposed analytical estimation technique based upon certain assumptions about the project. • From the science of Halstead, the length and volume of code can be measured. The length of a code is used to measure the length of the source code program. It is defined as follows: N = N1 + N2 • Where N1 is the total number of operator occurrences, and N2 is the total number of operand occurrences. • The volume metric is used to measure the amount of storage space required for the program. It is defined as: V = N log (n1 + n2) • Where n1 is the number of distinct operators, and n2 is the number of distinct operands that occur in a program. • Analytical estimation is manly useful for estimating software efforts in maintenance, scheduling, and reporting projects. 133 Staffing and Personnel Planning • Project managers fix the staff requirement early in the project because multiple projects may be running in the organization. • The number of staff varies at different times as the project progresses. • The staff requirement increases during the system design, detailed design, coding, and testing times. • The staff requirement decreases during integration, deployment and training, and documentation. • Norden in 1958 analysed several research and development projects and studied the staffing patterns in the software development cycle. • He observed that the staffing pattern can be approximated by the Rayleigh distribution curve as shown in Figure 4.2 and the Rayleigh curve can represented by the equation: E = K/t²d × t × e-t²/2t²d 134 Staffing and Personnel Planning E Effort per unit time E = K/t²d × t × e-t²/2t²d K (Total effort area) td Time Figure 4.2: The Rayleigh curve • The Rayleigh curve represents the relationship between effort (E) and time (td) at any point of time. • E indicates the staffing requirement at any particular time during the duration of the project. • K is the total area under the curve, which represents the total effort requirements for the project. td is the time at which the curve reaches its maximum value. 135 Staffing and Personnel Planning • In 1976, Putnam subsequently analysed various army projects using the Rayleigh curve for determining the personnel level of effort required in the software life cycle • Putnam found that td in Norden’s equation is the time when a project reaches the testing and integration and deployment stage. • After observing a large number of projects, Putnam derived the following expression for the personnel level effort pattern in any project: S = Ck K1/3 t4/3d • Where S is the product size in KLOC and Ck represents the technological aspects that may affect productivity. • K is the total effort in person-month required yearly and td represents the time taken from project initiation to product deployment. 136 Staffing and Personnel Planning • Staffing level estimation is used to determine the personnel level requirement in different tasks and phases of the development cycle. • Personnel planning concentrates on estimating and allocating the right person to the right task at the right time during project execution. • The personnel requirement is determined by dividing the total effort by the development time. • The project manager then recruits the required personnel in the project. Thereafter, the team is composed and responsibilities are allocated to the team members corresponding to their skills. 137 Project Scheduling and Milestones • A project schedule is built to answer what tasks will be accomplished when, how, and by whom. • In project scheduling, the overall effort and staff are distributed across the project duration for each task in the project. • PMI’s PMBOK defines the project schedule as the planned dates for carrying out the scheduled activities and the planned dates for meeting the schedule milestones • A schedule milestone is an end point of a task while performing an activity in the process. 138 Project Scheduling and Milestones • Project scheduling activities – Task identification – Work breakdown structure – Task interdependency – Time allocation – Resource allocation – Monitoring, tracking, and control 139 Project Scheduling and Milestones Task Identification • Task identification focuses on identifying all the activities and tasks before considering the delivery dates and resource constraints. • The tasks are decided based upon the nature of the project, which can be a new development project, reengineering project, enhancement project, etc. • There are various factors that influence the project tasks, such as project size, project staff, project complexity, mission criticality, reengineering factors, number of potential users, requirements stability, and the maturity of technology. • Task identification begins with the mission and vision of the project. Top-down and bottom-up approaches can be used for the preparation of the task list. 140 Project Scheduling and Milestones Task Identification: Example Mission critical system T1 Mission critical system T1.1 Risk analysis T1.2 Prototype construction T1.3 Requirement analysis T1.4 Design T1.4.1 System architecture T1.4.2 System design T1.4.2.1 Input design T1.4.2.2 Database design T1.4.2.3 Output design T1.4.3 Detailed design T1.5 Coding T1.6 Testing T1.6.1 Unit test T1.6.2 Integration test T1.6.3 System test T1.6.3.1 Stress testing T1.6.3.2 Performance testing T1.6.3.3 Volume testing T1.6.3.4 Security testing T1.6.4 Acceptance testing T1.7 Deployment 141 Project Scheduling and Milestones Work Breakdown Structure • The work breakdown structure (WBS) shows the project details of tasks, making it easier to understand and communicate them throughout the project life cycle. • The WBS represents a hierarchical breakdown of a project into elements. • The total work of the project is divided into manageable elements with increasing levels of detail. • The upper levels of the WBS are typically major deliverables of the project. • The lower levels are the refinements of the upper level. • A properly structured WBS helps to improve the accuracy of cost estimates by estimating the costs of the lower-level elements. • It provides a mechanism for performance measurement and control level by level. 142 Project Scheduling and Milestones Work Breakdown Structure for Mission Critical System Mission critical system Risk analysis Prototype construction System architecture Input design System design Output design Requirement analysis Detailed design Database design Design Unit testing Stress testing Testing Deployment Integration testing Acceptance testing Coding System testing Performance testing Figure 4.4: Work breakdown structure Recovery testing 143 Project Scheduling and Milestones Task interdependency • Task interdependency represents the dependency relationship or the sequence of tasks between a pair of activities. • WBS is converted into an activity network diagram (AND) that shows the task interdependency in the project. • The activity network diagram is designed using – Project Evaluation and Review Technique (PERT) – Critical Path Method (CPM). 144 Project Scheduling and Milestones PERT-CPM Method • PERT is a network-based representation of tasks or activities to determine the task interdependency. • It represents the precedence or parallel relationships among the tasks in a project. • A PERT diagram has the following construction rules: – Each task or activity is represented as a node in boxes. – Arrow shows the dependencies between tasks or activities. – There is a start node, which has only an outgoing arrow, and an end node, which has only incoming arrows. – An arrow pointing to a node comes from its predecessor activity, which must be completed before a task can begin. 145 Project Scheduling and Milestones PERT-CPM Method – Arrows pointing out of a task box go to its successor tasks, which cannot start until at least this task is complete. – For example, T1 is the predecessor of T2 in the following diagram. T2 cannot start until T1 is completed. Predecessor T1 Task 1 Time duration Successor T2 Task 2 146 Project Scheduling and Milestones • Based upon the details of WBS and the sequence of activities, an activity network diagram is drawn which shows the sequence of serial and parallel activities in the project. • There is no cycle in the activity network diagram. • The expected completion time in days is shown inside the nodes, along with the activities. • The duration of the project is equal to the longest path from the start to the finish node of the network. • A path in the network diagram is one of the routes following the arcs from the start to the finish node. • The length of a path is the sum of the expected estimated durations of the activities on the path. 147 Project Scheduling and Milestones Example: Activity network diagram Input design, 6 Start, 0 Architectural design, 10 Output design, 6 Database design, 13 Finish, 0 Detailed design, 18 Figure 4.5: Activity network diagram 148 Project Scheduling and Milestones PERT-CPM Method • The duration of the project must be at least the length of the longest path. • Thus, the estimated project duration equals the length of the longest path through the project network. • This longest path is called the critical path. • For larger projects, it may be helpful to determine the following values for each activity: – Earliest Start time (TES): It is the earliest time an activity may begin after allowing the preceding activities to finish. Earliest start time (TES) = max (TEF of immediate predecessors). – Earliest Finish time (TEF): It is the earliest time an activity may finish after allowing the preceding activities to finish. Earliest finish time (TEF) = TES + Activity duration. • TES and TEF are calculated in the forward pass through the network diagram. 149 Project Scheduling and Milestones PERT-CPM Method • Sometimes activities take longer than the expected time duration that may delay project completion. • So, to determine how much late an activity can start or finish without delaying project completion as: – Latest Start time (TLS): It is the latest time an activity may begin without delaying project completion. Latest start time (TLS) = TLF Activity duration. – Latest Finish time (TLF): It is the latest time an activity may finish without delaying project completion. Latest finish time = TLF = min (TLS of immediate successors). – Slack time (TS): The slack time for an activity is the difference between its latest finish time and its earliest finish time. Slack time (TS) = TLF – TEF = TLS – TES. • The backward pass through the network diagram is made starting with the final activities and moving backward in time toward the initial activities to calculate TLS and TLF. 150 Project Scheduling and Milestones PERT-CPM Method TES = 10 TEF = 16 Input design, 6 TES== 00 TEF== 00 Start, 0 TLS = 0 TLF = 0 TES = 0 TEF = 10 Architectural design, 10 TLS = 0 TLF = 10 TLS = 17 TLF = 23 TES = 10 TEF = 23 Database design, 13 TLS = 10 TLF= 23 TES = 10 TEF= 28 Detailed design, 18 TES = 23 TEF = 29 Output design, 6 TLS = 23 TLF = 29 TES = 29 TEF = 29 Finish, 0 TLS = 29 TLF = 29 TLS = 11 TLF = 29 Figure 4.6: PERT with the critical path 151 Project Scheduling and Milestones PERT-CPM Method • There are some activities having no slack and other activities have slack time. The critical path then is the path through the network in which none of the activities have slack. • Each activity with zero slack is on the critical path through the project network such that any delay along this path will delay project completion. • The critical path is shown in Figure 4.6 with dark arrows in the network diagram. • The critical path is: Start node > Architectural design > Database design > Output design > Finish node 152 Project Scheduling and Milestones PERT-CPM Method • Advantage: – PERT is useful to determine the expected project completion time, the probability of completion before a specified date, and the start and end dates. – It helps to find the critical path activities that directly influence the completion time. • Limitation: – The time estimates for activities are somewhat subjective and depend on judgment. – If there is little experience in performing an activity, the time is fixed only by an educated guess. 153 Project Scheduling and Milestones Time allocation • The project time can be estimated based on certain assumptions and the experience of estimating the likely estimates of the activities in the project. • Therefore, the estimation of time duration for a project includes three time estimates: – Optimistic time (TO): It is the shortest time in which the activity can be completed. – Most likely time (TM): It is the completion time having the highest probability. – Pessimistic time (TP): It is the longest time that an activity might require. 154 Project Scheduling and Milestones Time allocation • The expected time for each activity can be approximated using the following weighted average: Expected time (T) = (TO + 4 × TM + TP)/6 • This expected time might be displayed on the network diagram along with the activities in boxes. • The variance for each activity is determined as: [(TP - TO)/6]2 • The variance in the total project durations is the sum of the variances of the activity duration on the critical path. • This is helpful for project managers in determining the completion time of the project. 155 Project Scheduling and Milestones Resource allocation • A Gantt chart is a horizontal bar chart that provides a graphical illustration of a project schedule. • It is commonly used for scheduling the tasks, allocating the resources, and tracking the progress of projects. • Drawing a Gantt chart requires tasks, duration of the tasks, and resources requirements to complete the tasks. Gantt charts are also useful for monitoring the progress of the project. • In a Gantt chart, activities are generally shown vertically on the lefthand side and the horizontal bar indicates the start date, end date, and duration of each activity. 156 Project Scheduling and Milestones Resource allocation Task name Duration Start (days) date Architectural 10 20/01/11 design Input 6 2/01/11 design Database 13 31/01/11 design Detailed 18 31/02/11 design Output 6 13/02/11 design End date Jan 20 30/01/11 Jan 30 Feb 12 Feb 18 25/01/11 12/02/11 11/02/11 18/03/11 Figure 4.7: Gantt chart for software design 157 Project Scheduling and Milestones Monitoring, Tracking, and Control • There are several methods for monitoring, tracking, and controlling the project activities. • Some automated tools such as Microsoft Project, SMART, etc., are also used for monitoring the projects. • The most popular methods used for project monitoring and tracking are – Review meetings, – Cost-schedule milestone graphs, – Status reporting, – Earn value methods, and so on. 158 Project Scheduling and Milestones Monitoring, Tracking, and Control • Review meetings – Review meetings are conducted to ensure that the planned schedule is executed within time and appropriate resources. – Project managers conduct review meetings regularly to check the status of all the tasks specified in the Gantt chart. • Status reporting – In status reporting, each member of the project records the status of their assigned tasks. – The project manager calls periodical project status meetings and each member reports the current status of the tasks. – The problems faced by the team members are discussed in the status meeting. The project status meeting is generally called weekly or quarterly. 159 Project Scheduling and Milestones Monitoring, Tracking, and Control • Cost-schedule milestone graph – The cost-schedule milestone graph is a graphical representation of the progress of a project. – The project progress is measured monthly or at the interval decided by the project manager through the cost estimated against the planned schedule. – At each milestone, the actual cost is compared with the schedule. A variation represents the fluctuation in the planned cost and planned schedule. 160 Project Scheduling and Milestones Monitoring, Tracking, and Control • Earn value analysis – The earn value analysis is a quantitative analysis to determine the progress of a project. – Each task is given an earn value, i.e., the effort decided during project planning in the ratios of the project size. – The earn value of each task is summed and thus it is the total cost that is estimated. – This value is compared with the actual cost reported in the costschedule or status reporting document. – The project manager can find the progress of the project and the deviation in the cost or schedule. 161 Miscellaneous Plans Planning for the development life cycle Configuration management plan Risk management plan Quality assurance plan System testing plan Deployment plan 162 Summary • Project planning is necessary for devising resources and budgets, for monitoring and controlling the activities of project management. • Software metrics are used to measure products, processes, and projects. • There are various units of size measurement, such as lines of code (LOC), function point (FP), token count (TC), fuzzy logic sizing, object point (OC), standard component sizing, etc. • The most popular estimation techniques are estimation by analogy, Delphi estimation, algorithmic cost modelling, and analytical technique. Project scheduling is an important responsibility performed by project managers in order to complete the project in a successful manner. • Each activity and process of project development is planned before execution. • These plans are the selection of the development life cycle, configuration management plan, risk management plan, quality assurance plan, system testing plan, and deployment plan. 163