UNIT - VII. 1. Distinguish between the process and product with respect to metrics in software engineering?

Transcription

1 UNIT - VII Syllabus: Metrics for Process and Products: Software Measurement, Metrics for software quality. Risk management: Reactive vs. Proactive Risk strategies, software risks, Risk identification, Risk projection, Risk refinement, RMMM, RMMM Plan. 1. Distinguish between the process and product with respect to metrics in software engineering? Measure - quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process. E.g., Number of errors Metric - quantitative measure of degree to which a system, component or process possesses a given attribute. A handle or guess about a given attribute. E.g., Number of errors found per person hours expended Motivation for metric: Estimate the cost & schedule of future projects Evaluate the productivity impacts of new tools and techniques Establish productivity trends over time Improve software quality Forecast future staffing needs Anticipate and reduce future maintenance needs Examples: Defect rates Error rates Measured by: individual module during development Errors should be categorized by origin, type, cost Metric classification: Products Explicit results of software development activities Deliverables, documentation, by products

2 Processes Activities related to production of software Resources Inputs into the software development activities hardware, knowledge, people Product Vs process: Process Metrics Insights of process paradigm, software engineering tasks, work product, or milestones Lead to long term process improvement Product Metrics Assesses the state of the project Track potential risks Uncover problem areas Adjust workflow or tasks Evaluate teams ability to control quality Types of measures: Direct Measures (internal attributes) Cost, effort, LOC, speed, memory Indirect Measures (external attributes) Functionality, quality, complexity, efficiency, reliability, maintainability Example (product metric - quality) - Density of reported defects calculated at the end of each lifecycle phase - Total number of field defects reported after customer installation at the end of each suitable time period Example (process metrics) Many facets of the process yield metrics, for example: Application of methods and tools Use of standards Effectiveness of management Performance of development system It is also possible to use product metrics calculated on the process description A Metrics Programme Software development organizations should have a metrics programme in order to: -calibrate models that can be used to forecast project/product behavior -give measures that can be used to control the software development process Involves metrics AND data collection

3 Quality factors: Product operations: Correctness: the extent to which a program satisfies its specifications and fulfills the customer s mission objectives Reliability: the extent to which a program can be expected to perform its intended function with required precision Usability: the amount of computing resources and code required by the program to perform its function Integrity: the extent to which access to software or data by unauthorized persons can be controlled Efficiency: the effort required to learn, operate, prepare input for, and interpret output of a program 2. Explain the concept of software measurement in detail with an example? Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined unambiguous rules Software plays an important role in our life. We want products which affect our lives has quality attributes. We need quality software. In order to determine quality of software we must have some metrics to measure quality. The key point here is quality of the same product may be change. Software is not an exception. So if we determine quality

4 attributes of the software we can also have more precise, predictable and repeatable control over the software development process and product. In the early days of computing, software costs represented a small percentage of the overall cost of a computer-based system. Therefore, a sizable error in estimates of software cost had relatively little impact. Today, software is the most expensive element in many computer-based systems. Therefore, a large cost-estimation can make the difference between profit and loss. Software measurement enables us to estimate cost and effort devoted to project. Software measurement enables us to determine quality of software. Software measurement enables us to predict maintainability of software. Software measurement enables us to validate the best practices of software dep t. Area of software measurement in software engineering is active more than thirty years. There is a huge collection of researches, but still no a concrete software cost estimation model. If we want to estimate cost-effort of a software project. We need to know the size of the software. One of the first software metric to measure the size of the software as length is the LOC (Line of Code) The LOC measure is used extensively in COCOMO cost estimation model. Another size metric is Function points (FP) reflects the user's view of a system's functionality and gives size as functionality. A unit (the function point) expresses the amount of information processing that an application offers the user. The unit is separate from the way in which the information processing is carried out technically. A software system is a collection of parts interacting with each other to function as a whole. The key word is interact. A software system is developed by people. Since people are the major input used to develop software, understanding human behavior is essential to understanding the software development process. In short, what type of behavior is being encouraged or discouraged? Benefits of Software Measurement Increase return on IT investments Improves communication Encourages appropriate behavior Communicates workloads Enhances requirements process Leverage resources Pinpoints opportunities for improvement Manage workloads Reduce overtime Reduce cost by 15% - 20% by just measuring

5 Many Disciplines Software measurement includes many topics beyond the technical aspects of developing and maintaining software. They include: Software Development Social Psychology Industrial Psychology Organizational Behavior Micro-economic theory Statistics One thing we have learned by working around the globe and with so many different organizations, it is seldom technical problems that inhibit productivity and quality. Instead the far majority of problems are related to human interactions, process and communications. 3. Explain the risk management in software engineering with full details? Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty. Many problems can plague of software project. A risk is a potential problem; it might happen, it might not. But regardless of the outcome, it's a really good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a contingency plan should the problem actually occur Risk is the potential future harm that may arise from some present action" Risk Management is a process that is used to minimize or eradicate risk before it can harm the productivity of a software project. With only 28% of software projects finishing on time and on budget, risk and the management of risk play an important role in software development. There are two ways that software engineers can handle risk. A reactive software engineer corrects a problem as it occurs, while a proactive software engineer starts thinking about possible risks in a project before they occur. There are several types of risk that can occur during a software development project. These include: Risk Type Generic Risks Description generic threats across all projects. For example, requirements change, loss of team members, loss of funding Product-Specific Risks high level risks associated with the type of product being developed. For example: availability of testing resources Project Risks affect project schedule or resources

6 Product Risks Business Risks affect quality or performance of software affect the viability of the software There are also specific risks associated with team members, customers, tools, technology, time estimation, and team size. Many of these risks can be minimized by the development methodology used for the project. There are many different tools that can be used to analyze the risk apparent in a project and that can help choose the best way to minimize or eliminate that risk. What is Risk? Risk is an uncertainty. We don t know whether a particular event will occur or no but if it does has a negative impact on a project. An example would be that team is working on a project and the developer walks out of project and other person is recruited n his place and he doesn t work on the same platform and converts it into the platform he is comfortable with. Now the project has to yield the same result in the same time span. Whether they will be able to complete the project on time. That is the risk of schedule. Definitions of Risks Risk is the probability of suffering loss. Risk provides an opportunity to develop the project better. Risk exposure= Size (loss)* probability of (loss) There is a difference between a Problem and Risk Problem is some event which has already occurred but risk is something that is unpredictable. The Principles of Risk Management 1. Global Perspective: In this we look at the larger system definitions, design and implementation. We look at the opportunity and the impact the risk is going to have. 2. Forward Looking View: Looking at the possible uncertainties that might creep up. We also think for the possible solutions for those risks that might occur in the future. 3. Open Communication: This is to enable the free flow of communication between in the customers and the team members so that they have clarity about the risks.

7 4. Integrated management: In this phase risk management is made an integral part of project management. 5. Continous process: In this phase the risks are tracked continuously throughout the risk management paradigm. Risk management paradigm 1. Identify: Search for the risks before they create a major problem 2. Analyze: understand the nature, kind of risk and gather information about the risk. 3. Plan: convert them into actions and implement them. 4. Track: we need to monitor the necessary actions. 5. Control: Correct the deviation and make any necessary amendments. 6. Communicate: Discuss about the emerging risks and the current risks and the plans to be undertaken. Team Risk Management Principles The two principles are: 1. Shared Product Vision: The common goal between the team and the supplier is established so that the vision is very lucid. 2. Team work: Working collectively towards achieving a common goal. The additional two principles will be added to the above five principles:

8 The Best way to snub the risks to some extent is to involve the customers right from the beginning and build a team oriented approach. In this way the team risk management principles will help to tackle the risks better. How to Manage the Risks Determine risk sources and Categories. Determine Risk Parameters Establish a Risk Management Strategy Identify Risks Evaluate and prioritize the risks. Develop and Implement Risk mitigation plans 4. DISCUSS THE STRATEGIES FOR RISK MANAGEMENT? In this chapter, we present three strategies for risk management. These strategies are defined in order to support various types of software development projects according to the amount of risk influence. Based on the amount of risk on a software development project, we define three risk management strategies: (1) careful, (2) typical and (3) flexible. Careful risk management strategy is intended for fresh and inexperienced organizations whose software development projects are connected with new and unproven technology. Typical risk management strategy is defined as a support for mature organizations with experience in software development projects and used technologies, but whose projects carry a decent number of risks. Flexible risk management strategy is engaged in experienced software development organizations whose software development projects are formally defined and based on proven technologies.

9 Careful risk management strategy should be used on state of the art software development projects, which are completely unknown to the organization. This risk management strategy should be used on a software development project with high acceptable risks, new technology and inexperienced people. Careful risk management strategy could be described as high priority risk management. Risks on software development projects, with an implemented careful risk management strategy, should be taken with utmost importance. This requires rigorous risk analysis on multiple levels. Risks should be analyzed and traced on individual, team and organizational levels. In order to identify important risks as soon as possible and on a wide problem area, every project team member should be involved in risk management. This means that every project member should identify and define risks connected with his problem area, but risks should also be identified and defined on the team and organizational area. Risk mitigation strategies must be defined for each organizational level. In order to successfully implement the risk management strategy, an organization should define risk management roles on the software development project, i.e. there should be project members whose primary activities are connected with risk management. Since careful risk management strategy is connected with an extremely high number of risks on a software development project, an organization should formally define risk interpretation and ranking policy. This should help to separate the important from the unimportant risks in order to address important risks as soon as possible. Project team members should continuously trace risks and actions connected with risks. Work on software development must be ordered according to project risks, i.e. risks with high importance should be solved first. Activities of flexible risk management strategy

10 Define Risk Management Roles Assess Previously Solved Risks Performed on team level Risk Identification and Definition Compare Risks to Previously Solved Risk Analysis and Tracking Perform Risk-Related Activities Important areas of Risk Management: We can define five main risk impact areas: (1) The use of new and unproven technologies, (2) software system requirements, (3) software system architecture, (4) software system performance and (5) organizational and non-functional area Risks are present in every software development project because software development is based on knowledge and new technologies, and the chances for success of a software development project are closely connected with successful risk addressing. As a result of that, we have closely investigated risks and risk impact areas in software development projects. With this paper, we propose a key element of modern software development practices to be software risk management. In order to achieve efficient risk management, we have proposed three risk management strategies suitable for different software development projects according to the amount of risk impact. Reactive vs. Proactive Risk strategies Reactive risk strategies have been laughingly called the Indiana Jones School of risk Management In the movies that carried his name, Indiana Jones, when faced with overwhelming difficulty, would invariably say, Don t worry, I ll think of something! Never worrying about problems until they happened, Indy would react in some heroic way. The majority of software teams rely solely on reactive risk strategies. At best, a reactive strategy monitors the project for likely risks. Resources are set aside to deal with them, should they become actual problems. More commonly, the software team does nothing about risks until something goes wrong. Then, the team flies into action in an

11 attempt to correct the problem rapidly. This is often called a fire fighting mode. When this fails, crisis management takes over and the project is in real jeopardy. A considerably more intelligent strategy for risk management is to be proactive. A proactive strategy begins long before technical work is initiated. Potential risks are Identified, their probability and impact are assessed, and they are ranked by importance 5. EXAMINE THE VARIOUS STEPS INVOLVED IN RISK IDENTIFICATION? Risk identification is a systematic attempt to specify threats to the project plan (estimates, Schedule, resource loading, etc.). By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary. There are two distinct types of risks for each of the categories that have been presented generic risks and product-specific risks. Generic risks are a potential threat to every software project. Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand. To identify product-specific risks, the project plan and the software statement of scope are examined and an answer to the following question is developed: One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories: Product size risks associated with the overall size of the software to be built or modified. Business impact risks associated with constraints imposed by management or the marketplace. Customer characteristics risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. Process definition risks associated with the degree to which the software process has been defined and is followed by the development organization. Development environment risks associated with the availability and quality of the tools to be used to build the product. Technology to be built risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. Staff size and experience risks associated with the overall technical and project experience of the software engineers who will do the work. The risk item checklist can be organized in different ways. Questions relevant to each of the topics can be answered for each software project. The answers to these questions allow the planner to estimate the impact of risk. A different risk item checklist format simply lists characteristics that are relevant to each generic subcategory. Finally, a set of risk components and drivers" [AFC88] are listed along with their probability although generic risks are important to consider, usually the product-specific risks cause the most headaches. Be certain to spend the time to identify as many product-specific risks as possible.

12 6. WRITE SHORT NOTES ON RISK REFINEMENT PROCESS? During early stages of project planning, a risk may be stated quite generally. As time passes and more is learned about the project and the risk, it may be possible to refine the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor, and manage. One way to do this is to represent the risk in condition-transition-consequence (CTC) format.that is, the risk is stated in the following form: Given that <condition> then there is concern that (possibly) <consequence>. All reusable software components must conform to specific design standards and that some do not conform, then there is concern that (possibly) only 70 percent of the planned reusable modules may actually be integrated into the as-built system, resulting in the need to custom engineer the remaining 30 percent of components. This general condition can be refined in the following manner: Subcondition 1. Certain reusable components were developed by a third party with no knowledge of internal design standards. Subcondition 2. The design standard for component interfaces has not been solidified and may not conform to certain existing reusable components. Subcondition 3. Certain reusable components have been implemented in a language that is not supported on the target environment. The consequences associated with these refined subconditions remains the same (i.e. 30 percent of software components must be customer engineered), but the refinement helps to isolate the underlying risks and might lead to easier analysis and response 7. RISK MITIGATION, MONITORING, AND MANAGEMENT All of the risk analysis activities presented to this point have a single goal to assist the project team in developing a strategy for dealing with risk. An effective strategy must consider three issues: risk avoidance risk monitoring risk management and contingency planning If a software team adopts a proactive approach to risk, avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation. For example, assume that high staff turnover is noted as a project risk, r1. Based on past history and management intuition, the likelihood, l1, of high turnover is estimated to be 0.70 (70 percent, rather high) and the impact, x1, is projected at level 2. That is, high turnover will have a critical impact on project cost and schedule. To mitigate this risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, and competitive job market). Mitigate those causes that are under our control before the project starts.

13 Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave. Organize project teams so that information about each development activity is widely dispersed. Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner. Conduct peer reviews of all work (so that more than one person is "up to speed ). Assign a backup staff member for every critical technologist. As the project proceeds, risk monitoring activities commence. The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely. In the case of high staff turnover, The following factors can be monitored: General attitude of team members based on project pressures. The degree to which the team has jelled. Interpersonal relationships among team members. Potential problems with compensation and benefits. The availability of jobs within the company and outside it. 8. EXPLAIN THE RMMM PLAN? A risk management strategy can be included in the software project plan or the risk management steps can be organized into a separate Risk Mitigation, Monitoring and Management Plan. The RMMM plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan. Some software teams do not develop a formal RMMM document. Rather, each risk is documented individually using a risk information sheet (RIS). In most cases, the RIS is maintained using a database system, so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily. Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence. As we have already discussed, risk mitigation is a problem avoidance activity. Risk monitoring is a project tracking activity with three primary objectives: (1) to assess whether predicted risks do, in fact, occur; (2) to ensure that risk aversion steps defined for the risk are being properly applied; and (3) to collect information that can be used for future risk analysis. In many cases, the problems that occur during a project can be traced to more than one risk. Another job of risk monitoring is to attempt to allocate origin (what risk(s) caused which problems throughout the project).