Wiley: Automated Defect Prevention: Best Practices in Software Management. Preface. The Case for Automated Defect Prevention. What is ADP? 1. 2 What are the goals of ADP? People: Stimulated and Satisfied. Product: High Quality. Organization: Increased Productivity and Operational. Efficiency. 1. 2.
Process: Controlled, Improved, and Sustainable. Project: Managed through Informed Decision Making. Integrate static analysis into a software development process; Code Quality. How is ASDP implemented? Principles. 1. 3. Practices. 1. 3. 3 Policies. From Software Quality Control. Software for embedded systems. Defect Prevention Mindset. Automation. 1. 4 From the waterfall to modern software development process. Acronyms. 1. 6 Glossary. References. 1. 8 Exercises. Principles of Automated Defect Prevention. Introduction. 2. 2 Defect Prevention: Definition and Benefits. Historical Perspective: Defect Analysis and Prevention in. Auto Industry - What Happened to Deming? Principles of Automated Defect Prevention. Principle 1: Establishment of Infrastructure: . Initial Planning and Infrastructure. Introduction. 3. 2 Initial Software Development Plan. Product. 3. 2. 2 People. Technology. 3. 2. Process. 3. 3 Best Practices for Creating People Infrastructure. Defining Groups. 3. Determining a Location for Each Group's. Infrastructure. 3. Defining People Roles. Establishing Training Program. Cultivating a Positive Group Culture. Best Practices for Creating Technology Infrastructure. Automated Reporting System. Policy for Use of Automated Reporting System. Minimum Technology Infrastructure. Intermediate Technology Infrastructure. Expanded Technology Infrastructure. Integrating People and Technology. Human Factors and Concerns. Examples. 3. 7. 1 Focus on Developer Ideas. Focus on Reports Generated by the Minimum. Infrastructure. 3. Acronyms. 3. 9 Glossary. References. 3. 1. Exercises. 4. Requirements Specification and Management. Introduction. 4. 2 Best Practices for Gathering and Organizing. Requirements. 4. 2. Creating the Product Vision and Scope Document. Gathering and Organizing Requirements. Prioritizing Requirements. Developing Use Cases. Creating a Prototype to Elicit Requirements. Creating Conceptual Test Cases. Requirements Documents Inspection. Managing Changing Requirements. Best Practices in Different Environments. Existing Versus New Software Project. In- House Versus Outsourced Development Teams. Policy for Use of the Requirements Management System. The project manager should approve the final version of. The architect should approve the final version of the. SRS) document. The requirements from. SRS should be entered into, and their changes tracked in, the. The architect or lead developer should define the scope. The developer should create test cases for each feature. After the developer implements a feature, she should. Extended Planning and Infrastructure. Introduction. 5. 2 Software Development Plan. Defining Project Objectives. Defining Project Artifacts and Deliverables. The Vision and Scope document. SRS, describing the product key features. Architectural and detailed design documents and. List of COTS (Commercial- Off- the- Shelf- Components). Source and executable code. Test plan. 5. 4. 7 Acceptance plan. Periodic reports generated by the reporting system. Deployment plan. 5. User and operational manuals. Customer training plan. Selecting a Software Development Process Model. Defining Defect Prevention Process. Managing Risk. 5. Managing Change. 5. Defining Work Breakdown Structure (WBS) - An Iterative. Approach. 5. 1. 0 Best Practices for Estimating Project Effort. Estimation by Using Elements of Wideband Delphi. Estimation by Using Effort Analogy. Estimation by Using Parametric Models. Estimations of Using COTS and Code Reuse. Estimation Quality Factor and the Iterative Adjustments. Estimates. 5. 1. 1 Best Practices for Preparing the Schedule. Measurement and Tracking for Estimation. Identifying Additional Resource Requirements. Extending the Technology Infrastructure. Extending the People Infrastructure. Examples. 5. 1. 4. Focus on the Root Cause of a Project Scheduling. Problem. 5. 1. 4. Focus on Organizing and Tracking Artifacts. Focus on Scheduling and Tracking Milestones. Acronyms. 5. 1. 6 Glossary. References. 5. 1. Exercises. 6. Architectural and Detailed Design. Introduction. 6. 2 Best Practices for Design of System Functionality and its. Quality Attributes. Identifying Critical Attributes of Architectural. Design. 6. 2. 2 Defining the Policies for Design of Functional and. Non- functional Requirements. Applying Design Patterns. Service Oriented Architecture. Mapping Requirements to Modules. Designing Module Interfaces. Modeling Modules and their Interfaces with UML. Defining Application Logic. Refining Test Cases. Design Document Storage and Inspection. Managing Changes in Design. Best Practices for Design of Graphical User Interface. Identifying Critical Attributes of User Interface. Design. 6. 3. 2 Defining the User Interface Design Policy. Identifying Architectural Patterns Applicable to the User. Interface Design. Creating Categories of Actions. Dividing Actions into Screens. Prototyping the Interface. Testing the Interface. Examples. 6. 4. 1 Focus on Module Assignments and Design Progress. Focus on the Number of Use Cases per Module. Focus on Module Implementation Overview. Focus on Customized Best Practice for GUI Design. Acronyms. 6. 6 Glossary. References. 6. 8 Exercises. Construction. 7. 1 Introduction. Best Practices for Code Construction. Applying coding standards throughout development. Applying the test- first approach at the service and module. Implementing service contracts and/or module interfaces. Applying Test Driven Development for algorithmically. Conducting white box unit testing after implementing each. Verifying code consistency with the requirements and. Policy for Use of the Code Source Control System. Each developer should have a local copy (sandbox) of files. Each team should have a sandbox with copies of all files. Parallel development practices should be well defined and. Each developer should check out only code that she is. Each developer should check in to source control only code. Each developer should clean the sandbox and re- shadow. The entire team should store code for different software. The entire team should use versioning features only for. Measurements Related to Source Control. Tracking of Source Control Data. Policy for Use of Automated Build. Creating a special build account. Cleaning the build area before each build. Shadowing or cloning the source code to the build. Building the application at regularly scheduled intervals. Completely automating the build process. Creating hierarchies for Makefiles and/or other build. Parameterizing scripts and build files. For n- tier applications, establishing and creating a build. Fully integrating automated builds with the source control. Integrating testing into the automated build process. Measurements Related to Automated Builds. Tracking of Data Related to Automated Builds. Examples. 7. 5. 1 Focus on a Customized Coding Standard Policy. Focus on Features/Tests Reports. Acronyms. 7. 7 Glossary. References. 7. 9 Exercises. Testing and Defect Prevention. Introduction. 8. 2 Best Practices for Testing and Code Review. Conducting White Box Unit Testing: Bottom- Up Approach. Conducting Black Box Testing and Verifying the Convergence. Top Down and Bottom Up Tests. Conducting Code Reviews as a Testing Activity. Conducting Integration Testing. Conducting System Testing. Conducting Regression Testing. Conducting Acceptance Testing. Defect Analysis and Prevention. Policy for Use of Problem Tracking System. During development, problem tracking systems should be. After a code freeze, the problem tracking system should be. During release planning, recorded feature requests should. Measurements of Data Related to the Problem Tracking. System. 8. 4. 5 Tracking of Data Related to Problem Tracking System. Policy for Use of Regression Testing System. Configuring the regression system so that it provides. Executing regression tests automatically after each. Reviewing regression test results at the beginning of each. Using regression results to assess the deployment. Measurements Related to the Regression Testing System. Tracking of Data Related to the Regression Testing. System. 8. 6 Examples. Focus on Defect Tracking Reports. Focus on Test Type Reports. Example of a Root Cause Analysis of a Design and Testing. Defect. 8. 7 Acronyms. Glossary. 8. 9 References. Exercises. 9. Trend Analysis and Deployment. Introduction. 9. 2 Trends in Process Control. Process Variations. Process Stabilization. Process Capability. Trends in Project Progress. Analyzing Features/Requirements Implementation Status. Analyzing Source Code Growth. Analyzing Test Results. Analyzing Defects. Analyzing Cost and Schedule. Best Practices for Deployment and Transition. Deployment to a Staging System. Automation of the Deployment Process. Assessing Release Readiness. Release: Deployment to the Production System. Non- intrusive Monitoring. Acronyms. 9. 6 Glossary. References. 9. 8 Exercises. Managing External Factors. Introduction. 1. 0. Best Practices for Managing Outsourced Projects. Establishing A Software Development Outsource. Process. 1. 0. 2. Phase 0: Decision to Outsource. Phase 1: Planning. Phase 2: Implementation. Phase 3: Termination. Best Practices for Facilitating IT Regulatory. Compliance. 1. 0. Section 5. 08 of the US Rehabilitation Act. Sarbanes- Oxley Act of 2. Best Practices for Implementation of CMMI. Capability and Maturity Model Integration (CMMI). Staged Representation. Putting Staged Representation Based Improvement into. Practice Using ASDP. Putting Continuous Representation Based Improvement into. Practice Using ASDP. Acronyms. 1. 0. 6 Glossary. References. 1. 0. Exercises. 1. 1. Case Studies: Automation as an Agent of Change. Case Study I: Implementing Java Coding Standards in a. Financial Application. Company Profile. 1. Problems. 1. 1. 1. Solution. 1. 1. 1. Data Collected. 1. The Bottom Line Results - Facilitating Change. Acronyms. 1. 1. 1. Glossary. 1. 1. 1. References for Case Study I. Case Study II: Implementing C/C++ Coding Standards in an. Embedded Application. Introduction. 1. 1. C/C++ Coding Standards.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2016
Categories |