Download
risk management in software projects n.
Skip this Video
Loading SlideShow in 5 Seconds..
Risk management in Software Projects PowerPoint Presentation
Download Presentation
Risk management in Software Projects

Risk management in Software Projects

157 Vues Download Presentation
Télécharger la présentation

Risk management in Software Projects

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Risk management in Software Projects José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003-2004

  2. Índice • Failure and root causes. • Risk Definition • Formas en las que se afrontan las causas de las desviaciones • Elementos de la Gestión de Riesgos • Identificar los factores de Riesgo • Evaluar la probabilidad y el efecto • Desarrollo de estrategias para mitigar los riesgos • Monitorizar los factores de riesgo GpiI-3C Risk management in Software Projects

  3. Failure and root causes. • Software projects fail if: • Software never runs. • Don’t accomplish same expected functions. • Software isn't delivered on time. • Higher cost than expected. • Reasons: • High level of complexity (communications, interrelation with other systems, etc..) • Uncertainty. It wasn’t clear the objective. GpiI-3C Risk management in Software Projects

  4. Risk Definition (Fairley) • Risk is a potential problem. • Problem is a risk that has materialized. • By a problem, we mean an undesirable situation that will require time and resources to correct. • (may be uncorrectable). • A risk is characterized by: • The probability that occur (0<P<1) • A loss associated GpiI-3C Risk management in Software Projects

  5. Risk factors fall into two categories • Generic risks, common to all software projects, then we tray to improve the organization to overcome this risks or we have a check list. • Project specific risks. • This are complementary points of view we must act on both. GpiI-3C Risk management in Software Projects

  6. Most Common Software Risks (1) (Caper Jones) • Ambiguous improvement targets.(4) • Creeping users requirements.(9) • Crowded office conditions.(10) • Excessive schedule pressure.(13) • Excessive time to market.(14) • Inaccurate cost estimating.(19) • Friction between: • Client and software contractors.(16) • Software management and senior executives.(17) GpiI-3C Risk management in Software Projects

  7. Most Common Software Risks (2) (Caper Jones) • Inadequate compensation plans.(24) • Inadequate configuration control and project repositories.(25) • Inadequate Curricula (S.E., S.M.)(26, 27). • Inadequate package acquisition methods.(29) • Inadequate software policies and standars.(31) • Inadequate tolls and methods (project management, Quality assurance, software engineering, technical documentation…)(34-37) GpiI-3C Risk management in Software Projects

  8. Most Common Software Risks (3) (Caper Jones) • Lack of reusable code, data, test, human interfaces.(41-47) • Lack of specialization (48). • Low user satisfaction(53). • Low productivity.(50) • High maintenance costs.(18) • Partial live cycle definitions.(57) • poor technology investments. • Silver bullet syndrome.(62) GpiI-3C Risk management in Software Projects

  9. Specific risk causes. • “When a project is successful, it is not because there are no problems, but because the problems were overcome .” • We can act: • Reactive: we wait problems and then we act on them. • Proactive: We identify potential problems and act in anticipation GpiI-3C Risk management in Software Projects

  10. Risk management elements • Different techniques to work whit risk. • The spiral life cycle. • Check lists • Risk management. • This methods can work all together. GpiI-3C Risk management in Software Projects

  11. Risk management procedures • Identify risk factors • Asses risk probabilities and effects on the project • Develop strategies to mitigate identify risks • Monitoring Risk factors • Invoke a contingence plan. • Manage the crisis. • Recovery from a crisis. • Fairley, R. IEEE Software Mayo 1994 GpiI-3C Risk management in Software Projects

  12. Identify risk factors • You must visualize the project development and identify “wrong” things. • If you have a checklist with problems in other projects you work then revise that list. • “Who don’t know their past is commended to repeat” GpiI-3C Risk management in Software Projects

  13. You must difference cause (risk factors), problems and symptoms. • Whether you identify a situation as a risk or an opportunity depends on your point of view. • Is the glass half full or half empty? • Situations with high potential for failure often have the potential for high pay back. GpiI-3C Risk management in Software Projects

  14. Asses risk probabilities and effects on the project • Evaluate the probability of this problem. • Evaluate the effect the problem would have on the project desired outcome. • Classify risks with the Risk exposure, calculated as: • Probability * Effect • As a consecuence we will identify more important risks. GpiI-3C Risk management in Software Projects

  15. Evaluación de la probabilidad de que se de el problema. • Not all the problems have the same probability. • Some times evaluating the probability is something difficult, use • Similar cases . • Optimist, pessimist and more probable. • Remember the Murphy law: • “if something can go wrong, it will do” • We can use simulation tools. GpiI-3C Risk management in Software Projects

  16. Develop strategies to mitigate identify risks • Two types of strategies: • Action planning. • Addresses risks that can be mitigated by immediate response • Contingency planning. • We accept the risk and we plan and control the risk. GpiI-3C Risk management in Software Projects

  17. Action planning • We minimize or vanish the risk. • We take action before the problem will materialize. • Example: • Problem: We can have problem using new tolls. • Action: We hire a experienced worker whit this tools GpiI-3C Risk management in Software Projects

  18. Contingency planning • We accept the risk and we prepare a plan and we will use this if the risk is materialized. • The actions to take are: • Identify variables to be control in order to detect that the problem is here. • Create an action plan to be used during the crisis, as a consequence of this problem. • Planning the crisis recovery. GpiI-3C Risk management in Software Projects

  19. Monitoring Risk factors • We observe identify symptoms, grouped. • We must quantify in a precise manner with objective, timely and accurate metrics. • We must have a clear control limits • We need a tradability between risk factors and risks. GpiI-3C Risk management in Software Projects

  20. Invoke a contingence plan • When a quantitative risk indicator crosses a predetermined threshold. • Usually you can have different levels, • At first levels the operative level take action, • If can’t correct the situation then the contingency plan will start. GpiI-3C Risk management in Software Projects

  21. Manage the crisis • Despite a team’s best effort, the contingence plan may fail, in which case project enters crisis mode GpiI-3C Risk management in Software Projects

  22. Recovery from a crisis • After a crisis certain actions are required: • Reward personnel who have worked in burnout mode, • Reevaluating cost and schedule in light of the drain on resources from managing the crisis. GpiI-3C Risk management in Software Projects

  23. Bibliografía • Fairley, R. “Risk Management for Software Development” en Software Engineering editado por Dorffman, M y Thayer, R.H., IEEE Computer Society, 1997 • Fairley, R. “Risk Management for Software Projects”, IEEE Software, Mayo 1994 • Jones, C. Assessment and Control of Software Risks. Yourdon Press, Prentice Hall, 1994. GpiI-3C Risk management in Software Projects