...

• means irrelevant
  Let us assume that two time periods (T1-T2) have passed, with T3 just about to start.
  

  Anchor
  h.3l18frh h.3l18frh

  
  Observation: in activity A1 after time T2 the Estimated running effort is 10 ph and the estimated accumulated effort (i.e. including T1) is 20+10 = 30 ph. However, the Actual effort for A1/T2 is 12 ph, and the accumulated effort is 13+12 = 25 ph. So it seems that A1 is a bit behind the estimated effort ("plan") – but that can have many valid reasons. We are only measuring resource usage (effort, time), not the actual state of the software under development!
  Ex. what advice will you give to all the activities A1-A3 for the last T3 period?
  
  
  
  
  
  
  
  
  
  
  
  
  

  Anchor
  __RefHeading__28162_946898870 __RefHeading__28162_946898870

  Anchor
  h.206ipza h.206ipza

  Appendix C – Content of the phase/sprint documents/chapters
  This appendix contains information about what the different phase documents (or report chapters) should include. See also former project reports for more details.
  That is, it is common to divide a waterfall-based software project into the following 13 (or so) phases, whose
  documentation whose documentation then becomes a chapter in your final project report:
  
  C1. Introduction
  C2. Planning
  C3. Pre-study of the problem space vs. solution space
  C4. Choice of lifecycle-model: waterfall vs. agile?
  C5. Requirements specifications
  C6. Estimation of realization effort for use-case model
  C7. Construction/ design
  C8. Programming
  C9. Testing
  C10. Documentation
  C11. Evaluation
  C12. Presentation and demonstration
  C13. Appendices
  
  If an agile lifecycle model is chosen, like in Scrum, we recommend one "phase" (or report chapter) per Scrum-sprint, typically 2-3 such. These "Scrum phases" will then replace the waterfall phases C5-C10.
  Below you will find some more information on what each phase document is expected to contain. Note that the group can also select another phasing. 
  
  

• C1. Introduction

  Write a good, one-page abstract early, and explain the overall context, motivation, demands and results.
  

  C2. Planning

  See appendix A – Project plan.
  

  C3. Pre-study of the problem space vs. solution space

  The preliminary studies are vital for the group to obtain a good understanding of the total problem. Here, you will have to describe the problem at hand. You should describe the current system and the planned solutions (text, workflow, use-case scenarios, information flow, and other graphical presentations you can use). It is all about getting a good understanding of the challenges ahead! The group should investigate if existing and potentially competing solutions exists on the market. If such solutions exist, they should be described. You should also describe alternative solutions that fully or partially require custom implementations. The group must also set up evaluation criteria that form the basis for choice of a solution. Software by third party software providers (as OSS or COTS) should be actively pursued as candidates for implementation of large parts of your software system, see http://sourceforge.net
  In cases where existing components can be applied as modules in the project solution, a simple cost-benefit analysis should be carried out.
  Summary:
  Describe the main business requirements, both functional and non-functional, that will constitute the requirements for the final solution and its functionality. These requirements will later form the base for later formalization of requirements. Try also to make use-case diagrams to express the major functional requirements, cf. the simple effort-estimation method in Appendix F.
  Describe the situation and solutions of today ("as-is")
  Describe the wanted situation and its possible solutions ("to-be")
  Evaluation criteria
  Market investigations
  Description of alternative solutions
  Evaluation of alternative solutions, including adjusted requirements and potential costs and benefits.
  Choice of solution, in dialog with customer.
  To conclude, the pre-study should have two main deliveries:
• A (partly) prioritized set of requirements – cf. the Scrum "backlog".
• A proposed system architecture to enable a fast break-down (modularization) of the technical work

...