Classwork‎ > ‎Project Milestones‎ > ‎Wrap Up‎ > ‎

Older version of this page

You should be reading this page for the first time very early in the quarter.  It describes what you need to accomplish if you are to successfully execute your project.  At the beginning of the quarter you probably don't understand all the concepts here, let alone how to implement them.  Don't worry, we'll talk about them as class progresses.  There's too much to do in one quarter.  We may add more things for you to do.  You need to get started right away if you are able to do most of this stuff.  Some of it you may have to execute in parallel.  You and your team need to decide if you are going to execute on everything that is described.  If so, how?  And, if not, what are you going to leave out and why?  Figuring all of this out in the absence of complete/good/accurate information is what software engineering is all about.

The "Wrap Up"  describes your entire project over the quarter.  Hopefully, you've been keeping up on the project milestones along the way, which requires documenting much of what needs to be in the Wrap Up.  Your team has two deliverables for the Wrap Up.

  • A written document (answer all the questions)
  • A presentation (14 minutes)
Details follow as the quarter rolls out.  However, here are some questions you should answer in the Wrap Up:
  • What is the vision of your project?  What's the one sentence, 1 paragraph, and 1 page summary of what your project is?
  • What are the key metrics for success?  When will you plan to achieve various goals?  Are you achieving them?
  • What is the  process for delivering software?
  • What was your team organization structure like? Who does what? How did this work out? In retrospect, would you have organized your team differently?
  • What are your development tools?  Why did you choose them?
  • What is your run time platform?  How did you choose it?
  • What are the communication mechanisms your team uses?  Is there a wiki or wiki-equivalent?
  • Did your team use weekly status reports to communicate?  An alternative mechanism?
  • What is your architecture?
  • Do you have an up to date schedule?
  • Do you successfully use a source code/version control system?
  • What is your version management strategy?  Branch a lot?  Branch as little as possible?  What is your team's philosophy on branching?
  • Do you have a bug database? Do you use it?  How do you use it? (What's the process for filing, triaging, fixing bugs, and deploying fixes? How many bugs have been filed?
  • Do you have a code review process?  What is it? Do you use it?
  • Do you have a requirements review process?  What is it?  Do you use it?
  • Do you have a design review process?  What is it?  Do you use it?
  • Do you have an architecture review process? What is it? Do you use it?
  • Do you have coding standards?  What is it? Do you use it?
  • Do you have written requirements?  Are they up to date?
  • What is your test strategy?  Do you have a regression test suite?
  • Do you have a test server?  Where is it deployed?  How close does it look like the live site?
  • Do you have a staging server?  Where is it deployed?  How close does it look like to the live site?
  • Where do you deploy your live site?  Why did you choose this? What is the physical and logical topologies?
  • Do you have a build process?  Is it nightly?
  • What is your deployment process?  How many steps?  Is it documented?
  • If a new developer comes on board, how do they bring up a development environment?  Is it documented?
  • Do you back up your software?  Your data?  Can you recover?  Under what conditions?
  • Do you have monitoring software in place?  What is it?How do you use it?
  • Did you collect feedback?  What was it?  How did you use it?
  • What is your design center for scale?  Any idea how you will grow beyond that?
  • How close does your final deliverable match the original requirement/goals?  Were you successful at delivering the product?
  • Have you released your project onto GitHub for public consumption?  
  • Do individuals have GitHub projects where they show case your project?  Why or why not?
  • Where do you use divide and conquer in your project?
  • Is your software modular?  Do you have clean interfaces -- interfaces that are "cleanly" separated from implementation?
  • Is your software loosely coupled?  Your organization?  Has it aided in the success of your project?
  • What decisions did your team make that turned out to be mistakes?  How did you correct for them?
  • What three big lessons did you learn from working on this project?
Note that in your wrap, you might be able to recover from a misstep in  a previous milestone.  For example, in your Zero Feature Release, perhaps you didn't sucessfully implement a source code/version control system.  But by the end of the quarter, it is in place and you didn't catastrophically destroy your code base.  Nice job!  You "caught up."