KnowledgeCity

How can we qualify/quantify the area of expertise of a software developer working on one of CFMU's (oooopppss DNM's) systems? Can we use the records from Remedy, i.e. the SCs and relevant items linked to them?

CAVEAT

It is true that software is more often read than written 1, and as such the numbers out of a KnowledgeCity-like analysis should be complementary to any other source of information, i.e. feedback from team leader/co-workers.

1 Bracha, Gilad and Griswold, David "Strongtalk: typechecking Smalltalk in a production environment", http://doi.acm.org/10.1145/165854.165893

DONE ##

• tried to describe the idea here
• (draft) unix scripts to extract the data

TODO ##

1. assess the idea

2. gather data and prototype for 1 user with spreadsheet with coarse and fine granularity: Generate a csv file with Change Id, Originator, Responsible, System, CR Reference, I2 Reference, Topic, Item System, Item Subsystem, Path, File Name

3. If a 3D view is to be used it is necessary to understand what is mapped to what. width = ? height = ? color = ? relative position (two variables here) = ?

4. address Ada and C++ clustering of filenames

5. some histogram

Introduction

This is an experimental area dedicated to explore the prototype of KnowledgeCity.

The idea is to try to complement TLs input on team members' skills and area of expertise with 'data from the field'. The inspiration comes from CodeCity.

If you think about our closure graph, i.e. TACT closure, you can think of each closure component as a city block. Certain CFMU systems are easier to cluster into (city-like) blocks, for example Java software with its package oriented file organization can be naturally organized. The case of Ada or C++ sources is more difficult and clustering for them will probably need the use of some AI techniques: k-means, expectation maximization.

TACT closure graph was generated on Linux by

$ Cgraph -b TACT.TACT\_CONFIG.LATEST -o TACT_closure.gif

Tech details ##

Typically we save code changes tagged with SC (Software change) and since some time (ca. 2000) we load the mane of the impacted version-controlled entities in Remedy.

This allows us to produce a release note in semi-automated mode where we can extract all CRs/SCs/I2s/PADs between 2 selected system family baseline builds.

The same data could be used to extract where somebody has worked and have an automated way to assess in which heads the knowledge resides: this is not perfect science but could be instructive to see if it somewhat confirms what TLs report. It can also be useful to

• investigate whether there are uncovered areas (and it could well be that they are untouched bacause stable...or dead)

• see what area of code will be left uncovered if somebody leaves

• ...

Remedy Queries ##

The following are representative Remedy queries that can be used from Advanced (Manual) Search box:

• One of all SCs in 2011 for BYG is for example SC_056402)

    (('Date & Time' >= "01/01/2011 00:00:00") AND ('Date & Time' <=
    "01/02/2012 00:00:00")) AND ('Originator' = "BYG" OR 'Responsible' = "BYG")
  

• for SC_056402 above, the list of version controlled entities, a.k.a. files, impacted comes from the following Remedy query

    'SC ID' = "SC_056402"  AND 'File Name' != $NULL$
  

  One of them is for example this.

The (draft) idea ##

In principle the data can be extracted: we have all SC worked by <who> and associated to baseline build items, so that a per person histogram can be produced for all files belonging to which component in the various CFMU systems. For the example data in Tact closure, list of SCs, items for SC and baseline item details we could count how many times file an1_receiver_task-direct_control.adb in component CORE of system TACT has been 'touched' by BYG in 2011.

• For fine-grained classification: It is true that inside CORE you have clear clusters of files with related functionality which have the same prefix, for example atfm_message_... all_ft... casa... casa_task... ccams-client... ccams_contingency... and this is just special of TACT; CHMI or CUA have probably different ways to organise the code either structurally (directories for the package name in Java) or by logically by name-prefix.

• for coarse granularity we could restrict the view to TACT/CORE