Abstract not found

In a software development group of IBM Retail Store Solutions, we built a non-trivial software system based on a stable standard specification using a disciplined, rigorous unit testing and build approach based on the test-driven development (TDD) practice. Using this practice, we reduced our defect rate by about 50 percent compared to a similar system that was built using an ad-hoc unit testing approach. The project completed on time with minimal development productivity impact. Additionally, the suite of automated unit test cases created via TDD is a reusable and extendable asset that will continue to improve quality over the lifetime of the software system. The test suite will be the basis for quality checks and will serve as a quality contract between all members of the team. 1

To achieve higher flexibility and to better satisfy actual customer requirements, there is an increasing tendency to develop and deliver software in an incremental fashion. In adopting this process, requirements are delivered in releases and so a decision has to be made on which requirements should be delivered in which release. Three main considerations that need to be taken account of are the technical precedences inherent in the requirements, the typically conflicting priorities as determined by the representative stakeholders, as well as the balance between required and available effort. The technical precedence constraints relate to situations where one requirement cannot be implemented until another is completed or where one requirement is implemented in the same increment as another one. Stakeholder preferences may be based on the perceived value or urgency of delivered requirements to the different stakeholders involved. The technical priorities and individual stakeholder priorities may be in conflict and difficult to reconcile. This paper provides i) a method for optimally allocating requirements to increments; ii) a means of assessing and optimizing the degree to which the ordering conflicts with stakeholder priorities within technical precedence constraints; iii) a means of balancing required and available resources for all increments; and iv) an overall method called EVOLVE aimed at the continuous planning of incremental software development. The optimization method used is iterative and essentially based on a genetic algorithm. A set of the most promising candidate solutions is generated to support the final decision. The paper evaluates the proposed approach using a sample project.

Test-driven development is a software development practice that has been used sporadically for decades. With this practice, test cases (preferably automated) are incrementally written before production code is implemented. Test-driven development has recently reemerged as a critical enabling practice of the Extreme Programming software development methodology. We ran a case study of this practice at IBM. In the process, a thorough suite of automated test cases was produced. In this case study, we found that the code developed using a test-driven development practice showed, during functional verification and regression tests, approximately 40 % fewer defects than a baseline prior product developed in a more traditional fashion. The productivity of the team was not impacted by the additional focus on producing automated test cases. This test suite will aid in future enhancements and maintenance of this code. The experiment and the results are discussed in detail. 1.

As software organizations continue to move toward Web-based systems development, they often assign or outsource such projects to small teams of highly qualified, but often relatively young, developers. Frequently, the developers’ attitude is less than positive toward software engineering practices—particularly software process improvement initiatives and metrics collection. Part of the problem is the business context: Web-based applications demand faster time-tomarket and the continual integration of new requirements. Such demands have increased the popularity of agile software processes, which let teams increase development productivity while maintaining software quality and flexibility. Agile processes like extreme programming (XP),1-3 Scrum,4 Crystal,5 and adaptive software development6 aim to increase a software organization’s responsiveness while decreasing development overhead. They focus on delivering executable code and see people as the strongest ingredient of software development. Here, we offer an overview of the philosophy and practice behind XP, which is currently the most popular agile methodology.

Das Thema der Diplomarbeit ist 'Requirements Engineering in Agile Software Development'. Der erste Teil der Diplomarbeit befasst sich mit den beiden Software Engineering Ansatzen und vergleicht diese. Wahrend das traditionelle Requirements Engineering mehr dokumentenorientiert ist, versuchen agile Methoden Dokumentation so weit wie moglich zu reduzieren. Die Diplomarbeit analysiert die Unterschiede und Gemeinsamkeiten der beiden Ansatze und zeigt, wie agile Methoden von Requirements Engineering Techniken profitieren konnten. Der zweite

Software developers and project managers are struggling to assess the appropriateness of agile processes to their development environments. This paper identifies limitations that apply to many of the published agile processes in terms of the types of projects in which their application may be problematic.

This chapter draws attention to the question of determining the conditions when free/open source software development may represent a significant alternative to modern software engineering techniques for developing large-scale software systems. F/OSSD often entails shorter development times that can produce higher quality systems, and incur lower costs than may be realized through developing systems according SE techniques. Understanding why and how this may arise is the focus of this chapter. It presents, analyzes, and compares data collected from different F/OSSD projects, including an in-depth case study, to help develop such an understanding. The goal of this chapter is to determine the circumstances and conditions when F/OSSD represents a viable alternative to SE for the development of complex software systems. In particular, the chapter seeks to contrast differences observed in the arrangement and tooling of their respective software development practices, production resources, technical regimes, and community practices in which they are embedded. This in turn may then help identify how the practice and principles of SE might be improved.

To address the problems of traditional software development, recent years have shown the introduction of more light-weight or "agile " development processes (eXtreme Programming being the most prominent one). These processes are intended to support early and quick production of working code by structuring the development into small release cycles and focus on continual interaction between developers and customers. As such software development processes become more popular, there is a growing demand from industry to introduce agile development practices in tertiary education. This is not a straighOCorward task as the corresponding practices may run counter to educational goals or may not be adjusted easily to a learning environment. In this paper, we discuss some of these issues and reflect on the problems of teaching agile processes in tertiary education. 1.

This paper discusses a model-based approach to testing as a vital part of software development. It argues that an approach using models as central development artifact needs to be added to the portfolio of software engineering techniques, to further increase efficiency and flexibility of the development as well as quality and reusability of results. Then test case modeling is examined in depth and related to an evolutionary approach to model transformation. A number of test patterns is proposed that have proven helpful to the design of testable object-oriented systems. In contrast to other approaches, this approach uses explicit models for test cases instead of trying to derive (many) test cases from a single model