|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|
|7||7.1, 7.2, 7.6|
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.
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 may be 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.
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:
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).
You can find information about using wikis here. Here is an example of what a persona wiki page would look like; you can find the markdown here.
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 identify—creatively—additional features.
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 aim of the software prototype is to test and clarify product ideas and to 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 that you use throughout the development of your software product.
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 are making in these architectural decisions.
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.↩
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.
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.
Submit the following:
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 microservices 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.
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.
Document your microservice on your GitHub wiki page for your project. Include the following:
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.
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; you 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:
Submit the URL to the wiki page.
Create a project wiki page called “Testing.” On that wiki page, include the following information:
Submit the URL of your wiki page.
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.
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?