PASSI CITY COLLEGE

City of Passi, Iloilo

SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

COURSE NUMBER: IT ELECT 1

COURSE TITLE: System Analysis and Design
MODULE: 2

OVERVIEW:

Systems Analysis and Design (SAD) is an exciting, active field in which analysts continually
learn new techniques and approaches to develop systems more effectively and efficiently.
However, there is a core set of skills that all analysts need to know no matter what approach
or methodology is used. All information systems projects move through the four phases of
planning, analysis, design, and implementation; all projects require analysts to gather
requirements, model the business needs, and create blueprints for how the system should be
built; and all projects require an understanding of organizational behavior concepts like change
management and team building.

MODULE OUTCOMES

At the end of this module, the students must have:

 Explain the role played in information systems development by the systems analyst
 Describe the fundamental systems development life cycle and its four phases
 Explain how organizations identify IS development projects
 Explain the importance of linking the information system to business needs
 Be able to create a system request
 Describe technical, economic, and organizational feasibility assessment

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 1

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 INTRODUCTION
Most IT departments face a demand for IT projects that far exceeds the depart-
ment’s ability to supply them. In the past 10 years, business application growth has
exploded, and chief information officers (CIOs) are challenged to select projects that
will provide the highest possible return on IT investments while managing project
risk. In a recent analysis, AMR Research Inc. found that 2% –15% of projects taken
on by IT departments are not strategic to the business.1 In today’s globally
competitive business environment, the corporate IT department needs to carefully
prioritize, select, and manage its portfolio of development projects.
Historically, IT departments have tended to select projects by ad hoc methods:
first-in, first-out; political clout; or the squeaky wheel getting the grease. In recent
years, IT departments have collected project information and mapped the projects’
contributions to business goals, using a project portfolio perspective.2 Project
port¬folio management, a process of selecting, prioritizing, and monitoring project
results, has become a critical success factor for IT departments facing too many
potential projects with too few resources.3 Software for project portfolio
management, such as Hewlett Packard’s Project and Portfolio Management,
Primavera Systems’ ProSight, and open-source Project.net, has become a valuable
tool for IT organizations.
Once selected, a systems development project undergoes a thorough process of
project management, the process of planning and controlling the project within a
spec¬ified time frame, at minimum cost, with the desired outcomes.4 A project
manager has the primary responsibility for managing the hundreds of tasks and
roles that need to be carefully coordinated. Project management has evolved into an
actual profession with many training options and professional certification (e.g.,
Project Management Pro¬fessional, or PMP) available through the Project
Management Institute (www.pmi.org). Dozens of software products are available to
support project management activities.
Although training and software are available to help project managers,

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 2

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 unrea¬sonable demands set by project sponsors and business managers can make
project management very difficult. Too often, the approach of the holiday season,
the chance at winning a proposal with a low bid, or a funding opportunity pressures
project managers to promise systems long before they are realistically able to
deliver them. These overly optimistic timetables are thought to be one of the
biggest problems that projects face; instead of pushing a project forward faster,
they result in delays.
Thus, a critical success factor for project management is to start with a real¬istic
assessment of the work that needs to be accomplished and then manage the project
according to the plan. This can be accomplished by carefully following the basic
steps of project management as outlined in this chapter. First, the project
man¬ager chooses a system development methodology that fits the characteristics
of the project. Based on the size of the system, estimates of a time frame are made.
Then, a list of tasks to be performed is created that forms the basis of the project
work plan. Staffing needs are determined, and the project manager sets in place
mecha¬nisms to coordinate the project team throughout the project. Finally, the
project manager monitors the project and refines estimates as work proceeds.
C ONC EP TS 2-A PROJECT PORTFOLIO MANAGEMENT: AN ESSENTIAL TOOL FOR IT DEPARTMENTS
IN ACTION

Information systems are at the core of underway and those that are awaiting approval. The soft-
Sabre Holdings Corporation. The Sabre reservation system is ware helps prioritize projects, allocate employees, moni-
the booking system of choice for travel agencies worldwide. tor projects in real time, flag cost and time variances,
Sabre is also the parent company of Travelocity. com, the measure the ROI, and help the IT department objectively
second largest online travel agency in the United States. measure the efficiency and efficacy of IT investments.
Like many companies, Sabre’s IT department strug- Primavera Systems’ PPM software has enabled
gles with many more project requests than it has resources Sabre Holdings to update its queue of projects regularly,
to accomplish—as many as 1500 proposals for 600 funded and projects are now prioritized quarterly instead of
projects annually. Because of the volatile, competitive annually. A study of users of Hewlett Packard’s PPM Cen-
nature of the travel industry, Sabre is especially challenged ter software found that in all cases, the investment in the
to be certain that IT is doing the right projects under software paid for itself in a year. Other findings were an
constantly changing conditions. While traditional project average 30% increase in on-time projects, a 12% reduction
management techniques focus on getting individual in budget variance, and a 30% reduction in the amount of
projects done, Sabre needs to be able to rapidly change time IT spent on project reporting.
the entire set of projects it’s working on as market
conditions shift. Sources: Tucci, Linda, “Project portfolio management takes
flight at Sabre,“ SearchCIO.com, November 28, 2007.
Project portfolio management software collects and
manages information about all projects—those that are Tucci, Linda, “PPM strategy a CIO’s must-have in hard times,”
SearchCIO.com, March 5, 2008.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 3

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 PROJECT SELECTION
Many IT organizations tackle a number of important initiatives simultaneously. For
example, new software applications may be under development; new business
models may be under consideration; organizational structures may be revised; new
technical infrastructures may be evaluated. Collectively, these endeavors are
man¬aged as a program by the IT steering committee. The steering committee
must provide oversight and governance to the entire set of projects that are
undertaken by the IT organization. The individual projects that are accepted by the
steering committee are temporary endeavors undertaken to create a unique product
or service.
Investments in information systems projects today are evaluated in the context of
an entire portfolio of projects. Decision makers look beyond project cost and
consider a project’s anticipated risks and returns in relation to other projects.
Com¬panies prioritize their business strategies and then assemble and assess
project port¬folios on the basis of how they meet those strategic needs.
The focus on a project’s contribution to an entire portfolio of projects rein¬forces
the need for the feasibility study as described in Chapter 1. The approval committee
has the responsibility to evaluate not only the project’s costs and expected benefits,
but also the technical and organizational risks associated with the project. The
feasibility analysis is submitted back to the approval committee, along with an
updated system request. Using this information, the approval committee can
exam¬ine the business need (found in the system request) and the project risks
(described in the feasibility analysis).
Portfolio management takes into consideration the different kinds of projects that
exist in an organization—large and small, high risk and low risk, strategic and
tactical.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 4

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 Size What is the size? How many people are needed to work on the
project?
Cost How much will the project cost the organization?
Purpose What is the purpose of the project? Is it meant to improve the
technical infrastructure? support a current business strategy?
improve operations? demonstrate a new innovation?
Length How long will the project take before completion? How much
time will go by before value is delivered to the business?
Risk How likely is it that the project will succeed or fail?
Scope How much of the organization is affected by the system? a
department? a division? the entire corporation?
Economic Value How much money does the organization expect to receive in
FIGURE 2-1 return for the amount the project costs?
Ways to Classify Projects

(See Figure 2-1 for different ways of classifying projects.) A good project portfolio
will have the most appropriate mix of projects for the organization’s needs. The
committee acts as a portfolio manager, with the goal of maximizing benefits versus
costs and bal¬ancing other important factors of the portfolio. For example, an
organization may want to keep high-risk projects to a level less than 20% of its total
project portfolio.
The approval committee must be selective about where to allocate resources,
because the organization has limited funds. This involves trade-offs in which the
organization must give up something in return for something else in order to keep
its portfolio well balanced. If there are three potentially high-payoff projects, yet all
have very high risk, then maybe only one of the projects will be selected. Also, there
are times when a system at the project level makes good business sense, but it
does not at the organization level. Thus, a project may show a very strong economic
feasibility and support important business needs for a part of the company;
how¬ever, it is not selected. This could happen for many reasons—because there is
no money in the budget for another system, the organization is about to go through
some kind of change (e.g., a merger, an implementation of a company-wide system

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 5

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 like an ERP), projects that meet the same business requirements already are
under¬way, or the system does not align well with current or future corporate
strategy.

Applying the Concepts at Tune Source

The approval committee met and reviewed the Digital Music Download project
along with two other projects—one that called for a new supply-chain portal and
another that involved the enhancement of Tune Source’s data warehouse.
Unfortunately, the budget would allow for only one project to be approved, so the
committee carefully examined

YOUR 2-1 TO SELECT OR NOT TO SELECT

TURN

It seems hard to believe that an have worked for or know about. Describe a scenario in approval
committee would not select a project that meets which a project may be very attractive at the project real business
needs, has a high potential ROI, and has a level, but not at the organization level.
positive feasibility analysis. Think of a company that you

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 6

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 YOUR 2-2 PROJECT SELECTION
T U R N

In April 1999, one of Capital Blue processing claims, for instance, the program would pull
Cross’ health-care insurance plans had been in the field for out up-to-the-minute data at a given point in time for users
three years, but hadn’t performed as well as expected. The to analyze.
ratio of premiums to claims payments wasn’t meeting The third alternative was to develop a decision-
historic norms. In order to revamp the product features or support system to allow users to make relational queries
pricing to boost performance, the company needed to from a data mart containing a replication of the relevant
understand why it was underperforming. The stakehold- claims and customer data.
ers came to the discussion already knowing they needed Each of these alternatives was evaluated on cost,
better extraction and analysis of usage data in order to benefits, risks, and intangibles.
understand product shortcomings and recommend
improvements. QUESTION:
After listening to input from the user teams, the stake- 1. What are three costs, benefits, risks, and intangibles
holders proposed three options. One was to persevere associated with each project?
with the current manual method of pulling data from flat 2. Based on your answer to question 1, which project
files via ad hoc reports and retyping it into spreadsheets. would you choose?
The second option was to write a program to
dynamically mine the needed data from Capital’s customer Source: “Capital Blue Cross,” CIO Magazine, February 15,
2000, by Richard Pastore.
information control system (CICS). While the system was

the costs, expected benefits, risks, and strategic alignment of all three projects.
Cur¬rently, top management is anxious to bring the digital music download
capability to market in order to satisfy the demands of its existing customers and
potentially expand its customer base. The Digital Music Download project is best
aligned with that goal. Therefore, the committee decided to fund the Digital Music
Download project

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 7

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 2-B INTERVIEW WITH LYN MCDERMID, CIO, DOMINION VIRGINIA POWER

My second role is to push innovation that creates

value for the business. I manage this by looking at our
lines of business and asking which lines of business create
the most value for the company. These are the areas for
which I should be providing the most value. For example, if
we had a highly innovative marketing strategy, I would
push for innovation there. If operations were running
smoothly, I would push less for innovation in that area.
My third role is strategic, to look beyond today and
find new opportunities for both IT and the business of
providing energy. This may include investigating process
systems, such as automated meter reading or looking into
the possibilities of wireless technologies.
L/n Muoearid

the costs, expected benefits, risks, and strategic alignment of all three projects.
Cur¬rently, top management is anxious to bring the digital music download
capability to market in order to satisfy the demands of its existing customers and
potentially expand its customer base. The Digital Music Download project is best
aligned with that goal. Therefore, the committee decided to fund the Digital Music
Download project

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 8

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 CO NCEPTS 2-C INTERVIEW WITH CARL WILSON, CIO, MARRIOTT CORPORATION
IN ACTION

At Marriott, we don’t have IT projects— Therefore, business projects are proposed, and IT
we have business initiatives and strategies that are is one component of them. These projects are then evaluated
enabled by IT. As a result the only time a traditional “IT the same as any other business proposal, such as a new
project” occurs is when we have an infrastructure resort—by examining the return on investment and other
upgrade that will lower costs or leverage better function- financial measures.
ing technology. In this case, IT has to make a business At the organizational level, I think of projects as must-
case for the upgrade and prove its value to the company. do’s, should-do’s, and nice-to-do’s. The “must-do’s” are
The way IT is involved in business projects in the required to achieve core business strategy, such as guest
organization is twofold. First, senior IT positions are filled preference. The “should-do’s” help grow the business and
by people with good business understanding. Second, enhance the functionality of the enterprise. These can be
these people are placed on key business committees and somewhat untested, but good drivers of growth. The “nice-
forums where the real business happens, such as finding to-do’s” are more experimental and look further out into
ways to satisfy guests. Because IT has a seat at the table, the future.
we are able to spot opportunities to support business The organization’s project portfolio should have a
strategy. We look for ways in which IT can enable or bet- mix of all three kinds of projects, with a much greater pro-
ter support business initiatives as they arise. portion devoted to the “must-do’s.” Carl W ilson

CO NCEPTS 2-D A PROJECT THAT DOES NOT GET SELECTED

IN ACTION

Hygeia Travel Health is a Toronto- would allow Hygeia to recommend the less expensive
based health insurance company whose clients are the hospital to its customer. That would save the customer
insurers of foreign tourists to the United States and Canada. money and help differentiate Hygeia from its competitors.
Its project selection process is relatively straightforward. The benefits team used the same three-meeting
The project evaluation committee, consisting of six senior process to discuss all the possible benefits of implement-
executives, splits into two groups. One group includes the ing the claims database. Members of the team talked to
CIO, along with the heads of operations and research and customers and made a projection by using Hygeia’s past
development, and it analyzes the costs of every project. experience and expectations about future business
The other group consists of the two chief marketing officers trends. The verdict: The benefits team projected a rev-
and the head of business development, and they analyze enue increase of $210,000. Client retention would rise by
the expected benefits. The groups are permanent, and to 2%, and overall, profits would increase by 0.25%.
stay objective, they don’t discuss a project until both sides The costs team, meanwhile, came up with large
have evaluated it. The results are then shared, both on a estimates: $250,000 annually to purchase the database
spreadsheet and in conversation. Projects are then and an additional $71,000 worth of internal time to make
approved, passed over, or tabled for future consideration. the information usable. Put it all together and it was a
Last year, the marketing department proposed pur- financial loss of $111,000 in the first year.
chasing a claims database filled with detailed information The project still could have been good for marketing—
on the costs of treating different conditions at different facil- maybe even good enough to make the loss acceptable.
ities. Hygeia was to use this information to estimate how But some of Hygeia’s clients were also in the claims infor-
much money insurance providers were likely to owe on a mation business and, therefore, potential competitors. This,
combined with the financial loss, was enough to make the
given claim if a patient was treated at a certain hospital as
company reject the project.
opposed to any other. For example, a 45-year-old man suf-
fering a heart attack may accrue $5000 in treatment costs Source: “Two Teams Are Better Than One,” CIO Magazine, July
at hospital A, but only $4000 at hospital B. This information 15, 2001, by Ben Worthen.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 9

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 CREATING THE PROJECT PLAN
Once the project is launched by being selected by the approval committee, it is time
to carefully plan the project. The project manager will follow a set of project man-
agement guidelines, sometimes referred to as the project management life cycle, as
he or she organizes, guides, and directs the project from inception to completion.
Generally speaking, the project management phases consist of initiation, planning,
execution, control, and closure.
In large organizations or on large projects, the role of project manager is com-
monly filled by a professional specialist in project management. In smaller organiza-
tions or on smaller projects, the systems analyst may fill this role. The project manager
must make a myriad of decisions regarding the project, including determining the best
project methodology, developing a work plan for the project, determining a staffing
plan, and establishing mechanisms to coordinate and control the project.

Project Methodology Options

As we discussed in Chapter 1, the Systems Development Life Cycle (SDLC) provides
the foundation for the processes used to develop an information system. A method-
ology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and
deliverables). There are many different systems development methodologies, and they
vary in terms of the progression that is followed through the phases of the SDLC.
Some methodologies are formal standards used by government agencies, while others
have been developed by consulting firms to sell to clients. Many organizations have
their own internal methodologies that have been refined over the years, and they
explain exactly how each phase of the SDLC is to be performed in that company. Here
we will review several of the predominant methodologies that have evolved over time.

Waterfall Development With waterfall development, analysts and users proceed

sequentially from one phase to the next. (See Figure 2-2.) The key deliverables for
each phase are typically voluminous (often, hundreds of pages) and are presented

Planning

Analysis

Design

Implementation

FIGURE 2-2 System

Waterfall Development

to the approval committee and project sponsor for approval as the project moves

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 10

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 from phase to phase. Once the work produced in one phase is approved, the phase
ends and the next phase begins. As the project progresses from phase to phase, it
moves forward in the same manner as a waterfall. While it is possible to go
backward through the phases (e.g., from design back to analysis), it is quite
difficult. (Imagine yourself as a salmon trying to swim upstream in a waterfall).
Waterfall development methodologies have the advantages of identifying
requirements long before programming begins and limiting changes to the
require¬ments as the project proceeds. The 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 system, and testing is treated almost as an afterthought in the
implementation phase. In addi¬tion, the deliverables are often a poor
communication mechanism, so important requirements may be overlooked in the
volumes of documentation. If the project team misses an important requirement,
expensive post-implementation programming may be needed. Users may forget the
original purpose of the system, since so much time has elapsed between the original
idea and actual implementation. Also, in today’s dynamic business environment, a
system that met the existing environmental condi¬tions during the analysis phase
may need considerable rework to match the environ¬ment when it is implemented.
This rework requires going back to the initial phase and making needed changes
through each of the subsequent phases in turn.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 11

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 There are two important variants of waterfall development. The parallel devel¬opment
methodologies evolved to address the lengthy time frame of waterfall devel¬opment. As shown in
Figure 2.3, instead of doing the design and implementation in sequence, a general design for the
whole system is performed. Then the project is divided into a series of 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.
Parallel development reduces the time required to deliver a system, so changes in the business
environment are less likely to produce the need for rework. The approach still suffers from problems
caused by voluminous deliverables. It also adds a new problem: If the subprojects are not
completely independent, design decisions in one subproject may affect another, and at the project
end, integrating the subprojects may be quite challenging.
The V-model is another variation of waterfall development that pays more explicit attention to
testing. As shown in Figure 2.4, the development process pro¬ceeds down the left-hand slope of
the V, defining requirements and designing sys¬tem components. At the base of the V, the code is
written. On the upward-sloping right side of the model, testing of components, integration testing,

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 12

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 and, finally, acceptance testing are performed. A key concept of this model is that as require¬ments
are specified and components designed, testing for those elements is also defined. In this manner,
each level of testing is clearly linked to a part of the analy¬sis or design phase, helping to ensure
high quality and relevant testing and maxi¬mize test effectiveness.

The V-model is simple and straightforward and improves the overall quality of systems through its
emphasis on early development of test plans. Testing focus and expertise is involved in the project
earlier rather than later; plus, the testers gain knowledge of the project early. It still suffers from the
rigidity of the waterfall development process, however, and is not always appropriate for the
dynamic nature of the business environment.

Rapid Application Development (RAD)5 Rapid application development is a collection of

methodologies that emerged in response to the weaknesses of waterfall development and its
variations. RAD incorporates special techniques and computer tools to speed up the analysis, design,
and implementation phases in order to get some portion of the system developed quickly and into
the hands of the users for evaluation and feedback. CASE (computer-aided software engineering)
tools, JAD (joint application development) sessions, fourth-generation/visual programming

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 13

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 languages (e.g., Visual Basic.NET), and code generators may all play a role in RAD. While RAD can
improve the speed and quality of systems development, it may also introduce a problem in
managing user expectations. As systems are devel¬oped more quickly and users gain a better
understanding of information technology, user expectations may dramatically increase and system
requirements may expand during the project (sometimes known as scope creep or feature creep).
RAD may be conducted in a variety of ways. Iterative development breaks the overall project into
a series of versions that are developed sequentially. The most impor¬tant and fundamental
requirements are bundled into the first version of the system. This version is developed quickly by a
mini-waterfall process, and once implemented, the users can provide valuable feedback to be
incorporated into the next version of the sys¬tem. (See Figure 2-5.) Iterative development gets a
preliminary version of the system to the users quickly so that business value is provided. Since users
are working with the system, important additional requirements may be identified and incorporated
into sub¬sequent versions. The chief disadvantage of iterative development is that users begin to
work with a system that is intentionally incomplete. Users must accept that only the most critical
requirements of the system will be available in the early versions and must be patient with the
repeated introduction of new system versions.
System prototyping performs the analysis, design, and implementation phases concurrently in
order to quickly develop a simplified version of the proposed sys¬tem and give it to the users for
evaluation and feedback. (See Figure 2.6). The sys¬tem prototype is a “quick and dirty” version of
the system and provides minimal features. Following reaction and comments from the users, the
developers reana-lyze, redesign, and reimplement a second prototype that corrects deficiencies and
adds more features. This cycle continues until the analysts, users, and sponsor agree that the
prototype provides enough functionality to be installed and used in the organization. System
prototyping very quickly provides a system for users to eval¬uate and reassures users that progress
is being made. The approach is very useful when users have difficulty expressing requirements for
the system. A disadvantage, however, is the lack of careful, methodical analysis prior to making
design and implementation decisions. System prototypes may have some fundamental design
limitations that are a direct result of an inadequate understanding of the system’s true requirements
early in the project.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 14

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 15
IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 Planning Analysis

Design
Analysis

Implementation
Analysis

Design

System
version 1
Implementation
Analysis

Design

System
version 2
Implementation

System
version 3

FIGURE 2.5
Iterative Development

FIGURE 2.6
System Prototyping

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 16

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 Planning

Analysis

Design

Analysis

Design
Design prototype Implementation

Implementation

System

FIGURE 2.7
Throwaway Prototyping

Throwaway prototyping6 includes the development of prototypes, but uses the prototypes
primarily to explore design alternatives rather than as the actual new system (as in system
prototyping). As shown in Figure 2-7, throwaway prototyping has a fairly thorough analysis phase
that is used to gather requirements and to develop ideas for the system concept. Many of the
features suggested by the users may not be well understood, however, and there may be
challenging technical issues to be solved. Each of these issues is examined by analyzing, designing,
and building a design prototype. A design prototype is not intended to be a working system. It
con¬tains only enough detail to enable users to understand the issues under consideration. For
example, suppose that users are not completely clear on how an order entry system should work.
The analyst team might build a series of HTML pages to be viewed on a Web browser to help the
users visualize such a system. In this case, a series of mock-up screens appear to be a system, but
they really do nothing. Or, suppose that the project team needs to develop a sophisticated graphics
program in Java. The team could write a portion of the program with artificial data to ensure
that they could create a full-blown program successfully.
A system that is developed by this type of methodology probably requires sev¬eral design
prototypes during the analysis and design phases. Each of the prototypes is used to minimize the
risk associated with the system by confirming that important issues are understood before the real
system is built. Once the issues are resolved, the project moves into design and implementation. At
this point, the design proto¬types are thrown away, which is an important difference between this
approach and system prototyping, in which the prototypes evolve into the final system.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 17

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 Throwaway prototyping balances 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. It may take longer
to deliver the final system compared with system prototyping (because the prototypes do not
become the final system), but the approach usually produces more stable and reliable systems.

References :
1) System Analysis and Design, Fifth Edition by Alan Dennis, Barbara Haley Wixom and Roberta M. Roth
2) Systems Analysis and Design: An Object-Oriented Approach with UML
by Alan Dennis & Barbara Haley Wixom & David Tegarden
3) Systems Analysis and Design in a Changing World by John W. Satzinger & Robert B. Jackson
& Stephen D. Burd

Sugested Readings :
1) https://www.projectmanager.com/blog/project-selection-for-better-strategic-results
2) https://www.geeksforgeeks.org/software-engineering-functional-point-fp-analysis/
3) https://www.investopedia.com/terms/g/gantt-chart.asp
4) https://www.villanovau.com/resources/project-management/controlling-process-project-management/

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 18

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

Last Name : ______________________________________ First Name :_________________ M.I.: _________

Course, Year & Section : _______________________

Module 2

1. Answer the following questions:

A. Compare and contrast structured design methodologies in general with Rapid Application
Development (RAD) methodologies in general.

_________________________________________________________________________________
________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 19

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
 B. What are the difference between Iterative Development , System Prototyping and Throw away
Prototyping?

___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________

C. Describe how projects are selected in organizations.

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 20

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 21

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 2