Transcript scopedatabase

SIM5102
A Metrics Database: SCOPE
(Software Certification
Programme in Europe)
Motivations
• Need to collect together the data from
different sites and different sources and
store them at central site
• Three ways that metrics data can be
stored
• On paper forms
• In electronic flat files
• In a database
Motivations
• Paper form
– The cheapest and easiest means of storage –
for very small amounts of data
– Very difficult to back up
– Have to photocopying each sheet of paper
Motivations
• Flat files
– Only storing data from a single source (i.e.
from one tool)
– A text file – data is represented in the form of
two-dimensional table
“main”, 1, 23, 5.7, 44, 8
“proc1”, 2, 34, 6.3, 33, 9
“proc2”, 3, 46, 10, 23, 12.
Motivations
– Advantages over paper forms
• Most statistical and spreadsheets packages can
import and export flat files
• Can be stored electronically and readily copied
and backed up
• Can be concatenated – data can be combined –
but only if the set and ordering is exactly the same
Motivations
o Database
• Combine data from two or more sources
• Relational database – consists number of a
number of tables of data which can be crossreferenced
• Allow us to add and update metrics data and then
extract it later as it is needed
REQUIREMENTS FOR THE DATABASE SYSTEM
• Although the database system was built specifically to
support the activities of the SCOPE project, there are
many aspect of the requirements that will apply to other
types of metrics schemes
• SCOPE project required a simple and effective way of
transferring all the relevant data to a central site
REQUIREMENTS FOR THE DATABASE SYSTEM
• The database should therefore have the
following properties
– The transfer procedure should be automated and
require minimal human interaction – make the system
cheap to use and less prone to error
– The system should be adaptable to incorporate many
of the tools used in applying assessment techniques
– The system should be reliable - chance of data being
corrupted or lost is minimized
– The system should be platform-independent (e.g.
hardware, OS) to be generally usable
ARCHITECTURE OF THE DATABASE SYSTEM
• Various parts of the database
– Database proper – consist of tables and
relations
– The input routines (CMFI)
– The output routines (CMFO)
– Data transfer tools
– Encryption tools
Database proper
– Database would consist of nothing other than metric
values – we would not know what the metrics values
referred to
– The following classes of data therefore had to be
added to make the metrics analysable:
• Naming data – names of components – subsystem, modules,
etc.
• Configuration data – version and date of the components
• Component-structure data – links modules to their respective
subsystem and subsystem to their respective system
• Project data – information about all the application domain
and development style
Database proper
– Naming and configuration data are necessary
because:
• We can query the database and extract metrics
related to particular components or sets of
components
• When the data is transferred to the database, we
will know what the metric values refer to
Components-structure data – allow us to aggregate
metrics and determine which modules and
subsystems belong to which products
Database proper
• Project data gives background information about
the software product such as
– The application domain,
– The criticality of the product
– And high-level information about the process
DATA TRANSFER
• Transferring data as text
– One common feature in all current computer system –
represented as ASCII
– Transfer file using ftp or kermit
– Can transfer data between different sites by standard floppy
disks, tapes or email
– Have to ensure that the metrics tool used in assessment do
produce their metrics in text files in an agreed format
– If the metrics tool is window-based and the metrics values are
only displayed on the screen with no text-output.
– Solution – persuade the tool makers to produce metrics data in
some agreed format perhaps confirming to an international
standard – base on CMF
Data Transfer
• The Common Metrics Format (CMF)
– A defined file syntax which is used to express
the metric data output by tools in a text file
– Easily readable and the language is flexible to
allow new metrics to be added or old metrics
to be removed
Data Transfer
• Inputting data to the database
– The database input routines (known as CMFI) read in
the CMF files and check the syntax is correct
– Perform some consistency checking such as:
• Validity of ranges of metrics and
• Provides warnings to the users if inconsistencies are found
– CMFI has no difficulty in processing a file that
contains metrics from different case studies or
sources – all the relevant information should present
in the CMF file
– If the data refers to a new case study, CMFI will
automatically create new entries in the tables to
accommodate this
Data Transfer
• Outputting data
– Data can be extracted from the database by
using SQL
– Data can be output in any format required
including the common metrics format
– Known as CMFO
– The most used format – a flat file format so
that data can be read in by statistics
packages