اکتشاف رابطه بین بلوغ فرآیند توسعه نرم افزار و عملکرد پروژه

Software projects have a high rate of failure. Organizations have tried to reduce the rate through methodological approaches but with little perceived success. A model of software development maturity (the capability maturity model (CMM)) describes managerial processes that can be used to attack software development difficulties from the managerial control perspective at five maturity levels. Our study examined performance of projects in relation to the activities at these various levels of maturity. A survey of software engineers indicated that the activities associated with the managerial control of development related positively to project performance measures. However, not each level of maturity demonstrated observable benefits, indicating that greater caution is needed in the planning and implementation of the activities.

Software projects continue to grow more critical to the organizations that employ them. Still, software failures are frequent. According to Standish Group International [38], about 15% of all software development projects never deliver a final product. Software project problems cost US companies and government agencies an estimated US$ 145 billion annually. In large software development projects, more than 80% are excessively late and over budget [13] and [26]. One approach to combat the failure rate has been technical, with organizations introducing new design methods [4] and [25]. However, after significant resources are poured into software development methods, such as CASE and Rapid Application Development, projects are often still considered “run-aways” [2], [5], [28], [39] and [40]. The managerial side of the software development project, meanwhile, is often conducted without adequate planning, with poor understanding of the overall development process, and a lack of a well-established management framework [36] and [37]. A formal addition to management practice was developed in the 1990s to help organizations along an evolutionary path to a more disciplined development process. The Software Engineering Institute (SEI), for the US Department of Defense (DoD), recommended a number of key software process improvement (SPI) areas. Later, these activities were formed into an evaluative framework called the capability maturity model (CMM) [33] and [34]. This model requires a considerable amount of time and effort to implement and often needs a major shift in culture and attitude [7] and [19]. One study found that the median time for an organization to move up one level of the five-level CMM is between 21 and 37 months [16]. Over three-quarters of the organizations reported that implementing any key SPI activity took longer than expected. In fact, resources expended amount to billions of dollars every year in the US alone. In addition to these, an organization’s culture can be adversely impacted by adding to its rigid bureaucracy and reducing creativity and freedom on the part of the developers [21]. Thus, given the costs and potential disadvantages of implementing the CMM, benefits must be evident to justify its continued use. The CMM has already achieved wide interest and acceptance in the software industry. It has spread far beyond its origins and is now used by thousands of major organizations worldwide [12]. But is the CMM an appropriate model for guiding improvements in the software development process? Do the suggested SPI activities really apply to a variety of organizations? To our surprise, no empirical evidence examining the effects of the various suggested SPI activities on project performance can be found in the information system (IS) literature. Therefore, the focus of this study is on the relationship between SPI activities and software project performance. Specifically: 1. Is there a relationship between the implementation of the CMM’s SPI activities and an organization’s software project performance? 2. Are certain SPI activities more likely to influence the final project outcomes than other suggested SPI activities? 3. Which dimensions of project outcomes are more likely to be influenced by which SPI activities?

CMM was originally designed to help characterize the maturity of software practices, guide a program of continuous process and workforce development, set priorities for immediate actions, and establish a culture of software development process quality excellence. CMM assumes that the quality of a software project outcome depends on the extent of suggested activities actually implemented by an organization [18]. Today, the CMM has spread far beyond its original application area and is widely used by software organizations in the US and around the globe. Our study examined the relationship between CMM software process development activities and project performance. From the responses of 154 experienced software project developers, the analysis confirmed that software process management maturity is positively associated with project performance. This result is largely consistent with the many individual cases reported in [27]. To software managers, this result suggests that CMM, in general, could be a useful guide to improving their current state of software processes in order to improve project performance. Results indicate that project performance is most related to the process engineering and organizational support activities of the CMM (Level III) but that product and process quality activities (Level IV) also have a positive relationship with project performance. On the other hand, basic project management process activities (Level II) were not significant at all. Organizations therefore need to realize that benefits may not be reached until they achieve Level III. This requires a great amount of time and money before benefits can be realized. Also, strong relations to benefits seem to tail off after Level III. Not all organizations may wish to pursue the CMM under these conditions. Further relationships between the various specific project performance criteria and the SPI activities were explored. Process engineering and organizational support activities are positively associated with learning, control, interaction quality, and software flexibility. Interestingly, adherence to basic project management activities was negatively related to software flexibility. However, software flexibility can be improved with Levels III and IV activities. Furthermore, the quality of the interaction between users and IS staff was positively related to product and process quality related activities (Level IV) but not activities in other levels. These insights may prove crucial to organizations that seek to follow the CMM model for their software development process improvements. Identifying strengths and weakness in an organization’s current software development processes against a community standard is a necessary first step to build consensus around the fundamental software process development problems of their organization. Organizations then set priorities for their improvements so the resources can be effectively allocated to a few vital areas and activities. Planning sufficient attainment of the levels in CMM is important in realizing any benefits. An expectation that certain fundamentals must be in place to implement the higher level activities is important in planning for realization of the benefits. Furthermore, achieving higher levels of software development process maturity requires a long-term commitment to continuous process improvement. It may take organizations years to achieve the next level of maturity and to realize the benefits. The CMM focus is on “what” organizations should do and not “how” they should do it. Sometimes the practices follow strict organizational requirements, at other times it is left to individuals who exercise autonomy to determine what actions are required and how to execute these activities [29] and [30]. Some studies support the concept that technical project performance can be improved if team members engage in higher levels of self-control as opposed to rigid organizational control [3] and [41]. This is one example of how the CMM provides “what to do” but allows flexibility on the part of the team members in “how to” accomplish their tasks.