Software Project Management Chapter 4 PDF

Chapter 4 Software Project management Outline Responsibility of Software Project Managers The organization of SPMP document Project Planning Scheduling, Organization, and Team Structure Staffing Risk Management Project Estimation Techniques Quality Assurance Project Monitoring Plans Manag...

Chapter 4 Software Project management Outline Responsibility of Software Project Managers The organization of SPMP document Project Planning Scheduling, Organization, and Team Structure Staffing Risk Management Project Estimation Techniques Quality Assurance Project Monitoring Plans Management The activities and tasks undertaken by one or more persons for the purpose of planning and controlling the activities of other in order to achieve objectives that could not be achieved by the others acting alone Project Management A system of management procedures, practices, technologies, skills, and experience necessary to successfully manage an engineering project The organization of SPMP document Software project manager prepare a document on the basis of decision finalized during the project planning. This document is known as Software Project Management Plan Document or SPMP document. The organization of SPMP document SPMP document is a well organized document that contains the project planning in detail. It would have details about project objective, project estimates, project schedules, project resources, project staffing, risk management plans, project monitoring, project control and other activities. A SPMP document is prepared and organized in structure as shown below: Introduction Objectives Functions Performance issues Constraints Project estimates Hardware and Software Historical data used Highly skilled professionals Estimation techniques details Staff organization Cost, duration, effort estimates Team formation and structure Project Schedule Management reporting Work breakdown Risk Management Gantt and PERT chart Risk analysis Project resource Risk identification Manpower Risk abatement methods Software project management Software project management is an essential part of software engineering. Experienced professional Plenty of time Enough budget Bad management may result: Late delivery Increased cost To fail to meet customer requirement Responsibilities of project managers Proper management is essential for the successful completion of software project and the person who is responsible for it is called project manager. Job responsibilities of project manager are:- Involves with the senior managers in the process of appointing team members Responsible for effective project planning and scheduling, project monitoring and control activities in order to achieve the project objectives.  Builds the project team and assigns tasks to various team members Acts as a communicator between the senior management and the other persons involved in the project like the development team and internal and external stakeholders. Effectively resolves issues that arise between the team members by changing their roles and responsibilities. Modifies the project plan to deal with the situation. Skills required by project manager are:- Must have the knowledge of different project management techniques like risk management, configuration management, cost estimation techniques, etc Must have ability to make judgment, since project management frequently requires making decisions. Must have good grasping power to learn the latest technologies to adapt to project requirements. Should be open minded enough to accept new ideas from the project members and be creative enough to come up with new ideas. Should have good interpersonal, communication, and leadership qualities in order to get work done from the team members. Management activities Project managers take responsibility for some or all of the following activities according to the situation. Proposal writing. Project planning, scheduling and staffing. Project costing. Project monitoring and reviews. Personnel selection, supervision, and evaluation. Report writing and presentations. Generally the project managers are responsible : For What to do When to do How to do Who will do What to use For supervision to ensure that the project is going on To the required standard According to the schedule Within budget Proposal writing Content of proposal document 1. Introduction 1.1. Background 1.2. statement of the problem 1.3. objective 1.4. scope 1.5. significance 2. Methodology and tools 2.1. Methodology 2.2. Tools 2.3. cost analysis 2.4. Project schedule 3. References Project planning What we meant by a project plan? Project planning is an organized and integrated management process, which focuses on activities required for successful completion of project. It prevents obstacles that arise in the project such as changes in projects or organization’s objectives, non availability of resources , and so on. It also helps in better utilization of resources and optimal usage of the allocated time for a project. Developing a realistic project plan is essential to gain an understanding of the resources required, and how these should be applied. Cont.. Objectives of project planning It defines the role responsibilities of project management team members. It ensures that the project management team works according to the business objectives. It checks feasibility of the schedule and user requirements. It determines project constraints. Project planning process It comprises the following: Objectives and scope of the project Techniques used to perform project planning Effort of individuals involved in project Project schedule and milestones Resources required for the project Risks associated with the project Cont.. Project planning process consists the following activities: Identification of project requirements Identification of cost estimates Identification of risks Identification of critical success factors Preparation of project charter Preparation of project plan Commencement(beginning) of the project Types of Project plan Development plan:- Specifies the order of work to be carried out, resources, responsibilities, and so on. Quality assurance plan:- Specifies the quality procedures & standards to be used. Validation plan:- Defines how a client will validate the system that has been developed. Configuration management plan:- Defines how the system will be configured and installed. Maintenance plan:- Defines how the system will be maintained. Staff development plan:- Describes how the skills of the participants will be developed. Project plan structure Introduction- brief introduction to project Project organization- introduction to organizations, people, and their roles Risk analysis- what are the key risks to the project? Hardware and software resource requirements- what H/ware and S/ware resources will be required for the project and when Work breakdown- the project divided into activities, milestones, deliverables; dependencies between tasks etc Project schedule- actual time required - allocation of dates Reporting and progress measurement - mechanisms to monitor progress. Work breakdown There are many ways of breaking down the activities in a project, but the most usual is into: work packages tasks Deliverables milestones A work package is a large, logically distinct section of work: typically at least 12 months duration may include multiple concurrent activities independent of other activities but may depend on, or feed into other activities typically allocated to a single team. Deliverables in requirement process ACTIVITIES Feasibility Require ments Prototype Design Requirements study analy sis development study specifica tion Feasibility User Evaluation Architectur al System report requirements report design requirements MILESTONES Deliverable Project scheduling Split project into tasks and estimate time and resources required to complete each task. Project scheduling provides details such as start and end date of the project, milestones, and tasks for the project. It is to perform project scheduling to effectively manage the tasks of the project. Minimize task dependencies to avoid delays caused by one task waiting for another to complete. Dependent on project managers intuition and experience. Factors that delay project schedule Unrealistic deadlines: when the time allocated for completing a project is impractical and not according to the effort required for it. Changing user requirements: when user requirements are changed after the project has started. Under-estimation of recourses: when the resources for the project is not done according to its requirements. Lack of consideration of risk: when risk is not considered during project planning and scheduling. Lack of proper communication among team members: Difficulties of team members: when some members require leave for personal reasons. The project scheduling process Gantt chart PERT chart Scheduling problems Estimating the difficulty of problems and hence the cost of developing a solution is hard. Productivity is not proportional to the number of people working on a task. Adding people to a late project makes it later because of communication overheads. The unexpected always happens. Always allow contingency in planning. Project staffing Project staffing is the process of searching, evaluating, and, establishing a working relationship amongst the personnel involved in the project. The number of team members required in project depends on the type of project and the effort and cost required for it. It is important to assign different roles and responsibilities to different individuals according to their skills, abilities, and experience. Principles of project staffing The tasks should be assign to staff members according to their skill and abilities. Every staff member should be assigned a designation. Staff members should be employed according to their requirements in the project only after the project is approved. Every staff member should be constrained to follow the guidelines and standards of the organization. Project Team structure Detailed scheduling is done only after actual assignment of people has been done. project's team is led by a project manager, who does the planning and task assignment. is responsible for all major technical decisions of the project. The teams are structured hierarchically, consists of analyzer, programmers, testers, a configuration controller, quality controller, and possibly a librarian for documentation. Generally the team structure is determined by the Management style of the organization; The number of people, who will populate the team, and their skill levels The overall problem difficulties. Team structure Group of people are involved in software development process. These people should work like a team in order to develop a high quality project. Factors considered to organize team structure: Technical skill of the individuals Required degree of communication between the team members Characteristics of the project to be developed such as size, time deadline, reliability, quality, and so on Type of project to be developed Project cost estimation After we know all the requirements and the process we follow , we have to know How much cost is needed How much time and effort Most of the time 2/3 of all major projects overrun their original estimation. Estimation is complex and challenging activities. It needs knowledge about size of project About required effort The time of delivery or schedule Estimate overall cost Costing and pricing Estimates are made to discover the cost, to the developer, of producing a software system Estimating cost: Cost for the developer not buyer We need our cost to manage and assess. Estimating price: Broader organizational, economic, political and business considerations influence the price charged Software pricing factors Market A d evelopment organisation may quote a low price because it opportunity wishes to move into a new segment of the software market. Accepting a low profit on one project may give the opportunity of more profit later. The experience gained may allow new products to be developed. Cost estimate If an organisation is unsure of its cost estimate, it may increase uncertainty its price by some contingency over and above its normal profit. Contractual terms A c ustomer may be willing to allow the developer to retain ownership of the source code and reuse it in other projects. The price charged may then be less than if the software source code is handed over to the customer. Requirements If the requirements are likely to change, an organisation may volatility lower its price to win a contract. After the contract is awarded, high prices can be charged for changes to the requirements. Financial health Developers in financial difficulty may lower their price to gain a c ontract. It is better to make a sm aller than normal profit or break even than to go out of business. Estimation Technique Expert Judgment Estimation by Analogy Parkinson’s law Cost Price to win Estimation Technique: Expert judgment One or more experts in both software development and the application domain use their experience to predict software costs. Process iterates until some consensus is reached. Advantages: Relatively cheap estimation method. Can be accurate if experts have direct experience of similar systems Disadvantages: Very inaccurate if there are no experts! Estimation Technique: Estimation by analogy The cost of a project is computed by comparing the project to a similar project in the same application domain The actual data from the completed project are taken to estimate the proposed project Advantages: May be accurate if project data available and people/tools the same Disadvantages: Impossible if no comparable project has been tackled. Estimation Technique: Parkinson's Law "work expands to fill the time available for its completion.“ if you give a task more time than it genuinely requires, people will tend to use up all the allocated time, often without adding much value. The project costs whatever resources are available Advantages: No overspend Disadvantages: System is usually unfinished Estimation Technique: Cost Pricing to win The estimated effort depends on the customer’s budget and not on the software functionality The project costs whatever the customer has to spend on it. Advantages: You get the contract Disadvantages: The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required. Only a good strategy if you are willing to take a serious loss to get a first customer, or if Delivery of a radically reduced product is a real option. Top-down and bottom-up estimation Any of these approaches may be used top-down or bottom-up. Top-down Start at the system level and assess the overall system functionality and how this is delivered through sub-systems. Bases the overall estimate on properties of the project as a whole, which are then applied across estimates encompassing all project activities. Bottom-up Start at the component level and estimate the effort required for each component. Add these efforts to reach a final estimate. calculation is based on the sum of the various, individual project activity estimates Top-down estimation Usable without knowledge of the system architecture and the components that might be part of the system. focus on overall system properties, such as integration, change management, and incremental delivery, combined with its relative ease of application Can underestimate the cost of solving difficult low-level technical problems. Bottom-up estimation Usable when the architecture of the system is known and components identified. Capture project-specific issues, application design features, and implementation-specific details, which tend to accumulate rapidly and can affect the estimate greatly. It may underestimate the costs of system level activities such as integration and documentation. Quality assurance plans To ensure that the final product is of high quality, some quality control (QC) activities must be performed. Main purpose is to identify defects. a quality plan in a project specify the activities that need to be performed for identifying and removing defects, and the tools and methods that may be used for that purpose. Defines the quality strategy, goals and responsibilities, and institutionalizes these activities. Generally quality management defines the maturity of a software development organization by planned systematic pattern of actions. Major steps Strategic Quality Planning (Needs of an organization product & process characteristics, define boundaries) Process Management (Define a processes that guarantee quality product development, identify changes) Quality Assurance (Assure achievement of product qualities, identify risks and suggest re-planning) Quality Improvement (Improve existing models in order to improve the quality of products) Quality management specification Input Organizational needs Existing models (product, process, quality) Output Key product & process characteristics ( Project Goals & Context) QA plan Observations/Lessons Learned (successes & failures in projects) Improved models Cont.. Questions addressed by Quality Management How do we achieve customer satisfaction? How do we easily find requirements for our products? How do we find the appropriate processes? How do we manage change (internal, external)? How do we perform continuous & sustained improvement? etc…. Then we have to justify effort Quality Management. It depends on:- Cost of defects in projects Risks in projects Opportunities in projects Quality culture Quality standards International standard (IEEE) Institute of Electrical and Electronics Engineers Functionality:- Does the software meet the requirements? Reliability:- How often does the software fail? Usability:- Can the software be used easily? Efficiency:- How well does the software perform? Maintainability:- How well can the software be changed/maintained? Portability:- How well can the software be migrated on other systems? Risk management Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project. There are three categories of risks Project risks: affect schedule or resources; Product risks: affect the quality or performance of the software being developed; Business risks: affect the organization developing or procuring the software. The results of risk analysis should be documented in the project plan along with an analysis of the consequences of a risk occurring.  Software risks Risk Affects Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with different priorities. Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Project and There will be a larger number of changes to the requirements than product anticipated. Specification delays Project and Specifications of essential interfaces are not available on schedule product Size underestimate Project and The size of the system has been underestimated. product CASE tool under-performance Product CASE tools which support the project do not perform as anticipated Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed. The risk management process Risk identification Identify project, product and business risks; Risk analysis Assess the likelihood and consequences of these risks; Risk planning Draw up plans to avoid or minimize the effects of the risk; Risk monitoring Monitor the risks throughout the project. The risk management process Risk Risk Risk analysis Risk planning identification monitoring Risk avoidance List of potential Prioritised risk Risk and contingency risks list assessment plans  Risks and risk types Risk type Possible risks Technology The database used in the system cannot process as many transactions per second as expected. Software components that should be reused contain defects that limit their functionality. People It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available. Organisational The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget. Tools The code generated by CASE tools is inefficient. CASE tools cannot be integrated. Requirements Changes to requirements that require major design rework are proposed. Customers fail to understand the impact of requirements changes. Estimation The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated. Risk analysis Assess probability and seriousness of each risk. Probability may be very low, moderate, high or very high. Risk effects might be catastrophic, serious, tolerable or insignificant.  Risk analysis I Risk Probability Effects Organisational financial problems force reductions Low Catastrophic in the project budget. It is impossible to recruit staff with the skills High Catastrophic required for the project. Key staff are ill at critical times in the project. Moderate Serious Software components that should be reused Moderate Serious contain defects which limit their functionality. Changes to requirements that require major design Moderate Serious rework are proposed. The organisation is restructured so that different High Serious management are responsible for the project.  Risk analysis II Risk Probability Effects The database used in the system cannot process as Moderate Serious many transactions per second as expected. The time required to develop the software is High Serious underestimated. CASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of Moderate Tolerable requirements changes. Required training for staff is not available. Moderate Tolerable The rate of defect repair is underestimated. Moderate Tolerable The size of the software is underestimated. High Tolerable The code generated by CASE tools is inefficient. Moderate Insignificant Risk planning Consider each risk and develop a strategy to manage that risk. Avoidance strategies The probability that the risk will arise is reduced; Minimization strategies The impact of the risk on the project or product will be reduced; Contingency plans If the risk arises, contingency plans are plans to deal with that risk; Risk management strategies I Risk Strategy Organisational Prepare a briefing document for senior management financial problems showing how the project is making a very important contribution to the goals of the business. Recruitment problems Alert customer of potential difficulties and the possibility of delays, investigate buying-in components. Staff illness Reorganise team so that there is more overlap of work and people therefore understand each other’s jobs. Defective components Replace potentially defective components with bought-in components of known reliability. Risk management strategies II Risk Strategy Requirements Derive traceability information to assess requirements change changes impact, maximise information hiding in the design. Organisational Prepare a briefing document for senior management showing restructuring how the project is making a very important contribution to the goals of the business. Database Investigate the possibility of buying a higher-performance performance database. Underestimated Investigate buying in components, investigate use of a development time program generator Risk monitoring Assess each identified risks regularly to decide whether or not it is becoming less or more probable. Also assess whether the effects of the risk have changed. Each key risk should be discussed at management progress meetings. Risk indicators Risk type Potential indicators Technology Late delivery of hardware or support software, many reported technology problems People Poor staff morale, poor relationships amongst team member, job availability Organisational Organisational gossip, lack of action by senior management Tools Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations Requirements Many requirements change requests, customer complaints Estimation Failure to meet agreed schedule, failure to clear reported defects Cont.. When planning a project, it is critically important to know what the key risks are, and is possible plan for them:  Staff turnover  Management change  Hardware unavailability  Requirements change  Specification delays  Size underestimate  Technology change  Product competition Project Monitoring The main goal of monitoring is for project managers to get visibility into the project execution. To ensure that the project goals are met There are three main levels of monitoring: 1. Activity-level monitoring: ensures that each activity in the detailed schedule has been done properly and within time 2. Status reports: are often prepared weekly to take stock of what has happened and what needs to be done 3. The milestone analysis: is done at each milestone or every few weeks, if milestones are too far apart. Key points Good project management is essential for project success. The intangible nature of software causes problems for management. Managers have diverse roles but their most significant activities are planning, estimating and scheduling. Planning and estimating are iterative processes which continue throughout the course of a project. Key points A project milestone is a predictable state where a formal report of progress is presented to management. Project scheduling involves preparing various graphical representations showing project activities, their durations and staffing. Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats. Thank you!