Software Engineer GLOSSARY
0-9
0-day See zero-day.
1337 See elite hacker.
1GL See first generation language.
1NF See first normal form.
2FA See two-factor authentication.
2GL See second generation language.
2NF See second normal form.
3-2-1 backup strategy You keep three copies of your data (two backups plus the copy that’s in use) on two types of media with one copy off-site.
3GL See third generation language.
3NF See third normal form.
4GL See fourth generation language.
5GL See fifth generation language.
80/20-rule In the Dynamic Systems Development Method (DSDM), the assumption that 80 percent of an application’s features will take 20 percent of the project’s total time to implement. (The 80/20-rule often applies to other situations too. For example, 80 percent of the bugs are usually contained in 20 percent of the code.)
A
acceptance test A test to determine whether the finished application meets the requirements.
ACM Association for Computing Machinery.
ACS Australian Computer Society.
activation See execution specification.
activity diagram In UML, a diagram that represents workflows for activities. They include several kinds of symbols connected with arrows to show the direction of the workflow.
adapter, wrapper, or translator A design pattern that provides a simplified interface to a class.
adaptive development model A development model that enables you to change the project’s goals if necessary during development.
administrator Someone who manages the development team’s computers, network, and other tools.
Also called a system administrator.
advisor user Any user who brings an important viewpoint to the project.
adware Spyware that displays ads on your browser.
agile development A development model where you initially provide the fewest possible features at the lowest fidelity to still have a useful application. Over time, you add more features and improve existing features until all features have been implemented at full fidelity.
Agile Manifesto A set of four guiding principles for agile development. In brief the principles are as follows:
- ➤ Individuals and interactions over processes and tools
- ➤ Working software over comprehensive documentation
- ➤ Customer collaboration over contract negotiation
- ➤ Responding to change over following a plan
Agile Unified Process (AUP) A simplified version of Rational Unified Process that includes agile methods such as test-driven development and agile modeling. In 2012, AUP was superseded by Disciplined Agile Delivery.
AI See artificial intelligence.
AI tools Artificial intelligence tasks that have largely been solved, such as speech recognition and synthesis and natural language processing.
algorithm A software recipe that explains how to solve a particular programming problem.
algorithmic bias Occurs when a program’s algorithms have an underlying bias that makes them
produce bad results.
ambassador user Someone who acts as a liaison between the users and the developers.
analyst, business analyst, or domain expert The customers’ representatives, particularly when the
customers are within the company.
anchoring A phenomenon where an early decision made by one person influences later decisions
by others.
angler phishing Phishing sent via social media with the attacker sometimes posing as a customer service
representative.
anomaly In a relational database, an error caused by a design flaw such as records holding inconsistent
values or being unable to delete a piece of data because it is necessary to record some unrelated piece of
information.
anti-spyware Similar to antivirus software except it looks for spyware.
antivirus software A program that looks for and removes installed malware. It may also scan emails
and downloads and may periodically scan every file on the system.
architect Someone who focuses on the application’s overall high-level design.
artifact In a UML deployment diagram, a file, script, executable program, or other item that is deployed.
In development models, something generated by the model, such as a requirements document, user story,
or piece of code.
artificial general intelligence (AGI) “True” artificial intelligence. Also called strong AI, full AI, and
general intelligent action.
artificial intelligence (AI) A program that does something human-like.
artificial neural network A learning system modeled on biological neural networks such as the human
brain. Also called a neural network.
artificial neuron A small part of a neural network. Also called a neuron.
assertion A statement about the program and its data that is supposed to be true. If the statement isn’t
true, the assertion throws an exception to tell you that something is wrong.
Atlantic City algorithm Correct at least some fraction of the time and always relatively fast.
attribute Some feature of a project that you can measure, such as the number of lines of code, the
number of defects, or the number of times the word “mess” appears in code comments. See also metric
and indicator.
audit trail A record of actions taken by an application’s users for security auditing purposes.
augmented reality (AR) A system that overlays computer-generated images on real-world images,
possibly through goggles or a heads-up display.
AUP See Agile Unified Process.
B
backtracking A way to envision a search through a solution space. You follow a path until you find that
it cannot work and then you backtrack to a previous partial solution that may still succeed.
BDUF See Big Design Up Front.
behavior diagram In UML, a diagram that shows the behavior of some entity. There are three kinds of
behavior diagrams: activity diagrams, use case diagrams, and state machine diagrams.
big board A large board used by many agile models that is posted in a visible location so that everyone
can see the project’s status at a glance. Also called an information radiator.
Big Design Up Front (BDUF) See predictive development model.
big O notation A system for studying the limiting behavior of algorithms as the size of the problem
grows large.
binary search A search where you repeatedly divide the area that may contain a target into two smaller
(ideally equal) pieces.
biometric security Uses body measurements (such as fingerprint recognition, retina scan, facial recognition, or voice recognition) for identification.
black-box test A test designed by someone who doesn’t know how the code works internally.
black hat Someone who breaks security for malicious reasons or personal gain.
blackboard Combines data from various data sources, possibly translating into a common format.
bloatware See crapware.
blockchain A distributed ledger system that allows participants to verify that certain transactions have
occurred without requiring a central authority.
blue hat Either (1) revenge seekers or (2) outside security professionals.
bot A program that runs over a network.
botnet A network of bots controlled by an attacker—for example, to launch distributed denial-ofservice attacks.
brainstorming A group technique for discovering creative solutions to a problem.
branch and bound A particularly clever way to prune decision trees.
bug A flaw in a program that causes it to produce an incorrect result or to behave unexpectedly. Bugs
are generally evil.
build engineer In Feature-Driven Development (FDD), someone who sets up and controls the
build process.
burndown chart In scrum, a graph showing the amount of work remaining over time.
business advisor See business analyst.
business ambassador Someone who provides business information from the viewpoint of the users.
business analyst A domain expert who helps define the application’s purpose and who provides
feedback during development. Also called a business advisor.
business requirements The project’s high-level business goals. They explain what the customer hopes
to achieve with the project.
business visionary Someone who has a clear vision of the application’s business role, particularly early
in the process when that role isn’t clearly written down.
C
cause-and-effect diagram See Ishikawa diagram.
CAV See complexity adjustment value.
CBSE See component-based software engineering.
chain of responsibility A design pattern that uses a chain of objects to handle requests by passing the
request along until an object handles it.
change A change to an application that is requested by customers. This may happen when customers
understand the application better, when customers think of a new feature or a modification they want, or
when the users’ environment changes so the application needs to be changed to be useful.
change control board A group of project members, possibly including one or two customers, that
reviews and approves or rejects change requests.
change-making problem A problem where you must find the fewest coins needed to make change for
a given amount.
change management See version management.
change manager Studies and approves or rejects changes requested by the customers, analysts, developers, and others.
change tracking See version management.
chatbot A program that uses natural language processing to interact with customers to do things like
track orders, check account balances, and connect with the correct department.
chief architect In Feature-Driven Development, the person responsible for the project’s overall programmatic design.
chief programmer In Feature-Driven Development, an experienced developer who is familiar with all
of the functions of development (design, analysis, coding, and so on). Chief programmers lead
project teams.
child class A class derived from a parent class. The child class inherits properties, methods, and events
from the parent class.
child table See foreign key.
CIA triad In database security, this stands for confidentiality, integrity, and availability.
class In object-oriented programming, a construct that defines a type (or class) of items. For example, if
you define a Customer class, you can then create many Customer objects representing different real-world
customers.
class diagram In UML, a diagram that describes the classes that make up the system, their properties
and methods, and their relationships.
class owner In Feature-Driven Development, the person who is responsible for a particular class’s code.
Cleanroom A development model that emphasizes defect prevention rather than defect removal. It uses
formal methods, statistical quality control, and statistical testing to prevent and detect bugs.
client-server architecture A design that separates pieces of the system that need to use a particular
function (clients) from parts of the system that provide those functions (servers). That decouples the client
and server pieces of the system so that developers can work on them separately.
client tier The tier in a multitier architecture that consumes a service. This is often an application’s user
interface.
coach Someone who helps a development team follow its chosen path (XP, scrum, Lean, and so forth).
Alternatively, someone who works with less-experienced team members to help them learn and be more
effective.
code coverage The lines of code that are executed during a demonstration or a suite of tests.
code inspection See code review.
code review When two or more programmers walk through a piece of code to look for problems. Also
called a code inspection.
codebehind In Windows Presentation Foundation (WPF), the code that sits behind the user interface.
More generally, any code that sits behind the user interface.
coding standards Standards used by a development team to ensure consistency. Standards may define
conventions for variable names, comments, documentation, specific code style, and more. Coding standards make the code easier to read and debug.
column See field.
command Encapsulates a command that can be passed as a parameter.
commensurate difficulty The concept that dangerous or difficult things should be harder to do than
things that are safe and simple.
communication diagram In UML, a diagram that shows communication among objects during some
sort of collaboration. This is similar to a sequence diagram except a sequence diagram focuses on the
sequence of messages and a communication diagram focuses more on the objects involved in the
collaboration.
complexity adjustment factors In function point calculations, values that take into account the
importance of general features of the application (such as transaction rate).
complexity adjustment value (CAV) In function point calculations, the sum of the complexity
adjustment factors.
complexity factor In function point calculations, you multiply each function point metric by a
complexity factor to indicate how complex each activity is.
component-based software engineering (CBSE) A design that regards the system as a collection of
loosely coupled components that provide services for each other.
component diagram In UML, a diagram that shows how components are combined to form larger
parts of the system.
component interface test A test that studies the interactions between components. This is a bit like
regression testing in the sense that both examine the application as a whole to look for trouble, but
component interface testing focuses on component interactions.
composite A design pattern that composes objects into a tree- or network-like structure so you can
represent objects and groups of objects uniformly.
composite structure diagram In UML, a diagram that shows a class’s internal structure and the
collaborations that the class allows.
computability theory The study of what things are computable and how quickly programs run.
configuration management Managing the items produced by the project such as requirements
documents, designs, and, of course, source code. This may include controlling changes to those items so
that changes don’t happen willy-nilly.
continuous integration and continuous delivery/deployment (CI/CD or CICD) Agile taken to
the extreme.
conversation hijacking When an attacker inserts bogus messages into a conversation stream.
coprime See relatively prime.
COTS Commercial off-the-shelf, as in a COTS application. Software, hardware, or other resources that
are available from a vendor without any customization.
cowboy coding A development methodology where the programmers have complete control over the
process and generally do what they want. This is often a derogatory term, although for very small projects
and very experienced developers it can sometimes produce good results.
crapware Programs that serve ads, return marketing information to companies, and constantly nag you
to upgrade.
credential stuffing When an attacker breaks one system and then uses its usernames and passwords to
try to attack another system. Also called password stuffing.
critical path A longest path through a PERT chart network. If any task along a critical path is delayed,
the project’s final completion is also delayed. Note that a network may have multiple critical paths.
cross-functional team A team where every member can play every role. Every member can participate
in requirements analysis, design, programming, testing, and the rest.
Crystal A family of development methodologies that take into account a project’s team size and criticality. Team size determines the project’s “color,” which can be Clear (1–6), Yellow (7–20), Orange (21–40),
Orange Web (21–40 with ongoing releases), Red (41–80), Maroon (81–200), Diamond (201–500), and
Sapphire (501–1,000). Criticality is measured by the type of thing that could be at risk. Criticality values
include comfort, discretionary money, essential money, and life.
Crystal Clear A relatively relaxed and easy-going approach to development using a small team (1–6
people) and low criticality. Crystal Clear defines only three required roles: sponsor, senior designer, and
programmer. See also Crystal.
Crystal Orange A development approach that is slightly larger and more formal than Crystal Yellow.
Projects may add the new roles business analyst, project manager, architect, and team leader. They also add
requirements, tracking, a release schedule, object models, code reviews, acceptance testing, and more
formal delivery. Total team size is typically 21–40 people.
Crystal Yellow A development approach that is slightly larger and more formal than Crystal Clear.
These projects adopt new practices above the roles defined by Crystal Clear, including easy communication, code ownership, feedback, automated testing, a mission statement, and more formal increments.
Total team size is typically 7–20 people.
customer or client A person for whom a project is being built. Typically, the customer defines requirements and verifies that the finished application meets those requirements. In some models, the customer
also provides feedback during development.
cutover The process of moving users to a new application.
cyber insurance Covers damages related to cyberattacks such as legal counsel, forensics, losses due to
fraudulent transactions, and reparations to customers.
cypherpunk This person advocates widespread use of strong encryption as a means to promote
social change.
D
DAD See Disciplined Agile Delivery.
daily scrum Scrum’s version of a daily standup meeting. Also simply called a scrum. See also standup meeting.
data-centric architecture A design where the application is centered around some kind of database.
data tier The server tier in a three-tier architecture.
data warehouse A secondary database that holds older data for analysis. In some applications, you
may want to analyze the data and store modified or aggregated forms in the warehouse instead of keeping
every outdated record in the production database.
database administrator (DBA) Maintains the team’s databases, possibly including the documentation
and source code databases.
database-centric architecture See data-centric architecture.
database designer Specialist at designing databases.
DBA See database administrator.
DDoS See distributed denial-of-service attack.
decision tree A logical tree data structure that helps you think about a problem’s solution space.
declarative programming language A language where you specify the result that you want and the
program figures out how to get that result.
decomposition In a V-model project, the steps on the left side of the V that break the application down
into pieces that you can implement.
decorator A design pattern that attaches additional features to an object.
deep dive See spike.
deep learning Uses a neural network with several layers that process increasingly abstract features.
defect Incorrect feature in an application. Defects can be broadly grouped into two categories: bugs
and changes.
defensive programming The idea that the code should work no matter what kind of garbage is passed
into it for data. The code should work and produce some kind of result no matter what. See also offensive
programming.
denial-of-service attack (DoS) Tries to make a server or network unusable, usually by flooding it with
bogus requests.
deployer In Feature-Driven Development, someone who handles deployment.
deployment The process of delivering a finished application to the users. See also implementation.
deployment diagram In UML, a diagram that describes the deployment of artifacts (files, scripts,
executables, and the like) on nodes (hardware devices or execution environments that can execute
artifacts).
derive To subclass a child class from a parent class. The child class inherits properties, methods, and
events from the parent class.
design inspection A review of a design to look for problems before writing code to implement the
design. In Feature-Driven Development, a chief programmer holds a design inspection before the team
implements the design.
design package In Feature-Driven Development, the result of a design-by-feature phase. The design
package includes a description of the package, sequence diagrams showing how the features will work,
alternatives, an updated object model, and method prologues.
design pattern In object-oriented programming, an arrangement of classes that interact to perform
some common and useful task. Similar to an algorithm for objects.
developer Someone who participates in the project development. Sometimes this term is used interchangeably with programmer.
development manager In Feature-Driven Development, someone who manages day-to-day development activities.
DevOps The development process with operations planning integrated into the process from the
beginning.
DevSecOps The development process with security and operations planning integrated into the process
from the beginning.
direct manipulation When the user performs “physical” manipulation of objects on the screen—for
example, drag and drop.
Disciplined Agile Delivery (DAD) A development framework that incorporates features of UP, scrum,
XP, kanban, Lean, and others. It uses the three UP phases: inception, construction, and transition.
distributed architecture A design where different parts of the application run on different processors
and may run at the same time. The processors could be on different computers scattered across the
network, or they could be different cores on a single computer.
distributed denial-of-service attack (DDoS) A denial-of-service attack that comes from multiple
computers, possibly in a botnet.
divide and conquer An algorithmic approach were you repeatedly divide a problem into pieces and
then either solve or discard pieces.
domain expert A customer, user, executive champion, or other person who knows about the project
domain and how the finished application should work. Also called subject matter expert (SME).
domain manager In Feature-Driven Development, someone who leads the domain experts and provides
a single point of contact to resolve domain issues.
domain walk through In Feature-Driven Development, a walk-through of a scenario by a domain
expert to verify that the scenario is correct and to answer questions for the developers about the scenario.
dongle A small device that plugs into your computer (often through a USB port) so your program can
verify that the device is present.
don’t repeat yourself (DRY) principle In programming, a rule of thumb that says if you need to write
the same piece of code twice, then you should extract it into a separate method that you can call from
multiple places so you don’t have to write it a third time (or a fourth time, or a fifth time, and so on).
DoS See denial-of-service attack.
double extortion scheme Ransomware where the attacker encrypts files and also threatens to release
sensitive data to other hackers or the public.
driver In pair programming, the programmer who types.
DRY See don’t repeat yourself (DRY) principle.
DSDM See Dynamic Systems Development Method.
dynamic programming An algorithm that uses saved partial results.
Dynamic Systems Development Method (DSDM) An agile framework designed with a more
business-oriented focus. It can be used to add extra business control to other development models. It uses
the phase’s pre-project, project life cycle (which includes study, functional modeling, design and build, and
implementation) and post-project.
E
EDA See event-driven architecture.
edge computing The idea of moving computation and data storage closer to data sources such as IoT
devices to reduce response time, centralized storage requirements, and network usage.
eight-queens problem A problem where you must find a way to position eight queens on a chessboard
so they cannot attack each other.
eleet See elite hacker.
elite hacker, eleet, leet, or 1337 A hacker with mad ninja skillz. The term is sometimes used ironically.
embarrassingly parallel A problem that naturally breaks into pieces that have little to do with each
other, so coordinating among parallel processes is easy.
environment The hardware, network, operating system, other applications, and other features that are
present where the application runs. This includes the users’ computers, networks, printers, other applications, and physical environment (chairs, lamps, coffee machines, and so forth).
ergonomics The study of people in their work environments, particularly looking for ways to reduce
injuries such as severe eyestrain, carpal tunnel syndrome, computer back, trigger finger, mouse shoulder,
tech neck, BlackBerry thumb, iPad hand, Wiiitis, and Nintendinitis.
event In object-oriented programming, an event occurs to notify the application that something
interesting occurred. For example, the user might have clicked a button or a timer might have expired.
event-driven architecture (EDA) A design where various parts of the system respond to events as
they occur.
everything as a service (XaaS) A category of cloud-based tools that provide remote services for things
such as storage, computing, security, and e-commerce.
evolutionary prototype A prototype that evolves over time with new features added and the existing
features improved until the prototype eventually becomes the finished application.
exception An unexpected condition in a program such as a divide by zero or trying to access a missing
file. If the code doesn’t catch and handle the exception, the program crashes.
execution See execution specification.
execution specification In a UML sequence diagram, a gray or white rectangle that represents a
participant doing something. Also called an execution or activation.
executive champion The highest-ranking executive who supports the project.
executive sponsor See executive champion.
exhaustive search The strategy of examining every possible solution to find the best one.
expert system See rule-based architecture.
exploit A program that exploits a bug in the system. Also called a sploit.
Extreme Programming (XP) A development model that takes typical programming practices (such as
code reviews) to extremes (pair programming).
F
façade A design pattern that provides an interface to a (usually complicated) subsystem.
facilitator A person who generally makes everyone else’s life easier and makes the team work
more smoothly.
factory method A method that creates a new instance of a class.
FakeApp A counterfeit program that looks like some other program.
FDD See Feature-Driven Development.
Feature-Driven Development (FDD) An iterative and incremental development model that was
designed to work with large teams. The large teams mean this model requires more roles. It starts with two
phases: develop a model and build a feature list. It then iterates three more phases: plan-by feature,
design-by feature, and build-by feature.
feature list In Feature-Driven Development, a prioritized list of features that the application
should have.
feature team In Feature-Driven Development, when a new feature requires changes to several classes,
the class owners are assembled into a feature team to study and implement the changes.
field In a relational database, a single piece of data in a record. For example, each record in a Students
table would contain a FirstName field. Also called a column.
fifth generation language (5GL) A language where programs solve problems by using rules and
constraints rather than by following an algorithm given to it by a programmer.
firewall Monitors incoming and outgoing network traffic to enforce security rules and scan attachments
for spam and viruses.
first class app A program that occupies much of the screen for long periods at a time, such as a browser
or word processor. Users interact with these apps enough to quickly become advanced users.
first generation language (1GL) Machine code consisting of a big pile of 0s and 1s.
first normal form (1NF) The least normalized level of a table in a relational database. To be in 1NF, the
table should satisfy the following conditions:
1. Each column must have a unique name.
2. The order of the rows and columns doesn’t matter.
3. Each column must have a single data type.
4. No two rows can contain identical values.
5. Each column must contain a single value.
6. Columns cannot contain repeating groups.
fishbone diagram See Ishikawa diagram.
Fishikawa diagram See Ishikawa diagram.
five-second rule The idea that all interactive tasks should complete within five seconds.
flyweight A design pattern used to allow objects to share common data so they can remain relatively
small.
foreign key In a relational database, a set of one or more fields in one table with values that uniquely
define a record in another table. The table containing the foreign key is the child table, and the table that
contains the uniquely identified record is the parent table. See also foreign key constraint.
foreign key constraint When two tables are related by a foreign key, a foreign key constraint requires
that a child record cannot exist unless the corresponding record exists in the parent table. For example, a
StudentAddress record might not be allowed to contain a State value that isn’t defined in the States
lookup table.
formjacking When an attacker inserts malicious code into a copy of a website’s forms.
fourth generation language (4GL) Provides a higher level of abstraction than a 3GL. These tend to be
more specialized, focusing on a particular domain—for example, SQL or MATLAB.
function point metric In function point calculations, a metric used to calculate a project’s function
points, such as the number of inputs and the number of outputs.
function point normalization Dividing a metric by the project’s function points to allow you to
compare projects of different sizes and complexities.
function point value Calculated as a weighted average of the raw FP and the CAV.
functional programming language Defines programs and methods as mathematical functions.
functional prototype A prototype that looks like a finished application (or part of one) but that doesn’t
necessarily work the way the real application will. For example, it could use faked data or predetermined
responses to user actions.
functional requirements Detailed statements of the project’s wanted capabilities. They’re similar to the
user requirements but may also include things that the users won’t see directly, such as interfaces to other
applications.
G
Gantt chart A kind of bar chart that shows a schedule for a collection of related tasks. Bar lengths
indicate task durations. Arrows show the relationships between tasks and their predecessors.
GIGO Garbage in, garbage out.
gradual cutover Deployment technique where you install the new application for some users while
others continue working with the existing system. You test the system for the first users and when everything’s working correctly, you start moving other users to the new system until everyone has been moved.
gray-box test A combination white-box test and black-box test. The tester knows some but not all of
the internals of the method being tested. The partial knowledge lets the tester design some specific tests to
attack the code.
greedy algorithm An algorithm that moves toward the best solution locally at every step. For example,
to reach the top of a mountain at night, you can try always moving uphill. Also called a hill-climbing
algorithm.
green hat A noob hacker who may not understand the consequences of their actions.
grey hat (gray hat, greyhat) Usually similar to white hats but they break into systems without
permission.
H
hacktivist Uses hacking as a form of civil disobedience.
halting problem Given a program and set of inputs, the problem of predicting whether the program
will eventually halt.
helper or servant A design pattern that uses a package of helper methods that can be used by multiple classes.
heuristic An algorithm that gives a good solution for a problem but that doesn’t guarantee to give you
the best solution possible.
high-level language 3GLs, 4GLs, and 5GLs.
hill-climbing algorithm See greedy algorithm.
horizontal prototype A prototype that demonstrates a lot of the application’s features but with
little depth.
human factors engineer Someone who studies human-computer interactions to help design user
interfaces, workflow, and other issues that can improve end-user effectiveness. Also called a user interface designer.
I
IDE See integrated development environment.
idiom An agreed upon convention. For example, a save icon that looks like a floppy disk even though
no one uses floppy disks anymore.
IEEE Institute of Electrical and Electronics Engineers.
IEEE-CS Institute of Electrical and Electronics Engineers, Computer Society.
imperative programming language A language where the program issues commands to the computer
to tell it what to do.
implementation When used by programmers, this term usually means writing the code. When used by
managers, this often means deployment.
implementation requirements Temporary features that are needed to transition to using the new
system but that will be later discarded.
increment The result of a single iteration of an incremental development model. The increment is a fully
tested piece of software suitable for release to the users.
incremental deployment Deployment where you release the new system’s features to the users gradually. First, you install one tool (possibly using staged deployment or gradual cutover to ease the pain). After
the users are used to the new tool, you give them the next tool. You continue until all the tools have
been deployed.
incremental development A development model where you initially provide only some features at full
fidelity. Over time, you add more features (always at full fidelity) until all features have been implemented
at full fidelity.
incremental prototyping A development model where you build a collection of prototypes that
separately demonstrate the finished application’s features. You then combine the prototypes (or at least
their code) to build the finished application.
incremental waterfall model A development model that uses a series of waterfall cascades. Each
cascade ends with the delivery of a usable application called an increment. Also called the multiwaterfall model.
indicator A metric that you can use to predict the project’s future. For example, if the metric “comments
per KLOC” is 3, that may be an indicator that the project will be hard to maintain.
information radiator See big board.
inheritance hierarchy In object-oriented programming, a “family tree” showing inheritance relationships among classes. In a language that doesn’t support multiple inheritance, the relationships form a
hierarchy.
Insider, malicious insider, whistleblower A hacker who has inside information about an organization
that makes hacking easier.
insider threat A threat posed by an employee, former employee, contractor, vendor, or someone else
who has inside knowledge of the business.
installation See deployment.
instance An object created from a class.
instrumentation Code added to a program by a profiler to allow it to track the program’s performance.
integrated development environment (IDE) An environment for building, compiling, and debugging
software. An IDE may include other tools such as source code control, profiling, code editors with syntax
highlighting and auto-completion, and more.
integration In a V-model project, the steps on the right side of the V that work back up to the conceptual top of the application.
integration test A test that verifies that a new piece of code works with the rest of the system. It checks
that the new code can call existing code and that the existing code can call the new code.
interaction diagram In UML, a category of activity diagram that includes sequence diagrams, communication diagrams, timing diagrams, and interaction overview diagrams.
interaction overview diagram In UML, basically an activity diagram where the nodes can be frames
that contain other kinds of diagrams. Those nodes can contain sequence, communication, timing, and
other interaction overview diagrams. That lets you show more detail for nodes that represent complicated tasks.
Internet of Behaviors (IoB) The study of how and why people use technology to purchase things.
Internet of Things (IoT) Networked objects that have sensors, processors, and other technology—for
example, smartwatches, fitness trackers, smart toasters, and medical sensors.
interview puzzles Once incorrectly believed to be useful for identifying people who would make good
programmers. Today these are seldom used for interviews, but they do make interesting puzzles.
invariant A state of the program and its data that should remain unchanged over some period of time.
Often used in assertions.
IoB See Internet of Behaviors.
IoT See Internet of Things.
Ishikawa diagram Named after Kaoru Ishikawa, a diagram that shows possible causes of effects that
you want to study, such as excessive bugs, delays, and other failures in the development process. Also
called fishbone diagrams, Fishikawa diagrams, and cause-and-effect diagrams.
iteration 0 A pseudo-iteration that includes startup tasks that must be performed before the project’s
code development starts, such as planning, initial requirements gathering, and building the development
environment.
iterative development A development model where you initially provide all of the application’s
features at a low fidelity. Over time, you improve the features’ fidelity, occasionally releasing improved
versions of the application until all features have been implemented at full fidelity.
iterator A design pattern that provides a way to access the elements in a collection without exposing the
collection’s underlying details.
J
James Martin RAD A specific RAD development model that uses four phases: requirements planning,
user design, construction, and cutover. The user design and construction phases iterate.
JBGE See just barely good enough.
JIT See just-in-time.
joint code ownership See shared code ownership.
junkware See crapware.
just barely good enough (JBGE) The idea that you should include only the bare minimum of comments and documentation to get the job done. Note that JBGE is JB better than not GE. (Just barely better
than not good enough.)
just-in-time (JIT) An inventory management practice where inventory items are supplied just in time for
use to minimize inventory levels.
K
kanban (production chain) A just-in-time technique that uses kanban cards to indicate when a production station needs more parts. When a station is out of parts (or is running low), a kanban card is sent to a
supply station to request more parts.
kanban (software engineering) An agile methodology where a team member who finishes their
current item takes the next highest priority item from the project’s backlog. Kanban seeks to restrict the
amount of work in progress at any given time.
kanban board A big board. (See big board.) Typically, columns indicate each task’s status. Columns
might be labeled Backlog, Ready, Coding, Testing, Approval, and Done. In some variations, rows indicate
the person assigned to each task.
key In a relational database, a set of one or more fields that uniquely identifies a record.
keylogger Spyware that sends your keystrokes to the attacker.
KLOC Kilo (1,000) lines of code.
knapsack problem A problem where you must fill a knapsack with a fixed size to maximize the value
of the items selected.
knight’s tour problem A problem where you must move a knight so it visits every square on a chess
board without visiting any square twice. In the closed knight’s tour problem, the knight must end so it can
move back to its starting point in the next move.
knowledge base system See rule-based architecture.
L
language guru Someone who is an expert in the programming language, technology, and other
arcane items being used by the team. The other developers call on this person as needed. Also called a
language lawyer.
language lawyer See language guru.
Las Vegas algorithm An algorithm that always either produces a correct result or tells you that it
cannot, but its runtime may be uncertain.
lazy initialization A design pattern technique that delays an object’s creation until the object is needed.
Lean See Lean Software Development.
Lean Software Development (LSD) An agile development methodology that focuses on removing
waste (such as unclear requirements, repetition, and unnecessary meetings) from the development process.
learning system A system that “learns” from training data, usually with little or no human supervision.
Also called machine learning (ML).
leet A “language” where letters are replaced with different letters and numbers that look somewhat
similar. See also elite hacker.
lifeline In a UML sequence diagram, a vertical dashed line that represents an object’s existence.
linear undo The normal “undo the previous action” model.
load test A test that simulates many users all running simultaneously to measure the application’s
performance under stress.
logic bomb A program that takes action when a particular set of circumstances occurs.
logic tier The middle tier in a three-tier architecture. This tier usually contains business logic.
lookup table In a relational database, a table that contains values that are just used as foreign keys.
low-code/no-code (LCNC) Platforms that allow non-programmers to build software.
low-level language 1GLs and 2GLs.
LSD See Lean Software Development.
M
machine learning (ML) See learning system.
magic number A value that just appears in the code with no explanation. For example, it might
represent an error code or database connection status. Use constants and named variables instead of magic
numbers to make the code easier to read and understand.
malvertising See crapware.
malware Short for “malicious software.”
man-in-the-middle (MITM) attack Attack where an attacker intercepts a private communication. The
attacker may simply eavesdrop or may modify messages. (The M can also stand for “monster,” “machine,”
“monkey,” or “meddler.” Also called person-in-the-middle.)
mediator A design pattern that uses an object through which other objects can interact.
member In object-oriented programming, a general name for a class’s properties, methods, and events.
memento A design patterns that uses an object to capture another object’s internal state so it can be
restored to that state later.
metaphor A story about something that the user understands that parallels some feature of a program
to make using that feature easier (for example, the wastebasket/recycle bin).
method In object-oriented programming, a piece of code that makes an object do something.
method prologue A description of a method that includes its purpose, input and output parameters,
return type, possible exceptions (ways the method can fail), and assumptions.
metric A value that you use to study some aspect of a project. A metric can be an attribute (such as the
number of bugs) or a calculated value (such as the number of bugs per line of code). See also attribute and
indicator.
MFA See multifactor authentication.
microservices A type of service-oriented architecture that uses loosely coupled lightweight services.
MITM See man-in-the-middle.
ML See learning system.
model-view-controller (MVC) A design pattern that defines three kinds of classes that work together.
The model class represents the data. The view (or views) displays some sort of view of the model. The
controller lets the user modify the model.
model-view-presenter (MVP) A refinement of the MVP pattern. The model represents the data and
views display a representation of the data as before. The view is also responsible for capturing user events.
The presenter acts as a mediator between the view and the model.
model-view-view/model (MVVM) Somewhat similar to MVP. A model represents the data, a view
displays the data, and the view/model sits in between much as the presenter does in the MVP pattern. The
biggest difference is that the view does not have a direct reference to the view/model. Instead, it forwards
user interface information via some sort of binding such as bound properties or events.
module Groups related classes, methods, or other objects into a single entity.
monolithic architecture A design where a single program does everything.
Monte Carlo algorithm An algorithm that sometimes produces an incorrect result, but usually with a
small probability.
MOSCOW (or MoSCoW) A scale for prioritizing application features. The initials stand for Must,
Should, Could, and Won’t.
multifactor authentication (MFA) A system that uses multiple forms of media such as a password,
dongle, and text message to verify someone’s identity. See also two-factor authentication.
multiple inheritance In object-oriented programming, when a child class inherits from multiple parent
classes. (Most object-oriented languages do not support multiple inheritance.)
multiply recursive algorithm An algorithm that calls itself recursively more than once. See also multiply
recursive algorithm and multiply recursive algorithm.
multitier architecture A design that uses multiple tiers to allow a client to use services provided by a
server. Examples include client/server architectures, two-tier architectures, and three-tier architectures.
multiwaterfall model See incremental waterfall model.
MVC See model-view-controller.
MVVM See model-view-view/model.
N
N-tier architecture See multitier architecture.
nagware See crapware.
narrow AI See weak AI.
natural language processing (NLP) The ability of the computer to understand written or spoken
human language.
navigator In pair programming, the programmer who watches as the driver types. Also called an
observer or pointer.
neural network See artificial neural network.
neuron A small part of a neural network. Also called an artificial neuron.
NIHS See not invented here syndrome.
NLP See natural language processing.
node In a UML deployment diagram, a hardware device on which an artifact is deployed.
nonfunctional prototype A prototype that looks like an application but that doesn’t actually
do anything.
nonfunctional requirements Statements about the quality of an application’s behavior or constraints
on how it produces a wanted result such as the application’s performance, reliability, and security
characteristics.
nonlinear undo Lets you undo and redo actions out of their original order.
noob, newbie, newb, n00b, nub Derogatory terms for a beginner at hacking, gaming, programming,
or anything else.
normalization For metrics, performing some calculation on a metric to account for possible differences
in project size or complexity. Two general approaches are size normalization and function point normalization. (See also size normalization and function point normalization.) In database design, the process of
rearranging tables to put them into standard (normal) forms that prevent anomalies.
not invented here syndrome (NIHS) In programming, the mistake of thinking you need to rewrite a
piece of code just because someone else wrote it and it doesn’t work the way you would have written it.
null object A design pattern that uses a default object in place of a null reference.
O
object An instance of a class.
object composition In object-oriented programming, a technique where an object is composed of other
objects. Sometimes used to simulate multiple inheritance.
object diagram In UML, a diagram that focuses on a particular set of objects and their relationships at
a specific time.
object model A model showing the classes that make up an application, the class details (such as
properties, methods, and events), and interactions among the classes.
object-oriented language A programming language that lets you define classes that you can then use
as blueprints to make instances of those objects.
object pool A group of objects that can be recycled and reused.
observer (design pattern) A design pattern where an object should receive notification when another
object’s state has changed. Also called publish/subscribe.
observer (pair programming) See navigator.
offensive programming The idea that the code immediately flags an error if it receives unexpected
inputs so that you can decide whether they are valid. See also defensive programming.
Open Unified Process (OpenUP) An open-source tool built by the Eclipse Foundation to help in using
the Unified Process development model.
OpenUP See Open Unified Process.
Osborn method A basic brainstorming approach developed by Alex Faickney Osborn.
over refinement In object-oriented programming, a design problem that occurs when you refine a class
hierarchy unnecessarily, making too many classes that make the code complicated and confusing.
P
package diagram In UML, a diagram that describes relationships among the packages that make up a
system. For example, if one package in the system uses features provided by another package, then the
diagram would show the first “importing” the second.
pair programming An Extreme Programming practice where two (or three) programmers work
together at the same computer. The driver or pilot types while the observer, navigator, or pointer watches
and reviews each line of code as it is typed.
parallel programming When multiple processors perform calculations at the same time to
achieve a goal.
parent class A class from which a child class is derived. The child class inherits properties, methods, and
events from the parent class.
parent table See foreign key.
password dongle See dongle.
password manager A program that stores passwords for other programs.
password stuffing See credential stuffing.
Pepsi paradox The phenomenon that people sometimes prefer one thing initially but then grow to like
it less over time. In software engineering, users initially like beginner features but eventually they become
more advanced and prefer advanced features.
perimeter security Security measures such as firewalls that try to prevent an attacker from entering the
system or network from the outside.
person in the middle (PITM) See man-in-the-middle.
PERT Program Evaluation and Review Technique. See PERT chart.
PERT chart A graph that uses nodes (circles or boxes) and links (arrows) to show the precedence
relationships among the tasks in a project.
phishing A contact (such as an email or voicemail) that tries to trick you into thinking it is a legitimate
contact in order to make you do something that you normally wouldn’t, such as clicking a link or revealing passwords.
phreak Someone who hacks telephone networks or networks in general.
pilot See driver.
PITM Person in the middle. See man-in-the-middle.
planning game A game where team members use cards containing user stories and try to see how many
cards they can fit into a release. There are two kinds of planning games: release planning and iteration planning.
planning poker In scrum, a game where developers use card decks based on the Fibonacci numbers to
estimate the amount of work for the project’s tasks. Cards might have numbers ace, 2, 3, 5, 8, and king; or
0, 1, 2, 3, 5, 8, 13, 21, 34, 55, and 89; or 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, and 100. Also called scrum poker.
point of no return The point during a project where the expense of canceling a project is greater than
the expense of moving forward.
point-release A minor application build that isn’t necessarily released to the customers.
pointer See navigator.
polymorphism The ability to treat a child object as if it were actually from a parent class. For example,
it lets you treat a Student object as if it were a Person object because a Student is a type of Person.
potentially shippable increment (PSI) In scrum, the result of a sprint. This is a fully tested application
that could be shipped to the users.
predictive development model A development model where you predict in advance what needs to be
done and then you go out and do it. Also called Big Design Up Front (BDUF).
presentation tier The client tier in a multitier architecture.
procedural programming language An imperative language that lets you group pieces of code into
procedures.
process metric A metric designed to measure your organization’s development process. They are
collected over a long period across many projects and used to fine-tune the software engineering process.
product backlog In scrum, the list of features not yet implemented by the application.
product burndown chart In scrum, a graph showing the amount of work remaining in a whole project
over time. Also called a release burndown chart.
product metric See project metric.
product owner Someone who represents the customers, users, and other stakeholders and for whom the
application is being built. Sometimes called the sponsor.
profiler A program that monitors another program to identify the parts that are slow, that use the most
memory, or that otherwise might be bottlenecks.
programmer An underpaid, overworked person who writes the code and complains about excessive
management and restrictive coding standards.
progressive web apps (PWA) Web-based applications that run on any compliant browser.
project manager Monitors the project’s progress to ensure that work is heading in the right direction at
an acceptable pace. Meets with customers and other stakeholders to verify that the finished product meets
their requirements. If the development model allows changes, the project manager ensures that changes are
made and tracked in an organized manner so they don’t get lost and don’t overwhelm the rest of the team.
project manager/tracker A person who tracks schedules, monitors progress, and generally makes sure
the project stays on track.
project metric Metrics that measure and track the current project to predict future results for
that project.
property In object-oriented programming, an attribute of an object that helps define the object’s
characteristics.
prototype A mockup of some or all of the application to let the developers and customers study an
aspect of the system. Typically, a software prototype is a program that mimics part of the application that
you want to build.
prototype (design pattern) A design pattern where an instance of an object with default properties
filled in is used as a template for other objects.
proxy A design pattern where an object provides a placeholder for another object to control access to
that object.
prune To remove branches from a decision tree to make it smaller and therefore make searching it faster.
pseudocode Text that looks a lot like a programming language but isn’t one. You can use pseudocode
to study how a piece of code would work if you wrote it in an actual programming language such as C#,
Java, or Visual Basic.
PSI See potentially shippable increment.
publish/subscribe See observer (design pattern).
Q
quality manager Someone who ensures the application’s quality. This person tracks bug reports, test
results, and reviews; uses statistical methods to estimate quality; defines the project’s quality procedures
(such as testing and review guidelines); and uses other techniques used to improve quality.
R
race condition In distributed computing, a situation in which multiple processes interfere with each
other when one incorrectly overwrites the results of another.
RAD See rapid application development.
raise In object-oriented programming, an object raises an event to notify the application that something
interesting occurred.
random solution A heuristic that just makes a random selection. Random solutions are often not very
good, but you can sometimes find an acceptable solution by examining many random solutions.
randomized algorithm An algorithm that relies on randomness in some way. See also Monte Carlo
algorithm, Las Vegas algorithm, and Atlantic City algorithm.
ransomware Malicious software that encrypts files and demands payment to unlock the files.
rapid application development (RAD) Development models that emphasize producing code and
deemphasize planning. These models produce code iteratively and incrementally as quickly as possible.
RAD principles include small teams, frequent customer interaction, frequent integration and testing, and
short timeboxed iterations.
Rational Unified Process (RUP) IBM’s version of the Unified Process.
raw FP value In function point calculations, the sum of the function point metrics multiplied by their
complexity factors.
record In a relational database, a single set of values in a table. For example, a particular student’s data
would be contained in a record in the Students table. Also called rows or tuples.
recursive algorithm An algorithm that calls itself. See also recursive algorithm.
red hat Hackers who attack black hats, possibly using illegal means.
refactor The process of rearranging and rewriting code to make it easier to understand, debug,
and maintain.
refinement In object-oriented programming, the process of breaking a parent class into multiple
subclasses to capture some difference between objects in the class.
regression test A test that exercises the entire application to verify that a new piece of code didn’t
break anything.
relational database A database that stores related data in rows and columns in tables.
relatively prime Two integers are relatively prime (or coprime) if they have no common factors other
than 1. For example, 21 = 3 × 7 and 8 = 2 × 2 × 2 are relatively prime because they have no common
factors other than 1. By definition –1 and 1 are relatively prime to every integer, and they are the only
numbers relatively prime to 0.
release burndown chart See product burndown chart.
release manager In Feature-Driven Development, someone who gathers information from the chief
programmers to track the project’s progress.
requirement validation The process of making sure that the requirements say the right things.
requirement verification The process of checking that the finished application actually satisfies the
requirements.
requirements The features that an application must provide to be successful.
responsive design Design that adjusts accordingly to the size of the user’s device.
retrospective meeting In scrum, a meeting after a sprint where the scrum master and the project team
discuss the sprint and ask the following questions: (1) What went well and how can we make that happen
again? (2) What went poorly and how can we avoid that in the future? (3) How can we improve
future sprints?
rootkit Set of programs that provides access to part of the computer.
row See record.
rule-based architecture A design that uses a collection of rules to decide what to do next. These
systems are sometimes called expert systems or knowledge-based systems.
RUP See Rational Unified Process.
S
sashimi A variation on the waterfall model where phases overlap. Also called sashimi waterfall and
waterfall with overlapping phases.
SCA Service Component Architecture.
scrapyard Hypothetical clipboard system that lets you save and restore many items.
scribe Someone who keeps records of requirements, agreements, assumptions, and other important facts
discovered at meetings, particularly at DSDM workshops.
script kiddie, skiddie, skid Derogatory term for someone who breaks into systems by using scripts and
prepackaged tools rather than by “honest” hacking.
scrum See daily scrum.
scrum A development methodology that uses frequent small increments to build an application iteratively and incrementally.
scrum master In scrum, someone who helps the team follow scrum practices, challenges the team to
improve itself, and removes obstacles for the team.
scrum poker See planning poker.
SDLC See software development life cycle.
second generation language (2GL) An assembly language.
second normal form (2NF) The second level of normalization for a table in a relational database. A
table is in 2NF if it satisfies the following conditions:
1. It is in 1NF.
2. All nonkey fields depend on all key fields.
self-organizing team A team that has the flexibility and authority to find its own methods for achieving
its goals. Team members are motivated to take work without waiting for it to be assigned. They take
responsibility for their work and track their own progress.
senior developer A software engineering ninja that other developers can call on when they need help.
sequence diagram In UML, a diagram that shows how objects collaborate in a particular scenario.
This is similar to a communication diagram except a sequence diagram focuses on the sequence of
messages and a communication diagram focuses more on the objects involved in the collaboration.
service A self-contained program that runs on its own and provides some kind of service for its clients.
Service Component Architecture (SCA) A set of specifications for service-oriented architecture defined
by vendors such as IBM and Oracle. See service-oriented architecture.
service-oriented architecture (SOA) A design similar to a component-based architecture except the
pieces are implemented as services.
shared code ownership In Extreme Programming, code ownership is joint so anyone can modify any
piece of code if necessary to make changes or fix bugs. In contrast, in Feature-Driven Development, each
class is owned by a class owner.
shift-left The idea of moving a feature’s design earlier in the project. For example, shift-left security
makes security design start at the beginning of the project.
shift-left security Shift-left applied to security. See also shift-left.
shift-left testing Shift-left applied to testing. See also shift-left.
side effect A non-obvious result of a method call that makes using the method confusing.
singleton A design pattern where an object can have only one instance.
size normalization For metrics, dividing a metric by an indicator of size such as lines of code or days of
work. For example, bugs/KLOC tells you how buggy the code is normalized for the size of the project.
size-oriented normalization See size normalization.
SME Subject matter expert.
smishing SMS phishing.
SMS Short Message Service. (A text message.)
SOA Service-oriented architecture.
soapbox In planning poker, after each hand the people with the highest and lowest estimates are given a
brief soapbox to explain why they feel their estimates are correct.
software development life cycle (SDLC) All the tasks that go into a software engineering project from
start to finish: requirements, design, implementation, and so forth. Also called the application development
life cycle.
spear phishing When a phishing attack is customized for the target to make it more attractive.
spike A quick prototype, design, or piece of code that lets you explore some feature of an application in
depth. Also called a deep dive.
spike solution See spike.
spiral development model A development model that uses a risk-driven approach to decide what
development approach to take for each stage of the project. It uses four phases: planning, risk analysis,
engineering, and evaluation.
sploit See exploit.
sponsor See product owner.
spoofing Sending a communication that pretends to be from someone else. For example, when an email
includes a fake message header.
sprint In scrum, the name given to the timeboxed incremental iterations. Typically, a sprint is 30 days,
although some projects use shorter sprints of one, two, or three weeks.
sprint backlog In scrum, the list of features not yet implemented by a sprint.
sprint burndown chart In scrum, a graph showing the amount of work remaining in a sprint over time.
sprint planning meeting In scrum, a timeboxed (typically a maximum of four hours) meeting before a
sprint begins to decide what features should move from the project backlog into the sprint backlog so that
they will be implemented during the sprint.
sprint review meeting In scrum, after a sprint ends, this is the meeting where the team presents the
potentially shippable increment to the product owner, who verifies that it meets the sprint’s goals.
spyware Malicious software that collects information and sends it to an attacker.
SQL injection When an attacker inserts data into a field to make the program compose an SQL
statement that does something incorrect such as providing unauthorized access.
staged deployment Deployment that begins with building the application in a fully functional staging
environment so you can practice deployment until you’ve worked out all of the kinks.
stakeholder Someone who has a stake in the outcome of the project. Typically, this includes users,
customers (if those are different from users), sponsors, managers, and development team members.
stakeholder requirements These describe the goals of the project from the stakeholders’ point of view.
This term is often used interchangeably with “user requirements.”
stand-up See stand-up meeting.
stand-up meeting In Extreme Programming, a brief (15 minutes or less) daily meeting where team
members say what they did since the last meeting, what they hope to do before the next meeting, and any
problems they foresee in getting that work done.
state An internal representation of an object’s state so the object can act differently when its state
changes. In bug tracking, a bug’s state tracks its progress through the system. Example states include New,
Assigned, Reproduced (or Verified), Cannot Reproduce, Pending, Fixed, Tested, Deferred, Closed,
and Reopened.
state diagram (or state transition diagram) A directed graph where nodes represent states and links
represent transitions between states.
state machine diagram In UML, a diagram that shows the states through which an object passes in
response to various events. States are represented by rounded rectangles. Arrows indicate transitions from
one state to another. Sometimes annotations on the arrows indicate what causes a transition.
state-sponsored hacker Hackers supported by a government to hack rival governments or businesses
in rival nations.
stepwise refinement See top-down design.
story points The number of points assigned to a story by planning poker. See planning poker.
strategy A design pattern where a class encapsulates an algorithm so you can use different algorithms
interchangeably.
structure diagram In UML, a diagram that describes things that will be in the system you are designing.
For example, a class diagram shows relationships among the classes that will be used to represent objects
in the system such as inventory items, customers, and invoices.
subject matter expert (SME) See domain expert.
suicide hacker Someone who causes chaos and disruption without regard to the damage they do or
possible consequences such as jail time.
system administrator See administrator.
system integrator Someone who builds and tests the interfaces between the application and other
applications.
system test An end-to-end run-through of the whole system. A system test exercises every part of the
system to discover as many bugs as possible.
T
table In a relational database, a set of records that all contain the same fields, although each record’s
fields may contain different values. For example, a Student table would contain data about students.
TCO See total cost of ownership.
TDD See test-driven development.
team lead See team leader.
team leader The leader of a programming team, particularly if a large project is broken into separate
teams. Typically, a team leader is a more experienced developer. Also called a team lead.
team member A member of the development team. Depending on the development model, this can
include many different kinds of participants. The team may include customer representatives in addition to
developers.
technical lead Highest-ranking technical person on a project.
technical writer Someone who writes online and printed documentation and training materials.
template A design pattern where a class forms an outline of an algorithm so subclasses can redefine
selected steps.
test-driven development (TDD) A programming technique where you (1) write a test to verify a
feature, (2) verify that the program fails the test, (3) write code to implement the feature, and (4) verify
that the code passes the test.
test-first development (TFD) A programming technique where you write all of the unit tests for a piece
of code before you write the code. You then write all of the code, run the tests, and fix the code if it doesn’t
pass the tests.
tester, test engineer, test designer Someone who earns a salary by breaking your code.
TFD See test-first development.
third generation language (3GL) Works at a much higher level than 1GLs and 2GLs. More machineindependent and much easier for humans to understand. Python, C#, Delphi, etc.
third normal form (3NF) The third level of normalization for a table in a relational database. A table is
in 3NF if it satisfies the following conditions:
1. It is in 2NF.
2. It contains no transitive dependencies.
three-tier architecture A design where a middle tier provides insulation between client and server tiers.
The middle tier can map data between the format provided by the server and the format needed by
the client.
throwaway prototype A prototype that is used to study some aspect of a system and is then discarded.
time bomb A program that takes action at a particular date and time.
timing diagram In UML, a diagram that shows one or more objects’ changes in state over time.
toolsmith Someone who builds tools for use by other developers.
top-down design A design process where you start with a high-level statement of a problem and then
successively break the problem into more detailed and smaller pieces until the pieces are small enough to
implement. Also called stepwise refinement.
total cost of ownership (TCO) The total expected cost of a software application, including development costs, deployment costs, and maintenance costs over the expected lifetime of the application. (Often
maintenance costs account for 75 percent of TCO.)
tracker In XP, someone who monitors the team’s progress and the team members’ progress and calculates metrics.
trainer Someone who trains the application’s end users.
transient app A program that is used infrequently and for short periods of time so users remain relative
beginners.
transitive dependency In a relational database, when a nonkey field’s value depends on another
nonkey field’s value.
trolley problem A series of thought experiments where you must choose between various bad options
such as rerouting a trolley to kill one person instead of five.
tunnel problem A thought experiment where you must choose between running over a child or
crashing into the side of a tunnel and dying.
tuple See record.
twin A design pattern that allows a program to imitate multiple inheritance in programming languages
that do not allow it.
two-factor authentication (2FA) A system that uses two forms of media such as a password and text
message to verify someone’s identity. See also multifactor authentication.
two-tier architecture A design where a client (often the user interface) is separated from the server
(normally the database).
U
UI See user interface.
UML See Unified Modeling Language.
Unified Modeling Language (UML) A collection of diagramming techniques for describing different
aspects of a system.
Unified Process (UP) An iterative and incremental development framework that involves four stages:
inception, elaboration, construction, and transition.
unit test A test that verifies the correctness of a specific piece of code.
UP See Unified Process.
use case A description of a series of interactions between actors. The actors can be users or parts of the
application. A simple template might include a title, main success scenario, and extensions (other variations on the scenario). See also user story.
use case diagram In UML, a diagram that represents a use case. Stick figures represent actors (someone
or something that performs a task) connected to tasks represented by ellipses.
user experience (UX) The user interface plus surrounding interactions to include the user’s whole
perception of the application and its “brand.”
user interface (UI) All of the things that the user sees and does with the application.
user interface designer See human factors engineer.
user requirements These describe how the project will be used by the eventual end users.
user story A short story explaining how the system will let the user do something. See also use case.
UX See user experience.
V
V-model Basically, a waterfall model that’s been bent into a V shape to emphasize that each task on the
left side of the V corresponds to a task on the right side.
VBA See Visual Basic for Applications.
velocity In scrum, the amount of work the team can perform during a sprint, usually measured in story
points per sprint.
version management Managing the versions of items produced by the project such as requirements
documents, designs, and, of course, source code. You should be able to retrieve any earlier version of those
items if necessary. Also called version tracking, change management, and change tracking.
version tracking See version management.
vertical prototype A prototype that has little breadth but great depth.
virtual reality (VR) An immersive three-dimensional environment.
virus A malicious program embedded inside another program that replicates either by copying itself into
another program or by creating a new copy of the program that contains the virus.
vishing A voice phishing attack—for example via voice mail, a robocall, or a human caller.
visionary Someone who has a clear vision about what an application should do.
visitor A design pattern where an object represents an operation on a data structure so you can define
new behaviors without modifying the data structure.
Visual Basic for Applications (VBA) Macro programming language used to automate some Microsoft
programs such as Excel, Word, and PowerPoint.
vulnerability disclosure program A program that allows businesses to report cyberattacks and data
breaches without fear of damaging press, possibly via confidential disclosure.
W
waterfall A predictive development model where each project phase flows into the next.
waterfall with feedback A variation on the waterfall model where each phase is allowed to feed information back to the preceding phase.
weak AI A program that is intended to solve a single problem, such as driving a car or finding target demographics for magazine sales. Also called narrow AI.
web service A service that provides a standardized web-based interface so that it is easy to invoke over the Internet.
whaling Spear phishing aimed at a company executive such as a CEO, CFO, or other CxO.
white-box test A test designed by someone who knows how the code works internally. That person can guess where problems may lie and create tests specifically to look for those problems.
white hat An “ethical” hacker who breaks security for nonmalicious reasons with the target’s permission.
Windows Presentation Foundation (WPF) A Microsoft user interface framework used to create desktop applications.
WIP See work in progress.
work in progress (WIP) The work being done at a given moment, particularly in a kanban project.
working prototype See functional prototype.
workshop facilitator Someone who plans, runs, and encourages participation at workshops, particularly DSDM workshops.
worm A program that tries to copy itself to other computers on a network.
WPF See Windows Presentation Foundation.
X
XP See Extreme Programming.
Z
zero-day (0-day) A vulnerability that is either unknown to security researchers or known but does not yet have a fix.