The development process for a program is how it's made. It consists of the steps it takes to go from planning to programming and beyond!
Image source: HuffPost and How It's Made
Types of Development Processes
There are many different ways to create a program.
Traditionally, program development follows a set path. It is orderly and intentional. One of the most well-known frameworks for developing software is known as the waterfall development model. It's characterized by a step-by-step process, where one step flows naturally into another.
A visual representation of the waterfall development model. Image source: PaulHoadley at English Wikipedia. / CC BY-SA
Over the years, new methods of creating programs were created, such as the Agile and DevOps development methodologies. These methods can offer a more flexible approach to development, and help foster collaboration between developers and users. There can also be variations within methods. For example, programmers have created variations, or modifications, on the waterfall development model over the years.
Some development processes aren't intentional. They're exploratory in nature, and the programmer experiments as they go along. This can happen when a program doesn't have specific guidelines behind it or when developers are under time constraints.
Iterative and Incremental Development Processes
When you think of "iteration," think of repetition. In an iterative development process, programmers develop working prototypes of their program and go back through the stages of their development method to make their programs better.
In an incremental development process, programmers will break the program they're working on into smaller pieces and make sure that each piece works before adding it to the whole.
Programs can be developed using both of these models, or any combination of the two. For example, you can take a code segment of a larger program and revise it until you finish developing it completely, then move on to another part of the program. You're using an iterative process by revising that code segment to completion, but an incremental one for the program at large.
The Drawing Board
The beginning steps for most development processes are the planning phases. Lots of work goes into a program even before anyone opens a code editor.
Investigation and Reflection
This is the game-plan stage of the development process. The goal of this investigation is to make the goal of the programmers as clear as possible.
In this stage, programmers establish what their purpose is and the problem they're trying to solve. They figure out what their program will need to do, and also what their program will need in order to function properly.
They'll often have program specifications to help them with this task. Program specifications are descriptions of the goals of the program agreed on by both the programmers and the clients.
In order to get a clear picture during this stage, programmers have to consult with many sources. If their program is for a client, the client will be consulted to determine what they want. If they're working in a group, they may have to consult each other to make sure all parts of their program will work together. They may also have to do external research to discover what sorts of programs are similar to the one they're trying to make.
Ways Programmers Investigate:
- collecting data through communication channels, such as surveys
- user testing
- conducting interviews with clients to assess what their needs are
- direct observation of the project in action if the project has already been through one or two loops
In an iterative process, this stage can also include a reflection aspect on ways the project could improve or why something isn't working. With every repetition, the questions to investigate and reflect on change, becoming more specific over time.
The design phase of the development phase details how to accomplish the goals of the program.
This design phase may include:
- planning and story-boarding
- organizing the program into modules and functional components
- creating diagrams that represent the layouts of the user interface
- developing a testing strategy for the program
Program Requirements and Specifications
Through investigation, programmers are able to discover their program's requirements. Program requirements describe how a program works. What should a user be able to do? What does a user need to provide for the program to work?
Program requirements also include what's needed on the programmer's end (ex: the program must be compatible with multiple browsers) as well as what tests need to be run to confirm that all these requirements are in place.
From here, programmers are free to start building, prototyping, and testing their programs to their hearts' contents.
While they're writing their programs, they'll need to record what they're doing. They'll do this through the process of writing program documentation.
Program documentation, at its simplest, is a description of how something in your program works. Sometimes, this description can include how your program was developed, such as why you chose one method of coding over another. The documentation could describe a code segment, event, procedure, or even the whole program itself.
Why is documentation used? Programmers document a program in order to break it down and explain it. They need to do this for a variety of reasons. Programs are complex things, and when you're dealing with pages and pages of code, documentation helps you keep things straight. They also foster collaboration. Someone other than the original programmer may someday need to work with this code, and documentation helps explain what's going on.
Think of documentation as notes for your code in the same way you'd take notes for a textbook.
With this in mind, let's turn to a common form of program documentation: comments.
One of the most common forms of program documentation is known as comments. Comments are documentation written directly into the program itself.
Image by Johnson Martin from Pixabay
In the above image, the grey portions of text with the number symbol (#) in front of the words are comments. Each comment describes what the code below it is intended to do.
Comments are often marked by some sort of symbol, like the number symbol, that tells the computer to disregard the text when running the program.
❗While most of the programming languages you'll be working with in this class will support comments, there are some that won't. In this case, you'll need other documentation methods.
Sourcing Your Work
As you travel further and further on the path of computer science study, you may come across a situation where you're using code that someone else helped make. Maybe you and a friend were working together on the Create project. Maybe you had a group project. Maybe you found this really nice code segment that does exactly what you need...
Not so fast, buster! There are some things you need to do before using code that other people helped create.
First, check with your teacher: are you allowed to use this code?
Next, you need to get the user's permission, if possible.
If not, code is often licensed in a way that will tell you what your usage permissions are. Verify that you have permission to use this code.
Finally, you need to cite your sources. Just like when writing an essay or making a PowerPoint, it's important to cite your sources and acknowledge any work that you didn't make. Fortunately, this can be done within your program's documentation.
Overall, your citation should include who originally wrote the code and where the code came from.
There are plenty of online guides about how to cite code, and you're in good hands! Here's a comprehensive one to get you started.