The process of E-type software development and evolution has proven most difficult to improve, possibly due to the fact that the process is a multi-input, multi-output system involving feedback at many levels. This observation, first recorded in the early 70s during an extended study of OS/360 evolution, was recently captured in a FEAST hypothesis; a hypothesis being studied in on-going twoyear project, FEAST/1. Preliminary conclusions based on a study of a financial transaction system, FW, are outlined and compared with those reached during the earlier OS/360 study. The new analysis supports, or better does not contradict, the laws of software evolution, suggesting that the 1970s approach to metric analysis of software evolution is still relevant today. It is hoped that FEAST/1 will provide a foundation for mastering the feedback aspects of the software evolution process, opening up new paths for process modelling and improvement.

There aren't any silver bullets in software development, and there probably never will be. However, Extreme Programming is a simple set of common-sense practices that, when used together, really can give you much of what you just read in the paragraph above. In this book, we tell you what the XP practices are, and how to install them in your project.

Abstract not found

For more information, please visit our website at

The Internet has had a significant impact on the process of developing information systems. However, there has been little research that has examined specifically the role of development methodologies in this new era. Although there are many new forces driving systems development many other issues are extensions of problems that have been there for some years. This paper identifies the main requirements of methodologies for developing Web applications. To achieve this objective a methodology is proposed which attempts to address a number of issues identified within the literature. The Internet Commerce Development Methodology (ICDM) considers evolutionary development of systems, provides a business and strategic focus and includes a management structure in addition to covering the engineering aspects of Web application development. The methodology is compared with several other Web development methodologies. ICDM differs in that it provides a framework for developing an e-business strategy, incorporates a management structure, procedures for customer involvement and provides guidelines on developing a conducive organisational culture. Evaluation of the method highlighted that practitioners would ideally like methodologies to be relevant to their industry and provide detailed guidelines on changing organisational culture. 1.

The need of developing a new software engineering process (SEP) that could allow the quick prototyping of some robotic applications and meet the requests coming from some companies for a development process that was shorter than PASSI, gave us the opportunity of applying our studies on the assembling of a new SEP by reusing parts (called method fragments) from other processes. In this paper we discuss our approach that, starting from the method engineering paradigm, adapts and extends it considering specific agent-oriented issues like the multi-agent system metamodel. The final result of our experiment (Agile PASSI) is presented together with the requirements that motivated its structure.

: Software inspections are widely regarded as a cost-effective mechanism for removing defects in software, though performing them does not always reduce the number of customer-discovered defects. We present a case study in which an attempt was made to reduce such defects through inspection training that introduced program comprehension ideas. The training was designed to address the problem of understanding the artifact being reviewed, as well as other perceived deficiencies of the inspection process itself. Measures, both formal and informal, suggest that explicit training in program understanding may improve inspection effectiveness. The software technical review is a widely-recommended mechanism for software defect removal. Such reviews go by many names---inspections, Fagan-style inspections, code reviews, peer reviews, formal reviews---and exhibit significant variations among organizations [Fagan, Freedman, Gilb]. All such review methods rely on the self-evident notion that softwar...

A dynamic simulation model of an inspection-based software lifecycle process has been developed to support quantitative process evaluation. The model serves to examine the effects of inspection practices on cost, schedule and quality throughout the lifecycle. It uses system dynamics to model the interrelated flows of tasks, errors and personnel throughout different development phases and is calibrated to industrial data. It extends previous software project dynamics research by examining an inspection-based process with an original model, integrating it with the knowledge-based method for risk assessment and cost estimation, and using an alternative modeling platform. While specific enough to investigate inspection practices, it is sufficiently general to incorporate changes for other phenomena. It demonstrates the effects of performing inspections or not, the effectiveness of varied inspection policies, and the effects of other managerial policies such as manpower allocation. The resu...

Adaptability is important to the survival and success of just about any software system, especially due to the rapid changes in technology, organizational structure, human perception and needs. Measurement of the degree to which a software system is adaptable to such changes is often times of a critical concern to software practitioners. This paper proposes a framework, POMSAA (ProcessOriented Metrics for Software Architecture Adaptability), which aims to provide numeric scores representing the adaptability of a software architecture as well as the intuitions behind these scores. In this framework, the intuitions behind the architectural adaptability scores are traced back to the "whys" of the architecture, namely, the requirements for which the architecture exists in the first place. POMSAA achieves the needed tracing by adopting the NFR Framework, which is a process-oriented qualitative framework for representing and reasoning about non-functional requirements (NFRs). In this paper we show how POMSAA can be used to calculate adaptability metrics for an architecture of a software system, how it helps detect weaknesses and strategic strengths in the architecture, how it helps to understand the reasons for the weaknesses/strengths and how to make improvements (that will help improve the metrics), and how to recalculate the metrics for the new architecture fast and intuitively. This paper also describes how POMSAA was used in supporting the development of an adaptable architecture for a real-system, a test and measuring instrument used for testing cell phones. 1.

Choosing appropriate practices for a project can be hard, given the various dimensions of performance each claims to optimize. Using data from 29 projects, this study examines the impact of eight development practices on both productivity and quality. Results suggest managers should choose a coherent system of practices on the basis of the specific objectives the software must meet.