F28SD2 Software Design

1
F28SD2 Software Design

• Overview of Software Processes
• Monica Farrow
• EM G30 monica_at_macs.hw.ac.uk
• Material available on Vision

2
Introduction to the module

• In this module we start to look at the
  development of software engineering projects,
  initially focussing on design
• Software processes an overview - today
• Architectural, functional and object-oriented
  design
• Unified Modelling Language
• Industry standard for object-oriented modelling
• Verification and validation
• Testing (CS students)
• Feasibility studies (IS students)
• Looking ahead

3
The software process

• The software process is
• A structured set of the activities required to
  develop a software system
• Specification
• Design
• Validation
• Evolution. Sommerville
• 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

4
Software engineering

• Software engineering encompasses software
  processes as well as the associated technologies
  technical methods and automated tools.
• The software engineering module in 3rd year
  continues the study of the processes and
  technologies

5
Essential difficulties of software engineering

• In 1987 Fred Brooks published a paper No Silver
  Bullet, in which he stated that building
  software will always be hard because of
• Complexity.
• Each project is different to the last, with large
  numbers of statements. Its not like designing
  one car and building lots of them.
• Simplified models lose some essential properties
  of the project.
• Leads to problems in communication and management
• And....

6
Essential difficulties of software engineering

• Conformity
• Software must conform to existing systems and
  legislation.
• Changeability
• External causes dictate the need for change, or
  people discover new uses for the product
• Invisibility
• Software cannot be visualised. Although diagrams
  can be drawn, it is not possible to show all
  aspects simultaneously.
• This paper has been much discussed, but these
  essential difficulties remain.

7
Problems with software systems

• Dec 2008 Department for Transport
• the computer system was inadequately procured
  and tested, and that staff do not trust it
• Connecting for Health
• Electronic records for every patient. 2yrs behind
  schedule, costs twice as much as originally
  planned.
• Student Loans 2004
• New system could not cope with volume of
  enquiries
• Ministry of Defence 1990s
• 34 billion spent on a system which was never
  used (too incompatible)

8
Process improvement

• The desire for improvement of process has led to
  a number of models of the software construction
  process.
• Most divide it into stages or phases, with
• a notion of progress towards a satisfactory
  product and
• feedback and iteration to improve or correct at
  each stage.
• The most famous of these is the waterfall
  lifecycle model originally proposed by Royce.

9
Waterfall process model
Requirements capture
System and software design
Implementation and unit testing
Integration and system testing
Youll find slightly different versions elsewhere.
Operation and maintenance
10
Waterfall comments

• Had its roots in 1970s when we felt an
  engineering discipline was vital to developing
  software.
• When Royce proposed it he didnt call it
  waterfall and it had feedback loops in it to
  encourage his visionary notion of do it twice,
  later echoed by Brooks.
• Accountants love waterfall without loops as it
  provides clear contractual milestones and
  deliverables to hold people accountable against.
• Projects are seldom so clear-cut and linear.
• Most require some iteration. W/Fall is often
  modified with arrows back to any stage to show
  this.

11
Waterfall criticisms

• Its 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.
• However, the modified version is useful when the
  requirements are well-understood and are unlikely
  to change radically during development

12
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 maintenance including correction of
  defects (11).

Requirements
Specification
Planning
Design
Implementation
Maintenance
13
Generic software process models

• The waterfall model
• Separate and distinct phases of specification and
  development.
• Evolutionary development
• Specification, development and validation are
  interleaved.
• Component-based software engineering
• The system is assembled from existing components.
• There are many variants of these models

14
The Role of Prototyping

• Engineers frequently build working models, or
  prototypes to help them understand clients'
  requirements and jointly explore possible
  solutions.
• Here is a prototypefor a fold-out mobile
  phone,to enable easy video-watching
• 8 Jan 2009

15
The Role of Prototyping

• The problems faced by software engineers are no
  less complex than the problems faced by other
  engineers
• So prototypes enable software engineers to
  understand the problem domain and the user
  requirements
• Prototypes imply user involvement, evaluation,
  feedback and iteration in the development process
• As communication between the engineers and the
  users improves, a better understanding of user
  requirements and technological constraints is
  achieved.

16
Evolutionary development

• 2 fundamental types
• Exploratory development
• Work with the customer
• Develop well understood sections
• Evolve by adding in new features
• Throwaway prototyping
• Experiment with poorly understand customer
  requirements
• Prototypes may not evolve into final system
• Difficult to measure progress
• Systems can be poorly structured
• More suitable for small projects
• A mix of approaches works best.

17
Component-based software engineering

• Based on systematic reuse where systems are
  integrated from existing components or COTS
  (Commercial-off-the-shelf) systems.
• Process stages
• Component analysis
• Requirements modification
• System design with reuse
• Development and integration.
• This approach is becoming increasingly used as
  component standards have emerged.

18
Process iteration

• System requirements ALWAYS evolve in the course
  of a project so process iteration, where earlier
  stages are reworked, is always part of the
  process for large systems.
• Iteration can be applied to any of the generic
  process models.
• Two (related) approaches
• Incremental delivery
• Spiral development.

19
The Hanging Rope Analogy
Iterative Delivery
Quality
Waterfall
Time
20
Incremental delivery

• Rather than deliver the system as a single
  delivery, the development and delivery is broken
  down into increments with each increment
  delivering part of the required functionality.
• User requirements are prioritised and 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.

21
Incremental development advantages

• Customer value can be delivered with each
  increment so system functionality is available
  earlier.
• Early increments act as a prototype to help
  elicit requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to
  receive the most testing.

22
Boehms spiral model
23
BOEHM'S Spiral Model

• Demonstrates incremental development and
  delivery, iteration, evaluation and 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.

24
BOEHM'S Spiral Model

• 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.

25
Rapid Application Development

• The Rapid Application Development (RAD) process
  was initiated in the 1990s for projects with a
  rapidly changing business environment, where it
  is often impossible to arrive at a stable,
  consistent set of system requirements.
• 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.

26
Characteristics of RAD processes

• The processes of specification, design and
  implementation are concurrent. There is no
  detailed specification and design documentation
  is minimised.
• The system is developed in a series of
  increments. End users evaluate each increment and
  make proposals for later increments.
• System user interfaces are usually developed
  using an interactive development system.

27
Advantages of incremental development

• Accelerated delivery of customer services.
• Each increment delivers the highest priority
  functionality to the customer.
• User engagement with the system.
• Users have to be involved in the development
  which means the system is more likely to meet
  their requirements and the users are more
  committed to the system.

28
Problems with incremental development

• Management problems
• Progress can be hard to judge and problems hard
  to find because there is no documentation to
  demonstrate what has been done.
• Contractual problems
• The normal contract may include a specification
  without a specification, different forms of
  contract have to be used.
• Validation problems
• Without a specification, what is the system being
  tested against?
• Maintenance problems
• Continual change tends to corrupt software
  structure making it more expensive to change and
  evolve to meet new requirements.

29
Agile methods

• Dissatisfaction with the overheads involved in
  design methods led to the creation of agile
  methods. These methods
• Focus on the code rather than the design
  feedback from people rather than planning
• Are based on an iterative approach to software
  development
• Are intended to deliver working software quickly
  and evolve this quickly to meet changing
  requirements.

30
Agile methods

• Agile methods are probably best suited to
  small/medium-sized business systems or PC
  products.
• There are several different agile methods, of
  which Extreme Programming (XP) is one of the best
  known.

31
Extreme programming

• Takes iterative development to extreme lengths
• Fast production of code in an efficient and
  intense manner that also allows changes in
  requirements to be quickly reflected in the
  system.
• Emphasis on speed and simplicity
• Uses Test Driven Development
• Writes tests first then code
• Uses pair programming
• Involves constant refactoring of the code
• Customer is deeply involved

32
Key points so far

• Software processes are the activities involved in
  producing and evolving a software system.
• General activities are specification, design and
  implementation, validation and evolution.
• Generic process models describe the organisation
  of software processes. Examples include the
  waterfall model, evolutionary development and
  component-based software engineering.

33
Key points so far

• Iterative process models describe the software
  process as a cycle of activities.
• Rapid Application Development, including Agile
  processes, have concurrent specification, design
  and implementation.
• There is no ideal process model. Choice varies
  according to the type of application and the
  people involved.
• These notes mostly from Sommerville SE8 ch 4 ch
  17

34
Information Systems lifecycle

• We have seen various types of software lifecycle
• Waterfall, spiral, agile...
• These
• concentrate on design and implementation of a
  software system
• models lack an overall picture of the
  organisation and its business processes
• A traditional structured design method extended
  in this manner is shown next
• (Based on Avison and Shah)
• The similarities are clear
• So are the new features

35
Problems with existing system
New business opportunities
Information Systems lifecycleAfter Avison and
Shah p71
IS planning
Managerial directive
Feasibility study
Feasibility study report
Systems investigation
Project plans
User requirements
Staff assignment
Resource requirements
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?
36
Whats similar?

• Stages rather like waterfall
• Repeats with review like spiral
• Progress in terms of artefacts

37
Whats added?

• Feasibility study
• Review during maintenance
• System is an open one
• Operation feeds back to design

38
Feasibility study

• Propose and evaluate alternatives
• Establish priorities
• Gather information
• Perform cost-benefit analysis
• Form options for computerisation
• Present conclusions
• The negative option is a valid option!

39
Review during maintenance

• Learning from experience
• Effectiveness of the solution
• Correctness of function
• Efficiency
• Suitability for the business process
• Effectiveness of the process
• Kept to time?
• Kept to budget?
• Lessons learned for future developments

40
System is an open one

• Take account of influences from the organisation
  which change over time
• Managerial directives
• often arbitrary
• but often dominate decision making
• New opportunities
• business process change requires system change
• Longer term information systems planning
• system change to maintain business process

41
Operation feeds back to design

• Operation reveals errors - maintenance in SE
• Operation reveals bottlenecks for the business
• Operation reveals new opportunities for business
• Operation reveals difficulties for users
• Summary from the original build a system then
  hand it over approach, we must be now more aware
  of the user and their environment.

42
Next

• Andrew on Wednesdays
• NO tutorial session this Thursday
• 3 Tue lectures on UML
• Diagrammatic language to model requirements,
  actions, states, classes....