6 pma salehuddin - pqp & 3 core process procedures

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

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

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

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

CONTENTS

1.0 Introduction 2.0 Quality Objective3.0 Quality Planning4.0 Key Project Deliverables5.0 Organisation & Responsibilities

5.1 Project Manager5.2 Office Manager5.3 QA Manager5.4 Software Analyst5.5 UI Designer5.6 Programmer5.7 Tech Support

6.0 Quality System 7.0 Quality Standards 8.0 Quality Tools9.0 Quality Control and Quality Assurance Activities

9.1 Document and Data Control9.2 Quality Records9.3 Quality Activities

9.3.1 Contract Review9.3.2 Post Review9.3.3 Amendments9.3.4 Records

9.4 Inspection and Test9.4.1 Inspection and Test Plan9.4.2 Inspection and Test9.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 PRODocument

Name:

Project Quality Plan

Document Category:

Plan

Document Number:

R1

Revision:

1

Revision Date:

19-04-2013

Pages:

15KTD WARGAMING SIMULATION SOFTWARE

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

4.0 KEY PROJECT DELIVERABLES

NUM TASK DELIVERABLE DUE DATE1. Requirement

Specificationa) 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

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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

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

• 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 COMMENTR1.1 Review Software FrameworkR1.2 UI Designing Procedure Procedure for core

process used to for next PMA question.

R1.3 Using Quality ToolsR1.4 Testing and Inspection of Computer HardwareR1.5 Using Software Development Waterfall ModelR1.6 Programming Procedure Procedure for core


R1.7 Project Planning, Tracking and Oversight Processes

R1.8 Software Requirements Analysis ProcessR1.9 UI Design Process

R1.10 Programming ProcessR1.12 Project Implementation R1.13 Inspection and Testing ProcessR1.14 Evaluate Beta and Final Software R1.15 Corrective Action ProcessR1.16 Software Development Library Control

ProcessR1.17 Technical ReportsR1.18 Management and Routine ReportsR1.19 Quality AuditsR1.20 Software QAR1.21 Project TrackingR1.22 Software Implementation and Unit Testing

Process Audit ChecklistR1.23 Testing Process Audit Checklist

Control of Non ConformanceR1.24 Document ControlR1.25 Contract Handover

19

R1.26 Contract AdministrationR1.27 Manual Writing Procedure Procedure for core


R1.28 Project SchedulingR1.29 Project Cost ControlR1.30 Control of RecordsR1.31 Project Filing SystemR1.32 Inspection and Test PlanR1.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 PROCESSUI Designing Design software componentsProgramming Building, testing and integrating components.

User Manual Writing Discover application details and produce

20

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


Name:

User Interface (UI) Designing

Document Category:

Procedures

Document Number:

R1.2

Revision:

1

Revision Date:

19-04-2013

Pages:


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

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

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

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

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


Name:

Programming Procedure

Document Category:

Procedures

Document Number:

R1.6

Revision:

1

Revision Date:

19-04-2013

Pages:


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

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

• 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

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

• 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

• 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

• 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

• 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

• 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


Name:

Manual Writing Procedure

Document Category:

Procedures

Document Number:

R1.27

Revision:

1

Revision Date:

19-04-2013

Pages:


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

• 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

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

6 pma salehuddin - pqp & 3 core process procedures

Education