Glossary
Statements about functionality that, when satisfied, mean the functionality has been satisfactorily implemented.
Agile
A software process model and philosophy for managing and developing software projects. Agile values include individuals and interactions, working software, customer collaboration, and responding to change.
attitude toward risk
(Cognitive facet.) How willing a person is to take chances while using technology (risk-tolerant vs. risk-averse).
business capability
The capacity of a business resource or a combination of resources to generate value for customers by leveraging their environment through a process that involves both tangible and intangible resources. Source: Michell, V. (2011). A focused approach to business capability. In Proceedings of the First International Symposium on Business Modeling and Software Design, 105–113. University of Reading. https://doi.org/10.5220/0004459101050113
class diagrams
In Unified Modeling Language (UML), a visualization of how classes are built in relation to other classes in object-oriented software. Includes properties and methods of individual classes and “has a” and “is a” relationships between classes.
client-server architecture
High-level architecture characterized by one component (the server) responding to requests and providing resources while other components (clients) request those resources.
clients
One or more people or organizations who are requesting the software be made and have decision-making authority about the software (e.g., because they are paying for it or otherwise providing resources).
code decay
Reduction of code quality over time. Can result in decreased maintainability, more bugs, and irretrievable failure.
code smell
Aspect of code indicating the code is of poor quality (e.g., has detriments to readability and maintainability).
cognitive facet value
A position on the spectrum of a cognitive facet. Also called a “cognitive style.”
cognitive facets
Five aspects of users that affect how they solve problems in software: motivations, information processing style, computer self-efficacy, attitude toward risk, learning style.
cognitive style
A person’s preferred way of processing (perceiving, organizing and analyzing) information using cognitive mechanisms and structures. They are assumed to be relatively stable. Whilst cognitive styles can influence a person’s behavior, depending on task demands, other processing strategies may at times be employed – this is because they are only preferences. Source: Armstrong, S.J., Peterson, E.R., & Rayner, S. G. (2012). Understanding and defining cognitive style and learning style: A Delphi study in the context of educational psychology. Educational Studies, 4, 449-455. https://doi.org/10.1080/03055698.2011.643110
communication pipe
Technology and/or approach used for sending and receiving messages between processes.
component
Within a codebase, a unit of the code containing related functionality. Ideally, a component is both replaceable and reusable.
computer self-efficacy
(Cognitive facet.) A person’s confidence in their ability to use technology (low vs. medium vs. high).
constraint
A restriction; what must be done or not done.
contingency
A future event or circumstance that may occur but depends on known and unknown factors. Can be difficult to predict far ahead of time.
coupling
The degree to which one unit of code is dependent on another.
Daily Scrum
In Agile Scrum, a 15-minute meeting during which developers discuss what has been done since the last Daily Scrum, what will be done before the next Daily Scrum, and whether there are any blockers.
Definition of Done (DoD)
A set of acceptance criteria that, once satisfied, means a user story has been satisfactorily implemented.
Eisenhower matrix
A grid for helping decide whether to do, delegate, schedule, or eliminate a task based on its urgency and importance.
encapsulation
In object-oriented programming, (1) combining data and the methods that act upon those data into one unit of code or (2) preventing external direct access to data within a unit of code.
estimation
Figuring out ahead of time how long a task is likely to take.
eventual consistency
Characteristic of software systems where different parts of the system can have less up-to-date information (e.g., state, data) than other parts, but the inconsistencies are temporary.
extensibility
Degree to which software supports adding functionality later.
Extreme Programming (XP)
Agile methodology that prioritizes customer satisfaction and communication, short development cycles, iteration, frequent releases, code review, teamwork, pair programming, required unit testing, and implementing only the functionality that’s needed.
fist of five
A method for gauging and building group consensus that uses a six-level voting system (zero to five fingers).
focus groups
A structured conversation facilitated by a researcher with a small group of prospective users (typically 6-12 individuals). The aim of this session is to gather insights about the participants’ attitudes, opinions, motivations, concerns, and challenges concerning a specific product or topic.
functional requirement
Description of what functionality the software needs to have.
Gantt chart
Horizontal bar chart showing start and end times of activities within a project schedule, along a time line.
GenderMag Method
A method that involves utilizing a specialized cognitive walkthrough and customizable personas (Abi, Pat, and Tim) to identify and address gender-inclusivity issues in software, thus improving its overall gender inclusiveness.
given-when-then
A format for writing an acceptance criterion: Given <context>, when <action>, then <result>. Source: Agile Alliance. (n.d.). What is “given – when – then”? https://www.agilealliance.org/glossary/gwt/
graphical user interface (GUI)
A user interface with interactive graphics, in contrast to a text-based user interface.
ground rules
A set of statements about the team, agreed to by each team member, for avoiding team conflict and dysfunction.
heuristic evaluation
A usability inspection method in which evaluators independently examine a design to ensure it aligns with a predetermined set of heuristics, and then compare their findings. Source: Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Empowering People—CHI ’90. Association for Computing Machinery. https://doi.org/10.1145/97243.97281
high-fidelity prototype
A polished illustration that looks like a finished, publishable user interface design (especially a GUI). Almost always digital.
high-level architecture
Abstract representation of overall code design; covers all parts of the software.
ideal days
The number of days it would take to complete the work if the work could be 100% focused on.
implementation
(Software development life cycle phase.) Using the requirements and design to code the software.
inclusive design
Designing with the goal of increasing usability for traditionally underserved user populations while also increasing usability for mainstream users.
Inclusivity Heuristics
Guidelines for making software inclusive to diverse users.
Increment
In Agile Scrum, a measurable increase in functionality toward completing the Product Goal.
information processing style
(Cognitive facet.) How a person gathers data in relation to acting on those data (comprehensive vs. selective).
inspection method
Any approach in which an evaluator examines a user interface.
integrated development environment (IDE)
Software for developing software.
interaction design
A method of designing technology that focuses on aiding users in comprehending the operations and events occurring within the technology, as well as guiding them on the available actions they can take.
interaction diagram
Visualization of collaboration between different parts of software.
INVEST
Characteristics of good user stories (independent, negotiable, valuable, estimable, small, testable). Source: Wake, B. (2003, August 17). Invest in good stories, and Smart Tasks. XP123 Exploring Extreme Programming. https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
iteration
Verb: Revision. Noun (in Agile): A time-boxed software development cycle.
iteration plan
In Agile, establishing what will be done during a development cycle.
JavaScript Object Notation (JSON)
A lightweight data-interchange format that is easy for humans to read and write. Source: JSON.org. (n.d.). Introducing JSON. https://www.json.org/json-en.html
learning style
(Cognitive facet.) How a person prefers to move through software (by tinkering vs. by mindful tinkering vs. by process).
low-fidelity prototype
A rough sketch of a user interface design (especially a GUI). Can be hand-drawn or digital.
maintenance
Development activities that improve software but that are unrelated to implementing new features (e.g., correcting bugs, improving organization of code, and the like).
managerial skill mix (MSM)
Three categories of skills used by managers: (1) interpersonal, (2) technical, (3) administrative/conceptual. Source: Badawy, M. K. (1995). Developing managerial skills in engineers and scientists: Succeeding as a technical manager. Van Nostrand Reinhold.
medium-fidelity prototype
A careful and detailed illustration of a user interface design (especially a GUI). Can be hand-drawn, but digital is more common.
method
A preestablished way of achieving a specific outcome.
microservices architecture
High-level architecture characterized by multiple independent components that each run in their own process and communicate between one another without direct access.
minimum viable product (MVP)
A cost-effective and efficient approach that allows for improved evaluation of potential user interest in a product before it is fully developed. Source: Olsen, D. (2015). The lean product playbook: How to innovate with minimum viable products and rapid customer feedback. Wiley.
mitigation plan
What will be done if a contingency happens.
monolith architecture
High-level architecture characterized by being in one or few pieces; cannot be easily divided into components that run separately and are independently useful.
motivations
(Cognitive facet.) What keeps someone using technology (task completion vs. tech interest).
nonfunctional requirement
Description of how well software is expected to perform or what constraints or limitations it must respect.
pairwise comparison
A process in which entities are compared in order to determine which is preferred.
paper prototype
A manually created drawing utilized to convey a prospective user interface design that is intended for implementation, particularly a design focused on graphical user interface.
participant
In a Unified Modeling Language sequence diagram, the columns. They can represent objects, users, or other entities involved in a program’s execution.
persona
Fictitious character created to represent specific user subsets within a target audience. They are commonly used in marketing and user interface design to aid in the concentration on particular groups of users and customers.
planning fallacy
An optimism bias in which predictions regarding the time required to complete a future task tend to underestimate the actual time needed.
planning poker
In Agile, a consensus-based method of assigning estimates to a task that involves individuals on a team each making their own estimate privately, then sharing with the team, discussing, and re-estimating as needed.
prioritization
Deciding which units of work to complete before others.
Product Backlog
In Agile Scrum, an ordered list of all that is known to be needed to improve a product.
Product Owner
In Agile Scrum, the person who is responsible for guiding the Scrum Team on making the most valuable software possible.
project management
The process of planning and executing a project while balancing the time, cost, and scope constraints.
project management system
Software for planning, organizing, and otherwise carrying out a project.
project network diagram
Graph showing the order in which a project’s activities are to be completed.
project priority matrix
A 3 × 3 grid for documenting how to respond when there are potential changes to a project’s time, cost, or scope. Options include allowing only positive change (constrain), allowing negative change (accept), or seeking positive change (enhance).
pseudocode
Fake code. Pseudocode looks like code but doesn’t follow the rules of a particular programming language. Used to communicate programming concepts.
quality attribute
A characteristic of software used to describe how good it is.
RACI matrix
In project management, a chart for defining which roles are responsible (R) and accountable (A) for a task or deliverable, and which roles should be consulted (C) or informed (I) about the status of the task or deliverable.
refactoring
Improving code design without changing what the code does.
release plan
What will be completed for a specific software release and when the release will occur.
requirement
A rule the software must conform to, including what the software must do, how well it must do what it does, or the software’s limitations or constraints.
requirements elicitation
The process of gathering requirements from project stakeholders.
requirements specification
Converting stakeholder requests into written requirements.
risk
Estimated probability of a negative contingency given known and unknown factors.
risk mitigation
An action taken in order to avoid a contingency.
scheduling
Deciding when project activities are to be completed, how long they will take, and what resources are needed to complete them.
scope
The boundaries and deliverables of a project.
Scrum
An Agile framework designed for the development and maintenance of complex software.
Scrum board
A way to organize and visualize tasks or work as cards on a board. The board has columns for different categories, and each card is placed within a column. A Scrum board could be a physical bulletin board with sticky notes or index cards. It is also a common feature of task management software.
Scrum Master
In Agile Scrum, the person who is responsible for making sure the Scrum Team is following Scrum.
sequence diagram
In Unified Modeling Language, an interaction diagram showing how different participants (e.g., users, software components, classes, etc.) collaborate during a single use case.
service
A unit of software that receives and fulfills requests.
software architecture
Code design. Can be shown at different levels of abstraction and detail.
software development life cycle (SDLC)
Phases through which a software’s development proceeds: requirements, design, implementation, testing, maintenance.
software engineering
Systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software. Source: International Organization for Standardization, International Electrotechnical Commission, Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering — Vocabulary (ISO/IEC/IEEE Standard No. 24765:2017). https://www.iso.org/standard/71952.html
software process model
A philosophy and/or set of approaches for software development and/or software project management.
software requirements specification (SRS)
A document that contains software requirements.
spike
A quick and to-the-point investigation for gathering information to help the team answer a question or choose a development path.
Sprint
In Agile Scrum, a development period (a month or less).
Sprint Backlog
In Agile Scrum, the set of activities to be completed during a Sprint (from Product Backlog), the associated Sprint Goal, and a plan for completing the activities.
Sprint Goal
In Agile Scrum, the overall objective of the Sprint.
Sprint Planning
In Agile Scrum, the activity of decided what work will be done during the Sprint.
Sprint Retrospective
In Agile Scrum, a meeting during which the Scrum Team discusses how the last Sprint went in terms of individuals, interactions, processes, tools, and the Sprint Definition of Done.
Sprint Review
In Agile Scrum, a meeting during which the Scrum Team and other stakeholders discuss what happened during the Sprint and what to do during future Sprints.
stakeholders
Anyone who is or will be affected by the software or its development (e.g., clients, companies, users, developers, managers, politicians, and so on).
story points
A method for estimating an activity based on its size relative to other activities. Scale established by team.
sustainability
Degree to which software can continue to function over time (e.g., measured in time and how well the software is functioning).
task management
The collection, assignment, sharing, tracking, and scheduling of tasks. Source: Gil, Y., Groth, P., & Ratnakar, V. (2009). Leveraging social networking sites to acquire rich task structure. In Proceedings of the Workshop on User-Contributed Knowledge and Artificial Intelligence: An Evolving Synergy (WikiAI).
task management system
Software for planning and organizing project activities.
tech stack
The set of programming languages, frameworks, and other technologies chosen or needed for implementing a piece of software.
technical debt
Time and resources you (or someone else) will need to spend on modifying your software in the future because of the poor decisions you’re making in the present.
think-aloud protocol
A feedback-gathering method to assess the usability of a design, wherein a test user verbalizes their thoughts and impressions while interacting with the design.
triple constraint
In project management, the three limiting factors that govern project execution: time, cost, and scope. Scope includes quality. Cost includes spending money and resources.
Tuckman’s model of team development
A five-stage model of how a team develops over time: (1) forming, (2) storming, (3) norming, (4) performing, (5) adjourning.
Unified Modeling Language (UML)
A set of notation and methods for describing and designing software.
usability testing
The act of observing individuals as they attempt to interact with your software.
use case
A formal agreement outlining the expected behavior of a system.
user acceptance testing (UAT)
Formally testing software with end users to check not only whether it performs as expected but also whether end users will use it. Typically performed before the software is released.
user interface (UI)
What a user interacts with to operate a system (e.g., a graphical user interface, a command-line interface, a virtual or augmented reality interface, and the like).
user story
A concise and straightforward explanation of a feature presented from the viewpoint of the individual seeking the new functionality, typically a user or customer of the system.
validation
Confirming that software meets users’ needs (“Did we build the right software?”).
velocity
In Agile, a measure of how much work is being completed.
verification
Confirming that software satisfied its requirements (“Did we build the software right?”).
Waterfall
Way of going about software development and management that is characterized by extensive planning, comprehensive documentation, and moving linearly through stages of the software development life cycle (SDLC).
