MIS Chapter 2

Development of Information Systems Solutions

Exam Study Guide — Simplified for Easy Understanding

1. The Systems Approach — The Big Idea

Think of a business like a machine with many parts. If one part breaks, you don't just fix that one
part randomly — you look at how the WHOLE machine works together.

The Systems Approach means:

• Every business process has INPUTS, PROCESSING, OUTPUTS, and FEEDBACK
• You look at how information flows through the ENTIRE organization
• You fix the real underlying problem — not just the surface symptom

💡 Key Insight: IS solutions fail most often because of poor requirements gathering — NOT bad
technology.

2. Understanding the Problem

Symptom vs. Real Problem
This is one of the most important distinctions in the chapter:

Symptom (What You See) Real Problem (Root Cause)

My stomach hurts I ate bad food
 Sales are going down Inventory system does not update in real-time
Employees are slow The software has no search function

Feasibility Study — 4 Types

Before doing anything, ask these 4 questions:

Type Question It Asks Simple Example

Organizational Does it fit our company culture? Will our staff accept this change?
Economic Do we have the budget? Can we afford the software?
Technical Does the technology exist? Is there software that does this?
Operational Will people actually use it? Is it practical for daily work?

⚠️Exam Tip: ALL 4 feasibility types must be checked before moving forward with a project.

3. Designing the Solution

Two Types of Design

Design Type Focus Question It Answers Example

Logical Design WHAT the What information? What The system needs a customer
system needs reports? search function
Physical Design HOW to build What hardware, We will use Oracle database on
it software, network? Windows Server

Prototyping
A prototype is a quick, rough version of the system built to get early feedback.

• Like a LEGO model before building the real house

• Much cheaper to change a prototype than a finished product
• Managers test it and give feedback before full development begins
4. Implementing the Solution
This is where you actually build and launch the system. It has 4 key parts:

Step What It Means

Acquisition Buy the hardware and software needed
Software Development Write the code or customize existing software
Training Teach staff how to use the new system
Conversion Move from the old system to the new one

The 3 Conversion Methods

When switching from old to new system, you have 3 options:

Method What Happens Risk Level When to Use

Parallel Run both old AND new at SAFEST When errors would be very costly
same time
Phased Switch one MEDIUM Large organizations
module/department at a time
Direct (Cut-over) Turn off old, turn on new RISKIEST When speed is critical
immediately

🎯 Exam Tip: Parallel = Safest. Direct = Riskiest. This is a common exam question!
5. The SDLC — System Development Life Cycle
This is the MOST IMPORTANT concept in Chapter 2. Learn all 7 phases!

What Is SDLC?
• Developed in the 1960s for large mainframe projects
• A step-by-step process for building information systems
• Also called the WATERFALL model — like water flowing downhill, you can only move
FORWARD
• Very structured and risk-averse — designed for big, complex projects

The 7 Phases of SDLC

Phase 1 — Preliminary Analysis

Key Question: Should we even start this project?
• Review the problem: What is it? Is solving it possible?
• Look at alternatives that already exist
• Launch a feasibility study (all 4 types)
Done by: Requirements Analyst or Business Analyst

Phase 2 — System Analysis

Key Question: Exactly what should the new system DO?
• Interview users and stakeholders
• Document all current procedures and workflows
• Identify data requirements
• NO coding happens here — only listening and documenting
Output: System Requirements Document
Done by: Systems Analyst

Phase 3 — System Design

Key Question: How exactly will we build it?
• Translate business requirements into technical specifications
• Design the user interface, database, inputs, outputs, and reports
• Covers both Logical Design (WHAT) and Physical Design (HOW)
Output: System Design Document
Done by: Systems Analyst, Developer, or Systems Architect
Phase 4 — Programming
Key Question: Let's write the actual code!
• Developers use the System Design Document as their guide
• Write the software code that builds the system
• First time actual software is created
Output: Initial Working Program
Done by: Developer, Software Engineer, Programmer, Coder

Phase 5 — Testing
Key Question: Does it actually work? Find the bugs!

Test Type What It Checks

Unit Test Each small piece of code works correctly on its own
System Test All pieces of the system work together properly
User Acceptance Test (UAT) Real users try the system and confirm it meets their needs

• Find a bug → Fix it → Test again → Repeat until clean

Done by: Tester, Testing Analyst, Quality Assurance (QA)

Phase 6 — Implementation
Key Question: Launch it to the whole organization!
• Train all users on the new system
• Provide documentation and user manuals
• Convert data from old system to new system
• Choose a conversion method: Parallel, Phased, or Direct

Phase 7 — Maintenance
Key Question: Keep it healthy after launch!
• Fix reported bugs and errors
• Evaluate and implement requests for new features
• Perform system updates and backups for each new version

Important Money Fact:

Type Name Meaning
Development Cost CAPEX (Capital Expense) Big one-time investment — comes from
capital budget
Maintenance Cost OPEX (Operating Expense) Ongoing smaller costs — comes from
operating budget
SDLC — Quick Reference Summary Table

Phase Key Question Main Output Done By

1. Preliminary Should we do it? Feasibility Study Business/Requirements
Analysis Analyst
2. System Analysis What should it do? Requirements Systems Analyst
Document
3. System Design How will we build it? Design Document Systems Analyst /
Architect
4. Programming Let's write the code Working Software Developer /
Programmer
5. Testing Does it work? Bug-free Software Tester / QA
6. Implementation Let's launch it! Live System Everyone involved
7. Maintenance Keep it working Updated System Support Team

The Big Weakness of SDLC

• It is very RIGID — like a one-way road, you cannot go back

• Once started, you CANNOT change requirements
• No software is shown to users until AFTER the Programming phase
• Projects can take months or even YEARS to complete
• Because of this, newer and more flexible methods were developed

💡 Remember: SDLC is called the Waterfall Model because steps flow only in one direction —
forward, like a waterfall.
EXAM CHEAT SHEET — Most Likely Questions

Topic What to Remember

4 Feasibility Types Organizational, Economic, Technical, Operational
Symptom vs Problem Symptom = what you see. Problem = the real cause.
Logical vs Physical Design Logical = WHAT. Physical = HOW.
Prototyping Quick rough version to get feedback before building the real thing
3 Conversion Methods Parallel (safest) → Phased (medium) → Direct (riskiest)
SDLC / Waterfall 7 phases, moves only forward, rigid, for large projects
SDLC Phase 1 Preliminary Analysis — Should we start? Feasibility study.
SDLC Phase 2 System Analysis — What should it do? Requirements Document.
SDLC Phase 3 System Design — How? Design Document.
SDLC Phase 4 Programming — Write the code. First actual software.
SDLC Phase 5 Testing — Unit Test, System Test, UAT.
SDLC Phase 6 Implementation — Train, document, convert data.
SDLC Phase 7 Maintenance — Fix bugs, add features, backup.
CAPEX vs OPEX Development = CAPEX. Maintenance = OPEX. Different budgets!
SDLC Weakness Rigid, no going back, no changes to requirements, slow.

Good luck on your exam! You've got this!