Overall Systems Development Process

1
Overall Systems Development Process

• Dr Jon Tepper
• Room N330

2
Learning Objectives

• Describe the traditional systems development
  lifecycle (waterfall model)
• Identify cross-lifecycle activities
• Identify key stages of all development lifecycles
  
• Identify the typical outputs of a systems
  development lifecycle

3
Learning Objectives

• Discuss the problems associated with the
  traditional waterfall model
• Explain Prototyping and its advantages and
  disadvantages
• Identify the different stakeholders in a systems
  development project

4
(No Transcript)
5
Project Identification Selection

• Someone (system owners or users) initiates a
  project by identifying the need for a new or
  enhanced system
• Could be at corporate-level e.g. to convert
  keyboard input to barcode input
• Projects can be planned or unplanned
• Planned plan to select system development
  project that provides most benefits
• Unplanned easily overwhelms organisation and
  must be screened and prioritised by IT managers

6
Project Initiation Planning

• Further investigation to determine if project is
  worth pursuing
• What are the risks? What is the project scope?
• Project leader and systems analysts will draw up
  a plan for management
• Can the IT dept develop the solution with
  resources available?
• Project leader and some team members will
  evaluate feasibility and present this information
  to system owner

7
Project Initiation and Planning
Typical Inputs and Outputs
8
Analysis

• Current system is studied and alternative or
  replacement systems are proposed
• Problem analysis systems analyst must
  understand problem and present to management
• Requirements analysis what data must be
  captured and stored? What must the system do?
• Decision analysis How much of the system must
  be computerised? Should we buy or build it? What
  technology should we use? Is the web required?

9
Requirements Capture and Analysis
Typical Inputs and Outputs
RTM is a table showing the relationship between
each system function or feature and the relevant
requirement(s) that sanction it
10
Design

• Description of the recommended solution is
  converted into logical and then physical system
  specifications
• How will technology be used in the new system?
• What ideas and opinions do users, vendors IT
  specialists have?
• Designs must adhere to internal technical design
  standards that ensure completeness, usability,
  reliability, performance and quality
• Technology based views of data,processes
  interfaces

11
Design
Typical High-Level Inputs and Outputs
Requirements Documentation
Updated RTM shows the relationship between each
design element and the relevant requirement(s) in
the requirements documentation
12
Implementation

• System specifications are converted into a
  working system that is tested and used
• The computer-based system is coded, tested and
  installed within the organisation.
• Coding programmers produce programs that make
  up the system
• Testing programmers and test engineers test
  individual programs and the entire system to find
  and correct errors
• Installation new system becomes part of daily
  activities of the organisation. Application
  software is installed onto new or existing
  hardware
• User Training Support finalisation of
  documentation training

13
Implementation 1 Coding and Testing
Typical Inputs and Outputs
Design Documentation
Updated RTM shows the relationship between each
design element detailed in the design
documentation and the corresponding software
artefact (and associated test plan)
14
Implementation 2 Installation
Typical Inputs and Outputs
Design Documentation
Installation and Conversion Plan
15
Operation and Support

• Once the system is operating, it delivers the
  business solution to the user community
• It will require on-going system support for the
  remainder of its life
• Systems support (maintenance) consists of
• Technical support
• User support
• Fixing software errors (bugs)
• Recovering the system after a crash
• Adapting the system to new requirements
• Eventually user feedback and problems indicate
  its time to start over and reinvent the system
  (system entropy reached!)

16
Process of Maintenance

• Four major activities occur within maintenance
  (support)
• Obtaining maintenance requests
• Transforming requests into changes
• Designing changes
• Implementing changes
• Remember by definition the SDLC is cyclic,
  therefore the last activity leads back to the
  first and then repeating development steps until
  the change is implemented see Hoffer et al
  (2001) pp 619, fig18.4
• Deliverables will thus be produced at each SDLC
  phase

17
Cross Life Cycle Activities

• Activities that overlap many or all phases of the
  methodology
• Fact finding research, interviews,
  questionnaires etc
• Documentation presentations recording facts
  and specifications. Presenting findings to
  management.
• Estimation measurement
• Feasibility analysis
• Project and process management
• Change management
• Quality management

18
SDLC Outputs
PHASE 1 Project Identification Scope
Output / Product / Deliverable
System owner or user identifies project Project
is planned or unplanned
Priorities for systems projects Architecture
for data, networks, hardware IS management is
the result of associated systems planning
activities
PHASE 2 Project Initiation Planning
Context data and process models of existing
system Detailed steps, or work plan, for
project Specification of system scope and
high-level system requirements or
features Assignment of team members and other
resources
Systems thinking gain clear understanding of
the system Summarise findings to management
including whether to proceed to next stage
Process, data and logic models of existing
system General recommendations on how to fix,
enhance or replace existing system. Explanation
of alternative systems and justification for
chosen alternative
PHASE 3 Analysis
Define business requirements (software) for new
system Perform problem, requirement and decision
analysis Prepare system requirements report.
Evaluate alternatives.
PHASE 4 Design
Logical Design Functional detailed
specifications of all system elements (data,
processes, processing logic, inputs and
outputs) Physical Design Technical, detailed
specifications of all system elements (programs,
files, network, systems software)
Logical Physical models and descriptions of
solution
PHASE 5 Implementation
Code Code Repository Documentation e.g. build
scripts, test specifications Training procedures
and support capabilities
Coding, Testing, Installation, User Training
Support
PHASE 6 Operation Support
New versions of Software Updated Documentation
Training Support
Technical support, User support, Bug fixing,
Upgrades, Disaster recovery, System backups etc
19
Key Stages of All SDLCs

• More Generally
• Life of a computer-based system can always be
  divided into two key stages
• Systems development
• Analyse, design and build it!
• Systems operation and support
• Use it, keep it running and support it!
• Eventually you cycle back from operation and
  support to redevelopment

20
Is A Lifecycle A Methodology?

• Whitten et al (2001) states that a systems
  development methodology implements the
  development stages of the 2 general phases of an
  SDLC
• So are the terms methodology and life cycle
  abused in ISAD? What do you think?

21
Problems with Waterfall Model

• Iteration complicates manageability
• Working guidelines and rules inflexible change
  a user or system requirement you must go to
  initial phase and propagate changes through each
  phase
• Amount of documentation produced makes it
  difficult for users and analysts to see overall
  picture
• Long development times
• May take years to develop a complex software
  system - by which business needs, priorities and
  market place may change
• Use of parallelism may minimise these limitations

22
Prototyping

• An iterative process of systems development in
  which requirements are converted to a working
  system which is continually revised through close
  work between an analyst and the users
• Since prototyping is only a small-scale version
  of the whole system some features and
  functionality may be omitted
• Prototypes typically contain the Graphical User
  Interface (GUI) and partial functionality

23
Prototyping Cycle
Analyst consults with User
Initial Requirements
Working Prototype
New Requirements
If Prototype Accepted
Problems
Next Version
Adapted from Naumann, J. D., and Jenkins, A. M.
(1982). Prototyping the new paradigm for
systems development. In MIS Quarterly, 6(3), PP
29-44.
24
Prototyping Complements SDLC

• Prototyping can be used to complement a
  traditional structured SDLC
• A prototype could be developed early on in the
  analysis and design phase to help identify user
  requirements
• The final system developed is based on the
  specification of the prototype
• Prototyping is an excellent method for accurately
  determining user requirements

25
Prototyping Tools

• Computer-aided Software Engineering (CASE) tools
  are software tools that help the analyst through
  each phase of the SDLC e.g., to construct system
  designs, code or tests
• A prototype can be developed using such CASE
  tools as 4th Generation Languages (4GLs)
• Allows graphical construction of prototype via
  query, screen and report design tools rather than
  writing code from scratch
• Examples., Borland Delphi visual editing of
  GUI, creation of database apps, programming with
  object-orientated Pascal
• Borland C Builder same as Delphi but uses
  C instead of Pascal Microsoft Visual Basic
  same as Delphi but uses BASIC

26
Advantages of Prototyping

• Shortened development times
• Less chance for business or system requirement
  changes
• Reduced development costs
• Allows users to be actively involved in the
  analysis and design phases
• Users can see and experiment with the system thus
  solving problem of trying to understand system
  through endless documentation
• Visual nature of the prototype creates an
  understanding of the system that would be
  difficult to achieve from paper diagrams
  written documentation

27
Disadvantages of Prototyping

• The term Rapid Application Development (RAD) is
  used to market the prototyping products and
  attracts criticisms of it not being a serious
  method i.e. its for hackers!
• Name refers to projects that complete quicker
  than when using traditional SDLC but 4GL tool
  vendors use RAD as a buzzword to sell products
• 4GL tools can tempt application programmers to
  avoid structure analysis and design techniques
• Result inconsistencies between system modules,
  non compliance with standards, non-functional
  requirements not expressed, lack of safety
  features
• Users may not give up prototype
• Users want analysts to use RAD techniques as they
  want the system as quick as possible - probably
  at the expense of quality!

28
Stakeholders and their Roles

• A stakeholder is any person who has an interest
  in an existing or new computer-based system.
  Stakeholders can be technical or non-technical
  workers
• For information systems, the stakeholders can be
  classified as
• System owners
• System users
• Systems analysts
• System designers
• System builders (programmers!)
• IT vendors and consultants

29
Summary

• Describe the traditional systems development
  lifecycle (waterfall model)
• Identify cross-lifecycle activities
• Identify key stages of all development lifecycles
  
• Identify the typical outputs of a systems
  development lifecycle

30
Summary

• Discuss the problems associated with the
  traditional waterfall model
• Explain Prototyping and its advantages and
  disadvantages
• Identify the different stakeholders in a systems
  development project