In the multimodel improvement context, Software Organizations need to incorporate into their processes different practices from several improvement technologies simultaneously (i.e. CMMI, PSP, ISO 15504, and others). Over the last few years, software process architectures have been considered a means to harmonize these technologies. However, it is unclear how to design a software process architecture supporting a multimodel environment. In this chapter, an overview of the method to design a software process architecture is presented, identifying basic concepts, views, phases, activities, and artifacts. In addition, important aspects in the creation of this method are explained. This method will assist process stakeholders in the design, documentation, and maintenance of their software process architecture.
Top1. Introduction
Multimodel Software Process Improvement (MSPI) aims to achieve business goals, develop quality products through a mature process applying multiple improvement technologies best practices simultaneously, and reduce time-to-market and production costs (Siviy, Penn, & Stoddard, 2008; Unterkalmsteiner, Gorschek, Islam, Cheng, Permadi, & Feldt, 2012). Therefore, software organizations are analyzing their processes, selecting appropriate improvement technologies and adopting best practices from each technology.
Problems have arisen within organizations working under this multimodel environment (Kelemen, Kusters, & Trienekens, 2011), where multiple technologies, which may be used in different ways, address the same need with significant overlap. Therefore, the decision to simultaneously adopt multiple technologies can be complex and can depend as much on how they will be implemented as on their specific features and benefits.
The need to harmonize technologies emerges as a solution toward working simultaneously with multiple improvement technologies (Kirwan, Marino, Morley, & Siviy, 2008a; Lawrence, 2009; Pardo, 2010). Currently, there are many harmonization approaches (Calvache, Pino, García, & Piattini, 2009; Kirwan et al., 2008a), methods and techniques (Halvorsen & Conradi, 2001; Mutafelija & Stromberg, 2003; Wang & King, 2000). Some techniques, such as mapping and comparison, are widely used but many other techniques have not yet been clearly defined, making harmonization of multiple technologies a difficult endeavor for organizations.
Software Process Architectures have been recognized as a means to harmonize multiple technologies within an organization that develops software products (Kirwan et al., 2008a; Kirwan, Marino, Morley, & Siviy, 2008b). Software process architecture in a multimodel environment is defined as “a set of process elements and its relationships that support adding, removing or modifying any improvement technology and allowing it to be derived from standard processes” (Pesantes, Lemus, Mitre, & Mejia, 2012a).
Several methods have been published to address the problem of how to design a process architecture (Borsoi & Becerra, 2008; Dai, Li, Zhao, Yu, & Huang, 2008; Green & Ould, 1996; Maldonado & Velázquez, 2006). However, it is unclear how to design a software process architecture that supports a multimodel software process improvement environment.
This research presents a method to design a software process architecture that supports a multimodel environment. This method considers creating a software process architecture that will receive as input a set of harmonized heterogeneous technologies and obtain as output a set of standard processes. It is based on a statistical thinking approach, analysis method and internal structured analysis technique.
Accordingly, the contents herein are structured as follows: section 2 presents a background of available efforts regarding methods to design a process architecture. Section 3 presents important aspects considered to create the method. Section 4 describes the basic concepts of the method. Section 5 shows the basic constructors of a software process architecture. Section 6 gives a general description of the method. Section 7 describes the method’s phases, with their respective activities and artifacts. The last section summarizes conclusions and future works of this research.