Systems Analysis and Design I

1. Systems Analysis and Design I Session 2 Software development methodology and OO

2. Recap • IS are universal and predate modern computers (IT) • Different Types of IS • Operational systems, management support systems, office systems, real-time control systems. • 3 Management Levels (operational, tactic, and strategic) • Data, Information and Knowledge • Problems in the development of IS • 3 types of main players (stakeholders)  3 perspectives • Quality Problems and Productivity Problems • Essence and Accidents of Software Development

3. Today • Software (IS) development methodology • Preliminaries of Object-Orientation

4. Avoiding the Problems

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

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

7. 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. 7

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

9. 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. 9

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

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

12. 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?” 12

13. 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?” 13

14. 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?” • 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?” 14

15. Project Lifecycles • Traditional Lifecycle 15

16. Analysis != Design • Analysis identifies ‘what’ the system must do • The analyst seeks to understand the organisation, its requirements and its objectives • Design specifies ‘how’ it will do it • The designer seeks to specify a system that will fit the organisation, 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’ 16

17. Traditional Lifecycle: Strengths & Problems • Tasks in different 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 lifecycle • 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 17

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

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

20. Incremental Development • Software is developed in a series of increments until complete. • Functionality is added increment by increment, with functionalities generally being added during earlier increments. • Deliver working, free-standing, useful ‘chunks’ of software, one at a time. 20

21. Iterative & Incremental Development: Spiral Model 21

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

23. Take Home Messages • Project Lifecycles • Traditional Lifecycle (TLC) / Waterfall • Iterative & Incremental Development / Spiral 24

24. Software Development Processes

25. Building a Doghouse • Drive to the DIY store and buy some timber and nails • … • By the end of the afternoon, you'll have a new house for Fido • Oops, you forgot a door(or made some other mistakes) • Well, it’s not a big problem. You can fix it or even start over from the beginning. • All you‘ve wasted is justan afternoon 26

26. Building a House • Now you want a new home for yourself. • Draw outline on the ground. • Order some timber, nails, plumbing and cables. • Get tools. • Start putting together wooden boards. • Run plumbing and cables through the house. • … • Oops, you suddenly realise that a wall is not in the right place. So you rip out the wall and move it to six inches away. 27

27. Building a House • No! That's not the way to build a house. • You will waste a lot of money and a lot of time - productivity problem • The house will probably collapse - quality problem • Clearly you have to go further than just tools and techniques. • A fool with a tool … • You need something broader: • a methodology (an overall philosophical and systematic approach to the problem) 28

28. Building Doghouse vs House • The loose approach to building a doghouse is appropriate for small software projects too. • If you use the wrong design for 1000 lines of code, you can change or start over completely without losing much. • However, when building a house or larger software, certain stepsshould be taken: • careful planning (to avoid collapsing buildings/failedsoftware projects) • systematic approach (reasonable sequence ofsteps) • getting the right people (different areas of expertise) • financing the project • and so on 29

29. Process, Method and Methodology • Often confused, as if they were all the same thing, but actually these terms differ • Some authors use method to mean methodology • Some authors use process for both! 30

30. Process, Method and Methodology • Process/Method = a step-by-step description of the steps involved in doing a particular job. [Since no two projects are ever identical, any method is specific to one project.] • Applying methods is like “cooking by strictly followinga recipe” • Methodology = a set of general principles that guide the choice of a method suited to a specific task or project. • [recall: a methodology is an overall philosophical and • systematic approach to the problem] • Applying methodologies is knowing about “whycertain steps are taken while preparing a meal” 31

31. Mixing Drinks: A Real-World Example • Tools: cocktail shaker, jigger, juicer, measuring spoons, knife, . . . • Techniques: stirring, shaking, blending, pouring, . . . • Process/Method: following a strict recipe while preparing adrink • Methodology: knowing about the philosophy • Running out of an ingredient, what to substitute? • Guest wants non-alcoholic version, what to use? 32

32. What Is a Methodology? • A collection of • Procedures • Techniques • Tools • Documentation Aids • Organised within a lifecycle or structure • An underlying philosophy that captures a particular view of the meaning and purpose of IS development --- Avison and Fitzgerald (2002) 33

33. Why Use a Methodology? • Advantages: • Helps produce better quality product • Documentation standards • Acceptability to users • Maintainability of software • Consistency of software • Helps ensure user requirements are met completely • Helps the project manager • Better control of project execution • Reduction in overall development costs • Promotes communication between stakeholders • Encourage the transmission of know-how throughout 34

34. Take Home Messages • Processes, Method and Methodology • What Is a Methodology? • Why Use a Methodology? 35

35. Unified Software Development Process (RUP/USDP)

36. Unified Process • Unified Software Development Process (USDP) • A public domain development methodology originally proposed by the same team (in Rational Software, 1999) who created UML • brought the Booch method, OMT and Objectory together • Large and complex • significant learning curve involved, or tailor to fit • Emphasise iterative and incremental lifecycles. • Rational Unified Process (RUP) • Proprietary methodology owned by IBM (since 2003) • The most mature OO methodology to date • USDP has been largely superseded by RUP (though they are very similar in their main aspects) 37

37. Phases and Workflows Transition Inception Elaboration Construction 3 1 2 4 5 6 7 8 Project Phases Requirements Analysis Iterations within each phase Design Size of square relative to the time spent on a workflow Implementation Test Workflows

38. Phases • Phases are organised along time • Each phase consists of a number of iterations • Inception Phase • Determining the scope and purpose of the project • Elaboration Phase • Capturing the requirements • Determining the structure of the system • Construction Phase • Building the system • Transition Phase • Product installation and roll-out 41

39. Milestones • Phasesmatter to project managers • Phases are sequential and delineated by milestones • Manager’s focus shifts from one phase to the next Each milestone is a decision point– beginnext phase or stop now? 42

40. Workflows • Workflows are organised along content • Each workflow consists of a group of activities • 5 main workflows • Requirements • Analysis • Design • Implementation • Test • Workflows matter to developers 43

41. Main Activities • Requirements capture and modelling(use case model, requirements list, prototypes) • Requirements analysis (identify objects, communication diagrams) • System design (system architecture) • Class design (sequence and state diagrams, design class diagrams) • Interface design (interface specification, prototypes) • Data management design (database specification) • Construction • Testing • Implementation (installation)

42. Phases vWorkflows • Within each phase, activities iterate. • No set rule for the number of iterations. • Workflows within a phase are the same. • The balance of effort spent in each workflow varies from phase to phase • All phases run from requirements to testing, but emphasis changes. • At first, main effort is on capture, modeling, analysis of requirements. • Later phases emphasise implementation and testing. 45

43. UP v TLC or 2D v 1D Requirements Design Test Analysis Implementation Requirements Analysis Design Implementation Test • In a TLC project the phases and the workflows and activities are linked together • For example, in the Requirements phase only Requirements workflow activities are carried out; all Requirementswork should be completed before work starts on Analysis. • In aUnified Process projectthe phases and the workflows/activities are independent with each other • For example, some Requirements work may be happening alongside Analysis work. Another view of TLC 46

44. Take Home Messages • Unified Process • Phases and Workflows • 2D Structure 47

45. What Is Object-Orientation?

46. You’d have to be living face down in a moon crater not to have heard about object-orientedprogramming. Tom Swan Object-oriented programming is an exceptionally bad idea which could only have originated in California. Edsger Dijkstra

47. Object • An object is “an abstraction of something in a problem domain, reflecting the capabilities of the system to keep information about it, interact with it, or both.” • Coad and Yourdon (1990) • “We define an object as a concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand. Objects serve two purposes: they promote understanding of the real world and provide a practical basis for computer implementation.” • Rumbaugh et al. (1991) 50

48. Object • “Objects have state, behaviour and identity.” • Booch (1994) • Identity (Who am I?) • each object is unique • State (What do I know?) • the conditions of an object at any moment that affect how it behaves • Behaviour (What can I do?) • the way in which an object responds to messages 51

49. Objects A coffee machine object? 52

50. Identity != Equality • Different objects must have different identities • Different objects may have exactly the same state (be equal) • e.g., twin brothers, two interchangeable blue pens, etc. [Java] if (obj1 == obj2) tests identity if (obj1.equals(obj2)) tests equality 53