QUALITY ASSURANCE “Go High or Go Home!”

Developed Team Motto of “Go High or Go Home!” Our approach to project quality management involves the identification of specifications for our project deliverables that were identified in the scope statement. Creation of work breakdown structure and an assignment matrix to assign roles and responsibilities

“Ishikawa” Fishbone Diagram This quality control tool was utilized to improve group effort and tackle problems with quality control. The project manager presented the problem and asked for assistance from the group to determine the main causes of the problem

Group suggestions were subsequently drawn on the board as the main bones of the diagram This eventually led to the cause and effect diagram being filled out 1st Problem: Difficulty that we had with gathering all the members for meetings.

Ishikawa Diagram on Difficulty with Gathering Team

Solution to 1st Problem The group identified that the root cause of the problem was inadequate information dissemination. The team divided the activities according to the components of the WBS and used email as the primary medium for updating fellow team members on work assignments. Email communication also allowed us to preview meeting agenda as well as set up date and times for group meetings. 2nd Problem: Finding the best approach or method of collecting user input.

Ishikawa Diagram on Collection of User Requirements

Solution to 2nd Problem The team identified that the most productive method for data gathering was using the interview process. Two members had direct interviews with past and current employers. First hand experiences of group members with motel management systems and were also a primary source of user input.

Pareto Diagram During the initial testing phase we noted some recurring bugs. Pareto diagram was used to create a frequency histogram, helping us sort out the problems according to levels of priority. This analysis allowed us to efficiently identify the most vital problem that needed to be fixed. Consequently, the other two bugs were resolved after the most important one was debugged.

Pareto Diagram for System Bugs

Capability Maturity Model …The Initial Level ? Overall the team’s software process maturity can probably be best described to be at the initial level of the CMM. This team had such a limited lifespan and members worked on the project on a temporary basis. Thus creating more of an ad hoc approach, that is characteristic of the first stage of the CMM. Talents and contributions of individual team members were instrumental in developing the project deliverables.

…or maybe The Repeatable Level ? However, the project was undertaken using processes and concepts in information technology project management. Documentation and tracking were done using Microsoft Projects as the tool for following goals that were realistic, relevant to the size and scope of our software development process. All these focus on key processes that would be most typical of the second level of the CMM.