Report Overview

Sestofts ord om akademisk indhold Uanset typen af bachelorprojekt er det nødvendigt at projektet indeholder refleksion over opgaven og tilgangen til dens løsning, dvs. tager et “akademisk skridt tilbage fra stoffet”. Det er således ikke tilstrækkeligt at en rapport beskriver et computerspil eller et softwaresystem der er udviklet i projektet. Der skal også være fx evaluering af produktet, argumentation for dets design, metoderne anvendt i dets konstruktion, og så videre, og en sammenligning med eksisterende produkter og løsninger beskrevet i litteraturen. Tilsvarende er det heller ikke tilstrækkeligt at en rapport refererer en lang række artikler eller bøger inden for et fagligt område. Der skal også være fx diskussion af modstridende synspunkter eller af de forskellige formål, synsvinkler eller akademiske traditioner der (formentlig underforstået) ligger bag disse artikler eller bøger.

 Peter Sestoft's writing reports

Check out Peter Sestoft's document. We will be using his template, that looks like this:

  1. Preface
  2. Introduction
  3. Background and description of the problem
  4. Problem analysis
  5. User's guide and examples
  6. Technical description of the program
  7. Test
  8. Conclusion

Comments

Vincens: I believe we should have more focus on the experience with using the Android SDK and platform. I agree that Sestofts template isn't exactly fit for a more exploratory report. But I believe we can make it all fit nicely with a little more effort.

Structure modified to our needs

Indicate if the chapter or section is ok, by typing names first letter like this GJ,GS,GT,GV. When a chapter is accepted by all mark it as bold.

  1. Preface #78 GT GS GJ GV
  2. Introduction #79 GT GS GJ GV
  3. Background and description of the system #89 GT GS GJ GV
    • The Android platform #103 GT GS GJ GV
    • The system under development #90 GT GS GJ GV
      • Description of the application #84 GT GS GJ GV
      • Use cases #81 GT GS GJ GV
      • Requirements #91 GT GS GJ GV
        • Client #88 #138 GT GS GJ GV
        • Server #82 GT GS GJ GV
  4. Problem analysis #106 GS GJ GT GV
    • Availability #80 GS GJ GT GV
      • Location availability #77 GS GJ GT GV
      • Internet availability #76 GS GJ GT GV
    • Web Services #116 GS GJ GT GV
      • What is RESTful? #68 GS GJ GT GV
      • Message format #144 GS GJ GT GV
    • Data processing #92 GS GJ GT GV
      • Visualizing moods #83 GS GJ GT GV
    • Persistency #93 #94 GV GS GJ GT
    • Automated Testing #134 GS GJ GT GV
  5. User's guide #124 #143 GV GS GJ GT
    • The application flow #112 GV GS GJ GT
    • Starting the application #98 GV GS GJ GT
    • Using the application #124 GV GS GJ GT
      • Setting up DrunkDroid? #111 GV GS GJ GT
      • Going on a trip #113 GV GS GJ GT
      • The occasional mood indication #119 GV GS GJ GT
      • Viewing a mood map #97 #95 GV GS GJ GT
      • View a previous trip #96 #95 GV GS GJ GT
  6. Technical description of the system #125 GV GS
    • Availability strategies #129 GV GS GT GJ
      • Location strategy #102 GV GS GT GJ
      • Internet strategy #104 GT GS GJ
    • Client-server communicating #131 GV GS GT GJ
      • Web service technologies #109 GV GT GS GJ
        • Restlet #69 GV GT GJ GS
      • Web services #110 #75 GV GS GT GJ
        • xStream #74 GV GT GS GJ
      • Using the web services #136 GV GT GS GJ
    • Utilizing processing power #115 GV GS GT GJ
      • Producing mood map data with grid #118 GV GT GJ GS
      • Drawing the mood map #114 GV GT GJ GS
    • Persistency #127 GV GT GJ GS
      • Client #105 GV GT GJ GS
        • Settings #107 GV GT GJ GS
      • Server #86 GV GT GJ GS
    • Automated testing #134 GT GV GJ GS
      • Unit testing #121 GT GV GJ GS
      • Stubs and Mocks #72 GT GV GJ GS
      • Excerciser Monkey #122 GV GJ GS
    • Optimizations for mobile devices #99 GV GT GJ GS
  7. Tests #128 GV GT GJ

7. Conclusion #145

Notes

GV = Gennemlæst Vinc

Common errors to be Search/Replace? fixed

From To
classfile class file
cellphone cell phone
moodmap mood map
heatmap heat map
fulfil fulfill
\small{\texttt{ {\small\texttt{
a xml an xml
a XML an XML
xml XML
xStream XStream
xstream XStream
Xstream XStream
URL URI
uri URI
testcase test case
color colour (not when Code!)
rise rize*
ladder latter watch out for ladders!

* as in colorize

Terms from BDSP

  • Heterogeneity (forskelligartethed)
  • Openness (åbenhed)
  • Security (sikkerhed)
  • Scalability (skalerbarhed)
  • Availability, Failure handling (tilgængelighed, fejlbarlighed & fejlhåndtering)
  • Concurrency (samtidighed)
  • Transparency (gennemsigtighed)