48 lines
1.1 KiB
Plaintext
48 lines
1.1 KiB
Plaintext
1
|
|
00:00:00,080 --> 00:00:02,980
|
|
This is the context in which, typically, a pure
|
|
|
|
2
|
|
00:00:02,980 --> 00:00:06,310
|
|
waterfall process will work well. Why? Well, because it's a
|
|
|
|
3
|
|
00:00:06,310 --> 00:00:10,160
|
|
context in which requirements are usually well understood. The
|
|
|
|
4
|
|
00:00:10,160 --> 00:00:13,020
|
|
domain is well understood, so that kind of system has
|
|
|
|
5
|
|
00:00:13,020 --> 00:00:15,900
|
|
been built many times before. And also, it's a
|
|
|
|
6
|
|
00:00:15,900 --> 00:00:19,510
|
|
system in which we don't expect requirements to change dramatically
|
|
|
|
7
|
|
00:00:19,510 --> 00:00:23,180
|
|
over time. Therefore, a waterfall model, in which we collect
|
|
|
|
8
|
|
00:00:23,180 --> 00:00:25,140
|
|
all the requirements at the beginning and then we move
|
|
|
|
9
|
|
00:00:25,140 --> 00:00:28,280
|
|
to the subsequent phases might be the most appropriate one. Probably
|
|
|
|
10
|
|
00:00:28,280 --> 00:00:30,800
|
|
we don't want to do evolutionary prototyping in the case of
|
|
|
|
11
|
|
00:00:30,800 --> 00:00:34,130
|
|
the control system for an airplane. Same thing holds for TDD,
|
|
|
|
12
|
|
00:00:34,130 --> 00:00:36,460
|
|
so we want to be a little more rigorous in those cases.
|