Systems Analysis and Design I

1. Systems Analysis and Design I Session 1: Introduction

2. Outline • What are information systems? • Problems in information systems development • Avoiding problems (Information system life-cycles)

3. What are Information Systems?

4. Information Systems—”Definition” • A system is a complex set of interacting parts that act as if they were a single unified thing • Some characteristics • A system exists in an environment • A system is separated from its environment by some kind of boundary • A shared boundary between two systems or between a system and its environment is known as interface • A system receives inputs from its environment and send outputs into its environment, and transforms its inputs in some way to produce its output • A system has a control mechanism, altering the way it operates and relying on feedback • …

5. Data, Information and Knowledge • An information system is something that people create to capture, store, organise and display information • Data = raw facts representing values, quantities, concepts and events pertaining to relevant activities (in Latin, data=“given”) • e.g., telephone numbers • Information = data that have been processed or summarised to produce value-added facts, revealing features and trends • e.g., telephone numbers grouped by their areas, industries • Knowledge = understanding of information, obtained by experience or study, and resulting in the ability to do things effectively and efficiently. • tacit (in a person’s mind) or documented (in some form) • e.g., how the telephone numbers can be used in telemarketing to entice people to buy products 5 --- Maciaszek, L.A.:Requirements Analysis and System Design, (3rded). Addison Wesley, 2007

6. Information Systems – Types • IT has revolutionised the field of information systems • A brief overview of some general types of applications in organisations: • Operational Systems automate the routine, day-to-day record-keeping tasks • Management Support Systemshelp managers to decide or to communicate • Office Systemsautomate or assist in the work of office workers, e.g. clerks, secretaries, typists and receptionists. • Real-Time Control Systems typically operate physical equipment, often in safety-critical settings 6

7. IS for three levels of management 7 --- Maciaszek, L.A.:Requirements Analysis and System Design, (3rded). Addison Wesley, 2007

8. IS: operational systems • Recall: at the “data” level • Online Transaction Processing (OLTP) systems • Examples: accounting systems • The information flow is based on thousands or millions of similar transactions • Each represents an exchange of a quantity • Transaction – a logical unit of work that accomplishes a particular business task and guarantees the integrity of the database after the task completes • Database technology • persistent storage • concurrency control • integrity constraints • security 8 --- Maciaszek, L.A.:Requirements Analysis and System Design, (3rded). Addison Wesley, 2007

9. IS: tactical management systems • At the “information” level • OnLineAnalytical Processing (OLAP) systems • Analysis of pre-existing historical data to facilitate decision making • Data warehouse technology • summarising (aggregation) • packaging (into graphs, charts, spreadsheets, animations, ...) • partitioning (reducing amount of data) • Data marts • subset of data relevant to a particular dept/function • Data webhouses 9 --- Maciaszek, L.A.:Requirements Analysis and System Design, (3rded). Addison Wesley, 2007

10. IS: strategic management systems • Knowledge Processing Systems • “know-how” – intellectual capital accumulated through experience • Knowledge Management – to help organisations discover, organise, distribute and apply the knowledge encoded in information systems • Data mining • association (patters of one event leading to another) • classification (facts that fall into predefined categories) • clustering (categories discovered by an algorithm) • AI techniques predictive rather than retrospective models 10 --- Maciaszek, L.A.:Requirements Analysis and System Design, (3rded). Addison Wesley, 2007

11. Take Home Messages • Information systems have been used throughout history using whatever technology was available at the time • Information technology is the machinery that makes an IS work • Today this usually involves a digital computers (but not necessarily) • Different Types of Information Systems • 3 Management Levels (operational, tactic, and strategic) • Data, Information and Knowledge 11

12. Problems in Information Systems Development

13. Outline • What Are the Problems? • Section 2.2 (pp. 44 – 52) • Why Things Go Wrong? • Section 2.3 (pp. 52 – 56) • Essence and Accidents of Software Development 13

15. An Exaggeration? Out of 50,000 projects in the study, 71% of software projects fail to meet these three criteria: on time, on budget, and with satisfactory results (The Standish Group “CHAOS” report, 2015) 15

16. Three types of players in IS projects • IS development is a complex activity that always involve people: • end-users • those who will benefit from the system’s outputs, directly or indirectly • clients • managers, those who have control or influence over the initiation, direction or progress of the project • [person(s) responsible for paying for the development] • developers • those who are responsible for the development of the IS 16

18. End-user’s perspective • “What system? I haven’t seen a system.” • vapourware -- projects that are much talked about, but never finished • “It might work, but its dreadful to use!” • poor interface, incomprehensible error messages, • unhelpful 'help', poor response time, unreliability • “It’s very pretty, but does it do anything useful?” 18

19. Client’s perspective • “If I’d known the real price, I’d never have agreed.” • “It’s no use delivering it now, we needed it last April!” • “OK, so it works, but the installation was such a mess my staff will never trust it.” • “I didn’t want it in the first place.” [pretty like Brexit ;-)] • “Everything has changed now, we need a completely different system.” 19

20. Developer’s perspective • “We built what they saidthey wanted.” • “There wasn’t enough time to do it any better.” • “Don’t blame me, I’ve never done OO analysis before!” • “How can I fix it? I don’t know how it’s supposed to work.” • [when modify an existing system] • “We said it was impossible, but no-one listened.” • [developers can be overwhelmed by organisational politics] • “The system is fine. The users are the problem.” 20

21. Why Things Go Wrong? We are faster! We are better! 21 https://en.wikipedia.org/wiki/Pirates_of_Silicon_Valley

22. Why Things Go Wrong? • Quality Problems • Definition of “quality”: fitness for purpose • But what is the purpose? How to measure the fitness? • The wrong problem is addressed • System conflicts with business strategy • The context is neglected • Organisation culture may be ignored • The system analysis or design is performed incorrectly • Team is poorly skilled or inadequately resourced (e.g., not enough time allowed) • The project is carried out for the wrong reason • Technology pull or political push (e.g., the dot.com crashes) 22

23. Why Things Go Wrong? • Productivity Problems • Related to the rate of progress of a project, and the resources that it consumes along the way • Customers change their minds about the requirements • Requirements drift • External events change the environment • e.g., new legislation (Brexit?). • Implementation is not feasible • May not be known until the project has started • Poor project management • Inexperienced management or political difficulties 23

24. Brooks' Law Adding manpower to a late software project makes it later. Frederick Phillips "Fred" Brooks Jr. (born April 19, 1931) is an American computer architect, software engineer, and computer scientist, best known for managing the development of IBM's System/360 family of computers and the OS/360 software support package. Brooks has received many awards, including the National Medal of Technology in 1985 and the Turing Award in 1999 27

25. The Mythical Man-Month • 100 Man-Month? • 1 Man x 100 Month • 10 Man x 10 Month • 100 Man x 1 Month Group Intercommunication Formula: n (n−1)/2 e.g., 50 developers give 50·(50–1)/2=1225 channels of communication 28

26. No Silver Bullet “Essence and Accidents of Software Engineering” by F.P. Brooks 29

27. The essence of software development • Difficulties defined by the issues inherent in the software itself • software is a product of a creative act (not a result of a repetitive act of manufacturing) • Software development inherent properties • (not amenable to ‘silver bullets’ or breakthroughs): • complexity (no repetitive elements) • Complexity grows non-linearly with size • conformity (to old interfaces, no redesign) • changeability (is often used beyond the original domain) • Because business processes and requirements are in a constant state of flux, application software must be built to accommodate change. • invisibility (no geometric representation) 30

28. The accidents of software development • Difficulties that today attend its production but that are not inherent • Software development variables: amenable to human intervention • attributed mostly to the fact that an information system is a social system • the software solution must not be adding to the inherent complexity of the software product • adaptiveness (supportability) is the challenge • = understandability + maintainability + scalability (extensibility) • related to • stakeholders, process and modelling 31

29. Take Home Messages • What Are the Problems? • 3 types of main players  3 perspectives • Why Things Go Wrong? • Quality Problems • Productivity Problems • Essence and Accidents of Software Development 34

30. Avoiding the Problems

31. I have a need. I can help. What do you need? Development as Conversation • Sales Customer Developer --- Teach Yourself Extreme Programming In 24 Hours. 36

32. What I need is … I understand. Development as Conversation • Requirements Customer Developer --- Teach Yourself Extreme Programming In 24 Hours. 37

33. If we built this would it meet your need? Yes. Start working. Development as Conversation • Design Customer Developer --- Teach Yourself Extreme Programming In 24 Hours. 38

34. What are you doing? Programming. Please wait. Development as Conversation • Build Customer Developer --- Teach Yourself Extreme Programming In 24 Hours. 39

35. I’m finished. Is this what you wanted? Let me check and see. Perfect! Development as Conversation • Test Customer Developer --- Teach Yourself Extreme Programming In 24 Hours. 40

36. Let’s launch it. Call me if there are any problems. Development as Conversation • Launch Customer Developer --- Teach Yourself Extreme Programming In 24 Hours. 41

37. Traditional Lifecycle (TLC) The TLC model is also called the waterfall lifecycle model because of the difficulty of returning to an earlier phase. 42

38. Traditional Lifecycle – Key Questions • 1. System Engineering: • “What is our context?” • “How will human, hardware and software get involved in?” • 2. Requirements Analysis: • “What are we trying to achieve?” • “What entities are we dealing with?” • “How can we be sure we have the right ones?” 43

39. Traditional Lifecycle – Key Questions • 3. Design: • “How are we going to solve the problem?” • “What hardware and software will we need in the finished system?” • “How are we going to implement the solution?” • “What will the source code and supporting files look like?” • “What rules govern the interfaces between the system components?” • “Can we remove ambiguity and ensure correctness?” 44

40. Traditional Lifecycle – Key Questions • 4. Construction: • “How can we code the components to meet the specification?” • “How do we write stylish code?” • 5.Testing: • “Does the finished system satisfy the requirements?” • “Can we break the system?” 45

41. Traditional Lifecycle – Key Questions • 6. Installation: • “What do the system administrators have to do?” • “How can we educate the end users?” • 7. Maintenance: • “Can we find and fix the faults?” • “Can we improve the system?” 46

42. Project Lifecycles • Traditional Lifecycle 47

43. Analysis != Design • Analysis identifies ‘what’ the system must do • The analyst seeks to understand the organization, its requirements and its objectives • Design specifies ‘how’ it will do it • The designer seeks to specify a system that will fit the organization, provide its requirements effectively and assist it to meet its objectives • It is important to distinguish the two activities and the associated mindset • We need to know ‘what’ before we decide ‘how’ 48

44. Traditional Lifecycle: Strengths & Problems • Tasks in phases may be assigned to specialised teams • Project progress evaluated at the end of each phase • Can be used to manage projects with high levels of risks • Real projects rarely follow such a simple sequential life cycle • Iterations are almost inevitable in real projects but are expensive and problematic with the TLC • Lapsed time between systems engineering and the final installation is long • Unresponsive to changes during project as iteration is difficult Underlying assumptions: • perfect understanding between developers and customers • a crystal ball that foresees the future 49

45. The cost of this form of iteration increases as the project progresses making it impractical and not effective Waterfall Lifecycle with Feedback Loops 51

46. Iterative Development • Divide the project into many iterations, each of which can be viewed as a mini-project in its own right. 52

47. Incremental Development • Deliver working, free-standing, useful ‘chunks’ of software, one at a time. 53

48. Iterative & Incremental Development: Spiral Model 54

49. Iterative & Incremental Development: advantages • risk mitigation — making it possible to identify risks earlier and to take action • change management — changes to requirements are expected and properly managed • team learning — all the team can be involved from the start of the project • improved quality — testing begins early and is not done as a ‘big bang’ with no time 55

50. Project Lifecycles Attack major risks early and continuously, or they will attack you. 56