Written from the perspective of a Technical Project Manager, this study presents a scenario for a complete "shift left" software development effort. It brings considerations for Test and Support as early as the Inception Stage. Based on an innovative model - Development Process Activity Cycles (DPAC) - this representation allows visualization of progress including recursive activities. The model is based on an interpretation of the Deming quality cycle of Plan Do, Check Act (PDCA). Periodic Management reports are generated using configuration management data generated during the Act phase of each iteration. There is no Test stage in the DPAC model; Test is represented in the back swing Check Phase of each iteration.
This approach allows the user or Subject Mater Expert (SME) to contemplate the face of the system through several iterations of design and development, using the triad principle ("Power of Three") matching a programmer, tester and member of the user community This approach incrementally reveals the best fit to the intent of the vision statement and iteratively uncovers the needs of the user while maintaining conceptual integrity.
This book provides a holistic and comprehensible view of the entire development process including ongoing evolution and support, staffing, and establishment of a comprehensive quality engineering program. It describes activity inside the "belly of the beast." By including support services as a part of the development model a complete return on investment (ROI) can be calculated and a value stream can be measured over the entire Application Life Cycle.
You will
· See how the various disciplines constituting the software development process come together
· Understand where in the iterative development process progress can be measured and control exercised
· Review how a quality engineering program will positively affect the quality of the development process
· Examine how the quality of the development process profoundly affects the quality of the software system
Who this book is for
Intended for a technical audience, this work should be of interest to all technical personnel including analysts, programmers, test and production, especially mid level managers and anyone familiar with the principles of a Lean, Agile approach to development.
Chapter 1: The DPAC Model.- Chapter 2: Why Include Support in a Development Model?.- Chapter 3: Inception.- Chapter 4: Elaboration.- Chapter 5: Construction.- Chapter 6: Assembly.- Chapter 7: Evolution.- Chapter 8: Risk Management.- Chapter 9: Engineering SOftware Quality.- Chapter 10: Final Remarks.- Appendix.
Robert F. Rose has provided services to both private and public sectors including telecom and healthcare, NavAir, the Environmental Protection Agency (EPA) and Housing and Urban Development (HUD). His experience includes pioneering design and development of a warehouse system for storing and analyzing medical records, design and development of an early prototype logistics tracking system for the V22 Osprey, and design and implementation of a complex enterprise wide web based directory system. Among his accomplishments he was Technical Project Manager for the Presidential Commission's Inquiry on the Challenger Disaster. The DPAC model is the product of independent efforts both in management and in preparation of the technical approach section for various responses to Requests for Proposals (RFP). Now retired, Robert has pulled together the sum of his experience with the process of developing software into the DPAC framework. It is entirely original work not derivativefrom other approaches.
Über den Autor
Robert F. Rose has provided services to both private and public sectors including telecom and healthcare, NavAir, the Environmental Protection Agency (EPA) and Housing and Urban Development (HUD). His experience includes pioneering design and development of a warehouse system for storing and analyzing medical records, design and development of an early prototype logistics tracking system for the V22 Osprey, and design and implementation of a complex enterprise wide web based directory system. Among his accomplishments he was Technical Project Manager for the Presidential Commission's Inquiry on the Challenger Disaster. The DPAC model is the product of independent efforts both in management and in preparation of the technical approach section for various responses to Requests for Proposals (RFP). Now retired, Robert has pulled together the sum of his experience with the process of developing software into the DPAC framework. It is entirely original work not derivativefrom other approaches.
Inhaltsverzeichnis
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 quality assurance (SQA) Configuration management. Test - continuous testing. Test driven development (TDD). The sum and intent of Software Quality Engineering.
Software Quality defined
9.1 Software Quality Assurance (SQA)
9.1.1 Ongoing Documentation
9.1.2 Data Flow Diagram (DFD)
9.2 Configuration Management (CM)
9.2.1 Identification of Configuration Items
9.2.2 CMDB
9.2.3 Change Reports (CRpt) and Discrepancy Reports (DR)
9.2.4 The Hardware Configuration Inventory (HWCI)
9.2.5 Change Control
9.2.6 Status Accounting
9.3 Test
9.3.1 Test Driven Development (TDD)
9.3.2 Perform Test
9.3.3 Audits
9.4 Data Related Quality Engineering
9.4.1 Conversion Plan
9.5 Software Quality Engineering for Programming
9.6 The Sum and Intent of Software Quality Engineering
Chapter 10. Final Remarks
tbd
Appendix 1. Attributes of Quality: International Organization for Standardization (ISO)
Appendix 2. Summary of Standards, Guidelines and Procedures
Appendix 3. Data Flow Diagramming: Symbols and Rules, An example
Resources
Klappentext
The principal benefit this book is to provide a holistic and comprehensible view of the entire software development process, including ongoing evolution and support. It treats development as a collaborative effort with triad communication between a tester, a programmer, and a representative from the user community or a Subject Matter Expert (SME). Progress is measured by user acceptance in each cycle before proceeding to the next step of an activity. There is no test stage in the DPAC model: continuous testing is represented in the backswing (Check Phase) of each activity cycle. nThis approach posits that there exists some ¿happy path¿ that represents the intent of the project as declared by the objectives of a Vision Statement, and that this path can be revealed by an iterative and incremental process of ¿freeing the statue from the stone.¿ As the image of this path unfolds, more waste is removed while retaining conceptual integrity. n nThe example presented herein walks the reader through an application of the model. This book should be of great interest to Product and Project Managers new to the concept of a lean agile development effort, and all practitioners of an agile methodology or those considering or just beginning an agile journey.nWhat You'll LearnnSee how the various disciplines constituting the software development process come togethernUnderstand where in the development process management, you can exercise measurement of progress and controlnReview how a quality engineering program will positively affect the quality of the development processnExamine how the quality of the development process profoundly affects the quality of the software systemnnnnWho This Book Is FornManagers, from the C-Suite (CEO,CXO, CIO) to line managers including project managers, and practitioners including programmers, testers, and mid-level managers (Technical Project Managers, Software Quality Engineers, and Coaches). Also, Agile enthusiasts who are looking for a software development methodology on which to place their hat.
n
n
Learn how user feedback drives the process of software development
Put a tester, programmer, and client representative triad in the context of an overall development effort
Study a visual reference to understand the creation and support of a Traceability Matrix
