| "Software risk management is important | | | | management, and continuous process. |
| because it helps avoid disasters, rework, and | | | | |
| overkill, but more importantly because it | | | | These principles have been adapted into a |
| stimulates win-win situations" - The National | | | | maturity framework that establishes the |
| Aeronautics and Space Administration (NASA), | | | | project management and engineering foundation |
| 1999. | | | | during the initial stages, and quantitatively |
| | | | controls the process during the more advanced |
| Risk is defined as "The possibility of | | | | stages of maturity. |
| suffering harm or loss; danger." Even if | | | | |
| we're not familiar with the formal | | | | Top-down risk estimation maps project risk |
| definition, most of us have an innate sense | | | | into schedule completion dates. Bottom-up |
| of risk. Risks shape many of our behaviors. | | | | risk management puts detail behind the |
| Software Technical Risk can be defined as a | | | | top-down approach. Bottom-up risk management |
| measure of the probability and severity of | | | | identifies underlying project strengths and |
| adverse effects inherent in the development | | | | risks that drive the top-down risk estimate. |
| of software that does not meet its intended | | | | |
| functions and performance requirements. | | | | Using the Project Self-Assessment Kit, these |
| | | | results can be achieved quickly, easily, and |
| The term Risk Management is applied in a | | | | confidentially. The SATC has applied its |
| number of diverse disciplines. To many social | | | | metrics experience and some concepts from |
| analysts, politicians, and academics it is | | | | theoretical models of software quality to |
| the management of environmental and nuclear | | | | develop a unique model for evaluation of |
| risks. Software Risk Management is a | | | | quality and project risks. This model fits |
| proactive approach for minimizing the | | | | the needs of project managers of many |
| uncertainty and potential loss associated | | | | reputable organizations like NASA and GSFC |
| with a project. | | | | because the model is dynamic, not static, in |
| | | | the fact that it allows the production of |
| It includes the set of practices that enable | | | | multiple snapshots of project status across |
| software development projects to identify, | | | | the development. |
| prioritize, address, eliminate and manage | | | | |
| specific software risk items before they | | | | The data is used to make projects about |
| become threats to success or major sources of | | | | specific project risks at project milestones. |
| rework. Some categories of risk include | | | | The model uses a broad range of measures for |
| product size, business impact, | | | | both software products and development |
| customer-related, process, technology, | | | | processes. The model is applicable across the |
| development environment, staffing (size and | | | | development life cycle. The model's metrics |
| experience), schedule, and cost. Awareness of | | | | are derived based on aspects of the |
| Software Risk Management has been increasing | | | | attributes that answer questions of the |
| in the industry. | | | | project managers. The model includes analysis |
| | | | guidelines for the data collected. |
| The primary goal of a software development | | | | |
| project is to develop code and documentation | | | | "Risk Guide 2.30 risk management tools" also |
| that will meet the project's requirements. | | | | helps in managing the risks in software |
| The risks are measured in the testing phase. | | | | development because for successful risk |
| The specific attributes measured during | | | | management effectiveness, continuous and open |
| software development are Maintainability-for | | | | communication is prerequisite. Therefore, |
| ease of finding and fixing the errors, | | | | provide the project stakeholders a broad and |
| Reusability and above all Structure | | | | highly available communication channel |
| Architecture - Evaluation of the constructs | | | | through which they can communicate |
| within a module to identify possible | | | | risk-related information. On top of this |
| error-prone modules. Once code has been | | | | communication facility establish continuous |
| generated and completed, unit testing, formal | | | | risk assessment process based on three |
| testing - System, Integration, and Acceptance | | | | concepts: reviews, snapshots and reports that |
| Testing - begins which usually emphasizes on | | | | underpin the three layers of processing the |
| correctness and reliability of the software. | | | | risk-related information: identification, |
| | | | analysis and reporting and something which |
| Major software projects have the highest | | | | creates a great ease in software risk |
| probability of being cancelled or delayed of | | | | management is risk database which should be |
| any known business activity. Once deployed, | | | | equipped with learning facilities to provide |
| software projects often display excessive | | | | for "learning from experience". |
| error densities and low levels of | | | | |
| reliability. However, it is not a law of | | | | The SEI Software Risk Evaluation (SRE) |
| nature that software projects will run late, | | | | Service is a diagnostic and decision-making |
| be cancelled, or be unreliable after | | | | tool that enables the identification, |
| deployment. A careful program of risk | | | | analysis, tracking, mitigation, and |
| analysis and abatement can reduce the | | | | communication of risks in software-intensive |
| probability of major software disasters, and | | | | programs. An SRE is used to identify and |
| also shorten average development cycles at | | | | categorize specific program risks emanating |
| the same time. | | | | from product, process, management, resources, |
| | | | and constraints. The programs own personnel |
| Poor estimations and planning, wrong status | | | | participate in the identification, analysis, |
| report of projects with misleading and | | | | and mitigation of risks facing their own |
| unacceptably poor software quality and | | | | development effort. |
| reliability are some of those serious and | | | | |
| real issues against software organizations | | | | SUMMARY AND CONCLUSIONS |
| which are agreed by the software executives | | | | |
| and managers themselves. Additional risk | | | | Large software projects are very hazardous |
| factors like new major requirements in | | | | business ventures. For projects above 10,000 |
| mid-development and harmful schedule pressure | | | | function points, cancellations, delays and |
| by the executives that damages quality makes | | | | cost overruns have been the norm rather than |
| it crucial to examine the root causes which | | | | the exception. But careful analysis of the |
| includes process factors, technology and | | | | root causes of large software project delays |
| product factors, and organizational factors, | | | | and disasters indicate that most of the |
| organizational capabilities and explore the | | | | problems stem from inaccurate estimation, |
| current state of the art for minimizing their | | | | inaccurate status reporting, and lack of |
| harmful effects. | | | | historical data from similar projects. |
| | | | |
| Some paradigms, principles, techniques and | | | | All of these root causes can be minimized or |
| tools are used to manage the risks. | | | | even eliminated by the adoption of formal |
| | | | estimating methods and tools, by formal |
| The paradigm is a framework for software risk | | | | monthly status reports of both quantitative |
| management. From this framework, a project | | | | and qualitative data, and by benchmark |
| may structure a risk management practice best | | | | analysis of similar projects to provide a |
| fitting into its project management | | | | solid basis of what can and cannot be |
| structure. It is usually a cyclic process | | | | accomplished. |
| containing identification, analyze, plan, | | | | |
| track, control, formal or informal | | | | The results of these activities are used to |
| communication for achieving a common goal. | | | | develop an actionable framework of risk |
| | | | mitigation actions based on assessor |
| The maturity framework into which these | | | | experience and individual project |
| quality principles have been adapted was | | | | characteristics. Formal risk assessment is |
| first inspired by Philip Crosby in his book | | | | most effective for projects with relatively |
| Quality is Free [Crosby 79]. The staged | | | | significant risk. In addition, the |
| structure of the SW-CMMSM is based on product | | | | organization for which a project is being |
| quality principles that have existed for the | | | | assessed needs to have sufficient project |
| last 60 years. The framework provides the | | | | management infrastructure to be able to take |
| solutions on the basis of seven main risk | | | | action based on the results. The organization |
| management principles-shared product vision, | | | | also needs to have a commitment to improving |
| teamwork, global perspective, forward-looking | | | | project execution effectiveness. |
| view, open communication, integrated | | | | |