Optimising processes of IT organisation through software products’ configuration management

The present paper is focused on the efficiency of processes within IT firms which design software products, by finding optimum management solutions for these types of activities. In order to achieve this, we focus on software products configuration management, with specific objectives in documenting and ensuring visibility to the product’s configuration and of the stage of achieving its physical and functional characteristics. Through configuration management, technical and administrative rules are established and applied for designing, developing, producing and supporting the elements of the product’s configuration, in each stage of its lifecycle. The conclusions of this research are focused on evaluating economic effects obtained by implementing the quality management system, according to the ISO 9001:2000 quality standard, while developing software products, at the level of IT firm.configuration management, quality management, product lifecycle, software quality

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle

Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner. This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006--2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction. This paper documents the above study and explores reasons for this mismatch between this common rule of thumb and empirical data. In summary, DIE is not some constant across all projects. Rather, DIE might be an historical relic that occurs intermittently only in certain kinds of projects. This is a significant result since it predicts that new development processes that promise to faster retire more issues will not have a guaranteed return on investment (depending on the context where applied), and that a long-held truth in software engineering should not be considered a global truism.Comment: 31 pages. Accepted with minor revisions to Journal of Empirical Software Engineering. Keywords: software economics, phase delay, cost to fi

Detecting Functional Requirements Inconsistencies within Multi-teams Projects Framed into a Model-based Web Methodology

One of the most essential processes within the software project life cycle is the REP (Requirements Engineering Process) because it allows specifying the software product requirements. This specification should be as consistent as possible because it allows estimating in a suitable manner the effort required to obtain the final product. REP is complex in itself, but this complexity is greatly increased in big, distributed and heterogeneous projects with multiple analyst teams and high integration between functional modules. This paper presents an approach for the systematic conciliation of functional requirements in big projects dealing with a web model-based approach and how this approach may be implemented in the context of the NDT (Navigational Development Techniques): a web methodology. This paper also describes the empirical evaluation in the CALIPSOneo project by analyzing the improvements obtained with our approach.Ministerio de Economía y Competitividad TIN2013-46928-C3-3-RMinisterio de Economía y Competitividad TIN2015-71938-RED

Can using Fagan Inspections improve the quality of specification in 2011? A Case Study

In this paper, we explore why Fagan Inspections have become obsolete in the software industry, given the body of evidence which supports their use to improve the quality of software artefacts and the software development process. Since the late 1970’s, much has been written about how Fagan Inspections improve the quality of both processes and outputs of the software development process. The literature indicates that the Fagan Inspection technique can improve quality of software (or other software development artefacts) by a reduction in defects of 60 – 90%. However, recent literature suggests that inspection techniques in general and Fagan Inspections in particular, are no longer used. A study in 1998 found that respondents used inspections either irregularly or not at all. Teams often review artefacts informally, but believe that they are performing an inspection or formal review. The lack of rigour in the review process results in reduced benefits and more defects in the artefacts. To explore this situation, we conducted a case study with a local enterprise and we report on the early findings. These suggest that the introduction of Fagan Inspections may have a number of benefits before they have even been introduced fully, including recognition of flaws in the current development process, development of technical knowledge relating to the software process domain, and improved team relations and a ‘quality’ culture. In addition, the personnel using Fagan Inspection gain experience in the production of ‘quality’ artefacts

Software Engineering Timeline: major areas of interest and multidisciplinary trends

Ingeniería del software. EvolucionSociety today cannot run without software and by extension, without Software Engineering. Since this discipline emerged in 1968, practitioners have learned valuable lessons that have contributed to current practices. Some have become outdated but many are still relevant and widely used. From the personal and incomplete perspective of the authors, this paper not only reviews the major milestones and areas of interest in the Software Engineering timeline helping software engineers to appreciate the state of things, but also tries to give some insights into the trends that this complex engineering will see in the near future

Measuring the Impact of Quality Improvement in a Software Company

The quality issue is not only a matter of developing and implementing a quality system. It mandatory this system to function precisely on a long term basis. The evaluation of quality impact as a consequence of its improvement is a scary thing the quality specialists prefer to be apart due to its complexity. That’s the reason why the article emphasize on: the need and justification of quality impact evaluation, particularities of quality in software domain generated by its specificity, what evaluation of economic effects means in the context of a quality improvement particularly in a software company, a proposed method to calculate the impact of quality (on the costs structure), a practical example of how the method should be used and the results interpreted based on two simulated case.quality improvement; quality management; software industry; quality impact evaluation; measure quality.

Industry-driven innovative system development for the construction industry: The DIVERCITY project

Collaborative working has become possible using the innovative integrated systems in construction as many activities are performed globally with stakeholders situated in various locations. The Integrated VR based information systems can bind the fragmentation and provide communication and collaboration between the distributed stakeholders n various locations. The development of these technologies is vital for the uptake of these systems by the construction industry. This paper starts by emphasising the importance of construction IT research and reviews some future research directions in this area. In particular, the paper explores how virtual prototyping can improve the productivity and effectiveness of construction projects, and presents DIVERCITY, which is th as a case study of the research in virtual prototyping. Besides, the paper explores the requirements engineering of the DIVERCITY project. DIVERCITY has large and evolving requirements, which considered the perspectives of multiple stakeholders, such as clients, architects and contractors. However, practitioners are often unsure of the detail of how virtual environments would support the construction process, and how to overcome some barriers to the introduction of new technologies. This complicates the requirements engineering process