Master Software Engineering in one focused session.

The four SE process activities

Typical SDLC activities

SDLC vs Process model

SDLC = what stages. Process model = how you execute them (sequential vs iterative).

Why SE matters

• Rising software complexity, large teams, long lifecycles
• Cost of failure is enormous — Ariane 5 exploded in 40 seconds from a 64→16-bit bug
• Late delivery, blown budgets, poor quality

ACM/IEEE Code of Ethics — 8 principles

The big picture

Waterfall

Linear, sequential — each phase finishes before the next. Requirements → Design → Implementation → Testing → Deployment → Maintenance.

V-Model — Verification & Validation

Waterfall extension — each dev phase has a matching test phase, forming a V. Test plans are written upfront, not at the end.

Iterative Waterfall

Adds feedback loops between phases — you can revisit earlier stages. Better for large/complex projects where requirements need refinement.

Spiral Model — risk-driven

Combines Waterfall + Iterative. Each loop has 4 quadrants:

Big Bang

Minimal planning, mostly coding. Suitable only for tiny or academic projects.

Quick chooser

The Agile Manifesto — 4 values

“While there is value in items on the right, we value the items on the left more.”

Agile characteristics

• SDLC activities are interleaved, not sequential
• Requirements = outline only (no formal SRS — though minimal docs do exist)
• Increment duration: 2–3 weeks
• Adaptive — customer feedback shapes the next increment
• Informal customer communication
• Heavy tool support (automated testing, configurable software)

Extreme Programming (XP)

Defined by Kent Beck (1996). Concept: take good practices and push them to the extreme.

XP principles

The 4 XP practice clusters

Core XP components

1. User stories — informal feature descriptions from the user's view
2. Refactoring — continuous code improvement
3. Test-First Development (TDD) — write tests before code
4. Pair Programming — driver + navigator

YAGNI & DRY

Test-Driven Development (TDD)

TDD advantages

• Tests define the interface & behavior spec (reduces ambiguity)
• Forces clarification of omissions before implementation
• Avoids “test-lag” — devs can't outpace testers

TDD challenges

• Devs prefer coding to testing — may write incomplete tests
• Hard to test UI display logic / screen workflows incrementally
• Hard to judge test completeness

Pair Programming

Driver writes code · Navigator reviews in real time. Promotes collective code ownership, continuous code inspection, and refactoring.

The 3-5-3 structure

3 Roles · 5 Events · 3 Artifacts. This is the single most exam-worthy thing in Scrum.

3 Roles

5 Events

3 Artifacts

The 3 Scrum phases

1. Outline Planning — general objectives, software architecture
2. Sprint Cycles — each delivers an increment
3. Project Closure — wrap up, docs, lessons learned

Sprint cycle workflow

During the sprint, the Scrum Master shields the team — all external comms route through them.

Scrum benefits

• Big product broken into manageable chunks
• Unstable requirements don't stall progress
• Whole-team visibility → better communication
• Customers see on-time delivery, gain real feedback
• Trust and a “we'll succeed” culture

Scaling Agile

When scaling, keep the fundamentals: flexible planning, frequent releases, continuous integration, TDD, communication.

Scrum vs XP vs Waterfall

The standard format

Example: “As a returning shopper, I want to save my payment details, so that I can check out faster next time.”

INVEST criteria

Story elaboration process

1. Start with Epics — large, high-level features
2. Break down into smaller stories
3. Refine as a team — remove ambiguity, add subtasks
4. Add Acceptance Criteria — 3–5 specific outcomes (happy + error path)

Epic vs User Story

Acceptance criteria

• Happy path — successful flow (e.g. invite sent)
• Error path — invalid input handled (e.g. malformed email rejected)
• Boundary — limits enforced (e.g. ≤ 5 MB upload)

The main problem with user stories

Completeness. Experienced users skip “obvious” details when describing their work. Mitigate with ethnography, prototypes, and structured questions.

Two big splits

Functional vs Non-Functional

Functional requirement quality

NFR categories

NFRs as vague goals — and how to fix them

Stakeholders often say: “System should be easy to use.” SE must convert this to quantifiable:

Requirements engineering process

Elicitation techniques

Interview do's

• Open-minded — avoid preconceived ideas
• Use springboard questions (“tell me what you want” fails)
• Ask for proposal documents upfront

Ethnography advantages

• Captures actual work practice (air traffic controllers turning off over-sensitive alerts)
• Reveals cooperation patterns — awareness of adjacent sectors

Ethnography disadvantages

• Doesn't support innovation (just describes current practice)
• Doesn't give broader organizational/domain requirements

Stories vs Scenarios

A scenario describes: initial assumption · normal flow · what can go wrong · concurrent activities · system state on completion.

Why prioritize?

• Limited resources (time, money, people)
• Agile uses fixed-schedule timeboxes — must decide what fits
• Dynamic, ongoing — priorities shift as the project evolves

The 4 categories

Steps to apply MoSCoW

1. Gather requirements (no initial filtering)
2. Engage cross-functional stakeholders
3. Define rules & dispute resolution (voting?)
4. Allocate resources — Must Haves ≤ 60% of total effort (predictability)
5. Categorize via litmus tests
6. Review & adjust continuously

Other named techniques

3 UML diagram families

Class Diagram (Structural)

The most-used UML diagram. Shows classes, attributes, methods, and relationships. The “blueprint” of OO systems.

• Box with three compartments: name, attributes, methods
• Relationships: association, aggregation (◇), composition (♦), inheritance (▷), dependency (- - ->)
• Multiplicity: 1, *, 0..1, 1..*

State Machine Diagram (Behavioral)

Models the states of an entity and transitions triggered by events. Shows movement through finite states.

Purpose

• How to enter a state
• How to leave a state
• What actions happen while in a state

Build two lists first: State list (e.g. Available, Cancelled, Full) and Stimulus list (e.g. enroll, drop, capReached).

Activity Diagram (Behavioral)

The OO equivalent of a flowchart / DFD. Models workflow — control flow, decisions, parallelism.

Elements

Limitation: doesn't show which object performs each activity (unless labeled with swimlanes).

Use Case Diagram (Behavioral)

External view — what the system does for actors. Use case = sequence of actions delivering measurable value to an actor.

• Actor — stick figure (person, org, external system)
• Use case — horizontal ellipse
• Association — solid line between actor & use case
• «include» — required sub-use-case · «extend» — optional extension

Sequence Diagram (Interaction)

Shows objects interacting over time. X-axis = objects, Y-axis = time (top to bottom).

Key elements

• Object box — [instance]:[Class]
• Lifeline — vertical dashed line below object
• Activation box — thin rectangle on lifeline = object busy processing
• Message — solid arrow between lifelines (synchronous = filled, asynchronous = stick arrow)
• Return — dashed arrow (optional; skip if obvious)
• «create», «destroy» — special messages

Control info

• [condition] — message only sent if true
• *[expression] — iteration/loop
• Self-call — arrow looping back to same lifeline

Picking the right diagram

Architectural design drivers

Pattern 1 — MVC

• Model — data + business logic
• View — presentation
• Controller — input handling, mediates model ↔ view

Separation of concerns. Same Model can drive multiple Views.

Pattern 2 — Layered

• Each layer talks only to the layer immediately below
• Each layer has a well-defined interface used by the layer above
• Higher layer sees lower layer as services

Typical layers: UI → Application functions (use cases) → Domain → Infrastructure (DB, network).

Pattern 3 — Repository

Sub-systems share data via a central database/repository. Efficient for large data volumes.

Alternative: each sub-system owns its DB and passes data explicitly.

Pattern 4 — Client-Server

Distributed system. Computations on separate programs/hardware that cooperate.

• Server — provides services, listens, accepts connections, responds to messages
• Client — accesses one or more servers to obtain services
• One server, many clients simultaneously

Examples

World Wide Web · Email · Network File System · Transaction Processing · Remote Display · Database System

Pattern 5 — Pipe-and-Filter

• Stream of data flows through a series of processes
• Each process transforms the data
• Components run concurrently
• Very flexible — components can be removed, replaced, reordered

Classic example: Unix shell pipelines (cat | grep | sort), compilers.

Pattern 6 — Transaction-Processing

• Process reads a series of inputs one by one
• Each input describes a transaction (a command to change state)
• Transaction dispatcher routes each one to a handler component

Examples

Payroll · Ticket Reservation · Purchase Order Entry · Airline Reservation

What triggers evolution?

• Software defects reported
• Changing business requirements
• Changes in other systems in the environment

Why software evolves forever

• Large systems have 10–30+ year lifetimes (ATC: 30+, business: 10+)
• Companies need ROI on their software investment
• Business environment shifts; the system must too

3 types of maintenance

3 reasons for urgent change

Why post-delivery changes cost more

Software re-engineering

When a system is still useful but increasingly hard to maintain. Functionality is preserved; the system is restructured.

Activities

• Re-documenting
• Refactoring architecture
• Translating programs to a modern language
• Modifying/updating data structure & values

Benefits over replacement

Refactoring vs Re-engineering

Legacy system — 4 strategic options

Agile ↔ Plan-driven handover pain

Error vs Fault vs Failure

Verification vs Validation

7 fundamental testing principles

1. Testing shows presence of defects, not absence
2. Exhaustive testing is impossible
3. Early testing saves money
4. Defect clustering — 80% of bugs in 20% of modules
5. Pesticide paradox — same tests stop finding bugs; update them
6. Testing is context-dependent (medical ≠ e-commerce)
7. Absence-of-errors fallacy — bug-free but useless = still useless

Testing levels (V-Model)

Box approach

Black-box test design

Static vs Dynamic

Walkthroughs are shorter and informal; inspections are formal and structured. Both record faults (don't fix them).

Non-functional testing

• Performance — Load, Stress, Scalability
• Usability, Security, Reliability

Test-Driven Development (recap from XP)

1. Identify a small increment of functionality
2. Write an automated test (it will fail)
3. Run all tests
4. Write code to pass the test, re-run
5. Refactor & move on

Even with TDD you still need system testing for performance, reliability, and unwanted-output checks.

Release vs System testing

Scenario & requirement-based testing

Requirement-based: one requirement → set of test cases. Mentcare: if patient is allergic, prescription must warn. Tests: no allergy → no warning; one allergy → warning; ignored warning → user must give reason.

Scenario testing: test sequences of requirements via a credible user story (nurse on home visits encrypts/decrypts records, etc.).

Performance testing

User testing — 3 flavors

Why bugs escape

• User ran untested code paths
• Statements executed in different order than tested
• Untested input combinations
• User's environment wasn't tested

Why exhaustive is impossible: too many paths (5 paths × 20 loops = ~100 trillion), too many inputs, too many environments.

Test automation

Manual test: $X every time. Automated test: 3–30× $X upfront, ~$0 every run after. Worth it for any test that will run repeatedly.

What a proposal does

• Defines a problem
• Proposes a software-based solution
• Justifies why and how it should be built

Goal: convince readers that the problem is worth solving, the solution is feasible, and your team can deliver.

Characteristics of a good proposal

Standard structure

1. Title & Overview — clear title; 3–5 line summary
2. Problem Statement — who · what · why · what if not solved
3. Background & Literature Review — existing solutions and gaps
4. Proposed Solution — features, modules, architecture, key tech
5. Scope — what's in AND what's not
6. Tools & Technologies — choices justified for the problem
7. Expected Outcomes & Deliverables — app, reports, docs, demo
8. Timeline / Gantt Chart — big-picture for non-technical readers
9. Conclusion — synthesis & commitment

Poor vs good problem statement

Common mistakes

• Vague problem statements
• Over-ambitious scope
• Copy-paste / plagiarism
• No justification for tool choices
• Poor formatting & grammar
• Treating the proposal as a formality

The mnemonic bundle

One-liners that win marks

• SE = systematic, disciplined, quantifiable approach to development, operation, and maintenance.
• Agile vs Waterfall = embrace change vs lock-in. Working software vs comprehensive docs.
• Scrum Master is a servant leader, not a manager. Shields the team.
• Product Owner owns the backlog. Developers own the increment. Scrum Master owns the process.
• Functional reqs = what; Non-functional = how well.
• Verification = build it right (spec). Validation = build the right thing (user).
• Error → Fault → Failure. Human mistake → code defect → observed wrong behavior.
• Black-box finds omissions; White-box finds commissions.
• Refactoring = continuous during dev. Re-engineering = one-off restructure of legacy.
• Pesticide paradox: same tests stop catching bugs — must evolve test suite.
• Dijkstra: testing shows presence of defects, not absence.

If the question says…