1/33
Comprehensive vocabulary flashcards covering basic software engineering definitions, Brooks' difficulties, requirements engineering, architectural styles, design principles, testing fundamentals, and process models.
Name | Mastery | Learn | Test | Matching | Spaced | Call with Kai |
|---|
No analytics yet
Send a link to your students to track their progress
Software Engineering
The systematic, disciplined, quantifiable approach to the development, operation, maintenance, and retirement of software.
People (Essential Ingredient)
The most important of the three essential ingredients; includes everyone in the cycle such as managers, developers, users, and stakeholders.
Processes
A series of steps or activities used to produce high-quality products.
Tools
Instruments used to motorize processes, which improve efficiency, accuracy, and productivity.
Complexity (Essential Difficulty)
A condition where software systems are more intricate than other human constructs; no two parts are identical, and states increase with every element.
Conformity (Essential Difficulty)
The requirement that software must conform to existing external interfaces, human institutions, and systems.
Changeability (Essential Difficulty)
The pressure for software to constantly evolve as environments change or users discover new possibilities.
Invisibility (Essential Difficulty)
The characteristic of software lacking physical representation, making it difficult to visualize, conceptualize, and communicate.
No Silver Bullet
Brooks' claim that no single technology, such as AI or object-oriented programming, provides a tenfold productivity gain in a decade.
Requirements Engineering
The description of WHAT the system should do, as opposed to HOW it should do it.
Ziv’s Law
The principle that software development is unpredictable; artifacts such as requirements will never be fully understood, and uncertainty is inevitable.
Analysis (Requirements Phase)
The process of discovering and gathering customer needs.
Specification (Requirements Phase)
The process of describing and documenting customer needs.
Application Context
A section of the requirements document that details the environment or situation of the software.
Architectural Erosion
When implemented code diverges from the intended, planned design due to factors like short deadlines, developer sloppiness, or lack of documentation.
Model-View-Controller (MVC)
An architectural style that isolates business logic from the user interface (UI).
Client-Server
An architectural style that partitions tasks between service providers and requesters.
Layered Style
A style using horizontal layers where each communicates only with the one directly below it.
Peer-to-Peer
A decentralized architectural style where participants act as both clients and servers.
Pipe-and-Filter
A style consisting of sequential steps called filters connected by channels called pipes.
Publish-Subscribe
An architectural style where senders send messages to a broker without knowing the specific receivers.
High Cohesion
A design principle involving the grouping of related functionality into a single module.
Low Coupling
A design principle focused on reducing interdependency across separate modules.
Information Hiding
The practice of hiding design decisions likely to change in order to protect the rest of the system.
Verification
The testing process to determine if the software conforms to its specifications.
Validation
The testing process to determine if the software serves its intended purpose.
Dijkstra Quote
"Program testing can be used to show the presence of bugs, but never to show their absence".
Statement (Node) Coverage
A testing metric that requires visiting every node in the control-flow graph.
Branch (Edge) Coverage
A testing metric that requires visiting every edge; it is more thorough than statement coverage.
Black-box Testing
Testing based on specifications, including techniques like equivalence partitioning and boundary value analysis.
White-box Testing
Testing based on code structure, such as control-flow graphs.
Waterfall Model
A linear process model following a sequence of requirements, design, implementation, verification, and maintenance.
Spiral Model
A risk-driven software process model.
Test-Driven Development (TDD)
An XP/Agile practice where developers write tests before the corresponding code.