Comparison Of Methodologies


Published on

Comparison Of Methodologies

Published in: Technology, Sports
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Comparison Of Methodologies

  1. 1. Chapter 13 Comparison of Methodologies . – p.41/192
  2. 2. Picking a Methodology You’ve got a team of 10-12 developers eagerly awaiting your instructions. Which methodology do you pick? Usually one of the following things is done Choice dictated by the methodologies used previously by the developer’s boss Using a new “hyped” methodology “Heard from a friend of my brother’s wife that it’s good.” There was this lecturer at the College. . . Comparing methodologies is like comparing apples to oranges . – p.42/192
  3. 3. Comparing Apples to Oranges Has been done before (using a Nicolet 740 FTIR spectrometer) In Annals of improbable research (Scott A. Sandford) Result: the two are very similar . – p.43/192
  4. 4. Comparing Apples to Oranges(2) Other people might have different opinions Biologist points to taxonomy, describing similarities and differences Nutrition expert has still another opinion... Observation: depending on who you ask, you get different answers . – p.44/192
  5. 5. Comparing Methodologies Same with methodologies: Computer scientist: tries to develop general (theoretical) framework for comparing methodologies Developer: tries to judge situation from prior experiences and case studies Senior management: tries to find out, if methodology will give certain quality assurances Vendor: tries to sell own product (so you have to read between the lines) . – p.45/192
  6. 6. Comparing Methodologies(2) So, how can we compare methodologies? 1. Describe “ideal” methodology, then compare to other methodologies Who determines what’s ideal? If we find ideal methodology, why use other methodologies? 2. Construct general comparison tool by selecting appropriate features 3. Develop a contingency framework to map appropriate methodology to a particular environment 4. Develop a common frame of reference for viewing different methodologies (provides a “meta-language”) . – p.46/192
  7. 7. Comparing Methodologies(2) We are going to look at: Theoretical model for comparison (Song and Osterweil) (2.) Checklists (3.)/Frameworks (4.) Capability Maturity Model (CMM levels) We are not going to look at: Brochures of vendors . – p.47/192
  8. 8. Theoretical Model Song and Osterweil criticize that previous comparison methods have been very unscientific Analysis and comparisons are activities common to many scientific fields E.g. comparing animals in biology in a systematic and objective way: Comparison of organs and inter-organ relations Usually organs (e.g. eyes) are classified by their functions (e.g. vision) Using this classification, organs having the same or similar functions can be identified and compared One compares structures (e.g. shape) and relations to other organs (e.g. brain) . – p.48/192
  9. 9. Theoretical Model(2) Comparison of methodologies should be done similarly: Comparisons of components and inter-component relations Components should be classified by their functions (what problems they address) Components should then be characterized by their structures Problem: methodologies and their components are often not rigorously defined Methodologies and their components themselves need to be modeled . – p.49/192
  10. 10. Overview Modeling Methodology 1 Formalism Methodology 2 Build Base Build Process Model Framework Process Model Process Model Process Model Classify Components Classification Develop Select Develop Process Code Comparison Topics Process Code Topics Process Code Process Code Make Comparison Topics Topics Difference Summarize Differences Summary . – p.50/192
  11. 11. Step 1: Build Process Model Develop a model, a more formalized description, of each of the two methodologies After doing so, methodology can hopefully be decomposed into components Problem: many components (e.g. guidelines, rules-of-thumb) lack precise semantics Model must be at higher abstraction level, yet be compact and clear A number of Software Process Modeling Formalisms (SPMF) have been developed for this . – p.51/192
  12. 12. Build Process Model(2) SPM by Williams is a typical SPMF Development process is described as a set of activities: SPM = {activity} An activity is described by a set of preconditions, an action, a set of postconditions, and a set of messages: activity = {{precond.}, action, {postcond.}, {msg}} Activities may be composed of other activities and may be performed in parallel Messages provide a means of communication and synchronization among various activities . – p.52/192
  13. 13. Step 2: Classify Components Having identified components, they are now classified This is done within a comparison framework, identifying components that address similar issues Typical issues are How is problem modeled? How is solution modeled? How is design documented? . – p.53/192
  14. 14. Describing Comparison Issues Concept: Understanding problems of IS development General principles of coping with these problems Concrete strategies that guide development Artifact: A description involved in the development process (e.g. code, diagrams) . – p.54/192
  15. 15. Describing Comparison Issues(2) Representation: Means for representing artifacts (e.g. document templates, design/modeling languages) Action: Physical and/or mental behaviors during development May create or modify an artifact . – p.55/192
  16. 16. Step 3: Select Comparison Topics Topics should be selected based upon goals of a specific comparison Two general criteria can always be used: Components should be comparable Comparison between them should help in showing key differences . – p.56/192
  17. 17. Select Comparison Topics(2) Classification may illustrate that two concepts address similar issues If so, one can select these two concepts for comparison and trace artifacts supporting the concepts representations representing the artifacts actions creating or modifying the artifacts And eventually find the artifacts, representations, and actions that could be compared . – p.57/192
  18. 18. Step 4a: Develop Process Code Process model developed in step 1 may be too abstract We have to identify detailed differences between compared components This more detailed modeling is called process code (to distinguish it from process model) This step is optional . – p.58/192
  19. 19. Step 4b: Make Comparison Typical criteria for comparing process code/model (again this depends on goal of comparison) Inter-component dependency Degree of human involvement Development procedure/order Scope of issues that methodology addresses . – p.59/192
  20. 20. Step 5: Summarize Aims at providing readers with an overview and a conclusion Should be organized around the comparison topics Should help indicate the main differences between components . – p.60/192
  21. 21. Summary of Theoretical Model Tries to help compare methodologies more systematically and objectively Has limitations It is almost impossible to capture all details of a methodology in a formal, rigorous model Modeling a methodology is a non-trivial task (ranging from hours to weeks) Conclusion: is probably not going to be used by practitioners, but helps understand findings of scientists . – p.61/192
  22. 22. Checklists/Frameworks Lots of checklists for choosing a methodology exist Contain many questions of the following or similar form How big is project? (small/medium/large) How much experience does project manager have (little/medium/much) What tool support is expected (no/partly/full) etc. After evaluating answers according to a certain scheme, an answer is delivered . – p.62/192
  23. 23. Checklists(2) This approach has many drawbacks: Methodologies (and their context) are much too complicated to be forced into simple recipes Answer materializes in a “magic” way, no knowledge about the rationale of the checklist creator . – p.63/192
  24. 24. Frameworks Frameworks are a more systematic way for evaluating methodologies Potential user (of a methodology) does not just check boxes and waits for answer Still somewhat subjective, will not satisfy everyone Frameworks raise important questions that user has to answer for him-/herself We are looking at two frameworks: NIMSAD: Normative Information Model-based System Analysis and Design Framework by Avison/Fitzgerald . – p.64/192
  25. 25. NIMSAD Aims: Help understand the area of problem solving (in general) Help evaluate methodologies, their structures, steps, form, nature, etc. Help in drawing conclusions Before presenting actual comparison, we take a look at how IS development (or problem solving in general) is perceived under NIMSAD . – p.65/192
  26. 26. Rationale NIMSAD framework has four essential elements Problem situation (methodology context) Intended problem solver (methodology user) Problem-solving process (methodology itself) Evaluation of the above . – p.66/192
  27. 27. Problem Situation Client Organizations serve as context for information systems This context is important for methodologies: Effectiveness of IS can only be judged in this context Interaction with organizational members during development Interpersonal relationships formed in this context . – p.67/192
  28. 28. Problem Solver Problem Solver Client However powerful, useful, and effective a methodology may be, success often depends on personal characteristics of problem solver: What does he/she select as relevant or dismisses as irrelevant? What are the implications of this selection? . – p.68/192
  29. 29. Mental Constructs of Problem Solver Perceptual process: One of the most influential characteristics Acts as a filter to determine what is perceived as significant Each person perceives reality differently Problematic if perception of problem solver does not match that of stakeholder . – p.69/192
  30. 30. Mental Constructs of Problem Solver(2) Values/Ethics: Beliefs that we consider to be “good” Help pass judgment on situations Example: participation High economic values: participation is a waste of time High social values: highly effective . – p.70/192
  31. 31. Mental Constructs of Problem Solver(3) Motives/Prejudices Personal needs that we try to satisfy Opinions that we form from our values and experiences Becoming conscious of these is helpful . – p.71/192
  32. 32. Mental Constructs of Problem Solver(4) Experience, knowledge, and skills Acquired from education, training, and practical work Have to match requirements of the methodology to be used . – p.72/192
  33. 33. Mental Constructs of Problem Solver(5) Reasoning ability/Structuring processes Ability to abstract essential aspects and structure them in a meaningful way Thinking in different ways helps to gain new insights Communicating those thoughts in a clear way helps other people to understand reasons . – p.73/192
  34. 34. Mental Constructs of Problem Solver(6) Roles In the development process, persons take on different roles Advisor Analyst Consultant Designer Implementer ... Conflicts between expected role behavior and natural behavior of a person results in stress . – p.74/192
  35. 35. Problem-solving Process Methodology is a way of problem solving Needs to help perform three essential phases: Phase 1: Problem formulation Phase 2: Solution design Phase 3: Design implementation . – p.75/192
  36. 36. Phase 1: Problem Formulation Stage 1: Understanding the “situation of concern” Mental construct Problem Solver Client Mental construct can have several effects on grasping the situation . – p.76/192
  37. 37. Stage 1: Understanding situation Deriving a boundary of concern Mental construct Problem Solver Client Boundary of concern . – p.77/192
  38. 38. Boundary of Concern If we do not subject mental constructs to self-critical examination, we may end up accepting predefined boundaries of client construct implicit boundaries (where there are none) not identifying relevant elements A methodology should support this structuring of problem by supplying appropriate methods of investigation . – p.78/192
  39. 39. Boundary of Concern(2) Why is boundary so important? It excludes many elements from subsequent steps If causes for identified problems lie outside of boundary, it doesn’t matter how well content of boundary is redesigned actual problem will not be solved . – p.79/192
  40. 40. Stage 2: Performing Diagnosis Where are we now? Stage 1 is more or less a description of situation Diagnosis aims at understanding reasons for current situation Helps identify gaps of knowledge or misunderstandings Helps in communicating with clients in deriving agreed understandings Two levels of expression: Conceptual/logical level Physical level . – p.80/192
  41. 41. Conceptual/Logical Level Describes general and situation-specific information on an abstract level (“what” issues) Details include information flows, people’s tasks, roles, functions, etc. Expressed with the help of rich pictures, variance grids, data flow diagrams, actigrams/datagrams, bubble charts, etc. . – p.81/192
  42. 42. Physical Level Describes physical characteristics of a situation (“who” or “how” issues) Details include actual products, specific individuals, documents, computers (performance, memory capacities, etc.) Expressed in descriptive of tabular form . – p.82/192
  43. 43. Stage 3: Defining Prognosis Where do we want to be and why? Client wants to change current state Prognosis is expression of desired state Focus is not to create content of future state (that is role of design), but to understand rationale for change Depending on outcome of this stage, project may not be started at all . – p.83/192
  44. 44. Stage 4: Defining Problems What is preventing realization of desired state? Analyzing the gap between current and desired state Identify and critically examine the absence and/or relationships of elements Results in identifying problem areas (written down in concrete problem statements) . – p.84/192
  45. 45. Stage 5: Deriving Notional Systems Specifying requirements of a system If such a system is built, we eliminate the identified problems change from current state to described state . – p.85/192
  46. 46. Phase 2: Solution Design Here we fill prognosis with content Starting point is notional system Consists of two stages: Stage 6: Conceptual/logical design Stage 7: Physical design . – p.86/192
  47. 47. Stage 6: Conceptual/Logical Design Design system on an abstract level (similar to the level used for conceptual/logical analysis) Most structured methodologies construct data flows/processes and/or ER-diagrams ignoring roles/functions of individuals . – p.87/192
  48. 48. Stage 7: Physical Design Selection of ways and means to realize logical design Usually a range of different realizations are possible Additional criteria may play a role in selection: Efficiency Reliability Accuracy Security/Safety Availability . – p.88/192
  49. 49. Phase 3: Implementation This phase determines success of whole development process Demonstrates validity of all previous steps Consists of several tasks (that we are going to look at) . – p.89/192
  50. 50. Tasks Strategy and planning Identify and adapt a strategy for sequencing all activities Management and control Set up management and control functions to help supervise activities . – p.90/192
  51. 51. Tasks(2) Environment Preparation Adjust surrounding for future system (e.g make changes to buildings, cabling, train users) System development Identify activities and needed resources (e.g. recruitment of new personnel, acquisition of hard-/software, coding of programs, testing) Changeover Integrate the new system (and introduce other changes) into the prepared environment . – p.91/192
  52. 52. Evaluation Methodology should not be a simple execution of steps Should help bring about an efficient and effective transformation of situations Role of (evaluation) framework is to question methodologies as to what they attempt to transform why they try to transform it how they help in undertaking the transformation . – p.92/192
  53. 53. Evaluation(2) Evaluation of the three elements problem situation, problem solver, problem-solving process Before the project: Initial assessment of the three elements During the project: Changes may alter the use of methodology After the project: Evaluate if problems were solved and how methodology helped in doing so . – p.93/192
  54. 54. Applying NIMSAD MIMSAD is not a methodology itself (does not provide content to different stages) It is about finding out what elements in the framework a methodology addresses in what order and how Methodology does not have to be an exact one-to-one mapping to framework . – p.94/192
  55. 55. Applying NIMSAD(2) NIMSAD provides important questions to check Answers have to be found by potential users of a methodology∗ Questions for all elements of NIMSAD More complete list in NIMSAD book, here just an excerpt of most important ones ∗ The following might be disturbing for some students: lots of questions without answers . – p.95/192
  56. 56. Problem Situation Who are the clients? How strong is their commitment? Does methodology help in identifying clients and their concerns? What’s the situation like? (well-structured, less well-structured, ill-structured) For which situation is methodology suitable? What does situation demand (identify problems, design solutions for already identified problems, implement an already designed solution)? . – p.96/192
  57. 57. Problem Solver What level of abstract and technical thinking does methodology demand from user? Do philosophical views advocated by methodology match user’s view? What knowledge sets and skills does methodology require from user? Are mental constructs of user considered? . – p.97/192
  58. 58. Problem-solving process Stage 1: Understanding situation of concern Does methodology offer assistance for boundary construction? What is role of client (inclusion/participation or external)? Does methodology discuss particular methods of investigation? . – p.98/192
  59. 59. Problem-solving process(2) Stage 2: Diagnosis What techniques does methodology offer for expressing situation characteristics? What level of expression is advocated (conceptual/logical and/or physical) What environmental (context) information is captured? What tools and techniques are available? . – p.99/192
  60. 60. Problem-solving process(3) Stage 3: Prognosis Is this stage supported at all? How does methodology offer help in defining prognosis? How are desired states established? . – p.100/192
  61. 61. Problem-solving process(4) Stage 4: Defining Problems What problems or problem types are of concern to the methodology? How does it help in deriving problem statements? Are problem statements evaluated (or just accepted)? . – p.101/192
  62. 62. Problem-solving process(5) Stage 5: Deriving notional systems Does methodology derive notional systems from identified problems? Does it offer help in formulating notional systems? . – p.102/192
  63. 63. Problem-solving process(6) Design (Stage 6: Conceptual/Logical Design, Stage 7: Physical Design) Does methodology accept client’s notional system as starting point? Does it distinguish between logical and physical design stages? Does it help in formulating design solutions? What aspects cannot be captured by methodology? Is a user on his/her own when trying to fill these gaps? How experienced is user to be expected in the solution domain? Who decides on which solution to take? . – p.103/192
  64. 64. Problem-solving process(7) Stage 8: Implementation What steps does methodology offer for developing the IS? What does it offer in terms of tools and techniques? How does it help in handling major changes in the notional system at this time? . – p.104/192
  65. 65. Evaluation Does methodology provide techniques for evaluating itself and its outputs for problem situation? problem solver? problem-solving process? . – p.105/192
  66. 66. Evaluating Methodologies We are going to look at two methodologies in the framework of NIMSAD: SSADM SSM . – p.106/192
  67. 67. SSADM: Problem Situation Organizational context has higher priority than in other structured methodologies Commitment of users is checked (partially) during feasibility study Still SSADM is mainly concerned with formal descriptions of data and processes via data flow diagrams Irregular and changing patterns often left out of domain of SSADM . – p.107/192
  68. 68. SSADM: Problem Solver SSADM does not alert its users to their mental constructs E.g. two different (competent) SSADM users may arrive at two different sets of data flow diagrams Most dominant knowledge and skills required are of technical nature In practice, however, users also need social skills to make methodology effective (not made explicit by methodology) . – p.108/192
  69. 69. SSADM: Problem-solving Process Stage 1: Understanding situation of concern Boundary construction is trial and error within SSADM Assumes that data flow diagrams can help construct boundary This often establishes an implicit boundary (anything that cannot be captured in DFDs remains outside) . – p.109/192
  70. 70. SSADM: Problem-solving Process(2) Stage 2: Diagnosis SSADM makes most useful contribution to this stage Use of DFDs provide clear ways of expressing flows of formal data Starts with physical data flows (describing how data is processed) Then tries to extract underlying meaning into a logical data model and logical data flow model Does so by removing physical elements of elementary processes and then reconstructing/regrouping transformed processes . – p.110/192
  71. 71. SSADM: Problem-solving Process(3) Stage 2: Diagnosis Logicalization may be problematic, as physical constraints may disappear Example: agent updates customer record on laptop, later this is synchronized with headquarters After logicalization there may only be one customer record file left. . . Regular and frequent patterns get modeled, special cases may be forgotten . – p.111/192
  72. 72. SSADM: Problem-solving Process(4) Stage 3: Prognosis Defining prognosis is not really possible in SSADM Although better than in other structured approaches, as clients get to choose among different Business Systems Options (BSO) Feasibility study also helps in deciding if benefits outweigh costs Rationale of clients’ desired states may not become clear (it is assumed that clients know what they want) . – p.112/192
  73. 73. SSADM: Problem-solving Process(5) Stage 4: Defining problems There is an explicit problem definition phase during feasibility study At this point things are still vague, however As there is no real prognosis, problems cannot be derived by looking at differences between diagnosis and prognosis . – p.113/192
  74. 74. SSADM: Problem-solving Process(6) Stage 5: Deriving notional systems Strength of SSADM is in formalizing requirements of client Achieved by modeling the data flows of the required system with help of DFDs Functions and user interfaces of the system can be specified Developing specification prototype helps in getting feedback from client Again, assumes that client knows what he/she wants . – p.114/192
  75. 75. SSADM: Problem-solving Process(7) Stages 6 and 7: Design SSADM distinguishes between logical and physical design We are going to look at these in turn . – p.115/192
  76. 76. SSADM: Problem-solving Process(8) Stages 6: Logical Design Most useful and rigorous techniques offered by SSADM are DFDs Designs are usually created by modifying logical diagnosis diagram using requirements and feasibility study as guideline SSADM also very useful for structuring dialogues Does not take any interest in how design decisions will affect environment (BSO only looks at requirements) . – p.116/192
  77. 77. SSADM: Problem-solving Process(9) Stages 7: Physical Design SSADM provide mainly generic guidelines Many decisions depend on technical issues specific to chosen environment Environment is chosen in Technical System Option (TSO) phase of SSADM In TSO technical alternatives drawn up from requirements are presented to clients for decision Better than other structured approaches (where there is no TSO) Still problems for non-computerized areas of design . – p.117/192
  78. 78. SSADM: Problem-solving Process(10) Stages 8: Implementation Completely missing (one of the weakest points) . – p.118/192
  79. 79. SSADM: Evaluation Completely missing (the other of the weakest points) . – p.119/192
  80. 80. SSADM: Summary SSADM is/was popular methodology for formal design of IS Better in “soft”, non-technical aspects than other structured approaches However, still a technical methodology with weak points in “soft” aspects of IS development, the implementation phase, and self-evaluation At least, does not claim to cover “soft” aspects adequately . – p.120/192
  81. 81. SSM: Problem Situation SSM is one of the few methodologies that makes comments about problem situation SSM is applicable to ill-structured situations In contrast to structured methodologies (which seek a “single” truth), SSM considers many different views Encourages its users to develop new perceptions of organizations through systems thinking SSM recognizes three roles: client (initiates study), problem owner (identifies relevant systems), problem solver (uses SSM to resolve client’s concerns) . – p.121/192
  82. 82. SSM: Problem Solver SSM recognizes the need for reflection Considers mental constructs of its users Methodology user takes on role of debate facilitator and learner However, SSM relies on its users to have considerable conceptualization, abstraction, philosophical, and political skills . – p.122/192
  83. 83. SSM: Problem-solving Process Stage 1: Understanding situation of concern SSM provides insightful contributions to boundary construction Boundaries, problem ownership, problem content, and context issues are all open to question Context of a problem situation can be captured in rich pictures . – p.123/192
  84. 84. SSM: Problem-solving Process(2) Stage 2: Diagnosis SSM does not prescribe particular form of expression to capture essential aspects of an organization Any technique may be used: graphs, text, animation, pictures, charts, tables, etc. (“rich pictures”) This is a strength and a weakness: Gives users a lot of freedom But also a lot of responsibility (user has to know what he/she is doing) SSM does not distinguish between logical and physical diagnosis descriptions . – p.124/192
  85. 85. SSM: Problem-solving Process(3) Stage 3: Prognosis/Stage 4: Defining problems are skipped (details later) Are handled a little differently in SSM . – p.125/192
  86. 86. SSM: Problem-solving Process(4) Stage 5: Deriving notional systems SSM does not derive notional systems from identified problems (see Stage 4) Attempts to develop many potentially relevant notional systems Formulates notional systems with root definitions (CATWOE) . – p.126/192
  87. 87. SSM: Problem-solving Process(5) Stage 6/7: Design No distinction between logical and physical design Uses root definitions as guide for design process Design is not a strong point of SSM Not quite clear how to derive at an activity-based design from system-based root definition . – p.127/192
  88. 88. SSM: Problem-solving Process(6) Stage 8: Implementation Missing . – p.128/192
  89. 89. SSM: Problem-solving Process(7) Stage 3: Prognosis SSM operates in environment where there are multiple desired states clients who are unsure of their desired states SSM does not attempt to construct clear prognosis outline Each root definition implies a particular desired state There are many potentially relevant notional systems . – p.129/192
  90. 90. SSM: Problem-solving Process(8) Stage 4: Defining problems As there is no clear prognosis, it is difficult to derive problem statements from mapping diagnosis to prognosis SSM maps design models against diagnosis to determine relevance Decision on relevance is carried out by conducting debate with participants Practically, Stage 4 is deferred until design is finished . – p.130/192
  91. 91. SSM: Evaluation SSM does not have an explicit step for evaluation Nevertheless, it propagates learning When evaluation is done, usually focus on problem-solving process Mostly done through SSM case studies (UK Health Service, Shell, IS planning) . – p.131/192
  92. 92. SSM: Summary SSM is a methodology for ill-structured problem situations Allows discussions on different viewpoints of participants Author of SSM also encourages debate and discussions about SSM SSM is in constant process of refinement to meet valid criticism . – p.132/192
  93. 93. Framework by Avison/Fitzgerald Has seven basic elements: Philosophy Model Techniques and Tools Scope Outputs Practice Product . – p.133/192
  94. 94. Philosophy The principle (or set of principles) that underlies a methodology Several areas are distinguished Paradigm Objectives/Domain Target . – p.134/192
  95. 95. Paradigm Science paradigm vs. systems paradigm Science paradigm explains world through reductionism, repeatability, refutation Systems paradigm is concerned with whole picture, interrelationships between parts of the whole Simplified this means Science paradigm ≡ “hard” thinking Systems paradigm ≡ “soft” thinking . – p.135/192
  96. 96. Paradigm(2) Debate has been extended to Epistemology: study of knowledge, how we acquire knowledge Ontology: study of being (or what “is”) Let’s make a short excursion into philosophy . – p.136/192
  97. 97. Epistemology The two extreme positions are positivism and interpretivism Positivism There is an objective reality beyond the human mind Ideas and theories need to be tested against this reality This is done via experiments, surveys, field studies, etc. . – p.137/192
  98. 98. Epistemology(2) Interpretivism Knowledge of world is constructed through a person’s lived experience Reality is constructed socially Interpretivists use case studies, hermeneutics, phenomenology, etc. Hermeneutics: theory and practice of interpretation∗ Phenomenology: study of phenomena (appearance of things) from a first person point of view ∗ Hermeneutic cycle is process by which we return to a text (or the world), and derive a new interpretation – perhaps a new one every time or a new one for every interpreter . – p.138/192
  99. 99. Ontology The two extreme positions here are realism and nominalism Realism There are universal entities and universal terms to describe them E.g. many individual horse entities, but there is also general concept of an “ideal” horse Nominalism There are no universal entities, we can only refer to concrete, individual entities E.g. many individual horse entities, speaking of horses in general is mere convenience for speaking of many things at once . – p.139/192
  100. 100. Excursion into Philosophy Usually extreme positions not encountered in pure form A positivist confronted with a loaded gun will not start calculating trajectories, possible areas of impact, he will experience strong (subjective) emotions An interpretivist paying £1000 into his bank account will not accept the teller’s subjective point of view that crediting £800 is close enough . – p.140/192
  101. 101. Paradigm(3) Positivism Objectivist Epistemology Interpretivism approaches Subjectivist approaches Realism Nominalism Ontology . – p.141/192
  102. 102. Objectives/Domain What is methodology trying to achieve within an organization? Development of a purely “computerized” IS? Does it take wider view including other tasks? Does it try to reengineer whole business processes/change strategy of organization? . – p.142/192
  103. 103. Target For what types of problems environments types or sizes of organizations is methodology applicable? . – p.143/192
  104. 104. Model What constructs does methodology use to model the real world? Verbal Analytic/mathematical Iconic/pictorial/schematic Simulation . – p.144/192
  105. 105. Techniques and Tools What techniques and tools are provided to support user of methodology? . – p.145/192
  106. 106. Scope Which phases of life cycle of IS development does methodology cover? strategy, feasibility, analysis, logical design, physical design, programming, testing, implementation, evaluation, maintenance Problematic if methodology does not follow life cycle . – p.146/192
  107. 107. Outputs What is methodology producing in terms of deliverables? This can range from feasibility studies, requirements and analysis specifications up to working implementations of IS When are these outputs generated? . – p.147/192
  108. 108. Practice What is the background of methodology (commercial or academic)? What is the user base (numbers and types of users)? Who are the participants and what are their required skill levels (can users apply methodology themselves or are highly skilled consultants necessary)? . – p.148/192
  109. 109. Product What do you get for your money, i.e. when purchasing methodology, what is included? Software tools Written documentation Training Help service . – p.149/192
  110. 110. Applying Avison/Fitzgerald Framework We are looking at SSADM and SSM in light of Avison/Fitzgerald framework Some arguments have already been presented in NIMSAD framework Therefore, this is kept shorter . – p.150/192
  111. 111. Philosophy Paradigm SSADM Follows science paradigm Belongs to objectivist approaches SSM Clearly follows systems paradigm Belongs to subjectivist approaches . – p.151/192
  112. 112. Philosophy(2) Objectives/Domain SSADM Has objective of developing computerized IS Neglects organizational aspects SSM Tries to capture a broader view, including organizational context . – p.152/192
  113. 113. Philosophy(3) Target SSADM Data flow diagrams not applicable for all types of problems (decision support systems, web applications) Targets large organizations (although there is slimmer version called MicroSSADM) SSM Applicable in human activity situations with ill-structured problems . – p.153/192
  114. 114. Model SSADM Main modeling concept: data flow diagrams SSM Very flexible “rich pictures” . – p.154/192
  115. 115. Techniques and Tools SSADM Main technique: structured approach to modeling and design Tools like drawing tools, tools for project management, code generation seen as useful, but not essential SSM Organizational techniques Does not advocate or mention specific tools . – p.155/192
  116. 116. Scope SSADM includes (Strategy), feasibility, analysis, logical design, physical design SSM includes Strategy, (feasibility), analysis, (logical design) . – p.156/192
  117. 117. Outputs SSADM Basically follows SDLC, so in each phase certain documents are produced (e.g. feasibility study, requirements specification, design documents) SSM Divided into seven stages, at the end of which certain documents are produced (e.g. rich pictures, root definitions) . – p.157/192
  118. 118. Practice SSADM Commercial background “Traditional” participants: analysts, designers, (programmers) SSM Academic background Participants: much greater role of client and problem owner . – p.158/192
  119. 119. Practice(2) Difficult to evaluate user base, some numbers: Fitzgerald 1999: 57% of organizations use methodologies: 11% purely commercial ones, 30% adopted commercial ones, 59% unique ones Russo/Wynekoop 1995: of 132 organizations using a methodology, 77% used structured approach, 8% prototyping/iterative approach, 5% RAD approach . – p.159/192
  120. 120. Product SSADM Large store of manuals, books, etc. Certificate of proficiency can be acquired SSM A set of academic papers and books . – p.160/192
  121. 121. Capability Maturity Model (CMM) Created by the Software Engineering Institute at Carnegie Mellon Originally aimed at helping Department of Defense assess capabilities of vendors and sub-contractors Not so much about methodologies themselves, but about how well an organization organizes its processes Has five levels, level 5 being the best one . – p.161/192
  122. 122. Overview Improving Optimizing process Predictable Managed process Standard Defined process Disciplined Repeatable process Initial . – p.162/192
  123. 123. Initial (Level 1) Development is characterized as being ad hoc or even chaotic Processes are not defined Everything depends on skilled individuals to get their act together Software is typically delivered late and over budget Little effective management and control Unfortunately, too many organizations are still at this level . – p.163/192
  124. 124. Repeatable (Level 2) Basic project management processes are established Allows tracking of costs, schedules, functionality Somme process discipline is in place Earlier success on projects with similar applications can be repeated . – p.164/192
  125. 125. Defined (Level 3) Management and engineering activities are documented, standardized, and integrated into a standard process All projects use an approved, tailored version of the organization’s process Training programs are implemented to ensure that staff has necessary skill . – p.165/192
  126. 126. Managed (Level 4) Detailed measures of the process and product quality are collected and analyzed Process and products are quantitatively understood and controlled Risks in moving to new application domains are known and carefully managed . – p.166/192
  127. 127. Optimizing (Level 5) Entire organization is focused on continuous process improvement Organization can identify weaknesses and prevent potential defects beforehand Cost/benefit analyses of new technologies base on data on effectiveness of current process . – p.167/192
  128. 128. Summary CMM is based on manufacturing and product-building view of systems development This is not always appropriate as often IS development is more of a creative art than a science CMM is mainly concerned with (technical) aspects of software development, not the wider area of IS development High levels in CMM do not always lead to high quality software, just well-documented processes . – p.168/192
  129. 129. Chapter Summary Comparing methodologies is a very difficult task Unfortunately, no silver bullet for doing so has been found yet As many views as writers on the subject . – p.169/192