The phase of pre-contract of software projects is highly relevant for providers and acquirers.This time consuming phase should be done in a cost-effective way, since the possibility of finishing in a software contract is uncertain.The literature reports some macro-activities to guide this process.However, they are coarse grained, and therefore, difficult to follow in practice by practitioners.Moreover, it is not clear how the industry deals with the pre-contract process; particularly, when addressing the preselling of small software projects.This article presents an exploratory study that involves 14 Chilean software companies, in which we performed qualitative research to understand how they conduct the pre-contract process of small projects.The results were arranged in a model, named the Pre-Contract Process (PCP) model, which identifies the most prevalent actors, activities, outcomes, and a workflow according to the best practices used by these companies.These results extend those reported in the literature; particularly, the PCP model contributes with more in depth information about how to conduct the macro-activities in practices.Although this process is still preliminary, it can be used to inform the design of pre-contract activities in software companies and educational institutions.Future software engineers and practitioners can take advantage of it to address their own project pre-contract processes.

At project pre-selling time, customers and software providers collaborate to define the product required by the former; and based on it, the latter can generate a project proposal and a bid. This collaborative activity, that we have named product scoping, is not properly supported by the current tools and techniques, mainly due to the constraints imposed by the preselling phase; e.g., the activity has to be done quickly, accurately, and involving few resources. This article presents an instrument that supports the product scoping in bespoke projects, dealing with the main constraints involved in the pre-selling phase. The instrument is a canvas, and its design was particularly conceived to support the product scoping of data processing projects; however, the canvas can be adapted to address other project types. The instrument has been evaluated with real customers and providers, and the obtained results show that it helps conduct the product scoping process in a cost-effective way.

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.

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.

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.