Process Models

1
Process Models

• Compiled by Bernard Otinpong

2
Objectives

• Identify the activities within Software
  Development
• Distinguish between Verification and Validation
• Explain the stages of the Waterfall Model
• Distinguish between throwaway and evolutionary
  prototyping
• Explain the advantages and disadvantages of
  prototyping

3
Introduction

• Software systems are often large and complex
• There is a clear need to be organized when
  embarking on a development.
• When setting about a software project, you need
• - a clear statement of what is required
• - a package of methods and tools
• - a plan.

4
Introduction contd.

• The plan of action known as a process model . It
  is a plan of what steps are going to be taken as
  the development proceeds.
• This term is derived as follows a process is a
  step or a series of steps.
• A process model is a model in the sense that it
  is a representation of reality.
• Like any model, a model is only an approximation
  of reality.

5
Introduction contd.

• A process model has two distinct uses
• -It can be used as a basis for the plan for a
  project. Here the aim is to predict what will be
  done.
• -It is used to analyze what actually happens
  during a project. Here the aim is to improve the
  process for the current and for future projects.

6
Introduction contd.

• There are several mainstream process models
• -seat-of-the-pants, do-it-yourself, or ad hoc
• -waterfall
• -prototyping
• -formal methods
• -spiral

7
The Components of Software Development

• During the development of a software system,
  there are several activities that must be carried
  out at some time
• - requirement engineering
• - architectural or large scale design
• - small scale design
• - coding
• - system integration
• - validation
• - verification
• - maintenance

8
Requirements Engineering

• At the start of a project, the developer finds
  out what the user (client or customer) wants
  software to do and records the requirements as
  clearly as possible. The product is a
  requirements specification.

9
Architectural (largescale) Design

• A software system may be large and complex. It is
  usually too large to be written as one single
  program. The software must be constructed from
  modules or components.
• Architectural, or large-scale design, breaks the
  overall system down into a number of simpler
  modules.
• The products of this activity are an
  architectural design and module specification.

10
Detailed Design

• The design of each module, or component, is
  carried out. The products are detailed designs of
  each module.

11
Coding

• The detailed designs are converted into
  instructions written in the programming language.
• The product is the code.

12
System integration

• The individual components of the software are
  combined together.
• The product is the complete system.

13
Maintenance

• The software is put into use. Sooner or later it
  will probably need fixing or enhancing. Fixing
  faults is part of maintenance. At some future
  time the users may want some enhancement made to
  the program. Making this change also constitutes
  maintenance.
• Software maintenance often goes on for years
  after the software is first constructed. The
  product is the modified software.
• In some process models, all of these stages are
  visible in other process models some of these
  stages vanish or become part of some other stage.

14
Validation and Verification

• Validation and verification are ways of checking
  that development has been done properly. Two of
  the major challenges of software development are
• - making sure that the software meets its
  users' needs
• - producing reliable software

15
Validation and Verification contd.1

• The terms "validation" and "verification"
  describe these two problems. The terms are
  sometimes confused or used interchangeably.
• Verification "Are we building the product
  right?"
• Validation "Are we building the right product?"

16
Validation and Verification contd.2

• One way of understanding the difference is that
  validation is to do with the clients' view of the
  system, while verification is concerned with the
  developers' view
• Another way of understanding the difference is
  that validation is to do with the external view
  of a system, while verification is concerned with
  the internal consistencies within the system.
• As is to be expected, both validation and
  verification are carried out continuously during
  software development.

17
Validation and Verification contd.3

• A significant example of validation is acceptance
  testing. The software is apparently complete and
  is demonstrated to its client and accepted by
  them as satisfactory.
• The inputs to acceptance testing are the client
  and the apparently completed software. The
  products are a sign-off document and an accepted
  system. The outcome is that the system complies
  with the requirements of the client.
• Two examples of verification are unit testing and
  system testing.

18
Unit Testing

• Each module of the software is tested in
  isolation. The inputs to unit testing are
• - the unit specification
• - the unit code
• - list of expected test results.
• The products of unit testing are the test
  results.
• Unit testing verifies that the behaviour of the
  coding conforms to its unit specification.

19
System Testing or Integration Testing

• The modules are linked together and the complete
  system tested. The inputs to system testing are
  the system specification and the code for the
  complete system.
• The outcome of the system testing is the
  completed tested software. System testing
  verifies that the system meets its specification

20
System Testing or Integration Testing (2)

• Verification is carried out after every stage of
  software development, except the 1st
  (requirements analysis). It is the way in which
  the correctness of each stage is checked.
• Current evidence suggests that many computer
  systems do not meet the needs of their users, and
  that therefore successful validation is a major
  problem in software engineers today.
• It is a common experience that users think they
  have articulated their needs to be software
  engineer. Then the engineer will spend months or
  even years developing the software only to find,
  when it is demonstrated, that it was not what the
  user wanted

21
System Testing or Integration Testing (3)

• It is too easy to blame the requirements analysis
  stage of development, because the basic problem
  is one of the quality of the communication
  between users and developers.
• Users do not know (and usually do not care) about
  technicalities, whereas the software engineer is
  often from a different culture.
• Worst of all is the problem of some common
  language for accurately describing what the user
  wants. The users are probably happiest in the
  natural language (e.g. English), whereas the
  software engineer would probably prefer some more
  rigorous language that would be incomprehensible
  to the users. There is a cultural gap.

22
System Testing or Integration Testing (4)

• A major problem with one of the main process
  models, the waterfall model, is that users do not
  see what the system does until very late in the
  development process. If the system does not meet
  their needs, an enormous amount of work may have
  o be redone.
• The essential problem with validation is that,
  given that there are difficulties with accurately
  describing users needs, developers need some way
  of demonstrating a working version of the
  software - a prototype - as early as possible .

23
Next Week

• The Waterfall model
• Feedback in the waterfall model
• Prototyping