Docstoc

Quality Management Plan - PDF

Document Sample
Quality Management Plan - PDF Powered By Docstoc
					 Protein Express Project
Quality Management Plan

                        Version 1.6

                        14 March 2006

             Author       Nitesh Prasad, Greg Lord
            Reviewer      Virtus Software

               Client     ARC Centre of Excellence
             Address      Monash University
                          Clayton Campus




         Team Leader      Greg Lord
     Technical Leader     Matt Partington
    Planning Manager      Sia Panagiotopoulos
Data/Testing Manager      Damon Arezzolo
      Quality Manager     Nitesh Prasad
                                                                                              Quality Management Plan




    Table of Contents

    Content                                                                                                   Page #


     Table of Contents .............................................................................................. 2
     1.0   Introduction ............................................................................................. 4
     2.0   Standards ................................................................................................ 5
       2.1    Design Standards................................................................................... 5
          2.1.1   UML Modelling Standards .................................................................. 5
          2.1.2   Use Case & Use Case Descriptions ...................................................... 5
          2.1.3   Class Diagram................................................................................. 6
          2.1.4   Sequence Diagram........................................................................... 7
          2.1.5   User Interface Design Standards ........................................................ 8
          2.1.6   System Report Standards.................................................................. 9
       2.2    Coding Standards................................................................................... 9
          2.2.1   Java Standards ............................................................................... 9
            2.2.1.1 Filenames ................................................................................... 9
            2.2.1.2 Naming Conventions ..................................................................... 9
            2.2.1.3 Class naming ............................................................................. 10
            2.2.1.4 Interfaces ................................................................................. 10
            2.2.1.5 Methods.................................................................................... 10
            2.2.1.6 Variables................................................................................... 10
            2.2.1.7 Constants ................................................................................. 10
            2.2.1.8 Comments ................................................................................ 10
            2.2.1.9 Indentation ............................................................................... 11
            2.2.1.10 Declarations............................................................................ 11
            2.2.1.11 Class and Interface .................................................................. 11
            2.2.1.12 Statements............................................................................. 11
            2.2.1.13 White Space ........................................................................... 11
            2.2.1.14 If Statements and Loops ........................................................... 11
            2.2.1.15 SQL....................................................................................... 12
       2.3    Technical Documentation Standards ........................................................ 12
          2.3.1   General Layout.............................................................................. 12
          2.3.2   Cover page................................................................................... 13
          2.3.3   Table of Contents page ................................................................... 13
          2.3.4   Introduction.................................................................................. 13
          2.3.5   Tables ......................................................................................... 13
          2.3.6   Documentation.............................................................................. 13
          2.3.7   Graphics ...................................................................................... 13
          2.3.8   Header ........................................................................................ 13
          2.3.9   Footer ......................................................................................... 13
          2.3.10 References ................................................................................... 14
          2.3.11 Appendices................................................................................... 14
       2.4    Security Standards............................................................................... 14
          2.4.1   Login and Passwords ...................................................................... 14
          2.4.2   Database Security.......................................................................... 14
          2.4.3   Internet Security ........................................................................... 14
       2.5    Database Standards ............................................................................. 14
          2.5.1   Tables ......................................................................................... 14
          2.5.2   Database ..................................................................................... 15
          2.5.3   Field Names.................................................................................. 15



Quality_Management_Plan_v_1.6.doc                             14/03/2006                                        Page 2 of 22
                                                                                              Quality Management Plan

         2.5.4    Data Type ....................................................................................      15
     3.0   Configuration Management Plan.................................................................             16
       3.1   Configuration Identification....................................................................         16
       3.2   Reviews Procedure ...............................................................................        16
         3.2.1    Configuration Identification .............................................................          16
         3.2.2    Version Control .............................................................................       16
         3.2.3    Change control..............................................................................        17
         3.2.4    Audit ...........................................................................................   17
         3.2.5    Authority......................................................................................     17
       3.3   Change Control Board...........................................................................          17
       3.4   Change Control Procedures ....................................................................           18
         3.4.1    Summary .....................................................................................       18
         3.4.2    Review Procedures.........................................................................          18
     4.0   Communication Plan ................................................................................        19
     5.0   References.............................................................................................    20
     6.0   Appendices ............................................................................................    21
       6.1   Appendix A .........................................................................................     21
       6.2   Appendix B .........................................................................................     22




Quality_Management_Plan_v_1.6.doc                            14/03/2006                                         Page 3 of 22
                                                                           Quality Management Plan




    1.0 Introduction
    A Quality Management Plan describes the procedures and methods for implementing
    quality assurance and quality control. The purpose of Quality Management is to: prepare
    Software Development Review, implement configuration management and to apply skills
    in quality management.

    Quality Management is also about: good software, robust software, satisfying the client,
    and also satisfying the developers. This document is designed to ensure project quality for
    those projects produced. This document describes design, coding, technical, security and
    database standards.




Quality_Management_Plan_v_1.6.doc                14/03/2006                               Page 4 of 22
                                                                         Quality Management Plan




    2.0 Standards
    2.1   Design Standards
          2.1.1 UML Modelling Standards

    The standard used will be the Unified Modelling Language (UML 2.0). The software used
    to create models will be Enterprise Architect (EA Version 3.51). All diagrams will use EA
    Standard font. All diagrams are to be printed on white A4 pages and will display a name
    and page number at the bottom right of the page. Actors, use cases, objects and classes
    will use EA Standard black text colours to distinguish the work.



          2.1.2 Use Case & Use Case Descriptions

    A Use Case simply describes the actions that users take on a system. A Use Case diagram
    includes users, use cases, and the many relationships between the two within a system
    and possibly one or more subsystems. Use Case diagrams should have these necessary
    UML representations:
        · System name
        · Actors
        · Use Cases and Use Case numbering system (eg: UC01 and its description)
        · Relationships (Includes, Extends, Associations, Generalisation)
        · Properties (includes name, author, version #, created and updated)

    Subsystems will be displayed using a rectangle with the subsystem name in the top right
    corner. Association will always be depicted as a straight line.
    See Figure 1.0 for example.

    Use Case Descriptions should always contain:
       · Use Case number
       · Use Case name
       · Actor list
       · Purpose statement
       · Overview
       · Actor action & system response
       · UC prefixes for Use Case name
       · UC-G prefixes for GEL image manipulation




Quality_Management_Plan_v_1.6.doc               14/03/2006                             Page 5 of 22
                                                                                                                           Quality Management Plan


                                                           Name:      Protein Express
                                                           Author:    Greg Lord
                                       UC-04 View          Version:   1.0
                                       Request Info        Created:   12/02/2001
                                                                                                       UC-09 Record                        UC-G01
                                                           Updated:   27/02/2006 2:17:13 PM
                                                                                                        purification                    Manipulate GEL
                                                                                                          results          «extend»         images


                                       UC01 Place
                                         request
                                                                                                                                      This use case refers
                                                                                                                                      to the GEL image
                                                                                                        UC-07 Setup
                                                                                                      expression wells                manipulation
                                                                                                                                      system that Virtus
                                                                                                                                      software is also
                                   UC-05 Search
                                      request                                                                                         authoring.


                                                                          Researcher
        Client                                                                                          UC-08 Record
                                                                                                      expression results
                                   UC-02 Update
                                     request




                            «extend»
                                                                                                UC-10 Print items

                 UC-03 Delete
                   request




                                                                                  UC-11 Print                UC-12 Print GEL
                                                                                    reports                      image

                                          UC-06 Populate
                                              menus


        System                                                                                  UC-13 Print order




    Figure 1.0: Use Case Diagram example




            2.1.3 Class Diagram
    Class Diagram are structured diagrams consisting of pieces that make up our system or
    subsystems. We model class diagrams to see more details about our product and to show
    the information needed to put together a map indicating the paths through the available
    functionality. Class diagrams should have these necessary UML standards:
       · System name
       · Classes
       · Objects
       · Attributes (including: access specifiers, data types and initial values)
       · Operations (including: access specifiers, arguments and return types)
       · Associations
       · Relationships (including direction and multiplicity)
       · Properties (includes name, author, version #, created and updated)




Quality_Management_Plan_v_1.6.doc                                             14/03/2006                                                           Page 6 of 22
                                                                                                                      Quality Management Plan




    First letter of the class name will be a capital letter. The names of attributes and
    operations will start with a lowercase letter and each new word will begin with a capital
    letter. There will be no space between the words.
    See Figure 1.1 for example.



                                       Name:          Eastern Districts Soccer League
                                       Author:        Nitesh Prasad                                  Season
                                       Version:       1.0
                                       Created:       10/11/2005 10:52:21 AM                  -    seasonId: int
                                       Updated:       27/02/2006 3:11:18 PM                   -    drawId: int
                                                                                              -    startDate: date
                               Division                                                       -    endDate: date

                  -       divisionId: int                                                     +    setId() : int
                                                       1                           0..*
                  -       divisionName: String                                                +    setDate() : date
                  -       seasonId: int

                  +       setName() : void
                                                                                                       Round
                  +       setId() : int

                                    1                                                         -    roundId: int
                                    10..12                                                    -    teamId: int
                                                                                              -    roundDate: date
                                Team
                                                                                              +    setId() : int
                      -    teamId: int                                                        +    setDate() : date
                      -    teamName: String       1           home team
                      -    clubId: String
                      -    playerId: int
                      -    divisionId: int                                         1                  Game


                      +    setName() : void                   away team                   -       result: String
                      +    setId() : int                                                  -       teamId: int
                                                  1                                1
                                                                                          +       setResults() : String
                                                                                          +       setTeamId() : int



    Figure 1.1: Class Diagram example


          2.1.4 Sequence Diagram
    Sequence diagrams are used to model object interactions arranged in time sequence and
    to distribute use case behaviour to classes. Sequence diagrams should have these
    necessary UML representations:
       · System name
       · Actors and Objects
       · Life lines
       · Messages of appropriate type
       · Message names and conditions
       · States, Branching, and Alternative flows.
       · First letter of the object name will be a capital letter and the name will be
           underlined.
       · Properties (includes name, author, version #, created and updated)
       · Stereo type icons

    See Figure 1.2 for example.




Quality_Management_Plan_v_1.6.doc                                     14/03/2006                                                  Page 7 of 22
                                                                                                                    Quality Management Plan



    Note: a System Sequence diagram is normally used in conjunction with the use case
    description to help document the details of a single use case or scenario within a use
    case. To System Sequence diagram will provide explicit identification of inputs and
    outputs.



                                       Name:       EDSL001
                                       Author:     Nitesh Prasad
                                       Version:    1.0
                                       Created:    3/11/2005 11:16:15 AM
                                       Updated:    8/11/2005 1:05:48 PM
                                 EDSL                                          EDSL                    DBConnect              :Player
         EDSL                 PlayerView                                  PlayerController
        Registrar
          Enter player name(searchString)


                                            Enter search string(string)



                                                                                      conn:dbConnect




                                                                                             searchForPlayers(searchString)


                                                                                                      returMatch

                                                  returnMatches
                                                                                                                         {moreMatches}


          SelectRequiredPlayer(name)

                                            retrievePlayer(name, ID)

                                                                                                       getDetails




    Figure 1.2: Sequence Diagram example



           2.1.5 User Interface Design Standards
    General rules:
       · Standard look and feel, user friendly
       · The design will be read from top left to bottom right.
       · Forms sized to fit on a 1280 x 1824 size screen.
       · Titled borders (highlight)
       · Plain borders to surround instruction text.
       · Buttons and text field should be an appropriate size.
       · Links, headers & footers.
       · Style navigation: page elements appear in the same location on each page.
       · Should include where necessary: labels, buttons, check boxes, radio buttons,
          combo boxes, text areas, lists and text fields.


Quality_Management_Plan_v_1.6.doc                                      14/03/2006                                                        Page 8 of 22
                                                                            Quality Management Plan

       ·   Standard colours for buttons, text fields, and same back ground colour

    Rule for text
    Within text fields:                 Black, Arial, 10pt.
    Labels (for text fields):           Black, Arial, Bold, 10pt.
    Labels (for instructions):          Black, Arial, 10pt.



           2.1.6 System Report Standards.
    All reports should have the following standards and style guideline;
    Report Header:
         · Font:          Normal + Arial, 18pt, Bold
         · Align:         Left
         · Detail:        Report Title
    Page Header:
         · Font:          Normal + Arial, 10pt
         · Detail:        Top left corner. (title)
    Detail Section:
         · Font:          Normal + Arial, 12pt
         · Align:         Justified
         · Detail:        Report detail
    Group footer:
         · Font:          Arial, 10pt
         · Align:         Left
         · Detail:        Report detail.
    Page Footer:
         · Font:          Normal + Arial, 10pt
         · Detail:        Report title and version # – bottom left corner. Date in
                          center. Page # of # - bottom right corner.
    Report Footer:
         · Font:          Arial, 10pt,
         · Align:         Left
         · Detail:        Report detail.



    2.2    Coding Standards
           2.2.1 Java Standards
    The following Java standards will be followed by Virtus.

           2.2.1.1 Filenames
    File names must start with a capital letter.
    No underscores “_”, no special characters.
    Multi-word names have first letter of subsequent words capitalized (E.g. BankView)
    Example Filenames: BankAccount, Dog, Coin, Purse, BankController


           2.2.1.2 Naming Conventions
    The naming conventions parallel that of the Java naming conventions, a link to these
    conventions can be found at the bottom of this section.




Quality_Management_Plan_v_1.6.doc                 14/03/2006                             Page 9 of 22
                                                                             Quality Management Plan

           2.2.1.3 Class naming
    Class names should be nouns.
    First letter of each internal word capitalized.
    Keep the class name simple and descriptive.

    Example:
    class Customer.


           2.2.1.4 Interfaces
    The interface names should be capitalized like the class names.


           2.2.1.5 Methods
    Method names should be verbs.
    First letter should be lowercase.

    Example:
    setName(String newName);
    getName();
    setDOB(int newDOB);
    getDOB();


           2.2.1.6 Variables
    Should NOT start with underscore “_” or dollar sign “$” characters (even though both are
    allowed in Java).
    Should be short and meaningful.
    One-character variable name should be avoided except for temporary variables.
    Common temporary variables are i, j, k, m, n, x, y, z for integers; c, d, e for characters.


           2.2.1.7 Constants
    Constants are all upper case with words separated by underscores, “_”.
    Constants need to be defined as 'final' variables and where possible as 'static'.

    Example:
    private static final int MIN_NAME_LENGTH;


           2.2.1.8 Comments
    Example of different comments:

    Block comment:
    /* … This is a block comment … */

    Single-line comment:
    // … This is a single line comment …

    Javadoc comment
    /** … This is a Javadoc comment … */

    All methods (except main) should have an appropriate Javadoc comment showing
    @param and @return.
    All classes should have Javadoc comments describing what the class does.



Quality_Management_Plan_v_1.6.doc                     14/03/2006                        Page 10 of 22
                                                                           Quality Management Plan



           2.2.1.9 Indentation
    Lines should be short enough to be viewed in all situations, 80 characters is a preferred
    maximum due to it being the standard size of terminal displays.

    Wrapping lines:
       · Break after a comma.
       · Break before an operator.

    Align the new line, with the beginning of the expression, at the same level as the previous
    line. Break strings over lines using String Concatenation

           2.2.1.10 Declarations
    One declaration per line:

    Example:
    int age;
    char gender;
    String dob;

           2.2.1.11 Class and Interface:
    No space between a method name and the parenthesis “(“.
    Open brace "{" appears at the end of the same line as the declaration statement.
    Closing brace "}" starts a line by itself indented to match its corresponding opening
    statement.

           2.2.1.12 Statements
    Start each new statement on its own line:

    Example:
    i++; // correct
    j++; // correct
    i++; j++; // avoid

           2.2.1.13 White Space
    Use blank lines between “class and interface”, “method”, “local variables” and “block of
    comment”.

    Example:
    a = (a + b) / (c * d); // this is good
    a=(a+b)/(c*d); // avoid this

           2.2.1.14 If statements and loops
    If statement
    Example:
    if (condition) {
            statements;
    } else if (condition) {
            statements;
    } else {
            statements;
    }

    For loop



Quality_Management_Plan_v_1.6.doc                14/03/2006                             Page 11 of 22
                                                                             Quality Management Plan

    Example:
    for (condition) {
            statements;
    }

    While loop
    Example:
    while (condition) {
           statements;
    }

    Do.. While loop
    Example:
    do {
           statements;
    } while (condition);

    If statements/loops always use braces {} to improve readability.
    Always indent code inside braces {}.


            2.2.1.15 SQL
    Capital letters should be used for all SQL keywords:
    Example:
    SELECT, FROM

    Brackets () should be used where appropriate to improve readability.
    Table and variable names should be consistent with those in the Database Standards.

    The Java coding standards as specified by Sun Microsystems will be followed. They can be
    found at: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html



    2.3     Technical Documentation Standards
            2.3.1 General Layout
    The general layout of our documentation will consist of title page, t able of content,
    introduction, and main body. Each page also consists of a border, header and footer.
    Other properties such as conclusion, references and appendices will be included if the
    document requires them.


    ·   Paragraph          Font: Verdana, 10pt, justified and normal
    ·   Heading 1          Font: Arial, 18pt, Bold, text in the heading 1 format will surrounded
                           with a box that will also be shaded in with the colour pale blue.
    ·   Heading 2          Font: Arial, 14pt and bold
    ·   Heading 3          Font: Arial, 12pt, Bold and Underline
    ·   Heading 4          Font: Arial, 11pt, Bold and Underline
    ·   Header             Font: Verdana, 10pt
    ·   Footer             Font: Verdana, 10pt
    ·   Bullets            Bullet: Small disc (filled black circle)
    ·   Table              Header Text, Bold.
    ·   Margins            Top: 2.54cm Bottom: 2.54cm Left: 2.3cm Right: 2.3cm

    Note:



Quality_Management_Plan_v_1.6.doc                  14/03/2006                              Page 12 of 22
                                                                              Quality Management Plan

       ·   Headings should be numbered appropriately i.e. 1.0, 1.1, 1.2, 1.2.1, 2.0 etc.


           2.3.2 Cover page
    The cover page consists of:
       · Virtus Software logo           Top centred
       · Document Title                 Font : Verdana,   22pt,   Black and Bold
       · Document Version               Font : Verdana,   12pt,   Black
       · Author Name                    Font : Verdana,   10pt,   Black
       · Reviewer Name                  Font : Verdana,   10pt,   Black
       · Client Name                    Font : Verdana,   10pt,   Black

       ·   Team Members                 Font : Verdana, 10pt, Black
       ·   Date                         Font : Verdana, 12pt, Black



           2.3.3 Table of Contents page
    The Table of Contents page will display right aligned page numbers, and the heading on
    the left.

           2.3.4 Introduction
    See General layout.

           2.3.5 Tables
    Table grids will be set to their default styles. The title row of the tables will be shaded
    with the colour pale blue.

           2.3.6 Documentation
    The document naming standards and format are:
       · A hard copy will be printed on A4 paper
       · The soft copy available on line will be in a word and pdf format.
       · The first letter of the filename will be in upper case and followed by lower case,
          words separated by(“_”) with the version of the document.

           2.3.7 Graphics
    Graphics other then the Virtus software logo must be identified by
    Figure 1.1 Graphic name

           2.3.8 Header
    The header will be included in all pages starting from the Table of Contents. The header
    will contain the Virtus logo (left aligned), and the documents title (right aligned).

           2.3.9 Footer
    The footer will contain the filename (left aligned), the date manually entered from the last
    correction and (centred) and page number of general type page x of y (right aligned).




Quality_Management_Plan_v_1.6.doc                 14/03/2006                               Page 13 of 22
                                                                           Quality Management Plan

           2.3.10 References
    References are to appear as the second last item of the report. Any use of published
    materials will be credited.
    This text will be in normal text. This must include the information:

       ·   Title(book, magazine/newspaper, website)
       ·   Author
       ·   Year
       ·   Address (only if it is a website)

           2.3.11 Appendices
    The appendix will appear as the last page. The appendix number will appear on the left at
    the top of the page. Example 1.1 Appendix name



    2.4    Security Standards
    Due to a rapid changing information technology sector, system security standards will be
    set up to monitor user id, passwords and access levels for the Virtus team. Data backup
    and recovery procedures must also be addressed, and a disaster recovery plan may be
    implemented.

           2.4.1 Login and Passwords
    This section covers security issues such as user access levels and password composition.
    · User Access Levels:
          o Administrator: should be able to override any system functions as well as add,
                   delete and modify experiments/results.
    • Passwords:
          o Authorisation will be required by administrator for updating data/results
          o “Administrator” account passwords must be eight or more characters and consist
                   of upper and lower case characters

           2.4.2 Database Security
       ·   All MySQL user accounts should be password protected
       ·   Only MySQL root accounts have access to the user table in the mysql database
       ·   Do not store any plain-text passwords in the database

           2.4.3 Internet Security
       ·   Use firewall
       ·   Ports that are not used by certain applications should be closed
       ·   Try to modify any dynamic URLs by adding %22 ('"'), %23 ('#'), and %27 (''') in
           the URL
       ·   Do not transmit plain (unencrypted) data over the Internet

    2.5    Database Standards
           2.5.1 Tables
       ·   All tables will be named starting with lower case letter. If the table name is two
           words, they are joined together with the first letter of the second word becoming a
           capital letter.
       ·   Tables will have a primary key where appropriate
       ·   All tables will have a unique index on the primary key to enforce uniqueness (no
           duplicate values)



Quality_Management_Plan_v_1.6.doc                14/03/2006                             Page 14 of 22
                                                                            Quality Management Plan

       ·   No spaces will be used when assigning names to tables.


           2.5.2 Database
       ·   Databases will be created using MySQL
       ·   Databases will be relational
       ·   Cardinality must be included in database design


           2.5.3 Field Names
       ·   All field names will be named as per the table convention mentioned above.
       ·   The primary key for every table should be an autonumber (auto increment).
       ·   All other fields should not start with the table name or the object name.


           2.5.4 Data Type
       ·   Data types should be carefully chosen to match the data using the smallest data
           type possible (i.e. don’t use a double when an int will do)

           Example: If there is a variable in a class defined by:
                  private String colour
           then the SQL code that creates this field would be :
                  colour TEXT DEFAULT NULL,
       ·   The length of each field should be as small as possible while still providing some
           expandability (i.e. don’t allow ten digits for the primary key when four is more
           than enough)




Quality_Management_Plan_v_1.6.doc                 14/03/2006                              Page 15 of 22
                                                                            Quality Management Plan




    3.0 Configuration Management Plan
    Virtus Software conducts its activities under a Configuration Management Plan such that
    we manage the quality of our work and specify the manner in which any changes are
    received and actioned. The plan helps us manage a project and its various deliverables
    from the start to finish. Software Configuration Management (SCM) is a series of
    activities that:
        · Control change to a project
        · Define ways of managing the change
        · Audit changes to a project
        · Report on the changes that have been made



    3.1    Configuration Identification
    Configuration Identification is to identify that the following general items are covered
    under the configuration management plan.
       · Standards.
       · Documentation.
       · Source code.
       · Data.
       · Testing.


    As part of keeping the customer informed at all times, we will get sign off on the following
    items before finalising the requirements gathering process.
        · Scope Document.
        · System Requirements Specification
        · Risk Management Plan.
        · User Interface Prototype – Database and GUI
        · Client Acceptance Test



    3.2    Reviews Procedure
    Virtus Software will adopt the following list of configuration management procedures.



           3.2.1 Configuration Identification
    All components of the project will be reviewed by the Quality Leader to identify if the item
    falls under configuration management. If they do they will be maintained on the Eventum
    Software website with current version information such as date issued, author and
    document number recorded.

           3.2.2 Version Control
    All documents will be saved, displayed and printed with a version number starting with
    1.0. When minor changes are made the new version will be saved with the document
    number 1.1 then 1.2 and so on. If a major change is made the document will be saved as
    2.0. The version numbers in the document are put in manually.




Quality_Management_Plan_v_1.6.doc                 14/03/2006                             Page 16 of 22
                                                                         Quality Management Plan




          3.2.3 Change control
    If the client requests any changes, they have to access Eventum Software to put in issues
     http://cit3.ldl.swin.edu.au/eventum/. The client has to login using username and
    password which will be provided. Once logged on to Virtus Software - Eventum site, the
    client can create issues by filling out the form. See Figure 1.3 for example.




    See Figure 1.3 Create Issue Form.


    Eventum site is reviewed by all members of the Change Control Board who will either
    authorise the change or reject it. The fact that all members of the team are on the
    Change Control Board will ensure all members are aware of the change. If a request is
    rejected a reason is recorded on Eventum and email will be sent to the client to inform
    them of the decision.

          3.2.4 Audit
    Once a change has been completed it will be audited by the Quality Leader to ensure all
    applicable standards are adhered to. If successful then the results will be placed on
    Eventum.

          3.2.5 Authority
    While all team members are involved in the configuration plan the Project Manager is
    ultimately responsible for the authorisation and implementation of change




    3.3   Change Control Board
    The members of the Change Control Board are:




Quality_Management_Plan_v_1.6.doc               14/03/2006                            Page 17 of 22
                                                                          Quality Management Plan



          Change Control Board Members:
          Team Leader                             Greg Lord
          Quality Manager                         Nitesh Prasad
          Technical Manager                       Matt Partington
          Testing manager                         Damon Arezzolo
          Planning manager                        Sia Panagiotopoulos




    3.4     Change Control Procedures
            3.4.1 Summary
    The main goal of configuration management is to help to control and manage the various
    types of changes that may affect a project. This means that we have the following things:
       · Traceability
       · Know what changes were made
       · Who made the decision to implement the change.
       · Why the change was implemented
       · Protects and controls the contents of the product
       · Ensure that the project is achieving the goals that it sets out to achieve
       · Ensure that the integrity of the project, the contents (product and documentation)
           is maintained
       · Securing the contents and making sure that everyone in the project team knows
           what the contents are.


            3.4.2 Review Procedures
       ·    All documents once completed will undergo a thorough review known as a
            walkthrough.
       ·    A formal walkthrough is done by the whole group.
       ·    Review leader will obtain all the relevant standards and have them available for
            the walkthrough.
       ·    Team leader ensures when, where, who and how the walkthrough needs to be
            done.
       ·    The review will check the whole document, matches the required standards and
            will use the “Walkthrough Action List” to record any issues found. When the review
            is completed, the secretary will sign off the document next to “Walkthrough
            Secretary” and gives to the author(s) of the document for action.
       ·    Items raised on the action list will be actioned by the author of the document.
       ·    When all items are actioned, the checklist is returned to the walkthrough leader.
            The leader will then check all items meet requirements and if satisfactory will
            initial each point for verification. If the requirements are not satisfactory, the
            checklist is actioned back to the author to be redone.
       ·    Once the walkthrough leader have initialled all the points, the checklist document
            will been filed.




Quality_Management_Plan_v_1.6.doc                14/03/2006                            Page 18 of 22
                                                                             Quality Management Plan




    4.0 Communication Plan
    The first point of contact of any issues is the Project Leader and if un-contactable then the
    Technical Leader. The primary method is mobile phone and if unsuccessful email is to be
    used. The contact information is listed below:

    Team Member              Role                   Phone              Email
    Greg Lord                Project Leader         0400 941 958        2406330@swin.edu.au
    Matt Partington          Technical Leader       0405 105 925        1179152@swin.edu.au




Quality_Management_Plan_v_1.6.doc                  14/03/2006                             Page 19 of 22
                                                                       Quality Management Plan




    5.0 References
    ·   Identified standard UML version 2.0 Download: http://www.uml.org/#UML2.0
    ·   UML – A Beginner’s Guide, Jason T.Roff, 2003.
    ·   Systems Analysis & Design in a changing World – third edition, Satzinger Jackson
        Burd, 2003
    ·   The Java coding standards as specified by Sun Microsystems will be followed. They
        can be found at: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html




Quality_Management_Plan_v_1.6.doc               14/03/2006                         Page 20 of 22
                                                                   Quality Management Plan




    6.0 Appendices

           6.1    Appendix A - Team Minutes

    Refer to Virtus Software website for actual minutes details.




    Figure 1.4: Example of meeting minutes




Quality_Management_Plan_v_1.6.doc                 14/03/2006                  Page 21 of 22
                                                             Quality Management Plan



          6.2    Appendix B - Walkthrough Action List




    Figure 1.5: Example of Walkthrough Action List




Quality_Management_Plan_v_1.6.doc               14/03/2006              Page 22 of 22

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:365
posted:4/3/2010
language:English
pages:22
Description: Quality Management Plan