Project Management (2).pdf

Project Management (2).pdf

• 1.
  The Management Scope: 1. The management spectrum describes the management of a software project. 2. The management of a software project starts from requirement analysis and finishes based on the nature of the product, it may or may not end because almost all software products faces changes and requires support. 3. It is about change the project from plan to reality. 4. The management spectrum focuses on the four P’s, such as People, Product, Process and Project. 5. Here, the manager of the project has to control all these P’s to have a smooth flow in the progress of the project and to reach the goal.
• 3.
  The People: 1. Peopleof a project includes from manager to developer, from customer to end user. But mainly people of a project highlight the developers. 2. It is so important to have highly skilled and motivated developers that the Software Engineering Institute has developed a People Management Capability Maturity Model (PM- CMM),Organizations that achieve high levels of maturity in the people management area have a higher likelihood of implementing effective software engineering practices. The Product: 1. The product is the ultimate goal of the project. 2. To develop a software product successfully, all the product objectives and scopes should be established, alternative solutions should be considered, and technical and management constraints should be identified beforehand. 3. Lack of these information, it is impossible to define reasonable and accurate estimation of the cost, an effective assessment of risks, a realistic breakdown of project tasks or a manageable project schedule that provides a meaningful indication of progress.
• 5.
  The Process : 1.A software process provides the framework from which a comprehensive plan for software development can be established. 2. A number of different tasks sets, milestones, work products, and quality assurance points enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. 3. Finally, umbrella activities cover the software process model. 4. Umbrella activities are independent of any one framework activity and occur throughout the process.
• 6.
  The Project : 1.The project is the complete software project that includes requirement analysis, development, delivery, maintenance and updates. 2. The project manager of a project or sub-project is responsible for managing the people, product and process. 3. The responsibilities or activities of software project manager would be a long list but that has to be followed to avoid project failure. 4. A software project could be extremely complex and as per the industry data the failure rate is high. 5. Its merely due to the development but mostly due to the steps before development and sometimes due to the lack of maintenance.
• 7.
  W5HH Principle orModel : 1. Created by software engineer “Barry Boehm”, the purpose behind the W5HH principle is to work through the objectives of a software project, the project timeline, team member responsibilities, management styles, and necessary resources. Important Note : “Barry Boehm”, gave a philosophy which prepares easy and manageable designs or outlines for software projects. He calls it the W5HH principle after a series of questions that define key project characteristics and the resultant project plan. A series of questions can help project managers more efficiently manage software projects.
• 8.
  Why is thesystem being developed? Ans: All stakeholders should assess the validity of business reasons for the software work. Does the business purpose justify the expenditure of people, time, and money? What will be done? Ans: The task set required for the project is defined. When will it be done? Ans: The team establishes a project schedule by identifying when project tasks are to be conducted and when milestones are reached. Who is responsible for a function? Ans: The role and responsibility of each member of the software team are defined. Where are they located organizationally? Ans: Not all roles and responsibilities reside within software practitioners. The customer, users, and other stakeholders also have responsibilities. How will the job be done technically and authoritatively? Ans: Once the product scope is established, management and technical strategy for the project must be defined. How much of each resource is needed? Ans: The answer to this question is derived by developing estimates based on the answers to earlier questions.
• 9.
  Software Metrics Software processand product metrics are quantitative measures that enable SW people to gain insight into the efficacy of SW process and the projects that are conducted using the process as a framework. Note : A software metric is a measure of software characteristics which are measurable or countable. Software metrics are valuable for many reasons, including measuring software performance, planning work items, measuring productivity, and many other uses. Software Metrics Terms * Measure 1. provides a quantitative indication of the extent, amount, dimension, capacity or size of some attribute of a process or product. Example: Number of defects found in component testing. LOC of each component * Measurement 1.The act of collecting a measure. Example: Collecting the defect counts. Counting LOC.
• 10.
  Types of SoftwareMetrics 1. Process Metrics Process metrics are used to measure the characteristics of the process of software development. For example includes the efficiency of detection of fault etc. The characteristics of the methods, tools, and techniques used for software development can be measured using process metrics. 2.Product Metrics The characteristics of the software product are measured using product metrics. Some of the important characteristics of the software are: * Software size and complexity * Software reliability and quality Computation of these metrics is done for different stages of the software development lifecycle.
• 11.
  3. Internal Metrics Theproperties which are of great importance to a software developer can be measured using the metrics called internal metrics. An example is a measure of Lines of code (LOC). 4. External Metrics The properties which are of great importance to a user can be measured using the metrics called external metrics. An example is portability, reliability, usability, etc. 5. Project Metrics 1. The progress of the project is checked by the project manager using the metrics called project metrics. 2. Various metrics such as time, cost, etc., are collected by using the data from the projects in the past, and they are used as an estimate for the new software. 3. The project manager checks the progress of the project from time to time, and effort, time and cost are compared with the original effort, time and cost. 4. The cost of development, efforts, risks and time can be reduced by using these metrics. 5. The quality of the project can also be improved. With the increase in quality, there is a reduction in the number of errors, time, cost, etc.
• 12.
  Software Measurement Example *Size Oriented Metrics 1. LOC Metrics 1. It is one of the earliest and simpler metrics for calculating the size of the computer program. 2. It is generally used in calculating and comparing the productivity of programmers. 3.These metrics are derived by normalizing the quality and productivity measures by considering the size of the product as a metric. Following are the points regarding LOC measures: 1. In size-oriented metrics, LOC is considered to be the normalization value. 2. It is an older method that was developed when FORTRAN and COBOL programming were very popular. 3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-months. 4. Size-oriented metrics depend on the programming language used. 5. As productivity depends on KLOC, so assembly language code will have more productivity. 6. LOC measure requires a level of detail which may not be practically achievable. 7. The more expressive is the programming language, the lower is the productivity. 8. LOC method of measurement does not apply to projects that deal with visual (GUI-based) programming. 9. It requires that all organizations must use the same method for counting LOC. 10.This is so because some organizations use only executable statements, some useful comments, and some do not. Thus, the standard needs to be established. Note : These metrics are not universally accepted.
• 13.
  Based on theLOC/KLOC count of software, many other metrics can be computed: 1. Errors/KLOC 2. Cost / KLOC 3. Defects/KLOC 4. Pages of documentation/KLOC 5. Errors/PM 6. Productivity = KLOC/PM (effort is measured in person-months) 7. Cost / Page of documentation Advantages of LOC 1. Simple to measure Disadvantage of LOC 1. It is defined on the code. For example, it cannot measure the size of the specification. 2. It characterizes only one specific view of size, namely length, it takes no account of functionality or complexity 3. Bad software design may cause an excessive line of code 4. It is language dependent 5. Users cannot easily understand it
• 14.
  Software quality metrics: Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project. These are more closely associated with process and product metrics than with project metrics. Types of quality metrics : 1. Product quality metrics 2. In-process quality metrics 3. Maintenance quality metrics 1. Product quality metrics : This metric includes the following * Mean Time to Failure * Defect Density * Customer Problems * Customer Satisfaction
• 15.
  Mean Time toFailure This metric is generally used with safety critical systems such as the airline traffic control systems, aeronautics, and weapons. Defect Density It measures the defects relative to the software size expressed as lines of code or function point, etc. i.e., it measures code quality per unit. This metric is used in many commercial software systems. Customer Problems It measures the problems that customers encounter when using the product. It contains the customer’s view towards the problem space of the software, which includes the non-defect oriented problems together with the defect problems. The problems metric is usually expressed in terms of Problems per User-Month (PUM). PUM = Total Problems that customers reported (true defect and non-defect oriented problems) for a time period + Total number of license months of the software during the period
• 16.
  Where Number of license-monthof the software = Number of install license of the software × Number of months in the calculation period Note : PUM is usually calculated for each month after the software is released to the market, and also for monthly averages by year. Customer Satisfaction Customer satisfaction is often measured by customer survey data through the five-point scale 1.Very satisfied 2.Satisfied 3.Neutral 4.Dissatisfied 5.Very dissatisfied Note : Satisfaction with the overall quality of the product and its specific dimensions is usually obtained through various methods of customer surveys. Based on the five-point-scale data, several metrics with slight variations can be constructed and used, depending on the purpose of analysis
• 17.
  2. In-process qualitymetrics : In-process quality metrics deals with the tracking of defect arrival during formal machine testing for some organizations. This metric includes, 1. Defect density during machine testing 2. Defect arrival pattern during machine testing 3. Phase-based defect removal pattern 4. Defect removal effectiveness 1. Defect rate during formal machine testing (testing after code is integrated into the system library) is correlated with the defect rate in the field. Higher defect rates found during testing is an indicator that the software has experienced higher error rejection during its development process. 2. The overall defect density during testing will provide only the summary of the defects. The pattern of defect arrivals gives more information about different quality levels in the field. Example : The pattern of defect backlog overtime. This metric is needed because development organizations cannot investigate and fix all the reported problems immediately.
• 18.
  3. It isan extension of the defect density metric during testing. In addition to testing, it tracks the defects at all phases of the development cycle, including the design reviews, code inspections, and formal verification before testing. 4. Defect removal effectiveness Note : This metric can be calculated for the entire development process, for the front-end before code integration and for each phase. It is called early defect removal when used for the front-end and phase effectiveness for specific phases. The higher the value of the metric, the more effective the development process and the fewer the defects passed to the next phase or to the end field.
• 19.
  3. Maintenance qualitymetrics 1. To alter the quality of the product during this phase must be less not more. 2. The following are the fixes that can be carried out to eliminate the defects as soon as possible with excellent fix quality. * Fix backlog and backlog management index * Fix response time and fix responsiveness Fix backlog and backlog management index 1. Fix backlog is related to the rate of defect arrivals and the rate at which fixes for reported problems become available. 2. It is a simple count of reported problems that remain at the end of each month or each week. 3.This metric can provide meaningful information for managing the maintenance process
• 20.
  Backlog Management Index(BMI) is used to manage the backlog of open and unresolved problems. Note : If BMI is larger than 100, it means the backlog is reduced. If BMI is less than 100, then the backlog increased. Fix response time and fix responsiveness 1. The fix response time metric is usually calculated as the mean time of all problems from open to close. 2. Short fix response time leads to customer satisfaction. 3. The important elements of fix responsiveness are customer expectations, the agreed- to fix time, and the ability to meet one's commitment to the customer.