Systems Analysis & Design Methods

SADM
IS 5800: Project Team
Dayanand Thakur & Teresa Zuro

November 6, 2007

1
 Overall Objective
What is Systems Development Methodology?
Why is it important?
What are the roles & responsibilities?
What is the System Development Lifecycle
What are its common components?
Do companies really use development
methodology?
Best Practices & Lessons Learned

2
 What is Systems Analysis & Design
Methodology?
Systems Analysis & Design Methodology
(SADM) A recommended collection of
phases; procedures; rules; techniques;
tools; documentation; management, and
training to improve the quality of a
software development effort. 1

Various methodologies have emerged

overtime 2

Transforming an ART into a SCIENCE

through structured methodologies

Interchangeable Terms
Systems Analysis & Design
Methodology
Systems Development Methodology
Software Development
Methodology

1. Avison, D. and Fitzgerald, G. "Where Now for Development Methodologies?" Communications of the ACM, Vol. 46, No. 1, 2003, pp.
79-81.
2. Georgiadou, E. Software Process and Product Improvement: A Historical Perspective. Cybernetics and Systems Analysis; Jan/Feb 3
2003; 39,1 pg. 125
 A Simple System Making Lunch
Understanding the IT way of Thinking
System Is composed of interacting parts that operate together to achieve
some objective or purpose. A system is intended to absorb inputs, process them
in some way and produce outputs. Outputs are defined by goals, objectives, or
common purposes. http://www.umsl.edu/~sauterv/analysis/intro/system.htm, reviewed 9/6/2007

PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2nd Edition , John Wiley & Sons, Inc. 4
 Overall Message
What is systems development methodology?
Why is it important?
What are the roles & responsibilities?
What is the System Development Lifecycle
What are its common components?
Do companies really use development
methodology?
Best Practices & Lessons Learned

5
 SADM is Important to MBA Students!
Preparation for future role
as a business manager

Bridging the gap between

IT & Business through
education

Once general managers understand IT through experience and education, they

are more likely to be involved in IT, and more likely to lead their organizations in
achieving business success through IT. - Lacity, M. Why General Managers Need to Understand
Information Technology

http://mygateway.umsl.edu/webapps/portal/frameset.jsp?tab_id=_2_1&url=%2Fwebapps%2Fblackboard%2Fexecute%2Flauncher%3Ftyp
6
e%3DCourse%26id%3D_16570_1%26url%3D
Why is SADM Important?
Software Evolution

The expanding role of software in the information world

forced attentions to software & development needs:
Acceptable speed & cost for development
Traceable time schedule for development process

Software products need to be developed with assurances:

High Quality
Longevityused/maintained over a long period of time
Accommodate the changing requirements of the user
Compliance

http://www.codeproject.com/useritems/Process.asp, reviewed 9/25/2007

7
 Why is SADM Important?
Managing Business Expectations & IT Capabilities
Systems Analysis & Design Methods:
The methodology used will dictate how systems development gets done
That is, the strategy, steps, directions, or actions taken.

Common SAD Methods:

Structured Systems Analysis & Design Methods (SSADM)
Rapid Application Development Methods (RAD)
Computer Assisted Software Engineering Tools (CASE)

Methodologies can be:

Purchased
Created in house
Combination of both

8
 Early Systems Development
Too Much Ambiguity
Business
Requirements Not
Inadequate tools & techniques for Satisfied
analysis and design.
Limited user involvement
Extensive maintenance after
Poor resource planning implementation
Poor project progress tracking Lack of business ownership
Requirements were misunderstood
Important data ignored or poorly
analyzed
Over budget & not delivered on
Unstructured schedule
Methods

http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html
9
http://www.mpstovsky.com/FGSU%20Slides.pdf
 Formal Methodology
Aim to better satisfy business
objectives.
Aim to Satisfy
Less ambiguity Business Needs
Extensive user involvement
Formalized requirements analysis Fewer misunderstandings
Best practices techniques for Business requirements satisfied
analysis, design, and testing Improved product quality
Time management Improved productivity
Cost management Reduced development lifecycle time
Resource management Reduction in post development costs

Methodical
Processes

http://www.codeproject.com/useritems/Process.asp 10
 Overall Message
What is systems development methodology?
Why is it important?
What are the roles & responsibilities?
What is the Systems Development Lifecycle
What are its common components?
Do companies really use development
methodology?
Best Practices & Lessons Learned

11
Systems Development
Major Roles & Responsibilities

Project Sponsor
Project Manager
IT Project Team
End User

12
 Project Sponsor
Owner
Most corporate leaders agree that Develop a convincing business
this person should be the executive case.
receiving a majority of the Get approval to proceed &
projects benefits. secure project funding
Monitor project progress
An effective business sponsor
Chair the project steering
provides the leverage needed to
promote, defend, and enhance the committee
success of the business initiative. Sponsor a risk assessment
Be a project cheerleader
Ultimately responsible for keeping Remove project roadblocks
the project on schedule, on budget, Assess project deliverables
and achieving its planned benefits.
Capture the benefits

Perkins, Bert, "Executive Sponsors: What They Really Do" Computerworld; Sep 12, 2005; 39,37, pp. 60 13
 Project Manager
The Bus Driver
Role of the Project Manager
Keep project on course 1. What is to be done?
Alert project owner of major roadblocks 2. What are the benefits?
Navigate detours
3. Who benefits?
Keep everyone on board
4. Who is the customer?
Maintain order
5. Who is the sponsor?
Goal is to arrive at final destination on
time & on budget
6. How will the deliverables fit the
legacy system?
According to Peter Schulte, author of, Complex IT 7. How much will the project cost?
Project Management 16 Steps to Success, there 8. What is the project timeline?
are thirteen key questions that must be asked.
9. What are key dependencies?
The purpose of the Big Thirteen is to:
10. What is the risk?
Uncover hard facts 11. What are the success metrics?
Assess the maturity of the project 12. How will we support this?
Get a feel for the positions and agendas of 13. What is the shelf life?
stakeholders
Schulte, Peter. Complex IT Project Management: 16 Steps to Success. Auerbach 2004 . pp. 3 14
IT Project Team
The Mechanics

The IT project team is the

projects mechanic.

Analyze business case

Feasibility study
Make recommendations
Design a system
Build the system
Test the system
Implement the system
Support the system
15
End User Community
The Passengers

The end user is the passenger on the project

journey. Some have a more detailed role but
all should benefit from the ride.

We provide input to
the needs and
requirements
analysis. We also
participate in systems
design and testing.

16
 Overall Message
What is systems development methodology?
Why is it important?
What are the roles & responsibilities?
What is the Systems Development Lifecycle
What are its common components?
Do companies really use development
methodology?
Best Practices & Lessons Learned

17
 System Development Lifecycle
Systems development is the process of developing
information systems through successive phases in
an orderly way.

http://whatis.techtarget.com/definition/0,,sid9_gci936454,00.html, reviewed 9/14/2007

18
 System Development Lifecycle Phases
PROJECT MANAGEMENT PHASES

Requirements
Planning Design Development Testing Implementation
Analysis

Planning Analysis Design Implementation

Wixom, Dennis & Haley. Systems Analysis and Design, 2nd Edition, John Wiley & Sons, Inc.
http://bcs.wiley.com/he-bcs/Books?action=index&itemId=0471073229&bcsId=1308
19
 Systems Development Lifecycle
Questions Answered

Planning Analysis Design Implementation

Why build the Who uses the How will the System
system? system? system work? delivery
How do we What will it Post-
structure the do? implementati
project? When & on support
where will it
be used?

Wixom, Dennis & Haley. Systems Analysis and Design, 2nd Edition, John Wiley & Sons, Inc.
http://bcs.wiley.com/he-bcs/Books?action=index&itemId=0471073229&bcsId=1308 20
 Systems Development Lifecycle
Participants
Planning Analysis Design Implementation
Project Sponsor Project Project Project
Project Manager * Manager * Manager *
Manager * Business Business Business
Business Managers * Managers* Managers *
Managers * Business Business Business
Business Systems Systems Systems
Systems Analyst* Analyst* Analyst*
Analyst* Technical Expert Technical Technical
End Users * End Users * Developers Developers
Vendor Vendor
Consultant Consultant
End Users * End Users *

21
 Systems Development Lifecycle
Definitions
PROJECT CHARTER is a statement of the scope, objectives and participants in
a project It serves as a reference of authority for the future of the project.

REQUIREMENTS/NEEDS ANALYSIS encompasses those tasks that go into

determining the needs or conditions to meet for a new or altered device, taking
account of the possibly conflicting requirements of the various stakeholders.
Functional Requirementsspecific functions that the software performs.
Non-functional Requirementssuch as performance, operational
environment, standards conformance, reliability, robustness, accuracy of
data, correctness.

SPECIFICATIONS ANALYSIS A project's specifications consist of the body of

information that should guide the project developers, engineers, and designers
through the work of creating the software.
http://en.wikipedia.org/wiki/Main_Page ;
http://www.philosophe.com/design/requirements.html
http://www.csc.calpoly.edu/~gfisher/classes/205/handouts/spec-doc-outline.html
22
Project Requirements Vs. Specifications
Project Scope Requirement Specification

DATE Month of July

Florida
U.S.
LOCATION

Gulf Coast

Family Vacation
Driving
TRANSPORTATION
Family Car

Condo
Sleeps 6

Within 1 block
ACCOMMODATIONS
of beach

Swimming Pool
23
on Site
 Systems Development Lifecycle
Definitions
TECHNICAL FEASIBILITY STUDY Involves questions such as whether
the technology needed for the system exists, how difficult it will be to
build, and whether the firm has enough experience using that
technology. The assessment is based on an outline design of system
requirements in terms of Input; Output; Fields; Programs, and
Procedures.

CONCEPTUAL SYSTEM DESIGN - A conceptual system is simply a

model. There is no limitations on this kind of model whatsoever except
those of human imagination.

SYSTEMS INTEGRATION TESTING is testing conducted on a complete,

integrated system to evaluate the system's compliance with its
specified requirements.

http://en.wikipedia.org/wiki/Main_Page ;
http://www.philosophe.com/design/requirements.html
24
 Systems Development Lifecycle
Deliverables

PLANNING ANALYSIS DESIGN IMPLEMENTATION

Project Charter Needs Physical design System
& Business Case /Requirements Prototypes integration &
Form CORE analysis Construction testing
project team Specifications Develop and/or Post-
Project analysis Purchase implementation
Managers Big Feasibility Study System testing audit,
13 Conceptual User maintenance &
design acceptance support
testing

25
 Overall Message
What is systems development methodology?
Why is it important?
What are the roles & responsibilities?
What is the Systems Development Lifecycle
What are its common components?
Do companies really use development
methodology?
Best Practices & Lessons Learned

26
 System Development Methodology
Two Common Approaches
Joint Application
Development

Rapid Application
Development Spiral
(RAD)

Methodology Iterative

Structured
Systems Analysis Waterfall
& Design (SSADM) 27
 The Waterfall Model-Basic Concepts
Project is divided into sequential
phases ,with some overlap
acceptable between phases.

Emphasis is on planning, time

schedules, target dates, budgets
and implementation of entire
system at one time.

Tight control is maintained over

the life of project through the
extensive use of documentation as
well as through formal reviews and
approvals by user and IT
management occurring at the end
of most of the phase before
beginning of the next phase.

Paul Fisher,James Mc Daniel and Peter Hughes," System Development lifecycle Models and Methodologies", Canadian Society for International Health
certificate course in Health Information systems,Module-3,Part-3:Lifecycle Models and Methodologies.
Alan Dennis, Barbara Haley Wixom, and Roberta Roth, System Analysis and Design 3 rd Edition, John Wiley and Sons Inc. 28
Waterfall Model
Strengths Weaknesses
Ideal for supporting less Inflexible, slow, Costly and
experienced project teams. Cumbersome.

Orderly sequence of steps and Problems not identified until

strict control ensures Quality, testing.
Reliability and Maintainability of
developed system. Difficult to respond to changes.

Progress is measurable. Depends on early identification

and specification of
requirements, yet users may not
be able to clearly define them.

Daryl Green and Ann DiCaterino, A survey of system development process models, CTS Albany,Feb.1998.
29
 RAD Phased Development
Methodology
User design: users
and IS professionals
This methodology breaks the overall participate in JAD
system into a series of versions that sessions
are developed sequentially.

The team categorizes the

requirements into a series of
versions, then the most important
and fundamental requirements are
bundled into the first version of the
system.

The analysis phase then leads into

design and implementation;
however, only with the set of
requirements identified for version 1.
Cutover is delivery of
new system to end users
As each version is completed, the
team begins work on a new version. 30
RAD Methodology
Strengths Weaknesses
Early visibility Buying corporate software
Greatly reduced manual coding components could be costly
Increased user involvement Application is less efficient and less
Possibly fewer defects precise
Possibly reduced cost May accidentally empower a return
Shorter development cycles to the uncontrolled practices of the
Standardized look and feel early days of software development
Reduced features
Reliance on third-party components
may
sacrifice needed functionality
add unneeded functionality
create legal problems

Software Engineering Sommerville; seventh edition; Pearson Education. Chapters 4,7 31

System Development Life Cycle
Tools & Techniques
Techniques and Tools Representing

Communication
System Flow Data Process Logic
with Users

Data Flow Decision Tree

ER Diagrams Interviews
Diagrams /Table

Business Data Structured

User Reviews
Area Analysis Dictionary Charts

Data Business
Process
Structure JAD Sessions Systems
Model
Diagrams Design

Business Brain
Area Analysis Storming
32
 Entity-Relationship Diagrams
A graphical representation of the
data layout of a system at a high
level of abstraction.

Defines data elements and their

inter-relationships in the system

The ERD is an implementation-

independent representation of a
problem domain and it facilitates
communication between the end-
user and the analyst.

The basic components of the ERD

are entities, properties of entities
called attributes, and
relationships between entities.
33
Data Flow Diagrams

34
 Data Dictionary

Data dictionary
Defines each data element and data group
Use of BNF to define structure of data groups

Example Data Dictionary

Mailing Label = customer_name +customer address

customer_name =customer_last_name +customer_first_name +customer_middle_initial

customer_address =local_address +community_address + zip_code

local_address =house_number + street_name +(apt_number)

community address =city_name + [state_name |province_name]

35
CASE Tools
Computer-Aided Software Engineering
Diagramming tools support contemporary
systems development
Screen and report
generators automate step-by-step
development methods
Analysis tools reduce the amount of
repetitive work
Repository
allow developers to free
their mind cycles for
Documentation generators more creative problem-
solving tasks
Code generators

36
 CASE Tools
Ab Integrated CASE tools
support the entire SDLC

Upper CASE
A Used to automate the first three phases
of SDLC
Lower CASE
b Used to automate the last two phases of
SDLC

37
 Factors Affecting Use of
SAD Methods
Waterfall vs. Prototyping

1. Development Team Size

Large = Waterfall
Small = Prototype

2. Organization Innovativeness
Late Adopter = Waterfall
Early Adopter = Prototype

Research by: Khalifa & Verner (2000) 3. Developers Beliefs/Perceived

N = 82 senior software developers
Questionnaire
Consequences of Process Quality
Australia & Hong Kong Project control = Waterfall
Well-established organizations with many years of Communication with users =
software development experience.
Average IS staff: 200 Prototype
Khalifa, M. and Verner, J. "Drivers for Software Development Method Usage". IEEE Transactions On Engineering Management, Vol. 47.
No.3, August 2000 pp. 360-369 38
 Development
methodology
products found
in the market
today.

Trepper, Charles. "Continuous Process Improvement". InformationWeek. August 21, 2000, Issue 800 . pp. 65 39
 Overall Message
What is systems development methodology?
Why is it important?
What are the roles & responsibilities?
What is the Systems Development Lifecycle
What are its common components?
Do companies really use development
methodology?
Best Practices & Lessons Learned

40
 Research Shows.
Research by: Lang & Fitzgerald Format: Web & Postal Survey
Location: Ireland Original Population: 438
Response Rate: 45%

Lang, M. and Fitzgerald, B."New Branches, Old Roots: A Study of Methods and Techniques in Web/Hypermedia Systems Design". 41
Information Systems Management, Summer 2006. 23, 3, pp. 62-74
 Fortune 1000 Company
Case Study #1
SADM Implementation Effectiveness
185 Application Developers Measurable improvements
Going from no methodology to a within 6 months
comprehensive company wide Based on comparison of 2,251
methodology. projects before methodology
& 280 projects after:
Methodology was adaptable to
18% increase in on-budget
many project types. performance
Training: 150 page guide and 26% reduction in number of
access to online version with links late projects
to tools & templates 25% reduction in average days
late
CIO Support: All developers
Higher customer satisfaction
received a formal written policy to
Less training time required for
begin using methodology for all new hires and transfers among
projects. teams
Riemenschneider, C. and Hardgrave, B. "Explaining Software Developer Acceptance of Methodologies: A Comparison of Five 42
Theoretical Models". IEEE Transactions on Software Engineering. Vol. 28, No. 12. Dec 2002. pp. 1135 - 1145
 A More Detailed Look
Fortune 100 Company - Case Study #2
Revenues
Sector: Financial
Lines of Business:
Community Banking 25% 33%
Home and Consumer Finance (HCFG) *
Wholesale Banking
Total Revenue (2006): $35,691MM 42%

Employees:
Total Employees158,000 +
IT Employees6,800 Consumer Banking
IT Support Group: Technology HCFG *
Information Group (TIG) Wholesale Banking

Interview: Company Name and Interviewee Anonymous, IT Project Manager interviewed in person by Dayanand Thakur and Teresa
43
Zuro, October 5, 2007
 Technology Information Group (TIG)
8 Divisions / 6,800 Employees
Information Services = largest division within TIG focus on application development.
5 CIO Groups within Information Systems
Each CIO group supports a distinct line of business (LOB)
Each CIO group has 6 unique CIO Councils CEO

TIG CIO

Tech & Wireless &

Tech Human
Enterprise Tech Shared EACO Finance Accounting
Infrastructure Resources
Info Services Services

Services

CIO CIO CIO CIO

CIO

LARGE
LOB 2 LOB 3 LOB 4 LOB 5

HCFG

Relationship
Manager
Technology
Officer
Application
Officer
Architect
Quality
Assurance
Officer
Infrastructure
Relationship
Manager
COMPLEX
(HCFTG)

Interview: Company Name and Interviewee Anonymous, IT Project Manager interviewed in person by Dayanand Thakur and
DECENTRALIZED
44
Teresa Zuro, October 5, 2007
 Fortune 100 Company
How We Use Technology
Technology enables our customers to control
when, where and how they want to be served.
It is also the single most important cause of
the convergence of the financial services
industry.. Technology, alone, does not give us
a competitive advantage. Whats important is
the creativity and speed with which we use it.
Quote by company CEO found on company webpage

45
 Fortune 100 Company
Management Philosophy
Best Practices Adapting to Change

We learn from each other.We We subscribe to the Darwinian

share ideas, give ideas, find
ideas, and copy ideas from philosophy of success: its not
whoever has them. Were the strongest or most
always searching across the intelligent who will survive the
company for Best challenges of the future but
Practices.to improve the
customer experience, keep those who best adapt to
customers, attract new ones, change.
increase revenue and reduce
expenses.
Quote by company CEO found on
Quote by company CEO found on company webpage
company webpage
46
 The Integrated Methodology (IM)
HCFGs Project Roadmap
Is a scalable project
methodology that integrates
the best project management
practices and procedures into
one common, high level, end-
to-end business and technical
project methodology.

Is designed to provide
guidance to project teams by
enabling them to meet:
Project objectives
Business objectives
Production objectives
Audit and OCC
requirements
Interview: Company Name and Interviewee Anonymous, IT Project Manager interviewed in person by Dayanand Thakur and
Teresa Zuro, October 5, 2007 47
 Organization Goals
& IM Benefits
GOALS IM BENEFITS

Better understanding & Delivers one common methodology

preparation of the functionality IM incorporates proven best practices
being implemented to leverage gains already made
Improved accuracy in meeting A single process that enables easier
the business needs methodology maintenance
Enhanced communication; Quality is built into the process rather
teamwork; and job performance than focus on outputs
Earlier detection of issues & Flexibility unique solutions have
errors unique needs
Fewer project delays & lower Supports both iterative and waterfall
costs system development approaches
Proactive planning vs. reactive Supports both technical and non-
firefighting technical projects
Interview: Company Name and Interviewee Anonymous, IT Project Manager interviewed in person by Dayanand Thakur and Teresa
48
Zuro, October 5, 2007
49
 IM Key Components
Initiate Plan Execute Close
Project Phases

Goals define the focus and intent of work completed during a specific phase.
Checkpoints provide a way to evaluate the work completed during each phase
Goals & and determine if the project is ready to move on to next phase.
Checkpoints

An area of focus is a collection of related activities that are related to a major

area of concern within the overall project.
Areas of Focus

50
 IM Key Components cont
Project documents that help preserve the results of key project activities.
Artifacts (R)= Required; (CR)= Conditionally Required; (BP)= Best Practice

Defines the responsibilities of an individual, or a set of individuals.

Project Role

Support mechanisms for project teams Includes: software tools and

checklists
Tools

Defined by each area of focus. High-level activities which tell the project
team what needs to be done. Include: workflow, prerequisites, required
Process
Steps sign-off, roles, artifacts produced, & support tools.
51
 Scalability Guidelines
Dictate the Level of IM Adherence
Attributes SL1 SL2 SL3 SL4
IM Scalability
Guidelines $600K - $300K -
Project Cost > $1 MM See LOB
Defines the artifacts & $999K $599K
goals required for a
project based on its
Scalability Level (SL) Risk
360 130
Assessment > 600 See LOB
599 359
Score
SLs take into
consideration
project types Return on $600K - $300K -
> $1 MM See LOB
Investment $999K $599K
budget amounts
risks and complexity
Interview: Company Name and Interviewee Anonymous, IT Project Manager interviewed in person by Dayanand Thakur and
52
Teresa Zuro, October 5, 2007
 IM Governance
HCFTG Quality Assurance
Project Methodology &
Oversight & Measurement IM Metrics Functional Team
Process Council (PMAP)
Team
Established mid-2005 IT professionals Established by PMAP Council

Scope: to streamline & They identify significant They identify, analyze, &
enhance SDLC processes and project issues at the point of manage IM improvements and
artifacts origin & resolve before they processes.
impact project success.
PMAP Team: assists HCFG Project Success:
project teams successfully use Must meet all project,
IM processes business, & production
objectives.
Project Information Channel: Audit & OCC compliance
to support continuous process
improvement IM Compliance:
Enterprise PM (EPM)
OCC
 Overall Message
What is systems development methodology?
Why is it important?
What are the roles & responsibilities?
What is the Systems Development Lifecycle
What are its common components?
Do companies really use development
methodology?
Best Practices & Lessons Learned

54
 Systems Analysis & Design
The Challenge
Does One Methodology
Fit All Problem Situations? Problem Situations
One method is likely not suitable for all CLASS I: Well structured problem
project types. Factors to consider: situation with well defined
problem and requirements.
Project Factors size; objectives; CLASS II: Well structured problem with
timeframe; requirements; approval; risk; clear objectives but uncertain
decision support user requirements.
CLASS III: Unstructured problem situation
Technical Factors application/system where objectives are unclear or
type, design flexibility, developer conflicting among groups.
knowledge
CLASS IV: High user interaction with system
and/or user acceptance is
Organizational Factors user group important.
knowledge & support, job function impact
CLASS V: Complex problem situations
requiring a contingency approach
Project Team Factors - resources needed; to information systems.
knowledge/experience

Avison, D.E. and Taylor, V. "Information Systems Development Methodologies: a classification according to problem situation". Journal of
Information Technology, 1997, Vol 12, pp. 73-81b 55
 Lessons Learned & Best Practices
RESEARCH INTERVIEW
Stakeholder support & Commit to building a working
participation relationship between IT & the
Senior management commitment business
Well balanced project team IT must treat business like a
customer
Clear business objectives Use Best PracticesDo Not
SADM must fit project/problem Reinvent the wheel
situation Project Governance
Thorough requirements/needs Amenable to change
analysis & proper documentation Keep it simple
Smaller is better Deliver project in phases
Ensure accountability IT account manager for each
Project retrospectives business team One Stop Shop

1. Al-Mushayt, O., Doherty, N, and King, M. "An Investigation into the Relative Success of Alternative Approaches to the Treatment of
Organization Issues in Systems Development Projects". Organization Development Journal. Spring 2001. 19,1, pp. 31-47
2. Interview: Company Name and Interviewee Anonymous, IT Project Manager interviewed in person by Dayanand Thakur and Teresa
Zuro, October 5, 2007 56
Q&A

57
 Additional References
1. Finlay, Paul N, Mitchell, Andrew C. Perceptions of the benefits from introduction of CASE: An
Empirical Study. MIS Quarterly. Dec 1994. Volume 18. No. 4. Pp. 353
2. Hugos, Michael. How to Sponsor A Project. Computerworld. Mar 21, 2005. Vol. 39. No. 12. Pp.
29
3. Larman, Craig, Basili, Victor R. Iterative and Incremental Development: A Brief History. IEEE
Computer Society. June 2003. pp. 47
4. Livari, Juhani. The Relationship Between Organizational Culture and the Deployment of Systems
Development Methodologies. MIS Quarterly. March 2007. Vol. 31. No. 1. pp. 35
5. Jiang, James, Klein, G., Balloun, J. Systems Analysts Attitudes Toward Information Systems
Development. Information Resources Management Journal. Fall 1998. Vol 11. No 4. pp. 5
6. Middleton, Peter. Barriers to the efficient and effective use of Information Technology The
International journal of Public sector Management, Vol 13, 1, 2000, pp 85
7. Pratt, Mary, What Do Users Want. Computerworld. June 26, 2006. Vol. 40. No. 26. Pp. 40
8. Roberts, Tom, Leigh, W, Purvis, R. Perceptions on Stakeholder Involvement In the
Implementation of Systems Development Methodologies. The Journal of Computer Information
Systems. Spring 2000. Vol. 40. No. 3. Pp. 78
9. http://www.methodsandtools.com viewed Oct, 5, 2007.
10. http://www.stsc.hill.af.mil/crosstalk/1995/01/Comparis.asp viewed, Sep 20, 2007.

58