-: The software development life cycle.
So when we talk about the software development life cycle
or the SDLC, this is what we're going to talk about
as all of the different phases as you take a product
from an idea, to execution, to being out in the real world.
Now software development doesn't always follow
formal models, sometimes it's done more adhoc,
but there are some formal models
that we're going to talk about as we go through
the next couple lessons.
There's many different forms of the SDLC,
but they all share about eight basic functions or phases.
Now, the software development life cycle
can also be used for application development, services,
software, systems, or anything else that you really want
to build because it is just a standard type of project
management type of framework, but it was developed
for software specifically, but it can be adapted
to anything else.
Now you want to plan for security early on in the process
because by building it into the planning
and the requirements, it's going to be able to be
put in early and it's going to be a lot more secure
than waiting until you have a finished product
and then trying to slap security on it at the end
and it comes in an actual cheaper price if you do it
earlier on because adding security early is much cheaper
than trying to patch it later on.
Now those eight phases I talked about, or eight functions,
are here on the screen.
You can see there's planning, there's requirements,
design, coding, testing, training and transition,
operations and maintenance, and then end of life.
We're going to talk about each of those in this lesson
a little bit more.
So the first one we have is planning and planning is
your initial investitgations into the effort conducted.
So you're going to start determining
the feasibility of conducting or designing
this piece of software.
Is this software going to be able to serve
the needs you have?
What's the cost going to be like?
And are there any alternate solutions?
Now the way we look at alternate solutions
is is there something in the marketplace
that already exists or should we be building it ourself?
So if I'm dealing with an in-house problem,
like for instance, we want to build an accounting system.
Well, do we need to code that and design it ourself
or is there something like QuickBooks that can equally
perform the functions we want?
If there is, it may be cheaper to buy something
off the shelf or something from a third party
instead of developing it yourself, or you might be able
to buy pieces and parts and put them together
to make the overall system you want.
Now the end result here is either decision to move forward
or say nope, we're just going to go ahead
and buy that off-the-shelf QuickBooks product
and not build our own accounting software
in our example, right?
And so we'll make that decision and then we'll move on
to the next phase, which is requirements.
Now once you've planned and decided that it is feasible
for you to develop your own piece of software
and you have a good, high level understanding of what
the cost is, now you can start building those requirements.
This is where you're going to gain stakeholder
and customer input into the process.
They're going to tell you what
the required functionality is.
So we're going to go back to my example
of building an accounting software.
Maybe there's one of the things I need to be able to do
is track our income and our expenses.
That's one function that the customer or stakeholder
is going to give you.
There may be another one that may be able
to produce reports, showing what those things are.
There may be another one where you have to be able to do
automatic acceptance of payments through credit cards
or writing out digital checks, essentially,
and putting ACS transfers to pay payroll, right?
All of these things are functions that we may build
into the requirements of this.
Now what should the program do and does your current
program do it?
Well, that's all part of this requirements function.
Now here's really where you as a cyber security analyst
need to get into this.
You need to start putting your security requirements
in early because everything that's a requirement
when you start building this is they need
to get (mumbles) to the next phase,
which is design.
So if you have a requirement that this thing is safe,
that it's secure, that it stores the data
in an encrypted format, that it hashes the passwords,
whatever those requirements are, put them in here.
You are one of the stakeholders as a cyber security
professional and you need to make sure your
required functionality is considered in the design
of this program.
So then we take all of those requirements
and we move into the design phase.
And here's where we're going to start creating
the designs for the functionality, the architecture,
and the integration points, any techniques
we're going to use, data flows, processes,
and other elements.
So we're not actually coding yet, but we're going to take
all those requirements we had.
For instance, we had requirement to store the data
in an encrypted format, right?
That was one of the requirements I gave you.
We now need to develop a process for that, and so we're
going to whiteboard it, we're going to start
flowcharting it, we're going to say here's going to be
the inputs and the outputs.
The input is the raw data, the output is a AES-256
encrypted file, right?
And then what in between those is going to
make it happen and make it work?
This is big block diagrams.
Then we take those and we start moving
into the next phase, which is coding,
and this is where we're actually going to code
all those pieces.
The programmers start writing the code for all
of the software, they start building those requirements,
and conduct the testing of each individual unit of code
through code analysis, all right?
Now we're going to take all those pieces of code
and this is the basic prototype of the software
and we're going to move it into the next phase,
which is testing, and here's where we do some more
formalized testing because the coders
did their own individual testing, but now we're going
to go into a formal method.
And formal testing outside of the development team,
people like shareholders, stakeholders, customers,
beta testers, all of these folks are going to get
their hands on the software.
So if we have this application that we've made
and it does accounting, we now want to give it
to the customer to start trying it out
and figure out what works.
When the customer is happy with it, they give you
the thumbs up.
That's called User Acceptance Testing.
You give it to them and they make sure
all the required functionality is there.
Now the users are probably not going to be
thinking about things like security, so you
as a cyber security professional may get called in
to do some of this as a stakeholder,
some of this formal testing, and see if it meets
your functionality requirements from a security standpoint.
Once we've gone past that, we're going to move
into the next phase, which is training and transition.
So we've got this program, we've gone
through the beta test, everyone's happy.
We want to go start selling it, right?
We want to start putting it into use.
Well, this is where we're going to ensure
the end users are trained on the software
and that they can now accept the software,
install the software, and deploy the software
into the live environment.
So going back to my accounting example.
We've now made all the code work, we've tested the code,
and it's been accepted by the users.
Now we're going to train all of the users across
the staff how to use it and we're going to roll it out
across our enterprise.
Then we're going to move into the next thing,
which is operations and maintenance.
And this is where most things take about 70%
of their life cycle that's spent
in operations and maintenance.
There's actually a very small piece
of the actual development and the testing upfront,
but operations and maintenance is where it is
the longest phase, it's where everything happens.
This is where the daily use of the program happens.
This is where all the calls to your help desk happen,
this is where patching, and updating, and modification
of the program, and all that support is going to occur
and it's very, very, very expensive.
This is why, if you don't start thinking about
security until you get to this phase, it starts getting
very expensive to add it in, so you want it early on
in that requirements phase.
Now we go through this whole life cycle
and we're going to use this program for a long time.
Now once the program is no longer useful,
it's going to reach what's called End of Life.
And when we get to End of Life, this is where
we're going to dispose of and retire the software
and there's a couple of questions you have to think about.
How long are you going to start supporting this software
until you stop?
For example, Windows XP.
It came out in 2001, right?
They supported that up until 2014.
That was 13 years of support that was provided
by Microsoft free of charge to their customers.
That's a really, really long time.
Normally, most software is considered somewhere around
a three to five year life cycle and then they retire it
and they move on.
Now the problem with Windows XP and the reason
why they supported it for so long is their users
didn't want to stop using it because Windows XP
was a good piece of software.
People were happy with it, they were comfortable with it,
and they didn't like Windows Vista.
So a bunch of people didn't migrate up,
including most of their business customers.
They waited until Windows 7.
So once Windows 7 came along, they started migrating
to the new version, and then they were able
to End of Life Windows XP.
You have to have these plans and you want
to think about all this at the beginning
as you're planning out this whole life cycle
of what this software is going to do.
So in summary, what are our eight phases?
Well, planning, requirements, design,
coding, testing, training and transition,
operations and maintenance, and end of life.
Once you go through all eight pieces of this
software development and life cycle,
any other frameworks we're going to talk about
in the next couple of lectures are going to be covered.