CS 321 Midterm

The overarching goal of software engineering (four parts)

A quality product, delivered on time, within budget, that is of value to customers and users.

What is an umbrella activity? Name four.

An activity that spans the whole life cycle instead of living in one phase. Examples: project management, risk management, software quality assurance, configuration management, documentation, V&V.

The SDLC phases, in order

Requirements → architecture → design → implementation → testing → evolution. Whatever process you follow, the product still passes through every phase in some form.

Verification vs. validation

Verification: did we build the product right (conforms to spec, process, standards)? Validation: did we build the right product (meets what users actually need)?

The three stages of testing

1. Development testing (by the builders: unit → component → system). 2. Release testing (separate team, always black-box). 3. User testing (e.g. beta).

Unit vs. component vs. system testing

Unit: one unit in isolation. Component: several units assembled, testing how they interact. System: all components linked, testing emergent behavior.

The 4Ps of software engineering

People, Process, Project, Product (Lesson 1 slide 6; the slide gives no definitions). Be ready to say what each means for your own project.

Plan-driven vs. agile: what's fixed and what varies?

Plan-driven fixes scope and moves the time. Agile fixes time and resources (timeboxing) and flexes the scope.

Plan-driven vs. agile: five more differences

Phased vs. iterative/incremental. Working software at the end vs. at regular intervals. Large vs. small teams. High vs. low communication overhead. Validation at the end vs. continuous. Predictive vs. adaptive planning. Change at set times through a formal process vs. accommodated maximally.

Waterfall: when does it fit, and what is its main weakness?

Fits large, long projects with stable requirements. Weakness: change is expensive, and gets more expensive the later it comes. Customers vanish between elicitation and user testing, and see no working software until the end.

Incremental development: pros and cons

Pros: adapts to change, faster feedback, cheaper changes to unbuilt parts, contained ripple effect. Cons: less visible/predictable process, poor early quality compounds (brittle code base), hard to define the first increment.

Prototyping: low vs. high fidelity, and the two paths after

Low-fi: paper mockups. High-fi: minimally functional software. After feedback: keep it as 'version zero' (refactor it first) or throw it away. Risk: customers anchor on the prototype's look.

Spiral model: the four quadrants

1. Objectives, alternatives, constraints. 2. Identify and mitigate risks (its defining feature). 3. Develop and verify the next-level product. 4. Plan the next phase. You can run one loop just for the riskiest phase.

THE FOUR AGILE VALUES (the one thing she said to memorize)

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

Why did agile happen? (the crisis numbers)

The chronic software crisis of the mid-1990s: about 84% of US projects were failures. Alistair Cockburn (IBM) studied why the other 16% succeeded. Those practitioners met in Utah in 2001 and wrote the Manifesto.

Does agile mean no documentation?

No. 'Just enough' documentation in a different form: self-documenting code, test cases as docs, sticky notes. If the customer values comprehensive docs, you write them. Teams often document after the fact.

Values → principles → practices: which are in the Manifesto?

Values (4) and principles (12) are. Practices are not; the framers left practices to each team. Any practice traces up to a principle, which traces up to a value.

Trace velocity up the pyramid

Practice: tracking velocity → principle: sustainable pace (a constant pace indefinitely) → value. Do this for any practice.

Features vs. stories: who prioritizes, who estimates?

Features (epics) are high-level and live in the project backlog. Only the features for the next release get decomposed into stories ('As a <role>, I can <action> so that <benefit>'). Customers prioritize. The dev team estimates.

Release cycle vs. iteration

The timeframe splits into equal release cycles, each split into equal iterations (usually 2 weeks). Development happens in iterations. Working software must be delivered at the end of every release cycle, not necessarily every iteration.

How do you handle a change request?

Not immediately (unless it's an emergency). Run a cost-benefit analysis: benefit of changing vs. not changing, where we are in the lifecycle, how many users are affected. Changes are near-free during RE and costly once code exists.

Scrum vs. XP

Scrum is a project/process-management framework with no engineering practices, so it is used alongside XP, which supplies the development practices.

Product Owner

May or may not be the customer (could be a customer rep such as a business analyst). Owns the functionality and is the final authority on whether something is done.

Pair programming: roles and how it's used today

One machine. The driver types, the navigator collaborates and reviews continuously, and they switch regularly. It is collaborative design, not a designer/typist split. Today it's used selectively: onboarding and very complex work.

Name five XP practices

Pair programming, on-site customer, collective ownership / whole team, continuous integration, TDD, refactoring, sustainable pace.

TDD in one breath

Write tests first. They fail (red). Write just enough code to pass (green). Then refactor. Payoffs: no bloat, better understanding of the requirements. It started as an XP practice.

Scrum vs. Kanban

Scrum is timeboxed and structured, a good start for new teams. Kanban is continuous flow with no iterations, and needs more team maturity.

When to choose plan-driven vs. agile (four factors)

Problem domain complexity / number of stakeholders; solution complexity and requirements stability (up-front modeling?); project size and team location; organizational culture.

What is usability? (in her words)

The quality of the user experience: how you feel after using a product. It needs both ease of use and usefulness. (ISO 9241-11: understand it, don't memorize it.)

The five usability criteria

Learnability, efficiency, errors, memorability, satisfaction.

Usability efficiency is NOT ___

System speed or performance. It means: once a user has learned the system, how easily can they accomplish their goal?

The errors criterion

How often users make errors, whether they can recover gracefully, and whether the message gives enough information to fix the mistake. (Combination lock: zero recoverability, no error messages.)

Functional vs. non-functional requirements

Functional: what the system does (or must not do). Non-functional: attributes of the system (security, performance, availability, usability) or constraints placed on it (storage limit, permissions, legal standards).

Why are NFRs more crucial than functional requirements?

They apply to the entire system (it is either secure or not), and failing one can render the system useless. Bank example: 20/20 features but not secure → rejected. 15/20 and secure → accepted.

'The system shall NOT accept credit cards.' Functional or non-functional?

Functional. Remove the negation: 'shall accept credit cards' is functional, so its opposite is too.

Domain requirements

Constraints from the application domain (FERPA in higher ed, HIPAA for a hospital billing system). They are a subset of NFRs, so missing one makes the system useless. Domain experts help, but they have tacit knowledge they can't articulate.

How do you make an NFR testable?

Add a quantitative measurement criterion. Example: 'a new user can learn the system in no more than 5 minutes' (learnability). Satisfaction: 'would you recommend this?' on a scale.

The five requirements engineering activities

Elicitation, analysis, specification, verification, requirements management (planning and controlling the rest).

Where does requirements validation happen?

Throughout, at every step. A clarifying question in an interview is validation. It is not a sixth box after specification.

The requirements evaluation criteria

Validity, consistency, completeness, realism/feasibility, verifiability/testability, unambiguity, traceability. Verifiability and unambiguity are 'crucial'.

Forward vs. backward traceability

Forward: every requirement appears in the architecture, the design, and the product. Backward: every feature in the product traces to an originating requirement (stops developers going off on tangents).

Agile RE concepts and practices

Evolutionary requirements, minimal big requirements up front, incremental and iterative implementation, accommodating late change, minimal documentation, just-in-time (JIT) requirements. Also: implicit V&V (mostly validation), requirements as a prioritized stack, the stakeholders' own vernacular, direct stakeholder involvement.

The agile RE process (four steps)

1. Identify the high-level features. 2. Prioritize them. 3. For each feature, gather details just in time from stakeholders. 4. Develop (TDD) and run acceptance tests.

Estimation and prioritization techniques

Estimation: relative story points (Fibonacci), velocity, done by the dev team, including testing time. Prioritization: MoSCoW, the day-one test, high/medium/low against the MVP, done by customers.

Architecture vs. design: her class/object analogy

Architecture is the class: a generic template or blueprint. Design is an object: many designs can instantiate one architecture. The same solution in C and in Java is two designs.

What is architecture, and what drives it?

The blueprint: the components, how they're arranged, and the relationships governing their interactions. It stays in the 'what' space. It is driven mainly by NFRs.

What is an architecture view? Why several?

The system from one stakeholder's perspective: a user sees functionality, a developer sees modules, a DB engineer sees data flow. A large system needs multiple views to be documented properly.

The 4+1 view model, and her criticism

Logical, process, development, and physical views, plus scenarios (use cases). Her criticism: logical and process views slip into design/implementation (objects, runtime processes).

What does an architecture framework provide? Name four.

Tools for creating an architecture: reference architectures, patterns, which views to build, a vocabulary, a method. DoDAF (US DoD; 'at a minimum, know DoDAF'), TOGAF (Open Group, method), MODAF (UK MoD), Zachman.

Data-centered (repository) pattern

A central data store with many clients (DBMS, library information systems, voice/image recognition). Supports modifiability and scalability. Shortcoming: the store's reliability and availability can be compromised (single point of failure).

Data flow (pipes and filters) pattern

Data passes through a chain of filters (batch processing, compilers, UNIX pipes). Supports reusability and modifiability. Shortcoming: unsuitable for dynamic interaction.

Call and return pattern

A main program calls subroutines (a Java main method calling other methods). Supports scalability and modifiability. Shortcomings: global data introduces vulnerabilities, and tight coupling causes ripple effects when things change.

Layered pattern: what it supports and what it costs

Concentric layers (UI → application → utility → core) with a layer policy, e.g. each layer only calls the one below. Supports security (critical assets in the inner layers), portability, modifiability, and reusability. Examples: .NET, the OSI 7-layer model. Cost: runtime performance overhead.

Security vs. safety

Security: how protected the data and system are. Safety: how safe the system is to operate for the people using it (Therac-25 radiation machine = safety). Security conflicts with nearly every other NFR.

Use case: definition, main vs. alternative sequence

The sequence of interactions between a user and the system to achieve a goal. Main sequence = the normal flow. Alternative sequences = deviations that need extra steps before resuming, and they drive error-handling design (auto-save).

Client-server pattern

Clients reach shared servers over a network (email servers and clients; a film/photo library with catalog, video, and picture servers). Supports modifiability and reusability. Shortcomings: server availability and scalability can suffer, and performance can be unpredictable.

Service-oriented architecture (SOA)

The system is composed of independent services (e.g. Amazon Web Services). Supports interoperability, reusability, scalability, and availability. Shortcomings: complex service management, and the overhead can hurt performance.

What is software design?

The 'how': algorithms, data structures, language, tools. It turns requirements and architecture into a concrete, readable plan for developers and testers, covering data, functionality, and behavior. It must reflect an architecture.

Abstraction vs. refinement

Abstraction removes detail and moves up (grouping stories into a feature). Refinement adds detail and moves down (breaking a feature into stories). Two sides of the same coin.

Separation of concerns → modularity → functional independence

SoC: split a complex problem into concerns (behaviors/features). Modularity: the concrete realization, actual independent components. Functional independence: the result, with low coupling and high cohesion.

Information hiding vs. abstraction

Information hiding is need-to-know access: one student can't see another's records, an admin can. Abstraction hides how something works so you can use it without knowing (driving a car).

Refinement vs. refactoring

'Get it working, then make it better' is refactoring: improving internal structure while preserving external behavior. Refinement means elaborating detail.

Observer pattern: problem, solution, consequence

Problem: one dataset shown as a pie chart and a bar graph means duplicated, coupled code. Solution: separate the subject (data) from the observers (displays). Consequence: change either side independently. Cost: notifying many observers.

What does configuration management include?

Version control, change management (cost-benefit on each change request), system building (linking components into an executable), release management (licenses, docs, versions, installers, release timing).

Four design patterns from the slides (the study guide asks for at least 4)

Observer: tell several objects that another object's state changed. Façade: tidy up the interfaces to a set of related, incrementally built objects. Iterator: a standard way to access a collection's elements regardless of how it's implemented. Decorator: extend an existing class's functionality at runtime.

What can testing show, and what can't it?

It reveals the presence of errors, never their absence. Exhaustive testing is impossible, so test smarter, and test as you go.

The two goals of testing

Validation testing: show the system does what it's supposed to. Defect testing: find where it misbehaves or doesn't conform to its spec.

Fitness for purpose: when are we done testing?

When confidence is high enough for the purpose. The bar depends on software purpose/criticality, user expectations, and the marketing environment.

Inspection vs. testing

Inspection is static verification: people examine any representation (requirements, design, code, schemas) without running it, so it can happen before implementation, on incomplete versions, and can check standards and maintainability. Testing is dynamic verification: execute the system with test data and observe its behavior. They complement each other.

Regression testing

Re-running tests to check that a change hasn't broken previously working code. It is expensive when manual and simple when automated: re-run every test on every change, and the tests must pass before you commit.

Alpha vs. beta vs. acceptance testing

Alpha: users test with the dev team at the developer's site. Beta: a release goes to users to experiment with and report problems. Acceptance: customers decide whether to accept and deploy the system (mainly custom systems).