Automated Defect Prevention: Best Practices in Software Management

This book describes an approach to software management based on
establishing an infrastructure that serves as the foundation for
the project. This infrastructure defines people roles, necessary
technology, and interactions between people and technology. This
infrastructure automates repetitive tasks, organizes project
activities, tracks project status, and seamlessly collects project
data to provide measures necessary for decision making. Most
importantly, this infrastructure sustains and facilitates the
improvement of human-defined processes.

The methodology described in the book, which is called Automated
Defect Prevention (ADP) stands out from the current software
landscape as a result of two unique features: its comprehensive
approach to defect prevention, and its far-reaching emphasis on
automation. ADP is a practical and thorough guide to implementing
and managing software projects and processes. It is a set of best
practices for software management through process improvement,
which is achieved by the gradual automation of repetitive tasks
supported and sustained by this flexible and adaptable
infrastructure, an infrastructure that essentially forms a
software production line.

In defining the technology infrastructure, ADP describes
necessary features rather than specific tools, thus remaining
vendor neutral. Only a basic subset of features that
are essential for building an effective infrastructure has been
selected. Many existing commercial and non-commercial tools support
these, as well as more advanced features. Appendix E contains such
a list.

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 Requirements 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 References.

5.18 Exercises.

6. Architectural and Detailed Design.

6.1 Introduction.

6.2 Best Practices for Design of System Functionality and its
Quality Attributes.

6.2.1 Identifying Critical Attributes of Architectural
Design.

6.2.2 Defining the Policies for Design of Functional and
Non-functional Requirements.

Dorota Huizinga, PhD, is the Associate Dean for the College of
Engineering and Computer Science and Professor of Computer Science
at California State University, Fullerton. Her publication record
spans a wide range of computer science disciplines and her research
was sponsored by the National Science Foundation, California State
University System, and private industry.

Adam Kolawa, PhD, is the cofounder and CEO of Parasoft, a
leading provider of Automated Error Prevention software solutions.
Dr. Kolawa is a coauthor of Bulletproofing Web Applications, has
contributed to or written more than 100 commentary pieces and
technical papers, and has authored numerous scientific papers.

Digital version available through Wiley Online Library

Permissions

To apply for permission please send your request to permissions@wiley.com with
specific details of your requirements. This should include, the Wiley title(s), and the specific portion of the content you wish to re-use
(e.g figure, table, text extract, chapter, page numbers etc), the way in which you wish to re-use it, the circulation/print run/number of people
who will have access to the content and whether this is for commercial or academic purposes. If this is a republication request please include details
of the new work in which the Wiley content will appear.