Software Engineering Fundamentals

0.0(0)
Studied by 2 people
call kaiCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/33

flashcard set

Earn XP

Description and Tags

Comprehensive vocabulary flashcards covering basic software engineering definitions, Brooks' difficulties, requirements engineering, architectural styles, design principles, testing fundamentals, and process models.

Last updated 9:43 PM on 6/8/26
Name
Mastery
Learn
Test
Matching
Spaced
Call with Kai

No analytics yet

Send a link to your students to track their progress

34 Terms

1
New cards

Software Engineering

The systematic, disciplined, quantifiable approach to the development, operation, maintenance, and retirement of software.

2
New cards

People (Essential Ingredient)

The most important of the three essential ingredients; includes everyone in the cycle such as managers, developers, users, and stakeholders.

3
New cards

Processes

A series of steps or activities used to produce high-quality products.

4
New cards

Tools

Instruments used to motorize processes, which improve efficiency, accuracy, and productivity.

5
New cards

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.

6
New cards

Conformity (Essential Difficulty)

The requirement that software must conform to existing external interfaces, human institutions, and systems.

7
New cards

Changeability (Essential Difficulty)

The pressure for software to constantly evolve as environments change or users discover new possibilities.

8
New cards

Invisibility (Essential Difficulty)

The characteristic of software lacking physical representation, making it difficult to visualize, conceptualize, and communicate.

9
New cards

No Silver Bullet

Brooks' claim that no single technology, such as AI or object-oriented programming, provides a tenfold productivity gain in a decade.

10
New cards

Requirements Engineering

The description of WHAT the system should do, as opposed to HOW it should do it.

11
New cards

Ziv’s Law

The principle that software development is unpredictable; artifacts such as requirements will never be fully understood, and uncertainty is inevitable.

12
New cards

Analysis (Requirements Phase)

The process of discovering and gathering customer needs.

13
New cards

Specification (Requirements Phase)

The process of describing and documenting customer needs.

14
New cards

Application Context

A section of the requirements document that details the environment or situation of the software.

15
New cards

Architectural Erosion

When implemented code diverges from the intended, planned design due to factors like short deadlines, developer sloppiness, or lack of documentation.

16
New cards

Model-View-Controller (MVC)

An architectural style that isolates business logic from the user interface (UI).

17
New cards

Client-Server

An architectural style that partitions tasks between service providers and requesters.

18
New cards

Layered Style

A style using horizontal layers where each communicates only with the one directly below it.

19
New cards

Peer-to-Peer

A decentralized architectural style where participants act as both clients and servers.

20
New cards

Pipe-and-Filter

A style consisting of sequential steps called filters connected by channels called pipes.

21
New cards

Publish-Subscribe

An architectural style where senders send messages to a broker without knowing the specific receivers.

22
New cards

High Cohesion

A design principle involving the grouping of related functionality into a single module.

23
New cards

Low Coupling

A design principle focused on reducing interdependency across separate modules.

24
New cards

Information Hiding

The practice of hiding design decisions likely to change in order to protect the rest of the system.

25
New cards

Verification

The testing process to determine if the software conforms to its specifications.

26
New cards

Validation

The testing process to determine if the software serves its intended purpose.

27
New cards

Dijkstra Quote

"Program testing can be used to show the presence of bugs, but never to show their absence".

28
New cards

Statement (Node) Coverage

A testing metric that requires visiting every node in the control-flow graph.

29
New cards

Branch (Edge) Coverage

A testing metric that requires visiting every edge; it is more thorough than statement coverage.

30
New cards

Black-box Testing

Testing based on specifications, including techniques like equivalence partitioning and boundary value analysis.

31
New cards

White-box Testing

Testing based on code structure, such as control-flow graphs.

32
New cards

Waterfall Model

A linear process model following a sequence of requirements, design, implementation, verification, and maintenance.

33
New cards

Spiral Model

A risk-driven software process model.

34
New cards

Test-Driven Development (TDD)

An XP/Agile practice where developers write tests before the corresponding code.