This book collects articles written by industry luminaries that describe effective software construction practices in these areas. This book contains a carefully selected array of articles address the vital elements of this phase. Subjects include project management tips and techniques, eXtreme Programming (XP), strategic reuse management, patterns, components, class normalization, mapping objects to relational databases, persistence modeling using the UML, writing maintainable code, coding tips and techniques, writing secure code, regression testing, testing frameworks (JUnit), change management, traceability within UML models, and configuration management.
The Construction phase is the third of six phases — Inception, Elaboration, Construction, Transition, Production , and Retirement — that a system experiences throughout its complete lifecycle. This phase has several goals:
- To describe the remaining requirements
- To flesh out the design of your system
- To ensure that your system meets the needs of its users and fits into your organization’s overall system portfolio
- To complete component development an d testing, including both the software product and its documentation
- To minimize development costs by optimizing resources
- To achieve adequate quality as rapidly as possible
- To develop useful versions of your system
This book is third in a four-volume series that presents a critical review of the Unified Process — designed to present a more robust software process that addresses your development and production needs. The series provides you a balanced perspective of the alternative design methodologies available, proposes a synthesized software process that addresses the scope of your real world, and presents materials from the Software Development magazine that will flesh out each of the UP phases. One goal of this book and of the entire series, is to provide proven alternative approaches to the techniques encompassed by the Rational Unified Process (RUP). Another goal is to fill in some of the gaps in the RUP. Because the RUP is a development process, not a software process, it inevitably misses or shortchanges some of the concepts that are most important for software professionals.