Software Project Survival Guide

Thanks to James O. Kimrey for putting this page together.

Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

ACM. Acronym for Association of Computing Machinery, a professional membership organization that provides a variety of member services to people who work with computers.

Analysis. See Requirements Analysis

Applications programs. The kind of software developed for use by end users. Examples of applications include spreadsheet, word-processing, and accounting programs. Compare information systems, real-time software, shrink-wrap software, and Systems software.

Architecture. The design of the organizational structure of a system, its communications rules, and system wide design and implementation guidelines. Architecture is also sometimes referred to as "system architecture", "design", "high-level design", and "top-level design". The term "architecture" can also refer to the architecture document.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Baseline, n. The original version of a work product that serves as the basis for all future development work, that is placed under change control, and that can be changed only through the systematic change control process.

Build. A specific instance of a software program at a particular time during its development. Builds are often numbered. At the end of the project, a specific build will be released or accepted. Compare Delivery and Release.

Build instructions. See Software build instructions.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Change board. The group of people responsible for evaluating Change Proposals, approving or rejecting them, and notifying affected parties of how each one was resolved.

Change Control Plan. The document that describes how change control will be conducted on a specific project.

Change control. The practice of managing changes in requirements, architecture, design, source code, and other work products.

Change Proposal. A document or form used to propose changes as part of a systematic change control process. A Change Proposal typically includes a description of the change; an evaluation of impacts that the change will have on cost, schedule, quality, and other product and project characteristics; and a justification of why the change is needed.

Code reading. A code review technique in which source code is read by one or more programmers before a review meeting is held. Compare Code review, Inspection, and Walkthrough.

Code review. A technical review that focuses on a system's source code. See Technical review.

Coding Standard. A document describing the detailed conventions that developers must follow in creating a system's source code.

Coding. See Construction.

Complexity. The degree to which a system's designer or code is difficult to understand because of numerous components or relationships among components.

Cone of uncertainty. The amount of possible error in a software project estimate, which is very large in the early stages of a project and shrinks dramatically as the project nears completion.

Construction. The activity in software development comprising detailed design, coding, unit testing, and debugging. This activity is also commonly known as "coding", "implementation", and "programming".

Control. The ability to direct the outcome of a project's cost, schedule, functionality, or other characteristics. Compare Visibility.

Customer. The person or persons that the software ultimately must please in order to be considered a success. For information systems, often the customer is an in-house end user. For shrink-wrap software, the customer is a person or organization that buys the software. For custom software, the customer is the organization that contracts with the software development organization in order to develop a system.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Daily build and smoke test. A development practice in which a version of the software is built every day and then subjected to a short test to determine whether it "smokes" (breaks). If the build is found to be stable enough for the test group to work with, the build passes the smoke test.

Defect. An error in a program's specification, design, or implementation.

Defect tracking. The practice of recording all defects found in the executable software and other work products and monitoring them throughout the project.

Deliverable. Any work product that must be delivered to someone other than the work product's author.

Delivery. The release of software to users outside the group that is responsible for the development of the software. Software can be delivered by developers to a testing group, internal users, or external customers. "Delivery" and "release" are used interchangeably. Compare Build and Release.

Deployment Document (Cutover Handbook). The document that describes how to put a new system into operation, especially what must be done for a new system to replace an older system.

Design. The process of conceiving, inventing, or contriving a scheme for turning a specification for a computer program into an operational program; the activity that links requirements development to construction. "Design" also refers to the result of the design activity. Compare Architecture and Detailed design.

Design review. A technical review that focuses on a system's design. Compare Technical review.

Detailed design. Software design work that focuses on operations of individual routines and small collections of routines. Compare Architecture.

Detailed Design Document. A document that describes the detailed design for a specific part of a system. See Detailed design.

Downstream. Usually refers to construction and system testing, but can also refer to any part of a software project that follows any other particular part. Compare Upstream.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

End user. The ultimate user of a program. The end user of a word processing program could be an administrative assistant or a writer. The end user of a compiler could be a software developer. Compare Customer, Key user.

Executive sponsor. The person or group who has final authority over project wide decisions. This person or group should be responsible for committing to a feature set, approving the user interface design, and deciding whether the software is ready to release to its users or customers. If the decision-making authority is a group, each person in the group should represent a different interest - management, marketing, development, quality assurance, and so on. Sometimes this group is the Change Board.

End-user documentation. Books, reference cards, help screens, and other materials that are delivered to end users.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Go/no go decision. A decision made during the project's Planning Checkpoint Review about whether to continue a project.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

High level. General, broad, and abstract, as in "high-level design" or "high-level milestones". Compare Top level.

High-level Design. Software design activity that is more like architecture than detailed design. Compare Architecture and Detailed design.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

IEEE. Acronym for Institute of Electrical and Electronics Engineers, a professional membership organization that provides a variety of member services to software developers and other kinds of engineers.

Implementation. Essentially the same as construction. Also refers to the work products created during construction, such as source code. See Construction.

Individual Stage Plan. The document that contains a detailed plan, which includes miniature milestones, for performing work during a single stage of a project using staged delivery.

Information systems (IS). The kind of software developed for use in general business operations, such as payroll software, accounting software, and billing software. Compare Applications programs, Real-time software, Shrink-wrap software, and Systems software.

Inspection. A technical review technique characterized by use of individual code reading, checklists to focus each reviewer's attention, review meetings that inspect each line of code interactively, and systematic feedback from the review process to improve future reviews.

Install Program. A specific kind of program that is run to set up new software on a computer.

Integration. The activity of combining multiple software components and making them work together.

Integration testing. The testing of software components that have been integrated

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Key users. A set of users who will provide guidance in defining software requirements. These users must be selected in such a way that if they say the feature is important, you can believe that it truly is important. Likewise, if they say that a feature can be left out, you should be confident that you truly can leave it out. Be sure to include both power users and average users. Compare Customer, End user.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Line of code. A programming language statement, often defined as a noncomment, nonblank source statement.

Low level. Specific, detailed, and concrete, as in "low-level design" or "low-level milestones".


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Make files. See Software build instructions (make files).

Maintainability. The ease with which a software system can be modified to change or add capabilities, improve performance, or correct defects.

Miniature milestone. A task that takes a few days or less to perform, and for project tracking purposes, is considered to be either done or not done, but never partially done. Miniature milestones are also called "inch pebbles", and "microstones".

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Object-oriented design. An approach to software design that makes use of object-oriented programming concepts.

Object-oriented programming. A kind of computer programming that focuses on building computer programs from collections of objects (amalgamations of data and operations on data that are treated as unified entities). Programming languages that support object-oriented programming include C++, Java, and Smalltalk.


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

People-aware management accountability. The practice of holding managers accountable for the condition of the human resources on their projects, especially for whether people emerge from their projects worth more or less to their organizations.

Phase. A period during which a project team focuses primarily on a specific kind of work, such as the requirements development, architecture, construction, and release phases. Compare Stage.

Planning Checkpoint Review. A review held about 10 to 20 percent of the way through a software project to determine whether the project planning, requirements development, and initial architecture work is sufficient to support development of the rest of the software. A go/no go decision is made during this review.

Postmortem. A phase at the end of a software project during which project team members evaluate the project and learn lessons that can be applied to the next project. "Postmortem" also refers to the report created during the postmortem phase.

Programming. The general activity of software development, especially construction activities. Compare Construction.

Project tracking. Monitoring the status of a project by regularly comparing actual results to planned results, such as comparing the actual schedule and budget to the planned schedule and budget, or the actual functionality present to the required functionality.

Prototype, n. See User Interface Prototype.

Prototype, v. A development technique in which a preliminary version of a program or subprogram is developed to facilitate user feedback or examine other development issues.

Pseudocode. English-like statements that are used for low-level program design.


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Quality assurance (QA). A planned and systematic pattern of activities designed to ensure that a system has the desired characteristics.

Quality Assurance Plan. The document that describes the specific quality assurance practices a software project intends to use.


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Readability. The ease with which a person can read and understand the source code of a system, especially at the detailed statement level.

Real-time software. The kind of software that deals with systems that must operate within a time frame determined by external constraints. Typical real-time systems include avionics and manufacturing control programs. Compare Applications programs, Information systems, Shrink-wrap software, and Systems software.

Release. The delivery of software to users who are outside the group that is responsible for the development of the software. Software can be released by developers to a testing group, to internal users, or to external customers. "Release" and "delivery" are used interchangeably. Compare Acceptance, Build, and Delivery.

Release Checklist. A form containing a list of activities that should be performed during the release phase of a project to prevent software that is not ready to be released from being released.

Release Sign-off Form. A form that project stakeholders sign to record their agreement that a software program is ready to be released to the customer.

Requirements. A detailed description of what the software is supposed to do. Compare Requirements development and User Manual/Requirements Specification.

Requirements analysis. See Requirements development.

Requirements development. The software development phase during which user needs are explored and both the users and the development team acquire a detailed understanding of what software should be created.

Requirements specification. 1. The document that contains statements of requirements. 2. The activity of committing requirements to writing. 3. The phase during which requirements are explored and developed. See Requirements development.

Requirements traceability. The ability to determine for each requirement which parts of the system's architecture, design, and implementation were created to satisfy that requirement and vice versa.

Reusability. The extent to and ease with which parts of a system can be put to use in other systems.

Review. See Technical review.

Revision control. Archival and retrieval of specific works products, usually stored in electronic form, through an automated system. Compare Change control and Source-code control.

Risk. An undesirable outcome.


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Shrink-wrap software. The kind of software developed for the mass market and sold in retail stores, such as word processors, spreadsheets, and project planners. Compare Applications programs, Information systems, Real-time software, and Systems software.

Smoke test. See Daily build and smoke test.

Software architecture Document. The document that describes a program's architectural design. Compare Architecture.

Software build instructions (make files). The scripts and other instructions that software developers use to automate the process of converting source code into executable software.

Software Construction Plan. A plan that describes how a specific software component will be created, including miniature milestones.

Software Development Plan. The document that describes how a software project will be conducted. The project plan includes schedules, budgets, estimates, and technical methodologies; it is updated to include detailed plans for each phase throughout the project.

Software Integration Procedure. The sequence of steps that developers must follow when they combine newly developed code with code that has already been integrated.

Software Project History document. The document that summarizes the course of the project and the lessons learned by the project team during the project. Also called the Software Project History.

Software Project Log. A record book or document in which project characteristics are regularly recorded, including staff hours, defect counts, lines of code, and so on.

Software release. See Release.

Software test case. See Test case.

Source code control. The specific kind of revision control used to control source code. See Revision control.

Source code tracing. The activity of stepping through source code line by line in a symbolic debugger for the purpose of watching the program flow, observing changes in variables, and determining whether the source code operates as intended.

Source code. The detailed, human readable instructions that directly or indirectly describe to the computer how a software system should operate.

Specification. Synonym for "requirements". Occasionally refers to architecture, but that use is nonstandard.

Stage. A period during a staged delivery project that includes the activities of detailed design, construction, test, and delivery. A stage is essentially a project in miniature. Compare Phase.

Staged delivery cycle. See Stage.

Staged Delivery Plan. A plan that specifies during which stage of a staged delivery project each detailed requirement will be delivered.

Staged delivery project. A project that performs requirements development and architecture for a whole system, then delivers the software in multiple stages, driving the software to a quality level at the end of each stage sufficient to release the software to end users, if desired.

Staged delivery. A delivery made at the end of a stage. Compare Delivery and Stage.

System. Generally, a whole program. Sometimes used more specifically to refer to operating-system level code.

System test. Systematic exercise of an entire program for the purpose of finding defects.

Systems software. The kind of software for use by the computer itself or by software developers, including operating systems, device drivers, compilers, and so on. Compare Applications programs, Information systems, Real-time software, and Shrink-wrap software.


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Technical review. A catchall term for inspections, walkthroughs, code reading, and other practices in which one or more persons examines the work of another person for the purpose of improving its quality.

Test. Execution of a program for the purpose of finding defects.

Test case. A description of inputs, execution instructions, and expected results, which are created for the purpose of determining whether a specific software feature works correctly or a specific requirement has been satisfied.

Top 10 Risks List. A document that describes the most significant risks to a project in priority order and that is updated about twice a month.

Top level. The most general, broad, and abstract, as in "top-level design" or "top-level milestones". Compare High level.

Tracking. See Project tracking.


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Understandability. The ease with which a system can be comprehended at both the system organizational and detailed statement levels. Understandability has to do with the coherence of the system at a more general level than readability. Compare Readability.

Unified Modeling Language (UML). A diagrammatic convention for expressing the kind of software design that is known as object-oriented design.

Unit test. Execution of individual routines and modules by the developer or by an independent tester for the purpose of finding defects.

Upstream. Usually refers to requirements development and architecture, but can also refer to any part of a software project that precedes any other particular part. Compare Downstream.

User interface. The visible part of a program including menus, dialog boxes, and other on-screen elements.

User Interface Prototype. A mockup of software under development that is created for the purpose of eliciting user feedback about the software's intended functionality and look and feel.

User Interface Style Guide. A document that specifies the way that the software should look and feel and guides detailed user-interface development.

User Manual/Requirements Specification. A document created during the requirements development phase that is used both as end-user documentation and as a specification of the software's requirements.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Visibility. The ease and accuracy with which it is possible to assess the status of a project's cost, schedule, functionality, or other characteristics. Compare Control.

Vision statement. A description of the highest level objective of the project.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Walkthrough. A relatively informal review technique in which a developer leads members of a review team through a design or code and the review team identifies possible problems and improvements.

Work product. The tangible result of work performed. Examples of work products include executable software, documents and test cases.