Guideline - Concepts and Definitions

G U I DE L I NE
Concepts and Definitions
Code 11e-HD/PM/HDCV/FSOFT
Version 1/2
Effective date 07/12/2006

Guideline: Concepts and definitions v1/2
1. INTRODUCTION
1.1 Purpose
This document aims at giving explanations to concepts and definitions used in Fsoft’s documents.
1.2 Application scope
Concepts and definitions used in this document are applied to Fsoft.
1.3 References
No Code Document name
1 ISO 9000:2000 ISO 9000:2000 Fundamentals and vocabulary
2 CMM (SEI) 1.1 SEI Capability Maturity Model
3 CMMI 1.1 Guidelines for Process Integration and Product Improvement
11e-HD/PM/HDCV/FSOFT Internal use 2/22

2. CONTENT
Acceptance Note This document contains such actual information of the project as: scopes and
objectives, deliverables, performance, quality, teams, assets, problems, rewards and
penalty. It is an acceptance of internal contract between the representative of Fsoft
management board and those assigned responsibility for project completion.
Access Control Control on configuration items to maintain their integrity.
Activity An activity is a unit of work that an individual playing the role described by the
worker may be asked to perform. The activity has a clear purpose, usually
expressed in terms of creating or updating some work product, such as a model, a
class, a plan. Every activity is assigned to a specific worker. The granularity of an
activity is generally a few hours to a few days, it usually involves one worker, and
affects one or only a small number of work products. An activity should be usable as
an element of planning and progress; if it is too small, it will be neglected, and if it is
too large, progress would have to be expressed in terms of an activity’s parts.
Allocated Requirement Requirement that includes all or part of the performance and functionality of a higher
level requirement on a lower level architectural element or design component.
Analyst The person taking main responsibility for the User requirement identification process
Architectural Design The step in moving from the domain of problems to the domain of solutions. The
results of this step are described in an Architectural Design Document (ADD) that
includes a collection of software components and their interfaces.
Architecture Design The software architecture document (ADD) provides a comprehensive overview of
Document (ADD) the architecture of the software system. It serves as a communication medium
between the architect and other project team members regarding architecturally
significant decisions which have been made on the project.
FPT Authority of Company/branch leader who has the responsibility for a field, a group of departments
Management Board according to the assignation of General Director or Branch Director.
Base Measure A distinct property or characteristic of an entity and the method for quantifying it. (See
“derived measures.”)
Example: Effort, number of defects, project size
Baseline Audit Baseline audit will be carried on in order to assess the compliance of configuration
management activities in project.
Baseline A baseline is a ‘snapshot’ in time of one version of each work product in the project
repository. It provides an official standard on which subsequent work is to be based,
and to which only authorized changes can be made. After an initial baseline is
established every subsequent change to a baseline is recorded as a delta until the
next baseline is set. (RUP)
A specification or product that has been formally reviewed and agreed upon, that
thereafter serves as the basis for further development, and that can be changed only
through formal change control procedures (CMM).

Baseline area Baseline area is the area where Configuration Items are stored after the
reviews/tests planned for them have been completed and the issues raised against
them are closed or marked as unresolved before releasing them to the user.
Big Bang Testing Big Bang testing is non-incremental testing. During non-incremental testing: all
modules are combined in advance; the software is tested as a whole – this generally
results in chaos; correction is difficult when a set of errors is encountered, because
the isolation of causes is complicated by the vast expanse of the software.
Once these errors are corrected, new ones appear and the process continues in a
seemingly endless loop.
Binary CSCIs Binary CSCIs are Word document, Excel file, etc. that is non-text files.
Bottom-up Approach to The bottom-up approach, on the other hand, first defines the various activities that
Estimation need to be executed for the project. As these activities are typically at a sufficiently
low level of granularity, effort estimate of each activity can be done from past
experience. The estimate for the total project is then obtained from the estimates of
these activities.
Bottom-Up Testing In this testing approach, the software is merged from the bottom to the top and
tested. The terminal modules are tested in isolation first, and then the next sets of
higher modules are tested along with the previously tested lower modules.
Capability Maturity A description of the stages through which software organizations evolve as they
Model (CMM) define, implement, measure, control, and improve their software processes. This
model provides a guide for selecting process improvement strategies by facilitating
the determination of current process capabilities and the identification of the issues
most critical to software quality and process improvement.
Capability Maturity CMMI provides an opportunity to avoid or eliminate these stovepipes and barriers
Model Integration through integrated models that transcend disciplines. CMMI consists of best
practices that address product development and maintenance. It addresses practices
(CMMI)
that cover the product's life cycle from conception through delivery and maintenance.
There is an emphasis on both systems engineering and software engineering and the
integration necessary to build and maintain the total product.
Causal Analysis and This is a support process area at CMMI Maturity Level 5. The purpose of is to identify
Resolution (CAR) causes of defects and other problems and take action to prevent them from occurring
in the future.
CCB Change Control Board, the person(s) responsible for making decision accept or not
the change request.
Change Request Requests among project teams or between the customer and the project team to
implement one/some changes in the initial software requirements or accepted user
requirements or accepted project product.
Checklist The table of questions and contents for reviewing, assessing built in order to support
testing, reviewing, assessing the work, software, document quality… these tables are
also criteria and norms identified in advance for works and results.
CN Branch/sub-company of FPT
CN Department The center/department at CN level

CNTT Information technology
Code Review Used in coding process to show that a program is consistent with its specification or
coding convention. The review is performed by programmer (one-person or a group).
Coding Process The process to develop software including software components, software system
according standards and defined requirements.
Completeness A measure of the extent to which the product meets all requirements (stated and
implied – the Project Manager should strive to make explicit as much as possible, to
limit the risk of unfulfilled expectations).
Computer Software A software item which is identified for configuration management or, an aggregation
Configuration Item of software that satisfies an end user function and designated for separate
(CSCI) configuration management.
Configuration Control The configuration control process and procedures designating the level of control
through which each work product must pass (for example, author control, project-
level control, acquirer control); identifying the persons or groups with authority to
authorize changes and to make changes at each level (for example, the programmer/
analyst, the software lead, the project manager, the acquirer); and the steps to be
followed to obtain required authorization for changes, to process change requests, to
track changes, to distribute changes, and to maintain past versions. Change control
provides the mechanism to build software systems for tests that have a known
configuration and can be exactly reproduced.
Configuration The ability to identify what information has been approved for concurrent use in the
Identification project, who owns the information, how the information was approved for CM control,
and the latest approved release.
Configuration Item (CI) A uniquely identifiable subset of the CSCI that represents the smallest portion of the
system to be subject to independent configuration management change control
procedures. Configuration items need to be individually controlled because any
change to a configuration item may have some effect upon the properties of the
system.
Configuration Configuration Management identifies, organizes, controls, and reports on the data
Management used by a software project. Data can be software program, documentation, shell
script, binary code, test cases, test shell scripts, and other textual information.
Configuration management commonly addresses the following five areas:
Identification, Configuration Change Control, Accounting, Reviewing, and Access
Control.
Configuration The process to identifies, organizes, controls, and reports on the data used by a
Management Process software project.
Configuration Officer The person taking main responsibility for the Configuration management process
Contract An official legal agreement between two parties or more, usually written.
Contract Management The process to establish and manage software contracts effectively.

Process
Control Limit The control limits are set to maintain the system in statistical control, and to serve as
goals for improvement.
Construction Stage The goal of this stage is to develop the system. Generally the construction stage is a
manufacturing process, where the emphasis is placed in managing resources and
controlling operations to optimize costs, schedules and quality.
Corrective Action Action taken to eliminate the causes of a detected nonconformity or other
undesirable situation.
COTS Items that can be purchased from a commercial vendor. (COTS stands for
“commercial off the shelf.”)
A COTS (commercial off-the-shelf) product is one that is used "as-is." COTS

products are designed to be easily installed and to interoperate with existing system
components. Almost all software bought by the average computer user fits into the
COTS category: operating systems, office product suites, word processing, and e-
mail programs are among the myriad examples. One of the major advantages of
COTS software, which is mass-produced, is its relatively low cost.
Curative Action Action taken to cure the symptoms or to correct the nonconforming output. It does
not eliminate the causes of the non-conformance.
Customer Satisfaction Customer’s perception of the degree to which the customer’s requirements have
been fulfilled.
Customer support The process to support customer to exploit effectively software products supplied by
Process FPT.
Decision Analysis This is a support process area at CMMI Maturity Level 3. The purpose of is to
Resolution (DAR) analyze possible decisions using a formal evaluation process that evaluates
identified alternatives against established criteria.
Defect The non-fulfillment of a requirement related to an intended or specified use.
Defect Aging A special defect density report in which the defect counts are shown as a function of
the length of time a defect remained in a given status (waiting-for-test, error, pending,
tested, accepted, etc.).
Defect Density The number of defects is shown as a function of one or two defect attributes (such as
status or severity).
Defect Rate This metric provides the trend and the measurement of product quality.
Defect Trend The defect count is shown as a function over time.
Definition Stage This stage aims at defining user requirements for software packages. Studying and
translating the user requirements into clear, well-formulated and complete User
Requirement Document (URD), analyses the URD and creating Software
Requirement Specification (SRS) are the main activities of this stage.
Deliverable An output from a process that has a value, material or otherwise, to a customer or
other stakeholder.
Deployment Process The process to deliver the software program to the user at a specific location. The

main activities of are to deliver and/or install software to customer/user and provide
user guidance.
Install and train users to exploit software products supplied by FPT.
Deployment Officer The person taking main responsibility for the Deployment process
Derived Measure Data resulting from the mathematical function of two or more base measures. (See
“base measure.”).
Example: Productivity, defect rate, test effectiveness
Derived Requirement Requirements that are not explicitly stated in the customer requirements, but are
inferred (1) from contextual requirements (e.g., applicable standards, laws, policies,
common practices, and management decisions), or (2) from requirements needed to
specify a product component.
Derived requirements can also arise during analysis and design of components of the
product or system. (See “product requirements.”).
Derived requirements arise from constraints, consideration of issues implied but not
explicitly stated in the customer requirements baseline, and factors introduced by the
selected architecture, the design, and the developer’s unique business
considerations.
FSoft requirement management sheet: Category = DER (User's wish and non-direct
stated requirements).
Design Process The process to create and assure software design suitable to user requirements.
Design Review A documented, comprehensive and systematic examination of a design its capability
to fulfill the requirements for quality, identity problems, if any, and propose the
development of solutions.
Designer The person taking main responsibility for the Software designing process
Detailed Design Detailed Design is the step, where the design contents outlined in the ADD are
decomposed until they can be expressed as modules. The detailed design describes
project’s implementation details in a Detailed Design Document (DDD).
Detailed Design In Detailed Design, lower-level components of the Architectural Design are
Document decomposed until they can be expressed as modules in the selected programming
language.
Developer The person taking main responsibility for the Coding process
GDA FPT General Director Assistant.
General Director Board FPT General Director and FPT Vice General Directors.
Generic Goal Generic goals are called “generic” because the same goal statement appears in
multiple process areas. In the staged representation, each process area has only one
generic goal. Achievement of a generic goal in a process area signifies improved
control in planning and implementing the processes associated with that process
area, thus indicating whether these processes are likely to be effective, repeatable,

and lasting. Generic goals are required model components and are used in
appraisals to determine whether a process area is satisfied.
Generic goals in CMMI staged representation:
GG2 Institutionalize a Managed Process
GG3 Institutionalize a Defined Process

Generic Practice Generic practices provide institutionalization to ensure that the processes associated
with the process area will be effective, repeatable, and lasting. Generic practices are
categorized by generic goals and common features and are expected components in
CMMI models.
Generic Goals and Generic Practices
 realize the capability dimension
 therefore, they apply across all Process Areas

Effectiveness Extend to which planned activities are realized and planned result achieved.
Efficiency Relationship between the results achieved and resources used.
Effort deviation This metric measures the effectiveness of effort usage, project planning and
managing capability.
Effort distribution This metric provides visibility into the effort distribution, the relation of each type of
activities, and the cost driver of project.
Effort usage This metric provides tracking the used effort against budgeted.
FAD Administration Department of FPT
FAF Accounting Department of FPT
FHR Human Resource Department of FPT
FPT Corporation for Financing and Promoting Technology
FQA Quality Assurance Center of FPT
FSOFT FPT Software Join stock company
FWB Worldwide Business Center
FPT-HCM FPT Ho Chi Minh Branch
FPT Department The center/department at corporation level
FPT Management General Director, GDA’s, Vice General Directors, Directors of CN, Chief of
Board Representative Offices, Managers of FPT department.
FPT Quality System Including FPT’s organizational structure, processes, documents and resources that
are necessary for implementing quality management.
FPT Software Process The FPT software engineering methodology that is defined, released and applied to
software activities performed by FPT.
FPT software process A set of documentation that is official released relating to FPT software processes.

handbook
Function Points The basic unit to calculate the necessary work bulk to complete software function.
Kick off To start a project
ID Specify the unique identification number of the item.
Identifying A task that should be performed early in the development of the system, and once
Configuration Items something is designated as a configuration item, the design of that item should not
change without the knowledge and permission of the party controlling the item.
Incremental Integration The antithesis of the Big Bang approach. During incremental integration, the software
is constructed and tested in small segments; errors can be isolated and corrected
easily.
Interfaces are more likely to be tested correctly, and a systematic test approach may
be applied.
Indicator It measures quality requirement or process factor by the value of a quantity.
Integration Sequence Advantages & Disadvantages - This is related to overall system performance. This
can be decided by, which integration sequence is more useful to the performance of
the system.
If you have 3 modules, i.e. A, B & C. Integration sequence for this -
1. Integration of A & B and then with C
2. Integration of B & C and then with A
3. Integration of A & C and then with B
Out of these three, you can decide which is the best suitable for the system, keeping
in mind performance, schedule, future usage, etc.
Initiation Stage Initiation stage is a start of the SLC, in which:
Project’s software scope and boundary conditions, including the operational vision
and proposed products, are established.
Overall cost and schedule of the project are estimated.
Potential risks are defined.

Interface Requirement For example, application components that must interface with an off-theshelf
database component must comply with interface requirements imposed by the
selected database.
FSoft requirement management sheet: Category = INR (Interface with other system,
subject to integration).
Iteration A distinct sequence of activities with a base-lined plan and valuation criteria resulting
in a release (internal or external).
Key Requirement Identify key requirements that have a strong influence on cost, schedule,
functionality, risk, or performance. The information should be added to Requirement
guideline. Traceability matrix maybe have a new column to reflect key requirements.
Example: “Key” field in RM sheet template will be “Yes” if there is at least one highest

value in “Priority”, “Risk”, “Difficulty” or “Cost to implement” fields.

Life Cycle Set of generally sequential stages of manageable size
Lower Control Limit The lowest standard of the control limits
(LCL)
Man-Day (MD) Working day, the basic unit to calculate the software technical work bulk. Each man-
day is equal to 8 working hours.
Man-Month (MM) An unit equal to 25 man-days
Management Review A formal evaluation by top management of the status and adequacy of the quality
system in relation to quality policy and objectives.
Maturity Level The maturity level of an organization provides a way to predict the future
performance of an organization within a given discipline or set of disciplines.
Experience has shown that organizations do their best when they focus their
process-improvement efforts on a manageable number of process areas that require
increasingly sophisticated effort as the organization improves.
In CMMI models with a staged representation, there are five maturity levels, each a
layer in the foundation for ongoing process improvement, designated by the numbers
1 through 5:
Initial, Managed, Defined, Quantitatively Managed, and Optimizing.

Milestone The moments of project need to be given special control, at which there are
important results, main tests and reviews. The milestones are normally the moments
at the end of the stages.
Non Conformity The non-fulfillment of a specified requirement.
Operation Concept A general description of the way in which an entity is used or operates. (Also known
as “concept of operations.”).
Example: business requirement for drawing money from bank account.
Operation Meeting Conducted to inform the department management the status of running projects and
define problems unresolvable at project level.
Operation Scenario A description of an imagined sequence of events that includes the interaction of the
product with its environment and users, as well as interaction among its product
components. Operational scenarios are used to evaluate the requirements and
design of the system and to verify and validate the system.
Example: Steps for drawing money from bank account using ATM.
Peer Review A methodical examination of software work products by the producers’ peers to
identify defects and areas where changes are needed. The reviews are focus on the
reviewed products and not on the producers. Results of the peer reviews are not
used to evaluate the performance of individuals.
Pilot Deployment The activity belonging to the software project. Pilot deployment is confined within one
or some locations, not all locations within the deployment scope or estimated objects
of the software products.
Post-Mortem To finish a project

Preventing risk Preventing risk is the transition point between reactive and proactive approaches.
Preventive Action The action taken to eliminate the causes of a potential non-conformance or other
undesirable potential situations.
Primary Version The version produced by the first development life-cycle and after a major
modification (which affected to main functions and/or structure of the software
application).
Priority of Risk Specify the urgency of implementation of preventive actions for reducing or
eliminating the causes of risk.
Valid value: high, medium, low
Proactive risk Proactive risk management means that the project team has a visible process for
management managing risks that is measurable and repeatable.
Process A set of inter-related resources and activities which transform inputs into outputs.
Process Area A process area is a cluster of related practices in an area that, when performed
collectively, satisfy a set of goals considered important for making significant
improvement in that area. All CMMI process areas are common to both continuous
and staged representations. In the continuous representation, process areas are
organized by process area categories.
Process Capability A documented characterization of the range of expected results that would normally
Baseline (PCB) be achieved by following a specific process under typical circumstances. A process
capability baseline is typically established at an organizational level.
Process Factor Process characteristic that affects to process output
Process Indicator It measures process factor in form of the value of a quantity.
Process Measurement The set of definitions, methods, and activities used to take measurements of a
process and its resulting products for the purpose of characterizing and
understanding the process.
Process Performance A measure of actual results achieved by following a process. It is characterized by

both process measures (e.g., effort, cycle time, and defect removal efficiency) and
product measures (e.g., reliability, defect density, and response time).
Process Performance A documented characterization of the actual results achieved by following a process,
Baseline which is used as a benchmark for comparing actual process performance against
expected process performance. (See “process performance.”).
Process Performance A description of the relationships among attributes of a process and its work products
Model (PPM) that are developed from historical process performance data and calibrated using
collected process and product measures from the project and which are used to
predict results to be achieved by following a process.
Process Tailoring The activity of creating a process description by elaborating, adapting, and/or
completing the details of process elements or other incomplete specifications of a
process. Specific business needs for a project will usually be addressed during
process tailoring.
Product Result of a process including services, hardware, software, documents or a

combination of these above types provided to customers.
Product Baseline In configuration management, the initial approved technical data package (including,
for software, the source code listing) defining a configuration item during the
production, operation, maintenance, and logistic support of its life cycle. (See
“configuration management” and “configuration item.”).
Product Component The term “product component” is used as a relative term in CMMI models. In CMMI,
product components are lower level components of the product; product components
are integrated to “build” the product.
There may be multiple levels of product components. A product component is any

work product that must be engineered (requirements defined and designs developed
and implemented) to achieve the intended use of the product throughout its life.
Product components are parts of the product delivered to the customer and may
serve in the manufacture or use of the product. A car engine and a piston are
examples of product components of a car (the product). The manufacturing process
to machine the piston, if delivered to the customer, is a product component.
However, if the manufacturing process is used to machine the piston delivered to the
customer, the manufacturing process is a work product, not a product component.
The repair process used to remove the engine from the car for repair and the process
used to train the mechanic to repair the engine are typically examples of product
components because they are delivered to the customer.
Product Component Product-component requirements provide a complete specification of a product
Requirements component, including fit, form, function, performance, and any other requirement.
Product Life Cycle A “product life cycle” is the period of time, consisting of phases, that begins when a
product is conceived and ends when the product is no longer available for use. Since
an organization may be producing multiple products for multiple customers, one
description of a product life cycle may not be adequate. Therefore, the organization
may define a set of approved product life-cycle models. These models are typically
found in published literature and are likely to be tailored for use in an organization.
A product life cycle could consist of the following phases: (1) concept/vision, (2)
feasibility, (3) design/development, (4) production, and (5) phase out.
Productivity This metric provides the measurement about general productivity in project
Product Release A stable, executable version of product, together with any other peripheral elements
necessary to use this release.
Product Requirements A refinement of the customer requirements into the developers' language, making
implicit requirements into explicit derived requirements. (See “product-component
requirements” and “derived requirements.”) The developer uses the product
requirements to guide the design and building of the product.
Product Size Provides tracking the size of software products against estimated. This metric also is
base of other metrics, for example productivity, or quality of product.
Project Unique process, consisting of a set of definition and controlled activities with start
and finish date, undertaken to achieve an objective conforming to specific
requirements, including the definition of time, cost and resources.

Project Duration The cycle time of the project is short if the project duration is shorter than 2 months,
medium if it is between 2 and 6 months. Otherwise it is a long project.
Project Manager The person taking main responsibility for the Software project management process.
In general, a project manager can manage different projects at the same time.
Project’s Defined Life The SLC for the project
Cycle (PLC)
Project Management Project Management CSCIs which are project plans, schedules, status reports etc.
CSCIs They will start at the beginning of the project and last through the many iterations of a
project till the end of the project. They may be updated and different versions
maintained but they will not move from one environment to another.
Project Management The process to plan and manage software projects effectively.
Process
Project Meeting Conducted to review the project results, define problems at project level and define
problems irresolvable at project level to submit for handling on higher level.
Project Plan The purpose of the Project Plan is to gather all the information necessary to control
the project. It describes the approach to the development of the software and is the
top-level plan generated and used by the managers to direct the development effort.
Project Progress This report is periodically made on progress, finished work content, estimated plan
Report for next works.
Project Stages Stages of the project targeted at reaching definite results and specified in the project
plan. Stages are divided according to different durations and named based on the
name of the software process taking the leading role. Example: systematic analysis
stage, requirement specification stage, design stage…
Quality Assurance Part of the quality management focused on providing confidence that the quality
requirements will be fulfilled.
Quality Audit A systematic and independent examination to determine whether Quality Activities
and related results comply with planned arrangements and whether these planned
arrangements are implemented effectively and are suitable to achieve objectives.
Quality Control Part of the quality management focused on fulfilling quality requirements.
Quality Cost This metric provides the cost that project pays for quality and efficiency of quality
activities in project. Quality cost is combined from Prevention cost, Appraisal cost
and Non Conformity cost.
Quality Gate All stages of the SLC are verified and validated by QA through Quality gates to
determine:
1. If the objectives of the stage have been met.
2. If the mandatory work products have satisfied the requirements.
Quality Indicator It measures quality requirement in form of the value of a quantity
Quality Management Coordinated activities to direct and control an organization with regard to the quality.
Quality Objective Something sought, or aimed for , related to quality

Quality Officer The person taking main responsibility for the Quality process
Quality Plan A document setting out the specific quality practices, resources and sequence of
activities relevant to a particular product, project or contract.
Quality Planning Part of the quality management focused on setting quality objectives and specifying
necessary operational processes and related resources to fulfill the quality
objectives.
Quality Requirement Characteristic of product/process outputs that are customer expectation and using
need.
Quality of Software A measure of reliability, stability, and the performance of the target of test (system or
application-under-test). Quality is based upon the evaluation of test and the analyses
of defects discovered during the testing.
Quantitative Objective Desired target value expressed as quantitative measures.
Quantitatively Managed A defined process that is controlled using statistical and other quantitative
Process techniques. The product quality, service quality, and process performance attributes
are measurable and controlled throughout the project.
Reactive Risk Reactive risk management means the project team reacts to the consequences of
Management risks (actual problems) as they occur. Proactive risk management means that the
project team has a visible process for managing risks that is measurable and
repeatable.
Record Documents stating results achieved or providing evidence of activities performed.
Release A product release. A release can be internal or external.
An internal release is used only by the development organization, as part of a

milestone, or for a demonstration to users or customers. An external release (or
delivery) is delivered to end users. A release is not necessarily a complete product,
but can just be one step along the way, with its usefulness measured only from an
engineering perspective.
Release Note Each release should be accompanied with a release note which typically contains:
version number of the release; date of release; number & details of the sources
released along with the type of sources (Java, HTML etc); number of open issues;
issues closed if any of the previous version; other dependencies like specific version
of operating System etc; impact on other systems, if any; specific installation
instructions.
Relevant Stakeholder The term “relevant stakeholder” is used to designate a stakeholder that is identified
for involvement in specified activities and is included in an appropriate plan (See
“Stakeholder”). Example: customer, BA group representatives, project team, onsite
coordinator.
Reliability The ability of an item to perform a required function under stated conditions for a
stated period of time.
Requirement Need or expectation that is stated, generally implied or obligatory.
Requirement This metric measures the completeness of requirements and how far to reach the
Completeness destination.

Requirements and Requirements and Design CSCIs in an Iteration of a project consist of the CSCIs that
Design CSCIs are produced during requirements and design. They may be updated and different
versions maintained but there will be one separate document per Iteration and they
will not move from one environment to another.
Requirement Elicitation Using systematic techniques, like prototypes and structured surveys, to proactively
identify and document customer and end-user needs.
Requirement The management of all requirements received by or generated by the project,
Management including both technical and nontechnical requirements as well as those

requirements levied on the project by the organization.
Requirement An excel sheet, used to track the status, relationship and change of requirements
Management Sheet during the whole project.
(RMS)
Requirement The evidence of an association between a requirement and its source requirement,
Traceability its implementation, and its verification.
We need to maintain relationship between requirements i.e. R1, R2, R3 are different
requirements then relationship between R1 and R3 to be mentioned if any. This will
help us to decide if there is any change in R1, we need to look into R3 also to change
the same as R1 is related to R3. This will help during change management activities.
Example: Requirement list in FI, RM sheet template. Relationship between

requirements implemented by Parent and Traced From fields.
Requirement Process Define and analyze user requirements, software requirements and manage them.
Requirement Provider Requirements providers could be customer and for internal project Senior
management/Marketing department. Criteria - for internal and external
projects.
Requirement Stability Provides the visibility into whether requirements changes are responsible for cost
overruns, schedule delays, and decreased product quality.
R&D Research and Development
Response Time Maximum response time on request
Review Activity undertaken to determine the suitability, adequacy and effectiveness of the
subject matter to achieve established objectives.
Rework Action on a non-conforming product to make it conform to the requirements.
Risk Risk is the possibility of suffering loss. For a given project, the loss could be in the
form of diminished quality of the end product, increased cost, missed deadlines, or
complete failure to achieve the mission and purpose of the project. In other words, a
risk is a problem waiting to happen.
Risk Action Planning Risk action planning is the third step in the risk management process. It turns risk
information into decisions and actions. Planning involves developing actions to
address individual risks, prioritizing risk actions, and creating an integrated risk
management plan.
Risk Analysis Risk analysis is the second step in the proactive risk management process. Risk
analysis is the conversion of risk data into risk decision-making information.
Thorough analysis ensures that the team is working on the right risks.

Risk Condition A natural language statement describing the existing condition that could possibly
lead to a loss for the project.
Risk Control This is the last step in the proactive risk management process. After the team has
chosen the risk metrics and the triggering events, there is nothing unique about risk
management. Rather, risk management melds into project management processes
to control the risk action plans, correct for variations from the plans, respond to
triggering events, and improve the risk management process.
Risk Consequence A natural language statement describing the loss that would occur to the project if the
risk became certain.
Risk Contingency A paragraph or two describing the team strategy in the event that the actions planned
Strategy to mitigate the risk don’t work. The team would execute the risk contingency strategy
if the risk contingency strategy trigger were reached.
Risk Exposure The overall threat of the risk to the project, balancing the likelihood of actual loss with
the magnitude of the potential loss. The team uses risk exposure to rate and rank
risks.
Risk Factor Risk factors are grouped by focus area and risk factor category. Examples of risk
factor categories within a focus area are mission and goals factors, decision drivers,
organizational management factors, and budget and cost factors. Each risk factor
has one or more characteristic that describes whether the risk should be considered
a high, medium, or low risk.
Risk Identification This is the first step in the proactive risk management process. Risks must be
identified before they can be managed. Risk identification provides the project team
with the opportunities, cues, and information that allow them to surface major risks
before they adversely affect the project.
Risk Identifier The name the team uses to uniquely identify a risk statement for reporting and
tracking purposes.
Risk Impact Risk impact measures the severity of adverse affects, or the magnitude of a loss, if
the risk comes to pass.
Risk Management Risk management sets for a discipline and environment of proactive decisions and
actions to assess continuously what can go wrong, determine what risks are
important to deal with, and implement strategies to deal with those risks.
Risk management aims to analyze, identify possible risks that may occurs and that
may affect to project objectives, schedule or effort in unfavorable manner if it occurs.
Risk Management An organized, technical approach to identify what might cause harm or loss (identify
Strategy risks), assess and quantify the identified risks, and to develop and if needed
implement an appropriate approach to prevent or handle risk causes that could result
in significant harm or loss. Typically, risk management is performed for project,
organization, or product-developing organizational units.
Risk Mitigation Action A list of actions the team will take to mitigate the risk. They will log these action items
in the project tacking system.
Risk Probability Risk probability is the likelihood that an event will actually occur. Using a numerical
value for risk probability is desirable for ranking risks. Risk probability must be

greater than zero, or the risk does not pose a threat to the project. Likewise, the
probability must be less than 100 percent or the risk is a certainty—in other words, it
is a known problem.
Risk Tracking Risk tracking is the fourth step in the risk management process. In it, the team
monitors the status of risks and the actions it has taken to mitigate them. Risk
tracking is essential to effective action plan implementation. This means devising the
risk metrics and triggering events needed to ensure that the planned risk actions are
working. Tracking is the watch dog function of the risk action plan.
Sales Person The person taking main responsibility for the Software contract construction and
management process.
Sandwich Testing A testing approach that uses the Top-Down strategy for the upper levels of the
software structure, coupled with the Bottom-Up strategy for the subordinate levels.
Schedule Deviation This metric provides information on how well the project is performing with respect to
its schedule commitments.
Size Deviation This metric provides information on how well the estimation is performed.
Size of the Project The number of staffs of a project.
Team
The size of the project team is small if the project has less than 5 members, medium
if it has between 5 and 20. Otherwise, it is large.
Skill Level of the The indicator of experience of members of a project.
Project Team
The skill level of the team is high if a majority of the team members have more than
two years of experience with technology being deployed in the project, otherwise, it is
considered low.
Specific Goal Specific goals apply to a process area and address the unique characteristics that
describe what must be implemented to satisfy the process area. Specific goals are
required model components and are used in appraisals to help determine whether a
process area is satisfied.
Specific Practice A specific practice is an activity that is considered important in achieving the
associated specific goal. The specific practices describe the activities expected to
result in achievement of the specific goals of a process area. Specific practices are
expected model components.
Specific Goals and Specific Practices
 realize the process dimension
 therefore, they apply to a particular Process Area

Software Estimation A Software Estimation File template (SEF) should be maintained that contains
File information such as, estimation methods used, date of estimate, size, cost, schedule,
critical computer resources, and risks for each estimate that is developed. Software
estimates should be submitted for use in the Fsoft software process database.
Finally, data should be collected and analyzed from each of the above steps and
should be used to improve the estimation process by the SEPG.

Software Package Software package is a computer program, which is developed basing on the
customer requirements and associated document in order to meet business or
information management need or be integrated into other controlling technology
equipment.
Software Process A set of documentation that is officially released relating to FPT software processes.
Handbook
Software Requirement Features that a system, HWSCI or CSCI have to satisfy for the proposer’s
requirement acceptance and approval. These are the criteria requirements stated in
the criteria regulations or required by customer in contract.
Software Requirement The Software Requirements Specification (SRS) focuses on the collection and
organization of all requirements surrounding your project. For example, it may be
Specification (SRS)
desired to have a separate SRS to describe the complete software requirements for
each feature in a particular release of the product. This may include several use
cases from the system use-case model, to describe the functional requirements of
this feature, along with the relevant set of detailed requirements in Supplementary
Specifications.
Software Standard Life The organization standard of SLC.
Cycle (SSLC)
Solution Stage The main purpose of this stage is to define an effective solution to meet customer
requirements. Analyzing and creating a good design for the software package are the
main activities of this stage.
Source CSCIs Source CSCIs are the CSCIs produced during the build (coding and testing)
activities. They are source code, SQL batch file, make file, parameters file (XML or
INI)…
Standard Process An operational definition of the basic process that guides the establishment of a
common process in an organization.
A standard process describes the fundamental process elements that are expected
to be incorporated into any defined process. It also describes the relationships (e.g.,
ordering and interfaces) between these process elements.
Stage Set of logically related processes, usually culminating in the completion of one or
more products (PMI, CMM).
Stakeholder A “stakeholder” is a group or individual that is affected by or in some way

accountable for the outcome of an undertaking. Stakeholders may include project
members, suppliers, customers, end users, and others.
Status The current situation of work/activity/product.
Status Accounting Formalized recording and reporting of the established configuration documents, the
status of proposed changes, and the status of the implementation of approved
changes. Status record information provides an accessible and current record of the
status of each controlled piece of information that is planned to be used, the content
of each release from CM, and who has checked out or is working on a piece of
information that the test organization plans on accessing through CM.

Sub-Contractor Select subcontractors having competent to satisfy subcontract requirements and
Management Process manage software subcontract activities effectively.
Subcontract Officer The person taking main responsibility for the Software subcontracting process
Supplier Supplier is the organization that provides a product to the customer.
Supporter The person taking main responsibility for the Customer support process
Technical Data A collection of items that may include the following if such information is appropriate
Package to the type of product and product component (for example, material and
manufacturing requirements may not be useful for product components associated
with software services or processes):
• product architecture description
• allocated requirements
• product-component descriptions
• product-related life-cycle process descriptions if not described as separate

product components.
• key product characteristics
• required physical characteristics and constraints
• interface requirements
• materials requirements (bills or material and material characteristics).
• fabrication and manufacturing requirements (for both the original equipment

manufacturer and field support).
• the verification criteria used to ensure requirements have been achieved.
• conditions of use (environments) and operating/usage scenarios, modes and

states for operations, support, training, manufacturing, disposal, and
verifications throughout the life of the product.
• rationale for decisions and characteristics (requirements, requirement

allocations; design choices).
Properties (attributes) of products or services to be acquired or developed.
Example: CI Register in FI
Technical Proposal Technical Proposal, prepared by evaluation team together with marketing people to
present to customer. TP should outline the customer’s business requirements and
proposed solution.
Technical Review This meeting evaluates software elements to verify progress against the plan, to
Meeting evaluate the work results of the stage, and to decide whether the next stage may be
started.
Termination Stage The project closes at this stage when customer accepts the whole project and signs
off the contract. Project assets must be collected and transferred to Fsoft process
asset library.

Test Case A set of test inputs, execution conditions, and expected results developed for
particular objective, such as to exercise a particular program path or to verify
compliance with a specific requirement.
The purpose of the Test Case is to identify and communicate the conditions which
will be implemented in test and are necessary to verify successful and acceptable
implementation of the product requirements (use cases, performance characteristics,
etc.). Test cases reflect one measure of test coverage, requirements-based test
coverage, in that each test case traces back to at least one requirement for test
which reflect the product requirements.
Test Plan Contains information about the purpose and goals of testing within the project.
Additionally, the test plan identifies the strategies to be used to implement and
execute testing and resources needed.
The purpose of the test plan is to communicate the intent of the testing activities.
Test An activity to validate and verify the program/system/product/document to confirm

that the program/system/product/document has met the requirements stated in the
requirement specification, design document and technical defects have been
detected.
Test Process The process to plan and conduct test for software products including software
components, software systems.
Tester The person taking main responsibility for the Testing process
Test Coverage The measurement of testing completeness, and is based on the coverage of testing,
expressed either by the coverage of test requirements and test cases, or the
coverage of executed code.
Timeliness This metric measures the ability to satisfy customer in timeliness
Timesheet A spreadsheet, etc on which the number of hours a person works are recorded.
Top-down Approach to In a top-down approach, the overall estimate for the project is first determined based
Estimation on some models and then the estimates for different tasks are determined. Such a
model typically requires, as input, the size estimate (in Lines Of Code-LOC or
function points or use case points) of the overall system.
Top-Down Integration An incremental approach to the construction of program structure. In Top-Down
Testing testing: The main control module is used as a test driver and all modules that directly
subordinate to the main control module are substituted by stubs; Stubs are replaced
with actual modules one at a time, depending on the integration approach selected
(depth/breadth first); As new modules are integrated, tests are conducted; Upon
completing each set of tests, another stub is replaced with the real module;
Regression testing may be conducted to ensure that new errors are not introduced.
Traceability The ability to trace the history, application or location of that which is under
consideration.
Traceability Matrix This should be defined to verify whether all the requirements are defined and tested
for the project. This may be maintained as a separate document, which will refer to
the relevant sections of various documents/records generated in the project. The PL

should review and approve this matrix. The traceability matrix should be updated to
reflect any change that may take place during the execution of the project.
Training Faculty Training Faculty are specialists from within FSOFT. They make courseware and
teach.
Training-in-Charge Training-in-Charge (or Training Coordinator) is a member of an Operation unit.

He/she is responsible for training activities in his/her unit, including Project Training
Plans.
Training Manager Training Manager is responsible for annual planning, reporting, reviewing curriculum,
calendar, courseware, and for overall management.
Training Staff Training Staff is responsible for conducting training course, maintaining records,
student enrollment.
Transition Stage The focus of the Transition stage is to ensure that software is available for its end
users. Delivering software to customer, implementing software systems on customer
site and conducting test activities for acceptance are main activities of this stage.
Upgraded Version The version used in warranty stage (which is based on defect reports and/or
approved requirement change request).
Upper Control Limit The highest standard of the control limits.
(UCL)
User Organizations or individuals using FPT’s software products.
User Case A use case defines a set of use-case instances, where each instance is a sequence
of actions a system performs that yields an observable result of value to a particular
actor. A use-case class contains all main, alternate flows of events related to
producing the "observable result of value". Technically, a use-case is a class whose
instances are scenarios.
User Case Point The Use Case Points Approach, from Rational Software, is a modification of the
Function Points method of estimation. As the process maturity of FPT increases,
there should be attempts to tailor this estimation method to include or exclude any
features specific to FPT.
User Requirement Details of user requirements viewed from the aspect of the software product user.
User Requirement The user requirement document (USR) provides a high-level–sometimes
Document (URS) contractual–basis for the more detailed technical requirements. There can also be a
formal requirements specification. The URD captures very high-level requirements
and design constraints, to give the reader an understanding of the system to be
developed. It communicates the fundamental "why's and what's" related to the project
and is a gauge against which all future decisions should be validated.
Validation (VAL) The purpose of VAL is to demonstrate that a product or product component fulfills its
intended use when placed in its intended environment. In other words, validation
ensures that “you built the right thing.”
Verification (VER) The purpose of VER is to ensure that selected work products meet their specified
requirements. In other words, verification ensures that “you built it right.”

Version A variant of some work product; later versions of a work product typically expand on
earlier versions.
Weight The number that characterizes the severity of something as defect, requirement...
E.g. a defect could be weighted in 1 (cosmetic), 3 (medium), 5 (serious) or fatal (10).
Working Agreement This record is used to acknowledge work contents and scopes agreed between FPT
Record and customer during the project implementation process.
Work Order The Work Order is the Project Manager's means of communicating what is to be
done and when, to the responsible staff. It becomes an internal contract between the
representative of Fsoft management board and those assigned responsibility for
completion.
Worker A worker defines the behavior and responsibilities of an individual, or a set of

individuals working together as a team, within the context of a software engineering
organization. The worker represents a role played by individuals on a project, and
defines how they carry out work.
Note that workers are not individuals; instead, they describe how individuals
should behave in the business and the responsibilities of an individual. Individual
members will wear different hats, or play different parts or roles. The mapping from
individual to worker, performed by the project manager when planning and staffing
the project, allows different individuals to act as several different workers, and for a
worker to be played by several individuals.
Work Product Product
Work Product Review A process during which a work product is represented to second party (a person or
group of persons) for comment or approval. The review objectives are to identify
defects, violations, and non-conformations of work products against the defined
specifications, plans and standards before releasing. Peer review is the
recommended method to conduct software work product reviews.
Work Result Report The report used on finishing a specific work or as requested from senior level.
Approver Reviewer Creator
Le The Hung
Nguyen Thanh Nam Hoang A Na
Hoang Anh Duc

Guideline - Concepts and Definitions

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guideline - Concepts and Definitions

Uploaded by

Copyright:

Available Formats

G U I DE L I NE

Concepts and Definitions

Effective date 07/12/2006

1.2 Application scope

Concepts and definitions used in this document are applied to Fsoft.

No Code Document name

1 ISO 9000:2000 ISO 9000:2000 Fundamentals and vocabulary

2 CMM (SEI) 1.1 SEI Capability Maturity Model

3 CMMI 1.1 Guidelines for Process Integration and Product Improvement

11e-HD/PM/HDCV/FSOFT Internal use 2/22

Access Control Control on configuration items to maintain their integrity.

Management Board according to the assignation of General Director or Branch Director.

Example: Effort, number of defects, project size

11e-HD/PM/HDCV/FSOFT Internal use 3/22

CN Department The center/department at CN level

11e-HD/PM/HDCV/FSOFT Internal use 4/22

CNTT Information technology

(CSCI) configuration management.

Management Process software project.

11e-HD/PM/HDCV/FSOFT Internal use 5/22

A COTS (commercial off-the-shelf) product is one that is used "as-is." COTS

Defect The non-fulfillment of a requirement related to an intended or specified use.

Defect Trend The defect count is shown as a function over time.

11e-HD/PM/HDCV/FSOFT Internal use 6/22

Install and train users to exploit software products supplied by FPT.

Example: Productivity, defect rate, test effectiveness

GDA FPT General Director Assistant.

11e-HD/PM/HDCV/FSOFT Internal use 7/22

Generic goals in CMMI staged representation:

GG2 Institutionalize a Managed Process

GG3 Institutionalize a Defined Process

Generic Goals and Generic Practices

 realize the capability dimension

 therefore, they apply across all Process Areas

Efficiency Relationship between the results achieved and resources used.

FAD Administration Department of FPT

FAF Accounting Department of FPT

FHR Human Resource Department of FPT

FPT Corporation for Financing and Promoting Technology

FQA Quality Assurance Center of FPT

FSOFT FPT Software Join stock company

FWB Worldwide Business Center

FPT-HCM FPT Ho Chi Minh Branch

FPT Department The center/department at corporation level

11e-HD/PM/HDCV/FSOFT Internal use 8/22

Kick off To start a project

ID Specify the unique identification number of the item.

Indicator It measures quality requirement or process factor by the value of a quantity.

If you have 3 modules, i.e. A, B & C. Integration sequence for this -

1. Integration of A & B and then with C

2. Integration of B & C and then with A

3. Integration of A & C and then with B

Overall cost and schedule of the project are estimated.

Potential risks are defined.

11e-HD/PM/HDCV/FSOFT Internal use 9/22

value in “Priority”, “Risk”, “Difficulty” or “Cost to implement” fields.

Lower Control Limit The lowest standard of the control limits

Initial, Managed, Defined, Quantitatively Managed, and Optimizing.

Non Conformity The non-fulfillment of a specified requirement.

Example: business requirement for drawing money from bank account.

Post-Mortem To finish a project

11e-HD/PM/HDCV/FSOFT Internal use 10/22

Valid value: high, medium, low