Chapter 3

2) Level 1: Initial - The organization follows no standard development

process other than chaos. Success or failure is usually depends on
the skill and experience of the team.
Level 2: Repeatable - The main focus at this level is project
management. The organization has established project management
processes and follows a system development process, which may
change from project to project. Success or failure is still function of the
skill and experience of the project team.
Level 3: Defined - The organization has developed a standard system
development process (also called a methodology), which is stable,
predictable and repeatable.
Level 4: Managed - The organization has established measurable
goals for quality and productivity goals and metrics for projects.
Level 5: Optimizing - The organization has established a continuous
project monitoring, improvement process based on measure and data
analysis established in Level 4.

4) Systems development methodology is the methodology used to

“execute” and govern the systems development process.
Systems life cycle is the” natural” life cycle stages where conversion
must take place, starting from development, then converting to
operations and maintenance, and ending with redevelopment

6) Principle 1: Get the System Users Involved - The methodology

involves the users, in order to get their partnership and commitment,
and to ensure that the solution addresses the real business problem
and requirements.
Principle 2: Use a Problem-Solving Approach - The methodology
employs a problem-solving approach to ensure that the right problem
is being correctly solved with the right solution.
Principle 3: Establish phases and Activities: The methodology
establishes and divides the project into phases to ensure that the
systems development process is conducted in a planned and
structured process.
Principle 4: Document Throughout Development: The methodology
includes continuous documentation through each phase, instead of
waiting for the end of the project. This is to enhance communication
and acceptance, increase user involvement, and reassure
management about progress.
Principle 5: Establish Standards - The methodology builds or uses
established standards to ensure effective system integration
and to ensure consistency with the organization’s IT architecture.
Principle 6: Manage the Process and Projects - The methodology
includes a project management process in order to ensure that the
project is developed at minimum cost, meets quality standards, and is
completed on time.
Principle 7: Justify Information Systems as Capital Investments - The
methodology views organizational information systems as capital
investments. Alternative opportunities are evaluated based upon their
cost-effectiveness, risk and feasibility
Principle 8: Don’t Be Afraid to Cancel or Revise Scope - The
methodology includes a strategy for continuous evaluation of project
scope, feasibility and risk. It also advocates a creeping commitment
approach to system development in order to build multiple feasible
checkpoints. As part of this strategy, the methodology includes a
change management process for adjusting scope, and a risk
management plan to identify and mitigate risks. The methodology also
supports the idea that cancellation of the project may sometimes be
the best business decision.
Principle 9: Divide and Conquer -The methodology breaks the system
into smaller, more manageable subsystems and components to ease
the problem-solving process.
Principle 10: Design Systems for Growth and Change - The
methodology accepts the reality of change and that system entropy is
a natural occurrence. Correspondingly, the methodology
acknowledges system design based upon growth and change.

8) Requirements analysis: A business requirements statement, which

documents the what business requirements must be met by new
system
Logical design: A non-technical design document that translates the
business requirements into a conceptual design for the new system.
Physical design and Integration: The redesigned business processes,
design prototype, and the physical or technical design specifications.

9) The scope definition phase occurs as the result of a business

problem, opportunity, directive, or some combination of any or all of
these three triggers.
The stakeholder participants are generally the system owners, project
managers and systems analysts.
The first essential question is focused on “Is the problem worth looking
at?” The second essential question is about what are the size and
boundaries of the project, vision, constraints required participants,
budget and schedule of the project.
The three important deliverables are the:
i.Problem statement, which documents and categorizes the problem,
opportunity or directive, but doesn’t attempt to solve any of them.
ii.Scope statement, which identifies the boundaries of the project
iii.Statement of work, the contract that agrees to develop the project
and specifies the work to be done

10) System users, systems analysts, and project managers typically

are involved and participate in this phase. The primary focus during
the requirements analysis phase is on what the system needs to do,
not how it should do it. Each proposed requirement should be
evaluated on whether it meets one or more of the system
improvement objectives defined during the preceding problem
analysis phase. The critical error that must be avoided is to cut the
requirements analysis short before business needs are fully
understood in order to work on the technical solution.

14) The Rapid Application Development (RAD) strategy might be the

best one to use in this situation where requirements are not well
known and short time, but the organization does not need the entire
system delivered all at once. The RAD strategy is to use prototyping
techniques to actively engage system users, to condense the typical
time required for initial development by focusing on the most
problematic requirements, and to dramatically decrease the time to
implementation of an operational system with basic functionality. Then
iterative development will continue in order to gradually fill out and
expand system functionality.
An alternative strategy might be to purchase and customize a
commercial application package (also known as commercial
off-the-shelf software or COTS). Since designing and building a new
system from scratch would not be required, initial implementation
would be generally quicker. Also, COTS often has “one size fits all”
approach to functionality in order to ensure that a broad range of
possible business functions are met.

15) Employment of the RAD methodology may increase lifetime

system costs through what is frequently perceived as a philosophy of
“code, implement and repair” because of its emphasis on speed of
implementation.
A COTS solution may end up costing far more than anticipated
because system integration can be very difficult and time consuming.
Further, a COTS solution may end up driving the business processes,
rather than the other way around with the business processes driving
the technological solution.

Chapter 2

1) Front-office information systems support business functions that

directly involve customers. Examples include marketing, sales, and
customer relations management information systems. Back-end
information systems support internal business functions and
interactions with suppliers. Examples include human resources,
financial management, manufacturing and inventory control systems.

3) The three goal-oriented perspectives are to:

a.Improve business knowledge, which is a product of information and
data.
b.Improve business processes, which are the significant activities
(including management) that carry out the mission of the organization
c.Improve business communications, which represents how the
system in-terfaces with its users and other information systems, also
the way how people communicate and collaborate with each other.

4) System Owners are concerned with high-level processes or

business functions from a strategic viewpoint.
System Users are concerned with the processes or ‘work’ that must
be performed to provide the appropriate responses to business events
from an operational viewpoint.
System Designers are concerned with the business processes from a
technical viewpoint of which to automate and how best to automate
them.
System Builders are concerned with the business processes from the
technical viewpoint of the programming logic to be used.
System owners, system users, system designers, and system builders
each tend to have a different perspective of the system processes.

5) You should not automatically make changes, even if they appear

obvious, also you should not request approval to add these data
elements directly from the system users, without consulting first with
the systems analyst(s) who developed the requirements document.
You should ensure that any changes to the requirements documents
follow a structured process including the impacted stakeholders before
they are made.

8) Middleware is a layer of utility software that sits between application

soft-ware and systems software to transparently integrate differing
technologies so that they can interoperate. It reduces complexity of
the system, both in the development process and in system
maintenance. Before middleware was developed, applications used
point to point connection to exchange in-formation or data. Middleware
allows each application to only need one in-terface rather than
requiring separate interfaces between each and every application. For
each application it needs to talk to. From a graphic view, the
architecture design resembles a ‘hub and spoke’ model.

10) System owners tend to look at business processes as a big

picture, the high level processes and their impact upon the ability of
the organization to meet its goals and objectives. System users tend
to be concerned with operational aspects, how the system works and
how they interact with it. In the customer self check-in system
scenario, the system owners would probably view the processes from
the standpoint of whether satisfaction of customer will increase while
reducing labor costs. From the perspective of the system users,
customers in this case, the concern would be whether the self
check-in kiosk is easy to use, reliable, and can perform the same
services as a reservations agent.

11) System designers tend to view communications in terms of the

technical design of the user- to/from- system and the
system-to-system interfaces. For the customer self check-in, they
would probably be concerned with how intuitively the system
communicates with the customer, can the customer use the system
quickly and easily the first time with no more than minimal instructions.
System designers would also be concerned with how the check-in
system communicates with the airlines’ reservation and other
systems. System builder’s view of communications is technological
rather than design-oriented, they are concerned with the interface
technology to be used in building the system. For the self check-in
system, they would probably tend to view communications in terms of
the application development environment required to construct the
graphical user interface, also the middleware to be deployed between
the various systems.

13) Dividing knowledge, process and communications into separate

blocks sitting on top of a network technologies building block provides
a modular methodology sometimes called the “clean-layering”
approach. The chief advantage is the inherent modularity of the
framework; anyone of the building blocks can be modified with little or
no impact upon the other blocks.

14) Off-the-shelf systems are generally designed for a wide range of

potential customers, and thus tend to have a corresponding wide
range of features built into the software. Since the initial cost of
development cost is spread among many customers, the purchase
price of an off-the-shelf application is generally substantially less than
the cost of developing a custom application. The systems can be
implemented more quickly because extensive programming is not
required. However, support and upgrades for the off-the-shelf system
depends on the manufacturer’s ongoing success and presence. If the
manufacturer goes out of business, the organization can lose its
technical support and future improvements. It may have to switch to
another product. If the vendor releases an upgrade that is
incompatible with the organization’s current interfaces, the
organization may have to modify its interfaces or live with an
unsupported product when the manufacturer stops providing support
for the old version. Subsequently, a company’s business processes
may have to be modified to fit the software, which means that
business needs may not be met in an optimal fashion. Moreover, there
is a risk that users will be resistant to change in their business
processes which they have been following for years.

15) In a custom-built application, system builders would view the

custom application as something to be built using computer
programming languages or application development software to tools.
With a COTS package, that view would change. The system builder
would focus on the customization that needs to and can be done to
the COTS system, the interface programs that need to be developed
so the COTS system can interoperate with the organization’s other
systems, and on developing applications to extend the functionality of
the COTS system where needed to meet business require-ments.