Project Quality Plan

1. POST MODULE ASSIGNMENT (PMA)
PROJECT QUALITY PLAN (PQP) FOR A COMPUTER SOFTWARE PROJECT
1.0 Introduction
A PQP is a document setting out overview of work approach, practices and procedure to
ensure compliance. It can also be defined as a set of activities planned at the beginning of the
project that helps achieve quality in the project being executed. The purpose of the PQP is to
define the activities/tasks that intend to deliver products while focusing on achieving
customer’s quality expectations. The activities/tasks are defined on the basis of the quality
standards set by the organization delivering the product.
The PQP should:
a) Fulfill the client’s needs from the contract.
b) Reflect the current practices and capabilities.
c) Suitable for the team organization.
d) Be specific yet flexible by having a simple and short PQP.
Elements that should be included in a detailed PQP are:
a) Project Team Responsibilities.
b) Design Control.
c) Document Control.
d) Inspection and Testing.
e) Nonconformance.
f) Corrective Actions.
g) Quality Records.
h) Quality Audits.
i) Quality Objectives.
j) Key Project Deliverables and Processes.
k) Quality Standards.
l) Quality Control and Assurance Activities.
m) Quality Roles and Responsibilities.
n) Quality Tools to be Used in the Project.
1

2. For QA to be effective, two things must be ensured:
a) The PQP must be sufficient to achieve the required quality standards expected of the
organization. In this regard, the plan must not only be specific and detailed listing all the
quality requirements and standards, but also include all steps taken to ensure that those
requirements and standards are met.
b) QA should be independent of the project itself.
2.0 Assumption
For the purpose of this PMA, a number of assumptions are made to set the basis and
background of the PQP. The assumptions consists of the client’s background, company
background and a simplified project description from the contract.
2.1 Client Background
KTD is responsible to produce Army officers from graduates from the various plethora of
tertiary education institutions. Several courses are run within a year to accommodate the
various categories of Army Officers for the Malaysian Army. The organization structure of
KTD is shown in Figure 2.1. Basically, KTD is divided into 4 departments which is
Administration, Training, Logistic Support and Examination & Validation. KTD intends to
outsource a software application for wargaming simulation in their training syllabus. The
chosen company for KTD is SOFTWARE PRO.
Figure 1.0 – KTD Organisation Structure
2

3. 2.2 Company Background
SOFTWARE PRO is a software development company providing custom made software for
customers. Software produced is guaranteed through a mature software development
methodology geared for design, implementation and future computer systems. The company
is committed to the timely delivery of user friendly software with AI, robust and highly
compatible product design in a disciplined environment of dependable customer service. The
world class services offered by SOFTWARE PRO are proven through its over 20 years of
outstanding track record for numerous global clients.
2.3 Project Description
SOFTWARE PRO has assigned a team to develop a War Battle Simulation Software for
KTD. The composition of the team is shown in Figure 2.3. The project particulars are:
a) Project Duration – 6 months.
b) Project Cost – RM 50,000.00
Figure 2.0 – Project Team
The Scope of Project are:
a) Produce a fully functional bug-free War Battle Simulation Software.
b) Embed AI according to the Best Coding Practice.
c) Manual to use the software.
3

4. 3.0 Objective
The objective of this PMA is to perform the following:
a) Prepare a PQP to be used to manage the project
b) Prepare 3 different procedures for core processes as describe in the PQP.
4.0 Methodology
Methodology is the manner, method, procedure, way or approach that will be used to attain,
achieve, and accomplish the objective of this PMA. The method used is assumption based
approach. Assumptions will be used to create the Project Quality Plan. The assumptions will
be used to fulfill the components of the Project Quality Plan.
5.0 PQP
The PQP is shown in the following pages:
4

5. CONTENTS
1.0 Introduction
2.0 Quality Objective
3.0 Quality Planning
4.0 Key Project Deliverables
5.0 Organisation & Responsibilities
5.1 Project Manager
5.2 Office Manager
5.3 QA Manager
5.4 Software Analyst
5.5 UI Designer
5.6 Programmer
5.7 Tech Support
6.0 Quality System
7.0 Quality Standards
8.0 Quality Tools
9.0 Quality Control and Quality Assurance Activities
9.1 Document and Data Control
9.2 Quality Records
9.3 Quality Activities
9.3.1 Contract Review
9.3.2 Post Review
9.3.3 Amendments
9.3.4 Records
9.4 Inspection and Test
9.4.1 Inspection and Test Plan
9.4.2 Inspection and Test
9.4.3 Inspection, Test and Records
9.5 Inspection and Test Computer Hardware
9.6 Inspection and Test Status
9.7 Control of Nonconformance
9.8 Corrective Action
9.9 QA Audits
10.0 List of Procedures and Processes
5
SOFTWARE PRO
Document
Name:
Project Quality Plan
Document Category:
Plan
Document Number:
R1
Revision:
1
Revision Date:
19-04-2013
Pages:
15
KTD WARGAMING SIMULATION SOFTWARE

6. 1.0 INTRODUCTION
This PQP has been developed by SOFTWARE PRO in following with the Quality
requirements of ISO Standards. The Quality Plan is tailored to meet the specific requirements
of the contract to ensure that KTD requirements are satisfied.
2.0 QUALITY OBJECTIVE
The quality objective is to ensure that all phases of the Project are executed with the highest
level of Quality and efficiency satisfying the KTD requirements. The Quality Plan shall be
implemented with the full support of all stakeholders engaged in the Project.
3.0 QUALITY PLANNING
Quality Planning activities have been incorporated into the Project Implementation Plan and
provisions have been made in the planning to ensure that documents required for activities
are prepared and issued for approval and before the planned activity is to commence.
It is the responsibility of the QA Manager to maintain the List of Procedures and Processes
current and effective throughout all stages of the Project as may be required for review and
approval by the Project Manager. The flowchart below shows a process of the software
development and to be followed as phases in order:
Figure 5.0A – Software Development Phase
SOFTWARE PRO uses the Software Development Waterfall Model, after each phase is
finished, it proceeds to the next one. Reviews may occur before moving to the next phase
which allows for the possibility of changes. Reviews may also be employed to ensure that the
phase is complete; the phase completion criteria are referred to as a "gate" that the project
must pass through to move to the next phase. The Waterfall Model discourages revisiting and
revising any prior phase once it's complete. This will ensure the project completion in time.
6

7. 4.0 KEY PROJECT DELIVERABLES
NUM TASK DELIVERABLE DUE DATE
1. Requirement
Specification
a) Produce Project Implementation Plan
according to requirements from contract
and explained to KTD.
b) Confirmation letter after Project
Implementation Plan explanation and
endorsed by KTD.
End of 1st month
2. Software Design a) Produce software framework and UI
prototype.
b) Produce amended framework and user
interface prototype after presentation
feedback from KTD.
c) Repeat 2.b) if require further
amendments.
End of 2nd
Month
3. Programming a) Weekly report on programming status.
b) Produce software beta version by end
of 3rd month.
End of 3rd month
4. Testing a) Report on software testing by
SOFTWARE PRO and KTD
representative.
b) Debugging report from software
testing.
End of 4th month
5. Software Production Produce final version of software. End of 5th month
6. User Manual
Production
a) Produce user manual.
b) Delivery of software and user manual.
2 weeks before
project
completion date
Figure 5.0B – Key Project Deliverables
5.0 ORGANISATION AND RESPONSIBILITY
5.1 Project Manager
The Project Manager appointed by Software Pro is authorised to decide and take all necessary
actions to ensure speedy, effective and economical completion of the project. He is directly
responsible to KTD for the success of the Project.
7

8. Software Pro has delegated to the Project Manager the complete authority to take the
necessary actions to ensure conformance by the team to the Quality System. To satisfy the
purpose of this Project Quality Plan, the word “Responsibility” shall mean “The actions
which the nominated personnel are responsible and accountable for”. The responsibilities
include:
· Accomplish human resource objectives by orienting, training, assigning, scheduling,
coaching, counseling, disciplining employees, communicating job expectations, planning,
monitoring, appraising, reviewing, planning, enforcing policies and procedures.
· Achieves operational objectives by contributing information and recommendations to
strategic plans and reviews; preparing and completing action plans; implementing
production, productivity, quality, and customer-service standards; resolving problems;
completing audits; identifying trends; determining system improvements; implementing
change.
· Meets financial objectives by forecasting requirements; preparing an annual budget;
scheduling expenditures; analyzing variances; initiating corrective actions.
· Updates job knowledge by participating in educational opportunities; reading
professional publications; maintaining personal networks; participating in professional
organizations.
· Enhances department and organization reputation by accepting ownership for
accomplishing new and different requests; exploring opportunities to add value to job
accomplishments.
5.2 Office Manager
The Office Manager reports to the Project Manager. His responsibilities include:
· Maintain office services by organizing office operations and procedures, controlling
correspondence, designing filing systems, reviewing and approving supply requisitions
and clerical functions.
· Provide historical reference by defining procedures for retention, protection, retrieval,
transfer and disposal of records.
8

9. · Maintains office efficiency by planning and implementing office systems, layouts,
and equipment.
· Designs and implements office policies by establishing standards and procedures,
measuring results against standards and making necessary adjustments.
· Summarization information, review, analyzes and drafts reports and presentations.
· Contributes to team effort by accomplishing related results as needed.
· The Office Manager may be expected to perform secretarial duties such as taking
minutes, taking appointments, typing documents, filing, etc.
5.3 QA Manager
The QA Manager reports to the Project Manager. Responsibilities and authority with regard
to quality matters are directly delegated on all the project activities undertaken. His
responsibilities include:
· The preparation, updating, amendments and issue of this Quality Plan.
· Review and approval of work procedures and instructions.
· To hold frequent quality meetings with the project team.
· Monitor the status of implementation of the PQP.
· Monitor the implementation of the Project Procedures.
· Review quality concerns of the work process and make recommendations for
improvements.
· Conduct software inspection and testing with the Software Analyst focusing on quality.
5.4 Software Analyst
The Software Analyst reports to the Project Manager. His responsibilities include:
· Coordinate with KTD and Project Team Members to gather the information needed for
the software development.
· Determine requirements for software development that is practicable to SOFTWARE
PRO.
9

10. · Review software requirements with Project Team Members.
· Produce initial software framework for KTD, UI Designer and Programmer.
· Amend software framework if required.
· Conduct software inspection and testing with the QA Manager focusing on functionality.
· Produce user manual documentation after completion of final software version
which includes step-by-step procedural guides, overview material, field specific
definitions, explanation of reporting functions, and training material. Internal
documentation includes reports of all the tests conducted, the results and final sign off.
5.5 UI Designer
The UI Designer reports to the Project Manager. His responsibilities include:
· Translate software framework for KTD and leveraging that to design a quality,
meaningful and workable UI.
· Work closely with the Software Analyst and Programmer to ensure seemless integration
of the UI with the program source code.
· Define the look and feel of the UI satisfying or exceed KTD requirements.
· Amend UI prototype if required after presentation to KTD.
5.6 Programmer
The Programmer reports to the Project Manager. His responsibilities include:
· Confirm project requirements by reviewing software framework, input data, and output
requirements with Software Analyst, UI Designer, and KTD.
· Arrange project requirements in programming sequence by analyzing, preparing a work
flow chart and diagram using knowledge of computer capabilities, subject matter,
programming language, and logic.
· Encode project requirements by converting work flow information into computer
language.
10

11. · Program the software by entering coded information.
· Confirm program operation by conducting tests with QA Manager, modifying program
sequence and source codes.
· Maintain historical records by documenting programming activities.
· Maintain client confidence and protects operations by keeping programming software
confidential.
· Correct errors by making appropriate changes and then rechecking the program to ensure
that the desired results are produced.
· Conduct trial runs of programs and software applications to be sure they will produce the
desired output.
· Consult with Project Manager to suggest any changes.
· Investigate for cause if program does not integrate well with UI.
· Consult with Project Manager to define and resolve problems during programming
activities.
5.7 Tech Support
The Tech Support reports to the Project Manager. His responsibilities include:
· Evaluate computer hardware requirements for the Project.
· Provide suitable PC hardware to Project Team Members.
· If required, propose budget for additional computer hardware to the Project Manager.
· Maintains computer hardware efficiency at optimum level performance.
· Investigate and fix any computer hardware failures during Project Implementation
· Contributes to team effort by accomplishing related results as needed.
6.0 QUALITY SYSTEM
The holistic Quality System involved in the project consists of:
11

12. · Project Team Members ensure their responsibilities and priority for quality as an
individual and a team.
· The final product of the software must meet and preferably exceed KTD requirements.
· The process of the implementation of the software development meets the standards of
this PQP and the experience leveraged for improvement on future projects.
7.0 QUALITY STANDARDS
The quality standards used are ISO 9000 with ISO 9001 for the overall QMS, Software
Development Waterfall Model and Best Coding Practices of uniform coding, reducing
oversight errors and the time spent in inspection and testing which are a set of rules that
SOFTWARE PRO has learned over time to improve the quality of software development.
Using these Quality Standards greatly reduces the probability of problems during software
development.
FIGURE 5.0C – Software Development Waterfall Model
8.0 QUALITY TOOLS
This project utilizes several Quality Tools throughout the software development:
· Survey to KTD appointed representatives – During requirement specification phase.
12

13. · QFD – This is the tool used to bring KTD into the software development process. The
information received from KTD falls into two categories: input and feedback. a) Input is
given through the contract. b) Feedback throughout the software development. In
addition, affinity diagram, interrelation diagram, tree diagram and matrix diagram are
integrated into the QFD.
· Flowchart – Used by Software Analyst and Programmer during Software Design and
Programming phase.
· Gant Chart – Used by Project Manager to monitor progress of project phases and
deliverables are on time.
· Cause and Effect Diagram – For problem solving during software development.
· Stratification – Used together with Cause and Effect Diagram to group problems into
categories.
· Check Sheet – Facilitates collection of data from Survey and QFD displaying it in an
easily understandable visual form.
9.0 QC AND QA ACTIVITIES
9.1 Document and Data Control
· The receipt, issue, indexing filing, storing and changes to the Project documents shall be
controlled at all times in accordance with relevant project procedure. The control of all
Project Site Documentation is the responsibility of the Project Manager.
· Control shall ensure that records of receipt, description, revision, numbering and
distribution are maintained. The distribution requirements for each type of document
shall be determined and defined to ensure the correct edition of each document is issued
to the workplace prior to performance of the activity concerned.
· Registers of control may be computer-or manually-generated depending upon the
volume of documents involved. A transmittal system shall be used for the internal and
external movement of all documents.
9.2 Quality Records
13

14. · It is the responsibility of the QA Manager or his designated Inspector to ensure that all
Quality Records are compiled, maintained and collated as the work is performed
throughout the duration of the Project. These records provide objective evidence of the
Quality of work produced and testify that the work is in compliance with contractual
requirements.
· Such Quality records shall contain all data and information required by KTD, standards,
regulations, specifications, software framework and the contract.
· Records shall be legible, correctly identified, readily retrievable and traceable to the
materials or activity for which they were produced and duly signed by the Project
Manager.
· Records shall be indexed, filed and protected to prevent damage, deterioration or loss.
· Records can comprise legibly hand-written, printed or typed documents, magnetic tapes,
disks, microfilm or other acceptable media. Certificates shall comprise original
documents or authenticated copies.
.
9.3 Quality Activities
9.3.1 Contract Review
· To review contract and establish its suitability.
· To establish the requirements of the project relevant to all disciplines and compile into a
List of Procedures and Processes for the information of all Team Project Members who
are required to work on the project.
· To establish a reference file of all Quality Records and to ensure that all changes to this
data is controlled, authorised and distributed as necessary.
9.3.2 Post Review
· At the commencement of the project, Project Team Members shall review the contract
requirements to confirm their understanding and interpretation of all scope of work. A
Project Launch Meeting will be held.
· Project Team Members shall review their assigned documents and provide comments to
anything not understood or obtain clarification to any conflicts.
14

15. · Missing data, information, etc. shall be identified to the Project Manager/Software
Analyst, who will record in an “Action Log” and take the necessary action to obtain
missing information as required. Conflict between or within documents forming the
Contract will be presented in writing to KTD for resolution.
· The Project Manager will endorse the procedures and processes issued to all Project
Team Members as controlled copies.
9.3.3 Amendments
· The Software Framework and UI Design are revised as and when clarifications, further
information or changes are received.
· During the course of the Project Implementation there may be various changes to the
original scope of the contract. In case of contractual changes, the following shall apply:-
a) The proposed changes shall be reviewed jointly by SOFTWARE PRO and KTD. On
agreement of the changes, the necessary documents shall be duly endorsed and stamped
for implementation.
b) The relevant Project Team Members affected by the changes shall be formally
advised of the changes.
c) Superseded sections of the Contract shall be identified and marked as “Superseded”
and withdrawn from the office.
d) Any applying or other related documents affected by the change shall be withdrawn
from source to prevent further implementation.
e) The Project QA Manager shall review all contractual changes to establish the effect on
the PQP and Quality System. Any such effect on the Quality System shall be adjusted
accordingly.
9.3.4 Records
All such changes or amendments to the PQP shall be properly recorded. The processing of
these records shall be in strict accordance with the Project Document and Data Control
Procedure.
9.4 Inspection and Test
9.4.1 Format and Approval of Inspection and Test Plan
15

16. · The content and format of all Inspection and Test Plans shall be subject to approval by
the Project Manager.
· Where necessary, separate procedures shall be developed for special processes that are
not covered by routine procedures. These procedure shall then become part of the Project
Quality System and PQP.
· The Inspection and Test Process applied as shown in Figure 4.0D.
FIGURE 5.0D – Inspection and Test Process Flow Diagram
9.4.2 Inspection and Test
· Inspections and Tests all phases and deliverables.
· Inspections and Tests shall be performed in accordance with the Project Quality Plans,
standards and best practices.
· The relevant Inspection and test data and reports shall be compiled and submitted for all
phases and distributed accordingly.
9.4.3 Inspection, Test and Records
16

17. · Inspection, testing and records shall be established and maintained which give clear
evidence that deliverables have passed inspection and/or test in accordance with defined
acceptance criteria.
· All relevant Certificates, Inspection Reports, etc., that are generated from the inspection
and tests shall be considered as QA Records and filed accordingly.
· A non-conformance log shall be maintained by the QA Manager who shall report on the
Quality status on the Quality status to the Project Manager.
9.5 INSPECTION AND TEST COMPUTER HARDWARE
· All computer hardware used in the software development shall be kept in good working
order and maintained to the required efficiency for optimum performance.
· It is the overall responsibility of Tech Support to ensure that all computer hardware used
in the Project is maintained as required by the Project Team Members and clearly
identified as being acceptable.
· Any computer hardware that is suspected of being inefficient or non-functional shall be
withdrawn from use and brought to the attention of the Project Manager. It is therefore
essential that computer hardware are maintained.
9.6 INSPECTION AND TEST STATUS
· The QA Manager shall be responsible for monitoring the status of all Inspection and
Tests that are required to be performed throughout the different phases of the project.
The system for identifying the status of inspection and/or testing shall be by reference to
the quality records.
· The QA Manager shall develop and issue Inspection and Test check lists in the Test
Plans and shall be issued to show requirements during Inspection and Tests.
9.7 CONTROL OF NONCONFORMANCE
· The purpose of this Section is to ensure that Nonconformance of procedures and
processes are clearly and easily recognised by all concerned so that they are not
17

18. inadvertently used on the Project. It is the responsibility of the QA Manager to ensure
that the necessary controls are in place to satisfy the requirements of this Section.
· When detected, nonconformance shall be identified by immediately reporting to the
Project Manager and written in a non-conformance report.
· No further work shall be progressed on the software development until rectified by the
Project Manager
· It is the responsibility of the QA Manager to ensure that all rectified Nonconformance
are reinspected by the same method that detected the original discrepancy.
9.8 CORRECTIVE ACTION
· To ensure that all discrepancies found are processed in accordance to Control of
Nonconformance and that early resolutions are developed in order not to avoid undue
delays in the work.
· The QA Manager shall ensure that the Project Team Members have been addressed on:-
a) Necessary approvals.
b) Reinspection and acceptance.
c) Acceptance by the Project Manager.
d) A documented history of the deficiency.
9.9 QA AUDITS
· During the Contract duration, a systematic programme of Quality System Audits shall be
undertaken to determine whether Quality Activities and related results comply with the
planned arrangements, and whether said arrangements are implemented effectively and
are suitable in achieving Quality Objectives.
· The QA Manager is responsible for developing a programme of planned internal audits
to be performed to provide evidence that:
a) Project Team Members are complying with aspects of the Project Quality System
relevant to their activities.
b) The Project Quality System is adequate, practical and effective to apply.
c) Recommended corrective actions are being implemented effectively.
d) Conditions adverse to Quality are promptly identified, documented, reported to the
Project Manager and corrected to preclude repetition.
18

19. · Review of the Quality System will be performed at appropriate intervals as determined
by the Project Manager.
· Every effort shall be made to prepare for the SOFTWARE PRO Project Team for a
Client Audit. In this regard, the QA Manager shall on an on-going basis spot check
various department disciplines for conformance to the Quality Plan. Any discrepancies
found shall be brought to the attention to the Project Manager to initiate corrective
action.
10.0 LIST OF PROCEDURES AND PROCESSES
DOCUMENT NUMBER PROCEDURES / PROCESS COMMENT
R1.1 Review Software Framework
R1.2 UI Designing Procedure Procedure for core
process used to for
next PMA question.
R1.3 Using Quality Tools
R1.4 Testing and Inspection of Computer Hardware
R1.5 Using Software Development Waterfall Model
R1.6 Programming Procedure Procedure for core
process used to for
next PMA question.
R1.7 Project Planning, Tracking and Oversight
Processes
R1.8 Software Requirements Analysis Process
R1.9 UI Design Process
R1.10 Programming Process
R1.12 Project Implementation
R1.13 Inspection and Testing Process
R1.14 Evaluate Beta and Final Software
R1.15 Corrective Action Process
R1.16 Software Development Library Control
Process
R1.17 Technical Reports
R1.18 Management and Routine Reports
R1.19 Quality Audits
R1.20 Software QA
R1.21 Project Tracking
R1.22 Software Implementation and Unit Testing
Process Audit Checklist
R1.23 Testing Process Audit Checklist
Control of Non Conformance
R1.24 Document Control
R1.25 Contract Handover
19

20. R1.26 Contract Administration
R1.27 Manual Writing Procedure Procedure for core
process used to for
next PMA question.
R1.28 Project Scheduling
R1.29 Project Cost Control
R1.30 Control of Records
R1.31 Project Filing System
R1.32 Inspection and Test Plan
R1.33 Review Software Framework
6.0 PROCEDURES FOR CORE PROCESSES
In the Computer Science body of knowledge, there are 6 core processes for software
development that covers all stages of a project, from planning to implementation. The
processes repeat in multiple iterations, with the earlier iterations placing more emphasis on
the planning processes, and the later iterations leaning more heavily into the implementation
process. The 6 core processes are:
a) Identify the requirement and obtain project approval.
b) Planning and monitoring the project.
c) Design software components
d) Building, testing, and integrating components
e) Complete testing and produce software
f) Discover application details and produce instruction guide.
These core processes are comprehensive, and are meant to include everyone involved in the
project from the ground up, from the project team leader to the end users who will ultimately
be the ones utilizing the software. Each core process consists of many work instructions or
procedures throughout the software development.
For the purpose of this PMA, 3 different procedures have been prepared as part of a core
process. The relation between the procedures and core process chosen are as Figure 5.0 :
PROCEDURE CORE PROCESS
UI Designing Design software components
Programming Building, testing and integrating components.
User Manual Writing Discover application details and produce
20

21. instruction guide
Figure 6.0A – 3 Procedures and Core Process Relation
The 3 procedures are shown in the following pages:
CONTENTS
1.0 Introductuion
2.0 Prototyping
3.0 Interface-Flow Diagram
4.0 General UI Guidelines
21
SOFTWARE PRO
Document
Name:
User Interface (UI) Designing
Document Category:
Procedures
Document Number:
R1.2
Revision:
1
Revision Date:
19-04-2013
Pages:
5
KTD WARGAMING SIMULATION SOFTWARE

22. 1.0 INTRODUCTION
A layman’s benchmark of quality software is by ‘judging the book by its cover’. For most
people, the UI is the software. What users want is for developers to build software UI that
meet their needs and that are easy to use.
UI design is important for several reasons. The better the UI the easier it is to train people to
use it, reducing your training costs. The better the UI the less help people will need to use it,
reducing the support costs. The better the UI the more the users will like to use it, increasing
their satisfaction with the work that you have done.
The UI of software will often make or break it. Although the functionality that an application
provides to users is important, the way in which it provides that functionality is just as
important. It won’t matter how technically superior your software is or what functionality it
provides, if your users don’t like it they simply won’t use it. Don’t underestimate the value of
UI design.
2.0 PROTOTYPING
Prototyping is an iterative analysis technique in which users are actively involved in the
mocking-up of screens and reports. The purpose of a prototype is to show people the
possible design for the user interface of an application. As we see in the figure below there
are four steps to the prototyping process:
22

23. Figure 6.0B – Iterative Steps of Prototyping
Determine Needs - The requirements of the end-users drive the development of the
prototype as they define the objects that the system must support. It is the responsibility of
the software analyst gather the requirements and provide to UI Designer.
Build Prototype - Using a prototyping tool or high-level language to develop the screens and
needed by the end-users.
Evaluate Prototype - The beta version of the prototype needs to be evaluated. The main goal
is that you need to verify that the prototype meets the needs of the users. Three basic issues
during evaluation: a) What’s good about the prototype? b) What’s bad about the prototype? c)
What’s missing from the prototype?
Determine if Require Amendment – The steps are repeated until the UI meets the quality
standard of KTD.
23

24. 3.0 INTERFACE-FLOW DIAGRAMS
Interface-flow diagrams show the relationships between the UI components, screens and
reports, that make up the software. In the figure below is an example of an interface-flow
diagram for an order-entry system. The boxes represent user interface objects (screens,
reports, or forms) and the arrows represent the possible flow between screens. For example,
when you are on the main menu screen you can go to either the customer search screen or to
the order-entry screen. Once you are on the order-entry screen you can go to the product
search screen or to the customer order list. Interface-flow diagrams allow you to easily gain a
high-level overview of the interface for your application.
.
FIGURE 6.0C – An Interface-Flow Diagram for an Order-Entry System
24

25. 4. GENERAL UI GUIDELINES
· Be consistent in the UI design throughout the software.
· Set a UI standard and stick to them.
· User friendly for beginners
· Ensure text formatting consistently, positively and in full English.
· Navigation between of screen and on screen is important.
· Use color sparingly and always have a secondary indicator.
· Follow the contrast rule – put dark text on light backgrounds and light text on dark
backgrounds.
· When items are unavailable, gray them out, don’t remove them if you want the users
to form accurate mental models.
· Use non-destructive default buttons.
· Left justify edit fields and right justify their labels.
· Right justify integers, decimal-align floating point numbers, and left justify strings.
· Don’t create busy/crowded screens.
· Use group boxes and whitespace to group logically related items on the screen.
· Open windows in the center of the action.
· Pop-up menus shouldn’t be the only source of functionality.
Figure 6.0D – Alignment of Fields
25

26. CONTENTS
1.0 Introductuion
2.0 Coding Technique
2.1 Names
2.1.1 Routines
2.1.2 Variables
2.1.3 Tables
2.1.4 Miscellaneous
2.2 Comments
2.3 Format
26
SOFTWARE PRO
Document
Name:
Programming Procedure
Document Category:
Procedures
Document Number:
R1.6
Revision:
1
Revision Date:
19-04-2013
Pages:
9
KTD WARGAMING SIMULATION SOFTWARE

27. 1.0 INTRODUCTION
Superior coding techniques and programming practices are hallmarks of a quality program.
The bulk of programming consists of making a large number of small choices while
attempting to solve a larger set of problems. The readability of a source code has a direct
impact on how well a developer comprehends a software system. Source code maintainability
refers to how easily that software system can be changed to add new features, modify existing
features, fix bugs, or improve performance. Although readability and maintainability are the
result of many factors, one particular facet of software development upon which all
developers have an influence is programming standard.
2.0 CODING TECHNIQUES
Coding techniques incorporate many facets of software development and directly impact the
functionality of the final software. For the purpose of this document, all forms of source code
are considered, including programming, scripting, markup, and query languages. The coding
techniques defined here are not proposed to form an inflexible set of coding standards.
Rather, they are meant to serve as a guide for developing a coding standard for a specific
software project. The coding techniques are divided into three sections: a) Names.
b) Comments. c) Format.
2.1 NAMES
Perhaps one of the most influential aids to understanding the logical flow of an application is
how the various elements of the application are named. A name should tell "what" rather than
"how." By avoiding names that expose the underlying implementation, which can change,
you preserve a layer of abstraction that simplifies the complexity. For example, you could
use GetNextStudent() instead of GetNextArrayElement().
A tenet of naming is that difficulty in selecting a proper name may indicate that you need to
further analyze or define the purpose of an item. Make names long enough to be meaningful
but short enough to avoid being wordy. Programmatically, a unique name serves only to
differentiate one item from another. Expressive names function as an aid to the human reader;
27

28. therefore, it makes sense to provide a name that the human reader can comprehend. However,
be certain that the names chosen are in compliance with the applicable language's rules and
standards. Following are recommended naming techniques:
2.1.1 Routines
· Avoid elusive names that are open to subjective interpretation, such as Analyze() for a
routine, or xxK8 for a variable. Such names contribute to ambiguity more than
abstraction.
· In object-oriented languages, it is redundant to include class names in the name of class
properties, such as Book.BookTitle. Instead, use Book.Title.
· Use the verb-noun method for naming routines that perform some operation on a given
object, such as CalculateInvoiceTotal().
· In languages that permit function overloading, all overloads should perform a similar
function. For those languages that do not permit function overloading, establish a
naming standard that relates similar functions.
2.1.2 Variables
· Append computation qualifiers (Avg, Sum, Min, Max, Index) to the end of a variable
name where appropriate.
· Use customary opposite pairs in variable names, such as min/max, begin/end, and
open/close.
· Since most names are constructed by concatenating several words together, use mixed-case
formatting to simplify reading them. In addition, to help distinguish between
variables and routines, use Pascal casing (CalculateInvoiceTotal) for routine names where
the first letter of each word is capitalized. For variable names, use camel casing
(documentFormatType) where the first letter of each word except the first is capitalized.
28

29. · Boolean variable names contain Is which implies Yes/No or True/False values, such
as fileIsFound.
· Avoid using terms such as Flag when naming status variables, which differ from
Boolean variables in that they may have more than two possible values. Instead
of documentFlag, use a more descriptive name such as documentFormatType.
· Even for a short-lived variable that may appear in only a few lines of code, still use a
meaningful name. Use single-letter variable names, such as i, or j, for short-loop
indexes only.
· If using Charles Simonyi's Hungarian Naming Convention, or some derivative thereof,
develop a list of standard prefixes for the project to help developers consistently name
variables.
· For variable names, it is sometimes useful to include notation that indicates the scope of
the variable, such as prefixing a g_ for global variables and m_ for module-level
variables.
· Constants should be all uppercase with underscores between words, such
as NUM_DAYS_IN_WEEK. Also, begin groups of enumerated types with a common prefix,
such as FONT_ARIAL and FONT_ROMAN.
2.1.3 Tables
· When naming tables, express the name in the singular form. For example,
use Employee instead of Employees.
· When naming columns of tables, do not repeat the table name; for example, avoid
having a field called EmployeeLastName in a table called Employee.
· Do not incorporate the data type in the name of a column. This will reduce the amount of
work needed should it become necessary to change the data type later.
29

30. 2.1.4 Miscellaneous
· Minimize the use of abbreviations. If abbreviations are used, be consistent in their use.
An abbreviation should have only one meaning and likewise, each abbreviated word
should have only one abbreviation. For example, if using min to abbreviate minimum, do
so everywhere and do not later use it to abbreviate minute.
· When naming functions, include a description of the value being returned, such
as GetCurrentWindowName().
· File and folder names, like procedure names, should accurately describe what purpose
they serve.
· Avoid reusing names for different elements, such as a routine
called ProcessSales() and a variable called iProcessSales.
· Avoid homonyms when naming elements to prevent confusion during code reviews,
such as write and right.
· When naming elements, avoid using commonly misspelled words. Also, be aware of
differences that exist between American and British English, such as color/colour and
check/cheque.
· Avoid using typographical marks to identify data types, such as $ for strings or % for
integers.
2.2 COMMENTS
Software documentation exists in two forms, external and internal. External documentation is
maintained outside of the source code, such as specifications, help files, and design
documents. Internal documentation is composed of comments that developers write within
the source code at development time. One of the challenges of software documentation is
ensuring that the comments are maintained and updated in parallel with the source code.
Although properly commenting source code serves no purpose at run time, it is invaluable to
a developer who must maintain a particularly intricate or cumbersome piece of software.
Following are recommended commenting techniques:
· When modifying code, always keep the commenting around it up to date.
30

31. · At the beginning of every routine, it is helpful to provide standard, boilerplate
comments, indicating the routine's purpose, assumptions, and limitations. A boilerplate
comment should be a brief introduction to understand why the routine exists and what it
can do.
· Avoid adding comments at the end of a line of code; end-line comments make code
more difficult to read. However, end-line comments are appropriate when annotating
variable declarations. In this case, align all end-line comments at a common tab stop.
· Avoid using clutter comments, such as an entire line of asterisks. Instead, use white
space to separate comments from code.
· Avoid surrounding a block comment with a typographical frame. It may look attractive,
but it is difficult to maintain.
· Prior to deployment, remove all temporary or extraneous comments to avoid confusion
during future maintenance work.
· If you need comments to explain a complex section of code, examine the code to
determine if you should rewrite it. If at all possible, do not document bad code—rewrite
it. Although performance should not typically be sacrificed to make the code simpler for
human consumption, a balance must be maintained between performance and
maintainability.
· Use complete sentences when writing comments. Comments should clarify the code, not
add ambiguity.
· Comment as you code, because most likely there won't be time to do it later. Also,
should you get a chance to revisit code you've written, that which is obvious today
probably won't be obvious six weeks from now.
· Avoid the use of superfluous or inappropriate comments, such as humorous sidebar
remarks.
· Use comments to explain the intent of the code. They should not serve as inline
translations of the code.
· Comment anything that is not readily obvious in the code.
31

32. · To prevent recurring problems, always use comments on bug fixes and work-around
code, especially in a team environment.
· Use comments on code that consists of loops and logic branches. These are key areas
that will assist the reader when reading source code.
· Separate comments from comment delimiters with white space. Doing so will make
comments stand out and easier to locate when viewed without color clues.
· Throughout the application, construct comments using a uniform style, with consistent
punctuation and structure.
· Despite the availability of external documentation, source code listings should be able to
stand on their own because hard-copy documentation can be misplaced.
· External documentation should consist of specifications, design documents, change
requests, bug history, and the coding standard that was used.
2.3 FORMAT
Formatting makes the logical organization of the code stand out. Taking the time to ensure
that the source code is formatted in a consistent, logical manner is helpful to yourself and to
other developers who must decipher the source code. Following are recommended formatting
techniques:
· Establish a standard size for an indent, such as four spaces, and use it consistently. Align
sections of code using the prescribed indentation.
· Use a monospace font when publishing hard-copy versions of the source code.
· Except for constants, which are best expressed in all uppercase characters with
underscores, use mixed case instead of underscores to make names easier to read.
· Align open and close braces vertically where brace pairs align, such as:
32

33. · You can also use a slanting style, where open braces appear at the end of the line and
close braces appear at the beginning of the line, such as:
· Whichever style is chosen, use that style throughout the source code.
· Indent code along the lines of logical construction. Without indenting, code becomes
difficult to follow, such as:
Indenting the code yields easier-to-read code, such as:
33

34. · Establish a maximum line length for comments and code to avoid having to scroll the
source code window and to allow for clean hard-copy presentation.
· Use spaces before and after most operators when doing so does not alter the intent of the
code. For example, an exception is the pointer notation used in C++.
· Put a space after each comma in comma-delimited lists, such as array values and
arguments, when doing so does not alter the intent of the code. For example, an
exception is an Data Object (ADO) Connection argument.
· Use white space to provide organizational clues to source code. Doing so creates
"paragraphs" of code, which aid the reader in comprehending the logical segmenting of
the software.
· When a line is broken across several lines, make it obvious that the line is incomplete
without the following line.
· Where appropriate, avoid placing more than one statement per line. An exception is a
loop in C and C++ such as for (i = 0; i < 100; i++).
· When writing HTML, establish a standard format for tags and attributes, such as using
all uppercase for tags and all lowercase for attributes. As an alternative, adhere to the
XHTML specification to ensure all HTML documents are valid. Although there are file
size trade-offs to consider when creating Web pages, use quoted attribute values and
closing tags to ease maintainability.
· When writing SQL statements, use all uppercase for keywords and mixed case for
database elements, such as tables, columns, and views.
· Divide source code logically between physical files.
· In ASP, use script delimiters around blocks of script rather than around each line of
script or interspersing small HTML fragments with server-side scripting. Using script
delimiters around each line or interspersing HTML fragments with server-side scripting
increases the frequency of context switching on the server side, which hampers
performance and degrades code readability.
· Put each major SQL clause on a separate line so statements are easier to read and edit,
for example:
34

35. · Do not use literal numbers or literal strings, such as For i = 1 To 7. Instead, use named
constants, such as For i = 1 To NUM_DAYS_IN_WEEK, for ease of maintenance and
understanding.
· Break large, complex sections of code into smaller, comprehensible modules.
1.0 INTRODUCTION
User manuals are written to explain how a product is used. Softwares typically come with
user manuals. A user manual is a formal writing piece with a specific structure. User manuals
are written by Software Analyst.
2.0 STEPS
35
SOFTWARE PRO
Document
Name:
Manual Writing Procedure
Document Category:
Procedures
Document Number:
R1.27
Revision:
1
Revision Date:
19-04-2013
Pages:
2
KTD WARGAMING SIMULATION SOFTWARE

36. The following are the steps to write a user manual.
· FULLY UNDERSTAND THE SOFTWARE - Before you can explain how to use
your product to others, you must completely understand and know the product.
· KNOW THE PURPOSE FOR THE MANUAL – User manuals are typically written
for several reasons: to instruct the user on how to use the software, to market or improve
SOFTWARE PRO image.
· DO AN AUDIENCE ANALYSIS – The user manual should be written to the end
user who will be reading the manual. An audience analysis will tell you who your main
or target audience will be and will guide your writing. You can never please your entire
audience: write the manual to suit the target or largest audience.
· ORGANIZE THE MANUAL LOGICALLY – The user manual should follow the
steps of how the software should be used. Split the manual into chapters or sections that
make sense for the product’s use.
· INCLUDE ALL NECESSARY PARTS – User manuals can be made of numerous
parts including a front cover, table of contents, list of figure or tables, introduction,
chapters or sections that make sense for the product’s use.
 A table of contents is needed for longer manuals.
 A glossary or index is needed when there are many terms to explain that your
audience may not be familiar with.
 A list if tables or figure is only necessary if there are more than a few tables or figures
in the manual.
 An appendix is needed for things that should be explained but cannot be explained at
another point in the manual because it would disturb the flow and focus.
 Include visual aides in the manual to assist visual learners.
· SPEAK TO THE USER IN EASILY UNDERSTANDABLE TERMS – Technical terms
can be intimidating and misunderstood. Use words and terms users will understand.
Make a glossary of any technical terms or words used in the manual.
36

37. · PROOFREAD THE MANUAL – A manual can lose credibility due to grammar and
spelling mistakes. Have a coworker or friend proofread the manual as well.
· GET THE MANUAL APPROVED – The manual will be approved by the Project
Manager.
REFERENCE
1. Hj. Ir. Mohd Hanaffi Bin Ayob. Lecture Notes. 2013
2. Prof. Ir. Dr. Sha’ri. Lecture Notes. 2013
3. Goetsch D. Implementing TQM. Pearson/Prentice Hall. 1995
4. Goetsch D.
5. Gitlow H.
37

38. 6. Juran. Quality Control Handbook. 5th edition. Mcgraw Hill. 1999.
7. Tari J. Components of Successful Total Quality Management. TQM Magazine. Vol 17
Issue 2. 20015
8. Nguyen F. Using Total Quality Management. Scopus Articlebase. 2008.
9. Pomoni C. The Basics of Total Quality Management. Web of Science. 2010.
10. Saha A. Introduction and an Overview of Implementing Total Quality Management.
University of New York. Feb 2008.
38