Research Questions

Under this headline I will present the two research questions I seek to answer. These questions are directly linked to the base-model of Abdel-Hamid, and will act as guideposts for my reply. My first question focuses on the different subsystems of the base-model, and central assumptions related to the software development process within the model as a whole. My first question is:

Q1: Are there any unrealistic assumptions in Tarek Abdel-Hamid’s “Software Development Project management” model? If so, how we can modify those assumptions to make the model more realistic?

Here I wish to draw out the quality assurance, rework and testing phases as areas of concern.

There are four reasons for this choice. The first reason lies in the room for improvement highlighted by the author himself, and the function of quality assurance, rework and testing presented in the model. In the end of Abdel-Hamid’s thesis he provides several areas that will require improvements in future research. One of the areas that will need enhancements is software quality (Abdel-Hamid, 1991: p.227).

My motivation for doing this research, rest on the possibility to achieve increased software quality. Quality of software products hinges on the three efforts of quality assurance, rework and testing, and will therefore be suitable for further enhancements. Further-more, in previous studies the analysis of the quality assurance efforts were largely focused as a cost-function of production. The question of allocation was only addressed according to cost-estimates and not by the nature of the process. Hence, important questions like motivational factors on the rework effort were never addressed. Therefore I find enhancement potential in the realm of quality assurance, rework and testing.

The second reason for choosing these three efforts rests with their pivotal position in regards to project costs and errors. From the literature review, we learn that quality assurance efforts are considerable in order to detect errors during the production process. These errors are then reworked at a later stage by the production teams. These quality check and rework efforts are very important in understanding costs and benefits regarding quality of software products.

Managements allocate resources to quality assurance, rework and testing. The manpower allocated to these efforts decrease the manpower available for production activities. It is very important to balance the allocation of manpower between the different efforts depending on the production process. With my enhancements, the need for re-allocation of manpower to testing at an earlier stage is a key consideration. Increased realism and new information available for management, new considerations on manpower allocation are necessary.

The third reason rests on the apparent lack of a feedback connection between the testing phase and rework phase in the model. In the base model systems testing is the final effort before the project is complete. However, from the literature we see that medium sized software projects run testing in tandem with rework and quality assurance at set stages. Therefore there is a major assumption that the testing-phase commences as an end process to production. As a result, the errors found at testing are not fed back into the production process to get reworked and corrected. This constitutes a dead-end in the model. This is a vital point for improving our understanding of the relationship between rework and testing that is currently missing in the base model. By addressing the relationship with rework and testing I will be able to increase the realism of the model, and it provides a valuable point of entry for policy-decisions.

The fourth and final reason rests on testing process. When we look at the literature on software production we find ample evidence for several stages of testing during a project’s lifecycle. Looking at data provided from the U.S on testing in software projects, we find that only 2% of projects utilize only one testing stage. The most common number of testing-stages is 6, appearing in 21% of software projects (Jones & Bonsignour, 2012: p.324).

It also addresses a gap of knowledge in the literature as well. The importance of testing and the universal utilization of testing have been established in the literature as an important tool.

But the focus on testing has not however, produced quantitative data on testing. Jones and Bonsignour note that “the lack of quantitative data does not speak well for the professionalism of the software industry. For more than 50 years finding and fixing bugs, have been the most expensive identifiable software cost driver. High defect levels are the primary reason for software schedule and cost overruns. Knowing the impact of defects on software projects and the impact of test cases and test effort on project performance is critical information.” They argue that the lack of such data goes a far way of explaining the endemic situation with cancellations and schedule delays (Jones & Bonsignour, 2012).

The second question looks at the overall model behaviour and how my enhancements can provide additional improvements to its behaviour. The second question is:

Q2: In terms of policy conclusion (for example: distribution used to resources), are there additional policies for instance, supplementary allocation of resources to quality assurance, rework and testing efforts that would improve the model behaviour?

Regarding the question of policy inclusions, my enhancements will provide a basis for applying policy in the thesis. The first enhancement provides an expanded testing regime where software tests will be conducted during production. In the original model testing is only carried out as a final systems test. The literature on testing indicates that modern software projects carry out wide variety of technical tests during production in order to ensure product quality. Tests are conducted at certain milestones, and provide error-detection (Jones &

Bonsignour, 2012). With an enhancement to the testing-effort, I will be able to calculate and provide additional policies regarding allocation of resources to the quality assurance, rework and testing effort. These policies should enable better software quality and still be cost-efficient methods. It is important that we achieve better software quality without creating severe additional costs for the project and the client.

The second enhancement to the model is a client-review system. In modern software projects the client is an important actor. With the increased use of customer acceptance testing, I provide a testing-regime that includes the client. The client-review will be split between a team allocated by the testing staff and personnel allocated by the client. The testing staff will present a piece of software or application to the client staff. The client’s staff will carry out the review of the applications and provide their experiences with the software. These reviews are valuable because they provide an additional instance for error detection.

The empirical data on customer acceptance testing reveal an average defect removal efficiency of 30% (Jones & Bonsignour, 2012: p.320). It is important to note that the inclusion of the client in this regime is in accordance with both sides of the argument regarding the client. The client is allowed to participate in end-user testing, but will not provide technical fixes or solutions. The overall technical aspect of the software is kept exclusively in the realm of software development. The new client-review and the enhanced test regime will change the allocation of manpower for testing.

In the base-model, all members of the production staff are allocated to testing near to the end of the development cycle. With these new structures, the allocation for testing process will be allocated during the development phase and will be separated into different stages of testing, and between systems testing and client-review.

So far, the enhancements I have suggested have been linked to the testing effort. Testing is regarded as the most important tool for defect removal. For some projects, the testing effort is the only measure for defect removal. However, testing alone is an expensive and limited tool.

Therefore, my third enhancement is linked to the incorporation of the quality assurance effort into the overall defect removal effort. Quality Assurance and Testing will now be linked with each other as tandem defect removal-tools. It is equally effective for defect removal to have pre-test efforts that identify errors and prevent further occurrences. There are several different techniques available. I have chosen a relative new approach called the capture-recapture method. The general idea stems from biology (Jones & Bonsignour, 2012). When errors are found in the quality assurance effort, they are first reported and sent to rework. Thereafter, the fixed pieces of code previously generating the reworked errors are tagged. After tagging, they are released back into the system and sent to testing. During systems testing after the classification stage, errors are found and identified by the testing effort. Deviating tasks that are found to contain tagged errors will be send back to rework, as they are a result of bad fixes. Deviating tasks that holds no tagged errors are sent back to the quality assurance effort for classification. Tasks that contain untagged errors are a result of escaped errors from the previous detection process.

During system testing after classification phase and during identification phase deviated tasks with tagged errors in, will be send back to rework as they contain the bad fixes errors but deviated tasks with no tagged errors in, will be send back to quality assurance process to get the error detection there first as they contain the escaped errors from previous detection process.