MANAGING INFORMATION TECHNOLOGY

offbeatnothingΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

75 εμφανίσεις


E. Wainright Martin


Carol V. Brown


Daniel W. DeHayes

Jeffrey A. Hoffer


William C. Perkins


MANAGING

INFORMATION

TECHNOLOGY

FIFTH EDITION

CHAPTER 10

M
ETHODOLOGIES FOR
C
USTOM
S
OFTWARE
D
EVELOPMENT



© 2005 Pearson Prentice
-
Hall Chapter 10
-

2


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 385

Systems development life cycle (SDLC)


a highly
structured approach for development of new customized
software applications



© 2005 Pearson Prentice
-
Hall Chapter 10
-

3


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 386

The SDLC Steps


Figure 10.1 The Systems Development


Life Cycle



© 2005 Pearson Prentice
-
Hall Chapter 10
-

4


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 386

The SDLC Steps


Figure 10.2 Cost Breakdown for $1 Million


SDLC Project



© 2005 Pearson Prentice
-
Hall Chapter 10
-

5


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 386

The SDLC Steps

SDLC:


Most often requires a lot of documentation


Outputs from one step inputs to next


Often referred to as the “waterfall” model



© 2005 Pearson Prentice
-
Hall Chapter 10
-

6


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 387
-
388

Definition Phase



Feasibility Analysis


Types of feasibility


economic, operational,
and technical


Deliverable


10
-
20 page document:


Executive overview and recommendations


Description of what system would do and how it
would operate


Analysis of costs and benefits


Development plan



© 2005 Pearson Prentice
-
Hall Chapter 10
-

7


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 388

Definition Phase



Requirements Definition


Focuses on logical design:
processes, data
flows, and data interrelationships


not
specific
physical implementation


Deliverable


system requirements document:



Detailed descriptions of inputs and outputs,
processes used to convert input data to outputs


Formal diagrams and output layouts


Revised cost/benefit analysis


Revised plan for remainder of project





© 2005 Pearson Prentice
-
Hall Chapter 10
-

8


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 389

Construction Phase


System Design


System Building


System Testing


Figure 10.3 Characteristics


of High Quality Systems



© 2005 Pearson Prentice
-
Hall Chapter 10
-

9


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 390

Implementation Phase


Installation


Operations


Maintenance



© 2005 Pearson Prentice
-
Hall Chapter 10
-

10


Page 391

Implementation Phase


Installation


Figure 10.4 Implementation Strategies

Parallel Strategy

Parallel Strategy

Parallel Strategy

Parallel Strategy



© 2005 Pearson Prentice
-
Hall Chapter 10
-

11


Page 392

Implementation Phase


Maintenance

Figure 10.5 Percent of Development


Resources Devoted to Maintenance



© 2005 Pearson Prentice
-
Hall Chapter 10
-

12


Page 392

Implementation Phase


Maintenance

Figure 10.6 The Widening Gap Between

Organization’s Needs and System’s Performance



© 2005 Pearson Prentice
-
Hall Chapter 10
-

13


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 393

The SDLC Project Team


Usually temporary


Includes personnel from IS and business units


Has a
project manager


Traditionally from IS


Can be from business unit


May be one from each


Responsible for success of project


delivering
quality system on time and within budget



© 2005 Pearson Prentice
-
Hall Chapter 10
-

14


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 394

The SDLC Project Team


Includes
systems analysts



Have critical roles


Work closely with business managers and end users


Have problem
-
solving skills, knowledge of IT
capabilities, strong business understanding


Has a business
sponsor

and a
champion



© 2005 Pearson Prentice
-
Hall Chapter 10
-

15


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 394

Managing an SDLC Project


Characteristics critical for success:


Manageable project size


Accurate requirements definition


Executive sponsorship




© 2005 Pearson Prentice
-
Hall Chapter 10
-

16


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 395


Figure 10.7 Costs of Error Correction


by SDLC Step

Managing an SDLC Project

(Adapted from Boehm, 1976)



© 2005 Pearson Prentice
-
Hall Chapter 10
-

17


S
YSTEMS
D
EVELOPMENT
L
IFE
C
YCLE
M
ETHODOLOGY

Page 395

SDLC Advantages and Disadvantages

Figure 10.8 Advantages and Disadvantages


of Traditional SDLC Approach



© 2005 Pearson Prentice
-
Hall Chapter 10
-

18


P
ROTOTYPING
M
ETHODOLOGY

Page 396


Prototyping approach:


Takes advantage of availability of fourth generation
procedural languages and relational database
management systems


Enables creation of system (or part of system)
more quickly, then revise after users have tried it


Is a type of
evolutionary development

process



© 2005 Pearson Prentice
-
Hall Chapter 10
-

19


P
ROTOTYPING
M
ETHODOLOGY

Page 396


Prototyping examples:


Input and output screens developed for users to
test as part of requirements definition


“first
-
of
-
a
-
series”


a completely operational
prototype used as a pilot


“selected features”


only some essential features
included in prototype, more added later


Prototyping used as a
complete alternative

to
traditional SDLC methodology



© 2005 Pearson Prentice
-
Hall Chapter 10
-

20


P
ROTOTYPING
M
ETHODOLOGY

Page 396


Prototyping used as a
complete alternative

to
traditional SDLC methodology:


Good when requirements hard to define


Good when system needed quickly


Impractical for large, complex applications




© 2005 Pearson Prentice
-
Hall Chapter 10
-

21


Page 397

The Prototyping Steps


Figure 10.9 The Prototyping Life Cycle



© 2005 Pearson Prentice
-
Hall Chapter 10
-

22


P
ROTOTYPING
M
ETHODOLOGY

Page 398


Representatives from IS and user
management necessary


Need team members who can quickly build
systems using advanced tools


Requires dedicated business user roles

The Prototyping Project Team



© 2005 Pearson Prentice
-
Hall Chapter 10
-

23


P
ROTOTYPING
M
ETHODOLOGY

Page 398
-
399


Advantages:


Only basic requirements needed at front end


Used to develop systems that radically change how
work is done, so users can evaluate


Allows firms to explore use of new technology


Working system available for testing more quickly


Less strong top
-
down commitment needed at front end


Costs and benefits can be derived after experience with
initial prototype


Initial user acceptance likely higher


Prototyping Advantages and Disadvantages



© 2005 Pearson Prentice
-
Hall Chapter 10
-

24


P
ROTOTYPING
M
ETHODOLOGY

Page 399


Disadvantages:


End prototype often lacks security and control features


May not undergo as rigorous testing


Final documentation may be less complete


More difficult to manage user expectations


Prototyping Advantages and Disadvantages



© 2005 Pearson Prentice
-
Hall Chapter 10
-

25


P
ROTOTYPING
M
ETHODOLOGY

Page 399

Prototyping Within an SDLC Process


Figure 10.10 SDLC with Prototyping


to Define Requirements



© 2005 Pearson Prentice
-
Hall Chapter 10
-

26


P
ROTOTYPING
M
ETHODOLOGY

Page 399

Prototyping Within an SDLC Process


Figure 10.11 Prototyping/Piloting Replaces


SDLC Definition Phase



© 2005 Pearson Prentice
-
Hall Chapter 10
-

27


N
EWER
A
PPROACHES

Page 400

Rapid Application Development (RAD)


Figure 10.12 Four
-
Step RAD Cycle


Hybrid methodology


aspects of SDLC and
prototyping


Goal is to produce a
system in less than a
year




© 2005 Pearson Prentice
-
Hall Chapter 10
-

28


N
EWER
A
PPROACHES

Page 400
-
401

Rapid Application Development (RAD)

Joint application design (JAD)


a technique in which a
team of users and IS specialists engage in an intense and
structured process in order to minimize the total time
required for gathering information from multiple
participants



© 2005 Pearson Prentice
-
Hall Chapter 10
-

29


N
EWER
A
PPROACHES

Page 400
-
401

Rapid Application Development (RAD)

Joint application design (JAD)


a technique in which a
team of users and IS specialists engage in an intense and
structured process in order to minimize the total time
required for gathering information from multiple
participants

Computer
-
aided software engineering (CASE)


any
software tool used to automate one or more steps of a
software development methodology



© 2005 Pearson Prentice
-
Hall Chapter 10
-

30


N
EWER
A
PPROACHES

Page 401

Rapid Application Development (RAD)


Figure 10.13 Types of CASE Tools

(Adapted from Valacich, George, and Hoffer, 2001)



© 2005 Pearson Prentice
-
Hall Chapter 10
-

31


N
EWER
A
PPROACHES

Page 402

Rapid Application Development (RAD)


Figure 10.14 RAD Advantages


and Disadvantages



© 2005 Pearson Prentice
-
Hall Chapter 10
-

32


N
EWER
A
PPROACHES

Page 402

Agile Software Development Discipline


Alternative methodology for smaller projects


Based on four key values:


Simplicity


Communication


Feedback


Courage


One type:
Extreme Programming (XP)


Programmers write code in pairs


Use simple design and frequent testing



© 2005 Pearson Prentice
-
Hall Chapter 10
-

33


M
ANAGING
S
OFTWARE
P
ROJECTS
U
SING
O
UTSOURCED
S
TAFF

Page 402


Advantages:


Helps keep software development costs down


Uses technical expertise not available in
-
house


Can often complete projects more quickly


Off
-
site outsourcing:


Onshore


within same country or region


Offshore


not within same country or region



© 2005 Pearson Prentice
-
Hall Chapter 10
-

34


M
ANAGING
S
OFTWARE
P
ROJECTS
U
SING
O
UTSOURCED
S
TAFF

Page 402


Offshore

alternative good option when:


System requirements well
-
defined and remain stable


Time is of essence and 7x24 hour availability of
resources a good idea


Cost of project important



© 2005 Pearson Prentice
-
Hall Chapter 10
-

35


M
ANAGING
S
OFTWARE
P
ROJECTS
U
SING
O
UTSOURCED
S
TAFF

Page 402
-
403


Guidelines for managing offsite outsourcer:


Manage expectations, not staff


Take explicit actions to integrate the offsite workers


Communicate frequently


Abandoning informal ways may result in increased
rigor