We're going to move into Section Two now in which we're going to talk about enforcing security controls in the development environment. In this particular module we're going to talk about various development methods, some database models, how we can get to the databases through the internet. We'll talk about web application development and various forms of malicious software including weaknesses and vulnerabilities at the source code level. Configuration management is an aspect of secure coding, code repositories and the security of APIs.

Probably the oldest development model is the Waterfall. It has a lot of variants that have been developed since. But, what characterizes the Waterfall and its variants is that each phase contains a list of activities that must be performed and documented before the phase begins. Now, the importance of this particular point is there's a lot of rigor in how the process is formed and it places great importance on the documentation and that everything follows the documentation. Each method follows a form of rigorous sequencing of tasks in a finish-to-start project management sort of form.

The methods are adequate for long term, long duration projects, but tend to respond very poorly to changes and the variability that might take place over the long period that the program is developing. We have the Structured Programming Development. There you see the graphic that illustrates that, where one thing leads to another in a very rigorous formed pathway.

A variant of the Waterfall was the Spiral, which attempted to use the same logic of finish-to-start in the steps, but to speed things up, as it spiraled out from its point by producing a new prototype at each turn on the spiral.

And then we had the Cleanroom. This was a technique that was favored by NASA and the military for many years because it started with a clean sheet of paper, so to speak, with each project that was being initiated. Unfortunately, the Cleanroom learned only from things that happened within the particular flow of a particular project, but it didn't tend to bring things from one project into another except rarely in the form of techniques.

We have the V Model, which is an extension of the Waterfall and is based on the association of a testing phase for each corresponding phase in the development cycle. Now as you see by the diagram, we have down the left-hand side of the V requirements analysis, system design, architecture design, module design, leading at the bottom of the V to coding. On the right-hand side as we go up, we have unit testing, integration, system testing, and acceptance testing. In the valley of the V there is, from the bottom to the top, unit testing, integration testing design, system test design and acceptance test design, with arrows pointing to each leg of the V. It means that for each single phase in the development cycle there is a directly associated testing phase. This is a highly disciplined model and the next phase starts only after completion of the previous phase. So again, it emphasizes the finish-to-start project management style.

Now, the corresponding testing phase of the development phase is planned in parallel. So, marking a line from, at the top, requirements analysis through acceptance test design to acceptance testing, there is a line that goes directly across the top. So, there is a verification phase on one side of the V and validation phases on the other side. The coding phase joins the two side of the V Model. So, as rigorous as this is, it doesn't respond very well to change. Now the V Model, like all of these models, has some pros and some cons. The advantage is that it's highly disciplined and phases are completed sequentially. Now that can bring certain benefits. Unfortunately, it does tend to make things a little bit longer in the process. It works well for smaller projects where requirements are very well understood. It is simple and easy to understand and use. It's easy to manage due to the rigidity of the model with each phase having specific deliverables and a review process. Verification and validation activities are included in each step on each leg of the V. However, these very strengths lead to certain disadvantages. It tends to make the model very inflexible with a very high cost associated with change. There's high risk and uncertainty brought about by any change that is introduced. It is not a good model for complex or object-oriented projects. And it's a poor model for long or on-going. Furthermore, it is not suitable for projects where requirements are at a moderate to high level of risk of changing and once the application is in the testing phase, it is very difficult to go back and change a functionality, meaning a very high cost in break fix or modification. And no working software is produced until very late in the life cycle.

Now, to overcome those kinds of disadvantages, iterative development techniques were developed beginning with prototyping or modified prototyping models, a rapid application development, joint analysis development and then, exploratory models. And most of these iterative development types, they're based around the notion of putting together something very quickly as a proof of concept and then once the proof of concept demonstrates that the idea is sound and that the basics are good, it continues to evolve and produce additional prototypes until the final prototype is production ready. 

There are of course, other models and methods. We have Computer-Aided Software Engineering. We have Component-Based Development, one of the precursors of object-oriented. We have the Reuse Model, also another precursor to object-oriented. And then, Extreme Programming, which is a program predecessor to the Agile Method. And speaking of Agile, here we have Agile software development which is an approach to software development under which requirements and solutions evolve through collaborative effort of self-organizing and cross-functional teams and their customer end users.

Agile is known for being exactly what the name indicates, one that adapts very well to change and in fact, change is more the norm than an exception. It advocates adaptive planning. In other words, things are not set in stone. It evolves and the development follows a path of evolution. It believes in early delivery and continual improvement of the process. Agile encourages, as the name suggests, rapid and flexible response to change and here we have the six basic steps: requirements, planning, design, development, release and then track and monitor.

Now, along with Agile, said almost in the same breath most times, is the Scrum Methodology. Now, Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products. As you see by the diagram, one of the things that Scrum emphasizes is regular and very short term deliveries. It takes the scientific method of empiricism, in other words, learning from experience, and implements that into software so that as it moves forward in its short cycles of sprints it learns as it goes and adapts as it goes, very much a contrast to older methods. Consequently, Scrum replaces a programmed algorithmic approach from the earliest methods with a more heuristic one to deal with unpredictability and solving unpredictable, complex problems.

Another methodology that is in close association with Agile and Scrum is the evolving DevOps and more recently, the DevSecOps. Now, DevOps itself is an operational philosophy that promotes better communication and collaboration between the teams, development, operations and application delivery, and also reaching out to others in the organization. The idea being that as this is adopted and evolves it leads to better integrations of these teams. Now, the tools include continuous integration and quality assessment. It produces a continuous delivery and deployment methodology and that becomes the psychology of these teams with an emphasis on substantial task automation.

Now, DevSecOps takes this one step further and involves security in the picture as early in the cycle as possible so that the development, operations, application, delivery and security teams become more and more tightly integrated. Again, it emphasizes improved integration and automation. And that brings us to the end of our first module of the software development security domain, domain eight of the CISSP exam review and preparation seminar. Be sure to join us for the next module where we're going to begin with the database environment. Thank you.