Standard Glossary Terms

Project terms	Standard terms

This file is a dictionary of standard terms defined as they are used across projects.

General Terms

Attached worksheet

n. The idea is similar to filling in an IRS form and using worksheets to calculate subtotals or make specific decisions. That is to say, there is a hierarchy to the templates: there are the main templates, and then worksheets for specific topics. We have divided the information into several files so that each file is focused on one topic, and so that each file can be worked on by one person in a reasonable amount of time.

Checklist

n. There are two kinds of checklists:

Many of the templates have a section with questions that help to check the work in that template. Often the sample answers to the checklist questions suggest corrective actions.
For design and code review meetings, there are links to guidelines and checklists that help identify common errors in the artifacts reviewed in those meetings.

Chip away

v. The process of removing sample text from templates when that text does not apply to the current project. Often some of the sample text will be kept or revised to fit the current project. Even if the sample text does not fit the current project, it provides a reusable example of how to phrase that type of description. The term "chip away" comes from an old joke: when a sculptor was asked how he carved a marble statue of a horse, he replies, "It was easy, I just started with a big block of marble and chipped away everything that did not look like a horse."

Process impact

n. The process impact box on each template explains where the current template fits into the software development process. It usually includes a brief comment on who should create the document, and who would be expected to make use of it.

Sticky note

n. The idea is similar to a post-it note attached to a document that tells you to "sign here" or fill in a certain field. There are two types of sticky notes:

TODO notes instruct you on how to fill in the template. This is the minimum that you need to do. One of the main goals of ReadySET Pro is to help your team quickly carry out basic software engineering activities. The TODO sticky notes make that easy by making the templates more self-explanatory.
TIP notes help you think of better ways to fill in the template. Another goal of ReadySET Pro is to help your team make better decisions that can make your whole project more successful. The TIP sticky notes help with that.

After you have done the work described in the sticky note, you may delete the sticky note.

Software and Technology Terms

API (Application Program Interface): n. An API is a set of functions that one software component makes available to other software components. That allows other programs to "call" this program via direct function calls, or more indirect communications such as SOAP messages.
Berkeley DB: Berkeley DB (BDB) is a computer software library that provides a high-performance embedded database, with bindings in C, C++, Java, Perl, Python, Ruby, Tcl, Smalltalk, and many other programming languages. BDB stores arbitrary key/data pairs as byte arrays, and supports multiple data items for a single key. BDB can support thousands of simultaneous threads of control or concurrent processes manipulating databases as large as 256 terabytes, on a wide variety of operating systems including most Unix-like and Windows systems, and real-time operating systems.( Wikipedia)
Components: A component is an object written to a specification. It does not matter what the specification is: COM, Enterprise JavaBeans, etc., as long as the object adheres to the specification. It is only by adhering to the specification that the object becomes a component and gains features such as reusability.
Database: A database is a structured collection of records or data. A computer database relies upon software to organize the storage of data. The software models the database structure in what are known as database models. The model in most common use today is the relational model. Other models such as the hierarchical model and the network model use a more explicit representation of relationships (wikipedia).
DTD: Document Type Definition (DTD) is one of several SGML and XML schema languages, and is also the term used to describe a document or portion thereof that is authored in the DTD language. A DTD is primarily used for the expression of a schema via a set of declarations that conform to a particular markup syntax and that describe a class, or type, of document, in terms of constraints on the structure of that document. A DTD may also declare constructs that are not always required to establish document structure, but that may affect the interpretation of some documents. XML documents are described using a subset of DTD which imposes a number of restrictions on the document's structure, as required per the XML standard (XML is in itself an application of SGML optimized for automated parsing).
Hibernate: Hibernate is an object-relational mapping (ORM) library for the Java language, providing a framework for mapping an object-oriented domain model to a traditional relational database. Hibernate solves Object-Relational impedance mismatch problems by replacing direct persistence-related database accesses with high-level object handling functions.
J2EE: n. Java 2 Enterprise edition. This provides further enterprise features for java in a robust and scalable fashion.
J2SE: n. Java 2 Standard edition. This is a library of java classes used to develop applications in the Java programming language.
Java: n. A computer programing language. Spine is a java program written to serve as a core for building other applications.
Java application framework: Interchangeable with API with the difference that a framework is also classified as a library of functions meant to satisfy a particuar purpose
Junit: JUnit is a unit testing framework for the Java programming language. Created by Kent Beck and Erich Gamma, JUnit is one of the xUnit family of frameworks that originated with Kent Beck's SUnit. JUnit has spawned its own ecosystem of JUnit extensions
LDAP: The Lightweight Directory Access Protocol, or LDAP , is an application protocol for querying and modifying directory services running over TCP/IP. A directory is a set of objects with similar attributes organized in a logical and hierarchical manner. The most common example is the telephone directory, which consists of a series of names (either of persons or organizations) organized alphabetically, with each name having an address and phone number attached. Due to this basic design (among other factors) LDAP is often used by other services for authentication, despite the security problems this causes.
Log4J: Log4J is a Java-based logging utility.
Persistence Store: Used to store data that will not change even if the stroe where to be restarted eg database, filesystem and/or LDAP.
SOAP (Simple Object Access Protocol): n. SOAP is the message format used by standard web services. It entails sending an XML document to a server in order to invoke an operation on the server-side. More information on SOAP.
Swing Application: Swing is a desktop graphical user interface library which can be used to develop applications
SWT Application: SWT is a graphical user interface library used for developing applications
Web Application: a Web application is an application that is accessed via Web browser over a network such as the Internet or an intranet. It is also a computer software application that is coded in a browser-supported language (such as HTML, JavaScript, Java, etc.) and reliant on a common web browser to render the application executable
XML Schema: An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntax constraints imposed by XML itself. An XML schema provides a view of the document type at a relatively high level of abstraction. There are languages developed specifically to express XML schemas. The Document Type Definition (DTD) language, which is native to the XML specification, is a schema language that is of relatively limited capability, but that also has other uses in XML aside from the expression of schemas. Two other very popular, more expressive XML schema languages are XML Schema (W3C) and RELAX NG. The mechanism for associating an XML document with a schema varies according to the schema language. The association may be achieved via markup within the XML document itself, or via some external means.

Process Terms

Change Control Board (CCB)

n. A group of people who review proposed changes to the project requirements and/or source code to accept or reject changes in each particular release. Proposed changes are usually rejected if they introduce too much risk or would trigger additional effort (e.g., the need to retest the entire product). A CCB is usually composed of development managers and representatives of other stakeholders, such as the QA department manager.

Code Complete

A release is called "code complete" when the development team agrees that no entirely new source code will be added to this release. There may still be source code changes to fix defects. There may still be changes to documentation and data files, and to the code for test cases or utilities. New code may be added in a future release.

External Release Number

n. External release numbers are the numbers that users see. They may be the same as the internal release number, especially if the product being built is a component intended to be reused by another engineering group in the same development organization. External release number are often simpler, and may not count up logically. E.g., "Office 2000", "10 Optimized".

Feature Complete

A release is called "feature complete" when the development team agrees that no new features will be added to this release. New features may still be suggested for later releases. More development work needs to be done to implement all the features and repair defects.

Internal Release Number

n. An internal release number is the number that the development team gives each release. Internal release numbers typically count up logically, i.e., they do not skip numbers. They may have many parts: e.g., major, minor, patch-level, build number, and RC number.

Planning Variables

n. The set of variables that must be balanced in planning a project:

Schedule
Functionality
Budget
Quality
Risk

Release Number

n. The term "release number" by itself refers to an external release number. Users normally are not aware of the existence of any internal release numbers.

Requirements Terms

Actor: n. A person or external system that uses the system being built.
Feature specification: n. A feature specification focuses on one feature of a software product and completely describes how that feature can be used. Feature specifications are described fully here. One feature may be used in many different ways as part of many different use cases.
Use case: n. The main part of a use case is a set of steps that give an example of how an actor can use the product to succeed at a goal. These steps are called the "Main success scenario", and they include both user intentions and system responses. Use cases are described fully here. One use case may show how the actor uses several features to accomplish a goal.

Design Goals

Abstract Factory Pattern: The Abstract Factory Pattern is used to return one of several groups of classes. In some cases it actually returns a Factory for that group of classes.
Abuse prevention: Prevention of abuse (e.g., using the system to send spam).
Adapter Pattern: The Adapter pattern, used to change the interface of one class to that of another one.
Auditability: The system allows all changes to be accounted for later. I.e., we can look back and see who made each change.
Bridge Pattern: The Bridge pattern, intended to keep the interface to your client program constant while allowing you to change the actual kind of class you display or use. You can then change the interface and the underlying class separately.
Builder Pattern: The Builder Pattern assembles a number of objects to make a new object, based on the data with which it is presented. Frequently, the choice of which way the objects are assembled is achieved using a Factory.
Capacity matching: The architecture deploys components onto machines that provide needed resources with reasonable total expense. E.g., a database should run on a machine with fast disks, while an application server might depend more on CPU speed.
Chain of Responsibility: The Chain of Responsibility allows an even further decoupling between classes, by passing a request between classes until it is recognized.
Command Pattern: The Command pattern provides a simple way to separate execution of a command from the interface environment that produced it
Composite Pattern: The Composite pattern, a collection of objects, any one of which may be either itself a Composite, or just a primitive object.
Consistency and familiarity: Users can apply their knowledge of similar UIs or UI standards to this system.
Correctness: This design correctly matches the given requirements.
Data capacity: The system can store the amount of data needed.
Data security: The system protects sensitive user and corporate data from unauthorized access or modification.
Decorator Pattern: The Decorator pattern, a class that surrounds a given class, adds new capabilities to it, and passes all the unchanged methods to the underlying class.
Design Patterns: A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise.
Ease of access: Application code to access stored data is simple.
Ease of integration: The components can work together, and making them work together can be accomplished within the planned budget and schedule.
Efficiency: The design enables the system to perform functions by using an acceptable amount of time, storage space, bandwidth, and other resources.
Expressiveness: This design allows for storage of all valid values and relationships. I.e., the functionality of the system is not unduly restricted by the design of its database.
Extensibility: New features or components can be easily added later.
Façade Pattern: The Façade pattern, which groups a complex object hierarchy and provides a new, simpler interface to access those data.
Factory Pattern: The Factory Pattern is used to choose and return an instance of a class from a number of similar classes based on data you provide to the factory.
Feasibility: It is possible for the design to be implemented and tested with the planned amount of time and effort.
Flyweight Pattern: The Flyweight pattern, which provides a way to limit the proliferation of small, similar class instances by moving some of the class data outside the class and passing it in during various execution methods.
Implementation phase guidance: This design divides the implementation into components or aspects that can correspond to reasonable implementation tasks.
Interoperability: The database or data files can be accessed and/or updated by other applications.
Interpreter: The Interpreter provides a definition of how to include language elements in a program.
Intrusion prevention: Prevent unauthorized access at the operating system level. E.g., prevent hackers from opening a command shell on the server.
Iterator Pattern: The Iterator pattern formalizes the way we move through a list of data within a class.
Mediator Pattern: The Mediator defines how communication between classes can be simplified by using another class to keep all classes from having to know about each other.
Modularity: Concerns are clearly separated so that the impact of most design changes would be limited to only one or a few modules.
Observer Pattern: The Observer pattern defines the way a number of classes can be notified of a change,
Performance: The design allows data to be accessed and updated quickly.
Prototype Pattern: The Prototype Pattern copies or clones an existing class rather than creating a new instance when creating new instances is more expensive.
Proxy Pattern: The Proxy pattern, which provides a simple place holder class for a more complex class which is expensive to instantiate.
Reliability: Stored data cannot easily be corrupted by defective code, concurrent access, unexpected process termination, or other causes.
Safety: Users are not likely to accidentally produce an undesired result, e.g., delete data, or send a half-finished email.
State Pattern: The State pattern provides a memory for a class's instance variables.
Singleton Pattern: The Singleton Pattern is a pattern that insures there is one and only one instance of an object, and that it is possible to obtain global access to that one instance.
Strategy Pattern: The Strategy pattern encapsulates an algorithm inside a class,
Task support and efficiency: The UI is well matched to the users' tasks and it can be used with a reasonable number of clicks and keystrokes.
Template Pattern: The Template pattern provides an abstract definition of an algorithm, and
Testability: It is easy to test components of this design independently, and information is available to help diagnose defects.
Understandability: Developers can understand this design and correctly implement it.
Understandability and learnability: Users can reasonably be expected to understand the UI at first sight. Users will be able to discover additional features without aid from other users or documentation, and they will be able to recall what they have learned.
Visitor Pattern: The Visitor pattern adds function to a class,

UI Terms

Abstract widget

n. Each abstract widget is a piece of information or a user interface affordance. In GUI design, each abstract component will eventually be implemented as a widget, but the choice of specific widgets happens later. E.g., an abstract widget may offer the user a choice of one of five options. That abstract widget could be implemented with any one of several concrete widgets, such as a radio button group, sub-menu, drop-list, combo-box, or roller.

Cognitive walk-through

n. A cognitive walk-through is a systematic method for evaluating how well a user interface supports a specific use case. Any step that fails one of the following indicates a potential usability problem:

Will the user realize that he/she should have the intention listed in this step?
Will the user notice the relevant UI affordance?
Will the user associate the intention with the affordance?
Does the system response clearly indicate that progress is being made toward the use case goal?

Interaction context

n. An interaction context is an exclusive UI mode: the user can only use one interaction context at a time. All the UI elements within one context are visible and usable at the same time. E.g., a dialog with three tabs has three interaction contexts because only one tab can be used at a time. Users can easily move among a few contexts while performing the steps of a use case, but use cases that require too many contexts are usually difficult to use.

Model View Controller (MVC)

is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the Model represents the information (the data) of the application and the business rules used to manipulate the data, the View corresponds to elements of the user interface such as text, checkbox items, and so forth, and the Controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

UI zone

n. A UI zone is a set of pages that share common characteristics such as navigational elements and security constraints. E.g. user screens might be in one zone, whereas administrative screens would be in a second zone. Typically an application UI will have only three to seven zones, even if there are dozens of screens. Zones are considered during UI design and may or may not be explicitly visible to users.

QA Terms

Bug: n. Deprecated since 1991. See defect.
Defect: n. The result of the developer's error embodied in the product source code, initial data, or documents. E.g., a square root function which allows negative numbers as arguments is defective. Defects can be removed by changing the source code, initial data, or document.
Error: n. A mistaken thought in the developer's mind. Often caused by miscommunication or bad assumptions. Errors can lead to defects. E.g., a developer might erroneously think that the square root of -4 is -2.
Failure: n. The user-visible result of a fault. E.g., an error message or an incorrect result. This is evidence that can be included in a defect report. Developers use failure evidence during debugging to eventually find and remove defects.
Fault: n. The execution of defective code. E.g., if a certain input is provided to defective code, it may cause an exception, or go into an infinite loop, or store an incorrect value in an internal variable. A fault is not normally visible to users, only the failure is visible.

QA Goals

Efficiency: The system's operations should execute quickly, with reasonable use of machine and network resources. I.e., if one user does one operation, it should execute efficiently.
Functionality > Accuracy: Accuracy refers to the mathematical precision of calculations done by the system. Any system that does numeric calculations must consider accuracy, e.g., financial or scientific applications.
Functionality > Compatibility: Systems that claim to follow standards or claim compatibility with existing systems must adhere to the relevant file formats, protocols, and APIs. The relevant standards are linked at the top of the QA plan.
Functionality > Correctness: Correctness is the most basic quality goal. It means that, when valid inputs are given and the system is in a valid state and under reasonable load, the system's behavior and results will be correct.
Functionality > Factual correctness: The data in the system is a true representation of the real world. Any system that contains initial data or gathers data about the real world should be sure that the data is factually correct. E.g., a tax preparation program should embody correct and up-to-date facts about tax law.
Functionality > Robustness: Robustness is the system's ability to gracefully handle invalid inputs. It should never be possible for any user input to crash the system or corrupt data, even if that user input is abnormal, unexpected, or malicious.
Maintainability > Evolvability: The evolvability quality affects the overall cost of future changes. I.e., can the system easily be modified and extended over time?
Maintainability > Testability: Testability determines if the system can easily be tested. I.e., do the requirements precisely specify possible inputs and the desired results? Can the system be tested in parts? When failures are observed, can they be traced back to defects in specific components during debugging? Is testing practical with the available testing tools?
Maintainability > Understandability: Developers must understand the system before they can safely make changes to it. The understandability goal addresses how easy it is for (future) developers to understand how the system works.
Operability: The long-term needs of system administrators should be reliably supported. E.g., is the system easy to install? Can the administrator recover from a crash? Is there sufficient log output to diagnose problems in the field? Can the system's data be backed up without downtime? Can the system be upgraded practically?
Reliability > Availability under load: Every system has some capacity limits. What happens when those limits are exceeded? The system should continue to service those requests that it is capable of handling. It should not crash or stop processing all requests.
Reliability > Consistency under concurrency: Systems that allow concurrent access by multiple users, or that use concurrency internally, should be free of race conditions, live-lock, and deadlock.
Reliability > Consistency under load: Every system has some capacity limits. What happens when those limits are exceeded? The system should never lose or corrupt data.
Reliability > Longevity: The system should continue to operate as long as it is needed. It should not gradually use up a limited resource. Longevity defects include memory leaks or rapidly filling the disk with log files.
Scalability: Scalability is a general quality that holds when the system continues to satisfy its requirements when various usage parameters are increased. E.g., a file server might be scalable to a large number of users, a large number of files, very large-sized files, or very high capacity disks. Some specific scalability goals are listed below.
Scalability > Large data volume: This is a specific type of scalability goal dealing with the ability for the system to handle large data sets. Operations should continue to be correct and efficient as data set size increases. Furthermore, the user interface should still be usable as the data presented to users increases in size.
Scalability > Performance under load: This is a specific type of scalability goal dealing with the performance of the system at times when it is servicing many requests from many users.
Security: The system should only allow usage by authorized users, and restrict usage based on permissions. The system should not allow users to side-step security rules or exploit security holes. E.g., all user input should be validated and any malicious input should be rejected.
Usability > Consistency and Familiarity: Users should be able to apply their past experience with other similar systems. This means that user interface standards should be followed, and common conventions should be used whenever possible. Also, UI elements that appear in several parts of the UI should be used consistently, unless another UI quality takes priority. E.g., if most currency entry fields do not require a dollar-sign, then one that does demand it is a consistency defect, unless there is a real chance that the user is dealing with another currency on that step of his/her task.
Usability > Efficiency: Users should be able to accomplish common tasks with reasonable effort. Common tasks should be possible with only one or two user actions. The difficulty of each step should also be considered. E.g., does the user have to remember a long code number or click on a very small button?
Usability > Learnability and Memorability: Every user interface contains some details that users will need to learn and remember. E.g., Alt-F to open the "File" menu. UI cues and rules can make these details easier to learn and remember. E.g., the "F" is underlined and, as a rule, the first letter is usually the accelerator key.
Usability > Task support: This is the quality of match between user tasks and the system's UI. Task support defects are cases where the system forces the user to take unnatural steps to accomplish a task or where the user is given no support for a difficult step in a task. E.g., the user must invent an 8-character filename for their "Christmas card list." E.g., the user must total their own tax deductions.
Usability > Safety: Humans are error-prone, but the negative impact of common errors should be limited. E.g., users should realize that a given command will delete data, and be asked to confirm their intent or have the ability to undo.
Usability > Subjective satisfaction: Users should feel generally satisfied with the UI. This is a subjective quality that sums up all the other user interface qualities as well as aesthetics.
Usability > Understandability and Readability: Users need to understand the system to use it. The basic metaphor should be understandable and appropriate to user tasks. Some defects in understandability include unclear metaphors, poor or hard-to-see labels, lack of feedback to confirm the effects of user actions, and missing or inadequate on-line help.

Additional Standard Terms

For additional standard terms, see the following reference sites: