YT YouTube2Text

YouTube2Text → Transcripts → Lecture 06: Life Cycle Models - II

Lecture 06: Life Cycle Models - II — Transcript

by NPTEL IIT Kharagpur · 3,065 words · 480 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:01[Music]
0:18welcome to this lecture in the last
0:22lecture we had discussed about the life
0:26cycle model and especially the classical
0:28waterfall model and as part of the life
0:33cycle model we had looked at the various
0:36activities that are undertaken during
0:38the development process and we had spent
0:45some time on the feasibility study which
0:50is an important activity undertaken by
0:52the project manager with the help of a
0:55case study we had identified what are
0:58the activities that are taken up by the
1:01project manager during feasibility study
1:03and at the end of the feasibility study
1:05the business case is written this is one
1:10of the initiating processes writing the
1:13business case and we had seen that how
1:17an effective business case can be
1:19written now let's proceed further in
1:24this lecture based on the discussions
1:29that we heard the last lecture we will
1:32discuss about the iterative waterfall
1:34model we'll look at the v-model
1:37evolutionary model and prototyping model
1:39that's the plan for this lecture the
1:44classical waterfall model is an
1:48idealistic model the main problem is
1:52that it assumes no defect is introduced
1:58during any phase each phase is completed
2:02and the next phase starts and so on
2:04until the project completes but in
2:07effect
2:10there are a lot of defects that are
2:12introduced in almost every phase of the
2:15lifecycle and that's the reason why it
2:23may be necessary to go back to a
2:26previous phase once a defect is
2:28identified for example the defect may be
2:32identified in the design phase that a
2:37requirement specification functionality
2:41was missing and then need to take up the
2:46requirements activity through our the
2:50requirement specification document and
2:53then again come back to the design phase
2:58that is the reason why we need the
3:01feedback path once the defect occurs in
3:09a phase there is a mistake by a
3:14developer it often remains unnoticed
3:16until a later phase and then once it is
3:24noticed in a letter phase it is then
3:29removed but the question here is that
3:34the latter the phase the more expensive
3:39is to correct this defect why is that
3:46the answer is not very far to sake
3:50because if defect occurs and it is
3:53removed immediately
3:55then that's the best thing the cost will
3:58be minimal but let's say the defect is
4:01removed after one phase that is the next
4:04phase then only
4:09two phases are affected only two phase
4:13documents need to be changed but if
4:16let's say defect is occurs in the
4:20requirement specification page and it is
4:23discovered during testing then not only
4:28the requirement specification document
4:30has to change the design needs to be
4:33changed the code needs to be changed and
4:36these are lot of activities and lot of
4:39documents need to change and that's the
4:41reason why the letter the fades in which
4:45the defect gets detected the more
4:48expensive is the removal of the defect
4:51this is a very important concept and it
4:54is known as the phase containment of
4:56errors so that sort is written here that
5:04once the defect is detected redo the
5:09work in the previous phases and
5:11therefore if there are lot of
5:13intermediate phases it has crossed many
5:17phases before the defect is detected
5:20then lot of rework is needed in the
5:28iterative waterfall model is very
5:30similar to the classical waterfall model
5:33so you can see the waterfall here but
5:38also there are feedback paths this
5:43feedback paths make the model realistic
5:47unlike the classical model where one
5:50phase completes and then the next phase
5:53completes and so on here we assume that
5:57there can be a defect which get noticed
6:01during the testing phase and we need to
6:04go back to the design phase or maybe the
6:06requirement analysis phase and then fix
6:11that defect and not only that fix the
6:14work in the later phases as well
6:20as we are saying that it's the important
6:23concept for the errors when they're the
6:27mistakes are made by the developers they
6:31must be fixed in the same page that is
6:36the ideal that the defects are detected
6:39and fixed in the same page that will
6:42incur the lowest cost the more delay
6:47occurs in detecting the defect the more
6:50expensive it will be if a design defect
6:54is detected in the design phase itself
6:58then it just need to change the design
7:00document but if it is detected during
7:03the testing phase not only the design
7:05document needs to be changed but the
7:07cordon is to be reworked and that will
7:10be much more expensive so this is called
7:12as the phase containment of errors it's
7:14an important principle that once a
7:18mistake occurs mistake or error occurs
7:22this must be contained to the same page
7:25it's called as a phase containment of
7:28errors the principle of detecting errors
7:33as close to its point of introduction is
7:36called as the phase containment of
7:38errors it's a very important principle
7:40and very intuitive also so this is the
7:49iterative waterfall model the phases are
7:52identical to the classical model
7:54excepting that the feedback paths are
7:57available the main strengths of the
8:02waterfall model is it is very intuitive
8:03easy to understand all the developers
8:06can very easily understand and use the
8:10model the milestones are clear
8:14understood by the team and the project
8:17manager can easily monitor the progress
8:21it provides the required stability
8:25management the project manager can have
8:29a strong control
8:31put scheduled milestones and monitor but
8:38then it has lot of deficiencies one of
8:42the major problem with the waterfall
8:44model is that it is not very suitable to
8:51handle changes to the functionalities
8:56but in almost every software project the
9:01requirements change there are many
9:05reasons why the requirement may change
9:07for example the customer may not be may
9:14not have thought that some
9:15functionalities will be required because
9:19he did not understand or did not think
9:23you cannot grasp what are all required
9:26at the beginning of the project but as
9:28he looks at functionalities then he can
9:32make out that certain functions will be
9:36required the other is that as the
9:39development takes place the business
9:43itself might undergo some change and
9:46therefore changes will be required so
9:50there are many reasons why changes will
9:57be required during the development of
9:59the software but in the waterfall model
10:03the requirements are fixed upfront and
10:06then the design coding and testing are
10:11undertaken and there is no way provided
10:14by the waterfall model to make any
10:18changes this is possibly the biggest
10:23shot coming of the waterfall model the
10:26other shortcomings are that here lot of
10:30documents are produced phases are
10:33completed the requirements is complete
10:36design is complete documents are
10:38produced code is complete but during
10:41testing found that most of
10:44the requirements are not met so the
10:47project manager gets a false impression
10:49of the progress that the progress is the
10:53project is proceeding nicely according
10:55to the plan but during the testing phase
10:59finds out that very little has been done
11:05the main reason for that is that the
11:08integration is a big bang at the end
11:11till then everything was fine but at
11:14during integration it has found that
11:16most of the functionalities are not
11:19working another problem with this model
11:22is that once the customer gives the
11:26requirement they have no chance to see
11:28the system till the end when it is
11:33delivered to them it would have been
11:36really good if the customers were
11:39involved they could see that what are
11:42the functionalities aids they're being
11:44developed they could have suggested
11:46modifications and so on these are the
11:49major difficulties with the waterfall
11:53model the biggest one is that it doesn't
11:57have the flexibility to handle the
11:59requirement change false impression of
12:04progress because phases are getting
12:07complete but integration is on Big Bang
12:11at the end where it is noticed that the
12:17progress is realest most of the
12:19functionalities are not working and the
12:23customer involvement is very minimal the
12:26customer cannot give suggestions but
12:31then the waterfall model was popular and
12:36it is also successfully used in some
12:41types of projects the projects for which
12:44waterfall model is suitable is that the
12:47requirements are very well understood
12:49and known to the customer they have used
12:54similar software they know what all is
12:56required
12:57it's not that something they're thinking
13:00of a new type of software it's a regular
13:04software requirements are well known and
13:07stable technology is understood
13:11development team have experience with
13:13similar projects so as you can see here
13:18that the project is rather routine
13:23project where the development team have
13:28done similar work they are just trying
13:35to develop one more of that you can say
13:42that the challenges here are less
13:44because the requirements are known what
13:50the software will finally look like what
13:52functionalities is very well known the
13:56technology is understood development
13:58team had experience in similar projects
14:01and for such simple projects Waterfall
14:06model can be used and this happens to be
14:09the most efficient way to complete these
14:11projects but what about the classical
14:16waterfall model the eyetality waterfall
14:19model has its use we saw that for simple
14:22projects they can be used but what about
14:26the classical waterfall model because
14:29here this was the idealistic model where
14:31it was assumed that there is no defect
14:36in any fades all fails proceed
14:40idealistically but the use of this is
14:45that the final documentation should
14:50appear like the software is developed in
14:52a using a classical waterfall model
14:54there are no backtracking no mistakes
14:57nothing and if the document is written
15:01that way then it facilitates
15:04comprehension of the documents
15:08just to give an analogy you may be
15:11trying to do a mathematical theorem
15:15proving or maybe trying to solve a
15:18problem mathematical problem and you
15:21might many times do rework mistakes go
15:25back to the previous failed previous
15:29step and so on but if your final
15:36document for this problem has all these
15:41things that where you did mistake where
15:44you went back corrected and so on then
15:47it becomes extremely complicated for
15:49somebody trying to understand the best
15:52for somebody to understand is that you
15:55give him the correct steps as if you had
16:03not committed any mistakes and so on and
16:07that is what is basically the classical
16:10waterfall model that all phases proceed
16:13without any mistakes now let us look at
16:17the v-model this is a variant of the
16:21waterfall model only small changes are
16:26there small derivative of the waterfall
16:31model essentially all the activities are
16:33there the waterfall model now let us
16:37look at the v-model the V model
16:41emphasizes on the verification and
16:45validation activities throughout the
16:47lifecycle we had seen that in the
16:51waterfall model the testing activity was
16:55only at the end initially there is
17:00requirements specification then there is
17:05design coding but the testing activities
17:09are only at the end and that's the
17:13reason why the testing activities take
17:14long time and the other problem is that
17:19what do the testers do
17:22till the testing phase starts what do
17:25they do the v-model gives answer to that
17:32it emphasizes verification and
17:35validation and normally this model is
17:40used well the software is supposed to be
17:43more reliable for example those software
17:48being used in critical applications the
17:51B model is used here in every phase of
17:57development there are some test
17:59activities for example running the test
18:02cases and later they may get executed
18:10but every phase there are some test
18:13activities that occur so this is the
18:17diagrammatic representation of the V
18:19model looks like AV here the model
18:22representation and that's the reason why
18:25it is called as a V model during the
18:31requirement specification the system
18:33test cases are developed which are
18:36executed during system testing during
18:39high-level design the integration test
18:41cases are developed during the detailed
18:44design the unit test cases are developed
18:47which are used during the unit testing
18:50after the coding is complete as you can
18:54see here that there is a emphasis on
18:57verification and validation activities
18:59and every phase there are some test
19:04activities unlike the waterfall model
19:06where the test activities occurred only
19:09when only in the integration and system
19:11testing
19:16here this slide it just says what are
19:21the system the test activities occur
19:23during the requirement analysis and
19:25specification system test case design
19:28activities occur high level design the
19:31integration test design activities occur
19:33and during the detailed design the unit
19:36tests design activities occur from the
19:40strength of this model is that it
19:43emphasizes verification and validation
19:47it's very similar to the waterfall model
19:50excepting that every phase has some
19:52verification and validation activities
20:00but then it has many weaknesses
20:03just like the waterfall model here it
20:08does not support overlapping of the
20:10phases that is one phase has to complete
20:14then the next phase starts what if some
20:16of the developers few of the developers
20:18complete first should they wait for the
20:22other developers to complete just idle
20:25or they can get started with the next
20:28phase this model does not allow that the
20:32wait for all phase the fails to complete
20:36and only then they can start the next
20:39phase
20:44does not easily accommodate letter
20:46change requirements does not provide
20:51support for effective risk handling so
20:54these are some of the problems of the
20:56v-model but then it is the natural
21:00choice for systems requiring high
21:02reliability and it is used when all
21:08requirements are known upfront and the
21:11technology is known now let's look at
21:15the prototyping model which is also a
21:18small variation of the basic waterfall
21:22model if we look at the diagrammatic
21:27representation of the prototyping model
21:30the initial phase here is prototype
21:32construction and after that the design
21:35coding etcetera are carried out here
21:43just like the waterfall model the
21:45activities are organized but then before
21:49starting the actual development a
21:51working prototype must be built what is
21:55a prototype a prototype is a toy
21:59implementation of the system which has
22:05limited functionalities slow reliability
22:10and so on but the question is that why
22:14do we need to develop a prototype before
22:18we start to develop the system what are
22:20the advantages of developing the
22:22prototype
22:28the first thing is that once you develop
22:32the prototype we can know what are all
22:36the requirements that should be there if
22:39there are any requirements which are
22:41missing if the customer can look at the
22:45prototype then you can find out what are
22:48the missing requirements there is a
22:55improved communication with the customer
22:59there is a user involvement because
23:02unlike the classical or the iterative
23:06waterfall model where the after the
23:08requirements are given the only thing
23:11that the customer sees the delivered
23:13software here in contrast in this model
23:17the prototype is constructed and given
23:20to the customer for his comments and
23:25also since a prototype exists it reduces
23:29the documentation reduces the
23:33maintenance costs and also if there are
23:39technical risks that the development
23:42team anticipates then they can through
23:47the prototype construction they can
23:49address those risks
23:55the reason for developing the prototype
23:58is to illustrate to the customer what is
24:01the software is going to look like what
24:05will be the input data formats messages
24:07reports interactive dialogues the
24:11technical issues associated with the
24:12product development the developers can
24:19experiment and find out what is the best
24:23way to handle technical issues sometimes
24:31the major decisions depends on issues
24:34like the response time of the hardware
24:36controller and here by developing the
24:41prototype the designers can have their
24:49solution based on the hardware the
24:53response time of the hardware controller
24:56at the up front rather than proceeding
25:01throughout all the development
25:03activities and finding out that the
25:05hardware controller response time is
25:07slow and they need to change everything
25:10so developing a prototype helps in
25:17getting the customer feedback and also
25:22many technical issues are clarified and
25:25the development can proceed correctly
25:35also when a prototype is developed the
25:41once it is used for the illustrating to
25:44the customer it is thrown away and the
25:47actual system is developed but then the
25:50experience that the development
25:52development team gets in developing the
25:54prototype that goes a long way in
25:58developing a good software here in the
26:04prototyping model first the approximate
26:07requirements are obtained a quick design
26:11is construct is made and then the
26:16prototype is constructed using various
26:19shortcuts the shortcuts can be like
26:23inefficient inaccurate or dummy
26:26functions a table lookup rather than
26:30writing the code for the actual
26:32computation we can implement that in the
26:37this diagram that initially a quick
26:40design is done based on the requirements
26:43that have been gathered prototype is
26:45built submitted to the customer for
26:49evaluation based on customer feedback we
26:52find the requirements again have a quick
26:55design change the prototype and so on
27:00until the customer is satisfied with the
27:03prototype then a waterfall model is used
27:06for developing the software
27:11so the it's a small variation of the
27:18waterfall model only the initial
27:20prototype construction that is added
27:22here and because of the prototype is
27:29kind of a requirement specification
27:32animated requirements specification
27:37requirement specification document may
27:40not be required but one thing that we
27:44must be clear here is in the prototyping
27:47model once the prototype has been used
27:50to demonstrate to the customer and
27:53address the technical issues the
27:55prototype is thrown away and then the
28:00development starts but does the
28:05prototype construction add to the cost
28:09and the development becomes more costly
28:11no not really because for systems with
28:16unclear user requirements with
28:19unresolved
28:19technical issues the prototyping is
28:22actually a cost effective way of
28:24developing the software because without
28:27a prototype we might have to change the
28:31software many times and that would make
28:33it much more expensive that would incur
28:38massive redesigned costs and even though
28:42there is a small upfront cost of
28:44developing the prototype but that will
28:47be more effective cost effective then
28:52not using the prototype and finally
28:58finding out that the customer has lot of
29:01dissatisfaction and suggests many
29:04changes and also the technical issues
29:08are unresolved as a result many changes
29:11occur with this discussion we'll just
29:17stop here
29:19and continue discussing a few more
29:22lifecycle models in the next lecture
29:26thank you

About this transcript

This page contains the full transcript of Lecture 06: Life Cycle Models - II by NPTEL IIT Kharagpur, generated from the public captions YouTube serves with the video. The transcript has 3,065 words across 480 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.