Great query! Here is my response.
#1 - Analysis - Objective: Looking at and understanding the opportunity to be addressed or solved. Defining the bounds of the opportunity. The potential inputs and desired outputs. Analysis ends with an opportunity document. That opportunity document should define the legal and technical bounds of the opportunity and point out any legislative, regulatory, or technical hurdles.
#2 - Design - Takes as an input the results of analysis; an opportunity document. Developing using agile design principles the team creates a wire model that describes the solution to be built. What specifically goes in. What specifically comes out. The design defines what processes should be used. What the major components of the solution should look like. Again, in agile the design defines the building blocks that will be assigned to various teams to be developed. An important security component of the design is classifying the information used throughout. Basic test plans are documented.
#3 -Implementation - Teams work through sprints to build and integrate the component pieces of the solution defined by the design. What needs to be coded versus what s available from a library? An important security step here is to identify common modules or functions; make sure that they work correctly; and then use (call) that same code from different modules. Testing is planned and executed on each module and function during each sprint. Documentation that describes the product and it's use is developed.
#4 - Quality Assurance - Does the product as built fulfill the design objectives? Have the technical and legal 'guardrails' described in analysis been addressed? What testing is needed to release to deployment?
#5 - Deployment - The deployment phase begins with decisions about Continuous Development (alpha, beta,...) and Continuous Deployment (versioning). When and who will be included in alpha and beta testing? How will users be trained? Criteria for going 'to production' are finalized. The product documentation is shared with the user community and perfected.
#6 - Maintenance - Perhaps the most important part of maintenance is deciding what feedback qualifies as something that can be fixed in the current design and what feedback falls outside of the current design. Things that can be fixed flow back to the developers and are addressed in future versions. Design issues go back to the designers to be examined for future major versions or new products. All the while maintenance issues are triaged so that security issues are pushed to the top of the queue to be seen and responded to by developers.
