Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Hybrid software processes are defined as a combination of practices from traditional and agile methodologies. Most software development companies currently apply this kind of process; however, the appropriate combination of practices is not often clear. To address this issue, we have proposed DynaTail in a previous study, i.e., a method for tailoring a software process and its practices to a particular context to improve a certain characteristic. In this work, we use an MDE approach to formalize all the artifacts involved in DynaTail: processes, context, practices influencing goals, and tailoring transformations. This model-based formalization lays the base for building supporting tools. We illustrate all models with a running example from a Chilean medium-size software development company.

Background: Implementing agile practices in software development processes promises to bring improvements in product quality and process productivity, but there are few reports of cases of failure to learn from. And more specifically, it is not always clear which practices work well in which contexts.

Software process definition and improvement are frequent strategies followed by software companies in order to enhance software quality and boost development productivity. Software processes are used for guiding development teams while executing projects, and also as a basis for project planning and monitoring. There are some tools available for software process definition and a plethora of tools for project management with support for project planning and monitoring. These tools are usually not integrated so project plans are made manually possibly introducing inconsistencies with respect to the process they are based on. Moreover, when project management is not performed using an integrated tool, plan and trace also differ. Measuring process execution is a common path for SPI. To this end, matching tasks in the process, plan and trace is needed to understand where the process fails and how it might be improved. Inconsistencies among these artifacts hinders SPI since manually matching tasks demands a large effort. In this paper we define an approach for process-based project management that reduces these inconsistencies. We present CASPLE, a tool that supports this approach, and we illustrate its application in PowerData, a small Chilean company. A case study of applying the approach and CASPLE in four of our industrial partners is also presented.

Although most computer science graduates develop their professional careers as software engineers, there are no academic program with a specific focus on software engineering in Chile. Considering ACM/IEEE Software Engineering 2014 Curriculum Guidelines as a starting point, we analyzed the curricula of the CS Engineering and CS Technology programs offered by the most traditional Chilean universities, in order to establish to what extent they address the knowledge areas included in that recommendation. We also gathered information about theoretical and/or practical approaches of their courses, their types of evaluations and temporality. The results of this status report indicate that most knowledge areas of the ACM/IEEE curricula are covered but not all with the same emphasis. Programs count on three or four mandatory software engineering courses, most of them have a practical approach, are evaluated through exams and projects and start between the seventh and eight semesters. These results let us learn that some knowledge areas are not emphasized as they deserve. For example, Software Quality or Software Process are skills that industry often requires but academia does not seem to take into account. Similarly, it might be necessary to have students learn about software engineering earlier during their career. Knowing the actual status, actions can be taken.

Abstract A software company can define a software process line (SPrL) to deal with projects with different characteristics. This entails defining a base process and its variation points; the SPrL is then tailored to each project. This approach avoids the co‐evolution problems but is expensive to set up. In companies that register project events, this information could be used to discover the SPrL. However, traditional discovery algorithms focus on extracting a single process, which can be overly complex and would not be useful for managing future projects. Filtering out less frequent behavior leads to the discovery of simpler models, but these may not include relevant behavior. To address these issues, we propose the v‐algorithm, which discovers a SPrL from process logs. Two thresholds split the log into three clusters based on relation frequency. The first one is used to generate the base process, the second one is used to identify variable elements, and the last one is discarded. We used the v‐algorithm to discover the SPrL of Mobius, a small Chilean software company. We also discuss how the values of the thresholds affect the process discovery quality dimensions, extending existing metrics to the SPrL case. Copyright © 2016 John Wiley & Sons, Ltd.

Companies define software processes for planning and guiding projects. Since process definition is expensive, and in practice, no one process "fits all" projects, the current trend is to define a Software Process Line (SPrL): a base process that represents the common process elements, along with its potential variability. Specifying a SPrL is more expensive than just specifying one process, but the SPrL can be adapted to specific project contexts, minimizing the amount of extra work carried out by employees. Mining project logs has proven to be a promising approach for discovering the process that is applied in practice. However, considering all the possible variations that may be logged, the mined process may be overly complex. Some algorithms deal with this by filtering infrequent relations between log events, but they may discard relevant relations. In this paper we propose the v-algorithm that uses two thresholds to set up a SPrL: highly frequent relations are used to build the base process, variable relations define process variability, and rare relations are discarded as noise. We applied the $v$-$algorithm$ to the project log of Mobius, a small Chilean software company. We obtained a SPrL where we identified unexpected alternative ways of performing certain activities, as well as an optional activity that was originally specified as mandatory.

Companies formalize software processes as a way of organizing development projects. Since there are differences in project contexts, a one-size-fits-all approach does not work well in practice. Some companies use a family of a predefined processes, but this approach has a high process maintenance cost. Instead, we define Software Process Lines (SPrL), where a general process with variability is tailored to project contexts. Model- Driven Engineering (MDE) provides a formal framework for defining the models and transformations required for automated SPrL tailoring. However, this approach requires the definition and co-evolution of various types of models and tool support beyond the skills of process engineers, making the industrial adoption challenging. This paper shares our experience using a megamodeling approach to the development of the back-end of our toolset. The megamodel provides a uniform mechanism for process definition, variability, tailoring and evolution, and we hide the MDE complexity through a user-friendly front-end. We report the application of our approach at Mobius, a small Chilean software enterprise.

Companies formalize their software processes as a way of organizing their development projects. As each project has its own requirements and objectives, a family of processes is required in practice, in order to ensure that each project is handled appropriately. This family may be a collection of predefined processes, but can also be automatically generated by tailoring a general process to a project’s context which requires formalization and tool support to be successful. Model-driven engineering provides a formal framework for defining the models and transformations required for automated process tailoring, but various types of models must be specified and evolved, limiting the industrial adoption of this approach. To address this problem, in this paper we propose a megamodel for automated process tailoring. Megamodeling provides an integrating framework for modeling in the large, including the definition and evolution of all models and transformations required for tailoring while hiding complexity. We report the application of our approach to the software development process of Rhiscom, a small Chilean company.

Tailoring is the mechanism of adapting a software process to the needs of a project. Model-Driven Engineering (MDE) provides a formal basis and tools infrastructure for automatic software process tailoring. However, the use of a MDE approach can become awkward for most process engineers, because it requires knowledge of MDE concepts and formalisms to implement the required models and tailoring transformations. Proposals trying to address this problem should balance the formality required by MDE and the usability needed by the users. This paper presents a model-based tool and its associated procedure that allow process engineers to automatically generate tailoring transformation rules using a graphical user-interface, obtaining the desired balance. The proposal is illustrated with a running example.

Applying architecture knowledge promotes quality, reduces risks, and is crucial to best meet stakeholders' expectations. Current architecture knowledge is vast and ever-growing, however, it is also heterogeneous, diverse, disperse, and expressed at different levels of abstraction and rigor. In practice, architecture design is bounded by the architect's skills, experience, and the subset of knowledge he masters, and it also requires a huge effort to adjust such knowledge to the development scenario. The resulting architecture is therefore not as good as it could be. Moreover, the architect's effort is not repeatable as it is implicitly embedded in the architecture descriptions. Although model-based approaches are being used to capture particular domains and methods, most approaches lack either generality or homogeneity, making it hard to integrate, adapt and apply such knowledge. In this work, we use megamodeling to provide an homogeneous means for capturing architecture knowledge, making it shareable and reusable. We formally define a mapping from key architecture concepts to modeling artifacts. Also, an architecture design scripting language is used to capture the fine-grained design actions, making architecture design repeatable.

ABSTRACT Defining and formalizing the software development process is a common means for improving it. Software process modeling is often a challenging and expensive endeavor, because a well specified process may still include inefficiencies that are hardly detected before enacting it. Thus, assessing process quality is a relevant concern to improve several aspects such as conceptual integrity, correctness, usability, maintainability, and performance, among others. This paper describesAvispa, a graphical tool that allows analyzing the quality of SPEM 2.0 software processes models.Avispaidentifies a series of error patterns and highlights them in different blueprints. A detailed description of the internals ofAvispais provided to show both its structure and its extensibility mechanisms. We also present an interactive mechanism to define new analysis scripts and to implement new patterns and blueprints. This paper illustrates the application ofAvispain an industrial case study where process engineers are assisted to analyze the quality of their process. Copyright © 2013 John Wiley & Sons, Ltd.

SUMMARY Defining organizational software processes is essential for enhancing maturity because they cannot be improved if they are not specified. However, software process definition is hard and still not good for assuring productivity because the best process depends on the project's particularities. The process engineer can define a specific process for each kind of project, but this is expensive, unrepeatable, and error prone. Moreover, it is difficult to foresee all project scenarios and therefore the appropriate processes. The most usual situation is to apply always the same software process, although it is known to be suboptimal. To deal with this challenge, we propose a model‐based approach to software process tailoring that automatically generates project‐specific processes on the basis of the organizational process and project contexts. We still require competent process engineers to define the company's process, but once done, our approach is systematic, repeatable, and easy to use. The proposal is applied for tailoring the requirements engineering process of a medium‐size Chilean company. Processes obtained matched those used in the company for planned project contexts, and they were also reasonable for nonexpected situations. The company's process and project engineers agreed that the approach was highly valuable. Copyright © 2013 John Wiley & Sons, Ltd.

Software product quality and project productivity require defining suitable software process models. The best process depends on the circumstances where it is applied. Typically, a process engineer tailors a specific process for each project or each project type from an organizational software process model. Frequently, tailoring is performed in an informal and reactive fashion, which is expensive, unrepeatable and error prone. Trying to deal with this challenge, we have built CASPER, a meta-process for defining adaptable software process models. This paper presents CASPER illustrating it using the ISPW-6 process. CASPER meta-process allows producing project specific processes in a planned way using four software process principles and a set of process practices that enable a feasible production strategy. According to its application to a canonical case, this paper concludes that CASPER enables a practical technique for tailoring a software process model.

Software process models are sophisticated and large specifications aimed at organizing and managing software development. Their formal specification demands an enormous effort, but once specified there are few approaches and even fewer tools that aid the process engineer to analyze the quality of the process. For the last five years we have aided software companies in specifying their software processes and we have found a series of error patterns that indicate the potential presence of misconceptions or misspecifications. This paper presents these patterns, characterizes the kinds of errors they potentially reveal, and details how errors could be localized within a software process model. To assist process engineers to analyze the quality of their processes, we provide Avispa, a tool that graphically renders different aspects of a process model and highlights potential errors as intuitive and comprehensible indicators. The approach and the supporting tool are illustrated by applying them for analyzing the software process models of three Chilean software companies.

Defining organizational processes is essential for enhancing maturity. However the best process depends on the particularities of each project. Typically a process engineer defines a specific process for each project in an ad-hoc fashion, which is expensive, unrepeatable and error prone. Trying to deal with this challenge we propose a model-based approach to software process tailoring that generates project specific processes based on the organizational process and the project context. The approach is systematic, repeatable and it does not depend on the people using it. The proposal has been applied for tailoring the Requirements Engineering process of a medium size company. The obtained results were validated by process engineers of the company. Processes obtained using the proposed approach matched the ones used in the company for planned contexts and also they were reasonable for non-expected situations.

Automated consistency checking of UML models becomes necessary as models grow in size and complexity. Since the UML metamodel does not enforce model consistency, there are no fixed guidelines on how to approach the consistency problem. Current solutions are generally partial. The translation of the metamodel and the user designed model into Description Logics has proved to provide a solution in detecting a large set of inconsistencies. In order to make this solution available to system designers, we have implemented MCC+, a UML model consistency checker, built as a plug-in for Poseidon for UML, and relying on Jena as a reasoning engine. Compared to other approaches, we propose a usable and scalable solution, interoperable with a known modeling tool. We show the application of MCC+ to a real world large example of a meshing tool.

Automated consistency checking of UML models becomes necessary as models grow in size and complexity. Because the UML metamodel does not enforce model consistency, there are no guidelines as how to approach the consistency problem. Current solutions are partial and tools are mostly of academic nature. The translation of the metamodel and the user designed model into Description Logics has proved to be useful in detecting a large set of inconsistencies. We present MCC, a UML model consistency checker, built as a plug-in for Poseidon for UML, and relying on Racer as a reasoning engine. We propose a usable and scalable solution, interoperable with a known modeling tool.