Carolla Terminology

ASQC

American Society for Quality Control

Acceptance Test Plan (ATP)

Each Customer Advocate (sometimes individual customers) creates an Acceptance Test Plan as a separate document. Test Cases are generated from the Use Cases and Collaboration Diagrams of the SRS and the Sequence Diagrams of the SDD. The ATP includes document assurance, usability testing and ensures the product matches the customers' expectations. The ATP defines the acceptance test from Use Cases, and includes collaboration and sequence diagrams.

Agenda

A list, outline or plan of things to be done which threads the previous meeting's action items and minutes into the current meeting's schedule. The agenda prevents action items from getting lost and maintains accountability throughout the project.

Architectural description

A design document that provides a scope for an application’s scope. It includes the operating system, architectural model, data requirements, and other details of how the architecture drives or constrains the system design.

Architectural design diagram

A diagram that shows the hardware platform, connectivity, topology, and support software for the system design.

Architectural interaction diagram

See interaction diagram, sequence diagram.

Assumption

A statement that has not been verified as true, but the project proceeds as if it were true. Any assumption can become a risk.

Baseline statistics

A set of metrics characterizing a system to be used in comparison with future similar systems. Baseline statistics may also be applied to development teams to predict how fast (or how much effort) a new system may take to develop. These comparisons are called calibrations.

Boilerplate

A standard text component of a document that requires few or no changes.

Build

A cycle of consruction that consist of one to three use cases.

Business Abstract

An initial requirements document filled out by the customer to help define the scope of the project. The Business Abstract contains the project mission statement and business tasks from each customer's perspective and gives each customer or other stakeholder a chance to define their expectations for the success of the project.

Capability Maturity Model (CMM)

A process with five well-defined levels of sequential development: Initial, Repeatable, Defined, Managed and Optimizing developed by the software Engineering Institute in 1986 to help improve the application of an organization's supporting software technologies. These five maturity levels provide an ordinal scale for measuring the maturity, and therefore the capacity of, an organization's use of its software technologies. The levels also help prioritize an organization's software improvement efforts.

Change cases

A change case is the impact a requirements change wil have on a project's schedule, effort, or cost based on tracing its impact throughout the Requirements Traceability Matrix.

Change Request Form

A formal request from the customers or any stake holder to make a change to the product. These changes will affect devlopment, testing, and the schedule. Developers then compare the change request against the requirements, design, and scedule and determine how much it will cost as well as how long it will take to make the change. The Change Request Form contains a section to report back to the Change Management Board for their consideration if they want to impact the schedule and budget with these changes.

Class category diagram

A diagram that shows a group of logically-related objects that work together to fulfill a high level system function. Class categories are useful in large systems to aggregate large numbers of objects, allowing a more conceptual and clearer picture of the system.

Class diagram

The OOA document that describes the object model, or a portion of it. The class diagram contains classes, their relationships to each other, and cardinality for each relationship. Class diagrams often contain attributes and services for each class too.

Class specifications (CSP)

The prose document for analysis and design that details the definition of each class and each class's attributes and services. The psecification used for design also includes the types for each attribute and service, and the type of each formal parameter in each service. Provides prose description of each class or interface.

Collaboration diagrams

A interaction diagram showing the dynamic message-passing relationship between objects, including which object owns the data being passed and the service being called. Collaboration diagrams are used to validate an object model by tracing its use cases.

Complexity

The level of intricacy in the logic of the solution or problem or the degree of difficulty and amount of time to implement a particular design or piece of software.

Complexity metrics

The quantitative values that indicate the degree of difficulty and amount of time to implement a particular design or piece of software. Function points and Kemerer metrics are typically used to calculate object- and system-level complexity.

Concurrent Engineering

An SDLC that allows a software system to be turned over to the Customers with no defects. Concurrent Engineering is compliant with the international ISO 9000-3 guidelines and SEI’s Capability Maturity Model, a de facto international standard, and is the basis for Carolla Development’s SDLC.

Construction Procedures

The Construction Procedures (6) coordinates and tracks activities using the detailed level design, screen designs, and report layouts while developing functional test. It refines the initial design and resolves remaining design issues per use case by coordinating with implementation steps. This procedure employs iterative development while using the Change Management Board to resolve unexpected results from test cases. Procedure 6 minimizes rework and maintains tight defect control by obtaining final approval from customers of all releases and intermediate steps.

Context diagram

A technical project scoping tool that identifies the interface of the system including customers using the system, the data (or control) from or to the system, and external systems that interface to the system in question. It identifies what data the system sends to and receives from the users, and how the inputs of the system are related to the outputs.

Conversion

A process that moves a product from an old design to a new design and analyzes the organization's business rules to improve the implementation.

Cost/benefit analysis

A calculation comparing the costs and benefits of various alternatives to building a new project. Cost information from vendors’ RFP’s are included. Standard alternatives include: [1] build new system; [2] do nothing; [3] buy entire system, or [4] buy parted of the new system and build part. One to three vendor’s proposals are compared with alternatives [1] and [2]. The c/b analysis is crucial to a cost-effective acquire vs. buy decision.

Costbox

A rough categorization of a product by its expected cost, usually calculated from the timebox and estimated personnel needed to accomplish the project. A project’s costbox is a scoping tool to allow management to make informed decisions before the requirements have been fully collected.

Cross Functional Process Map Diagram (CPM Diagram)

Process flow of tasks and project roles responsible to complete th task.

Customer advocate

The user of the system, or an advocate of the people using the system. The Customer advocate is not necessarily the ultimate user of the system, but may be represented internally by other groups. Customers are intimately involved in the requirements, modeling, design, and acceptance of the new system.

Data Interface Form (DIF)

The document that defines the logical schema, physical schema, the API to files and database managers used in the implementation of the design.

Defect

A discrepancy between a test case and the product requirements, design, or implementation. Defects can also occur in the test case itself.

Deliverables

Project artifacts that push development of a product forwards. The measurable result or output of a process.

Deliverables List

An outline of project artifacts that push development of a product forward.

Dependency

A resource that is assumed available, and will stop or impact the project if it is not. Dependencies usually apply to deliverables, people or events within the project and become risk when the resource is out of the project leadr's control.

Design class diagram

A class diagram that represents the implementation of the extended object model.

Developer

The roles that help to implement the new system, which includes programmers, systems architect, data base administrators, human factors specialists, etc.

Development and Test Planning Procedures

The Development and Test Planning Procedure provides clear technical milestones for implementation of deliverables using thin-thread and risk-driven use cases. It reviews development schedules and approves deployment and numerouse test plans while testing product in a nerar-production environment. This procedure uses incremental deployment to ensure customer satisfaction. Procedure 5 implements strategic documents to avoid unnecessary delay by compiling all sub-project plans together into a tactical plan to organize and control resources and time predictably.

Executive Commitment

Support for the project idea with commitment and money by the Executive Sponsor. This commitment starts a detailed look into the project scope in more detail. This is a required field on the Project Proposal Resolution.

Executive sponsor

The management role that provides the corporate goal and budget for the project being considered. Executive sponsors are typically directors, department heads or vice- presidents, and they operate from a project review or screening board during project selection.

External Customers

Target users outside a department or the corporation who develop the product.

5x5 model

A process model containing 5 scopes (logical, financial, deliverable, temporal, and organizational) that are cross-checked formally against 5 perspectives: management, documenter, users, developers, and testers. The 5-by-5 model is a best-practice when using these scopes and crosschecks.

Facilitator

A person who conducts a project meeting, JAD session, or Formal Technical Review and understands the technical content of the product or process in question. Facilitator duties include scheduling the room, writing the agenda, and selecting the reviewers for a Formal Technical Review.

Formal Technical Review Procedures

A document explaining how to conduct formal technical reviews, a quality support activity to identify potential problems and variances from established standards that allows for issues about a project to be raised and resolutions formed. Controls the quality of a project by detecting errors and potential problems and following a standard procedure.

Formal Technical Review Issues Log

A document containing all the questions that arose about the document in the Formal Technical Review. This log contains an issue phrased as a question, the importance of the issue, the person responssible for resolving the issue, the planned and actual dates of completion, and the resolution of the issue.

Full time equivalent (FTE)

The person's cost to the organization including salary and "sunk costs" assuming a full time workweek.

Function creep

The addition of new features not within the orginal scope of the project. function creep often occurs when the project scope and requirements are vague or ill collected. Project delays and overly long maintenance cycles result from function creep.

Function points

A metric that measures the complexity of a function or algorithm. Function points correspond to the internal complexity of an object.

Functional Test Plan(FTP)

A document defining the functional tests from Use Cases and containing the formal testing criteria and test cases generated from the Use Cases and Collaboration Diagrams of the SRS and the Sequence diagrams of the SDD.

Functions list

A list of activities the customers expect the system to perform. The system functions are defined from the context diagram. Optional deliverable of the mid-level scoping process.

High Level system Design Procedures

The High Level System Design implements the Validated Object Model to obtain design specifications and cost. This procedure provides data for calculating Build plans and construction schedules while justifying that the product is worth the investment to the business through a Cost/Benefit analysis. Procedure 4 provieds high level designs, validates the design, and confirms cost and technical viability or effectiveness of design with stakeholders and technical team.

Human factors specialist

A role that helps the customer to design a computer screen or report for a psychologically or physically comfortable esthetic. The human factors specialist is technically concerned with the position of colors, data fields, ease of use, and sometimes, ergonomics.

Inch Pebble

A project event that demonstrates progress in small and frequent steps. Inch pebble contrasts the traditional "milestone" in which progress check points are relatively large and far apart.

Inspection

A method of validation based on individual examination of the item under consideration. Inspections are useful for finding difficult problems in code. Contrast with review.

Interaction diagram

A diagram that shows the dynamic message-passing relationship between objects, including which object owns the data being passed, and which object owns the service being called. Object-scenario diagrams are used to validate an object model by tracing its use cases. Interaction diagrams differ from object-scenario diagrams by including more detailed information about architecture, and are typically used to validate system object designs by tracing the system’s use cases. See also Sequence diagrams.

Integration Test

See test, integration.

Internal Customers

Target users within a department or inside the corporation who devlope the product. May refer solely to the development group.

International Organization for Standardization (ISO)

An organization that sets international standards founded in 1946. ISO deals with all fields except electrical and electronics. ISO created JTC1, the Joint Technical Committee for information technology.

Issue

A question about the project that may affect the project's progress. Issues are kept in the Isuses Log because forgotten issues usually become problems. Issues are assigned to a certain person for resolution by a certain date.

Issues Log

A common point for all issues to be collected and viewed by anyone interested in the project. It is used throughout the duration of the project. See also Project Issues Log and formal technical review Issues Log.

Joint Application Design (JAD) sessions

A highly effective requirements collection technique used by the technical team and the customers to build the requirements for the new system.

Kemmerer metrics

See Metrics, Kemmerer

Kickoff Meeting

The first business meeting of a project after project approval by the Project Approval board that sets expectations of user, schedules regular project meetings, and makes the project "official". The Project Leader, Technical Analyst, Executive Sponsor, and Customer Advocates attend and define the stakeholders of the project.

Killpoint

A place in the project (usually after a key deliverable) at which the Executive Sponsor, QA, or some other authorized person may teminate the project at any particular time, a project is only approved up to the next killpoint. QA's killpoints are standardized at the deliverables that require the Formal Technical Review inherent in the methodology. Carolla's QA defines killpoint policy in genral; whereas the executive sponsor defines killpoints to his/her project.

Master Test Plan

A document describing test objectives that establishes a coorrdinating strategy for testing, and provides a frtamework for detailed test planning. It defines and aids in the management of the testing. The Master Test Plan describe the strategy to be used during all aspects of testing and the quality assurance staffing requriements. this document provides the overall plan and procedure of how the yststem will be testd and the tests will be managed and otherwise controlled in best project management practices. This document includes other subordinate test plans and test procedures, which are separate documents.

Maintenance

Revision and upkeep to an already existing product constitutes 80% of the product life cycle. One project goal is to minimize maintenance.

Metrics, complexity

Measurements for how difficult an object ormodule will be to implement and/or debug. See also Kemmerer Metrics and function points metrics.

Metrics, defect tracking

Quantitative descriptions of the quality of the system under production, e.g., defects per thousand lines of code, defects per requirement or feature, number of lines of code, rate at which defects are found or repaired, source of defects (requirements, test cases, code), etc.

Metrics, Kemmerer

A metric that measures the complexity between objects. It relies on the complexity with the object’s services, and is often used in conjunction with function points of the object’s services. Kemerer metrics and function points together can yield the complexity of a system of objects at the model or design level.

Metrics, performance

A quantitative description of how the system responds to use, e.g., number of simultaneous users, probable response time, throughput rate.

Migration strategy

A plan by which old systems are moved out and new systems are moved in, and included in the Project Plan. New systems can be migrated all at once (flash cut), in parallel with existing systems, phased in a little at a time (incremental). The migration strategy includes operational support issues, such as help desk, maintenance, customer training, etc. These issues are resolved and become part of the ratified project work plan.

Milestones

A project event that demonstrates progress in relatively large and far apart steps. Milestone contrast to Inch Pebbles where progress checkpoints are relatively small.

Minimal defect project

A project in which all defects found can be repaired in less that 10% of the time it took to develop the product.

Minutes

Project minutes are a concise collection of resolutions, action items, and issues that promote accountability. The resolution and action items each have a completion date and the name of the person responsible.

Mission Statement

A statement of the project, as defined by the Executive sponsor, the expectations of the stakeholders, and the organization's business objectives. All project responsibiities must align with the mission statement, and as such, becomes the criteria by which the project success is determined. See Executive goal.

New build

A product to be developed from scratch with little existing product base. Parameter ion the Project profile.

Object design

The conceptual representation of an implementation of the solution to a business problem. The object design, typically represented with a class diagram, is technology-dependent and specific to architecture, computer language, screen and report layouts, and other real-world restrictions.

Object model

The conceptual representation of the problem domain of an application that embodies the business rules being automated. An object model, typically represented with a class diagram, is used to validate requirements, drive a software solution (object design) or to re- engineer the business rules.

Observer

A person in a Formal Technical Review who participates silently, does not interact, merely watches the proceedings.

Overlap Method for Project Estimation

Estimates the amount of calendar time needed to complete a project when the exact number of use cases is not available. The Overlap Method is not as accurate as claculating the actual scedule from use cases, but is more accurate than the guesses project leaders must use before the project is scoped. The Overlap Method uses the same technique used for guaranteed project schedules, but with an estimate of the number of use cases.

Priority

The importance of a project relative to other projects including resource conflict and availability. Priority is either quanititative or qualitative.

Problem statement

A statement of needs stating what is to be done with the project or product.

Producer

Person who builds a written document or deliverable on the status of a product.

Product Acceptance

"Product acceptance (inspection and test) measures product during and at the end of each [construction] process. The objective of these measurements is to confirm that product quality requirements have been met and that the product is ready for the next operation or delivery to the customer, this activity includes liaison with customer-inspection personnel. If the requirements have not been met, product acceptance provides the raw data for rejection, corrective action, and subsequent performance improvement." – ASQC.

Product manager

A prject team member who supports management direction within executive guidelines

Product Release Plan

The plan by which the product will be rolled out into the production environment. It explains the strategy, training, setup, and options for incorporating a new product into the business procedures.

Product Requirements Document (PRD)

A deliverable in step two of the Carolla Process. This is a scoping document that contains the general product description and drives the Software Requirements Specification (SRS) while paralleling the development of the Project Charter. This PRD collects, analyzes and defines the high-level user needs and features of the product.

Product Transition Procedures

The Product Transistion Procedure installs th product and evaluates success against predefined success criteria (user expetations). This procedure closes the project and marks the beginning of maintenance. Procedure 7 ensures that the product performs in its intended environment as a whole an collects data for predicting future characteristics.

Project Abstract

A document reconciling all of the features and issues from all the stakeholders' Business Abstracts. It is a summary of the size and scope of the project expected contianing the Executive Goal, all the features of the product, the responsibilities of the project, and success criteria for the project.

Project Approval Board

A group of people in the Project Office that approve or deny project proposals. Defines the project's profile, schedules with proper team and prioritizes it and collects executive commitment. See Project Proposal Form.

Project Assessment Report (PAR)

The report when the project is completed in which all stakeholders review their thoughts about the project: what they liked, what they didn't like, so that future projects will go better.

Project Binder

The Project Binder is the collection of all key documents for the project. The Binder contains the contact list of all project team members, the mission statement, the Deliverables List, all documents defined in the deliverables list and an archive section. The archive section contains all Minutes, Agendas and support documents (e.g., Business Abstracts and Issues Log).

Project Charter (CHR)

A mid-level scoping document containing the strategy by which the product will be built and the project will be managed. The Project Charter contains five scope sections: Product Features, Organizational Resources, Schedule, Budget, and Deliverables. The Charter describes how (at the strategic level) the project will meet the success criteria defined in the Project Abstract.

Project Concept Procedure

The Project Concept Procedure transforms a new idea into an official project; all projects are reviewed, prioritized within the context of other projects, and are aligned with the corporate goals. It ensures that the project is officially sanctioned, that the correct and complete set of stakeholders are involved, and that the stakeholders' expectations for the project are clearly stated. It guarantees that the deliverables for the project are clearly defined and agreed by all involved and that the project is authorized within corporate goals.

Project control file

A central collection point for all information (required and optional documents) about the project. This file is the responsibility of the project leader.

Project Issues Log

A document containing all the questions that were not answered at the time they arose and ensures certains aspects of the project are not forgotten. It contains an issue phrases as a question, the priority of the issue, the person responsible for seolving the issue, the planned and actual dates of completion, and the resolution. It identifies and classifies any risk to the prject. The project Issues Log is maintained by a member of the team and published on a weekly basis.

Project leader

The technical expert role that drives the detailed implementation of a specific aspect of the project, and is directly responsible for all project deliverables. A large project may have multiple project leaders reporting to the same project manager.

Project manager

The administrative role that has responsibility for project implementation. The project manager ensures that all features of the system are delivered on time, within-budget, and with appropriate resources. Project managers may have multiple projects.

Project profile

A table that characterizes the project idea in terms of urgency, size, complexity, target users, project type, and quality-level. The profile is used to determine the specific deliverables for the project.

Project Proposal Form (PPF)

A deliverable that helps to formalize the project idea from an individual and analyze issues. This document contains a Project Profile, which is a synopsis of the project essential for deciding particular deliverables for a project.

Project Proposal Resolution (PPR)

The formal response to an idea for a project that records all project ideas as either rejected, deferred, approved, or no action (merged with an existing project) for the organization. Requires a completed and reviewed Project Proposal Form and keeps all projects official and aligned with the business objectives and timelines of the organization.

Project Roles

Certain roles required by a project to drive the process forward. These roles may be a single individual or a team of individuals; a single person may have multiple roles. Project team roles: executive sponsor, project sponsor, project mamager, customer, technical analyst, project leader, developer, test manager, tester, technical writer, and quality engineer. sometimes the operations manager plays a role. See the Roles table in the MPP.

Project sponsor

The customer manager role that has responsibility for the financial scope of the project, and oversees the logical scope for improvements and changes. Project sponsors may have multiple projects, and usually report to the executive sponsor.

Project team

The group of people responsible for the project success. This team is composed of customers, or customers representatives, and the Technical Team. The Project Team is assigned during the customer kickoff meeting of the Identify Project phase.

Project Work Plan (PWP)

The schedule of tasks, durations, and dates to accomplish a project. A high level work plan shows the standard deliverables for the process; the detailed project plan shows the project-specific tasks.

Quality Assurance (QA)

"Quality management consists of two fundamental groups: Product Acceptance and Quality Engineering." –ASQC. See those entries.

Quality Control (QC)

See Product Acceptance.

Quality Engineering

"Quality engineering applies the technology of quality systems to the specific technologies of a company’s business. Organizationally, quality engineering embodies activities of inspection and test planning, data analysis and corrective action, and the quality interface with marketing and engineering. In this capacity, quality engineers are responsible for continued improvements in documentation systems, statistical techniques, testing systems, failure-analysis techniques, reliability programs, vendor quality systems, and so on." – ASQC.

Recorder

A scribe that records technical issues, keeps time, and maintains meeting minutes during a formal Technical Review.

Request for Information (RFI)

A letter sent to eligible candidate vendors interested in receiving a Request for Proposal.

Request for Proposal (RFP)

A request to a vendor to provide a solution to the requirements specification that describe the business need. The RFP contains the costs and features the vendor will provide to the company in lieu of the company’s building a system themselves.

Requirements Data Collection, Modeling and Validation Procedures

The Requirements Data Collection Procedures is the third step in the SDLC. This procedure transforms the project scope into a validated business model using requirments specifications from Use Cases. It refines and validates requirments to rmove product defects and assures valid, complete and consistent requirments with use cases and ciustomer needs. Procedure 3 provides a true specification for design, testing, implementation, docudmentation, operation, and project management that is clear, concise, complete, and modifiable.

Requirements Treaceability Matrix (RTM)

A document listing the responsibilities of the product, and maps each responsibility to the classes that must be implemented to perform the Use Cases that it comprises during design. Test cases are mapped to the use cases during testing. this document is required by the SEI and is critical for change cases.

Review

A method of validation based on examination of an idea (or its deliverable) by a group of the originator’s peers. Reviews are useful for refining and optimizing requirements, designs, object models, and documentation before proceeding with implementation of those ideas.

Reviewer

A person who reviews a document for a formal Technical Review. This person raises issues, and focuses on quality and technical evaluation of the prodcut as correct and complete.

Risk

A statement that will negatively impact the project if not dealt with accordingly.

Scope

Each project has five areas of influence that can be viewed from a specific emphasis, or scope. These five scopes are financial (budget and cost flow), logical (business rules, analysis, design, and implementation), organizational (personnel and managerial responsibility), temporal (schedules, task breakdowns, and durations), and deliverable scopes (all outputs of the system and process used to develop it).

Scribe

See Recorder.

Sunk cost

Money a company pays that relates to an employee's employment, include lights etc.

Sequence Diagrams

A diagram that shows the dynamic message-passing relationship between objects, including which object owns the data being passed, and which object owns the service being called. Object-scenario diagrams are used to validate an object model by tracing its use cases. Interaction diagrams differ from object-scenario diagrams by including more detailed information about architecture, and are typically used to validate system object designs by tracing the system’s use cases. Formerly known as Architecture Interaction Diagrams.

Software Development Life Cycle (SDLC)

A process of developing a software system in an organized, controlled, and predictable way. The process starts at the conception of the project to its termination with the company, sometime called a cradle-to-grave process.

Software Engineering Institute (SEI)

A federally funded research and development center that is under contract to Carnegie Mellon University and is devoted to the advancement of software engineering and the quality of software support systems. The SEI carries out its mission through two principal areas of work: software Engineering Management Practices, and Software Engineering Technical Practices.

Software Requirements Specification (SRS)

A formal document that captures the problem need and solution requirements of the new system. The spec must be written such that the requirements are testable, modifiable, traceable, concise, complete, non-ambiguous, and can be used to drive design, the user manual, and testing. The Requirements spec is composed primarily of use cases.

Stakeholder

A person with a business reason to see the project succeed and will be impacted by its failure. They are usually customer advocates on the Project team. Technical team members are NOT stakeholders.

System design

The system design is the real-world solution to the business problem domain, and represented by a class diagram. It is built by reiteratively adding the real-world constraints to the idealized object model. A high level system design is the first arbitrarily few passes before the full, or detailed, system design is refined.

System Design Document (SDD)

A document that describes and defines the system (or high level) design of the product. There are five main portions of this document: archtecture of the project, high level design of the product, including the class diagram and class specifications, validating the design, how th product will interface with other systems and the Build Plan. This plan shows how the project will be incrmentally implemented in phases. Each phase will deploy one or more use-cases that QA and Testing will verify. Software developers typically develop this document.

System Test and Evaluation Performance Strategy (STP

A report on operational parameters and integrated testing, which contains four parts: the System Performance Testing, the Load (Capacitance) Testing, the Stress Testing, and the Reliability/Stability Testing.

System integration

A process of purchasing and assembling systems with little or no devlopment.

Target customers

Those people that benefit directly from the product. See Internal Customers and External Customers.

Technical analyst

The role that organizes and drives requirements data collection from the customer and develops the rigorous model of the requirements. The analyst must have skills in requirements collection and object-oriented analysis and design, but does not necessarily need programming skills. The analyst should be independent of the customer to avoid bias of the requirements model. Some companies use data administrators for this role, or business analysts with extended technical skills.

Technical and Business Planning Procedures

The second step in the Carolla process that proceeds from the initial scoping of the project into the next level of detail about how the project will be accomplished, and what major features of the product will be implemented. A mid-level determination of project scope that estimates the general range of functionality, organizational impact, cost, and effort required. Ensures that the project benefits the company before committing full resources and effort to it. This procedure ensures that all customers' and executive expectations are met. Leverages existing technology into new technology (for conversion projects). Defines project scope and users' needs at a more detailed level (using the 5x5 model).

Technical writer

The role that helps the technical and managerial roles document the processes and deliverables of the project, including centralization and distribution of these documents, organization of the project library, and their updates. The Technical Writer composes the Customers’ User Manual and sits in on any review where a Customer advocate is needed.

Testing

One or more test cases to validate a related collection of features or processes in a product.

Test, acceptance

A functional test of a new system, written and conducted primarily by the customers. The test is not exhaustive, but enough to prove the viability of the system to the customers’ satisfaction.

Test, capacitance

See test, load.

Test, load

A test that measures the performance of the system under the maximum conditions for which it was designed, e.g., number of users, number of messages per minute, amount of data handled. Various loads below the maximum are also tested to develop a performance curve for the product. These performance (or operational) results are used to help find bottlenecks and improve future performance.

Test, regression

A kind of test in which previous test cases are selected and rerun against subsequent versions of the product. Regression testing ensures that new defects are not introduced into already tested code by new releases.

Test, stress

A test that measures the performance of the system over the maximum conditions for which it was designed, e.g., number of users, number of messages per minute, amount of data handled. The intent is to cause a breakdown in the system and measure under what conditions the breakdown occurs. These performance (or operational) results are compared with the load testing to calculate utilization figures for developing recovery contingencies.

Test, usability

A test in which the psychological human factors are tested; e.g., how easy to learn and use the product, how easy and intuitive to navigate among the various options, how effective the customer becomes at the task intended.

Test case

A method of exercising a product, feature, or process flow to confirm a single predefined result. Failed test cases reveal product defects or defects in the test case.

Test case, black box

A test case that assume no knowledge of the product or object internals. The test case is build by the testers from the requirements and reflects the process or feature behavior. Use cases are typically used to build black box test cases.

Test case, grey box

A test case that involves the relationships between modules of objects. It requires some internal knowledge but not fully detailed knowledge of the system. Collaboration and sequence diagrams provide the data to orginate gray box test cases.

Test case, white box

A test case that takes advantage of knowledge internal to the product. White box cases originate with developers and are produced during the unit testing done by developers, and used by both developers and testers. Objects should have test services built in so each object can test themselves.

Test Case Form (TCF)

A documentation of an individual tes case from the Functional Test Plan. The TCF includes what the tester is to perform on the software, the expected results of the test and a section for the tester to fill out for their findings. If the test failed, the tester will describe, in this section, what they observed and why they think it failed.

Test Manager

The role responsible for accountability of test cases against testing procedures.

Timebox

A rough categorization of a product by its expected duration. A project’s timebox is a scoping tool to allow management to make informed decisions before the requirements have been fully collected.

Use case

A transaction with the system from interface to interface initiated by the user or another system. The use case captures the essence of a single, simple system responsibility and is the basis for object-oriented modeling. Use cases are used to detail requirements, drive testing, and validate the object model.

UML list

Unified Modeling Language. A standard for modeling the process of a business, or the procedures of a program. UML is a visual representation of pi calculus to form a mathematical proof of the validity or requirements or design.

Validated object design

A object design that complies with the structural and organizationclass rules for object designs specific to architecture, computer language, screen and report layouts, and other real-world restrictions. UML uses interaction diagrams (sequence diagrams are preferred) to validate object designs.

Validated object model

An object model that complies with the structural and organizational class rules for object models and support the dynamic simulation of the appropriate use cases. Valid object models ensure that the problem domain has been modeled completely, non-ambigiously, and with proper mathematical relationship. UML uses interaction diagrams (collaboration diagrams are preferred) to validate the object models.

XUML

Extednded UML, praticularly Carolla's extensions to the notation for enhancement, completeness, and notational convenience.

Zero defect project

A project that shows no major defects after completion for a period of time equal to the development time, and for the same period of time shows no other defects that remain unresolved two or more weeks after being reported to the developers.

ASQC quotes are from "The Management of Quality: Preparing for a Competitive Future", John Hagan, ASQC, 1984.

Copyright Carolla Development, 1996-2001