Term
|
Definition
| A discipline concerned with the scientific study and description of algorithms, programs, the devices that interpret them, and the phenomena surrounding their creation and usage. |
|
|
Term
|
Definition
| The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. |
|
|
Term
|
Definition
| Algorithms for developing software: A set of activities, methods, practices, and transformations that people employ to develop and maintain software and the associated products. |
|
|
Term
|
Definition
| A sequence of steps performed for a given purpose; the execution of a process model. The process integrates people, tools, and procedures. |
|
|
Term
|
Definition
| A set of activities, methods, practices, and transformations that people employ to develop and maintain software and the associated products (documents, etc.); ; the execution of a software process model. |
|
|
Term
| Waterfall Model (System Requirements) |
|
Definition
| The system concept is defined, customer and client requirements are captured, hardware and software components defined and mapped. |
|
|
Term
|
Definition
| a formal (complete, precise, consistent, and unambiguous) description of “what” each software component must do is prepared by the developer and reviewed by the customer (software specification document); a software project plan is produced at the end of this phase. |
|
|
Term
|
Definition
| The specification is elaborated in two steps that define “how” the product will work: Architectural Design breaks down the whole system into component parts (modules) and the interactions between them (interfaces); Detailed Design involves elaborating the design of individual components by specifying data structures and algorithms. |
|
|
Term
|
Definition
Software module designs are translated to code and then unit tested.
Integration & Test: Software modules are integrated into larger functional aggregates (subsystems) and tested in the operational environment. The final step tests the complete system (acceptance testing or validation – customer agrees that the system meets the specification). |
|
|
Term
| Installation and Maintenance |
|
Definition
| The completed system is installed in the operational environment and maintained (error correction and enhancement) for the remainder of the system lifetime. |
|
|
Term
|
Definition
| A cyclic approach to software development marked by four basic stages that are repeated on each cycle until the target system is delivered. A risk-driven meta model developed by Barry Boehm. Stage 1: Identify objectives, alternative solutions, and constraints for the part of the system currently under consideration. |
|
|
Term
| Unified Process Model Elicitation |
|
Definition
| A phase of the Unified Software Process that develops an initial description of the proposed system from the client’s and end-user perspective. |
|
|
Term
|
Definition
| A phase of the Unified Software Process that produces a Software Requirements Specification giving a high-level internal view of the system architecture. |
|
|
Term
|
Definition
| A sequence of actions a proposed system performs to offer some results of value to a User. |
|
|
Term
|
Definition
| A system has many types of users. Each type of user is defined by an actor. Actors may be people or external systems. Actors interact with the product via one or more Use Cases. An actor role is defined by a particular set of use cases performed by that actor to accomplish a particular goal or objective. |
|
|
Term
|
Definition
| A type of UML diagram that illustrates the flow of interactions between the given system and the actors that participate in a given use case. |
|
|
Term
|
Definition
| A model produced by the Unified Process that defines the system boundary, external actors and interfaces, and system functionality from the users’ perspective. |
|
|
Term
|
Definition
| A model produced by the Unified Process that defines the internal system architecture, allocates functionality to system classes and objects, and establishes a solution baseline. |
|
|
Term
|
Definition
| A model produced by the Unified Process that defines a blueprint for implementation for system implementation; an abstraction of the solution that maps 1-1 with some implementation language. |
|
|
Term
|
Definition
| Characterized by: Functional decomposition, use of procedural abstraction for information hiding, no data encapsulation, reusability only at the application level – no reusable modules. Implemented in C. |
|
|
Term
|
Definition
| Characterized by: Functional decomposition, use of procedural abstraction for information hiding, use of OO techniques such as data encapsulation and abstraction with incomplete information hiding, reusability of the Vector ADT. Implemented in C. |
|
|
Term
|
Definition
| Characterized by: Functional decomposition, use of procedural abstraction for information hiding, use of data encapsulation and abstraction with language-enforced information hiding, reusability of the Vector Class. Implemented in C++. |
|
|
Term
|
Definition
| Characterized by: Object-Oriented decomposition, significant use of reusable classes and packages. |
|
|
Term
|
Definition
| ) A frame of mind and set of concepts that permit the designer to reason about the problem and its solution at some level of generalization that disregards irrelevant details – it organizes the problem and its solution into various strata of concepts, entities and their logical relationships. |
|
|
Term
|
Definition
| A kind of abstraction that assigns a name, perhaps with defined parameters, to a well-defined and reusable computational process or algorithm. This allows the designer to reason in terms of inputs and results of the named computation without having to think about the details of how the computation will be accomplished or implemented. |
|
|
Term
|
Definition
| A kind of abstraction that assigns a name (a new type) to a collection of related data elements and a set of operations for manipulating those data. This allows the designer to treat as one conceptual unit a data structure and the procedural abstractions that manipulate that structure without having to worry about the details of how the data structure and its operations will eventually be implemented. |
|
|
Term
|
Definition
| A separately named and addressable software unit that encapsulates and abstracts a set of related software capabilities and features. It generally consists of two parts: an interface – for access by similar software units, and an implementation – that specifies how the capabilities and features of the interface are realized. |
|
|
Term
|
Definition
| A kind of design property that exploits language mechanisms and encapsulation techniques to hide details about the representation of data structures and types for the purpose of making it increasingly difficult, if not impossible, for clients of a data type or structure to directly access and manipulate the internal content or composition of that type or structure. |
|
|
Term
|
Definition
| A type of design activity that focuses on the enumeration of all the relevant modules (logical organizational units) and components (processing units), their functionality and data processing responsibilities, their inter-dependencies, connectivity and/or communication relationships with other architectural units. |
|
|
Term
|
Definition
| A type of design activity that focuses on enumerating all relevant information elements that must be handled by the system together with specifying the relationships that must be defined, created and maintained among these elements. Examples: composition, aggregation, association, specialization, generalization, and multiplicity are relationships used in object-oriented design methods. |
|
|
Term
|
Definition
| A type of design activity that focuses on the mechanism enabling two or more architectural units to exchange data with each other or interact in some way. This activity must specify the data content exchanged, the direction of flow, timing constraints, interaction protocols, and mechanism for communication (e.g., hardware signal, hardware registers, shared variables, data file, database record or relation, gui). |
|
|
Term
| Component and Module Design |
|
Definition
| A type of design activity that focuses on the internal data structures and algorithms required for a given architectural unit to satisfy all its interface, functional, and non-functional requirements within a given operation context. |
|
|
Term
|
Definition
| A kind of software module or model that abstracts something in the domain of a problem or its implementation, reflecting the capabilities of a system to keep information about it, interact with it, or both; an encapsulation of attribute values and their exclusive services. |
|
|
Term
|
Definition
| A collection of objects offering a common set of services and possessing a common set of data attributes. It defines or characterizes a new “data type” in the problem or solution domain. |
|
|
Term
|
Definition
| A mechanism and information structure for transmitting both control and data between objects. |
|
|
Term
|
Definition
| Used during requirements analysis and specification to model interaction between the system and its actors! This interaction often involves receiving and presenting information and/or requests. These modules collect and encapsulate requirements defining external system interfaces - if these change, only modules of this kind will need to be changed. |
|
|
Term
|
Definition
| Used during requirements analysis and specification to model information that is long-lived and often persistent. They model information and behavior of some phenomenon or concept such as an individual, a real-life object or event. |
|
|
Term
|
Definition
| Used during requirements analysis and specification to model modules that monitor and otherwise manage or coordinate, sequencing, transactions, and control of other objects and are often used to encapsulate a control (thread) related to a specific use cases. They are used to encapsulate complex computations or business logic that cannot be logically associated with any other kind of analysis module. |
|
|
Term
|
Definition
| A type of UML diagram used to express the static structure of an OO software design in terms of its modular components and their relationships. |
|
|
Term
|
Definition
| A type of UML diagram used to express the dynamic interactions among objects and actors participating in a use case. |
|
|
Term
|
Definition
| A type of UML diagram used to express the execution time flow of messages and method calls among objects at the detailed design level. |
|
|
Term
|
Definition
| A type of UML diagram used to express the control flow among processes and use cases at the system level, or the flow of control of algorithmic steps in a method or procedure at the detailed design level. |
|
|
Term
| Generalize-Specialize (Is-A) Relation |
|
Definition
| A relationship between two classes in an object-oriented design (Class Diagram) that states, if B Specializes A (A Generalizes B), every instance of B is also an instance of A. |
|
|
Term
|
Definition
| A Whole-Part relation between objects or class instances. It indicates Parts that are essential or required constituents of the Whole necessary to make the Whole function properly. The Parts have no meaning or independent existence outside the context of the Whole. |
|
|
Term
|
Definition
| A Whole-Part relation between objects or class instances, where the Whole represents a container or organizational unit holding the Parts. The Parts can have meaning and can exit outside their relationship to the Whole. |
|
|
Term
|
Definition
| A relationship between an Actor and a Use Case in a Use Case Diagram representing a bi-directional interaction and flow of data. In the context of a Class Diagram, this relationship describes some type of interaction or dependency between two objects or class instances. |
|
|
Term
| Specialize(Generalize) Relation |
|
Definition
| A relationship between two use cases in a use case diagram that states if B Specializes A (A Generalizes B) B is a specific method for realizing A. |
|
|
Term
|
Definition
| A relationship between two use cases that indicates one is a required sub-step of the other. |
|
|
Term
|
Definition
| A relationship between two use cases that indicates one is a functional extension of the other – defining an optional sub-step of the other. |
|
|
Term
|
Definition
| A relationship between two use cases that indicates one is a required sub-step of the other, where the sub-step is shared by two or more major use cases. It implies the includes relation, but is unique in that the sub-use case is factored out for reuse by other major use cases. |
|
|
Term
|
Definition
| Software flaws uncovered after delivery of a given system to its end-users. |
|
|
Term
|
Definition
| A quantitative indication of the extent, amount, dimensions, capacity, or size of some attribute of a product or process. |
|
|
Term
|
Definition
| A quantitative measure of the degree to which a system, component, or process possesses a given attribute. |
|
|
Term
|
Definition
| A measure of software size and complexity based on the number of distinct independent control flow paths through a given method or procedure. |
|
|
Term
|
Definition
| A measure of software size and complexity based on counts of the number of distinct operators and operands required to express an algorithm or procedure. |
|
|
Term
| Predictive Metric(Indicator) |
|
Definition
| A metric applied during development and used to predict the values of a software quality factor. |
|
|
Term
|
Definition
| The act or process of ensuring that a metric reliably predicts or assesses a quality factor. |
|
|
Term
| Quality Metrics Framework |
|
Definition
| A decision aid used for organizing, selecting, communicating, and evaluating the required quality attributes for a software system. A hierarchical breakdown of quality factors, quality subfactors, and metrics for a software system. |
|
|
Term
|
Definition
| Software flaws uncovered before delivery to customer and end-users. |
|
|
Term
|
Definition
| Software flaws uncovered after delivery to customer and end-users. |
|
|
Term
|
Definition
| A software test activity designed to evaluate whether or not products of a given development activity conform to the specifications used to build those products. |
|
|
Term
|
Definition
| A test activity designed to evaluate whether or not a given software product satisfies user requirements – that is, solves the problem it was designed to solve. |
|
|
Term
|
Definition
| A tree-like structure used to document the various causes contributing to errors or defects of a given type. |
|
|
Term
|
Definition
| Demonstrating correct component or subsystem behavior by observing outputs generated at its interface as a function of inputs supplied at its interface. |
|
|
Term
|
Definition
| Demonstrating that valid computational paths and interactions are observed internal to a component or subsystem as a function of given inputs. |
|
|
Term
|
Definition
| Tests that attempt to cause the system to fail by presenting inputs or loads for which it was not designed. |
|
|
Term
|
Definition
| Tests that attempt to expose system performance problems when certain computational resources approach their design limits. |
|
|
Term
|
Definition
| After a change is made to a component, the process of re-running tests that the component had successfully passed before the change was made to ensure that previous capability remains verified. |
|
|
Term
|
Definition
Test Components automate one or several test procedures or parts of them.
Examples include: Test drivers, Test scripts and Test harnesses. |
|
|
Term
|
Definition
| Describes testing requirements, strategies, resources, and schedule for each build and system release. Describes what test cases should be performed and passed for each build and/or system release. |
|
|
Term
|
Definition
| Capture results of test cases; declares whether or not test case was successful; generates defect or anomaly reports for tracking. |
|
|
Term
|
Definition
| Document abnormal or unexpected test outcomes or events. Used to capture and track test anomalies during development. Developer must ensure all anomalies have been satisfactorily addressed or removed before delivery (customer signoff). |
|
|
Term
|
Definition
| Answer the question: Why do the features called out by the testing technique warrant our effort? A fault model therefore identifies the relationships and components of the system under test that are most likely to have faults. |
|
|
Term
| Conformance Directed Testing |
|
Definition
| Seeks to establish conformance to requirements and specifications. Employs a non-specific fault model – any fault that violates conformance is equal to any other in importance or significance. |
|
|
Term
|
Definition
| Seeks to reveal implementation faults of a particular kind or type. It is motivated by the observation that conformance can be demonstrated for an implementation that contains faults. Employs a specific fault model – directs testing toward particular kinds of faults. |
|
|
Term
| Test and Organization Stages (Pleeger) (Part 1) |
|
Definition
| 1. Module (Component)(Unit) Testing – testing the smallest software building blocks in a controlled environment to meet functional requirements. 2. Integration Testing – testing component aggregates to ensure interface requirements are met and that inter-module communication works according to design. 3. Function Testing – testing system functionality (use cases) to insure it meets system requirements specifications. |
|
|
Term
| Software Process Capability |
|
Definition
| Describes the range of expected results that can be achieved by following a software process. |
|
|
Term
| Software Process Maturity Level |
|
Definition
| The extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. |
|
|
Term
| CMM Maturity Levels (Part 1) |
|
Definition
| 1. Initial: The software process is characterized by ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics. 2. Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. |
|
|
Term
|
Definition
| Except for level 1, each maturity level is decomposed into several key process areas that indicate where an organization should focus to improve its software process. If an organization is at level K+1 then it has addressed all of the KPAs at levels ≤ K. Each KPA identifies a cluster of activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. |
|
|
Term
| Five Functions of Management (Part 1) |
|
Definition
| (Planning) Predetermining a course of action for accomplishing organizational objectives. (Organizing) Arranging the relationships among work units for the accomplishment of objectives and the granting of responsibility and authority to obtain these objectives. (Staffing) Selecting and training people for positions or roles in the organization. |
|
|
Term
|
Definition
| The overall approach to a project that provides guidance for placin emphasis and using resources to achieve the project objectives. |
|
|
Term
|
Definition
| Directives that guide decision making and project activities. Policies limit the freedom in making decisions but also allow some discretion. |
|
|
Term
|
Definition
| Directives that specify customary methods of handling activities; guides to actions rather than guides to decision making. Procedures detail the exact manner in which a project activity must be accomplished and allow very little discretion. |
|
|
Term
|
Definition
| Requirements for specific and definite actions to be taken or not taken with respect to particular project situations. No discretion is allowed! |
|
|
Term
| Functional Organization (Part 1) |
|
Definition
| Personnel in each organizational unit perform the same function (Systems Engineering)(Software Engineering)(Verification&Validation)(Software Quality Assurrance)– basically they have the same job descriptions although they may vary in experience and leadership roles. |
|
|
Term
| Project Oriented Organization |
|
Definition
| The organization is organized around projects – each project headed by a Project Manager that has the responsibility to hire, discharge, train, and promote people within the project. Each project has its own staff organized around similar personnel functional roles. |
|
|
Term
| Matrix Organization (Part 1) |
|
Definition
| There is a vertical (Column) or functional structure similar to the Functional Organization, but there is a horizontal (Row) structure similar to the Project Organization overlayed on top of the functional structure. Personnel in each functional unit are assigned to work on a given project – some may not be assigned to any project (pool resources). |
|
|
Term
| Mazlow's Hierarchy of Human Needs |
|
Definition
| This is a pyramid structure that characterizes the needs that motivate human behavior. In general, needs at lower levels of the pyramid must be met before needs at higher levels can be met. The levels are (from most basic or fundamental to most noble or liberating ) are: Biological Survival, Safety and Security, Social Needs, Esteem and Recognition, Self Actualization. |
|
|
Term
|
Definition
| An independent examination of a software project for the purpose of determining compliance with plans, specifications, and standards. |
|
|
Term
| Software Quality Assurance |
|
Definition
| A planned and systematic pattern of all actions necessary to provide adequate confidence that the development process and the work products conform to established standards. |
|
|
Term
|
Definition
| A method for controlling and reporting on the status of work products generated by the project. |
|
|
Term
| Verification and Validation |
|
Definition
| The process of assuring that each phase of the development life cycle correctly implements the specifications from the previous phase and that each work product satisfies its requirements. |
|
|
Term
| Walkthroughs and Inspections |
|
Definition
| Systematic examination of software work products by the producer's peers, conducted for the purpose of finding errors. |
|
|
Term
|
Definition
| Stage 2: Evaluate alternatives and identify associated risks using prototyping and simulation. Stage 3: Develop and verify the next system increment. Stage 4: Review outcome of earlier stages and plan the next cycle. |
|
|
Term
| Test Organization and Stages (Pfleeger) (Part 2) |
|
Definition
| 4. Performance Testing – testing speed and capacity of the system to verify the system meets non-functional execution requirements and constraints. (Validation) 5. Acceptance Testing – customer testing to insure that end-users are satisfied that the system meets quality requirements. (Validation) 6. Installation Testing – making sure the system runs in the target environment |
|
|
Term
| CMM Maturity Levels (Part 2) |
|
Definition
| 3. Defined: The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. 4. Managed: Detailed measures of the software process and product quality are collected. 5. Optimizing: Continuous process improvement is enabled by quantitative feedback from the process |
|
|
Term
| Five Functions of Management (Part 2) |
|
Definition
| (Directing) Creating an atmosphere and environment that will assist and motivate people to achieve desired end results. (Controlling) Establishing, measuring, and evaluating performance of activities toward planned objectives. |
|
|
Term
| Functional Organization (Part 2) |
|
Definition
| When a work product is produced or reviewed by members of one organizational unit, it is passed to some other organizational unit for further development or review. There is no single project supervisor over the whole project, although there is a general manager and there is typically a project coordinator and/or customer/user liason. |
|
|
Term
| Matrix Organization (Part 2) |
|
Definition
| Each project (Row) is managed by a Project Manager who has authority over work assignments, but does not have authority to hire, discharge, train, or promote personnel – this authority resides in the manager of each functional unit. This structure is more efficient in its use of human resources but frequently results in management control conflicts. |
|
|
