■ Table of Contents

Lecture 17 — Software Testing

Verification & Validation, Unit/Component/System Testing, TDD, User Testing

Lecture 18 — Inspection vs Testing & Debugging

Static vs Dynamic, Bug Types (Syntax/Logic/Runtime/Semantic), Debugging Process

Lecture 19 — Software Testing Techniques

Black Box, White Box, Flow Graphs, Cyclomatic Complexity, Path Coverage

Lecture 20 — Software Project Management

4 P's, Team Structures, W5H2 Principle, Why Projects Fail

Lecture 21 — Legacy Systems

Evolution, Legacy Components, Business Value, Migration Decisions

Lecture 22 — Software Reengineering

Reengineering Process, Reverse Engineering, Refactoring, Restructuring
 Lecture 17
Software Testing

■ The Big Picture

Real-World Analogy
Think of building a car. Before selling it, you must check it meets safety standards (verification) AND
that customers actually enjoy driving it (validation). Software testing does the same — it finds bugs
before real users do. A test that discovers a bug is a SUCCESSFUL test, not a failure!

■ Verification vs Validation
These are the two pillars of quality assurance, defined by Barry Boehm:

Concept Question Asked Focus

Did you build the product

Verification RIGHT? Meets system specifications?

Did you build the RIGHT

Validation product? Meets user expectations?

■ Defect Testing vs Validation Testing

Imagine testing as looking at a black box. The system takes inputs (set I) and produces outputs (set O).
Some outputs will be wrong — those come from bad inputs in a subset Ie.
• Defect Testing: Deliberately try inputs from Ie — the "evil" inputs that expose bugs.
• Validation Testing: Use "normal" inputs outside Ie to confirm the system works correctly.
The boundary between these two approaches is not rigid — both happen simultaneously in practice.

■ The Three Stages of Development Testing

Stage What is Tested Analogy

Individual functions, methods, Focus on each chip after

1. Unit Testing classes in isolation manufacturing

Multiple units combined — test

2. Component Testing their interfaces Test the assembled module

All components integrated — test

3. System Testing the whole system together Test the whole car

Unit Testing in Detail

Unit testing is done by developers on their own code modules. It focuses on:

• Normal inputs — expected, standard scenarios

• Boundary inputs — edge cases (e.g., input = 0, empty string, max value)
Key Benefits:

• Repeatable: Can re-run after any code change to catch regressions.

• Bounded: Narrow focus makes finding & fixing defects easier.
• Cheaper: Defects found early cost far less to fix than those found late.
• Design-oriented: Forces you to think about cohesion and coupling.

Component Testing — Interface Types

When multiple units are joined into a component, we test how they talk to each other. There are 4 types of
interfaces:

Interface Type Description

Data passed between components as function

Parameter Interface parameters

A memory block shared by multiple components

Shared Memory Interface (common in embedded systems)

One component calls procedures/functions of

Procedural Interface another

Components communicate by sending and

Message Passing Interface receiving messages (e.g., client-server)

Interface Error Types

• Interface Misuse: Calling component passes wrong type, order, or number of parameters.
• Interface Misunderstanding: Caller assumes wrong behavior — e.g., calling binary search on an
unsorted array.
• Timing Errors: In real-time systems, producer and consumer run at different speeds causing stale
data reads.

■ Test-Driven Development (TDD)

TDD in Plain English
Write the test FIRST (it fails because the code doesn't exist yet). Then write just enough code to make
it pass. Then clean up. Repeat. Also called "Test First Development" — introduced in XP (Extreme
Programming) but now mainstream in both agile and plan-based processes.

The TDD cycle (5 steps):

• 1. Identify the small increment of functionality needed.

• 2. Write an automated test for it — it WILL fail at first (that's intentional — proves the test adds value).
• 3. Run the test — confirm it fails.
• 4. Write the code to make it pass. Refactor as needed.
• 5. All tests pass → move to the next increment.
An automated test has three parts:

• Setup: Initialize inputs and expected outputs.

• Call: Execute the method/object being tested.
• Assertion: Compare actual result with expected. True = pass, False = fail.

■ User Testing
Type Description Location

Selected users + developers in

Alpha Testing controlled environment Developer's site

Larger user group, developer

Beta Testing NOT present; users report bugs User's environment

Customer formally tests if system

Acceptance Testing is ready for deployment Customer premises

■ Defect Origination & The Chaotic Zone

Defects enter software at these stages: Requirements → Design → Coding → Documentation → Testing
itself (bad fixes) → Maintenance changes.

The golden rule: Fix defects as close to their origin as possible! Fixing a requirements defect at the testing
stage means changing requirements, design, AND code — extremely expensive.

The Chaotic Zone

When defects are NOT caught early, they pile up at the testing and maintenance phases. The sheer
volume of accumulated, interrelated defects makes the system unstable and extremely difficult to fix.
This is the "chaotic zone." Solution: combine Inspection + Testing for maximum defect removal
efficiency.

■■ HIDDEN DETAILS — Professors Love Testing These

• "A test is SUCCESSFUL if it discovers an error" — not if the software passes! This is
counterintuitive but critical.

• Verification = Did you build it RIGHT? | Validation = Did you build the RIGHT thing? — professors
mix these up in questions.

• TDD is also called "Test First Development" — the test is written BEFORE the code.

• Alpha testing is at the DEVELOPER'S site; Beta testing is at the USER'S site — a very common
exam swap.

• Acceptance testing can be FORMAL (custom contract software) or INFORMAL (product tryout) —
not always the same thing.
• Interface Misunderstanding (e.g., calling binary search on unsorted array) is different from Interface
Misuse (wrong parameter types).

• The chaotic zone argument: testing alone is NOT enough — you must combine with inspection.
 Lecture 18
Inspection vs Testing & Debugging

■ The Big Picture

Real-World Analogy
Inspection is like a manuscript editor reading your novel for errors before printing — no execution
needed. Testing is like actually printing and reading the book to see if the story makes sense when
experienced. Both catch different kinds of problems, and together they produce the best quality.

■ Inspection vs Testing
Aspect Inspection Testing

Type Static (no execution) Dynamic (requires execution)

Early — requirements/design
Timing phase Later — after implementation

Detects Defects in documents and code Failures during execution

Cost Relatively low Can be high (environment setup)

Cannot catch dynamic/runtime Cannot PROVE absence of

Limitation issues defects

Inspection Process Steps:

• Planning → Overview Meeting → Preparation → Inspection Meeting → Rework → Follow-up

Testing Process Phases:

• Test Planning → Test Case Design → Environment Setup → Execution → Defect Reporting &
Retesting

Why Use Both?

Inspections catch issues EARLY (cheap fixes) and reduce the test effort needed later. Testing then
validates runtime behavior that inspections cannot see. Together they maximize defect removal
efficiency and minimize overall cost.

■ Debugging
Debugging is the process of IDENTIFYING, ANALYZING, and FIXING bugs. It is different from testing:

• Testing detects the PRESENCE of bugs.

• Debugging finds the CAUSE and FIXES it.
The Debugging Process (6 Steps):
• 1. Reproduce: Run with same inputs/conditions that caused the bug.
• 2. Isolate: Use breakpoints to pinpoint the responsible code.
• 3. Analyze: Understand WHY it happened (logic error? wrong algorithm?).
• 4. Fix: Correct the issue with minimal impact on other parts.
• 5. Test the Fix: Re-run to confirm bug is gone and nothing else broke.
• 6. Prevent: Add test cases or refactor to prevent recurrence.

■ Types of Bugs/Errors
Error Type Definition Detection Example

Caught by COMPILER Missing semicolon,

Syntax Error Violates language rules — before execution wrong indentation

Divide by zero,
Occurs DURING NullPointerException,
Runtime Error program execution Program crashes ZeroDivisionError

Wrong operator
Code runs, produces No crash — hardest to (+instead of -), wrong
Logic Error WRONG results find! loop condition

Syntax OK but
statement makes no Code may run but is Assigning value to a
Semantic Error sense logically meaningless literal: 2 = x

■ Special Error Categories

Coding Errors
Caused by lack of attention to detail: failure to check error returns, invalid conditions, wrong parameter
passing, incorrect return types. Symptoms: unexpected errors in black-box testing, compiler warnings.

Loop Errors
• Infinite loop: Loop condition never becomes false (e.g., missing i += 1 in a while loop).
• Index Error: Looping beyond the bounds of a list (e.g., range(4) on a 3-element list).

Pointer Errors
• Uninitialized pointers: Pointer declared but never assigned a target.
• Deleted pointers: Pointer used after the memory it pointed to was freed.
• Invalid pointer: Points to valid memory but memory does not contain expected data.

Memory Overrun
Writing data beyond allocated buffer — overwrites adjacent memory. Caused by overstepping array
boundaries or copying a string too large for its buffer.

Symptom: Program crashes after a specific routine is called; crashes may seem random.

Memory / Resource Leak

Memory allocated but NEVER deallocated. The program keeps consuming memory until the OS runs out.

Symptoms: System slowdowns, random crashes over long periods.

■■ HIDDEN DETAILS — Professors Love Testing These

• The detection timing of each error type is a classic exam question: Syntax = Compilation time (no
execution); Runtime = During execution; Logic = After execution (wrong result, no crash).

• Logic errors are the HARDEST to find because there are no error messages — the code runs
perfectly but gives wrong answers.

• Semantic errors are NOT the same as logic errors — semantic means the statement is
linguistically nonsensical (like 2 = x), while logic means the algorithm reasoning is flawed.

• Memory leak ≠ Memory overrun: leak = forgot to free memory; overrun = wrote past the end of a
buffer.

• Debugging is NOT testing — debugging FINDS and FIXES the root cause after testing has
DETECTED the presence of a bug.
 Lecture 19
Software Testing Techniques

■ The Big Picture

Real-World Analogy
Black Box testing is like testing a vending machine — you press buttons and check what comes out,
without caring about the internal mechanics. White Box testing is like being the engineer who opens
the machine and tests every gear and wire. Both approaches are necessary for thorough testing.

■ Black Box Testing

The tester treats the system as a black box — only inputs and outputs matter. Internal implementation is
completely hidden.

• Equivalence Partitioning: Group inputs that behave the same way. If two test cases from the same
group would both find (or both miss) a defect, they are equivalent — pick one representative from each
group instead of testing all.
Testability Attributes (OOCDSSU): Operability, Observability, Controllability, Decomposability,
Simplicity, Stability, Understandability.

■ White Box Testing (Structural / Glass Box)

The tester has full access to internal code structure. Test cases are designed to exercise specific paths,
branches, and conditions inside the program.
What we analyze: Code design, structure, documentation, logical paths, collaborations between
components.

■ Flow Graphs — The Language of White Box Testing

A flow graph maps the logical flow of a program visually. Key components:

• Node: A circle representing one or more sequential statements.

• Edge (Link): An arrow representing flow of control between nodes.
• Region: An area bounded by edges and nodes (count the outside area too!).
• Predicate Node: A node containing a condition — has 2 or more outgoing edges.

Basic Code Structures in Flow Graphs:

Structure Flow Graph Representation

Multiple sequential instructions lumped into one

Sequence node — no branching
 First node = if condition; two outgoing nodes = true
If branch and false branch

First node = switch; multiple middle nodes =

Case/Switch different cases; all merge to one exit

A loop guard node; keeps looping while condition is

While true; exits when false

■ Coverage Criteria
Coverage Type What It Means Strength

Every line/statement in the code Basic — may miss untested

Statement Coverage runs at least once branches

All decision branches (true AND Stronger than statement

Branch Coverage false) are tested coverage

Every possible route from input to Most thorough — impractical for

Path Coverage output is tested large programs

■ Cyclomatic Complexity
Plain English
Cyclomatic complexity is a NUMBER that tells you how many independent test cases you need at
minimum to cover every logical path through your code. Higher number = more complex code = more
tests needed.

Three ways to calculate it (all give the same answer):

• Method 1 — Regions: Count the number of enclosed regions in the flow graph (include the outer
region).
• Method 2 — Edges & Nodes: V(G) = E − N + 2 (E = edges, N = nodes)
• Method 3 — Predicate Nodes: V(G) = P + 1 (P = number of predicate/decision nodes)
Example: Flow graph with 11 edges, 9 nodes, and 3 predicate nodes:

Method 2: V(G) = 11 − 9 + 2 = 4 | Method 3: V(G) = 3 + 1 = 4 | Method 1: 4 regions = 4

Cyclomatic complexity = 4 means there are 4 independent paths to test.

■■ Independent Paths
An independent path is one that introduces at least ONE new edge (new processing/condition) not yet
covered by previously defined paths.

A path that is simply a combination of already-defined paths is NOT independent — it covers no new
edges.

■ Paths Through Loops

For a loop that iterates N times, the number of possible paths grows exponentially:

Iterations (N) Number of Possible Paths (2^N)

N=0 1 path (loop not entered)

N=1 2 paths

N=2 4 paths

N = 20 Over 1 million paths (2^20)!

This is why exhaustive path testing is practically impossible for real programs.

■ Infeasible Paths
An infeasible path is a route through the code that can NEVER be executed for any actual input. Good
programming practice: minimize infeasible paths to zero — they waste test effort generating test cases for
paths that can never run.

■ Deriving Test Cases (The Process)

• 1. Draw the flow graph from the design or code.
• 2. Compute cyclomatic complexity V(G).
• 3. Determine a basis set of independent paths (count = V(G)).
• 4. Design test cases that force execution of each independent path.

■■ HIDDEN DETAILS — Professors Love Testing These

• All THREE cyclomatic complexity formulas MUST give the same result — if they don't, you made a
calculation error.

• V(G) = E − N + 2 (not +1, not −2). Memorize this exactly.

• The number of independent paths in a basis set = cyclomatic complexity. They are the same
number.

• An independent path must traverse at least ONE new edge — a combination of old paths is NOT
independent.

• For N loop iterations: 2^N paths. For N=20, that's over 1 million — this is WHY exhaustive testing is
impossible.

• Don't forget to count the OUTER region when counting regions for cyclomatic complexity!

• Equivalence partitioning (Black Box): two tests are equivalent if they would both find OR both miss
a defect.
 Lecture 20
Software Project Management Concepts

■ The Big Picture

Real-World Analogy
Building software without project management is like constructing a skyscraper with no architect, no
schedule, and no budget tracking. Capers Jones found that GOOD project management was
associated with 100% of successful projects, and BAD management with 100% of failed ones. It's that
critical.

■ Why Do Projects Fail?

Common reasons projects go off the rails:

• Changing or ambiguous/incomplete customer requirements

• Unrealistic deadlines
• Underestimated effort (honest mistake)
• Unpredictable technical difficulties or risks
• Poor communication among staff
• Failure in project management itself

■ The 4 P's — The Management Spectrum

Effective project management focuses on four aspects:

P What It Means

The team — senior managers, PMs, engineers,

People end-users, customers

What is being built — scope, context, information

Product objectives, functions

Which development model to use — Waterfall,

Process RAD, Incremental, Agile

The management plan — timelines, risks, progress

Project tracking, postmortem

■ People — Leadership & Team Organization

MOI Model of Leadership (Weinberg):
• Motivation: Encourage technical people to produce their best.
• Organization: Build/adapt processes to translate concept into product.
• Idea/Innovation: Foster creativity — make people feel creative.

DeMarco's 4 Leadership Traits:

• Heart: Genuinely cares about people and the project.
• Nose: Can detect trouble and "bad smells" in the project early.
• Gut: Makes quick decisions on gut feeling when needed.
• Soul: Is the motivating spirit of the team.

The Three Team Structures:

Structure Characteristics

No permanent leader; rotating coordinators;

decisions by group consensus; horizontal
Democratic Decentralized (DD) communication

Defined leader for specific tasks; problem solving

still group-based; both horizontal and vertical
Controlled Decentralized (CD) communication

Team leader handles all top-level problem solving

and coordination; only vertical communication
Controlled Centralized (CC) (leader ↔ members)

■ Coordination & Communication Techniques

Type Examples

SE documents, memos, schedules, error tracking

Formal, Impersonal reports

Formal, Interpersonal QA activities, design/code reviews, status meetings

Informal, Interpersonal Group meetings, collocating teams

Electronic Emails, electronic communications

Interpersonal Networking Informal discussions with group members

■ Product — Establishing Scope

Before planning, you must define the product's scope: context, information objectives, required functions
and performance. Then decompose the problem and partition it into functional components to create
estimates.

■■ Process — Choosing the Right Model

Project Characteristics Situation Best Process Model
 Small, similar to past work Low uncertainty Waterfall / Linear Sequential

RAD (Rapid Application

Tight timeline, known domain Compartmentalized Development)

Large functionality, quick delivery Known requirements Incremental

Uncertain requirements Exploratory Prototyping

Iterative releases needed Changing requirements Agile Methodologies

■ Project — Reel's 5 Steps for Success

• 1. Start on the right foot: Understand the problem, set realistic objectives, build the right team.
• 2. Maintain momentum: Don't lose focus after a good start — sustain energy till the end.
• 3. Track progress: Monitoring ensures timely delivery; enables corrective action.
• 4. Make smart decisions.
• 5. Conduct a postmortem analysis: Learn from mistakes; improve the process continuously.

■ The W5H2 Principle (Barry Boehm's 7 Questions)

Question What It Asks Purpose

Why is the system being

WHY developed? Objective and vision

WHAT What will be done? Process and milestones

WHEN By when? Timeline

Who is responsible for each

WHO function? Team roles

Where are they organizationally

WHERE located? Stakeholder origins

How will the job be done (tech +

HOW management)? Procedures and methods

How much of each resource is Estimations and quantitative

HOW MUCH needed? analysis

■■ HIDDEN DETAILS — Professors Love Testing These

• The 4 P's are People, Product, Process, Project — NOT Planning! A common mistake.

• MOI = Motivation, Organization, Idea/Innovation (Weinberg's model). DeMarco's = Heart, Nose,

Gut, Soul.

• W5H2 = 5 W's + 2 H's: Why, What, When, Who, Where, How, How Much — know all 7.
• DD has NO permanent leader; CC has ALL control at the TOP. CD is the middle ground.

• Choosing the wrong process model for project characteristics is a leading cause of project failure.

• Postmortem analysis is step 5 of Reel's process — it's about LEARNING from the project, not
blame.
 Lecture 21
Legacy Systems

■ The Big Picture

Real-World Analogy
Imagine a 40-year-old factory with original machinery still running because it would cost a fortune to
replace. New workers don't know how it works; the manual is missing; spare parts are discontinued.
That's a legacy system — old, critical, expensive to change, impossible to simply throw away.

■ The Evolution Process

All software systems change over their lifetime. The evolution cycle:

• Change proposals → Release planning → Implementation → Validation → New release → Repeat

Sources of change proposals: Unimplemented requirements, new requirements, bug reports,
improvement ideas from the development team.

Urgent Changes — A Special Problem

When a critical system fault disrupts operations, fixes must happen IMMEDIATELY — even if
documentation can't be updated. The result:

• Emergency fix is applied; documentation is skipped.

• Over time, the original change is forgotten.
• Code and documentation drift apart permanently.
• This accelerates software aging — future changes become progressively harder.

Best Practice
After emergency repairs, the new code should be REFACTORED and improved to avoid long-term
degradation. This is why agile favors minimal documentation.

■■ What is a Legacy System?

A legacy system is one that has been in operation for many years and relies on languages and
technologies no longer used for new development. Its structure may have degraded through many
accumulated changes.

■ The 6 Logical Components of a Legacy System

Component Key Issues

May be old mainframes — incompatible with current

1. System Hardware IT purchasing policies; expensive to maintain
 OS, compilers, utilities — may be obsolete; no
2. Support Software longer supported by original vendors

Multiple programs built at different times by different

3. Application Software teams — inconsistent style

Huge accumulated data; may be inconsistent,

4. Application Data duplicated, spread across multiple databases

Business workflows built AROUND the legacy

5. Business Processes system — may be constrained by its limitations

Rules embedded in the system — may not be

6. Business Policies/Rules documented anywhere else

■ The Layered View — Why One Change Cascades

Legacy components form interdependent layers. Changes in one layer ripple upward and downward:

• A new database (support layer) may enable web access → business processes change to use it.
• Software changes may slow the system → new hardware needed → further software changes become
possible.
• New hardware may not support old software interfaces → major application code changes needed.

■ Legacy System Assessment — The Decision Matrix

Assess each legacy system on two dimensions: Business Value and System Quality. Then decide:

Decision When to Apply

Low business value, processes have changed

Scrap completely significantly, organization no longer dependent

System still required, stable, requirements rarely

Continue maintaining change, few change requests from users

System quality degraded, regular changes required,

Transform/Reengineer still has business value

System cannot continue operating, affordable

Replace partially or fully off-the-shelf replacement available

Business Value Assessment — 4 Key Issues:

• Use of the system: How frequently and widely is it used?
• Business processes supported: How critical are the processes it enables?
• System dependability: Is it reliable and available?
• System outputs: How important are the outputs it produces?

■ Types of Software Maintenance

 Type Purpose

Fault Repair Fix bugs and security vulnerabilities

Environmental Adaptation Adapt software to new platforms and environments

Functionality Addition Add new features and support new requirements

Note: These types are not mutually exclusive — environmental adaptation often introduces new
functionality at the same time.

■ Legacy System Migration

Migration = moving the legacy system to a new platform/environment. It is risky because:

• New development may take years.

• Changes to one part of the system cause cascading changes elsewhere.
• A complete system specification may not exist.
• Critical business rules may be embedded in code only — undocumented elsewhere.

■■ HIDDEN DETAILS — Professors Love Testing These

• Legacy systems are not just old code — they include hardware, support software, data, business
processes, AND policies (6 components).

• The layered architecture means changes cascade in BOTH directions — up and down the stack.

• Business processes may be DESIGNED AROUND the legacy system — this is a key reason you
can't simply replace it.

• The 4 business value assessment issues: Use, Business Processes supported, Dependability,
Outputs.

• The 3 types of maintenance: Fault Repair, Environmental Adaptation, Functionality Addition — no

clear boundary between them.

• Emergency fixes that skip documentation are a PRIMARY cause of legacy system degradation
over time.
 Lecture 22
Software Reengineering

■ The Big Picture

Real-World Analogy
Reengineering is like renovating an old house instead of demolishing and rebuilding it. You keep the
walls and foundation (the working functionality), but modernize the wiring, plumbing, and layout. The
house still does the same job, but it's now easier to maintain and extend.

■■ Migration vs Reengineering vs Replacement

Approach What Happens What Changes Cost/Risk

Move software to new

environment (hardware, Changes
Migration OS, cloud) LOCATION/platform Lower cost, faster

Restructure/improve the Changes HOW

Reengineering software internally software works Higher cost, longer time

Build a completely new Replaces

Replacement system from scratch EVERYTHING Highest risk and cost

■ Why Reengineer Instead of Replace?

Reengineering has two key advantages over redeveloping from scratch:

• 1. Reduced Risk: Redeveloping business-critical software is risky — specification errors, development

problems, delays, and business loss. Reengineering preserves existing verified functionality.
• 2. Reduced Cost: Real example from Ulrich: Reimplementation of a commercial system was estimated
at $50 million; reengineering it cost only $12 million.

■ The Reengineering Process Model (6 Stages)

Stage Activity

Catalog all applications; assess size, age, business

1. Inventory Analysis criticality, maintainability

Update or create documentation (if

2. Document Restructuring stable/end-of-life, may skip)

Analyze program to extract design and produce

3. Reverse Engineering higher-level representation
 Modify source code and data to improve structure
4. Program Restructuring (code refactoring + data restructuring)

Incorporate new business processes and

5. Forward Engineering requirements into the restructured system

Validate that restructured system still works

6. (Ongoing) QA/Testing correctly

■ Reverse Engineering
Reverse engineering is the process of analyzing a program to create a representation at a HIGHER level
of abstraction than the source code — essentially recovering the design from the code.

Reverse engineering activities:

• Understanding PROCESSING: What the program does step by step.

• Understanding DATA: Internal data structures and database structures.
• Understanding USER INTERFACES: How the program interacts with users.

■ Program Restructuring
1. Code Restructuring (Refactoring)
Improving or updating the code WITHOUT changing its external behavior or functionality. Goals: better
readability, maintainability, and structure. It is a transparent activity — users see no difference.

2. Data Restructuring
Restructuring the database schema — extracting data items, understanding data flow, reorganizing data
structures. When you change database schema (add an attribute, add a table), all associated queries,
joins, and conditions may need to change too. This is why data restructuring is HARDER than code
restructuring.

4 Specific Program Restructuring Activities:

• Source Code Translation: Convert from old language to modern version or different language (using
translation tool).
• Structure Improvement: Analyze and simplify control structure for readability. Partially automated.
• Modularization: Group related parts; remove redundancy; possible architectural refactoring. Manual
process.
• Data Reengineering: Change data to reflect program changes; redefine database schemas; clean up
data (remove duplicates, fix errors). Very expensive.

■ Forward Engineering
Incorporating NEW business processes and rules into the reengineered system. Unlike reverse
engineering (recovering what exists), forward engineering applies SE principles to create a better version
that also addresses new requirements and technologies.

■■ Reengineering vs Refactoring
 Concept When Applied Scale Purpose

After system has been Addresses structural

maintained for years; decay in legacy
Reengineering costs are rising Large-scale, periodic systems

PREVENTS the
Continuous throughout structure and code
development and degradation that leads
evolution — ongoing to expensive
Refactoring improvement Small, continuous maintenance

■ "Bad Smells" Addressed by Refactoring

Bad Smell Problem Refactoring Solution

Same/similar code in multiple Extract into a single shared

Duplicate Code places method

Method is too large and does too Split into smaller, focused
Long Methods much methods

Type-based switch logic Replace with polymorphism

Switch Statements scattered throughout code (OOP)

Same group of data items

appears repeatedly in many Replace with an encapsulating
Data Clumping places object/class

■ Cost of Reengineering Activities

Cost increases from left to right in the reengineering spectrum:

Activity Relative Cost

Cheapest — automated conversion to modern

Source Code Translation language

Document Restructuring Moderate — updating or creating documentation

Program Restructuring Moderate-High — code and data refactoring

Most Expensive — fundamental restructuring of the

Architectural Migration system

■■ Important Limitations
Not all reengineering steps are always needed:

• Skip source code translation if you still use the same programming language.
• Skip reverse engineering documentation recovery if reengineering can be fully automated.
• Skip data reengineering if data structures don't change during reengineering.
Critical limitation: A reengineered system will generally NOT be as maintainable as a brand-new system
built with modern engineering methods.

■■ HIDDEN DETAILS — Professors Love Testing These

• Reengineering does NOT change functionality — it improves structure and understandability while
keeping behavior the same.

• Reengineering vs Replacement: 2 advantages are Reduced Risk + Reduced Cost ($50M → $12M
example from Ulrich).

• Data restructuring is HARDER than code restructuring because changing a DB schema requires
changing all related queries and joins.

• Refactoring is CONTINUOUS (prevents decay); Reengineering is PERIODIC (fixes decay after it

occurs).

• The 4 "bad smells": Duplicate Code, Long Methods, Switch Statements, Data Clumping — know
what refactoring solves each.

• Forward engineering adds NEW requirements; Reverse engineering RECOVERS existing design
from code.

• Not all 6 reengineering steps are always required — depends on what needs to change.

• Source code translation = cheapest reengineering step; Architectural migration = most expensive.
 ■ Quick Reference Cheat Sheet
Key Formulas & Definitions at a Glance

Critical Formulas
What Formula

Cyclomatic Complexity (Edges/Nodes) V(G) = E − N + 2

Cyclomatic Complexity (Predicate Nodes) V(G) = P + 1

Cyclomatic Complexity (Regions) V(G) = Number of enclosed regions (+ outer)

Paths through N-iteration loop 2^N possible paths

n(n-1)/2 (each member communicates with all

Communication Channels in DD team others)

Critical Distinctions — Exam Favorites

Concept Pair Key Distinction

Verification vs Validation "Built RIGHT" vs "Built RIGHT thing"

Testing vs Debugging Detects presence of bug vs Finds cause & fixes it

External view (I/O only) vs Internal view (code

Black Box vs White Box structure)

Alpha vs Beta Testing Developer's site vs User's site

Periodic large-scale fix vs Continuous small

Reengineering vs Refactoring improvement

Transforms how software works vs Moves to new

Reengineering vs Migration platform

Improve existing vs Build brand new (higher

Reengineering vs Replacement risk/cost)

Compile time vs Wrong result vs Crash during

Syntax vs Logic vs Runtime Error execution

Mnemonic Aids
• 4 P's of PM: "People Push Products & Projects" (People, Product, Process, Project)
• MOI Leadership: "Making Outstanding Impact" (Motivation, Organization, Idea/Innovation)
• TDD cycle: Red → Green → Refactor (Test fails → Test passes → Clean up)
• 3 Interface Error Types: "MisMis-Time" (Misuse, Misunderstanding, Timing)
• 6 Legacy Components: Hardware, Support Software, App Software, App Data, Business Processes,
Business Rules
• W5H2: Why What When Who Where + How How Much

Software Engineering Study Guide | Lectures 17–22 | Course Instructor: Maheen Zulfiqar | Good luck on your exam! ■