T T. Think Together Sandra Milena Choles Arvilla THINK TOGETHER. Srovnávání řízení rizik pro softwarové projekty

Transcription

1 Česká zemědělská univerzita v Praze Provozně ekonomická fakulta Doktorská vědecká konference 7. února 2011 T T THINK TOGETHER Think Together 2011 Srovnávání řízení rizik pro softwarové projekty Comparative of risk management practices for software projects Sandra Milena Choles Arvilla 217

2 Abstrakt Cílem této práce je analyzovat stávající postupy používané pro rizikový managment a zjistit ty nejvhodnější procesy pro průmyslový vývoj softwaru. Tento výzkum je prováděn na základě záměru navrhnout více průmyslový a praktický model pro řízení rizik softwarových projektů. Postupy a modely vybrané pro tuto problematiku jsou procesy řízení rizik, které byly definovány nejznámějšími autory v této oblasti. Klíčová slova Riziko, řízení projektů, softwarové projekty, model. Abstract The aim of this paper is to analyze the existent practices used for risk management in order to extract the most relevant processes for the software development industry. The motivation for this research is to design a more industrial and practical model to manage risk on software projects. The practices and models considered for this paper are the risk management processes defined by the most known authors of this field. Key Words Risk, project management, software projects, model. INTRODUCTION Every day the need for new software solutions is bigger and more demanding. This phenomenon requires that software development companies improve their processes in order to deliver a quality product. According to ISO 9000:2000 the definition of quality is: The degree to which a set of inherent characteristics fulfills requirements. (ISO 9000, 2000). These requirements are typically related to the provision of a specific product, service or intangible item. Main interest of a customer is to acquire a product at fair prices and be satisfied, which means the product/service should comply with all customer s needs. Every software development deals with significant amount of uncertainty that may affect the final quality. Main critical aspects that software project team has to deal with are: Over costs, short deadlines and customer dissatisfaction. It is expected that all the functionalities of the software are reliable, stable and last but not least with the minimal complexity possible. Another aspect related with software quality are maintainability, portability and leanness. All this conditions should be achieved within a specific environment where new or unproven technology can be involved. According to this definition the final product should accomplish the cost expected, should be delivered on time and comply with all the features required by the user. We can see how trough the main 3 critic aspect mentioned before; even more critical situations can be detected, as it is the use of unproven technology. ISBN:

3 These kind of situations are usually considered as risks that may compromise the success of the software project. Risk is not always a problem. It is a possible event that could produce a loss. Risk is a part of any activity and can never be totally eliminated. Also, it is important to notice that risk cannot always be identified, for which every project team should be prepare. There is always an opportunity for improvement with every possible risk. This could be taken as a very positive perspective, nevertheless without the existence of risk there is no possibility of progress, improvement or development. Objectives and methodology The main objective of this paper is to make a review of the existent risk management methodologies and to analyze the need of a new strategy that could response to the new trends in software development, as it is agile development. The methodology used during this work and consists of the following points: 1. The content of the first phase of analysis is the study of theoretical sources of basic knowledge and models. 2. The second phase will be dedicated to examining current demand of developing strategies. 3. The third stage is to initiate a formulation of a new strategy based on the knowledge gained during the previous two phases. DEFINITIONS AND GENERAL PROBLEM Project Management Project management is the collection of knowledge, skills, strategies and tools to achieve the objectives of a specific project. As a result is the satisfaction of the parties involved in the project. It is important to clarify the main characteristics of a project. A unique and temporary task with a specific purpose is usually considered a project. There are some misunderstandings when the word program and/or operation are used. A program is a set of projects and operations are regularly tasks always for the same objectives. (PMBOK, 2009) Among all the processes belonging to project management there are some processes designated to the analysis, evaluation and control of risks that may occur during all the stages of the project and can compromise the success of it. There are many factors that can make a project a complete failure. These factors are usually attributed to poor planning, which really means that such planning was done with simplicity and therefore were not referred to situations or factors that change the course the project during its development. The planning stage is to experience one of the most definitive if not the most important. Any decision to tone during this period affected positively or negatively other phases of the project according to realistic assumptions have been made. External factors play an important role during the development of a project and are rarely considered and/or evaluated during the preliminary stages of the project, what is even worse, in Think Together 2011 Dostupné z:

4 most cases the potential threats that may affect a project are not estimated. What exactly does risk mean? What are the events or conditions that could affect the project in a negative way? Many definitions have been produced for the word risk but there is always a constant; risk is a future event that brings the possibility of changing the expected results of specific situation. Risk management Risk management covers all the activities necessary to reduce the effect of unexpected events in a project. Most of authors agree on the key steps to be developed for risk management: identification and response. These big steps have subsidiary steps that may vary according to the situation or business. Risk management is not an independent discipline; it is a part of the whole project management strategy. As a consequence risk management processes are directly connected with the additional processes of the project development. RM methodologies What follows is a review of the most known models and/or strategies for risk management. Boehm s model: Barry W Bohem know as the father of the software risk management propose a model in 1991 who distinguished two principals steps, each one divided in substeps as it follows: Risk assessment: risk identification, analysis, prioritization. Risk control: risk management planning, resolution and monitoring. The types of risks considered by Bohem are: Personnel shortcomings, unrealistic schedules and budgets, wrong development, extra development, unstable requirements, shortfalls in externally components and tasks, and forced computer-science capabilities. He also proposed a scale for the probability of occurrence and according to this scale the impact of the risk can be evaluated (Bohem, 1991). SEI s risk management approach: SEI propose a framework based on three groups of practices: software risk evaluation, continuous risk management and team risk management. The Software Engineering institute has defined the risk taxonomy, which classifies the risk into several categories like: requirements risks, design risks, coding and testing risk, contract risks, and resources risks. A special element of this approach is the team risk management which defines methodologies, processes and tools for developing working relationships between the customers and suppliers (Higuera, Haimes, 1996). ISO standard for risk management (ISO 31000:2009) consists in a set of principles to be accomplished in order to make risk management a useful and effective practice. This standard can be applied at any time following the development, implementation and continuous improvement of a specific framework which considers risk management processes as part of the regular operation of a company or organization. ISO covers three clauses: a set of principles, a framework and a series of process to manage risk. These clauses are linked. This standard applies to any kind of company and organization. For our interest I will describe it in terms of software engineering relevancy. ISBN:

5 The framework defined by ISO for the management of risk has 4 components which are strictly connected: Mandate and commitment: This component demands total compromise by the management of the organization or project, who should accomplished a series of tasks to prepare the basis of the strategy and aligned it to the current situation and goals of the organization. Management should define and approve the risk management policy. During this phase all the necessary resources should be allocated. Important procedure is to communicate all the stakeholders the benefits and implications of risk management strategy implementation. Design of framework for managing risk: The first step would be the analysis of the internal and external context of the organization or project. ISO gives the minimum aspects that should be analyzed but note that this is not limited. According to each company s interest the analysis could be deeper and/or wider. Establishing risk management policy should be set and basically it should define responsibilities for risk management within the project or company, the necessary resources, the way in which risk management performance will be measured and reported and the links between the objectives of the project and risk management policy. Is important to note that ISO proposes only a generic standard that provides guidelines for the risk management, nevertheless the quantification and evaluation of risks may be specified using alternative techniques like the ones mentioned in the first part of this paper. Implementing risk management requires setting the appropriate timing. During implementation all the regulatory requirements should be complied. The communication and consult with stakeholders should remain appropriate. Monitoring and review of the framework is necessary to ensure the effectiveness of risk management. This should be done measuring the performance against indications previously defined. Also periodically review of the policy and framework are required. Based on results of reviews and measurements some improvements could be implemented. As an additional part of the process ISO requires a record of the progress and activities of the risk management process. These records provide the necessary information for improvement and future appliance in different projects. There are some other risk management approaches from very important computer science authors that I would like to mention but I will not go deep in details (Misra, Kumar, 2006). The Hall s P 2 I 2 approach which covers four specific factors: People, Process, Infrastructure and Implementation. According to Hall these are the most influential factors that may change the expected results. Kontio s Riskit methodology proposes the design of the Riskit analysis graph to analyze all risk elements. All of these models may have been developed from a different point of view, according to different risks analyzed. Some of them like in Boehm s case propose to attack the risk in the early stages of development, some authors consider wiser to keep a control of risks during all the phases of the project. Think Together 2011 Dostupné z:

6 The common point of all the models and strategies mentioned in this paper is that they all keep the theoretical concept but the details of the risk measurement are left to the human subjectivity of each project team or risk analyst. There are few works that intend to provide a more precise scale of risk evaluation like FMEA developed by the US Armed forces to be used with military purposes. After some decades this technique has been used for all kind of purpose and business. FMEA presents a simple scale from 1 to 10 to rank the severity, occurrence and probability of detection of a risk. As a result of the combination of these 3 scales, the risk priority number is calculated. Nevertheless in my opinion there is still a lack of precision for risk ranking. The ISO standard provides a complete framework that can be the resume of all the older models. The special interest on ISO standard is due to the simple and clear presentation of the main concepts, process and guidelines of risk management. The companies are interested in this kind of practices but they don t count with the appropriate knowledge to implement them. ISO provides a simple way to address companies to the efficient implementation of risk management framework. Personally I considered that the more effort invested in the early development steps the less possibility of dangerous risk occurrence. However, the new development trends require a dynamic and fully present risk management strategy that can allow redesign and implementation in late development stages. Emerging software development trends and its RM demand Different software development trends have become aim of many studies in the last decade. As much has been talked, companies started to show some interest for them as they claim faster and more reliable development. According to (Andrews, 2009), (Allam, 2008), (CIOL, 2010) some of the trendiest practices are Saas, SOA and Agile development. Software as a service (Saas) known also as Application Software Provider model (ASP), has a level of risk that may incur in data control lost, security vulnerability among another failures. This model requires a RM plan focused in the protection of data. (SIIA, 2001) Service oriented architecture (SOA), one of the risks present in this architecture is the complex model adoption (Bhatt, 2008). Risk management strategy should focus its effort in business integration potential failures. Agile methodologies were created to produce quantitative results to the user as fast as possible and to allow flexible design and development. The main principle is an iterative life cycle. Risk management current methodologies define a linear progress that may not be the most appropriate for agile development. The need of agile development born as a response to one of the most common failures in software projects: software delivered doesn t fulfill user requirements due to lack of communication and business oriented analysis and planning. ISBN:

7 INITIAL PROPOSAL Classic software life cycle and classic risk management methodology are fully integrated and may have proved their success, however new trends require a change in risk management cycle. The figure no. 1 shows the classic waterfall life cycle, the background colors represent the presence of risk management processes. Yellow represents risk assessment which includes: identification, analysis and evaluation of the risk. Brown shows risk control and red color is for risk review. Analysis Figure no. 1: Waterfall software life cycle Design Implementation Testing Maintenance The agile development requires iterative processes. During every iteration of the development should be present a full cycle of risk management: Assessment, mitigation and review. Risk management for agile development requires less formality and more response, continuous risk measurement and response actions should be the core of the risk management plan Figure no.2 shows an initial proposal for appropriate integration of risk management model and agile development. RMP refers to risk management plan setting, RID as risk identification and RMS as risk measurement. Figure no. 2: Iterative development and RM model Risk mitigation is integrated within the development iteration; the results of the mitigation will feed the adaptation of the risk management plan after each round. This model requires the presence of risk analysis in all the stages of the development and continuous feedback to generate more accurate response. CONCLUSIONS The missing question is how precise is the ranking of risk. After an extended reading of many authors and opinions of risk management models, I will propose the combination of the elements that are present in software engineering projects and the design of a more precise risk ranking scale. The actual demands for technology requires faster results and equal quality. We have seen how the rise for new alternative for software development try to solve this situation. A clear example is the agile software development that provides a series of methodologies which main characteristics are the iterative and incremental approach. The time spent for analysis and design is seriously reduced in these methodologies, this can result in lack of quality and possible project fail. Think Together 2011 Dostupné z:

8 Risk management current proposals are focused in classic development methods which means that a new risk management model specifically designed for agile development should be defined. My intention is to integrate the already existing concepts of risk management with the new agile development principles to create a formal risk management model for agile technologies. LITERATURA Higuera R. P., Haimes, Y. Y. (1996): Software Risk Management Technical Report, Report # CMU/SEI-96-TR-012, Software Engineering Institute, Carnegie Mellon University, USA. Boehm, B. W. (1991): Software Risk Management: Principles and Practices, IEEE Software, 8(1): International Organization for Standardization (ISO) (2009): ISO 31000:2009 Risk Management: Principles and Guidelines., Geneva. International Organization for Standardization (ISO) (2009): ISO 9000:2000 Quality management systems., Geneva. Van Scoy, Roger L. (1992): Software Development Risk: Opportunity, Not Problem Software Engineering Institute (CMU/SEI-92-TR-30, ADA ), USA. Misra C. S., Kumar V., Kumar U.(2006): Different techniques for risk management in software engineering: a review Eric Sprott School of Business, Carleton University, Canada Project management institute (2009): A guide to the Project Management Body of Knowledge 4th edition, USA Top 10 trends in software development 2009 (2008). CYBERMEDIA INDIA ONLINE LIMITED - (CIOL), India. Available at 10-trends-in-software-development-2009/ /0/ (accessed January 2011). Trends in software testing for 2011 (2010). CYBERMEDIA INDIA ONLINE LIMITED - (CIOL), India. Available at Allam, Mahmoud (2008): New Trends in Software Engineering, Communication & Information Technology Program, Nile University, Egypt (SIIA) Software and information industry association (2001): Software as a service: Strategic backgrounder, Washington D.C., USA Bhatt, Amit (2008): SOA (Service oriented architecture), Bynary Semantics. ISBN: