week 2 chapter 3 systems development power point

8/10/2019 Week 2 Chapter 3 Systems Development Power Point

1/120

Copyright Irwin/McGraw-Hill 19981

Information System Development

Prepared by Kevin C. itt!an "or$te!$ %naly$i$ & e$ign Method$ 'ed

by (. ). *hitten & ). . +entley

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 eachphase or activity, what is its purpose, participants, prerequisites,

deliverables, activities, postrequisites, and impact?


2/120

Copyright Irwin/McGraw-Hill 1998,




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 computeraided systems engineering!"#$%& and describe the role of "#$% tools in system

development?


3/120





System Development Life Cyclesand Methodologies

The process used to develop information systems is

called a methodology. #ll methodologies are derived from a logical system problem

solving process that is sometimes called asystem development lifecycle'

# system development life cycle (SDLC)is a logical process

by which systems analysts, software engineers, programmers,

and endusers build information systems and computer

applications to solve business problems and needs' (t issometimes called an application development life cycle'


4/120

Copyright Irwin/McGraw-Hill 1998'





hat isa !ethodology" # methodologyis the physical implementation of the logical life

cycle that incorporates !)& stepbystep activities for each phase,

!*& individual and group roles to be played in each activity, !+&deliverables and quality standards for each activity, and !& tools

and techniques to be used for each activity'

# true methodology should encompass the entire system-s

development life cycle'

.ost modern methodologies incorporate the use of severaldevelopment tools and techniques'


5/120






hy Do Companies use !ethodologies" .ethodologies ensure that a consistent, reproducible approach is

applied to all projects'

.ethodologies reduce the risk associated with shortcuts andmistakes'

.ethodologies produce complete and consistent documentation

from one project to the ne/t'


6/120





Underlying Principles of SystemsDevelopment

#rinciple $: %et the &wners and 'sers nvolved 0wner and user involvement is an absolute necessity for

successful systems development'

1he individuals responsible for systems development must maketime for owners and users, insist on their participation, and seek

agreement from them on all decisions that may affect them'

.ethodologies reduce the risk associated with shortcuts and

mistakes'

.ethodologies produce complete and consistent documentationfrom one project to the ne/t'


7/120Copyright Irwin/McGraw-Hill 19980





#rinciple : 'se a #ro*lem+Solving ,pproach # methodology is, first and foremost, a problemsolving approach

to building systems'

1he classical problemsolving approach is as follows2 $tudy and understand the problem !opportunity, and3or

directive& and its system conte/t'

4efine the requirements of a suitable solution'

(dentify candidate solutions and select the 55best66 solution'

4esign and3or implement the solution'

0bserve and evaluate the solution6s impact, and refine the

solution accordingly'







#rinciple : 'se a #ro*lem+Solving ,pproach 1here is tendency among ine/perienced problem solvers to

eliminate or abbreviate one or more of the problem solving steps'

1he result can be range from2 solving the wrong problem

incorrectly solving the problem

picking the wrong solution







#rinciple -: sta*lish #hases and ,ctivities .ost life cycles and methodologies consist of phases'

(n its simplest, classical form, the life cycle consists of four

phases2 systems survey

systems analysis

systems design

systems implementation

# 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/120



11





#rinciple -: sta*lish #hases and ,ctivities 7hases are usually broken down into activities and tasks that can

be more easily managed and accomplished'

1he phases of a project should be completed toptobottom, insequence'



1,





#rinciple /: sta*lish Standards for Consistent

Development and Documentation $ystems development standards usually describe2

activities responsibilities

documentation guidelines or requirements

quality checks

1he need for documentation standards underscores a common

failure of many analysts the failure to document as an ongoing

activity during the life cycle'



1





#rinciple 0: 1ustify Systems as Capital nvestments (nformation systems are capital investments'

When considering a capital investment, two issues must be

addressed2 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'8 Cost+effectivenessis 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'

"ostbenefit analysis is an important skill to be mastered'



1'





#rinciple 2: Don3t 4e ,fraid to Cancel or 5evise Scope # significant advantage of the phased approach to systems

development is that it provides several opportunities to reevaluate

feasibility'

(n the long run, canceled projects are less costly than implemented

disasters9

.ost analysts fail to adjust estimated costs and schedules as scope

increases' #s a result, the analyst frequently and needlessly accepts

responsibility for cost and schedule overruns'



1





#rinciple 2: Don3t 4e ,fraid to Cancel or 5evise Scope 1he creeping commitment approach2

.ultiple feasibility checkpoints are built into the systems

development methodology' #t any feasibility checkpoint, all costs are considered sunk

!meaning irrecoverable& and irrelevant to the decision'

1he project should be reevaluated at each checkpoint to

determine if it is still feasible'

#t each checkpoint, the analyst should consider28 cancellation of the project if it is no longer feasible

8 reevaluation of costs and schedule if project scope is to be

increased

8 reduction of scope if the project budget and schedule are frozen,

but not sufficient to cover all project objectives'



1





#rinciple 6: Divide and Conquer #ll systems are part of larger systems !called supersystems&'

:irtually all systems contain smaller systems !called subsystems&'

We divide a system into its subsystems in order to more easilyconquer the problem and build the larger system'

;y dividing a larger problem !system& into more easily

managed pieces !subsystems&, the analyst can simplify the

problemsolving process'


17/120






#rinciple 7: Design Systems for %rowth and Change .any systems analysts have fallen into the trap of developing

systems to meet only today6s user requirements'

ntropyis the term system scientists use to describe the naturaland inevitable decay of all systems'

4uring the support phase, the cost of maintenance e/ceeds the

costs of starting over the system has become obsolete'


18/120





Systems

$lannng

Systems

Analyss

Systems

Desgn

Systems

Im#lementaton

Systems

Su##ort

Obsolete System

Ne7


19/120






#rinciple 7: Design Systems for %rowth and Change $ystems that are designed to meet only current requirements are

difficult to modify in response to new requirements'

.any systems analysts become frustrated with how much timemust be dedicated to supporting e/isting systems !often called

legacy systems&, and how little time is left to work on important,

newsystems development'

1oday6s tools and techniques make it possible to design systems

that can grow and change as requirements grow and change' Fle/ibility and adaptability do not happen by accident they must

be built into a system'


20/120






%et the owners and users involved

'se a pro*lem+solving approach

sta*lish phases and activities

sta*lish standards for consistent

development and documentation

1ustify systems as capital investments

Don3t *e afraid to cancel

Divide and conquer

Design systems for growth and change


21/120

Copyright Irwin/McGraw-Hill 1998,1




FAST A System DevelopmentMethodology

8ow a FAST #ro9ect %ets Started When system owners, system users, or systems analysts initiate a

project,FASTcalls this a unplanned system request.


22/120

Copyright Irwin/McGraw-Hill 1998,,





8ow a FAST #ro9ect %ets Started 1he opposite of an unplanned system request is a planned system

initiative'

# planned system initiative is the result of one of the followingearlier projects2

8 an information strategy planthat has e/amined 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'

8 a *usiness process redesignthat has thoroughly analyzed a series

of fundamental business processes to eliminate redundancy and

bureaucracy, and to improve efficiency and valueadded now it

is time to redesign the supporting information systems for those

business processes'


23/120


24/120

Copyright Irwin/McGraw-Hill 1998,'





8ow a FAST #ro9ect %ets Started #CS a useful framework for classifying problems,

opportunities, and directives'

(t is called#CSbecause each of the letters represent one ofsi/ categories'

#+the need to improveperformance'

+the need to improve information!and data&'

+ the need to improve economics, control costs, or increase

profits'C + the need to improve controlor security'

+ the need to improve efficiencyof people and processes

S + the need to improveserviceto customers, suppliers, partners,

employees, etc'


25/120






The #CS #ro*lem+Solving ;ramewor

1he following checklist for problem, opportunity, and directive identification uses Wetherbe6s 7(%"%$

framework' =ote that the categories of 7(%"%$ are not mutually e/clusive> some possible problems show

up in multiple lists' #lso, the list of possible problems is not e/haustive' 1he 7(%"%$ framework is

equally suited to analyzing both manual and computerized systems and applications'

#5;&5!,


26/120








27/120







C&


28/120







C&


29/120







S5?C #ro*lems= &pportunities= and Directives

,. 1he system produces inaccurate results

4. 1he system produces inconsistent results

C. 1he system produces unreliable results

D. 1he system is not easy to learn

. 1he system is not easy to use;. 1he system is awkward to use

%. 1he system is infle/ible to new or e/ceptional situations

8. 1he system is infle/ible to change

. 1he system is incompatible with other systems

1. 1he system is not coordinated with other systems


30/120






,n &verview of the FAST Life Cycle and !ethodology 1he final output of the methodology is the production system!so

named because the system Bproduces results-&'

#s you develop a system, you need a place to store various byproducts such as documentation, production data, and software'

1he three data stores are described as follows2

the repositoryis a place where systems analysts and other

developers store documentation about the system' %/amples of

such documentation might include written memos, userrequirements, andprogram flowcharts'


31/120






,n &verview of the FAST Life Cycle and !ethodology 1he three data stores are described as follows2 !continued&

the data*aseis built during the project to store actual business

data about such things as "


32/120





REASON:

A

SystemDe2elo#ment

Metho*ology

System

0sers

System

O(ners

$ro*ucton

System

Database

$rogram

/braryRe#ostory

STARTSTART

System

Kno(le*ge

an*

Documentaton

Database

Structures

an* actual!usness Data

A##lcaton

$rograms

FINISH

$lanne*

System

Intat2e

0n#lanne*

System

Request

OR


33/120



Prepared by Kevin C. itt!an "or$te!$ %naly$i$ & e$ign Method$ 'edby (. ). *hitten & ). . +entley


,n &verview of the FAST Life Cycle and !ethodology 1he symbology used in FASTis as follows2

1he rounded rectangles representphasesin aFAST system

development project' 1he thick green arrowsrepresent the information flows that

trigger !or start& aFASTproject'

1he thick *lac arrowsrepresent the major deliverables !or

outputs& of the phases' %ach deliverable contains important

documentation and3or specifications' =otice that thedeliverable of one phase may serve as input to another phase'


34/120





,n &verview of the FAST Life Cycle and !ethodology 1he symbology used in FASTis as follows2 !continued&

1he thin black, doubled-ended arrowsrepresent other

secondary information and communication flows' 1hese flowscan take the form of conversations, meetings, letters, memos,

reports, and the like'

1he people silhouettes indicate people or organizations with

whom the analyst may interact'

Finally, consistent with our creeping commitment principle, theblack circlesindicate checkpoints at which time the project

participants should reevaluate feasibility and3or project scope'


35/120




>

Sur2ey

$hase

C

Stu*y

$hase

B

De&nton

$hase

Targetng

$hase

G

Desgn

$hase

H

%onstructon

$hase

$urchasng

$hase

)& necessary,

Del2ery

$hase

System

0sers

System

O(ners

In&ormaton

Technology

:en*ors

0n#lanne* System $roblem

$lanne*

System$ro"ect

$ro"ect an*

System Sco#e

System

Ob"ect2es

!usnessRequrements

Technology

Requrements

Desgn

Requrements

Technology

IntegratonRequrements

Desgn

S#ec&catons

$rototy#es

O#eratonal

System

!usness Requrements

!usness

Requrements

Request

&or

$ro#osals

$ro#osals

$ro*ucton System


36/120





,n &verview of the FAST Life Cycle and !ethodology 1he FASTmethodology consists of eight phases' 1hey are as

follows2

1he Survey haseestablishes the project conte/t, scope,budget, staffing, and schedule'

1he Study haseidentifies and analyzes both the business and

technical problem domains for specific problems, causes, and

effects'

1he!efinition haseidentifies and analyzes businessrequirements that should apply to any possible technical

solution to the problems'


37/120






follows2 !continued&

1he Targeting haseidentifies and analyzes candidatetechnical solutions that might solve the problem and fulfill the

business requirements' 1he result is a feasible, targetsolution'

1heurchasing hase!optional& identifies and analyzes

hardware and software products that will be purchased as part

of the target solution'

1he!esign hasespecifies the technical requirements for the

target solution' 1oday, the design phase typically has significant

overlap with the construction phase'


38/120






follows2 !continued&

1he "onstruction hasebuilds and tests the actual solution !orinterim prototypes of the solution&'

1he!elivery haseputs the solution into daily production'


39/120




>

Sur2ey an*

#lan the#ro"ect

C

Stu*y an*

analy8e the

e'stng

system

B

De&ne

an* #rort8e

the busness

requrements

Target a

&easble

system

soluton

G

Desgn an*

ntegrate

the

target

system

H

%onstruct

an* test

the target

system

$urchase

any ne(

har*(are an*

so&t(are

Install an*

m#lementthe

#ro*ucton

system

System

0sers

System

O(ners

In&ormaton

Technology

:en*ors

training, support, and feedback

demonstrations

and

feedback

ideas

and

opinions

ideas

andopinions

requirements

and

rriorities

the business,

problems,

causes, and

effects

0n#lanne* System Request

$lanne*

System

$ro"ect

$ro"ect an*

System Sco#e

SystemOb"ect2es

!usness

Requrements

Technology

Requrements

Desgn

Requrements

Technology

Integraton

Requrements

Desgn

S#ec&catons

$rototy#es

Functonal

System

technology standards

technology

standards

system

proposal

problem statement

and

feasibility analysis

!usness Requrements

!usness

Requrements

Request

&or

$ro#osals

$ro#osals

technical

support

installation

support

consulting

services

$ro*ucton System

executive

leadership

Feasblty

Assessment

an*$ro"ect

$lan

technical

leadership

scope

technology proposal


40/120

f i


41/120

Copyright Irwin/McGraw-Hill 1998'1




The Survey #hase 7urpose2

1he purpose of the survey phase is threefold'

8 1he survey phase answers the question, C(s this project worthlooking at?D

8 1he survey phase must define the scope of the project and the

perceived problems, opportunities, and directives that triggered the

project'

8 1he survey phase must establish the project team and participants,

the project budget, and the project schedule'

f i l


42/120

Copyright Irwin/McGraw-Hill 1998',




The Survey #hase 7articipants and oles

1he facilitator of this phase is the systems analyst'

1his phase describes the system and project from theperspective of system owners'

%/ample system owner roles2

8 #$ecutive sponsor the highestlevel manager who will pay for

the project'

8 Technical sponsor the highestlevel manager from (nformation$ervices organization who will pay for the project'

8 7roject manager!s& the manager!s& of the project team' 1his

person is responsible for the staffing, budget, and schedule'

f i S l


43/120





The Survey #hase 7rerequisites

1he key input to the phase is either the unplanned system

requestor the planned system initiative'

#ctivities

1he most important activity in the survey phase is to define the

scope or size of the project'

0nce scope has been defined, we need to answer that question

C(s this project worth looking at?D #ssuming the system is worth looking at, the project manager

should formally plan the project' 1his includes establishing a

preliminary budget and schedule, and staffing the development

team'

If ti S t D l t


44/120

Copyright Irwin/McGraw-Hill 1998''




The Survey #hase 4eliverables

# key deliverable for the survey phase is aproject charterthat

presents the findings, recommendations, and plans of the team

to the e/ecutive sponsors'

8 1his might be a report or verbal presentation> possibly both'

1he report version is sometimes called an initial study report'

8 1he analyst6s recommendation may prescribe2

a 55quick fi/,66

an enhancement of the e/isting system and software

a completely new information system'

8 For the latter possibility, a statement of pro9ect scope and

o*9ectivesis delivered to the study phase'

If ti S t D l t


45/120





The Survey #hase 7ostrequisites and Feasibility "heckpoints

# circle at the beginning of any information flow indicates that

the flow Bmay or may not occur- based on our creeping

commitment principle'

"ircles define feasibility checkpoints inFAST'

1he definition of project and system scope will only occur if

the project has been approved to continue to the ne/t phase'

If ti S t D l t


46/120






The Survey #hase 7ostrequisites and Feasibility "heckpoints !continued&

1he feasi*ility assessment and pro9ect planwill be reviewed

by the system owners !or asteering committeethat includes

system owners&'

8 0ne of four decisions is possible2

approve the project to continue to thestudy phase

change the scope and continue on to thestudy phase

reject the project outright

delay the project in favor of some other project

If ti S t D l t


47/120






The Survey #hase (mpact #nalysis

$cope definition is critical to all projects, planned and

unplanned, but it could be deferred until thestudy phasefor

those projects that have already been determined to be worth

looking at'

If ti S t D l t


48/120






The Study #hase 7urpose2

1he purpose of the study phase is threefold'

81he project team must gain an appropriate understanding of thebusiness problem domain'

8 We need to answer the question, C#re these problems

!opportunities, and directives& worth solvingD?

8 We need to determine if the system is worth developing'

7articipants and oles


1his phase describes the system and project from the

perspective of system users'

If ti S t D l t


49/120






The Study #hase 7rerequisites

1he key input to the phase is the statement of pro9ect and

system scopefrom thesurvey phase.

1he project team studies the e/isting system by collecting

factual information from the system users concerning the

businessand the perceivedproblems, causes, and effects.

#ctivities

@earning the system terminology, history, culture, and nuancesis the principle activity in this phase'

4uring the study phase, we need to address the causes and

effects of the problems, opportunities, and directives' 7(%"%$

can serve as a useful framework for doing this'

If ti S t D l t


50/120






The Study #hase 4eliverables

1he findings of the study phase are reviewed with the system

owners as a businessproblem statement and feasibility

analysis!sometimes called a detailed study report&'

8 1he problem statement may take the form of a formal written

report, an updated feasibility assessment, or a formal presentation

to management and users'

8 1he problem statement should include system o*9ectives.1hese

objectives define the business criteria on which any new systemwill be evaluated'

InformationSystem Development


51/120






The Study #hase 7ostrequisites and Feasibility "heckpoints

1he system owners will review findings and either agree or

disagree with recommendations'

8 0ne of three decisions is possible2

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/120






The Study #hase (mpact #nalysis

7hase is rarely skipped because you almost always need some

understanding of the current system'

7hase may be abbreviated because of2

8 the project was triggered by aplanned system initiative

8 the project was triggered by a management directive



53/120






The Definition #hase 7urpose2

1he purpose of requirements analysis is to identify the data,

process, interface, and geographic requirements for the users of

a new system'

8 $pecify these requirements without e/pressing computer

alternatives and technology details> at this point, keep analysis at

the business level'



$ystem users assigned to the team play an essential role in

specifying, clarifying, and documenting the business

requirements' (t is, however, e/tremely important to involve

system users not on the team'



54/120






The Definition #hase 7rerequisites

1he definition phase is triggered by an approved statement of

system o*9ectives'

1he team collects and discusses requirements and priorities

from the system users'



55/120






The Definition #hase #ctivities

1he identification and validation of business requirements is

the principle activity in this phase'

8 1he most popular approach to documenting and validating users6

requirements is modeling'

!odelingis the act of drawing one or more graphical

!meaningpicture-oriented& representations of a system' 1he

resulting picture represents the users- 4#1#, 70"%$$(=E,

(=1%F#"%, or E%0E#7(" requirements from abusiness pointofview'



56/120






The Definition #hase #ctivities

1he identification and validation of business requirements is

the principle activity in this phase' !continued&

8 #nother approach to documenting and validating requirements is

prototyping'

#rototypingis the act of building a smallscale, representative

or working model of the users6 requirements for purposes of

discovering or verifying those requirements'

#nother activity in the definition phase is to prioritizerequirements'

8 equirements can be classified as Bmandatory-, Bdesirable-, or

Boptional-'



57/120






The Definition #hase 4eliverables

1he final models and prototypes are usually organized into a

*usiness requirementsstatement'

1he requirements statement becomes the trigger for systems

design'



58/120






The Definition #hase 7ostrequisites and Feasibility "heckpoints

#lthough it is rare, the project could still be canceled at the end

of this phase'

.ore realistically, the project scope !or schedule and budget&

could be adjusted if it becomes apparent that the new system6s

requirements are much more substantive than originally

anticipated'



59/120



Prepared by Kevin C. itt!an "or

$te!$ %naly$i$ & e$ign Method$ 'edby (. ). *hitten & ). . +entley


The Definition #hase 7ostrequisites and Feasibility "heckpoints

1oday, it is popular to time bo$a project based on the business

requirements'

8 Time *o@ingis 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' %ssentially, the project

team guarantees that new versions will be implemented on a

regular and timely basis'

(f the project is not canceled, it proceeds to the targeting phaseand designphases'



60/120






The Definition #hase (mpact #nalysis

1his phase is never skipped'

1he definition phase formally separates 55what66 from 55how66 toproperly define and prioritize those requirements'



61/120






The Targeting #hase 7urpose2

1here are almost always multiple candidate solutions to any set

of business requirements'

1he 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'


1he facilitator of this phase is the systems analyst' #ll members of the project team including system owners,

system users, and system designers must be involved in this

key decisionmaking phase'



62/120






The Targeting #hase 7rerequisites

1he targeting phase is triggered by a reasonably complete

specification of *usiness requirements'

1he project team also solicits ideas and opinionsfrom all

classes system users'

1he project team also identifies or reviews any technology

standardsvia the technologyoriented system owners'



63/120






The Targeting #hase #ctivities

1he first activity is to define the candidate solutions'

8 $ome technical choices may be limited by a predefined approved

technology architecture provided by systems managers'

#fter defining candidates, each candidate is evaluated by the

following criteria2

8 Technical feasi*ility' (s the solution technically practical? 4oes

our staff have the technical e/pertise to design and build this

solution?

8 &perational feasi*ility' Will the solution fulfill the user6s

requirements? 1o what degree? ow will the solution change the

user6s work environment? ow do users feel about such a

solution?



64/120






The Targeting #hase #ctivities

#fter defining candidates, each candidate is evaluated by the

following criteria2 !continued&

8 conomic feasi*ility' (s the solution costeffective !as defined

earlier in the chapter&?

8 Schedule feasi*ility' "an the solution be designed and

implemented within an acceptable time period?

1he final activity is to recommend a feasible candidate as the

target system'


65/120



66/120






The Targeting #hase 7ostrequisites and Feasibility "heckpoints

$everal outcomes are possible from the this phase'

8 $ystem owners might choose any one of the following options2

#pprove and fund the systems proposal !possibly including an

increased budget and timetable if scope has significantly

e/panded&'

#pprove or fund one of the alternative system proposals'

eject all of the proposals and either cancel the project, or

send it back for new recommendations'

#pprove a reducedscope version of the proposed system'

;ased on the decision, apurchasing phasemay be triggered'

#lso, based on the decision, the design phase !possibly already

in progress& may be canceled or modified in scope or direction'



67/120






The Targeting #hase (mpact #nalysis

1his phase is not always required if the organization has an

application architecture'

8 #n application architecturedefines an approved set of

technologies to be used when building any new information

system'



68/120






The #urchasing #hase 7urpose2

1he 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/120






The #urchasing #hase 7articipants and oles


0ther participants28 (nformation technology vendors !who sell hardware and3orsoftware&'

8


70/120






The #urchasing #hase 7rerequisites

1he key input to the phase is business requirementsfrom the

definition phase, and the technology requirementsfrom the

configuration phase'

1he project team should also be aware of and technology

standardsimposed by systems management'



71/120






The #urchasing #hase #ctivities

1he project team-s initial activity is to research the technology

and marketplace'

1he project team organizes the business, technology, and

relationship requirements, and establishes the mechanisms that

will be used to evaluate the technical alternatives'

8 1hese requirements and mechanisms are communicated to the

vendors as a request for proposals'

1he vendors usually respond with formal proposalsthat may

also have to be clarified or negotiated'



72/120


y p




The #urchasing #hase #ctivities

1he project team must evaluate proposals and quotes to

determine !)& which ones meet requirements and

specifications, and !*& which one is the mostcost effective'

1he analysts make a recommendation to the system owners

!and usually the information system managers as well&'

1he authorized agents of the business e/ecute the final orders,

contracts, licenses, and service agreements'



73/120


y p




The #urchasing #hase 4eliverables

1he key deliverable of the purchasing phase is a technology

proposal to systems owners to acquire specific hardware

and3or software'

(f that proposal is approved, the a technology integration

requirementsstatement is passed on to the design phase'



74/120


y p




The #urchasing #hase 7ostrequisites and Feasibility "heckpoints

1he procurement phase is followed by the design phaseunless

the purchased software fully meets the business and technology

requirements of the project'

(n the case where a purchased system fully meets requirements

!sometimes called a turn-key systembecause you just turn the

key to start the system&, the project proceeds immediately to

the deliveryphase'

(f the procurement phase results in a Bno decision,- the project

proceeds directly to the design phase to be designed and

constructed inhouse as a custom solution'



75/120


y p




The #urchasing #hase (mpact #nalysis

1his phase is entirely optional based on the makeversusbuy

decision in the target phase'



76/120


y p




The Design #hase 7urpose2

1he purpose of the design phase is to transform the business

requirements from the definition phaseinto a set of technical

design blueprints for construction'

FASTencourages an iterative Bdesignandconstruct- strategy'



77/120


y p




The Design #hase 7articipants and oles


0ther important participants2

8 4atabase specialists might design or approve the design of any

new or modified databases'

8 =etwork specialists might design or modify the structure of any

computer networks'

8 .icrocomputer specialists may assist in the design of workstation

based software components'

8 uman interface specialists may assist in the design of the user

interface'

8 $ystem users must be involved they evaluate the new system6s

easeoflearning, easeofuse, and compatibility with the stated

business requirements'



78/120


y p




The Design #hase 7rerequisites

1he design phase has two triggers2

8 1he *usiness requirementsfrom the definition phase'

8 1he design requirementsfrom the targeting phase'

(n those projects which will purchase hardware and3or

software, the design phase also receives2

8 Technology integration requirementsfrom the purchasing phase'

$ystem users provide various ideas and opinionsinto or aboutthe system-s design'



79/120


y p




The Design #hase #ctivities

FAST has Bmerged- the design and construction phases to form

a rapid application development!or 5,D& approach based

on iterative prototyping'

8 1his strategy designs and constructs the system as a series of

prototypesto which the system users react'

8 1he prototyping process is as follows2

Step $' 4efine the baselevel scope of the first !or ne/t&

version of the system'

Step ' 4efine, design, construct, and load the database'



80/120


y








8 1he prototyping process is as follows2 !continued&

Step -' 4efine, design, and construct the inputs' 4emonstrate

this prototype to the system users'%&epeat step ' until the system users are satisfied. (f necessary, return

to step ) to add new requirements to the database design.* Step /' 4efine, design, and construct the outputs'

4emonstrate this prototype to the system users'%&epeat step + until the system users are satisfied. (f necessary, return

to step ) to add new database requirements, or step to add new input

requirements.*



81/120










Step 0' 4efine, design, and construct the interface'

4emonstrate this prototype to the system users'

!&epeat step until the system users are satisfied. (f necessary, return

to step ), , or ' to add new database, input, or output requirements,respectively.*

Step 2' 4esign and construct any missing system controls

such as security, backup, recovery, etc'



82/120










Step 6' (mplement this version of the system'

Step 7' Eo to step ) to begin the #4 cycle for the ne/t

version of the system'



83/120





The Design #hase 4eliverables

1he final deliverable is a technical set of design specifications'

8 4esign specifications can take several forms, but the most

common approach is modeling'

8 Eeneral design models will depict2

1he structure of the database'

1he structure of the overall application'

1he overall Blook and feel- of the user interface'

1he structure of the computer network'

1he design structures for any comple/ software to be written'



84/120





The Design #hase 7ostrequisites and Feasibility "heckpoints

#t this point a project is rarely canceled'

%ach constructed prototype is refined or e/panded by another

pass through system design until the final system is

constructed'

(mpact #nalysis

1his phase is mandatory'



85/120





The Construction #hase 7urpose2

1hepurpose of the construction phase is twofold2

8 to build and test a functional system that fulfills business and

design requirements

8 to implement the interfaces between the new system and e/isting

production systems



86/120





The Construction #hase 7articipants and oles


1he analyst serves as a general contractor for work done by

technical specialists or subcontractors'

$ystem users- responsibilities are usually limited to reacting to

the functional system-s easeoflearning and easeofuse'



87/120





The Construction #hase 7rerequisites

1he design specifications!general or detailed& are the key

input to the construction phase'

(nformation technology vendors may provide installation

support for any packaged software or software development

tools'



88/120





The Construction #hase #ctivities

1he database and networks provide the system-s infrastructure>

therefore, they must be constructed first %unless they already

e$ist*' #ny new software packages must be installed and tested'

#ny new programs must be constructed and tested'



89/120





The Construction #hase #ctivities

0ne of the most important aspects of application programming

is testing both unit and system testing'

8 'nit testsensure that the applications programs work properly

when tested in isolation from other applications programs'

8 System testsensure that applications programs written in isolation

work properly when they are integrated into the total system'



90/120





The Construction #hase 4eliverables

1he final deliverable of the construction phase is the

functional system.

1he rapid application development strategy ofFASTresults in

several interim deliverables called prototypes'



91/120





The Construction #hase 7ostrequisites, Feasibility "heckpoints, and (mpact #nalysis

#t this point a project is rarely canceled'

1his phase is optional'

(t is possible that a prototype might be implemented as a first

!ne/t& version before the system has been fully constructed'

Information System Developmentl


92/120





The Delivery #hase 7urpose2

1he purpose of the delivery phase is to install, deploy, and

place the new system into operation orproduction'



1he systems analyst is the most visible player asthey

communicate implementation problems and issues between

system users, system designers, and system builders' 1he entire project team is active in this phase'

$ystem owners and users step to the forefront as cheerleaders

for the new system'

Information System DevelopmentS A S D l


93/120





The Delivery #hase 7rerequisites

1he key input to the delivery phase is the functional system.

$ystem users provide continuousfeedbackas new problems

and issues are common !note2 no system has achieved the

nirvana goal of Bperfection-&'

For new information technology !hardware and software&, the

information technology vendors provide necessary technical

support'

Information System DevelopmentFAST A S t D l t


94/120





The Delivery #hase #ctivities

1he training of system users'

1he writing of various manuals'

1he loading of files and databases'

4eliverables

1he final deliverable of the delivery phase !and the project& is

the production systemfor the system users'

#nother output of the delivery phase is training and support'



95/120





The Delivery #hase 7ostrequisites, Feasibility "heckpoints, and (mpact #nalysis

1he project is complete9 1here is no further feasibility analysis'

1here may be a project postaudit to evaluate the system,

methodology, and team'



96/120





4eyond Systems Development + Systems Support 0nce the system is placed into production, the analyst6s role

changes to systems support'

System supportis the ongoing maintenance of a system after

it has been placed into operation' 1his includes programmaintenance and system improvements'

$ystems support doesn6t consist of phases so much as it does

ongoing activities' 1hese activities include2

8 Fi/ing software Bbugs-'

8 ecovering the system'

8 #ssisting users'

8 #dapting the system to new requirements'



97/120




Cross Life Cycle Activities

Cross Life Cycle ,ctivities Cross life cycle activitiesare activities that overlap many or all

phases of the methodology in fact, they are normally performed

in conjunction with several phases of the methodology'

"ross life cycle activities include2 fact finding

documentation and presentation

estimation and measurement

feasibility analysis project management

process management'



98/120




ID Tas- Nam e

> Sur4e8 $5ase

C Stu.8 $5ase

B Definition $5ase

Tar+etin+ $5ase

Desi+n $5ase

G $urc5asin+ $5ase

H "onstruction $5ase

Imp-ementation $5ase

J

>? !act !in.in+

>> Documentation

>C $resentation

>B Estimation

> Measurement> !easi,i-it8 Ana-8sis

>G $ro9ect mana+ement

>H $rocess mana+ement

>

>J

C?

C>

CC

CB

C

C

CG

'*=)' '=> '='? '=*' '=*@ *=? *='' *='@ *=*/ )=) )='( )='> )=*? )=)' ?=> ?='? ?=*' ?=*@ /=/ /='* /='

Kanuary February March A#rl May



99/120





;act ;inding ;act 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/120





Documentation and #resentations "ommunication skills are essential to the successful completion of

a project'

1wo forms of communication that are common to systems

development projects are documentation and presentation' Documentationis the activity of recording facts and

specifications for a system'

#resentationis the related activity of formally packaging

documentation for review by interested users and managers'

7resentations may be either written or verbal'



101/120





Documentation and #resentations :ersion control over documentation has become a critical success

factor> it involves keeping and tracking multiple versions of a

system6s documentation'

.ost information systems shops want to keep documentationfor all of the following versions2

8 0ne or more previous versions of the system'

8 1he current production version of the system'

8 #ny version of the system going through the build and test

activity'8 #ny version going through the life cycle to create a new version'

Information System DevelopmentC


102/120




>

The

Sur2ey

$hase

The

Stu*y

$haseB

The

De&nton

$hase

The

Targetng

$hase

The

Desgn

$hase

H

The

%onstructon

$haseG

The

$urchasng

$hase

The

Im#lementa3

ton

$hase

$rogram

/braryDatabase

Re#ostory

#ro"ect

an*

system

sco#e

system

ob"ect2es

busness

requrements

*esgn an*

technology

requrements

*esgn

s#ec&catonstechnologyntegraton

requrements

&unctonal

systems#ec&catons

#ro*ucton

system

s#ec&catons

#urchase*

so&t(are

#rototy#es

an*

&unctonalso&t(are

#ro*ucton

so&t(are

test

*ata

actual busness *ata



103/120





stimation and !easurement (nformation systems are significant capital investments' For this

reason, estimation and measurement activities are commonly

performed to address the quality and productivity of systems'

stimationis the activity of appro/imating the time, effort,costs, and benefits of developing systems' 1he term

guesstimation !as in 55make a guess66& is used to describe the

same activity in the absence of reliable data'

!easurementis the activity of measuring and analyzing

developer productivity and quality !and sometimes costs&'



104/120





stimation and !easurement 1here are two common approaches to estimation'

First, some analysts avoid estimation out of fear, uncertainty,

or lack of confidence'

8 1he analyst may resort to what are jokingly called 55guesstimates'66

;etter analysts draw on e/perience and data !both their own

and the collective e/perience of others& from previous projects

to continually improve their estimates'



105/120





stimation and !easurement .easurement has become important because of the productivity

and quality problems that plague systems development'

1he field of software and systems metrics offers hope for the

future'8 Software and systems metricsprovides an encyclopedia of

techniques and tools that can both simplify the estimation process

and provide a statistical database of estimates versus performance'



106/120





;easi*ility ,nalysis # system development life cycle that supports our creeping

commitment approach to systems development recognizes

feasibility analysis as a cross life cycle activity'

;easi*ilityis a measure of how beneficial the development ofan information system would be to an organization'

;easi*ility analysisis the activity by which feasibility is

measured'



107/120





#ro9ect !anagement and #rocess !anagement $ystems development projects may involve a team of analysts,

programmers, users, and other ($ professionals who work together'

#ro9ect managementis the ongoing activity by which an

analyst plans, delegates, directs, and controls progress todevelop an acceptable system within the allotted time and

budget'

.ost project development failures are attributed to poor leadership

and management'

1his mismanagement results in unfulfilled or unidentifiedrequirements, cost overruns, and late delivery'



108/120





#ro9ect !anagement and #rocess !anagement 1he systems development life cycle provides the basic framework

for the management of systems projects'

rocess managementsintent is to standardize both the way we

approach projects, and the deliverables we produce duringprojects'

#rocess managementis an ongoing activity that establishes

standards for activities, methods, tools, and deliverables of the

life cycle'

Information System DevelopmentComputer-Aided Systems


109/120




Computer-Aided SystemsEngineering CASE!

hat is Computer+,ided Systems ngineering" Computer+aided systems engineering (C,S)is the application

of information technology to systems development activities,

techniques, and methodologies' "AS# toolsare programs

!software& that automate or support one or more phases of asystems development life cycle' 1he technology is intended to

accelerate the process of developing systems and to improve the

quality of the resulting systems'

"#$% is not a methodology or an alternative to methodologies'

"#$% is an enabling technology that supports a methodology-spreferred strategies, techniques, and deliverables'



110/120




Computer-Aided SystemsEngineering CASE!

The 8istory and volution of C,S Technology 1he true history of "#$% dates back to the early to mid)GHIs'

1he ($40$ project used a language calledroblem Statement

/anguage %S/*for describing user problems and solution

requirements for an information system into a computerizeddictionary'

# companion product calledroblem Statement Analy0er

%SA*was created to analyze those problems and requirements

for completeness and consistency'

S/1SAran on large mainframe computers' "#$% success started with the advent of the personal computer'

(n )GJ, (nde/ 1echnology !now known as (ntersolv& created a

7" software tool called#$celerator'



111/120




Computer Aided SystemsEngineering CASE!

, C,S Tool ;ramewor "#$% tools are classified according to which phases of the life

cycle they support'

1he term upper+C,S describes tools that automate or

support the Bupper- or earliest phases of systems development the survey, study, definition, and design phases'

1he term lower+C,Sdescribes tools that automate or support

the Blower- or later phases of systems development detailed

design, construction, and implementation !and also support&'



112/120





C,S Tool ,rchitecture #t the center of any true "#$% tool-s architecture is a database

called a repository !or a link into such a repository&'

#round the repository is a collection of tools or facilities to create

documentation or other system components' 1he real power of a Btrue- "#$% tool is derived from its repository

!or its ability to use and update some other tool-s repository&'

# C,S repositoryis a developers- database' (t is a place

where the developers can store diagrams, descriptions,

specifications, and other byproducts of systems development'$ynonyms include dictionaryand encyclopedia'

.any different "#$% tools can share information across a

single repository'



113/120






114/120




%ENTRA/

RE$OSITORY

/ocal

Re#ostory

)on a /AN

Ser2er,Securty an*

:erson

%ontrol

Tools

Inqury an*

Re#ortng

Tools

Data

Sharng

Tools

+ouse3

-ee#ngTools

1ra#hcs

Tools

Decson

Su##ort

Tools

;ualty

Management

Tools

Desgn

1enerators

%o*e

1enerators

Document

Tools

IN$0TSL

mo*els9

*escr#tons

an*

#rototy#es

O0T$0TSL

re#orts9

#roblems9an*

analyses

m#orte*an*

e'#orte*

-no(le*gechec-3out

chec- n

-no(le*ge

Re#ostory

Ser2er

%ASE Tool

Facltes

)on a (or-staton,

Descr#ton

Tools

$rototy#ng

Toolsln-s ln-s



115/120





C,S Tool ,rchitecture "#$%

week 2 chapter 3 systems development power point

Documents