4 Software Development Life Cycle II
R. Baskaran
Once this modification is been carried out and my client is found to be satisfactory I will be giving it for post delivery and maintenance. So after it is been deployed to the end user it should be maintained. So then I come to a retirement phase. So anything that is been mapped on a full line that is called development phase whereas a nything that is mentioned in the diagram with a dotted line it is called maintenance phase. As you can very well see there are no design involved in it. Basically I start developing with whatever methodology I want to build it. Basically if you ask me a question of what sort of projects would work better on a code and fix model. Anything which is very simple in terms of understanding once the client specifies the complete requirements of the product at a simplest level and I find this particular project as very simple to be done I can directly start coding and fix up whatever errors that turns out. So there has been no specification designed for this particular model. So this being the easiest way to develop a software instead this should have been the first model, build and fix or code and fix would be a the first model before we arrive at a sequence of phases to be carried out. And in a way although it seems to be pretty easy as students you might be developing a code and fix model. Because during laborator y you will be directly involved coding once having said problem of Fibonacci series or to write a program to find 1,- 2,3-4 this series of sequence although I say a problem statement you can directly code on it. It does not require a complete set of requirements . Likewise it seems to be the easiest way to develop a software. Although it is easy to develop it requires quite a lot of maintenance. And the maintenance is not as estimated it is much costlier than what we have expected.
The most expensive way for maintenance and maintenance seems to be a nightmare many a times. Looking further at this code and fix model product is implemented without requirements or specifications or any any attempted design which exactly means I have never posted on the requireme nts I basically try to understand there is no documentation related to the requirements. There has been no documentation towards specification and there has been no design specification also. So the developer simply throw code together and rework it as many time as necessary to satisfy the client. This is the fundamental idea behind code and fix model where the developer simply understand what is to be developed and tries to satisfy the clients as much as possible. So it is used in a smaller project and it is totally unsatisfactory for projects of unreasonable size. So as it has clearly mentioned this kind of development would work much better for a simpler projects are for a small project. Anything which is to be coded between 50 -100 lines of code or a maximum 200 lines of code would work on this kind of model. But then when I look at certain complex activities where design is utmost required this model may not be preferable. So this particular model is totally unsatisfactory for projects or products that a re to be developed with software for any unreasonable size. Further to look about this code and fix model this model starts with an informal general product idea and just develops code until the product is ready. So it basically tries to concentrate again and again on the coding aspect of it until I say the product is ready to be delivered to the client or money or time runs out. Work is in random order, I can work on anything that I find much feasible. So this corresponds with no plan. Some of the advantages of this particular code and fix model will involve there is no administrative overhead found towards this code and fix model. Signs of progress in terms of code early in the life cycle development model so we have skipped on the requirements we have skipped on the analysis we have skipped on the design phase we have directly landed on the coding phase. So any person who is of low experience anyone one can use this particular model. So this is just a beginning for a small proof of concept projects and for example as a part of risk reduction. So a project which basically can be a proof of concept at the beginning which does not involve a major quantum of work can be shown as this model type.
Some of the disadvantages, majorly this is been advantageous there is no design no specification no documentation available so it is highly dangerous in nature. And further if you could refer to the previous session was talking about planning I was talking about visibility of the project. So this doesn’t even cover on the planning aspect and the visibility aspect so there is no visibility and control over the project, and we don’t have to estimate on the resources also there are no hard and fast rules towards deadlines and some of th mistake which have mentioned towards this particular model are hard to detect and correct. So many a times as I have started coding on this particular aspect I may not understand the risk involved towards this product and some times I may go on error also. My entire intention is to satisfy my clients. So if I am to largely towards satisfying my clients my clients expectation would often change which cannot be adopted by way where lot of errors might turn up. So mistakes are hard to detect and correct and impossible this particular model is impossible for large projects and it comes out with largest communication breakdown and it is a major chaos for us. So for these specific reasons towards code and fix model and some of the disadvantages of the previous model called waterfall model we wish to proceed with certain other model called spiral model.
This particular spiral model has advantage towards one specific event which is called a risk management activity. As for as waterfall model and code and fix is concerned we have not majorly concentrated on the risk factors on the beginning of the requirements collection phase. Whereas this spiral model talks more of a risk and the outcome towards a product. So this is the primary objective towards working on a spiral model. End users are hard to obtain define it is natural to develop a software in an experimental way. For example we can build some software see if it meets customer requirements if not go to one step 1 else stop. So this loop will approach gives rise to structured iterative life cycle models. That means I am asked to develop a software if it meets the entire requirements given by my customer, if it is all been met I continue otherwise I stop. So this is been an iterative process so long , it is been a structured iterative life cycle model and this particular model is been initially coined by Boehm, called Boehm’s Spiral Model in 1988 he developed a model called spiral model as an iterative model which includes risk analysis and risk management. So these two are mentioned to be the key ideas behind the spiral model, O ne is called risk analysis the other one would be risk management. Now look at the entire model structure where it is been divided into 4 phases. We will start with the first phase which is called determine objective alternates a nd constraints. SO given any specific project the main objective of the project is to understand the objective behind why I have to approach on the particular problem so first we try to understand the objectives of the project, are there any alternate flows in case of any errors found and are there any projects constraints majorly that we were talking at the beginning of session 4 we were talking about staff, money, infrastructure, time. So these 4 are the underlying facts about the constraints when we are about look at these constraints there are so many issues that might come across when we work on the project. So I would start on the project at this level which is not at the index, so I would initially understand on all the aspects of the objectives which takes some of my time so I work back I understand the complete requirements of the project then I start building up of prototypes initially. So as a second phase the first phase is to basically figure out what my objectives are what my alternatives are what my constraints are the second phase is to majorly talk about evaluating the alternatives identifying and resolving the risks, so whatever risk that has been pointed out during the alternative phase where and all the risk majorly arises those will be sorted and prototype being built at phase 2. At phase 3, its a typical process where we develop verify and produce it to the next level. At phase 4 we will majorly concentrate on the planning towards next phase so it revolved around only these 4 phases, I repeat whatever I have said, phase 1 is more on talking about objectives alternative and constraints, phase2 is about identifying and resolving risks, phase 3 is about developing and verifying next level products, phase 4 is about planning for next phase, so when we are at the phase 1 we will be talking majorly on the objectives and whatever objectives that we have defined at the beginning we will be working on those objectives as a development and as a prototype. A simplest prototype will be built. And we will be going across the sequence of phases only at phase 3 where we exactly develop and verify on the next level of the product. And if you look at the entire structure the proof of concept requirements planning design and validation verification detailed design coding testing aspects of it is only 25% of the overall development phase. That is at the phase 3. It I involve all four phases only 25% of the time I will be talking about these development and verification the rest of the times I will be either concentrating on the risk or at the development of the prototype by looking at the various alternatives. So this particular picture is been plotted towards different modes of operation different sequences of the particular model towards estimated with respect to the cost so each cycle of this particular model is been estimated with determining objectives specificity constraints generating alternatives identifying risks resolving the risks developing the next level product and planning for the next cycle.
- http://www.tutorialspoint.com/sdlc/sdlc_spiral_model.htm
- http://ecomputernotes.com/software-engineering/build-and-fix-model
- https://zone.ni.com/reference/en-XX/help/371361J-01/lvdevconcepts/lifecycle_models
- Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill,2001.
- Pankaj Jalote, “An Integrated Approach to Software Engineering”, Second Edition, Springer Verlag,1997.
- Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000.