System Development Methods

CT00046-3-2

Structured Methodologies
 Topic & Structure of the Lesson

1. Principles of structured methodologies.

2. Phases in Waterfall methodology, Structured Systems
Analysis and Design Methodology (SSADM), and V-Model.
3. Strengths and weaknesses of structured methodologies.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 2

 Slide 3 (of 17)

Learning Outcomes

 By the end of this lecture, you should be able to :

1. Explain the underlying principles of Structured
Methodologies.
2. Describe the phases in Waterfall, Structured Systems
Analysis and Design Methodology (SSADM), and V-Model.
3. Identify the strengths and weaknesses of Structured
Methodologies.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 3

 Slide 4 (of 17)

Key Terms you must be able to use

 If you have mastered this topic, you should be able to use

the following terms correctly in your assignments and
exams:
 Structured Methodologies
 Waterfall Methodology
 SSADM
 V-Model

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 4

 Structured Methodologies Principles

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 5

Slide 5 (of 19)

Traditional / Structured Methodologies

 System development is organized into phases, with deliverables

and milestones to measure progress.
 Developed in the 70’s.
 Also known as Traditional Methodologies
 Very detailed steps explained.
 The formulation for beginners to develop a system.
 Requirements need to be clear and fixed.
 Focus on error free product
 Rigid and strict rules.
 Emphasis on full documentation.
 Example methodologies: Waterfall Model, Structured Systems
Analysis and Design Methodology (SSADM), V-Model.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 6
 Waterfall Methodology

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 7

 Waterfall Methodology

 Introduced in the 1970s by Dr. Winston W. Royce.

 Close to SDLC phases
 Can be used for almost all types of projects
 Highly structured and rigid - sequential development
process.
 One should move to the next phase only when its
preceding phase is completed and perfected.
 Promotes quality control of process and product.
 Emphasis on good documentation

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 8

 Waterfall Methodology
Phases
Requirements

Design

Implementation

Integration & Testing

Deployment

Maintenance

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 9

 Waterfall Methodology
Phases .. cont.

 Requirement Gathering and Analysis

– All possible requirements of the system to be developed are
captured and documented into System Requirement Specification
(SRS) document.
 System Design
– The SRS is studied, and system design is prepared.
– System Design helps in specifying hardware and system
requirements and helps in defining overall system architecture.
 Implementation
– With inputs from system design, the system is first developed in
small programs called units, which are integrated into the next
phase.
– Each unit is developed and tested for its functionality which is
referred to as Unit Testing.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 10

 Waterfall Methodology
Phases .. cont.
 Integration and Testing
– All the units developed in the implementation phase are
integrated into a system after testing each unit.
– Post integration the entire system is tested for any faults and
failures.
 Deployment
− Once the functional and nonfunctional testing is done, the
product is deployed in the customer environment or released
into the market.
 Maintenance
– Aimed to fix some issues which come up in the client
environment.
– Also, to enhance the product some better versions are released.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 11
 • Watch the following video to find out more about the Waterfall
Methodology

Waterfall Methodology        

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 12

 Structured Systems Analysis and
Design Methodology (SSADM)

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 13

 Structured Systems Analysis and
Design Methodology (SSADM)

 Popular methodology
used in the late 80s
 Rigid and document-
led approach to
system design
 Good for projects with
complex database
design.
 Has strategies to align
business needs with
system development.
 Ends at design stage.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 14

 SSADM Phases

Decide how viable the project really

is.

Investigation of current system and

provides users with options that
meet their requirements.

Refine the requirements based on

the selected business system option.

Evaluation of the best technical

products and provides detailed
specification.

Covers everything needed for

construction and implementation.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 15

 Project Definition

• Before a project can begin, we must establish the

objectives and the areas of the business which are
involved.
• The need to begin a new project may arise from a variety of
causes. For example:
– It may be that the existing manual system has proved
inadequate to handle a particular set of circumstances,
– It may be that the requirements of an entirely new
company or department need to be defined and
subsequently satisfied.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 16

 Project Definition (Cont.)

• The starting point for a project should be a Project

Initiation Document.
• Usually produced jointly by the client (or user) and the
analyst and define:
– The objectives and scope of the investigation or project.
– The resources available or required and the timescales
involved.
– Any limitations or constraints

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 17

 Feasibility Study

• A feasibility study aimed to decide how viable the project

really is before too many resources are committed.
• Within a feasibility study, a preliminary investigation,
analysis, and design are carried out with the aim of:
– understanding the operation of the present system and
its problems
– identifying the requirements for the new system
– identifying a range of viable solutions to the problem
– identifying the cost/benefit implications involved

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 18

 Feasibility Study (Cont.)

More specifically, the study should embrace the following

• Overview of the current system (if appropriate)
− objectives
− outline description of processing
− -outline description of input and output data
requirements
− operational constraints, e.g., volumes of data, timescales
for processing, etc.
− problems, shortcomings, costs
• Requirements for the new system
− objectives
− overview of output, input, processing and data
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 19
 Feasibility Study (Cont.)

• Overview of a range of alternative solutions comprising, for each

solution:
− technical feasibility, i.e., will the proposed hardware and/ /or software be
able to solve the problem?
− are suitably qualified personnel available to develop the system?
− economic feasibility, i.e., how much will the solution cost (hardware,
software, staff, training, etc.)?
− what are the benefits? can they be quantified (reduction in staff)?
− what are the risks of implementing the system (e.g., financial loss)?
− what is the cost of not implementing the system? (e.g., loss of
competitive edge)
− operational feasibility: can the system be developed and implemented
within the given timescales?
− what impact will the system have on the users (e.g., skill implications,
retraining, redundancy, etc.)?
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 20
 Feasibility Study (Cont.)

• Overall recommendation.
− other implications. For example, if the system is to hold
personal data, is the company registered under the Data
Protection Act? or software be able to solve the
problem?

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 21

 Investigation of Current Environment

• Investigation of the current environment documents the

current system (if it exists) and production of a Requirements
Catalogue, data model, and process model.
– Requirements consist of a collection of problems in the current
system, together with a set of requirements for the new system.
– As there may be millions of items of data within a small system, it
is necessary to simplify the analysis procedure by grouping data
relating to the same or similar objects and treating it as a single
entity. An entity is an object of the real world about which
information is held in a particular system.
– Data is moved around the system by processes. These processes
may be triggered in several ways; for example, time, the input of
data from outside, or from another part of the system.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 22

 Business System Options

• Provides User Management with prepared options (Business

System Options/BSO) describing the scope and functionality of
alternative ways of developing a system to meet user
requirements, and user & task identification.
• Describe 'what the system should do' rather than 'how it will do
it’ it
• The set of options should be designed to give the user the
opportunity to decide what approach should be taken to solve
the problems of this part of his business. It is normal for the
analyst to produce several options for discussion with the user.
• The proposed options are chosen, this choice then enables the
analyst to proceed with the detailed logical design of the
proposed system.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 23

 Definition of Requirements

• Definition of Requirements takes the selected Business System

Option and refines the requirements catalog, data, and process
models expanding the detail into function descriptions and
Input/Output structures.
• The following tasks are carried out and documentation is
amended or created to support the development of the required
system model.
– Defining Required System Processing
– Development of Required Data Model
– Derive System Functions
– Structure Diagrams
– Specification Prototypes

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 24

 Technical System Options

• Technical system option is the evaluation of the best technical products

to meet the requirements specification. This is carried out in parallel
with the next phase Logical Design). The options are normally
produced in outline from a 'brainstorming' session and consider some
aspects, for example:
– Will we need processing to be available at more than one point, in
which case what levels of processing are needed and where are the
processor(s) and terminals going to be located?
– Does data need to be passed between sites and, if so, what do we
need?
– What software will need to be bought and/or developed? the
software was able to support adequate response times at peak loading.
– What if the production of invoices were not held up due to insufficient
printers (or to the lack of a sufficiently large buffer in the printer or
printers).
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 25
 Logical Design

• Logical Design, (i.e., what the new system will do) providing the
detailed specification of processing structures, data, and Human-
Computer Interfaces in the form of dialogues. The three parts of
this stage can be carried out in sequence or in parallel, this will
depend on the skills and size of the project team.
– Dialogue Design: This area of design is important to users as
often they see their interaction with the system as
synonymous with the functionality of the system.
– Define Update Processing: This step completes the
specification of the update processing and the associated
error handling.
– Define Enquiry Process: This step completes the database
Enquiry Process specification and associated error handling.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 26

 Physical Design

• Physical design (i.e., how the new system will work)

specifies the physical data, processes, inputs, and outputs.
It covers everything needed to decide an application's
construction and implementation methods.
• The stage requires expertise in the form of designers,
programmers and other specialists. Analysts can specify
function components, but experienced designers are
required to decide how those components can be
implemented.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 27

 Physical Design

• Some tasks in this stage include:

– Preparing for Physical Design.
– Create Physical Design Strategy: include Processing System
Classification, DBMS Data Storage Classification, and DBMS
Performance Classification.
– Physical Data Design and Process Design.
– Space and Performance: If the previous activities have been
completed, the design may need to be modified to meet the
required storage and performance objectives.
– Physical Process Specification: the logical design products are
converted into programs, physical I/O formats, and physical
dialogue designs that will work in the selected physical
environment.
– Function Component Implementation Map.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 28
 SSADM
Design Techniques

 Logical Data Modeling

– To determine the high-level requirement for the system
– System components, entities, main process, etc.

 Data Flow Modeling

– To determine the ‘movement’ of data within the system
– Data transformation, storage, data flow, etc.

 Entity Event Modeling

– To determine the processes and operations
– Event sequence, dependency, etc.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 29

 V-Model

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 30

 V-Model

 Derived and modified from Waterfall Model.

 After the implementation phase, the phases in the V-Model
bent upwards to form the ‘V’ shape. This represents the
association between each phase with its testing phase.
 The horizontal dimension of the V-Model denotes the project
completeness (project time).
 The vertical dimension of the V-Model denotes the multiple
levels of the system of interest. The topmost level represents
the system context in which the system operates. The
bottommost level represents the parts that can be obtained
and hence suffice to be defined in a black-box view.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 31

 V-Model
Phases

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 32

 V-Model
Phases (Cont.)

 Concept of Operations
 Identify goals and objectives of the proposed system,
study business strategies and policies to determine
system constraints. Study organizations entities,
stakeholders, activities, etc.
 Produce a checklist that contains:
 Clear reasons to develop a new system or upgrade
the existing system.
 Stakeholders and their roles.
 Identified internal, external, support, physical and
operational environments of the proposed system.,
etc.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 33
 V-Model
Phases (Cont.)

 Requirements Analysis and Architecture

 Requirements Analysis: User requirements are collected using
requirement engineering techniques i.e., interview, survey,
observation, etc. Requirements the documented in a System
Requirements Specification (SRS) describing functional and non-
functional requirements.
 System Design: Study the SRS, figure out possibilities and
techniques to implement the defined requirements. If any
unfeasible requirements, user is informed to discuss the alternative
replacements. The software specification document is produced
that contains structure of system menu, structure of data, data
dictionary, list of business scenarios, test plans, etc.
 Architecture Design/Physical Design: Includes software
architecture, database tables, interface relationships, required
technologies, brief functionality of the module, etc.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 34
 V-Model
Phases (Cont.)
 Detailed/Module Design
 The proposed system has broken down into smaller and manageable
units/modules, then each unit is explained in detail. The detailed
design includes database tables with type, size, and constraints, detail
interfaces, detail input and output for each module, etc.
 Verification and Validation
 Unit testing: each unit is tested to discover and resolve any defects
and bugs.
 Integration testing: some integrated units will be tested together to
discover and resolve any issues in the interfaces and interaction.
 System testing: aimed to check the overall system meets the specified
requirements.
 User acceptance testing: used by the users to verify the system, to
determine whether a system satisfies their criteria. Includes interface
quality and overall requirements.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 35
 V-Model
Phases (Cont.)

 Operation and Maintenance

 Identify best practices for system operations, problem
management and support/help desk best practices, release
management and quality assurance in system operations,
characteristics and best practices for IT asset management,
hardware maintenance and hardware monitoring, capacity
planning and monitoring activities, maintenance, and service
management activities within an organization, etc.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 36

 • The following video describes how the verification and
validation take place in the V-Model.

V-Model

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 37

 V-Model
Techniques

 Takes the ‘top-down’ development approach

– Concept, Architecture Design, high-level design, etc.
 Verification and Validation at end of each phase / process
which can include:
1. Validation of stakeholder requirements
2. Validation of allocated requirements
3. Validation of system element definitions
4. Validation of the virtually integrated system
5. Validation of the operational system deployed into its environment
6. Validation of the in-service system.
 Use various testing techniques for product
– Unit, integration, system, user acceptance, etc.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 38

 Structured Methodologies
Strengths & Weaknesses

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 39

 Strengths with Structured Methodologies
(in general)

 A hierarchical approach tends to generate well-organized

systems. Its step-by-step approach (parallel to the system
development life cycle).
 Simplifies project management, risk management, and
resource management.
 Additionally, this methodology’s tools and techniques can
all be used to support other methodologies.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 40

 Problems with Structured Methodologies
(in general)

 Rigid phases, discourage skipping of unimportant steps.

 Emphasize of process and product quality rather than
customer satisfaction
 Requirement need to be defined at the beginning of the
project and not encouraged to change towards the end.
 Cost and time is often unpredictable for large projects.
 Too many ‘red-tapes’, wasting time and resources

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 41

 Summary

 Traditional/Structured Methodologies contains detailed steps explained,

requirements that need to be clear and fixed, focus on error-free product,
rigid and strict rules, and emphasis on full documentation.
 The Waterfall methodology can be used for almost all types of projects, is
highly structured, and use a sequential development process - one should
move to the next phase only when its preceding phase is completed and
perfected.
 The SSADM is suitable for projects with complex database design, has
strategies to align business needs with system development, and ends at the
design stage.
 The V-Model contains the horizontal dimension that denotes the project
completeness (project time) and the vertical dimension that denotes the
multiple levels of the system of interest. Besides, verification and validation
can be conducted at end of each phase.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 42

 Question & Answer

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 43

 Next Session

• Agile Methods

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 44