Home » Teaching » CSCI 40500/77100: Software Engineering (FA ’24)

Subscribe

Archives

Categories

Attribution-NonCommercial-ShareAlike 4.0 International

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.

CSCI 40500/77100: Software Engineering (FA ’24)

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.

Ultimately, the vision you come up with now may not reflect what you eventually decide your project to be. In other words, your vision may change during the course of the project’s development. Indeed, that is exactly the motivation behind agile methods. Thus, at the point, you only need to have an initial idea of what the project should be.

Clearly label your group’s product vision in your project’s README.md file in your Git repository created by GitHub Classroom. Then, push your changes up to GitHub. Use markdown to write it. For example, your README.md file may look as follows:

# Project 10

## Product Vision

Your product vision here.

Finally, submit the permalink of your project’s README.md file by the deadline on Bb (do not put it in the comment text box, instead, create a submission). You must submit the permalink (the URL is insufficient). An example permalink is https://github.com/CSCI-40500-77100-Fall-2024/project-7/blob/8ca0d62fa8d2b2ded2c13f336659e5f8e5f3a94b/README.md (note that a permalink includes the SHA1 hash).

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.

While it is acceptable to use firebase and other kinds of “app” generators for the prototype, such technologies should be avoided for the final project deliverable. You need to write code to apply the lessons from the course.

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. If your project is deployable, e.g., web app, mobile app, deploy your prototype. 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 on Bb.

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; instructions for Chrome). 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 hereHere 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.

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-Fall-2024/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 decomposed 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 permalink to your project’s README.md file on GitHub Classrooms. Finally, create a submission (do not enter the URL as a “comment”).

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. 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

Resources


  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 ↩︎