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:
- Preliminary Project Design document: week 6
- Detailed Project Design document: week 11
- 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 DELIVERABLES AND THEIR DATES!
- 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, &c.
Detailed Project Design
You must spend some time to expand your Preliminary Design into a new copy of the
document to have the following as part of your detailed design:
- Section 2.1 – Project description, project management 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.
- 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 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 ___
. If you have epics that have been
stated in the preliminary document, break those down into smaller stories for this part. As the
development proceeds, you will need to make sure that things you've found out, questions you've
answered, and other questions that have arisen are all documented in the requirements. You can
also make a sub-section 2.2.1 that is called Design Decisions
and document things there.
- 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.
- 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.
- 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:
- slide 1 — Title slide
- name of project
- project team members
- date
- LMU logo
- slide 2 — Purpose of project
- why was this a good fit?
- why were you interested?
- why is this a worthwhile project?
- slide 3 — Project goals
- what the project accomplishes
- 3 - 4 bullets
- 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
- 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
- slide 6 — Agile method slide 1
- what method: Scrum, Kanban, Lean, …, or what?
- why did you choose this method?
- did it work well?
- slide 7 — Agile method slide 2
- what were the advantages of your tool
- what were the drawbacks of it
- slide 8 — Demonstration
- demo of what you have working
- slide 9 — Project challenges slide 1
- describe a challenge that you encountered
- describe how you mitigated that challenge
- slide 10 — Project challenges slide 2
- describe a different challenge that you encountered
- describe how you mitigated that challenge
- 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]?
- slide 12 — Thank you and questions