Module 5 Software Testing and Maintenance

NEED AND TYPES OF MAINTENANCE:

Software Maintenance: Software maintenance is an activity in which program is modified after it has been
put into use. In this usually it is not preferred to apply major software changes to system’s architecture.
Maintenance is a process in which changes are implemented by either modifying the existing systems
architecture or by adding new components into the system.

Need for maintenance:

Software maintenance is widely accepted part of SDLC now a day. It stands for all the modifications and
updating done after the delivery of software product. There are number of reasons, why modifications are
required, some of them are briefly mentioned below:
● Market Conditions: Policies, which changes over the time, such as taxation and newly introduced
constraints like, how to maintain bookkeeping, may trigger need for modification.
● Client Requirements: Over the time, customer may ask for new features or functions in the software.

● Host Modifications: If any of the hardware and/or platform (such as operating system) of the target
host changes, software changes are needed to keep adaptability.
● Organization Changes: If there is any business level change at client end, such as reduction of
organization strength, acquiring another company, organization venturing into new business, need to
modify in the original software may arise.
Types of maintenance:
Various types of software maintenance are:
● Corrective Maintenance: Means the maintenance for correcting the software faults.

● Adaptive Maintenance: Means maintenance for adapting the change in environment (different
system or operating systems).
● Perfective Maintenance: Means modifying or enhancing the system to meet the new requirements.

● Preventive Maintenance: This includes modifications and updating to prevent future problems of the
software.
Change RequestCorrective Adaptive Perfective maintenance
maintenance (fault maintenance (system enhancement)
repair) (platform adoption)

Change Impact analysis System release Change System release

management planning implementation

Figure 5.1: Maintenance Process

 Issues in software maintenance:

Issues in software
maintenance

Technica Management Cost Software maintenance measurement

l Figure 5.2: Software Maintenance Issues
estimation
SOFTWARE CONFIGURATION MANAGEMENT (SCM):
Software configuration management is a set of activities carried out for identifying, organizing and controlling
changes throughout the life cycle of computer software.
During the development of software “change must be managed and controlled” in order to improve quality
and reduce error.
Hence software configuration management is a quality assurance activity that is applied throughout the
software process.
SCM helps to eliminate the confusion often caused by miscommunication among team members. The SCM
system controls the basic components such as software objects, program code, test data, test output, design
documents and user manuals.
The SCM system has the following advantages:
● Reduced redundant work.

● Effective management of simultaneous updates.

● Avoids configuration-related problems.
● Facilitates team coordination.
● Helps in building management; managing tools used in builds.
● Defect tracking: It ensures that every defect has traceability back to its source.

Software Configuration Items (SCIs): Information that is created as part of the software engineering process.
Baselines: A Baseline is a software configuration management concept that helps us to control change.
Signals a point of departure from one activity to the start of another activity. Helps control change without
impeding justifiable change.
Elements of SCM
There are four elements of SCM:
1. Software Configuration Identification
2. Software Configuration Control
3. Software Configuration Auditing
4. Software Configuration Status Reporting
The SCM Process
The SCM process defines a series of tasks:
● Identification of objects in the software configuration

● Version Control

● Change Control

● Configuration Audit, and

● Reporting
 Reporting

Configuration Audit

Change Control

Version Control

Identification

SCIs

Figure 5.3: SCM Process

SOFTWARE CHANGE MANAGEMENT:

Change control is function of configuration management, which ensures that all changes made to software
system are consistent and made as per organizational rules and regulations.
A change in the configuration of product goes through following steps –
● Identification: A change request arrives from either internal or external source. When change request
is identified formally, it is properly documented.
● Validation: Validity of the change request is checked and its handling procedure is confirmed.

● Analysis: The impact of change request is analyzed in terms of schedule, cost and required efforts.
Overall impact of the prospective change on system is analyzed.
● Control: It is decided that the changes are worth incorporation or not. If it is not, change request is
refused formally.
● Execution: If the previous phase determines to execute the change request, this phase takes
appropriate actions to execute the changes, through a thorough revision if necessary.
● Close request: The change is verified for correct implementation and merging with the rest of the
system. This newly incorporated change in the software is documented properly and the request is
formally closed.

VERSION CONTROL:
Version Control is a system or tool that captures the changes to a source code element: file, folder, image or
binary. This is beneficial for many reasons, but the most fundamental reason is it allows you to track changes
on a per file basis.
Version Control Benefits:
● Secure Access to your Source Code

● File History
● Facilitate Team Communication
● Baseline Trace Ability
● Automated Merge Capabilities
● Ensures no one Over-Writes Someone Else's Code
● Allows for Better Control for Parallel Development
 CHANGE CONTROL AND REPORTING:
Change control is a systematic approach to managing all changes made to a product or system. The purpose
is to ensure that no unnecessary changes are made, that all changes are documented, that services are not
unnecessarily disrupted and that resources are used efficiently. Change control is an essential step in
software life cycle. The change control can be carried out using following steps:
● A change request initiates a changes

● The configuration object is “checked out” of the database.

● The changes are applied to the object.
● The object is then “checked in” to the database where automatic version control is applied.

PROGRAM COMPREHENSION TECHNIQUES:

Program comprehension is a domain of computer science concerned with the ways software engineers
maintain existing source code.
Program comprehension tools only play a supporting role in other software engineering activities of design,
development, maintenance, and re-documentation. Software Engineering discipline which aims at understanding
computer code written in a high-level programming language. Program Comprehension is useful for reuse,
maintenance, reverse engineering and many other activities in the context of Software Engineering.

Program Comprehension Tool:

A program that aims at making the understanding of a software application easier, through the presentation
of different perspectives (views) of the overall system or its components. A PC Tool has modules to:
● Extract information by parsing the source code

● Store and handle the information extracted

● Visualize all the retrieved information

RE-ENGINEERING:
Software re-engineering means re-structuring or re-writing part or all of the software engineering system. It is
needed for the application which requires frequent maintenance.
Software re-engineering is a process of software development which is done to improve the maintainability of
a software system.
Re-engineering a software system has two key advantages:
● Reduced risk: As the software already exists, the risk is less as compared to developing new software.
● Reduced cost: The cost of re-engineering is significantly less than the costs of developing new
software.

Re-engineering process activities:

● Source code translation: In this phase code is converted into new language.

● Reverse Engineering: Under this activity the program is analyzed and understood thoroughly.
● Program structure improvement: Restructure automatically for understandability.
● Program modularization: The program structure is reorganized.
● Data re-engineering: Finally clean-up and restructure system data.
 Origi Program Modula Original
nal documentation rized data
Program program

Reverse
engineering
Program Data
Source code modularization reengineering
translation

Program
structure Structu Re-
improvement red engineer
program ed data

Figure 5.4: Re-engineering process activities

REVERSE ENGINEERING:
Reverse engineering is the process of design recovery. In reverse engineering the data, architectural and procedural
information is extracted from a source code.
The reverse engineering is required because using this technique the dirty, ambiguous code can be converted
to clear and unambiguous specification. This specification helps in understanding the source code.
There are 3 important issues in reverse engineering:
1. Abstraction Level: This level helps in obtaining the design information from the source code. It is
expected that abstraction level should be high in reverse engineering.
2. Completeness Level: The completeness means detailing of abstract level. The completeness decreases
as abstraction level increases.
3. Directionality Level: Directionality means extracting the information from source code and gives it to
software engineer. The directionality can be one way or two way. The one way directionality means
extracting all the information from source code and gives it to software engineer. The two way
directionality means the information taken from source code is fed to re-engineering tool that
attempts to restructure or regenerate old programs.

Dirty source code

Restructured code

Clean source code Process

Extract abstraction Interface

Initial documentation Database

Refine and simplicity

Final specification

Figure 5.5: Reverse engineering process

Difference between reverse and forward and engineering:
S.N Reverse Engineering Forward Engineering
o.
1. It performs transformation from a The traditional process of moving from high-level
lower abstraction to higher one. abstractions and logical, implementation
independent designs to the physical
implementation of a system.
2. Usually done when docs are not appropriate Modification of the system is done. E.g.
or is missing. 1) Use of different programming
language. 2 ) introduction of new DBMS
3) Transfer of s/w to new h/w platform.
3. Reverse engineering is a process in which the Forward-engineering is a process in which theories,
dirty or unstructured code is taken, methods and tools are applied to develop a
processed and it is restructured. professional software product.
4. Reverse Engineering is trying to recreate the Forward engineering is normal engineering. It
source code from the compiled code. That is builds devices that can do certain useful things for
trying to figure out how a piece of software us:
works given only the final system.
5. It is complex because cleaning the dirty or It is simple and straight forward approach.
unstructured code requires more efforts.
6. Documentation or specification of the Documentation or specification of the product is
product is useful to the developer. useful to the end user.
7. This process starts by understanding This process starts by understanding
the existing unstructured code. user requirements.
Table 5.1: Forward and Reverse Engineering

TOOL SUPPORT:
CASE Tool Support:
CASE tools are set of software application programs, which are used to automate SDLC activities. CASE tools
are used by software project managers, analysts and engineers to develop software system.
There are number of CASE tools available to simplify various stages of Software Development Life Cycle such
as Analysis tools, Design tools, Project management tools, Database Management tools, Documentation tools
are to name a few.
Use of CASE tools accelerates the development of project to produce desired result and helps to uncover
flaws before moving ahead with next stage in software development.

Components of CASE Tools

CASE tools can be broadly divided into the following parts based on their use at a particular SDLC stage:
● Central Repository - CASE tools require a central repository, which can serve as a source of common,
integrated and consistent information. Central repository is a central place of storage where product
specifications, requirement documents, related reports and diagrams, other useful information
regarding management are stored. Central repository also serves as data dictionary.
● Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of SDLC.

● Lower Case Tools - Lower CASE tools are used in implementation, testing and maintenance.
● Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC, from Requirement
gathering to Testing and documentation.
 Planning
U
pp
er Int
Analysis
CA eg
SE ra
Design te
d
Lo CA
Implementation w SE
er
CA
Testing SE

Maintenance

Figure 5.6: CASE Component

Project
managemen
t tools
Programming tools
Prototyping
and simulation
tools
Consistency and
completeness tools
Software
C configuration
Documentation tools entral repository management tools
(Data Dictionary)
Analysis and
design tools
Requirement tracing
tools
Database
Transferring tools for management and report
exchanging data in generation tools
different formats

Figure 5.7: Block Diagram for CASE Environment

PROJECT MANAGEMENT CONCEPTS:
Software project management is an activity of organizing, planning and scheduling the software projects. The
goal of software project management is to deliver the software product in given time and within the budget.
It is also necessary that the software project should be developed in accordance with the requirements of the
organization. The project management is the application of knowledge, skill, tools and techniques to project
activities to meet the project requirements.

Objectives of project management:

 ● The objective of the project planning and management is to provide a framework for the project.
● Using the project framework, the project manger decides the estimates for the schedule, cost and
resources.
● Another objective of the project planning and management is that- it should be possible to get the
best case and worst case outcomes of the project.
● There should be sufficient information discovery through the project so that reasonable project
estimate can be made.

FEASIBILITY ANALYSIS:
When the client approaches the organization for getting the desired product developed, it comes up with a
rough idea about what all functions of the software must perform and which all features are expected from
the software.
Referencing to this information, the analysts do a detailed study about whether the desired system and its
functionality are feasible to develop or not.
This feasibility study is focused towards goal of the organization. This study analyses whether the software
product can be practically materialized in terms of implementation, contribution of project to organization,
cost constraints, and as per values and objectives of the organization. It explores technical aspects of the
project and product such as usability, maintainability, productivity, and integration ability.
The output of this phase should be a feasibility study report that should contain adequate comments and
recommendations for management about whether or not the project should be undertaken.

PROJECT AND PROCESS PLANNING:

Project planning is part of project management, in which project manager should recognize the future
problems in advance and should be ready with the tentative solution to those problems. A project plan must
be prepared in advance from the available information. The project planning is an iterative process and it
gets completed only on the completion of the project. This process is iterative because new information gets
available at each phase of the project development. Hence the plan needs to be modified on regular basis for
accommodation new requirements of the project.
Project planning is inherently uncertain as it must be done before the project is actually started. Therefore
the duration of the tasks is often estimated through a weighted average of optimistic, normal, and pessimistic
cases.
The main purpose of this phase is to plan time, cost, and resources adequately to estimate the work needed
and to effectively manage risk. Initial planning generally consists of:
• Developing the scope statement
• Selecting the planning team
• Identifying deliverables
• Creating the work breakdown structure
• Identifying the activities needed to complete those deliverables
• Sequencing the activities in a logical way
• Estimating the resources needed
• Estimating the time needed
• Estimating the costs
• Developing the schedule
• Developing the budget
• Gaining formal approval to begin

RESOURCE ALLOCATIONS:
Once the objectives of the project management are achieved, the project management is to estimate the
resources for the project. Various recourses of the project are:
 • Human or people
• Reusable software components
• Hardware or software components
The resources are available in limited quantity and stay in the organization as a pool of assets. The shortage
of resources hampers development of the project and it can lag behind the schedule. Allocating extra
resources increases development cost in the end. It is therefore necessary to estimate and allocate adequate
resources for the project.
Resource management includes:
• Defining proper organization project by creating a project team and allocating responsibilities to each
team member.
• Determining resources required at a particular stage and their availability.
• Manage Resources by generating resource request when they are required and de-allocating them
when they are no more needed.

SOFTWARE EFFORTS:
Project Estimation
For an effective management, accurate estimation of various measures is a must. With the correct estimation,
managers can manage and control the project more efficiently and effectively.
Project estimation may involve the following:
• Software size estimation: Software size may be estimated either in terms of KLOC (Kilo Line of Code)
or by calculating number of function points in the software. Lines of code depend upon coding
practices. Function points vary according to the user or software requirement.
• Effort estimation: The manager estimates efforts in terms of personnel requirement and man-hour
required to produce the software. For effort estimation software size should be known. This can either
be derived by manager’s experience, historical data of organization, or software size can be converted
into efforts by using some standard formula.
• Time estimation: Once size and efforts are estimated, the time required to produce the software can
be estimated. An effort required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks are divided
into smaller tasks, activities or events by Work Breakthrough Structure (WBS). The tasks are scheduled
on day-to-day basis or in calendar months. The sum of time required to complete all tasks in hours or
days is the total time invested to complete the project.
• Cost estimation: This might be considered as the most difficult of all because it depends on more
elements than any of the previous ones. For estimating project cost, it is required to consider –
o Size of the software
o Software quality
o Hardware
o Additional software or tools, licenses etc.
o Skilled personnel with task-specific skills
o Travel involved
o Communication
o Training and support

PROJECT SCHEDULING:
Project Scheduling in a project refers to roadmap of all activities to be done with specified order and within
time slot allotted to each activity. Project managers tend to define various tasks and project milestones and
then arrange them keeping various factors in mind. They look for tasks like in critical path in the schedule,
which are necessary to complete in specific manner (because of task interdependency) and strictly within the
time allocated. During the project scheduling the total work is separated into various small activities.
 Iden Ide Esti Assign Create
tify ntify possible mate people to activity
activities dependencies resources conduct network and
activities bar charts

Figure 5.8: Project scheduling process

For scheduling a project, it is necessary to:

• Break down the project tasks into smaller, manageable form
• Find out various tasks and correlate them
• Estimate time frame required for each task
• Divide time into work-units
• Assign adequate number of work-units for each task
• Calculate total time required for the project from start to finish

COST ESTIMATIONS:
Cost estimation can be defined as the approximate judgments of the costs for project. Cost estimation is
usually measured in terms of effort. The effort is the amount of time for one person to work for a certain
period of time. COCOMO is one the most widely used software estimation models in the world. The
Constructive Cost Model (COCOMO) is a procedural software cost estimation model .COCOMO is used to
estimate size, effort and duration based on the cost of the software.
COCOMO predicts the effort and schedule for a software product development based on inputs relating to
the size of the software and a number of cost drivers that affect productivity.
COCOMO has three different models that reflect the complexities:
● Basic Model: this model would be applied early in a projects development. It will provide a rough
estimate early on that should be refined later on with one of the other models.
● Intermediate Model: this model would be used after you have more detailed requirements for a
project.
● Detailed Model: when design of the project is complete you can apply this model to further refine
your estimate.
Within each of these models there are also three different modes. The mode you choose will depend on your
work environment, and the size and constraints of the project itself. The modes are:
● Organic: this mode is used for “relativity small software teams developing software in a highly familiar,

in-house environment”.
● Embedded: operating within tight constraints where the product is strongly tied to a “complex of
hardware, software, regulations and operational procedures”.
● Semi-detached: an intermediate stage somewhere in between organic and embedded. Projects are
usually of moderate size of up to 300,000 lines of code.

Basic Model: The basic COCOMO model estimates the software development effort using only Lines Of Code
(LOC). Various equations in this model are:
Effort Applied (E) = ab(KLOC)bb [man-months]
Development Time (D) = cb(Effort Applied)db[months]
People required (P) = Effort Applied / Development Time [count]
Where, KLOC is the estimated number of delivered lines (expressed in thousands) of code for project. The
coefficients ab, bb, cb and db are given in the following table:
Software ab bb cb db
Projects
 Organic 2.4 1.05 2.5 0.38
Semi- 3.0 1.12 2.5 0.35

detached
Embedde 3.6 1.20 2.5 0.32
d
Table 5.2: List of Constants Based on Mode for Basic COCOMO
Intermediate Model: This is an extension of basic COCOMO model. This estimation model makes use of set of
“cost driver attributes“to compute the cost of software.
The formula for effort calculation is:
E=ai(KLOC)(bi)(EAF)
Where E is the effort applied in person-months, KLOC is the estimated number of thousands of delivered
lines of code for the project, and EAF is the factor calculated above. The coefficient ai and the exponent bi
are given in the next table.
Software Projects ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
Table 5.3: List of Constants Based on Mode for Intermediate Model
The Development time D calculation uses E in the same way as in the Basic COCOMO.
Detailed Model: Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering
process.
The detailed model uses different effort multipliers for each cost driver attribute. These Phase Sensitive effort
multipliers are each to determine the amount of effort required to complete each phase. In detailed
COCOMO, the whole software is divided into different modules and then we apply COCOMO in different
modules to estimate effort and then sum the effort.
The effort is calculated as a function of program size and a set of cost drivers are given according to each
phase of the software life cycle.

PROJECT SCHEDULING AND TRACKING:

Project schedule is the most important factor for software project manager. It is the duty of project manager
to decide the project schedule and track the schedule.
Tracking the schedule means determine the tasks and milestone in the project as it proceeds.
Following are the various ways by which tracking of the project can be achieved:
● Conduct periodic meetings.

● Evaluate results of all the project reviews.

● Compare actual start date and scheduled start date of each of the project task.
● Determine if milestones of the project are achieved on scheduled date or not.
● Meet informally to the software practitioners.
● Assess the progress of the project quantitatively.

RISK ASSESSMENT AND MITIGATION:

Risk management involves all activities pertaining to identification, analyzing and making provision for predictable
and non-predictable risks in the project. Risk may include the following:
 ● Experienced staff leaving the project and new staff coming in.
● Change in organizational management.
● Requirement change or misinterpreting requirement.
● Under-estimation of required time and resources.
● Technological changes, environmental changes, business competition.

Process of Risk Management:

Risk management performed in following stages:
1. Risk identification: In this phase all possible risks are anticipated and a list of potential risks are
prepared.
2. Risk analysis: After risk identification, a list is prepared in which risks are prioritized.
3. Risk planning: The risk avoidance or risk minimization plan is prepared in this phase.
4. Risk monitoring: Identified risks must be mitigated. Hence risk mitigation plan must be prepared once
the risks are discovered.

Risk identification Risk analysis Risk planning Risk monitoring

List of identified Prioritized list of Risk avoidance Risk

risks risk /minimization plan assessment

Figure 5.9: Risk management process

Risk Mitigation, Monitoring and Management (RMMM):
Risk analysis supports the project team in constructing a strategy to deal with risks.
There are three important issues considered in developing an effective strategy:
● Risk avoidance or mitigation - It is the primary strategy which is fulfilled through a plan.

● Risk monitoring - The project manager monitors the factors and gives an indication whether the risk is
becoming more or less.
● Risk management and planning - It assumes that the mitigation effort failed and the risk is a reality.

RMMM Plan:
● It is a part of the software development plan or a separate document.

● The RMMM plan documents all work executed as a part of risk analysis and used by the project
manager as a part of the overall project plan.
● The risk mitigation and monitoring starts after the project is started and the documentation of RMMM
is completed.

SOFTWARE QUALITY ASSURANCE (SQA):

Software Quality:
In the context of software engineering, software quality measures how well software is designed (quality of
design), and how well the software conforms to that design (quality of conformance).
 Quality Control:
Quality control (QC) is a procedure or set of procedures intended to ensure that a manufactured product or
performed service adheres to a defined set of quality criteria or meets the requirements of the client or
customer.

Quality Assurance:
It is planned and systematic pattern of activities necessary to provide a high degree of confidence in the
quality of a product. It provides quality assessment of the quality control activities and determines the
validity of the data or procedures for determining quality.

SQA Activities to Assure the Software Quality

The Software Quality Assurance of the software is analyzed and ensured by performing a series of activities.
The activities are performed as step by step process and the result analysis is reported for the final evaluation
process. The activities are performed as step by step process and the result analysis is reported for the final
evaluation process.
A Quality Management Plan is prepared
● Application of Technical Methods (Employing proper methods and tools for developing software)

● Conduct of Formal Technical Review (FTR)

● Testing of Software
● Enforcement of Standards (Customer imposed standards or management imposed standards)
● Control of Change (Assess the need for change, document the change)
● Measurement (Software Metrics to measure the quality, quantifiable)
● Records Keeping and Recording (Documentation, reviewed, change control etc. i.e. benefits of docs).

PROJECT PLAN:
A project plan is a formal document designed to guide the control and execution of a project. A project plan
is the key to a successful project and is the most important document that needs to be created when starting
any business project.
A project plan is used for the following purposes:
● To document and communicate stakeholder products and project expectations

● To control schedule and delivery

● To calculate and manage associated risks

PROJECT METRICS:
Metrics is a quantitative measure of the degree to which a system, component, or process possesses a given
attribute.
Project metrics are quantitative measures that enable software engineers to gain insight into the efficiency of
the software process and the projects conducted using the process framework. Project metrics are used by a
project manager and a software team to adapt project work flow and technical activities.

Size Oriented Metrics:

● Size oriented measure is derived by considering the size of software that has been produced.

● The organization builds a simple record of size measure for the software projects. It is built on past
experiences of organizations.
● It is a direct measure of software
● A simple set of size measure that can be developed is as given below:
o Size= KLOC
o Effort = Person/month
 o Productivity=KLOC/ Person-month
o Quality= number of faults/KLOC
o Cost=$/KLOC
o Documentation= Pages of documentation/KLOC

Function Oriented Metrics:

● Use a measure of the functionality delivered by the application as a normalization value.

● Functionality cannot be measured directly; it must be derived indirectly using other direct measures.
• A measure called the function point.
• Function points are derived using an empirical relationship based on countable (direct) measures of
software's information domain and assessments of software complexity.
How to calculate Function Point?
Domain Count Weighting factor Count
Characteristics Simple Average Complex
Number of user input x 3 4 6
Number of user output x 4 5 7
Number of user x 3 4 6
inquiries
Number of files x 7 10 15
Number of external x 5 7 10
interfaces
Count Total
Table 5.4: Function Point calculation table

Number of user inputs. Each user input that provides distinct application oriented data to the software is counted.
Inputs should be distinguished from inquiries, which are counted separately.

Number of user outputs. Each user output that provides application oriented information to the user is
counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a
report are not counted separately.

Number of user inquiries. An inquiry is defined as an on-line input that results in the generation of some
immediate software response in the form of an on-line output. Each distinct inquiry is counted.

Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a large
database or a separate file) is counted.

Number of external interfaces. All machine readable interfaces (e.g., data files on storage media) that are
used to transmit information to another system are counted.

To compute function points (FP), the following relationship is used:

FP = count total [0.65 + 0.01 Σ(Fi)] where count total is the sum of all FP entries .

The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions:
1. Does the system require reliable backup and recovery?
2. Are data communications required?
 3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?

Object Oriented Metrics:

Following are the set of metrics for object oriented projects:
1. Weighted Methods per Class
Number of methods defined in class
● Complex methods weigh more

● Higher numbers = more faults

● Classes are more specific = hard to reuse

● Changes have more impact on subclasses

2. Depth of Inheritance Tree
Number of super classes
● Measures depth of hierarchy

● Deep trees imply more complexity

● Inheritance should reduce complexity not increase it

● Deep trees promote reuse

● Bugs are found in middle of tree

3. Number of Children
Number of immediate subclasses
● Measures breadth of hierarchy

● Depth (DIT) implies reuse in a way breath (NOC) does not

● Large numbers mean high reuse of base class; test it!

● High NOC related to lower faults.

● BUT, perhaps improper use of base class

4. Coupling between Object Classes
 Number of classes to which I am coupled
● Coupling → We use each other’s data or methods

● High CBO is undesirable

● Prevents reuse

● Sensitivity to changes in others increases maintenance

● > 14 is too high

5. Response For a Class

Total number of methods executed
● Large RFC = more faults

● If most methods have a small RFC but one method has a

● Hugh RFC

● you have a structured (not OO) application

● Lack of Cohesion of Methods

How well the methods of a class are related to each other?
o A cohesive class performs one function
o Highly cohesive classes promotes encapsulation
o but have highly coupled methods
o Low cohesion = more error