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:
- “Market” Research—Determining the nature of the project. Primary question:
- Why spend time and resources building this project?
- Project Concept—Determining the main features/functions of the system.
- What will it be able to do?
- How will the user interact with the system?
- What will it look like (to the user)?
- Development Plan—Determining feature prioritization. Primary questions:
- What features are most important?
- Which features depend on other features?
- What are the biggest risks (what will be most challenging)?
- Proof of Concept (Pre-Alpha Prototype).
Primary purpose: Minimize risk by demonstrating initial implementation of key features.
- Alpha Prototype
Primary purpose: First user testing for implementation feedback.
- Beta Prototype (iterative—may have multiple versions)
Primary purpose: Testing of release candidate (tested for features, usability and possible bugs)
- Customer Delivery (final release with full documentation)
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:
- Formulating problems in a way that enables us to use a computer and other tools to help solve them.
- Logically organizing and analyzing data
- Representing data through abstractions such as models and simulations
- Automating solutions through algorithmic thinking (a series of ordered steps)
- Identifying, analyzing, and implementing possible solutions with the goal of achieving the most efficient and effective combination of steps and resources
5. Understand and use fundamental programming concepts such as loops, Boolean Logic, procedures, abstraction, and variables (global and local)
The kindergarten students were the first audience for the seniors exhibition project.
A screenshot of Andrew Petosa’s simulation of white blood cells navigating through healthy cells using random sporadic movements.
A screenshot of code written by Ryan Chang and Tristen Tucker to create a space adventure game.
Screenshot of Michael Couron’s and Nick Tweed’s game coded entirely in Java.
A Unity-based Game
Miles Miller chose to recreate the Pac-Man game in StarLogo TNG.
Created by Kevin Belew for display in the room during Exhibition.