CMSI 543 / SYEG 557: Semester Project Page

Project Basics

You will be responsible for designing, documenting, and implementing a small scale of your own this semester. The idea is for you to get hands-on experience of actually going through all the steps of the entire process, using Agile for your project development. To that end you must do:

• Form a team of FOUR PEOPLE. Please do not try to do this with less if it can be helped, although sometimes the total class size may mean a team of three must be made. If you come up with a group of five, we will work together to re-assign someone to a different group.
• Come up with a project idea. This could be a database, a web app, something using AWS or Google Web Services, or basically anything that you'd like. HOWEVER, be aware of the time considerations and don't be too aggressive. Remember that the focus of this class is on the AGILE SOFTWARE PROJECT MANAGEMENT aspects, NOT the development of the application itself. The significant 'wow' factor for the software is not really an issue — the project management of the software project IS the issue.
• Document the design in a design document; this will be explained during the semester
• Keep track of all code and documentation in a GitHub repository; note that this *MUST BE* a public repository. If you are working on something that has proprietary data, that's fine, you don't need to check your data into your repo, but you *DO* need to check your CODE into your repo!
• A good way to document things in GitHub is using the Git Wiki page that is part of your git repository. Another way is to use the README.md file in your repo, which you should be using anyhow for information about your project. There are other ways to do documentation, too, including [*gasp*] what's known as a loose-leaf notebook, so whatever floats your boat is fine, as long as your project is documented!
• PLEASE WORK IN TEAMS! This doesn't mean one person does the documentation while qnother one does the implementation while a third does the user stories while a fourth does the burn-down tracking or velocity. It means, ALL of you will work on ALL PARTS together. Remember this is a model of an Agile project and the name of the game is TEAMWORK. To that end, I'll be making the second half of the class period each week a 'group meeting time' so you will have at least one hour every week as a group.
• REMEMBER THE BIGGEST PART OF THIS PROJECT is Agile project management. Without being totalitarian about it, you must have some sort of project plan in place, which must be included in your repo. FOR YOUR OWN BENEFIT, this should include some type of regular status report so that you can track your progress. In addition, because you are working in teams, you will need to have regular meetings – BE SURE TO DOCUMENT WHAT GOES ON IN THOSE MEETINGS so you can remember design decisions, who is doing what, when it is supposed to be done, etc.
• Finally, make sure that you ALL have the same knowledge! Any one of you should be able to take over the others' tasks in case one of you gets hit by the proverbial bus.

Schedule of Deliverables

The following deliverables will be due on the dates indicated:

1. Preliminary Project Design document: week 6
2. Detailed Project Design document: week 11
3. Project Demonstration: week 16 – 17

Document Section Descriptions

Preliminary Project Design

You must have the following as part of your preliminary design:

• Section 1.1 – Project description, project management style used, potential users, maybe some other stuff
• Section 1.2 – Preliminary project requirements; these can be formalized as an SRS, an ARD, or can be a list of user stories. Try to break the project up into a CSCI breakdown which will provide an outline of the parts of the project in a hierarchical way. Note that this requirements specification is a LIVING DOCUMENT which you will need to update at several stages during the development of your project.
• Section 1.3 – Preliminary design description, including diagrams and text explanations; this should show graphically the things you discuss in text in the previous section, but only needs to be a high level or top level diagram or two.
• Section 1.4 – Preliminary development schedule; this just needs to be a basic idea of what parts will be developed in what order, and a SWAG at what will be in each iteration. Since you don't know all the details at this point, the focus should be on the functional decomposition of the project and a first shot at what might be done together as part of a single MVP. Focus on the parts you have specified in Section 1.2. DO NOT SIMPLY LIST THESE THREE DELIVERABLES and their due dates as your preliminary schedule ~ put some thought into the durations and the order of your development for the parts.
• Section 1.5 – Development tools, which is just a listing of what software you'll need to use to develop your project; for example, an editor, a UI tool, perhaps a compiler, or a linker, or a browser used to test your web pages, an Agile project tool, etc.

Detailed Project Design

You must spend some time to expand your Preliminary Design into a new copy of the document. Normally you would update the original, but for ease of tracking class deliverables for evaluation purposes you need to do two documents. You should have the following as part of your detailed design:

• Section 2.1 – Project description, project development style used, potential users, maybe some other stuff; this will be an expanded version of section 1.1 of the Prelimineary Design that has more detail which has been uncovered during the initial development phase. The way to do this section is to copy what you have in section 1.1 pf the previous deliverable and then add more detail to it.
• Section 2.2 – Detailed project requirements; this time you will focus on the AGILE type of requirements, namely user stories using the Agile language for the requirement language.
  Now that you have some ideas of what your requirements and user stories are and have probably built an initial concept or prototype, try to translate those ideas into some Agile requirements using the As a ______ I want ______ so that ______ language. If you had epics in the preliminary document, break those down into smaller child stories for this part. You must also add AT LEAST ONE ACCEPTANCE CRITERIA to each of the child stories so that you can test and prove that the requirement is met.
  As the development proceeds, you will need to make sure that things you've found out, questions you've answered, and other questions that you've thought of are all documented in the language of the requirements in this section of the document. You can also make sub-sections in this part that provide better document organization. For example, you might create a sub-section 2.2.1 that is called Design Decisions and document those kinds of things there. You could make a sub-section 2.2.2 that is called Front End Requirements for the user interface section and put all the child stories and their acceptance criteria for that part of the project into that section.
• Section 2.3 – Detailed design description, including UPDATED AND EXPANDED diagrams and text explanations; feel free to include the original diagrams from your preliminary design, but add some others that show more detail. Diagrams DO NOT need to be UML, but please name them properly. Don't draw a simple data flow diagram and then label it as a UML Class Diagram or a UML Use Case Diagram. Instead, label it Data Flow Diagram, which is what it is.
  If you WANT to use UML for your diagrams, that would be great! Check out the copy of the book UML Distilled that I have left for you in my repository at the following link: [go here!]
  If you get stuck or need some advice, let me know and I'll be glad to help!
• Section 2.4 – Detailed development schedule which shows the iterations, which user stories are destined for which sprint, the total number of story points for the project, total number of story points for each sprint, etc. If you have completed an iteration already, show that it is complete. If you've done two, show that both are complete. If you are using an online Agile tool, like Trello, put a link to your project board website in the document as well.
• Section 2.5 – Project status, which shows the current product backlog, the user stories in the current sprint, and what has been completed. There should also be a burndown plan for the sprints, and a burnup plan for the project as a whole.

Demonstration

You will demonstrate your project in class, showing the current MVP that the last completed iteration has produced. There will be a presentation, with slides using the following format:

1. slide 1 — Title slide
   
   • name of project
   • project team members
   • date
   • LMU logo
2. slide 2 — Purpose of project
   
   • why was this a good fit?
   • why were you interested?
   • why is this a worthwhile project?
3. slide 3 — Project goals
   
   • what the project accomplishes
   • 3 - 4 bullets
4. slide 4 — Project description
   
   • concept of operation ~ how it works
   • some idea of planned system data flow
   • this might require two or even three slides
5. slide 5 — Project planning
   
   • project management tool[s] used
   • screen shot of current board or tool
   • burn-up plan for project
   • burn-down plan for current iteration
6. slide 6 — Agile method slide 1
   
   • what method: Scrum, Kanban, Lean, …, or what?
   • why did you choose this method?
   • did it work well?
7. slide 7 — Agile method slide 2
   
   • what were the advantages of your tool
   • what were the drawbacks of it
8. slide 8 — Demonstration
   
   • demo of what you have working
9. slide 9 — Project challenges slide 1
   
   • describe a challenge that you encountered
   • describe how you mitigated that challenge
10. slide 10 — Project challenges slide 2
    
    • describe a different challenge that you encountered
    • describe how you mitigated that challenge
11. slide 11 — What changed during development
    
    • describe something you had to change/modify/re-think during development
    • what happened to force that change?
    • was it a substantial change [a pivot] or just a minor adaptation?
    • what would have happened had you persevered [stayed the course]?
12. slide 12 — Thank you and questions