And Franchise Colleges 01 Systems Development By MANSHA

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 Systems Section 01 Security Systems Development 6

Computer Systems in Organisations Management Information Systems Decision Support Systems Knowledge Based Systems Office Automation Systems Section 01 Executive Information 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 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 Eth ica l Is sue s ser U s Systems Development Company Politics Te ch Iss nica ue l s ts en m l ga ire Le qu Re Section 01 Development Approach Time 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 these are very costly Section 01 “Waterfall” Approach Systems Design 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 is building upon the analysis to develop the selected solution v 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 – 4 GL 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 4 GLs Section 01 Systems Development 23

Spiral Model A STRUCTURED METHODOLOGY Initial requirements gathering and project planning Planning 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 Strategic modelling Object 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 £ 319 m 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 £ 136 m since it was signed in 1998" (Computer Weekly 28 June 2001) "DVLA savings disappear. EDS proposed 30% savings from £ 5 m vehicle software but DVLA underestimated the technology challenge. " (Computer Weekly 30 August 2001) "Financial services company Prudential Europe has terminated a £ 35 m 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, p 4) • "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 Slater, 1995, p 3) • 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 Section 01 Systems Development 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 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 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 • 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 is building upon the analysis to develop the selected solution v 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, Fox. Pro, 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 Web. Object 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