Linker

linker + silap
- no join to silap (early lifecycle observations)
- technical problems with that join
  1) unit of measurement difference
     PITS: SCSI
	 SILAP: whatever is out there . "any software element"
  2) the synonym problem
		a) MB1: anonymous sanitized names
		b) PITS: full project name
  3) LINKER maintained by Deadrick;'s team. SILAP data maintained
     by another team, not even in a database (just excel sheets)
     

linker-
- sucks data in from PITS
- can report costs assocate with each task, not with individual issues.
- cannot access developer issues
- can safely provide full access to LINKER to clinets since LINKER
  does not write back to PITS
- originally designed to be a data repository
- limited foresight regarding the need for a robust querying capability
	- undergoing major revision
	- original vision, a set of canned queries
	- subsequent experience motivated a major re-engineering

Pits - a per-project database. can't see how to usethe PITS screesn to
query across projects. so the ability oto generalize from the
experience in multiple projects is limites

what is the ideal db query- one that addresses the core business case of
this unit. i.e. we find bugs earlier than other projects; i.e. leakage
with IV&V is less than leakage without.
BUT cant do that since we dont have access to developer issues

audit of the data dictionary.
- rang through the dabney model. 
- many diagrams, three generic forms
- most of the dabney ontology not observable
- would need a combination of COCOMO/SILAP/PITS/LINKER to get the rest
- but very little of the remaining actually in current data bases

dabnet- of the space of things we want to measure, we only might access 10 * {requirements, integration,  design, code}
- and some we'll never get ((e.g. tool use)