Software Process Validation: Quantitatively Measuring the Correspondence of a Process to a Model ; CU-CS-840-97

this article

Discovering Models of Software Processes from Event-Based Data ; CU-CS-819-96

Many software process methods and tools presuppose the existence of a formal model of a process. Unfortunately, developing a formal model for an on-going, complex process can be dicult, costly, and error prone. This presents a practical barrier to the adoption of process technologies, which would be lowered by automated assistance in creating formal models. To this end, we have developed a data analysis technique that we term process discovery. Under this technique, data describing process events are rst captured from an on-going process and then used to generate a formal model of the behavior of that process. In this paper we describe a Markov method that we developed specically for process discovery, as well as describe two additional methods that we adopted from other domains and augmented for our purposes. The three methods range from the purely algorithmic to the purely statistical. We compare the methods and discuss their application in an industrial case study

Evaluating Process Quality Based on Change Request Data – An Empirical Study of the Eclipse Project

Abstract. The information routinely collected in change request management systems contains valuable information for monitoring of the process quality. However this data is currently utilized in a very limited way. This paper presents an empirical study of the process quality in the product portfolio of the Eclipse project. It is based on a systematic approach for the evaluation of process quality characteristics using change request data. Results of the study offer insights into the development process of Eclipse. Moreover the study allows assessing applicability and limitations of the proposed approach for the evaluation of process quality

VALUE ESTIMATION OF SOFTWARE FUNCTIONAL TEST CASES

VALUE ESTIMATION OF SOFTWARE FUNCTIONAL TEST CASE

AN EMERGING THEORY ON THE INTERACTION BETWEEN REQUIREMENTS ENGINEERING AND SYSTEMS ARCHITECTING BASED ON A SUITE OF EXPLORATORY EMPIRICAL STUDIES

Requirements Engineering and Systems Architecting are often considered the most important phases of the software development lifecycle. Because of their close proximity in the software development lifecycle, there is a high degree of interaction between these two processes. While such interaction has been recognized and researched in terms of new technology (particularly methods and tools), there is a distinct lack of empirical understanding regarding the scientific properties of this interaction. Furthermore, in Requirements Engineering and Systems Architecting, not only technical but human aspects are considered critical for the success of these processes due to these processes lying at the front-end of the development cycle and therefore being more aligned with real-world issues. Thus, the scientific properties of the interactions between Requirements Engineering and Systems Architecting can be broken down into these two key aspects. For instance, the following example research questions relate to such scientific properties: What is the impact of an existing system’s architecture on requirements decision-making? What kinds of requirements-oriented problems are encountered during architecting? What is the impact of an existing systems architecture on new requirements being elicited? What is the impact of requirements engineering knowledge on systems architecting? There is little in the literature addressing such questions. This thesis explores such issues through a suite of six exploratory empirical studies that were conducted over the last five years. Based on the observations from these studies, an emerging theory is proposed that describes the impact of human and process factors in the interaction between Requirements Engineering and Systems Architecting. The impact of this emerging body of knowledge is deemed to be on the following: technology development for Requirements Engineering and Software Architecting (methods, tools, processes, etc.); hiring and training personnel for Requirements Engineering and Systems Architecture processes in industry; Requirements Engineering and Systems Architecture project planning; curriculum improvement in academia; and future empirical research in Requirements Engineering and Systems Architecting

An Empirical investigation of software project schedule behavior.

Two intensive, longitudinal case studies were conducted at IBM Hursley Park. There were several objectives to these case studies: first, to investigate the actual behaviour of the two projects in depth; second, to develop conceptual structures relating the lower-level processes of each project to the higher-level processes; third, to relate the lower-level and higher-level processes to project duration; fourth, to test a conjecture forwarded by Bradac et al i. e. that waiting is more prevalent during the end of a project than during the middle of a project. A large volume of qualitative and quantitative evidence was collected and analysed for each project. This evidence included minutes of status meetings, interviews, project schedules, and information from feedback workshops (which were conducted several months after the completion of the projects). The analysis generated three models and numerous insights into software project behaviour. The models concerned software project schedule behaviour, capability and an integration of schedule behaviour and capability. The insights concerned characteristics of a project (i. e. the actual progress of phases and milestones, the amount of workload on the project, the degree of capability of the project, tactics of management, and the sociotechnical aspects of a project) and characteristics of process areas within a project (i. e. waiting, poor progress and outstanding work). Support for the models and the insights was sought, with some success, from previous research. Despite the approach taken in this investigation (i. e. the collection of a large volume of evidence and the analyses of a wide variety of factors using a very broad perspective), this investigation has been unable to pinpoint definite causes to explain why a project will or will not complete according to its original plan. One `hint' of an explanation are the differences between the socio-technical contexts of the two projects and, related to this, the fact that tactics of management may be constrained by a project's socio-technical context. Furthermore, while the concept of a project as a distinct entity seems reasonable, the actual boundaries of a project in an organisation's `space-time' are ambiguous and very difficult to properly define. Therefore, it may be that those things that make a project difficult to distinguish from its surrounding organisation are interwoven with the socio-technical contexts of a project, and may be precisely those things that explain the progress of that project. Recommendations, based on the models, the insights and the conclusions, are provided for industry and research

On the Socio-Technical Dependencies in Free/Libre/Open Source Software Projects

During the course of the past two decades, Open Source Software (OSS) development model has lead to a number of projects which have produced software that rivals and in some cases even exceeds the scale and quality of the traditional software projects. Among others, Eclipse, Apache, Linux, and BSD operating system are representative examples of such success stories.However, OSS project like traditional in-house projects, often pose the potential for enormous problems, whose effects run the gamut from immense cumulative delay through complete breakdown and failure. This situation is evident, as OSS development is a socio-technical endeavor and is non-trivial. Such development occurs within an intensively collaborative process, in which technical prowess must go hand in hand with the efficient coordination and management of a large number of social, inter-personal interactions across the development organization. Furthermore, those social and technical dimensions are not orthogonal. It has been recognized that the structure of a software product and the layout of the development organization working on that product correlate.Therefore this thesis argue that a comprehensive understanding on the sustainable evolution of OSS projects can be gained through the examination of the mutual influence of social and technical dimensions in OSS development. Thus, the goal of this thesis is the verification and reasoning of the following proposition,“The evolution of the Open Source Software (OSS) project is constrained by the non-orthogonal evolution of Social and Technical dimensions (often termed as Socio-Technical dependency) of such projects”.In concrete terms, this thesis investigates and measures empirically the extent to which the two dimensions of OSS projects, social and technical, approximate and influence each other during the evolution of the projects. Perceived insight is then used to build proposals that would provide empirical basis to frame theory around the affirmed proposition.Moving towards this goal, this thesis proposes models, methods, frameworks and tool supports to measure, assess, and reason the socio-technical dependency within OSS project context. The starting point is to propose a data model to mimic the social and technical dimensions and their inter-relationships. This model is instantiated through the repository data of OSS projects that represent each of these dimensions. Then, methods and a mathematical model are proposed to derive dependency between the two dimensions, and to utilize them in measuring socio-technical dependency quantitatively. These proposals are then put into practice within distinct OSS project contexts to empirically measure and investigate socio-technical dependency. Along the process, frameworks, architectural design and corresponding tool implementations are provided to automate the analysis and visualization of such dependency.Reported results suggest that high degree of socio-technical congruence can be considered as the implicit underlying principle for building team collaboration and coordination within the developer community of long lived OSS projects. Even being highly distributed community of developers, and mostly using passive communication channels, OSS communities are tied together by maintaining task dependent communication. Such communication is often ad-hoc, adaptive and situated as it cope with rapid and continuous changes in the underlying software.Additionally, collaboration among projects are significantly influenced by the resembling properties among the projects. Resembling properties (e.g., project domain, size, and programming language) often form a favorable ground, thus creating a stimuli for developers to participate in those projects