01 Systems Development

1. And Franchise Colleges 01 Systems Development • By MANSHA NAWAZ 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 Systems Development

3. What Is SAD, BSA or SD? Developing Computer Systems ! 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) Systems Development

5. Computer Systems in Organisations Transaction Processing Systems EPOS Systems Banking Systems Healthcare Systems Insurance Systems Leisure Industry Systems Development

6. Computer Systems in Organisations Real-Time Systems Automated Production Control Control Systems Security Systems Systems Development

7. Computer Systems in Organisations Management Information Systems Decision Support Systems Knowledge Based Systems Office Automation Systems Executive Information Systems Systems Development

8. Problem Solving & Computers Follows a set Human of rules Requires human interpretation Highly Highly non- programmed programmed Transaction Executive Processing Information Systems Systems 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 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’ Systems Development

11. Ethical Issues Users Systems Development Company Politics Legal Requirements Technical Issues Forces on Systems Development ENVIRONMENT Development Approach Time 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 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 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 Systems Development

15. Structured Methodology • Yourdon • WATERFALL • SSADM • Prototyping • Object Oriented • etc Systems Development

16. 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 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 Systems Development

18. Project Specification Feasibility Study “Waterfall” Approach Systems Investigation Systems Analysis Systems Design Systems Implementation Review & Maintenance Waterfall Life Cycle A STRUCTURED METHODOLOGY May have iterations but these are very costly Systems Development

19. Project Specification Feasibility Study Systems Investigation Systems Analysis Systems Design Systems Implementation Review & Maintenance Systems Analysis & Design • Analysis is the problem solving stage • Design is building upon the analysis to develop the selected solution Systems Development

20. 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 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 Systems Development

22. 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 Systems Development

23. Identify basic Information Requirements Develop System to fulfil basic Requirements Experiment with basic system in Application area Refine Prototype to reflect known Requirements Prototyping - amended lifecycle Success depends on available tools: Application Packages Program Generators 4GLs Systems Development

24. Risk analysis based on initial requirements Planning Risk analysis Initial requirements gathering and project planning 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 Spiral Model A STRUCTURED METHODOLOGY Systems Development

25. Object Oriented Lifecycle A STRUCTURED METHODOLOGY • Different emphasis needed (OMG : Bennett et al) Life Cycle Strategic modelling Analysis modelling Object Modelling Full definition of the system Design modelling Implementation Mod. Construction Delivery Coordination and reuse 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 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 Systems Development

28. 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) 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? Systems Development

31. Why things go wrong Type of Failure Reason for Failure Comment System conflicts with business strategy Wrong problem addressed Organisational culture may be ignored Quality Problems Wider influences are neglected Team poorly skilled or inadequately resourced Analysis carried out incorrectly Project undertaken for wrong reason Technology pull or political push Requirements drift Users change their mind Productivity Problems External events change the environment New legislation May not be known until project has started Implementation is not feasible Inexperienced project manager Poor project control From Bennett et. al. (1999) Systems Development

32. The impact of change 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 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? Systems Development

35. 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 • boost sales • Avoid Costs • cheaper production or labour • Improve Service • to achieve other two above • acronym IRACIS Systems Development

36. Role of Systems Analyst 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]. Systems Development

38. You Use Analysis Every Day • e.g. ExpeditionScenario • 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? 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 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 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 Systems Development

42. Project Specification Feasibility Study Systems Investigation Systems Analysis Systems Design Systems Implementation Review & Maintenance Systems Analysis & Design • Analysis is the problem solving stage • Design is building upon the analysis to develop the selected solution Systems Development

43. “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 Project Selection Feasibility Study System Investigation 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 System Design System Implementation Review & Maintenance Systems Development

44. ? A B 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). • The ‘problem’, therefore, is the gap between the present situation and a more desirable one.” (Nolan 1989) Is this Problem Solving? Systems Development

45. PROJECT SPECIFICATION STAGE Identifying The Problem Data Gathering Problem Definition The Mess! Generate Ideas Solution Finding Gaining Acceptance Systems Development

46. 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 Systems Development

47. PROJECT SPECIFICATION • PROJECT TITLE • AUTHOR • SUPERVISOR • PROPOSER • OBJECTIVES • AIMS • RESOURCES & CONSTRAINTS • SCHEDULE • Sample to review in tutorial 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 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. 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 ?" Systems Development