1. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 1 Systems development Methodologies IN364

2. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 2 Agenda What is systems development Theories, methodologies, process models and tools for systems development Different process models A mixed approach Prototyping

3. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 3 What is systems development? Efforts concerning the product and the efforts concerning the process Reflective efforts and efforts resulting in changes Reflective efforts concerning the existing and visions

4. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 4 Different perspectives on SD A process of construction A process of organisational change A process of learning A political process

5. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 5 Theory in Systems Development We need an independent understanding of system development – enable us to understand the situation and compare and select properly between different approaches Task/problem“Solution” RoutineKnown Problem solvingKnownUnknown Problem definitionUnknown Situation Properties

6. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 6 Methodology Method: – Experiences in the form of a recipe – Gives practical advices – how to approach the task Methodology: In addition built on a philosophy Definition “A collection of procedures, techniques, tools and documentation aids which will help the systems developers in their efforts to implement a new information system. A methodology will consists of phases, themselves consisting of sub-phases, which will guide the systems developers in their choice of the techniques that might be appropriate at each stage of the project and also help them plan, manage, control and evaluate information systems projects” (Avison and Fitzgerald (2003))

7. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 7 Objectives of methodologies Examples: –Accurately recording of user needs –Systematic method for effectively monitoring of the process –To provide indications of changes as early as possible in the process –Produce a well documented and easy to maintain IS

8. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 8 Techniques and tools A technique is the doing of a particular activity –Elicit user needs –Describe analytical results A technique may involve the use of one or more tools –Rational rose to draw UML diagrams

9. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 9 Software process models Process model: “Determine the order of the phases/stages involved in a software development process and establish the transition criteria for progressing from one stage to the next” The wrong order of phases can jeopardize a project

10. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 10 Different process models Ad-hoc and native process model Specification/documentation driven process model Implementation/representation driven process model Risk driven process model

11. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 11 Why different models? Evolution – maturization Experiences with failures Historical development More sophisticated tools From only appreciation only the programmer to also include analysts and designers Changing relation between users and developers

12. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 12 Process models Code and fix Write some code Fix the problems in the code Requirement, design, test and maintenance at later stage – and after system in use Primary/fundamental problems –Unstructured code after multiple changes makes changes very expensive: Design is needed before coding –Poor match with user needs: Requirements eliciting is needed before design –Expensive fixing because of poor preparation for testing and modification: Preparation is needed

13. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 13 Process models II Stagewise Stagewise models –To meet the problems of code- and-fix by introducing successive stages, as for example: –The Waterfall model (1970) with two enhancements to the stagewise model: Feedback loops, but only to successive stages –Primary/fundamental problems Documents as completion criteria for early requirement and design phases – elaborated documents for poorly understood usages: Stages are pursued in the wrong order

14. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 14 Process models III Evolution To meet the problems of the stagewise models –By expanding increments of operational software directed by operational experience Primary/fundamental problems –Difficult to distinguish from the code-and-fix model –It is difficult to follow any evolutionary path due to interdependencies –Stages are pursued in the wrong order, as much hard to change code is developed before interdependencies are taken care of

15. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 15 Process models IV Spiral model A general and pragmatic model Each cycle is basically identical 1.Identification of objectives of the product, alternative means of implementation and constraints imposed 2.Evaluate the alternatives of 1, and identify uncertainty and plan how to solve them 3.Develop 4.Plan next cycle Allows a varying degree of completeness, formality and granularity of specifications Primary/fundamental problems Best suited for in-house development A great reliance on risk management

16. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 16 Risk management Identify risk items Plan how to resolve each risk, and maintain a list as the project proceeds Initiate appropriate corrective actions Probability Effects/ Consequences

17. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 17 A Mixed approach Complexity: –The amount of relevant and available information for making design decisions Uncertainty: –The availability and reliability of other information that could be relevant Abstraction and decomposition to reduce complexity: Specifying Prototypes to reduce uncertainty Combination of analytical and experimental approaches to handle both complexity and uncertainty

18. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 18 The experiments Students at UCLA and AU Simple functionality, uncertain GUI Rated after functionality, robustness, ease of use, ease of learning SpecifyingPrototypingMixed approach Functionality +-+ Robustness +-+ Ease of use -++ Ease of learning -++

19. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 19 Mixed approach II Specification: Analytical mode of operation –Abstraction to reduce complexity –Relies on available and reliable information –Simplification –No possibility for user to learn about the system Prototypes: Experimental mode of operation –Meets some of the limitation of specification –But communication and involvement of users gives raise to other challenges as more information

20. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 20 Mixed approach III Mode of operation: –Analytical (simplifying by abstraction) –Experimental (generating information by learning) Means of expression: –Specification (abstract description) –Prototypes (concrete behavior) Complexity and uncertainty are not independent –Analytic approach introduces new uncertainties by simplification of the world –Experiments produces information introducing new sources of complexity

21. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 21 Principle of limited reduction Complexity Uncertainty Experimental and prototyping Analytical and specifying

22. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 22 Mixed approach IV Approach Means of expression Mode of Operation Prototypes Specifications Experimental Analytical

23. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 23 Mixed approach V The Principle of limited reduction: “Relying on analytical behavior to reduce complexity introduces new sources of uncertainty requiring experimental countermeasures. Correspondingly, relying on experimental behavior to reduce uncertainty introduces new sources of complexity requiring analytical countermeasures.” (pp. 69) Means of expression require a certain mixture of analytical and experimental approach –Plans are analytical countermeasures to an experimental approach based on prototypes –Quality assurance as walkthroughs are experimental countermeasures to an analytical approach

24. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 24 Methodology in practice The concepts underpinning most methodologies origins from the 1967 – 1977 (prototyping, stagewise, user-participation) Most methodologies favors large-scale development, with a long development time – in conflict with continuous change and focus on short term requirements of the market Survey, 776 named individuals in different organizations “who were likely to be directly involved or responsible for system development” (Fitzgerald 1998 and 2000)

25. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 25 Methodology usage in practice II Type of projects: Average number of developers: 3.47 Average duration (in months): 5.72

26. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 26 Methodology usage in practice III Profile of current development environment

27. 17.03.2003 Petter Nielsen (pnielsen@ifi.uio.no) Information Systems/IFI/UiO 27 Methodology usage in practice IV Average percentage of development time allocated to development activities