Being a CISSP requires a lot of knowledge, which is why these professionals are so highly respected. One way the (ISC)² will test your breadth of knowledge before rewarding you with this designation is with the Common Body of Knowledge (CBK). Among other things, the CBK describes software development models that you must understand.

The CISSP CBK

Let’s begin with the CBK itself. This taxonomy is a collection of topics that security professionals around the world must understand to earn the CISSP designation. Likewise, it’s this kind of understanding that makes a CISSP such a prestigious title all over the globe.

As the name suggests, however, the real purpose of the CBK is to ensure that CISSPs around the world have a common body to refer to when discussing, debating and, most important, attempting to resolve matters that pertain to security.

To further this goal, the CBK is updated annually. The (ISC)² CBK Committee is constantly looking for new topics or pieces of information to add, so CISSPs are always up-to-date on what matters most.

The Role of Software Development Models in the CISSP

Software development models work a lot like recipes. Both give you an outline for creating a specific finished product. Each software development model is a bit different, though, and they are far more general than recipes are. We’ll describe some specific examples in detail in just a moment. The point we’re trying to make here is that software models give you best practices for creating general versions – not step-by-step instructions, as with a recipe.

As you can imagine, modern software isn’t something you want to build by “winging it.” That might work for an experienced cook who has an idea for a new meatloaf. It’s not going to work when you’re building a database intake system for a bank that also needs to uphold security as the utmost priority.

Aside from giving CISSPs guidelines to follow for the kinds of software they intend to create, it also makes it much easier to manage multiple people toward this end goal. Among other things, this allows for bigger projects without correspondingly large chances for errors. Software models can greatly decrease delivery time.

Now that we have this understanding in place, it has probably also become clear why software development models are so important when it comes to the CISSP CBK. To become a CISSP and remain a proficient one, you’ll need to understand the following models.

The Waterfall Model

This approach was originally put forward by Winston W. Royce in 1970, though it’s easy to argue that many people had already been using some version of it in the past. The waterfall approach was also the first analytical and design model for building a system.

Despite how old it is, it’s still very popular and effective. That’s because it’s based on such a logical concept. Every step logically flows from one to the next. CISSPs with lots of employees especially love it because it makes it so much easier to guide numerous employees toward the intended end result.

While you will learn there are different steps involved, depending on whom you speak to, the general idea is easy enough to grasp. As a CISSP, it will be your job to retrofit the outline to the task at hand.

The general outline looks like this:

  • Requirements
  • Design
  • Implementation
  • Verification
  • Maintenance

This was the original version created by Royce. Some modern interpretations split the design phase into “logical” and “physical” sub-phases.

Let’s look at the basics, though, beginning with requirements. You start with these at the beginning of development. You consider your user, first and foremost, and what it is they want. Then you simply decide how to give it to them. Once you know what the user wants, you move onto design.

In this phase, you have:

  • Logical Design
  • Physical Design

During the first sub-phase, system analysts use information from the last phase and design the system without any thought about the hardware or software involved. Once this is done, they will begin transforming this concept into a physical design that has specifications for hardware and software.

Next, there’s implementation. This is when the required code is actually written. When the programmers are finished, you’ve reached verification.

During this phase, you want to make sure that your project is meeting customer expectations. That being said, this step has lost favor in recent times, so you may decide to simply roll it out to customers and move onto maintenance.

In the maintenance phase, customers actually use the developed application. As feedback is given, necessary changes get made.

The Incremental Model

As the name suggests, this model divides the development of a platform into various builds. There will be numerous development cycles, which make this model much like a multi-waterfall cycle.

Each is divided into modules that are smaller still, which makes it much easier for a CISSP to manage (or delegate). Each module consists of four stages:

  • Requirements
  • Design
  • Implementation
  • Testing

During the first module, a working version of the software is created. This gives your team a foundation to build on. Every release following the first adds function to the previous one. These subsequent processes continue until the intended end result is finally achieved.

There are a number of advantages to building software this way. Some examples include:

  • It gives you a working model quickly and early on, which can help inform development in a way you might miss out on with the traditional waterfall approach.
  • Along the same lines, this model tends to be more affordable, as it gives you the flexibility to make changes to scope early on and alter requirements as necessary.
  • Testing and debugging is easier to do with a smaller iteration.
  • Customers can be consulted along the way (basically, the verification process over and over).
  • The initial delivery cost tends to be a lot less.
  • It’s much easier to manage risks because each cycle gives you the opportunity to identify and address them.

As long as you take the time to clearly understand the requirements of your software, the incremental model can be very powerful.

Spiral Model

The spiral model is a lot like the other two, as well. However, this model places much more emphasis on potential risks associated with the build. It has four phases:

  • Planning
  • Risk Analysis
  • Engineering
  • Evaluation

The spirals referred to by this model’s name describe how the project goes through each of these four phases repeatedly with every iteration. The baseline spiral, which starts with the planning phase, introduces the need to establish requirements and assess risks. Subsequent spirals build on the original.

Therefore, in the planning phase, your team is gathering requirements. During the risk analysis phase, you’re trying to identify any risks involved and what kinds of solutions would work best.

You’ll also produce a prototype by the end of this phase. This, again, gives you the opportunity to search out what risks may be threats and to consider possible solutions.

During the engineering phase, software is developed and testing is done. Although you’ve already considered potential risks, that doesn’t mean you won’t find areas where the software is lacking or otherwise needs to be improved.

Next, you bring the prototype in its current form to the customer and receive an evaluation. After you get feedback, you begin at the start of the spiral again and go through each phase.

Again, this model is a lot like the incremental approach, except that there is way more risk analysis involved. This makes it a smart choice for projects that:

  • Have large, mission-critical goals.
  • Come with strong approval and documentation controls.
  • Allow further functionality to be added at another time.
  • Require a working model to be produced ASAP.

When cost and risk evaluation are essential, the spiral software development model is ideal.

Agile Software Development 

This is yet another, more specific version of the incremental model. With this approach, software is released quickly in rapid, successive cycles. As a result, small incremental releases are made, with each building on the functionality produced by the last. However, thorough testing is still involved, so software quality can be maintained.

If you’ve heard of extreme programming (XP), then you know of one of the most popular examples of agile software development.

Agile projects rely on sprints (also referred to as iterations). These short work periods generally last between two weeks and two months. During this time, pre-determined features decide upon during the requirements phase are developed and delivered to the customer.

Most agile software projects will involve multiple iterations. As with the spiral methodology, one of the main benefits of this approach is that you get a working model to the client ASAP. Then you receive their feedback and continue with the next iteration.

Other benefits to using the agile methodology include:

  • Clients generally prefer to be made a part of the process.
  • Daily interactions between departments are required. For example, the developers and the marketing team need to work together to ensure the end user’s needs are going to be met.
  • Changes can generally be made to the software quite easily even in the later stages of development.
  • When a client’s expectation is met for one component of the software (which is confirmed by the client at the end of an iteration), the people formally working on that aspect can shift their attention to another one.

While this is not the best model to use if documentation is going to be important, there’s a reason the agile methodology has become so popular. In fact, it’s used for more than just software development, but for other large, collaborative projects, too.

It’s also very important with this model that you completely understand your requirements before getting started or you’re just going to run around in circles and, quite possibly, frustrate your customer quickly.

CISSP Training – Resources (InfoSec)

Rapid App Development

The rapid app development (RAD) software development model puts a premium on rapid prototyping. Again, you can see how this newer approach flows from the rest. More and more, software developers want prototypes done and out to customers ASAP.

However, with RAD, a prototype is a working model that is equivalent in functionality to a component of the product itself.

In RAD, the functional modules are all developed parallel to one another. They are then integrated to make the final product as fast as possible.

This kind of rapidity is possible because there is no detailed planning involved with RAD. Instead of being reckless, this admission is required because it makes incorporating changes within the development process much easier.

RAD projects leverage the incremental model in many ways, too. Small teams of developers, customer representatives, product experts, and others work together on their designated component.

As long as each prototype is reusable, RAD can provide numerous advantages to CISSP developers. Again, it’s an incredibly fast form of software development. Compared to the waterfall model, you’ll be moving at breakneck speeds.

If the customer changes their requirements, it’s much easier to accommodate when you’re using the RAD model. Progress is also easier to measure because you’re constantly working in such small iterations. Most experienced teams are able to greatly reduce the amount of time spent on each iteration, too. There are countless tools available to help with this, as well.

The degree of integration involved with RAD usually helps solve a lot of issues you might otherwise face when creating prototypes with other models.

Before using RAD, it’s important that your clients are made aware of the nature of this model. They must be onboard with receiving the targeted prototypes within the same timeframes.

You also need highly skilled engineers. That’s why CISSPs are fantastic for this. Their level of experience can greatly reduce the overall development time required because of reusing the components and parallel development.

Understanding the CBK is essential to becoming a CISSP and working as one thereafter. One reason for this is so that you understand software development. The five models we discussed above are absolutely essential for creating platforms in the 21st century.

Sources

http://www.streetdirectory.com/travel_guide/135488/software/software_development_process_and_its_importance.html

http://istqbexamcertification.com/what-is-agile-methodology-examples-when-to-use-it-advantages-and-disadvantages/ 

http://searchsoftwarequality.techtarget.com/definition/waterfall-model

http://www.umsl.edu/~hugheyd/is6840/waterfall.html

http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-when-to-use-it/

What is Spiral model- advantages, disadvantages and when to use it?

Be Safe

Section Guide

Ryan
Fahey

View more articles from Ryan

Earn your CISSP the first time with InfoSec Institute and pass your exam, GUARANTEED!

Section Guide

Ryan
Fahey

View more articles from Ryan