Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

Actuarial tables

C++ Programming with Applications to Finance Project 1 2022/2023

The BlueSky Actuarial Consultancy Company has engaged you as a C++ consultant to create a computer application that produces actuarial tables on demand.   The aim of this project is to create a user friendly computer application that meets their requirements.  Your program should be accompanied by end-user and developer documentation.

This project description is accompanied by two les, namely a C++ header le Project .h and a sample table, Table_A .csv.  The header le Project .h must be included in your project without change.

The company uses 4 different tables, named A to D. In each table, the rows n = 1, . . . , 30 represent years, and the columns m = 1, 2, 3, 4, 6, 12, 52 represent the number of payments per year. An example le Table_A .csv is provided to illustrate the formatting. It is important that the formatting (including the headers) should be identical to that provided in Table_A .csv.

The contents of each table is the value of a certain actuarial quantity for different values of the number of years n, the number of payments per year m and the interest rate i.  The company has provided the following information about the contents of each table:

This project contributes 30% to the mark for this module. The deadline for submission is 11:59pm on Friday  17th of March  2023. The marks for the project will be split into 60% for coding  style,  clarity,  accuracy  and  efficiency  of  computation,  and  40%  for  documentation (including comments within the code) and ease of use. Credit will be given for partial completion of each task.

Task 1: Interest rate quantities

Write functions that calculate the quantities v , i(m) , d(m)  from the value of the interest rate i and the number of payments per year m.

Place the definitions of the functions in a new header le InterestRate .h. You may choose whether to place the implementations of the functions in this header le, or in an accompanying code le InterestRate .cpp.  You should choose meaningful names for the functions, and use comments in the code to document carefully how they should be used.

Task 2: Annuity values

The header le Project .h contains definitions for four functions that can be used to calculate the values in the table above.  Create a new le Annuities .cpp with the implementations of these functions. Your code should use the functions created in Task 1.

Task 3: Annuity tables

The header le Project .h also contains the definition of a function WriteTable.  Create a new file WriteTable .cpp that contains an implementation of this function.

The function WriteTable returns an integer value.  This value should be 0 if the le was created and written successfully. You should decide on what errors you wish to check for, and which error values you wish to return. This should be described in the developer documentation.

Task 4: User interface

When the program is executed, it should welcome the user with a greeting, and then ask the user to enter the value of the interest rate i as a decimal number  (for example, 0.05 if the interest rate is 5%). If the value of i entered is less than or equal to -1, then the user should be given further opportunities to enter a valid value of i.

The program should then allow the user to select all the tables that they wish to create. This can be done by allowing the user to make multiple choices from a menu, or allowing them to enter the names of tables required—your choice.

The program should then create each of the tables selected.  Each table should be placed in a le named Table_name .csv, where name  is by the name of the table (for example, A or B). Once a table has been created, your program should give a message to the user confirm that this has been done successfully.  The program should terminate once all tables have been created.

Submission instructions

Submit your work by uploading it in Moodle by 11:59pm on Friday 17th of March 2023

Format

Submit the code as a single compressed .zip file, including all Code::Blocks project ( .cbp) files (if you used Code::Blocks), data les ( .csv), source code and header ( .cpp and  .h) files and the executable (e.g.  .exe) file produced by compiling and linking the project, all residing in a single parent directory.  The  .zip file should preserve the subdirectory structure of the parent directory (that is, the subdirectory structure must be automatically recreated when unzipping the le).

The code should be accompanied by detailed documentation, split into two parts:

1.  Code developer documentation containing information to help understand the code. It should contain the following:

❼ Description of the le structure.

❼ Description of the available functions.

❼ Instructions on how to extend the code by adding new tables.

❼ Information on any error checking performed (in WriteTable or elsewhere).

❼ A few paragraphs on which modifications you would suggest to make the code more

efficient.

The developer documentation should not include extensive extracts from the code (brief snippets are perfectly ne, if typeset correctly—no screenshots!), and there is no need to describe the mathematical formulae in any detail.  It is expected that the developer documentation will be less than 5 pages in length.

2.  The end  user  instructions should contain instructions on how to use the compiled program, how to input data and how the results are presented, and a brief description of the methods implemented. The contents of this document should be appropriate for a reader who is not familiar with C++.  It is expected that the end user instructions will be 1 or two pages.

The documentation les must be submitted in .pdf format (two separate .pdf files containing developer documentation and user instructions) and uploaded in Moodle separately from the code .zip file.

It is advisable to allow enough time (at least one hour) to upload your les to avoid possible congestion in Moodle before the deadline. In the unlikely event of technical problems in Moodle please email your .zip files to [email protected] before the deadline.

Code usage permissions and academic integrity

You may use and adapt any code submitted by yourself as part of this module, including your own solutions to the exercises.  You may use and adapt all C++ code provided in Moodle as part of this module, including code from Capinski & Zastawinak, 2012, and the solutions to exercises.  Any code not written by yourself must be acknowledged and referenced both in your source les and developer documentation.

This is an individual project. You may not collaborate with anybody else or use code that has not been provided in Moodle. You may not use code written by other students.  Collusion and plagiarism detection software will be used to detect academic misconduct, and suspected offences will be investiaged.

If things go wrong

Late submissions will incur penalties according to the standard University rules for assessed work.

It may prove impossible to examine projects that cannot be unzipped and opened due to file corruption, or projects that cannot be compiled and run due to coding errors.  In such cases a mark of 0 will be recorded.  It is therefore essential that all project les and the directory structure are tested thoroughly on your machine before being submitted in Moodle. It is advisable to run all such tests starting from the .zip files about to be submitted, and using a different computer to that on which the les have been created.

All les must be submitted inside the zipped project directory, and all the les in the project directory should be connected to the project.  A common error is to place some les on a network drive rather than in the submitted directory. Please bear in mind that testing on a lab computer may not catch this error if the machine has access to the network drive. However, the markers would have no access to the le (since they have no access to your part of the network drive) and would be unable to compile the project.

As part of the marking process, the le Project .h will be replaced. If the copy of Project .h used in a project has been modied in such a way that the code does not compile with the original le, then a mark of 0 will be recorded.