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.

Quality defects are a common problem for producing companies, but causes and consequences are often unknown. The purpose of this thesis assignment is to develop a step-by-step analysis method for identifying the root causes of quality defects based on previously examined consequences. The first steps focus on customer recovery meanwhile the following steps concentrate on process recovery. The analysis method is process-orientated as the complete production and delivery process are scrutinized upstream by the combination of commonly used quality tools.   For testing the applicability of the presented method this thesis comprises a case study conducted at one company receiving complaints about quality defects. For the Case Study Company the consequences and causes of quality defects are described, analyzed and suggestions for improvement are developed.   In the investigated case, the developed method helps to identify causes and consequences of incomplete delivery, the company’s major quality problem. The upstream approach proved advantages for two reasons. First of all including the customer side guarantees that the cause analysis is limited to the relevant problems. With the help of the method the severity of consequences depending on the customers’ awareness of defects and available time can be detected. Secondly problems can be scrutinized in natural order as difficulties in production once identified can be followed step by step to the causes in a preceding step. The main causes identified in this case study are a lack of process definition and of standardization. Thus, the portrayed case suggests that regular appearances of quality defects are not a coincidence. The reasons are the underlying, possibly insufficiently defined and managed processes.   The general finding of the thesis assignment is the presented analysis method that comprises a systematic process-oriented approach designed to examine consequences and causes of quality defects. In contrast to the root cause analysis approaches found in literature each analysis step is described in detail. This makes the method easy to apply in practice. Therefore the method is a valid tool to deal with a high degree of complexity. The case study proved that it is effective and efficient to scrutinize problems with these characteristics. Under different circumstances the application of single quality tools might be sufficient and hence resource effective. Further investigation is necessary since this method has only been tested in one case study.

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.

Submitted by Izabel Franco (izabel-franco@ufscar.br) on 2016-10-03T18:14:47Z No. of bitstreams: 1 DissLAPR.pdf: 4492395 bytes, checksum: 3cbeb71e7d3159ff9f8b260e4486c81d (MD5) / Approved for entry into archive by Marina Freitas (marinapf@ufscar.br) on 2016-10-20T19:18:44Z (GMT) No. of bitstreams: 1 DissLAPR.pdf: 4492395 bytes, checksum: 3cbeb71e7d3159ff9f8b260e4486c81d (MD5) / Approved for entry into archive by Marina Freitas (marinapf@ufscar.br) on 2016-10-20T19:18:51Z (GMT) No. of bitstreams: 1 DissLAPR.pdf: 4492395 bytes, checksum: 3cbeb71e7d3159ff9f8b260e4486c81d (MD5) / Made available in DSpace on 2016-10-20T19:18:57Z (GMT). No. of bitstreams: 1 DissLAPR.pdf: 4492395 bytes, checksum: 3cbeb71e7d3159ff9f8b260e4486c81d (MD5) Previous issue date: 2015-09-02 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) / Over time, Business Processes have become a key asset for organizations since it allows managing what happens within their environments. It is possible to automate some activities of business processes resorting to the use of Information Systems and accordingly decrease the execution time and increase the production. However, Information systems often suffer maintenance over time and become obsolete in their technologies and a reengineering process becomes necessary. In this case, the Business Knowledge, located more accurately the reality in information system source code, should be mantained. Thereof, in this work, we propose an Approach to support the Business Process Recovery from Source Code. The approach, entitled RPN, uses a static analysis technique of source code because it allows to analyze the source code without the need to modify and run the information system source code. Furthermore, the approach uses the Knowledge Discovery Metamodel (KDM) standard with a set of Heuristic rules to identify relevant code elements to the business layer. As result, Business Process Models are generated according to Business Process Model and Notation (BPMN) standard specification. This models, together with other software artifacts, provide more subsidies to the Software Reengineering process. To evaluate the proposed approach, a case study was performed in Academic Domain to measure the effectiveness of the approach compared to the other approaches and the manual process. The results exceeded expectations and prove that the approach is effective. / Ao longo do tempo, processos de negócio se tornaram um artefato chave para organizações, visto que esses processos permitem gerenciar o que acontece dentro de seus ambientes. É possível automatizar algumas atividades de processos de negócio recorrendo ao uso de sistemas de informação e, dessa forma, diminuir o tempo de execução dessas atividades e aumentar a produção. Entretanto, ao longo do tempo, sistemas de informação sofrem diversas manutenções e tornam-se obsoletos em suas tecnologias e um processo de reengenharia torna-se necessário. Nesse caso, o conhecimento do negócio, localizado mais precisamente à realidade no código fonte do sistema de informação, deve ser mantido. Por este motivo, este trabalho propõe uma abordagem para apoiar a recuperação de processos de negócio a partir do código fonte. A abordagem, nomeada RPN, recorre à técnica de análise estática do código fonte, uma vez que essa técnica permite analisar o código fonte de um sistema sem a necessidade de modificá-lo e executá-lo. Além disso, a abordagem utiliza o padrão Knowledge Discovery Metamodel (KDM) com um conjunto de regras de heurísticas para recuperar elementos de código relevantes à camada de negócio. Como resultado, são gerados modelos de processos de negócio de acordo com a especificação padrão Business Process Model and Notation (BPMN). Esses modelos, em conjunto com outros artefatos de software, fornecem maiores subsídios para o processo de reengenharia de software. Para avaliar a abordagem proposta, foi realizado um estudo de caso no domínio acadêmico para mensurar a eficácia da abordagem comparado às outras abordagens e ao processo manual. Os resultados obtidos foram satisfatórios e a abordagem RPN mostrou-se muito eficaz e eficiente para executar seu propósito.