Software Development Life Cycle (SDLC)

Development models

agile, spiral and waterfall


Development model approaches, including agile, spiral and waterfall
When you are faced with a big, complex job how do you tackle it? Do you leap into it and do bits here and there until you finish, occasionally going back to fix or add to bits you started before? Or do you start at step 1, conscientiously finish every part of it before moving to step 2? In IT there are several different philosophies - or models - of managing large, complicated software development projects. The ones you need to know are named agile, spiral and waterfall. Each is a type of a Software Development Life Cycle (SDLC) model. Note - there is no objective 'best' SDLC model. If there were, the others would no longer exist. Each model has its advantages and disadvantages.
ALL OF THEM share certain features. They all describe a process of steps to develop software or other products, from its original conception to its final deployment and evaluation. Depending on whom you talk to, the naming and number of SDLC steps vary a little, but they are essentially the same. VCAA's official SDLC (aka 'Problem Solving Methology' aka PSM) are: Analysis* of what the solution needs to do, and what attributes it should have. Design - Exactly how will it do those things? When it's finished, how will its success or failure be judged? Development - program the software, and/or build the product. Do testing, write documentation, and deploy the product so end-users get access to it. Some SDLC models make Deployment a separate step, but VCAA doesn't. Evaluation - using the success/failure criteria establish during Design, determine whether the solution is actually achieving the goals for which it was originally created. * See the study design The fact that VCAA dedicates 4 pages to it in the study design shows how much they love it. Pay attention to it.
Important distinctions: ANALYSIS v DESIGN Analysis does not try to explain how the solution will work. It just describes what it should be able to achieve. This is done by managers, executives, and stakeholders (people with a special interest or investment in the project - e.g. investors, partner companies). Design takes the analysis and works out a "how to" strategy including technologies and techniques. This is done by programmers and designers. TESTING v EVALUATION Testing - informal testing is done during development to ensure a product is producing accurate output, and can do all the jobs it was supposed to. Formal testing occurs at the end of development, using real-world end- users as guinea pigs, as a final guarantee that everything works as expected. Evaluation is done after the solution has been finished and has been in real-world use for some time to find out whether it is successfully achieving the organisational goals for which it was created. Example: A company creates a new website with the sole aim of increasing sales. The finished website has zero errors, attracts millions of visitors, and has rave reviews from website judges. After the site has been online for three months, company sales have not increased. The website's testing was fantastic because it operates perfectly. The website's evaluation is a disastrous failure because it does not achieve its original goal of increasing sales.
THE SDLC MODELS
THE WATERFALL MODEL The first SDLC, described in 1956. This brutal model works in a strictly step-by-step fashion: each step is completely and perfectly finished, reviewed and verified before starting the next step. Just like going over a a waterfall, you can't go backwards. This model is valued where late changes to needs, design, or construction would be prohibitively expensive (or indeed impossible) so 100% accuracy is needed from the very beginning to ensure success at the end. The only way to go back to a previous stage in the waterfall model is to completely scrap the project and start again. As I said - it's brutal, but it can save lots of time and money wasted due to insufficient planning. But... What happens if - halfway through a project - a rival company launches a product that is better than the one you are working on? What happens if unexpected technology changes occur, e.g. a brand new type of storage device is released that blows SSD out of the water? Or... The clients (the ones requesting and paying for the solution) originally asked for certain features but now change their minds as they see demo versions of the finished solution? Do you persevere with a product that is already obsolete even before it's finished? Do you scrap it? Or do you go back and tweak it? Sometimes, real-world market or technological pressures force a re-evaluation of a project to keep it relevant. Sometimes, a project model needs to be more f-l-e-x-i-b-l-e. And that is the Agile model. Note - there are several modified versions of the Waterfall model with overlapping phases, risk reduction, etc, but the basic model is all you really need to know.
THE AGILE MODEL The Agile model includes flexibility that the waterfall model lacks. It allows adaptive planning (to cope with changes to needs or developing technologies), development that can backtrack to incorporate new techniques or technologies, continual improvement and flexible responses to changes in requirements, capacity limits, or new problems (e.g. new laws that suddenly make your sofware illegal or subject to public ridicule.) Agile Features: It is iterative - allowing repeated work on previous steps. It is adaptive and evolutionary - capable of responding to real-world changes as the project proceeds. It monitors the social/technological environment and itself and adjusts itself appropriately as needed. It allows ongoing collaboration with clients - to incorporate new or changed needs they might have. There is no unchangeable contract signed at the beginning of the project. Developers and clients work closely and often during development. It frequently delivers updated versions of products based on consumer feedback, developing technology, and commercial competition. It prefers to fail early and often during development, rather than failing once, catastrophically at the end. It relies more on adaptation* than prediction. It adjusts to ongoing changes instead of aiming at an unalterable waterfall-style final goal. As has been said: "Agile = make it up as you go along. Waterfall: make it up before you start, live with the consequences" * Contrary to popular illiteracy, there is no such word as "adaption." It is always "adaptation"
THE SPIRAL MODEL Key words: Risk-driven. It is best used when end-needs are changeable or fuzzy. But it can be slow and expensive. It's basically a blend whatever other SDLC models (e.g. waterfall, agile or other) do the job best. Its creator, Barry Boehm, defined six necessary features of the spiral model: 1. It's best to use the waterfall model unless: the requirements are not fully known or might change; there may be high-risk consequences of doing it wrong; there is not enough time to develop the solution. 2. Keep in mind what stakeholders would consider a "win" for them. Consider alternative strategies to accomplish that win. Identify and prevent risks from those strategies. Get the approval of stakeholders for the strategies. Otherwise, risks may be too great, or stakeholders may find the solution unacceptable (and won't pay for it). 3. How much effort goes into each activity is guided by how much risk it poses. A risky step requires more effort to prevent problems. 4. If risk can be reduced by more detailed planning, do it. Less-risky components deserve less detailed design. 5. Is there a clear definition of what the client considers a "win" - and how to achieve it - by the time the solution is finished? Is everything (technology, training, documentation, publicity, maintenance and support staff etc) prepared for a "win" when the solution is launched? 6. Has the solution been provided with enough long-term maintenance, support, and upgrades for its expected lifespan?
CONCLUSION - Which one should you use? As with all theoretical models, none of these models will probably ever be used fully and unchanged in The Real World. Instead, each offers a set of useful philosophical approaches that can be adopted and adapted according to need and circumstance. Adopt, and adopt, as necessary.

Write to Mark Kelly or Tell me why you don't want to write to Mark Kelly or Look at this Yeah. I know which option you went for. (If I cry quietly, no one will hear)

All original content copyright © vcedata.com
All rights reserved.

This page was created on 2022-04-14 @ 13:59
Last modified on Friday 6 October, 2023 14:34