Lectures

1. Software Products
2. Agile Software Engineering
3. Features, Scenarios, and Stories
4. Software Architecture
5. SQL vs NoSQL
6. Microservices Architecture
7. Serverless Computing
8. Security and Privacy
9. Testing

Assignments

Chapter	Questions
1	1.2, 1.3, 1.6
2	2.1, 2.4, 2.8
3	3.1, 3.5, 3.9
4	4.2, 4.4, 4.10
5	5.1, 5.7, 5.8
6	6.5, 6.9
7	7.1, 7.2, 7.6
9	9.1, 9.3

Project Deliverables

Product vision

Develop your group’s product vision for the semester-long project. Use the vision template and example. For information sources for developing a product vision, see Table 1.2.

Proof-of-concept prototype

Once your project vision has been documented, it’s now time to make your first project prototype. Per Ch. 1 of our textbook, the prototype at this stage will most likely be very bare (skeletal), may not use the technology that your final product will use, and maybe eventually thrown away. In other words, this is a proof-of-concept prototype; use it to assess the feasibility of your product and elicit the features that you will want it to have. You can use this prototype to build your product backlog (Ch. 2). This first prototype can be very simple, e.g., only showing pop-up messages of the functionality that will eventually be present.

Push your code to your GitHub Classroom repository on the master (main) branch. In your README.md file, explain how to use the prototype. Then, create a release of your product in GitHub (instructions here). In Bb, enter the URL of the release by the deadline. You may work on it during the lab portions of our class. Your group may be asked to present their prototypes in class.

Product backlog

Use your proof-of-concept prototypes to create a product backlog for your software product. It should be similar to the example given in Table 2.6:

1. Create a project in your repository as shown in the tutorial.
2. On the Kanban board, create columns corresponding to the states in Table 2.7.
3. Create PBIs as “notes” in the (first) “ready for consideration” column. You may want to ask potential users to use your prototypes in order to elicit feedback. Such users can be, for example, family members or other members of your household, or other classmates.
4. Refine the PBIs and transition them to appropriate states (columns) from Table 2.7. Do this by performing the activities detailed on slide 26. Higher priority items should go towards the top of the board.
5. Create issues out of each PBI in the (last) “ready for implementation” column using the issues feature of your GitHub Classroom repository. The note should have an option to convert them to GitHub issues.
6. For each issue, label (using the issue labels) it as either a feature, user request, development activity, engineering improvement, etc.
7. Estimate the time to do each issue by adding a label (e.g., 1h, 1d, 1/2d).
8. Submit the URL of your project.

Personas, scenarios, and user stories

Work together to write at least two different personas (example) for your project. For each persona, write one or more different scenarios (example). You need at least one scenario based on a persona for each team member. One persona can have multiple scenarios. Team members work individually on the scenarios. Next, meet with your team and discuss the proposed scenarios. Refine the scenarios together based on the discussion. Then, for each scenario, write three user stories (example).

1. Write the personas on your project wiki. Each persona should have its own project wiki page. Again, there should be at least two personas. You work together on this part as a team.
2. Write your initial scenarios on the same wiki page under the persona description. Each team member works individually on this. Thus, there should be at least one scenario per team member.
3. Next, work with your team to refine the scenario(s) as described above.
4. On same the wiki page, write at least three user stories under each scenario. Number the sentences (1, 2, 3, etc.).
5. Create a personas wiki page that links all of your personas together in a bulleted list. Use markdown!
6. Print the persona’s wiki page(s) that includes the scenarios you initially worked on individually as a PDF file from your browser and upload it to Bb. Ensure that the URL is present on the PDF (example). We want to ensure that every team member works on at least one scenario. In the Bb comments box, indicate the name of the scenario you worked on.

You can find information about using wikis here. Here is an example of a persona wiki page; you can find the markdown here.

Feature identification

Work with your team to identify additional features using the user stories generated as part of the Personas, scenarios, and user stories deliverable. You can find an example of a feature derived from user stories using the template shown in Figure 3.11 in Table 3.11.  As features are identified, the team should discuss and generate ideas about related features. The output of the feature identification process should be a list of features that you use for designing and implementing your product.

Use your lab time or schedule a meeting to discuss the scenarios and stories with your team and make an initial list of additional features on a “whiteboard.” You don’t need a lot of detail until you are ready to implement the features. The features identified should then be added to your product backlogs by creating GitHub issues and labeling the issues with the enhancement label. Finally, submit the URL of your enhancement issues (e.g., https://github.com/CSCI-40500-77100-Spring-2021/project-1/issues?q=is:open+is:issue+label:enhancement).

Although it makes sense to start identifying additional features from the user stories and scenarios you created in the last deliverable, you should also think creatively about alternative or additional features that help users work more efficiently or do things differently. As such, the additional features you identify as part of this deliverable need not only be derived from user stories and scenarios. Instead, you should use these as a tool to creatively identify additional features.

Prototype extension

Once you have developed your initial list of feature ideas as part of the feature identification deliverable, extend your existing prototypes to demonstrate these features. The software prototype aims to test and clarify product ideas and demonstrate your product to management, funders, and potential customers. Once you have completed the next prototype version, create another release and submit the URL of the next release by the deadline (do not put it in the comment text box, instead, create a submission) as you did in the Proof-of-concept prototype deliverable.

Once again, use the new prototype version to refine your product backlog, adding new details to features or even dumping (closing) features (that “won’t be fixed”). Transition the features through to appropriate states (columns) from Table 2.7 on your Kanban board that you created as part of the Product backlog deliverable. You don’t have to submit the board for this deliverable. Instead, it should be something you use throughout your software product development.

Layered software architecture

This exercise will facilitate, amongst your team, the design and discussion of your software product architecture. This deliverable should do this before starting to code the final product.1 Your team should agree on priorities and understand the trade-offs you make in these architectural decisions.

1. Using Figure 4.4 and Table 4.4, decide on the most important qualities of your software.
2. Using Figure 4.10 as an example, figure out how many layers to include in your system.
3. Start to populate these layers, as done in Figure 4.11. This diagram will show how the architectural components will be distributed and communicate with each other through the layered architecture.
   1. Involve your whole team and try out various decompositions to help understand their advantages and disadvantages.
   2. By trial-and-error, stop when you have what seems to be a workable decomposition architecture.
4. Using Table 4.8 as a guide, research and decide the technologies you will use in your product.

The steps outlined above should lead to a description of your product architecture that sets out the fundamental structure of your software and serves as a reference for its implementation. As such, put all of this information (important qualities, architecture, technologies chosen) in the README.md file for your project (note that this includes an architecture diagram). Next, submit the URL to your project’s README.md file on GitHub Classrooms. Finally, create a submission.

---

^{1. Note that a prototype aims to help you understand more about the product you plan to develop. Thus, it would be best if you implemented prototypes as quickly as possible.↩}

Containerize your project

Introduction

In Chapter 5, we learned that containers are a great way to move your application to the cloud. For example, they allow you to switch between cloud providers fairly easily. There are also other benefits, like onboarding new developers without worrying about them having all of the dependencies for your app.

Instructions

In this assignment, you will containerize your software product using Docker, which we discussed earlier in Chapter 5 (please revisit if needed). You will first need to create a Docker container for your application that specifies all of the dependencies your software product needs to run. This is done using a Dockerfile (here‘s an example). Then, you run Docker to build the Docker image (the container) for your app. Once that’s done, publish your Docker image to Docker Hub. Finally, create a “Docker” section in your README.md file that details how to run the image (here‘s an example). After this assignment, you will be familiar with containers and Docker, which you may later use to have your app use cloud-based services.

Submission

Submit the following:

1. The URL of your Docker image on Docker Hub (example: https://hub.docker.com/r/caseycas/gitcproc-docker).
2. The URL of your README.md file Docker section with the instructions on how to run your Docker image (example: https://github.com/caseycas/gitcproc#user-content-docker).

Resources

1. Docker Overview: Includes a tutorial.
2. Docker Student Developer Kit: Under the section entitled “Getting Started with Docker,” there are several resources, including documentation, slides, and labs.

Add a microservice

Instructions

Replace a part of your software product with a microservice. Identify a good microservice from your existing (monolithic) application using Table 6.1: Characteristics of microservices. You don’t have to refactor your entire application into microservices (unless you want to); for this assignment, you only need to replace a small part of your application with a (single) microservice. Some examples of microservices are found under “supporting functions” on slide 11. Remember that your microservice cannot use your existing shared database; it needs to be completely separate from the rest of your application. If it works with data related to your application, you’ll need a mechanism to keep the data eventually consistent.

Your microservice should include functionality that is common to all microservices, namely, message management, UI implementation, failure management, and data consistency management. You choose to use a framework for creating micro services to reuse this common code from existing infrastructure. Also, ensure that you are using good decomposition guidelines when designing your microservice.

Once you have designed and implemented your microservice, you’ll need to host it. There are several different ways to do this. First, you can use AWS if you like (student accounts are available and “free-tier” infrastructure). You can find directions for hosting a microservice on AWS here. Second, either you can containerize your microservice (see the last deliverable for details on how containers work) or use serverless functions (e.g., AWS Lambda). Other possibilities exist.

Lastly, you’ll need to call your microservice from your application where you replaced the legacy functionality. For this, develop a REST API for your microservice. Your main application will call your new microservice using this REST API. To create the API, you may want to research using existing frameworks for creating REST APIs since REST APIs are fairly common. To ensure resilience, either use a timeout or the circuit breaker pattern in communicating with your microservice. In the timeout case, implement a retry mechanism.

Notes

Although you are required only to implement a single microservice that your main application calls, that microservice may consist of multiple, smaller microservices, depending on your design. If that is the case, you’ll need to implement service communication.

Submission

Document your microservice on your GitHub wiki page for your project. Include the following:

1. A description of the microservice’s design, including diagrams.
2. Instructions on communicating with the microservice (i.e., document that REST API for the microservice). Ensure that the service is publicly accessible. During grading, we should communicate with the service using curl, as demonstrated during the lecture.
3. A description of how the microservice implements the characteristics of microservices.
4. A description of whether any data consistency mechanisms were needed and how they were implemented.
5. How the service is called from your application, e.g., synchronously, asynchronously.

Then, submit the URL of the wiki page on your GitHub project. Ensure that you are using the project repository assigned to you via GitHub Classroom.

Adding security/privacy

Add to your project one of the security or privacy features discussed in Chapter 7. It cannot be one that currently exists in your project; it must be a new feature. For example, you could add two-factor authentication (2FA), re-authenticate users immediately before performing a sensitive interaction, implement a session timeout (automatic logout), encrypt particular database fields (like passwords), implement (aspects of) the General Data Protection Regulation (GDPR), or publish a terms-of-service document that users must agree to to use your product.

Create a project wiki page that describes:

1. The security/privacy feature you added.
2. How you implement the new security/privacy feature.

Submit the URL to the wiki page.

Adding an automated unit test suite

Instructions

1. Using a testing framework (e.g., unittest, Mocha, Jest) of your choice, add at least two unit test classes to your project similar to what is done on slides 25 and 27–28. Each test class must have at least five unit tests (e.g., methods starting with test_). This must be done using a testing framework.
2. Create a test harness similar to that in slide 29 if applicable for your testing framework. Some frameworks do not require this step.
3. Set up continuous integration for your project that invokes your test suite each time there is a new commit to your project in your GitHub repository. You may use services such as Travis CI, GitHub Actions, Jenkins, and AWS CodePipeline.
4. Add a badge to your README.md file that indicates the testing status of your project.

Submission

Create a project wiki page called “Testing.” On that wiki page, include the  following information:

1. URLs to the code of the two test classes that you created in GitHub. If you created more than two classes, use a single URL representing the entire test suite code (e.g., package, module) in GitHub (example).
2. URL to the code of your test harness (runner) in GitHub (if applicable).
3. URL of a recent test run of your project (example).
4. URL to the section of your README.md file representing your test badge (example).

Submit the URL of your wiki page.

Notes

You may wish to run your tests via a build system appropriate for the language for which your system is written (some build systems, e.g., Buck, are language agnostic). Example build systems include Gradle, Maven, Make, npm, and Grunt). Many of these build systems support multiple languages. Here is an example of a Maven configuration for running unit tests.

Extra Credit

During the lecture, we mentioned that, for SaaS, it is important that (form) validation be performed both on the client and server. Why is it insufficient to have validation only on the client? What is the downside of performing validation on both tiers?

Resources

Add new link

Link name
Link address