now, our next element of secure software design is to figure out which type of methodology we're gonna work with.
Ah, we have the waterfall, which is a very traditional means. It's very much phase based, its unit directional. Ah, 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 and face forth and 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 it'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. Hopes I get 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
they use 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 you 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 problems.
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.
Ah, 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 upfront, 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 going to change.
So those are the pros and cons of agile. Each of thes 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 that in prototyping gives me that immediate feedback from the customer.
Ah, 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.