1. Create login screen
Decide how you want you log in screen to work. I have 3 examples of different difficulty/approach, but you should have your own ideas seeing as you have planned it in a flowchart!! DO NOT LOOK ONLINE!!!
Type up the code and keep testing it. Save it as eg login program. This will mean you can go back to it if you ever need to in future….like in the real thing!!
Take print screens of any problems and put them in your report under a heading called Development.
When you know if definitely works you could copy and paste it into a new Python, which will be your main/full program. Call this something sensible like Form Tutor Full Program.
Make sure you DEFINE it - use def login() for example – ready for use in the full program

2. Log in Program Suggested Plan of Action!
Decide exactly how you want you log in screen to work, of course you should have an idea because you have already planned it so look back at your flowchart and success criteria.
What you might not know, is how to do what you want to do.
DO NOT look on the Internet! You will not be able to in the real NEA. But because I am nice, I have I have 4 examples of different difficulty to help get you started. These will be in the ‘Resource Bank’ for the real thing (assuming I am allowed them there!)
Type up the code and keep testing it. Save it as eg login program. This will mean you can go back to it if you ever need to in future….like in the real thing!!
Take print screens of any problems and put them in your report under a heading called Log In Screen Development.
When you know it definitely works, copy and paste it into a new Python file, which will be your main program. Call this something sensible like Form Tutor Full Program.
This will eventually run using your menu system and sub-routines/functions so make sure you DEFINE it - use def login() for example

3. Testing it in separate/stand alone file – to make sure it works and fix any problems
A simple program which does the job. You show the code and you show it works. This is the iterative test part of development – testing as you go along.
But it’s not great because at the moment, it doesn’t deal with the wrong user name or password being put in.
So – you add this, take some print screens and show how you’ve improved it……………………

4. Development
So now you explain that here is the improved version, why it is an improvement etc
Still not quite there though because the program just ends if you leave it like this and poor Mr Leeman will never be able to log in. You need to show how you’re going to sort this out next…..

5. More Development
So now you explain that here is an even better version, why it is an improvement etc
Here you’d say you’d added in the call to the login function so that if either the user name or password are not right, the login program will restart.

6. And finally, once you know it is working, transfer it to a separate file which will become your main program. As you can see, I’ve started this off by defining a program called main which will then call on the login program to get everything started (and some of the print screen is missing off the bottom before you mention that!!):

7. Real world application – considerations to make your program “robust”, realistic, and reliable
Don’t worry if you can’t do these things, write about some of them in your evaluation to say how it would improve your program!
Allows the user to try again if they got the user name or password wrong
Have a range of user names and passwords stored in a text file so different people could log on eg Head of Year and Form Tutor, Manager and Staff, etc
Have a range of user names and passwords stored in a ‘dictionary’
Hide the password when it is entered so no one can see it/how many characters it has etc to avoid security risks. You could investigate getpass module of Python.
Encrypt the password – also to avoid security risks.
Use a more attractive user interface
Give a “forgot password” option to retrieve the forgotten password
Give hints on the password if they get it wrong
Locks them out for a certain length of time if they get it wrong a certain number of times
Different access levels for different users – eg different menu options once logged in depending on who they are (read only, edit, add, etc)