Project One: Shaping a Web System

Due by Tuesday, January 28, 2020

Project Description

For this project, you will apply the approach and techniques outlined in Shape Up to shape and pitch a web system that integrates with other systems that are part of a business, governmental, or non-profit organization. In other words, what you’re shaping is not a complete, self-contained application (Facebook, for a bad example) but a system that fits into some broader, larger set of systems that makes up a business’s concerns. As a starting point, think about systems for billing, shipping, account management, internal communication, issue tracking, customer support, ticket- or seat-booking, and so on.

The system you shape will have two core public components: a web-based user interface for managing and interacting with the system itself, and a data API for integrating with other systems within (and potentially outside) an organization.

Internally, your system will have or rely upon at least three components: a structured data store, consumption of a free (if rate-limited) relevant API providing supplemental data, and a server-side web framework for responding to incoming requests for both your system’s web-based user interface and its public data API. It is not necessary (or even desirable) to determine the specific details of those components at the shaping phase, although you absolutely must make sure a public data API is available to provide the supplemental data your system will ingest.

ITMD 467 students will deliver the pitch for a shaped system for Chicago residents to submit complaints to their correct ward alderman, drawing on data from the City of Chicago Data Portal to determine a resident’s alderman, and perhaps to enhance the contents of complaint data. For example, a complaint about rats might reference or include data from the city’s rodent baiting dataset. Your system will need to deliver its own database for tracking residents and their complaints, and the alderman’s response to or resolution of the complaint.

ITMD 567 students will research, invent, or discover some kind of business-oriented system and then deliver it as a shaped system and pitch.

Deliverables and Deadlines

  1. Due by Sunday, January 19: Post draft deliverables to Basecamp. Your draft post should include:
    • Your name and Project Pitch as the post title (e.g., Scarlet Hawk: Project Pitch)
    • A link to a GitHub Gist with ideas of your Problem, Appetite, Solution, along with any clear Rabbit Holes and No Goes
    • Fat-marker sketches, diagrams, and illustrations embedded in your GitHub Gist.
    • Specific requests for feedback from the instructor and peers. Write this in the body of your Basecamp post
  2. Due by Wednesday, January 22: Respond to at least 3 of your peers’ Draft Projects
  3. Due by Tuesday, January 28: Post final deliverables to Basecamp. Your final-deliverable post must include:
    • A link to a GitHub Gist of your written pitch, illustrated with fat-marker diagrams and sketches, outlining Problem, Appetite, Solution, Rabbit Holes, and No Goes.
    • A self-assessment, written in the text of the Basecamp post, of 250 words or so of your work on this project and your degree of confidence and satisfaction with your final pitch.

Project Requirements

  1. Refer to the two example pitches in Shape Up to help guide your own work, especially at the draft stage

Project Goals

  • Improve your ability to use rough sketches and brief, clear writing to describe and pitch a system design
  • Increase your skill in writing in GitHub-flavored Markdown syntax
  • Practice scoping and reducing a system to its core, essential components

Project Two: Web System Alpha-Release Cycle

Due by Thursday, March 12, 2020

Project Description

In the first of two six-week cycles, you and your team will rapidly prototype and begin to design and construct a web-based, service-architected system. It will ingest data from one or more third-party APIs, accept user-input data via a web interface that you will provide written in HTML, CSS, and JavaScript, and deliver an outbound API serializing your system’s data for consumption elsewhere in an organization.

Plan to include unit, functional, and integration test coverage as early in your process as possible. Your work will proceed this cycle as a series of 0.x.x-alpha.x releases.

Note that the requirements listed with this project are the overall system requirements for the final version to be delivered on Thursday, May 7. You and your team should choose which of these requirements to focus on at the alpha stage, and which to defer until the beta stage. For example, there is no requirement to deploy your system at the alpha stage, so your group might elect to defer deployment-oriented requirements until the beta stage (aka Project Three).

Deliverables and Deadlines

  1. Due by Friday, January 31: Organize into teams on Basecamp. You’re choosing your team members for the remainder of the semester, so choose wisely. There may be need of one team of four, so indicate in the Basecamp thread if you’re open to taking on a fourth member.
  2. Due by Thursday, February 6: Pitch your team’s project to the instructor via Basecamp. You may opt to use as-is or refine any Project One pitch written by any of your team members. Alternatively, you may pitch an entirely new project idea. The instructor must sign off on your team’s pitch before you can proceed.
  3. Due weekly: Post team progress reports weekly on the class Basecamp. Aim to do these on Thursdays. Rotate responsibility among your team members for the weekly writeup of your progress and struggles. Reference your project’s repositories, commits, and release notes by URL as appropriate.
  4. Due by Monday, February 17: Schedule a mid-cycle conference with the instructor. Sometime during the week of Feburary 17, you and your team will have a virtual chat of about thirty minutes with the instructor. Watch for scheduling details on Basecamp.
  5. Due by Thursday, March 12: Post your final alpha release project to Basecamp. Provide a team-authored report of your progress and challenges during the alpha cycle. Note the number and frequency of alpha releases you made during the cycle, and preview the work your team anticipates for the upcoming beta cycle.
  6. Due by Thursday, March 12: Email self and group-member critique memo to the instructor. Write at least 5–7 sentences assessing your own work on the project so far, and for each group member a 3–5-sentence assessment.

Project Requirements

  1. You and your team must actively use some kind of communication hub for coordinating team work and communication (e.g., Slack, Discord, or a team-members-only Basecamp). It is up to your team whether to invite the instructor to participate. But that might be a good idea.
  2. You and your team must use GitHub issue-tracking and code-reviews via pull requests to coordinate your team’s work and project progress.
  3. You and your team must tag significant alpha releases according to the Semantic Versioning specification.
  4. You and your team must publish release notes on GitHub to accompany all tagged releases, even at the alpha stage.
  5. You and your team must write documentation for your system, both as a standalone file, such as a README.md, and as code-adjacent comments. You are encouraged to explore your options for generating documentation from inlined comments for the language you’re using (for example, JSDoc is a documentation generator for JavaScript).
  6. Your system must ingest data from one or more third-party sources: either a data API or data that you scrape, maintain, and prepare in an API-like way.
  7. Your system must implement at least one appropriate datastore. It’s possible that some parts of your system might rely on a database, and others on flat files, a hashed document store, or some other mechanism that persists data in the event of system restarts or crashes.
  8. Your system must deliver error-free, standards-compliant HTML, CSS, and JavaScript to the browser. Your HTML must be valid and semantic; your CSS must be written in standalone stylesheets and rely on intelligent approaches to feature detection; and your JavaScript must be unobtrusive (that is, written leveraging event handlers and wholly avoiding deprecated JavaScript attributes in your HTML, such as onload).
  9. Your system’s front end must deliver its core functionality to the browser even in the absence of JavaScript or CSS. CSS, JavaScript, and advanced front-end techniques—such as asynchronous requests, service workers, and web sockets—must be implemented in a progressively enhanced way.
  10. Your system must provide a well-structured data API in an appropriate, error-free data-serialization format, such as JSON or XML, and it must feature sensible, developer-friendly data and endpoints. You and your team should include coverage of your API in your documentation.
  11. Your system must include functional, unit, and integration tests on the back end, as appropriate, and visual regression-testing on the front end (e.g., BackstopJS).
  12. Your system must limit its reliance on massive, all-in-one frameworks. You may choose either a front- or back-end framework, but not both. For example, if you opt to use Bootstrap (which, yuck), you will have to craft the back end of your system yourself. Choose wisely.
  13. Your system should include one or more appropriate, leading-edge front-end development APIs. Options include local storage, service workers, web sockets, or any combination of elements that make up progressive web app architectures.
  14. Your system should judiciously include feature-specific libraries, modules, or other packaged dependencies. Challenge yourselves as a group to develop the feature from scratch first (that is, using your language’s built-in APIs and standard library), and decide later whether to incur the technical debt and inherent risks of third-party dependencies. Consider also the technical debt and inherent risks of developing your own feature, of course.
  15. Your system should support multiple runtime environments (e.g., development, staging, testing, production). Your system’s configuration must be readily shareable among members of your team. A system that tucks its configuration into a MySQL database, as WordPress does (which, yuck), is almost certainly a non-starter.
  16. Once deployed, your system must implement some type of continuous integration, continuous delivery, or continuous deployment method to safeguard and automate your deployment.
  17. Once deployed, your system must be monitored by some type of lightweight monitoring software or process manager, such as PM2. Ideally, monitoring will be integrated to the extent possible with your deployment automation.
  18. Finally, like any temperamental client or manager, your instructor may amend, alter, or complicate the requirements and deliverables listed here at any time—but must provide you reasonable notice, via Basecamp, should that happen.

Project Goals

  • Analyze complex computing problems and apply principles of computing and other relevant disciplines to identify solutions
  • Assist in the creation, execution, and ongoing revision of an effective project plan
  • Design, implement, and evaluate a computing-based solution to meet a given set of computing requirements
  • Communicate effectively in a variety of professional contexts
  • Function effectively as a member or leader of a team engaged in activities appropriate to web-systems integration tasks
  • Identify and analyze user needs and take them into account in the selection, creation, evaluation and administration of computer-based systems
  • Apply security principles and practices to maintain operations in the presence of risks and threats

Project Three: Web System Beta-Release Cycle

Due by Thursday, April 23, 2020

Project Description

In this second of two cycles, you and your team will push your system beyond its alpha stages to achieve greater stability and test coverage along with some kind of build pipeline and continuous-integration approach to produce and deploy a series of 0.x.x-beta.x releases.

Plan to include unit, functional, and integration test coverage as early in your process as possible. In fact, aim for 100% test coverage of your existing, alpha code before you move on to any other plans for your beta iterations.

Note that the requirements listed with this project are the overall system requirements for the final version to be delivered on Thursday, May 7. By the end of the beta cycle, you should have met all of these requirements. Be sure to take stock of them early in this cycle, and contact the instructor immediately if you’re concerned about any of them.

Deliverables and Deadlines

  1. Due weekly: Post team progress reports weekly on the class Basecamp. Aim to do these on Thursdays. Rotate responsibility among your team members for the weekly writeup of your progress and struggles. Reference your project’s repositories, commits, and release notes by URL as appropriate.
  2. Due by Thursday, April 2: Schedule a mid-cycle conference with the instructor. Sometime during the week of April 6, you and your team will have a virtual chat of about thirty minutes with the instructor. Watch for scheduling details on Basecamp.
  3. Due by Thursday, April 23: Post your final beta release project to Basecamp. Provide a team-authored report of your progress and challenges during the beta cycle. Note the number and frequency of beta releases you made during the cycle, and preview the work your team anticipates for the upcoming public-release sprint.
  4. Due by Thursday, April 23: Email self and group-member critique memo to the instructor. Write at least 5–7 sentences assessing your own work on the project so far, and for each group member a 3–5-sentence assessment.

Project Requirements

  1. You and your team must actively use some kind of communication hub for coordinating team work and communication (e.g., Slack, Discord, or a team-members-only Basecamp). It is up to your team whether to invite the instructor to participate. But that might be a good idea.
  2. You and your team must use GitHub issue-tracking and code-reviews via pull requests to coordinate your team’s work and project progress.
  3. You and your team must tag significant alpha releases according to the Semantic Versioning specification.
  4. You and your team must publish release notes on GitHub to accompany all tagged releases, even at the alpha stage.
  5. You and your team must write documentation for your system, both as a standalone file, such as a README.md, and as code-adjacent comments. You are encouraged to explore your options for generating documentation from inlined comments for the language you’re using (for example, JSDoc is a documentation generator for JavaScript).
  6. Your system must ingest data from one or more third-party sources: either a data API or data that you scrape, maintain, and prepare in an API-like way.
  7. Your system must implement at least one appropriate datastore. It’s possible that some parts of your system might rely on a database, and others on flat files, a hashed document store, or some other mechanism that persists data in the event of system restarts or crashes.
  8. Your system must deliver error-free, standards-compliant HTML, CSS, and JavaScript to the browser. Your HTML must be valid and semantic; your CSS must be written in standalone stylesheets and rely on intelligent approaches to feature detection; and your JavaScript must be unobtrusive (that is, written leveraging event handlers and wholly avoiding deprecated JavaScript attributes in your HTML, such as onload).
  9. Your system’s front end must deliver its core functionality to the browser even in the absence of JavaScript or CSS. CSS, JavaScript, and advanced front-end techniques—such as asynchronous requests, service workers, and web sockets—must be implemented in a progressively enhanced way.
  10. Your system must provide a well-structured data API in an appropriate, error-free data-serialization format, such as JSON or XML, and it must feature sensible, developer-friendly data and endpoints. You and your team should include coverage of your API in your documentation.
  11. Your system must include functional, unit, and integration tests on the back end, as appropriate, and visual regression-testing on the front end (e.g., BackstopJS).
  12. Your system must limit its reliance on massive, all-in-one frameworks. You may choose either a front- or back-end framework, but not both. For example, if you opt to use Bootstrap (which, yuck), you will have to craft the back end of your system yourself. Choose wisely.
  13. Your system should include one or more appropriate, leading-edge front-end development APIs. Options include local storage, service workers, web sockets, or any combination of elements that make up progressive web app architectures.
  14. Your system should judiciously include feature-specific libraries, modules, or other packaged dependencies. Challenge yourselves as a group to develop the feature from scratch first (that is, using your language’s built-in APIs and standard library), and decide later whether to incur the technical debt and inherent risks of third-party dependencies. Consider also the technical debt and inherent risks of developing your own feature, of course.
  15. Your system should support multiple runtime environments (e.g., development, staging, testing, production). Your system’s configuration must be readily shareable among members of your team. A system that tucks its configuration into a MySQL database, as WordPress does (which, yuck), is almost certainly a non-starter.
  16. Once deployed, your system must implement some type of continuous integration, continuous delivery, or continuous deployment method to safeguard and automate your deployment.
  17. Once deployed, your system must be monitored by some type of lightweight monitoring software or process manager, such as PM2. Ideally, monitoring will be integrated to the extent possible with your deployment automation.

Project Goals

  • Analyze complex computing problems and apply principles of computing and other relevant disciplines to identify solutions
  • Assist in the creation, execution, and ongoing revision of an effective project plan
  • Design, implement, and evaluate a computing-based solution to meet a given set of computing requirements
  • Communicate effectively in a variety of professional contexts
  • Function effectively as a member or leader of a team engaged in activities appropriate to web-systems integration tasks
  • Identify and analyze user needs and take them into account in the selection, creation, evaluation and administration of computer-based systems
  • Apply security principles and practices to maintain operations in the presence of risks and threats

Project Four: Web System Public-Release Sprint

Due by Thursday, May 7, 2020

Project Description

Due to the semester’s time constraints (and an imagined impatient manager), this final cycle will deviate from the measured six-week cycles for your system’s alpha and beta releases, and instead focus on a two-week sprint to ship a 1.x.x version for public release.

Deliverables and Deadlines

  1. Due by Thursday, May 7: Post your final public release project to Basecamp. Provide a team-authored report of your progress and challenges during the short public-release cycle. Note the challenges you had operating on a much shorter development cycle, and preview the work your team would do next, were the project to live on beyond the current semester.
  2. Due by Thursday, May 7: Email self and group-member critique memo to the instructor. Write at least 5–7 sentences assessing your own work on the project this semester, and for each group member a 3–5-sentence assessment. Optionally, if you have suggestions for the instructor on how to improve this class in the future, please include those as well.

Project Requirements

  1. Tag significant public releases, including release candidates, according to the Semantic Versioning specification
  2. Your system must be deployed to a publically available server, if you’ve not already done so.
  3. Your deployment strategy must include the ability to roll back to an earlier, known stable version.
  4. Once deployed, your system must implement some type of continuous integration, continuous delivery, or continuous deployment method to safeguard and automate your deployment.
  5. Once deployed, your system must be monitored by some type of lightweight monitoring software or process manager, such as PM2. Ideally, monitoring will be integrated to the extent possible with your deployment automation.

Project Goals

  • Quickly revise a system’s core functionality and features to ready an initial public release.
  • Learn to automate deployment using a method like CI or CD to safeguard its uptime and availability.
  • Monitor your system in production.