Download
1 / 16
160 likes | 172 Views
Explore software engineering layers, life-cycle models, and compare various models. Define software engineering and learn the purpose behind it. Discover incremental and spiral models. Understand Build and Fix, Waterfall, Prototyping, and Incremental models in detail.
E N D
Software Engineering Introduction (The Process) James Gain (jgain@cs.uct.ac.za) http://people.cs.uct.ac.za/~jgain
Objectives • Define Software Engineering • Show the layers of Software Engineering • Order from Chaos - Introduce a range of software life-cycle models • Linear • Incremental • Spiral • Compare and contrast different models
Software Engineering Defined • Def 1: • The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines • Def 2: • The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software • Construct your own definition: • Purpose: solve the “software crisis” • Approach: using engineering-style practices
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) Software Engineering Software Engineering tools methods life-cycle model a “quality” focus
Life-cycle Models: Generic Phases • Definition (“what”): • Establish what the system requirements are • Use system engineering, project planning, requirements analysis • Development (“how”): • Establish how the system is to be realized – designed and built • Use software design, code generation, testing • Support: • Handle changes as the software environment evolves • Four flavours: correction, adaptation, enhancement, prevention • Umbrella Activities: • Ongoing across every phase • Project management, configuration control, risk management
Build and Fix Model • Chaos! No specification or design. Rework until the client is satisfied. • Only works on small projects • All changes are in coding phase (expensive) • Not a realistic option Build first version Modify until client is satisfied Maintenance Retirement
Waterfall Model • Adapted (in 1970) from conventional engineering cycle • Broken into phases, customers and developers sign-off documents at each phase, one-way trip • Cannot return to fix problems in previous phases Requirements Specification Design Implementation Integration Maintenance
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 Design Implementation Integration Maintenance
Prototyping Model • Early 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 Normal or modified Waterfall Customers test-drive mock-up Build/revise mock up
Incremental Models • Many systems evolve over time • Business and product requirements change over the (lengthy) period of a project • Linear (Waterfall and Prototyping) models cannot handle this • An iterative process which develops increasingly more complete versions of the software is called for • Two types: • Single Analysis phase followed by multiple incremental Design and Build phases • Everything is incremental (including Analysis)
Concurrent Incremental Model Integrate • Deliver increasing functionality at each build (usually n = 5..20) • First 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 Analysis Design Code Build 1 Integrate Analysis Design Code Build 2 Build n
Evaluating the Spiral Model • Emphasises Identifying and managing risks • Quit 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)
Other Lifecycle Models • Rapid 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 • Extreme 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
Even More Models • Formal 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 • CABTAB: • Code ABit, Test ABit • 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
Adaptability of Models • A life-cycle model (but not build-and-fix) will always be applied on every project BUT • The 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 • Processes can be lightweight or heavyweight (little or lots of administration overhead and control)
