Chapter 27 Issues

Learning Objectives What a methodology is. Rationale for a methodology Adopting a methodology in practice Evolution and development of methodologies

Issues The term methodology is used very loosely but very extensively and has raised many more questions than it answers. For example: What is the difference between a methodology and a method? Does a methodology include a specification of the techniques and tools which are to be used? Does a collection of techniques and tools constitute a methodology? Should the use of a methodology produce the same results each time?

Methodology – definition (1) “A recommended collection of philosophies, phases, procedures, rules, techniques, tools, documentation, management, and training for developers of information systems”. (Maddison, 1983) What tasks are to be carried out at each stage What outputs are to be produced When, and under what circumstances, they 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

Methodology – BCS definition (2) A systems development methodology is a recommended means to achieve the development, or part of the development, of information systems based on a set of rationales and an underlying philosophy that supports, justifies and makes coherent such a recommendation for a particular context. The recommended means usually includes the identification of phases, procedures, tasks, rules, techniques, guidelines, documentation and tools. They might also include recommendations concerning the management and organization of the approach and the identification and training of the participants.

Methodology components In practice, many methodologies, particularly commercial ones, are products that are ‘packaged’ and might include: Manuals Education and training (including videos) Consultancy support Tools and toolsets Pro forma documents Model-building templates, and so on

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

Rationale for a methodology 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?)

Rationale for a methodology ... 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?)

Rationale for a methodology ... 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 A standardized process Staff can change between projects without retraining Common experience and knowledge can be accumulated Easy system maintenance Better systems integration

Evolution and development of methodologies – three eras Pre-methodology Early methodology era to 1988 Methodology era to 1995 Era of methodology reassessment to 2002

Three eras 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

Three eras … 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

Three eras … 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

Three eras … 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)

Three eras … 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)

Three eras (and three editions) of Avison & Fitzgerald Early methodology era to 1988 9 themes, 8 techniques, 9 methodologies Methodology era to 1995 12 themes, 11 techniques, 15 methodologies Era of methodology reassessment to 2002 28 themes, 29 techniques, 25 methodologies

… and the Fourth Edition? Does this suggest some stability and Maturity in the field of Information Systems Development? Or does its increased coverage suggest less coherence and maturity?

Fitzgerald et al. (1999) - survey 57% using a methodology for systems development, of these: 11% were using a commercial development methodology unmodified, 30% were using a commercial methodology adapted for in-house use, 59% a methodology which they claimed to be unique to their organization

Designing methodologies Written up Made consistent Made comprehensive Made marketable Updated as needed Maintained Researched and developed Evolved into training packages Provided with supporting software

Designing methodologies Filling the gaps Expanding the scope Gaining competitive advantage

Themes – organisational, modelling, engineering and construction, people ….. Systems approach Strategic information systems Business process engineering Planning approaches Stages of growth Flexibility Project management Process modelling Data modelling Object modelling Legacy systems Evolutionary development Prototyping Rapid development Method engineering Web development Participation End user development (and client-led) Expert systems Knowledge management Customer orientation External development Application packages Enterprise resource planning Outsourcing Software Software engineering Automation Component development (and open source) Database management

Techniques – holistic, data, process, object-oriented, management, estimation, organisational, people …… Rich pictures Root definitions Conceptual models Cognitive mapping Entity modelling Relational modelling Normalization Dataflow diagramming Decision trees Decision tables Structured English Structure diagrams Structured walkthroughs Matrices Action diagrams Entity life cycle Object orientation UML Case-based reasoning Risk Analysis PERT Charts Gantt charts Lateral thinking Critical success factors Scenario planning Future analysis SWOT People techniques Stakeholder analysis Joint application development (JAD)

Tools and toolsets Tools Toolsets Project management : MS Project Groupware: GroupSystems Ventura Web site development: Dreamweaver Drawing: Microsoft Visio Database management system: Access Toolsets Information Engineering Facility Select Oracle

Methodologies – process, blended, object-oriented, rapid, people, organisational, frameworks…… STRADIS YSM JSD SSADM Merise IE Welti ERP development OOA RUP RAD JM DSDM Extreme programming WISDM (web development) ETHICS KADS CommonKADS SODA SSM ISAC PI CMM PRINCE Renaissance Multiview Euromethod

Why do organisations not adopt a methodology? Productivity Complexity ‘Gilding the lily’ Skills Tools Not contingent One-dimensional approach Inflexible Invalid or impractical assumptions Goal displacement Problems of building understanding into methods Insufficient focus on social and contextual issues Difficulties in adopting a methodology No improvements

Yet more questions Will methodologies solve the problems of IS development? Do methodologies have to change and develop? Do methodologies mean more bureaucracy and slower development? Should all organizations adopt a methodology? Where do methodologies go from here?

Where do we go from here? Ad-hoc development? Further developments in the methodology arena? Contingency? External development? What are the other movements or potential new ones?

End of Chapter 27 Thank You for Your Attention