Goal-Driven Software Development Process

Abstract: The three amigos of software development come together again to bring you an introduction to a new standard for creating today's software that will definitely be useful for any developer or manager familiar with UML. This book provides a comprehensive guide to The Objectory Software Development Process derived from the three market leading OOA&D methods: Booch, OOSE (Use-Case), and OMT. Overviews of the four basic principles of the Unified Process are complemented by excellent use case examples that are drawn from such areas as banking and inventory control.

Abstract: (NOTE: Each chapter concludes with a summary.) Preface. I. THE PROCESS. 1. Software Development Best Practices. The Value of Software. Symptoms and Root Causes of Software Development Problems. Software Best Practices. Develop Software Iteratively. Manage Requirements. Use Component-Based Architectures. Visually Model Software. Continuously Verify Software Quality. Control Changes to Software. The Rational Unified Process. 2. The Rational Unified Process. What Is the Rational Unified Process? The Rational Unified Process as a Product. Software Best Practices in the Rational Unified Process. Other Key Features of the Rational Unified Process. A Brief History of the Rational Unified Process. 3. Static Structure: Process Description. A Model of the Rational Unified Process. Roles. Activities. Artifacts. Disciplines. Workflows. Additional Process Elements. A Process Framework. 4. Dynamic Structure: Iterative Development. The Sequential Process. Overcoming Difficulties: Iterate! Gaining Control: Phases and Milestones. A Shifting Focus across the Cycle. Phases Revisited. Benefits of an Iterative Approach. 5. An Architecture-Centric Process. The Importance of Models. Architecture. The Importance of Architecture. A Definition of Architecture. Architecture Representation. An Architecture-Centric Process. The Purpose of Architecture. Component-Based Development. Other Architectural Concepts. 6. A Use-Case-Driven Process. Definitions. Identifying Use Cases. Evolving Use Cases. Organizing Use Cases. Use Cases in the Process. II. PROCESS DISCIPLINES. 7. The Project Management Discipline. Purpose. Planning an Iterative Project. The Concept of Risk. The Concept of Measurement. Roles and Artifacts. Workflow. Building an Iteration Plan. 8. The Business Modeling Discipline. Purpose. Why Business Modeling? Using Software Engineering Techniques for Business Modeling. Business Modeling Scenarios. Roles and Artifacts. Workflow. From the Business Models to the Systems. Modeling the Software Development Business. Tool Support. 9. The Requirements Discipline. Purpose. What Is a Requirement? Types of Requirements. Capturing and Managing Requirements. Requirements Workflow. Roles in Requirements. Artifacts Used in Requirements. Tool Support. 10. The Analysis and Design Discipline. Purpose. Analysis versus Design. How Far Must Design Go? Roles and Artifacts. Designing a User-Centered Interface. The Design Model. The Analysis Model. The Role of Interfaces. Artifacts for Real-Time Systems. Component-Based Design. Workflow. Tool Support. 11. The Implementation Discipline. Purpose. Builds. Integration. Prototypes. Roles and Artifacts. Workflow. Tool Support. 12. The Test Discipline. Purpose. Testing in the Iterative Lifecycle. Dimensions of Testing. Roles and Artifacts. Workflow. Tool Support. 13. The Configuration and Change Management Discipline. Purpose. The CCM Cube. Roles and Artifacts. Workflow. Tool Support. 14. The Environment Discipline. Purpose. Process Engineering Process. Roles and Artifacts. Workflow. Tool Support. 15. The Deployment Discipline. Purpose. Roles and Artifacts. Workflow. 16. Typical Iteration Plans. Defining the Product Vision and the Business Case. Building an Architectural Prototype. Implementing the System. 17. Implementing the Rational Unified Process. Introduction. The Effect of Implementing a Process. Implementing the Rational Unified Process Step by Step. Implementing a Process Is a Project. Appendix A: Summary of Roles. Appendix B: Summary of Artifacts. Appendix C: Acronyms. Glossary. Bibliography. Index. 0321197704T11172003

Abstract: Experience from a dozen years of analyzing software engineering processes and products is summarized as a set of software engineering and measurement principles that argue for software engineering process models that integrate sound planning and analysis into the construction process. In the TAME (Tailoring A Measurement Environment) project at the University of Maryland, such an improvement-oriented software engineering process model was developed that uses the goal/question/metric paradigm to integrate the constructive and analytic aspects of software development. The model provides a mechanism for formalizing the characterization and planning tasks, controlling and improving projects based on quantitative analysis, learning in a deeper and more systematic way about the software process and product, and feeding the appropriate experience back into the current and future projects. The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment). The first in a series of TAME system prototypes has been developed. An assessment of experience with this first limited prototype is presented including a reassessment of its initial architecture. >

Abstract: The potential benefits of using models are significantly greater in software than in other engineering disciplines because of the potential for a seamless link between models and the systems they represent. Unfortunately, models have rarely produced anticipated benefits. The key lies in resolving pragmatic issues related to the artifacts and culture of the previous generation of software technologies.