Measurement is fundamental to any engineering discipline and software engineering

is no exception. Software metric is a quantitative measure derived from the attribute
of software development life cycle [Fanton and Kaposi, 1987]. It behaves as software
measures.

A software measure is a mapping from a set of objects in the software engineering
world into a set of mathematical constructs such as numbers or vectors of numbers.
Using the software metrics, software engineer measures software processes, and the
requirements for that process. The software measures are done according to the
following parameters:

 The objective of software and problems associated with current activities,
 The cost of software required for relevant planning relative to future projects,
 Testability and maintainability of various processes and products,
 Quality of software attributes like reliability, portability and maintainability,

 Utility of software product,
 User friendliness of a product.

Various characteristics of software measures identified by Basili (1989) are given
below:

 Objects of measurement: They indicate the products and processes to be
measured.

 Source of measurement: It indicates who will measure the software. For
example, software designer, software tester and software managers.

 Property of measurement: It indicates the attribute to be measured like cost of
software, reliability, maintainability, size and portability.

 Context of measurement: It indicates the environments in which context the
software measurements are applied.

Common software measures

There are significant numbers of software measures. The following are a few
common software measures:

Size : It indicates the magnitude of software system. It is most commonly used
software measure. It is indicative measure of memory requirement, maintenance
effort, and development time.

LOC : It represents the number of lines of code (LOC). It is indicative measure of
size oriented software measure. There is some standardisation on the methodology of
counting of lines. In this, the blank lines and comments are excluded. The multiple
statements present in a single line are considered as a single LOC. The lines
containing program header and declarations are counted.

The requirements gathering is an art. The person who gathers requirements should
have knowledge of what and when to gather information and by what resources. The
requirements are gathered regarding organisation, which include information
regarding its policies, objectives, and organisation structure, regarding user staff. It
includes the information regarding job function and their personal details, regarding
the functions of the organisation including information about work flow, work
schedules and working procedure.

The following four tools are primarily used for information gathering:

1. Record review: A review of recorded documents of the organization is
   performed. Procedures, manuals, forms and books are reviewed to see format and
   functions of present system. The search time in this technique is more.

1. On site observation: In case of real life systems, the actual site visit is performed
   to get a close look of system. It helps the analyst to detect the problems of existing
   system

3. Interview: A personal interaction with staff is performed to identify their
   requirements. It requires experience of arranging the interview, setting the stage,
   avoiding arguments and evaluating the outcome.

3. Questionnaire: It is an effective tool which requires less effort and produces a
   written document about requirements. It examines a large number of respondents
   simultaneously and gets customized answers. It gives person sufficient time to
   answer the queries and give correct answers.

 There are various features that make requirements analysis difficult. These are

discussed below:

1. Complete requirements are difficult to uncover. In recent trends in engineering,
   the processes are automated and it is practically impossible to understand the
   complete set of requirements during the commencement of the project itself.
2. Requirements are continuously generated. Defining the complete set of
   requirements in the starting is difficult. When the system is put under run, the new
   requirements are obtained and need to be added to the system. But, the project
   schedules are seldom adjusted to reflect these modifications. Otherwise, the
   development of software will never commence.
3. The general trends among software developer shows that they have over
   dependence on CASE tools. Though these tools are good helping agents, over
   reliance on these Requirements Engineering Tools may create false requirements.
   Thus, the requirements corresponding to real system should be understood and
   only a realistic dependence on tools should be made.
4. The software projects are generally given tight project schedules. Pressure is
   created from customer side to hurriedly complete the project. This normally cuts
   down the time of requirements analysis phase, which frequently lead to
   disaster(s).
5. Requirements Engineering is communication intensive. Users and developers
   have different vocabularies, professional backgrounds and psychology. User
   writes specifications in natural language and developer usually demands precise
   and well-specified requirement.
6. In present time, the software development is market driven having high
   commercial aspect. The software developed should be a general purpose one to
   satisfy anonymous customer, and then, it is customised to suit a particular
   application.
7. The resources may not be enough to build software that fulfils all the customer‟s
   requirements. It is left to the customer to prioritise the requirements and develop
   software fulfilling important requirements.

 This document is generated as output of requirement analysis. The requirement

analysis involves obtaining a clear and thorough understanding of the product to be
developed. Thus, SRS should be consistent, correct, unambiguous & complete,
document. The developer of the system can prepare SRS after detailed communication
with the customer. An SRS clearly defines the following:

 External Interfaces of the system: They identify the information which is to flow
„from and to’ to the system.
 Functional and non-functional requirements of the system. They stand for the
finding of run time requirements.
 Design constraints:

The SRS outline is given below:

1. Introduction
   1.1 Purpose
   1.2 Scope
   1.3 Definitions, acronyms, and abbreviations
   1.4 References
   1.5 Overview
2. Overall description
   2.1 Product perspective
   2.2 Product functions
   2.3 User characteristics
   2.4 Constraints
   2.5 Assumptions and dependencies
3. Specific requirements
   3.1 External Interfaces
   3.2 Functional requirements
   3.3 Performance requirements
   3.4 Logical Database requirements
   3.5 Design Constraints
   3.6 Software system attributes
   3.7 Organizing the specific requirements
   3.8 Additional Comments
4. Supporting information
   4.1 Table of contents and index
   4.2 Appendixes

 Advantages :

 It is fast and efficient when dealing with large volumes of data that need to be
processed periodically (batch system).

Disadvantages

 Requires that all new transactions be sorted into the proper sequence for
sequential access processing.
 Locating, storing, modifying, deleting, or adding records in the file require
rearranging the file.
 This method is too slow to handle applications requiring immediate updating or
responses.

 An error is said to have occurred if the execution of a command to manipulate the

database cannot be successfully completed either due to inconsistent data or due to
state of program. For example, there may be a command in program to store data in
database. On the execution of command, it is found that there is no space/place in
database to accommodate that additional data. Then it can be said that an error has
occurred. This error is due to the physical state of database storage.

Broadly errors are classified into the following categories:

1) User error: This includes errors in the program (e.g., Logical errors) as well as
errors made by online users of database. These types of errors can be avoided
by applying some check conditions in programs or by limiting the access rights
of online users e.g., read only. So only updating or insertion operation require
appropriate check routines that perform appropriate checks on the data being
entered or modified. In case of an error, some prompts can be passed to user to
enable him/her to correct that error.

2) Consistency error: These errors occur due to the inconsistent state of database
caused may be due to wrong execution of commands or in case of a transaction
abort. To overcome these errors the database system should include routines
that check for the consistency of data entered in the database.

3) System error: These include errors in database system or the OS, e.g.,
deadlocks. Such errors are fairly hard to detect and require reprogramming the
erroneous components of the system software.

Database errors can result from failure or can cause failure and thus will require
recovery. However, one of the main tasks of database system designers is to make
sure that errors minimized. These concepts are also related to database integrity and
have also been discusses in a later section.

 “Fragmentation involves decomposing the data in relation to non-overlapping

component relations”.
Why do we need to fragment a relation? The reasons for fragmenting a relation are:

Use of partial data by applications: In general, applications work with views
rather than entire relations. Therefore, it may be more appropriate to work with
subsets of relations rather than entire data.

Increases efficiency: Data is stored close to most frequently used site, thus retrieval
would be faster. Also, data that is not needed by local applications is not stored, thus
the size of data to be looked into is smaller.

Parallelism of transaction execution: A transaction can be divided into several
sub-queries that can operate on fragments in parallel. This increases the degree of
concurrency in the system, thus allowing transactions to execute efficiently.

Security: Data not required by local applications is not stored at the site, thus no
unnecessary security violations may exist.

But how do we carry out fragmentation? Fragmentation may be carried out as per the
following rules:

a) Completeness: This rule ensures that there is no loss of data during
fragmentation. If a relation is decomposed into fragments, then each data item
must appear in at least one fragment.

b) Reconstruction: This rule ensures preservation of functional dependencies.
It should be possible to define a relational operation that will reconstruct the
relation from its fragments.

c) Disjointness: A data item that appears in a fragment should not appear in
any other fragment. However, a typical fragmentation called vertical
fragmentation is an exception to this rule. In vertical fragmentation the primary
key attributes must be repeated to allow reconstruction of original relation.
This rule ensures minimization of data redundancy.