1. Chapter 27
Issues

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

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

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

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

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

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

8. 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?)

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

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

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

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

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

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

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

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

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

18. … 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?

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

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

21. Designing methodologies
Filling the gaps
Expanding the scope
Gaining competitive advantage

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

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

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

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

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

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

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

29. End of Chapter 27
Thank
You for Your
Attention