Comparative Development Methodologies
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Comparative Development Methodologies

  • 10,654 views
Uploaded on

Comparative Development Methodologies

Comparative Development Methodologies

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
10,654
On Slideshare
10,394
From Embeds
260
Number of Embeds
5

Actions

Shares
Downloads
269
Comments
0
Likes
2

Embeds 260

http://mycourse.solent.ac.uk 195
http://www.slideshare.net 56
http://mycourse-archive.solent.ac.uk 5
http://translate.googleusercontent.com 3
http://webcache.googleusercontent.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Comparative Development Methodologies Lecture 10 Niki Trigoni Department of Computer Science and Information Systems Birkbeck College, University of London Email: niki@dcs.bbk.ac.uk Office Hours: Wednesdays, 6 - 7 pm Web Page: http://www.dcs.bbk.ac.uk/~niki
  • 2. Review of lecture 9  Two different kinds of methodologies:  rapid development methodologies and  organizational-oriented methodologies  Overview of Extreme Programming (XP), a rapid development methodology suitable for small to medium systems. The most important features are user stories, early feedback from the customer, unit test code, pair programming, refactoring and acceptance tests.  Overview of Soft Systems Methodology (SSM), an organizational-oriented methodology suitable for approaching more fuzzy problem situations where different stakeholders view the system from different perspectives.
  • 3. Overview of lecture 10 1. Frameworks 2. Methodology issues 3. Methodology comparisons
  • 4. Frameworks  Frameworks provide guidance to the developer in choosing methods, techniques, and tools rather than a prescriptive (methodology-style) step-by-step approach.  Examples of frameworks:  Multiview  Strategic Options Development and Analysis (SODA)  Capability Maturity Model (CMM)  Euromethod
  • 5. Frameworks: Multiview  It is a „multi-view‟ in the following sense:  As an information systems project develops, it takes on different perspectives or views: organizational, technical, human-oriented, economics and so on.  It brings together techniques from multiple methodologies.  It incorporates five different views in five stages:  Analysis of human activity  Analysis of information  Analysis and design of socio-technical aspects  Design of the human-computer interface  Design of technical aspects
  • 6. Frameworks: Multiview stages 5. Design technical Technical requirements aspects 4. Design human- entity computer interface model entity model computer tasks role set people tasks primary task model 3. Analyze and 1. Analyze human 2. Analyze activity information design socio-technical function aspects model
  • 7. Frameworks: Multiview concerns  The methodology must help answer the following questions:  Q1: How will the computer system further the aims of the organization installing it? (top management concern)  Q2: How will it be fitted into the working lives of the people in the organization that are going to use it? (trade union concern)  Q3: How can the individuals concerned best relate to the machine in terms of operating it and using the output from it? (users concern)  Q4: What information system processing function is the system to perform? (systems analysts concern)  Q5: What is the technical specification of a system that will come close enough to doing the things written down in the answers to the other four questions? (designers concern)
  • 8. Frameworks: Multiview framework 1.Human activity 1. (Q1) 2. 2. Information 3.. (Q4) 4. 3. Socio-technical 5. (Q2) 4. Human-computer interface (Q3) 5. Technical (Q5)
  • 9. Frameworks: Multiview framework Stage 1: Analysis of human activity  Based on SSM (Mode 1)  Central focus: Search for a particular world view  Form rich pictures of the problem situation  Let rich pictures stimulate discussion between the problem solver and the problem owner  Extract problem themes from rich pictures  Form root definition  Construct a conceptual model  Compare the completed conceptual model to the representation of the „real world‟ in the rich picture  Debate possible changes to improve the problem situation …
  • 10. Frameworks: Multiview framework Stage 2: Analysis of information  Takes as input the root definition/conceptual model from stage 1  Two main phases:  the development of a functional model:  identify the main function  decompose functions successively (4-5 levels)  provide hierarchical model and DFDs as input into stage 3  the development of an entity model  Extract and name entities from the area of concern  Establish relationships between entities  Construct an entity model and provide it as input to stages 4 and 5
  • 11. Frameworks: Multiview framework Stage 3: Analysis and design of the socio-technical aspects  Philosophy: people should be allowed to participate in the analysis and design of the systems that they will be using  Human considerations: job satisfaction, task definition, morale  Consider both social and technical objectives  Specify both social and technical alternatives  Match socio-technical alternatives  Rank in terms of meeting socio/technical objectives  Consider costs/resources/constraints and rank accordingly  Select best socio-technical solution  Define computer task, role set, and people tasks for solution
  • 12. Frameworks: Multiview framework Stage 4: Design of the human-computer interface  Takes as input the entity model from stage 2, and the computer tasks, role-set, and people tasks from stage 3  Philosophy: the ways in which users will interact with the computer will have an important influence on whether the users will accept the system  Works on the technical design of the human-computer interface  batch vs. online facilities  conversations and interactions with particular types of user  necessary inputs and outputs, error checking, minimization of number of keystrokes
  • 13. Frameworks: Multiview framework Stage 5: Design of the technical aspects  Takes as input the entity model from stage 2 and the technical requirements from stage 4  Takes a technical view towards an efficient design of the system  Final outputs are:  application subsystem (impl. functions in the function chart)  information retrieval subsystem (responds to data enquiries)  database (and db maintenance subsystem)  control subsystem (alerts for user/program/operator errors)  recovery subsystem (repairs system after error detection)  monitoring subsystem (records all system activities)
  • 14. Frameworks: SODA  Strategic Options Development and Analysis (SODA)  “SODA is an approach designed to provide consultants with a set of skills, a framework for designing problem solving situations and a set of techniques and tools to help their clients work with messy problems” [Eden and Ackerman, 2001]  Four perspectives:  individual (tries to make sense of the organization)  nature of organizations (political and power aspects play an important role in decision making; role negotiation)  consulting practice (role of negotiation in effective problem solving, managing consensus and commitment)  technology and techniques (used to bring together the first three elements)
  • 15. Frameworks: CMM  Capability Maturity Model (CMM) [Paulk 1993, Weber 1991]  CMM is a framework for evaluating processes used to develop software projects  Processes are grouped into five levels based on their „maturity‟ 1. Initial level (“heroic level”):  adhoc (and chaotic) development  success/failure depends on the individuals involved  not sustainable  late and over-budget software delivery 2. Repeatable level  identifiable policies for managing software development  realistic plans based on performance of previous projects  cost estimates, schedules, project standards
  • 16. Frameworks: CMM (cont.)  Continuing enumeration of maturity levels 3. Defined level  standard S/E processes documented  well-defined, stable development approach  includes readiness criteria, inputs, standards, procedures, verification mechanisms, outputs and completion criteria  organization-wide training program for learning process  quality and technical progress monitoring by management 4. Managed level  quantitative quality and productivity measures  software process db used to collect process-related data  analysis of methodology effectiveness  predictable processes and quick exception handling
  • 17. Frameworks: CMM (cont.)  Continuing enumeration of maturity levels 5. Optimizing level  proactive and continuous process improvement  ability to identify strengths and weaknesses  assess new technologies and process innovations  standard activity of planning and managing process change
  • 18. Frameworks: Euromethod  Euromethod: part of the IT standardization policy of the EU  Objective: to facilitate cross-border trading by providing a common understanding of requirements and solutions among users from different countries  Problem: diversity in approaches, methods and techniques in information systems used in Europe  Based on experiences with existing methods:  SSADM (from the UK)  Merise (from France)  IE (from the UK/US)  SDM (from the Netherlands)  DAFNE (Italy), MEIN (Spain), Vorgehensmodell (Germany)
  • 19. Frameworks: Euromethod  Euromethod applies to any information systems adaptation: development or modification of an information system providing that the initial (or current) state and the required final state can be defined.  Euromethod focuses on the understanding, planning and management of the contractual relationships between customers and suppliers of information systems adaptations.  Types of transactions in an IS adaptation Call for tender Approval of deliverables Approval of final Tender response Approval of status deliverables Supplier selection and plans Contract Contract change control completion Contract award TENDERING PRODUCTION COMPLETION
  • 20. Frameworks: Euromethod  Euromethod includes elements relating to „procurement‟ rather than development of information systems  Its concept is to bridge different methodologies by following three models: the transaction model, the deliverable model and the strategy model  The transaction model helps manage customer/supplier interactions across organizational boundaries  The deliverable model defines the target domain (data, functions, architecture) for an information systems adaptation, incl. the goals, the key roles and responsibilities of the customer and the supplier  The strategy model assesses the problem situation and selects a strategy with well defined decision points to get successfully to the final state of the adaptation.
  • 21. Overview of lecture 10 1. Frameworks  Multiview  Strategic Options Development and Analysis (SODA)  Capability Maturity Model (CMM)  Euromethod 2. Methodology issues  Components of a methodology  Rationale for a methodology  Adopting a methodology in practice  Evolution of methodologies 3. Methodology comparisons
  • 22. Issues: methodology components  How a project is to be broken down into stages  What tasks are to be carried out at each stage  What outputs are to be produced  When, and under what circumstances, thay are to be carried out  What constraints are to be applied  Which people should be involved  How the project should be managed and controlled  What support tools may be utilized  What are the training needs of the methodology users  Which is the philosophy, i.e. the underlying theories and assumptions of the methodology authors that have shaped the development of the methodology
  • 23. Issues: rationale for a methodology 1. A better end product  Acceptability (do people find the product satisfactory?)  Availability (is the product accessible when/where required?)  Cohesiveness (are information and manual systems integrated?)  Compatibility (does the system fit with other parts of the organization?)  Documentation  Ease of learning  Economy (is the system cost effective, within resources and constraints?)  Effectiveness (does the system meet business/organizational objectives?)  Efficiency (does the system utilizes resources to their best advantage?)  Fast development rate (time relative to project size and complexity)  Flexibility (is the system easily modifiable?)  Functionality (does the system cater for the requirements?)  Implementability (feasible changeover from the old to the new system?)  Low coupling (is there low interaction between subsystems so that changes of one does not affect the others significantly?)
  • 24. Issues: rationale for a methodology 1. A better end product (cont.)  Maintainability  Portability (can the system run on other equipment or in other sites?)  Reliability (is the error rate minimized and are outputs consistent?)  Robustness (is the system fail-safe and fault-tolerant?)  Security  Simplicity  Testability  Timeliness (does the system operate well under normal, peak, and every condition?)  Visibility (is it possible for users to trace why certain actions occurred?)
  • 25. Issues: rationale for a methodology 2. A better development process  Tight control of the development process  Well-specified deliverables at each stage  Improved management, planning and project control  Increase of productivity  Reduction of skills required of analysts => reduction of cost 3. A standardized process  Staff can change between projects without retraining  Common experience and knowledge can be accumulated  Easy system maintenance  Better systems integration
  • 26. Issues: adopting a methodology in practice  Variation points of different methodologies:  fully fledged product detailing every stage and task or vague outline of basic principles  high-level strategic and organizational problem solving or details of implementing a computer system  conceptual issues or physical design procedures or the whole range of intermediate stages  applicable to specific problem types or all-encompassing general-purpose methodology  usable with or without special training  people it requires to complete tasks (if specified)  tools and toolsets used
  • 27. Issues: adopting a methodology in practice  Methodology adopters should be aware of these variations and of their particular needs in order to make an educated decision of using a methodology  Methodology-related costs  initial purchase  training of personnel  required hardware and software  ongoing consultancy  Involve users, analysts and managers in the decision of selecting a methodology (it should not be purely an IT department decision)  Are we guaranteed successful information systems as a result of using a methodology?
  • 28. Issues: adopting a methodology in practice  Developers may interpret the demands of the methodology differently and thus end up with different results  Flexibility in how specified tasks are performed is another source of uncertainty about the expected results  Despite variations, multiple uses of a methodology should yield roughly the same results. Of course, this also depends on the methodology itself  The adoption of a methodology can be viewed as an attempt to reduce the degrees of freedom, by embodying a good practice for developing an information system  Main criteria for selecting a methodology:  Whether it fits with the organization‟s way of working  Whether it specifies deliverables at the end of each stage  Whether it enables better control and improved productivity  Whether is supports a particular set of tools
  • 29. Issues: evolution of methodologies  Pre-methodology era: until early 1970s  Information systems were developed without the use of an explicit development methodology  Emphasis on programming and solving technical problems  Individualistic development approach  Lack of regard for the organizational context  Poor project control and management  Growing interest in standards and a more disciplined approach
  • 30. Issues: evolution of methodologies  Early-methodology era: from early 1970s to early 1980s  Focused on identification of phases and stages to control and manage systems development  Waterfall model: feasibility study, systems investigation, analysis, design, development, implementation, maintenance  Well-defined set of deliverables upon the completion of a stage  Trained users and developers  Documentation standards
  • 31. Issues: evolution of methodologies  Methodology era: from mid 1980s to mid/late 1990s  Methodologies emerging both from theory and from practice  The methodology, rather than consultancy about the methodology, became the product, resulting in:  Write-up of the methodology  Consistency and comprehensiveness  Marketability and maintainability  Evolution into training packages  Provide with supporting software  Whilst creating methodology products  Many gaps were filled  The scope of methodologies was expanded (to more stages and higher organizational levels)  Strategic and planning aspects were introduced (to gain competitive advantage
  • 32. Issues: evolution of methodologies  Era of methodology reassessment: from late 1990s onward  Reappraisal of methodologies (change or abandon of specific methodologies)  Criticisms of methodologies:  Productivity: time consuming and resource intensive  Complexity: designed for large projects  Encouraging the creation of „wish lists‟ by users  Skills: training is required for their use  Tools: shift focus to documentation rather than analysis/design, complex to use  Not contingent upon the type of project or its size  One-dimensional approach: narrow solution  Inflexible: not allowing changes to requirements  Invalid or impractical assumptions (e.g. coherent business strategy)
  • 33. Issues: evolution of methodologies  Era of methodology reassessment: from late 1990s onward  Criticisms of methodologies (cont.):  Goal displacement: focus on the procedures to the exclusion of the real needs of the project  Problems of building understanding into methods: it is not enough to understand methods in order to understand the problem situation  Insufficient focus on social and contextual issues: overemphasis on the narrow technical development  Difficulties in adopting a methodology: resistance from developers and users  No improvements: not only it did not help, but it also hindered development
  • 34. Issues: evolution of methodologies  Era of methodology reassessment: from late 1990s onward  New directions:  Ad hoc development: rely on the experiences of developers  Further developments in the methodology arena: evolution of existing methodologies or development of new ones (object-oriented, RAD, prototyping, CRM approaches seem to be gaining ground)  Contingency: use the methodology as a general structure, and pick tools and techniques depending on the situation  External development: use of packages and outsourcing is effective for organizations with well-defined requirements, Enterprise Resource Packages (ERPs)
  • 35. Overview of lecture 10 1. Frameworks  Multiview  Strategic Options Development and Analysis (SODA)  Capability Maturity Model (CMM)  Euromethod 2. Methodology issues  Components of a methodology  Rationale for a methodology  Adopting a methodology in practice  Evolution of methodologies 3. Methodology comparisons  Criteria  Framework  Comparison
  • 36. Methodology comparison criteria  What aspects of the development process does the methodology cover?  What overall framework or model does it utilize? (SDLC, linear, spiral)  What representation, abstractions and models are employed?  What tools and techniques are used?  Is the content of the methodology well defined, such that a developer can understand and follow it? (stages, tasks, philosophy, objectives)  What is the focus of the methodology? (processes, data, blended, organization, people) Does it address strategic issues?  How are the results at each stage expressed?
  • 37. Methodology comparison criteria  What situations and types of application is it suited to?  Does it aim to be scientific/systemic/behavioral?  Is a computer solution assumed? What other assumptions are made?  Who plays what role? Does it assume professional developers, require a methodology facilitator, involve users and managers, and if so, to what degree?  What particular skills are required of the participants?  How are conflicting views and findings handled?  What control features does it provide and how is success evaluated?  What claim does it make as to its benefits? How are these claims substantiated?  What are the philosophical assumptions of the methodology?
  • 38. Methodology comparison criteria  Other criteria you would consider:  Rules and standardization  Coverage …          
  • 39. Methodology comparison framework 1. Philosophy • Paradigm • Objectives • Domain • Target 2. Model 3. Techniques and tools 4. Scope 5. Outputs 6. Practice • Background • User base • Participants 7. Product
  • 40. Method. comp. framework: philosophy  Philosophy  Set of principles that underlie a methodology  Four distinguishing factors: 1. Paradigm: specific way of thinking about problems  science vs. systems paradigm  science paradigm (by reductionism, repeatability and hypotheses refutation)  systems paradigm (concern for the whole picture, emergent properties, and interrelationships between parts of the whole) 2. Objectives, e.g.  to develop a computerized information system?  to discover if there is a need for a computerized system?
  • 41. Method. comp. framework: philosophy  Philosophy (cont.)  Four distinguishing factors (cont.): 3. Domain: situations that methodologies address  narrow problem vs. wider organization-level problems  individual problems vs. many interrelated problems viewed as a whole 4. Target: applicability of the methodology  general-purpose vs. application/organization specific
  • 42. Method. comp. framework: model  Model: abstraction and representation of the important factors of the information system or the organization  Verbal  Analytic or mathematical  Iconic, pictorial or schematic  Simulation  Most methodologies are iconic, pictorial or schematic.  Models are used as a means of communication, particularly between users and analysts
  • 43. Method. comp. fram.: techniques & tools  Techniques and Tools:  Are techniques and tools essential to the methodology?  Which techniques/tools are used in a methodology?  Examples:  Rich pictures, root definitions, etc  Entity modeling and normalization  DFDs, decision tables, decision trees, entity life cycles  OO design and UML  Various organizational and people techniques
  • 44. Method. comp. framework: scope  Scope: indication of the stages of the life cycle of systems development that the methodology covers  Recall SDLC (Systems development life cycle)  Feasibility study  System investigation  Systems analysis  Systems design  Implementation  Review and maintenance
  • 45. Method. comp. fram.: outputs & product  Outputs: what the methodology is producing  Deliverables at each stage  Nature of final deliverable  Decision about whether to computerize a process  Analysis specification  Working implementation of a system  …  Product: what purchasers actually get for their money  Software  Written documentation  Agreed number of hours training, consultancy  Telephone help service  ...
  • 46. Method. comp. framework: practice  Practice:  Methodology background: academic vs. commercial  User base: numbers and types of users  Participants and skill levels required  Assessment of difficulties and problems encountered  Perception of success and failure  Degree to which the methodology is altered by the users according to the requirements of the situation  Differences between the theory and the practice of the methodology
  • 47. Methodology comparison: philosophy  Philosophy:  Paradigm:  SSM adopts systems paradigm (avoids reductionist approach)  STRADIS, YSM, IE, SSADM, MERISE, RUP etc. adopt the science paradigm  Objectives:  STRADIS, YSM, IE, SSADM, MERISE, RUP etc have clear objectives to develop computerized information systems  SSM aims at much more than developing an IT system
  • 48. Methodology comparison: philosophy  Philosophy:  Domain:  IE, and SSM address general planning, organization, and strategy of information and systems in the organization (IE‟s first stage is information strategy planning)  STRADIS, YSM, SSADM, Merise and RUP are classified as specific problem-solving methodologies  Target:  RUP: general-purpose, not very useful for small systems  STRADIS: general-purpose, DFDs not suitable for management information systems or web-based systems  SSM: more applicable in human activity „messy‟ situations  XP: suitable for small and continuously evolving systems  most methodologies (not XP) designed for large systems
  • 49. Methodology comp.: model and techniques  Model:  STRADIS uses primarily DFDs  DFDs are also used in YSM, SSADM, IE, SSM (but play a less significant role than in STRADIS)  SSADM, IE, Merise, RUP integrate both processes and data  Techniques:  STRADIS is largely described in terms of its techniques  SSM does not heavily use techniques and tools  YSM, SSADM, RUP specify techniques and view them as important for the methodology  IE explicitly suggests that the techniques are not a fundamental part of the methodology
  • 50. Methodology comparison: scope & product  Scope: (see figure 27.3 in Information Systems Development, by Avison and Fidzgerald)  Product:  SSADM comes with a large set of manuals  SSM comes only with some academic papers  RUP has a range of books, and online specs  Some methodologies offer certification of competency for developers
  • 51. Methodology comp.: outputs & practice  Outputs:  Methodologies differ significantly in terms of  Kinds of deliverables  Degree of detail in which they are specified  How deliverables are used to measure progress and move to the next stage  Practice:  STRADIS, YSM, IE, SSADM: commercial origin  Merise, SSM, RUP: academic origin  STRADIS, YSM, IE, SSADM, Merise, RUP: professional technical developers  SSM: both business and technical people
  • 52. Summary of lecture 10 1. Frameworks  Multiview  Strategic Options Development and Analysis (SODA)  Capability Maturity Model (CMM)  Euromethod 2. Methodology issues  Components of a methodology  Rationale for a methodology  Adopting a methodology in practice  Evolution of methodologies 3. Methodology comparisons  Criteria  Framework  Comparison