0:00 1:42

Let's talk about the system development lifecycle. would figure out the best solution and then throw that
0:04 over the wall to some other coding team
Any computer information system can take a bit of effort 1:47
to develop and so it's a smart thing to break it down into and blah blah blah blah down the pipe it would go.
distinct phases. 1:51
0:16 Big systems takea year and a half, two years, three
For example, there is the analysis phase where you talk years to develop and by the time you're done
to customers and find out what the problem is -- what 1:58
they need. what you've built doesn't look anything like what anyone
0:24 wanted. So we realized we needed to
There's the design phase where you take that 2:04
information and you design an answer to the question, a chunk this up, to break it up into smaller chunks.
solution to the problem. 2:08
0:32 More importantly we needed to think about this whole
There's the build phase where you construct the system, process
and the deployment phase where you hand it back to the 2:13
customer, and finally the as a cycle. It's something you do over and over again.
0:42 2:18
support phase where you help them use it to the best In fact if you break the system down into a small enough
advantage. peice, you can take just a subset of the features,
0:47 completely analyze what they
Each of these phases requires a different kind of 2:27
thinking, a different kind of work, different activities, even need to, design a great set of features, build them, and
different ways of communicating. show them to the customer in just a couple weeks or
0:57 maybe a month.
In the analysis phase you are talking to the customer in 2:35
their language. That way they can tell you right away, "Yes, that's the
1:01 system we want."
In the design phase you're talking to other technologists 2:40
in their language. In the support phase you have to Do this a couple times and pretty soon you've got
respond to every interrupt, enough functionality that the customer's ready to go.
1:11 2:46
to every new problem that comes along. In the design This is called an iterative process. The kinds of activities
phase that just messes up your train of thought. you do in the cycle whether it's the old fashioned long
1:20 cycle
So it's good to break the system development process 2:56
down into phases. or one of these new cycles, the activities are the same.
1:24 So let's take a look at each one of those phases.
We used to think that these happened one after the 3:03
other, kind of like a waterfall, where you would sit down First of all
and you would analyze 3:04
1:33 usually there's an existing system. Even if it's just paper
everything that needed to be analyzed and you'd throw and pencil there's something that the customer does
the resulting set of documents over the wall to some sort today.
of design team and then they 3:13
There's some software that they use today that they use that you create in the analysis phase are for
to do their job, to do whatever it is they want you to do communicating between your team and the customer.
better. 4:49
3:20 Once you've got that solid, you go on to the design
So, listen to what they say about the old system: what phase. This is where your you've got a pretty good
works, what doesn't. handle on the problem, now you
3:26 4:57
Everything in this cycle is designed to take what the want to think about: What's the solution? Where the
customer says to you and turn it into range of different solutions? Some of them might be
3:32 expensive, some of them might take a
something of value for the customer. It's all about the 5:05
customer here. long time, some of them might be very cheap. You look
3:36 at all of the spectrum of: What can we do for this
We go to the next phase, the analysis phase, and there person?
you go deep into understanding the customer's 5:11
perspective -- What can we use? What technologies are available to
3:47 us? What other products can we buy that might do the
understanding what do they need, what pain are they same job?
feeling -- what's the problem. 5:19
3:51 Again, you produce documents and diagrams and that
You can do more interviews. sort of thing but in this phase you also start prototyping.
3:54 Early on you can even use
They'll tell you exactly what they want. Sometimes what 5:27
they tell you they want isn't really what they need so it's little bits of paper and show the customer, "Ok,
useful to go on ride you'll have a screen like this, and then it'll do
4:04 something else. What do you think?"
alongs, to actually do their job with them, and observe 5:33
them doing what they do. As you go along, the prototypes get more sophisticated.
4:09 You go to wire frames, mockups, and things like that.
If you've got all large customer base you can do surveys. You might even write code
There's all sorts of ways of finding 5:42
4:17 to show them this is how it will actually feel,
out: what does the customer need? How does the 5:45
customer think about it? code you might end up throwing away. The important
4:21 thing is: as you do your design, get feedback
In this phase you create diagrams and documents and 5:51
they're all in the customer's from your customer. The stuff you produce is for your
4:28 team, for the design team.
language. If they call some things with particular names, 5:57
you use those names. Some design teams are scattered all across the globe
4:34 and they have members that
You may not use those names inside the system or write 6:03
your software with those names but the documents and speak all sorts of different languages.
diagrams 6:06
4:44 So the language you see in design documents is very
structured. Later on in the course we will
6:12 But at this stage you want to avoid what they call
show stuff called pseudo code. We'll always have premature optimization:
different diagramming techniques. 7:42
6:18 trying to make it
Design documents are important 7:44
6:22 too focused before it works for what you are trying to
for communication. accomplish.
6:24 7:50
They're not to be any more important than that. If they Now when you're ready to deploy, it's a different story.
don't communicate, they're not any good Some folks 7:53
move very quickly through the You're gonna put it in the hands of customers and then it
6:34 does have to be fast, it does have to scale up.
design document phase and actually move right to the 8:00
code. Especially if you've broken it down into a tiny piece When you deploy an IT system,
you don't do a lot of 8:05
6:42 it's called rolling it out. You give it to some customers,
documenting -- you just get to the code. You make sure then you give it to more customers, then you scale up
everybody understands what needs to be built 8:13
6:46 your operation as you take on more and more
and you build it. customers.
6:48 8:16
This is production code. This is code that works, that's Two things are very important: One, if you're replacing
reliable, that's well tested. an existing system with a new system, you have to make
6:54 sure
It also might be other products from other companies or 8:24
other people if you're using open source. It might be you don't disrupt people's jobs.
other services. You might 8:26
7:04 They have to be able switch cleanly from one to the
use Google for your search engine, for example, instead other. Second, as you're ramping up from the early
of buying one. Goodness, no one ever adopters to a wider audience,
7:10 8:35
writes that stuff anymore unless they're in that line of you have to make sure that you don't mess up your
work. current customers.
7:13 8:39
The important thing in this phase is to build something If you add 1000 more customers and the system dies,
that works, something that the customer can use, and is that's not good. You have to scale up intelligently.
reliable. 8:45
7:22 Rolling out systems is a very interesting discipline.
Don't worry about making it fast, don't worry about 8:51
making it scale up to a million people, until you've got it Finally you are in this wonderful situation again where
working. you've got real people using your system
7:29 8:57
Knowing that it has to scale to a million people will and you can actually learn so much in the support
influence your design. It'll change your architecture. environment.
7:36 9:01
Some people think that the job's over at this point but no. At this point you show them what you think you know
In fact the job is just in its 10:41
9:09 and they tell you whether you are the right track.
richest phase when you've got real people using your 10:44
product. Do document reviews, follow-up interviews, whenever
9:14 you can do
Strangely enough, people will ask you for new stuff but 10:48
they won't like it when you give it to them. People don't to get a little bit of their time and get the feedback. In the
like change if it leads to design phase,
9:24 10:54
more work. Who would? If you've done your analysis you may not have running code yet so you can't actually
correctly and you've built the system and you've gotten test it against a test framework but you can use those
your feedback prototypes. You can show
9:32 11:03
from the customer, you know it's the right system. Help them to the customer. You can show mockups and say,
them over that little barrier through training, "OK here's the first screen, here is the second screen, is
9:37 what you want?"
through close support: talking to them, calling them up, 11:10
making sure they're happy. As you get closer to real code, you can actually show
9:43 them working code and you can run
Separate any kind of first impressions they might have 11:18
just because it's different from what really might be a programmatic tests. There's a very interesting trend
problem. If you've done your going on in
9:50 11:23
homework well, you'll find that people are very happy software development called
with the new system after a little use. Some of them take 11:28
to it right away. executable specifications using a language called
10:00 Gherkin and a tool called Cucumber. But we'll
Each one of these faces includes testing. 11:35
10:04 deal with that later when we talk about programming
The kind of testing you do to make sure that you're doing 11:39
it right When you actually building,
10:09 11:41
is different in each phase. Let's go around the circle you've got code now. Its production code. It's ready for
again and talk about how you check your understanding someone to actually use it and try it.
at each level. 11:47
10:16 You can use something called alpha testing.
In the analysis phase, again, you've got those 11:50
documents. In our course, when we're working on That's where you take the other people on your team
websites we'll show mockups, 11:53
10:26 and select customers, put them all under nondisclosure
we'll talk about behaviors. When we do databases we agreement
will show the business rules and 11:58
10:33 and actually give them the code - have them use it.
entity relationship diagrams and we'll show the schema. 12:02
10:37
You have to be careful here. You must always give 13:34
customers and they built something that shared photographs. Very
12:07 successful.
what you are prepared to release. Don't show them half- 13:39
finished work. Don't show them first drafts So be prepared to listen to your customers and be
12:15 prepared to change your plans if that's what you need to
because they might actually say, "That's good! Let's ship do.
that." 13:48
12:21 Finally, you're back in this wonderful state where you've
Then you're done. You'd better have code that you're got real customers using your system. Now you have
ready to deploy. real data. Your product itself can
12:25 13:59
In the next phase, in deployment, you start to roll it out to tell you: they clicked on this, they clicked on this, and
a larger and larger set of they said that was good,
12:31 14:05
customer. This is called beta testing. Its outside the they bought this, they produced that.... You can find out
team. what the customer really does in real time
12:35 14:12
You give it to a kind of person called an early adopter. and there's nothing like real data to help you understand
These are people who love risk, love 14:16
12:41 how the product is succeeding or failing and what you
having the latest and greatest things. What they give you need to do in the next iteration.
12:44 14:22
is information and usually you give them the product. There's a special form of this called A/B testing where
12:49 you actually deploy two different
It's a nice trade. But you have to be careful at this point 14:29
because versions of the same page, for example, and you see
12:54 which one works better
you may get feedback you're not prepared for. You may 14:34
hear from your customers, "That's a great product, but which one does the customer end up succeeding with or
you know what I'd really which one causes them to actually buy something?
13:04 14:42
rather have? I'd rather have a product that does this This is great for finding out the details of "What should
other thing." we do next?" It's not so good about finding out the
13:08 strategic
For example, there's a photo sharing site called flickr. 14:51
13:13 decisions you have to make.
When they started out it was something else. When they 14:53
did their initial testing their This kind of testing will never tell you
13:23 14:56
customers said, "Well, I don't really need THAT thing, should I produce an iPhone or some other breakthrough
but I love how easy it is to share these photographs. product.
13:28 15:00
Can I just use it to share photos with my friends?" But it's great for optimizing an existing product.
13:32 15:07
And they changed
So we got through the five phases of the system 16:36
development lifecycle. with our current budget? our people?
15:14 16:39
You may have seen that I've left out planning until this Each time you look at it and you have to make that hard
part of the presentation. decision: should we continue with the project? Don't wait
15:20 until you're way down
That's because planning 16:48
15:22 the road before you cancel a project and waste a lot of
is part of every phase. It fits in between every phase of money and time.
the project 16:52
15:28 Planning happens in every phase.
and it's done over and over again. 16:56
15:33 Why?
For example: 16:58
15:35 Because planning reduces uncertainty. When you start a
you've got data from your customers from the existing project, you can estimate all you like but you don't have
system and they've said, this doesn't a lot of information.
15:41 17:08
work, this works. They've filed change requests or bug You could be off by a factor of 10. Your budgets or
reports. schedules, they can all be so far off
15:45 17:15
You get a few people together, you give them a little bit that they're just misleading. Sometimes you have to
of money for budget and you ask the question: finish something within a certain amount of time.
15:50 Sometimes there's a market window.
Is there really a project here? Is this is something we 17:24
should do? Is there a market for this? You do your best. But planting reduces uncertainty and
15:55 in that way it reduces risk.
and you do a little bit of planning. You know a little bit 17:32
about the system; you plan the next phase. You go The other thing that planning does for you is it balances
through and you do your analysis what some people call the iron triangle.
16:03 17:38
and you'll understand the problem in greater depth. This is the set of time,
16:06 17:41
Now you go back to planning and you decide, well, now money (or resources), and features.
we know about the problem; let's plan what it'll take to do 17:45
a solution. You may have heard that expression, "I can give it to
16:15 you fast, I can to give it to you good, or I can give it to
and similarly, every time you go through a phase you you cheap."
replan. Its called a stage-gate system. 17:52
16:23 Pick two.
So you go through your analysis, you sit back and you 17:54
say, OK, how long this is gonna take us, what will it With that means is:
take... Are we gonna succeed or 17:56
16:30 If you have a certain set of features that you have to
not? You go through the design, you find out: Is this deliver, (It has to do this, that or thie other thing.)
technically feasible? Can we do this 18:02
Effort takes time, effort takes resources. A project manager i s the kind of person who can deal
18:08 with complexity, helps getting people together, and
You can sometimes getting the job done with a team.
18:10 19:42
throw more resources at a problem and have it happen It's a fun job. It can be tough but it's a fun job.
faster, 19:45
18:15 group to group and Purdue and
That's tricky, though. 19:48
18:17 The important thing to remember
What you can also do is you can say: "Well, we don't 19:51
need that and we don't need that, so let's take those is that
features off the table. 19:52
18:24 every time you update the plan, it's still wrong. It still is
Now, how much money does it take and how many inaccurate. General Dwight D.
months will it take?" 20:00
18:29 Eisenhower said that plans are nothing but planning is
Each time, that balancing factor of time and money and everything.
feature set is exactly what the people who do project 20:06
planning help you with. This is the guy that was in charge of the Normandy
18:40 invasion in WWII -- a gigantic undertaking. This is a guy
It can be a difficult conversation to have and there are in his presidential
some people are very good at it. 20:15
18:46 administration they built the interstate highway system --
These are called project managers. You might enjoy giant projects.
being a project manager if you are the kind of person 20:20
18:52 You'll get people who want you to start out with a plan
who really understands technology, can learn all sorts of and a stick to that plan all the way through the whole
new stuff from different disciplines, cycle.
18:57 20:28
('cause you usually work in a team of different kinds of As much as I would like to say that's possible, it really
people who in all of those phases) isn't.
19:03 20:33
but what you really enjoy it is helping a team do amazing Learned from each thing you do and update your plan
things every time and you'll ship faster than what someone who
19:08 doesn't.
against the odds. I mean, it is very unusual for software 20:42
project to come in on time and under budget. That's about all I can say.
19:17 20:44
A lot of software projects simply fail. So let's summarize the system development lifecycle.
19:21 There these phases: analysis, design, build, deploy, and
They're just difficult and when we talk about support.
programming later in the course you'll find out 20:54
19:27 They have individual tasks for each one: First,
why programming is difficult, why software is difficult. understand the problem and then understand the
19:30 solution.
21:02
You build a solution, then scale it up and deliver it. In
support you help the customer and you listen to them.
21:10
Each of these phases has unique kinds of outcomes or
deliverables: user documents
21:16
things that are in the user's voice, technical documents
and prototypes.
21:21
Eventually you get to the point where you've got a
functioning
21:24
system and you can hand that to customers. The
ultimate goal of this thing is to have people who are
enjoying themselves, who
21:32
can work a little bit less than they could in the last
system,
21:35
who are delighted and happy that you helped them out.
21:39
Remember: all the way along the line there's planning. In
between the analysis and the design phase,
21:44
in between the design phase and the build phase, in
between blah blah blah..in between every phase in the
next you go back and plan.