Deliverable #3 Resubmission
Quality Assurance Process Development for GDHM
University of Maryland, Baltimore County
IFSM 636
Jason Gregory, Keith Drexel, Weimin Hou, and CD Martin
Deliverable #3
Section I: Introduction
· Project Overview
· Organizational Environment:
GDHM is a new corporation, which previously existed as a subsidiary of Parent, Inc., a service company. They have extensive experience with design and documentation tools, workflow management solutions, training management software and various image utilities. Notated for their field client/server specialists, GDHM specializes in such training methods as instructor-led training, multimedia and CBT, interactive distance learning and self-study training. Due to recent growth, the current system for Analysis Design Development, Delivery and Documentation of software products has become obsolete. With the development of a Quality Assurance department, fresh attempts have been made to bring the company process into line.
· Problem Statement:
Currently, the system for Analysis Design Development, Delivery and Documentation is inadequate. Due to the expansion of the product line, the process for the development of software products has been outgrown. New issues (bugs/enhancements) are continually sent to the Quality Assurance (QA) department to test before their implementation or new release. Unfortunately, due to different dilemmas, the QA testing process is not handled efficiently and promptly. As a result, the company is losing money due to wasted man-hours through the redundancy and competency of the current system in place. The process, therefore, needs to be redefined in order to meet the organization’s growing needs.
This project proposes to make the maintenance effort of GDHM’s learning management system more efficient and less costly in terms of man-hours. The Call Support and Engineering Departments are currently performing the GDHM maintenance effort. The project hopes to affect both departments directly, though its effects should reach throughout most of the organization. The problems with the effort that were discovered deal mostly with a lack of strong procedures for the QA process and are detailed below:
Identified Problem List:
1) Call support work-time being wasted by QA / Development staff asking for more detailed customer problem issue information from the Support Log.
2) Call support work time being wasted by logging in issues that have already been logged.
3) Engineering work-time being wasted by resolving issues and testing fixes that have already been resolved.
4) Engineering work time being wasted by arguments between QA and Development over whether a reported problem should be fixed.
5) QA work time being wasted in creating Test Cases that had previously been created for other similar problems.
6) Issue resolution being slowed by QA not creating Test Cases until Fix needs to be tested.
7) High-cost Engineering work time being used on Log input issues when other departments bring issues to them.
8) Issues are being “dropped” (not addressed) due to not being logged or log entry ignored due to log non-use.
· Scope Statement: The areas that will be affected directly by the new system will be Quality Assurance, Development, and Call Support (support). Each of these entities will be more focused on the task as it relates to the entire company and less on how it impacts just their specific area. Some previous Call Support policies and systems will have to be overhauled or dropped altogether. Development will need to be able to consider each bug or enhancement from the point of view of the user as stated by Call Support and respect Quality Assurance’s input as constructive, rather than destructive. Indirectly, the new system will encompass the entire company and greatly influence the processes and policies of Documentation, Business Requirements Analysis, Sales and Implementation. As a result of the new system, the documentation being produced will better reflect the actual functionality of the software versus the predicted functionality. Business Function Analysts will be able to readily track enhancement requests toward their completion and if necessary, provide feedback from customers concerning unclear requirements.
Policy changes will strongly intertwine the workings of QA, Development and Call Support where, as previously, each area has maintained their own separate methods for delivery interdepartmentally. A shift of mentality will have to replace the “it’s out of my hair” approach that comes with passing off a bug or enhancement to the next department. A universal tracking system will have to be implemented for use by all departments. A Test Case template will have to be implemented to encourage the recording of all specifics needed to complete the task. A Test Case repository will need to be created for reuse of test materials versus the rebuilding the wheel again as has been the case.
· Recommendation
It is recommended that GDHM exercise Alternative 3 of this document, that of implementing a Policy Change along with Software and Database Modifications to the QA workflow. This proposed system falls within the desired budget and would recover much employee time that was previously being wasted due to the aforementioned listed problems. Alternative 1, the Outsourcing Maintenance effort, is shown to be cost-prohibitive; and Alternative 2, Policy Change Only, is inadequate to the total task, as it does not address Test Case re-use and Engineering access to Support Log information.
Section II: System Description
· Requirements and constraints
o Requirements:
1) The new/modified system must reduce the man-hours that are lost to duplication of effort due to duplicated logging of bugs in the Bug Log by enforcing “One Issue, One Entry.”
2) The new/modified system must reduce the man-hours that are lost to re-creating a Test Case that had been previously created and not stored for re-use.
3) The new/modified system must allow Engineering personnel direct access to the Issue Data currently in the Support Log that they require.
4) The new/modified system must reduce calendar time between receipt of an issue and its resolution.
5) The new/modified system must not expend more than 16 hours of “down-time” for any Call Support staff member’s training.
o Constraints:
1) The new/modified system cannot exceed $150,000 in one-time costs and must break-even within 4 years.
2) The new/modified system must be fully implemented by 12-31-2001.
· Text Description of Alternatives
o Alternative One – Outsource Maintenance
Outsource the call support process that deals with reporting issues/bugs (the call support staff will forward the relevant calls to the Contractor’s phone line, alternatively, a specific phone number for reporting issues can be distributed with the next release). Outsource QA process. Outsource development for program maintenance.
o Alternative Two - Policy Change
The second alternative would consist of developing a set of Standard Operating Procedures for the QA process. This would consist of such items as a common framework for what verbiage actually goes into the bug log, a common library for where all Test Cases are saved, establishment of authority over what constitutes an issue which needs resolution, and a more hardened process for the bug life cycle.
o Alternative Three - Policy Change, Modified Database, Additional Software
The third alternative is the combination of the SOP development with software and database development. In this alternative, testing software would be purchased that would automate some of the QA testing and automatically apply the already generated Test Cases against the fixed code. The functions of the Support Log would also be integrated into the Bug Log to form a consolidated database. This would take those functions out of the COTS Call Center package that is currently being used.
· Graphical Description of the Alternatives:
Original TrainingServer QA System Context Level, Level 0, Child 3.0 and Child 4.0 DFDs are included here, as the resolutions affect all these diagrams.
Original GDHM Quality Assurance System Context Level DFD
Original GDHM Quality Assurance System Level 0 DFD
Original GDHM Quality Assurance System Child Diagram 3.0
Original GDHM Quality Assurance System Child Diagram 4.0
o Alternative One - Outsource Maintenance
Alternative One – Outsource Maintenance
GDHM Quality Assurance System Context Level DFD
By outsourcing the whole QA System (including the Call Support process, the QA process, as well as the system maintenance), the whole GDHM organization will be able to use all their time and efforts to the development of the new products. Customers will contact the outsourced company about the bug/issue regarding the products, and it will be fixed and QA’ed by the same outsourced company. They keep all the related information and give the report to GDHM’s Engineering Department on an agreed time basis.
o Alternative Two – Policy Change
One of the changes of this alternative to the QA Process is that the SOP will be enhanced. The unlogged bug/issue will not pass on to the QA process, so the original data flow from 1.0 to 3.0 is eliminated. Another change is that Process 3.0 will be changed into “Address the Bug/Issue” instead of “Fix the Bug/Issue”. The reason of this change is that there will be one more sub process for Process 3.0 – Receive Bug/Issue, and one more data flow – Received Bug/Issue - passing from this process to Process 4.0. From the 2 child diagrams affected by this change - Child 3.0 and 4.0, we can see that as soon as Process 3.0 receives the logged bug/issue information, it passes on to the next process, so that Process 4.0 can start checking whether there is an appropriate Test Case against it, and if not, start developing one. A new data store D4 is developed for the convenience of checking the TC information available. Informing Process 4.0 earlier than before will change the situation that Process 4.0 can only start after receiving the “Product with Fixed Bug/Issue”, and after a Test Case is checked/developed then, thus reduce the entire time needed for the whole QA Process.
Alternative Two – Policy Change
GDHM Quality Assurance System Level 0 DFD
Alternative Two – Policy Change
GDHM Quality Assurance System Child 3.0 DFD
Alternative Two – Policy Change
GDHM Quality Assurance System Child Diagram 4.0
o Alternative Three – Policy Change, Modified Database & Additional Software
As mentioned at the beginning, this alternative is the combination of the SOP development with software and database development. Testing software would be purchased that would automate some of the QA testing and automatically apply the already generated Test Cases against the fixed code, which is indicated in Process 4.2. The functions of the Support Log would also be integrated into the Bug Log to form a consolidated database D1, which would be named as Issue Log. This would take those functions out of the COTS Call Center package that is currently being used.
Alternative Three – Policy Change, Modified Database & Additional Software
GDHM Quality Assurance System Level 0 DFD
Alternative Three – Policy Change, Modified Database & Additional Software
GDHM Quality Assurance System Child 3.0 DFD
Alternative Three – Policy Change, Modified Database & Additional Software
GDHM Quality Assurance System Child Diagram 4.0
Alternative Three – Policy Change, Modified Database & Additional Software
GDHM Quality Assurance System Child Diagram 4.2
31
· Comparison of Alternatives
REQUIREMENT / OUTSOURCE MAINTENANCE / POLICY CHANGE / POLICY CHANGE and SOFTWARE / DATABASE MODIFICATIONSystem must reduce the man-hours that are lost to duplication of effort due to duplicated logging / All GDHM Maintenance Hours reduced to zero / Duplication hours reduced to zero, +/- 5% for human error / Duplication hours reduced to zero, +/- 5% for human error
System must reduce the man-hours that are lost to duplication of effort due to Test Case re-creation. / All GDHM Maintenance Hours reduced to zero / Test cases will still be created on an ad-hoc basis
REQUIREMENT NOT MET / Duplication hours reduced to zero, +/- 5% for human error
System must allow Engineering personnel direct access to the Issue Data currently in the Support Log that they require / N/A / Engineering Personnel will still require going through Call Support staff
REQUIREMENT NOT MET / MEETS REQUIREMENT
System must reduce calendar time between receipt of an issue and its resolution / Speed increase probable, decrease possible / Issues may resolve faster due to Test cases being created when issue received and overall Engineering time savings / Speed increase will result from automated testing and from expedited Test Case application
System must not expend more than 2 day of “down-time” for any Call Support staff member’s training. / Per person Call Support training down-time is: ½ hr / Per person Call Support training down-time is: 7 hrs / Per person Call Support training down-time is: 12 hrs
CONSTRAINT /
OUTSOURCE
/ POLICY CHANGE / POLICY CHANGE and SOFTWARE / DATABASE MODIFICATIONSystem must cost less than $250,000 one-time and break-even within 2 years / Annual Cost is: $1,008,038;
Does NOT Break-Even. / One-Time cost is: $15,113;
Break-Even in 0.10 years. / One- Time cost is: $166,354;
Break-Even in 0.78Y years.
System must be fully implemented by 12-31-01 / Final date:05-08-01 / Final date: 07-13-01 / Final date: 09-06-01
Requirements & Constraints By Alternative
31
Section III: Feasibility Assessment
All of the three alternatives would bring benefits to GDHM. Overall benefits that would be gained are as follows:
Tangible gains:
o Time Saved by staff for issue entry.
o Time saved by staff researching issues.
o Time saved by staff testing issues.
o Reduction of staff needed for maintenance and regression testing.
o Decreased risk of issues going unaddressed do to user error
Intangible gains:
o Better retrieval of issue records
o Less redundancy on issue entry
o Less redundancy on issue testing
o Faster turnaround of software version enhancements
Below is the detailed feasibility analysis of the three alternatives:
o Alternative One: Outsource Maintenance
Economic Analysis:
The annual cost of outsourcing the maintenance effort is estimated at $2,165,089. The annual benefit (cost decrease due to reducing GDHM man-hours) of Outsourcing the maintenance effort is $1,157,051. Thus there is an annual cost INCREASE of $1,008,038. This Alternative does not reach a break-even point. Supporting detail is broken out in Appendix 2: Economic Feasibility Backup.xls.