Archief - [ALG]SE Software "engineering"
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
.Tyfius
Legacy Member
Ik ga mij in de grote discussie niet mengen, enerzijds wegens beperkte ervaring, en anderzijds omdat ik vind dat iedereen wel punten aanhaald die een waarheid bevatten.
Wat ik versta onder SE is het uitdenken van hoe een applicatie er moet uitzien in schemavorm (dankzij de doorgedreven lessen UML onder anderen) en daar ben ik van mening dat dit een deels overbodig werk is. Ik heb voor mijn eindwerk alles in UML moete zetten, daar ben ik langer mee bezig geweest dan het programmeren zelf. Dit terwijl ik op voorhand al een schema had gemaakt in een "zelfverzonnen" schemataal met pijltjes en uitleg die iedereen sneller en makkelijker leek te begrijpen dan de UML op zich (nochtans hebben wij allemaal dezelfde cursus UML gehad).
Ik ben van mening dat je niet aan een project kan beginnen zonder het eerst op voorhand uit te denken, maar dat je niet alles kan vertalen naar schema's en andere modellen alvorens te beginnen. Uiteindelijk ga je onderweg zoveel onverwachte dingen tegenkomen waardoor er van je initiele design weinig overblijft.
Wat ik versta onder SE is het uitdenken van hoe een applicatie er moet uitzien in schemavorm (dankzij de doorgedreven lessen UML onder anderen) en daar ben ik van mening dat dit een deels overbodig werk is. Ik heb voor mijn eindwerk alles in UML moete zetten, daar ben ik langer mee bezig geweest dan het programmeren zelf. Dit terwijl ik op voorhand al een schema had gemaakt in een "zelfverzonnen" schemataal met pijltjes en uitleg die iedereen sneller en makkelijker leek te begrijpen dan de UML op zich (nochtans hebben wij allemaal dezelfde cursus UML gehad).
Ik ben van mening dat je niet aan een project kan beginnen zonder het eerst op voorhand uit te denken, maar dat je niet alles kan vertalen naar schema's en andere modellen alvorens te beginnen. Uiteindelijk ga je onderweg zoveel onverwachte dingen tegenkomen waardoor er van je initiele design weinig overblijft.
EraSerX
Legacy Member
kwitters zei:Ik vraag me echt af ofdat jullie momenteel als professionele developer custom software schrijven voor klanten. Als dit zo is, in hoeverre hebben jullie bij die projecten alles op voorhand in wiskundige bewijsbare requirements vastgelegd? En hebben jullie de exactheid van je uiteindelijk opgeleverde programma kunnen valideren?
Maar het zou mij inderdaad ten sterkste verbazen dat jullie al enige ervaring hebben op dat gebied, anders zouden jullie niet zoveel bullshit (om het in Unzip Attack zijn woorden te zeggen) uitkramen.
Ik heb helaas geen projecten als Bikini Sudoku op mijn CV staan, dus ik heb die professionele developer ervaring niet, maar mij maak je niet wijs dat ze bij AIM geen planning of design maken voordat er code geschreven wordt. Hoe kan je anders beginnen programmeren als je niet weet wat je moet programmeren. Dat moet dan geen wiskundig model zijn, maar toch een duidelijk gestructureerd plan. Dat is voor velen al software engineering.
Maar grote developer teams hebben nood aan formele en wiskundige methodes. Banken, hospitalen, universiteiten gebruiken statistische modellen bij software engineering omdat ze nu eenmaal moeten. Zij willen een wiskundige 100% zekerheid dat hun software altijd werkt, ik zou ook geen blue screen willen zien als ik op de operatietafel wil.
kwitters
Legacy Member
EraSerX zei:
Ik ook niet
EraSerX zei:
killgore zei:
Er bestaat blijkbaar nogal onduidelijkheid waarover deze discussie nu juist gaat, dus ik zal dit even opfrissen:
kwitters zei:
QplQyer heeft hierop "inderdaad" geantwoord, dus hierover gaat het! Hij gaat met deze stelling akkoord, en ik niet. Of er al dan niet planning bij te pas komt heeft er weinig mee te maken. En als je wil weten hoe wij software maken, dan krijg je al een redelijk goed beeld als je dat artikel leest waarnaar ik verwees (en wat dus duidelijk niet tot "software engineering" behoort).
QplQyer
Legacy Member
Ja, met die aanpassing dat het "waterfall"-model wel kan aangepast worden om nieuwe specificaties en verwachtingen te kunnen invoegen (het is dus geen waterval, maar een waterval met op elke verdieping een trapje naar boven). En zoals ik reeds boven heb gezegd, biedt een wiskundig model daar het voordeel dat men de specificaties kan vergelijken en eventueel ingrijpende reducties kan doorvoeren in de code doordat zaken die informeel niet hetzelfde lijken, wel hetzelfde bleken te zijn.kwitters zei:
Software engineering zoals ik het bedoel kan dus wel degelijk geïncorporeerd worden in agile development (het biedt zelfs een extra voordeel, zoals ik in de reply hierboven heb aangetoond).
Over de schilder:
Als een schilder voor hij zijn schilderij maakt, alles berekent en modelleert zodat het zeker juist geprojecteerd is, dan beschouw ik die man als iemand die een ingenieurs-aanpak gebruikt om zijn schilderij te maken.
kwitters
Legacy Member
QplQyer zei:
Heel vreemd vind ik dat, want in je eerste post schrijf je het volgende:
QplQyer zei:
Dit lijkt mij de agile way van developen, maar dan niet zo negatief voorgesteld
. De code-test cycles zitten duidelijk wel in agile development (al dan niet geautomatiseerd met unit tests).QplQyer zei:
Je specificaties ondubbelzinnig neerschrijven in uw model lijkt mij een duidelijk waterfall model. Agile development neemt op voorhand aan dat de specificaties al fout zijn. Dus nee, agile development en software engineering zijn 2 verschillende zaken.
QplQyer zei:
Okee, hij heeft dan een ingenieurs-"aanpak". Maar zal de gehele kwaliteit van zijn schilderij dan volledig bepaald worden door zijn ingenieurs-aanpak, of zijn er ook niet-ingenieur (niet wiskundige of formele) zaken die de kwaliteit van zijn schilderij bepalen?
Hale
Legacy Member
Je ziet agile development gewoon veel te eng. eXtreme Programming is idd een agile methodologie die ver weg blijft van alles (formeel) te modeleren. XP is daarentegen, zoals de naam doet vermoeden, nogal extreem. Andere processen zoals the Unified Process (UP) zijn ook agile waarbij men afstapt van een waterfall process en veranderingen in specificatie niet probeert te vermijden, maar net aanvaardt als onvermijdelijk. Toch gaat men daar wel degelijk meer formeel design toepassen in de vorm van UML (collaboration diagrams, domain models, class diagrams, SSD, ...) en dus proberen de specificaties te vatten op abstractere niveaus. Belangrijk hierbij is natuurlijk dat je als developer dat moeilijke evenwicht bewaart tussen enerzijds alles up front te willen vastleggen en anderzijds verglijden in een soort van hack-test-refactor methode.
De definitie van Agile development impliceert dus niet (maar sluit ook niet uit) alles van upfront design overboord te gooien en kan in die zin dus wel perfect onder de noemer SE vallen.
QplQyer
Legacy Member
De methode die ik beschreef is "ambachtelijk programmeren". Niet echt professioneel te noemen, eerder "prutsen tot het werkt".kwitters zei:Dit lijkt mij de agile way van developen, maar dan niet zo negatief voorgesteld
Uit het document dat je gaf maak ik eerder op dat agile development draait om het idee dat specificaties niet 100% gekend zijn op voorhand. Dat idee impliceert nergens dat men "schrijf - test - fix" moet gebruiken. Dat idee impliceert enkel dat men naar boven moet kunnen reizen in het methodologie-plan.
Dit is een mogelijk methodologieplan met wiskundige modellering: http://wiki.di.uminho.pt/wiki/pub/LerNet/KickOffMeeting/alfa05sl.pdf. Slide 6 toont het model, dat duidelijk geen waterfall model is, maar een model dat op elk moment nieuwe requirements kan incorporeren.
Ik wil ook even wijzen op het feit dat in je link duidelijk staat dat de methoden van "agile development" niet nieuw zijn en dat ze enkel ontstaan zijn uit het idee van enkele mensen die menen dat er vroeger reeds goede software geschreven is zonder engineering. Inderdaad, het kan, maar het is verre van professioneel. De enige reden waarom het aanvaard wordt is omdat we nooit anders gekend hebben, cfr alle operating systems met hun bugs. Maar noem je dat "succesvolle" software? Ik alleszins niet.
Het model hierboven toont duidelijk aan dat formele methoden niet eisen dat specificaties onveranderlijk zijn.
Je hebt sowieso altijd specificaties nodig, anders weet je niet wat te bouwen. Of men uitgaat van het principe dat specificaties fout zijn of niet, verandert weinig aan de mogelijkheid om de implementatie van de specificaties wiskundig te kunnen bewijzen. Nogmaals, het veranderlijke van specificaties is net een argument voor het gebruiken van wiskundige methoden bij software development. Het kan immers voorvallen dat men denkt dat men een nieuwe specificatie heeft, maar dat blijkt dat de nieuwe specificatie equivalent is aan de voorgaande (te bewijzen met de nodige tools, die momenteel echter nog niet gereed zijn voor industrieel gebruik), waardoor men geen tijd moet steken in het herschrijven van de applicatie om te voldoen aan de nieuwe specificatie.
Dan is er nog het punt van agile development dat ze graag "face-to-face" converseren over het programma (dat claimt wikipedia althans) en daarom weinig op papier zetten. Ook daar bieden formele, ondubbelzinnige specificaties toch een waardevol hulpmiddel om de communicatie bij te sturen. Zo kan men immers beter begrijpen wat de ander bedoelt (hoeveel keren hebben mensen niet moeite om een ander te begrijpen door de ambiguïteit van de taal?).
Formele methoden kunnen dus duidelijk een waardevolle aanvulling vormen voor het agile-development iteratief proces.
Natuurlijk zal de kwaliteit van het schilderij ook afhangen van hoe de schilder zijn kleuren mengt en ze aanbrengt. Net zoals de kwaliteit van software niet volledig afhangt van hoe goed het model is, maar ook van hoe goed de implementeerder zijn code kan schikken, of hoe een huis niet afhangt van hoe de architect zijn tekening maakt, maar ook van hoe goed de metser de stenen kan metsen.
Unzip Attack
Legacy Member
even voor alle duidelijkheid, is er hier iemand die er van overtuigd is dat je een project EERST volledig kan modelleren en dan volledig kan uitwerken, zonder enige change of requirements ?
trouwens het is een lame excuus dat weinig afgestudeerden geen kennis hebben van modellen en modelgebaseerde ontwikkeling. ik kan gerust zeggen dat ik een heleboel van die technieken al heb moeten toepassen in diverse projecten.
en doch geloof ik niet in de ingenieurs-aanpak ala een volledig voorgetekend plan. ik vraag mij af wat men hier verstaat onder een wiskundig model en op welke manier die dan getest worden etc... dat is allemaal prachtig op papier, maar wie in godsnaam wil werknemers eerst 2 maanden opleiden om ze nadien pas aan het werk te kunnen zetten ? waarom geen gebruik van hybride technieken (UML,...), waar de klant (belangrijk is regelmatige feedback naar klanten) ook nog iets van snapt.
anyway ik geloof niet in een 'one-fits-it-all'-engineering techniek. In sommige projecten zal model-gebasseerd werk goed werken, in ander neemt het VEEL te veel tijd in om eerst het probleemdomein volledig te modelleren, in nog andere kan men beter werken met hybride technieken (agile model-driven dev). heeft imo geen sikkepit te maken met 'onprofessioneel' werken, sommige projecten hebben simpelweg SNEL resultaat nodig, en daarin is een volledige model-based aanpak gewoon overkill.
trouwens het is een lame excuus dat weinig afgestudeerden geen kennis hebben van modellen en modelgebaseerde ontwikkeling. ik kan gerust zeggen dat ik een heleboel van die technieken al heb moeten toepassen in diverse projecten.
en doch geloof ik niet in de ingenieurs-aanpak ala een volledig voorgetekend plan. ik vraag mij af wat men hier verstaat onder een wiskundig model en op welke manier die dan getest worden etc... dat is allemaal prachtig op papier, maar wie in godsnaam wil werknemers eerst 2 maanden opleiden om ze nadien pas aan het werk te kunnen zetten ? waarom geen gebruik van hybride technieken (UML,...), waar de klant (belangrijk is regelmatige feedback naar klanten) ook nog iets van snapt.
anyway ik geloof niet in een 'one-fits-it-all'-engineering techniek. In sommige projecten zal model-gebasseerd werk goed werken, in ander neemt het VEEL te veel tijd in om eerst het probleemdomein volledig te modelleren, in nog andere kan men beter werken met hybride technieken (agile model-driven dev). heeft imo geen sikkepit te maken met 'onprofessioneel' werken, sommige projecten hebben simpelweg SNEL resultaat nodig, en daarin is een volledige model-based aanpak gewoon overkill.
jodeman
Legacy Member
Het nadeel van die plannen is dat het opgesteld wordt door mensen en geen feedback krijgt van de praktische kant.
Wat ik wil zeggen is het volgende, je bent programmeur bij een bedrijf en ze smijten daar een heel uitgedokterd model op uw bureau en je moet het maar uitwerken hoe het er staat. Zo een plan is nooit, maar dan ook nooit helemaal correct. Mensen maken nu eenmaal fouten. Die fouten kom je dan tegen als je het aan het programmeren bent en dan moet je al je plannen gaan wijzigen terwijl er mensen aan het programmeren zijn. Veel tijd verloren aan het eerste plan, welk waarschijnlijk niet echt het correct beeld van de eindapplicatie is.
Beter zou zijn een minder technische omschrijving van een probleem en meer wisselwerking tussen de twee teams, samenwerken ipv uw werk op een andere dienst te smijten en hopen dat het iets of wat correct was en je er hopelijk niet teveel meer van hoort.
Wat ik wil zeggen is het volgende, je bent programmeur bij een bedrijf en ze smijten daar een heel uitgedokterd model op uw bureau en je moet het maar uitwerken hoe het er staat. Zo een plan is nooit, maar dan ook nooit helemaal correct. Mensen maken nu eenmaal fouten. Die fouten kom je dan tegen als je het aan het programmeren bent en dan moet je al je plannen gaan wijzigen terwijl er mensen aan het programmeren zijn. Veel tijd verloren aan het eerste plan, welk waarschijnlijk niet echt het correct beeld van de eindapplicatie is.
Beter zou zijn een minder technische omschrijving van een probleem en meer wisselwerking tussen de twee teams, samenwerken ipv uw werk op een andere dienst te smijten en hopen dat het iets of wat correct was en je er hopelijk niet teveel meer van hoort.
killgore
Legacy Member
kwitters zei:Oei, ben je dan zeker dat je niet mijn mening deelt
ik heb u al gezegd dat ik met het meeste dat je hier vermeldt akkoord ga, maar dat veel gewoon niets met SE te maken heeft (imho). Nu trek ik me even terug uit de discussie, want kheb koppijn van statistiek te leren
.edit: (koppijn over en juist zalige gourmet binnen
): uml is imho niet echt software engineering, het is een hulpmiddel dat kan gebruikt worden, maar vele mensen verwarren software engineering met je programma uitschrijven in UML. Dan ben je eigenlijk compleet hetzelfde bezig als een gewone programmeur, enkel in een abstracte taal die visueler werkt. Dat is niet wat SE inhoudt.QplQyer
Legacy Member
Afhankelijk van het project kan dat zonder verandering van verwachtingen, of met.Unzip Attack zei:
Het is geen "lame excuus", het is een waarheid. Tuurlijk zullen de meesten wel iets gezien hebben van UML en dergelijke meer. Maar UML op zich is geen formele modelleringstaal, het heeft geen wiskundige onderbouw (er gebeurt wel onderzoek naar en ik geloof dat er reeds formeel onderbouwde UML-notaties bestaan). Ik denk niet dat het gebruik van theorem-proving tools voor software-design is aangeleerd in je curriculum? Of model-checkers? Of VDM, B, Z, ... ?
Het idee dat een ingenieurs-aanpak een volledig voorgetekend plan zou zijn is ook niet volledig juist. Zoals hierboven reeds aangehaald, bieden formele methoden ook mogelijkheden om het plan onderweg te veranderen, en formele methoden gebruiken levert al meer een engineering aanpak.
Een wiskundig model kan vanalles zijn: Abstract state machines, Pi-calculus, een implementatie in een model-checker taal, een B-model, een model in de Z-notatie, ...
Voor een "lichte" manier om formele methoden te gebruiken (en een voorbeeld van een model):
http://home0.inet.tele.dk/pgl/fmtrends98.pdf
Voor snel resultaat gebruikt men dan beter een functionele programmeertaal
. Direct formeel bewijsbaar en heel snel geprogrammeerd (het model biedt een bijna directe vertaling naar de implementatie).Maar goed, jammer genoeg nog steeds minder performant dan imperatief programmeren.
Momenteel lijkt het mij ook beter om formele methoden complementair te gebruiken aan andere technieken, daar de tools & kennis ontbreken om een echt volledige formele toer op te gaan.
kwitters
Legacy Member
QplQyer zei:
Men kan niet bewijzen dat het model voldoet aan de verwachtingen van de klant, want klanten weten meestal niets over programmeren, laat staan formele of wiskundige methoden. Dus je vertrekt al van een model dat fout kan zijn. Welk nut heeft het dan om al dan niet te bewijzen of iets aan dat model voldoet, als je al van een foutief model vertrekt?
Bij source code hoef ik trouwens niets te bewijzen, aangezien de computer het uitvoert zoals het er staat: de fout zit altijd bij wat de mens "denkt" dat het doet of moet doen. Zulke problemen kan je enkel oplossen door te testen: kijken of het programma voldoet aan de verwachtingen van de *klant*.
In de slides die je doorstuurde staat dat formele methoden 40 jaar oud zijn, vind je het zelf dan niet vreemd dat die in de praktijk zelden gebruikt worden?
kwitters
Legacy Member
QplQyer zei:
De slides die je doorstuurde geeft trouwens aan dat het om een waterfall model gaat. Een waterfall model wil zeggen dat wanneer je de requirements aanpast, alle stappen terug moeten doorlopen worden. Bij een incrementeel process is dit niet zo, men voegt steeds meer functionaliteit toe in kleine stappen.
EDIT: misschien is dit niet duidelijk, dus hier even extra uitleg: een klant gaat geen feedback geven op jou voorgesteld formeel model aangezien hij hier niets van begrijpt, hij geeft feedback op het uiteindelijk werkende resultaat: maw, klant zegt dat er iets niet in orde is, jij moet alle stappen terug doorlopen om weer feedback te krijgen = waterfall model.
dJeez
Legacy Member
Dat hoeft toch ook niet? Zij tekenen het model niet uit en hoeven het ook niet zelf te toetsen aan het model. Je gaat zelf toch ook niet alle berekeningen die een architect doet gaan narekenen om te zien of het huis dat hij heeft ontworpen en dat de aannemer heeft gebouwd wel stabiel is? Als het pakket doet wat de klant vraagt en het model correct is, dan lijkt het plaatje mij toch wel volledig te kloppen.kwitters zei:
Als de klant enkel nog opmerkingen heeft over de UI (en niks echt functioneels wil gewijzigd zien), dan zit je doorgaans wel goed als je model correct is
.Nu er valt iets te zeggen voor beide kanten uiteraard, het grootste probleem is trouwens dat de klanten geen voeling hebben met software en dat ontwikkelaars doorgaans ook geen domeinexperten zijn in het vakgebied van de klant. Daardoor gaat doorgaans veel tijd verloren door miscommunicatie (de klant zegt A, de ontwikkelaar denkt dat hij B zei, en uiteindelijk is het C). Ergens had ik een goede cartoon die dat perfect illustreerde (autoband aan een boom). Als ik hem vind zet ik hem hier wel.
*edit* Deze was het : http://www.jacobsen.no/anders/blog/archives/2004/05/17/the_tire_swing_cartoon.html
En diegenen die maatsoftware voor klanten schrijven zullen hem zeker herkenbaar vinden
.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.