Your specification should define the scope of the course-connected portion of your project and should contain a number of user stories that each identify the who, what, and why of each piece of functi

Your specification should define the scope of the course-connected portion of your project and should contain a number of user stories that each identify the who, what, and why of each piece of functionality.

(I included my project proposal) This just needs to be very simple not include everything! Includes 2 assignments....

User Stories

A user story is a requirement statement that identifies the basic characteristics of a piece of functionality: the role of a user with an activity or goal in mind, the desired action they would like to take, and their motivation for using that functionality.

A user story usually initially takes the form

As a _________________ (who: user role)

I want to _________________ (what: capability/activity/goal)

so that I can _________________ (why: motivation).

Once you’ve written a number of user stories, you can collect them into groups to identify the different user roles your application should support, the major types of activity your application should support, and the different types of motivations users bring to your application. You can add these categories to each of your user stories in order to identify themes you can focus on independently while working on the application. This will help you to focus your efforts and complete working software in small increments.

You can capture these user stories and organize them in many different ways, but often the easiest method is to write each story on a 3”x5” index card with a marker or thick pen. This way, you can easily read what’s on the card, and can easily shuffle them and re-shuffle them into categories and themes, noting their categorizations and themes with annotations in the margins or on the backs of the cards.

Prioritization and the MVA

Once you’ve developed your collection of user stories and identified the categories and themes among them, you will want to prioritize those themes and decide which of them need to be part of your minimum viable application (MVA). You may decide that some themes can easily be split into multiple phases of implementation, allowing you to prioritize a portion of that theme for early development and other portions of that theme later.

Once prioritized, identify among the highest prioritized themes those that are important to include in the minimum viable application. Then, for those themes, identify whether each user story involves creating new capabilities in the browser-based client application, in the server application that supports it, or in both. If there are portions of the same user story that involve creating new capabilities in both applications, you will need to make a note on the story of what portion of the functionality belongs in the server and what portion belongs in the client.

These MVA-relevant themes and their user stories should then be captured in a project board in your project Github repository. You can find the project board feature under the Projects tab of your project repo. For more information on project boards, see the Github documentation here.

Your project board will serve as a guide for you during development of the next three assignments, so it’s very important that you create the relevant cards there.

The Specification Document

Once all that is done, you will need to write a specification document identifying the goal and synopsis of the project based on your proposal and discussion with the instructor, the major user roles, themes, and other categorizations identified, and the portion of the work identified for the MVA with reasons for that prioritization.

Your specification document should reference your project board and should contain a link to the project repostory within the document.

Submission

The project board must be completed in your project Github repository.

Your proposal document can be written in whatever software you wish, but must be submitted as a PDF format document.

Your proposal document must be submitted via the Canvas assignment, and must be submitted at least once before the deadline (along with organizing and collecting your story themes relevant to the MVA in your Github repo) in order to be marked complete.

Feedback

I will review and provide feedback on both the project board and the document.

You will receive feedback as I receive your proposals. I will provide feedback as soon as possible, and at a minimum within 72 hours of submission.

As before, if you submit early, you will receive feedback early, and may have the opportunity to act on feedback and resubmit a revised work prior to the deadline.

P2: Web Client

Once you have completed the project specification and project board, it’s time to start working on your application. To start, we’ll look at the browser-based, client side of the work.

ScheduleIntroductionThu, Oct 8, 2020Discussion/Lab Class PeriodThu, Oct 8, 2020Discussion/Lab Class PeriodTue, Oct 20, 2020Discussion/Lab Class PeriodTue, Oct 27, 2020Office hoursBy appointmentAssignment DueThu, Oct 29, 2020 The Tools

To do this, we’ll use JavaScript with HTML and CSS, as you might expect, but we’ll also use three key JavaScript libraries and three infrastructure tools/services:

JavaScript Libraries

• React - a library for building dynamic web interfaces using JavaScript in a componentized and manageable way. Along with React, create-react-app is a companion library that scaffolds a web-based application for you using React for components. (This scaffolding piece will be demonstrated for you in class.)
• Jest - a testing library included with the project scaffold created by create-react-app that allows testing your code. Along with Jest, react-testing-library is a companion library that provides easy ways to render components and assert properties on them when writing automated tests for your user interface.
• JSdoc - an automated documentation generation library that reads formatted comments and creates a documentation website for your application.

Infrastructure Services

• Github - a web service providing hosting and additional features for the git distributed version control system. You’ll be using git and Github to manage your codebase.
• Travis CI - a continuous integration platform that you’ll use to ensure every commit you push to Github passes all automated tests.
• Heroku - a platform-as-a-service that allows easy deployment of web-based applications that you’ll used to deploy your application so that it’s viewable from anywhere.

Requirements for the Assignment

You will start by negotiating the set of requirements you will attempt to implement for this portion of the project with the instructor.

Once these are decided and you have committed to a specific set of user stories to work through, you will implement as many of them as you can before the deadline.

️ Functional Requirements

1. The application must be viewable through a web browser.
2. The application should enable as many of the user stories you committed to as possible, ensuring that each is implemented in alignment with the user role and motivation behind them.

Source Code, Process & Deployment Requirements

1. Code for the application should be well-organized, using components and folders to keep related code together.
2. The application should make use of Github for version control. Commits should be small, be well-described in their commit messages, and contain a single change to the application.
3. All code for the application should be well-tested. (This means that for each function you write, you should write at least one, and possibly several, tests.) Automated tests should run on every commit and pull request to the repo (see Travis CI in the Tools section above).
4. The application should be well-documented (see JSdoc in the Tools section above).
5. The application should be deployed to the Internet (see Heroku in the Tools section above), and should be live (that is, publicly viewable via the Internet in a browser).

Submission

This assignment must be submitted as a link to your project board in the Canvas Assignment. (You may also submit a link to a filtered view of your project board containing only relevant user stories, if you wish.)

While working through your project board, I recommend you convert each user story card to an issue on the repo. Then, as you write code to implement the user story, you can do that on a new branch in the repo and submit that branch as a Github Pull Request. Your PR will provide a good mechanism for feedback on your work, and can be linked back to the issue to provide for easy tracking of what code changes implemented what features in your application.

If you don’t feel the code in your PR is ready, but still need early feedback, you have the option to create your PR in Draft mode, which will indicate to your reviewer(s) that you are requesting feedback at an early stage of implementation (as well as prevent accidental merging to the main branch of the repo).