In the software world, it’s important to write elegant code and follow processes. The simple truth is, if you don’t do a good job of following a reproducible process in software development, it can lead to products that range from excellent to horrible. This guide will show you how to produce high-quality software every time, by following guidelines based on years of software development.
The Steps
If you want to do things right, you have to do them in order. Let’s look at the steps that need to be followed to design a program properly.
- Identify the purpose of the project.
- Gather the requirements for the project.
- Prototype the project.
- Repeat steps 2 and 3 until the project is well-defined and ready to be implemented.
Identify the Purpose
You would be surprised at how many software projects are begun and finished without ever really knowing what they are going to be used for, or by. A software project is not a catch-all bucket to throw every known feature for every known problem into. Instead, programs are intended to fit under a single umbrella that defines who will be using the thing and what the program will do for them.
Some people call this a mission statement, although I personally prefer “The Big Picture” to define the purpose of the project. For example, you might have a program that aids the user in laying out an ad campaign. It makes sense to have features that allow you to import various kinds of pictures and set the fonts of different forms of text. It does not, however, make sense for it to look up the stock price of the company for whom you are doing the ad.
Identifying the purpose of the project means meeting with the stakeholders, and the people who will use the project. It is your job to weed out the features that make no sense, or that will detract from the overall usefulness of the project.
Gather the Requirements
Requirements are things that a project must do or conversely may not do. A requirement might be feature-related -requiring that a project implement a specific standard, such as XML storage, or be capable of being used by blind people. No matter what the requirement, there are two elements that must be true:
- A requirement must be capable of being implemented.
- A requirement must be capable of being tested.
When we say that something must be capable of being implemented, it means that a requirement has to be real. You cannot say, for example, that the program “responds quickly.” There is no way to tell what “quickly” means in this case. Likewise, you cannot test for something to respond quickly. A real requirement would read more like “the program must return data within 30 seconds.” Now the developer knows what is expected and the tester knows what to test.
Each time you talk to the user, you gather requirements. Often, these requirements do not come all together, you need to dig a bit to find them. A user might not mention, for example, that they want the program to run both on a desktop and in a web browser. They might forget to tell you that there are different kinds of users, from readers to administrators. It is your job, or the job of the project manager, to assemble and clean up these requirements into a single cohesive set of rules by which the program can be built.
Prototype the Project
A prototype is a partial implementation of a project, one that does not necessarily work completely. Sometimes prototypes don’t work at all, but simply show the user and the developer what the workflow of the application will be. A workflow is often called a “user story,” and indicates what steps a user will have to take to accomplish a given task.
Prototypes can have various forms. The visual aspect of the program is often referred to as a “wireframe,” since it consists of various components that need to be “wired” into back-end pieces that do the real work. For example, you might have a list of names of customers to select from. In the real program, this list would be supplied by some kind of database or service. In a prototype, however, it would be entered directly into the visual form and the user can see immediately what it will look like when running, without the need for writing the code behind the system.
Prototypes can include input forms, visual effects, reports, and even workflow diagrams. The point is not to make the code work, but rather for the user to see exactly what they are going to be getting when it does work.
Repeat Steps 2 and 3
One of the most important things in the design process is understanding that it is rarely done in one quick session. Instead, you meet with the users and developers, and possibly testers, and discuss what they think they want. It should be noted that what a user thinks they want in round one is rarely what they want in a subsequent round.
The usual process works like this: the users all see what they have asked for in a prototype and either completely rejects it or modify it greatly. This causes you, the designer, to go back to the drawing board and redesign the whole thing. As time goes by, and the users get a better understanding of what the program will do and what they want, the number of changes is reduced, over and over.
Eventually, the users and developers agree on what it is they want and the development effort begins. At this point, the system is fully designed, both from the user aspect and the development requirements.
Computer programing is used to develop software, gaming, and applications for mobile and desktop users. If you have an interest in the computer field, you can also learn coding and programming from the beginning level. You will need to join programming courses either online or offline.
Computer programs are not simply thrown together and given to users. They must be designed, from the ground up, to give the users what they want, without making it too difficult for them to accomplish what they need to do on a daily basis. By following a consistent plan for doing that design, you will make your users happy every time you create a new application.
