Lecture 3 - Software Life-Cycle Models

Lecture 3 - Software Life-Cycle Models

1. Software Engineering Problems

   • Complexity
     • Most complex human construct
   • Conformity
     • Often must fit into existing system
   • Changeability
     • Requirements change over time
   • Invisibility
     • Difficult to visualise what is happening

2. The Software Life-Cycle

   • The series of phases through which a software product passes from intial conception through to its final retirement from use

3. Build-And-Fix Model

   • 'Traditional'
   • No Formal Specification/Development Plan
   • Code written and re-written until it approximates what is required
   • Severe problems encountered for anything - but very small programs
     • Difficult to amend program to accommodate changing requirements

4. Waterfall Model

   • Attempted to separate design and implementation
   • Formalise process of design
   • Faults in previous phase often become apparent during subsequent phase
     • Incompleteness
     • Ambiquities
     • Contradictions
   • Revisions of previous phase
   • Problems:
     • Design documents produces are only useful if comprehensible to the clients and developers
     • Many unskilled/untrained Software Engineers work within the industry
     • Clients/Users generally not be able to determine if design reflects their requirements
     • Software Designed in isolation : no account taken of changing technology/competing products

5. Rapid Prototype Model

   • Similar to waterfall but within initial prototype
   • Working model representing subset of finished product
   • Concentrates on user interface design to demonstrate to clients
   • Prototype used to guide design of specification documents and give insights to problems in implementation
   • Fewer faults often found with this model

6. Incremental Model

   • Decompose product into a number of components each designed and built separately (termed builds)
     • Each component delivered to client when complete
       • Allows partial utilisation of product and avoiding long development time
       • Large initial capital outlay with subsequent long wait avoided
       • Traumatic effect of introduction completely new system all at once removed
   • Problems
     • Need to integrate each new build with previous builds and any existing systems
     • Decomposing product into builds not trivial
     • Too few builds and each build degenerates into Build-And-Fix
     • Too many builds leads to little added utility from each build

7. Spiral Model (Refer to Diagram)

   • Software development proceeds from centre outwards in a spiral
   • Current cost of project proportional to straight line distance from current point to centre
   • Each cycle represents a phase
   • Risk Analysis
     • Most significant addition to spiral model
     • Problems Include:
       • Hardware Manufacturers/Sub-Contractors may go bankrupt
       • Key personnel may leave company
       • Key groups/personnel not competent to design product
       • Better Competing Product Released
       • Technological Breakthroughs make product redundant
       • Product may not integrate properly despite design
       • Constraints on product performance (e.g. speed) not met by product
       • Client rejects product or changes requirements during developement
   • Analysis of Spiral Model
     • Prototypes produced at each stage help allieviate some risks
       • Timing Constraints (Especially for real time systems)
       • Client Acceptance of Design
       • Integration Problems
     • Disadvantages of Spiral Model
       • Some risks easier to evaluate than others
       • When external companies are involved, contracts often signed at outset
         • Value of subsequent risk analysis this compromised unless contracts may be re-negotiated
       • Cost of Risk Analysis prohibitive except for large (usually entirely in-house products

8. Fountain Model

   • Better for OOP compared to Waterfall
     • Circles represent each phase
     • Arrows represent iteration of phase
   • Phases overlap more than Waterfall
   • 'Natural Gravity' of Diagram infers repeated re-analysis of earlier phases
   • Care required with overlapping phases or model will degenerate into Build-and-Fix

9. Programming Language Paradigms

   • Imperative
     • Sequence of Instructions indication how to complete a task
     • 'Traditional Languages'
   • Declarative
     • Definitions of what a solution should consist of
   • Object-Orientated
     • Encapsulation of properties and methods
     • Inheritance of classes