The Traditional System Development Life Cycle

Download Report

Transcript The Traditional System Development Life Cycle

The Traditional System
Development Life Cycle
There are a number of important steps in the
creation of a system, regardless of which
approach you use. You may choose to ignore
some of these steps and combine others, but all
need to be considered. The traditional system
development life cycle (SDLC) makes all these
steps explicit. At the highest level, there are
three steps:
• Analysis
• Design and construction
• Implementation (and continuing Operations)
The Traditional System
Development Life Cycle
I. Analysis
1. Initiation (e.g., an RFP)
2. Feasibility study
•
•
•
•
Go? No go?
Technical – can we build it?
Economic – should we build it?
Operational – if we build it, will it be used?
Schedule – will it be ready in time?
3. Requirements definition
4. Specifications
5. Project plan
The Traditional System
Development Life Cycle
II. Design
6. Logical design (i.e., the external view)
7. Physical design (i.e., the internal view)
8. Coding (or code acquisition)
9. Testing
The Traditional System
Development Life Cycle
III. Implementation
10. Documentation – ouch! This should have been done
all along!
11. Conversion
•
•
•
•
Direct
Parallel
Pilot
Phased
12. Training – both initial and continuing
•
•
•
Users
I/S staff
Management
13. Installation
The Traditional System
Development Life Cycle
IV. Operations
14. Production
15. Post-implementation audit
16. Maintenance
The Traditional System
Development Life Cycle
What is maintenance?
“It is post-implementation software development,
designed to ensure the continued effectiveness of the
software in question.”
There are three types of maintenance:
1. Corrective
2. Adaptive
3. Perfective
How should maintenance be managed?
1. “Cradle-to-grave”; those who built it, maintain it.
2. Separate maintenance department.
3. Outsource the maintenance to a third party.
What is Prototyping?
• Prototyping is the process of building a
model of a system. In terms of an
information system, prototypes are
employed to help system designers build
an information system that intuitive and
easy to manipulate for end users.
Prototyping is an iterative process that is
part of the analysis phase of the systems
development life cycle.
The Requirements Phase
• During the requirements determination portion of
the systems analysis phase, system analysts
gather information about the organization's
current procedures and business processes
related the proposed information system. In
addition, they study the current information
system, if there is one, and conduct user
interviews and collect documentation. This helps
the analysts develop an initial set of system
requirements.
Development of a Prototype
• Prototyping can augment this process because it
converts these basic, yet sometimes intangible,
specifications into a tangible but limited working
model of the desired information system. The
user feedback gained from developing a
physical system that the users can touch and
see facilitates an evaluative response that the
analyst can employ to modify existing
requirements as well as developing new ones.
Types of Prototyping
• Prototyping comes in many forms - from low tech
sketches or paper screens(Pictive) from which users
and developers can paste controls and objects, to
high tech operational systems using CASE
(computer-aided software engineering) or fourth
generation languages and everywhere in between.
Many organizations use multiple prototyping tools.
For example, some will use paper in the initial
analysis to facilitate concrete user feedback and then
later develop an operational prototype using fourth
generation languages, such as Visual Basic, during
the design stage.
Advantages
– Reduces development time.
– Reduces development costs.
– Requires user involvement.
– Developers receive quantifiable user
feedback.
– Facilitates system implementation since
users know what to expect.
– Results in higher user satisfaction.
– Exposes developers to potential future
system enhancements.
Disadvantages
– Can lead to insufficient analysis.
– Users expect the performance of the ultimate
system to be the same as the prototype.
– Developers can become too attached to their
prototypes
– Can cause systems to be left unfinished and/or
implemented before they are ready.
– Sometimes leads to incomplete documentation.
– If sophisticated software prototypes (4th GL or
CASE Tools) are employed, the time saving
benefit of prototyping can be lost.
What is Outsourcing?
• Outsourcing involves transferring
responsibility for carrying out an activity
(previously carried on internally) to an
external service provider. The service
provider in turn provides services back to
the customer against agreed service levels
for an agreed charge. In many
outsourcings the transfer of the activity
involves the transfer of staff and assets.
Advantages
The reasons for outsourcing IT are varied but
some of the most frequently cited drivers include:
• Reducing IT costs;
• Access to world-class IT skills, experience and
resources;
• Removing non-core business;
• Minimising sizeable capital expenditure on IT
infrastructure; and
• Certainty of future IT spend.
Disadvantages
The potential downsides to outsourcing
include:
• A loss of control over a crucial business
service;
• A lack of flexibility in the services received;
• Damage to staff morale/culture clashes
(between the service provider and
customer).
Managing the outsourcing
relationship
• Once an outsourcing deal has been concluded
committed management of the outsourcing relationship
is critical to its success.
• A successful outsourcing requires processes and
procedures for managing the relationship between the
customer and the service provider: for example
• regular service meetings, agreed processes for
reviewing the services (preferably involving
benchmarking provision against other service providers),
reporting procedures and a robust mechanism for
escalating and resolving problems.
• An outsourcing services contract is not a contract which
should be put in a drawer once signed—it is a live and
operational document.