1. ITK-AM’05 © J.Stirna Analys och modellering av kommunikativa system och system för sammarbe Analysis and Modelling of Communicative Systems Janis Stirna Dept. of Computer and Systems Sciences Kungliga Tekniska Högskolan (KTH) Stockholm, Sweden js@dsv.su.se

2. ITK-AM’05 © J.Stirna 2 Outline Current problems in IS and IS development Business perspective of IS Requirements Engineering Requirements Specification Modelling Models Your task now This preview is not about the course, it is about the subject area

3. ITK-AM’05 © J.Stirna 3 Current state in the IS business  Lots of systems  Large systems  Complex systems  Systems everywhere (ubiquitous computing)  Systems into everything (embedded systems)  Mission critical systems  Business-enabling systems ……  Bad systems  Expensive systems  Dangerous systems  Toy systems ……  Consultants  outsourcing  extreme  wireless  agile  cost cutting  e-business  enabling  tools  technologies …… Someone has to build all that and make profit doing so. How to avoid costly mistakes?

4. ITK-AM’05 © J.Stirna 4 Example of poor system design 2005-08-22 Phone call queue lasted: 12:14min The support agent did not know the meaning of the error code. She could not replicate the error on her PC. She suggested to delete cash and cookies or load the page in Netscape. The problem persisted … She offered do the booking via telephone, but since the customer was not sure about the dates and times the offer was declined. The customer booked a ferry later that day. Why displaying a meaningless error code? What are the goals? Customer’s goal: to buy the ticket Airline’s goal: to make profit and to stay in business for a long time Issues: Fault tolerance vs. error tolerance vs. user interface Analysis: Business goals  business system  information system requirements  design

5. ITK-AM’05 © J.Stirna 5 Business perspective of IS  People are an essential part of this Background image source: Alter S., Information Systems: A Management Perspective Goals Business processes IS components IS requirements: Why do we do this? How do we do this? What systems do we need to support our business?  Good systems support business, bad systems retard business  However, bad businesses cannot be saved by good IS

6. ITK-AM’05 © J.Stirna 6 The Problem of Software Delivery Study of 9 Federal Software Projects Total Amount 6.8 Million US$  29%$ 2.0 MPaid but never delivered  47%$ 3.2 MDelivered but never used  19%$ 1.3 MAbandoned or reworked  3%$ 0.2 MUsed after change  2%$ 0.1 MUsed as delivered Source: Curtis B., Krasner H., Iscoe N., A field study of the software design process for large systems., Communications of ACM, November 1988

7. ITK-AM’05 © J.Stirna 7 Typical IS Development Problems (ch2.2)  A system that is promised (sometimes even paid for) but not delivered  A system that is difficult to use  A system that does not meet its users’ needs  Projects that overspend their budget (may no longer have a net benefit). Overruns of 200% of time and budget are not uncommon.  Systems that are delivered too late  Badly managed projects – all involved experience deep disgust  Systems that are rendered irrelevant by events  Budget and time constraints often conflict with doing the job properly – “Faster, cheaper, better!!!”  Users and owners may not know how to ask for what they really want  Technologies, development approaches, and business needs all constantly change © Bennett, McRobb and Farmer 2002

8. ITK-AM’05 © J.Stirna 8 Why things go wrong: quality problems  The wrong problem is addressed  Failure to align the project with business strategy  Wider influences and the context are neglected  Project team or business managers don’t take account of the system environment  Incorrect analysis of requirements  Poor skills or not enough time allowed  No proper knowledge about requirements modelling  Project undertaken for wrong reason  Technology push  Internal politics © Bennett, McRobb and Farmer 2002

9. ITK-AM’05 © J.Stirna 9 Why things go wrong: productivity problems  Users change their minds  Changing requirements  External events  E.g. introduction of the Euro, Y2K, 9/11  Implementation not feasible  May not be known at start of the project  Poor project control  Inexperienced management or political difficulties © Bennett, McRobb and Farmer 2002

10. ITK-AM’05 © J.Stirna 10 Requirements engineers link business stakeholders and IS developers RE "stake-holders" - customers - users - domain-experts requirements engineers information system engineers programmers

11. ITK-AM’05 © J.Stirna 11 The role of Requirements Specification REQUIREMENTS ENGINEERING DESIGN ENGINEERING problems informal requirements domain knowledge acquisition validation design verification Requirements Specification: - text - models - graphs - formulas - etc. information system ITK-AM group assignment ITK-KAK group assignment

12. ITK-AM’05 © J.Stirna 12 Reality Requirements Specifications are used to communicate and to reason about the reality  Therefore we need a formal language… … a modelling language. En motor består åtminstone av en pistong och en cylinderblock. Antalet pistong är inte begränsade. Varje pistong är en del av en motor och varje cylinderblock är en del av en motor. Engine consists of at least one piston and one cylinder block. The number of pistons is not limited. Each piston is a part of one engine and each cylinder block is a part of one engine. Motors sastāv no vismaz viena virzuļa un viena cilindru bloka. Virzuļu skaits nav ierobežots. Katrs virzulis pieder kādam motoram un katrs cilindru bloks ir daļa no kāda motora. By using models we avoid misunderstandings and reduce vagueness which leads to less development mistakes and rework thus increasing profit from development.

13. ITK-AM’05 © J.Stirna 13 Modelling The real worldThe model world Abstracting Structuring Categorising Generalising The enterpriseThe ”modeller”The processThe model A set of cognitive skills and competencies Takes time and effort to become a good modeller Experience is required personal Then do “some- thing”

14. ITK-AM’05 © J.Stirna 14 Modelling is a cognitive process It involves activities such as identifying, abstracting, structuring, categorising, generalising, negotiating, designing…. --> thinking Different people think differently and develop different thinking approaches --> develop your own Experienced modellers probably think differently than novices  Experience modellers use mental pattern matching – e.g. if we want to model a purchase order and there are no additional peculiarities in sight then: ------------------------------->  Many of such mental patterns are captured in literature under the name Analysis or Design Patterns

15. ITK-AM’05 © J.Stirna 15 Examples of models In ITK-AM you will learn things such as:  What this means  What is this diamond  What does 1..* mean … and many other useful things

16. ITK-AM’05 © J.Stirna 16 ITK-P1 ITK-AM This term you will learn basic knowledge about how to develop systems Book title modelling Public class Book { Private String title; public Chapter getChapter(int){…} } implementation ITK-KAK

17. ITK-AM’05 © J.Stirna 17 Summary of ITK-AM objectives  To learn object-oriented system analysis and design  To learn basic principles of system analysis  To learn how to apply object-oriented system developed methods in practice --> therefore ITK-AM is related to ITK-KAK The bottom line: you cannot claim that you have been educated in computer science if you cannot deal with reasonably complex UML diagrams. The course will use Unified Modelling Language (UML) because it is de facto industry standard.

18. ITK-AM’05 © J.Stirna 18 Your task now  Get the book  E.g. buy used  Read ch. 2 (and why not ch. 1&3)  Write a short essay relating one or some of the problems discussed in ch2 to something you have experienced yourself or have read about.  Why do this now?  ITK-AM is not really about these problems per se  But you need to be aware of them  ITK-AM is about learning OO A&D and UML