HOME _________ BIO ________ COURSES _________ PUBLICATIONS __________ GLOSSARY __________ CONTACT
 
 
a
     
Glossary    

A-C | D-L | M-Q | R | S | T-Z

 

maintenance engineer -- Software engineers who perform software maintenance on system/software systems.

maintenance manual -- A software engineering project deliverable document used by the maintenance personnel of the system (in contrast to the users) to enable them to maintain the system.  Contrast with operator's manual, users' manual.

maintenance plan -- A document that identifies the management and technical approach to be used in maintaining software products.  Typically included are topics such as tools, resources, facilities, and schedules.  [ANSI/IEEE Std 830-1998]  

maintenance project -- A software development project described as maintenance to correct errors in the original requirements specification

management review -- A review to determine the project status as it applies to project plans, schedules, budget, staffing, training, and so forth.  The monetary expenditures are compared with the budget, and differences between the budget estimates and actual project expenditures are explained.  The completion dates are compared with the master schedule, and differences between the scheduled completion dates and actual completion dates are explained.  

mapping -- Establishing a sequence of the activities in this standard according to a selected software life cycle model (SLCM).  See also instance; invocation; iteration, software life cycle model (SLCM).  [IEEE Stds Glossary]

mean time to repair (MTTR) -- The average time required by the maintenance team to implement a change and restore the system to working order to calculate MTTR.

milestone --A scheduled event used to measure progress.  Examples of major milestones for software projects may include an acquirer or managerial sign-off, baselining of a specification, completion of system integration, and product delivery.  Minor milestones might include baselining of a software module or completion of a chapter of the users' manual.  See also event.

milestone review -- (1).  A project management review that is conducted at the completion of each of the hardware/software development lifecycle phases (a milestone), such as -- requirements phase, preliminary design, detailed design phase, implementation phase, test phase, and sometimes installation and checkout phase.  For example, a detailed design review (DDR) is held at the completion of the detailed design phase.  (2). A formal review of the management and technical progress of a hardware/software development project.  See also physical configuration audit (PCA), preliminary design review (PDR), software specification review (SSR), system design review (SDR), system requirements review (SRR), test readiness review (TRR).  See also review.

minimum attractive rate of return (MARR) -- The rate of return that the organization considers to be the minimum before it will be interested in any investment; an expression of the rate of return that the organization is confident it can achieve through typical activities.  It represents the organization’s opportunity cost and is the interest rate used in business decision analysis.  [steve.tockey@construx.com]

minimum tasks -- Those V&V tasks required for the software integrity level assigned to the software to be verified and validated.  [IEEE Stds Glossary]

MM -- Acronym for maintenance manual. 

model -- A semantically closed abstraction of a system or a complete description of a system from a particular perspective.  Examples include use case, architecture, and domain models and code.  [geri@wyyzzk.com]

moderator -- In an inspection, the individual that is responsible for administrative tasks pertaining to the inspection, for planning and preparation of the inspection or walkthrough, ensures that the inspection is conducted in an orderly manner and meets its objectives, is responsible for collecting inspection data (if appropriate), and issues the inspection report.  [IEEE Std 1028-1997] 

modification request (MR) -- A generic term that includes the forms associated with the various trouble/problem-reporting documents (e.g., incident report, trouble report) and the configuration change control documents [e.g., software change request (SCR)].  [IEEE Stds Glossary]

modularity -- Those attributes of the software that provide a structure of highly independent modules.  [McCall, Richards, and Walters, RADC, 1977]

MP -- Acronym for maintenance plan.  [IEEE Stds Glossary]

MR -- Acronym for modification request.  [IEEE Stds Glossary]

MTTR – Acronym for mean time to repair.

nonfunctional requirement -- A software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes.  Nonfunctional requirements are sometimes difficult to test; therefore, they are usually evaluated subjectively.  Contrast with functional requirement.  Sometime referred to as design constraints.

object -- An entity that you can change or affect.  An object has state, behavior, and identity.  A group of objects with common structure and behavior is a class.  An instance of a class is an object.  See also object-oriented design.

Object Management Group (OMG) -- An international standards organization that owns and maintains CORBA and UML standards.  [geri@wyyzzk.com]

object-oriented design (OOD) -- A software development technique in which a system or component is expressed in terms of objects and connections between those objects.  [IEEE Std 610.12-1990]  Contrast with function-oriented design and data-structure-oriented design.

OOD -- Acronym for object-oriented design.

OPA -- Acronym for organizational process asset.  [IEEE Stds Glossary]

operation and maintenance phase -- The period in the software life cycle during which a software product is employed in its operational environment, monitored for satisfactory performance, and modified as necessary to correct problems or respond to changing requirements

opportunity cost -- The implicit cost associated with investing money in a certain activity.  Making that investment means that the same money cannot be invested elsewhere, where it might earn a higher interest rate.  [steve.tockey@construx.com]

optimization analysis -- A form of decision analysis that balances competing components to achieve the best performance.  Software’s classic space-time trade-off is an example of optimization; an algorithm that runs faster will typically use more memory.  Optimization balances the faster runtime’s value against the additional memory’s cost.  [steve.tockey@construx.com]

optional tasks -- Those V&V tasks that may be added to the minimum V&V tasks to address specific application requirements.  [IEEE Stds Glossary]

organizational process asset (OPA) -- An artifact that defines some portion of an organization’s software project environment.  [IEEE Stds Glossary]

pass/fail criteria -- Decision rules used to determine whether a software item or a software feature passes or fails a test.  [IEEE Stds Glossary]

PCA -- Acronym for physical configuration audit.  [IEEE Stds Glossary]

PDL -- Acronym for program design language.  [IEEE Stds Glossary]

PDR – Acronym for preliminary design review

peer reviews -- A semiformal to formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group other than the originator to detect faults, violations of development standards, and other problems.  The review members are peers (equals) of the designer or programmer.  Traditional error data is collected during inspections to be analyzed later and to assist in future inspections.  A peer review is sometimes called a walkthrough or inspection.

perfective maintenance -- Modification of a software product after delivery to improve performance or maintainability.  [IEEE Stds Glossary]

performance requirement -- A system/software system requirement specifying a performance characteristic that a system/software system or system/software component must possess; for example, speed, accuracy, and frequency.

physical configuration audit (PCA) -- (1) The formal examination of the configuration of a hardware/software configuration item against its technical documentation to establish the product or operational baseline.  [Military Standard 1521B-1985]  [U.S. Department of Defense (DoD) usage]  (2) An audit of the product specification and an inspection of the format and completeness of the user's manual and other manuals or handbooks due for acceptance at this time.

point design -- The selection of one design that satisfies the requirements without examining other potentially more effective designs.

post condition -- A constraint that must be true when a use case has ended. 

PR&RPI -- Acronyms for problem reporting and resolution planned information.  [IEEE Stds Glossary]

precondition -- A constraint that must be true when a use case is invoked.

preliminary design -- See architectural design.

preliminary design review (PDR) -- This review has been mostly replaced by architectural design review.  See architectural design review.  

present worth -- The basis for comparison that translates a cash flow stream into an equivalent single cash-flow instance at the beginning of the planning horizon.  [steve.tockey@construx.com]

preventive maintenance -- (1) Designing a software system that is easy to maintain.  (2) The continuous upgrading of a system to enable the system to cope with current and future changes

problem -- A negative situation to overcome.  A risk factor becomes a problem when a risk metric (an objective measure) crosses a predetermined threshold (the problem trigger).  [d.fairley@computer.org]

process architect -- The person or group that has primary responsibility for creating and maintaining the software life cycle process (SLCP).  See also software life cycle process (SLCP).  [IEEE Stds Glossary]

process model --A representation of a system/software development process activity intended to explain the behavior of some aspects of it.  The process model is less complex or complete than the activity or artifact modeled.  Also, know as a life cycle model.

product -- Any output of the software development activities (e.g., document, code, or model).  See also activity.  [IEEE Stds Glossary]

product baseline -- The “final” hardware/software configuration identification established at the end of the development phase. 

program design language (PDL) -- A specification language with special constructs and, sometimes, verification protocols, used to develop, analyze, and document a program design.  See also pseudocode.  [IEEE Std 610.12-1990]

program librarian – (1) An individual who administers the project library.  (2) The person responsible for establishing, controlling, and maintaining a software development library.  (3) An individual who acts as an  administrator, secretary, and librarian for many teams and who maintains and controls all elements of the software configuration, for example, documentation, source listings, and data catalogs, and indexes "reusable" software models.  The librarian also assists the team in research, evaluation, and document preparation.  

program support librarian (PSL) -- See program librarian.

project -- A subsystem that is subject to maintenance activity.  [IEEE Stds Glossary]

project agreement --A document or set of documents baselined by the acquirer and the supplier that specifies the conditions under which the project will be conducted.  A project agreement may include items such as the scope, objectives, assumptions, management interfaces, risks, staffing plan, resource requirements, price, schedule, resource and budget allocations, project deliverables, and acceptance criteria for the project deliverables.  Project agreements are very often defined in the contract statement of work.

project deliverable --A work product to be delivered to the acquirer.  Quantities, delivery dates, and delivery locations are specified in a project agreement.  Project deliverables may include the following.  operational requirements, functional specifications, design documentation, source code, object code, test results, installation instructions, training aids, users' manuals, product development tools, and maintenance documentation.  Project deliverables may be self-contained or may be part of a larger system's deliverables.

project plan -- See software project management plan.

pseudocode -- A general term for structured English or program design language.

PSL – Acronym for program support librarian.

quality attribute (requirement) -- A requirement that specifies the degree of an attribute that affects the quality that the system/software must possess; for example, reliability, maintainability, usability, etc.  See also software quality attribute (requirement). 

 

STORE
CSDP DVD
books
       
           
 

home | bio | courses | publications | glossary | contact | store


site and all contents © 2005 Richard H. Thayer, all rights reserved