Section 01 Systems Development 2
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 4
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 5
Computer Systems in Organisations
Transaction Processing Systems
BankingSystems
EPOS Systems
Healthcare Systems
Insurance SystemsLeisure Industry
Section 01 Systems Development 6
Computer Systems in Organisations
Real-Time Systems
Automated Production Control
Control SystemsSecurity Systems
Section 01 Systems Development 7
Computer Systems in Organisations
Management Information Systems
0
20
40
60
80
100
1st
Qtr
2nd
Qtr
3rd
Qtr
4th
Qtr
East
West
North
Decision Support Systems
OfficeAutomationSystems
Knowledge Based Systems
Executive Information Systems
Section 01 Systems Development 8
Problem Solving & Computers
Follows a setHuman of rules
Highly Highly non-programmed programmed
Transaction ExecutiveProcessing Information Systems Systems
Requires humaninterpretation
Section 01 Systems Development 9
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 10
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 11
Forces on Systems Development
SystemsDevelopment
Legal
Require
ments
Users
CompanyPolitics
Ethical Issues
Technical Issues
ENVIRONMENT
Time
Development Approach
Section 01 Systems Development 12
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 13
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 14
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 15
• Yourdon
• WATERFALL• SSADM
• Prototyping
• Object Oriented
• etc
Structured Methodology
Section 01 Systems Development 16
Yourdon
• 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
A STRUCTURED METHODOLOGY
Section 01 Systems Development 17
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 18
Waterfall Life Cycle
May have iterations butthese are very costly
Systems Investigation
Systems Analysis
Systems Design
Systems Implementation
Review & Maintenance
Feasibility Study
Project Specification
“Waterfall” Approach
A STRUCTURED METHODOLOGY
Section 01 Systems Development 19
Systems Analysis & Design• Analysis is the problem
solving stage
Systems Investigation
Systems Analysis
Systems Design
Systems Implementation
Review & Maintenance
Feasibility Study
Project Specification
Design is building upon the analysis to develop the selected solution
Section 01 Systems Development 20
SSADM
• 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
A STRUCTURED METHODOLOGY
Section 01 Systems Development 21
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 22
PROTOTYPING
• 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
A STRUCTURED METHODOLOGY
Section 01 Systems Development 23
Prototyping - amended lifecycle
Identify basicInformationRequirements
Develop Systemto fulfil basicRequirements
Experiment withbasic system inApplication area
Refine Prototypeto reflect knownRequirements
Success depends on available tools:
Application Packages
Program Generators
4GLs
Section 01 Systems Development 24
Spiral Model
Risk analysis based on initial requirements
PlanningPlanning Risk analysisRisk analysis
Customer evaluationCustomer evaluation EngineeringEngineering
Risk analysis based on customer reaction
Go, no-go decision
Toward a completedsystem
Initial software prototype
Next prototype level
Engineered system
Customerevaluation
Planning basedon customercomments
Initial requirementsgathering and projectplanning
A STRUCTURED METHODOLOGY
Section 01 Systems Development 25
Object Oriented Lifecycle
• Different emphasis needed (OMG : Bennett et al)
Object Modelling
Life Cycle
Coordination and reuse
Strategic modelling
Analysis modelling
Design modelling
Implementation Mod.
Construction
Delivery
Full definition of the system
A STRUCTURED METHODOLOGY
Section 01 Systems Development 26
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 27
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 29
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 lock-in…" (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 30
• 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 31
Why things go wrong
Type of Failure Reason for Failure Comment
QualityProblems
ProductivityProblems
Wrong problem addressedSystem conflicts withbusiness strategy
Wider influences are neglectedOrganisational culturemay be ignored
Analysis carried out incorrectly
Project undertaken for wrongreason
Users change their mind
External events change theenvironment
Implementation is not feasible
Poor project control
Team poorly skilled orinadequately resourced
From Bennett et. al. (1999)
Technology pull orpolitical push
New legislation
May not be known untilproject has startedInexperienced projectmanager
Requirements drift
Section 01 Systems Development 32
The impact of change
0102030405060708090
100
Definition Development Maintenance
Cost to change
Section 01 Systems Development 33
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 34
Real World Situation II
• stages blurred • customer often wants to
see ‘real s/ware’– prototyping
• requirements frozen?– iterate back between the
stages
• less suited to newer programming
that’s the theory but what about the real world?
Section 01 Systems Development 35
Towards Computerisation• What is needed to be done to move from position A to B?
A B
Paper Based Computer Based
?
• Increase Revenue– boost sales
• Avoid Costs– cheaper production or labour
• Improve Service– to achieve other two above
• acronym IRACISIRACIS
Why Computerise?
Section 01 Systems Development 37
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 38
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 39
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• communication skills / working alone & in teams• facilitating groups / managing expectations
Section 01 Systems Development 40
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 41
“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 42
Systems Analysis & Design• Analysis is the problem
solving stage
Systems Investigation
Systems Analysis
Systems Design
Systems Implementation
Review & Maintenance
Feasibility Study
Project Specification
Design is building upon the analysis to develop the selected solution
Section 01 Systems Development 43
Project Selection
Feasibility Study
SystemInvestigation
SystemAnalysis
SystemDesign
SystemImplementation
Review &Maintenance
“Construction builds the system in a series of iterations. Each iteration is a mini
project. You do analysis, design, coding, testing and integration for
the use cases assigned to each iteration.”
Fowler, 1997
“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 44
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).
• The ‘problem’, therefore, is the gap between the present situation and a more desirable one.”
(Nolan 1989)Is this Problem Solving?A B
?
PROJECT SPECIFICATION STAGE
Section 01 Systems Development 45
PROJECT SPECIFICATION STAGE
The Mess! Problem Definition
Generate Ideas Gaining Acceptance
Data Gathering
Solution Finding
Identifying The Problem
Section 01 Systems Development 46
• Having identified a problem area we need to produce a Project Specification
• Structured Systems Development : starting point to project work
Problem Definition
PROJECT SPECIFICATION STAGE
Project Specification is also referred to as a TERMS OF REFERENCE
Section 01 Systems Development 47
PROJECT SPECIFICATION• PROJECT TITLE• AUTHOR• SUPERVISOR• PROPOSER• OBJECTIVES • AIMS• RESOURCES & CONSTRAINTS• SCHEDULE• Sample to review in tutorialSample to review in tutorial
Section 01 Systems Development 48
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 49
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 50
• 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 51
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 52
• 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 53
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 54
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 55
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 56
Read the Supplement on
Systems Development Life Cycle
Read the Example report on
British WebObject Management System
Top Related