Software Engineering Definitions
Spring 2007
Software Process and Software Engineering
(Software Engineering) The application of a systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of software; that is, the application of engineering
to software.
(Computer Science) 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.
(Software Process Model) Algorithms for developing software: A set of activities, methods,
practices, and transformations that people employ to develop and maintain software and the
associated products.
(Process) A sequence of steps performed for a given purpose; the execution of a process model.
The process integrates people, tools, and procedures.
(Software Process) 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.
Page 1 of 11
Software Engineering Definitions
Spring 2007
(Water Fall Model)
(System Requirements) The system concept is defined, customer and client requirements are
captured, hardware and software components defined and mapped.
(Software Requirements) 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.
(Design phase) 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.
(Code & Unit) 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).
(Installation & Maintenance) The completed system is installed in the operational environment
and maintained (error correction and enhancement) for the remainder of the system lifetime.
(Spiral Model) 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.
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.
Page 2 of 11
Software Engineering Definitions
Spring 2007
(Unified Process Model)
(Elicitation) A phase of the Unified Software Process that develops an initial description of the
proposed system from the client’s and end-user perspective.
(Elaboration) A phase of the Unified Software Process that produces a Software Requirements
Specification giving a high-level internal view of the system architecture.
(Use Case) A sequence of actions a proposed system performs to offer some results of value to a
User.
(Actor) 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.
(Use Case Diagram) 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.
(Use Case Model) A model produced by the Unified Process that defines the system boundary,
external actors and interfaces, and system functionality from the users’ perspective.
(Analysis Model) 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.
(Design Model) 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.
Design Qualities/Styles Concepts
(Abstraction) 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.
(Procedural Abstraction) 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.
(Data Abstraction) 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.
Page 3 of 11
Software Engineering Definitions
Spring 2007
(Module) 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.
(Information Hiding) 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.
(Architectural Design) 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.
(Data Design) 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.
(Interface Design) 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).
(Component and Module Design) 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.
Page 4 of 11
Software Engineering Definitions
Spring 2007
Object Oriented Development Concepts
(Object) 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.
(Class) 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.
(Messages) A mechanism and information structure for transmitting both control and data
between objects.
(Boundary Classes/Objects) 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.
(Entity Classes/Objects) 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.
(Control Classes/Objects) 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.
UML Concepts
(Class Diagram) 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.
(Collaboration Diagram) A type of UML diagram used to express the dynamic interactions
among objects and actors participating in a use case.
(Sequence Diagram) A type of UML diagram used to express the execution time flow of
messages and method calls among objects at the detailed design level.
(Activity Diagram) 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.
(Generalize-Specialize (Is-A) Relation) A relationship between two classes in an objectoriented design (Class Diagram) that states, if B Specializes A (A Generalizes B), every instance
of B is also an instance of A.
Page 5 of 11
Software Engineering Definitions
Spring 2007
(Composition) 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.
(Aggregation) 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.
(Association) 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.
(Specialize(Generalize) Relation) 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.
(Includes Relation) A relationship between two use cases that indicates one is a required substep of the other.
Software Metrics Concepts
(Software Defects) Software flaws uncovered after delivery of a given system to its end-users.
(Software Measure) A quantitative indication of the extent, amount, dimensions, capacity, or
size of some attribute of a product or process.
(Metric) A quantitative measure of the degree to which a system, component, or process
possesses a given attribute.
(McCabe’s Metric) A measure of software size and complexity based on the number of distinct
independent control flow paths through a given method or procedure.
(Halstead’s Metric) 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.
(Predictive metric (Indicator)) A metric applied during development and used to predict the
values of a software quality factor.
(Metric Validation) The act or process of ensuring that a metric reliably predicts or assesses a
quality factor.
(Quality Metrics Framework) 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.
Page 6 of 11
Software Engineering Definitions
Spring 2007
Software Testing Concepts
(Software Errors) Software flaws uncovered before delivery to customer and end-users.
(Software Defects) Software flaws uncovered after delivery to customer and end-users.
(Software Verification) 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.
(Software Validation) 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.
(Fishbone Diagram) A tree-like structure used to document the various causes contributing to
errors or defects of a given type.
(Black Box Testing) Demonstrating correct component or subsystem behavior by observing
outputs generated at its interface as a function of inputs supplied at its interface.
(White Box Testing) Demonstrating that valid computational paths and interactions are
observed internal to a component or subsystem as a function of given inputs.
(Negative Tests) Tests that attempt to cause the system to fail by presenting inputs or loads for
which it was not designed.
(Stress Tests) Tests that attempt to expose system performance problems when certain
computational resources approach their design limits.
(Regression Testing) 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.
(Test Components) Test Components automate one or several test procedures or parts of them.
Examples include: Test drivers, Test scripts and Test harnesses.
(Test Plan) 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.
(Test Evaluations) Capture results of test cases; declares whether or not test case was
successful; generates defect or anomaly reports for tracking.
(Test Anomaly Reports) 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).
Page 7 of 11
Software Engineering Definitions
Spring 2007
(Fault Models) 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.
(Conformance-Directed Testing) 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.
(Fault-directed testing) 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.
(Test Organization & Stages)/Pfleeger
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.
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
Software Process Improvement Framework Concepts
(Software Process Capability) Decribes the range of expected results that can be achieved by
following a software process.
(Software Process Maturity Level) The extent to which a specific process is explicitly defined,
managed, measured, controlled, and effective.
(Five CMM Maturity Levels)
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.
3. Defined: The software process for both management and engineering activities is
documented, standardized, and integrated into a standard software process for the
organization. All projects use an approved, tailored version of the organization’s standard
software process for developing and maintaining software.
4. Managed: Detailed measures of the software process and product quality are collected.
Both the software process and products are quantitatively understood and controlled.
Page 8 of 11
Software Engineering Definitions
Spring 2007
5. Optimizing: Continuous process improvement is enabled by quantitative feedback from
the process and from piloting innovative ideas and technologies.
(Key Process Areas) 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.
KPAs identify the issues that must be addressed to achieve a desired maturity level. 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.
The KPAs may be considered to be the requirements for achieving a particular maturity level.
Page 9 of 11
Software Engineering Definitions
Spring 2007
Project Management Concepts
(5 Functions of Management)
(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.
(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.
(A Mgmt Strategy) The overall approach to a project that provides guidance for placin
emphasis and using resources to achieve the project objectives.
(A Mgmt Policy) Directives that guide decision making and project activities. Policies limit the
freedom in making decisions but also allow some discretion.
(A Mgmt Procedure) 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.
(A Mgmt Rule) Requirements for specific and definite actions to be taken or not taken with
respect to particular project situations. No discretion is allowed!
(Functional Organization) 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. 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.
(Project Oriented Organization) 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.
(Matrix Organization) 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).
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.
Page 10 of 11
Software Engineering Definitions
Spring 2007
( Mazlow’s Hierarchy of Human Needs) 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.
(Auditing) An independent examination of a software project for the purpose of determining
compliance with plans, specifications, and standards.
(Software Quality Assurance) 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.
(Configuration Management) A method for controlling and reporting on the status of work
products generated by the project.
(Verification & Validation) 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.
(Walkthroughs & Inspections) Systematic examination of software work products by the
producer's peers, conducted for the purpose of finding errors.
The following material is based on a CrossTalk article entitled, “Configuration
Management Fundaments.” CrossTalk Article
Refer to this article and answer the following questions.
1. List the top five sources or causes of change on a software project.
2. What four questions does a Configuration Management System attempt to answer?
3. What are the three major purposes of CM?
4. Identify and give a short paragraph description for each of the four major functions of
Configuration Management.
5. What is the purpose and function of the “Baseline Library”?
Page 11 of 11