Introduction. Traditional vs. Agile Approach Review of the best known traditional models - waterfall, spiral, V -model - and alternative agile models - Scrum, SAFe, DAD, RUP/UP, DSDM, XP and introduction to DPAC Chapter 1. The DPAC Model Presents the DPAC Model in a static view describing the Stages and Activity Cycles in generalized form. Shows where Test is included in the model in the backswing of the PDCA overlay for each cycle. Continuous testing. 1.1 Intent and purpose 1.
2 Phases of the DPAC activity cycles 1.3 DPAC is inherently a "shift left" model 1.4 DPAC Embraces Agile and DevOps 1.5 Activities represented in the DPAC model 1.6 Roles and responsibilities 1.7 Stages of Application Development 1.8 The objective of this model Paradigms as a hindrance to understanding 1.9 Summary Chapter 2.
Why Include Support in a Development Model? Offers quotes referring to the importance of including maintenance in the development cycles. Displays statistics regarding the cost of maintenance as a part of the overall lifecycle. Every project that succeeds, even if challenged becomes a Support project. Shows the consequences of types of error. Cites the top ten software development problems from the perspective of maintenance. Building political and social capital. 2.1 Statement of the Problem 2.
2 To put this in terms of total cost. 2.3 Putting Support in the Equation 2.4. Freeing the statue from the stone 2.5 Factors supporting code reliability 2.6 Measures during development to improve software system maintainability. 2.
7 Ameliorative measures 2.8 Political and Social Capital What''s Ahead Chapter 3. Inception Stresses the importance of a Vision Statement as a project charter. The role of the charter as a first step in creating "conceptual integrity." Introduces non-functional requirements. Planning for security including privacy concerns. 3.1 Goal: Achieving Consensus 3.
2 Nine Objectives 3.3 The importance of the Vision Statement 3.4 Introduction to the Traceability Matrix 3.5 Non-functional Requirements 3.6 Planning for Information Security and System Security 3.7 Privacy 3.7 Legacy data 3.8 Summary of Security requirements 3.
9 Identification of security requirements is initiated in the Inception Stage Summary Chapter 4. Elaboration The goal of Elaboration is to create an overall process model that will serve as a Functional Requirements Specification (FRS), the second step in preserving conceptual integrity. The FRS forms the basis of level of effort and cost estimation. Outlines the role of the system architecture and the system backbone. Introduces the Configuration Management Database (CMDB) and the Traceability Matrix. 4.1 The goal of the Elaboration Stage 4.2 Objectives 4.
3 Activities during Elaboration 4.4 Ongoing Activities 4.5 Implement Quality Engineering Plan 4.6 Additional responsibilities: 4.7 Data Flow Diagrams (DFD) 4.8 Functional Requirements Specification (FRS) 4.9 Design Review 4.10 Following design approval 4.
11 Determine staffing, roles and responsibilities. 4.12 Rules of the Road (staffing) 4.13 Design, develop and document the system architecture 4.14 Demonstrate an operating backbone 4.15 Application Design Requirements 4.16 Introduction to Configuration Management Data Base (CMDB) 4.17 The CMDB includes tools 4.
18 The Traceability Matrix 4.19 On Joint Application Development (JAD) 4.20 On Workshops (in general) Chapter 5 Construction Describes activities in the Process Detail and Unit Development Cycles. Introduces the practice of iterative development. Includes measures to assure the quality of the code as developed. Technical review subcycle. The triad principle. 5.
1 Process Detail Cycle 5.1.1 Approach 5.1.2 Phases 5.1.3 Roles and responsibilities 5.1.
4 Business Rules Definition 5.1.5 Form of Business Rules 5.1.6 Business rule review 5.1.7 Summation 5.2 Unit Development Cycle 5.
2.1 Overview 5.2.2 Changing requirements 5.2.3 Processing Change Reports (CRpt) 5.2.4 Configuration Management 5.
2.5 Advancement 5.2.6 Unit development 5.3 "Mechanical" tests 5.4 Test plans 5.5 Iterative development 5.6 Code check 5.
7 Technical review sub-cycle 5.8 Refactoring, Test driven development (TDD) 5.9 True to requirements 5.10 User review 5.11 Regarding tools 5.12 Automated testing 5.13 Power of three 5.14 Staffing 5.
15 Summation Chapter 6. Assembly "Service" assembly and system assembly. Continuous Integration and Continuous Delivery. Role of the agile DBA. Role of automation. 6.1 Definitions 6.2 Service Assembly 6.
3 Continuous Integration and Continuous Deployment 6.4 When to use Automation tools 6.5 Automation is suited to following types 6.6 Roles and Responsibilities 6.7 Systems of Record (SOR) and Systems of Engagement (SOE) 6.8 Test Data Management 6.9 The Agile DBA 6.10 DevOps and the Database 6.
11 Staffing Chapter 7. Evolution Support defined. Bureaucratic impediments. Types of support. Limited understanding. Lehman''s Laws. Software Support Lifecycle (SMLC). Tribal knowledge.
7.1 Support Defined 7.2 Processes, activities, and practices that are applicable to software Support: 7.3 About software Support 7.4 Support Personnel 7.5 Error Correction 7.6 Bureaucratic Impediments 7.7 On the difficulty of correcting an error during Support: 7.
8 Types of Support 7.9 Another View 7.10 Software Support Effort 7.11 Limited Understanding 7.12 Technical Problems 7.13 Forces for evolution 7.14 Lehman''s Laws 7.15 Model of the Software Support Lifecycle (SMLC) 7.
16 The importance of ''Tribal Knowledge'' Chapter 8. Risk Management A personal accounting of risks encountered in 35 years of software development. "Man month" is a unit of cost, not progress. 8.1 General Mayhem 8.2 Loss of Key Personnel - Missing a window of opportunity 8.3 Software Development always has a political dimension 8.4.
Unrealistic Expectations. 8.5 Lack of a competent Project "Champion." 8.6 Missing Man 8.7 Keep documentation up to date. 8.8 Missing Tools - Loss of "Tribal Knowledge.
" 8.9 Missing Overview. 8.10 Lack of Quality Engineering measures 8.11 Lack of proper tools. 8.12 Over optimistic level of effort 8.13 "Man Month" is a unit of cost, not progress.
8.14 No tool alone will "fix" gaps in the business model 8.15 Learning what a tool does NOT do 8.16 Lack of appropriate skills 8.17 "Round Up the Usual Suspects!" 8.18 Necessary elements Chapter 9. Engineering Software Quality Software quality defined. Sofwware qua.