Comparative Development Methodologies Lecture 6

1
Comparative Development MethodologiesLecture 6

• Niki Trigoni
• Department of Computer Science
• and Information Systems
• Birkbeck College, University of London
• Email niki_at_dcs.bbk.ac.uk
• Office Hours Wednesdays, 6 - 7 pm
• Web Page http//www.dcs.bbk.ac.uk/niki

2
Methodology

• A recommended series of steps to be followed in
  the course of developing an information system
• Methodology vs. method
• Is a methodology a collection of tools and
  techniques?
• Should the use of a methodology produce the same
  results each time?
• A recommended collection of philosophies, phases,
  procedures, rules, techniques, tools,
  documentation, management, and training for
  developers of information systems BCS
  Inf.Syst.Anal.Des.Working Group, 1983

3
Components of a methodology

• A methodology specifies
• How a project is to be broken down into stages
• What tasks are to be carried out at each stage
• When, and under what circumstances, they are to
  be carried out
• What outputs are to be produced
• What constraints are to be applied
• Which people should be involved
• How the project should be managed and controlled
• What support tools may be utilized

4
Methodology definition

• A systems development methodology is a
  recommended means to achieve the development, or
  part of the development, of information systems,
  based on a set of rationales and an understanding
  of philosophy that supports, justifies and makes
  coherent such a recommendation for a particular
  context. The recommended means usually includes
  the identification of phases, procedures, tasks,
  rules, techniques, guidelines, documentation, and
  tools. They might also include recommendations
  concerning the management and organization of the
  approach and the identification and training of
  the participants.

5
Why adopt a certain methodology?

• Better end product
• How do we know that the same information system
  could not be achieved with another methodology?
• No universal agreement on measures of quality
• Better development process
• Productivity is usually enhanced with the use of
  a methodology
• A methodology reduces the level of skills
  required of the analysts
• A standardized process
• Common experience and knowledge can be achieved

6
Types of methodologies

• Process-oriented methodologies
• Blended methodologies
• Object-oriented methodologies
• Rapid development methodologies
• Organizational-oriented methodologies

7
Process-oriented methodologies

• Emphasis is placed on the analysis of processes
• Examples
• STRADIS (Structured Analysis and Design of
  Information Systems) Gane and Sarson 1979
• top-down approach to analyzing processes
• YSM (Yourdon Systems Method) Yourdon 1993
• middle-up approach to analyzing processes
• some emphasis on the analysis of data

8
STRADIS

• Structured systems approach to both
• Analysis and
• Design
• Applicable to the development of any information
  system, irrespective of size and level of
  automation
• Relevant to a situation in which we need to
  develop a number of systems with insufficient
  resources to devote to all the potential new
  systems
• No detailed description of steps used, more
  emphasis placed on the techniques brought
  together
• Most important idea functional decomposition

9
Stages of STRADIS

• Initial study
• Detailed study
• Defining and designing alternative solutions
• Physical design

10
STRADIS 1. Initial study

• It lasts two weeks to four days
• Goal choose systems most warranting development
  in a competing environment
• Will a system
• i) increase revenues?
• ii) avoid costs?
• iii) improve services?
• Construction of an overview data flow diagram of
  the existing system and its interfaces
• Estimate of the times and costs of proceeding to
  a detailed investigation
• Estimate of final system development costs

11
STRADIS 1. Initial study (cont.)

• It differs from a feasibility study in that
• it does not include a review of alternative
  approaches to the proposal
• it is not as major or resource-intensive
• it is a commitment wrt to expected costs, but not
  to the actual implementation of the proposed
  system

12
STRADIS 2. Detailed study

• The existing system is examined in detail.
• The potential users of the system are identified
• Senior managements with profit responsibilities
• Middle managers of the departments affected
• End-user
• Analysts
• interview users and identify requirements/interest
  s
• prepare a DFD of the current system (with
  interfaces to other systems)

13
STRADIS 2. Detailed study (cont.)
Course Requir.
Student
Appl
Validate application
Check univ. requirements
Check course requirements
Make decision
Registry
Qualifications
Second check
Check unknown qualifications
Send reply
Reference books
Student
British Council
Applicants.
14
STRADIS 2. Detailed study (cont.)

• The boundary may be drawn in any place and can be
  moved
• DFDs are designed at various levels each level
  is exploded into lower levels (top-down
  functional decomposition)
• not all low-level processes are specified
• not all data flows and data stores are specified
  in the data dictionary
• DFDs are reviewed by a number of users
• Better estimate of costs and benefits
• Budget of the next phase

15
STRADIS 3. Alternative solutions

• Alternative solutions to the problems of the
  existing system
• System (rather than organizational) objectives
  are clearly stated
• The analyst uses the system objectives to produce
  a logical DFD of the new or desired system.
• Analysts and designers then work together to
  produce alternative implementation designs which
  meet a variable selection of the system
  objectives.
• Low-budget, quick implementation
• Mid-budget, medium-term version
• Higher-budget, ambitious version

16
STRADIS 3. Alternative solutions (cont.)

• A report is produced that includes
• a DFD of the current system
• limitations of the current system (cost/benefit
  estimates)
• Logical DFD of the new system
• For each identified alternative, the report
  includes
• which parts of the new DFD will be implemented
• user interface (reports, query interface etc.)
• estimated costs and benefits
• outline implementation schedule
• risks involved
• Based on the report, an alternative is chosen.

17
STRADIS 4. Physical design

• This step includes the physical design of the
  chosen alternative solution.
• DFD in detail (process logic, data dictionary,
  report and screen formats, exception handling)
• database and physical files (normalization is
  utilized to consolidate the datastores in DFDs
  into logical groupings)
• modular hierarchy of functions from the DFD
  (transform-centered vs. transaction-centered
  systems)

18
STRADIS 4. Physical design (cont.)

• Activities of the physical design phase are
  pursued to a level of detail, so that the
  following costs can be computed
• development time for the identified modules
• computer system required
• peripherals and data communication costs
• time to develop documentation and train users
• time of the users who interact with the system
• time to maintain or enhance the system
• Envisaged tasks
• Implementation
• Load databases

19
YSM (Yourdon Systems Method)

• Like STRADIS, YSM is based on the structural
  approach of functional decomposition
• A system is successively decomposed into
  manageable units
• Unlike STRADIS, YSM uses event-partitioning.
• neither a top-down nor a bottom-up approach
• middle-out approach
• YSM covers both
• enterprise (organizational) requirements
• system requirements

20
YSM phases

• Feasibility study
• Present system and its environment
• Essential modeling (assumes unlimited resources)
• How the required system must behave
• What data must be stored to enable this behavior
• Implementation modeling
• Limitations of available technology and
  performance requirements are taken into
  consideration

21
YSM 1. Feasibility study

• It is the shortest phase (only a few weeks long)
• Objective General understanding and overview of
  the existing system, its environment and the
  problems associated with it.
• Tasks
• Overview DFD for current system and interfaces
• Start an ER (Entity-Relationship) diagram

22
YSM 2. Essential modeling

• It is the most important phase in YSM.
• The system essential model is a model of what the
  system must do in order to satisfy the users
  requirements (not how)
• Two components enterprise model and system model
• environmental model building
• behavioral model building

23
YSM 2. Essential modeling (cont.)

• The environmental model defines the boundary
  between the system and the environment in which
  the system exists.
• Components of the model
• Statement of purpose
• brief statement about the purpose of the system
• provided for top management
• only a paragraph long
• Context diagram
• Level-0 DFD represents the system as a circle and
  the external systems with which it communicates
• Event list
• Stimuli that occur in the environment of the
  system to which the system must respond
  (flow-oriented, temporal, control events)

24
YSM 2. Essential modeling (cont.)

• The behavioral model describes what the internal
  behavior of the system must be in order to deal
  with the environment successfully.
• Components of the model
• First-cut DFD
• Entity-relationship diagram
• State transition diagram
• Adds information in the data dictionary (started
  in the context of the environmental model)

25
YSM 2. Essential modeling (cont.)
Upward leveling
Preliminary DFD
Downward leveling
26
YSM 2. Essential modeling (cont.)

• Types of data flows
• Discrete data flows (arrow)
• Continuous data flows (arrow with two heads

YSM data flow diagrams symbols
Process Discrete data flow Contin.
data flow
Data store Sources and sinks
27
YSM 2. Essential modeling (cont.)

• Process specifications (minispecs) are written
  for every process in the bottom level DFD
• The knowledge gained when refining the DFD will
  be used to help refine the ERD (Entity
  Relationship Diagram)
• If the system being modeled has any real-time
  characteristics, then a state transition diagram
  is also developed, in addition to the DFD and ERD.

28
YSM 3. Implementation modeling

• This phase starts the systems design process
• The essential model is modified based on
• Technology constraints
• Performance requirements
• Feasibility
• Main tasks
• Allocation of software environments to groups of
  processes
• Selection of database systems