The current proliferation of software process models provides flexibility for organizations to deal with the unavoidably wide variety of software project situations, cultures, and environments. But it weakens their defenses against some common sources of project failure, and leaves them with no common anchor points around which to plan and control. This article identifies three milestones -- Life Cycle Objectives, Life Cycle Architecture, and Initial Operational Capability -- which can serve as these common anchor points. It also discusses why these particular three milestones or their equivalents are success-critical, particularly for large software projects, but for other software projects as well. 1. Introduction For a few golden moments in the mid-1970's, it appeared that the software field had found a sequence of common anchor points: a set of milestones around which people could plan, organize, monitor, and control their projects. These were the milestones in the waterfall model...

People benefit from tightly integrated systems that can be designed, realized and evolved affordably. Unfortunately, common software design methods do not easily accommodate requirements for tightly integrated systems. Indeed, when used to meet such requirements, common methods tend to yield unnecessarily complex structures that complicate design and realization and that inhibit subsequent evolution. After substantiating this claim, I present the mediator method as a solution. This method combines behavioral entity-relationship (ER) modeling for design with a mediator approach to implementation. The mediator method is better than common methods for designing, realizing, and evolving many integrated systems. I support this claim both by rational argument from simplifying models and by careful...

Software engineering focuses on producing quality software products through quality processes. The attention to processes dates back to the early 70's, when software engineers realized that the desired qualities (such as reliability, efficiency, evolvability, ease of use, etc.) could only be injected in the products by following a disciplined flow of activities. Such a discipline would also make the production process more predictable and economical.

this paper, I review the history of HCI as steps toward a science of design. My touchstone is Simon's (1969) provocative book he Sciences of the Artificial. The book pre-dates HCI, and many of its specific characterizations and claims about design are no longer authoritative (see Ehn, 1988). Nevertheless, two of Simon's themes echo through the history of HCI, and still provide guidance for charting its continuing development

Test Driven Development (TDD) is a software development practice in which unit test cases are incrementally written prior to code implementation. In our research, we ran a set of structured experiments with 24 professional pair programmers. One group developed code using TDD while the other a waterfall-like approach. Both groups developed a small Java program. We found that the TDD developers produced higher quality code, which passed 18 % more functional black box test cases. However, TDD developer pairs took 16 % more time for development. A moderate correlation between time spent and the resulting quality was established upon analysis. It is conjectured that the resulting high quality of code written using the TDD practice may be due to the granularity of TDD, which may encourage more frequent and tighter verification and validation. Lastly, the programmers which followed a waterfall-like process often did not write the required automated test cases after completing their code, which might be indicative of the tendency among practitioners toward inadequate testing. This observation supports that TDD has the potential of increasing the level of testing in the industry as testing as an integral part of code development.

This paper discusses the importance of process support for business activities. A reference framework for process concepts and technology support is sought. The general requirements and properties of the process domain are rst discussed. Then, four process sub-models are presented to describe activities, products, tools and organisations, respectively. Five process model phases are also introduced, as well as meta-processes and related human roles to handle process models and their transformations. The process concepts are applied to a bank example.

Software processes are complex entities that may last for long periods of time and are carried out through the interaction of humans and computerised tools. They need to continuously evolve in order to cope with di erent kinds of changes or customisations both in the organisation and in the technologies used to support software production activities. In recent years, many software process technologies have been developed, and have currently been further extended and used in trial projects. Moreover, some research prototypes have generated commercial products, that are marketed and currently used in industrial organisations. Despite these significant efforts and results, however, there is still little conceptual characterisation and assessment of the properties of software processes and related support environments. It is difficult to compare and assess existing approaches. Even a common characterisation of the problems to be addressed seems to be problematic and difficult to achieve. This is particularly true when we consider software process evolution, for which it seems that an agreed-upon and satisfactory solution has not been established yet. This

From our experience with several organizations that employ software product families, we have learned that, contrary to popular belief, deriving individual products from shared software assets is a time-consuming and expensive activity. In this paper we therefore present a study that investigated the source of those problems. We provide the reader with a framework of terminology and concepts regarding product derivation. In addition, we present several problems and issues we identified during a case study at two large industrial organizations that are relevant to other, for example, comparable or less mature organizations.

Abstract not found

Requirements-driven impact analysis (RDIA) identifies the set of software entities that need to be changed to implement a new requirement in an existing system. RDIA thus involves a transition from requirements to software entities or to a representative model of the implemented system. RDIA is performed during the release planning phase. Input is a set of requirements and the existing system. Output is, for each requirement, a set of software entities that have to be changed. The output is used as input to many projectplanning activities, for example cost estimation based on change volume.