Research and Development 1/2012-13/instructies/Fase 2/ontwerpdocument
Uit Werkplaats
< Research and Development 1 | 2012-13 | instructies | Fase 2
Versie door Erik Barendsen (overleg | bijdragen) op 4 jun 2013 om 15:07
Product
Ontwerpdocument
Inleiding
In het ontwerpdocument werken jullie het idee voor de app uit. Het document beschrijft de bedoelde werking en verantwoordt de keuze voor deze app. Verder geeft het document uitgewerkte requirements, een technisch ontwerp en een projectplanning.
Instructie
- Kies een aansprekende titel. Dus niet ‘Ontwerp R&D1’ of iets dergelijks.
- Werk het ontwerp uit volgens de volgende indeling.
- Inleiding
- Geef globaal aan wat jullie gaan maken, voor wie het bedoeld is, wat het moet doen, etc. Met een goede inleiding zorg je dat de lezer de technische uiteenzettingen verderop beter kan plaatsen.
- Verantwoording
- Laat zien dat het ontwikkelen van deze app de moeite waard is. Beschrijf welke vergelijkbare producten er bestaan, en hoe jullie app zich daartoe verhoudt. Wat voegen jullie toe? Geef verder aan in hoeverre jullie voorstel voldoet aan succescriteria voor apps (bijvoorbeeld deze).
- Requirements
- Beschrijf achtereenvolgens:
- functionele eisen
- niet-functionele eisen
- use-case model en use-cases
- Gebruik de richtlijnen voor Use Case model en Use Cases uit de cursussen Requirements Engineering en Objectoriëntatie. Formuleer concreet en gedetailleerd.
- Ontwerp
- Globaal ontwerp
- Beschrijf een opdeling van het product in componenten (modules) en geef de onderlinge samenhang aan. Beschrijf de rol van de componenten en maak aannemelijk dat de componenten gezamenlijk doen wat ze moeten doen.
- Gegevensontwerp
- Analyseer welke gegevens er in het ontwerp aan de orde komen en geef aan hoe die informatie wordt gerepresenteerd, verwerkt en georganiseerd.
- Detail-ontwerp per component
- Beschrijf voor elke component hoe die gerealiseerd wordt in termen van klassediagrammen (publieke methoden en karakteristieke attributen).
- Gebruikersinterface
- Beschrijf de functionaliteit van het product vanuit het perspectief van de gebruiker. Beschrijf hoe de gebruiker het product gebruikt om de verwachte 'features' uit te voeren en geef aan welke feedback de gebruiker krijgt.
- Geef 'screenshots' om het interface te laten zien. Beschrijf de objecten op het scherm en de acties die eraan gekoppeld zijn.
- Planning
- Vermeld de kritische onderdelen / onzekere factoren van dit ontwerp, dat wil zeggen lastige punten ('uitdagingen') waar je in de planning van het projectwerk rekening mee moet houden.
- Geef voor elke week aan wat gedaan wordt, maar vooral wat het oplevert ('deliverable'). Zorg dus dat de planning productgericht is en maak daarmee de voortgang meetbaar. Het format kun je vrij kiezen. Je zou een zgn. Gantt-diagram (Google!) kunnen gebruiken om de tijdsplanning schematisch weer te geven.
Werkplaats
Het ontwerpdocument wordt een subpagina van de projectpagina. Gebruik het volgende stukje code als basis en zet op deze pagina een link naar het PDF-bestand dat je met LaTeX hebt gemaakt.
{{RD1-ontwerpdocument |Projectgroep=groepsnaam |Auteurs=auteur1, auteur2, auteur3 |Onderwerp=nog in te vullen }} [[Academisch jaar::2012-13| ]]
Beoordeling
Via onderstaande rubric met kwaliteitskenmerken.
1 ondeugdelijk | 2 matig | 3 adequaat | 4 excellent | |
---|---|---|---|---|
Inleiding | onvolledig | vaag, laat veel aan voorstellingsvermogen van de lezer over | informatief over vorm en gedrag, met weinig moeite voorstelbaar | geeft een compleet beeld |
Verantwoording | geen verwijzingen naar verwante producten en succesfactoren | vergelijking met verwante producten en succesfactoren, maar eigen indruk staat voorop | bevat zorgvuldige redenering gebaseerd op vergelijking met enkele verwante producten en succesfactoren | overtuigend; geeft een compleet beeld van de waarde van de app ten opzichte van bestaande producten en succesfactoren |
Requirements | vergezocht of obligaat | zinvolle eigenschappen, maar oogt niet volledig | zinvol, volledig | rijk, doordacht |
vaag, ambigu | vaag maar interpreteerbaar | specifiek | volledig SMART | |
Globaal ontwerp | onhandig, reduceert complexiteit nauwelijks | adequaat maar hier en daar onhandig | zinvolle modularisering, adeqaat | vakkundig, origineel, ingenieus |
summier beschreven | informatief maar bevat hiaten of onduidelijkheden over samenhang en werking | samenhang beschreven en werking beargumenteerd, er ontbreken hooguit details | volledige beschrijving en correcte argumentatie | |
Gegevensontwerp | summier of ontbreekt | datastructuren beschreven, maar niet overal handig gekozen | de relevante gegevenstypen benoemd; passende datastructuur gekozen | gestructureerde aanpak en/of zinvolle ontwerpbeslissingen zoals opslaglocatie aangegeven |
Detail-ontwerp | niet in termen van klassen, attributen, methoden | in de juiste termen, maar niet volledig tov use cases | volledig tov use cases, essentiële klassen en methoden genoemd | volledig tov use cases, uitgebreid met voorziene systeemspecifieke onderdelen |
Userinterface | onvolledig | (niet veel meer dan) screenshots | screenshots met toelichting over belangrijkste functies | compleet beeld van ontwerp van de gebruikersinteractie |
Planning | ontbreekt of in algemene termen (bv uit de cursusplanning) | in termen van activiteiten of handelingen, of globale deelproducten/componenten | in termen van specifieke deelproducten of componenten | idem, en zinvolle details over werkverdeling en fasering vermeld |
Opmerkingen |
Tips
- Werk zo concreet mogelijk: het is beter om op gemaakte keuzes terug te komen dan keuzes vooruit te schuiven.