Development Methodologies

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 58 minutes
Video Transcription
Welcome back to CyberRays. It's of course, I'm your instructor, Brad Roads. Let's jump into development methodologies
in this video. We're gonna look at development methodologies, and we're gonna look at the common security test that you do, regardless of the development methodology used.
The first development methodology we're gonna talk about here, created in the 19 seventies, is waterfall. Waterfall is very much like its namesake. It's a cascade of activities or a flow of activities that you do throughout the course of a development. You start with your system requirements, and if you do everything right, you end up with a system in operations. So
this is a very rigid methodology, not a lot of flexibility here. So what does that mean? That means if you create a requirement in system requirements
and it captures what the customer needs incorrectly once you get to the end of operations, you may never validate that actual system because you built it incorrect because of the rigidity off with waterfall model, you can see it. There's very few places where you can go actually
back and change or fix something along the way
on that is one of the downfalls of this model.
The next model we're gonna talk about is the systems Engineering V. It was developed in the 19 eighties, and the idea here was to get a system into operations and maintenance from the beginning of a concept of operations. So you've probably seen and heard those terms previously and what we've talked about and do verification and validation. Uh, this is also a very linear type project
project methodology, your development methodology.
When you get from concept of operations into implementation, you don't have a lot of flexibility to make changes along the way. Although, although, because you see the the arrow there, when we're looking at requirements, architecture and you're doing that verification and validation,
you actually might actually stop the development here and go back and fix something. Obviously, that's very expensive from a cost perspective,
but at least you can do it. Whereas in waterfall you couldn't.
The third methodology we're gonna talk about is is spiral and Spiral introduced, Ah, construct here in the 19 nineties of prototyping. And so the idea here was instead of what we see with with the the Engineering V, the system engineering V on waterfall, we actually now
developed test capabilities that we try out before we actually put them into operations. This was a novel approach. This allowed us to actually go through an editor of Process and look at the risk along the way with different prototypes, as opposed to trying to do that all at the end when we were doing testing and say, the systems engineering fear waterfall.
So a much more flexible process but still
still somewhat linear in execution. But better.
The fourth methodology is scaled, agile or scaled agile framework. This is a methodology that is used to develop very complex systems and actually develop them in a shorter time frame. So the idea here, pulling in the idea of the prototyping from spiral
agile development operates in 2 to 3 weeks spins or
activity cycles, where
capability is created and put into the hands of the user for checking, testing and use. So this is very different, so and unique, t scaled, agile and to the agile methodology here. We actually integrate the users Aziz product owners, to actually help influence how we develop the system. So this is a very flexible methodology.
It is. It is not just used for systems engineering software entering that engineering and that kind of thing.
Thus the scaled, agile methodology, the agile methodology. It can be applied to different industry verticals, which is unique. It is very, very complex, and it requires a lot of trying to execute correctly and what we see a lot of the times is organizations say their agile, but they're actually doing waterfall and slapping some agile stuff into it. So
you have to be really careful and understand that these methodologies
aren't necessarily always what they seem. And sometimes they're applied incorrectly. If you were to do true, agile, you would be very, very flexible in your development and potentially much faster than the other methodologies we talked about previously.
So as an ISI, there are things that you are going to do. No matter which methodology is chosen for the organization you support, you're gonna do risk assessments. That's a given. You have to be able to understand the risk of the systems being developed. You're gonna help the security folks conduct vulnerability assessment you're gonna look at.
Could a system be exploited based on the way it's designed?
Audit and compliance, obviously, Right. If there's regulations, laws. That kind of thing is, is that is our job to figure out One of my favorite things to do is an ISI. Is the trade studies where? And we're gonna talk about trade studies in detail, so you have a good idea what it is. But that's where we look at the ability of technical and non technical solutions to solve problems.
I will tell you as an ISI, sometimes we have to come back and say, You know what? That really great piece of technology isn't the best way to solve the problem.
We could simply solve that with a a process or a policy or or something in the non technical realm.
Um, and one of the other things we do is this Eases. We helped to write the testing requirements for these very complex systems that is truly systems engineering work. In fact, in my experience as a systems engineer over the years,
I will tell you that I have written a lot of test requirements, whether it's for the own, the systems I was helping to develop or somebody else was developing so that they could be tested accurately
and fully to ensure that they were going to operate securely.
So in this lesson, we covered development methodologies. We're gonna circle back and see those again. And I guarantee you, if you're studying for is it those are important things to know. And then we talked about the common security task that an ISI does in support of development methodologies.
We'll see you next time.
Up Next