How can the programming of a large, complex piece of software be managed?
What makes a piece of software “good”?
This senior math project was the third and final project for the “Computational Thinking” class. The first two projects introduced students to programming using MIT’s StarLogo TNG by having them create a treasure hunt game and embellish a simulation model of a virus infection. In this third project, the students were challenged with a simple directive: build an awesome program. There were no limits on what they could produce or the platform they chose to develop it on. Their only constraints were to follow a software incremental build process, modeled on one used to produce large-scale industrial software.
The following is the introduction of the project as given to students in the project overview document:
Many years ago I had a conversation with a friend at grad school. He was a systems engineer and we were discussing our career choices and what we really wanted to work on when we graduated. As a systems engineer, my friend was trained extensively in both computer hardware and software and he said, “Hardware is so limiting in terms of what you can do; in software the possibilities are endless.”
What we can build with software (that is, what we can program computers to do) is limited only by our imagination, creativity and determination. Sure, there are problems that we know a computer cannot solve (yet) and there are limits imposed on software by the hardware, but that needn’t stymie creativity. You have already worked extensively with two complex programs that have given you a glimpse of what can be created using the StarLogo TNG platform. Now it’s your turn to be creative and determined.
The directive for this project is simple: Build an awesome program!
Your program can be a StarLogo TNG game or a simulation or (with approval) any type of software (C++, Python, Java, and so forth) that inspires awe when it runs.
To create your program, you will adopt the principles of good program design, which include upfront design of the game/simulation, writing/testing fragments, documenting your code with comments, and so forth.
I designed this project with a lot of trepidation. While the software design process was something I was quite familiar with (and something I felt important for the students to gain some experience with) the complete open-endedness of the project had me worried that the students would really struggle to create a program that was worthy of public display, thinking that many might be far too ambitious and others might create something that did really represent a challenge. To a large extent, the design process addressed these concerns by having the students really focus on the features that they wanted to include in their program and to prioritize them appropriately. Not uncoincidentally, this approach forced students to engage with two major Habits of Mathematicians: “Start Small” and “Take Apart and Put Back Together”.
The majority of the students’ reflections on the project talked about how much they appreciated being able to make their own choice about what they created (and who they partnered with, if at all). Of all the projects I’ve designed, this one did give students the most latitude in what they created, and was the main source of student buy-in on the project.
One aspect of the project and student choice I will have to think about for the next time I do this project is how much latitude to give students when it comes to the development environment they can choose. Some groups did want to move away from StarLogo TNG to Unity, Stencyl and pure Java programming, with a few groups being daunted by the learning curve and moving back to the familiarity of StarLogo TNG.
When our final project was announced, I knew that I wanted to do something different than the other students. I felt that most of the students in the class were going to make games, probably because they like the level of interaction they can get from them. I, on the other hand, wanted to incorporate my love for biology into a simulation that the viewer couldn’t tamper with or change the outcome. I wanted the final results to be completely dependent on the agents themselves. I looked at the Programming Goes Viral project we did earlier in the semester and thought that I could use it as a starting point. Originally I was going to just change some of the code from the project, but then I thought that it would feel more satisfying if I started from scratch. I used the same concept: a virus infected different agents while another agent tries to fight it off, but instead of the virus attacking a population of people, I wanted the simulation to be a virus invading a single organism’s body while white blood cells try to kill it.
I struggled with programming during this class. Even at the end of the semester I had trouble with certain aspects of what I was programming for my simulation, mainly variables. I relied on the help of my fellow classmates when I didn’t know how to do something or when I had a bug that I did not know how to fix. When I first started writing the code I finished all the simple steps first, and with each gate I wrote more complicated code. At first I just set up all the agents, their color, simple movements and characteristics, and the amount of agents in the program. From there things got more complicated, but I paced myself well and did not face many problems. One issue I did come across was working with the smell blocks. When I set them up, they worked in the exact opposite way that I hoped for. The first one I wrote was for the white blood cells to track the virus, but then they ended up avoiding the virus agent. The issue was that I needed to use a global variable instead of a local one.
I am incredibly proud of my final product. It runs very well and has no bugs to speak of. Even though I encountered a couple issues in the process of writing the code, they were nothing I couldn’t handle. If I were to do it again I would challenge myself with something more original since I got the idea for this from a previous project.
The development of the software will be done in stages, which is sometimes referred to as a “gating process” because the development has to pass through a control gate before it can move to the next stage. The main stages for this project are:
1. Learn the essence of a software design cycle (concept, pre-alpha, alpha, beta and delivery) and apply it to a large-scale development.
2. Learn how to specify a software design in terms of features and functionality (requirements), and prioritize features/functionality in the context of the design cycle.
3. Emulate real-world software design by using “external” tester feedback in the revision/debug process.
4. Apply characteristics associated with computational thinking to develop a complex system from scratch, specifically:
5. Understand and use fundamental programming concepts such as loops, Boolean Logic, procedures, abstraction, and variables (global and local)
A Unity-based Game