so hello everyone welcome to the channel so our young junior to software engineering software lifecycle model super bad can a valley like a body other important unit a cookie a joy object oriented software engineering maybe a escape some parts common a champion who's burning get them a pop up to communicate a part common a ticket to this my basically I'm HDLC models cooperative Italy which Allah a start cut the a the ultimate objective of software engineering is to produce good quality maintainable software within reasonable timeframe and an affordable cost. This is the definition of software which I told you in the first unit. This is achievable only if we have matured processes to produce it. For a matured process, it should be possible to determine in advance how much time and effort will be required to produce the final product. This can only be done using data from past experience which requires that we must measure the software process.
Software development organization follows some process. When developing a software product in a mature organization, the process is usually not written down. In mature organization, the process isn't written down and is actively managed.
A key component of any software development process is the lifecycle model on which the process is based. The particular lifecycle model can significantly affect overall lifecycle cost association with a software product. Lifecycle of the software starts from concept exploration.
and ends at the retirement of the software in the IEEE standard glossary of software engineering terminology the software lifecycle is the period of time that starts when a software product is conceived and Ends when the product is no longer available for use the software lifecycle typically includes a requirement phase design phase implementation phase test phase installation and checkout phase operation and maintenance phase and sometime retirement phase All these things are important in all the models of HDLC You should know the requirement phase, design phase, implementation phase, test phase and installation phase These phases will be common in all models but in some models the life cycle will change A software life cycle model is a particular abstraction that represents the software life cycle A software life cycle model is often called a software development life cycle Which we represent in HDLC In this case, we represent a software life cycle model A variety of lifecycle models have been proposed and are based on tasks involved in developing and maintaining software. Few well-known lifecycle models are discussed in this chapter. First of all, we will study Build and Fix Model.
Sometimes a product is constructed without a specification or any attempted design. Instead, the developer simply builds a product that is reworked as many times as necessary to satisfy the client. This is called ad hoc approach and not well defined. Okay, the building fix my simple bill But I'm gonna fix can you build my name is big trying to do key example a particular model a which no coach hum Jada coach won't get this ad hoc approach catia.
Oh, you're not well defined I basically it is a simple two-phase model the first phase is to write code and the next phase to fix It and fixing in this context may be error Connect correction or addition of further functionality take up simple the sector is case opposite diagram say I'm simple the code lick and I fix canna quote a graphic dinner. Do kita. No, but I reliable in here.
Okay Although this approach may work on small programming exercises in which there will be 100 to 300 lines of code, we can use this approach. This model is totally unsatisfactory for software of any reasonable size. Code soon become unfixable and unenhancable. There is no room for design or any aspect of development process to be carried out in a structured or detailed way.
The cost of the development using the approach is actually very high as compared to the cost of a properly specified and carefully designed. In addition, maintenance of the product can be extremely difficult without a specification or design document. Then comes the waterfall model. The waterfall model is said to have been improved after build and fix. The most familiar model is the waterfall model which is given in Figure 2. The model has five phases.
It has five phases in which requirement analysis, specification design, implementation and unit testing are given. Integration and System Testing and operation and maintenance the phase always open in this order and do not overlap together upon um so now waterfall Yankee a click a cup but love is kajal behavior ever a direction material tie together the developer must complete each phase before the next phase begins this model is named waterfall model because it's diameter T a dramatic diagrammatic representation example a cascade of waterfall okay The structure of this is like a waterfall that's why it moves in one direction So this is the waterfall model First comes the requirement analysis and specification phase What is the goal of this phase is to understand the exact requirement of the customer and to document them properly This activity is usually executed together with the customer as the goal is to document all function, performance and interfacing requirements for the software The requirement describes the what of a system not the how system make a cacca cacca a comkara Nenaki a cacca comkara sir kya system kya comkara thai is my author requirement analysis phase this phase produce a large document written in a natural language contains a description of what the system will do without describing how it will it done the resultant document is known as software requirement specification Joe is k bar to make a document a arrow goes to both the SRS jockey software requirement specification jockey a first waterfall model key The first phase is the SRS document may act as a contract between the developer and customer If developer fails to implement full set of requirements it may amount to failure to implement the contracted system So first our document is ready which is SRS You can see this is our diagram in which first comes requirement analysis and specification Then comes second where we design Third where we implement and unit testing Fourth where we do integration and system testing and it includes operation and maintenance. So this is the phase of waterfall model. Now we will talk about second phase which is design phase.
The SRS document has been produced in the previous phase. Which contains the exact requirement of the customer. The goal of this phase is to transform the requirement specification into a structure that is suitable for implementation in some programming language.
Here overall software architecture is defined and the high level and detailed design work is performed. this work is documented and well and known as software design description the document which will be displayed in this is SDD document the information contained in the SDD should be sufficient to begin the coding phase see after this our phase is coming which is coding in which our implementation and unit testing is coming so the first document which we got before coding phase is SDD you have to keep in mind that first we got SRS then SDD now comes implementation and unit testing in which we will write code ok During this phase design is implemented. If the SDT is complete, the implementation or coding phase proceeds smoothly because all the information needed by the software developer is contained in the SDT.
During testing, the major activities are centered around the examination and modification of the code. Initially small modules are tested in isolation from the rest of the software product. There are problems associated with testing a module in isolation.
How do we run a module without anything to call it? to be called by it is possible to output intermediate values obtained during execution such problems are solved in this phase and modules are tested after writing some overhead code integration and system testing phase this is a very important phase okay effective testing will contribute to the delivery of high higher quality software products more satisfied users lower maintenance cost and more accurate and reliable result It is a very expensive activity and consumes one-third of one half of the cost of a typical development project. As we know, the purpose of unit testing is to determine that each independent module is correctly implemented. This gives little chance to determine that the interface between the modules is also correct and for the reason, integrating testing is performed.
System testing involves the testing of the entire system. Testing is important. So, in this testing, integration is done.
Whereas software is a part of the system, this is essential to build confidence in the developer before software is delivered to the customer or released in the market. Then you will see our fifth phase which is operation and maintenance phase. Maintenance phase is the most important phase in any model.
Software maintenance is a task that every development group has to face. When the software is delivered to the customer site installed and is operational, therefore release software inaugurates. The operation and maintenance phase of the lifecycle Thus time spent and effort required to keep the software operational After release is very significant Despite the fact that it is a very important and challenging task It is routinely the poorly managed headache that nobody wants to face Software maintenance is a very broad activity that includes error correction enhancement of capabilities, deletion of obsolete Capabilities and optimization the purpose of this phase is to preserve the value of the software over time This way may spend for five to fifty years whereas development may be one to three years Okay, they get to is face can die important is like okay So five to fifty years some are is phase may Jannevale a development make one to three years here Yeah, simple up quick but idea. Yeah, the examples at the model is too easy to understand a re-information reinforces the notion of defined before design First define then design and design before code First design then code That means define in SRS then design in SDD and code is implementation This model expects complete and accurate requirements early in the process which is unrealistic Working software is not available until relatively late in the process Thus delaying the discovery of serious error it also does not incorporate any kind of risk assessment Basically, after completing one phase, we jump to the next phase.
So, this is the thing that can be a problem. It is difficult to define all requirements at the beginning of a project. When software is made, things are defined later.
So, we cannot say that the S.R.S. is defined in that. No, no, no, there will be some requirement. Then comes, this model is not suitable for accommodating any change.
It is not possible for us to make any change because once the whole phase is over, we go to the next one. working version of the software is not seen until late in the project's life working project will be seen at the end when all the projects will be defined SRS will be created, HDD will be created, implementation will be done it does not scale up very large project we cannot use it on large project because it is for small project real project are really sequential due to this weakness the application of waterfall model should be limited to situations where the requirement and the implementation are well understood for example if an organization has experience in developing accounting system then building a new accounting system based on existing design could be easily managed with the waterfall model okay then we have second increment process models okay in this increment process models are effectively effective in the situation where requirement are defined precisely and there is no confusion about the functionality of the final product okay although functionality can be delivered in phase as per desired priorities after every cycle A usable product is given to the customer. For example, in the university automation software, library automation module may be delivered in the first phase and examination automation module in the second phase and so on.
Every new cycle will have an additional functionality. Increment process models are popular particularly when we have to quick deliver a limited functionality system. Then comes our intuitive enhancement model.
Has the same phases as well the waterfall model but with fewer restrictions. Generally the phases occur in the same order as in the waterfall model, but these models may be conducted in several cycles. A usable product is released at the end of the e-cycle, with each release providing additional functionality.
During the first requirement analysis phase, customer and developer specify as many requirements as possible and prepare a SRS document. developer and customer then prioritize these requirement developer implement the specified requirement in one or more cycles of design implementation and test based on the defined priorities this model is given in 2.3 up again object to yeah Mara figure 2.3 made a great yeah iterative enhance model is make a requirement to a design or implementation were free integration were operational yet Amala tab waterfall may up kiya design kebat tubara say tubara Sam second model pe kaam ka sakte hai yeh first release hai, then in second release meh fir design, implement, integrate and operation karenge, fir third meh. Toh yeh kya hai, yahaan pe hamara kya hai, yeh iterative enhanced model.
Hum iteratively isko enhance ka sakte hai after ek baar requirement mil gaye, fir hum baar baar iske first release, second release design kar kare, hum bana sakte hai. The aim of the waterfall and prototyping model is the delivery of a complete, operational and good quality product. In contrast, this model does deliver an operational quality product at each release, but one that satisfies only a subset of the customer requirement.
The complete product is divided into releases and the developer delivers the product to Releases by the release a typical product will usually have many release as shown in figure 2.3 at each release Customer has an operational quality product that does a portion of what is required Okay, the customer is able to do some useful work after First release with this model first release may be available within a few weeks or months Whereas the customer generally waits months or years to receive a product using the waterfall and prototyping model I have explained you that in iterative enhanced model, after one step, the second step will continue from there. So, one release, two release, three release will continue in this iterative way. But finally, we will keep changing the product later.
Then comes our RAD i.e. Rapid Application Development. This model is an increment process model and was developed by IBM. It was developed in 1980s. and described in the book of James Martin entitled Rapid Application Development.
Here user involvement is essential from requirement phase to deliver of the product. The continuous user participation ensures the involvement of users'expectations and perspectives in requirement elicitation, analysis, and design of the system. The process is started with building a rapid prototype and is given to users for evaluation. The user feedback is obtained.
and prototype is refined the process continues till the requirement are finalized we may use any grouping technique like fast qfd brainstorming session yeah interview major home ducted it is a fast man i'm active yes of size and red may use cut the for details after chapter three take a chapter three map from the bottom of fast case a qfd kota okay for requirement elicitation software requirement and specification srs and design documents are prepared with the association of users In RAD model, there is requirement planning, user description, construction and cut over First, we will see requirement planning phase Requirements are captured using any group elicitation technique We will study this technique, there will be interviews and brainstorming sessions We will see that in unit 3 Some techniques are discussed in chapter 3 Only issues is the active involvement of users for understanding of the project In this, users will be involved in requirement planning phase Then comes second user description Joint team of developers and users are constituted to prepare, understand and review the requirement The team may use automated tools to capture information from the other user This comes in user description Then comes third our construction phase In this, these phases combine the detailed design, coding and testing phase of waterfall model Here we release the product to customer It is expected to use code generator skin generator and other types of productive tools Take a hammer construction phase for the last time our cutover phase this phase incorporates acceptance testing by the user installation of the system and user training It's not a cutover phase in this model quick initial views about the product are possible due to delivery of rapid prototype Ticket to smegham rapidly a product code deliver cut the judges can nominate it together development time of the product may be reduced due to use of powerful development tools it may use case tools and frameworks to increase productivity involvement of user may increase the acceptability of the product if a user cannot be involved throughout the life cycle this may not be an appropriate model the case may user kahuna both jada important hai jo ki vo changes karne ke baad hum is model me ka sakte jab ye are a rapid rapid change ka sakte development time may not be reduced very significantly If reusable components are not available, high specialized and skilled developers are expected and such developers may not be available very easily. It may not be effective if system cannot properly modelize. Then comes our evolutionary process model.
Evolutionary process model resembles iterative enhanced model. The same phase as defined for the waterfall model. occur here in cyclic fashion.
The model differs from iterative enhancement model in the sense that this does not require a usable product at the end of each cycle. In evolutionary development requirements are implemented by category rather than by priority. For example, in a simple database application, one cycle might implement the graphical user interface, another file manipulation, another queries and another All 4 cycles must complete before there is working product available GUI allows the user to interact with the system File manipulation allows data to be saved and retrieved Queries allows user to get data out of the system Updates allows user to put data to the system With any one of those parts missing, the system would be unusable In contrast, an iterative enhanced model would start by developing a very simplistic but usable database. On the completion of each cycle, the system would become more sophisticated.
It would, however, provide all the critical functionality by the end of the first cycle. Evolutionary development and iterative enhancement are somewhat interchangeable. Evolutionary development should be used when it is not necessary to a particular type of development.
provide a minimal version of the system quickly these models are useful for project using new technology that is not well understood this is also used for complex project where all functionality must be delivered at one time but the requirement are unstable or not well in well understood by the system the key WM around evolutionary process model in the defendant but love do a sorry model saying key a particular requirement p-humming could use carrying a jessica of the sector We will use evolutionary process model for complex project In the beginning we will not have requirement And not well understood by data at the beginning So when we will use waterfall model then we will have requirement So it is like this, it depends on which model we will use Then comes our prototyping model So prototyping model means first we will make prototype Then we will use it A disadvantage of waterfall model is discussed in the last section in the working software It is not available until late in the process, thus delaying the discovery of serious error and alternative to this is to first develop a working prototype of the software instead of developing the actual software. The working prototype is developed as per current available requirement. Basically it has limited functional capabilities, low reliability and untested performance, usually low. The developer used this prototype to refine the requirement and prepare the final specification document Because the working prototype has been evaluated by the customer, it is reasonable to expect that the resulting specification document will be correct When the prototype is created, it is reviewed by the customer Typically, the review gives fair feedback to the developers that helps to improve uncertainties in the requirement of the software and the start and iteration of refinement in order to further clarify requirement as shown in figure 2.5 so if you see in prototyping model here requirement is taken then quick design is done customer evaluation is implemented now if customer wants to make some changes then it comes back refinement of requirement as per suggestion and again quick design so all this will continue after this SRS is made on this phase then comes design then comes implementation and unit testing integration and system testing and operational maintenance this is our prototyping model The prototype may be a usable program, but it is not suitable as the final software product. The reason may be poor performance, maintainability or overall quality.
The code for the prototype is thrown away. However, the experience gathered from developing the prototype helps in developing the actual system. Therefore, the development of prototype type might involve extra cost, but overall cost might turn out to be lower than that of equivalent system developed using the waterfall model.
Making a prototype is a tedious task. We never use prototypes. Basically, the user gets a clear pictorial representation of how it is going to look.
Developers should develop prototypes as early as possible to expand up the software development process. After all, the sole use of this to determine the customer's real needs. Once this has been determined, the prototype is discarded.
For this reason, the internal structure of the prototype is not very important. After the finalization of software requirements and specifications in the SRS document, the prototype is discarded and the actual system is then developed using the waterfall approach. Thus, it is used as an input to waterfall model and produce maintainable and good quality software.
This model requires extensive participation and involvement of the customer, which is not always possible. The disadvantage is that we need a user in this model because the prototyping will tell us So the disadvantage is that our customers are not always possible to be with us So this is the disadvantage Then comes our spiral model The problem with traditional software process model is that they do not deal sufficiently with the uncertainties Which is inherent 2. Software Projects Important software projects have failed because project risks were neglected and nobody was prepared then something unforeseen happened. Barry Bohem recognized this and tried to incorporate the project risk factor into a life cycle model. The result in the spiral model which was presented in 1986 and shown in figure 2.6 I will show you spiral model this is our spiral model it has four phases total we start from here cycle starts from first prototype then cost will increase on every cycle so this is our spiral model so this is our spiral model now let's see its phase what are the phases the radial dimension of the model represent the competitive cost I will say cost will increase on every cycle Each path around the spiral is indicative of increased growth. The angular dimensions represent the progress made in completion each cycle.
Each loop of the spiral from x-axis clockwise through 360 degrees represents one phase. One phase is split roughly into four sectors of major activities. First are the planning, risk analysis, development, assessment. Planning mechanism determines of objective, alternative, and constant.
Risk analysis means analyze. alternatives and attempts to identify and resolve the risk involved then comes the most important factor in this is risk we don't see risk in anyone here we are seeing risk in second phase because risk is an important factor which we will remove in this spiral third is development production, development and testing product then comes assessment and customer evaluation so in the end our customer evaluation will be done During the first phase planning is performed, risk are analyzed, prototypes are built, and customers evaluate the prototype. During the second phase, a more refined prototype is built, requirements are documented and validated, and customers are involved in assessing the new prototype. By the time third phase begins, risks are known and somewhat more traditional development approach is taken.
The focus is the identification of problem and the classification of this into different level of risk, the aim being to eliminate high risk factors. high-risk problem before they threaten the software operation or cost. An important feature of the spiral model is that each phase is completed with a review by the people concerned with the project, designer and programmer. This review consists of a review of all the products developed up to that point and includes the plan for the next cycle. These plans may include a partition of the product in smaller portions for development for component data.
implemented by individual groups or person if the plan for the development fails then the spiral is terminated otherwise it terminates with the initiation of new or modified product software you can see here the risk factor comes in the second phase first comes the planning phase then the last assessment and third comes the development phase so this is how our phase goes and the cost will increase on each and every cycle you can see here concept of operation Here integration testing, the rest of our operation will be performed, but here the most important factor is risk, which will increase in cost at every phase. The advantage of this model is the wide range of options to accommodate the good features of the other lifecycle model. It becomes equivalent to another lifecycle model in appropriate situations.
It also incorporates software quality objectives into software products. Development The risk analysis and validation steps eliminate errors in the early phases of development. The spiral model has some difficulties that need to be resolved before it can be a universally applied lifecycle model. These difficulties include lack of explicit process guidance in determining objective constraints, alternatives relying on risk and assessment expertise, and providing more flexibility than required for many.
applications. Then comes the unified process. The unified process is described by I.
Jacobson, G. Butch and J. Rembog in this book The Unified Software Development Process. It is a software engineering process with the goals of producing good quality maintainable software within specified time and budget. The unified process supports iterative development where project is developed through a series of of short fixed-length mini project called iteration the outcome of each iteration is a tested integrated and executable system each occasion has its own requirement analysis design implementation and testing activities hence the system continues to enlarge and refine with every iteration and thus grows incrementally over time thus this approach is also known as iterative and incremental development the unified process is now maintained and enhanced by a rational software corporation and thus also referred as RUP rational unified process as we all know sequential approach is not suitable due to Changing requirements and uncertainties in software development iterative approach is definitely better than Sequential approach and became the basis of a unified process The process also defines who is doing what how and when the role of everyone in the development process is defined Clearly and precisely there are the amari phases of unified process Okay, there are four phases in the unified process and the life cycle is shown Each phase has a specific outcome which can be reviewed if reviewed to improve the quality of the process In this phase, Inception, Elaboration, Construction and Transition are used These are the four phases of our RUP In Inception, this phase is used to define the scope of the work This is similar to requirement analysis and specification phase of waterfall model We define the requirement using the requirement elicitation techniques The customer and developer interaction helps us to capture and define the requirement Although requirements are always changing but the changes can be accommodated due to iterative nature of the process The outcome of the phase is clear defining of the objective of the project The second is elaboration In elaboration, how do we plan and design the product What resources are required?
What type of architecture may be suitable? These questions are answered in this phase We specify the feature and prepare the baseline of the architecture This is similar to design phase, waterfall model The outcome is the planning and architecture document of the project Inception is elaboration and construction is third We construct in this The objectives are translated in design and architectural document These documents are the inputs to construction phase and output is the product We build and test the product in this phase The outcome of this phase is the deliverable product to the customer and sometimes may be treated as beta release beta release will happen first after that our software product will be output so this is construction phase then comes our fourth transition phase transition the product of the customer involves many activities like delivering, training, supporting and maintaining the product the ultimate objective is the customer satisfaction the phase activities may continue till the customers are satisfied The outcome is the product release which also concludes the lifecycle of the unified process These four phases, Inception, Elaboration, Construction and Transition constitute a development cycle and produce a software generation In the first iteration, initial development cycle, first version of the software is produced The software will be used by users The feedback of the users in terms of additional functionality, failure report, etc. may motivate users to work for the second version. The same process is through inception, elaboration, construction and transition phase will repeat to evolve the next generation of the software product. These cycles are known as evolution cycle with several evolution cycle new generation of the product are produced.
This process will continue up to the retirement of the software product. You can see Inception, Elaboration, Construction, Transition, Version 1 is gone. Then if we want to make some changes, then again initial development cycle will be made.
So, let's go to the cycle. and continuously till the product is retired. So this is initial development and evolution cycle. Then the phases are not equal length. The length may vary depending on the type, specification and environment of the project.
In each phase we progress iterative and each phase may consist of one or more iteration as shown in figure 2.9. So you can see how many iterations will be made. After elaboration, iteration, iteration 4, iteration 5, iteration 6 At every iteration, our product will be made in the end and will be released at the end So this is iteration with a phase Each iteration follows a pattern which is similar to waterfall model Hence the workflow contains See, waterfall model is the base of all After that we made changes in it and made new models Hence the workflow contains the activities of requirement elicitation and analysis Design, implementation and testing Thank you yes your software requirement elicitation a yeah a chapter unit 3 Johan Mohamed's my suppose putting elitism a homeric technique as a hum SRS bonanza pala hum kaseyam document maranis appellum case a case a user say or a mario stakeholder so in data co-lake a data banana to yes can wrap a little unit three map bringing a however from one iteration to the next and from one phase to the next the emphasis on various activities will change figure 2.10 shows the relative emphasis on the various types of activities over time you can see the figure the graph is being made over time over the time which phase is going up first when we have requirement elicitation analysis then see the elaboration is at the top slowly you can see which is going on which peak in every phase so this diagram is representing this then comes these activities are not separated in time rather they are executed concurrently throughout the lifetime of the project as we have seen in figure 2.10 not much code is written early in the project life cycle but the amount is not zero Late in the project, most of the requirements are known, but some new ones are still identified. Thus, as the project matures, the emphasis on certain activities increases or decreases, but activities are allowed to execute at any time throughout the lifetime of the project. The inception phase is primarily dedicated to the requirement elicitation and analysis.
The scope of the work is defined and some planning work is also carried out. The elaboration phase has the focus on requirement with some emphasis on design and implementation During the construction phase, focus is mostly on design and implementation We produce first operational product after this phase The focus of transition phase is on training, installation and customer interaction The feedback of customers help us to improve and enhance the product We produce and deliver the final product You can see that we have completed the first phase requirement face but you peak is lehiya cookie hum subsap sepele in pick on garota inception in elaboration pay but just a design face a goto construction height pitch a la gorgie construction home code lick they put implementation my Maria peak pay to yes above quick diagram K through bataga pirata hamara unified process work products all four faces product produce different work product as per outcome of the faces in the inception phase has the following objective first a gathering and analyzing the requirement planning and preparing a business case and evaluating alternatives for risk management scheduling resources etc. then it comes to estimating the overall cost and schedule for the project then it comes to study the feasibility and calculating profitability of the project many documents are prepared are shown in figure 2.11 so you can see inception, prototypes, project plan, initial risk assessment initial business case, initial project, glossary, initial use case model vision document or business model to yet our inception of the vision document up take take a course almost a division document emphasis is on requirement and scope of the project it gives us an idea about overall objective and expectation from the project initially use case model gives you use case diagram take a excuse case diagram at the use came diagram up come a unit five we are listening to me Liga just make actors or homerage or June use case diagram one day along with actors the happy actors coming now Maria did it to a look actors come but I thought I said represent curate a tone We will study the use case diagram of the case in unit 5 It may also consist of use cases that can be identified at the early stage Initial business case may include revenue model, market condition, business difficulties, and financial forecast, etc. Project plan document may include phases and iterations for the development of the project Prototypes are very useful for the understanding of the project A business model may be required to provide idea about time to market marketing strategies, cash flows and trades.
The elaboration phase has the focus on the analysis of problem domain, establishes a sound architectural foundation, develops project plan and eliminates the risk elements. Some of the objectives and activities are establishing architectural foundation, design of use case model, elaborating the process, infrastructure and development environment, selecting component if possible for the project, demonstrating the architecture support the vision at reasonable cost and with the specified time okay the outcomes are given our elaboration phases are development plan revised risk document and executable architectural prototype architecture description document supplementary requirements with non-functional requirement use case model or a preliminary user manual this comes in our elaboration see a use case model At least 80% complete is prepared All use cases are identified along with associated actors Supplementary requirement documents with non-functional requirements and software architecture description documents are also prepared A prototype is also designed for the customer to give an idea about the final product A development plan may be iterated Workflow subject is also prepared A preliminary user manual, although optional, may also be prepared in this phase and will be used in the development process refined in the subsequent phases the construction phase produce the product for the customer The objective and activities are implementing the project minimizing development cost managing and optimizing resources testing the product Assessing the product release against acceptance criteria The outcome of this phase is a product ready to use for the customer and is shown in figure 2.13 Construction test outline, operational manuals, test suit, description of the current release, user manual, software product and documentation manuals This is the outcome of construction phase The outcomes are various operational and documentation manual along with software product The test suite documents are also preserved carefully because they are required during the maintenance of the software and product The transition phase lays focus on successful delivery and installation of the software product These phases include the following commencement of beta testing, analysis of users'views, training of users, tuning activities including bug fixing and enhancement for performance and usability, assessing for the customer satisfaction The outcomes are given in Figure 2.14 Okay, so transition matatine product release beta test reports or user feedback the unified process has many advantage due to iterative and increment incremental nature changes can be accommodated risk can be minimized Reas usability can be ensured and learning along with project evolution is possible. Hence the product that result from unified Process it will be of good quality the system has been tested several times improving the quality of testing the requirement have been refined and Are more closely related to the customers actual expectation about our selection of a lifecycle model Okay, so it's my character based on the following characteristic characters the para requirement development team users project type and association this table both important tech okay it is a Question when they go equation as a sector. He puts a takeaway key consom model I'm cub use cutting it to home easy table so but I'll take the characteristic of requirement requirements are very important for the selection of an appropriate model there are number of situation and problem during requirement captioning and analyze it the details are given below take a requirement ki are requirement easily understand understandable and defined to have waterfall model no hampa spell AC defined Otiya prototype model man a Yotico keep prototype member town customer cup main role a ticket so happen no a buggy not in iterative, not in evolutionary, not in spiral only red red and waterfall is the one in which our requirement is known rather do we change requirement quite often so once a requirement is made in waterfall then we go to another stage so waterfall is absolutely known then we have prototype in prototype we can change requirement often because after customer evaluation so here yes will come we can't do in iterative we can't do evolutionary in spiral as I told you that one circle increases the cost so we can change the requirement on the second cost after one and the rest is not possible in red then comes can we define requirement early in the cycle so when we can define early requirement yes we can do it in waterfall, iterative and in red and we were able to do it in evolutionary development because we were doing defined requirement earlier so here also in evolutionary where we can't define requirement early in prototyping because it depends on customer feedback I have told you in spiral that we can't define it earlier we define it after every spiral so there is no requirement in this requirement is indicating a complex system to be built so what is there in this?
not in waterfall we can't make complex system from waterfall and complex system is prototyping may use cut a job mark complex system or it creative in enhancement may be used cut the evolutionary development may be used cut the o spiral maybe take a job our complex system or Tommy char face could use cutting it take a job how many do comment corrects the stick oh there are Tia Mardi table is status of development team the status of development in terms of availability effectiveness knowledge and intelligent teamwork is very important for the success of the project if we know about mentioned parameter and characteristic of the team then we may choose an appropriate life cycle model for the following now what is in this? we have less experience on similar project see in waterfall when our HDD or SRS is made then only we go to the second phase so here we can't take risk at all so our prototype is like a structure if customer will evaluate again and again then our requirement will increase again and again we can't do it in iterative, not in evolution in spiral in spiral we go to the second cycle then we go to the third cycle less expense or similar project less domain knowledge if domain knowledge is less then we can use waterfall because domain knowledge is new to the technology so there our implementation is in one phase so we can check that its domain knowledge is less in iterative finance model also we can take less domain knowledge for development then we can do it in evolution and in spiral also we can't take risk in prototype and red because once it is done then we we can't take risk in this less experience on tools to be used if someone has used tools less then we can take it in waterfall and in our spiral we can't take rest of it because it doesn't have idea of tools availability of training if required if we need training then we can provide training in iterative enhance and in evolutionary and in red rest is no then comes involvement of user sustainability of the project hence user participation if available plays a very significant role in the selection of an appropriate life cycle some issues are discussed in table user involvement in all phases see in prototype we have user because in every phase our user gives information and in red too limited user participation so this is limited user participation in waterfall because once user gave requirement we made SRS now user is very limited now user can't work in iterative, evolutionary and spiral so in this we have limited user participation then user have no previous experience of participation in similar project if there is no participation of user in any project then what is there in that project we can use it in prototype, iterative, evolutionary or spiral rest for waterfall and red no user can export of problem domain for that in prototype domain can be any of our user so I will tell you in stakeholder that user definition is real so what is user user is the one who is using our product it can be anyone if he has particular domain knowledge then it will help in prototype it will help in iterative and evolutionary and in red for this, yes in other waterfalls and spirals we don't need to be expert of our user so type of project and associated disk very few models are incorporate risk and assessment project type is also important for the selection of a model some issues are discussed let's say project is the enhancement of the existing system If existing system was lying, then we are making a new proposed system. So, what is in this? It will help us in iterative, evolutionary and red. Rest, it will not help anywhere.
Funding is stable for the project. See, funding will be fixed in the waterfall, in the prototype and rest will be fixed in red. Rest is not possible. Funding is stable because there cost can increase. As I told you in spiral, cost will increase on every cycle.
So, it is not possible there. High reliability requirements High reliability requirements will be required in iterative, evolutionary and spiral Rest are known Tight project schedule Prototype, iterative enhancement, evolutionary development, spiral and red All of these will require tight project schedule except for waterfall Use of reusable component What is in prototype, spiral and red Here we can use reusable component our resources time money scars to yannick a Joe Amara resources a who was Kelly Hamada prototype or spiral is may hum a resources key to what I Bucky in many a ticket to up with the on the cna yet GJ Hamada question become a keto and appropriate model may be selected based on the option in table in table say he hum QC be question kajal of this activity can say model come use caning a firstly we have to answer the question presented for each Categorized by cycling are yes or no in that each table Rank is importance of each category or question within the category in terms of the project for which we want to select a model The total number of circle responses for each column in that table decide an appropriate model We may also do with a category ranking Which is all the conflict between models if the total in either cases is close or the same So basically in table say hum is called but I suck their key quantum model I make up use cannot be a table unit to up on this connote so provide come up I will make a notes in next video which will help you a lot and I will upload the notes and provide you see this video is over here if you like the channel then like and subscribe because I will tell you about the book in the same way and I will provide the notes separately thank you so much guys see you in the next video