Software Quality Plan
Upcoming SlideShare
Loading in...5
×
 

Software Quality Plan

on

  • 11,640 views

Sample plan from a fictional company for class taught by Pete McBreen during my MSc in Software Engineering program (2002)

Sample plan from a fictional company for class taught by Pete McBreen during my MSc in Software Engineering program (2002)

Statistics

Views

Total Views
11,640
Views on SlideShare
11,599
Embed Views
41

Actions

Likes
2
Downloads
301
Comments
1

3 Embeds 41

http://www.slideshare.net 38
http://www.linkedin.com 2
http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • how to get the ppt
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Simple Design: <br /> Passes all tests <br /> Contains no duplication <br /> Communicates all intentions necessary <br /> Contains the fewest possible methods and classes <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • An acceptance test is a test that the user defines, to tell whether the system as a whole works the way the user expects. Ideally, the acceptance tests are defined before the code that implements the feature. The acceptance test will be an iterative process where user will need to test each of subsystem during the software development process as soon as the components are being completed or when ever the new version is finished at the end of each iteration. These tests give a big picture of how much of the desired functionality will work and because the tests are run so often, there is a payoff to have the tests automated. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />

Software Quality Plan Software Quality Plan Presentation Transcript

  • GSES Good Software Engineering System Technologies Airline Reservation System (ARS) Project Software Quality Plan Guy Davis Samuel Lee Eileen (Xiaozheng) Wang Simon (Ming) Zhou
  • Quality Plan Overview
  • Quality Plan Overview dX approach 
  • Quality Plan Overview dX approach   Mission critical System
  • Quality Plan Overview dX approach   Mission critical System  Web security
  • Three roles in QA Developer  – Unit test is written before the code – Ensure the code quality Customer  – On site customer – Acceptance tests – Rapid feedback – Ensure that the system meet requirements QA  – Work with developer and customer to ensure the the quality of functionality delivered
  • Communication Frequent, short  meeting  Frequent feedback by short term iteration.  An open workspace
  • Risk Management Anticipate changes and ensure that the  associated risks are controlled. According to dX, should prioritize each use case card. High risk use cases are given higher priority.  “Agile methods emphasis on tests, integration, and flexibility are benefits for these types of critical, reliable, and safe systems.” http://fc-md.umd.edu/projects/Agile/statement_3.htm
  • Programmer
  • Test-First Design Pair Refactoring Programming Simple Design Programmer
  • Team
  • Open Workspace Collective Coding Ownership Standard Continuous Sustainable Integration Pace Metaphor Team
  • Customer
  • On-Site Customer Acceptance User Stories Tests Release Iterations Plan Small Customer Releases
  • On-Site Customer Acceptance User Stories Open Workspace Tests Collective Coding Ownership Test-First Standard Design Pair Refactoring Programming Simple Continuous Sustainable Design Integration Pace Metaphor Release Iterations Plan Small Releases
  • Infrastructure Quality Determine quality goals and targets  – Application server – Database – Operating system – Hardware (servers, interfaces, networking) Application of testing and evaluation  standards  Audit and review of testing processes
  • Application Server Quality Performance  – Load testing to meet worst-case scenario Fault-tolerance and redundancy   Availability  Compatibility – With database, OS, utilities, network interfaces, etc... Security 
  • Database Quality Availability   Reliability (data integrity) – Off-site transaction replication Security   Performance – Clustering of servers – Load testing at end of each iteration
  • Operating System Quality Compatibility Security    Performance  Stability/Reliability
  • Hardware Quality Fault-tolerance/redundancy  – Secondary data-centre, hot-standby Vendor support   Physical security – Is data-centre secure? Networking component quality  – Covers all interfaces to reservation system
  • Deployment Running the new system with the old  system in parallel for couple weeks  Before the deployment, the user training will be done  The IT support will be helping with the deployment – training  Help Desk should also be setup to handle calls after the deployment
  • User Acceptance Test Approach  – Tests are created from user stories. – Customer specifies scenarios to test. – User story is not completed until they passed the user acceptance tests Responsible Party  – Customers – Developers – Network Specialists – QA
  • User Acceptance Test (Cont.) Tools  – GUI » Commercial Tool » Run once to establish a “golden” copy » E.g. TestWeb – Code » Programmer write the code » E.g. JUnit – Spreadsheet » Represent tests in a spread sheet for repeated tests – Manual » Write down the procedures and plan on paper and then follow the steps manually
  • Training Targeted at different audiences  – General User – Technical Support Staff – Managers – Advance Users
  • Disaster Recovery Hardware Redundancy   Duplicate copy of software or applications  Backup of data  A backup site  Assign teams to different roles and responsibilities
  • Questions