dJeez zei:*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.
) vind ik dit benauwlijk herkenbaar 
.kwitters zei:Oei, ben je dan zeker dat je niet mijn mening deelt? UML is nog niets in vergelijking met wat software engineering voorstelt: zij willen ALLES formeel en wiskundig voorstellen, zodat achteraf de correcte werking kan bewezen worden.
Unzip Attack zei:
QplQyer zei:
QplQyer zei:
wlibaers zei:
Het is totaal naast de kwestie of de klant al dan niet een model begrijpt of dat we niet kunnen bewijzen dat een model voldoet aan de verwachtingen van de klant. Op elk bepaald moment heb je immers wel sowieso een idee nodig van wat de klant verwacht, anders kan je ook geen source-code beginnen schrijven op dat moment. Op dat moment kan je dus evengoed een model maken, bruikbaar om ondubbelzinnig te communiceren onderling, om specificaties te vergelijken met elkaar, om implementaties te controleren aan de specificaties die men denkt dat op dat moment geldig zijn. De voordelen die ik hier al drie keer heb neergetikt dus.kwitters zei:
Dat is dan ook net de hele pointe van waarom men programma's gaat bewijzen: om zeker te zijn dat de source code die je hebt geschreven overeenkomt met wat jij als _programmeur_ denkt dat het programma doet (getuige de vele bugs is dat niet altijd juist gedacht). En dat probleem kan men wel degelijk oplossen door het te bewijzen.
In Frankrijk gebruikt men de B-methode al vaker in de industrie.
Als je degelijk naar het schema had gekeken had je gezien dat de klant geen feedback geeft op het voorgesteld formeel model, maar op een functioneel prototype.
De vraag is natuurlijk hoe diep alles wordt uitgespit. Je noemt hier nu vele zaken op, ik weet niet aan welke universiteit je hebt gestudeerd (ik vermoed Antwerpen of Hasselt), aan de mijne heb ik alleszins daar niet zoveel over gezien, en dan nog enkel in mijn optie-specifieke vakken.
Op de ene universiteit wordt het dan wel al wat grondiger gezien dan op de andere vrees ik. Het belangrijkste voordeel voor mij vind ik het praktisch gegarandeerd bugvrij zijn van het programma. Ik dan ook een hekel aan bugs (en aan debuggen).
De programmeurs mogen dan ook direct beginnen. Het model wordt dan wel gemaakt door de theoretici.
QplQyer zei:
? Je kan hoogstens bewijzen dat je source code voldoet aan het opgestelde model.QplQyer zei:
QplQyer zei:
QplQyer zei:
QplQyer zei:
QplQyer zei:
Door ondubbelzinnig neer te schrijven wat je verwacht en dan te bewijzen dat het programma doet wat je verwacht. Idealiter zouden bewijs en programma eigenlijk hand in hand moeten geconstrueerd worden, maar goed.kwitters zei:Hoe ga je bewijzen dat source code voldoet aan wat iemand denkt
Het is idioot. Een fout in een programma is een constructiefout en wel degelijk de schuld van de programmeur.
Goedkoop, neen, dat heb ik ook nooit beweerd. Eén fout in software kan enorm veel kosten (en dan nog niet alleen aan het bedrijf dat de software heeft gemaakt). Wanneer men de kosten voor het producerende bedrijf optelt voor het oplappen van de fout, het herstellen van geleden imago-schade, ... lijkt het me niet sterk om te stellen dat de kosten van een formele specificatie die gecontroleerd werd lager zullen liggen (indien de werknemers reeds getraind waren natuurlijk). Als men het breder trekt, kunnen vele bedrijven die de software gebruikten ook enorm veel geld verliezen door een onbetrouwbare applicatie. Als men al die kosten optelt, denk ik zeker niet dat formele methoden gebruiken duurder zal uitkomen als de kosten van de fout.
Wat een vreemde vraag. Formele methoden zijn nu toepasbaar, parallel programmeren gebeurt nu ook, maar in de toekomst zal dit alleen maar meer opkomen (en meer naar werkelijke parallellisatie neigen dankzij de multi-cores). En formele methoden om de inherente complexiteit van het parallellisme te kunnen temmen zullen daar dan ook broodnodig zijn.
Natuurlijk is dat prototype bovenop het model. Zo verhindert men dat men gaat implementeren vooraleer men zeker is dat het model voldoet aan de verwachtingen van de gebruiker. Was dat dan niet ook juist de kritiek, dat je nooit een model kan tonen aan de gebruiker? Hierbij is dat duidelijk opgelost aan de hand van een prototype.
En aanpassingen in de toekomst aan zo'n softwarepakket zullen dan weer net goedkoper zijn doordat er een degelijke documentatie voor bestaat. Laat staan bij nieuwe applicaties die gelijkenissen vertonen met vorige.
Ik daag u uit, richt een bedrijf op, ontwikkel software volgens alle modellen en kijk na 5 jaar hoeveel u verdient hebt. Het uitdenken van alle mogelijkheden kost tijd en geld, en dat is iets wat de klant niet heeft. Het programma moet liever vandaag dan morgen af zijn.QplQyer zei:
Op 't ET forum was er een tijdje terug een discussie aan de gang over het maken van cheats. Basicly is dat een inbreuk tegen de EULA, en daar vertelde iemand het volgende:QplQyer zei:
Volgens mij valt een disclaimer hier ook onder.
QplQyer zei:
QplQyer zei:
. Wel eerst even een papiertje tekenen dat je bugvrij programmeert, en een duidelijk gespecifieerde schadeclaim in het geval er toch bugs opduiken.QplQyer zei:
QplQyer zei:
QplQyer zei:
, niets maar dan ook niets is 100% guaranteed to be error-free! Geen space shuttles, geen vliegtuigen, geen processoren, geen software, niets! Men kan wel proberen de kans op falen zoveel mogelijk te verkleinen, maar 100% error free in real-life projecten, forget it.QplQyer zei:
QplQyer zei:
QplQyer zei:
QplQyer zei:
QplQyer zei:
QplQyer zei:
QplQyer zei:
sinds wanneer kan jij een wiskundig model zomaar even in 1-2-3 in een uitvoerbaar model (simulatie) gieten ? en kan je mij dan ook even tonen hoe ik dat uitvoerbaar model 1 op 1 map in een GIS-framework. weetje van zodra er een beetje complexiteit bij komt te kijken, kan je je uitvoerbare modelletjes al terug in de kast gaan steken. simple as that.killgore zei:het dijkstra algoritme IS een wiskundig model
Unzip Attack zei:
. Dat willen de tegenstanders van SE hier zeggen, maar weerom: heeft niets te maken met het engineering aspect op zich.Nice, dan heeft Hasselt wel een degelijke opleiding blijkbaar.Unzip Attack zei:
0.0% was een overdrijving van mijn kant inderdaad. Libraries die "100%" perfect in modellen werken, maar die bugs bevatten in real world, daar is dan allicht iets misgelopen bij het implementeren. Of er liep iets mis bij een specificatie die men vergeten verifiëren is. Of bij de interactie met een andere component, het besturingssysteem en dergelijke meer. Er kan vanalles mislopen dat niet aan je eigen code ligt natuurlijk. Wat niet betekent dat we dan maar meteen alles moeten weggooien omdat het het probleem nog niet volledig oplost.
Natuurlijk beginnen de programmeurs nadat de theoretici hun werk hebben gedaan, het principe van een pipe-line kwam eerder in mij op toen ik dat neerschreef. De theoretici werken een nieuw project uit, terwijl de programmeurs de laatste loodjes van het ander project aan het bouwen zijn, zodat ze niet met hun vingers moeten zitten draaien terwijl het model wordt gemaakt. Ik had dat wat duidelijker moeten neerschrijven allicht.
Methoden die eenzelfde garantie bieden? Dan ben ik toch benieuwd naar welke methoden dat zijn, buiten het gewone testen natuurlijk.
Zo'n verandering heeft dan ook zijn ingang nodig vanuit het grote management en kan niet gebeuren vanuit een klein developergroepje.
Ik heb dan ook niet gezegd dat men het van de ene dag op de andere moet gaan gebruiken. Wel dat dit een evolutie is waar men naartoe zou moeten gaan. Dat daar nog veel werk en onderzoek voor nodig is, is mij wel duidelijk.
Gent.
Dat is het probleem met de industrie in het algemeen hé, snel-snel-snel. En een bedrijf dat het sneller en goedkoper belooft krijgt het contract (maar of de kwaliteit dan wel nog steeds zo goed is valt te betwijfelen natuurlijk). Trouwens, geld verdienen, daar gaat het mij niet om, de mogelijke kostenreductie was maar één argument van een heleboel.Tyfius zei:
Tyfius zei:
Neen, dat is waar, en dat was wat kort door de bocht van mij om de honderd procent bugvrijheid te poneren. Een aanzienlijke reductie van het aantal bugs lijkt mij echter ook wel redelijk gewenst.kwitters zei:
Dat wil niet zeggen dat het niet op termijn goedkoper kan worden (door het afstuderen van mensen met de benodigde kennis, etc, etc).Tyfius zei:
De wet van 30 juni '94 is de auteurswet. In de auteurswet staat enkel dat men een licentie kan verlenen onder voorwaarden (zolang die voorwaarden natuurlijk geen wettelijke rechten gaan verbieden, want dan is dat deel ongeldig). Echter is het heikele punt het feit dat je de EULA pas ziet nadat je het product (en dus de licentie erop eigenlijk) hebt gekocht. Ik ben ook geen jurist, dus ik kan het ook niet met de volledige garantie zeggen, maar ik vermoed dat een licentievoorwaarde na aanschaf in België ongeldig is.Tyfius zei:
Het gaat wel degelijk om wat de programmeur denkt wat zijn code zal doen in de formele methoden. Voor je begint te programmeren heb je sowieso een idee nodig van wat je denkt dat er verwacht wordt, de programmeur schrijft het neer en verifieert of zijn code eraan voldoet. Het valideren van de verwachtingen van de klant is een totaal andere stap, waar geen wiskunde bij komt kijken, neen.kwitters zei:
Als de werkgever het concept niet verwerkt in zijn methodologie en de werkgever het niet toestaat om tijd te spenderen aan het gebruiken van dergelijke methoden, kan men natuurlijk zoiets niet eisen van de werknemer. Bovendien rust het auteursrecht van computerprogramma's automatisch bij de werkgever, dus lijkt het mij normaal dat de werkgever de verantwoordelijkheid draagt voor fouten in zijn software.Als jij afgestudeerd bent mag je voor ons komen werken als programmeur
Het verschil is dat het ene een gratis service is, op vrijwillige basis, zonder winstoogmerk, waar het andere voor commerciële doeleinden wordt gefabriceerd. Met winstoogmerk dus. Van een commerciëel pakket verwacht men toch wel dat men erop kan betrouwen dat de functies die het aanbiedt volledig beschikbaar zijn en niet tot data-loss en dergelijke meer gaan leiden.
Extra betalen voor juistheid lijkt me de wereld op zijn kop. Misschien moet je hen dan ook maar laten betalen voor het laten maken van die fouten in de code die later opduiken? Maar goed, zoals ik reeds zei, het is doordat de gebruikers al gewend zijn geraakt aan het idee dat er in software fouten zitten, dat ze geen betere toestand durven hopen (met minder fouten dus) en dit zomaar slikken.
Ik zal enkele kritische applicaties geven anders:
De deur zou misschien op het eerste zicht klemmen, maar na enkele jaren zal dan misschien blijken dat de muur klemt doordat de funderingen scheef gegoten waren en het huis scheefzakt, waardoor er niets beters op zit dan het huis af te breken en opnieuw te bouwen.
QplQyer zei:
.