-So now I would like to wrap up this lesson - -2
-by going back to our discussion of rational unified process - -3
-phases and iterations. So to do that I'm going to bring - -4
-back the presentation that I used before, the summary representation - -5
-about phases and traditional software engineering activities. And I want to - -6
-use this representation to stress and discuss a couple of - -7
-things. Mainly I want to recap it because I think - -8
-it is very important. What is the relation between the rational - -9
-unified process, and the traditional software engineering phases, and software - -10
-engineering activities? And I like to do it now that - -11
-we have discussed the phases in a little more detail. - -12
-So I want to make sure that it is clear by now - -13
-how and when the traditional software engineering activities, the ones - -14
-listed here, take place in the context of the RUP - -15
-phases, the four listed up here. For instance, it should - -16
-be clear why implementation takes place mainly in the construction phase. - -17
-Why requirements engineering is prominent in the elaboration phase - -18
-and why deployment activities occur mostly in the transition phase, - -19
-and so on. So it should be clear now - -20
-why the activities are so distributed in the four phases. - -21
-It should also be clear that although there is - -22
-normally one main phase for each activity, the activities really - -23
-span multiple phases. Which is actually one of the interesting - -24
-aspect of RUP. So the fact that you're not really - -25
-done with an activity even in later phases. Why? Well, because that allows - -26
-you, in subsequent iterations, to address - -27
-problems that came up in previous iterations. -- cgit 1.4.1