Introduction - PowerPoint Presen by fjhuangjun


									F28SD2 Software Design
L01. Overview of Software Processes

     Monica Farrow
     Modified by Lu Fan
     December 2009
Introduction to the module
           Lu Fan (Tue)                     Andrew Ireland (Wed)

  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

  (IS)     Feasibility Studies               Testing & Analysis     (CS)

                          Revision & looking ahead
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 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

   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
   A sequential software development process
       Create a team, follow a well-documented process with fixed milestones
       Described by Winston Royce in 1970.
                                                  1) Collect & document all of
                                                     the system requirements
                                                  2) Produce a set of design
                                                  3) Write code that implements
                                                     the pieces specified in the
                                                  4) Integrate all of the pieces
                                                     and test to make sure the
                                                     system satisfies the
                                                  5) Package the system & ship
                                                     to the customer
Project costs
   For conventional projects, typically:
       2% of budget is spent on requirements   Design
       4% on specification                     Implementation
       1% on planning                          Maintenance
       6% on design
       20% on implementation
       and 67% on maintenance
        including correction of defects                    Planning
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
Requirements                     Iterative processes
capture                              Incremental delivery
                                     Spiral development
          System and
          software                   Rapid application development

                   and unit testing
                                        and system
 Rework the earlier stages
                                                       Operation and
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 delivery

   Problems
       Management
        Progress can be hard to judge & problems hard to find, because there is
        no documentation to demonstrate what has been done.
       Contractual
        The normal contract may include a specification; without a specification,
        different forms of contract have to be used.
       Validation
        Without a specification, what is the system being tested against?
       Maintenance
        Continual change tends to corrupt software structure, making it more
        expensive to change & evolve to meet new requirements.
Spiral development
   The spiral model
       Analyze a little, design a little, code a little
       Defined by Barry Boehm in 1988
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
   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)

   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

   Dissatisfaction with the overheads involved in design methods
    led to the creation of ‘agile’ methods
   Agile manifesto
       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 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)

   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 (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 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

   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

   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
     Problems with     New business                         Information Systems
     existing system   opportunities       IS
                                        planning            Development Lifecycle
Managerial                                                  David Avison & Hanifa Shah
 directive        Feasibility    Feasibility
                    study       study report                1997

                  Systems           User       Project       Resource      Staff     Methods
                investigation   requirements    plans      requirements assignment   and tools

                                   Current         System
                   Systems         system
                   analysis                     requirements
                                  data flow

                   Systems      New system       System      Training and
                    design       data flow     specification test plans

              Implementation     Programs      Procedures Documentation

                                                                               New system
                  Review        Evaluation               New problem           in operation
                maintenance       report                  statement?

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

To top