YT YouTube2Text

YouTube2Text → Transcripts → Lecture 08: Life Cycle Models - IV

Lecture 08: Life Cycle Models - IV — Transcript

by NPTEL IIT Kharagpur · 2,673 words · 424 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:01[Music]
0:16welcome to this lecture over the last
0:20few lectures we had looked at few
0:24important software development lifecycle
0:27models we had started looking at the
0:31classical model which is very intuitive
0:35the classical waterfall model and the
0:39derivatives of this model namely the
0:43iterative waterfall model looked at the
0:47v-model prototyping model and so on and
0:51over the years few more models came up
0:55as the shortcomings of the waterfall
0:58model were noticed these were the rad
1:03model the incremental model incremental
1:07with iteration and the evolutionary
1:09model in the last lecture looked at the
1:13incremental model today we will first
1:17look at the evolutionary model and then
1:20we look at the agile development model
1:27this is in fact an evolutionary model
1:30with iteration remember in the last
1:35class we had said that the term
1:38iteration is used when existing
1:42functionality which was delivered
1:45developed and delivered is iterated and
1:51refined based on customer feedback now
1:59let's look at the evolutionary model
2:00with iteration one of the main problem
2:07that we had said about the waterfall
2:09based model is that the requirement is
2:13defined and frozen at the start of the
2:16project but then look at here about the
2:22practical situation cappers jones
2:26researched an eight hundred eight
2:28thousand projects and he found that
2:32forty percent of the requirements were
2:35arrived when the development had already
2:38begun if we had frozen the requirements
2:43the start then this forty percent
2:47changes will be very difficult to
2:50incorporate because in reality this is
2:53the average figure forty percent it can
2:56even be more for some projects and
3:01therefore there is need for a model
3:04which can effectively handle requirement
3:10changes requirements change due to
3:13various reasons maybe the business
3:17changes very rapidly once they have
3:21defined a business procedure may be
3:22after a month the business procedure
3:25changes or maybe the technology changes
3:28or maybe they might have not understood
3:35what is required and told something else
3:38maybe they had forgotten to tell
3:40something and so on so the requirements
3:44changed due to various reasons and we
3:48need a model which can effectively
3:51handle requirement changes one way that
3:59has been considered very promising is
4:01that each time do only small part of the
4:05system those are riskier likely to
4:09change the customer is not sure about it
4:16plan a little for this small work design
4:20a little code a little and once the
4:27small part is completed give it to the
4:30customer for his evaluation and feedback
4:39here the customer is encouraged to
4:42participate the end user the tester
4:48integrator Technical Writer all are
4:51involved in the development let's see
4:58what very distinguished person in this
5:04area dumb glib what he has to say on the
5:08evolutionary model is he says that a
5:12complex system will be most successful
5:15if implemented in small steps retreat to
5:21a previous successful step on failure if
5:24some functionality is totally not
5:27required then at least you can go back
5:30to the previous version which is
5:33acceptable and then develop from there
5:38opportunity to receive feedback from the
5:41real world before throwing in all
5:43resources and you can correct possible
5:46errors so according to thumb Glinda the
5:52evolutionary model which he captures
5:55here in this video lines is a very
5:58promising model to handle changes to the
6:02requirement due to various reasons let's
6:06see what Craig lahrman has to say about
6:09evolutionary model with iteration even
6:12listener e iterative development implies
6:14that the requirements plan estimates and
6:18solutions evolve or refined over the
6:21course of iteration rather than fully
6:24defined and frozen in a major operand
6:27specification before the development
6:31ITER Asians begin Eva listen Airy
6:35methods are consistent with a pattern of
6:37unpredictable discovery and change in
6:40new product development craig Lerman
6:44says that when a problem when a project
6:49starts it is very difficult to visualize
6:51all that is require
6:53only when you start doing then you can
6:59know that what is wrong what is really
7:01required and so on so is very critical
7:04about the waterfall model where the
7:09requirements are fully defined and
7:11frozen before the development starts and
7:15therefore evolution aary model is the
7:18way to go and true to his words most of
7:24the development models that are being
7:25used now which have become popular
7:29he was the evolutionary model in some
7:33form let's look at the evolutionary
7:37model here the core modules of the
7:40software is first developed and this is
7:47refined into increasing levels of
7:50capabilities which are called as
7:52iterations in nice iteration new
7:56functionalities will be added and also
7:59the existing functionalities can change
8:01based on the user feedback and its
8:06development each iteration is developed
8:11through a mini waterfall model at the
8:15end of a iteration some code is
8:22delivered to the customer invariably at
8:29the end of development
8:30maybe the existing functionalities might
8:33have changed it is possible that no new
8:37functionalities might have got added but
8:39only the existing functionalities have
8:40got refined or it may so happen that
8:44existing functionalities have got
8:46changed a little bit and new
8:48functionalities have been added so these
8:51are an increment and therefore it has
8:57some incremental development but then
9:00the question is that how is the
9:03incremental development
9:05and the evolutionary development differ
9:09because as you can see that in both
9:12these models incremental and
9:14evolutionary there are small increments
9:20over which the system is developed and
9:21these increments are deployed at the
9:24customer site and feedback obtained but
9:28let me mention here that in the purely
9:33incremental model as you might have
9:36remember from our last discussion that
9:40all those requirements are identified
9:44and these are planned into small
9:47increments each increment is developed
9:50deployed feedback obtained and changes
9:53can happen but in an incremental model
9:57all the requirements are gathered to
10:00start with where as in evolutionary
10:03model it is not the case here after an
10:07overall understanding of the system we
10:10do not really capture all the
10:12requirements but then start with some of
10:15the core or riskier modules
10:21at the end of each iteration a tested
10:25integrated executable system is
10:28developed deployed at the customer site
10:33the length of the each iteration is
10:35typically fixed something like a
10:39two-week to one month or maybe 1.5 month
10:492 to 6 weeks and the development
10:52precedes over many iterations for
10:54example a system may get developed over
10:5610 to 15 iterations as you can see the
11:00evolutionary model the requirements are
11:03not frozen but here the customer is
11:10encouraged to participate give feedback
11:12based on which the further developments
11:15occur and the customer feedback is taken
11:17into account and functionalities get
11:19modified so here the requirements are
11:25modified in a iteration some of the
11:28existing functionalities as well as new
11:31functionalities are delivered here
11:37successive versions are developed and
11:39deployed at the cost customer site each
11:42version is capable of performing some
11:46useful work which the customer can use
11:48and give feedback and a new release can
11:54include a new functionalities and also
11:57existing functionalities may get
12:00modified and refined
12:06we can diagrammatically represent it
12:08like this that initially rough
12:13requirements just understand what the
12:15system needs to do and then there are
12:18iterations the iterations are shown here
12:21in each iteration is a mini waterfall
12:24where need to specify a small part
12:28develop validate and deploy at the
12:32customer site to start with the initial
12:35version the feedback is obtained
12:37there are several intermediate versions
12:40and then the final version is deployed
12:43at the customer site even listener a
12:49model has the advantage that the
12:50customer can use the system and give
12:58feedback and therefore the evolutionary
13:04model is best suited to find the user
13:08requirements the exact user requirements
13:10and once it is delivered to the customer
13:13the customer to meet the customer
13:18requirements also since these are each
13:22time tested each increment is tested and
13:27deployed at customer site therefore
13:30multiple test activities integration
13:33activities occur and therefore it is
13:39less likely to contain bugs because
13:42these are tested thoroughly
13:46and since each time the developers focus
13:50each time on a small part it helps in
13:53managing complexity man it's better
13:56manners changing requirements customer
14:00feedbacks are obtained and incorporated
14:07the customer gets worsen quickly they
14:11get trained on using the software if
14:16there are bugs these are fixed quickly
14:22in the next iteration but then there are
14:26some problems with the evolutionary
14:28model let us be aware about the problems
14:31of evolutionary model you had seen that
14:33it is lot of advantages but then here
14:38the process is unpredictable that is
14:40each time we develop a increment deploy
14:43and get the customer feedback now what
14:46if the customer just keeps changing the
14:51requirements asks keeps on asking for
14:54modifications and so on therefore the
14:59process is unpredictable don't know when
15:04it will finish because the customer may
15:08keep on changing the requirements and
15:10also if we have a long term plan then it
15:18becomes easier to deploy manpower
15:20recruit them schedule work monitor and
15:24so on here all these are problematic
15:32the system is poorly structured because
15:35there is no overall design made it's
15:39only small parts that are designed and
15:41integrated since the code is changed
15:48continually the code structure degrades
15:53and the system may not even converge to
15:57a final version if each time the
16:01customer keeps anton asking for changes
16:05now let us look at the spiral model the
16:13main feature of the spiral model is risk
16:16handling just look at the spiral here
16:19diagram the model follows spiral we'll
16:23see that it was proposed by Boehm here
16:28each loop of the spiral is called as a
16:31phase and the system gets developed over
16:39many phases there is no fixed number of
16:43edges as the system develops more and
16:51more phases are created there can be
16:53many loops on this spiral until the
16:57final delivery takes place but over each
17:00phase that is each loop of the spiral
17:03one feature is identified and is
17:09developed
17:14if you can see there are four quadrants
17:16here on the spiral model the first
17:19quadrant what needs to be done in that
17:24phase is identified and then if there
17:28are any uncertainties technical
17:32uncertainties are the user requirements
17:35are not clear a prototype is developed
17:38to resolve the risk and then the next
17:44iteration is developed given to the
17:47customer for his evaluation and then
17:50another feature is taken up so over each
17:56iteration one or more features are taken
17:59up the risk is resolved and then the
18:07next development occurs and customer
18:09feedback as can be seen here this model
18:15is ideally suited for very risky
18:18projects where the technology is not
18:22known it's possibly the first time that
18:25this kind of software is being developed
18:27the technology is not certain and so on
18:30so each time some features the most
18:34riskiest feature is identified risk is
18:38resolved it is developed and given for
18:43customer feedback and the next set of
18:46features are taken on
18:52here the risk is any adverse of
18:55circumstance that might happen hamper
18:57the successful completion of the project
18:59it can be technical issues are not clear
19:04it can be that the customer is not able
19:08to clearly specify what is required and
19:12here the prototype is developed to
19:16overcome the risk if the risk is that
19:24requirements are inappropriate prototype
19:26is developed given to the customer so
19:28that he can more clearly say what is
19:32required the third quadrant is developed
19:37and valid it and the fourth quadrant is
19:42give the developed solution to the
19:45customer for feedback and plan for the
19:47next iteration we can see that with each
19:51iteration around the spiral more and
19:54more complete versions of the software
19:56get built the spiral model is also
20:02called as a meta model because a single
20:06loop of the spiral is a waterfall model
20:09there are iterations and therefore it
20:13incorporates evolutionary and
20:15incremental models it uses prototyping
20:20the stepwise approach of the waterfall
20:23model is retained and therefore this
20:27model can be degenerated or can be used
20:32as any other model but then need to
20:36remember that the spiral model is
20:38suitable for very risky projects and
20:40large projects now let us look at the
20:44agile models
20:49if we look at the meaning of agile in
20:52dictionary agile means easily moved very
20:58fast nimble active software process
21:02etcetera these are some of the terms
21:04that are given as explanation for agile
21:07model in dictionary but then agile means
21:10very fast so the development in agile
21:15model should occur very fast in much
21:18less time then it occurs in other
21:22development models but then how is it
21:25developed very fast how his agility
21:27achieved agility is achieved because
21:33here it gives lot of flexibility to
21:37change the process that is if some
21:40project requires some work to be done
21:45some specific activity it will be done
21:47if it is not required for another
21:49project it will can be easily skipped
21:52because the model is very flexible
21:56unlike the waterfall model where there
21:59are predefined activities and steps and
22:03so on here we can fit the process to the
22:07project but more important is we can
22:10avoid things that waste time that is to
22:14get it done very fast we need to avoid
22:17whatever is a wastage of time what are
22:23the West's of time maybe if we are
22:26preparing very elaborate documents were
22:28mentioning that in the iterative
22:31waterfall model 50% of the development
22:34effort and time goes in preparing
22:38documents here we will see that it does
22:42away in preparing these elaborate
22:44documents and saves lot of time
22:50it was proposed in mid 90s mainly to
22:53overcome the shortcomings of the
22:55waterfall model one important
22:59characteristic is to handle change
23:01requests we had seen that the
23:06evolutionary model is a good way to
23:09handle change requests and the agile
23:11models do incorporate evolutionary
23:14development evolutionary and incremental
23:16development here the requirements are
23:20decomposed into small incremental parts
23:22and development precedes incrementally
23:26there are a few things which are
23:29important here instead of producing
23:33laborat documents following process
23:37rigorously here the individuals and they
23:41interact with each other rather than
23:43passing on a document to each other they
23:45explain to each other through
23:46interaction in a waterfall model the
23:50progress of the development is measured
23:53in terms of the documents produced is
23:55the requirement document complete is the
23:57design document complete is the detailed
24:02design complete is the code
24:04documentation complete test
24:07documentation complete but here the
24:11progress is measured in terms of the
24:13working software that has got developed
24:16how many iterations have been completed
24:18and each iteration some working software
24:21is deployed at the customer site here
24:24the customer is encouraged to
24:26participate in development this
24:29encouraged to collaborate in the
24:31development rather than just signing a
24:34contract at the start of the project and
24:36here it is assumed that changes will
24:41occur the requirements will change and
24:44how to handle those rather than making a
24:48long-term plan and following that plan
24:50here changes are welcome
24:56and how to handle those changes those
24:59are important issues here the agile
25:05methodologies is an umbrella term there
25:09are many processes development processes
25:14which have come up like extreme
25:17programming or XP scrum crystal dsdm
25:22lean etcetera each of them have the
25:29features of the agile model but then but
25:33then they differ in some ways each one
25:36has its own focus new things that are
25:46introduced in each of them as you will
25:48see new terms new activities and so on
25:53but then they all have the features of
25:58the agile methodologies which we just so
26:02discussed in the last slide development
26:07over increments interaction with the
26:11customer less documentation interaction
26:16among the developers testing in
26:21integrating and testing or each
26:23iteration deploying getting customer
26:25feedback and so on
26:30for this lecture just come to the end
26:35and in the next lecture we will discuss
26:38more details about the agile development
26:40model thank you

About this transcript

This page contains the full transcript of Lecture 08: Life Cycle Models - IV by NPTEL IIT Kharagpur, generated from the public captions YouTube serves with the video. The transcript has 2,673 words across 424 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.