Defect,time tracking for team software projec
Brought to you by:
ken_raisor,
tuma
Menu
▾
▴
Hi,
In the TSP launch meetings, we made our conceptual design. What we did next is , construct our team software project in dashboard. Our software product consists of 15 software modules(what we call them "Software Configuration Item"). In work breakdown structure view we entered all 15 software modules. Our goal is to track time and defects for each software modules in dashboard. But we see that when defining quality plan , you define your quality goals for whole projects (for all 15 modules.).We want to define it for each software modules and track it for each sofware modules?? Is there any way to do this?? Like define software product as master project and modules as team project….?
To answer, allow me to point out that a Quality Plan has two distinct parts: inputs and outputs.
In a TSP launch, you create a high level plan that includes the modules that you plan to produce. This generally occurs in meetings 1-4.
Next, you produce the quality plan. To produce a quality plan, you have to make decisions about several INPUT parameters:
1) The average number of defects that you inject per hour when designing, coding, etc.
2) The yield that you anticipate achieving in your reviews and inspections
3) The goals that you have for time-in-phase ratios (for example, design time vs code time)
4) The goals that you have for defect density (for example, the number of defects per KLOC in unit test)
These items are fairly universal. They are not generally specific to a particular MODULE; instead, they quantitatively describe your behaviors as a TEAM. If you, as a team, plan to strive for 70% yield in a code review, this is generally a goal that will apply to every module. I have never heard of a team that wanted to plan to achieve a lower inspection yield on "Module 1" than they do on "Module 2."
Since these items are universal, you only have to enter them once, on the Project Parameters and Settings page. Then, these INPUT parameters apply to every module in your project.
With these INPUT parameters in place, you can now examine the data that is OUTPUT by the quality model.
OUTPUT values include items like the expected defects injected and removed in various phases, and the number of defects that will be present in a module when it is delivered to a customer.
It is certainly useful to examine these outputs for the entire project, or for a single module. So the dashboard makes this fairly simple.
In the Team Dashboard, open the TSP Rollup Plan Summary and click on items such as the Quality Summary and Analysis Charts. When you are viewing these, you will notice one or two icons near the top of the page, immediately below the name of your project. If you put your mouse over these icons, you will see a tooltip such as "Navigate Hierarchy". Click on that icon and choose a particular module. Then, you will be viewing the Quality Plan for that module only. To return to the Quality Plan for the entire project, click on the icon again and select the top node for the project.
Hi Keminis:
Two other perspectives.
First, you would not want to lower the quality numbers for some modules. Humphrey (in the TSPi text) makes the point that the (low) quality of is usually caused by a small minority of modules in an overall system. Most modules are fine, but a few bad ones cause almost all the trouble. So, your team would not want to allow lower quality modules into your overall system. Module PQI, Percent Defect Free, and Component Quality Review in TSPi are metrics design to smoke out low quality modules.
Second, quality cost money-at least in the short run. Design (a quality process in PSP/TSPi), Personal Reviews and Team Inspections all cost money. My experience in academic TSPi is that, if the students meet the defaults for quality, and they meet the several metrics for their modules (Design Time > Code Time, DLDR time > 50% * Design Time, …), their modules have no (or very minor) Integration Test Defects and no more than 1 System Test Defects (usually zero). So, there is no reason to make the module numbers more demanding than the defaults.
From what I can tell, the default numbers from TSPi (these are provided by the Team Dashboard) find the sweet spot between being too low (allowing low quality modules to enter the TEST phase), and too high (costing money that does not have any benefit for overall system quality).
Again, I have only taught TSPi and never done an industrial sized TSP project; but before you change the defaults you should make sure you have address the above two arguments.
rfrederi
thanks for your quick replies.. I got the point.. :)