Comuter Science Coursework Watch
I've decided to create an EPOS system under Visual Basic, but I have no idea where to start
After you've done that, Start by doing a google search for real-world EPOS systems and figure out what features they've got - maybe watch some videos to see how they look and how people use them. Or alternatively go into a supermarket and take some photos of their self-service checkout systems, because those are pretty much the same thing, but more user-friendly. Keep some notes about the information you find because it'll be useful to feed this in to your requirements in the report.
The best place to start with any project is to define what the requirements are of the project. Draw some GUI mock-ups on paper and offload all your thoughts on paper about how it will work. Also consider who the user(s) are (Customers? Shop workers? Store Manager? SysAdmin?) - do those people need to be able to "log in"? Does the GUI change for different users? What do they need to be able to do, and how each input or button will work? Think about the kinds of data which would be useful for users - both going in and coming out. That might be data in the GUI for a sales assistant, or maybe data in a report like a .CSV file for a store manager, or maybe to support what happens when you scan a product, etc.
Also think about user input validation and how the system is going to cope with users pressing the wrong button. Will it hide a button which shouldn't be pressed? Will it prevent the user typing in stupid data? Will it show a message if the data is bad?
Also before you write code for something, describe how you're going to manually test the thing when you've got it working. Consider "normal" use cases (i.e. when the user does the 'right' thing), but also remember to test the validation with bad data. And think about what happens if the user does something bad - e.g. if the user scans all of their products but then their payment fails at the end because their credit card is rejected.
It's really important to spend time deciding exactly how you're going to test code before you begin writing it, because that's how you know whether the code is right or wrong. (And your report needs to contain details of your testing anyway - so you might as well do this as early as you can). You don't need a complete full-system test spec before you begin writing any code; pick one feature at a time, write some tests, get some code working, then look at the next feature, write tests for that, get the code working, etc.
it often helps to start out with the displays, including the inputs and outputs so that you've got something to see on the screen; even if the appearance/layout is incomplete and only has a few bits to start with, or looks messy, you can add to it later. This helps you visualise your testing when you start writing the real code, and it helps you put all the pieces in place so that testing is easier. It also helps to inform what data you're going to be storing in your database, which will feed in to your entity model.
Lastly, don't write code for everything in one go. Start out small and build things on top. For example, your first version of the system might only involve a single input for a single kind of user and a single button which shows a message. Make sure you build it gradually, the more changes you try to fit in at once without firing everything up to get it working, the more likely you are to break everything and spend hours trying to fix it.
Always just get a simple thing working so that it's functional and testable before moving on to the next little thing. This is called iterative development - it simply means treating a really big project as a series of very small, quick changes. A change might even only take you a few minutes or a few lines of code, but once you're done with a change, make sure the program builds and that you can run the program and test the thing/s you've changed.
You'll probably keep hitting points in time where you're not happy with the code, and the structure starts causing you problems or looks big, bloated and messy - that's a normal part of coding. When that happens, do some refactoring and re-structuring to tidy it up and get everything looking neat again, but again, don't try to refactor everything in one big bang, make sure you keep on running the app and testing it whenever you make a tidy-up change as well.