This view describes the DPAC Model and Cycles of Activity.
A flowchart of the Development Process Activity Cycles or D P A C. There are several stages: Inception, Elaboration, Construction, Integration, and Evolution, which are mentioned at the bottom and used to split the chart. The first step is in Inception, with Vision and Statement. A bar with text Analysis/Implementation and Test/Review split Inception from the rest. Then a circle is labeled Act and all the cycles are tangential around Act. The further the cycles are, the more oval-shaped they are. The cycles are Process Overview, Process Detail, Unit Development, Service Assembly, System Integration, Development, and Support. A line below, labeled Retirement, extends to the end of Evolution.
About the Model
A model, as used in this context, is a graphic representation of the development processes. Until now there has been no generalized model of the course of activities over all the application life stages. The DPAC model brazenly claims to fill that gap. In fact, I contend that it is the optimum model of geometric efficiency. It also describes a path of development, including recursive flows.
DPAC does for agile what “waterfall” does for traditional methods of development.
A, a ringing alarm clock, B, a circular object like a pebble, C, a boat steering shaped rotating device on a stand, D, the device causing a fallen coffee mug, E, contents of the mug falling, F, a bucket collecting the pebble like contents, G, a big scissor connected to the bucket's rope, H A shoe hanging on a lamp stand, I, a stapler over a paper.
Rube Goldberg’s model
Source: (c) Vernier Software & Technology used with permission.
DPAC and PDCA
Plan the work.
Do – implement the plan.
- Check
Test the result (where appropriate).
Review with users.
Act – determine the course of the next iteration, and review the results when the component is coded (trust but verify).
Each activity cycle is re-entrant. That is, an activity cycle may repeat or re-enter a previous cycle before “graduating” to the next cycle. For example, if any error of understanding or new view from the user is uncovered in the Service Assembly Cycle, the progress of development is routed back to the Process Detail Cycle – indicating more interaction with the user – and then to the Component Development Cycle where all coding takes place. Then, the service is reassembled in the Service Assembly Cycle, and the progress moves ahead to the System Integration Cycle where the process is repeated as necessary to gain the user’s concurrence.
Lowers the number of errors detected later in the development process – thereby decreasing overall cost
Reduces the amount of time to actually fix the error as at this point the team is in direct contact with the user
Lessens complexity to locate the source of an error in code as it is being developed
DPAC Embraces Agile and DevOps
DevOps is fundamentally about changing culture, about building much more responsible organizations that can move quickly in ever-changing circumstances. It’s also about taking full advantage of modern technology, to replace manual, time-consuming and error-prone activities with automation.
A model diagram for the Procedures in Business. Between ah ha, and ka ching. The process are Business, Agile Development fixes this, Development, DevOps fixes this, and Operations.
Transition between business cases and development, and between development and operations
Source: Matt Watson January 16, 2013, Insights for Dev Managers, “Divvy Up DevOps Tasks, Defining the Ops in DevOps” https://stackify.com/defining-the-ops-in-devops/ (Google)
Activities Represented in the DPAC Model
The larger function of the CAB is to maintain communication between the host organization and the development team regarding progress toward (or impediments against) objectives.
Impediments may include lack of accessibility or availability to the development team of area specialists, particularly as the development process proceeds into the Process Detail and Component Development Cycles.
Business Rule and Requirements Review is conducted by the Lead Business Analyst. The objective is to ensure that business rules and requirement statements are decomposed to “atomistic” statements of testable requirements. These data shall be maintained in a Requirements Database – consisting of online pointers to offline documents where accountable. The offline document compendium can be maintained by a designee of the Lead Business Analyst performing the role of librarian.
Technical review may include inspections, and/or refactoring. It is the responsibility of each programmer to maintain source code version control and track “build” options. In addition, the technical reviewers process Change Reports (CRpts) brought forward by the component developers. If the change is deemed to be a significant departure from the Vision Statement, the Technical Project Manager may refer the CRpt to the Change Advisory Board (CAB) for a decision of whether to carry it forward or to pass on its implementation.
Operations (DevOps) move persons from operations in the host organization into the development process.
Analysis, coding, test, and user review. There is a strong argument to be made for having the testers in the development process brought in with the development team, not as an extension of the host support staff. First, the team can hire testers who want to work alongside a programmer and/or business analyst. Second, the host test component will take over during the Deployment Cycle in the early Stage and would be stretched to provide personnel for the development team.
Configuration management (CM) is carried out in a set of roles that may be filled by different individuals.
To track the progress of each component of code in a Software Configuration Inventory (SWCI) database
To track the initiation and progress of Change Reports (CRpts) and Discrepancy Reports (DRs) through to completion
To initiate and maintain a traceability matrix, as a part of the Configuration Management Database (CMDB)
Each item in the software inventory is tracked through each activity cycle. The traceability matrix enables a tester at any level to identify to whom a questionable result of testing should be referred, and, in the event a business rule is changed or modified, allows an analyst or programmer to identify where in code a particular business rule is actualized.
Business analyst – Maintains a compendium of business rules reducing requirements to an irreducible (atomic) level. Tied to the goals and objectives of the Vision Statement, this is the bottom level of the traceability matrix.
Technical management – Maintains version control over source code, builds and deploys scripts and libraries, and synchronizes test data with current activity.
Test – Preserves test protocols and tool scripts.
Librarian – Maintains document control and publishes standards, guidelines, and procedures in conjunction with the Process Quality Assurance officer. In addition to maintaining version control of document work products (e.g., the compendium of business rules), this person maintains the glossary.
Database Administration – The Agile DBA maintains version control over database scripts, generation of test data and various versions of the Entity Relationship Diagram (ERD). The DBA is also the data modeler and initiates the data dictionary.
Software Quality Assurance (SQA) conducts audits to assure the integrity of the software development process. It is responsible for the promulgation of standards, guidelines, and procedures.
Project Management and Administration – The principal responsibilities are to track the burn rate and maintain liaison with the host organization.
Programmers (programmer/analyst, programmer/tester) perform the coding of the application.
Stages, Cycles, Phases, Parts, and Steps
Development stages and activity cycles
Stage | Cycle(s) |
|---|---|
Inception | Vision Statement |
Elaboration | Process Overview Cycle (Data Flow Diagram) |
Construction | Process Detail Cycle Component Development Cycle |
Assembly | Service Assembly Cycle System Integration Cycle |
Evolution | Deployment Cycle Support Cycle |
Retirement | Fold up process |
The Inception Stage of Application Development
The Inception Stage is occupied with the creation of a Vision Statement. The process begins with the identification of principal shareholders (area specialists) headed up by the sponsor, a “champion,” or a designated chairperson. The statement should begin with a declaration of purpose. The declaration of purpose is followed by “bullet points” of specific goals and objectives. It is critical that these “bullet points” be comprehensive of what the system is intended to accomplish.
The Elaboration Stage of Application Development
To identify process and data dependencies
To populate the data flows and data stores of the data flow diagram
To identify implementation priorities
To derive an initial estimated level of effort for each prioritized component
In this interpretation of the DPAC model, these objectives are met by the upper levels of a data flow diagram (DFD). This activity is represented in the DPAC model by iterations of the Process Overview Cycle.
At the conclusion of the Elaboration Stage, there should be a Design Review session for shareholders and development team members to walk through the DFD of the completed “system to be.” This will allow time for questions to be asked and answered regarding the broad outline of the system.
In this “low ceremony,” agile interpretation of the DPAC model, the DFD will constitute a functional requirements specification (FRS). The DFD should contain enough information to provide an early estimate of the level of effort to complete the software system. Again, the DFD and this information should be available at the end of the Elaboration Stage (after completion of various iterations of the Process Overview Cycle).
In general, the larger the project, the greater the need for “ceremony” (formalisms).
The Construction Stage of Application Development
To make assignments based on the processes uncovered in the Process Overview Cycle
To complete the data flow diagram (where required)
To create an initial (incremental) database design
To identify any subprocess logic that may have emerged as the work on design continues
To identify and define business rules
The Process Detail Cycle and the Component Development cycle are paired for each Component of software where work on each unit of code can proceed independently of others.
Particularly where Test-Driven Development is employed, it is essential that the programmer fully understands the requirements (business rules) to be rendered in code. It may be prudent to send a business analyst to conduct the first round of interviews, and have a programmer/analyst and a tester perform the second round. If anything remains unclear, the business analyst might do another round with or without a programmer before coding takes place. There may be several “spirals” and teams running concurrently – finishing at different times. Cycles are not necessarily of equal duration.
In general, the DPAC system strives to reduce the number of “handoffs” by pair programming with a tester and/or a business analyst.
The Process Detail Cycle and the Component Development Cycle may be iterated several times in successive order as “requirements” are clarified or uncovered late in the code development process.
The Assembly Stage of Application Development
The business of the Construction Stage is to produce “bug-free” components of code that meet the needs of the users. The business of the Assembly Stage is to assemble these units into operational components, and to test these components for “dynamic integrity.”
“Dynamic integrity” refers to uncovering conflicts between components – and in the case of the System Integration Cycle, conflicts between services. One test is to determine if navigation controls are functioning as intended from sign-on to sign-off. Hopefully there have been adequate architectural choices that enable assembly processes.
An illustration of the overlap between Dev Ops and the Development Environment. The three sections are Agile, Dev Ops, and Support, separated by a line and indicated by arrows at the bottom. The Dev Ops arrow has some overlap with the other two. The cycles are Process Detail, Unit Development, Service Assembly, System Integration, Development Cycle, and Support Cycle. As the cycles move further from the start, they become more oval-shaped. The Dev Ops consists of other oval cycles with a common tangential point, Server Positioning, Build Automation, Automated and Manual Test, Application Release Automation, and Version Control. Dev Ops starts in the Unit Development Section.
DevOps is operations reaching back into the development environment
Each of the servers required in the Construction and Assembly Stages must be identically provisioned (i.e., same hardware requirements, same version and release number as the Support Servers). This enables a smooth transition of code and data and eliminates hardware and operating system variation as sources of error.
The Evolution Stage and Retirement
Nowhere in application development is the ability to recover from an error more important than in the Support Cycle. Here, an error can bring down the system for an unspecified period of time – costing the organization for downtime of staff and internal matters – but more significantly can block customer engagement at an even higher cost in terms of customer retention. All the more reason to establish a traceability matrix. Retirement generally happens in a staggered relationship with the next generation.
The objective of this model is to maintain the conceptual integrity of requirements from inception to completion of the application life cycle.
There is no “Requirements Cycle” as such in this representation of the model. This interpretation embraces the concept that there exists some optimum set of Requirements and Design that best fit the needs of the user and that this optimum set will be “uncovered” incrementally as the development process proceeds through the iterative paths of the Process Overview Cycle, Process Detail Cycle, and Component Development Cycle – even as late in the process as the Service Assembly and System Integration cycles, with the last chance being the User Acceptance Test.
There is no “Test Cycle” in the DPAC model; test is a step of each cycle in the Check Phase of the PDCA paradigm (continuous testing).
This model is adaptable to product development, new database applications, system “conversions,” Management Information Systems (MIS), or workflow applications. It can be scaled down to small team and agile operations, “parceled out” to subcontractors working in a specific stage, or replicated over multiple locations of complex development activities. Use of this model greatly facilitates the management of multiple projects at higher administrative levels.
Any set of standards or controls can be applied within this framework. It can also be used in production environments, and can help in the achievement of compliance with Capacity Maturity Model Integration (CMMI) requirements. The model does not in any way change the need for a Software Quality Assurance Plan, a Configuration Management Plan, and thorough test protocols (scripts).
The activity cycles in this model do not correspond to method cycles such as a “sprint” nor does the ACT step correspond to daily stand-up meetings or a “scrum.”
This model describes the recursive path of single units of code from concept to requirements, to components, to a completed, integrated delivered system.
Paradigms as a Hindrance to Understanding
The labels and milestones in this model are not written in stone. However, the core concepts of Plan, Do, Check, and Act (PDCA) are the overriding guidance for what to do during each cycle, and in what order.
The objective of this model is to control the quality of the development effort.
Summation
As a management tool, DPAC allows the combined efforts of the CAB and the development team to control change, to prevent “requirements creep,” to halt runaway development efforts, and to track progress of each Component of code. It provides the means to measure the impact of changes to requirements or design before the construction of code. As a software quality engineering tool, it provides a framework for the implementation of standards, guidelines, and procedures. It also serves to ensure the quality of the software, and to ensure uniform presentation in each stage of the development effort.