F28sd2 software design l01 overview of software processes
Download
1 / 24

F28SD2 Software Design - PowerPoint PPT Presentation


  • 382 Views
  • Updated On :

F28SD2 Software Design L01. Overview of Software Processes Monica Farrow [email protected] Modified by Lu Fan [email protected] December 2009 Introduction to the module Andrew Ireland (Wed) Lu Fan (Tue) Intro to Software Processes Architectural Design UML – Use Case & Activity

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

PowerPoint Slideshow about 'F28SD2 Software Design' - 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 [email protected]

Modified by Lu Fan [email protected]

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

(IS)

(CS)

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

Requirements

Specification

  • 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

Planning

Design

Implementation

Maintenance


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

1997

Problems with

existing system

New business

opportunities

IS

planning

Managerial

directive

Feasibility

study

Feasibility

study report

Systems

investigation

User

requirements

Project

plans

Resource

requirements

Staff

assignment

Methods

and tools

Current

system

data flow

System

requirements

Systems

analysis

Systems

design

New system

data flow

System

specification

Training and

test plans

Implementation

Programs

Procedures

Documentation

New system

in operation

Review

and

maintenance

Evaluation

report

New problem

statement?


Slide24 l.jpg
Next

  • Andrew on Wednesdays

  • No tutorial on this Friday

  • 3 Tuesday lectures on UML

    • Use cases & activity diagrams

    • State machine diagrams

    • Class & interaction diagrams


ad