f28sd2 software design l01 overview of software processes l.
Skip this Video
Loading SlideShow in 5 Seconds..
F28SD2 Software Design L01. Overview of Software Processes PowerPoint Presentation
Download Presentation
F28SD2 Software Design L01. Overview of Software Processes

Loading in 2 Seconds...

play fullscreen
1 / 24

F28SD2 Software Design L01. Overview of Software Processes - PowerPoint PPT Presentation

  • Uploaded 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 'F28SD2 Software Design L01. Overview of Software Processes' - 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

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
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
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
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
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
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
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
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
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
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
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
Spiral development
  • The spiral model
    • Analyze a little, design a little, code a little
    • Defined by Barry Boehm in 1988
spiral development13
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
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
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
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
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
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
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
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
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
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

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


  • Andrew on Wednesdays
  • No tutorial on this Friday
  • 3 Tuesday lectures on UML
    • Use cases & activity diagrams
    • State machine diagrams
    • Class & interaction diagrams