{"id":82,"date":"2023-09-12T23:47:06","date_gmt":"2023-09-12T23:47:06","guid":{"rendered":"https:\/\/libraryresources.nse.org.ng\/setextbook\/back-matter\/glossary\/"},"modified":"2023-09-12T23:47:06","modified_gmt":"2023-09-12T23:47:06","slug":"glossary","status":"publish","type":"back-matter","link":"https:\/\/libraryresources.nse.org.ng\/setextbook\/back-matter\/glossary\/","title":{"raw":"Glossary","rendered":"Glossary"},"content":{"raw":"

Glossary<\/h2>\n
\n
\nacceptance criteria\n<\/strong>Statements about functionality that, when satisfied, mean the functionality has been satisfactorily implemented.\n\nAgile\n<\/strong>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.\n\nattitude toward risk\n<\/strong>(Cognitive facet.) How willing a person is to take chances while using technology (risk-tolerant vs. risk-averse).\n\nbusiness capability\n<\/strong>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.\u00a0Source<\/em>: Michell, V. (2011). A focused approach to business capability. In\u00a0Proceedings of the First International Symposium on Business Modeling and Software Design<\/em>, 105\u2013113. University of Reading.\u00a0https:\/\/doi.org\/10.5220\/0004459101050113<\/a>\n\nclass diagrams\n<\/strong>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 \u201chas a\u201d and \u201cis a\u201d relationships between classes.\n\nclient-server architecture\n<\/strong>High-level architecture characterized by one component (the server) responding to requests and providing resources while other components (clients) request those resources.\n\nclients\n<\/strong>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).\n\ncode decay\n<\/strong>Reduction of code quality over time. Can result in decreased maintainability, more bugs, and irretrievable failure.\n\ncode smell\n<\/strong>Aspect of code indicating the code is of poor quality (e.g., has detriments to readability and maintainability).\n\ncognitive facet value\n<\/strong>A position on the spectrum of a cognitive facet. Also called a \u201ccognitive style.\u201d\n\ncognitive facets\n<\/strong>Five aspects of users that affect how they solve problems in software: motivations, information processing style, computer self-efficacy, attitude toward risk, learning style.\n\ncognitive style\n<\/strong>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 \u2013 this is because they are only preferences.\u00a0Source<\/em>: 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.\u00a0Educational Studies, 4<\/em>, 449-455.\u00a0https:\/\/doi.org\/10.1080\/03055698.2011.643110<\/a>\n\ncommunication pipe\n<\/strong>Technology and\/or approach used for sending and receiving messages between processes.\n\ncomponent\n<\/strong>Within a codebase, a unit of the code containing related functionality. Ideally, a component is both replaceable and reusable.\n\ncomputer self-efficacy\n<\/strong>(Cognitive facet.) A person\u2019s confidence in their ability to use technology (low vs. medium vs. high).\n\nconstraint\n<\/strong>A restriction; what must be done or not done.\n\ncontingency\n<\/strong>A future event or circumstance that may occur but depends on known and unknown factors. Can be difficult to predict far ahead of time.\n\ncoupling\n<\/strong>The degree to which one unit of code is dependent on another.\n\nDaily Scrum\n<\/strong>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.\n\nDefinition of Done (DoD)\n<\/strong>A set of acceptance criteria that, once satisfied, means a user story has been satisfactorily implemented.\n\nEisenhower matrix\n<\/strong>A grid for helping decide whether to do, delegate, schedule, or eliminate a task based on its urgency and importance.\n\nencapsulation\n<\/strong>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.\n\nestimation\n<\/strong>Figuring out ahead of time how long a task is likely to take.\n\neventual consistency\n<\/strong>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.\n\nextensibility\n<\/strong>Degree to which software supports adding functionality later.\n\nExtreme Programming (XP)\n<\/strong>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\u2019s needed.\n\nfist of five\n<\/strong>A method for gauging and building group consensus that uses a six-level voting system (zero to five fingers).\n\nfocus groups\n<\/strong>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\u2019 attitudes, opinions, motivations, concerns, and challenges concerning a specific product or topic.\n\nfunctional requirement\n<\/strong>Description of what functionality the software needs to have.\n\nGantt chart\n<\/strong>Horizontal bar chart showing start and end times of activities within a project schedule, along a time line.\n\nGenderMag Method\n<\/strong>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.\n\ngiven-when-then\n<\/strong>A format for writing an acceptance criterion: Given <context>, when <action>, then <result>.\u00a0Source<\/em>: Agile Alliance. (n.d.).\u00a0What is \u201cgiven - when - then\u201d?<\/em>\u00a0https:\/\/www.agilealliance.org\/glossary\/gwt\/<\/a>\n\ngraphical user interface (GUI)\n<\/strong>A user interface with interactive graphics, in contrast to a text-based user interface.\n\nground rules\n<\/strong>A set of statements about the team, agreed to by each team member, for avoiding team conflict and dysfunction.\n\nheuristic evaluation\n<\/strong>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<\/em>: Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces. In\u00a0Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Empowering People\u2014CHI \u201990<\/em>. Association for Computing Machinery.\u00a0https:\/\/doi.org\/10.1145\/97243.97281<\/a>\n\nhigh-fidelity prototype\n<\/strong>A polished illustration that looks like a finished, publishable user interface design (especially a GUI). Almost always digital.\n\nhigh-level architecture\n<\/strong>Abstract representation of overall code design; covers all parts of the software.\n\nideal days\n<\/strong>The number of days it would take to complete the work if the work could be 100% focused on.\n\nimplementation\n<\/strong>(Software development life cycle phase.) Using the requirements and design to code the software.\n\ninclusive design\n<\/strong>Designing with the goal of increasing usability for traditionally underserved user populations while also increasing usability for mainstream users.\n\nInclusivity Heuristics\n<\/strong>Guidelines for making software inclusive to diverse users.\n\nIncrement\n<\/strong>In Agile Scrum, a measurable increase in functionality toward completing the Product Goal.\n\ninformation processing style\n<\/strong>(Cognitive facet.) How a person gathers data in relation to acting on those data (comprehensive vs. selective).\n\ninspection method\n<\/strong>Any approach in which an evaluator examines a user interface.\n\nintegrated development environment (IDE)\n<\/strong>Software for developing software.\n\ninteraction design\n<\/strong>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.\n\ninteraction diagram\n<\/strong>Visualization of collaboration between different parts of software.\n\nINVEST\n<\/strong>Characteristics of good user stories (independent, negotiable, valuable, estimable, small, testable). Source<\/em>: Wake, B. (2003, August 17).\u00a0Invest in good stories, and Smart Tasks<\/em>. XP123 Exploring Extreme Programming.\u00a0https:\/\/xp123.com\/articles\/invest-in-good-stories-and-smart-tasks\/<\/a>\n\niteration\n<\/strong>Verb: Revision. Noun (in Agile): A time-boxed software development cycle.\n\niteration plan\n<\/strong>In Agile, establishing what will be done during a development cycle.\n\nJavaScript Object Notation (JSON)\n<\/strong>A lightweight data-interchange format that is easy for humans to read and write.\u00a0Source<\/em>: JSON.org. (n.d.).\u00a0Introducing JSON<\/em>.\u00a0https:\/\/www.json.org\/json-en.html<\/a>\n\nlearning style\n<\/strong>(Cognitive facet.) How a person prefers to move through software (by tinkering vs. by mindful tinkering vs. by process).\n\nlow-fidelity prototype\n<\/strong>A rough sketch of a user interface design (especially a GUI). Can be hand-drawn or digital.\n\nmaintenance\n<\/strong>Development activities that improve software but that are unrelated to implementing new features (e.g., correcting bugs, improving organization of code, and the like).\n\nmanagerial skill mix (MSM)\n<\/strong>Three categories of skills used by managers: (1) interpersonal, (2) technical, (3) administrative\/conceptual. Source<\/em>: Badawy, M. K. (1995).\u00a0Developing managerial skills in engineers and scientists: Succeeding as a technical manager<\/em>. Van Nostrand Reinhold.\n\nmedium-fidelity prototype\n<\/strong>A careful and detailed illustration of a user interface design (especially a GUI). Can be hand-drawn, but digital is more common.\n\nmethod\n<\/strong>A preestablished way of achieving a specific outcome.\n\nmicroservices architecture\n<\/strong>High-level architecture characterized by multiple independent components that each run in their own process and communicate between one another without direct access.\n\nminimum viable product (MVP)\n<\/strong>A cost-effective and efficient approach that allows for improved evaluation of potential user interest in a product before it is fully developed. Source<\/em>: Olsen, D. (2015).\u00a0The lean product playbook: How to innovate with minimum viable products and rapid customer feedback<\/em>. Wiley.\n\nmitigation plan\n<\/strong>What will be done if a contingency happens.\n\nmonolith architecture\n<\/strong>High-level architecture characterized by being in one or few pieces; cannot be easily divided into components that run separately and are independently useful.\n\nmotivations\n<\/strong>(Cognitive facet.) What keeps someone using technology (task completion vs. tech interest).\n\nnonfunctional requirement\n<\/strong>Description of how well software is expected to perform or what constraints or limitations it must respect.\n\npairwise comparison\n<\/strong>A process in which entities are compared in order to determine which is preferred.\n\npaper prototype\n<\/strong>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.\n\nparticipant\n<\/strong>In a Unified Modeling Language sequence diagram, the columns. They can represent objects, users, or other entities involved in a program\u2019s execution.\n\npersona\n<\/strong>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.\n\nplanning fallacy\n<\/strong>An optimism bias in which predictions regarding the time required to complete a future task tend to underestimate the actual time needed.\n\nplanning poker\n<\/strong>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.\n\nprioritization\n<\/strong>Deciding which units of work to complete before others.\n\nProduct Backlog\n<\/strong>In Agile Scrum, an ordered list of all that is known to be needed to improve a product.\n\nProduct Owner\n<\/strong>In Agile Scrum, the person who is responsible for guiding the Scrum Team on making the most valuable software possible.\n\nproject management\n<\/strong>The process of planning and executing a project while balancing the time, cost, and scope constraints.\n\nproject management system\n<\/strong>Software for planning, organizing, and otherwise carrying out a project.\n\nproject network diagram\n<\/strong>Graph showing the order in which a project\u2019s activities are to be completed.\n\nproject priority matrix\n<\/strong>A 3 \u00d7 3 grid for documenting how to respond when there are potential changes to a project\u2019s time, cost, or scope. Options include allowing only positive change (constrain), allowing negative change (accept), or seeking positive change (enhance).\n\npseudocode\n<\/strong>Fake code. Pseudocode looks like code but doesn\u2019t follow the rules of a particular programming language. Used to communicate programming concepts.\n\nquality attribute\n<\/strong>A characteristic of software used to describe how good it is.\n\nRACI matrix\n<\/strong>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.\n\nrefactoring\n<\/strong>Improving code design without changing what the code does.\n\nrelease plan\n<\/strong>What will be completed for a specific software release and when the release will occur.\n\nrequirement\n<\/strong>A rule the software must conform to, including what the software must do, how well it must do what it does, or the software\u2019s limitations or constraints.\n\nrequirements elicitation\n<\/strong>The process of gathering requirements from project stakeholders.\n\nrequirements specification\n<\/strong>Converting stakeholder requests into written requirements.\n\nrisk\n<\/strong>Estimated probability of a negative contingency given known and unknown factors.\n\nrisk mitigation\n<\/strong>An action taken in order to avoid a contingency.\n\nscheduling\n<\/strong>Deciding when project activities are to be completed, how long they will take, and what resources are needed to complete them.\n\nscope\n<\/strong>The boundaries and deliverables of a project.\n\nScrum\n<\/strong>An Agile framework designed for the development and maintenance of complex software.\n\nScrum board\n<\/strong>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.\n\nScrum Master\n<\/strong>In Agile Scrum, the person who is responsible for making sure the Scrum Team is following Scrum.\n\nsequence diagram\n<\/strong>In Unified Modeling Language, an interaction diagram showing how different participants (e.g., users, software components, classes, etc.) collaborate during a single use case.\n\nservice\n<\/strong>A unit of software that receives and fulfills requests.\n\nsoftware architecture\n<\/strong>Code design. Can be shown at different levels of abstraction and detail.\n\nsoftware development life cycle (SDLC)\n<\/strong>Phases through which a software\u2019s development proceeds: requirements, design, implementation, testing, maintenance.\n\nsoftware engineering\n<\/strong>Systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software. Source<\/em>: International Organization for Standardization, International Electrotechnical Commission, Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering \u2014 Vocabulary<\/em> (ISO\/IEC\/IEEE Standard No. 24765:2017). https:\/\/www.iso.org\/standard\/71952.html<\/a>\n\nsoftware process model\n<\/strong>A philosophy and\/or set of approaches for software development and\/or software project management.\n\nsoftware requirements specification (SRS)\n<\/strong>A document that contains software requirements.\n\nspike\n<\/strong>A quick and to-the-point investigation for gathering information to help the team answer a question or choose a development path.\n\nSprint\n<\/strong>In Agile Scrum, a development period (a month or less).\n\nSprint Backlog\n<\/strong>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.\n\nSprint Goal\n<\/strong>In Agile Scrum, the overall objective of the Sprint.\n\nSprint Planning\n<\/strong>In Agile Scrum, the activity of decided what work will be done during the Sprint.\n\nSprint Retrospective\n<\/strong>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.\n\nSprint Review\n<\/strong>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.\n\nstakeholders\n<\/strong>Anyone who is or will be affected by the software or its development (e.g., clients, companies, users, developers, managers, politicians, and so on).\n\nstory points\n<\/strong>A method for estimating an activity based on its size relative to other activities. Scale established by team.\n\nsustainability\n<\/strong>Degree to which software can continue to function over time (e.g., measured in time and how well the software is functioning).\n\ntask management\n<\/strong>The collection, assignment, sharing, tracking, and scheduling of tasks.\u00a0Source<\/em>: Gil, Y., Groth, P., & Ratnakar, V. (2009). Leveraging social networking sites to acquire rich task structure. In\u00a0Proceedings of the Workshop on User-Contributed Knowledge and Artificial Intelligence: An Evolving Synergy (WikiAI)<\/em>.\n\ntask management system\n<\/strong>Software for planning and organizing project activities.\n\ntech stack\n<\/strong>The set of programming languages, frameworks, and other technologies chosen or needed for implementing a piece of software.\n\ntechnical debt\n<\/strong>Time and resources you (or someone else) will need to spend on modifying your software in the future because of the poor decisions you\u2019re making in the present.\n\nthink-aloud protocol\n<\/strong>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.\n\ntriple constraint\n<\/strong>In project management, the three limiting factors that govern project execution: time, cost, and scope. Scope includes quality. Cost includes spending money and resources.\n\nTuckman\u2019s model of team development\n<\/strong>A five-stage model of how a team develops over time: (1) forming, (2) storming, (3) norming, (4) performing, (5) adjourning.\n\nUnified Modeling Language (UML)\n<\/strong>A set of notation and methods for describing and designing software.\n\nusability testing\n<\/strong>The act of observing individuals as they attempt to interact with your software.\n\nuse case\n<\/strong>A formal agreement outlining the expected behavior of a system.\n\nuser acceptance testing (UAT)\n<\/strong>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.\n\nuser interface (UI)\n<\/strong>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).\n\nuser story\n<\/strong>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.\n\nvalidation\n<\/strong>Confirming that software meets users\u2019 needs (\u201cDid we build the right software?\u201d).\n\nvelocity\n<\/strong>In Agile, a measure of how much work is being completed.\n\nverification\n<\/strong>Confirming that software satisfied its requirements (\u201cDid we build the software right?\u201d).\n\nWaterfall\n<\/strong>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).\n\n<\/div>\n<\/div>","rendered":"

Glossary<\/h2>\n
\n
\nacceptance criteria
\n<\/strong>Statements about functionality that, when satisfied, mean the functionality has been satisfactorily implemented.<\/p>\n

Agile
\n<\/strong>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.<\/p>\n

attitude toward risk
\n<\/strong>(Cognitive facet.) How willing a person is to take chances while using technology (risk-tolerant vs. risk-averse).<\/p>\n

business capability
\n<\/strong>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.\u00a0Source<\/em>: Michell, V. (2011). A focused approach to business capability. In\u00a0Proceedings of the First International Symposium on Business Modeling and Software Design<\/em>, 105\u2013113. University of Reading.\u00a0https:\/\/doi.org\/10.5220\/0004459101050113<\/a><\/p>\n

class diagrams
\n<\/strong>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 \u201chas a\u201d and \u201cis a\u201d relationships between classes.<\/p>\n

client-server architecture
\n<\/strong>High-level architecture characterized by one component (the server) responding to requests and providing resources while other components (clients) request those resources.<\/p>\n

clients
\n<\/strong>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).<\/p>\n

code decay
\n<\/strong>Reduction of code quality over time. Can result in decreased maintainability, more bugs, and irretrievable failure.<\/p>\n

code smell
\n<\/strong>Aspect of code indicating the code is of poor quality (e.g., has detriments to readability and maintainability).<\/p>\n

cognitive facet value
\n<\/strong>A position on the spectrum of a cognitive facet. Also called a \u201ccognitive style.\u201d<\/p>\n

cognitive facets
\n<\/strong>Five aspects of users that affect how they solve problems in software: motivations, information processing style, computer self-efficacy, attitude toward risk, learning style.<\/p>\n

cognitive style
\n<\/strong>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 \u2013 this is because they are only preferences.\u00a0Source<\/em>: 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.\u00a0Educational Studies, 4<\/em>, 449-455.\u00a0https:\/\/doi.org\/10.1080\/03055698.2011.643110<\/a><\/p>\n

communication pipe
\n<\/strong>Technology and\/or approach used for sending and receiving messages between processes.<\/p>\n

component
\n<\/strong>Within a codebase, a unit of the code containing related functionality. Ideally, a component is both replaceable and reusable.<\/p>\n

computer self-efficacy
\n<\/strong>(Cognitive facet.) A person\u2019s confidence in their ability to use technology (low vs. medium vs. high).<\/p>\n

constraint
\n<\/strong>A restriction; what must be done or not done.<\/p>\n

contingency
\n<\/strong>A future event or circumstance that may occur but depends on known and unknown factors. Can be difficult to predict far ahead of time.<\/p>\n

coupling
\n<\/strong>The degree to which one unit of code is dependent on another.<\/p>\n

Daily Scrum
\n<\/strong>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.<\/p>\n

Definition of Done (DoD)
\n<\/strong>A set of acceptance criteria that, once satisfied, means a user story has been satisfactorily implemented.<\/p>\n

Eisenhower matrix
\n<\/strong>A grid for helping decide whether to do, delegate, schedule, or eliminate a task based on its urgency and importance.<\/p>\n

encapsulation
\n<\/strong>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.<\/p>\n

estimation
\n<\/strong>Figuring out ahead of time how long a task is likely to take.<\/p>\n

eventual consistency
\n<\/strong>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.<\/p>\n

extensibility
\n<\/strong>Degree to which software supports adding functionality later.<\/p>\n

Extreme Programming (XP)
\n<\/strong>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\u2019s needed.<\/p>\n

fist of five
\n<\/strong>A method for gauging and building group consensus that uses a six-level voting system (zero to five fingers).<\/p>\n

focus groups
\n<\/strong>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\u2019 attitudes, opinions, motivations, concerns, and challenges concerning a specific product or topic.<\/p>\n

functional requirement
\n<\/strong>Description of what functionality the software needs to have.<\/p>\n

Gantt chart
\n<\/strong>Horizontal bar chart showing start and end times of activities within a project schedule, along a time line.<\/p>\n

GenderMag Method
\n<\/strong>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.<\/p>\n

given-when-then
\n<\/strong>A format for writing an acceptance criterion: Given <context>, when <action>, then <result>.\u00a0Source<\/em>: Agile Alliance. (n.d.).\u00a0What is \u201cgiven – when – then\u201d?<\/em>\u00a0https:\/\/www.agilealliance.org\/glossary\/gwt\/<\/a><\/p>\n

graphical user interface (GUI)
\n<\/strong>A user interface with interactive graphics, in contrast to a text-based user interface.<\/p>\n

ground rules
\n<\/strong>A set of statements about the team, agreed to by each team member, for avoiding team conflict and dysfunction.<\/p>\n

heuristic evaluation
\n<\/strong>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<\/em>: Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces. In\u00a0Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Empowering People\u2014CHI \u201990<\/em>. Association for Computing Machinery.\u00a0https:\/\/doi.org\/10.1145\/97243.97281<\/a><\/p>\n

high-fidelity prototype
\n<\/strong>A polished illustration that looks like a finished, publishable user interface design (especially a GUI). Almost always digital.<\/p>\n

high-level architecture
\n<\/strong>Abstract representation of overall code design; covers all parts of the software.<\/p>\n

ideal days
\n<\/strong>The number of days it would take to complete the work if the work could be 100% focused on.<\/p>\n

implementation
\n<\/strong>(Software development life cycle phase.) Using the requirements and design to code the software.<\/p>\n

inclusive design
\n<\/strong>Designing with the goal of increasing usability for traditionally underserved user populations while also increasing usability for mainstream users.<\/p>\n

Inclusivity Heuristics
\n<\/strong>Guidelines for making software inclusive to diverse users.<\/p>\n

Increment
\n<\/strong>In Agile Scrum, a measurable increase in functionality toward completing the Product Goal.<\/p>\n

information processing style
\n<\/strong>(Cognitive facet.) How a person gathers data in relation to acting on those data (comprehensive vs. selective).<\/p>\n

inspection method
\n<\/strong>Any approach in which an evaluator examines a user interface.<\/p>\n

integrated development environment (IDE)
\n<\/strong>Software for developing software.<\/p>\n

interaction design
\n<\/strong>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.<\/p>\n

interaction diagram
\n<\/strong>Visualization of collaboration between different parts of software.<\/p>\n

INVEST
\n<\/strong>Characteristics of good user stories (independent, negotiable, valuable, estimable, small, testable). Source<\/em>: Wake, B. (2003, August 17).\u00a0Invest in good stories, and Smart Tasks<\/em>. XP123 Exploring Extreme Programming.\u00a0https:\/\/xp123.com\/articles\/invest-in-good-stories-and-smart-tasks\/<\/a><\/p>\n

iteration
\n<\/strong>Verb: Revision. Noun (in Agile): A time-boxed software development cycle.<\/p>\n

iteration plan
\n<\/strong>In Agile, establishing what will be done during a development cycle.<\/p>\n

JavaScript Object Notation (JSON)
\n<\/strong>A lightweight data-interchange format that is easy for humans to read and write.\u00a0Source<\/em>: JSON.org. (n.d.).\u00a0Introducing JSON<\/em>.\u00a0https:\/\/www.json.org\/json-en.html<\/a><\/p>\n

learning style
\n<\/strong>(Cognitive facet.) How a person prefers to move through software (by tinkering vs. by mindful tinkering vs. by process).<\/p>\n

low-fidelity prototype
\n<\/strong>A rough sketch of a user interface design (especially a GUI). Can be hand-drawn or digital.<\/p>\n

maintenance
\n<\/strong>Development activities that improve software but that are unrelated to implementing new features (e.g., correcting bugs, improving organization of code, and the like).<\/p>\n

managerial skill mix (MSM)
\n<\/strong>Three categories of skills used by managers: (1) interpersonal, (2) technical, (3) administrative\/conceptual. Source<\/em>: Badawy, M. K. (1995).\u00a0Developing managerial skills in engineers and scientists: Succeeding as a technical manager<\/em>. Van Nostrand Reinhold.<\/p>\n

medium-fidelity prototype
\n<\/strong>A careful and detailed illustration of a user interface design (especially a GUI). Can be hand-drawn, but digital is more common.<\/p>\n

method
\n<\/strong>A preestablished way of achieving a specific outcome.<\/p>\n

microservices architecture
\n<\/strong>High-level architecture characterized by multiple independent components that each run in their own process and communicate between one another without direct access.<\/p>\n

minimum viable product (MVP)
\n<\/strong>A cost-effective and efficient approach that allows for improved evaluation of potential user interest in a product before it is fully developed. Source<\/em>: Olsen, D. (2015).\u00a0The lean product playbook: How to innovate with minimum viable products and rapid customer feedback<\/em>. Wiley.<\/p>\n

mitigation plan
\n<\/strong>What will be done if a contingency happens.<\/p>\n

monolith architecture
\n<\/strong>High-level architecture characterized by being in one or few pieces; cannot be easily divided into components that run separately and are independently useful.<\/p>\n

motivations
\n<\/strong>(Cognitive facet.) What keeps someone using technology (task completion vs. tech interest).<\/p>\n

nonfunctional requirement
\n<\/strong>Description of how well software is expected to perform or what constraints or limitations it must respect.<\/p>\n

pairwise comparison
\n<\/strong>A process in which entities are compared in order to determine which is preferred.<\/p>\n

paper prototype
\n<\/strong>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.<\/p>\n

participant
\n<\/strong>In a Unified Modeling Language sequence diagram, the columns. They can represent objects, users, or other entities involved in a program\u2019s execution.<\/p>\n

persona
\n<\/strong>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.<\/p>\n

planning fallacy
\n<\/strong>An optimism bias in which predictions regarding the time required to complete a future task tend to underestimate the actual time needed.<\/p>\n

planning poker
\n<\/strong>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.<\/p>\n

prioritization
\n<\/strong>Deciding which units of work to complete before others.<\/p>\n

Product Backlog
\n<\/strong>In Agile Scrum, an ordered list of all that is known to be needed to improve a product.<\/p>\n

Product Owner
\n<\/strong>In Agile Scrum, the person who is responsible for guiding the Scrum Team on making the most valuable software possible.<\/p>\n

project management
\n<\/strong>The process of planning and executing a project while balancing the time, cost, and scope constraints.<\/p>\n

project management system
\n<\/strong>Software for planning, organizing, and otherwise carrying out a project.<\/p>\n

project network diagram
\n<\/strong>Graph showing the order in which a project\u2019s activities are to be completed.<\/p>\n

project priority matrix
\n<\/strong>A 3 \u00d7 3 grid for documenting how to respond when there are potential changes to a project\u2019s time, cost, or scope. Options include allowing only positive change (constrain), allowing negative change (accept), or seeking positive change (enhance).<\/p>\n

pseudocode
\n<\/strong>Fake code. Pseudocode looks like code but doesn\u2019t follow the rules of a particular programming language. Used to communicate programming concepts.<\/p>\n

quality attribute
\n<\/strong>A characteristic of software used to describe how good it is.<\/p>\n

RACI matrix
\n<\/strong>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.<\/p>\n

refactoring
\n<\/strong>Improving code design without changing what the code does.<\/p>\n

release plan
\n<\/strong>What will be completed for a specific software release and when the release will occur.<\/p>\n

requirement
\n<\/strong>A rule the software must conform to, including what the software must do, how well it must do what it does, or the software\u2019s limitations or constraints.<\/p>\n

requirements elicitation
\n<\/strong>The process of gathering requirements from project stakeholders.<\/p>\n

requirements specification
\n<\/strong>Converting stakeholder requests into written requirements.<\/p>\n

risk
\n<\/strong>Estimated probability of a negative contingency given known and unknown factors.<\/p>\n

risk mitigation
\n<\/strong>An action taken in order to avoid a contingency.<\/p>\n

scheduling
\n<\/strong>Deciding when project activities are to be completed, how long they will take, and what resources are needed to complete them.<\/p>\n

scope
\n<\/strong>The boundaries and deliverables of a project.<\/p>\n

Scrum
\n<\/strong>An Agile framework designed for the development and maintenance of complex software.<\/p>\n

Scrum board
\n<\/strong>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.<\/p>\n

Scrum Master
\n<\/strong>In Agile Scrum, the person who is responsible for making sure the Scrum Team is following Scrum.<\/p>\n

sequence diagram
\n<\/strong>In Unified Modeling Language, an interaction diagram showing how different participants (e.g., users, software components, classes, etc.) collaborate during a single use case.<\/p>\n

service
\n<\/strong>A unit of software that receives and fulfills requests.<\/p>\n

software architecture
\n<\/strong>Code design. Can be shown at different levels of abstraction and detail.<\/p>\n

software development life cycle (SDLC)
\n<\/strong>Phases through which a software\u2019s development proceeds: requirements, design, implementation, testing, maintenance.<\/p>\n

software engineering
\n<\/strong>Systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software. Source<\/em>: International Organization for Standardization, International Electrotechnical Commission, Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering \u2014 Vocabulary<\/em> (ISO\/IEC\/IEEE Standard No. 24765:2017). https:\/\/www.iso.org\/standard\/71952.html<\/a><\/p>\n

software process model
\n<\/strong>A philosophy and\/or set of approaches for software development and\/or software project management.<\/p>\n

software requirements specification (SRS)
\n<\/strong>A document that contains software requirements.<\/p>\n

spike
\n<\/strong>A quick and to-the-point investigation for gathering information to help the team answer a question or choose a development path.<\/p>\n

Sprint
\n<\/strong>In Agile Scrum, a development period (a month or less).<\/p>\n

Sprint Backlog
\n<\/strong>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.<\/p>\n

Sprint Goal
\n<\/strong>In Agile Scrum, the overall objective of the Sprint.<\/p>\n

Sprint Planning
\n<\/strong>In Agile Scrum, the activity of decided what work will be done during the Sprint.<\/p>\n

Sprint Retrospective
\n<\/strong>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.<\/p>\n

Sprint Review
\n<\/strong>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.<\/p>\n

stakeholders
\n<\/strong>Anyone who is or will be affected by the software or its development (e.g., clients, companies, users, developers, managers, politicians, and so on).<\/p>\n

story points
\n<\/strong>A method for estimating an activity based on its size relative to other activities. Scale established by team.<\/p>\n

sustainability
\n<\/strong>Degree to which software can continue to function over time (e.g., measured in time and how well the software is functioning).<\/p>\n

task management
\n<\/strong>The collection, assignment, sharing, tracking, and scheduling of tasks.\u00a0Source<\/em>: Gil, Y., Groth, P., & Ratnakar, V. (2009). Leveraging social networking sites to acquire rich task structure. In\u00a0Proceedings of the Workshop on User-Contributed Knowledge and Artificial Intelligence: An Evolving Synergy (WikiAI)<\/em>.<\/p>\n

task management system
\n<\/strong>Software for planning and organizing project activities.<\/p>\n

tech stack
\n<\/strong>The set of programming languages, frameworks, and other technologies chosen or needed for implementing a piece of software.<\/p>\n

technical debt
\n<\/strong>Time and resources you (or someone else) will need to spend on modifying your software in the future because of the poor decisions you\u2019re making in the present.<\/p>\n

think-aloud protocol
\n<\/strong>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.<\/p>\n

triple constraint
\n<\/strong>In project management, the three limiting factors that govern project execution: time, cost, and scope. Scope includes quality. Cost includes spending money and resources.<\/p>\n

Tuckman\u2019s model of team development
\n<\/strong>A five-stage model of how a team develops over time: (1) forming, (2) storming, (3) norming, (4) performing, (5) adjourning.<\/p>\n

Unified Modeling Language (UML)
\n<\/strong>A set of notation and methods for describing and designing software.<\/p>\n

usability testing
\n<\/strong>The act of observing individuals as they attempt to interact with your software.<\/p>\n

use case
\n<\/strong>A formal agreement outlining the expected behavior of a system.<\/p>\n

user acceptance testing (UAT)
\n<\/strong>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.<\/p>\n

user interface (UI)
\n<\/strong>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).<\/p>\n

user story
\n<\/strong>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.<\/p>\n

validation
\n<\/strong>Confirming that software meets users\u2019 needs (\u201cDid we build the right software?\u201d).<\/p>\n

velocity
\n<\/strong>In Agile, a measure of how much work is being completed.<\/p>\n

verification
\n<\/strong>Confirming that software satisfied its requirements (\u201cDid we build the software right?\u201d).<\/p>\n

Waterfall
\n<\/strong>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).<\/p>\n<\/div>\n<\/div>\n","protected":false},"author":1,"menu_order":2,"template":"","meta":{"pb_show_title":"","pb_short_title":"Glossary","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"back-matter-type":[38],"contributor":[],"license":[],"class_list":["post-82","back-matter","type-back-matter","status-publish","hentry","back-matter-type-glossary"],"_links":{"self":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/back-matter\/82","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/back-matter"}],"about":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/types\/back-matter"}],"author":[{"embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":0,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/back-matter\/82\/revisions"}],"metadata":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/back-matter\/82\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/media?parent=82"}],"wp:term":[{"taxonomy":"back-matter-type","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/back-matter-type?post=82"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/contributor?post=82"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/license?post=82"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}