IT 005 - Module 1.3

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

1/23

encourage image

There's no tags or description

Looks like no tags are added yet.

Last updated 2:44 AM on 7/29/26
Name
Mastery
Learn
Test
Matching
Spaced
Call with Kai
Chat

No analytics yet

Send a link to your students to track their progress

24 Terms

1
New cards

Effects of Scale

The idea that as software grows bigger and more complex, small added features can cause much bigger, unexpected problems.

2
New cards

Simpler is Better

A core software design principle: good software has a simple internal structure and a simple interface for users.

3
New cards

Internal Structure

How a program is built and organized on the inside (its code design).

4
New cards

Interface

The part of the software that users or other systems interact with.

5
New cards

Cost-Benefit Analysis

Weighing whether a new feature's benefits are worth its costs before adding it to software.

6
New cards

Feature Interaction Cost

The hidden cost of a new feature caused by how it affects and interacts with all the other existing features, not just itself.

7
New cards

Underestimating Cost

A common mistake where developers don't realize how expensive/complex adding a feature will really be.

8
New cards

Overestimating Value

A common mistake where developers think a new feature is more useful than it actually turns out to be.

9
New cards

Feature Creep (implied)

When more and more features are added, making a program more complex for both users and developers.

10
New cards

Security Risk from Feature Interaction

Unexpected combinations of features can create security holes, even if each feature works fine on its own.

11
New cards

"Attackers Break Systems, Not Components"

A security principle stating that attackers exploit unexpected interactions between features, not just single weak parts.

12
New cards

Secure System Design Principle

True security comes from software being modest, straightforward, and easy to understand.

13
New cards

Complex Design Risk

The more intricate a design and the more special-case features it has, the more room there is for errors.

14
New cards

Software Virtuosity

Using overly clever, intricate, or fast algorithms to solve efficiency problems; often makes code harder to maintain and less reliable.

15
New cards

Trade-off Consideration

Before making software more complex for performance reasons, consider simpler solutions like better hardware or reduced requirements first.

16
New cards

Higher-Level Programming Language

A programming language that is more abstract and closer to human language, making it easier to write and reducing bugs.

17
New cards

Abstraction Mechanism

A tool in a language (like procedures) that hides complex details, making code easier to read and manage.

18
New cards

Data Abstraction

A mechanism (like packages) that hides how data is structured, showing only what's needed to use it.

19
New cards

Control Abstraction

A mechanism (like iterators) that hides the details of how a process or loop works internally.

20
New cards

Checkable Redundancy

Extra information in code (like type declarations) that lets the compiler catch errors before the program runs.

21
New cards

Type Checking

A compiler process that ensures data is used correctly, rejecting code with type mismatches as illegal.

22
New cards

Automatic Storage Management

A feature (like garbage collection) that automatically manages memory, reducing errors from misusing memory.

23
New cards

Tunneling Attack

An attack that exploits vulnerabilities at a lower level of abstraction than what the software developers were working with.

24
New cards

Run-Time Support Library

A large set of built-in code (e.g., Ada's Run-Time Support Library) that higher-level languages rely on while running, which can itself be a target for attacks.