15-413 Deliverables

Project and Sprint 1 Plan Contents

• Team name, team member names and emails, client name and email
• Weekly meeting time set up with client [10 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]
• Name of scrum master and backlog manager for the first month-long Scrum sprint [10 points]
  
• A Product Backlog made up of a high-level list of software features.  The product backlog should be organized as follows:
  
• There should be an estimate 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. [10 points]
• Each feature should be assigned to one of 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]
• Features for the first sprint must be 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). [50 points]
  
• Features scheduled for after the first sprint should be just 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 10-30 engineer hours of development. [20 points]

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 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]
• Have each member of your team inspect the artifact separately.  For team member, turn in a list of the issues found by that person.  For each issue, you should list the location where you found the issue (file and line of code or section of document), and a summary of the issue. [20 points]
  
• Meet and perform a walkthough on the artifact.  Turn in a merged list of issues with the information above, but in addition describe the severity of each 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. [40 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]
• Fix what you consider to be the critical issues with the artifact, and turn in the original artifact and the fixed artifact.  [10 points]
  

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)
  
• A comprehensive list of quality attribute requirements, including 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 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).
• Test cases for functionality that has not yet been implemented can be described in a sentence or so of text.
• Test cases for functionality that *has* been implemented should include the summary sentence but also either an implementation of the test itself (e.g. in JUnit) or a detailed script for performing the test manually.
• Note that this presumes you have implemented/specified detailed tests for the functionality you have implemented.  This is an important part of an agile process.
  
• You may include any other information you feel is important to explain your quality assurance strategy to the instructor.
  

Final Project Presentation

Individual Reflection

• Please see the individual reflection assignment.

Project Report

360^o Peer Evaluations

• Please fill out the peer evaluation document.