Skip to content

Development Models

Ad-hoc development

in ad-hoc development, we create software without any formal guidelines or process.

Some disadvantages of ad-hoc development are: * some important actions (testing, design) may go ignored * not clear when to start or stop doing each task * does not scale well to multiple people * not easy to review or evaluate one's work The later a problem is found in software, the more costly it is to fix.

The software lifecycle

The software lifecycle contains series of steps / phases, through which software is produced. It can take months or years to be completed.

goals of each phase are: * mark out a clear set of steps to perform * produce a tangible document or item * allow for review of work * specify actions to perform in the next phase

Lifecycle phases

the standard phases are: * Requirements Analysis & Specification * High-level (Architectural) Design * Detailed (Object-oriented) Design * Implementation, Integration, Debugging * Testing, Profiling, Quality Assurance * Operation and Maintenance

However, these are other pssoible phases: * risk assessment: examining what actions are critical and performing them first (part of Spiral model) * prototyping: building a rough/partial version of the product and using it to guide design decisions

Software Development Models

Several models for developing software have been proposed, varying the order and frequency in which the aforementioned stages occur:

  • Code-and-fix: write some code, debug it, repeat until finished
  • Waterfall: perform the standard phases (requirements, design, code, test) in sequence
  • Spiral: assess risks at each step, and do the most critical action immediately
  • Evolutionary prototyping: build an initial requirement spec, code it, then "evolve" the spec and code as needed
  • Agile Methodology: agile software development is based on an incremental, iterative approach.

Pros/Cons of Usings Models

the models have these advantages * decomposing workflow * helps to understand and manage the process * can be used as a management tool

and the limitations of models are * a model is just a model: abstracts away some aspects and highlights others * artificial constraints * compromises with model are often necessary: as with almost everything in software engineering * risk of overemphasizing the process: the process is not the end in itself; product delivery is

Evaluating models

These are the criterias for evaluation of models: * Risk management * Quality / cost control * Predictability * Visibility of progress * Customer involvement and feedback

Roughly speaking the aim is to have a good, fast, and cheap model. But you can't have all three at the same time.

Code-and-fix model

The advantages of using code-and-fix model are: * no planning whatsoever; little management overhead * applicable for very small projects and short-lived prototypes

And these are the disadvantages of using code-and-fix model: * code becomes expensive to fix (bugs are not found until late in the process) * code didn't match user's needs (no requirements!) * code was not planned for modification, not flexible

Waterfall model

Waterfall model is perhaps the most common model for software development.

The benefits of waterfall model are: * formal, standard; has specific phases with clear goals * good feedback loops between adjacent phases

And the drawbacks are: * rigid, too linear; not very adaptable to change in the product * requires a lot of planning up front (not always easy / possible) * assumes that requirements will be clear and well-understood * costly to "swim upstream" by going back to a previous phase * Nothing to show to anxious customers ("We're 90% done!")

Spiral model

Spiral model breaks up the project into mini-projects based on risk * purpose: risk reduction * example: in first phase, * great when charting new territories (with high risks)

Roughly speaking these are the steps taken at each loop of the spiral: * determine objectives, options, constraints * identify risks * evaluate options to resolve the risks * develop and verify any deliverable items * plan the next phase * commit to approach for next phase

The benefits of spiral model are * provides early indication of unforeseen problems * as costs increase, risks decrease * always addresses the biggest risk first * focuses attention on reuse * accommodates changes, growth * eliminates errors and unattractive choices early * limits to how much is enough (not too much design, reqs, etc) * treats development, maintenance same way

And the problems of spiral model are: * complicated * relies on developers to have risk-assessment expertise * possibly more management overhead to assess risk * need for more elaboration of project steps (clearer milestones) * matching to contract software (doesn't work well when you're bound to a fixed inflexible contract)

Evolutionary prototype model

The idea behind evolutionary prototype model is to build an initial requirement spec, code it, then "evolve" the spec and code as needed. Each repetition is an evolution of the code, not necessarily bug fixes.

The benefits of evolutionary prototyping are: * produces steady signs of progress * useful when requirements are not very well known, changing rapidly, or customer is non-committing * allows close customer involvement * "What do you think of this version?" * can improve customer confidence / satisfaction * customers must be available on a short notice to give feedback

And the possible problems of evolutionary prototyping are: * sometimes difficult to distinguish from code-and-fix * assumes user's initial spec will be flexible; fails for: * separate pieces that must then be integrated * "information sclerosis": temporary fixes become permanent constraints * bridging; new software trying to gradually replace old * unclear how many iterations will be needed to finish * wrong order: makes lots of hard-to-change code