CIS 320

Chapter 1

Questions PG.36

1. Compare and contrast phases, steps, techniques, and deliverables.

Each phase (planning phase, analysis phase, design phase, and
implementation phase) is broken down into a series of steps. These steps
help with understanding the process of each of these phases. Each step relies
upon techniques to help produce the deliverables (specific documents and
files that provide understanding about the project).

2. Describe the major phases in the SDLC.

a) Planning Phase: this phase is a fundamental process of
understanding why an information system should be built and determined
how the project team will go about building it.
b) Analysis Phase: this phase answers the questions of who will use the
system, what the system will do, and where and when it will be used. During
this phase, the project team investigates any current systems, identifies
improvement opportune

c) Design Phase: this phase decides how the system will operate, in
terms of the hardware, software, and network infrastructure; the user
interface, forms and reports; and the specific programs, databases, and files
that will be needed.

d) Implementation Phase: this phase is the final phase in the SDLC

during which the system is actually built (or purchased, in the case of a
packaged software design). This is the phase that usually gets the most
attention, because for most systems it is longest and most expensive single
part of the development process.

3. Describe the principle steps on the planning phase. What are the
major deliverables?
a) Project Intuition: in this step, the systems business value to the
organization is identified. A system request presents a brief summary of a
business need, and it explains how a system that supports the need will
create business value. The IS department works together with the person or
department that generated the request (called the project sponsor) to
conduct a feasibility analysis. The feasibility analysis examines key aspects of
the proposed project like the technical feasibility, economic feasibility and
organizational feasibility

b) Project Management: this step occurs once the project is approved.

During project management, the project manager creates a work plan, staffs
 the project, and puts techniques in place to help the project team control and
direct the project through the entire SDLC. The deliverable for project
management is a project plan that describes how the project team will go
about developing the system

4. Describe the principal steps in the analysis phase. What are the
major deliverables?
a) Analysis Strategy: is developed to guide the project teams
efforts. Such a strategy usually includes an analysis of the current system
(as-is system) and its problems, and then ways to design a new system (to-be
system).

b) Requirements Gathering: The analysis of this informationin

conjunction with input from project sponsor and many other peopleleads to
the development of a concept for a new system. The system concept is then
used as a basis to develop a set of business analysis models that describes
how the business will operate if the new system were developed

c) System Proposal: The analyses, system concept, and models are

combined into a document called the system proposal, which is presented to
the project sponsor and other key decision makers. The system proposal is
the initial deliverable that describes what business requirements the new
system should meet. This is really the first step in the design of the new
system

5. Describe the principal steps in the design phase. What are the major
deliverables?
a) Design Strategy: this clarifies whether the system will be developed
by the companys own programmers, whether the system will be outsourced
to another firm, or whether the company will buy an existing software
package.

b) Architecture Design: This describes the hardware, software, and

network infrastructure that will be used. In most cases, the system will add or
change the infrastructure that already exists in the organization

c) Database and File Specification: These define exactly what data will
be stored and where they will be stored

d) Program Design: The analyst team develops the program design,

which defines the programs that need to be written and exactly what each
program will do

This collection of deliverables (architecture design, interface design, database

 and file specifications, and program design) is the system specification that is
handed to the programming team for implementation. At the end of the
design phase, the feasibility analysis and project plan are reexamined and
revised, and another decision is made by the project sponsor and approval
committee about whether to terminate the project or continue

6. Describe the principal steps in the implementation phase. What are

the major deliverables?
a) Construction: The system is built and tested to ensure it performs as
designed. Since the cost of bugs can be immense, testing is one of the most
critical steps in implementation.

b) Installation: This is the process by which the old system is turned off
and the new one is turned on. It may include a direct cutover approach, a
parallel conversion approach, or a phased conversion strategy

c) Support Plan: This plan usually includes a formal or informal post-

implementation review, as well as a systematic way for identifying major and
minor changes needed for the system

7. What are the roles of a project sponsor and the approval committee?
Project Sponsor: they could be represented either by an individual or a
department or a team. The project sponsor is from where the request is
generated. They are basically involved though out the various phases of the
SDLC.

a. The IS department works hand in hand with the project sponsor to

conduct a feasibility analysis, be it a technical, organizational or an
economical feasibility
b. During the Analysis phase the project team investigates any current
system, identifies improvement opportunities and develops a concept for the
new system in conjunction with the input from the project sponsor
c. At the end of the design phase the feasibility analysis and the
project plan are reexamined and revised and the decision whether the project
is to continue or terminated is made by the project sponsor along with the
approval committee
d. The key deliverables for each phase are typically very long and are
presented to the project sponsor for approval as the project moves from
phase to phase
e. The project sponsor approves the key deliverables for each phase
only after which the project moves from phase to phase
f. The project sponsor along with the users provides valuable
comments which are used to re-analyze, re-design and re-implement a
 second prototype which provides few more features

Approval Committee: Sometimes referred to as the steering committee is the

final decision maker regarding the fate of the project after carefully reviewing
the system request, feasibility analysis, system proposal, etc.

a. In planning phase after feasibility analysis the approval committee

decides whether the project should be undertaken
b. After Analysis the system proposal is forwarded to the approval
committee to decide whether the project should continue to move forward
c. During the Design phase the feasibility analysis and project plan are
reexamined and the approval committee will decide whether to terminate or
continue with the project

8. What does gradual refinement mean in the context of SDLC?

Generally, the clarity of understanding and the depth of detail of the new
system are gradually refined during the phases of the SDLC. Initially, the
requirements are only vaguely understood. This understanding is improved
during the Analysis phase. Further detail is developed during Design, and
then is fully expressed during Implementation

9. Compare and contrast process-centered methodologies with data-

centered methodologies.
Process-centered Methodologies: Process-centered methodologies emphasize
process models as the core of the system concept. Example: Process-
centered methodologies would focus first on defining the processes (e.g.,
assemble sandwich ingredients).

Data-centered Methodologies: Data-centered methodologies emphasize data

models as the core of the system concept. Example: Data centered
methodologies would focus first on defining the contents of the storage areas
(e.g., refrigerator) and how the contents were organized.

10. Compare and contrast structured design-based methodologies

in general to RAD-based methodologies in general.
Structured design methodologies are usually fairly formal, step-by-step
approaches to systems development. The project moves through the phases
in a systematic way. The emphasis in most of these methodologies is
development of paper-based specifications for the new system prior to
implementation. RAD methodologies, on the other hand, tend to emphasize
quick creation of a limited-capability version of the system or a model of the
system. These methodologies focus on refining this preliminary system or
 model rather than trying to fully describe it on paper prior to implementation

11. Compare and contrast extreme programming and throwaway

prototyping.
Extreme Programming (XP): Extreme Programming is founded on four core
values which provide a foundation on which XP developers use to create any
system. The four core values are Communication, Simplicity, Feedback and
Courage

Throwaway Programming: Throwaway prototyping-based methodologies

balance the benefits of well thought out analysis and design phases with the
advantages of using prototypes to refine key issues before a system is built.
Each of these issues is examined by analyzing, designing, and building a
design prototype

12. Describe the major elements and issues with waterfall

development.
Waterfall Development follows the phases of the life cycle in sequence
(Planning, Analysis, Design, and Implementation). Each phase is thoroughly
documented and approval is required before proceeding to the subsequent
phase. It is difficult, though not impossible, to go backwards in the SDLC
under Waterfall Development.
Waterfall Development requires that the system requirements be precisely
specified prior to implementation and also often "freezes" those requirements
during development. The high degree of effort devoted to specifying user
requirements is a strength of Waterfall Development but specifying those
requirements on paper is laborious and may lead to errors and omissions.
"Freezing" the requirements during development helps assure that the
system is developed according to specifications, but in a dynamic business
environment, the system that is ultimately developed may bear little
resemblance to what is actually needed at the time the project is completed.
Therefore, extensive maintenance may be needed after implementation to
revise the system to meet current conditions.

The two key advantages of the structured design waterfall approach are that:
- It identifies system requirements long before programming begins
- It minimizes changes to the requirements as the project proceeds
The two key disadvantages are that:
- The design must be completely specified before programming begins
- A long time elapses between the completion of the system proposal
in the analysis phase and the delivery of the system.

13. Describe the major elements and issues with parallel

development.
 The parallel development methodology attempts to address the problem of
long delays between the analysis phase and the delivery of the system.
Instead of doing design and implementation in sequence, it performs a
general design for the whole system and then divides the project into a series
of distinct subprojects that can be designed and implemented in parallel.
Once all subprojects are complete, there is a final integration of the separate
pieces, and the system is delivered

The major issues in this approach are that it still suffers from problems
caused by paper documents. It also adds a new problem such as sometimes
the subprojects are not completely independent; design decisions made in
one subproject may affect another, and the end of the project may require
significant integration efforts

14. Describe the major elements and issues with phased

development.
Phased Development is a RAD methodology that does not attempt to develop
the complete system initially. Instead, the system is generally specified. User
requirements are organized into a series of versions. The first version
includes the essential system components and is delivered to the users
quickly. Subsequent versions add features and refinements to the system
based on the initial specification plus the users' feedback and reaction to
using the system

The critical issue with Phased Development is to accurately specify the initial
requirements so that the first version provided to the users is useful, although
incomplete. If this is done well, Phased Development will provide value to the
organization by getting the users a system to use quickly. New requirements
may be identified through user feedback as well, which improves the "fit" of
the system to the business needs

15. Describe the major elements and issues with prototyping.

A prototyping-based methodology performs the analysis, design, and
implementation phases concurrently, and all three phases are performed
repeatedly in a cycle until the system is completed. Prototype is usually the
first part of the system that the user will use and the key advantage of a
prototyping-based methodology is that it very quickly provides a system for
the users to interact with, even if it is not ready for widespread organizational
use at first.

The major problem with prototyping is that its fast-paced system releases
challenge attempts to conduct careful, methodical analysis. Often the
prototype undergoes such significant changes that many initial design
decisions become poor ones. This can cause problems in the development of
 complex systems because fundamental issues and problems are not
recognized until well into the development process

Example: Imagine building a car and discovering late in the prototyping

process that you have to take the whole engine out to change the oil
(because no one thought about the need to change the oil until after it had
been driven 10,000 miles).

16. Describe the major elements and issues with throwaway

prototyping.
In throw-away prototyping, there is a more careful and rigorous analysis
performed as compared to Prototyping (more similar to the traditional SDLC).
However, in the Design phase, models of various elements of the system are
developed to help explore design alternatives and refine system
requirements. These prototypes help users clarify their needs, options, and
priorities. Once user requirements are established through reaction to the
design prototype, it is discarded; however, the requirements it embodied are
incorporated into the new system

Throw-away prototyping is very useful in situations where users are uncertain

about key elements of the system. Throw-away prototypes can help focus
users on design issues and improve understanding of business needs. The
approach helps create a system that suits the users needs even though those
needs may have been poorly understood initially

17. Need
18. Need

19. What are the key factors in selecting a methodology?

There are several factors that influence the choice of a methodology.
- Clarity of the user requirements
- Familiarity with the base technology
- System complexity
- Need for system reliability
- Time pressure
- Need to see progress on the time schedule

20. Need

21. Compare and contrast the role of a systems analyst, business

analyst, and infrastructure analyst.
These three roles emphasize different perspectives on the system. The
business analyst represents the sponsor/users interests, while the systems
analyst knows how to apply IS to support business needs. Together, the
systems analyst and the business analyst can design a system that conforms
 to the IS standards while adding value to the business. The infrastructure
analyst has more technical knowledge and provides the team with technical
constraints, or identifies infrastructure changes that the new system will
require.

System Analyst Roles:

- Identifying how technology can improve business processes
- Designing the new business processes
- Designing the information system
- Ensuring that the system conforms to information systems standards

Business Analyst Roles:

- Analyzing the key business aspects of the system
- Identifying how the system will provide business value
- Designing the new business processes and policies

Infrastructure Analyst Roles:

- Ensuring the system conforms to infrastructure standards
- Identifying infrastructure changes needed to support the system
22. 22. What is the difference between classes and objects?

A class is the general template we use to define and create specific

instances, or objects. Every object is associated with a class. If we were
building an appointment system for a doctors office, classes might include
Doctor, Patient, and Appointment.

An object is an instantiation of a class. In other words, an object is a person,

place, or thing about which we want to capture information. The specific
patients, such as Jim Maloney, Mary Wilson, and Theresa Marks, are
considered instances, or objects, of the patient class.

23. 23. What are methods and messages?

Methods implement an objects behavior. A method is nothing more than an

action that an object can perform.

Messages are information sent to objects to trigger methods. A message is

essentially a function or procedure call from one object to another object.

24. 24. Why are encapsulation and information hiding important

characteristics of object-oriented systems?

Encapsulation is the mechanism that combines the processes and data into
a single object. Information hiding suggests only the information required
to use an object be available outside the object. How the object stores data
or performs methods is not relevant, as long as the object functions correctly.
All that is required to use an object are the set of methods and the messages
 needed to be sent to trigger them. The fact that we can use an object by
sending a message that calls methods is the key to reusability because it
shields the internal workings of an object from the outside system. It keeps
the systems from being affected when changes are made to an object.
25.25) What is meant by polymorphism when applied to object-oriented systems?

Object-oriented systems focus on capturing the structure and behavior of

information systems in little modules that encompass both data and process.
These little modules are known as objects. The basic characteristics of a object-
oriented system include classes, objects, methods, messages, encapsulation,
information hiding, inheritance, polymorphism, and dynamic binding.
Polymorphism means that the same message can be interpreted differently by
different classes of objects. For example, inserting a patient means something
different than inserting an appointment. As such, different pieces of information
need to be collected and stored. Luckily, we do not have to be concerned with
how something is done when using objects. We can simply send a message to
an object ,and that object will be responsible for interpreting the message
appropriately.

26.26) Compare and contrast dynamic and static binding

Dynamic Binding: Dynamic, or late, binding is a technique that delays typing

the object until run-time. As such, the specific method that is actually called is not
chosen by the object-oriented system until the system is running. Static Binding:
This is a contrast to Dynamic binding. In a statically bound system ,the type of
object would be determined at compile time. Therefore, the developer would have
to choose which method should be called instead of allowing the system to do it.

27. What is a use case?

Use case diagrams allow the analyst to model the interaction of an
information system and its environment. The environment of an information
system includes both the end user and any external system that interacts
with the information system. The primary use of the use case diagram is to
provide a means to document and understand the requirements of the
evolving information system. Use cases and use case diagrams are some of
the most important tools that are used in object-oriented systems analysis
and design
28. What is meant by use-case driven?
Use-case driven means that use cases are the primary modeling tool to
define the behavior of the system. A use case describes how the user
interacts with the system to perform some activity, such as placing an order,
making a reservation, or searching for information. The use cases are used to
identify and to communicate the requirements for the system to the
programmers who must write the system. Use cases are inherently simple
because they focus on only one activity at a time

29. What is the Unified Modeling Language?

Until 1995, object concepts were popular but implemented in many different
ways by different developers. Each developer had his or her own
methodology and notation (e.g. Booch, Coad, Moses, OMT, OOSE, and SOMA).
Then in 1995, Rational Software brought three industry leaders together to
create a single approach to object-oriented systems development. Grady
Booch, Ivar Jacobson, and James Rumbaugh worked with others to create a
standard set of diagramming techniques known as the Unified Modeling
Language (UML). The objective of UML is to provide a common vocabulary of
object oriented terms and diagramming technique that is rich enough to
model any systems development project from analysis through
implementation

It was accepted as the standard for object developers in November 1997 by

the Object Management Group (OMG) and in2003, its version2.0 was
accepted as OMG. The Version 2.0 of the UML defines a set of fourteen
diagramming techniques used to model a system. The diagrams are broken
into two major groupings:

a) One for modeling structure of a system: The structure modeling

diagrams include class, object, package, deployment, component, and
composite structure diagrams.

b) One for modeling behavior: The behavior modeling diagrams include

activity, sequence, communication, interaction overview, timing, behavior
state machine, protocol state machine, and use case diagrams.

Overall, the consistent notation, integration among the diagramming

techniques, and the application of the diagrams across the entire
development process makes the UML a powerful and flexible language for
analysts and developers

30. Who is the Object Management Group?

The Object Management Group (OMG) is an international non-profit
organization supported by information systems vendors, software developers
 and users. OMG was founded in 1989, now has over 600 member
organizations, and meets bi-monthly. OMG provides a widely supported
framework for open, distributed, interoperable, scaleable, reusable, portable
software components based on OMG-standard object-oriented interfaces.
Objectives of the OMG architecture are:

a) To benefit application developers by making it much easier for

developers to build large-scale, industrial strength applications from a widely
available toolkit of standard components.

b) To benefit end-users by providing a common semantics that goes far

beyond the notion of a common look-and-feel in today's desktop applications

31. What is the primary purpose of structure diagrams? Give some

examples of structure diagrams.
Structure diagrams include the class, object, package, deployment,
component, and composite structure diagrams. Structure diagrams provide a
way for representing the data and static relationships that are in an
information system

Structured Diagrams:

Diagram Name Used To Primary Phase

Class Illustrate the relationships Analysis, Design
between classes modeled in the
system.
Object Illustrate the relationships Analysis, Design
between objects modeled in the
system.
Used when actual instances of
the classes will better
communicate
the model.
Package Group other UML elements Analysis, Design,
together to form higher level Implementation
constructs.
Deployment Show the physical architecture Physical Design,
of the system. Can also be used Implementation
to show software components
being deployed onto the
physical architecture.
Component Illustrate the physical Physical Design,
relationships among the Implementation
software components
Composite Structure Illustrate the internal structure Analysis, Design
of a class, i.e., the relationships
among
the parts of a class
32. For what are behavior diagrams used? Give some examples of
behavior diagrams.
The behavior diagrams included in UML 2.0 are the activity, sequence,
communication, interaction overview, timing, behavior state machine,
protocol state machine, and use case diagrams. Behavior modeling diagrams
provide the analyst with a way to depict the dynamic relationships among the
instances or objects that represent the business information system. They
also allow the modeling of the dynamic behavior of individual objects
throughout their lifetime. The behavior diagrams support the analyst in
modeling the functional requirements of an evolving information system.

Behavior Diagram Examples:

Diagram Name Used To Primary Phase

Activity Illustrate business workflows Analysis Design
independent of classes, the flow
of activities in a use case, or
detailed design of a method
Sequence Mode the behavior of objects Analysis Design
within a use case. Focuses on
the time-based ordering of an
activity
Communication Model the behavior of objects Analysis Design
within a use case. Focuses on
the communication among a set
of collaborating objects of an
activity
Interactive Overview Illustrate an overview of the flow Analysis Design
of control of a process.
Timing Illustrate the interaction that Analysis Design
takes place among a set of
objects and the state changes in
which they go through along a
time axis
Behavioral State Machine Examine the behavior of one Analysis Design
class
Protocol State Machine Illustrates the dependencies Analysis Design
among the different interfaces
of a class
Use-Case Capture business requirements Analysis Design
for the system and to illustrate
the inter-action between the
system and its environment

33. Why is it important for an OOSAD approach to be architecture

centric?
 Any modern approach to systems analysis and design should be architecture
centric. Architecture centric means that the underlying software architecture
of the evolving system specification drives the specification, construction,
and documentation of the system. Modern object-oriented systems analysis
and design approaches should support at least three separate but
interrelated architectural views of a system: functional, static, and dynamic.

a) The functional view describes the external behavior of the system

from the perspective of the user. Use cases and use case diagrams are the
primary approach used to depict the functional view. Also, in some cases,
activity diagrams are used to supplement use cases
b) The static view describes the structure of the system in terms of
attributes, methods, classes, and relationships. The structure diagrams
portray the static view of an evolving object-oriented information system

c) The dynamic view describes the internal behavior of the system in

terms of messages passed among objects and state changes within an
object. The dynamic view is represented in UML by behavior diagrams

34. Why does it mean for an OOSAD approach to be incremental

and iterative?
Object-oriented systems analysis and design approaches emphasize iterative
and incremental development that undergoes continuous testing and
refinement throughout the life of the project. Each iteration of the system
brings it closer and closer to real user needs. OOSAD allows the analyst to
decompose complex problems into smaller, more manageable components
using a commonly accepted set of notations. Also, many people believe that
users do not think in terms of data or processes but instead think in terms of
a collection of collaborating objects. As such, object-oriented systems
analysis and design allows the analyst to interact with the user using objects
from the users environment instead of a set of separate processes and data

35. What are the phases and workflows of the Unified Process?
The Unified Process is a specific methodology that maps out when and how to
use the various UML techniques for object-oriented analysis and design.
Whereas the UML provides structural support for developing the structure
and behavior of an information system, the Unified Process provides the
behavioral support. The Unified Process, of course, is use-case driven,
architecture centric, and iterative and incremental.

The Unified Process is a two-dimensional systems development process

described by a set of phases and workflows.

a) Phases: The phases of the Unified Process support an analyst in

 developing information systems in an iterative and incremental manner. Each
phase has objectives, a focus of activity over the workflows, and incremental
deliverables
- Inception
- Elaboration
- Construction
- Transition

b) Workflows: The workflows describe the tasks or activities that a

developer performs to evolve an information system over time. The
workflows of the Unified Process are grouped into two broad categories:
engineering and supporting
- Engineering workflows: The engineering workflows include
business modeling, requirements, analysis, design, implementation, test, and
deployment workflows. The engineering workflows deal with the activities
that produce the technical product (i.e., the information system)
- Supporting workflows: The supporting workflows include the
project management, configuration and change management, and the
environment workflows. The supporting workflows focus on the managerial
aspects of information system development.

36. Compare the phases of the Unified Process with the phases of
the waterfall model.
The Unified Process: is a specific methodology that maps out when and how
to use the various UML techniques for object-oriented analysis and design.
The Unified Process is a two-dimensional systems development process
described by a set of phases and workflows. The phases are inception,
elaboration, construction, and transition. The workflows include business
modeling, requirements, analysis, design, implementation, test, deployment,
project management, configuration and change management, and
environment.

The phases of the Unified Process support an analyst in developing

information systems in an iterative and incremental manner. The phases
describe how an information system evolves through time. Depending on
which development phases the evolving system is currently in, the level of
activity will vary over the workflows. Each phase has objectives, a focus of
activity over the workflows, and incremental deliverables.

- Inception: During the interception phase, a complete feasibility

analysis is done which determines whether the project needs to be
undertaken or not
- Elaboration: The primary deliverables of this phase would be to
include the UML structure and diagrams and to provide an executable of an
 baseline version of the evolving information system
- Construction: The construction phase, as expected by its name,
is heavily focused on programming the evolving information system.
- Transition: The primary focus of this phase is on testing and
deployment workflows

Waterfall Development: is the original structured design methodology (that is

still used today) is waterfall development. With waterfall developmentbased
methodologies, the analysts and users proceed in sequence from one phase
to the next. The key deliverables for each phase are typically very long (often
hundreds of pages in length) and are presented to the project sponsor for
approval as the project moves from phase to phase. Once the sponsor
approves the work that was conducted for a phase, the phase ends and the
next one begins. This methodology is referred to as waterfall development
because it moves forward from phase to phase in the same manner as a
waterfall.

As you can see, both the phases of the Unified Process and the Waterfall
development, follow a certain flow. They progress step by step and eventually
meet the requirement

37. Which phase in the SDLC is most important? Why?

All systems development projects follow essentially the same fundamental
process called the system development life cycle (SDLC). The planning phase
in SDLC is the most important phase because during this phase the project
team identifies the business value of the system, conducts a feasibility
analysis, and plans the project. This phase is the fundamental process of
understanding why an information system should be built and determining
how the project team will go about building it

38. Describe the major elements and issues with an object-

oriented approach to developing information systems.
Object-oriented approaches to developing information systems can use any
of the traditional methodologies such as the waterfall development, parallel
development etc. However, the object-oriented approaches are most
associated with a phased development RAD methodology. The primary
difference between a traditional approach such as structured design and an
object-oriented approach is how a problem is decomposed. In traditional
approaches, the problem decomposition process is either process-centric or
data-centric.

a) Use-Case Driven: A use case describes how the user interacts with
the system to perform some activity, such as placing an order, making a
reservation, or searching for information
 b) Architecture-centric: Architecture centric means that the underlying
software architecture of the evolving system specification drives the
specification, construction, and documentation of the system

c) Iterative and Incremental: Modern object-oriented systems analysis

and design approaches emphasize iterative and incremental development
that undergoes continuous testing and refinement throughout the life of the
project. Each iteration of the system brings it closer and closer to real user
needs