F28sd2 software design l01 overview of software processes
1 / 24

- PowerPoint PPT Presentation

  • Updated On :

F28SD2 Software Design L01. Overview of Software Processes Monica Farrow monica@macs.hw.ac.uk Modified by Lu Fan L.Fan@hw.ac.uk December 2009 Introduction to the module Andrew Ireland (Wed) Lu Fan (Tue) Intro to Software Processes Architectural Design UML – Use Case & Activity

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '' - sandra_john

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
F28sd2 software design l01 overview of software processes l.jpg

F28SD2 Software DesignL01.Overview of Software Processes

Monica Farrow monica@macs.hw.ac.uk

Modified by Lu Fan L.Fan@hw.ac.uk

December 2009

Introduction to the module l.jpg
Introduction to the module

Andrew Ireland (Wed)

Lu Fan (Tue)

Intro to Software Processes

Architectural Design

UML – Use Case & Activity

Function-oriented Design

UML – State Machine

Object-oriented Design

UML – Class & Interaction

Component-based Design

Design Patterns

Verification & Validation

Week 6&7

Feasibility Studies

Testing & Analysis



Revision & looking ahead

Software engineering l.jpg
Software engineering

  • Not very long ago in the history…

    • The 1940s – modern computers appeared

    • The 1950s – programming languages appeared

    • The 1960s – software crisis!

      • As a result of “chaotic software development process”

      • Projects ran over-time/budget

      • Software was inefficient/not able to meet requirements/never delivered

      • Codes were unmanageable/difficult to maintain

  • Software engineering:

    • Firstly proposed in 1968, NATO Software Engineering Conference

    • Cost-effective development of high-quality software systems

Software engineering4 l.jpg
Software engineering

  • Frederick Phillips Brooks, Jr.

    • “The Mythical Man-Month”

      • Essays on software engineering, published in 1975

      • Many important ideas, including:

        • Adding manpower to a late software project makes it later

        • The second-system effect

        • Advocacy of prototyping

    • “No Silver Bullet”

      • Essence and accidents of software engineering, published in 1986

      • Many important arguments, including:

        • Essential complexity – caused by the problem to be solved – cannot be removed

        • Accidental complexity – problems that we create on our own – can be fixed

        • Much of the accidental complexity has already been cleaned up – no silver bullet

The software process l.jpg
The software process

  • A structured set of activities required to develop a software system –Sommerville

    • Specification Design Validation Evolution

  • A framework for the tasks that are required to build high-quality software –Pressman

  • A process defines who is doing what, when and how to reach a certain goal –Jacobson, Booch, Rumbaugh

  • Several models for such processes, e.g. waterfall, spiral, agile and extreme programming

    • A.k.a. software lifecycle models, software development methodologies…

Waterfall process model l.jpg
Waterfall process model

  • A sequential software development process

    • Create a team, follow a well-documented process with fixed milestones

    • Described by Winston Royce in 1970.

  • Collect & document all of the system requirements

  • Produce a set of design documents

  • Write code that implements the pieces specified in the design

  • Integrate all of the pieces and test to make sure the system satisfies the requirements

  • Package the system & ship to the customer

Project costs l.jpg
Project costs



  • For conventional projects, typically:

    • 2% of budget is spent on requirements

    • 4% on specification

    • 1% on planning

    • 6% on design

    • 20% on implementation

    • and 67% on maintenanceincluding correction of defects





Waterfall criticisms l.jpg
Waterfall criticisms

  • Projects are seldom so clear-cut and linear

    • It’s usually late in the project before a working version is available for user to test and criticise.

    • Misunderstandings are not discovered until nearly complete and the problems are expensive to fix.

    • The earlier an issue is identified, the smaller the cost – errors detected in testing phase may be 50 times more costly to fix than if they were detected during requirements or design phases.

  • Most require some iteration

    • Waterfall is often modified with arrows back to any stage to show this.

Waterfall model with iterations l.jpg
Waterfall model with iterations

Requirements capture

  • Iterative processes

    • Incremental delivery

    • Spiral development

    • Rapid application development

System and

software design

Implementation and unit testing

Integration and system testing

Rework the earlier stages

Operation and maintenance

Incremental delivery l.jpg
Incremental delivery

  • Descriptions:

    • The development & delivery is broken down into increments, each delivering part of the required functionality.

    • User requirements are prioritised & the highest priority requirements are included in early increments.

    • Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

  • Advantages:

    • System functionality is available earlier – accelerated delivery

    • Early increments help elicit requirements for later increments

    • The highest priority system services tend to receive the most testing

    • Lower risk of overall project failure

Incremental delivery11 l.jpg
Incremental delivery

  • Problems

    • ManagementProgress can be hard to judge & problems hard to find, because there is no documentation to demonstrate what has been done.

    • ContractualThe normal contract may include a specification; without a specification, different forms of contract have to be used.

    • ValidationWithout a specification, what is the system being tested against?

    • MaintenanceContinual change tends to corrupt software structure, making it more expensive to change & evolve to meet new requirements.

Spiral development l.jpg
Spiral development

  • The spiral model

    • Analyze a little, design a little, code a little

    • Defined by Barry Boehm in 1988

Spiral development13 l.jpg
Spiral development

  • Descriptions:

    • Incremental development, delivery, iteration, evaluation & feedback.

    • The project moves continually from planning of the next increment, to risk assessment, through implementation and evaluation.

    • PM can terminate project at any point, while ensuring that the user gains some benefit from each increment.

    • Focuses on prototyping and formalises an evolutionary approach to software development.

    • Requires an explicit risk analysis during each cycle.

    • User involvement throughout the development process.

    • Validation and prioritisation of requirements.

  • Tends to work best for small projects.

Software prototyping l.jpg
Software prototyping

  • A prototype

    • simulates some of the features of the eventual program

    • may be completely different from the eventual implementation

  • Advantages

    • enables software engineers to understand the problem domain and the user requirements

    • allows users to provide better & more complete feedbacks

  • Types

    • Throwaway prototyping – the model will eventually be discarded

    • Evolutionary prototyping – constantly refine a functional model

    • Incremental prototyping – merge several prototypes in an overall design

Rapid application development rad l.jpg
Rapid Application Development (RAD)

  • RAD was Initiated in the 1990s for projects with a rapidly changing business environment, where to arrive at a stable, consistent set of system requirements is often impossible.

  • In these cases, a waterfall model of development is impractical. An approach to development based on iterative specification and delivery is the only way to deliver software quickly.

  • Characteristics:

    • Concurrent specification, design & implementation

    • Minimal planning, specification & documentation

    • End users evaluate each increment & make proposals for later increments

Agile methods l.jpg
Agile methods

  • Dissatisfaction with the overheads involved in design methods led to the creation of ‘agile’ methods

  • Agile manifesto www.agilemanifesto.org

    • Individuals and interactions rather than processes and tools

    • Software development rather than exhaustive documentation

    • Working with the customer rather than contract negotiation

    • Openness to change rather than following inflexible plans

  • Agile methods are probably best suited to small/medium-sized business systems or PC products.

Agile methods17 l.jpg
Agile methods

  • Principles:

    • Individuals & interactions

      • In the development world, people are more valuable than computer tools

      • Face-to-face conversation is the most efficient form of communication

    • Working software

      • Deliver software often (weekly)

      • Working software is the primary measure of progress

    • Customer collaboration

      • Customer needs come first

      • Feedback from customer rather than planning

    • Responding to change

      • Even late changes in requirements are welcomed

Extreme programming xp l.jpg
Extreme Programming (XP)

  • One of the best known agile methods

  • Ground rules:

    • Small team (2 to 12)

    • Continuous access to customers – needs an “on-site customer”

    • OO design and code – Smalltalk, Java

    • Change management system – code and tests

    • The system is always “working” (growing functionality over time)

    • Development cycle – 4 to 12 months (new release every 2-3 months, internal iterations every two weeks)

    • Not for life-critical systems (heart monitor, nuclear power plant, avionics systems, etc.)

Extreme programming xp19 l.jpg
Extreme Programming (XP)

  • Principles:

    • Planning

      • Do project planning via “user stories” – interview the customer

      • Start each day with a “stand-up meeting” – choose task & partner for the day

    • Designing

      • Keep the design simple – use the simplest thing that could work

      • Code refactor as needed

    • Coding

      • Pair programming – all code is reviewed as it is written

      • Code unit tests first – test-driven development

    • Testing

      • Unit tests for all code

      • Acceptance tests for each user story

Agile vs xp l.jpg
Agile vs. XP

  • Agile is a generalisation of XP, featuring

    • Small team sizes

    • Short development iterations – release at regular intervals

    • Continuous testing, e.g. daily regression tests

    • Collecting customer requirements using scenarios

    • Informal modeling techniques, e.g. CRC cards, simple drawings

    • Adaptive planning based on reprioritisation by the customers

  • XP is a radical agile method, requiring

    • On-site customer & planning by user stories

    • Pair programming

    • General-purpose developer

    • Unit tests for everything

  • Existing processes can be adapted to be more “agile”

Key points so far l.jpg
Key points so far

  • Software processes are the activities involved in producing and evolving a software system.

    • specification, design, implementation, validation and evolution.

  • Waterfall model describes the software development as a sequential process.

  • Iterative models describe the software development as a cycle of activities.

  • RAD, including Agile & XP, have concurrent specification, design and implementation.

  • There is no ideal process model

    • Largest software vendors, e.g. Microsoft & IBM, still primarily rely on traditional waterfall methodologies with some degree of spiraling.

Information systems lifecycle l.jpg
Information systems lifecycle

  • Software lifecycle models

    • concentrate on design & implementation of a software system

    • lack an overall picture of the organisation and its business processes

  • Information systems lifecycle models extend software lifecycle models by adding

    • Feasibility study

    • Review during maintenance

    • System is an open one

    • Operation feeds back to design

Slide23 l.jpg

Information Systems

Development LifecycleDavid Avison & Hanifa Shah


Problems with

existing system

New business









study report












and tools



data flow







New system

data flow



Training and

test plans





New system

in operation






New problem


Slide24 l.jpg

  • Andrew on Wednesdays

  • No tutorial on this Friday

  • 3 Tuesday lectures on UML

    • Use cases & activity diagrams

    • State machine diagrams

    • Class & interaction diagrams