| Term | Definition |
|---|---|
| AP | Applications Programmers - team members proficient in development and testing of computer code, and development of documentation, according to the project standards & guidelines |
| API | Application Program Interface - specification of the external interface of code objects, including the invocation protocol details for the operations on the objects; most useful for documenting reusable objects |
| API doc markup | Suspected errors in the Application Program Interface documentation noted during documentation validation |
| API documentation | Application Program Interface information formatted as a deliverable product |
| CASwE | Computer Applications Software Engineers - team members proficient in development of all software life cycle products according to the project standards & guidelines |
| CM | Configuration Management - contol of software versioning and releases |
| CM'd application | The deliverable application program stored in the Configuration Management system |
| CM'd reusable classes | Deliverable reusable classes stored in the Configuration Management system |
| COTS | Commercial Off The Shelf Software - software that can be purchased (or obtained for free) rather than created internally |
| COTS Vendor | A provider of Commercial Off The Shelf Software |
| COTS candidates list | A list of Commercial Off The Shelf Software to be evaluated, including name of vendor, name of tool, and vendor contact information |
| COTS cost | The cost of Commercial Off The Shelf Software |
| COTS cost vs build cost | A comparison of the cost of Commercial Off The Shelf Software and the estimated cost to build software having the same preliminary requirements |
| COTS eval | A comparison of the capabilities of Commercial Off The Shelf Software software candidates and the preliminary requirements by which the candidates are being evaluated. |
| COTS info | All information regarding Commercial Off The Shelf Software of use in the Build versus Buy process, including COTS Vendor, COTS cost, and COTS features |
| COTS sw features | The capabilities of Commercial Off The Shelf Software software |
| Department processes | Process charts for customer organizations. |
| Detailed Requirements | software requirements specified for building custom software according to the project standards and guidelines |
| EPS | Electronic publishing specialists |
| PDL | Program Design Language - also called "pseudo-code"; short descriptive natural language phrases and syntactically structured logic statements that describe required behavior |
| POC | Point of Contact - individual in a customer organization who acts as liaison to the development project |
| Prelim Sw Requirements | software requirements specified for Build versus Buy analysis according to the project standards and guidelines |
| SDP | Software Development Process -- the process documented herein |
| UI design | A detailed design for the human user interface for the software being built, initially captured using functionality screens |
| annotated bug reports | Bug reports with status information recorded in the appropriate fields of the bug report |
| annotated change requests | Feature requests with status information recorded in the appropriate fields of the report form |
| appropriate development task | The task of this software development process that needs to be performed to fix a reported bug. |
| automation candidates | Tasks of the customer organization process, the automation of which would be of most benefit to the customer organization |
| behavior table | A specification of the required response behavior of a software application to each of the stimuli of one stimulus set |
| black box information | Requirements information, specifically: the external interface to human users, external system users, and the environment; the stimulus-response behavior of the external interface; the look and feel of the interface to humans; the protocols and formats of the interface to external systems (including external files and data bases) and the environment. Does not include software system usage information, e.g., use cases or usage scenarios, which are process information not external interface specification information. Interface usage information is logically part of the customer organization process model and/or the user manual. |
| bt | See behavior tables |
| bug report | Description of a suspected error in an application program or its documentation, as submitted by a user organization. |
| build cost estimate | Estimated cost to build software having specified preliminary requirements |
| buy-build-drop list | List of automation candidates annotated with the results of the Build versus Buy analysis indicating which candidates will be built, which will be bought, and which will be dropped (rejected from further consideration). |
| candidate priority | Ranking of automation candidates with respect to their score in the Build versus Buy analysis. Candidates are scored as specified in the project standards and guidelines. |
| capability requirements | The functionality required by the software, expressed in terms of stimuli and their responses that define the external interface to the software system black box. |
| change request | Description of a desired new or modified feature for an existing application program, or a description of a new application program, as submitted by a user organization. |
| class interface spec | An Object Design notation for capturing the interface to a software module black box. The class interface spec is suitable as input to a generative tool for automatic creation of skeletal code, skeletal test cases, API documentation, and skeletal user documentation. |
| class list | The list of Java classes that must be built, as identified during Object Design. |
| client dept process | The process charts of the customer organization which the customer wishes to partially or completely automate. |
| client staff | Personnel of a customer organization who will be users of the application program being acquired (built or bought). |
| client stds & guidelines | Standards and guidelines of the customer organization which the customer wishes to partially or completely automate. |
| commented source code | Java or other computer code for an application program, including language statements and full explanatory comments, produced during Implementation & Test. |
| commented test code | Java or other computer code for the regression tests of an application program, including language statements and full explanatory comments, produced during Implementation & Test. |
| common service objects | Objects or classes in an application program that support the generation of response behavior for functionality objects and encapsulate design decisions such as data structures and algorithms, or interfaces to hardware |
| department heads | The manager of the customer organization and the manager of the development team. |
| department process metrics | Quantitative data reflective of the efficiency and/or productivity of a customer organization by which process improvement decisions, including process automation decisions, may be made. |
| department processes | Flow charts depicting the customer organization business process to be fully or partially automated. |
| design | The gray box view of the software system; i.e., those aspects of the software system that lie within the software system black box but outside the black boxes of the individual modules. |
| design constraints | Information about the internals of the software system black box that appears in a requirements specification due to this information being specified by the customer organization. |
| detailed requirements | See Detailed Requirements |
| extended bt | extended behavior table - A behavior table with two additional columns appended for capturing objects and their operations needed to support the specified response behavior |
| extended operation/method behavior table | An operation/method behavior table with two additional columns appended for capturing objects and their operations needed to support the specified response behavior |
| functionality requirements | See capability requirements |
| functionality object | An object or class in an application program that encapsulates a single stimulus set, including all stimulus detection mechanisms and generation of the associated required response behavior as specified in the associated behavior table |
| functionality screens | Sketches of the human user interface of the software system. |
| functionality tree | A horizontal tree-like notation used for recording stimulus sets and their organization according to the triggering (new stimulus) relationship. |
| gray box information | Design information, specifically: identification of code module names and type of information to be encapsulated in the code modules, code module relationships (composition, inheritance, polymorphism. and association/uses), specification of code module stable interfaces and external behavior. |
| header comments | Comments appearing at the beginning of the source code for a class or method that describes the purpose, assumptions, quality requirement tradeoffs, input/output variable semantics, and other background information underlying the class or method |
| hosting requirements | A list of platforms and other computing environment particulars on which an application program must operate |
| implementation | The white box view of the software system; i.e., those aspects of the software system that lie within the module black boxes. |
| input/output formats | Formats for reading and writing programmatic and environmental interface communication streams and files. |
| input-output lists | Statement of preliminary requirement capabilities expressed in terms of required application program input and output. |
| install documentation | Documentation describing how to install and configure an application program or reusable component. |
| install doc markup | Suspected errors in the installation documentation noted during documentation validation |
| library archive | One or more Java archive (jar) files containing code, documentation and specificatons for a reusable API, and stored in the reusable library. |
| library archive API doc | API documentation from one or more Java archive (jar) files stored in the reuse library. |
| mockup prototype | Prototype of an application consisting of the human user interface, but little or no functionality, intended to obtain requirements feedback from the customer organization. |
| object code | Compiled source code for an application program and/or its regression tests. For a Java program, obect code consists of class files which may be bundled into a jar file. |
| object model table | An Object Design notation for recording the common service objects (classes) from which an application program will be built, and the relationships among those objects. The relationships typically include composition, inheritance, polymorphism, and association. |
| operation/method behavior table | A specification of the response behavior of each method of a common service object; only methods with behaviors that require services of other common service objects need appear in the table |
| output formats | See input-output formats. |
| performance requirements | Statement in the preliminary requirements of quantitative values for quality requirements such as execution speed, reliability, usability, etc that the application program absolutely must have to be useful to the customer organization for the purpose for which it is intended |
| prelim class list | A listing of all objects (classes) identified in the extended behavior tables. |
| prelim oper list | A listing of all operations on a class identified in the extended behavior tables. |
| prelim sw requirements | Key information about the interface to the software system black box that will serve as evaluation criteria during Build versus Buy analysis. Includes input/output lists, performance requirements, hosting requirements, and any implementation constraints such as required programming language. |
| process metric checklists | A list of work products acquired showing the start and completion dates of their acquisition, as well as the start and completion dates of any revisions. |
| project stds & guidelines | Document detailing the standards and guidelines applicable to project software development |
| quality requirements | Characteristics of the application program as a whole, listed in order of importance, that serve as selection criteria when making development trade off decisions. Types of quality requirements include functionality, reliability, usability, administrability, maintainability, execution speed, and memory demand. |
| release archive | The completed application program and all associated deliverables such as regression tests, user documentation, API documentation, and install documentation. |
| release bt | The subset of the behavior tables of an application program which are to be implemented in a particular release (usually the release currently under development). |
| release group | All stimulus sets and associated behavior tables having the same customer-designated priority and scheduled to be implemented and released together. |
| release ss,bt | The subset of the stimulus sets stimulus sets and their associated behavior tables of an application program which are to be implemented in a particular release (usually the release currently under development). |
| requirements | The black box view of the software system; i.e., those aspects of the software system that are detectable in the external world. |
| reusable bt | The subset of the behavior tables of an application program which are deemed to be of sufficiently general utility to warrant developing their implementing classes as reusable components for inclusion in the reuse library |
| reusable classes | The subset of the classes of an application program which are deemed to be of sufficiently general utility to warrant developing as reusable components for inclusion in the reusable library; includes reusable requirements and reusable design components |
| reusable design components | The subset of the objects in the object model table and their associated object/method behavior tables of an application program which are deemed to be of sufficiently general utility to warrant developing their implementing classes as reusable components for inclusion in the reuse library |
| reusable requirements | The subset of the stimulus sets and their associated behavior tables of an application program which are deemed to be of sufficiently general utility to warrant developing their implementing classes as reusable components for inclusion in the reuse library |
| reuse library | The collection of reusable software components for use on future development projects, including class files in Java archive (jar) format, and their API documentation |
| rqmts changes | Changes to the stimulus sets stimulus sets and/or behavior tables of an application program resulting from customer organization feedback based on client staff using a mockup prototype or otherwise reviewing the requirements |
| software budget | The amount of funds allocated to software acquisition in the current customer budgeting cycle |
| ss | See stimulus sets |
| standards & guidelines | Engineering formulas, design tables, recording notations, design rules of thumb and similar information that guides the development process. Standards are such information when imposed by an outside body or agency with review or inspection authority over the design. Guidelines are such information when developed internally, or adopted voluntarily, by the customer. |
| stimuli | The messages or signals detectable by the system black box. |
| stimulus sets | A stimulus set is a cohesive collection of stimuli in which all the stimuli share functional, physical, and temporal cohesion. |
| test results | The output obtained when running the regression tests associated with an application program. |
| training feedback | Constructive critisism and comments obtained from customer organization staff relative to training received. |
| training materials | Presentations, demonstrations, lab exercises and similar material developed for the purpose of training customer staff in the installation, configuration, and operation of an application program. |
| unit test code | Ad hoc test code written by the implementors of an application program that ensures the code executes successfully for one or more common situations before sending the code to test prsonnel for regression testing |
| user doc markup | Suspected errors in the user documentation noted during documentation validation |
| user documentation | Information in book form (either hard copy format or on-line format) that explains how to use the application program to its intended users. Also called a user manual. |
| white box information | Implementation information. i.e., complete commented source code. |