Results 1 to 7 of 7

Thread: Software Design Document template

  1. #1

    Software Design Document template

    Hallo,

    Ik ben het boek Professional C++ 2nd edition aan het lezen, omdat ik als hobbyprogrammeur mijn kennis wil vergroten. Is een prima boek.
    Nu wil ik voor een vrij eenvoudige applicatie die al bestaat een z.g.n Software Design Document schrijven. Nu is mijn vraag of daar templates voor zijn.
    Ik kan alleen heel uitgebreide templates in het engels vinden. Ik zoek eigenlijk iets eenvoudigs. Ik ben de enige ontwikkelaar van het project.

    Met vriendelijke groeten,

    Don

  2. #2
    I7 7700K 32Gb Win10 Pro Wok's Avatar
    Join Date
    Dec 2002
    Location
    Alkmaar
    Posts
    1,997
    Ik heb in het verleden wel eens geëxperimenteerd met https://blog.tara.ai/software-design-documents/

    Uiteindelijk bleek Help scribble de meest handige tool voor mij wat betreft documentatie bij een applicatie.
    Last edited by Wok; 23-Aug-19 at 12:05.
    10.3.3, Delphi2010, of Lazarus 2.0.10

  3. #3
    Software Design Document, en zeker de beschrijving in de blogpost waar Wok naar verwijst, is precies hoe we vroeger software bouwden en nu niet meer. Je kan geen dikke pil gaan schrijven om alle details van te voren vast te leggen. Hoe gedetailleerd je het ook neerzet, misverstanden hou je altijd. Begrip kweek je door kleine stapjes vast te leggen en te bouwen, zodat je steeds meer elkaars taal gaat spreken (en ook veiliger grotere stappen kan nemen). Natuurlijk hoort daar documentatie bij, maar deze manier klinkt als afbakenen en indekken, en staat volgens mij haaks op het doel om een goede relatie op te bouwen met je opdrachtgever en te bouwen wat die wil hebben.

    Een grappig voorbeeld is dat van Joel Spolsky, die een design document heeft gemaakt voor een website die vertelt hoe laat het is:
    https://www.joelonsoftware.com/whattimeisit/
    (onderdeel van een serie posts, die hier begint.

    Volgens mij is het best serieus bedoeld, maar laat dat voorbeeld ook juist ziet wat er aan mankeert. Dit is al een behoorlijke lap tekst voor een website die helemaal niets doet. Er staan onbeduidende details in die waarschijnlijk onnodig zijn, zeker in een eerste versie, en die mogelijk nooit geïmplementeerd gaan worden, of die wél geimplementeerd gaan worden, en resulteren in een duur, tijdrovend project met veel overbodige features. Maar goed, tenzij je graag miljarden wilt spenderen aan een overheid-sized ICT project is het in ieder geval beter om zo'n template te gebruiken, dan om de officiële IEEEE standaard voor het schrijven van Software Design Descriptions te volgen (PDF, uit 2009, te koop voor 80 euro).

    Dus, als je ter oefening eens zo'n document wilt maken, beschrijf dan gewoon eens op hoog niveau wat het doet, teken met wat rechthoekjes en pijltjes en grof diagram van de standaard-flow(s) van de applicatie, en diep eentje ervan eens uit in wat meer detail, met specifieke uitzonderingen (als deze stap faalt, wat gebeurt er dan).
    Voeg daar een lijstje features aan toe waarvan je het juist opvallend vindt dat ze er niet in zitten, pik de twee of drie belangrijkste eruit, en maak daar ook zo'n tekeningetje van. Probeer op basis van die tekeningetjes te bepalen welke je het makkelijkst kan bouwen, en schat in welke het meest waardevol zou zijn. En dadaah, daar is het volgende kwartaal voor je imaginaire product roadmap. Gedetailleerder dan dat zou het volgens mij niet moeten zijn.
    Last edited by GolezTrol; 23-Aug-19 at 12:28.
    1+1=b

  4. #4
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,208
    Tsja. Maar als je werkt op basis van offertes moet je nu eenmaal toch al in detail vastleggen wat je levert (cq ondersteunt) of niet.

    Anders blijf je eeuwig details toevoegen en eindigt het project nooit.

  5. #5
    Hoi Wok, Goleztrol, marcov.

    Bedankt voor jullie reacties. Ik heb een stuk gelezen over Agile. Heb zelfs Agile voor dummies gekocht een tijdje geleden. Wat ik er van begrepen heb is dat Agile vooral wordt toegepast in teams.
    Hoe doet men dat dan als je alleen werkt aan een applicatie? Vooral met betrekking op hobbymatig programmeren.
    Groetjes,

    Don

    Newbie in Delphi.

  6. #6
    Of je nu Agile of anders programmeert, je kunt jezelf zien als een team wat werkt aan verschillende projectdelen.
    De projectdelen moeten in het algemeen onderling communiceren en daarvoor zijn afspraken nodig.
    Als deze afspraken vast liggen en ieder zich er aan houdt kunnen er TODO items open blijven staan zonder dat het project als geheel teveel pauzeert.

    Zo ook naar de klant / gebruiker: er zijn afspraken nodig hoe de HMI er uit gaat zien.

    Voor projectspecificaties is het van belang dat de bouwer en afnemer het met elkaar eens worden hoe het product er uit gaat zien.
    Ook in mijn automatiseringservaring in de proces industrie heb ik geen standaard gevonden, maar samen met de klant geprobeerd eenduidig te omschrijven wat geleverd moest worden.
    Bij dit beschrijven is het belangrijk voortdurend contact met de klant te hebben, omdat anders er met grote zekerheid iets gebouwd gaat worden wat voldoet aan de tekst, maar niet aan de bedoeling.
    Betrokkenheid en flexibel denken bij beide de bouwer-ontwerper en de klant is van groot belang in dit stadium.

    Succes en plezier met je hobby werkzaamheden!

  7. #7
    Bedankt voor je reactie MaartenW. Ik weet weer wat meer. Ik ben begonnen met ToDoList (https://www.codeproject.com/Articles...ible-Way-to-Ke) om een
    planning te maken welke onderdelen ik ga ontwikkelen.
    Groetjes,

    Don

    Newbie in Delphi.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •