BUSINESS DRIVEN
TECHNOLOGY
Business Plug-In B9
Systems Development
9-1
Introduction
•
Large, complex IT systems take teams of
architects, analysts, developers, testers, and
users many years to create
•
The systems development life cycle is the
foundation for many systems development
methodologies such as RAD and agile
– Systems development life cycle – the overall
process for developing information systems from
planning and analysis through implementation and
maintenance
9-4
Introduction
9-5
9-5
Systems Development Life Cycle PHASE 1: PLANNING
•
Planning phase – involves establishing a highlevel plan of the intended project and determining
project goals
•
Primary planning activities include
1. Identify and select the system for development
2. Assess project feasibility
3. Develop the project plan
9-6
PLANNING 1: Identify and Select the
System for Development
•
Organizations use different forms of evaluation
criteria to determine which systems to develop
– Critical success factor (CSF) – a factor that is
critical to an organization’s success
9-7
PLANNING 2: Assess Project Feasibility
•
Feasibility study – determines if the proposed
solution is feasible and achievable from a
financial, technical, and organizational standpoint
•
Different types of feasibility studies
–
–
–
–
–
Economic feasibility study
Operational feasibility study
Technical feasibility study
Schedule feasibility study
Legal and contractual feasibility study
9-8
PLANNING 3: Develop the Project Plan
•
Developing the project plan is a difficult and
important activity
•
The project plan is the guiding force behind ontime delivery of a complete and successful
system
•
Continuous updating of the project plan must be
performed during every subsequent phase during
the SDLC
9-9
Systems Development Life Cycle –
PHASE 2: ANALYSIS
•
Analysis phase – involves analyzing end-user
business requirements and refining project goals
into defined functions and operations of the
intended system
•
Primary analysis activities include
1. Gather business requirements
2. Create process diagrams
3. Perform a buy vs. build analysis
9-10
ANALYSIS 1: Gather Business
Requirements
•
Business requirements – the detailed set of business
requests that the system must meet in order to be
successful
•
Different ways to gather business requirements
–
–
–
–
–
Joint application development (JAD) session – where
employees meet to define or review the business requirements
for the system
Interviews
Questionnaires
Observations
Review business documents
9-11
ANALYSIS 1: Gather Business
Requirements
•
The system users review the requirements
definition document and determine if they will
sign-off on the business requirements
– Requirements definition document – contains the
final set of business requirements, prioritized in order
of business importance
– Sign-off – the system users’ actual signatures
indicating they approve all of the business
requirements
9-12
ANALYSIS 2: Create Process Diagrams
•
Process modeling – graphically representing the
processes that capture, manipulate, store, and distribute
information between a system and its environment
•
Common process modeling diagrams include
–
–
Data flow diagram (DFD) – illustrates the movement of
information between external entities and the processes and
data stores within the system
Computer-aided software engineering (CASE) tools –
automate systems analysis, design, and development
9-13
ANALYSIS 2: Create Process Diagrams
•
Sample data flow diagram
9-14
ANALYSIS 3: Perform a Buy vs. Build
Analysis
•
An organization faces two primary choices when
deciding to develop an information system
1. Buy the information system from a vendor
– Commercial off-the shelf (COTS) – software
package or solution that is purchased to support
one or more business functions and information
systems
– SCM, CRM, and ERP solutions are typically COTS
2. Build the information system itself
9-15
ANALYSIS 3: Perform a Buy vs. Build
Analysis
•
Organizations must consider the following when
making a buy vs. build decision:
– Are there any currently available products that fit the
organization’s needs?
– Are there features that are not available and
important enough to warrant the expense of in-house
development?
– Can the organization customize or modify an existing
COTS to fit its needs?
– Is there a justification to purchase or develop based
on the cost of acquisition?
9-16
ANALYSIS 3: Perform a Buy vs. Build
Analysis
•
Three key factors an organization should also
consider when contemplating the buy vs. build
decision:
1. Time to market
2. Availability of corporate resources
3. Corporate core competencies
9-17
Systems Development Life Cycle –
PHASE 3: DESIGN
•
Design phase – involves describing the desired
features and operations of the system including
screen layouts, business rules, process
diagrams, pseudo code, and other documentation
•
Primary design activities include:
1. Design the IT infrastructure
2. Design system models
9-18
DESIGN 1: Design the IT Infrastructure
•
Organizations need a solid IT infrastructure to
support their IT systems
•
IT infrastructure must meet the organization’s
needs in terms of time, cost, technical feasibility,
and flexibility
9-19
DESIGN 1: Design the IT Infrastructure
•
Sample IT infrastructure
9-20
DESIGN 2: Design System Models
•
Modeling – the activity of drawing a graphical
representation of a design
•
Different modeling types include:
–
–
–
–
Graphical user interface (GUI) – the interface to an
information system
GUI screen design – the ability to model the information
system screens using icons, buttons, menus, and submenus
Data models – a formal way to express data relationships to a
database management system (DBMS)
Entity relationship diagram (ERD) – a technique for
documenting the relationships between entities in a database
9-21
DESIGN 2: Design System Models
•
Sample entity relationship diagram (ERD)
9-22
Systems Development Life Cycle –
PHASE 4: DEVELOPMENT
•
Development phase – involves taking all of the
detailed design documents from the design
phase and transforming them into the actual
system
•
Primary development activities include:
1. Develop the IT infrastructure
2. Develop the database and programs
9-23
DEVELOPMENT 1: Develop the IT
Infrastructure
•
The platform upon which the system will operate
must be built prior to building the actual system
•
In the development phase, the organization
purchases and implements the required
equipment to support the IT infrastructure
9-24
DEVELOPMENT 2: Develop the Database
and Programs
•
Once the IT infrastructure is built, the
organization can begin to create the database
and write the programs required for the system
•
IT specialists perform the majority of the tasks
associated with the development phase
9-25
Systems Development Life Cycle –
PHASE 5: TESTING
•
Testing phase – involves bringing all the project
pieces together into a special testing environment
to test for errors, bugs, and interoperability, in
order to verify that the system meets all the
business requirements defined in the analysis
phase
•
Primary testing activities include:
1. Write the test conditions
2. Perform the system testing
9-26
TESTING 1: Write the Test Conditions
•
Test condition – the detailed steps the system
must perform along with the expected results of
each step
9-27
TESTING 2: Perform the System Testing
•
Different types of testing:
–
–
–
–
–
–
Unit testing – tests each unit of code upon completion
Application (or system) testing – verifies that all units of
code work together
Integration testing – exposes faults in the integration of
software components or units
Backup and recovery testing – tests the ability of an
application to be restarted after failure
Documentation testing – verifies instruction guides are
helpful and accurate
User acceptance testing (UAT) – tests if a system satisfies
its acceptance criteria
9-28
Systems Development Life Cycle –
PHASE 6: IMPLEMENTATION
•
Implementation phase – involves placing the
system into production so users can begin to
perform actual business operations with the
system
•
Primary implementation activities include:
1. Write detailed user documentation
2. Determine implementation method
3. Provide training for the system users
9-29
IMPLEMENTATION 1: Write Detailed User
Documentation
•
System users require user documentation that
highlights how to use the system
•
User documentation – highlights how to use the
system
9-30
IMPLEMENTATION 2: Determine
Implementation Method
•
Four primary implementation methods
1.
2.
3.
4.
Parallel implementation
Plunge implementation
Pilot implementation
Phased implementation
9-31
IMPLEMENTATION 3: Provide Training for
the System Users
•
Organizations must provide training for system
users
•
Two most popular types of training include:
– Online training – runs over the Internet or off a CDROM
– Workshop training – set in a classroom-type
environment and led by an instructor
9-32
Systems Development Life Cycle –
PHASE 7: MAINTENANCE
•
Maintenance phase – involves performing
changes, corrections, additions, and upgrades to
ensure the system continues to meet the
business goals
•
Primary maintenance activities include:
1. Build a help desk to support the system users
2. Perform system maintenance
3. Provide an environment to support system changes
9-33
MAINTENANCE 1: Build a Help Desk to
Support the System Users
•
Internal system users have a phone number for
the help desk they call whenever they have
issues or questions about the system
– Help desk – a group of people who respond to
internal system user questions
•
Providing a help desk is an excellent way to
provide comprehensive support for new system
users
9-34
MAINTENANCE 2: Perform System
Maintenance
•
Maintenance – fixing or enhancing an
information system
•
Different types of maintenance include
–
–
–
–
Adaptive maintenance
Corrective maintenance
Perfective maintenance
Preventative maintenance
9-35
MAINTENANCE 3: PROVIDE AN ENVIRONMENT
TO SUPPORT SYSTEM CHANGES
•
An organization must modify its systems to support
the business environment
•
It typically accomplishes this through change
management systems and change control boards
– Change management system – a collection of
procedures to document a change request and define
the steps necessary to consider the change based on
the expected impact of the change
– Change control board (CCB) – responsible for
approving or rejecting all change requests
9-36
Software Problems Are Business
Problems
•
Primary reasons for project failure include
– Unclear or missing business requirements
– Skipping SDLC phases
– Failure to manage project scope
•
•
Scope creep – occurs when the scope increases
Feature creep – occurs when extra features are added
– Failure to manage project plan
– Changing technology
9-37
Software Problems Are Business
Problems
•
Find errors early: the later in the SDLC an error is
found - the more expensive it is to fix
9-38
Closing Case One
Disaster at Denver International Airport
•
DIAs baggage system relied on 300 computers to
route bags and 4,000 telecars to carry luggage
across 21 miles of track
•
Due to baggage system failures, DIA delayed its
opening for 16 months, costing taxpayers roughly
$1 million per day, which totaled around $500
million
9-39
Closing Case One Questions
1.
One of the problems with DIA’s baggage system was
inadequate testing. Describe the different types of tests DIA
could have used to help ensure its baggage system’s
success
2.
Evaluate the different implementation approaches and
choose the one that would have most significantly increased
the chances of the project’s success
3.
Explain the cost of finding errors and how more time spent in
the analysis and design phase could have saved Colorado
taxpayers hundreds of millions of dollars
4.
Explain why BAE could not take an existing IT infrastructure
and simply increase its scale and expect it to work
9-40
Closing Case Two
Reducing Ambiguity in Business Requirements
•
The number one reason projects fail is bad
business requirements
•
Business requirements are considered “bad”
because of ambiguity or insufficient involvement
of end users during analysis and design
•
A requirement is unambiguous if it has the same
interpretation for all parties
9-41
Closing Case Two Questions
1.
Why are ambiguous business requirements the leading
cause of system development failures?
2.
Explain why the words “and” and “or” tend to lead to
ambiguous requirements
3.
Research the Web and determine other reasons for
“bad” business requirements
4.
What is wrong with the following business requirement:
“The system must support employee birthdays since
every employee always has a birthday every year”
9-42