Theory & SDLC
This term refers to the systematic application of engineering principles to software development.
Software Engineering
This common architectural pattern separates an application into Model, View, and Controller.
MVC
This type of test isolates and verifies a single component or module of code.
Unit Testing
This Git command is used to move changes from your local workspace to the staging area.
git add .
This OOP principle hides complex implementation details and shows only the necessary features of an object.
Abstraction
This type of requirement defines "what" a system should do (e.g., "The system shall process a payment")
Functional Requirement
These UML diagrams show the static structure of a system, such as a Class diagram.
Structural Diagrams
This process ensures the product meets the actual needs and expectations of the user ("Are we building the right product?").
Validation
This Git command saves your staged changes locally with a descriptive message.
git commit
This principle advises developers not to add functionality until it is absolutely necessary.
YAGNI - You Ain't Gonna Need It
This stage of the SDLC involves gathering user needs before any design or coding begins.
Requirements Engineering/Analysis
This design quality measures how independent modules are from one another; good design aims for "low" this.
Coupling
This process ensures the product is built correctly according to its technical specifications
Verification
This command is used to send your local commits to a remote hosting service like GitHub.
git push
This OOP mechanism allows a subclass to acquire the properties and methods of a superclass.
Inheritance
This requirement type defines "how" a system performs, such as its security, speed, or availability.
Non-functional Requirement
These UML diagrams show the dynamic flow and timing of a system's behavior.
Behavioral/Dynamic Diagrams
This testing phase is the final check performed by the customer before the software is delivered.
Acceptance Testing
This term refers to the storage space (local or remote) where your project and its version history are kept.
Repository
This term refers to the implied cost of future rework caused by choosing an easy, fast solution now instead of a better approach.
Technical Debt
This specific framework is used to categorize requirements, specifications, and domain knowledge.
WRSPM
This architectural style breaks a single application into a suite of small, independently deployable services.
Microservices
This black-box testing technique involves testing values at the exact edges of an allowed range.
Boundary Value Analysis
This command fetches changes from a remote repository and integrates them into your current local branch.
git pull
This principle suggests that a class should have only one reason to change, focusing on a single task.
Single Responsibility Principle