This application allows a user to enter respondents' details into an IT salary survey and then to compare a respondent's salary to the salary of either, other respondents, or, to salaries nationally based on data held on the IT sector.

Comparisons can be in terms of either role, experience or simply to all other employees. At least one respondent's details must be entered in a session before any comparison reports can be run and during any session, a user can enter as many respondents' details as they wish. If the user has entered only one respondent and then chooses to run a report, the application automatically selects that one respondent, if however, they have entered more than one respondent, they are prompted to select the respondent they wish to run comparisons against.

After a welcome screen is displayed:

the main menu is displayed:

From the main menu, the user has the choice of entering a repondent's details, running a report or Exiting. If they wish to run a report they must have entered at least one repondent's details, as all of the reports are comparison reports and they need something to compare to. If they try to choose the reports menu and at least one respondent has not been entered, they will be presented with a message telling them they must enter at least one respondent:

The user is asked to enter the respondent's name (optional), email (optional), role (from 8 pre-defined roles), experience and salary.

If an email is entered, it must be in a valid format. The role must be one of the pre-defined ones, experience can be between one and forty years and salary must be between €10,000 and €500,000. Once valid data has been entered, the details will be added to a Google Spreadsheet and a list of respondents added during the current session - there is more detail about the data model below.

If the user chooses the report menu and they have entered more than one respondent during this session then they will be asked to select from those respondents entered:

If they have only entered one respondent in the session, then that respondent will be automatically selected. Once a respondent has been selected the user is presented with the report menu:

From here they can choose one of six reports or choose to exit back to the main menu. When they run a report, they are returned to the report menu and they can run as many reports sequentially as they want before they choose to return to the main menu.

The respondent selected is compared to all other respondents with the same role, the number of respondents with a higher salary, if any is displayed, the number with the same salary, if any, is displayed and the number with a lower salary, if any, is displayed. The program pauses so the user can look at the information and they are requested to press a key when they wish to continue:

The respondent selected is compared to all other respondents with the similar experience i.e. +/- a year, the number of respondents with a higher salary, if any is displayed, the number with the same salary, if any, is displayed and the number with a lower salary, if any, is displayed. The program pauses so the user can look at the information and they are requested to press a key when they wish to continue:

The respondent selected is compared to all other respondents, the number of respondents with a higher salary, if any is displayed, the number with the same salary, if any, is displayed and the number with a lower salary, if any, is displayed. The program pauses so the user can look at the information and they are requested to press a key when they wish to continue:

The respondent selected is compared to data held for salaries for people with a similar role. The information is saved in quartiles, so the user is told which quartile the respondent falls into and the lower salary range for each quartile.

The respondent selected is compared to data held for salaries for people with the same experience. The salary of the respondent is compared in terms of percentage of the national average for that level of experience.

The respondent selected is compared to data held for salaries for people in the IT sector nationally. The information is saved in percentiles, so the user is told which percentile the respondent falls into and the lower salary range for every 20th pecentile.

A respondent is an object comprised of name, email, role, experience and salary. The first two are optional strings while the last three are numerics.

Within the program, the component items of a respondent are captured and validated then added to a list of respondents entered in that session of the program and appended to a respondent tab in a Google spreadsheet, see below.

A Google Spreadsheet with 8 tabs was created:

The first tab stores the respondent data i.e. name (if one entered), email (if one entered), role, experience and salary. Name and email in a real world setting would need to be handled appropriatley from a data protection standpoint.

The second tab stores the bottom salary level for each percentile of people nationally in the IT sector.

The third tab stores the average salary for each year, 1 to 40, of experience.

The fourth tab stores the bottom salary level for each quartile of people with the role of developer.

The fifth tab stores the bottom salary level for each quartile of people with the role of senior developer.

The sixth tab stores the bottom salary level for each quartile of people with the role of Technical Lead.

The seventh tab stores the bottom salary level for each quartile of people with the role of Head of Engineering.

The eighth tab stores the eight roles and their respective salary ranges.

The program appends respondents to the first tab and then uses the other tabs when creating the comparison reports.

It would be good to implement the ability to send an email summarising a rspondent in terms of the six reports.

Testing was performed on each individual field to make sure that proper validation was performed i.e. that menus will only accept selections which are valid and respondent data is, either, in a valid numerice range or emails are correct format.

Scenarios where reports were attempted to be run with no respondents previously entered were tested and these successfully stopped the reports from being run. Scenarios were tested where reports were run after only one respondent was entered and that respondent was automatically selected for comparison. Scenarios were tested where reports were run after multiple respondents were entered and the user was forced to choose one before the report could proceed.

The menu navigation i.e. iteration was also tested.

The run.py code was run through pycodestyle and all significant errors were fixed. The remaining errors were for lines, either text from the program or logic for the program which were over 79 characters.

There are no known functional bugs.

• The site was deployed to Heroku.

gspread and Credential from google.oauth2.service_account were both installed.

The re module was installed to allow validation of email formats.

The OS module was installed to allow the screen to be cleared at various points in the program.

The Code institute GitHub templates and the modules from the Diploma in Software Development were referenced repeatedly. W3Schools.com, W3org.com and StackOverflow.com were all also referenced liberally.