Part 03 - Development Methodologies

Video Activity

In this section we cover the major development methodologies used in software development. We discuss the trade offs of each in terms of flexibility in the face of changing requirements. This is important since one thing that is certain when it comes to developing software is that the customer at some point is going to change their mind about what ...

Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

2 hours 38 minutes
Video Description

In this section we cover the major development methodologies used in software development. We discuss the trade offs of each in terms of flexibility in the face of changing requirements. This is important since one thing that is certain when it comes to developing software is that the customer at some point is going to change their mind about what they want! We outline the development models and then dig into the specifics of each: - Waterfall model - Prototype model - Spiral model - Agile model

Video Transcription
when I was working as a security researcher for the D. O. D. I learned firsthand how difficult it is to effectively trained security personnel between competing vendors, standards, frameworks and policies. It was nearly impossible to manage all of our training needs and wants. There was no system, no gold standard, no process. To solve that problem, we created our newest offering, Sy Berry, for business.
Instead of trying to choose between vendors or standard, our community has created a single clearing house
where the best of all worlds can come together with courses and learning material created by instructors, vendors and experts from around the world. You don't have to worry if you're missing key information because you lost a game of vendor roulette. We don't pick winners and losers. We create a space where content creators and students can come together to fix a broken industry.
You'll get unlimited use of multiple hands on training products from multiple providers. You get the world's largest catalog of video based security training and you get unlimited live online training classes all in one singular catalog, Right on cyber Eri Thanks for being a valued member of cyber Eri
now Our next element of secure software design is to figure out which type of methodology we're gonna work with.
We have the waterfall, which is a very traditional means. It's very much phase based, its unit directional. It's an approach for project management within software development processes that's very much phase by phase. By phase, we also have
prototyping, which I'm sure you're familiar with prototypes.
You build a working model, if you will. The customer provides feedback and you tweak that working model. Get more feedback until eventually you've produced the product the customer wants,
then their spiral, which is kind of a combination of the waterfall and prototyping. And then finally we have agile, which is very, very popular today in the world of frequently changing requirements. So when we look at the waterfall method again, it's very much a phased based approach.
You don't move to face two until you've completed phase one.
Then you move to face three than phase four than face five, and you can see why this is called a waterfall waterfall, because it's kind of this stepping that you would see now. What's important understand is this isn't great for a long term project because we get the requirements right way up here.
And if it's six months a year, five years later, before we're actually producing the code,
well, those requirements have changed many times over. So this is generally good for shorter lived projects. It's not good for very long. So long term
project, just because of the distance between requirements and actually producing the software itself. So the benefits each phase we have very specific, well documented deliver, bols. Um, we complete things. We have to focus on one phase at a time.
This is gonna be good, like I mentioned before with very small projects where we truly understand the requirements there, well documented there, Well understood,
defined before design designed before code. This goes back to the idea of measure once cut twice because I got that exactly backwards. Measure twice. Cut once. There's a Freudian slip in there somehow, but the idea of Let's sit down, let's get our definitions.
Let's design and then we designed before we would code so again that very much that
days based approach, But it's very static in nature doesn't really adjust with requirements that change, and we know that working with customers. Their requirements frequently change. So if we're trying to adjust the scope during the life cycle of the project, that can cause great difficulty,
we don't actually produce the software till late on in the life cycle. So again, are we meeting our goals? We don't determine that till much later on. So again, if we've got this sort of model, we're using its best for short term projects.
Now, with prototyping again, you designed the model to meet the customer's expectations. They evaluated, they give feedback, then we designed. Then we prototype customer evaluates, and you can see kind of that loop of prototyping.
Now, the problem with this, you know, this is good because we get the feedback directly from the user's when we get that early on in the project. So we can work very closely hand in hand with the customer, ideally, to get better requirements and to get a higher quality product.
The downside is, you know, when a customer provides feedback, they may have no idea the ramifications of the feedback that they provide. I wish I had a nickel for every time a customer said. I just want to make this one small little change and that one small little change calls updates of thousands of lines of code.
You know, customers often don't understand, so
they want to make a small change, and it has this great expense in this great time associated with it. Often they don't understand
now. A combination of waterfall remember the waterfall was stepping. Prototyping is revolving sort of circular in nature. So if we take the steps of the waterfall and the circular nature of prototyping, we get what we call the spiral model.
So at the end of each phase in the spiral model
will produce a prototype that we get feedback on now. This could be quite costly to use, and it puts a lot of emphasis on early on risk analysis, making sure we understand what the risks are, and this takes a lot of expertise to pull off successfully.
The software development process, though, that most of us here about especially the day is called agile. That goes through brainstorming, designing, development, que a deployment.
But the important thing about agile is it's very, very flexible in nature, and it's going to allow for requirements to change throughout because we've got this piece where we're gonna allow feedback from the customer. We're gonna use small teams in order to produce certain pieces of functionality.
So there are a lot of benefits to using agile today.
Usually we look at this is producing fewer defects and great flexibility. We get immediate feedback
now, the cons there's less documentation created. And I know we could look at that as a pro. You know, yea, big benefit of having less documentation. But it's harder to track, um, less control with configuration management less focus on design up front, and it's a little bit more
focus on winging it. I hate to say that because it's not really a cross your fingers and let's hope it works model. But it is designed with that flexibility that we don't spend all that time up front with requirements and design because we know that they're gonna change. So those are the pros and cons of agile.
Each of these development methodologies have their benefits. The waterfall is much more traditional.
It's good for short term projects where we don't expect the requirements to change. Prototyping gives me that immediate feedback from the customer.
Uh, the spiral mechanism can give me a combination of waterfall and prototyping. So I get the benefits there. But it could be could be very expensive and add to the workload, just providing that prototype and feedback and going back into the
the things and reproducing the prototype it it could be very costly. And then we have agile. That gives us a lot of flexibility but also reduces the amount of documentation in the formalization of design. So pros and cons for all of these,
the type of software to be produced and what the requirements are
is gonna drive which methodology use.
Up Next
Security Operations

They are responsible for knowing where a network's possible vulnerabilities are and providing mitigation strategies to combat them. An effective Cyber Security Operations Manager will have experience in a technical security role including ...

Instructed By