Presentation on theme: "Section 01Systems Development1 01 Systems Development And Franchise Colleges By MANSHA NAWAZ."— Presentation transcript:
Section 01Systems Development1 01 Systems Development And Franchise Colleges By MANSHA NAWAZ
Section 01Systems Development2 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 01Systems Development3 What Is SAD, BSA or SD? Developing Computer Systems !
Section 01Systems Development4 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 01Systems Development5 Computer Systems in Organisations Transaction Processing Systems Banking Systems EPOS Systems Healthcare Systems Insurance Systems Leisure Industry
Section 01Systems Development6 Computer Systems in Organisations Real-Time Systems Automated Production Control Control Systems Security Systems
Section 01Systems Development7 Computer Systems in Organisations Management Information Systems Decision Support Systems Office Automation Systems Knowledge Based Systems Executive Information Systems
Section 01Systems Development8 Problem Solving & Computers Follows a set Human of rules HighlyHighly non-programmed Transaction Executive Processing Information Systems Requires human interpretation
Section 01Systems Development9 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 01Systems Development10 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 01Systems Development11 Forces on Systems Development Systems Development Legal Requirements Users Company Politics Ethical Issues Technical Issues ENVIRONMENT Time Development Approach
Section 01Systems Development12 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 01Systems Development13 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 01Systems Development14 What is Structured Methodology ? General statement –Avison ”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 01Systems Development16 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 01Systems Development17 Yourdon developed the standardisation of CASE tool & techniques. Model –process oriented Language –graphical, dfds etc. Steps –essential model etc. Guide –texts, courses, tools
Section 01Systems Development18 Waterfall Life Cycle May have iterations but these are very costly Systems Investigation Systems Analysis Systems Design Systems Implementation Review & Maintenance Feasibility Study Project Specification “Waterfall” Approach A STRUCTURED METHODOLOGY
Section 01Systems Development19 Systems Analysis & Design Analysis is the problem solving stage Systems Investigation Systems Analysis Systems Design Systems Implementation Review & Maintenance Feasibility Study Project Specification v Design is building upon the analysis to develop the selected solution
Section 01Systems Development20 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 01Systems Development21 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 01Systems Development22 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 01Systems Development23 Prototyping - amended lifecycle Identify basic Information Requirements Develop System to fulfil basic Requirements Experiment with basic system in Application area Refine Prototype to reflect known Requirements Success depends on available tools: Application Packages Program Generators 4GLs
Section 01Systems Development24 Spiral Model Risk analysis based on initial requirementsPlanning Risk analysis Customer evaluation Engineering Risk analysis based on customer reaction Go, no-go decision Toward a completed system Initial software prototype Next prototype level Engineered system Customer evaluation Planning based on customer comments Initial requirements gathering and project planning A STRUCTURED METHODOLOGY
Section 01Systems Development25 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 01Systems Development26 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 01Systems Development27 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 01Systems Development29 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 01Systems Development30 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 01Systems Development31 Why things go wrong Type of Failure Reason for FailureComment Quality Problems Productivity Problems Wrong problem addressed System conflicts with business strategy Wider influences are neglected Organisational culture may be ignored Analysis carried out incorrectly Project undertaken for wrong reason Users change their mind External events change the environment Implementation is not feasible Poor project control Team poorly skilled or inadequately resourced From Bennett et. al. (1999) Technology pull or political push New legislation May not be known until project has started Inexperienced project manager Requirements drift
Section 01Systems Development32 The impact of change
Section 01Systems Development33 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 01Systems Development34 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 01Systems Development35 Towards Computerisation What is needed to be done to move from position A to B? A B Paper BasedComputer Based ? Increase Revenue –boost sales Avoid Costs –cheaper production or labour Improve Service –to achieve other two above IRACISacronym IRACIS Why Computerise?
Section 01Systems Development36 Role of Systems Analyst
Section 01Systems Development37 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 01Systems Development38 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 01Systems Development39 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 01Systems Development40 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 01Systems Development41 “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 01Systems Development42 Systems Analysis & Design Analysis is the problem solving stage Systems Investigation Systems Analysis Systems Design Systems Implementation Review & Maintenance Feasibility Study Project Specification v Design is building upon the analysis to develop the selected solution
Section 01Systems Development43 Project Selection Feasibility Study System Investigation System Analysis System Design System Implementation 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 01Systems Development44 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? AB ? PROJECT SPECIFICATION STAGE
Section 01Systems Development45 PROJECT SPECIFICATION STAGE The Mess! Problem Definition Generate IdeasGaining Acceptance Data Gathering Solution Finding Identifying The Problem
Section 01Systems Development46 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 01Systems Development47 PROJECT SPECIFICATION PROJECT TITLE AUTHOR SUPERVISOR PROPOSER OBJECTIVES AIMS RESOURCES & CONSTRAINTS SCHEDULE Sample to review in tutorialSample to review in tutorial
Section 01Systems Development48 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 01Systems Development49 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 01Systems Development50 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 01Systems Development51 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 01Systems Development52 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 01Systems Development53 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 01Systems Development54 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 01Systems Development55 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 01Systems Development56 Read the Supplement on Systems Development Life Cycle Read the Example report on British WebObject Management System
Section 01Systems Development57 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