cerned with risk management for software development projects. The literature on risk management for soft- ware maintenance is much scarcer. On the other ...
A Risk Taxonomy Proposal for Software Maintenance Kˆenia P. Batista Webster, K´athia M. de Oliveira, Nicolas Anquetil UCB - Catholic University of Brasilia SGAN 916 M´odulo B - Av. W5 Norte Brasilia - DF - 70.790-160, Brazil {kathia,anquetil}@ucb.br Abstract There can be no doubt that risk management is an important activity in the software engineering area. One proof of this is the large body of work existing in this area. However, when one takes a closer look at it, one perceives that almost all this work is concerned with risk management for software development projects. The literature on risk management for software maintenance is much scarcer. On the other hand, software maintenance projects do present specificities that imply they offer different risks than development. This suggests that maintenance projects could greatly benefit from better risk management tools. One step in this direction would be to help identifying potential risk factors at the beginning of a maintenance project. For this, we propose a taxonomy of possible risks for software management projects. The ontology was created from: i) an extensive survey of risk management literature, to list known risk factors for software development; and, ii) an extensive survey of maintenance literature, to list known problems that may occur during maintenance.
1
Introduction
Risk management for software is considered as one of foremost best practices to be applied in software projects [1, 5]. As such it received lot of attention and there are numerous publications on risk management (e.g. [3, 19, 17, 21, 26, 28]), risk identification methods (e.g. [6, 20, 25]), etc. However, despite this profusion of work, there has been very little study on risk management for software maintenance projects [8]. Although it is the activity most practiced in industry (up to 90% of the work according to some research [29, 30]), software maintenance receives less attention
than other activities in software engineering1 . This is also true for risk management [8]. Maintenance suffers from an erroneous view that equates it to bug correction. However, studies (for example cited in[15, 30]) show that corrective maintenance accounts for only (approximately) 20% of all maintenance, whereas the larger part (up to 50%) is due to evolutive maintenance (implementation of new requirements). Actually, maintenance is an unavoidable activity required to keep systems synchronized with the reality they are modeling, a reality that changes continuously. Maintenance also presents specificities that set it apart from software development [8, 15]. In risk management, this implies that existing methodologies for identification, evaluation and management of risk factors, which were created for development projects, may not be adequate for maintenance projects. On the other hand, reports suggest that risk management would contribute to improve the quality and efficiency of software evolution [7, 34]. Considering the importance of both software maintenance and risk management for the industry we started a project on Risk Management for Software Maintenance. A first goal in this project was to establish the means to identify potential risks of a new maintenance project. A well accepted method for this is to use some kind of check list or risk taxonomy. In this article, we propose such a taxonomy for maintenance project risk factors. This taxonomy was established from two literature researches, both on software development risk factors and software maintenance known problems. The organization of the article is the following: First, in Section 2 we review some basic concepts of risk management for software projects. Section 3 discusses software maintenance, its importance and typical prob1 For example, Grubb and Takang state that “maintenance models are neither so well developed nor so well understood as models for software development.” [15, p.71]
lems it may face. Then, in Section 4, we present the methodology we followed to create the taxonomy of risk factors for software maintenance. This taxonomy is presented and discussed in Section 5. Finally, we present our conclusion and future work in Section 6.
Risks in Software Projects
A risk, in a software project, is an event which occurrence is uncertain and that could impact negatively the project if it should occur [18, 19, 26, 34]. The definition highlights two intrinsic properties of risks:
Impact
2
Table 1. Example of a probability/impact matrix to classify risks
high medium low
high critical critical medium
Probability medium low critical medium medium marginal marginal marginal
Uncertainty: A risk is defined as an uncertain event, when it does happen, it is no longer a risk but becomes a problem.
In the next section we will summarize some important facts on software maintenance to illustrate the importance of this activity. We will also comment on the necessity and current scarcity of research on risk management for maintenance.
Loss: A risk is a (possible) event which would damage in some way the project if it should happen.
3
In [20], Keil et al. studied various systems after delivery and established that many problems encountered could have been avoided if risk management had been applied during the projects. To increase the chances of success of a software project, one must constantly monitor possible risk factors, foresee possible solution should they occur, prepare for the possible occurrence of the risk, detect such occurrence when it happens, evaluate the severity and actual impact of the event, and apply the needed correction. There is no unique definition on how one should go about managing risks, however, in the various approaches proposed (e.g. [3, 9, 16, 19, 14, 28, 35, 10]) two activities arise as fundamental: Identification: Risk identification consists in enumerating all possible risks for a project (before they occur) [19]. There are many ways to identify risk factors (e.g. brainstorming session, fishbone diagram, etc.) but the most cited appears to be the use of a taxonomy of possible risks from which one identifies those that may apply to a particular project. Analysis: Risk analysis consists in quantifying each identified risk in terms of its probability of materializing and its potential impact [11, p.20]. Using a matrix of probability and impact, risks may be classified from critical (high probability and high impact), to marginal (low probability and low impact). Table 1 illustrates an example of such a matrix. In this paper, we propose a taxonomy of risks for software maintenance as a mean to facilitate the identification of risk factors in maintenance project.
Software Maintenance
Maintenance is traditionally defined as any modification made on a system after its delivery. Studies show that software maintenance is, by far, the predominant activity in software engineering (90% of the total cost of a typical software [30, 36]). It is needed to keep software systems actual and useful. Any software system reflects the world within which it operates. When this world changes, the software needs to change accordingly. Lehman’s first law of software evolution (law of continuing change, [22]) is that “a program that is used undergoes continual change or becomes progressively less useful”. Maintenance is mandatory, one simply cannot ignore new laws or new functionalities introduced by a concurrent. Programs must also be adapted to new computers (with better performances) or new operational systems. Maintenance differs from development for a number of reasons, including: Lack of documentation: Developers may rely on the fact that somebody (hopefully close by) knows one specific portion of the system, in the best cases there may even be a clear documentation. Maintainers must often work from the source code to the exclusion of any other source of information. Event driven: Development is requirement driven, one specifies the requirements and then plan their orderly implementation. Maintenance is event driven [30], external events require the modification of the software. There is much less opportunity for planning. Obsolete techniques: Developers may organize the system as best suits the requirements. In the best
cases, they may even be able to choose the programming paradigm and language, the hardware platform, etc. Maintainers must cope with choices made by others in the past. The programming language may be old (e.g. COBOL), the system architecture may not fully support the modification they need to implement, and it may even be so obfuscated by past modifications that there is no longer any clear architecture. Differing processes: The process of maintenance is different in that it requires new activities up-front which do not exist in development. For example, maintenance requires to analyze in depth the system to be modified before any analysis of the task at hand starts2 . Because of this, the bulk of the effort in a maintenance project is applied at the beginning of the project, whereas it is applied towards the end of a development project (during the implementation and test3 ) [15]. In development, the initial activity (requirement elicitation) may be difficult, but it typically requires less effort than the implementation because much less details are involved. System in operation: During maintenance, the system is in operation, this may significantly increase the difficulty of altering the system while maintaining it operational. These characteristics make maintenance an activity quite different from software development. They also imply that risk factors for software maintenance need not be the same as for software development [8]. This is why we were led to define a taxonomy of risk factors for software maintenance. The next section will explain the methodology we followed to create the taxonomy. The taxonomy itself is presented in Section 5.
4
Creating the Taxonomy
If risk management for software maintenance may be performed the same way as for software development, the risks encountered are not always the same (see previous section), and even when they are the same, they may have a different importance (for example a stronger impact) because of the differing conditions in which maintenance is performed. As was explained in 2 The analysis of the system is made even more difficult by the usual lack of documentation on the system. 3 In many maintenance projects (for example of legacy software), the test activity is crippled by the lack of previous test cases, the lack of detailed understanding of how the system should behave, and the pressure for a rapid delivery of the change.
Section 2, an important activity for risk management is the identification of the risk factors of a project. A taxonomy is a recommend tool to help in this identification. In this paper, we propose a taxonomy of risk factors for software maintenance projects. This work was necessary as we found little work listing risk factors for software maintenance. For example, although Charette et al. [8] do state that risk factors for software maintenance are different, they use the taxonomy of risk factors proposed by Carr et al. [6] which focuses software development. Table 2. References used to build the taxonomy # of risks proposed SOFTWARE DEVELOPMENT RISKS Boehm 1991 [4] 10 (also in [2, 21]) [37] Soeiro 1999 18 [17] Houston et al. 2001 30 [20] Keil et al. 1998 11 [25] Machado 2002 62 [1] Addison, Vallabh 2002 14 [27] Mizuno et al. 2000 23 Sommerville 2001 [38] 14 (chap. 4) [26] McManus 2004 20 [35] Schawlbe 2002 21 [11] deMarco, Lister, 2003 5 [6] Carr et al. 1993 64 [18, 19] Jalote 1999 & 2002 10 [32] Pressman 2001 10 [13] Fontoura, Price 2004 13 [23] Leopoldino 2004 32 [12] Farias 2002 15 [41] Williams et al. 1997 10 SOFTWARE MAINTENANCE RISKS [15] Grubb, Takang 2003 7 [29] Pfleeger 2001 12 [8] Charette 1997 7 [24] Lientz, Swanson 1981 23 [30] Pigoski 1996 18 [34] Schneidewind 2002 7 [31] Pigoski 2001 7 [33] Schneberger 1995 1 Sommerville 2001 [38] 9 (chap. 26, 27) Reference
Our taxonomy is based on adaptation of risk fac-
382 risk factors (development)
91 risk factors (maintenance)
Integration Integration 198 risk factors (development) 53 risk factors (maintenance)
2 references
56 risk factors (development)
Integration
92 risk factors
Figure 1. Construction process of the taxonomy
tors already documented for software development, and identification of problems specific to software maintenance. We conducted a survey of risk management for software development and found 382 risk factors in 18 publications (listed in Table 2). As a comparison, we found only one reference for software maintenance [34] listing 19 risk factors. In lack of references on risk factors for maintenance, we looked for publications listing problems occurring in this activity. the rational is that knowledge acquired in previous similar projects may be used to help identifying risks in new projects [10]. We also verified this fact experimentally [40] when we realized a first experiment on classifying some risk factors for maintenance. We found 84 problems with software maintenance in the literature which added to the seven risks found in [34] made up 91 possible risks for maintenance projects. It would make no sense to propose a taxonomy of
Table 3. Example of integration of similar risks • Performances do not meet expectations (including errors and low quality)4 • Under-performance • Not meeting performance requirements • Link failure or slow performances ⇒ Not meeting performance requirements (ex.: under-performance) risk factors (for maintenance or development) of 473 risks (382+91), therefore we decided to consolidate this list into a shorter one (the various steps of the consolidation are illustrated in Figure 1): • First, we analyzed the list of 382 risk factors for software development to identify and remove possible duplicates. Table 3 presents an example of this integration. This resulted in a list of 198 risk factors. • Second, we ignored all software development risk factors that were not referenced by at least two authors. The idea was to identify the most pertinent risks, eliminating those that were proposed by only one author, possibly in a very specific context. When an author reuses another one’s proposition unmodified (Boehm and Carr’s taxonomies were the most used by others), we did not count this as a second reference as we judged that the second author did not identify risk factors, but merely reused an existing work. Our list of risks was now down to 56 risk factors for software development. • Third, we analyzed the list of 91 risk factors and problems for software maintenance to identify and remove possible duplicates. As there were much fewer risk factors for software maintenance, we did not filter them on the number of references, all risks were considered even if referenced by only one author. This gave us 54 risk factors • Fourth, we integrated the two lists of risk factors resulting from step 2 and 3 to establish a final list of 91 risk factors for maintenance. To complete the creation of the taxonomy, we had to organize these 91 risk factors in categories. We chose to follow the organization scheme proposed by the SEI 3 The text proposed here is our translation from the original Portuguese: “Desempenho aqu´em do esperado (incluindo erros e baixa qualidade)”.
taxonomy [6] since this is the work which was the most cited. This taxonomy is organized in three levels: classes decomposed in elements, where the risk factors are classified. We reused Carr et al.’s three classes, adapting the names when necessary: Product Engineering (technical risks), Maintenance Environment (methodological risks), and Program Restrictions (organizational risks). As for the elements, we reused almost the same as proposed with a few modifications:
Design: Addresses the translation of requirements into an effective design. This element contains eight risk factors. Code: Addresses the transformation of software designs into code that satisfies the requirements. This element contains nine risk factors.
• Two elements (“Code and unit test” and “Integration and test”) of the Product Engineering class were merged into a more general element: “Test”. Several other taxonomies use this more general classification.
Test: Addresses the integrations of code units and the validation of the software product. This element contains two risk factors.
• As a consequence of this merge, the “Code and unit test” element was renamed “Code”.
Engineering specialties: Addresses the maintenance activities that may need specialized expertise. This element contains four risk factors.
• We added a “Legacy” element to the Product Engineering class. The SEI taxonomy is very much focused on development, and we felt the need to have an element reflecting some of maintenance’s specificities. In this case, the “Legacy” element is a recognition of the fact that a software system may come with defects that are independent of the current state of the maintenance organization but may impact a maintenance project.
5
Requirements: Addresses the definition of what the system needs to do. It also addresses the feasibility of maintaining the system. This element contains six risk factors.
Legacy: Addresses some factors depending on the state of the system maintained (mainly non-code artifacts) prior to the maintenance. This element contains three risk factors. The Maintenance Environment class is concerned with the project environment, where the software is being maintained. Its risk factors are listed in Table 5. This class is divided in five elements:
• Element “Contract” was excluded from the Program Restriction class. After steps 1 and 2 (See Figure 1) this element had only one risk left. This risk was transfered to the “Program interface” element.
Maintenance process: Lists the risk factors related to the definition, planning, documentation, suitability, enforcement, and communication of the methods and procedures used to maintain the product. This element contains seven risk factors.
• Two elements (“Development process” and “Development system”) in the Maintenance Environment class were renamed to “Maintenance process” and “Maintenance system”, for obvious reasons.
Maintenance system: Lists the risk factors related to the tools and supporting equipment used in product maintenance, such as CASE tools, simulators, compilers, and host computer systems. This element contains six risk factors.
Taxonomy of Risk Factors for Software Maintenance
As described in the preceding section our taxonomy follows the organization proposed by the SEI [6] with very similar classes and elements. In this section, we present our taxonomy, listing the risk factors contained in each element of each class and the references where those risk factors were found. The Product Engineering class consists of the activities required to maintain the product. Its risk factors are listed in Table 4. This class is divided in four elements:
Management process: Lists the risk factors related to the planning, monitoring, and controlling of budgets and schedules; controlling factors involved in defining, implementing, and testing the product; the project managers experience in software maintenance, management, and the product domain; and the managers expertise in dealing with external organizations including customers, senior management, and other contractors. This element contains nine risk factors. Management methods: Lists the risk factors related to the methods, tools, and supporting equipment that will be used to manage and control the
Table 4. Risk factors for the Product Engineering class • Change may impact directly on other systems’ funcRequirements tionalities [8] • Continuing stream of requirements changes [1, 4, 6, • Change may impact directly on current systems’ 8, 11, 12, 13, 17, 19, 25, 26, 32, 37, 38] functionalities [8] • Requirements incompletely specified [6, 20] • Large number of lines of code affected by change • Requirements unclear (ambiguous or imprecise) [6, request [34] 19, 25, 27] • Change affect an area of the code that is critical to • Requirements misunderstood (do not reflect custhe project [34] tomer intentions) [1, 6, 13, 20, 25, 27] • Large number of principal software functions affected • Gold Plating (i.e. adding more features than is necby the change [34] essary) [1, 4, 13, 26] Test • Performance requirements not met [11, 19, 37] • Inadequate test planning and preparation [6, 26, 29, Design 30, 34] • Limited understanding[29, 31, 33] • Significant cost of repeating full testing on a piece of • Unreliable hardware characteristics or unreliable software [31] vendor support [24, 29] engineering specialties • High level of complexity of the required change [6, • Lack of interactive agreement regarding requirement 17, 25, 34] specifications between the customer and the developer • Developing the wrong user interface [4, 26, 37] [6, 27] • Real-time performances shortfalls [4, 6, 26] • Specifications change inadequate [6, 11, 12, 27, 29] • Hardware constraints [4, 6, 24, 26, 34] • Unclear or misunderstood scope and/or objectives • New technology introduction [1, 13, 19, 20, 23, 25, 37] [1, 13, 23, 35] •Low design quality (system’s components should be • Real-time and highly synchronized systems [29] independent and cohesive) [15, 24, 29] Legacy Code • System documentation nonexistent, incomplete or • Antiquated system and technology [30, 38] outdated [8, 24, 29, 30, 38] • Program code is complex and unstructured [30] • Poor data integrity [24] • Difficulties in understanding programming tricks [38] • Data stored in differing or incompatible formats [38] • Structure of system maintained is corrupted [38] product maintenance, such as monitoring tools, personnel management, quality assurance, and configuration management. This element contains 14 risk factors. Working environment: Lists the risk factors related to the general environment within which the work will be performed, including the attitude of people and the level of cooperation, communication, and morale. This element contains six risk factors. The Program Constraints class consists of the risks external to the project, factors that are outside the direct control of the project but can still have major effects on its success. Its risk factors are listed in Table 6. This class is divided in two elements: Resources: Lists the risk factors related to the external constraints imposed on schedule, staff, budget, or facilities. This element contains five risk factors. Program Interfaces: Lists the risk factors related to the external interfaces to customers, other
contractors, corporate management, and vendors. This element contains 12 risk factors.
6
Conclusion
Risk management is considered a fundamental area of software engineering and project management. However, risk management for software maintenance projects has been little explored and this important activity suffers from a lack of tools to adequately identify and evaluate risk factors. In this paper, we propose a taxonomy of risk factors for software maintenance. Risk factors were integrated from an extensive survey of literature on risk management for software development and on maintenance problems. We identified more than 400 risks in the literature from which we extracted 91 risk factors relevant to software maintenance projects. These 91 risk factors were classified according to the categorization of the risk taxonomy proposed by the SEI [6]. The current taxonomy is a first proposal, several
new references have been pointed to us by the reviewers of ICSM’05 and we will endeavor to update the taxonomy in the light of these new references. A first evaluation of the task showed that it may not bring many changes. We analyzed 47 risk factors listed in [39, p.50] and found them to be generally at a much lower abstraction level than our risks. This results in many of them being more specific than risks factors we already consider (e.g. “Efficiency” is a specific case of “Performance requirements not met”), or over specific (e.g. “No error message”). The next step planned will be to propose an evaluation of the probability and impact of these risks for typical maintenance projects. This proposition will be based on the opinion and experience of maintenance managers. Based on this evaluation, the risks we propose could be prioritized. This would be useful to help maintenance managers getting gradually acquainted with the taxonomy by initially focusing on the risks that are typically most critical. It could also help to validate the effectiveness of the taxonomy by identifying risks that have typically little impact on software maintenance projects.
7
Acknowledgment
This work is part of a project, which is supported by the CNPq, an institution of the Brazilian government for scientific and technological development.
References [1] T. Addison and S. Vallabh. Controlling software project risks - an empirical study of methods used by experienced project managers. In Proceedings of SAICSIT, pages 128–140, Republic of South Africa, 2002. South African Institute for Computer Scientists and Information Technologists. ISBN:1-58113-596-3. [2] J. Adler, T.R.; Leonard and R. Nordgren. Improving risk management: moving from risk elimination to risk avoidance. Information and Software Technology, 41:29–34, 1999. [3] B. W. Boehm. Software risk management. IEEE Press, 1989. ISBN:0-8186-8906-4. [4] B. W. Boehm. Software risk management: Principles and practices. IEEE Software, 8(1):32–41, jan./feb. 1991. [5] N. Brown. Industrial-strength management strategies. IEEE Software, 13(4):94–103, jul./aug. 1996. [6] M. J. Carr, S. L. Konda, I. Monarch, F. C. Ulrich, and C. F. Walker. Taxonomy-based risk identification. Technical report, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, USA, 1993. CMU/SEI-93-TR-6.
[7] CCTA. Risk Handbook. Central Communications and Telecommunications Agency - UK Civil Service, 2000. [8] R. N. Charette, K. M. Adams, and M. B. White. Managing risk in software maintenance. IEEE Software, 14(3):43–50, may/jun. 1997. r [9] M. B. Chrissis, M. Konrad, and S. Shrum. CMMI - Guidelines for Process Integration and Product Improvement. Addison-Wesley, 2002. [10] D. Cleland, editor. A Guide to the Project Management Body of Knowledge - PMBOK Guide 2000 Edition. Project Management Institute (PMI), 2000. [11] T. Demarco and T. Lister. Waltzing With Bears: Managing Risk on Software Projects. Dorset House Publishing Co. Inc., 2003. [12] L. L. Farias. Planejamento de riscos em ambientes de desenvolvimento de software orientados ` a organiza¸ca ˜o. Master’s thesis, COPPE Sistemas - Universidade Federal de Rio de Janeiro, 2002. [13] L. M. Fontoura and R. T. Price. Usando gqm para gerenciar riscos em projetos de software. In J. F. osio Brasileiro de Engende Castro, editor, 18o Simp´ haria de Software, SBES’04, pages 39–54, out. 2004. ISBN 85-7669-002-0. [14] M. S. Framework. Msf risk management. http://www.microsoft.com/msf/ accessed on 05/20/2004. [15] P. Grubb and A. Takang. Software Maintenance: Concepts and Practice. World Scientific Publishing Co., Singapore, 2nd edition, 2003. [16] R. Higuera and Y. Haimes. Software risk management. Technical report, Software Engineering Institute, Carnegie Mellon University, 1996. CMU/SEI96-TR-012. [17] D. Houston, G. Mackulak, and J. Collofello. Stochastic simulation of risk factor potential effects for software development risk management. Journal of Systems and Software, 59(3):247–57, 2001. [18] P. Jalote. CMM in Practice: Processes for Executing Software Projects at Infosys, chapter 8, pages 159–74. Addison-Wesley, 1999. ISBN: 0201616262. [19] P. Jalote. Software Project Management in Practice, chapter 6, pages 93–108. Addison-Wesley, 2002. ISBN: 0201737213. [20] M. Keil, P. E. Cule, K. Lyytinen, and R. C. Schmidt. A framework for identifying software project risks. Communications of the ACM, 41(11):76–83, nov. 1998. [21] Y. Kwak and J. Stoddard. Project risk management: lessons learned from software development environment. Technovation, 24(11):915–920, nov. 2004. [22] M. Lehman. Programs, life cycles and the laws of software evolution. Proceedings of the IEEE, 68(9):1060– 76, sept. 1980. [23] C. Leopoldino. Avalia¸ca ˜o de riscos em desenvolvimento de software. Master’s thesis, Universidade Federal do Rio Grande do Sul, RS, Brazil, 2004. [24] B. P. Lientz and E. B. Swanson. Problems in application software maintenance. Communications of the AC, 24(11):763–69, nov. 1981.
Table 5. Risk factors for the Maintenance Environment class • Management priorities difficulties (ex.: focus on Maintenance process quick fixes in detriment of more robust solution) • Inadequately selected maintenance model, process, [29, 30] methods or tools support [6, 15, 25, 30] • Organizational strategy based on erroneous analysis • Maintainability features not incorporated into the (ex.: Maintenance budget not based on needs analysis) software effort [6, 31] [15, 30] • Lacking or inadequate control of the maintenance Management methods process [6, 23, 27] • Lack of monitoring of activities progresses [6, 25, 27] • Inadequate product control (ex.: product does not • Inadequate maintainer training [6, 25, 30, 32, 37, 38] attend customer’s expectations) [6, 12] • Inadequate quality assurance program [6, 35] • Excessive paperwork [17, 37] • Inadequate configuration control [6, 17, 25, 37] • Lack of adherence to programming standards [24] • Continuing stream of maintenance scope or objec• Difficulties in adapting to a rapidly changing busitives changes [20, 23, 25] ness environment [30] • Inadequate or inaccurate time estimation [23, 35, 38] Maintenance system • Inadequate or inaccurate cost estimation [17, 23, 30, • Insufficient capacity of the maintenance system (ex.: 35] too few work-stations, insufficient processing power, • Inaccurate metrics [17, 37] ...) [6, 38] • Inadequate or inexact effort estimation [37, 27, 32, • Lack of reliability in maintenance system (ex.: due to 38] unavailable components or wrong functions and prop• Performance measurement difficulties [30] erties ) [4, 6, 17, 26] • Contribution measurement difficulties [30] • Poor system support (ex.: training in use of the • Large backlog [24, 30] system, or resolution of problems by vendors) [6, 25] • Poor software and organization impact analysis (crit• Failure when running the system [24] ical skills , documentation and process) [31] • System hardware and software changes [24] • No programming standards [38] • Lack of support for re-engineering [30] Working environment Management process • Lack of team spirit (ex.: internal conflicts requiring • Inadequate planning [6, 25, 27, 35, 37] management intervention) [6, 12, 19, 25] • Ineffective definition of roles and responsibilities [6, • Poor internal communication (ex.: lack of knowledge 27, 35] of the system mission or of its importance for program • Inexperience or inefficiency of management [6, 23, 25] goals) [6, 25, 26] • Lack of interactions (communication) between man• Lack of staff commitment, low morale (e.g. due to agement and stakeholders[6, 25] lack of recognition and respect) [6, 12, 17, 24, 23, 25, • Failure to manage end user expectations [1, 20, 23, 27, 29, 30, 31] 24] • Lack of organizational maturity[17, 25] • Absence of leadership [25, 35] • Low productivity of staff [12, 17, 24, 25, 29, 35] • Lack of effective project management methodology • Lack of incentive to promote maintainability [38] [1, 13, 23, 25] [25] C. Machado. A-risk: Um m´etodo para identificar e quantificar risco de prazo em desenvolvimento de software. Master’s thesis, PPGIA, Universidade Cat´ olica do Paran´ a, 2002. [26] J. McManus. Risk Management in Software Development Projects. Elsevier Butterworth-Heinnemann, 2004. ISBN: 0-7506-5867-3. [27] O. Mizuno, T. Kikuno, Y. Takagi, and K. Sakamoto. Characterization of risky projects based on project managers’ evaluation. In 22nd International Conference on Software Engineering, ICSE’00. IEEE, IEEE Comp. Soc. Press, jun. 04-11 2000. [28] R. L. Murphy, C. J. Alberts, R. C. Williams, R. P. Higuera, A. J. Dorofee, and J. A. Walker. Continuous
[29] [30]
[31]
[32] [33]
Risk Management Guidebook. Software Engineering Institute, Carnegie Mellon University, 1996. S. L. Pfleeger. Software Engineering: Theory and Practice. Prentice Hall, 2nd edition, 2001. T. M. Pigoski. Practical Software Maintenance: Best Practices for Software Investment. John Wiley & Sons, Inc., 1996. T. M. Pigoski. SWEBOK - Guide to the Software Engineering Body of Knowledge, chapter 6 - Software Maintenance. IEEE Comp. Soc., 2001. R. S. Pressman. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 5th edition, 2001. S. Schneberger. Software maintenance in distributed computer environments: system complexity versus
Table 6. Risk factors for the Program Restrictions class • Problems with contracts [6, 35, 37] Resources • Problems with subcontractors [1, 6, 13, 37] • Unrealistic schedules (ex.: due to internal or external • Political factors (company, customer, associate conevents) [1, 4, 6, 8, 11, 12, 13, 19, 24, 25, 26, 32, 37] tractors or subcontractor) [6, 12, 19, 25] • Excessive schedule pressure [17, 25, 24] • Lack of adequate user involvement and/or commit• Staff problems (ex.: lack of expertise, knowledge, ment [1, 13, 20, 23, 24, 37] skills, etc.) [1, 4, 6, 8, 13, 15, 17, 19, 20, 23, 24, 25, 26, • Lack of senior management commitment [1, 6, 13, 27, 30, 31, 32, 34, 38] 17, 20, 23, 24, 30] • Unrealistic budget (ex.: due to internal or external • Conflict between user departments [13, 20, 23] events) [1, 4, 6, 12, 13, 15, 25, 26, 31, 37] • User misunderstanding (ex.: they may provide main• Instability or lack of continuity in maintenance tainers with incomplete or misleading data [24, 29] staffing [12, 15, 17, 23, 24, 25, 29, 30, 38] • User resisting to changes [8, 15, 32] Program Interface • High turnover in user organization [24] • Any problem with customers (ex. slack approval, • Failure to gain user commitment [13, 20] poor communication, lack of commitment, etc.) [6, • Inadequate user training [24] 12, 17, 23, 25, 38]
[34]
[35]
[36]
[37]
[38] [39] [40]
[41]
component simplicity. In International Conference on Software Maintenance, ICSM’95, pages 304–17. IEEE, IEEE Comp. Soc. Press, oct. 17-20 1995. N. F. Schneidewind. Advances in Software Maintenance Management: Technologies and Solutions, chapter VII - Requirements Risk and Maintainability. IDEA Group Publishing, 2002. ISBN: 1591400473. K. Schwalbe. Information Technology Project Management, chapter 10 - Project Risk Management, pages 302–35. Course Technology, Thomson Learning, Inc., 2nd edition, 2002. R. C. Seacord, D. plakosh, and G. A. Lewis. Modernizing Legacy Systems – Software technologies, engineering processes, and business practices. Addison-Wesley, 2003. L. M. Soeiro. M´etodo integrado de gerˆencia em engenharia de software. Master’s thesis, Universidade Federal de Bras´ılia, 1999. I. Sommerville. Software Engineering. Addison-Wesley Publishing Comp., 6th edition edition, 2001. S. R. Vallabhaneni. Auditing the Maintenance of Software. Prentice-Hall, Inc., 1987. ISBN 0-13-050964-7. K. Webster, K. M. de Oliveira, N. Anquetil, and R. Figueiredo. Prioriza¸ca ˜o de riscos para manuten¸ca ˜o de software. In O. Dieste and A. M. Moreno, editors, IV Jornadas Iberoamericanas em Engenieria Del Conocimento, JIISIC’04, volume II, pages 647– 660, Campus de Montegancedo, 28660 Boadilla del Monte, Madrid, Spain, nov. 2004. Servicio de Publicaciones de la Facultad de Inform´ atica de la Universidad Polit´ecnica de Madrid. R. C. Williams, J. A. Walker, and A. J. Dorofee. Putting risk management into practice. IEEE Software, 14(3):75–82, may/jun. 1997.
