m The Software Quality Assurance Plan shall

include the sections listed below to be in

compliance with this standard.

1. Purpose
2. Reference Documents
3. Management
4. Documentation
5. Standards, practices, conventions and
metrics
6. Reviews and audits
7. Test
. Problem reporting and corrective action
9. Tools, techniques and methodologies
10. Code control
11. Media control
12. Supplier control
13. Records collection, maintenance and
retention
14. Training
15. Risk Management
m The Goal of this project is turn any display
surface into touch sensitive display with the
help of gesture analyzing software library,
which was to work as an intermediate layer
between the screen and the applications
projected on it. The application will receive
the gesture data as input, along with the
information on which objects are affected.
m þe get help from these documents

m Project Proposal
m Project Plan
m Software Requirement Specifications
i
 
  i
   


i
 
    

   
   
     
    

 

 


i 

 
    

   
  
     
    &

    !" 
 
%
     !
""
# $
 


"  !


 
i ' 

   

 "


  (
m a

Mentioned in Reviews and audits below.
m i
  
 



1. Software Requirement Specification(SRS)
2. Software Design Description(SDD)
3. Software Verification and validation plan(SVVP)
4. Software Verification and validation plan
Review(SVVPR)
5. User Documentation
6. Software Configuration Management Plan
m Ät comprises of these 4 steps

1. Documentation Standards
2. Coding Standards
3. Metrics
4. Testing Standards
The standards governing this project are:
mÄ Standard for Software Test
Documentation (Ä Std 29-199)
mÄ Standard for Software Quality
Assurance Plans (Ä Std 730-199)
m þe will be developing the application in
Microsoft Visual Studio.N T 200 using C#
and we shall use external open source
libraries ex : Touchlib
 The following metrics will be recorded as
part of this project:
m Source lines of code produced by the
project
m Time spent during the project
m Calculate lines of code per detect
m Test input for plausibility and validity.
m Stress the software·s capability.
m Än unit testing, make sure every path of execution in
code has been thoroughly tested. This step should
be taken at the completion of a module.
m Än the integration testing, check that the modules
function as a whole, achieving a product that
satisfies the specification.
m Next is the system testing phase by the SQA group
where the test procedure is run along with ad hoc
testing. This phase should be performed after the
completion of each integration phase and at the
final completion of the product but before
deliverance to the customer.
m a

1. The audits will be performed by our supervisor of
the inception and the elaboration phase and if
he marks it correct then we will move further to
other phases
2. the leader will be responsible for maintaining the
project overall performance and will be
allocating the task/work according to his/her
expertise
3. we will try to manage our project more
effectively so that every members contributes
equally and feel motivated
m i
 


As a minimum, the reviews and the audits in 1.4.2.1
through 1.4.2.10 shall be conducted
1. System Requirements Review
2. Preliminary Design Review
3. Critical Design Review
4. Software Verification and Validation Plan Review
5. Functional audit
6. Physical audit
7. Än Process audit
. Managerial Review
9. Software configuration Management plan review
10. Post mortem review
m A System Requirements Review is one of a
number of such reviews conducted
periodically during Conceptual Design to
verify and approve sets of system-level
requirements as they are developed.
m The main purpose of SRR is to ensure that
the design is progressing in the correct
direction.
m During this we will review our risk
management plan, early designs and
preliminary designs so that we could
evaluate it and make things correct if
there anything wrong.
m Moreover we will also estimate the cost
and time required in the completion of
all these things
m At this design level we have reviewed or all
major documentation and plans.
m The Critical Design Review is one of the
major systems engineering reviews
conducted towards the end of Detailed
Design & Development and series of
Product Specifications are extracted from
this design from which the system is to be
developed or procured
m þe have started SVVPR in early phases
of the project life cycle.
m Both aspects are necessary as a system
meeting its specifications.
m The results of SVVPR forms an important
component in the safety case, which is a
document, used to support certification
m The objective of a functional audit is to
provide an independent evaluation of
software products, verifying that our
configuration items actual functionality and
performance is consistent with the
requirement specifications.
m Specifically this audit is held prior to the
software delivery to verify that all
requirements specified in the Software
Requirements Specification have been met
m This audit is a type of configuration
management audit.
m The objective of a physical audit is to
provide an independent evaluation of a
software product configuration item to
confirm that components in the built
version map to their specifications.
m The audit verifies that our software
performs all the functions described in
our design documentation and is ready
for delivery
m þe are effectively able to manage this
process auditing by planning controlling,
maintaining and organizing our resource
and activities in a way that the outcome
has achieved the objective of our
project.
m This basically concern with the reviewing
of the project documentation which is
done by our whole team which has
helped us to reshape material to fit our
objective.

m Thus this has helped us in establishing

and making documentation, report,
proposal and moreover scheduling our
presentation
m This design basically reflects the
functional completeness of the software
items against their requirements and the
physical completeness of the software
item.

m Uptil now we have fortunately managed

to achieve both of the aspects
m þe have conducted the post mortem
review and encountered both success
and failure of the project. Thus it helped
us in turning the failure to success
m þe have been continuously and regularly
analyzing our documentation; moreover
continuously it·s been reviewed and
analyzed by a supervisor.

m The information provided by the PRACA

allows area of possible needs of
improvement to be highlighted to
engineering for the development of the
corrective action
m
m The software quality assurance (SQA) plan is
an outline to measures quality levels within a
software development effort.
m These SQA help to ensure the quality of a
software project.
m An SQA plan also provides the procedures for
ensuring that quality software will be
produced or maintained in-house or under
contract.
m The SQA procedures have affect on
planning, designing, writing, documenting,
storing, and maintaining computer software.
m A configuration management system
(either Clear case or Subversion) will be
used to control the source code artifacts
produced as part of the project.

m Document revisions will be maintained in

a share point repository, with release
versions of documents made available
individually on the project website.
m þe are currently storing and saving our
documentation in our PC·s, laptops and USB·s.
Moreover we are continuously uploading our
document/file at box.net. Further we have got
the several hard copy of our documentation,
one of which is also kept by our advisor.

m As we are in just two initial phases so believe

that our documentation is secured and can·t
be manipulated. Moreover only authorized and
registered user can access box.net, therefore
there is no chance of manipulation and as well
as plagiarism.
m Minutes of meetings and notes of reviews
are added to the project library.
m Minutes of meetings are added after the
members of the meeting have 270
approved them. These records will be kept
throughout the duration of the project.
m After meetings, the SQA team ensures that
a date is set on which minutes of that
meeting are available.
m Notes of reviews are reworked into a new
version of the document.
m Än the course of the project, various skills might
suddenly be required from the Multi Touch Gesture
Recognition (MTGR) team. þhen this happens, PM
and QM together assess how many group
members already possess this skill.
m Actions are undertaken according to the following
list. Äf the number of group members that possess
the skill is
1. Low
2. Medium
3. High
m The SQA team must check whether the
goals of the project are clearly described. A
life cycle approach for the project must be
defined. The SQA team must ensure that the
Software Project Management Plan (SPMP)
is realistic by checking
m The assumptions made during the planning
of the project.
m Restrictions with respect to plan (e.g.
availability of members).
m xternal problems (e.g. delivery of PCs,
interface card and drivers).
Thank You