Team Stochastic
Central Washington University
Software Project 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:
11/09/10
Table of Contents
1
Introduction .......................................................................................................................3
1.1
Vision Statement ........................................................................................................................... 3
1.2
Real World Problem ...................................................................................................................... 3
1.3
Project Stakeholders ..................................................................................................................... 3
1.4
Project Scope ................................................................................................................................ 3
1.5
Document Preview........................................................................................................................ 4
2
Process Model and Team Organization ................................................................................5
2.1
Software Process Model ............................................................................................................... 5
2.2
Team Organization ........................................................................................................................ 5
2.3
Team Roles and Duties.................................................................................................................. 5
3
Risk Management ...............................................................................................................7
3.1
Risk Table ...................................................................................................................................... 7
3.2
Risk Analysis and Solution Strategies ............................................................................................ 7
4
Hardware and Software Requirements ................................................................................9
4.1
Hardware Requirements ............................................................................................................... 9
4.2
Software Requirements ................................................................................................................ 9
5
Work Breakdown Structure ............................................................................................... 10
5.1
Introduction ................................................................................................................................ 10
5.2
Activity Breakdown ..................................................................................................................... 10
6
7
Project Schedule ............................................................................................................... 11
6.1
Introduction ................................................................................................................................ 11
6.2
Estimation of Effort ..................................................................................................................... 11
Conclusion ........................................................................................................................ 12
Appendices ...................................................................................................................................... 13
Appendix A: CS 480 Resource Usage ...................................................................................................... 13
Appendix B: CS 480 Task Sheet ............................................................................................................... 15
Appendix C: CS 480 Gantt Chart ............................................................................................................. 18
Table 1 Risk Table.......................................................................................................................................... 7
Table 2 Activity Breakdown ........................................................................................................................ 10
1 Introduction
In business and insurance practice, evaluating the adequacy of reserves is very important when
valuation actuaries calculate the probability distributions of involved financial random outcomes. A
faster research system would assist the actuaries and academic studies to project insurance financials
on a stochastic interest rate or equity return basis. This research system will be desktop-based
application made from a combination of C++, Lua, and C#.
1.1 Vision Statement
Valuation actuaries are in need of a faster way to analyze and project insurance financials on a
stochastic interest rate (mainly cluster sampling for tail estimation of probability). This system will be
able to read stochastically generated scenarios from an Excel spreadsheet and estimate the probability
of tail as cluster samples by using one of the three distance formula that will be built-in the system.
Finally, the system output the required run-time for the distance sampling process, list of selected
sample scenarios, and probability of selected sample scenarios. The output of the system will play a vital
role in professional judgment of actuaries to evaluate the adequacy of reserves.
1.2 Real World Problem
One of the challenges of estimating the probability distribution of financial outcomes for large insurance
businesses is the run time. Estimating and analyzing the probability of a large block of business is often
too time consuming to be practical. Modelers at actuaries reduce the number of runs or group assets
into asset categories to reduce the run time for each scenario. This way of estimating the probability
distribution of large financial outcomes is not reliable. Additionally, under- or over-estimating large
financial outcomes may lead to poor judgment and even fail the entire business.
1.3 Project Stakeholders
The main users of this project are those who work at valuation actuaries evaluating the adequacy of
reserves of insurance companies.
Client: Dr Yvonne C. M. Chueh is our client. She is an Associate Professor in the Mathematics
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
stochastic interest rate.
Researchers: Researchers who are doing academic and industrial studies on actuarial sciences
can also use our project.
1.4 Project Scope
This project is a desktop standalone application. Generally, it will go through three phases to perform its
task; it will have a graphical user interface that interacts with the user to get his/her preferences 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, it will estimate the tail probability as cluster samples based on the 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. The program’s output plays a vital role in
professional judgment of actuaries to evaluate the adequacy of reserves.
The main goal of this project is to provide the actuaries with a more efficient research tool to make
stochastic modeling more accurate and reliable. This application will reduce the amount of time
currently spent on calculations. It will let the statisticians at actuaries and academic studies of actuarial
sciences 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.
1.5 Document Preview
The following documents are the significant part of our project plan:
Process Model and team Organization – We chose to use the waterfall process model with
prototyping. This model is a systematic process toward our final product, from start to finish.
The initial step is obtaining all the requirements from the client. While gathering requirements
and developing a design that will meet those requirements, we create a prototype that the
client and team members will review. Next, we implement the design and product. The final
step is to maintain the system, and to insure functionality.
Risk Analysis- Risk analysis is a technique to identify and assess factors that may jeopardize the
success of the project and achieving our goal. In this section, we analyze each potential risk to
our project and determine how it will affect our goal and project.
Hardware and Software Requirements – This section describe the specification of the inputs
that the program reads from the spreadsheet, and the software needed to develop and run the
application. It will also detail the hardware requirements for the program.
Work Breakdown Structure – This is a detailed section about the important dates and
subprojects, during development in the CS480-481 sequence.
Conclusion – This project mathematically interesting and will be a great learning experience for
the entire team.
2 Process Model and Team Organization
Detailed in this section are the process model, team members’ official responsibilities, and their roles for
this project. The development of the project follows the Waterfall method, with the addition of a
prototype. Each member will fulfill a specific position within the team to manage certain tasks
throughout the project. Each team member will also participate in each step of the development,
though in different proportions for each step.
2.1 Software Process Model
Though criticized for its lack of testing, the Waterfall method of software development provides
straightforward, systematic steps. This simplicity makes completing a fully developed, professionalgrade program possible within the time allotted, which is approximately six months. Once the project is
given, the developer team gathers requirements specifying the exact expectations and desires the client
has for the program. After compiling as many requirements as possible, the team enters the design
stage, conceptualizing the architecture of the code and the layout of the user interface. With an
acceptable design in place, the team builds a prototype of the design and presents it to the client and
other authoritative figures for formal review.
Using the feedback from the prototype, which we ultimately discard altogether, the program undergoes
a redesign and enters the construction step. During this step, the team builds a final version of the
project, which includes a fully functional user interface and a complete algorithm for correctly solving
the problem in question. To ensure the program satisfies all the requirements, the team tests the
software thoroughly, attempting to discover as many bugs and faults with the software as possible.
Once the testing has finished, which tends to imply the advent of a deadline, we will package up and
deliver the final product to the client. By this point, the software is a finished product.
2.2 Team Organization
Because of the scope and size of the project, each team member must take responsibility for portions of
the project. Providing the team with direction and focus, Alan Chandler will act as Team Leader. A few of
his duties involve equally distributing work among members, making sure members complete their
given tasks, and preparing agendas for meetings. Assuming the role of Lead Developer, Nathan Wood
will manage the design and architecture of the software. He must provide specifications for each portion
of code and guarantee proper integration of those portions. The team’s Lead Tester will be Eric Brown,
who will design and accumulate tests that will assess the correctness of the software. Temourshah
Ahmady, as the Quality Assurance Officer, will compare the software to the requirements and the
client’s expectations to guarantee the software is complete, correct, and meeting quality standards. This
requires maintaining close communication with the client.
2.3 Team Roles and Duties
Every team member will work cooperatively on every assignment and step of development, but some
will work more on certain tasks than others. For all written documentation, every member will provide
the same amount of work. The requirements and design steps will also require the same effort from
each member. During the construction stage, every member will have pieces of code to work on, but
the Lead Developer will be responsible for integrating each piece of code and will likely end up
programming a bit more. In the same, every member will work on developing tests and checking for
quality, but the Lead Tester and Quality Assurance Officer will put more effort into each task,
respectively. Regardless of the task, everyone will equally participate in the project, as shown in
Appendix A.
3 Risk Management
A risk can be anything that derails the development process of the application, and risk management is a
discipline for identifying risks, and determining measures to control and reduce them. This section
outlines some of the risks that may happen during the development process of our project application.
Our team will come up with a risk management plan to handle and assess the impact of each potential
risk.
3.1 Risk Table
Our team has identified the possible risks that may occur during our CS 480 and 481 Software Project.
The table below has detailed the risks with the likelihood they may occur and the impact they would
have on the future of the project.
Table 1 Risk Table
List
1
2
3
4
5
6
Risk
Team member does not do his share of the work
Team member becomes ill or injured
Team member does not continue to CS 481
Project does not meet client needs
Project falls behind and need more time
Team members disagreement
Likelihood
Medium
Medium
Low
Low
Low
Low
Impact
Medium
Medium
High
High
High
High
3.2 Risk Analysis and Solution Strategies
The following list describes the project's risks, their likelihood and impact, and the strategies for
managing these risks.
1. Since some of our team member may not have experienced working and learning as a team
before, they will find it hard, and they might not do their share of work. Therefore, in order to
prevent this risk, it is necessary for all team members to have good communication among each
other, and everyone should brief the team about his share of work during the weekly team
meetings. In particular, the team leader should make sure that everybody in the team has work
to do, and all team members must understand everything the team does.
2. As it is natural, it is possible for any member of our team member to get ill or something
unexpected happen, that would stop any of us to continue doing our share of work. In that
case, the team members are responsible to share the work and get the project done.
3. Since CS 480 and 481 is required, to complete the CS major, the likelihood that any of our team
members drop the class or unable to continue is very low. As mentioned, in only situation, that
our team members may not be able to continue is when they get ill or something unexpected
happens. In situation like that, we all will share the work and make every efforts needed to
complete the project.
4. In order to make sure that our project meet all the requirements and satisfy the client’s
expectations, we as a team should have effective communication with the client and make sure
that we update our client on every decision and any progress we make to complete the project.
5. It is possible that our team will run out of time to get the project done on time. To avoid this
risk, every team member should be highly committed to attend in all our meetings. In particular,
everybody should take responsibility to do their share of work, and those who finish their share
of work early should help the other team members. In case our team fall behind and cannot
complete the project on time, we all will take responsibility to request more time and get our
project done.
6. Every team member plays a vital role in obtaining the team’s goal and completing our project.
Therefore, we as a team respect each other’s ideas and inputs to make sure that everybody
agrees with how we will do our project. If our group disagrees, which can delay development;
we will make every effort to solve the disagreement.
4 Hardware and Software Requirements
We are planning to write our application primarily in the .NET framework on Windows 7 64 bit. Our
program will also depend on the Visual C++ 2010 runtime. This section first details hardware
requirements, and then software requirements.
4.1 Hardware Requirements
The target systems are dual-core desktop PCs running Windows XP SP3 32 bit, circa 2005. We expect
them to have at least 1 GB of physical RAM, and at least 1 GB of swap file. We expect the computer to
have a CPU equivalent to a Core 2 Duo, with around 3 GHz. The computers should have at least 20GB
free space.
The main difference from a hardware standpoint is the development PCs are faster, which poses some
testing challenges. We expect the development PCs to have at least 4GB of RAM, and a Core i7 with
around 3 GHz.
The development PCs are therefore much faster. To compensate for the differences, we will perform
final benchmarking to test if the program meets the performance requirements on a PC that we
consider representative of the users’ PCs.
4.2 Software Requirements
Target platforms will require the .NET framework version 4.0, which requires at least Windows XP. They
will also require the Visual C++ Runtime version 2010. As the primary target customers of this software
are business users, we expect that they will be running Windows XP SP3 32 bit, which is still prevalent in
the business world.
The development PCs are running primarily Windows 7 64 bit. Included with Visual Studio are the .NET
framework and the Visual C++ runtime, so this is not an issue for development. To install these needed
runtimes on the users PCs, we hope to bundle the installers with our installer, and if that is not possible
provide links to where users can download the installers.
As Windows XP 32 bit is different from Windows 7 64 bit, we will run all tests will on both at a bare
minimum. For basic testing, we will have a Windows XP 32 bit virtual machine to test the application on
for our project. For final testing, we will use a real machine with Windows XP 32 bit, and ensure that it
meets all the requirements on both platforms. If there is time, we will also test it on Windows XP 64 bit,
Windows Vista 32 and 64 bit and Windows 7 32 bit, as these are becoming more common in the
business world.
5 Work Breakdown Structure
5.1 Introduction
This section will include the breakdown of work, which our team must accomplish in order to create a
successful project. We will set the amount of time we believe each part of the project will take to be
completed and organize this information with Microsoft Project. As a team, we will decide these hours
and then split them between ourselves accordingly in order to have a fair amount of work. This will
make sure that our individual teammates do not feel they are getting too little or too much work
compared to everyone else.
5.2 Activity Breakdown
We will create time estimates for the remaining projects in CS480 and in CS481 in order to schedule our
time most efficiently. To do this we will approximate times for each part of the project and then put
those times into a project manager such as Microsoft Project. We will display the organization that this
program gives with a Gantt chart. With this sheet, we have accurately described the tasks, which we will
have to complete to finish our project1.
Table 2 Activity Breakdown
Due Date:
Monday February 1st
Wednesday February 3rd
Friday February 5th
Monday February 8th
Monday March 8th
Friday March 12th
Wednesday, Friday March 10, 12
Week of March 16-19th
1
See Appendix B
Assignment:
Software Design Specification
Midterm Oral Presentation
Software Test Plan
Peer Reviews
User’s Manual
Quality Assurance and Test Report
Final Oral Presentation
Program Satisfies Requirements
6 Project Schedule
6.1 Introduction
In this section, we will detail the scheduling of our project and the deadlines for different pieces of our
project. From the information in the previous section, we will determine a schedule by which we will
finish the parts of our project. Using Microsoft Project, we will use the amount of hours we estimated for
each project in the previous section to create a schedule. Microsoft Project has many advanced and
efficient methods that allow for a schedule that has an easy to understand format. Using this schedule our
team will efficiently tackle the CS480/CS481 Software Engineering Project.
6.2 Estimation of Effort
We approached estimating the effort required by working through one of the more detailed sections and
using that as a baseline for time. Extrapolating the amount of time needed to do this section we gathered
estimates for all of the projects following and agreed upon a time. To determine the interdependencies of
our different projects our group examined the assignments carefully. Reading through each document
allowed us to build an understanding of how the documents were interconnected. This information led us
to the documents we would need to do before other documents. Team roles dictated the parts of the
projects each team member would write. We assigned each team member to their roles by matching the
part of the project as closely as we could with their role. We show the accumulation of our efforts to
divide the various parts of projects in our Gantt chart2.
2
See Appendix C
7 Conclusion
The client, Dr. Chueh, insists that this project has never been done before. If that is true, then it could
become a groundbreaking program that may become commonplace in the actuarial world. For that
reason, Team Stochastic will put all the effort, energy, and resources into this project to produce the
best software possible, and following this project plan should make fulfilling that goal simpler.
Appendices
Appendix A: CS 480 Resource Usage
Appendix B: CS 480 Task Sheet
Appendix C: CS 480 Gantt Chart