SIM5102

1. SIM5102 A Metrics Database: SCOPE (Software Certification Programme in Europe)

2. 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

3. 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

4. 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.

5. 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

6. Motivations • Database • Combine data from two or more sources • Relational database – consists number of a number of tables of data which can be cross-referenced • Allow us to add and update metrics data and then extract it later as it is needed

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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