Iteration 4 Details for MPCS 51205

Each iteration will deliver an incremental accretion of work toward the final project deliverable.  Some assignments will require you to work individually and each team member will submit his or her deliverable, and other assignments will require you to work as a team and submit a single team deliverable.  Generally (see specifics within each Iteration), each student will be responsible for delivering some piece of the work (documentation, code, etc.).  You will be evaluated on the clarity and depth of your analysis of these and other deliverables.  "Deep Thinking" as well as "Shallow Thinking" are generally obvious.  Deep Thinking requires time and....thought.

Unless use of a tool is specified, you may take pictures of whiteboards, papers, napkins, etc. as submission artifacts.  From a remote collaborative design perspective, previous teams have happily leveraged free tools including excalidraw.com, which allows for collaborative brainstorming among remote team members.  However, some artifact deliverables will need to be in the form of formal models.  When a formal artifact is required, it will be so specified.

See the syllabus for information on grading.  Turning in Iteration assignments is required.  Submit your assignments as a tarball to the repository according to the directions on each Iteration page.

Iteration 4   Due: 5:00 pm, December 4, 2023 for all teams

This is the Final Iteration which will include your delivery your coded auction system.  You will have several weeks to produce this fourth and final iteration.  You are to work together as a team on these deliverables except when you are instructed to individually deliver something.

High Level Architecture and Domain Model: 

Considering the functional and technical requirements of the system, revisit your high level architecture and list of candidate classes. 

Deliverable One:  Final Architecture Deliverables:

As a team, continue your development of your high level architectural model of your proposed solution.  At this point, we will expect that protocols and technologies (ActiveMQ, RMI, sockets, TCP/IP, SOAP, REST, etc.) will begin to be detailed in your model. 

Additionally, produce any revised User Stories for your Microservices in scope.  Modify your user stories to reflect the planning changes you have encountered for your final deliverables.  Consider the functional and technical requirements of the system, and your design of the high level architecture and initial domain model.  Based on the functional requirements of the system and your architecture, existing user stories and current domain models, your requirement for this iteration is more code and tests that implement more of your microservices.  At the conclusion of this iteration, your domain models should be well fleshed out in terms of the models themselves.  You are to work collaboratively in developing your code and tests, whiteboarding (and documenting) various design alternatives, continuing to use CRC cards to identify salient classes in your models, finally delivering an updated UML model that will represent your "final iteration model".  Your code base should now be mature, and your tests should be running and verifying the fact that your system is coming to functional fruition.

If there are any user stories left undefined, each member of the team is responsible for (as in the previous iteration) for individually delivering these additional user stories fleshing out the model for whatever microservices they are responsible for (note you do not have to stay with "your" particular microservice.  The team members are free to flesh out whatever stories still need to be written.  These will detail user intentions as well as system responsibilities.  As in the previous iterations, the verbiage should be a simple description of one task or interaction of the system you envision.  Your user stories should continue to be both meaningful and descriptive from the point-of-view of users in some role or set of roles as they derive value from a system that will  embody the purpose or intentions underlying the user interaction.

Deliverable Two:  Final coded functioning auction system.

You are to produce the final code for your auction system deliverable.  You will continue to write tests (coded by hand or developed using an existing harness such as junit, postman, etc.) that verify that your code is producing the results you wish. 

Continue to look at your user stories and design models, and develop whatever remaining classes and APIs are need within this final iteration.  The goal in two weeks is to demonstrate before the class what your team's auction system.  As before, feel free to stub out whatever functionality you don't yet have time for or understand, but of course, at some point soon, stubs need to become functional code. 

Deliverable Three:  Presentation of your team project and Post-Mortem Analysis

This final deliverable brings together all your work and packages it for presentation and deployment.  During the last class, each team will be expected to talk for about 30 minutes, giving a full description of your auction system, including design and implementation, a live demonstration of the system running, and a post-mortem presentation on your project and team experience.  You should begin to prepare with a draft presentation which will consider the following topics (in addition to anything else you're interested in):

Description of your development methodology & how well (or not) it worked
Context Map and High Level Architecture
Microservice Architecture and Technology stacks (per Microservice)
Pain Points (technical and organizational)
What you thought would be easy that turned out hard
What you thought would be hard that turned out easy
Your Proudest Moment (TM) (aka the breakthrough)
What you thought was the coolest thing you discovered or produced (code, design)

You will deliver this presentation, along with a demonstration of your final project and a walk-through of your code during the final class.


Deliverable Four:  Finish documenting your Architecture Decisions

Referring to Michael Nygard's documentation of ADR usage here and https://adr.github.io and https://adr.github.io/madr/, tidy up and finish documenting your key architectural decisions.  You should store your ADRs in your github repository.
Submission:

For Iterations:

Have your designated Team Lead upload your team's IterationN files and any supporting materials to the repo. Please include a README text file that contains any instructions or additional details for the TAs to assist with grading.

Setup:

When you open the invitation URL in a browser tab, you will have to complete the following steps:

Github may ask you to grant permission for GitHub Classroom to have access to your GitHub account. If you are asked this question, you should say yes and grant access to Github Classroom.

You must click “Accept this assignment” or your repository will not actually be created. Do not skip this step!

If you run into any issues, please ask for help.