Developing a large software system involves many complicated, varied, and inter-dependent tasks, and these tasks are typically implemented using a combination of defined processes, semi-automated tools, and ad hoc practices. Stakeholders in the development process --- including software developers, managers, and customers --- often want to be able to track the actual practices being employed within a project. For example, a customer may wish to be sure that the process is ISO 9000 compliant, a manager may wish to track the amount of testing that has been done in the current iteration, and a developer may wish to determine who has recently been working on a subsystem that has had several major bugs appear in it. However, extracting the software development processes from an existing project is expensive if one must rely upon manual inspection of artifacts and interviews of developers and their managers. Previously, researchers have suggested the live observation and instrumentation of a project to allow for more measurement, but this is costly, invasive, and also requires a live running project. In this work, we propose an approach that we call software process recovery that is based on after-the-fact analysis of various kinds of software development artifacts. We use a variety of supervised and unsupervised techniques from machine learning, topic analysis, natural language processing, and statistics on software repositories such as version control systems, bug trackers, and mailing list archives. We show how we can combine all of these methods to recover process signals that we map back to software development processes such as the Unified Process. The Unified Process has been visualized using a time-line view that shows effort per parallel discipline occurring across time. This visualization is called the Unified Process diagram. We use this diagram as inspiration to produce Recovered Unified Process Views (RUPV) that are a concrete version of this theoretical Unified Process diagram. We then validate these methods using case studies of multiple open source software systems.

Developing a large software system involves many complicated, varied, and inter-dependent tasks, and these tasks are typically implemented using a combination of defined processes, semi-automated tools, and ad hoc practices. Stakeholders in the development process --- including software developers, managers, and customers --- often want to be able to track the actual practices being employed within a project. For example, a customer may wish to be sure that the process is ISO 9000 compliant, a manager may wish to track the amount of testing that has been done in the current iteration, and a developer may wish to determine who has recently been working on a subsystem that has had several major bugs appear in it. However, extracting the software development processes from an existing project is expensive if one must rely upon manual inspection of artifacts and interviews of developers and their managers. Previously, researchers have suggested the live observation and instrumentation of a project to allow for more measurement, but this is costly, invasive, and also requires a live running project. In this work, we propose an approach that we call software process recovery that is based on after-the-fact analysis of various kinds of software development artifacts. We use a variety of supervised and unsupervised techniques from machine learning, topic analysis, natural language processing, and statistics on software repositories such as version control systems, bug trackers, and mailing list archives. We show how we can combine all of these methods to recover process signals that we map back to software development processes such as the Unified Process. The Unified Process has been visualized using a time-line view that shows effort per parallel discipline occurring across time. This visualization is called the Unified Process diagram. We use this diagram as inspiration to produce Recovered Unified Process Views (RUPV) that are a concrete version of this theoretical Unified Process diagram. We then validate these methods using case studies of multiple open source software systems.

The study of the software development process is a relatively new research area but it is growing rapidly. This development process, also called 'the software life cycle' or 'the software process', is the methodology used throughout the industry for the planning, design, implementation, testing and maintenance that takes place during the creation of a software product. Over the years a variety of different process models have been developed. From the numerous process models now available, project managers need validation of the choice he/she has made for a software development model that he/she believes will provide the best results. Yet the quality software so sought after by software project managers can be enhanced by improving the development process through which it is delivered. Well tested, reliable evidence is needed to assist these project managers in choosing and planning a superior software process as well as for improving the adopted software process. While some guidelines for software process validation and improvement have been provided, such as CMMI, quantitative evidence is, in fact, scarce. The quantitative evidence sometimes may not be able to be obtained from high level processes that refer to a planned process model, such as a waterfall model. Furthermore, there has been little analysis of low level processes. These low level processes refer to the actions of how a development team follow a high level software process model to develop a software product. We describe these low level processes as project enactment. Normally there is a gap between the high level software process and the project enactment. In order to improve this software development process, this gap needs to be identified, measured and analyzed. In this dissertation, we propose an approach that examines the deviation between a planned process model and the project enactment of that plan. We measure the discrepancy from two aspects: consistency and inconsistency. The analytical results of the proposed approach, which include both qualitative and quantitative data, provide powerful and precise evidence for tailoring, planning and selecting any software process model. The entire approach is composed of four major phases: 1) re-presentation of the planned process model, 2) pre-processing the low level process data, 3) process mining, and 4) analysis and comparison of the recovered process model and planned process model. We evaluate the proposed approach in three case studies: a small, a medium, and a large-sized project obtained from an industrial software development organization. The appropriate data on low level processes is collected and our approach is then applied to these projects individually. From each case study we then performed a detailed analysis of the inconsistencies that had surfaced as well as the consistencies between the plan and the enactment models. An analysis of the inconsistencies revealed that several 'agile' practices were introduced during the project's development even though the planned process model was initially based on 'ISO-12207' instead of the 'agile' method. In addition, our analysis identifies the patterns in the process that are frequently repeated. The outcome of the case studies shows that our approach is applicable to a range of software projects. The conclusions derived from these case studies confirmed that our approach could be used to enhance the entire software development process, including tailoring and assessment.