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