Quality Assurance Plan

colonteeSoftware and s/w Development

Nov 4, 2013 (3 years and 7 months ago)

80 views



Team Stochastic

Central Washington University

Quality Assurance Plan

Project Name:

Cluster Sampling Tail Estimation Probability (CSTEP)

Editor:

Alan Chandler

Authors:

Alan Chandler

Eric Brown

Nathan Wood

Temourshah Ahmady

Faculty Advisor:

Dr. James
Schwing

Client:

Dr. Yvonne Chueh

Due Date:

12/08
/10



Contents

1.

Introduction

................................
................................
................................
.......................
1

Quality Assurance Plan Role

................................
................................
................................
...............
1

Purpose

1

Scope

1

Intended Audience

................................
................................
................................
.............................
2

Preview

2

2.

Document Standards

................................
................................
................................
...........
3

General Format:

................................
................................
................................
................................
.
3

Specifics:

3

3.

Coding Standards

................................
................................
................................
................
4

C#

4

C++

6

Lua

7

4.

User Interface Guidelines

................................
................................
................................
....
8

UI Standards

................................
................................
................................
................................
......
8

Computer Skill of the Intended Audiences

................................
................................
..........................
8

5.

Change Control Process

................................
................................
................................
.......
9

6.

Testing Process

................................
................................
................................
.................

10

Appendices

................................
................................
................................
................................
......

11

Appendix I

................................
................................
................................
................................
.......

11

Appendix II

................................
................................
................................
................................
......

12

Section Header

................................
................................
................................
................................

12

Heading 1

................................
................................
................................
................................
........

12

Heading 2

................................
................................
................................
................................
................

12

Appendix III

................................
................................
................................
................................
.....

13


1


1.

Introduction

Evaluating the adequacy

of reserves is a critical problem for many businesses and insurance companies.
Valuation actuaries need to calculate the probability distribution of relevant financial random outcomes
to solve these problems. Recently Dr. Yvonne Chueh developed a … cluste
r sampling technique for
probability tail estimation. Currently, actuaries implement these techniques in a spreadsheet that limits
the size and speed of the calculations, perhaps by as much as several orders of magnitude for both. This
research system will

be desktop
-
based application made from a combination of C++, Lua, and C#.

The main goal of this project is to provide the actuaries with a more efficient tool. That in turn will
provide stochastic models that are more accurate and reliable. We will call t
he tool Cluster Sampling for
Tail Estimation Probability (CSTEP). It will allow statisticians, both actuaries and academicians to
estimate and analyze the probability of a large block of business in a short amount of time. The output
of this program, which

will be cluster samples for tail estimation of probability, helps the valuation
actuaries to analyze and guide decisions on economic values for various lines of business.

Quality Assurance Plan Role

The Software Quality Assurance Plan plays a significant

role in overall effectiveness and efficiency of the
development of a system. It defines the activities performed to provide assurance that the software
-
related items delivered to the client conform to the established and contracted technical requirements.

In the Software Quality Assurance Plan, we describe the audit process to ensure that we follow the
policies, standards, practices, procedures, and processes applicable to the project.

Purpose

The main purpose of this Quality Assurance Plan is to establish

and document the procedures that we
will follow to ensure that CSTEP system conforms to design objectives, specifications, and technical
requirements and our team correctly perform these designated procedures. Furthermore, maintaining
communication to all

parties and insuring the quality objectives for the project is also one of the
purposes of this quality assurance plan.

Scope

We have tailored the Software Quality Assurance process to our software development effort. We have
also related to the project p
lanning and lifecycle description documents for the CSTEP. CSTEP is a
desktop standalone application. Generally, it will go through three phases to perform its task. It first will
have a graphical user interface that interacts with the user to get preferen
ces for the interest rate path,
size of the sample scenarios, and the distance formula choices built
-
in the system. Secondly, the system
will read stochastically generated scenarios in vector form from a spreadsheet. Finally, CSTEP will
estimate the tail p
robability as cluster samples based on a user selected distance formula, and it will
output the required run
-
time for the distance sampling process, list of sample scenarios, and the
probability of sample scenarios.

2


Intended Audience

The intended audience
s of the project are our team, the client, and those who work as valuation
actuaries evaluating the adequacy of reserves of insurance companies and researches in this area.

Client: Dr Yvonne C. M. Chueh is our client. She is an Associate Professor in the M
athematics
Department at Central Washington University.

End Users: All statisticians and actuarial experts who judge and evaluate a company’s financial strength
can benefit from this application as it relates to projecting insurance financials on a stochas
tic interest
rate.

Researchers: Researchers who are doing academic and industrial studies on actuarial sciences can also
use our project.

Preview

We split the remainder of the document into the following sections
:

Document Standard



This section describes

the standards and procedures that our team agreed on to
ensure consistent, correct, and timely preparation of project documentations.

Coding Standards



This section identifies the standards and procedures that our team decided to
follow for ensuring
consistent, correct, and useful code comments and other internal documentations of
the project.

User Interface Guidelines



This is a detailed section about the
user interface guidelines that our team
developed for assuring a consistent, easy
-
to
-
use user i
nterface.

C
hange Control Process



This is a detailed section about the process that our team will use to control
changes in designing and developing process of our project. The process that our our team decided to
use against creeping requirements and to

sure that all team members are advised of all changes is also
described in this section.

Testing Process



This section explores the process and procedures that our team has agreed up on to
use in testing the system.

Appendices



This section describes t
he forms that we as a team have developed for quality assurance
of our project.



3


2.

Document Standards

To build an efficient and successful project we need a constant way to create and maintain our
documents. This section will provide a layout of how we will

maintain our documents in order to ensure
the document conveys the information in a clear and concise manner. The first section will layout the
general format in which we begin our documents, and then will continue to describe more specifics on
the docume
nts. Our initial process is breaking up the documents into smaller sections that we match to
each team member based on their role. Matching each team member to a section makes sure that the
person who understands that section the best is writing that secti
on. Doing this also lessens the chances
of arguing between group members on which section they are doing. After we breakdown each section
into sections we create a rough draft, and then implement the standards that we have agreed upon as a
team.

General Fo
rmat:

The general format we use to create and maintain our documents are from a template that we have
created as a team
1
. Using this template makes sure we have a constant format to follow as we develop
the different documents throughout CS 480/481. Each g
roup member uses this template and saves the
document as DocumentName_TeamStochastic(TeamMembersName) so we can tell who created what.
Once the team has all finished their respective parts, the editor for this specific document will gather
each part of the

document and put them together in a rough draft. We then place this on xp
-
dev.com
for version control through their servers. Using version control makes sure that we integrate each
version of the document accurately, and without overwriting work done by a
nother team member.
Finally, the editor for the paper follows up on the rough draft by proofreading it, then giving it back to
each member to revise for spelling, grammar and proper English before the final copy.

Specifics:

Using templates for both the doc
uments and the headings within these documents ensures a clear
format for our document to follow. The template we created is a customization of the template
provided to us by Dr. Gellenbeck at the beginning of the quarter
2
. We then modified further by crea
ting
a section header to differentiate between different sections within our documents. These two features
together make our documents look clean, and give the document a good flow. Within this, we have also
added a constant text size and font to keep the
project uniform throughout the document. The section
headers are Cambria size 14 font, and the body paragraphs are Calibri size 11 font. We have chosen
these because they are professional, and easy to read.






1

See Appendix I

2

See Appendix II

4


3.

Coding Standards

Coding standards are required

to ensure consistent styling, formatting, and use of code, making it easier
to read and understand. They define the layouts and conventions of code structures and statements,
i.e., variable definitions, “if
-
then” statements, etc. Because this project invo
lves three different
programming languages, we have a coding standard for each.

C#

We will use the C# coding standards documented in
C# Coding Style Guide

by Mike Kruger, found at
http://www.icsharpcode.net/TechNotes/SharpDevelopCodingStyle03.pdf
. Here are

a few additions to
the style guide we will use.

4.4 Comment Content Formatting

When writing comments, capitalize the first word of each comment, and use a space before the first
word of each line. For single line comments, do not end with a period. This p
romotes readability.

Format like so:

// This is a good comment


Not

like this
:

//this is a badly formatted comment.

Also, when referring to type names, variable names, or class names, place quotes around them to
indicate it is a name.

// This is a comment
referencing variable “text,” not text


4.5 Ending a Block

Place a comment at the end of each block to indicate which block it is ending. Use the name or keyword
used to begin the block, and if the block is a conditional structure, indicate whether it is ne
sted within
the another structure of the same type or not. Don’t place a comment if something else is on the same
line as the end bracket or if the block is for a property.

public void DoSomething(int hmm, double huh) {


if (test) {


if (exam) {


if (midterm) {


// Do something


} // nested nested if


} // nested if



if (finalExam) {


// Do something


} else {


// Do something else


} // nested else



fo
r (int i = 0; i < hmm; i++) {

5



// Loop something


} // for


} // if

} // void DoSomething(int, double)


5.4 Property Declarations

Unless the code for the get and set definitions within a property deviate from the norm, place the get
and set definitions on one line each.

public bool Test {


get { return test; }


set { test = value; }

}


public bool Exam {


get {


return !exam;


}


set {


test = !value;


}

}


5.5 More on Variable Declarations

Never declar
e a variable with the same name as a class. This way the property for the field will be
unique.

Do not use:
Test test; // Since the property would be “Test”

Instead use:
Test testCase;

When declaring two or more variables of the same type, declare the type

and the first variable name
and then place each subsequent variable name on a new line, separating the list with commas. Do not
forget to indent subsequent names to the same position as the first name, and still initialize variables if
possible. It is uni
form to place initialized variables or fields at the top of the list, but this is not
imperative.


double first = 1.5,



second = 2,



last;

Also variables in order of increasing bit size of their type. Objects come last in the list. The order

of
object declarations can be arbitrary, but attempt to form a convention to promote uniformity.

bool miniscule,


nanoscopic;

byte little;

int medium = 10,


average;

float large;

double larger = 2.5;

6


long largest;

TestClass tester;


9.3 #region an
d #endregion

Use “#region
RegionName
” and “#endregion” so that similar portions of code within a class can collapse
easily. If there are more than 10 fields, define a “Fields” region. Always define a “Properties” region,
even if there is only one. If there

is more than one method, define a “Methods” region.


The following example code shows blocking and class structure.

namespace BracketExample

{


/// <summary>


/// This class...


/// </summary>


public class TestClass


{


bool test;

// “test” is a bird



#region Properties


public bool Test {


get { return test; }


set { test = value; }


}


#end Properties



/// <summary>


/// This method...


/// </summary>


void DoSomething()


{


if (test) {


// Do something


} else {


// Do something else


} // else


} // void DoSomething()


} // class TestClass

} // namespace BracketExam
ple


C++

All the C# coding standards defined above apply to C++ code except for properties. Because C++ does
not have properties, we will use accessor methods that appear similar to properties.

private:


bool test;


7


public:


// Property Test


bool

Test() { return test; }


void Test(bool value) { test = value; }


Lua

Because Lua is a small part of the project, we will simply use the coding standards defined by Lua users.
We found the Lua Style Guide at
http://lua
-
users.org/wiki/LuaStyle
Guide
. Here are a couple examples of
Lua code.


for i,v in ipairs(t) do




if type(v) == "string" then



print(v)



end


end



local

v
do



local

x = u2*v3
-
u3*v2



local

y = u3*v1
-
u1*v3



local

z = u1*v2
-
u2*v1



v = {x,y,z}


end



local

count
do



x = 0



count =
function
() x = x + 1;
return

x
end


end



8


4.

User Interface Guidelines

When users interact with a computer system, they do so via a user interface. Thus
,

user interface is the
prima
ry component of a software system

that

represents

how
usable and effective

a

software

system

is
.

This section explores the user interface guidelines that our team developed for assuring a consistent,
easy
-
to
-
use, and easy to understand, that meet the needs of the intended users, and that suppo
rt users
in the tasks they wish to undertake.

U
I
Standards

Our team has agreed up on enforcing the standard of
user
-
centered design for our
project user
interface. User
-
centered design is an approach to user interface design and development that involves
u
sers throughout the design and development process. User
-
centered design not only focuses on
understanding the users of a computer system under development but also requires and understanding
of the tasks that users will perform with the system and of the
environment in which they will use the
system.

In order to enforce this standard professionally, our team will make sure that the principle of
simplicity,
structure,
consistency
, and tolerance

is highly respected in developing and designing the user
interf
ace of our project.

Computer Skill of the Intended Audiences

Our intended audience

is

mostly experts and statisticians who
work as va
luation actuaries. Their
computer knowledge and experience is not so high. They only have a basic understanding of
Microsoft
Office software. Since our product’s users are not computer experts
, and
their knowledge of computer is
basic,
we

chose to enforce the standard of user
-
centered design.
By applying this standard, our product
user interface will be:



Very simple to

use. The user should be able to communicate with the system clearly and simply.



Organized in a meaningful and useful way. Features that users think of as related should appear
together on the user interface, or at least they should be clearly and closely
associated.



Consistent
that emphasizes the importance of uniformity in appearance, placement, and
behavior within the user interface to make our system easy to learn and remember.



Tolerant to prevent users from making errors. We will have a strong
error
-
ha
ndling

component
built
-
in our system that will keep the system as tolerant as possible.


9


5.

Change Control Process

The most important area of change to consider is the possibility of change in requirements, especially
once development on the final program has

begun. Although we have used paper prototypes and high
-
definition prototypes to ensure that the program is as the client desires, some changes are inevitable. To
deal with this, we intend to decouple and abstract different parts of the program so making c
hanges to
one component does not affect others. We also intend to make maximum use of metadata, as this
makes changes even simpler. For example, we intend to use the scripting language Lua to simplify
modifying the basic equations used by the program.

To g
uard against the possibility of feature creep, we intend to produce a concise requirements
document that includes all the features that will be in the final program. This document will also include
all requirements that would be good if they were in the fi
nal program if we had time to add them.
Including optional requirements in the initial specification should reduce the temptation to add extra
features, as there will always be a pre
-
planned component to work on. We will keep all team members
up to date vi
a requirements documents posted and updated on Subversion, and at regular meetings.



10


6.

Testing Process

For the purposes of our project, there are two major components that need testing: the UI
,

written in
C#, and the algorithm engine
,

written in C++. Each w
ill require a slightly different approach for testing.

For C# unit testing, we will use Visual Studio’s built in tools to test each method. All classes will be
required to have a testing fixture. We can perform integration testing in the same way. We must
test
some parts manually, as UIs are difficult to fully test automatically.

The C++ component requires a different approach. We intend to use C++ testing framework Google Test
to create unit tests, and integration tests for this component. Additionally, we

will run tests with known
input and output data into the finished engine to ensure that it works correctly. Finally, we will use a
utility to feed it bad data to automatically test if it crashes.

We will need to perform system testing manually, using main
ly black box methods. This is because the
main likely issues that could appear at this level are UI related. We can create automated tests to ensure
that it is communicating with the algorithm engine correctly, however. We can also have the client use
the
program prior to its completion to validate that the program meets her expectations. This will make
it much easier to fix issues before they come up in acceptance testing.

We will perform acceptance testing near the end of development, however we will be s
ure to allocate
enough time incase changes are required. We will schedule an extended meeting with the client where
we will have a representative test computer available with the software installed.




Appendices

Appendix I

Team Stochastic

Central Washington University

Document Name

Project Name:

Cluster Sampling Tail Estimation Probability (CSTEP)




Editor:


Authors:

Alan Chandler

Eric Brown

Nathan Wood

Temourshah Ahmady

Faculty Advisor:

Dr. James Schwing

Client:

Dr. Yvonne Chueh

Due Date:

MM/DD/YYYY



Appendix II

Section Header

Heading 1

Heading 2





Appendix III