Quality Management Team

1
Quality Management Team

• Lei Lei, Sun Liang Fadi
• 10/18/2007

2
Agenda

• Overview - Quality Management Planning
• Assumptions Constraints
• Requirements - Functional Non-Functional
• Quality Plan

3
Quality Planning Management

• What does Quality Management Entail?
• Quality Plan
• Quality Assurance
• Quality Control
• Quality Planning
• Quality planning is the process of identifying
  relevant quality standards and developing a plan
  to ensure the project meets those standards.
• Note
• An important input is the Project Management
  Plan(pg. 293)

4
Assumptions, Constraints Dependencies

• Assumptions e.g., the Seattle Seahawks is
  planning a 15 annual user growth on their Web
  site.
• Constraints e.g., the Web system cannot be taken
  down at any time during the baseball Season due
  to heavy traffic load.
• Dependencies e.g., does the Web site rely on
  another application or system? This could happen
  if the Seattle Seahawks has a separate
  enterprise-wise authentication system for a
  member to login.

5
Quality Standards/Requirements

• CUSTOMER SATISFACTION
• User-friendly graphical interface and a good
  transparency    
• Safe and secure Internet access
• Reliable and secure online transaction protection
  mechanism
• Well-designed and easy-to-maintained database    
  
• An online discussion forum    
• Accurate and appropriate contents    
• Well-documented Web site Help     
• Attractive multi-media presentation
• Access based on user roles  
• ADA Compliant (Consider the needs of people with
  disabilities)
• Good performance level (consideration of peak
  time users, multiple user hits, etc)
• Project-related documentation files
• Training procedures and documentation

6
Non-Functional Requirements

• Data Requirements
• Information of tickets, seats, baseball play
  schedules, teams, players, online sporting
  products, will be utilized, stored, or generated
  by the SS Web site.
• The typo rate of the Web site text will be less
  than 1.
• Any malicious or territory text that threats or
  insults other country, organization or people
  should not be displayed on the Web site.
• Any user who posts this kind of contents will be
  banned by the system administrator from the
  online forum.
• Database Requirements
• Reduce the loop and iterative connections in the
  database between tables to minimize maintenance
  efforts
• The size of the database will need to be less
  than 10G and records of registered users will
  need to be less than 10,0000.

7
Non-Functional Requirements (Cont.)

• Development Environment Requirements Specifying
  what tools, programming languages, and
  development platforms will be used for the
  development of the SS Web site (on both Server
  side and client side).
• Browser Requirements The Web site should
  function well on various Internet Browser
  including IE, FireFox, Safari, and Netscape.
• Interface Requirements Specifying how an
  application/system interacts with others, what
  systems provide input, which ones require output,
  what medium is used (multi-media tools such as
  flash, video, and images will be presented on the
  Web site). The Web site should be ADA compliant
  (e.g., consider an appropriate color theme choice
  to help color-blind people).
• Operational Requirements The Web site will need
  to be available to all levels of users on a
  7day-24hour base. The down rate for the server
  should be less 1. (Specifying any qualitative
  and/or quantitative parameters, which may be used
  as the basis for determining the operational
  effectiveness and suitability of a system prior
  to deployment).

8
Non-Functional Requirements (Cont.)

• Security Requirements
• An unregistered user will be able to browse the
  Web site and check the ticket, seat, game, and
  general information about the SS.
• A user will have to register and log on in order
  to access the player information, participate the
  online discussion in the forum, and make
  purchases online.
• The log on will be associated with an
  authentication process.
• The online purchase will have certain credit
  card/payment protection mechanism.
• Maintenance and System Administration
  Requirements
• The maintenance of the system will base on a
  monthly update and also adjust more frequently
  during the season time.
• Technical support people will be available to the
  client (the SS) within the next business day (M-F
  9-5).

9
Non-Functional Requirements (Cont.)

• Performance Requirements
• The normal response time of the Web site for a
  regular registered user will be less than 5
  seconds.
• The Web site should have the capability to deal
  with 10,000 peak time user and 5000 hits per page
  per second.
• Documentation Requirements
• Online Help should be available to any user.
• Web site related documentations including the
  project proposal, project management plan,
  project quality plan, project requirements doc,
  project design doc, Web site user manual, and
  project final report, will need to be submitted
  at the end of the project.
• All documents are required to be in Microsoft
  Word .doc format and include time, author, copy
  right, and details.

10
Quality Plan

• A quality management plan is a plan specifying
  how quality measures will be implemented during a
  project.
• Key Stakeholders Involved
• The Sedona project team
• The SS Steering Committee
• Key End Users
• Independent Peers Reviews

11
Quality Plan (Cont.)

• Pre-Requisites
• Budget Calculation based on Cost Benefit Analysis
• Best Practices and benchmarks will be used
• Thorough review of SSs guidelines for their ISO
  certification
• 30 of the overall project time-frame dedicated
  to Quality Management

12
Quality Plan (Cont.)

• Some Key Components of the process include
• Continuous communication with all concerned
  stakeholders in a timely and effective manner,
  keeping them up-to-date on all quality concerns
• Continuous Testing and Debugging

13
Quality Plan (Cont.)

• Quality Measures / Performance Metrics
• These will be extracted and based on the
  requirements discussed previously.
• Each item will be given a weight
• Ultimate goal is CUSTOMER SATISFACTION!

14
Quality Plan (Cont.)

• Change Control Management
• All changes will go through a formal change
  management request system. This will be in line
  with the flow chart mechanism highlighted in
  figure 8.21 on page 302. All requests will be
  logged onto the system electronically.
• If the change requested has already past the
  testing period of the given phase, it will be
  implemented after the GO LIVE in order to stick
  to the set Project Timeframes. With the exception
  of Senior Management requests, which MUST be
  entertained.

15
Quality Plan (Cont.)

• Assurance of Requirements Being Achieved
• Each of the requirements is applicable to a
  specific project phase.
• A checklist will be developed for each project
  phase in accordance with overall project
  requirements and scope. This will be handled by
  the Sedona Project Team, along with the
  respective KEY end-users assigned by SS.
• A complete quality performance metric / checklist
  will be developed to be used during the final
  testing phase of the project. This will be handed
  over to the Quality Assurance Team to handle.

16
Quality Plan (Cont.)

• Testing Execution
• As mentioned previously, each phase will be
  tested in accordance to the metrics defined.
• Once all design phases have been completed, the
  MAIN testing phase will include a simulation to
  test the traffic and performance of the website,
  in addition to the various functionality the
  website will have.

17
Quality Plan (Cont.)

• Tracking Problem Resolution
• Any item not adhering to the set standards will
  be rated High, Medium, or Low.
• All High items must be corrected immediately
  prior to the GO LIVE!
• All Medium items will be forwarded to the
  steering committee for their input and approval.
• All Low items will be catered after the GO LIVE
  date, unless time permits.

18

• THANK YOU