Software Ecosystems Risks 1
Ekananta Manalif1, Luiz Fernando Capretz1 and Danny Ho2 Department of Electrical and Computer Engineering, University of Western Ontario, London, Canada 2 NFA-Estimation, Richmond Hill, Canada {exx, lcapretz}@uwo.ca,
[email protected]
Keywords:
Software Risks, Software Ecosystems, Software Process, Software Project Management.
Abstract:
Software ecosystems is a new concept in the software arena that emphasizes the inter-networked activities that take place amongst entities during software development and operation. The core of this approach is building the application around shared platforms that are open to every party inside and outside an organizational boundary. This approach has been adopted by software companies in response to the increasing complexity of customer demands and recent trends in global software development, fuelled by the tremendous growth of internet applications. Despite its benefits, companies making the transition to the software ecosystem paradigm face new challenges in their software process activities. This paper identifies some risks inherent to software ecosystems.
1
INTRODUCTION
A software ecosystem is a collection of software systems , which are developed and co-evolve in the same environment. The environment can be organizational like a company, social as a opensource community, or technical such as Ruby ecosystem. A software ecosystems is also viewed as a set of business functioning like a unit interacting with a shared market for software and services, which are related by a common platform and operate through exchange of information, resources, and artefacts (Messerschmitt, 2003). Some argue that software ecosystem is a natural evolution of the foundation underlying: ComponentBased Software Development (CBSD) (Capretz et al., 2001; Capretz and Capretz, 1996; Capretz and Lee, 1992) and Software Product Line (SPL) (Ahmed et al., 2007; Ahmed and Capretz, 2010; Ahmed and Capretz, 2011). These are among the approach that have yielded most gain in productivity for the software industry in the last two decades. Software ecosystems is poisoned to become at the forefront of the software industry fuelled by new business models driven by collaboration and innovation in the software industry. Like component-based software development and software product lines. Software ecosystems offer opportunities of added value, maximizing the use of technologies and increasing services by
means of diverse actors having complementary roles. Following this trend in the software industry, a new research community has emerged, sharing interests in software ecosystems and how they affect the software engineering disciplines. However, the community and practitioners are only now realizing the drawbacks and risks of adopting this new paradigm. These issues will be described in this paper.
2
SOFTWARE ECOSYSTEMS
Bosch (2010) describes software ecosystems as: “A software ecosystem consists of a software platform, a set of internal and external developers and a community of domain experts in service to a community of users that compose relevant solution elements to satisfy their needs”. Although a rather new term, software ecosystems has become a new field of interest, with the promise of reducing development costs by 50%, decreasing defect density by similar magnitude, and substantially increasing the size and complexity of the product portfolio (Popp, 2010). A software ecosystem can be represented in three perspective levels as depicted in Figure 1. They are the Software Ecosystem Level, Software Supply Network Level, and Software Vendor Level (Jansen, 2009).
417
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
popularity amongst large organizations due to their inherent reliance on the adoption of a common architectural development process for multiple product development. In a software ecosystem, organizations are practicing a new process model that embraces other business entities, third party involvement in software development, and open architecture as its central pillars.
Figure 1: Software ecosystem perspective (Bosch, 2009).
The Software Vendor level is represented by an independent software vendor (ISV) that designs, builds, and releases software products and services. The aim of ISV is to maximize profits by selling software and related services to customers. The Software Supply Network level is built by several ISVs, hardware vendors, and service organizations, such as outsourcers, and system integrators that create cooperation in a series linked to satisfy market demands. In the Software Ecosystem level, several business entities function as a unit and build the interaction among them in a shared market for software and services. At this level, Campbell (2010) claims that the traditional walls between development entities have been broken down allowing collaboration and interoperability between parties. The two main reasons for software companies to be interested in moving towards a software ecosystem paradigm are: the understanding that they are not able to develop the necessary functionality in a reasonable amount of time and they lack investment in R&D to fulfil customers needs (Bosch, 2009). Increasing demand in a new and more specific functionality force software vendors to look at the third parties’ developers to add these functionalities to their products (Berk et al., 2010). In this situation, the intra-organizational open platform adopted by SPL companies is shared with the third party developers. According to Bosch (2010), a SPL consists of a software platform shared by a set of products and each product can typically select and configure components in the platform for its own purposes and extend the platform with product specific functionality. Therefore, the software ecosystem becomes the logical next step for software vendors that have a successfully implemented the SPL concept. This is gaining
418
3
SOFTWARE RISKS
Risk is the condition which must be considered in every activity where there are many factors that will affect the result of the activities or subsequent events. Risk always involves uncertainty and loss or can be defined as the possibility of loss (Iranmanesh et al., 2009). In a more detailed description, risk can be understood as a combination of probability or frequency of occurrence of an event and the severity or consequences of the hazard (Hall, 1998). In software development, software risk is defined as a measure of the likelihood and loss of satisfactory outcome affecting the software project, process, or product (Iranmanesh et al., 2009). Risk management starts with the identification of the necessary actions that should be taken to manage the risks. Two main steps in risk-management are riskassessment and risk-control as displayed in Figure 2.
Figure 2: Software risk management (Hall, 1998).
Risk-assessment involves the activities in risk identification and risk analysis, while risk-control involves the activities in risk planning, risk tracking, and risk resolving (Madachy, 1997). Risk management in software development has been recognized as an important activity for software projects and has become necessary for managing and developing software systems since the introduction of the spiral model for the software development life-cycle (Boehm, 1986). On possible way to reduce
SoftwareEcosystemsRisks
risks during software projects is to assign people with personality types best suited to a particular software life cycle phase (Capretz and Ahmed, 2010). In addition, most risk management in software development is based on three frameworks, they are COCOMO (Williams et al., 1997; Manalif et al., 2013), Top Ten Risks Management Method (Carr et al. 1993), and CMM/CMMI (Ahern et al., 2008; Hall, 1998). The COCOMO framework focuses on risk assessment and estimation based on software development cost; whereas the Top Ten Risk Management method is completely based on the subjective judgments of the project manager. CMM provides another model for the software development process and can be used as a framework for regulating software risk assessment and control. CMM uses the basic assumption that a good quality software product is the result of a good quality software development process. CMM has become widely adopted by software development organizations, because it is also designed to function as a risk management plan in the software development process by identifying the key practises in several key process areas (Iversen et al., 2004).
4
RISKS ASSESSMENT IN SOFTWARE ECOSYSTEMS
The most significant advantage of using risk management in software projects is that it helps project managers to focus on many aspects of a problematic situation, identifies potential causes of failure, helps link potential threats to possible preventative actions, and facilitates a shared perception of the project among project stakeholders (Nayak and Suesaowaluk, 2008). The risk assessment phase is the first step in the overall riskmanagement activity, which includes both the risk identification activity and the risk analysis activity. The risk assessment phase is a discovery process of identifying the sources of software risks and analyzing the potential effects of risks on the overall process. This risk identification activity focuses on grouping possible risks to the project into specific structures and classes known as taxonomy. The risk analysis activity prioritizes the risks so that the project manager can determine where the extra effort for risk management should be applied in order to get the maximum benefit. Software Engineering Institute (SEI) Risk Taxonomy depicted in Figure 3, can be used as a
tool for identifying risk and organizing the software development risk into three major classes: Product Engineering Risk, Development Environment Risk, and Program Constraints Risk (Nayak and Suesaowaluk, 2008).
Figure 3: SEI risk taxonomy.
Risks in software ecosystem are related to the challenges in regarding to software architecture and software process. These challenges create uncertainty and possibility of loss in each respective area. The risks related to the challenges in software architecture are: interface stability, evolution management, guaranteeing security and reliability, and the composition of independently developed functionality. The risks that relate to the challenges in the software development process are: the standardized process model, development coordination and management, requirement engineering, and quality assurance. Risk exposure for every identified risk can be determined by assessing and combining the probability/likelihood and potential impact/consequences for every risk using a Probability-Impact Risk Matrix as shown in Table 1. Table 1: Probability-impact risk matrix.
The result of risk analysis of the software ecosystem based on Probability-Impact Risk Matrix is shown in Table 2, in the Appendix.
419
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
Risk in the Product Engineering Class is mostly due to the challenge in the area of software architecture; whereas risk at Development Environment Class is likely due to the challenge in the area of software development process; and risk at Program Constraint Class is due to the fact that the software ecosystem relies heavily on the development activities of the third party software developer. The Risk Priority List, presented in Table 3 in the Appendix, can be generate from Table 2, and show the overall risks that sort by their Risk Exposure from very high to low. From a total of 13 risk elements in 3 risk class category (as presented in Figure 3) there are 5 risk elements that can be categorized as Very-High Risk elements: engineering specialities element, development process element, development system element, management process element, and program interface element. Additionally, 3 risk elements that can be categorized as High Risk elements: requirement element, design element, management method element. The overall risk assessment process in a software ecosystem is shown in Figure 4. Based on this qualitative risk assessment, we can draw the conclusion that the software development activity in a software ecosystem is considered to be a very risky process and as having severe consequences, the rate of success of a software ecosystem project will be very low and will have an unpredictable product quality. The risk assessment conducted in this work is based on the experts' opinion, but this data can be used as an early indication of the potential risk in implementing a software ecosystem. The higher risk is also due to the fact that software development in a software ecosystem is conducted through third party participation, which is not easy to manage. To be able to reduce the risk due to the high level of participation by parties outside the organizational boundary, the software ecosystem, when used as a collaborative software development project, needs a new process model that accommodates a common product vision and architecture, extensive idea and design exchange, continuous information sharing, and a continuing process of consultation, consent, and consensus, which is limited only by such issues as intellectual property, privacy, and security considerations (Nayak and Suesaowaluk, 2008).
5
CONCLUSIONS
Despite its advantages and benefits, there are still some challenges in the area of software architecture
420
and software process that create risks in for software ecosystems. As this new approach has been embraced by software organizations, in this paper we described the background and recent developments in qualitative risk assessment, and necessary actions that should be taken to reduce the software development risk in software ecosystem.
Figure 4: Risk assessment in software ecosystem (Manalif et al., 2012).
As a preliminary approach to study risk in software ecosystem, the risk identification of software ecosystem in this paper is based on a risk taxonomy, risk management, and contingency plan. Risk analysis on software ecosystem has identified 8 risk elements that can be categorized as Very-High Risk and High Risk elements from total 13 risk elements of 3 risk class categories. All of the risks in a software ecosystem are driven by a high level of dependency on a third party software developer, added to the fact that there is no standard process well-established for software development. Consequently, this situation creates
SoftwareEcosystemsRisks
challenges in the area of software architecture and software process development. With the lack of a standard software development process nor a secure risk management procedure, managing software development within a software ecosystem becomes uncertain and therefore very risky. To be able to extract the true benefits of software ecosystem concept, future research in this field should be focused on: modelling and developing a new software development process and software risk mitigation plan, as well as empirical research to study and to test the accuracy and applicability of a new process model that fits the needs of a software ecosystem.
REFERENCES Ahern, D. M., Clouse, A., Turner, R., 2008. CMMI distilled: a practical introduction to integrated process improvement, Pearson Education. Ahmed, F., Capretz, L. F. and Sheihk, S., 2007. Institutionalization of software product line: An empirical investigation of key organizational factors, Journal of Systems and Software, 80(6):836-849. Ahmed, F. and Capretz, L. F. 2010. An organizational maturity model of software product line engineering, Software Quality Journal, 18(2):195-225. Ahmed, F. and Capretz, L. F., 2011. An architecture maturity model of software product line, Innovations in Systems and Software Engineering: A NASA Journal, 7(3):191-207. Berk, I., Jansen, S., Luinenburg, L., 2010. Software ecosystems: a software ecosystem strategy assessment model, Proceedings of the 4th European Conference on Software Architecture, pp.127-134, Copenhagen. Boehm, B. W., (1986). A spiral model of software development and enhancement, ACM SIGSOFT Software Engineering Notes, 11(4):14-24, ACM Press. Bosch, J., 2009. From software product lines to software ecosystems, Proceedings of the 13th International Conference on Software Product Lines, pp.111-119, San Francisco, USA. Bosch, J., Bosch-Sijtsema P., 2010. From integration to composition: On the impact of software product lines, global development and ecosystems, Journal of Systems and Software, 83(1):67-76. Campbell, P. R. J. and Faheem, A., 2010. A threedimensional view of software ecosystems, Proceedings of the 4th European Conference on Software Architecture, pp. 81-84, Copenhagen. Capretz, L. F., Capretz, M. A. M. and Li, D., 2001. Component-based software development, 27th IEEE Conference of the Industrial Electronics Society, Denver, pp. 1834-1837, IEEE Press. Capretz, L. F. and Lee, P. A., 1992. Reusability and life cycle issues within an object-oriented design methodology. Ege, R., Singh, M. and Meyer, B.
(editors), in book: Technology of Object-Oriented Languages and Systems, pp. 139-150, Prentice Hall. Capretz, L. F. and Capretz, M. A. M., 1996. Objectoriented software: design and maintenance, World Scientific, Singapore, 263 pages. Capretz, L. F. and Ahmed, F. 2010. Why do we need personality diversity in software engineering, ACM SIGSOFT Software Engineering Notes, 35(2):11 pages, ACM Press. Carr, M., et al, 1993. Taxonomy–based risk identification, SEI SEI-93-TR-006, Pittsburgh, USA. Hall, E. M., 1998. Managing risk: methods for software systems development, Addison-Wesley Longman. Iranmanesh, S. H., Khodadadi, S. B., Taheri, S., 2009. Risk assessment of software projects using fuzzy inference system, International Conference on Computers & Industrial Engineering, pp. 1149-1154. Iversen, J. H., Mathiassen, L., Nielsen, P. A., 2004. Managing risk in software process improvement: an action research approach, MIS Quart., 28(3):395-433. Jansen, S., Finkelstein, A., Brinkkemper, S., 2009. A sense of community: A research agenda for software ecosystems, 31st International Conference on Software Engineering, pp.187-190, Vancouver, Canada. Madachy, R., 1997. Heuristic risk assessment using cost factors, IEEE Software, pp. 51-59. Manalif, E., Capretz, L. F., Nassif, A .B. and Ho, D., 2012. Fuzzy-ExCOM Software project risk assessment, 11th IEEE International Conference on Machine Learning and Application, Boca Raton, Florida, pp. 320-325. Manalif, E., Capretz, L. F. and Ho, D., 2013. Software project risk assessment and effort contingency model based on cost factors, Journal of Computations & Modeling, 3(1):113-132, International Scientific Ltd. Messerschmitt, D. G., Szyperski, C., 2003. Software ecosystem: Understanding an indispensable technology and industry, MIT Press, Cambridge, USA. Nayak, M. K., Suesaowaluk, P., 2008. Risk factors that affect collaborative software development, 4th IEEE International Conference on Management of Innovation and Technology, pp. 1366-1371, Bangkok. Popp, K. M. and Meyer, R., 2010. Profit from software ecosystems: Business models, ecosystems and partnerships in the software industry, BOD, Norderstedt, Germany. Williams, R. et al, 1997. Putting risk management into practice, IEEE Software, pp. 75-82.
421
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
APPENDIX Table 2: Risk analysis in software ecosystem.
Risk Class
Risk Elements
Description (Challenge Area)
Probability / Impact / Risk Consequence Likelihood Exposure
Requirements
Requirement Engineering (Process)
Likely
Medium
High
Design
Interface Stability (Architecture); Composition of Independent Functionality (Architeture)
Likely
High
High
Product Engineering Risk Code and Unit Test
Not identify
Unlikely
Medium
Medium
Integration and Test
Not identify
Unlikely
Medium
Medium
Engineering Specialities
Security (Architecture); Reliability Guarantee (Architecture)
Likely
Catastrophic
Very High
Near Certainty
High
Very High
Near Certainty
High
Very High
Highly Likely
High
Very High
Likely
Medium
High
Development Process Development System Development Management Process Environment Risk
No Standarized Process Model (Process) Development coordination and Management (Process)
Management Methods
Quality Assurance (Process); Evolution Management (Architecture)
Work Environment
Not identify
Unlikely
Very Little
Low
Resources Program Contract Constraints Risk Program Interfaces
Not identify
Unlikely
High
Medium
Highly Likely
Medium
Medium
Highly Likely
Medium
Very High
Development activities are highly dependent on 3rd party developer Table 3: Risk priority list.
No
Risk Elements
1 Engineering Specialities 2 Development Process 3 Development System
Description (Challe nge Area) - Security (Architecture); - Reliability Guarantee (Architecture) - No Standarized Process Model (Process)
Risk Exposure Very High Very High Very High
4 Management Process
- Development coordination and Management (Process)
Very High
5 Program Interfaces
- Development activities are highly dependent on 3rd party developer
Very High
6 Requirements
- Requirement Engineering (Process) - Interface Stability (Architecture); - Composition of Independent Functionality (Architeture) - Quality Assurance (Process); - Evolution Management (Architecture)
7 Design 8 Management Methods
High High High
9 Code and Unit Test
Not identify
Medium
10 Integration and Test
Not identify
Medium
11 Resources
Not identify
Medium
12 Contract
- Development activities are highly dependent on 3rd party developer
Medium
13 Work Environment
Not identify
422
Low
