In this chapter, we’re going to explore software projects your students will develop from start to finish in a more self-directed fashion than in their previous projects. The project development process and your role in it will include the popular academic methodology project-based learning (PBL) for making student projects meaningful in a personal and educational sense. Also included will be the Software Development Life Cycle (SDLC), which is used in the professional world to best ensure successful projects. Throughout these projects, you’ll serve more as a facilitator than a teacher, supporting students as they need it and providing guidance as opposed to directing their learning.

Explorable Explanations

Let’s first define the kind of software project your students should work on and the end goal you’ll help them achieve. Mathematics education uses the concept of manipulatives to make its abstract concepts more tangible. These are toys or other physical objects that students can play with to better understand ideas, such as place values, operations, and patterns. Figure 8-1 shows some examples of these educational tools, including a hundred board, base-ten blocks, counting sticks, fraction cubes, and an abacus-style counting device that connects the abstract to the real world.

Although these tools are very effective, they can be costly and take up physical space. As computers grew in popularity, academics and developers began creating online libraries of virtual manipulatives, software versions of these physical objects students could access freely, manipulate, and share. In 2011, software developers started talking about the concept of explorable explanations, which took the idea of a virtual manipulative and extended it into other academic subjects.

An influential early explorable explanation was developed by Bret Victor, who initially coined the term. He programmed reactive documents, which were dynamic texts that allowed users to change fields in a paragraph, which in turn would change quantities attached to each field. For example, a town planning commission weighing the width of public parking spaces against the number of spaces they want available might read, “At a width of eight feet per parking space, which surveys find insufficient, the town provides 160 spaces, which accommodate 97.5 percent of peak demand.”

Modifying the width of “eight feet” in the preceding statement would result in a cascade of changes to the rest of the text. For example, “At a width of eight-and-a-half feet per parking space, which surveys find adequate, the town provides 150 spaces, which accommodate 91.4 percent of peak demand.” Such documents, Victor argued, promoted transparency in calculations by making the author’s math explicit, prompted the audience to read actively rather than passively, and let the reader more deeply think about the subject matter.

Explorable vs. Demonstrative vs. Drilling

To best understand what explorable explanations are, it’s helpful to understand what they’re not. Let’s say a student is interested in visual arts and wants to explore expressing mathematics in that medium. They might start exploring fractals, patterns that are infinite and look similar no matter how deeply you zoom in on them. The student finds an algorithm for generating binary tree fractals, tweaks the seed variables—inputs that impact how the tree will “grow”—and outputs the tree, as shown in Figure 8-2.

The student demonstrates an understanding of the algorithm’s inputs and outputs, explaining that for this tree they set a length of 170 to make it tall, a divergence of 30 to make it broad, and a reduction of 0.75 to make it branch out in such a lovely fashion. But as great as this demonstration is, it’s only a demonstration. The audience consumes the concept passively. To make this explanation explorable, it needs to allow for user inputs. In this case, the student knows what those inputs are: length, divergence, and reduction. So they add form inputs like those in Figure 8-3, allowing the user to change the inputs and see what grows when they click the Generate button. This way, users can engage with the application to explore the concept.

Adding user inputs also incorporates an important challenge for students. Users introduce a wild card to a program. They submit inputs the developer doesn’t expect and use the application in ways that can break it. Accounting for this new variable—the user—will be part of the quality assurance (QA) phase later. This extra effort to add an interface that abstracts away needing to edit code to change the inputs will be worth it when students get to see users engage with their project and instantly produce forests of unique trees, like those in Figure 8-4.

Be aware that user inputs alone won’t make a project explorable. For example, a video game that provides the user with flash cards to blast with correct answers just drills the user, putting them through their paces in a gamified medium. It’s a fun way to memorize facts, but the application doesn’t give users a deeper understanding of the subject matter the way an explorable explanation does. Video games can make for amazing explorable explanations, but make sure students know the difference between a game that empowers discovery and one that merely gamifies the memorization of facts. Keep this in mind when you’re helping your students define what they want to work on for their software project.

A Driving Question

Since the term was first introduced, the concept of explorable explanations has broadened to include applications that explore all kinds of concepts. With graphing and charting frameworks, students can develop visualizations that explore mathematical and statistical concepts. With physics engines, students can develop apps that simulate Newton’s three laws of motion. With 3D modeling frameworks and open source chemistry specifications, students can set up visualizations of complex molecules. In the subject of biology, students can simulate the process of natural selection through evolutionary algorithms.

On the humanities side, students can extend their prose with interactive features like pop-up citations or write interactive fiction that uses links instead of physical pages. Students interested in history can develop interactive timelines with links to primary sources or integrate with online maps to illustrate famous events.

Once they have an idea of what they want to build, students must clearly articulate what they envision into a driving question. This question could be product oriented, such as “How do I write a chatbot that answers questions about the Revolutionary War?” It could be role oriented, as in “If I were a data scientist, how would I analyze the use of passive voice in Pride and Prejudice?” Either way, the question should be action oriented: it should help set the project scope and focus the student’s efforts.

When refining their driving question, students need to consider why the project is relevant and if the product can meet a local need to satisfy the essentials of PBL. In the SDLC, when developing a product, the team must determine who its stakeholders are. These are the people who have an interest in seeing the project succeed and help define what success looks like. You, as the educator and facilitator, are one crucial stakeholder, overseeing the technical aspects of the solution. Other stakeholders will be the end users, likely other students who will engage with the product and learn from it. A subject-matter expert (SME) (pronounced “shmee”) will also be involved. This person knows the business, can explain the requirements, and can verify the software meets those requirements accurately. For your students, this person will most likely be a teacher who best understands the subject for which they’re coding.

Project-Based Learning and the Software Development Life Cycle

With PBL, students take on long-term projects that deeply immerse them in answering an educationally relevant question that’s also of personal interest to them. The project development process requires critical thinking, creativity, communication, and inquiry. The student will move from understanding the academic content to applying it for more authentic subject matter comprehension.

PBL empowers students to construct their own understanding. Explorable explanations empower their users to interact with concepts in a dynamic way for deeper understanding. In this way, explorable explanations are code projects that perfectly complement PBL.

Additionally, PBL develops skills students will need in college and throughout their careers. Students will foster an aptitude for respectful collaboration as they work with SMEs who will make sure the end product meets the local need. Independently working through a project requires inquisitiveness, accountability, self-motivation, and persistence. These are habits of mind that will benefit students throughout their lives.

There are slight variations in how different organizations define the essentials of PBL; in this chapter, I’ll note several characteristics on which there is consensus:

• The project engages significant content, meaning the project focus must be educationally relevant and address a meaningful problem.

• The project question triggers a need to know in the student because it’s intrinsically relevant to them and motivates them to want to learn more.
• A well-articulated driving question sets a focus for the project and the scope.
• Empowering student voice and choice allows students to follow their own paths of inquiry and gives them freedom to decide how they want to proceed.
• As students work on their projects, they have extended opportunities for inquiry and innovation.
• These opportunities are followed by feedback and revision of their projects.
• All these efforts culminate into a publicly presented product.

These projects fall under the category of computational artifacts, covered in Chapter 1, where students produce tangible outputs related to computer science. Topics mentioned were program development, iterative development, debugging, feedback, documentation, and project management from the computer science standards. These are all subjects students will need to engage with in the project development process. As noted in “Educational Benefits” on page 23, code projects are an ideal match for PBL.

PBL is academically focused, but as mentioned earlier, organizations in the professional world use the SDLC to manage their software projects. SDLC has six stages, and different organizations give different names to each stage. Organizations might also group the stages or execute them in diverse ways depending on their project management methodology. Figure 8-5 shows the different stages in the development process.

The first stage, requirements, is where the developer or business analyst documents the details of the business need. The design phase is where the solution is architected. This is followed by the development phase when the actual code is written or the system is configured. Once the project reaches a point of stability, the quality assurance phase tests the application for bugs and to ensure it meets the business requirements. The product then goes live in the deployment phase, and its stability is monitored in the maintenance phase, which continues for the life of the system. The maintenance phase is shown leading to requirements as new feature requests or software enhancements start the process again.

As we’ll see shortly, there are many places where the stages of SDLC facilitate the essential characteristics of PBL; for example, the QA stage of SDLC is very similar to the feedback and revision aspect of PBL. In addition, the publicly presented project part of PBL is very much like the deployment phase of SDLC. These parallels exist as early as the start of the project, where developers plan and define their independent code project.

Requirements

The first step in launching your student projects is to define what those projects are. For computer science, there are many kinds of computational artifacts that students can produce. Several of these projects don’t require coding, such as test plans, use cases, or flowcharts. But in this chapter, we’ll focus on building a software application because such a project involves creating many of the ancillary artifacts surrounding SDLC.

A start-to-finish software project inherently addresses numerous topics in the computer science curriculum, meeting the need for PBL to involve significant content. But building applications also has great potential to address topics in other subjects at your school, provide services to other educators, and highlight the value of your computer science program in the community. Have your students think about the kinds of software they could write to explore topics in their other classes. By building an application that explores a concept covered in a non–computer science classroom, the student project becomes service oriented as they define a product that other students can learn from and other teachers can appreciate.

With a project idea that allows them self-expression, a driving question to focus their efforts, and stakeholders to define the details of how it should work, students will begin by documenting all this information into a project proposal. This is a living document that will change as they dive into the work. Project proposals can take several forms. Generally, it’s best to keep them brief and to the point for busy decision makers in an organization. In the professional world, project proposals explain the business need or opportunity, what service could benefit the organization or community, or what problem could be solved. In student projects, this could describe a subject covered in class that students have difficulty with or find unengaging. After a description of the need, the project proposal then provides an overview of the solution and how it satisfies this need. The project proposal should also list the stakeholders—teachers and students—who will evaluate the project and how well it meets its defined goals.

As the project facilitator, your role is to evaluate the project scope and feasibility from a technical perspective. In this book, the code examples have been limited to client-side JavaScript, which also limits the scope of what students can do with their applications. Does the project proposal require saving user data between sessions? If so, the application will need a database and the learning curve required to set it up. Does the solution need to present personalized features based on saved data? If so, the application will require server-side code and a more comprehensive development environment.

If the student’s vision exceeds what is possible within the project time frame, have them scale back the scope. This can mean scaling back the application’s initial functionality as a starting point, with the intent to iteratively enhance it as time allows. Ideally, explorable explanations are meant to be simple, straightforward, and fun toys that engage and enlighten the user. They should mostly avoid needing a heavy information technology infrastructure to run on. Once students have this starting point, they can continue to the design and development phases of the SDLC.

Design and Development

With an initial project proposal setting the project scope, students begin the design and development phases. Here they research what is needed to build their envisioned application and begin committing code to making it happen. These phases parallel the PBL characteristics of inquiry and innovation, where students internalize existing research and conceive new ideas from what they’ve learned.

The project proposal is a brief, high-level overview of the project and its goals, but the design document provides the details of how the software will work. How to properly document an application’s design is a question that has many correct answers. Some organizations document the flow of how the user will interact with the software step-by-step and each use case. Other organizations document the various software components, such as the database, frontend, and third-party services, as well as what is responsible for what functions and how they’ll work together. Others use flowcharts, and some rely strictly on comments in the code. Unfortunately, many organizations don’t document at all, and that’s a problem.

It’s important that students document their solutions to communicate in detail how they work to stakeholders. When we get to the QA phase of the SDLC, testers and peer reviewers will use the design documentation to verify that the application’s inputs and outputs match the requirements. When the software goes into the SDLC maintenance phase, the design documentation will be an invaluable resource to future developers and administrators who will inherit it and be responsible for keeping it running. When writing and rewriting this documentation, students should remember they’re writing for several audiences: their technical peers who will work with the code, nontechnical peers who will test the application, users who need to navigate the application, and themselves as a means of tracking their development progress.

When planning how they’ll tackle the project, students should research existing solutions. At this stage in the professional world, the question of build or buy becomes relevant. Are there existing products and solutions that can meet the business need with minimal customization or is it better to build an application from scratch? Using an existing solution costs less in terms of money for the organization and development time for the student. But doing so also makes for a less customizable product because the developer is constrained by the existing application’s features or overwhelmed by the complexity of a product with many years of development behind it.

Working from existing solutions is not an all-or-nothing choice. Software is made up of many different components, all of which might have existing solutions online. Remind students to decompose the entire product into smaller, more manageable pieces. For example, a student who intends to draw a number mandala, like the one described in Chapter 1, has many small problems to solve. For example, they must figure out how to draw pictures in the web browser, how to draw numbers, how to position numbers along the lines of a clock face, how to radiate those numbers outward along an imaginary spiraling line, and how to test for factors and primes. With seven billion humans on Earth, someone has probably solved each of these problems and has posted it to a forum or code repository.

The smaller and more numerous the pieces we can decompose to, the better. On a project level, each little problem to solve is a milestone we can use to track progress and clearly define roadblocks. On a personal level, there’s a great feeling of satisfaction that comes with scratching items off a to-do list and a sense of accomplishment that will keep students moving forward.

This section combined the design and development phases of the SDLC because they’re iterative phases that inform one another. Well-researched designs are subject to change when the developer starts writing code and inevitably runs into unexpected complications, such as a chosen technology that doesn’t quite meet the project’s needs or, as happens very often, a planned feature that turns out to be more complex to develop than anticipated. When these problems happen, it’s important to revisit the design documentation and update it accordingly.

As the facilitator, you’ll monitor each student’s development progress with check-ins each day so you can meet with them. In the professional world, these are known as stand-up meetings, where each member of the team gives a brief update on what they accomplished since the last stand-up and what they’re working on now. To keep the meetings brief, limit them to groups of no more than five students each, and coach students on providing their updates as quickly as possible to be respectful of everyone’s time.

This is also when students can notify you of roadblocks they’re encountering. Acknowledge the student’s difficulty, make a note to follow up with them on it in more detail, and then schedule time to meet with the student to collaborate on solving the problem. In Chapter 9, we’ll review techniques and strategies for helping students who are experiencing difficulties.

It’s also a good idea to have the student check in with their SME from time to time and make sure the project continues to meet the business need. It’s best to identify discrepancies between what is being developed and the educational requirements early on to prevent wasted effort. As the students’ applications grow more stable, they’ll move into the formal SDLC testing phase.

Quality Assurance

The QA phase of the SDLC begins when students believe they have a presentable product. As the developer, they’ve personally tested their applications and feel they’re ready for others to try them. We’ll cover three types of QA testing in this section.

Functional testing is where the application is treated like a black box and only its inputs and outputs are reviewed. Here students give their applications to their peers who can interact with the product in every possible way they think a user might. The testers’ goal is to try to make the application behave in an unintended way.

This includes testing user inputs they might think are improbable or illogical. For example, a user might submit “−100” in a field that expects a positive quantity and causes the application to crash. As a software developer, it’s tempting to blame the user for the bad input. But in the professional world, the application must validate every user input and elegantly inform the user if they made an error. Here’s a popular joke about functionality testing: “A QA tester walks into a bar. They order one beer. They order zero beers. They order 1,000 beers. They order qwerty beers . . .”

Once the application satisfies functional testing, it’s stable enough for user-acceptance testing (UAT). Here the SME reviews the application for content accuracy and to ensure it meets the business requirements. In the case of our explorable explanations, the teacher who best understands the concept being explored reviews the application for content accuracy and potentially offers corrections or suggestions for additional inputs, outputs, and features.

A final collaborative QA exercise in this phase is to conduct a code review, where developers read one another’s code and offer suggestions to improve it. This is very similar to peer review exercises in English classes, where students read each other’s papers and provide critical feedback. A good practice is for reviewers to first spend time articulating all the aspects they like about the code they’re reviewing. Have them explain what they think is clever and what they learned about coding from reviewing it. Then, with an eye toward tactful language, they can suggest ways they think the developer could improve the code or suggest additional features they would like to see.

A common complaint about peer reviews in academic settings is that students aren’t experts and might offer criticisms that aren’t valid. As the facilitator during this code review exercise, you’ll need to review all reviews and provide feedback on their tactfulness and accuracy before they go to the reviewee. Students who can learn to communicate their criticisms in a healthy, respectful way as well as accept criticisms and improve on them learn a valuable leadership skill that will benefit them throughout life.

QA is another iterative process that has the developer repeatedly revisiting and revising their application. As the facilitator, you should assure students that this is all part of the process. Many commercial applications have entire teams of QA testers reviewing them, and they still need software patches after going live. There is nothing to be discouraged about in the QA phase. In fact, students should feel increasing levels of confidence as their applications begin to pass various QA tests. Soon, their software will be ready for the deployment phase.

Deployment

Once an application passes its QA, UAT, and code reviews with flying colors, it moves to the deployment phase of the SDLC, which is the point where the application goes live. In software development, this is when the application is posted online to a publicly accessible URL or made available to download. In Chapter 10, we’ll explore code repositories that facilitate sharing the application with the world, but the deployment covered here is meant to satisfy academic requirements.

In PBL, the end of all our collaborative efforts culminates in a publicly presented project. This is an event in which students showcase their projects for an audience of teachers, other students, and parents. More important, this presentation reaches beyond the computer science classroom and promotes the students’ work in the larger school community and the community beyond the school.

These presentations are a comprehensive exercise in communication. Students communicate their learning process, technical understanding, subject matter understanding, and how these all contributed to their computational artifacts. These artifacts include the project proposal, design documentation, software code, testing outcomes, and the user-facing application.

Students will need time to practice their presentations, and feedback on their presentations is essential. You don’t want your students to build an amazing application and then fall short of presenting it in a way that communicates its significance and depth of achievement. Software developers are often boxed into the stereotype of being socially awkward and lacking good communication skills. Having the ability to explain complex technical concepts so people unfamiliar with the subject can understand is a prized skill in the business world and a proficiency your students should value.

This communication also includes conveying your failures. According to the Project Management Institute, only 64 percent of software projects meet their goals, and that’s for businesses with professional software developers. There are many unknowns in programming projects, and this difficulty is exacerbated for novice programmers. Students can learn a lot from a failure. Many organizations hold a project postmortem, no matter whether the project succeeds or fails, to analyze how the project went, what worked, and what didn’t. So, give your students permission to fail. As long as they document that failure and demonstrate an understanding of why and how the problems were too difficult to overcome, their time won’t have been wasted. A great deal of wisdom can come from project failure, and students will have realistic insights for the next project they take on.

The presentations should be an event: there are many ways to let the students shine. Giving each student a bit of time on stage with a projector is a great way to practice public speaking. You could also set up a fair-style environment where each student has a table and some presentation materials, such as a laptop. Attendees can roam around the room networking with students on a more conversational level. Online portfolios with code repositories and documentation can also supplement the presentations, allowing attendees to more deeply explore the projects beyond the event.

Summary

In this chapter, we explored how to facilitate student code projects that foster self-­motivation, free inquiry, deep sustained engagement with computer science concepts, and translating another academic topic of student interest into computational thought. These projects adhere to the essentials of PBL, such as meaningfulness, relevance, student voice and choice, free inquiry and innovation, feedback and revision, and finally a publicly presented project. At the same time, these projects follow phases of the SDLC including requirements, design and development, QA, and deployment.

We did not cover the maintenance phase of the SDLC. What happens after the project goes live? In PBL, the project presentation is the shining moment in which the project concludes, and the student has a tangible accomplishment of which to be proud. In software development, the code going into production is an important milestone, but not the end of the process. Chapter 10 covers how these student projects will live on in your school’s code repository as a resource for future classes.

In addition to these projects being a resource for future computer science students to learn and build from, by building explorable explanations, your students are creating applications from which students can learn concepts in other subjects. You’re bringing positive visibility to your school’s computer science department by providing a growing repository of specialized educational applications for other teachers to use in their classes. PBL makes students knowledgeable about a very specific subject, and hopefully you’ll learn as your students are learning.

In the next chapter, we’ll learn about some of the challenges students will face when tackling coding projects and how you can provide the support and encouragement to see them through to success.