Implement a KPI dashboard
Implement a KPI dashboard: overview of the development tasks
This page provides an overview of the development tasks needed to implement a KPI dashboard using Spago4Q. The implementation of a KPI dashboard could be a complex work , it requires to start a specific project. During the analysis phase all the requirements will be identified and the following preliminary tasks have to be realized:- a clear identification of the KPIs using, for example a Goal Question Metric method
- for every KPI: a complete definition of the algorithm, measure attributes and granularity level
- identification of the sources of the measure attributes (i.e. bugtracking tools, SVN, checkstyle, and so on).
The method and model proposed here may help you to approach exaustively the analysis phase.
The development of a KPI dashboard could be divided in two phases:
Phase 1: extract and load the data into the datawarehouse
- task 1.1 - configure the data source
- task 1.2 - configure and create the target database
- task 1.3 - define the extraction and transformation process
Phase 2: implement the dashboard
- task 2.1: Define a model
- task 2.2: Define kpis and thresholds
- task 2.2.1: create "dataset" , the dataset implements the kpi's algorithm
- task 2.2.2: create "analytical document" , the "analytical document" represents the kpi such as graph or a "composed document" (refer to SpagoBI documentation)
- task 2.3: Create a Model Instances (it establishes relationship between: model or a subset of a model, kpis and thresholds, resources (projects, products, ...)
- task 2.4: Configure the dashboard (named "KPI document" in the following) that represent the KPI included into the model instance.
Each task is described with reference to the following use case.
Use case - SLA Model
The aim is to create a dashboard, such as "Basic Model View" for monitoring a supply of software development and maintenance services. The model includes KPIs for both the services.
- UC-NEW-DEVSW
- UC-SLA-1.01 QualityOfDeliverables
- UC-SLA-1.02 ComplianceEndDate
- UC-SLA-1.03 DefectsSeverityBlocking (in Acceptance Test)
- UC-SLA-1.04 DefectsSeverityNotBlocking (in Acceptance Test)
- UC-SLA-1.01 QualityOfDeliverables
- UC-MANSW&HD
- UC-SLA-2.01 IncidentBLInterventionTime ( severity Blocking)
- UC-SLA-2.02 IncidentNBLInterventionTime ( severity Not Blocking)
- UC-SLA-2.03 IncidentBLResolutionTime ( severity Blocking)
- UC-SLA-2.04 IncidentNBLResolutionTime ( severity Not Blocking)
- UC-SLA-2.05 PhoneCallResponseTime
- UC-SLA-2.06 MultichannelResponseTime
- UC-SLA-2.01 IncidentBLInterventionTime ( severity Blocking)
The datawarehouse created in Phase 1 will be loaded using Generic XML Extractor functionality that collects the metrics from an XML file formatted in a predefined structure.