Chapter 1

Chapter 1: The Systems Development Environment

1. What is Information Systems Analysis and Design?

First, let's establish our core concepts.

• Information Systems Analysis and Design (SA&D) is the complex, challenging

organizational process that a team of business and systems professionals uses to
develop and maintain computer-based information systems.
• An Information System is not just the software. It's a complete package of hardware,
systems software, documentation, training materials, job roles, and the people who use
the software to do their work.
• The key result of this process is Application Software, which is software designed to
support a specific organizational function or process, like inventory management or
payroll.

Analogy: Think of a systems analyst as the architect and general contractor for a new house.

• Analysis: The architect first determines what the owner needs. How many bedrooms?
How big is the kitchen? What is the problem? (e.g., "The family is growing"). This is
systems analysis—understanding and specifying in detail what the information system
should accomplish.
• Design: The architect then creates detailed blueprints. This is systems design—
specifying in detail how the many components of the system (hardware, software,
people) should be physically implemented to solve the problem.

This entire process is guided by Methodologies (the overall "recipe" or approach), Techniques
(the specific processes, like how to conduct an interview), and Tools (computer programs, like
a CASE tool, that help apply the techniques).

2. A Modern Approach to Systems Analysis and Design (The Evolution)

The field has changed dramatically since the 1950s. The "modern" approach is best understood
by seeing how it evolved:

• 1950s-60s: This was the "art" phase. Computers were massive and expensive, so the
goal was processing efficiency. All applications were custom-built in low-level
machine language.
 • 1970s: The field became more disciplined, like engineering. The focus shifted from
"process-first" to "data-first" with the help of early database management systems.
• 1980s: Microcomputers (PCs) changed everything. The software industry expanded,
and "off-the-shelf" software became common. The analyst's role began shifting from a
"builder" to an "integrator".
• 1990s-Today: The focus is on system integration, the Internet, and agile development.
Today, we rarely build from scratch. We assemble systems from components, often
using cloud services. This requires analysts to be experts at integration.

3. Stakeholders: The Players in the Systems Game

A stakeholder is any person who has an interest in an existing or proposed information system.
Identifying them is critical because they are the source of the system's requirements.

Your slides and the book identify several key stakeholder groups:

• System Owners: The people who pay for and own the system.
• System Users: The people who will actually use the system day-to-day. This includes
a wide range of people, from clerical staff (internal users) to customers and suppliers
(external users).
• System Designers & Builders: The technical team of analysts, programmers, and other
specialists who create the system.

4. The Systems Analyst: A Problem-Solver

The systems analyst is the key professional in this entire process.

• Role: The analyst's primary role is to study the organization's problems and needs and
determine how people, methods, and information technology can best be combined to
bring about improvements.
• Core Identity: They are problem-solvers . They are agents of change and innovation
who act as a bridge between the business users and the technical team.
• Skills: As your slides note, an analyst needs a diverse set of skills: technical knowledge,
business knowledge, general problem-solving skills, and (perhaps most importantly)
strong interpersonal communication and relationship-building skills.
5. Sources of Application Software

An analyst's job changed from "builder" to "integrator" because we no longer have to build
every system from scratch. The "Sources of Application Software" slides show the modern
options, which are detailed in Chapter 2 of your book.

Here are the six primary sources:

1. IT Services Firms: You hire an outside company (e.g., Accenture, IBM) to build a
custom system for you.
2. Packaged Software Producers: You buy "off-the-shelf" software (e.g., Microsoft
Office, Intuit QuickBooks). This is a very common solution.
3. Enterprise-wide Solutions (ERP): You purchase a massive, integrated suite of
modules that manages all of the company's data and processes (e.g., SAP, Oracle). This
is a "build-your-own-system" kit on a massive scale.
4. Cloud Computing: You "rent" the software. The application is hosted on the internet
by a provider (e.g., [Link], Google Docs). This is becoming the dominant
model.
5. Open-Source Software: The software is freely available, and so is the source code.
You can use it as-is or modify it yourself (e.g., Linux, Firefox, mySQL).
6. In-House Developers: The "traditional" way. Your organization's own programmers
and analysts build the system from the ground up.

A key part of the analyst's job is to recommend which of these sources (or combination of
sources) is the best fit for the business problem.

6. The Systems Development Life Cycle (SDLC)

To manage the complex task of building a system, organizations use a standard process. The
most famous of these is the Systems Development Life Cycle (SDLC).

The SDLC is the traditional, standard methodology used to develop, maintain, and replace
information systems.

Think of it as the master recipe for systems development.

• It's a circular process. Maintenance on one system eventually leads to the planning for
its replacement.
• It is iterative. Phases are not always sequential; you often have to return to an earlier
phase as you learn new information.
7. Phases of the SDLC

Your slides and the book break this "recipe" into five distinct phases:

1. Planning: This is the "why" and "what" phase. The team identifies the need for a new
system, assesses its feasibility (can we build it? should we build it?), defines the
project's scope, and creates a Baseline Project Plan.
a. Deliverables: System justification, work plan, feasibility analysis.
2. Analysis: This is the "what" phase. The team thoroughly studies the organization's
current procedures and determines exactly what the new system must do. This has two
subphases:
a. Requirements Determination: Fact-finding (interviews, observation, etc.).
b. Requirements Structuring: Modeling the requirements (what you'll do in
Chapters 7 & 8).
c. Deliverables: Description of the current system, explanation of alternative
solutions.
3. Design: This is the "how" phase. The team converts the "what" (the requirements) into
a logical and then physical "how" (the system specifications).
a. Logical Design: Describes the functional features, independent of any specific
technology (e.g., "we need a customer database").
b. Physical Design: The technology-specific details (e.g., "we will use an Oracle
database on a Windows server").
c. Deliverables: Functional and technical specifications for all system elements
(data, inputs, outputs, programs).
4. Implementation: This is the "build and deliver" phase. The specifications are turned
into a working system that is coded, tested, and installed. This phase also includes
creating documentation, training users, and providing initial support.
a. Deliverables: Code, documentation, training procedures, and support
capabilities.
5. Maintenance: This is the "keep it running" phase. The system is systematically
repaired and improved to fix problems or adapt to changing business needs.
a. Deliverables: New versions or releases of the software.

8. Criticisms of the Traditional SDLC

The classic, rigid version of the SDLC is often called the Traditional Waterfall SDLC. It gets
its name because the project "flows" downhill from one phase to the next, like a waterfall.

As your slides point out, this model has serious criticisms:

• It's too rigid: The "waterfall" makes it hard to go back to a previous phase. It "locks
in" requirements too early, but business needs are constantly changing.
 • Limited User Involvement: Users are heavily involved in Analysis but may not see
the system again until Implementation, by which time it might not be what they wanted.
• Focus on Deadlines: The rigid phase structure focuses on meeting deadlines for
deliverables (e.g., "Is the logical design document finished?") rather than on building
high-quality, useful software.

9. Modern Development Approaches

Because of these criticisms, modern development has evolved.

Iterative Development The key alternative is Iterative Development. Instead of building the
entire system at once, the system is developed in successive iterations (or versions). Each
iteration goes through its own mini-SDLC (analysis, design, construction).

The Heart of Systems Development This iterative process is called the "Heart of Systems
Development". It's an Analysis-Design-Code-Test Loop. You analyze a small piece, design
it, code it, and test it. Then you take the next piece and repeat the loop, integrating it with the
first.

This iterative loop is the foundation of Agile Methodologies.

• Agile Manifesto: A set of principles valuing:

o Individuals and interactions over processes and tools.
o Working software over comprehensive documentation.
o Customer collaboration over contract negotiation.
o Responding to change over following a plan.

Capability Maturity Model (CMM)

Overview

The Capability Maturity Model (CMM) is a framework that organizations use to measure,
assess, and improve the quality of their software development process.

Think of it as a "maturity level" for an IT department. Its goal is to help an organization

move from having an unpredictable, chaotic process (Level 1) to having a mature, disciplined,
and optimized process (Level 5). This model was developed because so many significant
system projects were failing, and it was clear that the process for building software was a major
part of the problem.
The Five Levels of Maturity

Your slides show five distinct levels an organization can achieve. Each level builds on the
previous one:

1. Level 1: Initial
a. Description: The process is unpredictable, poorly controlled, and reactive.
b. Explanation: This is the "chaos" level. There are no stable, documented
processes. Success depends entirely on the heroic efforts of individuals. It's the
classic "firefighting" environment.
2. Level 2: Repeatable
a. Description: The process is characterized for projects and is often reactive.
b. Explanation: At this level, the organization has learned from past successes.
Basic project management practices (like cost tracking and scheduling) are in
place. They can repeat a successful project, but the process isn't standardized
across the entire organization.
3. Level 3: Defined
a. Description: The process is characterized for the organization and is proactive.
b. Explanation: This is a major leap. The organization now has a single, standard,
documented development process (like an SDLC) for all projects. This process
is understood, followed, and actively managed.
4. Level 4: Managed
a. Description: The process is quantitatively measured and controlled.
b. Explanation: You can't control what you don't measure. At this level, the
organization collects detailed data (metrics) on the quality of the process and its
products. This data is used to set quality goals and manage the process.
5. Level 5: Optimizing
a. Description: The focus is on continuous process improvement.
b. Explanation: At the highest level, the organization uses the data from Level 4
to not just manage the process, but to actively and continuously improve it. They
identify bottlenecks, test new ideas, and systematically make their development
process better, more efficient, and more effective.

Chapter 4

Identifying and Selecting Projects: The Process

The core of this chapter is a three-step process for choosing which IT projects to pursue.

Step 1: Identifying Potential Projects

First, where do the ideas for new systems come from? They can originate from two general
directions:
 • Top-Down Sources: These are projects identified by top management or a steering
committee. They tend to be strategic in nature, focusing on the broader needs of the
entire organization.
o Example: The CEO decides the company needs a new enterprise-wide system
to better compete with a rival. This would be a large, strategic project.
• Bottom-Up Sources: These are projects that bubble up from managers, business units,
or the IT department itself. They are often designed to solve a specific business problem
or take advantage of a new opportunity within a particular department.
o Example: The marketing department manager requests a new system to track
customer leads more effectively. This is a more tactical, focused project.

As a systems analyst, you will often be involved in helping user managers from these bottom-
up sources to formalize their requests and build the case for their proposed system.

Step 2: Classifying and Ranking Projects

Once we have a list of potential projects, we need a way to evaluate and prioritize them. We
can't just pick the one with the loudest advocate! We use a set of criteria to assess the merit of
each project. Some common criteria include:

• Strategic Alignment: How well does the project help the organization achieve its
strategic goals?
• Potential Benefits: How much will this project improve profits, customer service, or
efficiency?
• Resource Availability: Do we have the people, money, and tools to do this project?
• Project Size/Duration: How big is it and how long will it take?
• Technical Difficulty/Risks: How hard will it be to build?

A very powerful method for evaluating projects is Value Chain Analysis. This technique
involves looking at an organization's activities as a chain—from purchasing raw materials to
transforming them into products, to marketing, selling, and distributing them to customers. By
analyzing this chain, you can pinpoint where value is added and where costs are incurred, and
then prioritize IT projects that will provide the greatest benefit to that chain.

Step 3: Selecting Projects

This is the final decision-making step. It's not just a simple matter of picking the project with
the highest score. As Figure 4-3 shows, the decision is a blend of many factors: the needs of
the organization, existing systems, available resources, and the perspectives of the decision-
makers.

A useful tool for this step is Weighted Multicriteria Analysis. Let's look at the example from
your book (Figure 4-4):
 1. List Criteria: We list all the important requirements and constraints.
2. Assign Weights: Not all criteria are equally important. We assign a weight to each one
based on its relative importance. The weights must total 100%.
3. Rate Alternatives: Each potential project (or design alternative) is rated on a scale (e.g.,
1 to 5) for how well it meets each criterion.
4. Calculate Score: For each criterion, you multiply its weight by the rating to get a
score.
5. Sum the Scores: The alternative with the highest total score is often the best choice.

In the book's example, Alternative C has the highest overall score (430). However, notice that
Alternative A is the best when you only consider constraints (like cost). This shows that the
"best" choice isn't always clear-cut and often involves trade-offs.

Deliverables and Outcomes

The main output of this entire process is a schedule of specific IS development projects that
have been approved to move forward.

A key outcome is the concept of incremental commitment. This means that even though a
project is selected, it is not a guarantee that a full system will be built. The project is reviewed
after each phase of the SDLC, and the decision to continue is rejustified at each step. This
prevents organizations from throwing good money after a bad project.

The "Big Picture": Corporate and IS Planning

Good project selection is not an isolated activity. It's driven by the organization's overall
strategy. To make good choices, you must first have a clear plan.

Corporate Strategic Planning

This is an ongoing process that defines the mission, objectives, and strategies of an
organization. It's a three-step process:

1. Understand the current enterprise.

2. Define a vision for the future enterprise.
3. Develop a strategic plan to get from the current to the future state.

This process produces three key documents:

• Mission Statement: A simple statement that makes it clear what business the company
is in. (e.g., PVF's mission is to design and sell high-quality wood furniture ).
• Objective Statements: The broad, timeless goals for the organization (e.g., PVF will
strive to increase market share and be a leader in customer service ).
 • Competitive Strategy: The organization's "game plan" for achieving its mission and
objectives. Your book introduces three generic strategies from Michael Porter:
o Low-Cost Producer: Compete on price (e.g., Hyundai).
o Product Differentiation: Compete on a key product feature like quality or style
(e.g., Ford focusing on "Quality is Job One").
o Product Focus or Niche: Target a narrow market segment (e.g., convertible
sports cars).

Information Systems Planning (ISP)

ISP is the process of figuring out how information systems will help the organization achieve
its corporate objectives. It mirrors the corporate planning process:

1. Describe the Current Situation: This involves creating an inventory of the

organization's processes, data, technologies, and people. It often uses planning
matrices to show relationships (e.g., which business functions are performed at which
locations).
2. Describe the Target Situation: This involves creating blueprints for the desired future
state of the organization's IT.
3. Develop a Transition Strategy and Plan: This plan outlines the series of projects
needed to move from the current state to the future state. This becomes a primary source
for identifying new systems development projects.

This top-down planning approach ensures that IT projects are directly linked to the business's
overall strategy, leading to much better project selection decisions.

Applying this to Electronic Commerce

The process of identifying and selecting projects for an e-commerce application is the same,
but the context brings new factors to consider.

• The Internet is a global network of networks, and Electronic Commerce (EC) is the
use of the internet to support business activities. This includes not just B2C (Business-
to-Consumer) but also B2B (Business-to-Business) and the emerging Internet-of-
Things (IoT), where physical objects communicate over the internet.
• The Pine Valley Furniture WebStore Example: Your book uses PVF to illustrate
this. The company's board identified an opportunity for online sales. They decided to
start with the corporate furniture market because it had the greatest potential return on
investment and would be a good building block for future expansion into other markets.
This is a perfect example of a strategic, top-down project selection.

Chapter 5
This chapter is the "doing your homework" phase. Its entire purpose is to transform a vague,
one-page System Service Request (SSR) into a concrete, tangible project plan. This plan,
called the Baseline Project Plan, builds the business case that justifies spending the
organization's time, money, and resources.

This is a critical phase. A study by the U.S. Government Accountability Office (GAO) found
that up to 20% of IT project failures are due to a poor understanding of requirements, which
starts right here. Spending proper time in this phase—your book suggests 10-20% of the entire
project effort—is the single best way to prevent failure later.

Let's break down the process.

The Process of Project Initiation and Planning (PIP)

This phase consists of two main activities:

1. Project Initiation: This involves the "startup" tasks needed to get the project off the
ground. These are activities like assigning the project team, establishing a relationship
with the customer (the business unit), and developing the Project Charter (a high-level
document that formally announces the project).
2. Project Planning: This is the main focus of the chapter. It's the process of defining the
clear, discrete activities and the work needed to complete the project. This is where we
create our two key deliverables.

The Deliverables: What We Produce

There are two primary outputs, or deliverables, from this phase:

1. The Baseline Project Plan (BPP): This is the master foundation document for the
rest of the project. It contains the best estimates of the project's scope, benefits, costs,
risks, and resource requirements. This isn't a static document; it's a "baseline" that will
be updated as the project progresses and we learn more.
2. The Project Scope Statement (PSS): This is a short (often one-page) document
created for the customer. It's a high-level summary of the BPP that clearly describes
what the project will deliver. Think of it as a communication tool to ensure both the
project team and the customer are on the exact same page about the project's goals.

The rest of the chapter is dedicated to the most important part of building these documents: the
Business Case.
Assessing Project Feasibility: Building the Business Case

To justify a project, we must prove it's a good idea. We do this by conducting a feasibility
study that looks at the project from six different angles.

1. Economic Feasibility (Cost-Benefit Analysis)

This is the "dollars and cents" question: Is this project worth the money? We must identify
and quantify all the financial benefits and costs.

• Benefits:
o Tangible Benefits: These can be measured in dollars and with certainty.
Examples include reduced personnel expenses, lower transaction costs, or
higher profit margins.
o Intangible Benefits: These are benefits you can't easily measure in dollars.
Examples include improved employee morale, increased customer satisfaction,
or better decision-making.
• Costs:
o Tangible Costs: These are costs you can easily measure, such as hardware,
software licenses, and developer salaries.
o Intangible Costs: These are hard to quantify, like a temporary loss of customer
goodwill or a dip in morale during the transition.
o One-Time Costs: Expenses for project start-up, like development and new
hardware purchases.
o Recurring Costs: Ongoing expenses for using the system, like software
maintenance fees or new data storage.

The Time Value of Money (TVM): You can't just add up all the benefits for five years and
subtract the costs. The core concept of TVM is that a dollar today is worth more than a
dollar tomorrow (because today's dollar can be invested).

We must use a discount rate (the cost of capital) to calculate the present value (PV) of all
future costs and benefits. This allows us to compare the project's total worth in today's dollars.

Once we have the present values, we use three common techniques to judge the project:

1. Net Present Value (NPV): The total PV of all benefits minus the total PV of all costs.
If the NPV is positive, the project is a good investment.
2. Return on Investment (ROI): The ratio of net cash receipts divided by the cash
outlays. This shows the project's profitability as a percentage.
3. Break-Even Analysis (BEA): This technique finds the point in time (e.g., "in 2.4
years") when the cumulative benefits of the project finally equal its costs.
2. Technical Feasibility

This is the "can we build it?" question. We assess the development organization's ability to
construct the system. The risk is high if:

• The project is large: A large project is riskier than a small one.

• The structure is low: The requirements are "messy," ill-defined, or not well
understood.
• The team has low experience: The team is unfamiliar with the technology (e.g., a new
programming language or hardware) or the business area.

3. Operational Feasibility

This is the "if we build it, will they use it?" question. It assesses how well the proposed system
solves the business problems and fits with the existing organizational structure. A system that
requires people to change their jobs radically is operationally riskier than one that doesn't.

4. Schedule Feasibility

This is the "can we build it in time?" question. We assess the likelihood that the project's time
frame and completion dates can be met.

5. Legal and Contractual Feasibility

This is the "will we get sued?" question. We assess potential legal ramifications, such as
copyright infringements, labor law violations, or violating nondisclosure agreements.

6. Political Feasibility

This is the "who will try to block this?" question. It's an assessment of how key stakeholders
in the organization view the proposed system. A system can be a perfect "10" in all other areas,
but if a powerful executive feels threatened by it, they may try to block its success.

Building the Baseline Project Plan (BPP)

After completing the feasibility analysis, you assemble everything into the BPP. This document
is the "bible" for the project. Your book provides a standard outline (Figure 5-9):

1. Introduction: An executive summary. It includes a Project Overview (defining the

scope, justification, resources, and schedule) and a Recommendation (a summary of
findings and a call to action—e.g., "We recommend this project proceed").
 2. System Description: A high-level description of the system. It outlines the alternatives
you considered and explains the one you selected.
3. Feasibility Assessment: The detailed "business case" you just built. It contains the full
economic, technical, operational, schedule, legal, and political analyses.
4. Management Issues: This section outlines the "rules of the road" for the project. It
defines the team configuration, the communication plan, project standards, and any
other managerial concerns.

Reviewing the Baseline Project Plan

You don't just write the BPP and start coding. The final step of this phase is to have it reviewed.
The most common method for this is a Structured Walk-Through.

• What it is: A peer-group review of any deliverable (in this case, the BPP).
• The Goal: To ensure the quality of the plan and get buy-in from all stakeholders.
• The Roles: It's a formal meeting where team members play specific roles:
o Coordinator: Plans and facilitates the meeting.
o Presenter: Describes the work product to the group (usually you, the analyst).
o User: Makes sure the work product meets the customer's needs.
o Secretary: Takes notes and records decisions.
o Standards Bearer: Ensures the plan adheres to organizational technical
standards.
o Maintenance Oracle: Reviews the plan in terms of future maintenance needs.

This process follows the principle of incremental commitment. The walk-through is a formal
checkpoint. At the end, the project is either approved to move on to the next (and more
expensive) Analysis phase, sent back for revisions, or, in some cases, canceled. This rigorous
planning is what separates successful projects from failures.

Chapter 6: Determining System Requirements

You are now entering the Analysis phase of the Systems Development Life Cycle (SDLC).
This is where the real investigative work begins. Think of the Planning phase (Chapters 4-5)
as deciding which mountain to climb. The Analysis phase is about studying that mountain in
detail, scouting the terrain, and drawing the map you'll use for your ascent.

This phase is broken into two parts:

1. Requirements Determination (This chapter)

2. Requirements Structuring (Chapters 7 & 8)

Chapter 6: Determining System Requirements is all about the first part: fact-finding. It's the
process of gathering all the information on what the current system does (if one exists) and
what the new system must do.
Let's explore the methods you'll use to do this.

1. The Analyst as a Detective

To be a good analyst during this phase, you must adopt the mindset of a detective. You're
looking for clues that reveal the true nature of the business problem. Your book highlights
several key characteristics you'll need:

• Impertinence: You must question everything. Don't accept "we've always done it that
way" as an answer.
• Impartiality: Your job is to find the best solution, not to (for example) justify buying
a specific piece of hardware or software. You must remain unbiased.
• Relax Constraints: At first, assume anything is possible. Don't let traditions or
assumptions limit your investigation.
• Attention to Details: Every fact must fit together. A small oversight now can lead to a
major system failure later.
• Reframing: You must look at the organization in new and different ways. Be creative
and don't just copy an old system.

The primary deliverables (or outputs) of this work are the notes, transcripts, documents, and
prototypes you collect. You must be careful to avoid "analysis paralysis"—the common trap
of spending so much time on fact-finding that you never actually move on to designing the
solution.

2. Traditional Methods for Determining Requirements

These are the classic, time-tested techniques for gathering information.

Interviewing and Listening

This is one of the primary ways analysts gather information. It's a conversation with
stakeholders (users, managers, etc.) to get their facts, opinions, and perspectives.

• The Process:
o Plan: Set up an appointment and prepare an interview guide—a checklist of
your questions.
o Execute: Be neutral, listen carefully, and take thorough notes.
o Review: Type up your notes within 48 hours. After that, your memory will
fade.
• Question Types:
o Open-Ended Questions: These have no prespecified answers (e.g., "What
would you say is the best thing about the system you currently use?"). They are
great for discovering information you didn't know to ask about, but they can
take a lot of time.
 o Closed-Ended Questions: These ask the user to choose from a set of answers
(e.g., "Which of the following is the best... A, B, or C?"). They are more efficient
and easier to summarize, but you might miss key details.

Interviewing Groups

You can also interview several people at once.

• Advantages: This is a more effective use of your time, and it allows group members to
build off each other's ideas (synergy).
• Disadvantages: Group interviews are notoriously difficult to schedule.
• Nominal Group Technique (NGT): This is a more structured way to conduct a group
interview. The process involves group members first working alone to write down their
ideas. Then, a facilitator collects and discusses all ideas with the group. This ensures
that quieter members' voices are heard.

Directly Observing Users

This involves watching people as they actually do their jobs.

• Why? People often don't have a completely accurate appreciation of what they do or
how they do it.
• Analogy (The "Lost Soft Drink Sales" Story): Your book gives a great example of
an analyst who couldn't figure out why a new, more efficient routing system was
decreasing sales. By riding along with a driver (observing), he discovered the new
system was too efficient—it didn't leave drivers any time for the "schmoozing" with
store managers that was necessary to get good shelf placement. The analyst would have
never found this in an interview.
• Drawbacks: Being observed can make people nervous and change their normal
behavior. It's also time-consuming and gives you only a "snapshot" of the work.

Analyzing Procedures and Other Documents

This involves studying the paper trail of the organization. By analyzing documents, you can
discover business rules, see what data is critical, and identify problems.

• Key Documents to Analyze:

o Written Work Procedures: These are the official "how-to" manuals for a job.
o Business Forms: These are excellent for showing what data is captured (e.g., a
customer order form).
o Reports: These show the output of a system, which tells you what data must be
stored and processed (e.g., a "Monthly Sales Report").
o Existing System Documentation: Manuals, flowcharts, or data dictionaries
from the current system.
This analysis often reveals a key concept: the difference between the Formal System (what
the documents say people do) and the Informal System (the way people actually work). A
good analyst must understand both.

3. Contemporary Methods for Determining Requirements

Because the traditional methods can be slow, several "contemporary" methods were developed
to speed up analysis.

Joint Application Design (JAD)

JAD is a structured, intensive session where key users, managers, and analysts are brought
together (often in an off-site location) for several days to define system requirements.

It's like a highly facilitated,-powered group interview. The key participants are:

• JAD Session Leader: The trained facilitator who runs the meeting.
• Users: The people who will use the system.
• Managers: Those who have an organizational stake in the system.
• Sponsor: The high-level executive who pays for the project.
• Systems Analysts: Your team, there to listen and learn.
• Scribe: The person who takes detailed notes, often on a laptop.

The JAD process helps resolve conflicts and builds user commitment, but it can be very
expensive to have so many key people in one room for so long.

Prototyping

A prototype is an iterative process where you build a rudimentary, working version of the
system and show it to users.

1. You build a "quick and dirty" model.

2. The user tests it. Seeing the model causes them to say, "Oh, now that I see it, I realize
I need a button for..."
3. You modify the prototype and show it to them again.
4. This cycle repeats until the requirements are well understood.
• Evolutionary Prototyping: The prototype is gradually refined until it becomes the
final system.
• Throwaway Prototyping: The prototype is just a simple model (sometimes just on
paper) built to answer a specific question. It is discarded after its purpose is served.
4. Radical Methods for Determining Requirements

Sometimes, the goal isn't just to improve a process, but to completely obliterate it and start
over.

This is Business Process Reengineering (BPR). BPR is the search for, and implementation
of, radical change in business processes to achieve breakthrough improvements.

• "Clean Sheet of Paper": BPR asks, "If we were a brand new company, how would
we accomplish this task?".
• Key Business Processes: BPR focuses on redesigning core, cross-functional processes
(e.g., "filling an order," which crosses sales, inventory, and shipping).
• Disruptive Technologies: BPR often uses new technologies to break old business rules.
For example:
o Old Rule: Information can only be in one place at a time.
o Disruptive Technology: Distributed databases.
o New Process: Multiple people in multiple locations can work on the same data
at the same time.

5. Agile Methodologies

These are modern, flexible methods that try to keep the analysis process fast and responsive to
change.

• Continual User Involvement: The user becomes a full-time member of the

development team, providing requirements in real-time. This works best with the
iterative "analysis-design-code-test" cycle.
• Agile Usage-Centered Design: This is an 8-step, JAD-like process. It's highly
structured and focuses on identifying user roles, their goals, and the tasks they must
perform to achieve those goals.
• The Planning Game (from eXtreme Programming): This is a structured interaction
between "Business" (the customer) and "Development" (the team).
o Exploration: Business writes "Story Cards" (features they want). Development
provides a time estimate.
o Commitment: Business sorts the cards by necessity, Development sorts by risk,
and together they choose which "stories" to build in the next release.
o Steering: The team shows the working software to Business, who can then
"steer" the project by adjusting the plan.

6. E-Commerce Example: The PVF WebStore

Your book shows how Pine Valley Furniture (PVF) used a JAD session to gather the
requirements for its new WebStore. In just three days, they collected detailed requirements on:
 • System Layout and Navigation: What the site should look like (e.g., "logo is always
in the same place").
• System Capabilities: What the site should do (e.g., "have a shopping cart" and
"product search").
• Customer and Inventory Information: What data needs to be stored.
• System Prototype Evolution: A plan to roll out the system in three stages .

This shows how a "contemporary" method like JAD can be used to quickly gather detailed
requirements for a modern e-commerce application.

Chapter 7: Structuring System Process Requirements

This chapter is one of the most important in all of systems analysis. In Chapter 6, we were in
"fact-finding" mode—we conducted interviews, observed users, and gathered documents to
determine what the system needs to do.

Now, in Chapter 7, we take that massive collection of notes, transcripts, and forms and translate
it into a formal, structured "blueprint" of the system's processes. This is the first step in moving
from a list of requirements to an actual model of the new system.

We will cover four main topics from this chapter:

1. Data Flow Diagrams (DFDs): The classic, traditional tool for modeling system
processes.
2. Decision Tables: A tool for modeling complex logic and business rules inside a process.
3. Object-Oriented Diagrams (Use Cases & Activity Diagrams): The modern, object-
oriented alternative to DFDs.
4. Business Process Modeling Notation (BPMN): A powerful standard for modeling
detailed business workflows.

Let's begin with the traditional core of process modeling.

1. Process Modeling with Data Flow Diagrams (DFDs)

What is Process Modeling? Process modeling is a technique for graphically representing the
functions, or processes, that capture, manipulate, store, and distribute data between a system
and its environment.

The most common tool we use for this is the Data Flow Diagram (DFD). A DFD is not a
flowchart. It does not show the order of steps; it only shows the movement of data through the
system. Think of it as a map of the data's journey.
DFD Mechanics: The Four Key Symbols

DFDs are simple and powerful, using only four symbols . Your book uses the Gane & Sarson
notation:

1. Process:
a. A rectangle with rounded corners.
b. This is an action or work performed on data. It must have a verb-phrase name,
like "Calculate Grade" or "Update Inventory".
2. Data Store:
a. A rectangle open on the right side.
b. This is data at rest—a "file cabinet" or a "database table" where data is stored.
It has a noun-phrase name, like "Student File" or "Inventory".
3. Source/Sink (External Entity):
a. A square.
b. This is the origin or destination of data. It is outside the system we are building.
Examples include "Customer," "Manager," or "Bank System".
4. Data Flow:
a. An arrow.
b. This is data in motion. It shows the data moving from one place to another and
has a noun-phrase name, like "Customer Order" or "Payment Receipt" .

DFD Levels (The "Google Maps" Analogy)

DFDs are hierarchical. We use a process called functional decomposition to break the system
down into smaller and smaller pieces. The easiest way to think about this is like using Google
Maps:

Context Diagram (The "Satellite View")

• This is the highest-level view of the entire system.

• It has only one process box (labeled "0") representing the whole system (e.g., "Food
Ordering System").
• It shows no data stores. It only shows the system's boundaries, all the external entities
(Sources/Sinks), and the main data flows that go in and out.

Level-0 Diagram (The "Country View")

• This is the "zoomed-in" view of the Context Diagram.

• It shows the major processes (e.g., "1.0 Receive Order," "2.0 Update Inventory") that
are inside the single Process 0 box.
• This is the first time we see the Data Stores (like "D1 Inventory File").
• It must be balanced with the Context Diagram.
Key DFD Rule: Balancing

Balancing is the single most important rule of DFDs. It means that all the data flows going
into and out of a process on a high-level diagram must exactly match the data flows going into
and out of the entire "zoomed-in" diagram for that process on the next level .

Think of it this way: If the "Satellite View" (Context Diagram) shows one river flowing into a
country, the "Country View" (Level-0 Diagram) must also show that same river flowing in.
You can't add or delete rivers.

DFD Levels 1, 2, ...n (The "City & Street View")

• We can "zoom in" again on any process from the Level-0 diagram.
• Decomposing Process 1.0 (e.g., "Receive Order") would create a Level-1 Diagram
with subprocesses like "1.1 Enter Customer Data," "1.2 Check Credit," etc..
• We continue decomposing until we reach the primitive DFD—the lowest level, where
a process cannot be broken down any further (it's a single decision, calculation, or
database operation).

Using DFDs for Analysis

DFDs are powerful analysis tools:

• Gap Analysis: We can draw DFDs for the current system and the proposed system,
then compare them to see what processes need to be added, deleted, or changed.
• Finding Inefficiencies: We can spot redundancies (e.g., the same data being entered
twice) or data that is captured but never used.
• Business Process Reengineering (BPR): DFDs are perfect for BPR. The IBM Credit
Corporation example in your book is classic:
o The "as-is" DFD showed a complex, 5-step process that took six days.
o The "to-be" DFD (after reengineering) showed a single process handled by one
person, cutting the time to 90 minutes. The DFD visualizes this improvement
perfectly.

2. Modeling Logic with Decision Tables

A DFD process box, like "Determine Reorder Quantity," tells you what it does, but not how it
decides. For complex logic, we use a Decision Table.

A decision table is a matrix that shows all possible conditions and the resulting actions. It's a
structured way to model "if-then-else" logic.
It has three parts:

1. Condition Stubs: The "if..." part. Lists the conditions that matter (e.g., "Type of item?,"
"Time of week?").
2. Action Stubs: The "then..." part. Lists the actions that can result (e.g., "Standing daily
order," "Minimum order quantity").
3. Rules: The columns that link specific conditions to specific actions.

A key technique for simplifying the table is to look for Indifferent Conditions. If the action
is the same regardless of a condition's value, we can put a dash ("-") in that cell to show it
doesn't matter, which lets us combine multiple rules into one.

3. The Object-Oriented (OO) Approach (Appendices 7A & 7B)

DFDs are part of the "traditional" structured approach. The modern, and very common,
alternative is the object-oriented (OO) approach, which uses different diagrams.

Chapter 8 Structuring System Data Requirements

We are going to move from "Process Modeling" (Data Flow Diagrams, which show how data
moves) to "Data Modelling" (E-R Diagrams, which show how data is structured).

Think of it this way: If DFDs are the "plumbing" of a house (showing where water flows),
Data Modelling is the "framing" and "storage closets" (showing where things fit and stay).

Here is your structured, comprehensive lesson plan.

Part 1: The "Why" and "Where" (Context)

1. What is Conceptual Data Modelling?

A conceptual data model is a detailed representation of the data needed by an organization. It

is independent of any specific software (like MySQL or Oracle). It focuses on business rules,
not technical implementation.

• Key Concept: It is implementation independent. This means we are drawing the

data structure based on business rules, not based on whether we are using Oracle,
MySQL, or Excel. We don't care how it's stored yet; we care what it is.
• The Goal: To show the rules about meaning and interrelationships among data.

Why do we do it?
 • Data is permanent; Processes change: The way you sell a product might change next
year, but the fact that a "Customer" places an "Order" is a fundamental business fact
that rarely changes.
• Similarity: Data structures are often similar across different organizations in the same
industry.

Where does it fit? It happens during the Analysis Phase of the Systems Development Life
Cycle (SDLC).

• Input: You gather requirements from interviews and documents.

• Output: An Entity-Relationship (E-R) Diagram.

2. Where does it fit in the SDLC? (Slides 3-4)

Look at the Systems Development Life Cycle (SDLC).

• Planning Phase: We create a high-level "Enterprise-wide data model" (very basic).

• Analysis Phase (Where we are now): We build the Conceptual Data Model. This is
the detailed E-R (Entity-Relationship) diagram.
• Design Phase: We later convert this E-R diagram into a "Logical Data Model"
(database tables).

The Process (Top-Down vs. Bottom-Up):

• Top-Down: You interview management and ask, "What is your business about?" You
derive the data from the big picture.
• Bottom-Up: You look at specific forms, reports, and screens (like the Invoice in Slide
46) and figure out what data is on them. You build the model from the details up.

Part 2: The Building Blocks

To build an E-R Diagram, you need three main components: Entities, Attributes, and
Identifiers.

1. Entities (The Nouns)

• Definition: A person, place, object, event, or concept about which the organization
wants to maintain data.
• Entity Type vs. Entity Instance:
• Entity Type: The category (e.g., STUDENT). In the diagram, this is the box.
• Entity Instance: A specific single occurrence (e.g., John Smith, ID# 9988).
This is the data inside the database.
• Strong vs. Weak Entity (Slides 47-54):
 • Strong Entity: Can exist on its own. Example: EMPLOYEE. It has a unique
ID (Employee_ID).
• Weak Entity: Cannot exist without a "Strong" owner. Example:
DEPENDENT (like a child of an employee). You can't list a dependent in the
HR system unless they are attached to an employee.
• Identifying Relationship: The link between the strong and weak entity.

2. Attributes (The Adjectives)

Attributes describe the entity. If STUDENT is the entity, Name, GPA, and Address are the
attributes.

Types of Attributes (Important!):

• Required vs. Optional:

• Required: Must have data (e.g., Student_ID).
• Optional: Can be left blank/Null (e.g., Major - a freshman might not have one
yet).
• Simple vs. Composite:
• Simple: Atomic. Cannot be broken down (e.g., Age, Gender).
• Composite: Can be broken down. Example: Address (breaks down into Street,
City, State, Zip).
• Single-Valued vs. Multivalued:
• Single: You only have one (e.g., Date_of_Birth).
• Multivalued: You can have many. Example: Skill. An employee can know
Java, Python, and SQL. Notation: Represented by a double oval or curly
brackets {Skill}.
• Derived:
• Calculated from other data. Example: Age is derived from Date_of_Birth and
Current_Date. We don't store "Age" because it changes every day; we
calculate it. Notation: Dashed oval.

3. Identifiers (The Keys)

• Candidate Key: An attribute that could uniquely identify an entity (e.g., Both
Student_ID and Social_Security_Number are unique).
• Identifier (Primary Key): The candidate key we choose to use.
• Composite Identifier: When one attribute isn't enough, we use two. Example: In a
FLIGHT entity, Flight_ID might not be unique (Flight 101 flies every day). The
identifier is Flight_ID + Date.
Part 3: The Glue (Relationships)

Relationships are the lines connecting the boxes. They are usually Verbs.

1. Degree of Relationship (How many entities are involved?)

• Unary (Recursive): A relationship with itself.

• Example: An EMPLOYEE manages another EMPLOYEE.
• Binary: A relationship between two entities. (Most common).
• Example: A STUDENT takes a COURSE.
• Ternary: Simultaneous relationship among three entities.
• Example: A VENDOR supplies a PART to a WAREHOUSE. (You need all
three to understand the transaction).

2. Cardinality (The Numbers)

This answers the question: "How many instances of Entity B are related to Entity A?"

• 1:1 (One-to-One): An Employee has one Parking Spot; a Parking Spot has one
Employee.
• 1:N (One-to-Many): A Customer places many Orders; An Order belongs to one
Customer.
• M:N (Many-to-Many): A Student takes many Courses; A Course has many Students.

3. Participation Constraints

• Total Participation (Double Line): EVERY instance must participate.

• Example: Every LOAN must have a BORROWER. (You can't have a loan
record without a person attached).
• Partial Participation: NOT every instance must participate.
• Example: EMPLOYEE manages DEPARTMENT. Not every employee is a
manager, so participation is partial.

Part 4: Advanced Modeling Concepts

Supertypes and Subtypes

Sometimes entities are very similar but have small differences. This is called Generalization.

• Supertype (Parent): EMPLOYEE. Attributes: Name, Address, Hired_Date (shared

by everyone).
• Subtype (Child):
• HOURLY_EMPLOYEE: Attribute = Hourly_Rate.
 • SALARIED_EMPLOYEE: Attribute = Stock_Options.
• Why do this? To avoid nulls. If we put "Hourly_Rate" on the main Employee table,
the Salaried people would have blank spaces. Subtyping cleans the structure.

Part 5: Case Study Explanations

Let's walk through the COMPANY Database example found in the slides. This is a classic
test of your ability to translate text requirements into a diagram.

Requirement 1: "The company is organized into DEPARTMENTs... Department controls a

number of PROJECTs."

• Diagram Result: You draw a DEPARTMENT box and a PROJECT box. You draw a
line connecting them called CONTROLS. It is 1: N (One department controls Many
projects).

Requirement 2: "Each employee works for one department but may work on several
projects."

• Diagram Result:
• Line between EMPLOYEE and DEPARTMENT (WORKS_FOR).
Cardinality is N:1 (Many employees work for One department).
• Line between EMPLOYEE and PROJECT (WORKS_ON). Cardinality is
M:N (Many employees work on Many projects).

Requirement 3 (The Tricky One): "We need to keep track of the number of hours per week
that an employee works on each project."

• Explanation: You cannot put "Hours" in the Employee box (which project?). You
cannot put "Hours" in the Project box (which employee?).
• Solution: "Hours" is an attribute of the Relationship itself (WORKS_ON). In the
diagram (Slide 64), notice that "Hours" is attached to the diamond WORKS_ON.

Summary of Diagram Notations

You will see different symbols in the slides (Chen) vs. the Book (Crow's Foot). As an analyst,
you must read both.

1. Chen Notation (used in many slides):

• Rectangle: Entity.
• Diamond: Relationship.
• Oval: Attribute.
• Lines: Connections.
2. Crow's Foot (used in the Book/Visio):
 • Box: Entity (Attributes are listed inside the box).
• Lines: Relationships.
• The "Crow's Foot" (three branching lines): Represents "Many".
• The "Bar" ( | ): Represents "One".
• The "Circle" ( O ): Represents "Zero" (Optional).

Chapter 9: Designing Databases.

In Chapter 8, we acted like architects drawing a blueprint (E-R Diagrams) of a house. We
decided what rooms (Entities) we needed.
In Chapter 9, we act like engineers. We are going to decide exactly how to build that structure,
so it doesn’t collapse. We will convert those drawings into actual database tables (Logical
Design) and decide how to store them on a hard drive (Physical Design).

Here is your structured, comprehensive guide to this chapter.

Part 1: The Database Design Process

Database design isn't just one step; it is a journey from abstract ideas to computer code.

1. The Three Levels of Design (Slide 5)

This is the most important framework to understand.

• Conceptual Design (E-R Models): This is what we did in Chapter 8. It is a high-level

drawing of business rules. It doesn't care if you use Oracle, MySQL, or Excel.
• Logical Design (Relational Model): This is the focus of this chapter. We convert the
drawings into Tables (Relations). It is still software-independent, but it looks like a
spreadsheet structure.
• Physical Design: This is the technical implementation. We decide data types (e.g.,
"This ID is 10 numbers long") and how to store files on the disk for speed.

2. Inputs and Outputs (Slide 6-7)

• Input: You take the E-R Diagram (from Ch 8) and the Forms/Reports (from Ch 7).
• Process: You clean up the data (Normalization) and combine different views (View
Integration).
 • Output: A set of Normalized Relations (Clean tables).

Part 2: The Relational Database Model

Most modern systems (SQL, Oracle, DB2) use the Relational Model.

In the academic world (Logical design), we use specific words. In the physical world (Physical
design), we use different words. You must know the translation:

Logical Model Physical/Common Definition

Term Term
Relation Table A two-dimensional grid of data.
Tuple Row (Record) One specific entry (e.g., John Smith's
data).
Attribute Column (Field) A characteristic (e.g., Name, Email).

Properties of a Relation (Slide 11)

Not every table is a "Relation." To be a Relation, it must follow strict rules:

1. Unique Name: Every table has a unique name.

2. Atomic Entries: No cell can contain multiple values (e.g., you cannot list three phone
numbers in one cell).
3. Unique Rows: No two rows can be exactly the same.
4. Order Irrelevant: The order of rows or columns does not matter.

Part 3: Integrity Constraints

Constraints are the "rules of the road" that keep data accurate. Without them, your database
becomes a garbage dump.

1. Domain Constraints

The value entered must be valid.

• Example: A GPA must be between 0.0 and 4.0. You cannot enter "Apple" into a GPA
column.

2. Entity Integrity (Primary Keys) (Slides 16–22)

• Primary Key: An attribute that uniquely identifies a row. (e.g., Student ID).
• The Rule: A Primary Key cannot be NULL (empty). If you don't have an ID, you
don't exist in the database.
 • Slide 17-19 Note: A Candidate Key is any attribute that could be a Primary Key (e.g.,
SSN or Email). You choose one to become the Primary Key.

3. Referential Integrity (Foreign Keys) (Slides 23–25)

This rule connects two tables.

• Foreign Key: A field in one table that points to the Primary Key of another table.
• The Rule: If Table B points to Table A, the record in Table A must exist.
• Example (Slide 25): You cannot create an Order for a Customer who does not exist.
The Customer_ID in the Order table must match a Customer_ID in the Customer table.

Part 4: Transforming E-R Diagrams into Relations

This is the technical core of the chapter. How do we turn the boxes and lines from Chapter 8
into Tables?

Rule 1: Regular Entities (Slide 30-32)

• Action: Create a table for the entity. The Identifier becomes the Primary Key.
• Example: CUSTOMER entity becomes CUSTOMER table.

Rule 2: Composite Attributes (Slide 33)

• Problem: One attribute has many parts (e.g., Address = Street, City, Zip).
• Action: Break it down. Make separate columns for Street, City, and Zip. Do not keep
the main "Address" field.

Rule 3: Multivalued Attributes (Slide 34)

• Problem: An employee has multiple skills (Java, Python, C++). You cannot put three
skills in one cell.
• Action: Create a separate table.
• Diagram Explanation: The new table (EMPLOYEE_SKILL) contains the Employee
ID (Foreign Key) and the Skill. The Primary Key is the combination of both.

Rule 4: Weak Entities (Slide 35-36)

• Problem: A Dependent (child) relies on an Employee.

• Action: Create a table for the Weak Entity. Its Primary Key is a combination of its own
partial key + the Owner's Primary Key.
• Example: Dependent PK = Employee_ID + Dependent_Name.
Rule 5: Binary Relationships (Slides 37–40)

• One-to-Many (1:N):
• The Rule: Take the Primary Key from the "One" side and put it into the "Many"
side as a Foreign Key.
• Example (Slide 38): One Customer places Many Orders. Put Customer_ID
inside the ORDER table.
• Many-to-Many (M:N):
• The Rule: Create a new third table (Associative Relation). It holds the Primary
Keys of both connected entities.
• Example (Slide 39): Students and Courses. Create a REGISTRATION table
containing Student_ID and Course_ID.
• One-to-One (1:1):
• The Rule: Take the Primary Key from the mandatory side and put it in the
optional side.

Rule 6: Advanced Relationships (Slides 41–43)

• Unary (Recursive) 1:N: (Slide 41)

• Scenario: An Employee manages other Employees.
• Action: Add a Manager_ID column to the EMPLOYEE table. It points back to
the Employee_ID in the same table.
• Ternary: (Slide 42-43)
• Scenario: A Doctor gives a Patient a Treatment.
• Action: Create a new table (PATIENT_TREATMENT). It contains three
Foreign Keys: Patient_ID, Physician_ID, and Treatment_Code.

Rule 7: Supertype/Subtype (Slide 44-45)

• Scenario: EMPLOYEE is the parent. HOURLY, SALARIED, CONSULTANT are

subtypes.
• Action:
1. Create one table for the Supertype (Employee).
2. Create separate tables for each Subtype.
3. The Primary Key for the subtypes is the same as the Supertype. It acts as both
PK and Foreign Key.

Part 5: Normalization

(Implied in Slides, Detailed in Book)

Normalization is "cleaning" your tables to remove redundancy (repetition).

 • 1st Normal Form (1NF): Eliminate repeating groups. Every cell must have a single
value. (Basically, convert Multivalued attributes to new tables).
• 2nd Normal Form (2NF): Eliminate Partial Dependencies.
• Rule: If you have a composite Primary Key (e.g., OrderID + ProductID), every
non-key column must depend on both parts, not just one.
• 3rd Normal Form (3NF): Eliminate Transitive Dependencies.
• Rule: A non-key column cannot depend on another non-key column.
• Example: If you have Zip_Code and City in a Customer table, City depends on
Zip_Code. Move them to a separate Location table.

View Integration (Merging Relations):

When you have multiple diagrams (e.g., one for HR, one for Payroll), you merge them. You
must resolve:

• Synonyms: Different names for the same thing (Student_ID vs. Matriculation_No).
• Homonyms: Same name for different things (Account could mean Bank Account or
User Account).

Part 6: Physical Database Design

(Covering Book Content regarding Physical Design)

Once the Logical tables are ready, we optimize them for the computer hardware.

1. Data Types

You must choose the correct storage format to save space and ensure integrity.

• VARCHAR: Variable length text (e.g., Names). Good for saving space.
• CHAR: Fixed length text (e.g., State Abbreviations "TX", "NY"). Faster processing.
• INT/NUMBER: For calculations.
• BLOB: Binary Large Object (for images or sound).

2. File Organization (How data sits on the disk)

• Sequential: Records are stored one after another (like songs on a cassette tape).
• Pros: Good for reading the whole file.
• Cons: Slow for finding one specific record.
• Indexed: A separate file (Index) keeps track of where records are (like the index at the
back of a textbook).
• Pros: Fast retrieval.
• Cons: Takes up extra space.
• Hashed: A mathematical formula calculates the address of the record.
 • Pros: Fastest possible retrieval for specific records.
• Cons: Terrible for retrieving ranges of data.

Part 7: Explanation of Slide Case Studies

1. The Company Database (Slides 59-67)

This is a comprehensive example.

• Slide 62 (Initial Entity Types): Shows the raw entities (Employee, Dept).
• Slide 64 (E-R Diagram): Introduces relationships.
• WORKS_ON is M:N (Many employees, Many projects). It has an attribute
"Hours".
• DEPENDENT is a weak entity (double diamond).
• Slide 67 (UML Class Diagram): This translates the E-R diagram into UML notation
(boxes with lines). It shows the exact same logic but uses "1..*" notation for cardinality.

2. Pine Valley Furniture (Slide 68, 52-55)

• Slide 52: Shows the full schema. Notice ORDER_LINE. This is an Associative Entity
created from the Many-to-Many relationship between ORDER and PRODUCT.
• Slide 54: The blue arrows represent Referential Integrity. They show that Product_ID
in the ORDER_LINE table points to the PRODUCT table.

3. Heather Sweeney Designs (Slides 56-58)

• Slide 56: Shows the Logical Data Model.

• Slide 58: Shows the Cascading Behavior.
• On Update Cascade: If a Customer ID changes, update it in all Order tables
automatically.
• On Delete Restrict: Do not allow a user to delete a Customer if they still have
active Orders.

Instructor's Summary

1. Design Process: Conceptual (Brainstorming) → Logical (Tables) → Physical (Hard

drive optimization).
2. Integrity: Primary Keys identify rows; Foreign Keys link tables.
3. Mapping:
• 1:N → Foreign Key goes to the "Many" side.
• M:N → Create a new table.
4. Normalization: Clean up the tables to prevent redundancy.
By following these steps, you ensure that the database is accurate, efficient, and capable of
growing with the business.

By following these steps, you ensure that the database is accurate, efficient, and capable of
growing with the business.

Chapter 10: Designing Forms and Reports.

As a System Design Analyst, I can tell you that this chapter is one of the most visible parts of
your job. You can write the best code in the world on the back end, but if the Forms (where
users input data) and Reports (where users read data) are ugly, confusing, or hard to use, users
will hate the system.

We are going to cover everything from the slides and the book, structured logically to make it
easy to digest.

Part 1: The Context (Where are we?) (Slides 1–3)

The Big Picture:

We are in the Design Phase of the Systems Development Life Cycle (SDLC).

• In the Analysis phase, we figured out what the system needs to do.
• Now, in the Design phase, we figure out how it looks and interacts with the user.

The Goal:
To move from abstract requirements to the actual "look and feel" of the system. We call this
Logical Design. We are designing the "User Interface" (UI).

Part 2: Definitions (Forms vs. Reports)

Before we design, we must define what we are building.

1. Form

• Definition: A business document that contains some predefined data but includes areas
where the user needs to enter or modify data.
• Key Concept: Forms are for INPUT or Action.
• Example: A checkout page on Amazon, an Employee Registration screen, or an ATM
screen where you type your PIN.
• Structure: Usually stylized, not just simple rows/columns. Ideally based on one
specific database record (e.g., one customer).

2. Report
 • Definition: A business document that contains only predefined data. It is a passive
document.
• Key Concept: Reports are for OUTPUT or Reading. You do not type into a report.
• Example: A monthly bank statement, a sales summary, or a pie chart.
• Structure: Often simple rows and columns. Usually contains data from many records
(e.g., all sales for the month).

Part 3: Types of Business Reports (Slide 5)

In the business world, reports generally fall into five specific categories. You need to know
which one your user needs:

1. Scheduled Reports: Produced automatically at fixed intervals (Daily, Weekly).

Example: A weekly payroll summary.
2. Key-Indicator Reports: Provide a summary of critical info. Example: A dashboard
showing total profit for the day.
3. Exception Reports: Highlights data that is out of the normal range. Example: A list
of items that are low on stock (below 10 units). These are great because managers don't
have to read everything, just the problems.
4. Drill-Down Reports: Starts with a summary, but allows users to click to see details.
Example: Clicking on "Annual Sales" to see "Monthly Sales," then clicking "June" to
see specific invoices.
5. Ad-hoc Reports: Unplanned. Generated on demand for a unique problem. Example:
"Show me all sales of red shoes in Texas last Tuesday."

Part 4: The Design Process (Prototyping)

(Slides 6–12)

How do we actually create these? We use a User-Centered Design approach. This means we
focus on the user, not just the technology.

The Workflow:

1. Collect Requirements: Who is the user? What is the task? Environment?

2. Structure: Create an initial prototype.
3. Evaluate: Ask users to test it.
4. Refine: Fix errors and repeat until satisfied.

Tools for Designing (The Evolution):

1. Coding Sheet (Slide 10):

• What is it? Old school graph paper with boxes for every character.
 • Use: Used when screens were green-text-only (80 columns x 25 rows). Rarely
used now, but good for understanding strict spacing.
2. Wireframe (Slide 8 & 11):
• What is it? A simple, low-fidelity sketch. It shows placement (where the button
goes) without design (colors/fonts).
• Why use it? It is fast. You can draw it on a napkin or use tools like Balsamiq. It
lets you test the flow without spending money on coding.
3. Visual Basic / Actual Code (Slide 9 & 12):
• What is it? High-fidelity prototype. It looks like the real app.
• Why use it? To test font sizes, colors, and actual interaction.

Part 5: Formatting Guidelines (The "Rules of the Road")

This is the core skill of a designer. If you follow these rules, your system will be usable.

A. General Layout (Slides 13-16)

• Meaningful Titles: Don't call it "Screen 1." Call it "Customer Entry Form." Include
the Date (Current date vs. Data date).
• Balance: Don't cram everything on one side. Use white space.
• Navigation: It should be obvious how to move forward, backward, or exit.
• Meaningful Information: Only display what is necessary. Don't clutter the screen.

Visual Example Analysis (Slide 15 vs 16):

• Bad Form (Slide 15): The title is vague ("Customer Information"). The fields are
crammed together. There is no clear way to exit. Labels are confusing.
• Good Form (Slide 16): Clear title ("Detail Customer Account Information"). Fields
are grouped logically. Buttons (Save, Help, Exit) are clear at the bottom.

B. Highlighting (Slides 17–19)

Use highlighting to draw attention to exceptions or errors. Do NOT use it constantly.

• Methods: Blinking, Bold, Size difference, Reverse video (black text on white), Boxing,
Underlining.
• Rule of Thumb: Blinking is aggressive. Use it only for critical alerts (e.g., "System
Meltdown"). Use Bolding for headers.

C. Color (Slide 20)

• Pros: Soothes the eye, accents interesting data, helps organization.

• Cons: Color blindness (approx. 8% of men). Colors look different on different monitors.
 • Rule: The system must be usable in Black & White. Color should be an enhancement,
not a requirement to understand the data.

D. Text Guidelines (Slides 21-23)

• Case: Mixed case (e.g., "Enter Name") is easier to read than UPPER CASE ("ENTER
NAME"). Upper case feels like shouting and is slower to read.
• Spacing: Use double spacing for long blocks of text.
• Justification: Left-justify text. Leave a "ragged" right margin (it helps the eye track
the line).
• Hyphens: Do not hyphenate words at the end of lines on screens.

Visual Example (Slide 22 vs 23):

• Bad Help Screen: All CAPS. No spacing. Huge block of text. Very hard to read.
• Good Help Screen: Mixed case. Grouped into sections ("Field Descriptions", "Special
Function Keys"). Easy to scan.

E. Tables and Lists (Slides 24–27)

When displaying rows of data:

• Labels: Every column needs a label. If the list is long, repeat the label on the next page.
• Spacing: Leave a blank line every 5 rows so the eye doesn't get lost.
• Alignment (Crucial!):
• Text: Left-Justify (e.g., Names, Addresses).
• Numbers: Right-Justify (e.g., Prices, Quantities). This aligns the decimal
points so users can compare values easily.

Part 6: Tables vs. Graphs

When should you use a table and when should you use a graph?

• Use a Table when: The user needs to read a specific individual value.
• Example: "What exactly was the sales figure for March?" -> Look at the table.
• Use a Graph when: The user needs to see trends, patterns, or comparisons.
• Example: "Are sales going up or down?" -> Look at the Line Graph.
• Example: "Who sold the most?" -> Look at the Bar Graph.

Part 7: Usability (How good is the design?)

(Slides 32–35)
Usability is the overall evaluation of how well the system supports the user. It is not just about
looking pretty; it is about functioning well.

The Three Pillars of Usability:

1. Speed: Can I get the job done fast?

2. Accuracy: Did I make mistakes?
3. Satisfaction: Did I hate using it?

How to Measure Usability (Slide 35):

• Learnability: How hard is it to use the first time?

• Efficiency: Once I know how to use it, how fast am I?
• Error Rate: How often do I click the wrong button?
• Memorability: If I come back in a month, do I remember how to use it?

Success Factors (Slide 33):

• Consistency: The "Save" button should be in the same place on every screen.
• Clarity: Don't use jargon. Labels should be self-explanatory.
• Flexibility: Allow shortcuts for advanced users (e.g., Ctrl+S to save).

Part 8: Designing for the Web (E-Commerce)

(Slides 36–40)

Web design has specific challenges because you don't control the user's screen size or browser
speed.

Common Errors to Avoid (Slides 36-37):

• Bleeding-Edge Tech: Don't force users to download weird plugins to view your site.
• Scroll-Killers: Avoid horizontal scrolling (left-to-right). Users hate it.
• Slow Downloads: Giant images that take forever to load will make users leave.
• Non-Standard Colors: Blue underlined text usually means a link. If you make your
non-links look like that, users will get frustrated clicking them.

Best Practices (Slide 38-40):

1. Lightweight Graphics: Use small, optimized images for speed.

2. Stylesheet-based HTML (CSS): Separate the Content (HTML) from the Formatting
(CSS).
• Why? If you want to change the font of the whole website, you change one CSS
file, not 1,000 HTML pages. It ensures consistency.
Instructor's Summary

To master Chapter 10, remember this flow:

1. Understand the User: Who are they? (Novice/Expert). What do they need? (Input via
Form / Output via Report).
2. Prototype First: Sketch it out (Wireframe) before you code it.
3. Follow the Rules: Align text left, numbers right. Use mixed case. Use colour sparingly.
4. Test for Usability: Can they learn it? Can they remember it? Do they make errors?

Chapter 11: Designing Interfaces and Dialogues.

In Chapter 10, we designed the "Forms" (paper or digital sheets). In Chapter 11, we design the
Interface (how the user interacts with the system) and the Dialogue (the conversation between
the user and the system).

Think of it this way:

• Chapter 10: Designing the menu at a restaurant (what food is available).

• Chapter 11: Designing the interaction with the waiter (how you order, how they
confirm, how you pay).

Here is your structured guide.

Part 1: The Basics (Interface vs. Dialogue) (Slides 1–4)

1. Interface Design:

• Focuses on how information is provided to and captured from users.

• It is the bridge between the human and the computer.

2. Dialogue Design:

• Focuses on the sequence of interactions.

• It is like a script in a play: User does A→ System responds B→ User does C.

The Design Process (Prototyping is Key):

Just like in Chapter 10, we use an iterative process:

1. Collect Information: Who is the user? What is the environment?

2. Construct Prototype: Build a mock-up.
3. Assess Usability: Test it.
4. Refine: Make it better.
Part 2: Interaction Methods (Slides 6–20)

How do we actually tell the computer what to do? There are five main styles.

1. Command Language (Slide 8):

• Description: You type explicit text commands.

• Example: Linux terminal ($ cp [Link] [Link]).
• Pros: Very fast for experts; powerful.
• Cons: Hard to learn; requires memorizing syntax.

2. Menu Interaction (Slides 9–15):

• Description: The system gives you a list of options; you pick one.
• Examples:
• Pop-up Menu (Slide 12): Right-click on your desktop. Good because it's right
where your mouse is.
• Drop-down Menu (Slide 12): File → Save. Good because it saves screen space.
• Guidelines (Slide 13):
• Wording: Use verbs (e.g., "Save," "Print"). Be precise.
• Organization: Group logical items together (e.g., "Cut/Copy/Paste" are always
together).
• Selection: Use consistent methods (mouse click or keyboard shortcut).

3. Form Interaction (Slides 16–17):

• Description: Like a paper form. You fill in the blanks.

• Example: Google Advanced Search.
• Pros: Intuitive; great for data entry.

4. Object-Based Interaction (Slides 18–19):

• Description: You manipulate visual symbols (Icons).

• Example: Dragging a file into the "Trash" can.
• Pros: Very easy to learn ("See and Point").

5. Natural Language (Slide 20):

• Description: You speak or type in normal English.

• Example: Siri, Alexa, Google Assistant.
• Cons: Computers still struggle with context and accents (though this is improving
rapidly).
Part 3: Hardware Devices (Slides 21–24)

You need hardware to interact. The choice depends on the task (Slide 24).

• Keyboard: Best for Data Entry.

• Mouse/Trackball: Best for Pointing and Selecting.
• Touch Screen: Best for casual users (ATMs, kiosks) because there is no learning
curve (just touch what you want).
• Light Pen/Stylus: Best for Drawing or correcting text.

Note on Slide 23: This table summarizes usability issues. For example, keyboards cause "User
Fatigue" (typing all day hurts), while touch screens have "Visual Blocking" (your hand covers
the screen while you touch it).

Part 4: Designing Interfaces (Layouts) (Slides 25–28)

Good interfaces follow a standard layout (Slide 25):

• Header: Title, Date, ID.

• Body: The actual data.
• Navigation/Comments: Buttons to move forward/back.

Navigation Flow (Slide 28):

• Good Flow: Left-to-Right, top-to-bottom. This matches how we read.

• Bad Flow: Jumping randomly around the screen. This confuses the user.

Part 5: Data Entry (The Most Critical Part) (Slides 29–35)

Data entry is where most errors happen. We must design the interface to prevent them.

Structuring Data Entry (Slide 31):

• Entry: Never ask for data you already have (e.g., if I enter "Customer ID," the system
should pull up "Customer Name").
• Defaults: Always provide defaults (e.g., Today's Date).
• Units: Clarify units (e.g., "Weight (kg)" not just "Weight").
• Format: Show the format (e.g., MM/DD/YYYY).

Controlling Data Input (Validation) (Slide 34):

You must validate data before it is saved.

• Class Test: Is it a number? (User types "ABC" into a Price field -> Error).
• Range Test: Is it reasonable? (User types "200" for Age -> Error).
• Missing Data: Is a required field empty?
 • Self-Checking Digits (Slide 35): A mathematical formula used to verify ID numbers
(like Credit Card numbers). If you mistype one digit, the formula fails, and the system
knows it's a typo.

Part 6: Feedback (Talking back to the user) (Slides 36–37)

The system must always tell the user what is happening.

1. Status Information: "Saving...", "Page 1 of 5". (Tells user where they are).
2. Prompting Cues: "Enter Date (MM/DD/YYYY)". (Tells user what to do).
3. Error/Warning Messages:
• Bad: "Error 56." (User has no idea what this means).
• Good: "File not found. Please check the name and try again." (Polite, specific,
helpful).

Part 7: Help Systems (Slides 38–40)

Guidelines (Slide 38):

• Simplicity: Short sentences.

• Organize: Use lists/bullets.
• Show: Provide examples.

Context-Sensitive Help:
The best help systems know where you are. If you press F1 while in the "Date" field, it should
show help about Dates, not the main menu.

Part 8: Designing Dialogues (The Flow) (Slides 41–47)

Dialogue Diagramming (Slide 44):

This is a specific diagram used to map out the flow of screens.

• Structure: A box with three sections (Slide 45).

• Top: Reference Number (Unique ID).
• Middle: Name/Description of the screen.
• Bottom: Return References (Where can I go from here?).

Example (Slide 47 - Customer Information System):

• Top (0): Login Screen.

• Middle (1): Main Menu.
• Bottom (2, 3, 4, 5): The Main Menu links to Screen 2 (Individual Info), Screen 3 (Order
Status), etc.
• Key Concept: This diagram shows the roadmap of the entire application.
Part 9: GUI & Web Design (Slides 49–56)

GUI (Graphical User Interface) Guidelines:

• Consistency: "Save" should always be under "File."

• Modality (Slide 51):
• Modal Window: You MUST deal with this window before doing anything else
(e.g., a "Save Changes?" dialog).
• Modeless Window: You can leave it open and work elsewhere (e.g., a
Find/Replace box).

Web Design Errors (Slides 53-54):

• Opening New Windows: Don't do it unless necessary. It breaks the "Back" button.
• Orphan Pages: Every page needs a link back to Home.
• Scrolling Navigation: Don't put the menu at the bottom where no one sees it.
• Complex URLs: Users can't type [Link]/cgi-bin/xc/889?id=9. Keep it simple.

Cookie Crumbs (Slide 55-56):

• Definition: A trail of links showing where you are.

• Example: Home > Electronics > Televisions > 4K TVs.
• Purpose: Helps users navigate backward and know their location.

Instructor's Summary

To master Chapter 11, focus on the user's experience:

1. Interaction: Choose the right method (Menu for novices, Command for experts).
2. Input: Prevent errors before they happen using validation (Range checks, Format
checks).
3. Feedback: Always tell the user what is happening (Status updates, Polite error
messages).
4. Dialogue: Map out the flow using Dialogue Diagrams to ensure the user never gets
stuck in a dead end.

Chapter 12: Designing Distributed and Internet Systems.

In previous chapters, we designed the interface and the database. Now, we have to decide
where those components live. Do they live on one big computer? Do they live on your phone?
Do they live in "the cloud"?

This chapter is about Architecture—how we physically lay out the network, hardware, and
software to make the system work efficiently.
Here is your structured, comprehensive lesson plan covering all slides and book concepts.

Part 1: The Context (The "Why" and "Where") (Covering Slides 1–5)

The Goal:
We are moving from "Logical Design" (what the system does) to "Physical Design" (how the
system is built). We are designing systems that don't just sit in one room but are spread out
(distributed) across buildings, cities, or the world via the Internet.

The Process (Slide 4):

Designing a distributed system is like designing a single-computer system, but harder. Because
components are spread out, there are more points of failure.

• Key Issues: Reliability (does it work?), Availability (is it online?), and Survivability
(if one server dies, does the system crash?).

The Deliverables (Slide 5):

When you finish this phase, you produce a document detailing:

1. Site Description: Where are the offices? What hardware is there?

2. Data Usage: Who needs what data and where?
3. Process Needs: What software needs to run where?

Part 2: Designing for Local Area Networks (LANs) (Covering Slides 6–14)

Before the Cloud, we had LANs. We need to understand two main ways to set up a LAN: File
Server vs. Client/Server.

1. File Server Architecture (The "Old" Way) (Slides 7-9)

• Concept: Think of the File Server as a giant, shared USB drive connected to the
network.
• How it works:
1. The Client (your PC) asks for data.
2. The Server sends the ENTIRE FILE to the client.
3. The Client processes the data (sorts, filters, calculates) using its own CPU
power.
• The Diagram (Slide 9): Notice the arrow says "Entire file sent to client." This is the
bottleneck.
• Limitations (Slide 8):
• Excessive Data Movement: If you want 1 record from a file of 10,000, the
server sends all 10,000. This clogs the network.
 • Fat Client Needed: Your PC must be powerful because it does all the work.
• Decentralized Control: If two people edit the file at the same time, data
corruption happens easily.

2. Client/Server Architecture (The "Modern" Way) (Slides 10-14)

• Concept: The server is not just a hard drive; it is a "Database Engine" (it has a brain).
• How it works:
1. The Client sends a specific request (SQL query) to the server.
2. The Server processes the request and finds exactly what is needed.
3. The Server sends ONLY the result back to the client.
• The Diagram (Slide 11): Notice the arrow says, "ONLY result of request." This is
much faster and saves bandwidth.
• Key Terms:
• Database Engine: The back-end software (like Oracle or SQL Server) that
manages data.
• API (Application Program Interface): The software "hooks" that let the client
talk to the server easily.

Comparison Table (Slide 14):

• File Server: Client does the processing; High network traffic; Low security.
• Client/Server: Both do processing; Low network traffic; High security.

Part 3: Advanced Architectures (Covering Slides 15–19)

As systems got complex, we needed more than just a Client and a Server.

1. Three-Tier Architecture (Slide 17)

Instead of two layers (Client + Server), we have three:

1. Data Management: The Database (The Vault).

2. Application/Analysis: The Business Logic (The Brains).
3. Presentation: The User Interface (The Face).
• Benefit: You can update the code (Application) without disturbing the database or the
user interface.

2. Middleware (Slide 17-18)

• Definition: Software that acts as a "translator" or "glue" connecting different systems.

• Diagram Explanation (Slide 18): You see phones, tablets, and desktops at the top.
You see different servers at the bottom. Middleware sits in the middle, translating
requests so any device can talk to any server.
3. Thin Clients (Slide 19)

• Definition: A device that does very little processing (e.g., a Chromebook or a

Smartphone). It relies on the server to do the heavy lifting.

Part 4: Cloud Computing (Covering Slides 20–29)

This is the standard for modern systems.

1. What is the Cloud? (Slide 20)

It is Utility Computing. Just like you plug a lamp into a wall socket and pay for the electricity
you use, companies "rent" computing power and storage from Amazon (AWS), Microsoft
(Azure), or Google over the Internet.

2. NIST Cloud Characteristics (Slide 25)

• On-demand self-service: You can buy more server space instantly without calling a
human.
• Rapid Elasticity: The system grows (scales up) when you are busy and shrinks when
you are quiet. (See Diagram on Slide 23: The red line matches demand perfectly, unlike
the blue stairs of in-house systems).
• Resource Pooling: One physical machine serves many customers.

3. Service Models (The "Pizza" Analogy) (Slide 26):

• IaaS (Infrastructure as a Service): You rent the hardware/network. You manage the
operating system and apps. (e.g., Amazon EC2).
• PaaS (Platform as a Service): They provide the hardware and the operating system
tools. You just write the code. (e.g., Google App Engine).
• SaaS (Software as a Service): They provide everything. You just use the software.
(e.g., Gmail, Salesforce).

4. Public vs. Private Cloud (Slide 27)

• Public Cloud: Owned by a vendor (Amazon/Microsoft). Shared by everyone. Cheap,

scalable.
• Private Cloud: Owned by the client. Higher security, more control, but expensive.

5. Management Issues (Slide 28)

When moving to the cloud, managers worry about: Security (is my data safe?), Reliability
(will Amazon go down?), and Lock-in (is it hard to switch vendors?).
Part 5: Service-Oriented Architecture (SOA) (Covering Slides 30–33)

1. What is SOA?
Instead of building one giant software monster (Monolithic), we build software out of small,
reusable blocks called Services.

• Example: A "Credit Card Check" service. The Sales system uses it. The Website uses
it. The Accounting system uses it. You write it once, and everyone uses it.

2. Web Services (How SOA works)

• XML (Extensible Markup Language): A coding language used to tag data so

computers can read it.
• JSON (JavaScript Object Notation): A newer, lighter, faster version of XML. Used
by mobile apps.
• SOAP vs. REST: These are protocols (rules) for sending data. SOAP is strict and
secure (like a registered letter). REST is simple and fast (like a postcard).

Part 6: Designing Internet Systems (Covering Slides 34–42)

When designing for the web, standardization is key.

1. Standards (Slide 35):

• BIND: How domain names ([Link]) turn into IP addresses.

• HTTP: The protocol for sending web pages.
• HTML: The language used to format web pages.

2. Site Consistency (Slide 37-39):

Professional sites look consistent on every page.

• CSS (Cascading Style Sheets): A file that controls fonts, colors, and layout for the
whole site. If you change the CSS file, every page updates instantly.
• XSL: Used to style XML data.

3. Site Management Issues (Slides 40-42):

• Trust: Does the site look professional? Do you disclose shipping fees upfront?
• Personalization: Does the site remember you? (e.g., "Recommended for you...").
• Link Longevity: "Links must live forever." Never delete a page; redirect it. Broken
links kill customer trust.

Part 7: Content Management Systems (CMS) (Covering Slides 43–44)

Definition: A software application used to create and manage digital content.

 • Examples: WordPress, Drupal.
• Benefit: It separates the Content (text/images) from the Design (formatting). A
marketing person can write an article without knowing how to code HTML.

Part 8: Pine Valley Furniture Application (Covering Slides 45–48)

Let's apply this to a real scenario: Pine Valley Furniture (PVF) wants to add Advertising to
their WebStore.

1. The Requirement:
They want to increase revenue by showing ads, but they have concerns (Slide 46):

• Speed: Ads shouldn't slow down the site.

• Appearance: Ads shouldn't ruin the layout.
• Navigation: Clicking an ad shouldn't kick the user out of the store completely.

2. The Solution (Slide 47):

They designed a Transactional Component:

• The system detects who the user is.

• It checks for seasonal promotions.
• It serves a specific, personalized ad.
• It logs the transaction (records that the ad was shown).

3. Management Reporting (Slide 48):

Why do we do this? So managers can query the data:

• "How many people clicked the lamp ad?"

• "Did clicking the ad lead to a purchase?"

Instructor's Summary

To master Chapter 12, think about the evolution of infrastructure:

1. Past: We used File Servers (clunky, moved too much data).

2. Present: We use Client/Server (efficient, secure).
3. Modern: We use the Cloud (scalable, pay-as-you-go).
4. Integration: We use SOA/Web Services (XML, JSON) to make different systems talk
to each other.
5. Interface: We use CSS and CMS to make web maintenance easy and consistent.

Designing distributed systems is about choosing the right architecture to ensure the system is
fast, safe, and always available.
 Chapter 13: System Implementation.
In previous chapters, we planned and designed the system (the blueprints). Now, we are
building the house and moving the family in.

This chapter covers three big buckets of work:

1. Coding and Testing (Making sure it works).

2. Installation (Switching from the old system to the new one).
3. Support (Documentation, Training, and Help).

Let’s break this down systematically, covering every slide and concept from your materials.

Part 1: Introduction & Deliverables (Slides 1–7)

Where are we? (Slide 3)

We are in the Implementation phase. We take the physical design specifications (from Chapter
12) and turn them into working code, test it, and install it.

The Purpose (Slide 4):

1. Convert specs into reliable software (Coding).

2. Document the work (so others can fix it later).
3. Provide Help for users (Training/Support).

The Deliverables (Slides 5–7):

You don't just hand over code. You hand over a package:

• Coding: Actual code and program documentation.

• Testing: Test scenarios (the plan) and test data/results.
• Installation: User guides, training plans, and a conversion plan (how to move old data
to the new system).
• Support: Help desk plans and online help systems.

Part 2: Software Application Testing (Slides 8–24)

You cannot just write code and hope it works. You must have a Master Test Plan.
The Seven Types of Tests (Slides 12–17)

The slides categorize tests into Static (code is not running) vs. Dynamic (code is running), and
Manual (humans do it) vs. Automated (computers do it).

1. Inspections (Static/Manual):

• What is it? A formal group review. Peers look at the code to check for syntax errors or
standards violations. It’s like a grammar check for code.

2. Walk-throughs (Dynamic/Manual):

• What is it? A group meeting where the programmer walks peers through the logic of
the code. "First it does X, then it does Y."
• Slide 15 Diagram: Shows the steps: Schedule meeting → Present work → Walk through
logic → Reviewers ask questions → Resolve disagreements.

3. Desk Checking (Dynamic/Manual):

• What is it? The programmer sits at their desk and manually traces the logic with a pen
and paper. "If input is 5, the variable becomes 10..."

4. Unit Testing (Dynamic/Automated):

• What is it? Testing one single module (file) in isolation to see if it works on its own.

5. Integration Testing (Dynamic/Automated):

• What is it? Putting unit-tested modules together to see if they work together. Usually
done Top-Down.

6. System Testing (Dynamic/Automated):

• What is it? Testing the entire program as a complete product. Does it meet the business
objectives?

7. Stub Testing (Dynamic/Automated):

• What is it? If you are testing the top module but the bottom modules aren't written yet,
you write a "Stub"—a fake line of code that just says, "I ran successfully." It acts as a
placeholder.

The Testing Process (Slides 18–21)

• Test Case: A specific scenario (e.g., "Login with a wrong password"). It must be
repeatable.
 • Testing Harness (Slide 21): Automated software that reviews code for errors. It saves
time by running thousands of tests automatically.

Coding + Testing = Refactoring (Slide 22)

In modern Agile/eXtreme Programming, you don't code then test. You do them together.

• Refactoring: Making a program simpler after adding a new feature. You clean up the
messy code to make it efficient without changing what it does.

Acceptance Testing (Slides 23–24)

This is the final check by the actual Users.

• Alpha Testing: Users test the system using simulated (fake) data.
• Includes: Recovery testing (pull the plug, see if it recovers), Security testing
(try to hack it), Stress testing (overload it with users).
• Beta Testing: Users test the system using real data in their real work environment.

Part 3: Installation Strategies (Slides 25–34)

Installation is the scariest part. It is turning off the old way of doing things and turning on the
new way. There are four strategies (Diagrams on Slides 27, 29, 31, 33).

1. Direct Installation (Slide 26-27)

• Concept: "Cold Turkey." Turn off the old system, turn on the new one.
• Diagram: Current System stops → New System starts.
• Pros: Cheapest method.
• Cons: Highest risk. If the new system fails, you have no backup.

2. Parallel Installation (Slide 28-29)

• Concept: Run both the old and new systems at the same time for a while.
• Diagram: Current and New systems overlap.
• Pros: Safest method. If new fails, you still have the old one.
• Cons: Very expensive (double the work, double the staff). Confusing for users.

3. Single-Location (Pilot) Installation (Slide 30-31)

• Concept: Try it out at one branch (e.g., the Dhaka office) before rolling it out to the
whole company.
 • Diagram: Location 1 gets New System. Location 2 stays on Current System until
Location 1 is successful.
• Pros: Limits damage if things go wrong.

4. Phased Installation (Slide 32-33)

• Concept: Install the system piece by piece (e.g., install the Accounting module first,
then Inventory later).
• Diagram: Current system slowly fades out as New Modules are added one by one.
• Pros: Low risk, easy to learn.
• Cons: Slow. Old and new systems must be able to share data (bridging).

Part 4: Documentation (Slides 35–38)

Documentation is "boring" but essential. Without it, no one knows how to fix or use the system
later.

• System Documentation: Detailed technical info for programmers (how the code works,
database structure).
• User Documentation: Instructions for the end-users (how to file an order, how to log
in).
• User Guide Structure (Slide 38): A standard guide includes an Introduction, Getting
Started, Troubleshooting, and a Glossary.

Part 5: Training and Support (Slides 39–44)

You must teach people how to use the system.

Types of Training (Slide 41):

• Resident Expert: One employee learns it and teaches the others.

• Instructor-led: Traditional classroom setting.
• E-Learning: Online courses/videos (Slide 42 Example: PowerPoint tutorials).
• Blended: A mix of classroom and online.

Support Mechanisms (Slide 44):

• Help Desk: A human team you call for help.

• Automated Support: FAQs, Online Forums, Chatbots.

Part 6: Organizational Issues & Success (Slides 45–47)

Why do systems fail even if the code is good? Psychology and Politics.
Implementation Failure (Slide 45):

• Fear of change.
• Lack of commitment from management.
• Politics (employees engaging in sabotage because they liked the old way).

Success Factors (Slide 46-47 - The Lucas Model):

Look at the diagram on Slide 47. It shows the chain reaction of success:

1. Management Support creates a sense of urgency.

2. This increases the User's Personal Stake (they care about the system).
3. This leads to higher Use.
4. Higher use leads to higher Satisfaction and better Performance.

Part 7: Security (Slide 48)

Security is a massive part of implementation.

• Threats: Malware (Viruses, Trojans), Laptop theft, Denial of Service (DoS) attacks.
• The Weakest Link: The User.
• Users write passwords on sticky notes.
• Users use weak passwords like "123456".
• Solution: Firewalls, VPNs, and strict user policies.

Part 8: Case Study – Webstore (Slides 49–53)

The slides use a Webstore (Online Shop) example to apply these concepts.

• Testing (Slide 49): They didn't just test "Buying an item." They tested:
• Simple: Add to cart.
• Multiple: Add item, change quantity.
• Crisis: What if the server crashes mid-purchase?
• Bug Tracking (Slide 51): They used a formal form to track bugs. You can't fix a bug
if you can't replicate it.
• Alpha/Beta (Slide 52-53):
• Alpha: Employees got $100 to shop on the test site to find bugs.
• Beta: Real customers were invited to try it out.

Part 9: Project Closedown (Slide 54)

The project is done. Now what?

1. Evaluate the Team: Who did well? Who didn't?

2. Reassign: Move programmers to the next project.
 3. Post-Project Review: "Post-Mortem." What went right? What went wrong?
4. Close Contracts: Sign off and get paid.

Instructor's Summary

To implement a system successfully, you need:

1. Rigorous Testing: Don't let users find the bugs.

2. Smart Installation: Choose a strategy (Direct, Parallel, etc.) that matches your risk
tolerance.
3. Training: A confusing system will be ignored by users.
4. Security: People are the biggest risk; train them well.

This concludes Chapter 13. You are now ready to maintain the system!