Productivity in software factories is very important because it allows organizations to achieve greater efficiency and effectiveness in their activities. One of the pillars of competitiveness is productivity, and it is related to the effort required to accomplish the assigned tasks. However, there is no standard way to measure it, making it difficult to establish policies and strategies to improve the factory. In this work, a model based on data envelopment analysis is presented to evaluate the relative efficiency of the software factories and their projects, to measure the productivity in the software production component of the software factory through the activities that are carried out in their different work units. The proposed model consists of two phases in which the productivity of the software factory is evaluated and the productivity of the projects it conducts is assessed. Numerical tests on 6 software factories with 160 projects implemented show that the proposed model allows one to assess the software factories and the most efficient projects.
TopIntroduction
Software factories offer great advantages, such as the ability to decrease production costs per product by up to 60%; time savings of up to 98% for putting a product on the market; labor requirements reduced by up to 60%; a tenfold improvement in productivity; and better quality of each product with 10 times fewer errors. These advantages increase the company’s portfolio of products and services as well as its chances of winning new markets (Clements & Northrop, 2001).
The importance of measuring productivity in a software factory is very important because of the close relationship between production-unit operations and profitability. In addition, once the company has quantified productivity, it has a solid foundation for strategic planning. Tracking historical productivity can reveal problem areas in the production units and promote improvements and efficient use of available resources. In turn, this outcome supports establishing specific dimensions for comparing the unit with its counterparts, since increased efficiency enables increased competitiveness (Castañeda & Mauricio, in press). Although a software factory’s functional components are typically organized around Project Management and Software Production and Support, and each component is composed of work units (as shown in Figure 1), 90% of the factory’s effort occurs in the Software Production component, and Analysis & Design, Programming, and Testing consume 85% of this component’s efforts (Jacobson, Booch, & Rumbaugh, 2000; Castañeda & Mauricio, in press).
Figure 1. Structure of software factories (Castañeda & Mauricio, 2018)
The software industry1 is enthusiastically adopting the concept of a software factory2, and one reason is the indicators that enable measuring its productivity and comparing them in the market. Measurement helps the business to consider actions that increase overall efficiency, using all resources effectively and efficiently to obtain the best possible results. The company must know how the organization is performing in relation to both its own previous periods and its competitors. This raises several questions, such as whether performance (i.e., productivity) of the factory is increasing, decreasing, advancing, or receding; the magnitude of this progress or setback; and the effectiveness of implemented strategies. However, measuring productivity is a complex activity because there is no consensus on what to measure (Scacchi, 1995; Asmild, Paradi, & Kulkarni, 2006, Moreira, Carneiro, Pires, & Bessa, 2010; Yilmaz & O’Connor, 2011; Cheikhi, Al-Qutaish, & Idri, 2012; Machek, Hnilica, & Hejda, 2012; Khan, Ahmed, & Faisal, 2014). Various publications on software productivity reviewed in recent years show that literature about measuring productivity in software factories is very scarce (Castañeda & Mauricio, 2018). Models for measuring productivity (Asmild et al., 2006; Nwelih & Amadin, 2008; Moreira et al., 2010; Yilmaz & O’Connor, 2011; Cheikhi et al., 2012; Machek et al., 2012) have considered only the unit of programming work, leading to a bias in measurement and the lack of measurement indicators that facilitate decision making in the organization.