Detailed Notes
This is an overview from one of our SDLC/Agile classes (https://school.develpreneur.com/p/software_development_life_cycle).
You can find out more through our online classes at https://school.develpreneur.com and register for free. Registration will add you to our email list and you will periodically receive coupons for courses as well as notifications of the latest releases.
Transcript Text
thank you [Music] welcome back to building better developers and one of the things that we stress is the idea of strong fundamentals that you build on a foundation that is solid that is one of the things that we found as an issue with some boot camp type approaches or books that you know learn X whatever it happens to be learn C sharp in 24 hours some of those kinds of things they have their place and they can be valuable depending on what your background is but if you're going to become something other than a coder if you're going to become a developer you need to understand the theory and the reasoning behind why things are done the way they are done you have to understand how software is built and why we build it and the way we do and so that brings us to our focus in this lesson we want to talk about sdlc which is the software development life cycle now this is something that is very basic to software development this is not some you know new fangled buzzword thing sdlc has been around for decades we're pushing A Century of this being around in some way form or fashion now granted it wasn't really formalized until all of you know it's pretty new 50 60 years ago something like that but it is a basis for a lot of what we do and so I want to talk about why do you need to know why is it useful even if you can write code for you to have a good solid understanding of sdlc and what it is now I want to step back a little bit and talk about the definition of it because sometimes it's one of those things that we just sort of like software development life cycle might as well be blah blah blah blah blah we don't really think about what it means so sdlc is the best way you can I think picture it in the real world or in a physical creation of a product is an assembly line if you think of an assembly line for an automobile there will be depending on how they do it but you know at some point there's people putting together pieces for the tires and there's somebody putting together or you know teams of people putting together pieces for the chassis and the frame and the the body and then even the internal stuff like the seats and the steering wheel and the stereo and all of those things are pieces that are built with people that are specialists in building that thing because they do it or these days they may be a robot that knows how to build that thing to put it together and then you go along the assembly line and you start putting pieces on this thing and when you get to the end you have an automobile that you can drive away that is what sdlc attempts to model and so there are these steps along the way and just to be clear and reiterate that there's six steps that are part of this DLC the first thing you do is you gather requirements then you design your solution and then you implement it and then you test what you built you deploy it you go put it in front of users and then you maintain it so you do you know bug fixes or updates things like that each of these steps is critical to the entire process of sdlc in this essential piece of it these essential steps there are definitely some things that we need to think about that we need to understand that we need to be comfortable with in order to be good software Developers so you may say I can write code I've built little applications why do I need to know this well one of the things is that each step is important we can easily and this gets pointed out over and over again if you read any articles that are on or you know surveys research done on why is software often struggling to meet you know budget and expectations and Beyond Time and why can't why does quality continue to be a problem why does software projects fail at rates that are not low yeah I think if everybody if software projects failed at like a five percent rate people would be jumping and screaming and throwing parties in the street there'd be parades and everything it's not even close to that it varies depending on who you're talking to but it's typically more like 25 percent to 40 depending on the projects and things like that and when you look at the research on those you often find that there were steps that were skipped or that were not done properly a common one is gathering requirements people just put together a couple things sometimes a couple bullet points say this is what we need to do and then you get into design and then that starts asking questions that point to gaps or holes or complete blind spots in the requirements and then same thing as maybe design isn't done as well and you get into or both requirements and design aren't doing very well you get into implementation and there are questions there are things there where it says hey we can't build this because you haven't specified it or you haven't told us how it's supposed to be done you haven't designed it or you didn't even you know have a requirement that really addresses this piece and it happens all the time so these are software fundamentals if you are building software not writing code you know if you're writing code you can write code for you know a window or whatever it is you don't really care outside of your little function that you're building for your code or your functions you're building for code if you're building an application if you're building software if you're putting these things together you're doing more than writing code and these are fundamental pieces to doing it you need to have requirements and design and Implement you need to test it and then it's got to be deployed and then maintain it so what sdlc gives us and a reason where it's useful for us to even if we are experienced developers go back every so often and think about sdlc and how we are building software looking at that or with a specific project even it helps you sort of assess did you forget something is there something when you looked at the time and the resources spent on your project is there something that's a gap or something that looks like it just there wasn't much there for example let's say you get done with your software and you're looking at all the hours that were done on it and there were let's say you know 10 000 hours done on implementation then you look at testing and there were 10 hours done on testing that should jump out to you that maybe you didn't either didn't track your testing properly or you didn't test properly now it could be that you did a lot of testing and implementation and so you you weren't able to properly address those or account for those hours but it may also be that you were just code code code you were on a deadline so it's just like basically just a rubber stamp you know a few hours of testing boom you're off and running that would be a gap or if you're looking at all that time same project that maybe you spent five hours on requirements maybe that's part of the reason it took you ten thousand hours of implementation because you didn't spend more time in requirements maybe if you'd spent 50 hours in the requirements you would down you know be down to five thousand hours of implementation there's definitely a cost for finding something out you know finding a bug or a hole the further you get into the process now another thing sdlc gives you is a a way it's a like I said it's like a non-specific way to build software so if you've got an approach or a methodology that you're using you can validate essentially your methodology and you can even sort of test the value of your methodology by mapping it back to sdlc if you have an approach if you're using methodology that doesn't design that says no we're not going to worry about design we're just going to go from requirements right into implementation you're probably going to struggle and by probably I would bet a lot of money that you will struggle that you will have issues because that means the designs got to be done somewhere if not then you're almost just like a step above randomly writing code so you want to make sure that all of your steps in sdlc are addressed in whatever the methodology is that you use now along those same lines is you can use sdlc as a way to like troubleshoot or improve your processes because you can go look at those six steps just as we've described here some of the examples you look at those steps and say am I giving it the proper I will say respect am I giving the amount of time am I putting the right kind of resources on that step or to address that step with an SLC now I'm going to get too far into it because we have classes we talk about it there are situations where some methodologies sort of combine some of those things so maybe requirements and design are done more or less at the same time or like for example if you use Rapid application development it's really in a sense you have requirements design and implementation all sort of going on at the same time so you don't see maybe the separate steps however if you step back and look at what is done look at the activities that are done using that methodology you can see where oh here they are doing the work of requirements Gathering here they are doing the work of design here they are doing the work of implementation so while they don't have to be separate steps the work related to this step does have to be there and if you are struggling in building software then maybe one of the things to do is step back and go back to the fundamentals are you following sdlc principles or are you shortcutting something these are the kinds of things that are useful for us to have to become better Developers otherwise as I've sort of mentioned you know you're you're just writing code there's a difference between generating code and building software and you need this fundamental you need this strong Foundation to be able to build software better you need to understand the big picture otherwise you're just writing code thank you for your time [Music] thank you
Transcript Segments
thank you
[Music]
welcome back to building better
developers and one of the things that we
stress is the idea of strong
fundamentals
that you build on a foundation that is
solid that is one of the things that we
found as an issue with some boot camp
type approaches or books that you know
learn X whatever it happens to be learn
C sharp in 24 hours some of those kinds
of things they have their place and they
can be valuable depending on what your
background is but if you're going to
become something other than a coder if
you're going to become a developer
you need to understand the theory and
the reasoning behind why things are done
the way they are done you have to
understand how software is built and why
we build it and the way we do
and so that brings us to our focus in
this lesson we want to talk about sdlc
which is the software development life
cycle
now this is something that is very basic
to software development this is not some
you know new fangled buzzword thing sdlc
has been around for decades
we're pushing A Century of this being
around in some way form or fashion now
granted it wasn't really
formalized until all of you know it's
pretty new 50 60 years ago something
like that
but
it is a basis for a lot of what we do
and so I want to talk about why do you
need to know why is it useful even if
you can write code
for you to have a good solid
understanding of sdlc and what it is
now I want to step back a little bit and
talk about the definition of it because
sometimes it's one of those things that
we just sort of like software
development life cycle might as well be
blah blah blah blah blah we don't really
think about what it means
so sdlc is the best way you can I think
picture it in the real world or in a
physical creation of a product is an
assembly line
if you think of an assembly line for an
automobile
there will be depending on how they do
it but you know at some point there's
people putting together pieces for the
tires and there's somebody putting
together or you know teams of people
putting together pieces for the chassis
and the frame and the the body and then
even the internal stuff like the seats
and the steering wheel and the stereo
and all of those things are pieces that
are built with people that are
specialists in building that thing
because they do it or these days they
may be a robot that knows how to build
that thing to put it together
and then you go along the assembly line
and you start putting pieces on this
thing and when you get to the end
you have an automobile that you can
drive away
that is what sdlc attempts to model
and so there are these steps along the
way
and just to be clear and reiterate that
there's six steps that are part of this
DLC the first thing you do is you gather
requirements
then you design your solution and then
you implement it and then you test what
you built you deploy it you go put it in
front of users and then you maintain it
so you do you know bug fixes or updates
things like that
each of these steps is critical
to the entire process of sdlc
in this essential piece of it these
essential steps there are definitely
some things that we need to think about
that we need to understand that we need
to be comfortable with in order to be
good software Developers
so you may say I can write code I've
built little applications
why do I need to know this
well one of the things is that each step
is important
we can easily and this gets pointed out
over and over again if you read any
articles that are on or you know surveys
research done on why is software
often struggling to meet you know budget
and expectations and Beyond Time and why
can't why does quality continue to be a
problem why does software projects fail
at rates that are not low
yeah I think if everybody if software
projects failed at like a five percent
rate people would be jumping and
screaming and throwing parties in the
street there'd be parades and everything
it's not even close to that it varies
depending on who you're talking to but
it's typically more like 25 percent to
40 depending on the projects and things
like that
and when you look at the research on
those you often find that there were
steps that were skipped
or that were not done properly
a common one is gathering requirements
people just put together a couple things
sometimes a couple bullet points say
this is what we need to do
and then you get into design and then
that starts asking questions that point
to gaps or holes or complete blind spots
in the requirements
and then same thing as maybe design
isn't done as well and you get into or
both requirements and design aren't
doing very well you get into
implementation and there are questions
there are things there where it says hey
we can't build this because you haven't
specified it or you haven't told us how
it's supposed to be done you haven't
designed it or you didn't even you know
have a requirement that really addresses
this piece
and it happens all the time
so these are software fundamentals if
you are building software not writing
code you know if you're writing code you
can write code for you know a window or
whatever it is you don't really care
outside of your little function that
you're building for your code or your
functions you're building for code
if you're building an application if
you're building software if you're
putting these things together you're
doing more than writing code
and these are fundamental pieces to
doing it you need to have requirements
and design and Implement you need to
test it and then it's got to be deployed
and then maintain it
so what sdlc gives us
and a reason where it's useful for us to
even
if we are experienced developers go back
every so often and think about sdlc and
how we are building software
looking at that or with a specific
project even it helps you sort of assess
did you forget something is there
something when you looked at the time
and the resources spent on your project
is there something that's a gap or
something that looks like it just there
wasn't much there
for example let's say you get done with
your software and you're looking at all
the hours that were done on it and there
were let's say you know 10 000 hours
done on implementation
then you look at testing and there were
10 hours done on testing
that should jump out to you that maybe
you didn't either didn't track your
testing properly or you didn't test
properly now it could be that you did a
lot of testing and implementation and so
you you weren't able to properly address
those or account for those hours
but it may also be that you were just
code code code you were on a deadline so
it's just like
basically just a rubber stamp you know a
few hours of testing boom you're off and
running
that would be a gap or
if you're looking at all that time same
project that maybe you spent five hours
on requirements maybe that's part of the
reason it took you ten thousand hours of
implementation because you didn't spend
more time in requirements
maybe if you'd spent 50 hours in the
requirements you would down you know be
down to five thousand hours of
implementation
there's definitely a cost for finding
something out you know finding a bug or
a hole the further you get into the
process
now another thing sdlc gives you is a a
way it's a like I said it's like a
non-specific
way to build software so if you've got
an approach or a methodology that you're
using you can validate essentially your
methodology and you can even sort of
test the
value of your methodology by mapping it
back to sdlc
if you have an approach if you're using
methodology that doesn't design
that says no we're not going to worry
about design we're just going to go from
requirements right into implementation
you're probably going to struggle
and by probably I would bet a lot of
money that you will struggle that you
will have issues
because that means the designs got to be
done somewhere
if not then you're almost just like a
step above randomly writing code
so you want to make sure
that all of your steps in sdlc are
addressed in whatever the methodology is
that you use
now along those same lines is you can
use sdlc as a way to like troubleshoot
or improve your processes because you
can go look at those six steps just as
we've described here some of the
examples you look at those steps and say
am I giving it the proper I will say
respect am I giving the amount of time
am I putting the right kind of resources
on that step or to address that step
with an SLC
now I'm going to get too far into it
because we have classes we talk about it
there are situations where some
methodologies sort of combine some of
those things so maybe requirements and
design are done
more or less at the same time or like
for example if you use Rapid application
development it's really in a sense you
have requirements design and
implementation all sort of going on at
the same time
so you don't see maybe the separate
steps however if you step back and look
at what is done look at the activities
that are done
using that methodology you can see where
oh here they are doing the work of
requirements Gathering here they are
doing the work of design here they are
doing the work of implementation
so while they don't have to be separate
steps the work related to this step does
have to be there
and if you are struggling in building
software then maybe one of the things to
do is step back and go back to the
fundamentals
are you following sdlc principles
or are you shortcutting something
these are the kinds of things that are
useful for us to have to become better
Developers
otherwise as I've sort of mentioned you
know you're you're just writing code
there's a difference between generating
code and building software
and you need this fundamental you need
this strong Foundation to be able to
build software better you need to
understand the big picture otherwise
you're just writing code
thank you for your time
[Music]
thank you