[ALG] Het programmeerproces

[mr_obb]

Ik heb nu wat kleine programmeerprojecten achter de rug. Al deze projecten waren redelijk straight-forward en eenvoudig. Ze waren dan ook binnen de week afgerond. Nu wil ik beginnen aan een wat groter project, waar waarschijnlijk ook door meerdere mensen aan gewerkt gaat worden.

Een programmeerproject bestaat voor zover ik weet uit de volgende delen:

• Het opstellen van de eisen aan het systeem
• Het opstellen van het functioneel ontwerp
• Het opstellen van het technisch ontwerp
• Het daadwerkelijke coden

Onderweg wordt er natuurlijk nog eens kritisch gekeken naar eerder gedaan werk, maar dat spreekt voor zich.

Stap 1, 2 en 3 doe ik waarschijnlijk alleen. Het grootste probleem zie ik komen bij stap 4. Ik wil graag dat de code overzichtelijk blijft, dat als ik over een jaar de code bekijk, ik binnen enkele minuten het stukje kan vinden dat ik zoek. Kortom: ik wil het project netjes laten verlopen.

Vrijwel alle tutorials en de gehele FAQ hier op Tweakers gaan over syntax en debugging. Ik ben nu juist op zoek naar info over project beheer, versie beheer en dergelijke.

Kan je vertellen hoe jij zulk soort projecten aanpakt of waar ik meer info over zulke projecten kan vinden?

[The Eagle]

Google is your friend: start met zoeken op SDM (System Development Method)

[Verwijderd]

Coden is een klein onderdeel van het proces. Schrijf bijwijzen van eerst je handleiding van je app en begin dan pas te coden.
Houd allemaal bijvoorbeeld CamelStyle aan voor je source en houd de regels duidleijk en strak. Verder wijst het zich wel van zelf.

Voor versie beheer heb je goede apps. Google heeft er al een paar gevonden voor je. Zelfs freeware.

[Verwijderd]

Een goed project begint altijd met een Plan van aanpak, hierin kan je duidelijk beschrijven wat nou het doel van het project is en wat je ermee wil bereiken.
Dit is van groot belang als je met meerdere mensen gaat zitten programmeren. Verder kunnen hier ook de kosten, risico's, planning enz. in verwerkt worden. Een aardige template hiervoor is die van Roel Grit (deze kan je downloaden op www.roelgrit.nl).

Technische en functionele eisen opschrijven (eisenpakket) is de 2e stap en kan gezien worden als een uitbreiding op het plan van aanpak.

Voordat je deze stappen af heb zou ik niet beginnen met programmeren. Helemaal als het om een zakelijke klant gaat. Zorg in dat geval dat je goede afspraken maakt over het uiteindelijke product en zie het eisenpakket als een contract (moet natuurlijk wel ondertekend zijn). Om de boel nog duidelijker te maken zou ik beginnen met een prototype. Dit kan bijv. een screenshot van de GUI zijn of iets dergelijks.

De stap hierna is natuurlijk het programmeren zelf. Probeer het werk op te delen (als je met meerdere mensen werkt). Programmeer overzichtelijk en zorg dat elke aanpassing door wie dan ook duidelijk wordt gemaakt (bijv. dmv een versienummer).

Dit zijn mijn tips, je hoeft natuurlijk niet op deze manier te werken maar naar mijn ervaring werkt deze methode in de meeste gevallen aardig goed.

Wil je je echt verdiepen in projectmanagement raadt ik de volgende boeken aan:
Project management van Roel Grit

Verder is (naar mijn mening) een heel goed boek over projectmanagement met een alternatieve aanpak het boek "Projectmatig Creëren" van Jo Bos.

Let wel dat deze in gaan op de basis van projectmanement en niet specifiek op het programmeergedeelte. Deze boeken maken alleen helder hoe je het best een (groot) project kan indelen en controleren.

Nog even een aanvulling, mocht je UML willen gebruiken is rational rose een aardig programma (alleen niet gratis). Als je student bent dan kan je deze vast wel met een studentenlicentie voor een prikkie krijgen.

Succes ermee verder.

[ Voor 23% gewijzigd door Verwijderd op 01-03-2004 22:31 ]

[Canard]

Ik mis nog een hele belangrijke fase in je lijst die altijd een ondergeschoven kindje is:

TESTEN!

Hiermee kan een product staan of vallen! Dus ook een testprocedure opzetten, ook kun je met Google hier veel over vinden.
Overigens dient het opzetten van een testplan en het uitvoeren van de testen gedaan te worden door iemand die niet of weinig geprogrammeerd heeft aan de applicatie!

Plan van te voren een aantal mijlpalen bij ontwikkeling en ga minimaal bij elke mijlpaal een test uitvoeren. Leg dus ook vast wat je geimplementeerd wil hebben bij elke mijlpaal.

Wat ikzelf prettig vind (en ook toekomstige gebruikers van de applicatie) is om van te voren je GUI schermen te maken en op basis hiervan je functionaliteiten te maken. Met deze schermen kun je dan scenario's maken (dus opvolgende schermen)
Deze schermen dienen het liefst door iemand gemaakt te zijn die goed inzicht heeft in de functionele kant van de applicatie (bijv. een toekomstige gebruiker)
Dit alles doe je dan in nauwe samenwerking met een gebruiker en ontwikkelaar/ontwerper

Verder is het belangrijk om regelmatig feedback te krijgen op je werk, functioneel én technisch gezien.

Ben overigens wel benieuwd over wat voor project het gaat

[ Voor 48% gewijzigd door Canard op 01-03-2004 22:30 ]

[Verwijderd]

Je kan het functioneel en technische ontwerp ook vervangen door:
Requirement analysis Document
System Design Document
Object Design Document

Je kan via het V-Model werken, maar daar is het project waarschijnlijk iets te klein voor.

http://www.extremeprogramming.org/, dat is eigenlijk meer voor projecten waar je met een 4 tot 10 aan werkt. Daar staan vast nog wel wat aanwijzigingen.

Ik weet niet of je een object georiënteerde taal gebruikt. Een Use Case Diagram, Sequence Diagrammen en een goed uitgewerkt klassendiagram inc. methoden en attributen lijkt me handig. Je zou ook naast UML, OCL kunnen toepassen om in een vroeg stadium al allerlei afspraken met betrekking tot het systeem vast te leggen.

Verder testapplicaties en goede documentatie. Als je in java programmeert: kun je jUnit voor het testen gebruiken en JavaDoc voor de documentatie (zie java.sun.com). Let wel dat je je programma naar de test toe schrijft en niet je test naar je zojuist geprogrammeerd programme. Eerst de test programmeren dus. (mits we het over unit-testen hebben, want de klant zal waarschijnlijk ook testen, en zelf kun je op bepaalde niveau's ook nog testen voordat je het aan de klant overdraagt).
Dat werkt wat sneller en makkelijk en bovendien nog volgens een standaard.
Verder duidelijk afspraken maken over hoe je wat doet.

Extreme programming werkt geloof ik op basis van prototypen. Je kan je project misschien opdelen in prototypen. Dit worden dan je mijlpalen. Je eerste prototype is dan een soort van dummie.

Genoeg methoden dus.

[Crysania]

een aantal dingen waar je op moet zoeken zijn deze

dit zijn veel gebruikte systeem ontwikkel methodes

SDM: Waterval methode
DSDM: Iteratieve methode
RUP: Iteratieve Methode
Extreme Programming: ook soort iteratief, met prototyping


--------------------------------------


in ieder geval. voor kleine projecten hoef je je niet echt aan zo'n methode te houden.

je begint bijna altijd met een plan van aanpak.
hierin zet je de globale planning, en de afbakening, resultaat van het project in het kort...

hierna komt meestal een "Definitie van Eisen"
hierin vertel je waaraan de applicatie moet voldoen met functionele eisen, technische eisen enz.

na de "definitie van eisen" begint het echte ontwerp.
SDM en DSDM gebruiken meestal een FO en TO. maar in rup zijn het meestal gewoon UML documenten.

[ Voor 56% gewijzigd door Crysania op 01-03-2004 22:33 ]

[Verwijderd]

Canard schreef op 01 maart 2004 @ 22:20:
(...)
Wat ikzelf prettig vind (en ook toekomstige gebruikers van de applicatie) is om van te voren je GUI schermen te maken en op basis hiervan je functionaliteiten te maken. Met deze schermen kun je dan scenario's maken (dus opvolgende schermen)
Deze schermen dienen het liefst door iemand gemaakt te zijn die goed inzicht heeft in de functionele kant van de applicatie (bijv. een toekomstige gebruiker)

(...)

Daar ben ik het niet helemaal mee eens. Ik ben van mening dat wanneer je begint met het maken van de Gui je de functionaliteit al helemaal vastlegt in een te vroeg stadium.
Kom je er later achter dat er nog functionaliteiten ontbreken, wordt dat lastig toevoegen. Je Gui zal nooit meer enorm veranderen waardoor bepaalde functionaliteit onvindbaar blijven, of niet goed meer toe te voegen is. Of je moet dan weer opnieuw beginnen.

Ik begin ook altijd redelijk snel aan de Gui, maar pas als ik de functionaliteit heb uitgedacht. Je hebt dus voor jezelf al duidelijk wat de functionele (en niet-functionele) eisen zijn. Je hebt je Use Case Diagram (die de functionaliteit weergeeft) al volledig uitgewerkt en een globaal, nog niet uitgewerkt klassendiagram gemaakt. Als je met een database werkt, heb je ook al nagedacht over het ERD.
Pas dan lijkt het me verstandig om aan de Gui te beginnen. Pas dan heb je denk ik pas een goed beeld over het te bouwen systeem en dan kan het werken aan de Gui's je beeld verbeteren i.p.v. belemmeren.

Overigens ben ik iemand die die dingen graag op papier uittekend in de eerste fasen. Alles wat je op papier ontwerp wordt om één of andere reden veel mooier dan wanneer je direct begint op scherm.

edit: V-model is een soort waterval-methode, maar dan met aandacht voor de weg terug, het testen. Daar zijn ook nog varianten op, zoals het zaagtandmodel.

[ Voor 5% gewijzigd door Verwijderd op 01-03-2004 22:33 ]

[mr_obb]

Ik heb al aardig wat nuttige antwoorden gezien. Alvast bedankt daarvoor.

Ik zal even wat duidelijker zijn over wat ik versta onderd de eerder genoemde delen van het programmeerproces.

Ik begin met het pakket van eisen. Dit is een document waarin je vastlegt welke functionaliteit er in het systeem moet zitten. Naast de functionele en niet-functionele eisen komen hierin o.a. scenario's en Use Case Diagrams.

Stap twee is het functioneel ontwerp. Hierin worden het eerste klassediagram gemaakt en worden sequence diagrams gemaakt.

Deze eerste twee documenten worden besproken met de eventuele opdrachtgever om zo inderdaad vast te leggen wat je gaat doen en (misschien nog belangrijker) wat niet.

In het technisch ontwerp wordt de klassediagramen uitgewerkt met taal-specifieke eigenschappen. Hier wordt dus de eerste opzet gegeven voor het daadwerkelijke coden, wat in de volgende stap komt.

De bovenstaande stappen heb ik, om het mezelf goed aan te leren, ook met de kleinere projecten gedaan. De laatste stap, het coden, heb ik daar meestal wat sneller en minder netjes gedaan.

Zoals Canard terecht opmerkt hoort ook het testen van de software tot het takenpakket van de programmeur.

Ik ga eens wat van de links doorkijken. Meer info is natuurlijk van harte welkom!!

[Canard]

Verwijderd schreef op 01 maart 2004 @ 22:32:
[...]
Daar ben ik het niet helemaal mee eens. Ik ben van mening dat wanneer je begint met het maken van de Gui je de functionaliteit al helemaal vastlegt in een te vroeg stadium.
Kom je er later achter dat er nog functionaliteiten ontbreken, wordt dat lastig toevoegen. Je Gui zal nooit meer enorm veranderen waardoor bepaalde functionaliteit onvindbaar blijven, of niet goed meer toe te voegen is. Of je moet dan weer opnieuw beginnen.

Stom van me... ik bedoelde eigenlijk dat ik de schermen eerst maak in MS PowerPoint of Fireworks... dus puur alleen globale scherm lay-out met daarin de functionaliteiten...
Dan nog ben ik het met je eens dat je moet opletten dat je geen functionaliteiten vergeet. Voordat je aan dit "papieren ontwerp" (zo noem ik het) begint, moet je inderdaad wel een goed idee hebben van de functionaliteiten.

Overigens werk ik veel met Flash MX (2004) om applicaties te bouwen en daarbij gebruiken wij vrij creatieve scherm-layout's, vandaar de keuze om bijv. in Fireworks de scherm-layout te maken.

[Crysania]

ik zie dat je het coden altijd als 1 stap ziet.

Er zijn veel projecten waarin er meerdere iteraties gebruikt worden voor het coden. hierdoor ziet de opdrachtgever al eerder een resultaat als pas aan het einde van het project. Ook kun je eventuele fouten in je ontwerp makkelijker aanpassen en kom je hier sneller achter.

Ik zelf vind dit de prettigste manier van werken.
als je dit interresant vind zoek dan ff op DSDM en RUP.

dsdm en rup zijn denk ik op dit moment de meest gebruikte project aanpakken in het bedrijfsleven.

[Alarmnummer]

tip: verkijk je niet te veel op UML. UML is leuk voor boeken, en communicatie. Maar ga systemen niet to in detail mbv UML uitwerken. Verder is het jammer dat UML het slechter doet naarmate je hoger op in het systeem komt (dus richting de architectuur). Je kan allerlei schema`s verkrachten om er iets mee aan te duiden, bv layers of pipes en filters, maar ik zou gewoon een lekker pakket pakken (zoals visio) waarmee je tenminste degelijke schema`s kan maken.

Pas dus op met overtollig gebruik van UML (en verder kan je met een reverse engineering tool ook weer UML genereren op basis van de code).

Als je meer over het ontwerpen van software op hoger nivo wilt weten dan adviseer ik je sowieso om erg veel tijd te steken in patterns. Vooral Patterns of Software Architecture I en II zijn erg interessant op dit nivo. Patterns of Enterprise Application Architecture en Enterprise Integration Patterns zullen je ook zeker niet misstaan als je meer richting de enterprise hoek gaat. En uiteraard zijn boeken over architectuur zelf en documentatie van architecturen ook erg belangrijk alhoewel ik denk dat het voor jullie op dit moment nog lichterlijk overkill is.

[ Voor 41% gewijzigd door Alarmnummer op 02-03-2004 17:28 ]

[Nibble]

Alarmnummer schreef op 02 maart 2004 @ 17:22:
tip: verkijk je niet te veel op UML. UML is leuk voor boeken, en communicatie. Maar ga systemen niet to in detail mbv UML uitwerken. Verder is het jammer dat UML het slechter doet naarmate je hoger op in het systeem komt (dus richting de architectuur). Je kan allerlei schema`s verkrachten om er iets mee aan te duiden, bv layers of pipes en filters, maar ik zou gewoon een lekker pakket pakken (zoals visio) waarmee je tenminste degelijke schema`s kan maken.

Pas dus op met overtollig gebruik van UML.

Imho is visio zeker als je gaat werken met wat grotere projecten (en meerdere analysten) echt een ramp.

Ik vind dat je _juist_ een uml diagram erg gedetaileerd moet maken. UML leent zich verder uitstekend voor iteratieve processen. Praktijk leert dat gedetaileerder en doordachter je schema's zijn (dus ook sequence diagrammen e.d.) dat dit zeker bij een langer lopend project zijn tijd dubbel en dik terug verdiend.

Het daadwerkelijke coden beslaat maar een klein deel van de totale tijd, meer als de helft is vooranalyse zoals hier al eerder genoemd werd bv het plan van aanpak en definitiestudies.

[Alarmnummer]

Nibble schreef op 02 maart 2004 @ 17:30:
[...]
Imho is visio zeker als je gaat werken met wat grotere projecten (en meerdere analysten) echt een ramp.

Voor het tekenen van normale schema`s (geen uml) vond ik visio eigelijk een uitkomst. Je krijgt zonder veel werk goed uitziende en praktische schema`s.

Ik vind dat je _juist_ een uml diagram erg gedetaileerd moet maken. UML leent zich verder uitstekend voor iteratieve processen. Praktijk leert dat gedetaileerder en doordachter je schema's zijn (dus ook sequence diagrammen e.d.) dat dit zeker bij een langer lopend project zijn tijd dubbel en dik terug verdiend.

Zoals ik boven al heb vermeld moet je oppassen tot welk nivo je doorgaat met het maken van UML diagrammen. Hoe meer je richting architectuur gaat hoe groter de behoefte hieraan is. Het imho volslagen zinloos om uml diagrammen te maken die 1 op 1 corresponderen met code.

Het daadwerkelijke coden beslaat maar een klein deel van de totale tijd, meer als de helft is vooranalyse zoals hier al eerder genoemd werd bv het plan van aanpak en definitiestudies.

Ik denk dat dit niet voor ieder project op gaat. Uiteraard zal er tijd gestoken moeten worden in analyse, plan van aanpak en allerlei andere verplichtingen. Maar er zal ook tijd gestoken moeten worden aan een goeie architectuur. En als je verder kijkt naar de meer agile-methodologieen zie je steeds meer dat de verschillende fases niet meer gescheiden zijn. Een gedeelte wordt ontworpen, een gedeelte geimpementeerd, een gedeelte getest en dan weer verder. Het voordeel hieraan is dat je ten 1e 'agile' bent omdat er geen onnodig werk is verricht. Een ander voordeel is dat vaak nieuwe inzichten worden opgedaan tijdens het implementeren en eventueel moet hierop het ontwerp aangepast worden.

[Noork]

The_Eagle schreef op 01 maart 2004 @ 21:58:
Google is your friend: start met zoeken op SDM (System Development Method)

SDM, dat wordt toch niet zoveel meer gebruikt? Dacht dat het al een wat oudere techniek was. volgens mij is het nu allemaal DSDM en RAD wat de klok slaat.

[Verwijderd]

Het lijkt mij best wel nuttig om een klassendiagram te maken wat één op één met de code is (met uitzondering van de Gui misschien).
Zeker als je met meerdere mensen bent.
Een keer met zes man een dag lang een klassendiagram uitgewerkt. Vervolgens nog geoptimaliseerd en gerestyled.
Daarna kun je gewoon "mindless" code kloppen. Ik ben een paar dagen ziek, ik kom terug, ik vraag hoever ze zijn en ik kan "mindless" verder code kloppen. Ik kan methoden aanroepen van klassen geprogrammeerd door anderen, zonder te kijken of die methoden inderdaad bestaan, zonder te kijken of die methoden inderdaad dat teruggeven, simpelweg omdat ik het klassendiagram voor mijn neus heb.
Alle methoden bestaan al. Alle attributen bestaan al. Het enige wat je nog moet doen is de inhoud van die methoden inkloppen, zodat ze werkelijk doen wat je van ze verwacht.
En zolang methoden er nog niet zijn (anderen zijn nog niet zover), maak je één of andere testklasse waarmee je ze simuleert, want ze komen er toch wel.
Je hoeft je collega's niet eens te spreken

Natuurlijk kun je tijdens het coderen tot de ontdekking komen dat iets beter op een andere manier kan. UML aanpassen, communiceren en verder werken.

[Crysania]

Verwijderd schreef op 02 maart 2004 @ 18:47:
Het lijkt mij best wel nuttig om een klassendiagram te maken wat één op één met de code is (met uitzondering van de Gui misschien).
Zeker als je met meerdere mensen bent.
Een keer met zes man een dag lang een klassendiagram uitgewerkt. Vervolgens nog geoptimaliseerd en gerestyled.
Daarna kun je gewoon "mindless" code kloppen. Ik ben een paar dagen ziek, ik kom terug, ik vraag hoever ze zijn en ik kan "mindless" verder code kloppen. Ik kan methoden aanroepen van klassen geprogrammeerd door anderen, zonder te kijken of die methoden inderdaad bestaan, zonder te kijken of die methoden inderdaad dat teruggeven, simpelweg omdat ik het klassendiagram voor mijn neus heb.
Alle methoden bestaan al. Alle attributen bestaan al. Het enige wat je nog moet doen is de inhoud van die methoden inkloppen, zodat ze werkelijk doen wat je van ze verwacht.
En zolang methoden er nog niet zijn (anderen zijn nog niet zover), maak je één of andere testklasse waarmee je ze simuleert, want ze komen er toch wel.
Je hoeft je collega's niet eens te spreken

Natuurlijk kun je tijdens het coderen tot de ontdekking komen dat iets beter op een andere manier kan. UML aanpassen, communiceren en verder werken.

hoe heb je dit klasse diagram gemaakt? gewoon klasses bedenken met je team?

hoe ik het meestal doe is zo:

je maakt use cases -> vanuit de use cases maak je sequentie diagrammen -> vanuit sequentie diagram ontstaat klasse diagram

[pagani]

Je bent eigenlijk nog de twee belangrijkste processen vergeten (imho) :
Software testing en implementatie. Hier gaan de meeste projecten (afgezien van uitloop op de tijd) de mist in.

Er zijn diverse ontwikkelmodellen, degene die jij beschrijft is eigenlijk het watervalmodel wat niet echt goed is. Kijk bijvoorbeeld eens naar technieken om dit model te verbeteren, bijvoorbeeld rapid prototyping...

[farlane]

johnnyv.nl schreef op 03 maart 2004 @ 09:37:
Er zijn diverse ontwikkelmodellen, degene die jij beschrijft is eigenlijk het watervalmodel wat niet echt goed is.

De meningen hierover verschillen nogal. Bovendien is het xp of iteratieve principe nog lang niet overal geacccepteerd.

[pagani]

farlane schreef op 03 maart 2004 @ 09:41:
[...]


De meningen hierover verschillen nogal. Bovendien is het xp of iteratieve principe nog lang niet overal geacccepteerd.

True, true, vrijwel iedereen werkt nog met het watervalmodel als grondslag. De vraag is dus echter of je, wanneer je je ontwikkelmethode gaat herzien, niet óók naar de andere varianten moet kijken.

[koli-man]

Nibble schreef op 02 maart 2004 @ 17:30:
[...]


Imho is visio zeker als je gaat werken met wat grotere projecten (en meerdere analysten) echt een ramp.


Het daadwerkelijke coden beslaat maar een klein deel van de totale tijd, meer als de helft is vooranalyse zoals hier al eerder genoemd werd bv het plan van aanpak en definitiestudies.

Ik denk eigenlijk dat het coden een groot deel van de tijd vergt, maar een klein deel van het project is.
Dus ik bedoel dat coden niet het belangrijkste is van een project maar wel de meeste tijd vergt, omdat je gewoon op sommige dingen even blijft hangen en weer moet zoeken hoe iets speciefiek moet e.d. Daar gaat de tijd in zitten.

[koli-man]

farlane schreef op 03 maart 2004 @ 09:41:
[...]


De meningen hierover verschillen nogal. Bovendien is het xp of iteratieve principe nog lang niet overal geacccepteerd.

En dat komt volgens mij door de bazen en hun tijdsdruk die ze op willen leggen. Want zij willen graag wat zien en dat is bij iteratief en sjit pas in een later stadium het geval.

[Alarmnummer]

koli-man schreef op 03 maart 2004 @ 09:47:
[...]


En dat komt volgens mij door de bazen en hun tijdsdruk die ze op willen leggen. Want zij willen graag wat zien en dat is bij iteratief en sjit pas in een later stadium het geval.

XP is voor managers ook een drama omdat het erg onduidelijk is hoe lang iets gaat duren. Ok.. dat 5 van de 6 projecten te laat en over budget (of zelfs niet) worden afgelevert, geeft denk ik ook genoeg te denken over de 'laten we proberen om wat managers info te verzinnen die nergens op gebaseerd is' manier. Verder is XP niet geschikt voor projecten waar veel mensen aan deelnemen. Je moet gewoon de goeie dingen van XP overnemen, en voor de rest moet je er imho niet al te veel aandacht aan schenken (XP is imho nogal overhyped)

Vooral bij 'experimentelere' opdrachten kan je slechter uitspraken doen over tijdsduur. Opdrachten waar een bedrijf veel ervaring mee heeft (en dus minder risicovol zijn), daarvan kan je uiteraard wel veel beter voorspellen hoe veel tijd het gaat kosten.

[ Voor 17% gewijzigd door Alarmnummer op 03-03-2004 11:04 ]

[Crysania]

koli-man schreef op 03 maart 2004 @ 09:47:
[...]


En dat komt volgens mij door de bazen en hun tijdsdruk die ze op willen leggen. Want zij willen graag wat zien en dat is bij iteratief en sjit pas in een later stadium het geval.

huh, volgens mij heb je het hier verkeerd.

bij waterval model lever je pas op het einde op.
bij iteratief heb je al tussen opleveringen.
oftewel bij iteratief zien de managers/bazen eerder wat resultaat.

[Varienaja]

koli-man schreef op 03 maart 2004 @ 09:45:
Dus ik bedoel dat coden niet het belangrijkste is van een project maar wel de meeste tijd vergt, omdat je gewoon op sommige dingen even blijft hangen en weer moet zoeken hoe iets speciefiek moet e.d. Daar gaat de tijd in zitten.

Als je tijdens het coden nog moet gaan nadenken over hoe iets moet, dan kan dat twee dingen betekenen:

• Je hebt de ontwerpfase overgeslagen
• Je moet terug naar de tekentafel om het bestaande ontwerp aan te passen

Ik heb het hier dan niet over het uitzoeken hoe een TList ook alweer werkt, en dat soort dingen he ;-)

Het denkwerk moet je namelijk zo ver mogelijk naar voren halen. Hoe verder in het ontwikkelproces je erachter komt dat er iets moet veranderen, hoe meer tijd het kost om de aanpassing te doen!

_{Sorry voor mijn betweterige uitspraak, ik heb pas cursus UML 2.0 gehad}

[ Voor 12% gewijzigd door Varienaja op 03-03-2004 12:11 ]

[Alarmnummer]

Varienaja schreef op 03 maart 2004 @ 12:10:
[...]
Als je tijdens het coden nog moet gaan nadenken over hoe iets moet, dan kan dat twee dingen betekenen:

• Je hebt de ontwerpfase overgeslagen
• Je moet terug naar de tekentafel om het bestaande ontwerp aan te passen

onzin. Je gaat een ontwerp niet in de kleinste details uitwerken. Ik snap niet dat mensen UML meer warderen dan het code-model. UML is erg praktisch, maar op het moment dat je je UML 1 op 1 correspondeert dan ben je imho veel te ver gegaan met ontwerpen.

_{Sorry voor mijn betweterige uitspraak, ik heb pas cursus UML 2.0 gehad}

Ja en? Zelfs grote jongens zoals Martin Fowler, oa auteur van het boek UML destilled, zegt dat UML overhyped is. Verder voldoet standaard UML vaak niet omdat het voor veel views (bv messaging, architectural) te beperkt is. Daarom zie je of extensies, of gewoon non uml oplossingen. Waarom zo krampachtig vasthouden aan een beperkte tool? Het gaat om de essentie erachter en niet om wat lullige (verkrachte) schema`s.

En als je graag voor alles een UML diagrammetje wil hebben, pak je toch fijn een reverse engineering tool?

[ Voor 8% gewijzigd door Alarmnummer op 03-03-2004 12:36 ]

[Vaudtje]

Alarmnummer schreef op 03 maart 2004 @ 10:42:
[...]

XP is voor managers ook een drama omdat het erg onduidelijk is hoe lang iets gaat duren. Ok.. dat 5 van de 6 projecten te laat en over budget (of zelfs niet) worden afgelevert, geeft denk ik ook genoeg te denken over de 'laten we proberen om wat managers info te verzinnen die nergens op gebaseerd is' manier. Verder is XP niet geschikt voor projecten waar veel mensen aan deelnemen. Je moet gewoon de goeie dingen van XP overnemen, en voor de rest moet je er imho niet al te veel aandacht aan schenken (XP is imho nogal overhyped)

Vooral bij 'experimentelere' opdrachten kan je slechter uitspraken doen over tijdsduur. Opdrachten waar een bedrijf veel ervaring mee heeft (en dus minder risicovol zijn), daarvan kan je uiteraard wel veel beter voorspellen hoe veel tijd het gaat kosten.

Ik kan me voorstellen dat XP moeilijker te managen is, maar wat ik van de iteratieve aanpak van DSDM weet is dat daar gewoon op een andere manier gemanaged moet worden (is eigenlijk heel logisch imho).
Bij DSDM wordt niet vastgelegd wat wanneer klaar moet zijn (zoals bij SDM/waterval), dus daar kan je ook niet op managen.
Er wordt juist gebruik gemaakt van timeboxing. Dat wil zeggen dat het project is opgedeeld in kleine perioden (meestal 1-4 weken). Tussen deze iteratieslagen wordt geevalueerd wat er gedaan moet worden in de volgende timebox.
De marge die bij SDM/waterval in de tijd zit, is bij DSDM juist op de functionaliteit gesteld. Door middel van prioritisering wordt functionaliteit toegevoegd zolang er nog tijd is in de timebox, te beginnen met de belangrijke dingen.

In plaats van te controleren of functionaliteit op tijd af is, moet de manager gaan controleren of er voldoende functionaliteit is op het controle moment. Dat is veel minder intuitief, en daarom wordt het snel 'onhandelbaar' genoemd.

Ik kan me voorstellen dat zoiets bij XP ook speelt. Bovendien is XP natuurlijk ook vaak misbruikt als excuus om slordig te programmeren, daar helpt niets tegen maar het imago van XP lijdt eronder.

[Alarmnummer]

DSDM en RUP zijn imho voor managers idd een veel veiligere manier van Project-voeren dan puur XP. Persoonlijk pak ik gewoon de interessante dingen van XP zoals unit testen, refactoring, patterns etc eruit en maak me er verder niet al te druk om. Veel technieken uit de agile software movement vind ik ook interessant (tdd, mda) maar zie ik nog niet meteen het praktisch nut van in.

[Varienaja]

Alarmnummer schreef op 03 maart 2004 @ 12:32:
onzin. Je gaat een ontwerp niet in de kleinste details uitwerken. Ik snap niet dat mensen UML meer warderen dan het code-model. UML is erg praktisch, maar op het moment dat je je UML 1 op 1 correspondeert dan ben je imho veel te ver gegaan met ontwerpen.

Wat bedoel je precies met een code-model? Gewoon de lijnen C++?

Ik weet hoe het is om een paar miljoen lijnen ongedocumenteerde, maar vooral on-gearchitectureerde code op je bordje te krijgen. Zulke code kan je gevoegelijk weggooien. Ik weet niet in wat voor werkomstandigheden jij verkeerd, maar mijn baas trok geen vrolijk gezicht toen hij dat hoorde.

Uit ontwikkelaars-oogpunt is het hele modelleer en ontwerp-verhaal misschien (zeker weten) vervelend, maar op de lange termijn heb je daar alleen maar voordeel van. Het is toch wel knap handig als er op hoog abstractie-niveau een document beschikbaar is, waarin staat hoe de relaties tussen objecten moeten liggen.


_{Grappig trouwens, de felle reactie als ik heel klein eventjes laat weten dat ik een UML cursus heb gevolgd :-D}

[Vaudtje]

Alarmnummer schreef op 03 maart 2004 @ 12:32:
[...]
Ik snap niet dat mensen UML meer warderen dan het code-model. UML is erg praktisch, maar op het moment dat je je UML 1 op 1 correspondeert dan ben je imho veel te ver gegaan met ontwerpen.

Helemaal mee eens. Lees dan de code of de javadoc, daar staat alles duidelijker in

Verder is het jammer dat UML het slechter doet naarmate je hoger op in het systeem komt (dus richting de architectuur).

Dat spreekt bovenstaande weer tegen (ook al zei je het eerder); wat bedoel je daarmee?
In mijn ervaring is het bijna onmogelijk om de daadwerkelijke implementatie in UML uit te leggen (thank god 4 javadoc), maar juist de samenhang tussen programmaonderdelen is prima te schematiseren met UML? Of bedoel je met architectuur iets anders?

[Alarmnummer]

Varienaja schreef op 03 maart 2004 @ 12:43:
[...]
Wat bedoel je precies met een code-model? Gewoon de lijnen C++?

idd.

Ik weet hoe het is om een paar miljoen lijnen ongedocumenteerde, maar vooral on-gearchitectureerde code op je bordje te krijgen. Zulke code kan je gevoegelijk weggooien. Ik weet niet in wat voor werkomstandigheden jij verkeerd, maar mijn baas trok geen vrolijk gezicht toen hij dat hoorde.

Ik weet hoe dat is. Ik heb zelf moeten mee werken aan een klassiek stovepipe system geschreven in c en delphi. Dit was een enorme brij met code waarin alle layers van het systeem bij elkaar in waren geprakt en functies meer of minder deden dan ze zeiden. Ik weet dus wat spaghetti code is

Aan de andere kant hou ik zelf veel van een goed design en je kan ook uitstekende systemen ontwerpen zonder alles in de kleinste details te ontwerpen. Door continu te refactoren hou je een systeem in uitstekende conditie. En uiteraard, hoe groter een systeem gaat worden (en hoe meer mensen er aan werken), hoe onmisbaarder een goeie documentatie (naast de sourcecode documentatie) gaat worden.

Uit ontwikkelaars-oogpunt is het hele modelleer en ontwerp-verhaal misschien (zeker weten) vervelend, maar op de lange termijn heb je daar alleen maar voordeel van. Het is toch wel knap handig als er op hoog abstractie-niveau een document beschikbaar is, waarin staat hoe de relaties tussen objecten moeten liggen.

Ontwerpen en modelleren vindt ik persoonlijk super om te doen. Maar je moet je wel realiseren hoever je hiermee gaat. Op het moment dat ik op hetzelfde abstractie nivo zit als code vind ik het zinloos om eerst een aantal UML diagrammen te maken en daarna te implementeren. Pas als je op een groter abstractie nivo komt te zitten, dan gaat UML interessanter worden.

_{Grappig trouwens, de felle reactie als ik heel klein eventjes laat weten dat ik een UML cursus heb gevolgd :-D}

Tja.. Ik krijg bij XP en UML altijd een beetje het idee dat mensen dit de 'silver-bullet' vinden. Daarmee wil ik niet zeggen dat XP en UML zinloos zijn, maar je moet weten wanneer je het moet toepassen.

Vaudtje
Dat spreekt bovenstaande weer tegen (ook al zei je het eerder); wat bedoel je daarmee?
In mijn ervaring is het bijna onmogelijk om de daadwerkelijke implementatie in UML uit te leggen (thank god 4 javadoc), maar juist de samenhang tussen programmaonderdelen is prima te schematiseren met UML? Of bedoel je met architectuur iets anders?

Op het moment dat je bij architectuur aankomt, moet je een architectuur beschrijven met allerlei views. Ik zie in literatuur of verkrachte UML diagrammen, waarbij ze bv een package misbruiken als Layer (layer-viewstyle), of ze pakken gewoon een fijn tekenpakket waarmee je de layers kan uitdrukken.

vb:



Hierbij wek je niet de indruk dat de layers afzonderlijke packages zijn (ze kunnen wel afzonderlijke packages zijn, maar hoeft niet). Er zijn veel meer van dit soort problemen waarbij standaard UML gewoon niet de juiste uitdrukkingskracht heeft. Waarom zou je dan een UML schema moeten hanteren, als je gewoon diagrammen kan maken met onderdelen die echt ergens voor staan zoals bv een server.

[ Voor 24% gewijzigd door Alarmnummer op 03-03-2004 12:58 ]

[koli-man]

Varienaja schreef op 03 maart 2004 @ 12:10:
[...]

Als je tijdens het coden nog moet gaan nadenken over hoe iets moet, dan kan dat twee dingen betekenen:

• Je hebt de ontwerpfase overgeslagen
• Je moet terug naar de tekentafel om het bestaande ontwerp aan te passen

Ik heb het hier dan niet over het uitzoeken hoe een TList ook alweer werkt, en dat soort dingen he ;-)

Dat bedoel ik nou net met zoiets als TList enz...Daarom tijd in de vorm van minuten en deel van een project. Daar zit het verschil en dat probeerde ik aan te geven.

[Alarmnummer]

*kick*

waar blijft het commentaar