RTI System devolopment.ppt

Copyright Irwin/McGraw-Hill 1998
1
Information System Development
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Introduction
 The chapter will address the following questions:
 What is the difference between the system development life cycle
and a methodology?
 What are the eight basic principles of systems development?
 What are the definitions of problems, opportunities, and directives
– the triggers for systems development projects?
 What is the framework that can be used to categorize problems,
opportunities, and directives?
 What is the phased approach to systems development? For each
phase or activity, what is its purpose, participants, prerequisites,
deliverables, activities, postrequisites, and impact?

2
Introduction
 The chapter will address the following questions:
 What are the cross life cycle activities that overlap the entire life
cycle?
 What is the definition of computer-aided systems engineering
(CASE) and describe the role of CASE tools in system
development?

3
System Development Life Cycles
and Methodologies
 The process used to develop information systems is
called a methodology.
 All methodologies are derived from a logical system problem-
solving process that is sometimes called a system development life
cycle.
 A system development life cycle (SDLC) is a logical process
by which systems analysts, software engineers, programmers,
and end-users build information systems and computer
applications to solve business problems and needs. It is
sometimes called an application development life cycle.

4
and Methodologies
 What is a Methodology?
 A methodology is the physical implementation of the logical life
cycle that incorporates (1) step-by-step activities for each phase,
(2) individual and group roles to be played in each activity, (3)
deliverables and quality standards for each activity, and (4) tools
and techniques to be used for each activity.
 A true methodology should encompass the entire system’s
development life cycle.
 Most modern methodologies incorporate the use of several
development tools and techniques.

5
and Methodologies
 Why Do Companies use Methodologies?
 Methodologies ensure that a consistent, reproducible approach is
applied to all projects.
 Methodologies reduce the risk associated with shortcuts and
mistakes.
 Methodologies produce complete and consistent documentation
from one project to the next.

6
Underlying Principles of Systems
Development
 Principle 1: Get the Owners and Users Involved
 Owner and user involvement is an absolute necessity for successful
systems development.
 The individuals responsible for systems development must make
time for owners and users, insist on their participation, and seek
agreement from them on all decisions that may affect them.
 Methodologies reduce the risk associated with shortcuts and
mistakes.
 Methodologies produce complete and consistent documentation
from one project to the next.

7
Development
 Principle 2: Use a Problem-Solving Approach
 A methodology is, first and foremost, a problem-solving approach
to building systems.
 The classical problem-solving approach is as follows:
 Study and understand the problem (opportunity, and/or
directive) and its system context.
 Define the requirements of a suitable solution.
 Identify candidate solutions and select the ``best'' solution.
 Design and/or implement the solution.
 Observe and evaluate the solution's impact, and refine the
solution accordingly.

8
Development
 Principle 2: Use a Problem-Solving Approach
 There is tendency among inexperienced problem solvers to
eliminate or abbreviate one or more of the problem solving steps.
 The result can be range from:
 solving the wrong problem
 incorrectly solving the problem
 picking the wrong solution

9
Development
 Principle 3: Establish Phases and Activities
 Most life cycles and methodologies consist of phases.
 In its simplest, classical form, the life cycle consists of four phases:
 systems survey
 systems analysis
 systems design
 systems implementation
 A fifth activity, systems support, refines the resulting system by
iterating through the previous four phases on a smaller scale to
refine and improve the system.

10
INFORMATION SYSTEMS FRAMEWORK
S
Y
S
T
E
M
A
N
A
L
Y
S
T
S
SYSTEM
BUILDERS
(components)
SYSTEM
DESIGNERS
(specification)
SYSTEM
USERS
(requirements)
SYSTEM
OWNERS
(scope)
Database
Technology
Database Structures
Database Scehma
Data Requirements
Business Subjects
FOCUS ON
SYSTEM
DATA
Application Programs
Application Schema
Business Processes
Business Functions
FOCUS ON
SYSTEM
PROCESSES
Component Programs
Interface Schema
Interface Requirements
System Context
FOCUS ON
SYSTEM
INTERFACES
Software
(and Hardware)
Technology
Interface
Technology
Networking
Telchnology
Network Programs
Network Schema
Communication Reqts.
Operating Locations
FOCUS ON
SYSTEM
GEOGRAPHY
SYSTEM
SUPPORT
SYSTEM
IMPLEMENTATION
SYSTEM
DESIGN
SYSTEM
ANALYSIS
SYSTEM
PLANNING
System
Development
CREATE TABLE CUSTOMER
(customer_no CHAR(10) NOT NULL
customer_name CHAR(32) NOT NULL
customer _rating CHAR(1) NOT NULL
balance_due DECIMAL(5,2)
CREATE INDEX cust_no_idx on CUSTOMER
CREATE INDEX cust_rt_idx on CUSTOMER
CUSTOMER
customer-no
customer-name
customer-rating
balance-due
PRODUCT
product-no
product-name
unit-of-measure
unit-price
quantity-available
ORDER
order-no
order-date
products-ordered
quantities-ordered
Or der Form
Help +
Custom er
Form
Pr oduct
Lookup
Logon
New Custom er
New Order
Or der Accepted
Change
of
Addr ess
Fir st Order
Request Or der Help
Or der Help Com plete
Request
Pr oduct
Lookup
Request Pr oduct Lookup Help
Pr oduct Lookup Help Com plete
On Event Help.ButtonClick Do
Change Focus HelpDialog
On Event OKButton Do
Begin
{proecdure}
End
On Event CancelButton Do
Create AccountType =
SalesClerk
Set OrderDir.Rights=full
Set CustomerDir.Rights=full
Set ProductDir.Rights=read
Set OrderAppDir.Rights=copy
Customers order zero,
one, or more products.
Products may be ordered
by zero, one, or more
customers.
Marketing
Advertising
Orders
Sales
Cancellations Services
O
rder
Management
System
Customer
Accounts
Receivable
Database
Warehouse
Bank
O
rder
Picking
O
rder
Credit
Credit
Voucher
Check
credit
Validate
customer
Validate
products
Release
order
Customers
Orders
Products
order
customer
number
valid order
order without
valid
customer
credit
order with
valid products
approved order
quantity
in stock
approved
order
rejected order
prices
picking
ticket
Fi recracker Sal es
EDI
Cust
St.
Louis
HQ
LA
Office
Indy
W ar e-
house
NY
Office
W est
Custom ers
East
Custom ers
Maintenance
Records
Pr oducts
Catalog
or der
catalog
changes
ship
or der
ship
or der
ship or der
cr edit cr edit
service
CUSTOMER
customer_no [Alpha (10)] INDEX
customer_name [Alpha(32)]
customer_rating [Alpha(1)] INDEX
balance_due [Real(5,2)]
PRODUCT
product_no [Alpha(10)] INDEX
product_name [Alpha(32)]
unit_of_measure [Alpha(2)]
unit_price [Real(3,2)]
quantity_available [Integer(4)]
ORDER
order_no [Alpha(12)] INDEX
order_date [Date(mmddyyyy)
CUSTOMER.customer_no
ORDER_PRODUCT
ORDER.order_no
PRODUCT.product_no
quantity_ordered [Integer(2)
Order
Processing
Program
Process
an Order
Initiation
Routine
Shutdown
Routine
Get an
Order
Validate
an Order
File an
Order
Check
Customer
Credit
Check
Product
Data
Check
Credit
Data
Release
an
Order
Customers Products
Orders
St. Louis
Mainframe
Indy AIX Server
NT Server LA
NT Server NY
Communications
Controller
PBX
Enternet LAN AIX/Lan
Manager
Ethernet LAN/NT
Ethernet LAN/NT
Client PC Client PC
Client PC Client PC
VALIDAT E_AN_ORDER.
REPEAT UNT IL NO_MORE_ORDERS
PERFORM CUST OMER_VALIDAT IO
REPEAT UNT IL NO_MORE_ORDER
PERFORM PRODUCT _VALIDATI
END REPEAT .
PERFORM CREDIT _CHECK.
IF CREDIT _CHECK 'BAD' THEN

11
Development
 Principle 3: Establish Phases and Activities
 Phases are usually broken down into activities and tasks that can
be more easily managed and accomplished.
 The phases of a project should be completed top-to-bottom, in
sequence.

12
Development
 Principle 4: Establish Standards for Consistent
Development and Documentation
 Systems development standards usually describe:
 activities
 responsibilities
 documentation guidelines or requirements
 quality checks
 The need for documentation standards underscores a common
failure of many analysts – the failure to document as an ongoing
activity during the life cycle.

13
Development
 Principle 5: Justify Systems as Capital Investments
 Information systems are capital investments.
 When considering a capital investment, two issues must be
addressed:
 for any problem, there are likely to be several possible solutions
 after identifying alternative solutions, the systems analyst
should evaluate each possible solution for feasibility, especially
for cost-effectiveness.
• Cost-effectiveness is defined as the result obtained by striking a
balance between the cost of developing and operating a system,
and the benefits derived from that system.
 Cost-benefit analysis is an important skill to be mastered.

14
Development
 Principle 6: Don’t Be Afraid to Cancel or Revise Scope
 A significant advantage of the phased approach to systems
development is that it provides several opportunities to reevaluate
feasibility.
 In the long run, canceled projects are less costly than implemented
disasters!
 Most analysts fail to adjust estimated costs and schedules as scope
increases. As a result, the analyst frequently and needlessly accepts
responsibility for cost and schedule overruns.

15
Development
 Principle 6: Don’t Be Afraid to Cancel or Revise Scope
 The creeping commitment approach:
 Multiple feasibility checkpoints are built into the systems
development methodology.
 At any feasibility checkpoint, all costs are considered sunk
(meaning irrecoverable) and irrelevant to the decision.
 The project should be reevaluated at each checkpoint to
determine if it is still feasible.
 At each checkpoint, the analyst should consider:
• cancellation of the project if it is no longer feasible
• reevaluation of costs and schedule if project scope is to be
increased
• reduction of scope if the project budget and schedule are frozen,
but not sufficient to cover all project objectives.

16
Development
 Principle 7: Divide and Conquer
 All systems are part of larger systems (called super-systems).
 Virtually all systems contain smaller systems (called subsystems).
 We divide a system into its subsystems in order to more easily
conquer the problem and build the larger system.
 By dividing a larger problem (system) into more easily
managed pieces (subsystems), the analyst can simplify the
problem-solving process.

17
Development
 Principle 8: Design Systems for Growth and Change
 Many systems analysts have fallen into the trap of developing
systems to meet only today's user requirements.
 Entropy is the term system scientists use to describe the natural
and inevitable decay of all systems.
 During the support phase, the cost of maintenance exceeds the
costs of starting over – the system has become obsolete.

18
Systems
Planning
Systems
Analysis
Systems
Design
Systems
Implementation
Systems
Support
Obsolete System
New 'business' problem or requirement
New 'technology'
alternative or requirement
Implementation error

19
Development
 Principle 8: Design Systems for Growth and Change
 Systems that are designed to meet only current requirements are
difficult to modify in response to new requirements.
 Many systems analysts become frustrated with how much time
must be dedicated to supporting existing systems (often called
legacy systems), and how little time is left to work on important,
new systems development.
 Today's tools and techniques make it possible to design systems
that can grow and change as requirements grow and change.
 Flexibility and adaptability do not happen by accident – they must
be built into a system.

20
Development
 Get the owners and users involved
 Use a problem-solving approach
 Establish phases and activities
 Establish standards for consistent
development and documentation
 Justify systems as capital investments
 Don’t be afraid to cancel
 Divide and conquer
 Design systems for growth and change

21
FAST –A System Development
Methodology
 How a FAST Project Gets Started
 When system owners, system users, or systems analysts initiate a
project, FAST calls this a unplanned system request.
 Unplanned system requests are frequently screened and
prioritized by a steering committee of system owners to
determine which requests get approved.
 The requests which are not approved are often said to be
backlogged until resources become available (which
sometimes never happens).

22
Methodology
 The opposite of an unplanned system request is a planned system
initiative.
 A planned system initiative is the result of one of the following
earlier projects:
• an information strategy plan that has examined the business as a
whole for the purpose of identifying those systems and application
development projects that will return the greatest strategic (long
term) value to the business.
• a business process redesign that has thoroughly analyzed a series
of fundamental business processes to eliminate redundancy and
bureaucracy, and to improve efficiency and value-added – now it is
time to redesign the supporting information systems for those
business processes.

23
Methodology
 Planned or unplanned, the impetus for most projects is some
combination of problems, opportunities, or directives.
 Problems are undesirable situations that prevent the
organization from fully achieving its purpose, goals, and
objectives.
• Problems may either be current, suspected, or anticipated.
 An opportunity is a chance to improve the organization even
in the absence of specific problems.
 A directive is a new requirement that's imposed by
management, government, or some external influence.

24
Methodology
 PIECES - a useful framework for classifying problems,
opportunities, and directives.
 It is called PIECES because each of the letters represent one of six
categories.
P - the need to improve performance.
I - the need to improve information (and data).
E - the need to improve economics, control costs, or increase
profits.
C - the need to improve control or security.
E - the need to improve efficiency of people and processes
S - the need to improve service to customers, suppliers, partners,
employees, etc.

25
Methodology
The PIECES Problem-Solving Framework
The following checklist for problem, opportunity, and directive identification uses Wetherbe's PIECES
framework. Note that the categories of PIECES are not mutually exclusive; some possible problems show
up in multiple lists. Also, the list of possible problems is not exhaustive. The PIECES framework is
equally suited to analyzing both manual and computerized systems and applications.
PERFORMANCE Problems, Opportunities, and Directives
A. Throughput – the amount of work performed over some period of time.
B. Response time – the average delay between a transaction or request and a response to that
transaction or request
INFORMATION (and Data) Problems, Opportunities, and Directives
A. Outputs
1. Lack of any information
2. Lack of necessary information
3. Lack of relevant information
4. Too much information – ``information overload''
5. Information that is not in a useful format
6. Information that is not accurate
7. Information that is difficult to produce
8. Information is not timely to its subsequent use

26
Methodology
INFORMATION (and Data) Problems, Opportunities, and Directives
B. Inputs
1. Data is not captured
2. Data is not captured in time to be useful
3. Data is not accurately captured -- contains errors
4. Data is difficult to capture
5. Data is captured redundantly -- same data captured more than once
6. Too much data is captured
7. Illegal data is captured
C. Stored Data
1. Data is stored redundantly in multiple files and/or databases
2. Stored data is not accurate (may be related to #1)
3. Data is not secure to accident or vandalism
4. Data is not well organized
5. Data is not flexible – not easy to meet new information needs from stored data
6. Data is not accessible

27
Methodology
ECONOMICS Problems, Opportunities, and Directives
A. Costs
1. Costs are unknown
2. Costs are untraceable to source
3. Costs are too high
B. Profits
1. New markets can be explored
2. Current marketing can be improved
3. Orders can be increased
CONTROL (and Security) Problems, Opportunities, and Directives
A. Too little security or control
1. Input data is not adequately edited
2. Crimes are (or can be) committed against data
a. Fraud
b. Embezzlement
3. Ethics are breached on data or information – refers to data or information letting to
unauthorized people
4. Redundantly stored data is inconsistent in different files or databases

28
Methodology
CONTROL (and Security) Problems, Opportunities, and Directives
A. Too little security or control (continued)
5. Data privacy regulations or guidelines are being (or can be) violated
6. Processing errors are occurring (either by people, machines, or software)
7. Decision-making errors are occurring
B. Too much security or control
1. Bureaucratic red tape slows the system
2. Controls inconvenience customers or employees
3. Excessive controls cause processing delays
EFFICIENCY Problems, Opportunities, and Directives
A. People, machines, or computers waste time
1. Data is redundantly input or copied
2. Data is redundantly processed
3. Information is redundantly generated
B. People, machines, or computers waste materials and supplies
C. Effort required for tasks is excessive
D. Materials required for tasks is excessive

29
Methodology
SERVICE Problems, Opportunities, and Directives
A. The system produces inaccurate results
B. The system produces inconsistent results
C. The system produces unreliable results
D. The system is not easy to learn
E. The system is not easy to use
F. The system is awkward to use
G. The system is inflexible to new or exceptional situations
H. The system is inflexible to change
I. The system is incompatible with other systems
J. The system is not coordinated with other systems

30
Methodology
 An Overview of the FAST Life Cycle and Methodology
 The final output of the methodology is the production system (so
named because the system ‘produces results’).
 As you develop a system, you need a place to store various by-
products such as documentation, production data, and software.
 The three data stores are described as follows:
 the repository is a place where systems analysts and other
developers store documentation about the system. Examples of
such documentation might include written memos, user
requirements, and program flowcharts.

31
Methodology
 The three data stores are described as follows: (continued)
 the database is built during the project to store actual business
data about such things as CUSTOMERS, PRODUCTS, and
ORDERS. This database will be maintained by the application
programs written (or purchased) for the information system.
 the program library is where any application software and
programs will be stored once they are written (or purchased).

32
REASON:
A
System
Development
Methodology
System
Users
System
Owners
Production
System
Database
Program
Library
Repository
START
START
System
Knowledge
and
Documentation
Database
Structures
and actual
Business Data
Application
Programs
FINISH
Planned
System
Initiative
Unplanned
System
Request
OR

33
Methodology
 The symbology used in FAST is as follows:
 The rounded rectangles represent phases in a FAST system
development project.
 The thick green arrows represent the information flows that
trigger (or start) a FAST project.
 The thick black arrows represent the major deliverables (or
outputs) of the phases. Each deliverable contains important
documentation and/or specifications. Notice that the deliverable
of one phase may serve as input to another phase.

34
Methodology
 The symbology used in FAST is as follows: (continued)
 The thin black, doubled-ended arrows represent other
secondary information and communication flows. These flows
can take the form of conversations, meetings, letters, memos,
reports, and the like.
 The people silhouettes indicate people or organizations with
whom the analyst may interact.
 Finally, consistent with our creeping commitment principle, the
black circles indicate checkpoints at which time the project
participants should reevaluate feasibility and/or project scope.

35
1
Survey
Phase
2
Study
Phase
3
Definition
Phase
4
Targeting
Phase
6
Design
Phase
7
Construction
Phase
5
Purchasing
Phase
(if necessary)
8
Delivery
Phase
System
Users
System
Owners
Information
Technology
Vendors
Unplanned System Problem
Planned
System
Project
Project and
System Scope
System
Objectives
Business
Requirements
Technology
Requirements
Design
Requirements
Technology
Integration
Requirements
Design
Specifications
Prototypes
Operational
System
Business Requirements
Business
Requirements
Request
for
Proposals
Proposals
Production System

36
Methodology
 The FAST methodology consists of eight phases. They are as
follows:
 The Survey Phase establishes the project context, scope,
budget, staffing, and schedule.
 The Study Phase identifies and analyzes both the business and
technical problem domains for specific problems, causes, and
effects.
 The Definition Phase identifies and analyzes business
requirements that should apply to any possible technical
solution to the problems.

37
Methodology
follows: (continued)
 The Targeting Phase identifies and analyzes candidate technical
solutions that might solve the problem and fulfill the business
requirements. The result is a feasible, target solution.
 The Purchasing Phase (optional) identifies and analyzes
hardware and software products that will be purchased as part
of the target solution.
 The Design Phase specifies the technical requirements for the
target solution. Today, the design phase typically has significant
overlap with the construction phase.

38
Methodology
follows: (continued)
 The Construction Phase builds and tests the actual solution (or
interim prototypes of the solution).
 The Delivery Phase puts the solution into daily production.

39
1
Survey and
plan the
project
2
Study and
analyze the
existing
system
3
Define
and priortize
the business
requirements
4
Target a
feasible
system
solution
6
Design and
integrate
the
target
system
7
Construct
and test
the target
system
5
Purchase
any new
hardware and
software
8
Install and
implement
the
production
system
System
Users
System
Owners
Information
Technology
Vendors
training, support, and feedback
demonstrations
and
feedback
ideas
and
opinions
ideas
and
opinions
requirements
and
rriorities
the business,
problems,
causes, and
effects
Unplanned System Request
Planned
System
Project
Project and
System Scope
System
Objectives
Business
Requirements
Technology
Requirements
Design
Requirements
Technology
Integration
Requirements
Design
Specifications
Prototypes
Functional
System
technology standards
technology
standards
system
proposal
problem statement
and
feasibility analysis
Business Requirements
Business
Requirements
Request
for
Proposals
Proposals
technical
support
installation
support
consulting
services
Production System
executive
leadership
Feasibility
Assessment
and
Project
Plan
technical
leadership
scope
technology proposal

40
INFORMATION SYSTEMS FRAMEWORK
S
Y
S
T
E
M
A
N
A
L
Y
S
T
S
SYSTEM
BUILDERS
(components)
SYSTEM
DESIGNERS
(specification)
SYSTEM
USERS
(requirements)
SYSTEM
OWNERS
(scope)
Database
Technology
(and standards)
Database Structures
Database Scehma
Data Requirements
Business Subjects
FOCUS ON
SYSTEM
DATA
Application Programs
Application Schema
Business Processes
Business Functions
FOCUS ON
SYSTEM
PROCESSES
Component Programs
Interface Schema
Interface Requirements
System Context
FOCUS ON
SYSTEM
INTERFACES
Software
(and Hardware)
Technology
(and standards)
Interface
Technology
(and standards)
Networking
Telchnology
(and standards)
Network Programs
Network Schema
Communication Reqts.
Operating Locations
FOCUS ON
SYSTEM
GEOGRAPHY
On-Going Support
Maintenance
Continuous
Improvement
Construction Phase
Delivery Phase
Targeting Phase
Purchasing Phase
Design Phase
Study Phase
Definition Phase
Survey Phase
(and project
planning)
Methodology
CREATE TABLE CUSTOMER
(customer_no CHAR(10) NOT NULL
customer_name CHAR(32) NOT NULL
customer _rating CHAR(1) NOT NULL
balance_due DECIMAL(5,2)
CREATE INDEX cust_no_idx on CUSTOMER
CREATE INDEX cust_rt_idx on CUSTOMER
CUSTOMER
customer-no
customer-name
customer-rating
balance-due
PRODUCT
product-no
product-name
unit-of-measure
unit-price
quantity-available
ORDER
order-no
order-date
products-ordered
quantities-ordered
Or der Form
Help +
Custom er
Form
Pr oduct
Lookup
Logon
New Custom er
New Order
Or der Accepted
Change
of
Addr ess
Fir st Order
Request Or der Help
Or der Help Com plete
Request
Pr oduct
Lookup
Request Pr oduct Lookup Help
Pr oduct Lookup Help Com plete
On Event Help.ButtonClick Do
Change Focus HelpDialog
On Event OKButton Do
Begin
{proecdure}
End
On Event CancelButton Do
Create AccountType =
SalesClerk
Set OrderDir.Rights=full
Set CustomerDir.Rights=full
Set ProductDir.Rights=read
Set OrderAppDir.Rights=copy
Customers order zero,
one, or more products.
Products may be ordered
by zero, one, or more
customers.
Marketing
Advertising
Orders
Sales
Cancellations Services
O
rder
Management
System
Customer
Accounts
Receivable
Database
Warehouse
Bank
O
rder
Picking
O
rder
Credit
Credit
Voucher
Check
credit
Validate
customer
Validate
products
Release
order
Customers
Orders
Products
order
customer
number
valid order
order without
valid
customer
credit
order with
valid products
approved order
quantity
in stock
approved
order
rejected order
prices
picking
ticket
Fi recracker Sal es
EDI
Cust
St.
Louis
HQ
LA
Office
Indy
W ar e-
house
NY
Office
W est
Custom ers
East
Custom ers
Maintenance
Records
Pr oducts
Catalog
or der
catalog
changes
ship
or der
ship
or der
ship or der
cr edit cr edit
service
CUSTOMER
customer_no [Alpha (10)] INDEX
customer_name [Alpha(32)]
customer_rating [Alpha(1)] INDEX
balance_due [Real(5,2)]
PRODUCT
product_no [Alpha(10)] INDEX
product_name [Alpha(32)]
unit_of_measure [Alpha(2)]
unit_price [Real(3,2)]
quantity_available [Integer(4)]
ORDER
order_no [Alpha(12)] INDEX
order_date [Date(mmddyyyy)
CUSTOMER.customer_no
ORDER_PRODUCT
ORDER.order_no
PRODUCT.product_no
quantity_ordered [Integer(2)
Order
Processing
Program
Process
an Order
Initiation
Routine
Shutdown
Routine
Get an
Order
Validate
an Order
File an
Order
Check
Customer
Credit
Check
Product
Data
Check
Credit
Data
Release
an
Order
Customers Products
Orders
St. Louis
Mainframe
Indy AIX Server
NT Server LA
NT Server NY
Communications
Controller
PBX
Enternet LAN AIX/Lan
Manager
Ethernet LAN/NT
Ethernet LAN/NT
Client PC Client PC
Client PC Client PC
VALIDAT E_AN_ORDER.
REPEAT UNT IL NO_MORE_ORDERS
PERFORM CUST OMER_VALIDAT IO
REPEAT UNT IL NO_MORE_ORDER
PERFORM PRODUCT _VALIDATI
END REPEAT .
PERFORM CREDIT _CHECK.
IF CREDIT _CHECK 'BAD' THEN

41
Methodology
 The Survey Phase
 Purpose:
 The purpose of the survey phase is threefold.
• The survey phase answers the question, “Is this project worth
looking at?”
• The survey phase must define the scope of the project and the
perceived problems, opportunities, and directives that triggered the
project.
• The survey phase must establish the project team and participants,
the project budget, and the project schedule.

42
Methodology
 Participants and Roles
 The facilitator of this phase is the systems analyst.
 This phase describes the system and project from the
perspective of system owners.
 Example system owner roles:
• Executive sponsor – the highest-level manager who will pay for
the project.
• Technical sponsor – the highest-level manager from Information
Services organization who will pay for the project.
• Project manager(s) – the manager(s) of the project team. This
person is responsible for the staffing, budget, and schedule.

43
Methodology
 Prerequisites
 The key input to the phase is either the unplanned system
request or the planned system initiative.
 Activities
 The most important activity in the survey phase is to define the
scope or size of the project.
 Once scope has been defined, we need to answer that question
– “Is this project worth looking at?”
 Assuming the system is worth looking at, the project manager
should formally plan the project. This includes establishing a
preliminary budget and schedule, and staffing the development
team.

44
Methodology
 Deliverables
 A key deliverable for the survey phase is a project charter that
presents the findings, recommendations, and plans of the team
to the executive sponsors.
• This might be a report or verbal presentation; possibly both.
– The report version is sometimes called an initial study report.
• The analyst's recommendation may prescribe:
– a ``quick fix,''
– an enhancement of the existing system and software
– a completely new information system.
• For the latter possibility, a statement of project scope and
objectives is delivered to the study phase.

45
Methodology
 Postrequisites and Feasibility Checkpoints
 A circle at the beginning of any information flow indicates that
the flow ‘may or may not occur’ based on our creeping
commitment principle.
 Circles define feasibility checkpoints in FAST.
 The definition of project and system scope will only occur if
the project has been approved to continue to the next phase.

46
Methodology
 Postrequisites and Feasibility Checkpoints (continued)
 The feasibility assessment and project plan will be reviewed
by the system owners (or a steering committee that includes
system owners).
• One of four decisions is possible:
– approve the project to continue to the study phase
– change the scope and continue on to the study phase
– reject the project outright
– delay the project in favor of some other project

47
Methodology
 Impact Analysis
 Scope definition is critical to all projects, planned and
unplanned, but it could be deferred until the study phase for
those projects that have already been determined to be worth
looking at.

48
Methodology
 The Study Phase
 Purpose:
 The purpose of the study phase is threefold.
• The project team must gain an appropriate understanding of the
business problem domain.
• We need to answer the question, “Are these problems
(opportunities, and directives) worth solving”?
• We need to determine if the system is worth developing.
 This phase describes the system and project from the
perspective of system users.

49
Methodology
 The Study Phase
 Prerequisites
 The key input to the phase is the statement of project and
system scope from the survey phase.
 The project team studies the existing system by collecting
factual information from the system users concerning the
business and the perceived problems, causes, and effects.
 Activities
 Learning the system terminology, history, culture, and nuances
is the principle activity in this phase.
 During the study phase, we need to address the causes and
effects of the problems, opportunities, and directives. PIECES
can serve as a useful framework for doing this.

50
Methodology
 The Study Phase
 Deliverables
 The findings of the study phase are reviewed with the system
owners as a business problem statement and feasibility
analysis (sometimes called a detailed study report).
• The problem statement may take the form of a formal written
report, an updated feasibility assessment, or a formal presentation
to management and users.
• The problem statement should include system objectives. These
objectives define the business criteria on which any new system
will be evaluated.

51
Methodology
 The Study Phase
 The system owners will review findings and either agree or
disagree with recommendations.
• One of three decisions is possible:
– canceled if the problems prove not worth solving, or a new
system is not worth building
– approved to continue to the definition phase
– reduced in scope or increased in budget and schedule, and then
approved to continue to the definition phase

52
Methodology
 The Study Phase
 Impact Analysis
 Phase is rarely skipped because you almost always need some
understanding of the current system.
 Phase may be abbreviated because of:
• the project was triggered by a planned system initiative
• the project was triggered by a management directive

53
Methodology
 The Definition Phase
 Purpose:
 The purpose of requirements analysis is to identify the data,
process, interface, and geographic requirements for the users of
a new system.
• Specify these requirements without expressing computer
alternatives and technology details; at this point, keep analysis at
the business level.
 System users assigned to the team play an essential role in
specifying, clarifying, and documenting the business
requirements. It is, however, extremely important to involve
system users not on the team.

54
Methodology
 Prerequisites
 The definition phase is triggered by an approved statement of
system objectives.
 The team collects and discusses requirements and priorities
from the system users.

55
Methodology
 Activities
 The identification and validation of business requirements is the
principle activity in this phase.
• The most popular approach to documenting and validating users'
requirements is modeling.
– Modeling is the act of drawing one or more graphical
(meaning picture-oriented) representations of a system. The
resulting picture represents the users’ DATA, PROCESSING,
INTERFACE, or GEOGRAPHIC requirements from a
business point-of-view.

56
Methodology
 Activities
 The identification and validation of business requirements is the
principle activity in this phase. (continued)
• Another approach to documenting and validating requirements is
prototyping.
– Prototyping is the act of building a small-scale, representative
or working model of the users' requirements for purposes of
discovering or verifying those requirements.
 Another activity in the definition phase is to prioritize
requirements.
• Requirements can be classified as ‘mandatory’, ‘desirable’, or
‘optional’.

57
Methodology
 Deliverables
 The final models and prototypes are usually organized into a
business requirements statement.
 The requirements statement becomes the trigger for systems
design.

58
Methodology
 Although it is rare, the project could still be canceled at the end
of this phase.
 More realistically, the project scope (or schedule and budget)
could be adjusted if it becomes apparent that the new system's
requirements are much more substantive than originally
anticipated.

59
Methodology
 Today, it is popular to time box a project based on the business
requirements.
• Time boxing is a technique that divides the set of all business
requirements for a system into subsets, each of which will be
implemented as a version of the system. Essentially, the project
team guarantees that new versions will be implemented on a
regular and timely basis.
 If the project is not canceled, it proceeds to the targeting phase
and design phases.

60
Methodology
 Impact Analysis
 This phase is never skipped.
 The definition phase formally separates ``what'' from ``how'' to
properly define and prioritize those requirements.

61
Methodology
 The Targeting Phase
 Purpose:
 There are almost always multiple candidate solutions to any set
of business requirements.
 The purpose of the configuration phase is to identify candidate
solutions, analyze those candidate solutions, and recommend a
target system that will be designed and implemented.
 All members of the project team including system owners,
system users, and system designers must be involved in this key
decision-making phase.

62
Methodology
 Prerequisites
 The targeting phase is triggered by a reasonably complete
specification of business requirements.
 The project team also solicits ideas and opinions from all
classes system users.
 The project team also identifies or reviews any technology
standards via the technology-oriented system owners.

63
Methodology
 Activities
 The first activity is to define the candidate solutions.
• Some technical choices may be limited by a predefined approved
technology architecture provided by systems managers.
 After defining candidates, each candidate is evaluated by the
following criteria:
• Technical feasibility. Is the solution technically practical? Does
our staff have the technical expertise to design and build this
solution?
• Operational feasibility. Will the solution fulfill the user's
requirements? To what degree? How will the solution change the
user's work environment? How do users feel about such a
solution?

64
Methodology
 Activities
 After defining candidates, each candidate is evaluated by the
following criteria: (continued)
• Economic feasibility. Is the solution cost-effective (as defined
earlier in the chapter)?
• Schedule feasibility. Can the solution be designed and
implemented within an acceptable time period?
 The final activity is to recommend a feasible candidate as the
target system.

65
Methodology
 Deliverables
 The key deliverable of the targeting phase is a formal systems
proposal to systems owners.
• The system proposal must be presented, and usually negotiated,
with the system owners who will usually make the final business
and financial decisions.
• This proposal may be written or verbal.
 If it is decided to purchase some or all of the target system
(hardware or application software), the technology
requirements must be forwarded to the purchasing phase.
 The solution design requirements must be provided to the
design phase.

66
Methodology
 Several outcomes are possible from the this phase.
• System owners might choose any one of the following options:
– Approve and fund the systems proposal (possibly including an
increased budget and timetable if scope has significantly
expanded).
– Approve or fund one of the alternative system proposals.
– Reject all of the proposals and either cancel the project, or send
it back for new recommendations.
– Approve a reduced-scope version of the proposed system.
 Based on the decision, a purchasing phase may be triggered.
 Also, based on the decision, the design phase (possibly already
in progress) may be canceled or modified in scope or direction.

67
Methodology
 Impact Analysis
 This phase is not always required if the organization has an
application architecture.
• An application architecture defines an approved set of
technologies to be used when building any new information
system.

68
Methodology
 The Purchasing Phase
 Purpose:
 The purpose of the purchasing phase is to research the
information technology marketplace, solicit vendor proposals,
and to recommend (to management) that proposal which best
fulfills the business and technology requirements.

69
Methodology
 Other participants:
• Information technology vendors (who sell hardware and/or
software).
• Users (both those on the project team and those in the user
community) must be involved since they must ultimately “live”
with the system.
• System owners must be involved because these purchases usually
exceed the authorized spending limits of the average project team.
• In most businesses, purchasing agents and legal staff must be
involved in negotiations for any contracts and service agreements.

70
Methodology
 Prerequisites
 The key input to the phase is business requirements from the
definition phase, and the technology requirements from the
configuration phase.
 The project team should also be aware of and technology
standards imposed by systems management.

71
Methodology
 Activities
 The project team’s initial activity is to research the technology
and marketplace.
 The project team organizes the business, technology, and
relationship requirements, and establishes the mechanisms that
will be used to evaluate the technical alternatives.
• These requirements and mechanisms are communicated to the
vendors as a request for proposals.
 The vendors usually respond with formal proposals that may
also have to be clarified or negotiated.

72
Methodology
 Activities
 The project team must evaluate proposals and quotes to
determine (1) which ones meet requirements and specifications,
and (2) which one is the most cost effective.
 The analysts make a recommendation to the system owners
(and usually the information system managers as well).
 The authorized agents of the business execute the final orders,
contracts, licenses, and service agreements.

73
Methodology
 Deliverables
 The key deliverable of the purchasing phase is a technology
proposal to systems owners to acquire specific hardware
and/or software.
 If that proposal is approved, the a technology integration
requirements statement is passed on to the design phase.

74
Methodology
 The procurement phase is followed by the design phase unless
the purchased software fully meets the business and technology
requirements of the project.
 In the case where a purchased system fully meets requirements
(sometimes called a turn-key system because you just turn the
key to start the system), the project proceeds immediately to the
delivery phase.
 If the procurement phase results in a ‘no decision,’ the project
proceeds directly to the design phase to be designed and
constructed in-house as a custom solution.

75
Methodology
 Impact Analysis
 This phase is entirely optional based on the make-versus-buy
decision in the target phase.

76
Methodology
 The Design Phase
 Purpose:
 The purpose of the design phase is to transform the business
requirements from the definition phase into a set of technical
design blueprints for construction.
 FAST encourages an iterative ‘design-and-construct’ strategy.

77
Methodology
 Other important participants:
• Database specialists might design or approve the design of any
new or modified databases.
• Network specialists might design or modify the structure of any
computer networks.
• Microcomputer specialists may assist in the design of workstation-
based software components.
• Human interface specialists may assist in the design of the user
interface.
• System users must be involved – they evaluate the new system's
ease-of-learning, ease-of-use, and compatibility with the stated
business requirements.

78
Methodology
 Prerequisites
 The design phase has two triggers:
• The business requirements from the definition phase.
• The design requirements from the targeting phase.
 In those projects which will purchase hardware and/or software,
the design phase also receives:
• Technology integration requirements from the purchasing phase.
 System users provide various ideas and opinions into or about
the system’s design.

79
Methodology
 Activities
 FAST has ‘merged’ the design and construction phases to form a
rapid application development (or RAD) approach based on
iterative prototyping.
• This strategy designs and constructs the system as a series of
prototypes to which the system users react.
• The prototyping process is as follows:
– Step 1. - Define the base-level scope of the first (or next)
version of the system.
– Step 2. - Define, design, construct, and load the database.

80
Methodology
 Activities
• The prototyping process is as follows: (continued)
– Step 3. - Define, design, and construct the inputs. Demonstrate
this prototype to the system users.
(Repeat step 3 until the system users are satisfied. If necessary, return
to step 1 to add new requirements to the database design.)
– Step 4. - Define, design, and construct the outputs.
Demonstrate this prototype to the system users.
to step 1 to add new database requirements, or step 2 to add new input
requirements.)

81
Methodology
 Activities
– Step 5. - Define, design, and construct the interface.
Demonstrate this prototype to the system users.
to step 1, 2, or 3 to add new database, input, or output requirements,
respectively.)
– Step 6. - Design and construct any missing system controls
such as security, backup, recovery, etc.

82
Methodology
 Activities
– Step 7. - Implement this version of the system.
– Step 8. - Go to step 1 to begin the RAD cycle for the next
version of the system.

83
Methodology
 Deliverables
 The final deliverable is a technical set of design specifications.
• Design specifications can take several forms, but the most
common approach is modeling.
• General design models will depict:
– The structure of the database.
– The structure of the overall application.
– The overall ‘look and feel’ of the user interface.
– The structure of the computer network.
– The design structures for any complex software to be written.

84
Methodology
 At this point a project is rarely canceled.
 Each constructed prototype is refined or expanded by another
pass through system design until the final system is constructed.
 Impact Analysis
 This phase is mandatory.

85
Methodology
 The Construction Phase
 Purpose:
 The purpose of the construction phase is twofold:
• to build and test a functional system that fulfills business and
design requirements
• to implement the interfaces between the new system and existing
production systems

86
Methodology
 The analyst serves as a general contractor for work done by
technical specialists or subcontractors.
 System users’ responsibilities are usually limited to reacting to
the functional system’s ease-of-learning and ease-of-use.

87
Methodology
 Prerequisites
 The design specifications (general or detailed) are the key
input to the construction phase.
 Information technology vendors may provide installation
support for any packaged software or software development
tools.

88
Methodology
 Activities
 The database and networks provide the system’s infrastructure;
therefore, they must be constructed first (unless they already
exist).
 Any new software packages must be installed and tested.
 Any new programs must be constructed and tested.

89
Methodology
 Activities
 One of the most important aspects of application programming
is testing – both unit and system testing.
• Unit tests ensure that the applications programs work properly
when tested in isolation from other applications programs.
• System tests ensure that applications programs written in isolation
work properly when they are integrated into the total system.

90
Methodology
 Deliverables
 The final deliverable of the construction phase is the functional
system.
 The rapid application development strategy of FAST results in
several interim deliverables called prototypes.

91
Methodology
 Postrequisites, Feasibility Checkpoints, and Impact Analysis
 At this point a project is rarely canceled.
 This phase is optional.
 It is possible that a prototype might be implemented as a first
(next) version before the system has been fully constructed.

92
Methodology
 The Delivery Phase
 Purpose:
 The purpose of the delivery phase is to install, deploy, and
place the new system into operation or production.
 The systems analyst is the most visible player as they
communicate implementation problems and issues between
system users, system designers, and system builders.
 The entire project team is active in this phase.
 System owners and users step to the forefront as cheerleaders
for the new system.

93
Methodology
 Prerequisites
 The key input to the delivery phase is the functional system.
 System users provide continuous feedback as new problems
and issues are common (note: no system has achieved the
nirvana goal of ‘perfection’).
 For new information technology (hardware and software), the
information technology vendors provide necessary technical
support.

94
Methodology
 Activities
 The training of system users.
 The writing of various manuals.
 The loading of files and databases.
 Deliverables
 The final deliverable of the delivery phase (and the project) is
the production system for the system users.
 Another output of the delivery phase is training and support.

95
Methodology
 Postrequisites, Feasibility Checkpoints, and Impact Analysis
 The project is complete! There is no further feasibility analysis.
 There may be a project post-audit to evaluate the system,
methodology, and team.

96
Methodology
 Beyond Systems Development - Systems Support
 Once the system is placed into production, the analyst's role
changes to systems support.
 System support is the ongoing maintenance of a system after it
has been placed into operation. This includes program
maintenance and system improvements.
 Systems support doesn't consist of phases so much as it does
ongoing activities. These activities include:
• Fixing software ‘bugs’.
• Recovering the system.
• Assisting users.
• Adapting the system to new requirements.

97
Cross Life Cycle Activities
 Cross Life Cycle Activities
 Cross life cycle activities are activities that overlap many or all
phases of the methodology – in fact, they are normally performed
in conjunction with several phases of the methodology.
 Cross life cycle activities include:
 fact finding
 documentation and presentation
 estimation and measurement
 feasibility analysis
 project management
 process management.

98
ID Task Name
1 Survey Phase
2 Study Phase
3 Def inition Phase
4 Targeting Phase
5 Design Phase
6 Purchasing Phase
7 Construction Phase
8 Implementation Phase
9
10 Fact Finding
11 Documentation
12 Presentation
13 Estimation
14 Measurement
15 Feasibility Analysis
16 Project management
17 Process management
18
19
20
21
22
23
24
25
26
12/31 1/7 1/14 1/21 1/28 2/4 2/11 2/18 2/25 3/3 3/10 3/17 3/24 3/31 4/7 4/14 4/21 4/28 5/5 5/12 5/19
January February March April May

99
 Fact Finding
 Fact finding – also called information gathering or data collection
-- is the formal process of using research, interviews, meetings,
questionnaires, sampling, and other techniques to collect
information about systems, requirements, and preferences.

100
 Documentation and Presentations
 Communication skills are essential to the successful completion of
a project.
 Two forms of communication that are common to systems
development projects are documentation and presentation.
 Documentation is the activity of recording facts and
specifications for a system.
 Presentation is the related activity of formally packaging
documentation for review by interested users and managers.
Presentations may be either written or verbal.

101
 Documentation and Presentations
 Version control over documentation has become a critical success
factor; it involves keeping and tracking multiple versions of a
system's documentation.
 Most information systems shops want to keep documentation
for all of the following versions:
• One or more previous versions of the system.
• The current production version of the system.
• Any version of the system going through the build and test activity.
• Any version going through the life cycle to create a new version.

102
1
The
Survey
Phase
2
The
Study
Phase
3
The
Definition
Phase
4
The
Targeting
Phase
5
The
Design
Phase
7
The
Construction
Phase
6
The
Purchasing
Phase
8
The
Implementa-
tion
Phase
Program
Library
Database
Repository
project
and
system
scope
system
objectives
business
requirements
design and
technology
requirements
design
specifications
technology
integration
requirements
functional
system
specifications
production
system
specifications
purchased
software
prototypes
and
functional
software
production
software
test
data
actual business data

103
 Estimation and Measurement
 Information systems are significant capital investments. For this
reason, estimation and measurement activities are commonly
performed to address the quality and productivity of systems.
 Estimation is the activity of approximating the time, effort,
costs, and benefits of developing systems. The term
guesstimation (as in ``make a guess'') is used to describe the
same activity in the absence of reliable data.
 Measurement is the activity of measuring and analyzing
developer productivity and quality (and sometimes costs).

104
 There are two common approaches to estimation.
 First, some analysts avoid estimation out of fear, uncertainty,
or lack of confidence.
• The analyst may resort to what are jokingly called ``guesstimates.''
 Better analysts draw on experience and data (both their own
and the collective experience of others) from previous projects
to continually improve their estimates.

105
 Measurement has become important because of the productivity
and quality problems that plague systems development.
 The field of software and systems metrics offers hope for the
future.
• Software and systems metrics provides an encyclopedia of
techniques and tools that can both simplify the estimation process
and provide a statistical database of estimates versus performance.

106
 Feasibility Analysis
 A system development life cycle that supports our creeping
commitment approach to systems development recognizes
feasibility analysis as a cross life cycle activity.
 Feasibility is a measure of how beneficial the development of
an information system would be to an organization.
 Feasibility analysis is the activity by which feasibility is
measured.

107
 Project Management and Process Management
 Systems development projects may involve a team of analysts,
programmers, users, and other IS professionals who work together.
 Project management is the ongoing activity by which an
analyst plans, delegates, directs, and controls progress to
develop an acceptable system within the allotted time and
budget.
 Most project development failures are attributed to poor leadership
and management.
 This mismanagement results in unfulfilled or unidentified
requirements, cost overruns, and late delivery.

108
 Project Management and Process Management
 The systems development life cycle provides the basic framework
for the management of systems projects.
 Process management’s intent is to standardize both the way we
approach projects, and the deliverables we produce during projects.
 Process management is an ongoing activity that establishes
standards for activities, methods, tools, and deliverables of the
life cycle.

109
Computer-Aided Systems Engineering
(CASE)
 What is Computer-Aided Systems Engineering?
 Computer-aided systems engineering (CASE) is the application
of information technology to systems development activities,
techniques, and methodologies. CASE tools are programs
(software) that automate or support one or more phases of a
systems development life cycle. The technology is intended to
accelerate the process of developing systems and to improve the
quality of the resulting systems.
 CASE is not a methodology or an alternative to methodologies.
 CASE is an enabling technology that supports a methodology’s
preferred strategies, techniques, and deliverables.

110
(CASE)
 The History and Evolution of CASE Technology
 The true history of CASE dates back to the early- to mid-1970s.
 The ISDOS project used a language called Problem Statement
Language (PSL) for describing user problems and solution
requirements for an information system into a computerized
dictionary.
 A companion product called Problem Statement Analyzer
(PSA) was created to analyze those problems and requirements
for completeness and consistency.
 PSL/PSA ran on large mainframe computers.
 CASE success started with the advent of the personal computer.
 In 1984, Index Technology (now known as Intersolv) created a
PC software tool called Excelerator.

111
(CASE)
 A CASE Tool Framework
 CASE tools are classified according to which phases of the life
cycle they support.
 The term upper-CASE describes tools that automate or
support the ‘upper’ or earliest phases of systems development –
the survey, study, definition, and design phases.
 The term lower-CASE describes tools that automate or support
the ‘lower’ or later phases of systems development – detailed
design, construction, and implementation (and also support).

112
(CASE)
 CASE Tool Architecture
 At the center of any true CASE tool’s architecture is a database
called a repository (or a link into such a repository).
 Around the repository is a collection of tools or facilities to create
documentation or other system components.
 The real power of a ‘true’ CASE tool is derived from its repository
(or its ability to use and update some other tool’s repository).
 A CASE repository is a developers’ database. It is a place
where the developers can store diagrams, descriptions,
specifications, and other by-products of systems development.
Synonyms include dictionary and encyclopedia.
 Many different CASE tools can share information across a
single repository.

113

114
CENTRAL
REPOSITORY
Local
Repository
(on a LAN
Server)
Security and
Version
Control
Tools
Inquiry and
Reporting
Tools
Data
Sharing
Tools
House-
keeping
Tools
Graphics
Tools
Decision
Support
Tools
Quality
Management
Tools
Design
Generators
Code
Generators
Document
Tools
INPUTS:
models,
descriptions
and
prototypes
OUTPUTS:
reports,
problems,
and
analyses
imported
and
exported
knowledge
check-out/
check in
knowledge
Repository
Server
CASE Tool
Facilities
(on a workstation)
Description
Tools
Prototyping
Tools
links links

115
(CASE)
 CASE tools provide some of the following facilities:
 Diagramming tools are used to draw the system models
required or recommended in most methodologies.
 Description tools are used to record, delete, edit, and output
non-graphical documentation and specifications.
 Prototyping tools are used construct system components
including inputs, outputs, and programs.
 Inquiry and reporting tools are used to extract models,
descriptions, and specifications from the repository.
 Quality management tools analyze models, descriptions, and
prototypes for consistency, completeness, or conformance to
accepted ‘rules’ of the methodologies that the CASE tools
support.

116
(CASE)
 CASE tools provide some of the following facilities: (continued)
 Decision support tools provide information for various
decisions that occur during systems development.
 Documentation organization tools are used to assemble,
organize, and report repository information that can be
reviewed by system owners, users, designers, and builders.
 Design generation tools automatically generate first-draft
designs for various system components based on the business
requirements recorded in the repository, and technology
standards provided by the system designer.
 Code generator tools automatically generate application
programs, or significant portions of those programs.

117
(CASE)
 CASE tools provide some of the following facilities: (continued)
 Testing tools help the system designers and builders test
databases and application programs.
 Data sharing tools provide for import and export of repository
information to and from other software tools that cannot
directly access the repository.
 Version control tools maintain the integrity of the repository
by preventing unauthorized or inadvertent changes, and saving
prior versions of various information stored in the repository.
 Housekeeping tools establish user accounts, privileges,
repository subsets, tool defaults, backup and recovery, and
other essential facilities.

118
(CASE)
 The Benefits of CASE
 Some of the most commonly cited benefits include:
 improved productivity (through automation of tasks and rapid
application development)
 improved quality (because CASE tools check for completeness,
consistency, and contradictions)
 better documentation (mostly because the tools make it easier
to create and assemble consistent, high quality documentation)
 reduced lifetime maintenance (because of the aforementioned
system quality improvements combined with better
documentation)
 methodologies that really work (through rule enforcement and
built in expertise)

119
(CASE)
 The Benefits of CASE
 Many information systems organizations provide CASE training
and support through a development center.
 A development center is a central group of information
systems professionals who plan, implement, and support a
systems development environment for other developers. They
provide training and support for both the methodology and
CASE tools.

120
Summary
 Introduction
 System Development Life Cycles and
Methodologies
 Underlying Principles of Systems Development
 FAST –A System Development Methodology
 Cross Life Cycle Activities
 Computer-Aided Systems Engineering (CASE)

RTI System devolopment.ppt

More Related Content

Similar to RTI System devolopment.ppt (20)

Recently uploaded (20)

RTI System devolopment.ppt