Catálogo de publicaciones - libros

All systems during their lifecycle, no matter how simple, will generate legal implications that need to be managed. The potential cost of an inadequate management of legal aspects can even imply the failure of the project. As a consequence, legal risk management should not only be a major activity of the development lifecycle, but it needs to be performed by qualified personnel following well-defined procedures and standards. However, current software process improvement models do not properly include processes for legal audits and more concretely legal risks management for each phase of the software development lifecycle. Neither in industry related to manage legal risks of software projects is possible to find well-defined and standardised projects. This lack of standardised process means that legal risks are handled reactively instead of proactively. This work presents a process for managing legal risks. It is organised by a series of activities to be performed at each stage of the software development lifecycle to eliminate or minimize the risk of project failures for legal reasons.

Software Process Improvement Programs provide many benefits to the companies investing in this type of activities.One of the main problems in relation with SPI Value Management consists of the difficulty to convince senior management to invest in this type of programs. This issue is solved by means of benchmarking with successful histories by means of case studies. The information of current of SPI case studies is very heterogeneous, making this task so difficult. This paper presents a technique to formalize the information enclosed in an SPI case study providing an easy access to the relevant information of a SPI case study. Moreover, the results, obtained from its application with pre-existing case studies are provided. This work has been partially supported by the Spanish National Project “Software Process Management Platform: modeling, reuse and measurement” (TIN2004-07083).

A central issue in knowledge management and software process improvement is to learn from experience. In software engineering, most experience is gathered in projects, which makes project experience a prime source for learning. Many companies conduct postmortem reviews, but we have found few companies that analyze the outcome of several reviews to facilitate learning on an organizational level. This paper reports an explorative study of what we can learn from analyzing postmortem review reports of twelve projects in a medium-size software company.

The lack of conceptualization and inclusion of human, social, and organizational dynamics in software process simulation models is a critical obstacle in (1) exploring the impact of socio-technical dimensions in software development and (2) measuring the performance of software processes. This paper presents a conceptual multi-resolution modeling and simulation framework that delineates various dimensions of organizational behavior as they relate to software development. The framework conceptualizes software development as a transformation system from the perspective of knowledge acquisition and cognitive systems engineering. Explicit distinctions between the strategy, operational, and technical views are clearly presented. Specifically, the paper formulates a preliminary conceptual model and elaborates on design space of the operational and technical views that focus on organizational, social, and human dynamics in process performance modeling and simulation.

Software complexity measures are essential aspects of software engineering. Relatively few studies have been conducted to compare the performance of different complexity metrics. This paper describes an experimental investigation, which compares the performance of three different software complexity metrics; McCabe’s cyclomatic complexity, Halstead’s complexity measures and Douce’s spatial complexity, by using data from an Open Source project Eclipse JDT. The results of this investigation indicate that in different situation these complexity metrics show different performance. However, Halstead’s effort measure and Douce’s spatial complexity are highly correlated, showing bigger correlation coefficient values. This leads us to suggest that because Halstead’s complexity measure is more mature and has better supporting tools, it may be a good idea to replace Douce’s spatial complexity metric with Halstead’s effort measure in practice.

Continuous improvement of software development capability is fundamental for organizations to thrive in competitive markets. Nevertheless, Software Process Improvement (SPI) initiatives have demonstrated limited results because SPI managers usually fail to cope with factors that have influence on the success of SPI. In this paper, we present the results of a multi-strategy approach aiming to identify critical success factors (CSF) that have influence on SPI. The study results were confirmed by the literature review. The CSF were identified through a combination of qualitative and quantitative analyses of the results of a survey we conducted with SPI practitioners involved in Brazilian software industry experiences. We also identified the relationships of major factors that emerged from the survey. We expect that the major CSF presented in this paper can be used by SPI managers in the definition of SPI strategies aiming to enhance SPI initiatives success.

Companies spend significant efforts on testing their products to achieve a sufficient quality level. This paper presents results from evaluating the quality impact of implementing a framework for component-level test automation and Test-Driven Development. The evaluation comprised six projects for two products at a software development department at Ericsson. The paper suggests how an existing measurement approach can be used for evaluating the quality impact of improvements in early phases, i.e. by classifying faults reported on released products after which phase they should have been caught in. Based on this measurement approach, the evaluation determined that the ratio of reported faults in the released products decreased significantly after implementing the framework. That is, the ratio of faults belonging to component-level testing decreased from between 60-70 percent to less than 20 percent in the two studied products.

Test-driven development (TDD) is entering the mainstream of software development. We examined the software development process for the purpose of evaluation of the TDD impact, with respect to software development productivity, in the context of a web based system development. The design of the study is based on Goal-Question-Metric approach, and may be easily replicated in different industrial contexts where the number of subjects involved in the study is limited. The study reveals that TDD may have positive impact on software development productivity. Moreover, TDD is characterized by the higher ratio of active development time (described as typing and producing code) in total development time than test-last development approach.

Improving software processes relies on the ability to analyze previous projects and derive which parts of the process that should be focused on for improvement. All software projects encounter software faults during development and have to put much effort into locating and fixing these. A lot of information is produced when handling faults, through fault reports. This paper reports a study of fault reports from industrial projects, where we seek a better understanding of faults that have been reported during development and how this may affect the quality of the system. We investigated the fault profiles of five business-critical industrial projects by data mining to explore if there were significant trends in the way faults appear in these systems. We wanted to see if any types of faults dominate, and whether some types of faults were reported as being more severe than others. Our findings show that one specific fault type is generally dominant across reports from all projects, and that some fault types are rated as more severe than others. From this we could propose that the organization studied should increase effort in the design phase in order to improve software quality.