LESSON TWO

In this lesson, we are going to study further the Analysis steps which include concept of
structured analysis, Fact gathering techniques, data flow diagrams, process description data
modeling.
We have already discussed in Lesson the three steps of Analysis phase which are:
• Analysis Strategy
• Requirements gathering
• System Proposal
Analysis strategy is concerned with analysis the existing/current system (called the as-is
system) and its problems, and then ways to design a new system (called the to-be system).
And information gathering is gathering of fact about the existing system and users/system
requirements with which the proposed or will-be system will be modelled.

What kinds of problems does an analyst typically solve?

Listed below are some examples of problems a system analyst may solve, these are just few.
Any problem that can be defined can be solved by a system analyst..
i. Customers want to order products any time of the day or night. So, the problem is
how to process those orders around the clock without adding to the selling cost.
ii. Production needs to plan very carefully the amount of each type of product to produce
each week. So, the problem is how to estimate the dozens of parameters that affect
production and then allow planners to explore different scenarios before committing
to a specific plan.
iii. Suppliers want to minimize their inventory holding costs by shipping parts used in
the manufacturing process in smaller daily batches. So, the problem is how to order
in smaller lots and accept daily shipments to take advantage of supplier discounts.
iv. Marketing wants to anticipate customer needs better by tracking purchasing patterns
and buyer trends. So, the problem is how to collect and analyze information on
customer behavior that marketing can put to use.
v. Management continually wants to know the current financial picture of the company,
including profit and loss, cash flow, and stock market forecasts. So, the problem is
how to collect, analyze, and present all of the financial information management
wants.
vi. Employees demand more flexibility in their benefits programs, and management
wants to build loyalty and morale. So, the problem is how to process transactions for
flexible health plans, wellness programs, employee investment options, retirement
accounts, and other benefit programs offered to employees.

The System analyst’s approach to problem solving

• Research and understand the problem
• Verify that the benefits of solving the problem outweigh the costs
• Define the requirements for solving the problem
• Develop a set of possible solutions (alternatives)
• Decide which solution is best, and make a recommendation
• Define the details of the chosen solution
• Implement the solution
• Monitor to make sure that you obtain the desired results

Requirements Determination
A requirement is a vital feature of a new system which may include processing or capturing
of data, controlling the activities of business, producing information and supporting the
management.
 Requirements determination involves studying the existing system and gathering details to
find out what are the requirements, how it works, and where improvements should be made.

The Activities In Requirement Determination

Major Activities in requirement Determination include:
i. Requirements Anticipation
o It predicts the characteristics of system based on previous experience which include
certain problems or features and requirements for a new system.
o It can lead to analysis of areas that would otherwise go unnoticed by inexperienced
analyst. But if shortcuts are taken and bias is introduced in conducting the
investigation, then requirement Anticipation can be half-baked.

ii.Requirements Investigation
o It is studying the current system and documenting its features for further analysis.
o It is at the heart of system analysis where analyst documenting and describing
system features using fact-finding techniques, prototyping, and computer assisted
tools.

iii.Requirements Specifications
o It includes the analysis of data which determine the requirement specification,
description of features for new system, and specifying what information
requirements will be provided.
o It includes analysis of factual data, identification of essential requirements, and
selection of Requirement-fulfillment strategies.

Information Gathering Technique

Interviewing: Systems analyst collects information from individuals or groups by

interviewing. The analyst can be formal, legalistic, play politics, or be informal; as the success
of an interview depends on the skill of analyst as interviewer.
It can be done in two ways
o Unstructured Interview: The system analyst conducts question-answer session to
acquire basic information of the system.
o Structured Interview: It has standard questions which user need to respond in either
close (objective) or open (descriptive) format.

Advantages of Interviewing:
o This method is frequently the best source of gathering qualitative information.
o It is useful for them, who do not communicate effectively in writing or who may
not have the time to complete questionnaire.
o Information can easily be validated and cross checked immediately.
o It can handle the complex subjects.
o It is easy to discover key problem by seeking opinions.
o It bridges the gaps in the areas of misunderstandings and minimizes future
problems.

Questionnaires: This method is used by analyst to gather information about various issues
of system from large number of persons.
There are two types of questionnaires:
Open-ended Questionnaires − It consists of questions that can be easily and correctly
interpreted. They can explore a problem and lead to a specific direction of answer.
Closed-ended Questionnaires − It consists of questions that are used when the systems
analyst effectively lists all possible responses, which are mutually exclusive.

Table2.1 Closed and Open-ended questionnaire

Closed questionnaire (Sample) Open ended questionnaire

Computer Science is a competitive course Is Computer Science worth

a. Agree b. Strongly Agree c. Disagree studying as a course?

Female students do better than their male counterpart. Are Female students better than
a. Agree b. Strongly Agree c. Disagree their Male counterpart?

Starting school at earlier age makes a child more What is the effect of early
intelligent. enrolment in school in a child.
a. Agree b. Strongly Agree c. Disagree

Working mothers takes care of home better than house Are working mothers preferred
wives. to house wives?
Agree b. Strongly Agree c. Disagree

Advantages of questionnaires :
• It is very effective in surveying interests, attitudes, feelings, and beliefs of users which
are not co-located.
• It is useful in situation to know what proportion of a given group approves or
disapproves of a particular feature of the proposed system.
• It is useful to determine the overall opinion before giving any specific direction to the
system project.
• It is more reliable and provides high confidentiality of honest responses.
• It is appropriate for electing factual information and for statistical data collection which
can be emailed and sent by post.

Secondary Research Or Background Reading (document review)

This method is widely used for information gathering by accessing the gleaned information.
It includes any previously gathered information used by the marketer from any internal or
external source.

Advantages :
• It is more openly accessed with the availability of internet.
• It provides valuable information with low cost and time.
• It act as forerunner to primary research and aligns the focus of primary research.
• It is used by the researcher to conclude if the research is worth it as it is available with
procedures used and issues in collecting them.

Structured Analysis
Structured Analysis is a development method that allows the analyst to understand the system
and its activities in a logical way. It is a systematic approach, which uses graphical tools that
analyze and refine the objectives of an existing system and develop a new system
specification which can be easily understandable by user.
Attributes of Structured Analysis
• It is graphic which specifies the presentation of application.
• It divides the processes so that it gives a clear picture of system flow.
• It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.
• It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development.
They are:
i. Data Flow Diagrams.
ii. Data Dictionary.
iii. Decision Trees.
iv. Decision Tables.
v. Structured English.
vi. Pseudocode.

Data Flow Diagrams (DFD) Or Bubble Chart

Pictures can speak louder than words. A Data Flow Diagram (DFD) is a traditional way to
visualize the information flows within a system. It can be manual, automated, or a
combination of both. A neat and clear DFD can graphically depict the following:
• a good amount of the system requirements.
• It shows the process of entry and exit of information in the system,
• what changes the information and where information is stored.
The purpose of a DFD is to show the scope and boundaries of a system as a whole. It may be
used as a communications tool between a systems analyst and any person who plays a part
in the system that acts as the starting point for redesigning a system. It usually begins with a
context diagram as level 0 of the DFD diagram, a simple representation of the whole system.
To elaborate further from that, we drill down to a level 1 diagram with lower level functions
decomposed from the major functions of the system. This could continue to evolve to become
a level 2 diagram when further analysis is required. Progression to levels 3, 4 and so on is
possible but anything beyond level 3 is not very common. Please bear in mind that the level
of detail for decomposing a particular function depends on the complexity that function.

Types of Data Flow Diagram (DFD):

DFDs are of two types:
i. Physical DFD
ii. Logical DFD.

Physical DFD :
o It is implementation dependent. It shows which functions are performed.
o It provides low level details of hardware, software, files, and people.
o It depicts how the current system operates and how a system will be implemented.

Logical DFD :
o It is implementation independent. It focuses only on the flow of data between
processes.
o It explains events of systems and data required by each event.
o It shows how business operates; not how the system can be implemented.
How to Draw DFD:
We should learn how DFD is drawn. First of all, let us see different drawing notations.

External Entity:
This can represent a human, system or subsystem where certain data comes from or goes to.
It is external to the system being studied, thus people used to draw external entities on the
edge of a diagram. Using Business process for exam, customer can be an external entity and

can be represented as below:

Process
A process is a business activity or function where data manipulation and transformation take
place. A process can further be decomposed to a better level of details, for representing how
data is being
processed within the process

Data Store (Storage)

This represents the storage of persistent data required and/or produced by the process. Some
examples of data stores are: Registration forms, database tables, etc.

Data Flow
A data flow represents the flow of information, with its direction represented by an arrowhead
that
shows at the end(s) of flow connector

(Connection from a data store to a process)

Context data flow diagram

Figure 2.1: Context Diagram

Context diagram represent system as an integral, here the system is connected to three data
store, (Inventory, Customer and Transaction)

Decomposition of Context diagram into detailed lower level.

The figure 2.1 can be decomposed into lower level details following the steps below:

i. Create three processes (Process Order, Ship Good, Issue Receipt) in the center as
shown below. That is the old spot for the System process and we place them there to
elaborate System.

ii. Wiring with connection lines for data flows: The remaining steps in this section are
about connecting the model elements in the diagram. For example, Customer provides
order information when placing an order for processing.

Enter order information as the

caption of flow

iii. The Process Order process also receives customer information from the
database to process the order. Represent it as shown below:
iv. By combining the order information from Customer (external entity) and the
customer information from Customer (data store), Process Order (process) then
creates a transaction record in the database. Create a data flow from Process Order to
Transaction.

v. Once a transaction is stored, the shipping process follows. Therefore, create a data
flow from Process Order (process) to Ship Good (process).
 vi. Ship Good (process) needs to read the transaction information (i.e. The order number
to pack the right product for delivery. Create a data flow from Transaction (data store)
to Ship Good (process).

(Note: The shapes can be moved around to make rooms if there is no space)

vii. Ship Good also needs to read the customer information for his/her shipping address.
Create a data flow from Customer (data store) to Ship Good (process).

viii. Ship Good then updates the Inventory database to reflect the goods shipped. Create a
data flow from Ship Good (process) to Inventory (data store). Name it updated
product record.
ix. Once the order arrives in the customer's hands, the Issue Receipt process begins. In
it, a receipt is prepared based on the transaction record stored in the database. So
create a data flow from Transaction (data store) to Issue Receipt (process).

x. Then a receipt is issued to the customer. Let's create a data flow from Issue Receipt
(process) to Customer (external entity). Name the data flow receipt.
This brings to completion the Level 1 DFD of the system, so the complete system diagram
should be as shown below:

Figure 2.2: Level 1 DFD diagram.

Data Flow Diagram Tips and Cautions

1. Process labels should be verb phrases; data stores are represented by nouns
2. A data store must be associated with at least a process
3. An external entity must be associated with at least a process
4. Don't let it get too complex; normally 5 - 7 average people can manage processes
5. DFD is non-deterministic - The numbering does not necessarily indicate sequence, it's
useful in
identifying the processes when discussing with users
6. Datastores should not be connected to an external entity, otherwise, it would mean that
you're
giving an external entity direct access to your data files
7. Data flows should not exist between 2 external entities without going through a process
SYSTEM DESIGN: STRUCTURE CHARTS, FORM DESIGNS, SECURITY,
AUTOMATED TOOLS FOR DESIGN.

System Design
System Design as have been earlier mentioned focuses on building the proposed system using
the result from the analysis carried out.

It is the process of defining the architecture, components, modules, interfaces, and data for a
system to satisfy specified requirements. Systems design could be seen as the application of
systems theory to product development.
The Inputs and Outputs of System Design

System design takes the following inputs:

• Statement of work/defined problem
• Requirement determination plan.
• Current situation analysis.
• Proposed system requirements including a conceptual data model, modified DFDs,
and Metadata (data about data).
• Outputs for System Design.

System design gives the following outputs :

• Infrastructure and organizational changes for the proposed system.
• A data schema, often a relational schema.
• Metadata to define the tables/files and columns/data-items.
• A function hierarchy diagram or web page map, that graphically describes the program
structure.
• Actual or pseudocode for each module in the program.
• A prototype for the proposed system.

The Systems Models

This simple means representation of system using diagrams or charts. Different types of
system models include:
i. Schematic Models:
• A schematic model is a 2-D chart that shows system elements and their linkages.
• Different arrows are used to show information flow, material flow, and
information feedback.
ii. Flow System Models:
• A flow system model shows the orderly flow of the material, energy, and
information that hold the system together.
• Program Evaluation and Review Technique (PERT), for example, is used to
abstract a real world system in model form.
iii. Static System Models:
• They represent one pair of relationships such as activity–time or cost–quantity.
• The Gantt chart, for example, gives a static picture of an activity-time
relationship.
iv. Dynamic System Models: Business organizations are dynamic systems. A dynamic
model approximates the type of organization or application that analysts deal with. It
shows an ongoing, constantly changing status of the system. It consists of −
• Inputs that enter the system
• The processor through which transformation takes place
• The program(s) required for processing
Systems are modelled using structured charts(diagrams). Such charts include:
i. Flowcharts:
ii. Entity Relationship diagrams (ERD)
iii. Use case diagram
iv. Sequence diagram:
v. Class diagram:
vi. Contextual diagram

Flowcharts:
A flowchart is simply a graphical representation of steps which depicts the steps in sequential
order and is widely used in presenting the flow of algorithms, workflow or processes.
Typically, a flowchart shows the steps as boxes of various kinds, and their order by connecting
them with arrows.

Advantages of using Flowchart

• It helps clarify complex processes.
• It identifies steps that do not add value to the internal or external customer, including
delays; needless storage and transportation; unnecessary work, duplication, and added
expense; breakdowns in communication.
• It helps team members gain a shared understanding of the process and use this
knowledge to collect data, identify problems, focus discussions, and identify
resources.
• It serves as a basis for designing new processes.

Table 2.2: Flowchart Symbols

SYMBOLS NAME CONVENTIONAL MEANING

Terminator The starting or ending point of the

system

Process Processing or some particular

operation

Document This represents a printout, such as a

document or a report.

Data represents input or output from the

system. An input might be an order
from a customer. Output can be a
product to be delivered. (for
Business system)
 On page reference This symbol would contain a letter
inside. It indicates that the flow
continues on a matching symbol
containing the same letter
somewhere else on the same page.

Off-Page Reference This symbol would contain a letter

inside. It indicates that the flow
continues on a matching symbol
containing the same letter
somewhere else on a different page

Delay or Bottleneck represents a delay or a bottleneck.

Decision represents a decision or branching

point. Lines coming out from the
diamond indicates different possible
situations, leading to different sub-
processes

Flow represent the flow of the sequence

and direction of a process

Entity Relationship diagrams (ERD)

This is visual representation of entities (which can be in form of tables or objects) and how
the entities are related to each other in the system.
ER diagrams help to explain the logical structure of databases. They are created based on three
basic concepts: entities, attributes and relationships.

How to Draw an Entity Relationship Diagram

i. Determine the Entities in Your ERD.
a. Start by identifying the “what”s in your system or architecture. ...
ii. Add Attributes to Each Entity. ...
iii. Define the Relationships Between Entities. ...
iv. Add Cardinality to Every Relationship in your ER Diagram. ...
v. Finish and Save Your ERD.

Advantages of ER diagrams
• ER model allows you to draw Database Design
• It is an easy to use graphical tool for modeling data
• Widely used in Database Design
• It is a GUI representation of the logical structure of a Database
 • It helps you to identifies the entities which exist in a system and the relationships
between those entities

Symbols in ER diagram

SYMBOLS REPRESENTS Remark

Entity can be a person, place, object

event or concept about which data is
Entities or Strong entities to be maintained. E.g. Student,
Course

Weak entities This represents a printout, such as a

document or a report.

Attribute Property or characteristic of an

entity. E.g, Name of Student,
Course code

Multivalued Attribute Phone number of a student, Students

offering a course,

Relationship Relationship is identified with verb

or verb phrase

Weak relationship A weak entity is a type of entity

which doesn’t have its key attribute.
It can be identified uniquely by
considering the primary key of
another entity

links attributes to entity represents relationship

types and entity types
with other relationship
types

Entity Notations

Entity Set
An entity set is a group of similar kind of entities. It may contain entities with attribute sharing
similar values. Entities are represented by their properties, which also called attributes. All
attributes have their separate values. For instance, in a University database, we might have
entities for Students, Courses, and Lecturers. Students entity can have attributes like
MatricNo, Name, DeptID and Level. They might have relationships with Courses and
Lecturers.
A university may have some departments. All these departments employ various lecturers and
offer several programs. Some courses make up each program. Students enroll in a particular
program and register various courses. A lecturer from the specific department takes each
course, and each lecturer teaches a various group of students.

SEMESTER
CUNIT REGID
CTITL

Weak Registration
C ID COURSE
Relation

Figure 2.3: Entity set showing the weak relationship

Strong Entity Set Weak Entity Set

always has a primary key. does not have enough attributes to build a
primary key
represented by a rectangle symbol. represented by a double rectangle symbol.
contains a Primary key represented by the contains a Partial Key which is represented
underline symbol. by a dashed underline symbol.
The member of a strong entity set is The member of a weak entity set is regarded
regarded as dominant entity set as a subordinate entity set.
Primary Key is one of its attributes which In a weak entity set, it is a combination of
helps to identify its member primary key and partial key of the strong
entity set.
between two strong entity set shown by a weak entity set shown by using the double
using a diamond symbol. diamond symbol
The connecting line of the strong entity set The line connecting the weak entity set for
with the relationship is single. identifying relationship is double.

Attributes
It is a single-valued property of either an entity-type or a relationship-type.
For example, a course might have attributes: code, title, unit, etc.
An attribute in ER Diagram is represented by an Ellipse

Attributes

Course title Course Unit

Course code

Course
Entity

Figure 2. 4: Attributes
 Types of Attributes Description

Simple attribute An atomic value that cannot be further divided.. For

example, a student’s contact number.

Composite attribute Can be further broken down. For example, a student’s

fullname may be further divided into lastname first name,
and othername

Derived attribute This type of attribute are not included in the physical
database. However, their values are derived from other
attributes. For example age should not be stored, instead
it can be derived from date of birth.

Multivalued attribute can have more than one values. For example, a student
can have more than one mobile number, email address,
etc.

Relationship
A relationship describes how entities interact. For example, the entity “Lecturer” may be
related to the entity “course” by the relationship “teaches” or “examines”. Relationships are
represented by diamond shapes and are labeled using verbs.

Relationships in ER diagrams
Recursive Relationship
If the same entity participates more than once in a relationship it is known as a recursive
relationship. In the below example an employee can be a supervisor and be supervised, so
there is a recursive relationship.

Cardinality

Cardinality defines the numerical attributes of the relationship between two entities or entity
sets.

Different types of cardinal relationships are:

• One-to-One Relationships
• One-to-Many Relationships
• May to One Relationships
• Many-to-Many Relationships
Figure 2.4: Relationship Cardinality
One-to – One Relationship
Example: One student can register for numerous courses. However, all those courses have a
single line back to that one student.

One-to-Many Relationships

One entity from entity set X can be associated with multiple entities of entity set Y, but an
entity from entity set Y can be associated with at least one entity.
For example, one class is consisting of multiple students.

Many to One
More than one entity from entity set X can be associated with at most one entity of entity set
Y. However, an entity from entity set Y may or may not be associated with more than one
entity from entity set X.
For example, many students belong to the same class.
Many to Many:
One entity from X can be associated with more than one entity from Y and vice versa.
For example, Students as a group are associated with multiple faculty members, and faculty
members can be associated with multiple students.

In object oriented programming, we can have charts like:

Use case diagram: which presents the user’s requirement.
Sequence diagram: which shows how sequence of activities in the system.
Class diagram: presents the objects and their relationship in the system.
Contextual diagram: which presents the system without details

Use Case and use case diagram

A use case describes a specific goal to be satisfied by the system to be built. Graphically,
it is an oval with a name. It is the most commonly used tool in managing project goals.
While a use case diagram is a kind of Unified Modeling Language (UML) diagram created
for requirement elicitation. Use case diagram provides a graphical overview of goals (modeled
by use cases) users (represented by actors) want to achieve by using the system. Use cases in
a use case diagram can be organized and arranged according to their relevance, level of
abstraction and impacts to users.
They can be connected to show their dependency, inclusion and extension relationships.

Figure 2.5: Use case diagram for Course Registration System (CRS)

Sequence diagram
Sequence diagram is used to depict the operational sequence of a to be system graphically.
 sd AttressSequence Diagram
user Attress Website Attress WebApp Atress Database

Click on Login icon

<<Display Login page

>>

Enter Login ID (Username & …

Autenticate ID

Search for ID

<<Return Search Result

>>

Alt
[Authentication = True
]
Allow Access

Display Required Page

[Else]
Return Error Message

<<Display Account Creation…

<<Create Account
>>
Save Account

Update

Figure 2.6: A sample of Sequence diagram

Class diagram
Class diagrams present the objects, showing their attributes and relationship between the
objects.

Figure 2.7: A class diagram

( Note: Study the remaining tools on your own)
The Types of Documentations in System Design
There are following four main documentations in System Design,:
• System documentation.
• User documentation.
• Program documentation.
• Operations documentation.

System Documentation : System documentation serves as the technical specifications for

the IS and how the objectives of the IS are accomplished. Users, managers and IS owners
need never reference system documentation. System documentation provides the basis for
understanding the technical aspects of the IS when modifications are made.
• It describes each program within the IS and the entire IS itself.
• It describes the system’s functions, the way they are implemented, each program's
purpose within the entire IS with respect to the order of execution, information passed
to and from programs, and overall system flow.
• It includes data dictionary entries, data flow diagrams, object models, screen layouts,
source documents, and the systems request that initiated the project.
• Most of the system documentation is prepared during the system analysis and system
design phases.
• During systems implementation, an analyst must review system documentation to verify
that it is complete, accurate, and up-to-date, and including any changes made during the
implementation process.

User Documentation: It includes instructions and information to the users who will interact
with the system. For example, user manuals, help guides, and tutorials. User documentation
is valuable in training users and for reference purpose. It must be clear, understandable, and
readily accessible to users at all levels.
The users, system owners, analysts, and programmers, all put combined efforts to develop a
user’s guide.

A user documentation should include:

• A system overview that clearly describes all major system features, capabilities, and
limitations.
• Description of source document content, preparation, processing, and, samples.
• Overview of menu and data entry screen options, contents, and processing instructions.
• Examples of reports that are produced regularly or available at the user’s request,
including samples.
• Security and audit trail information.
• Explanation of responsibility for specific input, output, or processing requirements.
• Procedures for requesting changes and reporting problems.
• Examples of exceptions and error situations.
• Frequently asked questions (FAQs).
• Explanation of how to get help and procedures for updating the user manual.

Program Documentation :
• It describes inputs, outputs, and processing logic for all the program modules.
• The program documentation process starts in the system analysis phase and continues
during implementation.
• This documentation guides programmers, who construct modules that are well
supported by internal and external comments and descriptions that can be understood
and maintained easily.
Operations Documentation : Operations documentation contains all the information
needed for processing and distributing online and printed output. Operations documentation
should be clear, concise, and available online if possible.

It includes the following information −

• Program, systems analyst, programmer, and system identification.
• Scheduling information for printed output, such as report, execution frequency, and
deadlines.
• Input files, their source, output files, and their destinations.
• E-mail and report distribution lists.
• Special forms required, including online forms.
• Error and informational messages to operators and restart procedures.
• Special instructions, such as security requirements.

Documentation Control :
Documentation is a process of recording the information for any reference or operational
purpose. It helps users, managers, and IT staff, who require it. It is important that prepared
document must be updated on regular basis to trace the progress of the system easily.
After the implementation of system if the system is working improperly, then documentation
helps the administrator to understand the flow of data in the system to correct the flaws and
get the system working.
Programmers or systems analysts usually create program and system documentation.
Systems analysts usually are responsible for preparing documentation to help users learn the
system. In large companies, a technical support team that includes technical writers might
assist in the preparation of user documentation and training materials.
Advantages :
• It can reduce system downtime, cut costs, and speed up maintenance tasks.
• It provides the clear description of formal flow of present system and helps to
understand the type of input data and how the output can be produced.
• It provides effective and efficient way of communication between technical and
nontechnical users about system.
• It facilitates the training of new user so that he can easily understand the flow of
system.
• It helps the user to solve the problems such as troubleshooting and helps the manager
to take better final decisions of the organization system.
• It provides better control to the internal or external working of the system.
LESSON THREE: SYSTEMS DEVELOPMENT METHODOLOGIES
A methodology 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 each
one is unique, based on the order and focus it places on each SDLC phase. Some
methodologies are formal standards used by government agencies, whereas others have been
developed by consulting firms to sell to clients. Many organizations have internal
methodologies that have been honed over the years, and they explain exactly how each phase
of the SDLC is to be performed in that company.
There are many ways to categorize methodologies. One way is by looking at whether they
focus on business processes or the data that support the business. A process-centered
methodology emphasizes process models as the core of the system concept. In Figure 1, for
example, process-centered methodologies would focus first on defining the processes (e.g.,
assemble sandwich ingredients). Data-centered methodologies emphasize data models as the
core of the system concept. In Figure 1 data-centered methodologies would focus first on
defining the contents of the storage areas (e.g., refrigerator) and how the contents were
organized. By contrast, object-oriented methodologies attempt to balance the focus between
process and data by incorporating both into one model. In Figure1, these methodologies would
focus first on defining the major elements of the system (e.g., sandwiches, lunches) and look
at the processes and data involved with each element.

Figure 2.8: A Simple Behavioral Model for Making Lunch

Another important factor in categorizing methodologies is the sequencing of the SDLC

phases and the amount of time and effort devoted to each. In the early days of computing,
programmers tend to move directly from a very simple planning phase right into the
construction step of the implementation phase.
This approach can work for small programs that require only one programmer, but if the
requirements are complex or unclear, you may miss important aspects of the problem and
have to start all over again, throwing away part of the program (and the time and effort spent
writing it). This approach also makes teamwork difficult because members have little idea
about what needs to be accomplished and how to work together to produce a final product.
Structured Design
The first category of systems development methodologies is called structured design. These
methodologies became dominant in the 1980s, replacing the previous, ad hoc, and
undisciplined approach. Structured design methodologies adopt a formal step-by-step approach
to the SDLC that moves logically from one phase to the next. Numerous process-centered and
data-centered methodologies follow the basic approach of the two structured design categories
outlined next.

Waterfall Development The original structured design methodology (still used today) is
waterfall development. With waterfall development–based methodologies, the analysts and
users proceed in sequence from one phase to the next (see Figure 2). 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.
This methodology is referred to as waterfall development because it moves forward from phase
to phase in the same manner as a waterfall. Although it is possible to go backward in the SDLC
(e.g., from design back to analysis), it is extremely difficult (imagine yourself as a salmon
trying to swim upstream against a waterfall, as shown in Figure 2).
Structured design also introduced the use of formal modeling or diagramming techniques to
describe the basic business processes and the data that support them. Traditional structured
design uses one set of diagrams to represent the processes and a separate set of diagrams to
represent data. Because two sets of diagrams are used, the systems analyst must decide which
set to develop first and use as the core of the system—process-model diagrams or data-model
diagrams. There is much debate over which should come first, the processes or the data,
because both are important to the system. As a result, several different structured design
methodologies have evolved that follow the basic steps of the waterfall model but use different
modeling approaches at different times. Those that attempt to emphasize process-model
diagrams as the core of the system are process centered, whereas those that emphasize data-
model diagrams as the core of the system concept are data centered.

Figure 2.9: A Waterfall Development–based Methodology

The two key advantages of the structured design waterfall approach are that it identifies
system requirements long before programming begins and 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 and that a long time elapses between the
completion of the system proposal in the analysis phase and the delivery of the system
(usually many months or years). Lengthy deliverables often result in poor communication;
the result is that important requirements can be overlooked in the voluminous documentation.
Users are rarely prepared for their introduction to the new system, which occurs long after
the initial idea for the system was introduced. If the project team misses important
requirements, expensive post-implementation programming may be needed (imagine
yourself trying to design a car on paper; how likely would you be to remember interior lights
that come on when the doors open or to specify the right number of valves on the engine?).
A system may also require significant rework because the business environment has changed
from the time that the analysis phase occurred. When changes do occur, it means going back
to the initial phases and following the change through each of the subsequent phases in turn.

Parallel Development
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 (see Figure 3).
The primary advantage of this methodology is that it can reduce the schedule time to deliver
a system; thus, there is less chance of changes in the business environment causing rework.
However, the approach still suffers from problems caused by paper documents. It also adds
a new problem: Sometimes the subprojects are not completely independent; design decisions
made in one subproject may

Figure 2.10: A Parallel Development–based Methodology

Rapid Application Development (RAD)

A second category of methodologies includes rapid application development (RAD)–based
methodologies. These are a newer class of systems development methodologies that emerged
in the 1990s. RAD-based methodologies attempt to address both weaknesses of structured
design methodologies by adjusting the SDLC phases to get some part of the system
developed quickly and into the hands of the users. In this way, the users can better understand
the system and suggest revisions that bring the system closer to what is needed.

Most RAD-based methodologies recommend that analysts use special techniques and
computer tools to speed up the analysis, design, and implementation phases, such as CASE
 tools, joint application design (JAD) sessions, fourth-generation/visual programming
languages that simplify and speed up programming (e.g., Visual Basic), and code generators
that automatically produce programs from design specifications. The combination of the
changed SDLC phases and the use of these tools and techniques improves the speed and
quality of systems development. However, there is one possible subtle problem with RAD-
based methodologies: managing user expectations. Due to the use of the tools and techniques
that can improve the speed and quality of systems development, user expectations of what is
possible may dramatically change.
As a user better understands the information technology, the systems requirements tend to
expand. Process-centered, data-centered, and object-oriented methodologies that follow the
basic approaches of the three RAD categories are described in the following sections.

❖ Phased Development: A phased development–based methodology breaks an overall system

into a series of versions, which are developed sequentially. The analysis phase identifies the
overall system concept, and the project team, users, and system sponsor then categorize the
requirements into a series of versions. The most important and fundamental requirements are
bundled into the first version of the system. The analysis phase then leads into design and
implementation—but only with the set of requirements identified for version 1 (see Figure
4).
Once version 1 is implemented, work begins on version 2. Additional analysis is performed
based on the previously identified requirements and combined with new ideas and issues that
arose from the users’ experience with version 1. Version 2 then is designed and implemented,
and work immediately begins on the next version. This process continues until the system is
complete or is no longer in use.

Figure 2.11: A Phased Development–based Methodology

Phased development–based methodologies have the advantage of quickly getting a useful

system into the hands of the users. Although the system does not perform all the functions
the users need at first, it does begin to provide business value sooner than if the system were
delivered after completion, as is the case with the waterfall and parallel methodologies.
Likewise, because users begin to work with the system sooner, they are more likely to
identify important additional requirements sooner than with structured design situations.
 The major drawback to phased development is that users begin to work with systems that are
intentionally incomplete. It is critical to identify the most important and useful features and
include them in the first version and to manage users’ expectations along the way.

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. With these methodologies, the basics of analysis and design
are performed, and work immediately begins on a system prototype, a “quick-and-dirty”
program that provides a minimal amount of features. The first prototype is usually the first
part of the system that is used. This is shown to the users and the project sponsor, who provide
comments. These comments are used to reanalyze, redesign, and re-implement a second
prototype, which provides a few more features. This process continues in a cycle until the
analysts, users, and sponsor agree that the prototype provides enough functionality to be
installed and used in the organization. After the prototype (now called the system) is
installed, refinement occurs until it is accepted as the new system (Figure 5).
The key advantage of a prototyping-based methodology is that it very quickly provides a
system with which the users can interact, even if it is not ready for widespread organizational
use at first. Prototyping reassures the users that the project team is working on the system
(there are no long delays in which the users see little progress), and prototyping helps to more
quickly refine real requirements. Rather than attempting to understand a system specification
on paper, the users can interact with the prototype to better understand what it can and cannot
do.
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. 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).

Figure 2.12: A Prototyping-based Methodology

❖ Throwaway Prototyping: Throwaway prototyping–based methodologies are similar to

prototyping-based methodologies in that they include the development of prototypes;
however, throwaway prototypes are done at a different point in the SDLC. These prototypes
are used for a very different purpose than those previously discussed, and they have a very
different appearance (Figure 6).
The throwaway prototyping–based methodologies have a relatively thorough analysis phase
that is used to gather information and to develop ideas for the system concept. However,
users may not completely understand many of the features they suggest, 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 a working system; it is
a product that represents a part of the system that needs additional refinement, and it contains
only enough detail to enable users to understand the issues under consideration.
For example, suppose users are not completely clear on how an order entry system should
work. The analyst team might build a series of HTML pages viewed using 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.
A system developed using this type of methodology probably relies on several 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 prototypes are thrown away, which is an important
difference between these methodologies and prototyping methodologies, in which the
prototypes evolve into the final system.

Figure 2.13: A Throwaway Prototyping–based Methodology

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. It may take longer to deliver the final system as compared to prototyping-
based methodologies (because the prototypes do not become the final system), but this type
of methodology usually produces more stable and reliable systems.

Agile Development
Agile is a third category of systems development methodologies. These programming-centric
methodologies have few rules and practices, all of which are fairly easy to follow. They focus
on streamlining the SDLC by eliminating much of the modeling and documentation overhead
and the time spent on those tasks. Instead, projects emphasize simple, iterative application
development. Examples of agile development methodologies include extreme programming,
Scrum, and the Dynamic Systems Development Method (DSDM). The agile development
approach typically is used in conjunction with object-oriented methodologies.

Extreme Programming: Extreme programming (XP) is founded on four core values:

communication, simplicity, feedback, and courage. These four values provide a foundation
that XP developers use to create any system. First, the developers must provide rapid
feedback to the end users on a continuous basis. Second, XP requires developers to follow
the KISS principle. Third, developers must make incremental changes to grow the system,
and they must not only accept change, they must embrace change. Fourth, developers must
have a quality-first mentality. XP also supports team members in developing their own skills.
Three of the key principles that XP uses to create successful systems are continuous testing,
simple coding performed by pairs of developers, and close interactions with end users to
build systems very quickly. After a superficial planning process, projects perform analysis,
design, and implementation phases iteratively (Figure7).

Figure 2.14: The Extreme Programming Methodology

Testing and efficient coding practices are core to XP. In fact, code is tested each day and is
placed into an integrative testing environment. If bugs exist, the code is backed out until it is
completely free of errors. XP relies heavily on refactoring, which is a disciplined way to
restructure code to keep it simple.
An XP project begins with user stories that describe what the system needs to do.
Then, programmers code in small, simple modules and test to meet those needs. Users are
required to be available to clear up questions and issues as they arise. Standards are very
important to minimize confusion, so XP teams use a common set of names, descriptions, and
coding practices. XP projects deliver results sooner than even the RAD approaches, and they
rarely get bogged down in gathering requirements for the system.
For small projects with highly motivated, cohesive, stable, and experienced teams, XP should
work just fine. However, if the project is not small then the success of an XP development
effort is doubtful. This tends to throw the whole idea of bringing outside contractors into an
existing team environment using XP into doubt. Furthermore, it is recommended only for
small groups of developers—no more than ten developers, and it is not advised for large
mission-critical applications. Due to the lack of analysis and design documentation, there is
only code documentation associated with XP, so maintaining large systems built with XP
may be impossible. And because mission-critical business information systems tend to exist
for a long time, the utility of XP as a business information system development methodology
is in doubt. Finally, the methodology needs a lot of on-site user input, something to which
many business units cannot commit.

Joint Application Development (JAD) : It is a new technique developed by IBM which

brings owners, users, analysts, designers, and builders to define and design the system using
organized and intensive workshops. JAD trained analyst act as facilitator for workshop who
has some specialized skills.

Advantages of JAD
o It saves time and cost by replacing months of traditional interviews and follow-up
meetings.
o It is useful in organizational culture which supports joint problem solving.
o Fosters formal relationships among multiple levels of employees.
o It can lead to development of design creatively.
o It Allows rapid development and improves ownership of information system.
Selecting the Appropriate Development Methodology
Because there are many methodologies, the first challenge faced by analysts is to select which
methodology to use. Choosing a methodology is not simple, because no one methodology is
always best. Many organizations have standards and policies to guide the choice of
methodology. You will find that organizations range from having one “approved”
methodology to having several methodology options to having no formal policies at all.

Figure 8 summarizes some important methodology selection criteria. One important item not
discussed in this figure is the degree of experience of the analyst team. Many of the RAD-
based methodologies require the use of “new” tools and techniques that have a significant
learning curve. Often these tools and techniques increase the complexity of the project and
require extra time for learning. However, once they are adopted and the team becomes
experienced, the tools and techniques can significantly increase the speed in which the
methodology can deliver a final system.

Figure 2.15: Criteria for Selecting a Methodology

Clarity of User Requirements: When the user requirements for a system are unclear, it is
difficult to understand them by talking about them and explaining them with written reports.
Users normally need to interact with technology to really understand what a new system can
do and how to best apply it to their needs. Prototyping- and throwaway prototyping–based
RAD methodologies are usually more appropriate when user requirements are unclear
because they provide prototypes for users to interact with early in the SDLC.
Familiarity with Technology: When the system will use new technology with which the
analysts and programmers are not familiar (e.g., the first Web development project with
Java), early application of the new technology in the methodology will improve the chance
of success. If the system is designed without some familiarity with the base technology, risks
increase because the tools might not be capable of doing what is needed. Throwaway
prototyping–based methodologies are particularly appropriate if users lack familiarity with
technology because they explicitly encourage the developers to develop design prototypes
for areas with high risks. Phased development–based methodologies are good as well,
because they create opportunities to investigate the technology in some depth before the
design is complete. Although you might think prototyping-based methodologies are also
appropriate, they are much less so because the early prototypes that are built usually only
scratch the surface of the new technology. It is generally only after several prototypes and
several months that the developers discover weaknesses or problems in the new technology.

System Complexity: Complex systems require careful and detailed analysis and design.
Throwaway prototyping–based methodologies are particularly well suited to such detailed
analysis and design, as opposed to prototyping-based methodologies, which are not. The
traditional structured design–based methodologies can handle complex systems, but without
the ability to get the system or prototypes into the users’ hands early on, some key issues may
be overlooked. Although phased development–based methodologies enable users to interact
with the system early in the process, we have observed that project teams who follow these
tend to devote less attention to the analysis of the complete problem domain than they might
using other methodologies.

System Reliability: System reliability is usually an important factor in system development

after all, who wants an unreliable system? However, reliability is just one factor among
several. For some applications reliability is truly critical (e.g., medical equipment, missile
control systems), whereas for other applications (e.g., games, Internet video) it is merely
important. Throwaway prototyping methodologies are the most appropriate when system
reliability is a high priority, because it combines detailed analysis and design phases with the
ability for the project team to test many different approaches through design prototypes
before completing the design. Prototyping methodologies are generally not a good choice
when reliability is critical because it lacks the careful analysis and design phases that are
essential for dependable systems.

Short Time Schedules: Projects that have short time schedules are well suited for RAD
based methodologies. This is due to them being designed to increase the speed of
development. Prototyping and phased development–based methodologies are excellent
choices when timelines are short because they best enable the project team to adjust the
functionality in the system based on a specific delivery date, and if the project schedule starts
to slip, it can be readjusted by removing functionality from the version or prototype under
development.
Waterfall-based methodologies are the worst choice when time is at a premium because they
do not allow for easy schedule changes.

Schedule Visibility: One of the greatest challenges in systems development is determining

whether a project is on schedule. This is particularly true of the structured design
methodologies because design and implementation occur at the end of the project. The RAD-
based methodologies move many of the critical design decisions earlier in the project to help
project managers recognize and address risk factors and keep expectations in check.