15-413 Deliverables

Project Plan Contents

• Team name, team member names and emails, client name and email
• Weekly meeting time set up with client [5 points]
  
• Picture of success for team [10 points]
• List of risks, written as condition-consequence statements, rated with impact, probability, and time frame, and ordered by risk exposure.  A mitigation strategy should be listed for each [20 points]
• An initial Product Backlog made up of a high-level list of software features, with a short description of each.  These should be detailed enough to determine the scope of the project and allow high-level estimation, but larger granularity and less detailed than individual programming tasks.  Think of a feature as being a week of development or more in scope.  The initial product backlog should be at least a page. [40 points]
• An estimation of the cost of each feature, developed using a wideband delphi or function points estimation technique. [10 points]
• Each feature should be given an risk and a client value. [5 points]
• An initial project plan should divide features into 3 month-long sprints. The first sprint should produce a system that is complete enough for the client to evaluate whether the team is on the right track; the system should also be working after sprints 2 and 3.  Besides the "working system" criterion, the schedule should be based on client value (early), risk mitigation (early), and respecting dependences. [10 points]
  
  
• The refined project plan is similar, but features must be defined in more detail.  Features for the first sprint must be defined at a level of detail so that they can be implemented.
  

Weekly Report Contents

• Current Product Backlog, listing tasks accomplished, those in progress (with estimated % complete), and those still to come [20 points]
• Earned value, cost performance index, and schedule performance index, based on figures in the Refined Project Plan [10 points]
• Updated list of risks (see Project Plan) [10 points]
  
• List of problems (distinct from risks; a problem is a risk that has materialized) [10 points]
• Time spent by each team member on each task in the previous week.  Include "overhead" tasks like producing reports, meeting, etc.  You have a budget of 12 hours per week; you will lose credit if you are under 9 hours or over 16 hours. [10 points]
• When was the last meeting you had with your client?  (sometimes you may miss a week, but the last meeting should always be < 2 weeks in the past). [10 points]
• List of defects found in QA processes (OK to point to an online defect tracking tool, but summary statistics should be given) [10 points]
• Date of the current build (should be within the last two days)
• Results of regression tests on the build : total number of tests, % successful [10 points]
• How well did you follow good SE process and practices? [10 points]
  

Inspection Report

• Together, agree on a checklist you will use.  You may use sources on the web if you cite them, but you are responsible for putting together a high-quality and relevant checklist.  Turn in your checklist. [20 points - graded on overall checklist quality]
• Perform a walkthough on the artifact.  Turn in a document that lists all issues found. For each issue, you should list the location where you found the issue (file and line of code or section of document), the summary of the issue, the severity of the issue (major or minor), whether the issue is believed to be an error, an improvement, a clarification, a style issue, a question, or something else, and a high-level overview of a proposed fix. Each issue should be given an an orthogonal defect classification category.  [60 points - graded on quality of the inspection and documentation]  See the instructor's 17-654 notes on inspection.
• At the end of the review, reconsider your checklist.  Turn in your new checklist, along with a description of why you made any changes. [10 points - graded on well-motivated changes]
  

Sprint Requirements and Plan Contents

• Team name, team member names and emails, client name and email
• Name of scrum master and backlog manager for this sprint
  
• Current prioritized Product Backlog, with the goals for the current sprint pointed out
  
• A description of each element of the backlog that is scheduled for the current sprint, sufficiently detailed to permit good estimation and to unambiguously describe the functionality to be implemented.  Generally, tasks on the backlog should be scoped to around 3-10 engineer hours.  The backlog should include all deliverables for the course as well as all deliverables for the client (e.g. including documentation).
  

Architecture and High-Level Design Contents

• Team name, team member names and emails
• At least one component-and-connector (C&C) diagram
• If appropriate, a deployment diagram (don't bother if everything is in one place, but if there is a network in your system do this)
  
• If appropriate, a module view (don't bother if the design diagram below would subsume it)
  
• At least one lower-level design diagram (e.g. a UML class diagram, or a similar substitute for non-OO designs)
  
• At least three quality attribute scenarios, documented as discussed in 15-313
  
• At least one behavioral diagram (e.g. a UML sequence diagram, or a workflow diagram)
• Any technical or business constraints
• Remember to include any necessary explanation of notation you use--e.g. most diagrams will need a legend, unless the diagram type and all elements used are completely standard (C&C views always need a legend).
• Include an explanation of how your design meets your quality attribute requirements.  You may find ideas like architectural patterns, tactics, and design patterns helpful.
  
• In addition to the above, include any diagrams or documentation necessary to convey architecturally significant quality attributes and/or design choices.  Despite the checklist above, you will be primarily graded on whether you've done a good job documenting your architecture, NOT on whether you have all the items above.
  

Test Plan Contents

• Team name, team member names and emails
• Define specific quality goals for your project.  These should be clearly defined, measurable, and quantitative where possible (e.g. defects/kLOC at various stages, minimum # of simultaneous clients supported).  Include both functional correctness and quality attributes.
• For each functional requirement (i.e. tasks in your backlog) and each quality attribute requirement (e.g. scenarios in your architecture), describe in detail how you will assure its quality (e.g. with testing, inspection, static analysis, or a combination).  If you are applying testing, describe the specific test cases you will write (if tests can be automated) and/or carry out (for manual testing).
• Any other information you feel is important to explain your quality assurance strategy to the instructor.
  

Final Project Presentation

Individual Reflection

Project Report

Peer Evaluations