Automated Defect Prevention: Best Practices in Software Management

Improve Productivity by Integrating Automation and Defect Prevention into Your Software Development Process
This book presents an approach to software management based on a new methodology called Automated Defect Prevention (ADP). The authors describe how to establish an infrastructure that functions as a software "production line" that automates repetitive tasks, organizes project activities, tracks project status, seamlessly collects project data, and sustains and facilitates the improvement of human–defined processes. Well–grounded in software engineering research and in industry best practices, this book helps organizations gain dramatic improvement in both product quality and operational effectiveness.
Ideal for industry professionals and project managers, as well as upper–level undergraduates and graduate–level students in software engineering, Automated Defect Prevention is complete with figures that illustrate how to structure projects and contains real–world examples, developers′ testimonies, and tips on how to implement defect prevention strategies across a project group.

Spis treści:
Preface.
Features and Organization.
Practice Descriptions.
Intended audience.
Acknowledgements.
Permissions.
Disclaimer.
1. The Case for Automated Defect Prevention.
1.1 What is ADP?
1.2 What are the goals of ADP?
1.2.1 People: Stimulated and Satisfied.
1.2.2 Product: High Quality.
1.2.3 Organization: Increased Productivity and Operational Efficiency.
1.2.4 Process: Controlled, Improved, and Sustainable.
1.2.5 Project: Managed through Informed Decision Making.
1.3 How is ASDP implemented?
1.3.1 Principles.
1.3.2 Practices.
1.3.3 Policies.
1.3.4 Defect Prevention Mindset.
1.3.5 Automation.
1.4 From the waterfall to modern software development process models.
1.5 Acronyms.
1.6 Glossary.
1.7 References.
1.8 Exercises.
2. Pri nciples of Automated Defect Prevention.
2.1 Introduction.
2.2 Defect Prevention: Definition and Benefits.
2.3 Historical Perspective: Defect Analysis and Prevention in Auto Industry – What Happened to Deming?
2.4 Principles of Automated Defect Prevention.
2.4.1 Principle 1: Establishment of Infrastructure: "Build a strong foundation through integration of people and technology".
2.4.2 Principle 2: Application of General Best Practices: "Learn from others′ mistakes".
2.4.3 Principle 3: Customization of Best Practices: "Learn from your own mistakes".
2.4.4 Principle 4: Measurement and Tracking of Project Status: "Understand the past and present to make decisions about the future".
2.4.5 Principle 5: Automation: "Let the computer do it".
2.4.6 Principle 6: Incremental Implementation of ADP′s Practices and Policies.
2.5 Automated Defect Prevention based Software Development Process Model.
2.6 Examples.
2.6.1 Focus on Root Cause Analysis of a Defect.
2.6.2 Focus on Infrastructure.
2.6.3 Focus on Customized Best Practice.
2.6.4 Focus on Measurements of Project Status.
2.7 Acronyms.
2.8 Glossary.
2.9 References.
2.10 Exercises.
3. Initial Planning and Infrastructure.
3.1 Introduction.
3.2 Initial Software Development Plan.
3.2.1 Product.
3.2.2 People.
3.2.3 Technology.
3.2.4 Process.
3.3 Best Practices for Creating People Infrastructure.
3.3.1 Defining Groups.
3.3.2 Determining a Location for Each Group′s Infrastructure.
3.3.3 Defining People Roles.
3.3.4 Establishing Training Program.
3.3.5 Cultivating a Positive Group Culture.
3.4 Best Practices for Creating Technology Infrastructure.
3.4.1 Automated Reporting System.
3.4.2 Policy for Use of Automated Reporting System.
3.4.3 Minimum Technology Infrastructure.
3.4.4 Intermediate Technology Infrastructure.
3.4.5 Expanded Technology Infrastructure.
3.5 Integrating People and Technology.
3.6 Human Factors and Concerns.
3.7 Examples.
3.7.1 Focus on Developer Ideas.
3.7.2 Focus on Reports Generated by the Minimum Infrastructure.
3.8 Acronyms.
3.9 Glossary.
3.10 References.
3.11 Exercises.
4. Requirements Specification and Management.
4.1 Introduction.
4.2 Best Practices for Gathering and Organizing Requirements.
4.2.1 Creating the Product Vision and Scope Document.
4.2.2 Gathering and Organizing Requirements.
4.2.3 Prioritizing Requirements.
4.2.4 Developing Use Cases.
4.2.5 Creating a Prototype to Elicit Requirements.
4.2.6 Creating Conceptual Test Cases.
4.2.7 Requirements Documents Inspection.
4.2.8 Managing Changing Requirements.
4.3 Best Practices in Different Environments.
4.3.1 Existing Versus New Software Project.
4.3.2 In–House Versus Outsourced Development Teams.
4.4 Policy for Use of the Requirements Management System.
4.4.1 The project manager should approve the final version of the vision and scope document, which should be entered into, and tracked in, the requirements management system.
4.4.2 The architect should approve the final version of the requirements specification (SRS) document. The requirements from SRS should be entered into, and their changes tracked in, the requirements management system.
4.4.3 The architect or lead developer should define the scope and test requirements for each feature to be implemented, and then enter those details in the requirements management system.
4.4.4 The developer should create test cases for each feature she is assigned to implement, and add those test cases to the requirements management system.
4.4.5 After the developer implements a feature, she should modify the test cases to verify the new feature, then, once the tests pass, she should mark the feature as "implemented".
4.4.6 Measurements Related to Requirement Management System.
4.4.7 Tracking of Data Related to the Requ irements Management System.
4.5 Examples.
4.5.1 Focus on Customized Best Practice.
4.5.2 Focus on Monitoring and Managing Requirement Priorities.
4.5.3 Focus on Change Requests.
4.6 Acronyms.
4.7 Glossary.
4.8 References.
4.9 Exercises.
5. Extended Planning and Infrastructure.
5.1 Introduction.
5.2 Software Development Plan.
5.3 Defining Project Objectives.
5.4 Defining Project Artifacts and Deliverables.
5.4.1 The Vision and Scope document.
5.4.2 SRS, describing the product key features.
5.4.3 Architectural and detailed design documents and models.
5.4.4 List of COTS (Commercial–Off–the–Shelf–Components) used.
5.4.5 Source and executable code.
5.4.6 Test plan.
5.4.7 Acceptance plan.
5.4.8 Periodic reports generated by the reporting system.
5.4.9 Deployment plan.
5.4.10 User and operational manuals.
5.4.11 Customer training plan.
5.5 Selecting a Software Development Process Model.
5.6 Defining Defect Prevention Process.
5.7 Managing Risk.
5.8 Managing Change.
5.9 Defining Work Breakdown Structure (WBS) – An Iterative Approach.
5.10 Best Practices for Estimating Project Effort.
5.10.1 Estimation by Using Elements of Wideband Delphi.
5.10.2 Estimation by Using Effort Analogy.
5.10.3 Estimation by Using Parametric Models.
5.10.4 Estimations of Using COTS and Code Reuse.
5.10.5 Estimation Quality Factor and the Iterative Adjustments of Estimates.
5.11 Best Practices for Preparing the Schedule.
5.12 Measurement and Tracking for Estimation.
5.13 Identifying Additional Resource Requirements.
5.13.1 Extending the Technology Infrastructure.
5.13.2 Extending the People Infrastructure.
5.14 Examples.
5.14.1 Focus on the Root Cause of a Project Scheduling Problem.
5.14.2 Focus on Organizing and Tracking Artifacts.
5.14.3 Focus on Scheduling and Tracking Milestones.
5.15 Acronyms.
5.16 Glossary.
5.17 Re