1. Software Engineering Introduction (The Process) James Gain (jgain@cs.uct.ac.za)jgain@cs.uct.ac.za http://people.cs.uct.ac.za/~jgain

2. Objectives lDefine Software Engineering lShow the layers of Software Engineering lOrder from Chaos - Introduce a range of software life-cycle models  Linear  Incremental  Spiral lCompare and contrast different models

3. Software Engineering Defined lDef 1:  The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines lDef 2:  The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software lConstruct your own definition:  Purpose: solve the “software crisis”  Approach: using engineering-style practices

4. Software Engineering a “quality” focus life-cycle model methods tools A Layered Technology  Focus: the underlying philosophy. High quality means project timeliness because of less debugging and rework  Model: structured sequence of high-level tasks  Methods: technical tasks for building software  Tools: automated or semi-automated support (CASE)

5. Life-cycle Models: Generic Phases 1.Definition (“what”):  Establish what the system requirements are  Use system engineering, project planning, requirements analysis 2.Development (“how”):  Establish how the system is to be realized – designed and built  Use software design, code generation, testing 3.Support:  Handle changes as the software environment evolves  Four flavours: correction, adaptation, enhancement, prevention 4.Umbrella Activities:  Ongoing across every phase  Project management, configuration control, risk management

6. Build and Fix Model lChaos! No specification or design. Rework until the client is satisfied.  Only works on small projects  All changes are in coding phase (expensive) lNot a realistic option Build first version Modify until client is satisfied Maintenance Retirement

7. Waterfall Model lAdapted (in 1970) from conventional engineering cycle lBroken into phases, customers and developers sign-off documents at each phase, one-way trip  Cannot return to fix problems in previous phases Requirements Specification Implementation Integration Design Maintenance

8. Modified Waterfall Model  Well established and widely used  Driven by text documents (but also  )  Needs up-front requirements  Customers only see the product at the end Requirements Specification Implementation Integration Design Maintenance

9. Prototyping Model lEarly versions of the software are for demonstration and requirements purposes. They are meant to be discarded.  Users get a feel for the system  Developers learn how to build the real thing  Customer may imagine that the prototype is final  Initial quick fix choices may be carried over to later development Listen to customers Build/revise mock up Customers test-drive mock-up Normal or modified Waterfall

10. Incremental Models lMany systems evolve over time lBusiness and product requirements change over the (lengthy) period of a project lLinear (Waterfall and Prototyping) models cannot handle this lAn iterative process which develops increasingly more complete versions of the software is called for lTwo types: 1.Single Analysis phase followed by multiple incremental Design and Build phases 2.Everything is incremental (including Analysis)

11. Concurrent Incremental Model lDeliver increasing functionality at each build (usually n = 5..20) lFirst build is the core  Requires an open architecture that accommodates integration  Get partial functionality early  Allows specialisation (e.g. full time designers)  Not as well proven AnalysisDesignCode Integrate Build 1 AnalysisDesignCode Integrate Build 2 Build n

12. Evaluating the Spiral Model lEmphasises Identifying and managing risks lQuit if the risks can’t be quantified  Considers entire software life cycle  Adaptable  Only suitable for large scale project (cost of risk analysis is high)  Requires risk assessment expertise  Only works for Internal Development (where the plug can be pulled without contractual issues)

13. Other Lifecycle Models lRapid Application Development (RAD):  Iterative model that needs well-defined requirements and uses 4GL techniques  Rapid (60-90 days)  Requires sufficient human resources, the right type of modular application and low technical risks lExtreme Programming:  Controversial lightweight iterative model with unique features (e.g. pair programming)  Model adopted in this course and for CS2 projects  Works well for vague requirements  Unproven, only really good for small projects

14. Even More Models lFormal methods:  Development is driven by a mathematical specification üAttacks ambiguity, incompleteness and inconsistency; allows formal verification  Time consuming and expensive; requires extensive training; not good for customer communication lCABTAB: –Code A Bit, Test A Bit –Like “hacker” it originally had a positive meaning (used to describe successful OO iterative models) –But now a derogatory term for iterative models that degenerate into haphazard development

15. Comparing Models ModelStrengthsWeaknesses Build-and-Fix Fine for short programs not needing maintenance Inappropriate for nontrivial programs Waterfall Disciplined approach Document driven Final product may not meet client’s real needs Prototyping Helps to detail user’s requirements The prototype may outlive its usefulness Iterative Get early results Promotes maintenance May degenerate into CABTAB Spiral Incorporates features from other models Only suited to large-scale in-house development Component- based Supports re-use and iteration Expensive in the short term

16. Adaptability of Models lA life-cycle model (but not build-and-fix) will always be applied on every project BUT lThe most suitable model and details of phases (e.g. degree of rigor) will vary based on:  Type of project (scientific, embedded, business, etc.)  Characteristics of the project  Common sense judgment  Experience of the project team lProcesses can be lightweight or heavyweight (little or lots of administration overhead and control)