[alg]opzetten van software

[Alarmnummer]

Ik heb mezelf er al een tijdje op betrapt dat het opzetten van software op dit moment nog een zwak punt is. Ik bedoel daar niet zozeer het ontwerpen van alle sourcecode ed mee, maar het formeel in kaart brengen wat er eigelijk allemaal moet gebeuren.

Ik ben zo nu en dan wat aan het stoeien met UML omdat die class diagrammen erg handig zijn om te begrijpen maar verder heb ik er nog geen praktische dingen mee gedaan.

Mijn vraag is dus hoe je begint met het opzetten van een stuk software.

[Greyfox]

Ik begin altijd met het definieren van de benodigde functionaliteit.

[Alarmnummer]

En waar doe je dat formeel in?

[Nexopheus]

Ik begin meestal met het opstellen van een SRD. (Software Requirements Document).
Dit is een soort van projectplan. Faseer dit document in 2 fasen. Requirements determination. ( wat is er nu? wat moet er komen, wanneer enz. Veel tekst.)
Tweede fase is dan de specification, hier komen dan de berekeningen, I/O, database ontwerpen UML diagrams ed.

[Verwijderd]

Uhm .... da's lastig. Er is eigenlijk geen eenduidige manier voor. Voordat je zelfs besluit iets te bouwen zit er meerstal al een groot voortraject aan, wat de uitvoerfase behoorlijk beinvloedt.

Uitvoeren begint eigenlijk altijd met een Plan van Aanpak (PvA). Wat daarin staat is zo afhankelijk van andere factoren dat je alleen met een volledige case beschrijving dat kan invullen.

[whoami]

Greyfox schreef op 26 september 2002 @ 14:10:
Ik begin altijd met het definieren van de benodigde functionaliteit.

Het opstellen van een requirements document dus.

Dit is eigenlijk het beste. Je begint met op te schrijven wat jouw applicatie/software moet kunnen en doen.

Op basis van dit document kan je (als dat nodig is), een databank analyse maken en uw ERD maken.
Daarna doe je een technische analyse waar je gaat gaan bepalen welke classes er nodig zijn, hoe die classes met elkaar interageren, ...

Alarmnummer schreef op 26 september 2002 @ 14:11:
En waar doe je dat formeel in?

MS Word.

[Zoijar]

moscow must-have-should-have-could-have-wont-have. Praat met je klant en probeer die dingen er uit te halen. Werk het uit en leg elk punt nog is een keer voor of het zo klopt. Je uiteindelijk software heeft zeker alle must-have functionaliteit, hoogst waarschijnlijk alle should-haves, als er dan nog tijd/geld over is een aantal van de could-haves. De wont-haves zijn voornamelijk voor jou nuttig, in de zin dat het duidelijk is wat je zeker niet hoeft te doen (bv multi-user oid). Deze punten kan je uitgewerkt in contract vorm gieten, dan weten beide partijen waar ze aan toe zijn.

Pas nadat je dit hebt kan je UML diagrammen enz gaan tekenen. Vooral eerst use-cases, en die dan weer aan de klant voorleggen. Misschien komt er dan nog een must-have naar boven bv. Daarna class en interaction diagrammen, dat is al meer programmeer technisch niveau dan, en niet zo zeer nuttig voor de klant. Misschien de technische afdeling.

Dan kan je die diagrammen aan je team voorleggen, en kunnen ze een prototype maken. Eventueel iets snel in elkaar geknutseld in visual basic oid. RAD, rapid application development Dan kan jij weer iets aan je klant laten zien. Als het allemaal goed is, kan je echt gaan proggen, anders misschien nog een extra use-case toevoegen.

[Greyfox]

Een requirements document maak ik mbv RUP (Rational Unified Process).
Ik begin er net mee, dus hoe het precies allemaal heet weet ik niet.

[Verwijderd]

Zoijar is een DSDM aanhanger?

[whoami]

Het is dus zeer belangrijk dat je zoveel mogelijk samenzit met je klant om alles te bespreken en het is ook belangrijk dat je alle must-have's, won't have's, etc... in een contract zet.

Het beste is, dat je na iedere stap die dingen gaat gaan bespreken met je klant.

Zoals Zoijar zegt...

[Zoijar]

trouwens: boek

[Glimi]

Zoijar schreef op 26 september 2002 @ 14:18:
moscow must-have-should-have-could-have-wont-have. Praat met je klant en probeer die dingen er uit te halen. Werk het uit en leg elk punt nog is een keer voor of het zo klopt. Je uiteindelijk software heeft zeker alle must-have functionaliteit, hoogst waarschijnlijk alle should-haves, als er dan nog tijd/geld over is een aantal van de could-haves. De wont-haves zijn voornamelijk voor jou nuttig, in de zin dat het duidelijk is wat je zeker niet hoeft te doen (bv multi-user oid). Deze punten kan je uitgewerkt in contract vorm gieten, dan weten beide partijen waar ze aan toe zijn.

Tja, dit is eigenlijk alleen nuttig als je boxed werkt. Hiermee bedoel ik, je hebt een vaste eind datum, en vaste capaciteit. Het product is juist flexibel, in tegenstelling tot de 'ouderwetse' manier, waarbij je alle gewenste functionaleit zo snel mogelijk ging implementeren.

edit:
/me heeft een lichtelijk DSDM trauma opgelopen na een evaring met een Facilitator (workshops) die geen nederlands sprak en het verloor van een ezel met schaken

[mbravenboer]

Ook dit proces mag best fun opleveren. Alles wat als "niet leuk" wordt gezien, wordt over het algemeen niet goed uitgevoerd.

Optie: extreme-programming . Een methode die met name geschikt is als de requirements zich zeer snel kunnen aanpassen en er gewerkt wordt in relatief kleine teams. Zie het boek "eXtreme-Programming eXplained van Kent Beck.

In de categorie "niet leuk" valt ook testen. Daarom moet je iets verzinnen: unit-testen. In de categorie niet leuk valt ook het verbouwen van software. Daarom moet je iets leuks verzinnen: refactoring.

Zodra je vervelende gevoelens krijgt bij een bepaalde methode of aanpak, moet je er gewoon vanaf zien .

[Verwijderd]

Wat voor projecten doe je meestal? Interne projecten, waar je zelf de specificaties vast moet leggen of externe projecten, waar je iets in opdracht van een klant maakt?

Als het niet iets voor mezelf is doe ik dit :
1. Inventariseer de eisen/wensen van de klant
2. Beschrijf wat het programma gaat doen
3. Beschrijf de user interface (printscreentjes van je schermpjes maken helpt)
Fase 2 en 3 leveren gezamenlijk een functioneel ontwerp op.
4. Schrijf offerte aan de hand van het functioneel ontwerp.
5. Laat offerte + FO door klant goedkeuren
6. Schrijf een TO aan de hand van het FO
Over het schrijven van een TO is al eens een topic geweest hier, maar ik neem aan dat je dat wel beheerst

Voor zover ik weet zijn er zowel voor FO's als TO's geen 'echte' standaarden. Er zijn meerdere methodes en technieken, maar het is aan jou om er eentje te kiezen. Het zal dus ook afhangen van je opdrachtgever en het bedrijf waar je werkt. Het belangrijkste is in ieder geval niet de gebruikte methode, maar het resultaat (FO + TO), dat moet zodanig zijn dat iemand die de software nog nooit gezien heeft aan de hand van deze twee documenten kan begrijpen hoe de software in elkaar steekt, en hoe er veranderingen aangebracht kunnen worden.

[Verwijderd]

O ja, als je echt lol wilt hebben moet je de klant een FAT-plan laten schrijven (FAT = Functionele Acceptatie Test)

Overigens hier de gehele gang van zaken bij ons :

1. Constatering nieuwe/veranderde eisen/wensen
2. Opstellen RFC (Request For Change)
3. Accordatie RFC door Change Management
4. Schrijven offerte FO n.a.v. RFC
5. Accordatie offerte door opdrachtgever
6. Schrijven FO
7. Schrijven offerte voor bouw/test/etc
8. Accordatie offerte voor bouw/test/etc door opdrachtgever
9. Schrijven TO
10. Schrijven systeemtestplan
11. Bouw + unittest
12. Integratie produkt in testrelease
13. Systeemtest
14. Aanbieden testrelease ter FAT
15. FAT testen (door opdrachtgever)
16. Aanbieden testrelease ter GAT
17. GAT testen (Gebruikers Acceptatie Test)
18. Aanbieden testrelease ter IAT
19. IAT testen (Integratie Acceptatie Test)
20. Aanbieden testrelease ter PAT
21. PAT testen (Productie Acceptatie Test)
22. Goedkeuring testrelease door Change Management n.a.v. testrapporten
23. Decharge voor opdracht
24. Invoering release in proefproductieomgeving
25. Goedkeuring voor landelijke invoering
26. Landelijke invoering

[Donderwolk]

Ik gebruik altijd Rational Rose voor die class diagrams. Die klassen kun je dan gemakkelijk exporteren met Rational Rose naar C++ code. Door deze klasse structuur te gebruiken wordt je programma ook meteen een stuk overzichtelijker.

De Rational Rose software is trouwens te gebruiken voor een complete UML analyse.
Een demo kun je downloaden op:
http://www.rational.com/products/rose/index.jsp

Deze demo is beperkt tot tien klassen geloof ik. Maar voor het gemiddelde thuisproject moet dat wel genoeg zijn dacht ik zo. Tenzij je van plan bent je eigen besturingssysteem te gaan schrijven

[Alarmnummer]

Het ontwerpen van de software zelf heb ik geen problemen mee, maar het gaat me eigelijk om dat stuk ervoor: het in kaart brengen van wat er eigelijk moet gebeuren.

Op dit moment is dat allemaal nog erg informeel gegaan, maar dit komt absoluut niet serieus over en verder heb je eigelijk ook geen poot om op te staan. Ik wil dus weten hoe je dit stuk formeel opzet zodat je geen gezeur hebt van een klant over missende functionaliteit en ik wil graag weten hoe jullie dit aanpakken.

Tot nu toe heb ik het geluk gehad dat er grove richtlijnen/ideeen waren en daar kon ik na overleg een eigen invulling aan geven, maar dit zal voor veel andere opdrachten niet opgaan.

[goalgetter]

Mischien iets om even door te lezen: The Art of Software Development

Staat in een reeks artikelen een heel proces beschreven van het verkrijgen van de wensen van de klant tot het coden.

[Zoijar]

Verwijderd schreef op 26 september 2002 @ 14:26:
Voor zover ik weet zijn er zowel voor FO's als TO's geen 'echte' standaarden.

Er zijn wel IEEE standaarden voor de documenten. (bv IEEE 830-1984 bij requirements analysis link )

Verder ben ik nergens echt een aanhanger van en weet ik er ook niet zo veel van... had een studiepunt of 10 in software engineering, en ben toen heel snel heel hard de andere kan op gerend. Not my cup of tea

[Alarmnummer]

*kick*

[Verwijderd]

Ervaring is hierin erg belangrijk.
Belangrijk is dat je eerst alles duidelijk krijgt dus 'the overview' hebt zoals mijn vroegere baas altijd zei .. keep the f*king overview, en weet je hij had nog gelijk ook!
Je moet er voor zorgen dat je de dingen zodanidg geanalyseerd hebt dat je begrijpt wat de klant wil .. dan ga je kijken naar de methodieken waar mee dit gedaan kan worden en maak je dus een soort van plan.
Als je dit plan hebt gemaakt en je bent er tevreden mee dan ga je aan de slag!

btw: wat ik blaat is heel erg ruwweg gezien .. maar het gaat om analyse daar begint alles ... gewoon op papier of in je hoofd .. al is het beter als je het opschrijft want dat kun je dan niet vergeten.

[Verwijderd]

Het systeem dat we op school wel eens gebruikt hebben is om eerst de opdracht te beschrijven.

Vervolgens beschrijven we de functionaliteit in onafhankelijke gebeurtenissen. Je krijgt dan een soort black box.

Omdat ik slecht ben in algemene beschrijvingen zal ik een voorbeeld geven.

Je hebt een digitaal horloge, deze is voorzien van 4 knoppen, namelijk adjust, hour, minute en light. Tevens heeft dit fictieve horloge een klokpuls als ingang

Vervolgens bepaal je de onafhankelijke gebeurtenissen, dit zijn de gebeurtenissen waarop het systeem hoe dan ook moet reageren. In mijn geval dus:
- Gebruiker drukt op adjust
- Gebruiker drukt op light
- Klokpuls geeft opgaande flank

hour en minute zijn geen onafhankelijke gebeurtenissen, de gebruiker moet immers op adjust drukken voordat de knoppen werken.

Vervolgens worden deze onafhankelijke gebeurtenissen beschreven:

Gebeurtenis: Gebruiker drukt op adjust
Procedure:
Indien de gebruiker op adjust gedrukt en daarna op hour wordt de tijd met 1 uur verhoogt
Indien de gebruiker op adjust gedrukt en daarna op minute wordt de tijd met 1 minuut verhoogt

Gebeurtenis: Gebruiker drukt op light
Procedure:
Het licht wordt aangezet

Gebeurtenis: Opgaande flank op ingang
Procedure:
De tijd wordt met 1 seconde opgehoogd

Natuurlijk zullen voor ingewikkelde systemen de specificaties heel wat langer worden en het zal dan gaan opvallen dat een aantal onderdelen van een procedure vaker terugkomen, deze dingen worden dan als subprocedure beschreven.

De bedoeling is dat deze beschrijving zo is dat de klant hem begrijpt en daaruit precies kan opmaken wat het systeem gaat doen en dat de klant onder dit document zijn handtekening zet.

Op deze manier heb je het systeem volledig gespecificeerd zodat de functionaliteit is beschreven en op het moment dat je voldoet aan deze specificaties is je systeem gereed

Op hoop dat je wat hebt aan dit stuk proza

[Verwijderd]

Ik ben niet zo'n enorme fan van al die hoelahoep zooi a la UML enzo, ik vind dat allemaal enorme overkill voor een probleem wat door de oplossers zelf bedacht is (zoals heel vaak het geval is in de ICT-wereld, imho).

Ik verdeel een project vaak over aparte modules (waarin elke module dus een subprobleem moet oplossen), en ik schrijf dan per module over het algemeen als eerst een mooi zootje header files waarin ik alle objecten uiteenzet die ik wil maken (je gaat dus eerst bedenken wat voor objecten je wilt, wat ze moeten doen), en dat ga je dan in header functie declaraties uiteen zetten. Vanaf hier hoop je de gewenste functionaliteit vanuit API-oogpunt te bereiken. En vanaf hier kun je dus de implementatie van dat alles doen, met het object framework wat je al had uitgedacht als (dynamische) basis.

Zo doe ik het al jaren, en zelfs vrij grote software-projecten kan ik zo nog redelijk overzien. Simpelheid dient de mens. . UML et all is ongetwijfeld prachtig en ik zal wel een enorme zijn dat ik die niet gebruik, maar voor mij hoeft al die fancy troep niet zo.

[Nexopheus]

Het voordeel van UML is dat je niet alleen weet welke objecten je gebruikt, maar ook hoe de onderlingde samenhang is. Wat de volgorde van object aanroepen zijn, totale context van het systeem, of juist de details van een subsysteem.

imho mag een soortgelijk schematechniek niet ontbreken in het ontwikkelen van software.

[Is wel offtopic overigens]

[Verwijderd]

Hmm, als je het puur over UML modelleren hebt ---> hier is zijn geen vaste stappen voor (dat maakt het zo verrekte handig)

Verder hangt het ook erg af, wat je wil modelleren! Maar als je de diagrammen van het UML kent (Use-case, Klasse, Sequence, collaboration, etc.)
Zou je zelf denk ik wel weten, welke diagrammen je het beste waar voor kan gebruiken!

Klassediagram is idd, verrekte handig, niet alleen omdat je via Rational Rose zo je halve code kunt laten generen in JBuilder (en dit werkt goed, als je mar goed modelleerd)

Ik zei in het begin dat er geen vaste stappenplan of iets dergelijk sis, maar die zijn er wel! Tenminste stappenplan waar je dingen kan overslaan en kan weglaten, je ben nog vrij in wat je doet ! "K zou zeggen, ga eens een cursusje volgen, of sla een UML boek open!