The implementation of our system is achieved using C#.Net on a Windows XP operating system and Microsoft Visual Studio as a development environment. The main classes of our implemented system and their methods are illustrated in Figure 6.12. Given the complexity of applying the tool to all work products of a phase let alone all the SDLC phases, It was decided to limit the application of our tool to the work product of type Highof the requirements phase so that the functionality of the tool is comprehended.
Figure 6.1: Tool User Interface
The user interface of our application is designed to include all the components of our system at once so that it is easily usable and gives the project manager and the QA prac- titioners the main points of control and interaction. An overview of the main application window is depicted in Figure 6.1.
6.2.1
The Entry of QA Practices
The first component of our application is the QA Techniques entry. In this stage, as is illustrated in Figure 6.2, software QA practitioners will enter the QA techniques and practices that are meant to be applicable to the requirements phase and are going to be utilised in the QA process for defect detection and removal activities. This list of practices will be recognised by our application once they are entered by the QA practitioner and are reserved a physical structure in the database of the system’s repository. A description of the technique can also be added in a separate column next to its name to highlight its purpose.
Figure 6.2: QA Techniques Entry Window
6.2.2
Project Detail Entry
The next component of our application is the Project Details entry process. At the be- ginning of any new software project development, QA practitioners will use the project
details component of the application to store the details of the project under development (Figuer 6.3).
Figure 6.3: Project Details Input Window
Such project details are the phase name, total phase size, labour rate and defect esca- lation cost. Some of those entries like the estimated phase size and defect escalation cost are going to be verified later, after the completion of the software development process. In other words, once the software project is completed the size of the phase will be de- termined accurately and compared to the initial estimates of size given by cost estimation
models used like COCOMO II and then updated in the system repository.
This is also applicable to the defect escalation cost which will use an experimental value from past projects and will be updated later, on the completion of every new project.
6.2.3
Work Products Categorisation
The second part that follows the project details entry process is the work products cate- gorisation. Considering our application as a prototype for demonstrating the system func- tionality only, it is assumed that there are three levels of risk, High, Medium and Low, by which artifacts of software life cycle phases are categorised. Each category is assigned a weight expressed as a percentage value (%) constituting the total size of the phase deliver- able. The mechanism of work products categorisation was previously detailed in Section 4.4.
The tabular form located below the main window of the project details (Figure 6.3) will include details of the previous projects that were developed following the same ap- proach to show the depth of the repository with regard to the same phase. As was de- termined in Chapter 4, QA practitioners should apply the system initially to the first five projects so as to build enough of a repository of QA data to lend more accuracy and effectiveness to their decisions.
6.2.4
Details of QA Activity Entry
After defining the project name and risk weights for the phase’s work product, the QA practitioner moves to the defect entry component of the tool. In this stage, relevant defect details resulting from current QA activities are entered and stored.
As shown in Figure 6.4, there are three pull-down menus for the project name, the number of QA practices defined before for that project and the work product categories. Note that the bug details window should include the phase name of the project, but as was clarified at the beginning of this chapter, our application is to demonstrate the functionality of our system in the requirements phase only.
Figure 6.4: QA Activity Details
The user assigns a coverage weight (%) value (β) for the QA practice chosen to per- form the QA activity, and will then enter the number of defects found during the applica- tion of this QA practice.
The number of escaped defects from the QA practices chosen will be updated later once the system testing phase completes. The entries of the shaded input boxes (size of work
product, % defects found, % defect escaped, etc.), are going to be calculated automatically based on the defects input details.
Moreover, the user should enter the execution duration required for applying the chosen QA practice; the input box Time(H) will include the overall duration of applying a QA practice with respect to the weight given. Then the Execution time box will calculate the estimated average duration time in an hour/functional point unit of measure. The cost of the defect removal process is entered in the input box Cost(£) and based on that, the tool will calculate the average cost per defect removal and show it to the user in the Removal cost box in a £/defect unit of measure. This measure is based on the labour rate value defined earlier in the project details component.