System Development Methods
CT00046-3-2
Comparing
Methodologies
This presentation file offers you an engaging experience in digital learning. All content in
this presentation, lecture notes, visual media and music are credited to its owner under
creative commons license. This presentation file belongs to APU and no media in this
presentation should be duplicated or distributed. Typefaces used in this presentation are
Trueno & Calibri.
01 Comparing Methodologies
Topic &
Structure of the
Lesson
02 Framework
Here are the items that will
be discussed in this lesson
03 Blending Methodologies
Learning Outcomes
By the end of this lecture, you should be able to :
1. Describe the criteria needed to compare methodologies.
2. Explain how a framework is used to select a methodology for a project.
3. Understand the purpose of blending methodologies.
Comparing Methodologies
Key Terms
you must be Framework
able to use
If you have mastered this
topic, you should be able to Blending Methodologies
use the following terms
correctly in your assignments
and exams:
01 Comparing Methodologies
01
Comparisons of Methodologies
Comparison made to select one (or more) suitable methodology for a project.
Wrong selection (or no methodology) would be disastrous. According to the
report by Hass (2007), the following are the troubling results from the past
projects:
• $80 -145 billion per year is spent on failed and cancelled projects (The Standish Group
International, Inc.)
• 25% - 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
• 50% are rolled back out of production (Gartner)
• 40% of problems are found by end-users (Gartner)
• Poorly defined applications have led to a persistent miscommunication between business and IT.
This contributes to a 66% project failure rate for these applications, costing U.S. businesses at
least $30 billion every year (Forrester Research)
• 60% - 80% of project failures can be attributed directly to poor requirements gathering, analysis,
and management (Meta Group)
01
Comparisons of Methodologies (cont’)
Nearly two thirds of all IT projects fail or run into trouble. (see figure below for
the results of the 2006 CHAOS Survey)
IT Projects in the United States, 2006 Survey
65% Failed : 19%
Source: The Stardish Source: The blending of traditional
19%
Group 2006 Chaos and agile project management
Report (Hass, 2007)
Over Time or 46%
Budget : 46%
35%
Succeeded: 35%
Figure 2: Project Performance Track Record – The Standish Group 2006 Chaos Report
01
Choosing the right Methodology
depends on:
The type of problems and suggested solution
• Direct solution, hypothesis, anomalies, etc.
The type of project
• Exclusive, corporate, partnership, outsourced, etc.
• Speed of the project.
Type of products
• Mobile, web, stand-alone, enterprise / corporate, etc.
• The expected output (conceptual, working product, etc.)
Requirements are fixed or can be often changing
Size and budget of the project
01
Choosing the right Methodology
depends on: (cont’)
Knowledge of developer
• Developer trained specifically under one methodology. Have enough resources for most of the
process.
• Developers can be easily trained on the methodology.
• The Vendor/partner is familiar with the methodology you use.
• Tools that developer have VS tools recommended by the methodology
Support for a methodology is easily obtained
• Tools, technologies, infrastructure, etc.
• Experts are available.
Availability of users throughout the project
01
Comparing Methodologies (example)
Features Waterfall V-Model Spiral RAD
Identification of At the beginning At the beginning At the beginning Flexible and
requirements of a project of a project of a project adaptable to
specifications changes
Cost Low Expensive Expensive Low
Expertise High Medium High Medium
Flexibility Rigid Little flexible Flexible High
Maintenance Least East Typical Easily
maintained
Duration Medium to Long Medium to Long Medium to Long Short term
term project term project term project project
02
Methodology Selection with a Framework
02
Framework
Frameworks are a systematic way of applying methodologies
It allows developers to see the system from different ‘point of view’
It shows the most efficient solutions for problems.
Example: MULTIVIEW framework, NIMSAD framework.
Looks at a scenario from many views and creates an automated design based on the captured tasks.
Focuses on Organizational analysis, Information analysis, Technical design, Human computer
MULTIVIEW
interaction and Work design.
A methodology for selecting and evaluating a methodology using three criteria: the problem
NIMSAD situation, the problem solver and the problem-solving process.
02
NIMSAD Framework
Normative Information Model-based Systems Analysis and Design (NIMSAD) is a
general framework that was derived from problem-solving industry, consultancy
practice and ‘action research’, and can be used for evaluating any methodology.
The reasons for developing a framework for assisting methodology users arose
because of the availability of so many methodologies, and the difficulties for
problem solvers in selection and use.
The aims of NIMSAD framework are:
Serve as a way of understanding the areas of problem solving, in general.
Help evaluate methodologies, their structure, steps, form, nature, etc.
Help to draw conclusions.
02
NIMSAD Framework Elements
The NIMSAD framework has four essential elements, namely:
The ‘problem situation’ (the methodology context)
The intended problem solver (the methodology user)
The problem-solving process (the methodology)
The evaluation of the above three
02
NIMSAD Framework The ‘problem
situation’
Most problem situations are set within an organizational context; thus,
organizations are important for methodologies because:
• The effectiveness of information processing systems can be measured only to the extent of their
contribution to information users in organizations.
• In order to develop an information processing system, we need to interact with organizational
members, to know what information they use now, to discover what problems they are trying to
solve with this information, to understand how the information processing system that we
design are going to operate, and to know how exactly they are going to solve the identified
problem, etc.
02
NIMSAD Framework The ‘intended
problem solver’
Intended problem solvers, tend to select some elements of the situation as being
relevant and useful for study and transformation. Some of this selection are
implicit and unconscious (based on gut feelings, assumptions), and some are
explicit concepts, models and methodologies that are employed.
Some characteristics constitute the intended problem solver’s ‘mental construct’
including:
Perceptual process acts as a filter to information from the ‘action world’ and
determine what information is to be significant.
Values help to pass judgement on situations or to assess the actions, behavior,
output and performance of others.
02
NIMSAD Framework The ‘intended
problem solver’ (continued)
Ethics is related to the standards which we and others place on a person’s
expected behaviour. For example, most problem solvers believe that it is highly
unethical to divulge sources of information.
Motives are those needs that we try to satisfy in each situation but keep private
to ourselves
Prejudices can be defined as persistent opinions which we form from our values,
experiences, or out of insecurity. This may be useful to the extent that they help
to reduce the time we spend on information gathering.
Experiences are an invaluable source for developing knowledge and skills and
help to form implicit models for structuring our understanding of situations.
02
NIMSAD Framework The ‘intended
problem solver’ (continued)
Reasoning ability is an ability to abstract the essential aspects from any situation
and to understand the concepts underlying out thought processes i.e., examine
what makes us reason in a particular way.
Knowledge and skills are acquired from education, training, experience.
Roles can be defined as the explicit behavioural characteristics sets that can be
attributed to someone responsible for performing a set of tasks.
02
NIMSAD Framework The ‘problem-solving
process’
In the problem-solving process, the problem formulation phase can be
expressed in several stages, namely:
Stage 1: understanding of the ‘situation of concern’
Stage 2: performing the diagnosis
Problem Formulation Stage 3: defining the prognosis outline
Stage 4: defining problems
Stage 5: deriving notional systems
Stage 6: performing conceptual/logical design
Solution Design Stage 7: performing physical design
Design Implementation Stage 8: implementing the designs
02
NIMSAD Framework The ‘evaluation’
The evaluation helps to measure the effectiveness of the problem-solving
process and the problem solver in the ‘problem situation’.
Some aspects of evaluation to be carried out include:
• To assess whether the designed systems were implemented within the limits or resources, time,
and efforts.
• To assess whether the ‘action systems’ do what they are supposed to do i.e., the features of the
notional systems have been realized.
• To assess whether the ‘problems’ have been resolved.
03 Blending Methodologies
03
Blending Methodologies
Sometimes one methodology is not sufficient for a particular project.
• The project might be blended as well
• Vendors are involved / part of the project has been outsourced
A blended methodology is a methodology that has been created by “blending”
together other methodologies.
03
Blending Methodologies (continued)
Traditional
• Detailed plan for entire project
• Scope-boxed phases
Deterministic • Track progress by tasks and milestones completed
• Detailed documentation for all requirements
• Design all before coding in complete detail
• Periodic builds
Up-Front • Integrate only once all code complete
• Partial unit test coverage
• Business involvement only at project start and completion
Low • “ Throw it over the wall “ requirements communication model
• Communication via periodic state meetings (monthly or greater)
03
Blending Methodologies (continued)
Blended Agile
• Short to medium length time-boxed iterations
• Varying granularity plans
Project Management • Track progress by value delivered
• Risk – driven requirements documentation
• Risk and value – driven design choices
• Spike solutions for riskiest components
Design & Development • Daily builds
• Continuous functional testing, largely automated
• 80% unit test coverage
• Frequent, regular business involvement
• Cross-group collaboration via frequent checkpoints
Collaboration
• Cross-functional teams
• Daily “standup” meetings
03
Blending Methodologies (continued)
“Pure” Agile
• 1 – 2-week time boxed iterations
• Plan only current iteration
Evolutionary • Track progress by working code
• Tests are only long – term requirements documentation
• Design all just-in-time – nothing up front
• Minimal design documentation
Just-In-Time • Continuous integration builds
• Test-driven development; 100%-unit test coverage
• Continuous face – to- face business involvement
• Cross – functional teams
High • Pairing
• Daily “standup” meetings
03
Blending Methodologies Example
A study by Rahmanian (2014) has proposed a blending methodology which composed of
the Waterfall methodology and SCRUM.
The Waterfall methodology provides a sequential development process with a lack of
capability to accept frequent changes. Whilst, SCRUM provides various types of
communication ways i.e. :
• Sprint planning meeting
• daily Scrum meeting
• Sprint review
• Sprint Retrospective.
The blended methodology is divided into two parts: one part requires a high level of planning,
and the other one requires a high level of agility. During the initial stage.
The project team and client apply a "waterfall-up-front" to determine detailed requirements.
While the agile approach during the design, implementation, and unit testing phases helps to
speed up the process, reduce risks of rework, delays, and rescheduling. At last, the "waterfall-
at- end" support for high-level testing and user acceptance.
03
Blending Methodologies Example
(continued)
Waterfall-Up-Front Waterfall-Up-End
Requirements System Test
Analysis
High Level
Need “Planning”
Initial Design Integration Test
Need “Agility”
Detailed Design Unit Test
Low Level
Implementation
Abstraction Level Agile Methods
03
Conclusions on System Development
Methodologies
All Methodologies include:
• Steps on what to do throughout a project.
Stages
• Often CASE TOOLS includes any use of computer-based support in the software
development, help to simplify the task.
TOOLS Testing Tool to test other software.
Code Generator to generate programming codes from design.
• Different ways of doing tasks
Prototyping – A model of the system developed to get feedback
TECHNIQUES Fact-finding using techniques such as interviews, surveys, document review,
observation, and sampling.
References
• Rahmanian, M. (2014). A comparative study on hybrid IT project management. International Journal of
Computer and Information Technology, 3(05), 1096-1099.
• Mishra, A., & Dubey, D. (2013). A comparative study of different software development life cycle models
in different scenarios. International Journal of Advance research in computer science and management
studies, 1(5).
• Hass, K. B. (2007). The blending of traditional and agile project management. PM world today, 9(5), 1-8.
• Jayaratna, N. (1994). Understanding and evaluating methodologies: NIMSAD, a systematic framework.
McGraw-Hill, Inc.
The End
Comparing Methodologies
Next Session: System Development Planning