Title Page ========== Project Title : MultiMahjong - Multi-Player Mahjong board game as Java application. Group ID : K-Team Group Members : 1. Joanna Araminta (jiar) 2. Victor Leung (vhle) 3. Joel Brakey (jebr) 4. Michael Hart (mwhart) 5. Dean Cortinovis (dcort) 6. Long Tang (lqkt) Abstract : This document consists of all the standards and practices, which K-Team will use in managing the MultiMahjong Project. Maintainer : Joanna Araminta Version Control : $Revision: 1.72 $ $Date: 1999/10/25 12:38:23 $ Table of Contents ================= 1. Purpose 1.1 Project Aims and Purpose 1.2 Software Items Used 1.3 Individuals Involved with the Project 2. Reference Documents 3. Management 3.1 Organisation 3.1.1 Project Managers 3.1.2 Supervisor 3.1.3 Team Secretaries 3.1.4 Client Liaison Officers 3.1.5 Librarian 3.1.6 Technical Researchers 3.1.6.1 Java 3.1.6.2 Artificial Intelligence 3.1.7 Auditors 3.1.7.1 Internal 3.1.7.2 External 3.1.8 Web Site Managers 3.1.9 Backup Manager 3.1.10 Risk Manager 3.1.11 Reviewers 3.1.11.1 Internal 3.1.11.2 External 3.1.12 Meeting Chairperson 3.1.13 Meeting Secretary 3.1.14 Document Maintainer 3.1.15 Prototyping Team 3.1.16 Coding Team 3.1.17 Testing Team 3.2 Project Plan 4. Documentation 4.1 Software Requirements Specification (SRS) 4.1.1 Nature and aims of Requirements Specification 4.1.2 Audience 4.2 Software Design Description (SDD) 4.2.1 Nature and aims of Design Description 4.2.2 Audience 4.3 Software Test Plan (TP) 4.3.1 Nature and aims of Test Plan 4.3.2 Audience 4.4 User Documentation 4.4.1 Client Application 4.4.1.1 Nature and aims of Client Application User Documentation 4.4.1.2 Audience 4.4.2 Server Application 4.4.2.1 Nature and aims of Server Application User Documentation 4.4.2.2 Audience 4.5 Design Notebook 4.5.1 Nature and aims of Design Notebook 4.5.2 Audience 5. Standards, Practices & Conventions 5.1 Meetings Procedures 5.1.1 General Meetings 5.1.1.1 Before Meeting Procedure 5.1.1.2 Meeting Procedure 5.1.1.3 After Meeting Procedure 5.1.2 Client Meetings 5.1.3 Supervisor Meetings 5.2 Review Procedures 5.2.1 Internal Reviews 5.2.2 External Reviews 5.3 Documentation Format Standard 5.4 Coding Standard 5.5 Pseudo Code Standard 5.6 Procedure for Testing 5.7 E-mail Subject Keywords 5.8 Channels of Communication 5.9 Follow Up Procedures 5.10 Problem Reporting Procedures 5.11 File and Directory Naming Standards 6. Reviews 6.1 Software Requirements Review (SRR) 6.2 Software Architectural Design Review (SADR) 6.3 Software Design Review (SDR) 6.4 Test Plan Review (TPR) 6.5 User Documentation Review (UDR) 6.6 Functional Audit 6.7 Physical Audit 7. Verification, Validation & Testing 7.1 Software Quality Assurance Plan (SQAP) 7.2 Software Requirements Specification (SRS) 7.3 Software Architectural Design Document (SADD) 7.4 Test Plans (TP) 8. Problem Reporting & Corrective Action 8.1 Critical Problems 8.2 Non-Trivial Problems 8.3 Trivial Problems 8.4 Corrective Actions 9. Tools, Techniques & Methodologies 9.1 Design Methodology 9.2 Choice of Language 9.3 Tools for Coding 9.4 Version Control 9.5 Records Maintenance & Media Control 9.6 Change Control 9.7 Other Tools 10. Risk Management 1. Purpose ========== The purpose of this SQAP is to clearly specify the standards and practices K-Team will follow throughout the life-cycle of the project. 1.1 Project Aims and Purpose ---------------------------- The purpose of our project is to write a program that lets users play the game of Chinese Mahjong (see SQAP Section 2 for the Mahjong rule book which explains how the game is played) over a network or in a stand-alone version of the game. The aim of the program is to provide users with an entertaining and easy to use game which follows the Chinese rules of Mahjong. Sub-aims to achieve this include: - The user interface will be graphical, simple and easy to use in order to make the game appealing to users. - The user interface will contain elements that have an intuitive use for a user who knows the rules of Chinese Mahjong. So they will easily be able to perform actions involved in a game, eg picking up a discarded tile in order to Pung. - It will look very similar to a real game of Mahjong, so it will show all key elements of the game. This includes: each players concealed, exposed and revealed tiles, the wall, the last discard and dead tiles. - The game will try to simulate the feel of a real game of Mahjong, including the speed and way discards are called for by a number of players at the same time (which means the player with the highest call will win). 1.2 Software Items Used ----------------------- Mac OS 8, Solaris 7, Windows 95/NT The primary OS's we will be developing the software for and on. Java Development Kit 1.2 The programming development kit that's needed to write Java programs and to run Java applications. CVS To enable version control of all documents involved in the project. Microsoft Project 98 For creating GANTT and PERT charts for project planning. Hotline 1.5 For keeping backups. Rational Rose For creating diagrams to be included in our design. 1.3 Individuals Involved with the Project ----------------------------------------- The Client we are working on the project for is: Steve Goschnick, Managing Director Solid Software Pty Ltd Level 3, Bouverie Street, Carlton VIC, 3053 Ph: 03 9344 9322, 03 9344 0154 E-Mail: gosh@solidsoftware.com.au, gosh@cs.mu.oz.au Our team for the project is K-Team and consists of: Joanna Araminta (jiar) Ph: 9889 4423 Victor Leung (vhle) Ph: 9706 1560 Joel Brakey (jebr) Ph: 9859 6038 Michael Hart (mwhart) Ph: 9859 5419 Dean Cortinovis (dcort) Ph: 9798 2684 Long Tang (lqkt) Ph: 9540 8992 The Supervisor for the project is: Anthony Senyard (anthls) Ph (W): 9344 1940 (H): 9417 2839 The Quality Assurance Reviewers for the project are: Lachlan McIlroy (lachjm) Laura Gentile (lgents) Kathryn Burt (kburt) Aseel Abbas (ana) 2. Reference Documents ====================== The documents that will be produced in the course of this project include: - The Software Quality Assurance Plan (SQAP) [this document] - The Risk Mitigation, Monitoring and Management (RMMM) - The Software Requirements Specification (SRS) - The Software Architectural Design Document (SADD) - The Software Design Document (SDD) - The Software Test Plan (TP) - The User Manual for both the Client and Server programs - The Progress Report - The Design Notebook Reference documents used for this project include: - Arnold, T et al "Software Engineering Project Manual", 1993, Dept. Computer Science, University of Melbourne. - Carkner, K.J. "How to play Mah Jong", 1993, Penguin Books Australia Ltd. - Couch, J. "Java 2 Networking", 1999, The McGraw-Hill Companies, Inc. - MJCM, Mah Jongg Cyber Museum URL: http://members.aol.com/pungchow/index.htm - Peter Van Der Linden, "Just Java 1.2", 1999, Sun Microsystems Inc. - Pressman, R. "Software Engineering: A Practitioner's Approach", 1992, McGraw Hill International Edition. - Sun Microsystems Inc., "The Java Tutorial", URL: http://java.sun.com/docs/books/tutorial/, 1999 - Zukowski, John "Mastering Java 1.2", 1998, Sybex, Alameda CA, USA 3. Management ============= 3.1 Organisation ---------------- The following roles and their associated responsibilities will be used in this project: - Project Managers : Semester 1 - Joanna Araminta Semester 2 - Michael Hart - Supervisor : Anthony Senyard - Team Secretaries : Semester 1 - Michael Hart Semester 2 - Joanna Araminta - Client Liaison Officer : Semester 1 - Joel Brakey Semester 2 - Dean Cortinovis - Librarian : Victor Leung - Technical Researchers : Java language: 1. Victor Leung 2. Dean Cortinovis Artificial Intelligence: 1. Long Tang - Auditors : Internal - Dean Cortinovis External - Fourth year students: 1. Lachlan McIlroy 2. Laura Gentile 3. Kathryn Burt 4. Aseel Abbas - Web Site Managers : Semester 1 - Michael Hart Semester 2 - Joel Brakey - Backup Manager : Michael Hart - Risk Manager : Joanna Araminta - Reviewers : Internal - All team members External : 1. Anthony Senyard 2. Fourth year students: 2.1 Kathryn Burt - SRS 2.2 Lachlan McIlroy - SADD, SDD 2.3 Aseel Abbas 2.4 Laura Gentile - Meeting Chairperson : Rotate among the team members - Meeting Secretary : To be appointed in each meeting - Documentation Maintainer : (To be appointed by the Project Manager, during task allocations.) SQAP - Joanna Araminta RMMM Plan - Joanna Araminta SRS - Michael Hart SADD - Michael hart SDD - Joel Brakey TP (Semester 1) - Long Tang TP (Semester 2) - Victor Leung Client Manual - Joel Brakey - Prototyping Team : 1. Victor Leung 2. Dean Cortinovis 3. Long Tang - Coding Team : 1. Victor Leung 2. Dean Cortinovis 3. Long Tang 4. Michael Hart 5. Joel Brakey - Testing Team : 1. Victor Leung 2. Dean Cortinovis 3. Long Tang 4. Michael Hart 5. Joel Brakey 3.1.1 Project Manager --------------------- - Negotiate a regular meeting time with the allocated Supervisor, to maintain communication between the Supervisor and the Team. - Arrange reviews with the Supervisor and Team Members. - Ensure that there is a chairperson for every meeting (not necessarily the Project Manager). - Maintain the Project Plan. - Provide feedback to the Supervisor on progress (where any allocated tasks have gone overtime they should be discussed with the Supervisor to ensure that the size of the task has not been underestimated and to manage the resulting slippages). - Report to the other Team Members the results of each meetings between the Project Manager and the Supervisor. - Maintain good relationships between other Team Members. - Ensure that all documents are reviewed, either internally, externally or both, before their submission. - Ensure the external reviews are followed up. - Allocate tasks evenly among team members and ensure that the tasks are followed. - Ensure that each team member submits a progress report after each submission. 3.1.2 Supervisor ---------------- - Monitor the progress of the team project (in a way that a high-level management would in a commercial setting). - Provide support and guidance to the team on technical matters. - Monitor the quality of all project deliverables. - Attend all agreed and arranged meetings with the Project Manager and team members. - Assist Project Manager to ensure workloads are equally distributed amongst team members. - Assist the team in their relationship with the Client. - Assist the team in developing project management strategies. - Assist the team in controlling slippages by negotiating any changes to delivery dates. - Assist in resolving team conflicts which appear to be affecting the project. - Report to the Co-ordinator on any factors affecting the progress of the project. 3.1.3 Team Secretaries ---------------------- - Maintain minutes from each meeting held. - Ensure that the minutes of every meeting are put in the repository within the time frame mentioned in Section 5.1.1.3, after the meeting takes place. - Maintain the Design Notebook. - Distribute an agenda before each meeting. - Ensure that minutes are typed according to the minutes template that can be found in: MultiMahjong/doc/templates/minTemplate.html 3.1.4 Client Liaison Officers ------------------------------ - Organise meeting times with the Client. - Keep the Client up-to-date with the K-Team's progress on the project. - Act as a primary contact with the Client. - Maintain minutes from each Client meeting. - Organise a 'Requirements and Acceptance' testing meeting with the Client. - Pass on requests from team member, for resources (if any). 3.1.5 Librarian --------------- - Maintain CVS repository. - Maintain READMEs for each team directory. - Run regular regression testing - Ensure that the Software Quality Assurance Plan Auditor has access to the team's documents. 3.1.6 Technical Researchers --------------------------- 3.1.6.1 Java ------------ - Learn how to program in JDK 1.2 - Arrange tutorials with other team members on the technical details of the Java language, which will include: * Java Networking * Swing * JavaDoc 3.1.6.2 Artificial Intelligence (AI) ------------------------------------ - Conduct research into how we can develop a good AI algorithm to play Mahjong. - Inform the other team member of the findings on AI. 3.1.7 Auditors -------------- 3.1.7.1 Internal ---------------- - Ensure that all documents conform to all the standards that are detailed in the SQAP. - Ensure that each section of a document is complete. - Check all deliverable documents for mistakes in grammar and spelling. 3.1.7.2 External ---------------- - Audit all documents and source code before submissions. - Ensure that the team has been following all the processes described in the SQAP. 3.1.8 Web Site Managers ----------------------- - Maintain the project web site. - Ensure that all documents and minutes are up on the team's web site to provide easy access for the team members, the Supervisor and the Client. 3.1.9 Backup Manager ------------------- - Perform weekly backups, and archives these. - Ensure that external auditors have access to backups log messages in the team repository. 3.1.10 Risk Manager ------------------ - Plan mitigation strategies in order to avoid risks, after identifying the most-likely-to-occur risks associated with the Project. - Maintain Risk Mitigation, Monitoring and Management Plan. - When risks occur, ensure that contingency plans are put into action. 3.1.11 Reviewers ---------------- 3.1.11.1 Internal ----------------- - Review all documents on the dates arranged by the Project Manager. - Provide feedback on the reviewed documentation. 3.1.11.2 External ----------------- - Review the specified document arranged by the team to be reviewed. - Provide feedback to the team on the documentation. - Provide suggestions on how to improve the content and the presentation of the reviewed document. 3.1.12 Meeting Chairperson -------------------------- - Start and run the meeting. - Allocate a meeting secretary to take minutes. - Maintain the meeting's agenda, and distribute it to the other team members, via e-mail, at least 24 hours prior to the meeting. - Ensure that all items on the agenda are covered. - Ensure that minutes of the meeting are recorded. 3.1.13 Meeting Secretary ------------------------ - Maintain minutes from the specified meeting. - Ensure minutes from the specified meeting are given to the Project Secretary, to be typed and put in the repository, within the time frame described in Section 5.1. - Write up the agendas of the meeting on the board. 3.1.14 Document Maintainer -------------------------- - Maintain the specified document allocated by the Project Manager. - Ensure that the specified document is up-to-date. - Modify the specified document after a review or an audit. 3.1.15 Prototyping Team ----------------------- - Conduct project prototyping. - Ensure that the prototype is ready at least 24 hours prior to the Preliminary Demonstration. 3.1.16 Coding Team ------------------ - Do project coding. 3.1.17 Testing Team ------------------- - Conduct testing, according to the Test Plan. - Ensure that the test results are carefully documented using the Testing templates, in: /home/case/340/s340gk/Repository/MultiMahjong/doc/templates/ 3.2 Project Plan ---------------- The major milestone of this project correspond with the submissions. GANTT charts will be used to show projected and completed time lines. The charts can be found in: /home/case/340/s340gk/Repository/MultiMahjong/doc/plan Major milestones (reviews and submissions): - Initial Team Meeting 16/03/99 - Initial Meeting with the Supervisor 16/03/99 (Project Manager and Supervisor) - Initial meeting with Client 17/03/99 - External review of SQAP (Draft) with 17/03/99 Anthony - Submission of SQAP (Draft) 19/03/99 - Initial Team Meeting with the Supervisor 22/03/99 - Project Plan review during Supervisor 01/04/99 meeting (Project Manager and Supervisor) - Internal Review of SRS 15/04/99 - Client Review of the SRS 15/04/99 - Submission of SRS 16/04/99 - Project Plan Review 19/04/99 (Project Manager and Supervisor) - External review of the SRS 22/04/99 (Team and Kathryn Burt - 4th year) - External audit of the SQAP (Lachlan McIlroy) 22/04/99 - Submission of Preliminary SADD 07/05/99 - Submission of Test Plans (Integration) 07/05/99 - External Audit of the SQAP (Laura Gentile) 19/05/99 - Sign-off SRS 15/06/99 - Prototyping team starts prototyping 28/06/99 - 31/08/99 - Java workshop #1 with Steve 25/06/99 - Java workshop #2 with Steve 28/06/99 - Internal review of SQAP 03/08/99 - External audit of the SQAP (Kathryn Burt) 11/08/99 - Review of Software Design Documentation 14/08/99 - Submission of Software Design Documentation 16/08/99 - Finalising SADD (second draft) for the 23/08/99 external review - External review of the SADD 26/08/99 (Team and Lachlan McIlroy - 4th year) - Preliminary Demonstration of Project 02/09/99 with Client - Preliminary RMMM completed 07/09/99 - Coding team starts coding 13/09/99 - 22/10/99 - External audit of the SQAP (Aseel Abbas) 17/09/99 - Internal review of SADD 18/09/99 - First internal review of TP 24/09/99 - Handover TP to Victor, so now instead of 29/09/99 Long as the maintainer, Victor is - Submission of the Software Architectural 29/09/99 Design Documentation (SADD) - Second internal review of TP 19/10/99 - External review of SDD 20/10/99 (Team and Lachlan McIlroy - 4th year) - Internal review of SDD 21/10/99 - Testing team start testing 27/09/99 - 25/10/99 - Submission of Final Product 22/10/99 (electronically) - Submission of the Software Design 25/09/99 Documentation - Submission of the Test Plan (Final) 25/09/99 - Submission of Final Documents 25/10/99 (electronically) - Final Presentation of Project 27/10/99 - Submission of Final Product and Documents 29/10/99 (hard copy) 4. Documentation ================ 4.1 Software Requirements Specification (SRS) --------------------------------------------- 4.1.1 Nature and aims of Requirements Specification ---------------------------------------------------- The aim of the SRS will be to address what features must be implemented in the software without mentioning how they are to be implemented. The SRS should serve the following purposes: 1. Specify software functions and how they should perform. Each one of these functions should be analysed carefully and categorise into three different levels: Level 1 - Essential Level 2 - Highly Desirable Level 3 - Desirable 2. Describe software's graphical user interface and how the software will interact with other system elements. 3. Establish constraints on the system 4. Describe all the documents and training requirements needed in completion of the project. 5. Establish customer sign-off. The SRS can be found in the group directory at: /home/case/340/s340gk/Repository/MultiMahjong/doc/SRS 4.1.2 Audience -------------- - K-Team - Client - Supervisor - Auditors 4.2 Software Design Description (SDD) ------------------------------------- 4.2.1 Nature and aims of Design Description ------------------------------------------- After the SRS is signed, we will begin the design process of the MultiMahjong system. This process consists of two stages, architectural and detailed design. The aim of the design process is to produce a design for MultiMahjong which meets all the requirements specified in the SRS. The architectural design will be an abstract representation of the system, which includes: 1. What major objects there are in the system 2. The relationships between these objects 3. What each of the objects do, but not how they are coded. 4. The traceability from the SRS to the design stage. The detailed design will describe each of the architectural design objects in detail. It will specify the algorithm and data types of components. The architectural design will be produced in a document known as the SADD. This file will then be extended during the detailed design phase to become the SDD. The final SDD can be found in the repository at: /home/case/340/s340gk/Repository/MultiMahjong/doc/SDD 4.2.2 Audience -------------- - K-Team (especially the Coding Team) - Client - Supervisor - Auditors 4.3 Software Test Plan (TP) --------------------------- 4.3.1 Nature and aims of Test Plan ---------------------------------- To ensure the product performs as expected, the test phase will be conducted in parallel with the coding phase. After coding has been completed testing will be used to correct any bugs that may exist in the code. This will continue until the product has been deemed sufficiently reliable. The test plan consists of 2 stages: Stage 1: Low level testing 1. Unit or module testing will be carried out by the author/s of that unit. Only black box testing is required at this stage. The tests conducted and test report will be based on a template, which is stored as /MultiMahjong/doc/templates/unitTemplate.doc in the repository. Once testing has commenced all unit tests will be saved as /MultiMahjong/doc/UnitTestRep/unit_test_n.rep in the repository, where n represents the unit test number. The author who is performing the unit testing should always try to fix bugs on spot, only the test data and test results will be recorded. A report of bugs detected is not required at this phase of testing. 2. For critical modules stage 1 low level testing will not be considered sufficient, thus a code inspection team will be formed (from other team members besides the module's author/s) to review the module. They will critically inspect code to review the module. In this inspection the team will check if any bugs or inefficient code is present. If the inspection team does come across such deficiencies they will document them following the bug report template, which is stored as /MultiMahjong/doc/templates/bugs_report.temp in the repository. The team can then decide whether further black box testing is required, and where appropriate may also decide that white box testing will be conducted. Once modules have passed level 1 low level testing (and any further testing required for critical modules) they will then be integrated with their related modules. Integration testing will be carried out by at least 2 testers, who will be guided as to what they should test by the author/s of the modules being integrated. The documentation of the integration tests conducted should follow the integration testing template which is stored as /MultiMahjong/doc/templates/interTemplate.doc. All of the integration tests should be stored as /MultiMahjong/doc/InterTestRep/int_test_n.rep, where n is the number of the integration test which has been conducted. The author/s of modules where problems are detected will be expected to help in fixing these errors, it will not solely be a task for the testers. This is of particular importance if modules are extremely erroneous and need major re-coding. Stage 2: High level testing 1. Once integration testing has been completed validation testing will be performed. The Software Requirements Specification will be used to determine whether the product meets the requirements of the product agreed upon by K-Team and the Client. If any requirements have not been met they should be documented in the following file: /MultiMahjong/doc/ValidationTest/srs_oversights.rep. If the team and the Client agree that the product meets all requirements this file will not be required, and instead a document will be drafted which both parties will sign to confirm that the product is a quality product. 2. At this stage the product is almost ready for release, and is the Alpha version of the product. The Alpha version will be distributed to all team members, who will then test the product by using it under the same conditions end users of the MultiMahjong product will be using it. Team members are encouraged to break the product in anyway that they can think of. Any bugs which team members find should be documented in the bugs report (see stage 1.2 for the file location). After Alpha testing has been completed and as many bugs as possible uncovered, these bugs should then be addressed by the team as a whole. 3. Product testing by the team is now considered to be complete. No further testing on the product will be conducted by the team after this phase. 4. If time allows prior to the final demonstration a Beta version of the MultiMahjong product will be given to the Client. Bugs will again be documented in the bugs report, but these will only be fixed if there is enough time. The Test Plan is located in the group directory at: /home/case/340/s340gk/Repository/MultiMahjong/doc/TP 4.3.2 Audience -------------- - K-Team (especially the Testing Team) - Client - Supervisor - Auditors 4.4 User Documentation ---------------------- 4.4.1 Client Application ------------------------ 4.4.1.1 Nature and aims of Client Application User Documentation ---------------------------------------------------------------- The aim of the Client Application User Documentation is to explain to the Client Application users how to properly use the system. The Client Application User Documentation will include: - An installation manual. - A game manual, which clearly describes the goals and the rules of Chinese Mahjong, and also describes how to play the game. 4.4.1.2 Audience ---------------- - K-Team - Client - Supervisor - Auditors - End users 4.4.2 Server Application ------------------------ 4.4.2.1 Nature and aims of Server Application User Documentation ---------------------------------------------------------------- The aim of the Server Application User Documentation is to provide information for the Server Application users, of the proper use of the system. The Server Application User Documentation will include: - An installation manual. - Usage manual. 4.4.2.2 Audience ---------------- - K-Team - Client - Supervisor - Auditors 4.5 Design Notebook ------------------- 4.5.1 Nature and aims of Design Notebook ---------------------------------------- The Design Notebook is to be maintained in a hard copy format. The Design Notebook shall contain: - Documentation of all design decisions (minutes of team meetings), - Results of reviews, - Sketches and diagrams from the client or from meetings, and - Any other documents which are used in the design process. 4.5.2 Audience -------------- - K-Team - Supervisor - Auditors 5. Standards, Practices & Conventions ===================================== The following set the standard procedures to be followed by the group at meetings and reviews, as well as documentation, coding and testing. 5.1 Meeting Procedures ---------------------- 5.1.1 General Team Meetings --------------------------- 5.1.1.1 Before meeting procedure -------------------------------- Meeting times will be decided by the Project Manager. Meetings will usually take place in the SEECS building, however if this is not convenient, the Project Manager will decide the meeting venue. Before each meeting, a chairperson will be elected by the Project Manager. The chairperson will then have to organise the agenda for the next meeting. Team members should notify the chairperson of any issues of concern that need to be discussed, via e-mail. This has to be done at least 48 hours prior to the meeting. The meeting chairperson will then have to e-mail the typed up agenda to the rest of the team 24 hours prior to the meeting. The agenda will be typed up at the beginning of the minutes. Refer to the minutes template in the group directory: /home/case/340/s340gk/Repository/MultiMahjong/doc/min 5.1.1.2 Meeting procedure ------------------------- Just before the meeting starts, the meeting chairperson will appointed a meeting secretary, to take minutes of the meeting. The appointed secretary will write the agenda on the board for easy viewing. The meeting chairperson will start the meeting. A regular team meeting will usually go for one to two hours depending on the agenda. The meeting chairperson must ensure that the agenda strictly followed. Any other businesses that might arise during the meeting will be discussed at the end of the meeting, or will be added to the agenda of the next meeting. The meeting chairperson will discuss each item of the agenda, in an orderly manner. Each item, where possible, will be resolved or further action will be decided upon. During the meeting, records of key discussion points and the decisions made are to be compiled by the meeting secretary, and noted explicitly in the Design Notebook (see Section 4.5). All decisions made in the meetings will be done democratically. Every team member's opinion on decisions made and design issues raised throughout the Project's life cycle, plays a very important role in order for the team to reach the best possible solutions. 5.1.1.3 After meeting procedure ------------------------------- The Project Manager will allocate tasks after each meeting. The task allocations are to be included in the minutes of the meeting. The minutes of the meeting will be passed on to the Team's Secretary, to be typed up in HTML format following the minutes template that can be found in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/templates The minutes from the general team meetings are to be filed in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/min/general within 5 days. The minutes will also be at K-Team's web site: http://www.perceptek.com.au/kteam/minutes The minutes for general team meeting are to be named YY-MM-DD.html 5.1.2 Client Meetings --------------------- Client meetings are to be arranged by the Client Liaison Officer. The Client Liaison Officer would have to inform the Client regarding the possible meeting time at least 5 days prior to the appointed date. The Client Meeting is usually attended only by the Client Liaison Officer and the Client, unless some other arrangements have been made. The meeting will take place at the venue that is specified by the Client. The Client Liaison Officer will act as both the Chairperson and the Secretary of the meeting. The Client Liaison Officer will take down minutes from the meeting, following the minutes template that can be found in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/min minutes will then have to be passed on to the Secretary to be typed up and filed away within 5 days after the meeting takes place. The minutes will be named as cYY-MM-DD.html and stored in the group directory /doc/min/client. These minutes can also be viewed at K-Team's web site: http://www.perceptek.com.au/kteam/minutes 5.1.3 Supervisor Meetings ------------------------- The Supervisor meetings are to be held between the Project Manager and the team's Supervisor. The Project Manager will inform the Supervisor of the meeting via e-mails, at least 3 days prior to the proposed meeting date. The meeting venue will be in the Supervisor's office, L1.56. The Project Manager will take minutes from the meeting and then pass on the minutes to the Secretary to be typed up, following the minutes template that can be found in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/templates The minutes are to be named sYY-MM-DD.html and stored in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/min/supervisor Like any other minutes, the minutes form the Supervisor meetings can be viewed at K-Team's web site: http://www.perceptek.com.au/kteam/minutes 5.2 Review Procedures --------------------- 5.2.1 Internal Reviews ---------------------- Internal Reviews are held among team members. The Project Manager will organise the review dates. Other team member can also call for review meetings whenever needed. The Project Manager or the person that calls for a review meeting should inform the other team members at least 3-5 days before the review takes place. Team members must have read and understand the document before coming to the review meeting, and formulate a list of suggestions. The minutes of the review meeting are to be named as rYY-MM-DD.html and stored in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/min/reviews The template of the review minutes will be the same as other minutes of other type of meetings. This can be found in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/templates The Project Manager will be the chairperson and the team's secretary will be the meeting secretary. The meeting secretary will record all suggestions and amendments raised from the review meeting. A further review of the document may be arranged if deemed necessary. 5.2.2 External Reviews ---------------------- External Reviews are to involved the relevant group members and the external reviewers (see section 3.1). The Project Manager will inform the external reviewer via e-mail what document the team wants the reviewer to review. The Project Manager will then set a time for a review meeting with the external reviewer, where the external reviewer will go through all the suggestions that he/she has after reviewing the document. The minutes of the review will be recorded and filed in the group directory /doc/min/reviews. The template of the review minutes can be found in the group directory /doc/templates. 5.3 Documentation Format Standard --------------------------------- The SQAP is written in plain text. All other documents will be written in HTML conforming to the HTML 4.0 standard as specified by W3C at: http://www.w3.org/TR/REC-html40/ All documents will have the following: - Title Page * Document title * Group name (K-Team) * Name and logins of group members * Abstract, briefly describing the document * Maintainer of document * Version and date - Table of Contents * Lists all Main sections, sub sections and sub sub sections - Table of Figures Sections for each document will be numbered in the following way to represent where the section fits in the document hierarchy: 1. Main Section 1.1 Sub Section 1.1.1 Sub Sub Section Figures will be labeled representing the section it is under as following: 1.1 ASCII Faces Example **** ** ** * 0 0 * * || * * \--/ * ** ** **** Figure 1.1.1 - An example image The following formatting standard applies to all documents: - Every sub section will be indented from the previous section. - Text within a section will be indented from the section heading. - Lists will be indented from the body of the text. - Lists should always begin with a capital letter and only end with a full stop if they make a complete sentence. - Every paragraph will be preceded by one blank line. - Every main section will be preceded by two blank lines. - Every sub section will be preceded by one blank line. - Every word in a section heading will begin with a capital letter, except for common prepositions (and, of, the, etc). - There will be a single space after a full stop or comma. Documents written in plain text are to conform to the following extra standards: - Lines are to be no longer than 80 characters. - Indents are defined as 4 spaces. - There will be no tab characters. - Main section headings will be underlined with '=' characters. - Sub section headings will be underlined with '-' characters. - Underlines will be the same width as the text. - Lists will use the following characters as bullets (in order of list hierarchy): - Level 1 * Level 2 + Level 3 + Level 4 (with '+' characters onwards) - Numbers will be used in lists if it is necessary to have an order, in the following way: 1. First Step 2. Second Step 2.1 First Sub-step in Second Step 2.2 Second Sub-step in Second Step 3. Third Step The standards for documents written in HTML apply to how the document should appear when viewed in Netscape Navigator 4.0 or later. There are no standards for the actual HTML coding itself, although a readable format should be adopted. Documents written in HTML are to conform to the following standards (in addition to those mentioned above for all documents). Note that whenever a "default" setting is referred to, it implies that the HTML 4.0 default should be used and no alternative explicitly declared. - The background must be white using . - The main text will reside in a table that is no wider than 580 pixels using . - All graphics must be no wider than 580 pixels, unless absolutely necessary. - Graphics must specify the exact height and width of the graphic in the tag - Graphics must be of a GIF or JPEG format. - The default indenting is to be used. - The default bullets and numbering for lists are to be used. - The main body of text should use the default font. 5.4 Coding Standard ------------------- The coding standard we will use is the suggested Java Coding Conventions (i.e.. JavaDoc ) from Sun Microsystems. This document is available in PDF format at: ftp://ftp.javasoft.com/docs/codeconv/CodeConventions.pdf There is also a copy in the MultiMahjong/doc/ directory of the repository (MultiMahjong/doc/CodeConventions.pdf). 5.5 Pseudo Code Standard ------------------------ Design of the classes will documented in JavaDoc and all methods that contain complicated algorithms will contain pseudo code to elaborate how it will be implemented. The pseudo code will be documented as follows: - The code will begin with the method name and variables, as they appear in the code. The format is: methodName(int attribute) { body; } - There is no blank line between the method name and the first line in the pseudo code. - All pseudo code will be surrounded be
brackets so that the text is pre-formatted and appears in code font. - All pseudo code within the method name will be indented, using 4 spaces. - Every line of code that is a complete action in the program is followed by a semicolon (;). - The following are formatting for condition statements in the pseudo code: * if then else: if condition then { action; } else{ action; } * for and while loops: for or while condition { action; } * case statements: case condition is N { action; } * all actions within the for, while, if then else or case statements will be indented using 4 spaces. 5.6 Procedure For Testing ------------------------- Guidelines for testing: - Testing of a new class will be conducted first by the author. It is the duty of the author to ensure the correctness and reliability of his/her code. A class is fully tested after all its methods are tested (black box only). - As mention in section 4.3 Software Test Plan, code inspection may be applied on some critical modules to decide on whether further black box and white box testing are necessary. - If successful at the single stage it will then be integrated into the project baseline for further testing. - Test cases will be used to determine the correctness of the integration. Test cases will be found in the group directory /src/testing. - Any bugs resulting from the integration will need to be handled by author(s) of integrated modules. That is why it is strongly recommended that author(s) of integrated modules assist tester(s) in this stage. - Once the bugs are believed to be removed from the bugs report, integration testing (with at least test data that detects the bugs in the first place) will be re-applied on the integrated modules. This is a closed circle and only complete when no bug is detected in this circle. - As the integration testing of all modules complete, Software Requirements Specification will be used to create test data to verify that the produced software does meet, at least, all level 1 requirements proposed in the SRS. 5.7 E-mail Subject Keywords --------------------------- The mail filter/processor program 'procmail' has been configured to store e-mail messages pertaining to different aspects of the project in separate folders as they arrive. This classification is based upon the first keyword encountered in the e-mail's subject line. The following keywords are recognised by the mail filter: - CLIENT (client communication) - CODE (discussions relevant to the implementation phase) - PROTO (discussions relevant to prototyping) - SADD (modular design of the overall system) - SDD (design of individual components within modules) - SQAP (process-related discussions) - SRS (the project requirements) - SUPER (supervisor communication) - TEAM (team related matters: meeting agendas, minutes, etc) - TP (testing and verification) If none of the above keywords are present, the e-mail message will be stored in a folder labeled 'other'. The librarian is responsible for examining this folder periodically and moving the messages contained therein to other folders, if appropriate. 5.8 Channels of Communication ----------------------------- E-mail will be used as a primary source of communication between team members, the Supervisor and the Client. Copies of all e-mails will be kept by the Secretary, however, all team members are encouraged to also keep copies. In addition the above, a centralised store of all e-mails addressed to the team will be located in the group directory at: /home/stude/340/s340gk/Repository/mail.archive This e-mail archive was started on Friday, 6 August 1999. The mail filter/processor program 'procmail' has been configured to classify and store e-mail messages pertaining to different aspects of the project in separate folders as they arrive. This classification is based upon the first keyword encountered in the e-mail's subject line. The list of recognised keywords is specified in Section 5.7. In the case of emergency, i.e. for urgent communication, the team will use the telephone to communicate between team members, the Supervisor and the Client. Each team members are encouraged to have the telephone numbers of all the individuals involved in the Project (i.e. the other team members, the Supervisor and the Client). This can be found in Section 1.3. The team's communication model is to be democratic decentralised. The team decided to follow this model so that everyone has an equal opportunity to decide on issues related to the Project. 5.9 Follow Up Procedures ------------------------ To ensure that all the reviews (both internally and externally) and the audits are followed up, a follow up report will be produced after each review and audit. Follow ups will be discussed in team meetings, during team update. The team's secretary will typed up the follow up reports. The follow up reports can be found in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/templates The follow up reports for the reviews are to be named furYY-MM-DD.html (the dates in the file name are the dates when the reviews were held) and stored in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/min/reviews The follow ups reports for the audits are to be named fuaYY-MM-DD.html (the dates in the file name are the dates when the audits were held) and stored in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/min/reviews 5.10 Problem Reporting Procedures --------------------------------- Problems encountered during the completion of the Project are to be categorised into three different type of problems. This is specified in Section 8.1 - 8.3. If any, these problems will be brought up in the team meetings to be discussed and solved, and will be documented in the team's minutes. 5.11 File and Directory Naming Standards ---------------------------------------- All the documents that will be handed in at the end of the Project's life cycle will be named according to their acronyms, in lower case letters. All the HTML files will be named as 'doc_acronym.html', and all the plain text files will be named as 'doc_acronym' (i.e the Software Quality Assurance Plan is written in plain text, thus it is named as 'sqap', where the Software Requirements Specification is written in HTML, thus it is named 'srs.html'). All the templates are to be named as 'name_of_docsTemplate.html'. All the bugs report are to be named as 'type_of_bugs.html'. All the test results are to be named as follows: - Unit Test Results -> unitTestClassName.html - Integration Test Results -> inteTestClassName.html The minutes naming standards can be found in Section 5.1. All the directories will be named according to the contents of the directory. For example, the directory that will contain all the source code will be called src/. All the directory names along with the brief description of what each directory is for, and the directory structure can be found in Section 9.5. 6. Reviews ========== This is a description of the reviews to be held, and a list of people who should be present. 6.1 Software Requirements Review (SRR) ------------------------------------- The SRR is held to ensure the adequacy of the requirements stated in the SRS. The internal and Client reviews will be held on 15/4/1999. Personnel needed: All K-Team members. The external review of the SRS is to be held on 21/4/1999. Personnel needed: 1. Kathryn Burt (Fourth Year Reviewer) 2. All K-Team members 6.2 Software Architectural Design Review (SADR) ---------------------------------------------- The SADR is held to evaluate the technical adequacy of the architectural design of the software as depicted in the first revision of the SADD. An internal SADR will take place on 18/9/1999. Personnel needed: All K-Team members. An external SADR will take place on 26/8/1999. Personnel needed: 1. Lachlan McIlroy (Fourth Year Reviewer) 2. All K-Team members. 6.3 Software Design Review (SDR) -------------------------------- The SDR is held to determine whether the detailed design of the MultiMahjong product depicted in the SDD satisfies the requirements agreed upon in the SRS and whether the design can feasibly be put into code. An internal SDR will take place on 20/10/1999. Personnel needed: All K-Team members. An external SDR will take place on 19/10/1999. Personnel needed: 1. Lachlan McIlroy (Fourth Year Reviewer) 2. All K-Team members. 6.4 Test Plan Review (TPR) -------------------------- The TPR is held to evaluate the adequacy and completeness of the test data and testing methods defined in the Final Test Plan. An Internal test plan review will be held approximately one week before the deadline for the Final Test Plan. It is assumed that at this stage, the prototype would be nearly completed. In order for the review to be effective, those team members who are involved in building the prototype should present their test data and test methods (these data and methods should be included in the Final Test Plan already) to the reviewers. Reviewers (other than the author(s)) will use this information for the evaluation. An internal TPR will take place on 24/9/99. Personnel needed: All K-Team members. 7. Verification, Validation & Testing ===================================== This section describes the methods used to verify the documents required for the MultiMahjong project. 7.1 Software Quality Assurance Plan (SQAP) ------------------------------------------ The method by which our SQAP will be verified is firstly by a team review which will take place on 16/3/99. This conforms with the meeting procedures laid out in section 5.1 of the SQAP. The criteria which will be examined at this review are: - Whether the SQAP contains the necessary criteria. - Whether the SQAP has sufficient detail in all areas to be ready for a managerial review. - Whether our SQAP is feasible and is agreed on by the team. Secondly a managerial review will be held between the team and our Supervisor on 17/3/99. The review will determine whether the SQAP meets the following criteria: - Project purpose and aims are described. - Software items used to make the project are listed and described. - Individuals connected with the project are identified. - All necessary documents are referenced. - Team members have been allocated roles and their associated responsibilities explained. - The responsibilities of the Supervisor, Reviewers (internal and external) and Auditors (internal and external) have been defined. - The project plan shows: * The phases of the project and submission dates. * The schedule of completed tasks for the Concept Phase. * Projected schedule for the subsequent phases, which include: + The Analysis and Specification Phase + The Architectural Design Phase + The Detailed Design Phase + The Coding and Integration Phase * Projected schedule for other major milestones. - All planned quality assurance documents are listed and described. - There are set procedures for meetings and reviews. - A time has been set for the regular meetings and a method of allocating tasks has been explained. - Standards have been set for documentation and coding. - Procedures for testing have been outlined. - Major reviews described with: * Types of review for each Phase * Items to be reviewed * Personnel involved in each review - Methods used to verify documents are described. - Problems have been categorised and described. - There are procedures for reporting and correcting problems. - The design methodology to be followed is described. - Tools and systems for documenting decisions and design are described. - Media control detailed. - Risks and mitigation strategies are documented. 7.2 Software Requirements Specification (SRS) --------------------------------------------- The principle method of verification of the SRS will be the SRR between the team and the Client, which will take place on 15/4/99. The review will determine whether the SRS meets the following criteria: - The purpose of the MultiMahjong project is given. - The existing logical system is described. - The proposed logical system is explained. - Functional requirements are described and numbered for traceability. - The non-functional requirements are described, including: * Identifying the users and what they will use MultiMahjong for * Hardware constraints * Likely modifications * Performance constraints * Design constraints * Implementation constraints * Security needs - There are requirements given for the user interface. - There are documentation and training requirements. - Acceptance criteria is specified. - Examples of system behavior are given. - There is a glossary to clarify certain words. - Section for Client and team to sign-off. The team will also hold a review to ensure that the SRS complies with the team's requirements, this meeting will take place on 15/4/99. The criteria that will be examined at this review are: - The completeness of the SRS with all constraints on the system described - The feasibility and necessity of requirements set - Requirements are objective and testable - Whether all requirements are easily understood - Changes required to the SQAP resulting from the SRS - Whether the SRS follows the documentation standard laid out in section 5.2 of the SQAP for submitting electronic documents 7.3 Software Architectural Design Document (SDD) ------------------------------------------------- The first stage in verifying the SDD will be for 2 team members to informally meet with the Client to: - Show paper prototypes of the Multi-Player Mahjong application. - Confirm these prototypes satisfy the Clients requirements set out in the SRS. - Confirm the way the program looks and allows the users to interact meets expectations. The second stage will be a team review, which will confirm: - The designed structure of the SDD meets requirements set out in the SRS. - The SDD contains: * The design description (which includes overview of system structure, each object in the object design, the name and/or ID of every object and clear and complete diagrams). * The object design descriptions (which includes each object that appears in the description and all information available for each object, including any references to specifications in the SRS). * Objects selected are appropriate. - The group is satisfied with the design decisions we have chosen. - The SQAP has been updated to reflect changes up to the SADD. - The SRS is updated so that the data descriptions and system descriptions include any changes. - The design notebook contains design decisions, their rationale and any trade-offs which have been made. 7.4 Test Plan ------------- The first stage in verifying the Test Plan will be for the team to conduct a team review. A group of 2 has been allocated to write up the Preliminary Test Plan. In the team review, the Preliminary Test Plan group will have to present the test plan to the other team members, and the following issues will be discussed: - Whether all functional requirements specified in the SRS are thoroughly tested. - The thoroughness of testing for various modules. - Whether it is necessary to conduct all the testing specified in the test plan. - Whether it is possible to perform all the tests specified, given the time constraints of the project. - The order of modules and systems to be tested. - The level of importance of the tests described in the test plan. The second stage will be an external review, which will be conducted by the team's fourth year reviewer, Lachlan McIlroy. In this review, the following issues will be discussed: - Whether the team has specified all the necessary tests that are needed to produce a quality product. - Give feedback to the team regarding the test plan. - Whether all the functionality specified in the SRS is thoroughly tested. The third stage will be a progress meeting with the Client. In this meeting, the team will do a presentation to the Client, explaining the team's test plans. This will happen after a fair amount of tests have been performed. 8. Problem Reporting & Corrective Action ======================================== 8.1 Critical Problems --------------------- A "critical" problem is defined as ambiguities or conflicts that may potentially lead to deviations from the Software Requirements Specification (s4.1) and the Software Design Description (s4.2). Due to their severity, critical problems should be made known to the development team (and the Client, if it relates to a change of requirements) within 48 hours of discovery. 8.2 Non-Trivial Problems ------------------------ Ambiguities or conflicts that do not fit the classification of critical problems may be classified as "non-trivial" if there are no obvious or easily implemented solution to the problem, or if the team's collaboration is required for the solution to be implemented (eg. changes to interface which may span several modules). Whoever discovered the problems should inform the Project Manager so that he/she can ensure that these problems will be discussed at the next team meeting. 8.3 Trivial Problems -------------------- Trivial problems are those that can by easily resolved by the team member who discovered the problem. They do not need to be formally reported, however it will still have to be documented in the SQAP and/or the Design Notebook, If the team member who discovered the problem choose to discuss the problem at the next team meeting, he/she may do so, that is if he/she feels that the discussion may be beneficial (eg. to uncover similar problems in other areas). 8.4 Corrective Action --------------------- In the case of critical and non-trivial problems, the problem will be carefully analysed and possible solutions explored. The likely impact of the problem on the development process also needs to be assessed. Depending on the severity/impact of the problem, additional resources may need to be dedicated to its resolution. In all cases, while many team members may actively participate in the problem resolution process, the person who discovered the problem is ultimately responsible for declaring the problem resolved. In other words, it is the discoverer who has the responsibility of testing the proposed solution to the problem. 8.5 Bug Reports --------------- If a fault/bug is discovered during development and/or testing, a bug report should be filed within 24 hours of discovery. The bug report should be of sufficient detail for any member of the development team to reproduce the reported bug. A template may be found in: /home/case/340/s340gk/Repository/MultiMahjong/doc/templates The team member who first found the bug would inform the whole team either via e-mail (preferred) or directly in the team meeting. On receiving such warning, at least a team member (prefer the author of the section of the code that produces the bug) will be allocated to eliminate the bug. This person must inform (e-mail or in the meeting) the whole team on whether the bug has been removed or not. The bug reports will be stored in the group directory: /home/case/340/s340gk/Repository/MultiMahjong/doc/bugs 9. Tools, Techniques & Methodologies ==================================== 9.1 Design Methodology ---------------------- For implementation and submission of documents, the waterfall model will be used. This means that the team will produce a SQAP, an SRS, an SDD, an SDD and a TP in that order. For the design process, we will use the Booch method of Object Oriented design. The five stages of the Booch method are as follows: 1. Establish core requirements (conceptualisation) 2. Develop a model of the desired behavior (analysis) 3. Create an architecture (design) 4. Evolve the implementation (evolution) 5. Manage post delivery evolution (maintenance) The layout of this method ensures a tight integration with the waterfall model. The Object Oriented nature also ensures a tight integration with the Java language. Due to the shear size of the project and lack of specific knowledge, we will begin prototyping before the design documentation is actually complete. This will enable us to eventually create a more accurate SDD by integrating our knowledge of the APIs of JDK 1.2. The final stages of this prototype will also coincide with the suggested date for the Preliminary Demonstration (see Section 3.2), after which, a more rigorous design and testing process will be applied according to our documentation. 9.2 Choice of Language ---------------------- The software will be developed in Java. The Java Development Kit (JDK) 1.2 will need to be used in accordance with the Client's specifications. 9.3 Tools For Coding -------------------- As specified in Section 9.2, JDK 1.2 will be used as the programming environment. This will enable us to develop code on Solaris 5.7, Windows 95/NT or MacOS 8. 9.4 Version Control ------------------- Version control for any code, documentation, or other text-based information will be handled using CVS. Every time a change is made it will be checked into CVS to keep the repository up to date. Multiple copies of coding and documentation will be avoided using CVS and all updates will be retrieved from the log when required. Log messages will indicate the corresponding section that was changed in the document and the reason why if necessary. 9.5 Records Maintenance & Media Control --------------------------------------- All code and documentation will be stored on-line in the group directory Updates to files will be handled by CVS and major documents will be maintained by the designated author of each file. The group directory structure will contain separate areas for SRS, SDD, TP, user documentation, design notebook, minutes, group correspondence, etc. The directory /home/case/340/s340gk/Repository has the following structure: - CVSROOT CVS administration files - MultiMahjong repository for the MultiMahjong project - bin binary files (Java byte code) - data game data, graphics, sounds, etc. - doc project documentation - SDD the Software Design Document - images illustrations for HTML documents - SQAP the Software Quality Assurance Plan - SRS the Software Requirements Specification - images illustrations for HTML documents - TP the Test Plan - images illustrations for HTML documents - reports unit, integration and system test reports - bugs bug reports - help on-line help files and user documentation - min minutes of meetings - client minutes of client meetings - dnbook the Design Notebook - general minutes of general team meetings - reviews minutes of reviews - supervisor minutes of supervisor meetings - plan the Project Plan (including Gantt charts) - templates templates for minutes, bug reports, etc - src Java source code directory - au this package structure follows the - com standards set by Sun Microsystems - solidsoftware - multimahjong - mmc MMC module - co CO module - game Game module - usergui UserGUI module - doc-files screenshots - mms MMS module - shared shared classes - prototype exploratory programming and prototyping - hack internal code name for our prototype - drivers driver and stub files used for software testing - module program modules - prototype exploratory programming and prototyping - stub stripped source files contain JavaDoc comments - testing other test-related files Information that does not need authorised access (i.e. the SQAP, SRS, etc) will be available on the team's web site so that it is easily accessible. This information will be updated by the Web Manager whenever such a document is completed or modified. The web site address of the team is: http://www.perceptek.com.au/kteam/ Everything in the CVS repository (/home/case/340/s340gk/Repository) will be mirrored on a Hotline Server as discussed in Section 9.6 and updated every week by the Backup Manager. This will provide extra backup services to those already provided by the Computer Science Department. The backup log will be updated every time a backup is made. This log will reside on the Hotline Server, but will be uploaded into the file /home/case/340/s340gk/Backup_Log before an external audit is to be made. As the Hotline Server is not accessible through UNIX, there are no script files and the backups are done manually. 9.6 Change Control ------------------ The CVS repository of all documentation, source code, and data files pertaining to the project will be readable and writable by all members of the development team and may be freely modified after a general consensus is reached amongst the development team, provided that the proposed changes to these files are in line with the Software Requirements Specification (s4.1) and the Software Design Description (s4.2). However, any changes to the requirements of the system, which requires the SRS to be modified, must be signed and approved by the Client. A file named 'README' will be created in each directory. This file will contain a list names and descriptions of all files and subdirectories. All changes to the repository must be carefully logged. In particular, the 'README' file should be updated and checked for accuracy each time a file is added or removed from the repository. 9.7 Other Tools --------------- Adobe GoLive will be used by the Web Site Managers to create, edit and maintain the HTML pages. Hotline will be used for backups and miscellaneous file storage. Hotline uses a client/server interface that will allow us to have access to files, news postings and chat rooms. This will provide extra functionality for file sharing and backup services. MS Project will be used to maintain the GANTT charts for the Project Plan (see Section 3.2). 10. Risk Management =================== All the details about the risks that K-Team might encounter during the Project life-cycle are included in the Risk Mitigation, Monitoring and Management (RMMM). This document can be found in the group directory /home/case/340/s340gk/Repository/MultiMahjong/doc/SQAP/rmmm.html