Software Engineering Final Study Guide

Software

Computer programs + documentation; may be for a specific customer or general market.

Quality attributes

Functionality, performance, maintainability, dependability, usability. Examples: safety, security, privacy, performance, interoperability.

Software engineering

Discipline covering all aspects of production from specification through maintenance.

Fundamental activities

Requirements specification, development, validation, evolution; also design, planning, team management.

Cost allocation

Maintenance > development; ~60% development, ~40% testing; evolution often exceeds development for custom software.

Iron Triangle

Scope, schedule, resources — balance is key to success.

Software process

Structured set of activities to develop a system.

Four process activities

Requirements, Design & Implementation, Validation, Evolution.

Waterfall

Sequential completion of activities.

Waterfall Pros

Stable requirements, coordinates multi-site projects, suited for safety-critical with heavy documentation.

Waterfall Cons

Rarely followed sequentially, requirements hard to state upfront, late visibility, blocking states.

Incremental model

Pros - Lower cost of change, frequent feedback, usable software even if cut short.

Cons - Low visibility without docs, structure deteriorates with added increments.

Agile

Iterative + incremental, flexible, collaborative, customer-focused; each iteration is a mini-waterfall.

Design activities

Architectural, Database, Interface, Component selection/design.

Artifacts

- Architecture → overall structure.

- Database → data structures & representation.

- Interface → defined component interfaces.

- Component → reusable components identified.

Verification vs Validation

“Are we building the product right?” vs “Are we building the right product?”

Testing stages

Unit → Integration → System → Customer Acceptance.

Unit testing

Independent testing of components (methods/classes).

Integration testing

Whole system, emergent properties.

Customer acceptance testing

Customer checks product meets needs.

Prototyping benefits

Spike solutions for difficult design problems, encourages refactoring.

Requirements

Specification of what should be implemented; system behavior, properties, constraints.

Business requirements (BR)

Needs leading to projects; lives in Vision & Scope.

User requirements (UR)

Goals/tasks users must perform; product attributes for satisfaction.

Functional requirements (FR)

Observable behaviors; originate from UR, business rules, quality attributes; often use cases or EARS.

Quality attributes (NFRs)

How well the system does something.

External interface requirements (EIR)

Connections to users, hardware, other systems.

Constraints

Restrictions on design/implementation.

Data requirements (DR)

Essential subject matter, business objects, entities, classes.

Business rules (BRu)

Policies, regulations, standards; not requirements but generate them.

Solution ideas

User suggestions that must be probed to uncover real requirements.

Stakeholder

Anyone with vested interest in SuD.

5 NFR examples

Performance, Availability, Security, Scalability, Maintainability.

Broker pattern

Solves communication/service discovery in distributed systems; supports scalability/resilience.

Metrics for NFRs

Response time, throughput, uptime %, vulnerabilities, defect fix time, scalability measures.

Use Case Definition

Text description of system behavior responding to a stakeholder (primary actor) request.

Anatomy

Actor, stakeholder, primary actor, SuD, scope, preconditions, guarantees/postconditions, MSS, extensions.

Trigger

Event that starts the UC.

Preconditions

Must be true before UC runs.

Postconditions

Must be true after UC runs.

MSS

Normal flow when nothing goes wrong.

Extensions

Alternate flows, mini use cases.

Right level tests

Boss test, EBP test, Size test.

Writing process

Scope → actors → goals → expand UC → stakeholders, preconditions, guarantees → MSS → extensions → refactor.

Scenario action types

Interaction, validation, internal change.

Style

“Who has the ball,” bird’s-eye view, move process forward.

Wording

Prefer “validate” over “check.”

Extensions checklist

Alt success, errors, failures, performance issues.

Use cases vs requirements

UC = user interaction steps; FR = system must-do behaviors.

Use cases vs user stories

UC defines interactive steps; user story is high-level goal.

Not a use case

GUI actions like “Click submit button.”

Agile manifesto

- Individuals & interactions > processes & tools

- Working software > documentation

- Customer collaboration > contract negotiation

- Responding to change > following a plan

Agile methodologies

XP, Scrum, Lean, Kanban.

XP principles

Planning Game, Small Releases, Metaphor, Simple Design, Testing, Refactoring, Pair Programming, Collective Ownership, Continuous Integration, 40-hour week, On-site Customer, Coding Standards.

Definition of Done

Feature is coded, tested, documented, accepted.

Sprint

Timeboxed iteration delivering increment from backlog.

User story

Cards, conversation, confirmation; contributes value regardless of order.

Product backlog

List of product requirements.

Sprint backlog

Tasks for current sprint.

Daily standup

Yesterday/today/blockers.

Sprint review

Demo for feedback.

Sprint retrospective

Inspect process, identify improvements.

Scrum Master

Facilitates Scrum, ensures practices, assists PO/dev team, facilitates events.

Product Owner

Single source for requirements/priorities, defines requirements clearly.

Kanban board

Visual workflow tool with columns/cards.

Agile principles (12)

Customer satisfaction, adaptability, frequent delivery, collaboration, motivated individuals, face-to-face communication, working software as progress measure, sustainable pace, technical excellence, simplicity, emergent design, reflection/tuning.

Release plan

Plans iterations, groups use cases for release (bucket planning).

Iteration plan

Maps developer tasks for iteration, created at start.

Daily planning (stand-up)

Accomplishments, next tasks, blockers.

SMART task check

Specific, Measurable, Achievable, Relevant, Time-boxed.

Story points

Relative effort measure, not time.

Velocity

Story points completed per iteration; past velocity informs future planning.

Task dependencies

SS - Task B depends on Task A starting.

SF - Task A must start before Task B can finish.

FS - Task A must finish before Task B starts.

FF -

Task A must finish before Task B can finish.

Critical path

Longest duration path; minimum time to complete project; schedule priority.

Risk planning

Prepare to avoid negative repercussions.

Group Anti-Patterns

Analysis paralysis, cart before horse, groupthink, silos, vendor lock-in, over-engineering, gold plating, viewgraph engineering, fire drill/heroics, death march.

Individual Anti-Patterns

Micromanagement, seagull management, email reliance, loose cannons, intellectual violence.

Impact vs Likelihood matrix

2D grid ranking risks by severity and probability.