Transcript SAD

And Franchise Colleges
01 Systems Development
By MANSHA NAWAZ
Section 01
Systems Development
1
Learning Aims
• Objective
– to understand system development lifecycle
– to understand the concept of a Systems
Analysis & Design
• Aims
– outline the function of each system
development stage
– outline Systems Analysis tasks
– outline Systems Design tasks
Section 01
Systems Development
2
What Is SAD, BSA or SD?
Developing Computer Systems !
Section 01
Systems Development
3
Types of Computerised Systems
•
•
•
•
•
•
•
Transaction Processing Systems (TPS)
Real-Time Systems (RTS)
Management Information Systems (MIS)
Decision Support Systems (DSS)
Knowledge Based Systems (KBS)
Executive Information Systems (EIS)
Office Automation Systems (OA)
Section 01
Systems Development
4
Computer Systems in Organisations
Transaction Processing Systems
EPOS Systems
Banking
Systems
Healthcare Systems
Leisure Industry
Section 01
Systems Development
Insurance Systems
5
Computer Systems in Organisations
Real-Time Systems
Automated Production Control
Control Systems
Section 01
Security Systems
Systems Development
6
Computer Systems in Organisations
Management Information Systems
Decision Support
Systems
100
80
60
Knowledge Based Systems
East
40
West
20
North
0
1st
2nd
3rd
4th
Qtr
Qtr
Qtr
Qtr
Office
Automation
Systems
Section 01
Executive Information
Systems
Systems Development
7
Problem Solving & Computers
Follows a set
Human of rules
Requires human
interpretation
Highly
programmed
Highly nonprogrammed
Transaction
Processing
Systems
Section 01
Executive
Information
Systems
Systems Development
8
Who Develops Computer Systems?
• The Computer Industry
– Software houses
– Systems houses & integrators
– Hardware vendors ..
• In House
– D P Departments (or IT Services) ..
– End Users? …
• Move towards Packaged Software
Section 01
Systems Development
9
Developing Computer Systems
• SYSTEMS DEVELOPMENT
– Strategy involved building & maintaining a computer
system through is ‘life cycle’
• THE LIFE CYCLE
– A systems existence from ‘idea’ to ‘termination’
• STRUCTURED METHODOLOGY
– Action Plan for Systems Development
– Documentation
– Uses abstract modelling ‘CASE tools & technique’
Section 01
Systems Development
10
Forces on Systems Development
ENVIRONMENT
Company
Politics
Systems
Development
Development
Approach
Time
Section 01
Systems Development
11
Systems Development
• Formalised approach to systems development
by use of a STRUCTURED METHODOLOGY
– Yourdon, Waterfall, SSADM, Prototyping,
Object Oriented, etc.
• Greater clarity of requirements and traceability
through a SYSTEMS LIFE CYCLE
• Focus on business needs
• More user involvement
• Reduction in maintenance time and effort
Section 01
Systems Development
12
Systems Life Cycle
• All systems have a limited lifetime
• Typical reasons for obsolescence
–
–
–
–
business growth
new technology becomes available
changes in users’ requirements
changes in environment
• Typical system lifetime 4-10 years
• Structured Methodologies are used to create a
system
Section 01
Systems Development
13
What is Structured Methodology?
• General statement
– Avison[82] ”a recommended series of steps and procedures
to be followed in the course of developing an Information
System”
• An underlying model
– conceptual representation of the product
• A language
– means of describing the product
• Defined & ordered steps
– the process of creating the product
• Guidance for applying
– procedures for conducting the process
Section 01
Systems Development
14
Structured Methodology
• Yourdon
• WATERFALL
• SSADM
• Prototyping
• Object Oriented
• etc
Section 01
Systems Development
15
Yourdon
A STRUCTURED METHODOLOGY
• The Analysis Models
– The Essential Model
• The Environmental Model
• The Behavioural Model
– The User Implementation Model
• The Design Models
– The Processor model
– The Task Model
– The Program Implementation Model
Section 01
Systems Development
16
Yourdon developed the standardisation of CASE
tool & techniques.
• Model
– process oriented
• Language
– graphical, dfds etc.
• Steps
– essential model etc.
• Guide
– texts, courses, tools
Section 01
Systems Development
17
Waterfall Life Cycle
A STRUCTURED METHODOLOGY
Project
Specification
Feasibility
Study
Systems
Investigation
Systems
Analysis
May have iterations but
“Waterfall” Approach
Systems
Design
these are very costly
Section 01
Systems Development
Systems
Implementation
Review &
Maintenance
18
Systems Analysis & Design
• Analysis is the problem
solving stage
Project
Specification
Feasibility
Study
Systems
Investigation
Systems
Analysis
Systems
Design
Design is building upon the
analysis to develop the selected
solution

Section 01
Systems Development
Systems
Implementation
Review &
Maintenance
19
SSADM
A STRUCTURED METHODOLOGY
• feasibility study module
– stage 0, fast run through (RA) ?proceed?
• requirements analysis module
– stage 1 traditional systems analysis
– stage 2 specify possible business options
• requirements specification module
– stage 3 detailed systems analysis
Section 01
Systems Development
20
SSADM Contd.
• logical system specification module
– stage 4 technical options
– stage 5 user interface & further detail
• physical design module
– stage 6 design with respect to options selected
Section 01
Systems Development
21
PROTOTYPING
A STRUCTURED METHODOLOGY
• Based on rapid development of refining a system
over a period of time.
• Basic System built early in life cycle
• Using automation, i.e.
– Program generators
– 4GL languages
– System development tools
– Packaged (standard) modules
• But there can still be problems
Section 01
Systems Development
22
Prototyping - amended lifecycle
Identify basic
Information
Requirements
Success depends on
available tools:
Develop System
to fulfil basic
Requirements
Experiment with
basic system in
Application area
Refine Prototype
to reflect known
Requirements
Application Packages
Program Generators
4GLs
Section 01
Systems Development
23
Spiral Model
A STRUCTURED METHODOLOGY
Initial requirements
gathering and project
planning
Planning
Risk analysis
Risk analysis
based on
initial
requirements
Risk analysis
based on
customer
reaction
Planning based
on customer
comments
Go, no-go decision
Toward a
completed
system
Customer
evaluation
Initial software
prototype
Customer evaluation
Engineering
Next prototype level
Engineered system
Section 01
Systems Development
24
Object Oriented Lifecycle
A STRUCTURED METHODOLOGY
• Different emphasis needed (OMG : Bennett et al)
Life Cycle
Object
Modelling
Strategic modelling
Analysis modelling
Design modelling
Implementation Mod.
Construction
Full
definition
of the
system
Delivery
Coordination and reuse
Section 01
Systems Development
25
Methodology Summary
•
•
•
•
Many lifecycle methodologies
Systems are being developed faster
Less documentation (is that a problem?)
Four D,s
– Decide, (Analyse), Design, Develop, Deploy
Section 01
Systems Development
26
Problems of Software Development
• Software Crisis or Affliction
– Schedule and cost estimates often grossly
inaccurate
– Productivity has not kept pace with demand
– Frequently poor quality systems are delivered
– Existing systems are difficult to maintain
Section 01
Systems Development
27
Section 01
Systems Development
28
Some Recent Problem Projects
•
•
•
•
•
•
•
•
•
"Concerns about the reliability of data mean that the launch of the Government's troubled Criminal
Records Bureau (CRB) has been postponed until the Autumn… (Computer Weekly 7 June 2001)
"The roll out of a £319m PFI project aimed at speeding up the criminal justice system has been
postponed indefinitely amid spiralling costs and serious technical concerns…The cost of the contract
has increased by £136m since it was signed in 1998" (Computer Weekly 28 June 2001)
"DVLA savings disappear. EDS proposed 30% savings from £5m vehicle software but DVLA
underestimated the technology challenge." (Computer Weekly 30 August 2001)
"Financial services company Prudential Europe has terminated a £35m IT contract with
Unisys…Prudential stands to lose about £10 million…not taking account the impact on business
expansion plans…" (Computer Weekly 13 September 2001)
Crams, the probation service case management system is to be dumped after six years of
development at the cost of millions of pounds. (Computer Weekly 13 July 2000)
"The UK treasury has abandoned hopes of recovering millions of pounds in compensation for delays
in the new national insurance system because it needs to preserve the relationship with the system's
developer, Anderson Consulting…a decision which illustrates the huge potential for outsourcer lockin…" (Computing 4 April 2000)
The MOD lost over £40 million pounds on two failed IT projects. In one case a system was abandoned
without ever having worked properly due to 'software problems'. In another case the complexity of a
pay system was underestimated at the outset and the project spiralled out of control. It was
abandoned after £8.7 million had been spent. The public accounts committee reported that the MOD's
attempts to develop bespoke systems were "ill-considered". (Computer Weekly 31 August 2000)
"The police service is more than a year behind in delivering some of its key IT targets" (Computer
Weekly 31 August 2000)
Data from self-assessment tax returns submitted to the Inland Revenue through its Internet service
has to be re-keyed into the main self-assessment computer system. (Computer Weekly 13 July 2000)
Section 01
Systems Development
29
• Note the top three reasons for failure. These are three areas where
structured methods might make claims of improvement. For instance:
• "The main [claim of structured methods] …is that they result in systems that
more closely match the needs of users because user requirements have
been more fully understood and communicated from the outset…" (Weaver,
Lambrou Walkley, 1998, p4)
• "It is a basic principle of SSADM that the users have involvement in, and
commitment to, the development of their system from a very early stage…"
(Goodland and Slater, 1995, p3)
• In general it is true to say that the authors of books on structured methods
offer little hard evidence to support their claims. No research, for instance, to
show that the use of a structured method actually improves the
understanding of user requirements. Of course it would be quite difficult to
perform such research in practice, so the proponents of methods tend to fall
back on more qualitative arguments to support their position. One argument
runs like this: methods use diagrammatic techniques; these are easily
understood by users and promote better communication with the users; this
improved understanding and communication leads to a better definition of
requirements. You might like to see if you can summarise, in a similar way,
any of the other arguments made in defence of structured methods. How
convincing do you find these kinds of argument? What counter arguments
can you come up with?
Section 01
Systems Development
30
Why things go wrong
Type of Failure
Reason for Failure
Wrong problem addressed
Quality
Problems
Wider influences are neglected
Analysis carried out incorrectly
Project undertaken for wrong
reason
Users change their mind
Productivity
Problems
Comment
System conflicts with
business strategy
Organisational culture
may be ignored
Team poorly skilled or
inadequately resourced
Technology pull or
political push
Requirements drift
External events change the
environment
New legislation
Implementation is not feasible
May not be known until
project has started
Inexperienced project
manager
Poor project control
From Bennett et. al. (1999)
Section 01
Systems Development
31
The impact of change
100
90
80
70
60
50
40
30
20
10
0
Section 01
Cost to change
Definition
Development
Systems Development
Maintenance
32
Real World Situation I
• Structured systems
development easy to
understand
– new practitioners &
customers
• divides large
complicated process up
into small easier bits
– better to manage
Section 01
Systems Development
33
Real World Situation II
• stages blurred
• customer often wants to
see ‘real s/ware’
– prototyping
• requirements frozen?
– iterate back between the
stages
that’s the theory
but what about
the real world?
• less suited to newer
programming
Section 01
Systems Development
34
Towards Computerisation
• What is needed to be done to move from position A to B?
A
?
B
Paper Based
Computer Based
Why Computerise?
• Increase Revenue
• Improve Service
– boost sales
– to achieve other two
above
• Avoid Costs
– cheaper production or labour
Section 01
• acronym IRACIS
Systems Development
35
Role of Systems Analyst
Section 01
Systems Development
36
SAD experience in the Real World
• "What Does a Systems Analyst Really Do?", [On-line],
University of Missouri: School of Business Administration,
USA.
• Available from:
http://www.umsl.edu/divisions/business/mis/system.htm
• [Accessed: 12/09/02].
Section 01
Systems Development
37
You Use Analysis Every Day
• e.g. Expedition Scenario
• The group are going on an overland journey to Borneo, a six week
expedition.
• They have been sponsored by “Wicked” magazine who will pay £5000
conditional on receiving two interim articles, for publication during the
expedition, one major feature article at the end and a follow up three
months later.
• They will need to take a portable computer, digital camera and mobile
phone at the very least.
TASK:
• What do you need to do in order to successfully complete the
project? How do you determine this?
Section 01
Systems Development
38
Systems Analyst Skills
• Systems Thinking
• Systems concepts / Applying systems thinking to Information Systems
• Organisational Knowledge
• Processes / internal politics
• Competitive & regulative environment / strategies & tactics
• Problem Identification/Analysis/Solving
• Technical Skills
• hardware / software
• publications / professional societies / courses & conferences
• Management Skills
• resource management / project management
• risk management / change management /humans
• Interpersonal Skills
Section 01
• communication skills / working alone & in teams
• facilitating groups / managing expectations
Systems Development
39
Specialist Skills
•
•
•
•
Systems Analysts used to do all these tasks
Computing is getter ever more complex
Beyond the capability of ONE person
Specialisms
–
–
–
–
Business Analysts
Data Analysts
Networking..
Communications …WWW ..etc etc
• TEAM – GROUP OF PEOPLE SHARE WORK LOAD
Section 01
Systems Development
40
“Systems Analysis is what the
Systems Analyst Does” (Parkin,1987)
•
•
•
•
•
•
•
•
•
•
•
•
Conducts feasibility studies (with alternatives)
Liases with users and determines requirements
Finds out facts important to the design of the proposed system
Determines human and computer procedures that will make up
the new system
Designs data storage (files) and interfaces
Writes program specifications
Tests programs and systems
Designs implementation procedures
Documents the system
Plans, monitors and controls the systems development
Reviews how successful the project was
Oversees maintenance of the system
Section 01
Systems Development
41
Systems Analysis & Design
• Analysis is the problem
solving stage
Project
Specification
Feasibility
Study
Systems
Investigation
Systems
Analysis
Systems
Design
Design is building upon the
analysis to develop the selected
solution

Section 01
Systems Development
Systems
Implementation
Review &
Maintenance
42
“Construction builds the system in a series
Project
of iterations. Each iteration is a mini
Selection
project. You do analysis, design, coding,
Feasibility
testing and integration for
Study
the use cases assigned to each
System
iteration.”
Investigation
Fowler, 1997
System
Analysis
“On the other hand,
the disadvantage of any
form of iterative life cycle is
that the project team and/or the
user may fall prey to the temptation of
endless iteration.”
Yourdon, 1994
Section 01
Systems Development
System
Design
System
Implementation
Review &
Maintenance
43
PROJECT SPECIFICATION STAGE
Need A Problem Solving ?
Problem Solving is …..
• “….. the art of finding ways to
get from where you are now to
where you want to be
(assuming you do not already
know how).
Is this Problem Solving?
Section 01
• The ‘problem’, therefore, is the
gap between the present
situation and a more desirable
one.”
(Nolan 1989)
?
A
Systems Development
B
44
PROJECT SPECIFICATION STAGE
Identifying The Problem
The Mess!
Generate Ideas
Section 01
Data Gathering
Solution Finding
Systems Development
Problem Definition
Gaining Acceptance
45
PROJECT SPECIFICATION STAGE
• Having identified a problem area we need to produce
a Project Specification
• Structured Systems Development : starting point to
project work
Problem Definition
Project Specification is also referred to as a
TERMS OF REFERENCE
Section 01
Systems Development
46
PROJECT SPECIFICATION
•
•
•
•
•
•
•
•
PROJECT TITLE
AUTHOR
SUPERVISOR
PROPOSER
OBJECTIVES
AIMS
RESOURCES & CONSTRAINTS
SCHEDULE
• Sample to review in tutorial
Section 01
Systems Development
47
FEASABILITY STAGE :
• A report which investigates and justifies
the need for the development of a new
system.
• Full investigation into existing system.
• An appraisal of the existing system,
practices and procedures.
• Highlight weakness
Section 01
Systems Development
48
Systems Analysis Stage
• Also referred to as requirements stage
• To ascertain the composition of a proposed
system.
• Identify WHAT is needed.
• Find out what the customer wants the system to
do and record as a Requirements List
– interviews, documentation, questionnaires etc.
Section 01
Systems Development
49
• To outline, sketch, plan and develop an improved
system.
• Build a blueprint or model of the required system
• Use of CASE tools (Context Diagram, Dataflow
Diagram, Data Dictionary)
• Produce a report : Analysis Specification.
• Must specify "What is needed."
• and not "How is it to be achieved ?"
Section 01
Systems Development
50
Design Stage
• “Stating how a system will be constructed
without actually building it”
Rumbaugh (1977)
• Produce a report : Design Specification.
– how will system data be stored
• design database tables / data attributes
– how will the system perform any operations
• design of algorithms, queries, reports, functions, etc
– hardware configuration options
Section 01
Systems Development
51
• Identify HOW the "needs" in the analysis stage are to
be achieved.
• Specify design of proposed system.
• Use of CASE tools (Normalisation, ER Model,
Tables, Forms, Queries, Reports, etc )
• Provide information in order to produce the system.
• Sketch plans
–
–
–
–
Outline
Detail
Written Specifications ….THEN
Actual construction
• Must specify “How it is to be achieved”
• and not “What is needed ?"
Section 01
Systems Development
52
When to Design?
• Alongside construction (just in time?)
• Alongside Analysis (solutions to problems as we go
along – often only in outline)
• After the analysis stage (Detailed design)
• Or both – as in rapid development
• Logical and Physical design
– Independence of the physical implementation
Section 01
Systems Development
53
Implementation Stage
• Writing of code
– Pascal, Cobol, C, Forth
• Building of tables, relationships & queries
– MS Access, FoxPro, Ingres, SQL
• Testing the individual components
– test plans and documented results
• Testing the complete system
– test plans and documented results
Section 01
Systems Development
54
Maintenance Stage
•
•
•
•
•
•
•
•
Delivery of the system
Data Input
User Guides
Training of staff
Operation strategy...user procedures
Changeover from old to new
Maintenance...fine tuning & bug fixing
Upgrades
Section 01
Systems Development
55
Read the Supplement on
Read the Example report on
Systems Development Life Cycle
British WebObject Management System
Section 01
Systems Development
56
Summary
• Know the stages involved in Systems
Development
• The use of Systems Methodologies such as the
WATERFALL model
• The importance of Systems Analysis & Design.
• Know the difference between Analysis & Design
Project Documentation requirements & standards
Section 01
Systems Development
57