ACM-SW cheat sheet

A functional requirement specifies a behavior or function the system must perform; a non-functional requirement constrains qualities such as performance, security, or usability.

A requirement is verifiable if a finite, cost-effective process exists to check whether the delivered system meets it.

Requirements elicitation techniques include interviews, questionnaires, observation, document analysis, brainstorming, and prototyping.

A use case describes a sequence of interactions between an actor and the system that yields an observable result of value to the actor.

Requirements traceability links each requirement to its source and to design, code, and test artifacts; forward and backward traceability support impact analysis.

MoSCoW prioritization classifies requirements as Must have, Should have, Could have, and Won't have.

A requirements baseline is a formally reviewed and agreed-upon set of requirements that changes only through change control.

Ambiguity in natural-language requirements is reduced by using a restricted grammar, defining terms in a glossary, and specifying measurable acceptance criteria.

Coupling measures interdependence between modules; low coupling is preferred. Cohesion measures relatedness within a module; high cohesion is preferred.

The Single Responsibility Principle states that a class should have only one reason to change.

The Open-Closed Principle states that software entities should be open for extension but closed for modification.

The Liskov Substitution Principle requires that objects of a supertype be replaceable by objects of a subtype without altering correctness.

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions.

The Interface Segregation Principle states that clients should not be forced to depend on methods they do not use.

Architectural styles include layered, client-server, pipe-and-filter, event-driven, and microservices; each trades coupling, scalability, and complexity differently.

A design pattern names a recurring solution to a problem in a context; it is described by intent, structure, participants, and consequences.

Cyclomatic complexity V(G) = E - N + 2P, where E is edges, N is nodes, and P is connected components; higher values indicate more test paths.

Defensive programming validates inputs and handles error conditions explicitly rather than assuming preconditions hold.

A code smell is a surface indication of a deeper problem, such as duplicated code, long methods, or excessive parameters.

Refactoring changes internal structure without changing external behavior; it is typically guarded by automated tests.

The DRY principle (Don't Repeat Yourself) states that every piece of knowledge should have a single, authoritative representation.

Static analysis tools detect defects such as unused variables, null dereferences, and style violations without executing the program.

Pair programming is a construction practice in which two developers share one workstation, one writing and one reviewing.

Immutable objects cannot change state after construction, which simplifies reasoning and supports safe sharing across threads.

Black-box testing derives test cases from specifications without knowledge of internal structure; white-box testing uses code structure.

Statement coverage measures the fraction of executable statements executed; branch coverage measures the fraction of decision outcomes executed.

Equivalence partitioning divides inputs into classes expected to behave alike; boundary value analysis tests values at and near class edges.

Unit tests verify individual components; integration tests verify interactions among components; system tests verify end-to-end behavior.

Regression testing re-runs existing tests after changes to detect unintended effects.

A test oracle is a mechanism for determining whether a test outcome is correct.

Mutation testing measures test suite quality by introducing faults and checking whether tests detect them.

The defect cost curve typically rises steeply the later a defect is found in the lifecycle.

Corrective maintenance fixes defects; adaptive maintenance responds to environment changes; perfective maintenance improves performance or maintainability; preventive maintenance reduces future risk.

Software aging is the gradual degradation of performance or maintainability due to accumulated changes and obsolete assumptions.

Legacy systems are often characterized by obsolete technology, lack of documentation, and high business value.

Reengineering restructures a system to improve maintainability without changing its functionality; reverse engineering recovers design information.

Refactoring is a form of preventive maintenance that improves structure without changing behavior.

Impact analysis identifies the components and artifacts affected by a proposed change.

Configuration management supports maintenance by tracking versions and enabling controlled change.

The majority of lifecycle cost in long-lived systems is typically attributed to maintenance rather than initial development.

Configuration items are artifacts placed under version control, including source code, requirements, build scripts, and documentation.

A baseline is a formally approved configuration that serves as a basis for further development and can only change through change control.

A configuration audit verifies that the delivered product matches its documented configuration.

Critical path method identifies the longest sequence of dependent tasks; its length determines the minimum project duration.

Earned value management compares planned value, earned value, and actual cost to assess schedule and cost performance.

A Gantt chart displays tasks against a timeline; a PERT chart displays task dependencies as a network.

Risk management involves identification, analysis, planning, and monitoring of risks throughout the project.

A change control board reviews and approves or rejects proposed changes to baselined artifacts.

The waterfall model is sequential; iterative and incremental models deliver working software in repeated cycles.

Scrum defines roles (Product Owner, Scrum Master, Developers), artifacts (Product Backlog, Sprint Backlog, Increment), and events (Sprint, Daily Scrum, Sprint Review, Sprint Retrospective).

Extreme Programming practices include test-driven development, pair programming, continuous integration, and small releases.

CMMI maturity levels range from 1 (Initial) to 5 (Optimizing), with levels 2-5 defined by process areas.

ISO/IEC 25010 defines software product quality characteristics including functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability.

A software process improvement cycle commonly follows Plan-Do-Check-Act.

Technical debt is the implied cost of rework caused by choosing an expedient solution over a better approach.

A quality gate is a checkpoint at which defined criteria must be met before a phase or release proceeds.

The ACM Code of Ethics and Professional Conduct includes obligations to contribute to society, avoid harm, be honest and trustworthy, and respect privacy.

Professional responsibility includes competence, maintaining confidentiality, and disclosing conflicts of interest.

Whistleblowing is the disclosure of illegal or unethical conduct within an organization to an authority able to act on it.

Intellectual property protections relevant to software include copyright, patents, trademarks, and trade secrets.

Software engineers should not claim expertise they lack and should seek appropriate review for work outside their competence.

Informed consent requires that users understand what data is collected and how it is used before agreeing.

Professional codes require that engineers report significant risks discovered in software to appropriate parties.

Conflicts of interest arise when personal interests could improperly influence professional judgment and must be disclosed.