Deliverable #1

Quality Assurance Process Development for GDHM, Inc.

University of Maryland, Baltimore County

IFSM 636

Jason Gregory, Keith Drexel, Weimin Hou, and CD Martin

Deliverable #1

·  Title: Quality Assurance Process Development for GDHM, Inc.

·  Organizational Contact:

(deleted for confidentiality)

·  Organizational Environment:

GDHM, Inc. 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, Inc. 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.

Company Specifications:

Approximate size: 100-120 employees

Business activity: Training Management

Target: Corporate, Government, and University Level

Baseline Project Plan

·  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. The process, therefore, needs to be redefined in order to meet the organization’s growing needs.

The process is described as follows:

When a bug/enhancement is delivered, the most common source is through direct customer contact (i.e. e-mail or telephone) to the support (Call Support) center. Bugs and enhancements may also originate in-house. Upon receipt of the “Issue”, Call Support starts or appends an entry in the ‘Support Log’, which contains customer information, and also enters a similar entry into the ‘Bug Log’, where detailed bug information is recorded. Call Support uses the Bug Log to determine if the bug has been addressed before. If the bug has a solution, a “Call Back” is performed and the customer is presented the solution. If the error is new, Call Support will present the problem to the development lead. Some problems are delivered directly to the Quality Assurance department from support or development prior to a development review by the development lead who determines whether the problem is classified as a bug or an enhancement [Enhancements are deferred in the Bug Log and delivered to the Business Analysts.] Bugs are subdivided into specific groups, depending on version, and delivered to their appropriate subgroups within development. Development addresses the bug and sends it to back to the development lead who marks it as fixed. The development lead then delivers the fixes to QA. If QA cannot recreate the bug, it is updated in the Bug Log as “QA Checked”. These bugs are then released back to Call Support. If the error reoccurs, the Bug Log is then updated and marked as “Not” fixed. QA then returns the bug back to development and the process begins again.

Enhancements are returned back to the process when Business Analysts have finished their evaluation. Enhancements are then delivered to the development team lead and subdivided into specific groups depending on the version and delivered to appropriate subgroups within development. Development addresses the enhancements and sends it to back to the development lead. The development lead marks the deferred entry as fixed in the Bug Log. The item is then sent to the “Queue” (a staging area) to wait for the next release date. Prior to its release, QA reviews all the prior bugs and enhancement requests. When all items pass the review, the release is turned over to Call Support for delivery. But this procedure is not carved in stone and releases might have been issued by development to Call Support before QA has finished their review. It is also not uncommon for multiple parties, including QA, to approach other departments in shortcuts to get needed information or help.

Process Illustration

Identified Problem List:

  1. No Standard Operating Procedure (SOP) for bug/enhancement handling and tracking
  2. Two separate ‘Bug Logs’ being used by Call Support. One log is for storing customer information and the other for the QA department, which causes confusion

3.  Duplication of effort/wasted time through issues (bugs/enhancements) being logged in more than once

  1. Enhancements, which constitutes a big part in new releases, are not entered into the ‘Bug Log’

5.  Discrepancies about what are considered ‘fixed’ between QA and Development

  1. Enhancements are often processed and tested without a real understanding of the issues they are trying to address
  2. Little in the way of Test Case (TC) standards and those that are currently in place are not strictly enforced

8.  Redundancy in bug/enhancement testing

9.  TC’s are always created on an “as needed” basis (duplication of effort)

  1. Quality Assurance (QA) is not always notified when Call Support issues a notice to the Development department concerning issues that need addressing which may delay TC development for the issue
  2. In-house customers may go directly to QA instead of passing the issues through Call Support first (in essence, leaving Call Support and Development uninformed)

As a result, our goal as a group is to develop a more efficient system to solve these problems and manage the bug and enhancement tracking of the Quality Assurance (QA) department.

·  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: At this early stage of development in our systems project, our team feels confident in proceeding with our planned interventions. With the current support received from our chosen organization, GDHM, Inc., through institutional contacts, employees, and management, we feel secure that once implemented, our system will prove successful. As shown in our feasibility analysis, there are many attributes that will help enable this decision.

·  System Description

o  “Obvious Solution”:

  1. Develop SOP’s for QA, Call Support and Development
  2. Implement software to track the issues (bugs/enhancements)
  3. Have all issues go through Call Support (in-house and outside customers)
  4. Have all issues go to QA and Development at the same time.
  5. Change ‘Bug Log’ to ‘Issue Log’, which contains both bug and enhancements
  6. Generate new Test Case (TC) standards
  7. Apply the TC’s against the issues

o  Alternative Solutions:

  1. Change SOP’s only. Make Call Support and Development use the existing resources that are already in place so as not to duplicate issues. Call Support would also have to notify QA the same time they notified Development through a linked e-mail system.
  2. Outsource (contract) new QA for service.

·  Feasibility Analysis

o  Economic:

The economic feasibility can be evaluated through cost-benefit analysis, i.e., evaluating IT systems for development by comparing systems costs with systems benefits.

For this project, systems costs have been identified, such as software, time, education and training costs. Setup of any of the identified tools would be easy to accomplish. Configuration of special details, however, may take a little longer. GDHM, Inc. has specialists in training and has been known to take in-house training topics and offer them to the public, so training would be straightforward and relatively effortless. Training for most of the packages will take approximately 5 business days. Hiring outside training is not feasible for this organization.

The actual cash resources available exceed $100,000 and have the full backing of the GDHM, Inc. upper management team. Testing tools that would be considered are from such manufactures as Rational Performance Studio ($100,000) and Mercury Winrunner ($150,000), RSW E-test Suite ($100,000) and policy writing tools such as Policy Maker ($30,000).

Systems benefits fall into two categories – tangible and intangible. Tangible benefits are systems benefits that can be monetarily quantified, such as increased profits, increased market share, reduced product/service costs and lower supply costs. Intangible benefits are systems benefits that cannot be monetarily quantified, such as improved customer satisfaction, enhanced employee morale, higher-quality corporate image, regulatory requirements satisfied and better decisions. The successful implementation of the project will satisfy both tangible benefits and the intangible benefits.

o  Technical: GDHM, Inc. currently has the ability in-house to build all the recommendations we have in mind. The problem would be in the issue that is causing them to require this implementation in the first place. Too many teams will be trying to give their input as to what is needed in such an issue management system. In order to be constructive, one would have to give the Quality Assurance department total control of one or more software engineers to control the eventual outcome. Also, automated testing software would be best left to an outside vendor. There are many products that have years of experience and would far exceed the expectations from the company’s own development staff. Policy software could go either way depending on the ability of staff to enforce Standing Operating Procedures (SOP’s) versus allowing software to do it for you.

o  Operational: Changing the SOP’s for the organization does introduce some possible risks. However, the company is currently in a state of flux due to being recently spun-off from its parent company, Parent, Inc., so another set of changes may be more favorable implemented now then when other polices are firmly established. There are minor compatibility issues when considering the two different log systems that are currently in place. They are not, at the present time, able to support each other in the organization. It is anticipated that implementation of the project will address all workflow and communication issues.

o  Legal and Contractual: There are no legal or contractual issues evident that would have a direct affect on the completion of the system. Any issues of concern may cover licensing agreements, but nothing else.

o  Political: Previously stated, the organization gives full backing of the project through the use of available monies and management support. But this may be a difficult issue with Call Support. Software Development will be more prone to fall into sway as QA and Development share a common supervisor. Call Support may be a little harder to bring on board, as the head of support already perceives a loss of power due to a division of his team. This may be viewed as a further loss of control in the eyes of Call Support supervision. The desired result is that new issues pass through QA, Development and Call Support in the proposed workflow.

o  Schedule: Depending on the availability of appropriate monies, employee introduction and overall organizational conformity, the effects of this new system could be observed as early as May/June of 2001. This estimate was determined by looking at such factors as software implementation, employee training hours and protocol/policy development. Other factors may also play a roll in the acceleration or delay of the system completion.

·  Management Issues

o  Team Members:

Jason Gregory (Project Director): Mr. Gregory is a first year candidate for the M.S. degree in IFSM. He currently holds a B.A. in History and is MCSE certified. He brings to the group 4 years of experience working with information systems processes and 2 years of experience with budgeting, procurement, and contracting processes with a government contractor in the state of Virginia. Mr. Gregory also spent time as a military Weather Forecaster/Observer.

Keith Drexel (Organizational Contact): Mr. Drexel is a first year candidate for the M.S. degree in IFSM. He currently holds a B.S. in IFSM and is knowledgeable programming languages such as C and COBOL. He brings to the group a plethora of experience from such organizations as the Health Care and Finance Administration, NASA’s Earth Observation Data and Information System, the Census Bureau, and Intermetrics (specialized in independent verification and validation).

Weimin Hou (Librarian): Ms. Hou is a first year candidate for the M.S. degree in IFSM. She currently holds a B.A. in English Education, as well as, a M.A. in Intercultural Communication. She has 3 years experience teaching English in Beijing and has worked as an Executive Assistant for a Croatian pharmaceutical company for approximately 2 years. Ms. Hou brings to the group exceptional organizational skills, as well as, the ability to stay focused and driven on the current project at hand. She also has experience in the field of qualitative research methodology.

CD Martin (Information Liaison/Marketer): Mr. Martin is a first year candidate for the M.S. degree in Informatics at UMAB. He currently holds a B.S. in Nursing, as well as, a license to practice nursing (RN) in the state of Maryland. He has 4 years experience as a Propulsion Technician in the U.S. Air Force that entailed areas in management, supply/distribution, and computer engine tracking. He currently is working as a Clinical Research Assistant at the University of Maryland, School of Nursing and brings to the group a general knowledge of computer applications and data collection techniques.