1
00:00:00,430 --> 00:00:06,300
Hi, in the last lesson we provided an overview of the course and motivated the

2
00:00:06,300 --> 00:00:09,570
need for software engineering. In this lesson,

3
00:00:09,570 --> 00:00:13,090
we will present and start discussing several traditional

4
00:00:13,090 --> 00:00:16,090
software engineering life cycle models. We will

5
00:00:16,090 --> 00:00:18,790
talk about their main advantages, and also about

6
00:00:18,790 --> 00:00:21,840
their shortcomings. We will also talk about

7
00:00:21,840 --> 00:00:25,720
classic mistakes in software engineering that is well

8
00:00:25,720 --> 00:00:29,530
known ineffective development practices, that when

9
00:00:29,530 --> 00:00:32,590
followed, tend to lead to better results. And

10
00:00:32,590 --> 00:00:35,120
covering those, will hopefully help us to avoid

11
00:00:35,120 --> 00:00:38,350
them in the future. And because in this

12
00:00:38,350 --> 00:00:41,290
lesson, I will discuss some fundamental aspects of

13
00:00:41,290 --> 00:00:44,730
software engineering, to suitably introduce these topics, I

14
00:00:44,730 --> 00:00:47,110
went to the University of Southern California, to

15
00:00:47,110 --> 00:00:50,300
interview one of the fathers of software engineering;

16
00:00:50,300 --> 00:00:53,070
Professor Barry Boehm.

17
00:00:53,070 --> 00:00:59,060
>> A well, a software life cycle is a sequence of, of decisions that you

18
00:00:59,060 --> 00:01:01,895
make, and it's fundamentally those decisions are

19
00:01:01,895 --> 00:01:05,280
going to be part of the history of the

20
00:01:05,280 --> 00:01:09,500
software that. You are going to build that other people are going to use, and

21
00:01:09,500 --> 00:01:15,330
the process model is basically answering the question of what do I do next and

22
00:01:15,330 --> 00:01:20,550
how long shall I do it for. And again, because there are a lot of different ways

23
00:01:20,550 --> 00:01:24,220
you can make that decision, you need to

24
00:01:24,220 --> 00:01:27,640
figure out which models are good for which particular

25
00:01:27,640 --> 00:01:31,475
situations. So, for example, we've, written a book

26
00:01:31,475 --> 00:01:34,846
that's called Balancing Agility and Discipline. It says under

27
00:01:34,846 --> 00:01:37,835
what conditions should you use agile methods, under

28
00:01:37,835 --> 00:01:40,824
which conditions should you invest more time in analyzing

29
00:01:40,824 --> 00:01:44,826
the situation and planning what you're going to do and the like. And so,

30
00:01:44,826 --> 00:01:49,866
typically if the project is, is small where it's three to ten

31
00:01:49,866 --> 00:01:55,271
people, agile works pretty well. If it's 300

32
00:01:55,271 --> 00:02:00,545
people, then I think we don't want to go that way. If the affect of

33
00:02:00,545 --> 00:02:05,960
the defect is loss of comfort or limited funds, then agile is fine,

34
00:02:05,960 --> 00:02:11,184
but if it is a loss of life, then you don't. On the other hand if, if

35
00:02:11,184 --> 00:02:13,776
you have a situation where you have lot

36
00:02:13,776 --> 00:02:17,745
of unpredictable change, you really don't want to spend

37
00:02:17,745 --> 00:02:23,439
a lot of time writing plans and lots of documents. In some cases you may have a

38
00:02:23,439 --> 00:02:26,907
project where you want to do waterfall in

39
00:02:26,907 --> 00:02:31,140
some parts and agile in others. So, these are

40
00:02:31,140 --> 00:02:36,180
the kind of things that, that make the choice of life cycle process

41
00:02:36,180 --> 00:02:41,409
model very important and very interesting as a subject of research.