Team StochasticCentral Washington University

Software Project PlanProject Name: Cluster Sampling Tail Estimation Probability (CSTEP)

Editor: Alan Chandler

Authors:

Alan ChandlerEric BrownNathan WoodTemourshah Ahmady

Faculty Advisor: Dr. James Schwing

Client: Dr. Yvonne Chueh

Due Date: 11/09/10

Table of Contents1 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 Project Schedule.................................................................................................................11

6.1 Introduction...............................................................................................................................11

6.2 Estimation of Effort....................................................................................................................11

7 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........................................................................................................................................7Table 2 Activity Breakdown.......................................................................................................................10

1 IntroductionIn 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 StatementValuation 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 ProblemOne 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 ScopeThis 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 PreviewThe 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 OrganizationDetailed 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 ModelThough criticized for its lack of testing, the Waterfall method of software development provides straightforward, systematic steps. This simplicity makes completing a fully developed, professional-grade 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 OrganizationBecause 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 DutiesEvery 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 ManagementA 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 TableOur 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 Risk Likelihood Impact1 Team member does not do his share of the work Medium Medium2 Team member becomes ill or injured Medium Medium3 Team member does not continue to CS 481 Low High4 Project does not meet client needs Low High5 Project falls behind and need more time Low High6 Team members disagreement Low High

3.2 Risk Analysis and Solution StrategiesThe 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 RequirementsWe 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 RequirementsThe 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 RequirementsTarget 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 IntroductionThis 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 BreakdownWe 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: Assignment:Monday February 1st Software Design SpecificationWednesday February 3rd Midterm Oral PresentationFriday February 5th Software Test PlanMonday February 8th Peer ReviewsMonday March 8th User’s ManualFriday March 12th Quality Assurance and Test ReportWednesday, Friday March 10, 12 Final Oral PresentationWeek of March 16-19th Program Satisfies Requirements

1 See Appendix B

6 Project Schedule

6.1 IntroductionIn 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 EffortWe 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 ConclusionThe 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