Archief - [ALG]SE Software "engineering"

QplQyer · 13 jan 2007

kwitters zei:
We zijn er allemaal mee eens dat software development nog in zijn kinderschoenen staat. Aanhangers van software engineering geloven dat we nu in het stadium zitten zoals ingenieurs vroeger. Als men vroeger een brug wou bouwen dan deed men dit men dit zonder eerst sterkte berekeningen e.d. te maken. Software engineers geloven dat software development, net zoals engineering, moet evolueren naar meer formele methodes om software te bouwen, net zoals bruggen etc. Duidelijke specificaties -> implementatie -> valideren van implementatie, een mooi voorbeel van een typisch engineering waterfall model.

Inderdaad.

Ik, langs de andere kant, geloof dat software developers in het stadium zitten zoals schilders in de 15de eeuw. Zij moesten zich bezig houden met 2 soort zaken: langs de ene kant zeer technische dingen zoals het samenstellen van verven (het engineering gedeelte), en anderzijds het artistieke gedeelte (afbeelden van de wereld). Schilders zijn ondertussen weg geevolueerd van het technische maken van verf, en kunnen zich nu volledig concentreren op het afbeelden van de wereld.
Als ik naar de software development wereld kijk dan zie ik ook een evolutie die zich wegtrekt van technische zaken. Men evolueert naar programmeertalen die dichter bij de mens staan (python, java, ... ). Hoe minder de focus op het technische gedeelte gaat liggen, hoe meer de focus op het maken van duidelijke software en duidelijke code gaat liggen.

Hier ga je er weer vanuit dat engineering enkel maar rond het technische draait, en rond het creëeren van fysieke zaken, wat hoegenaamd niet zo is (zoals reeds aangetoond met de definitie van wat engineering is). Engineering draait net rond het vertalen van concrete noden naar een creatie, waarin het zich onderscheidt van andere zaken is in het gebruiken van een intermediaire taal, die redeneren over datgene wat hij zal moeten creëeren toelaat.

De echte ingenieurskant in dit beeld zou het vertalen van 3D-concepten naar een 2D-vlak zijn (zoals je ziet, van de concrete wereld naar het abstracte). En wat kunnen we daar ondermeer voor gebruiken? Wiskunde.

Bij engineering komt dus net zoveel het vertalen van de werkelijkheid in een mythische wereld kijken als bij schilderen. Nogmaals, het technische is niet datgene waar de ingenieur zich met bezig houdt, maar is datgene waar de uiteindelijke implementeerder zich met bezig houdt (metsers, elektriciens, coders).

Software engineering trekt zich dan ook evenzeer weg van de technische zaken. Men tracht een abstractie te maken van het technische om er zo beter over te kunnen redeneren. Enkel is het door de ondubbelzinnigheid van een computer nodig om de werkelijkheid te vertalen naar een ondubbelzinnige taal. Een programmeertaal is ondubbelzinnig, maar laat niet gemakkelijk toe om ermee te redeneren of te rekenen (Het bewijzen van twee stukken code bijvoorbeeld. Met de code alleen gaat dat niet of moeizaam lukken, daarvoor heb je een wiskundige abstractie nodig die vlot rekenen toelaat).

Je zegt zelf dat we evolueren naar een meer natuurlijke taal, dat is net exact wat software-engineering doet, we vertalen wat we wensen enkel eerst in de taal van de wiskunde (liefst), in plaats van direct naar de programmeertaal.
In dat opzicht is de software-engineer dus reeds verder ge-evolueerd dan de code-schilder. Hij abstraheert in een veel hogere taal.

Als jullie je beter voelen bij formele methodes, gespecifieerde processen en up-front ondubbelzinnige requirements, dan ga ik jullie plezier niet afpakken. Maar laat mij dan ook mijn coder-plezier hebben in het maken van verstaanbare code en software waar de gebruiker zich goed in voelt .

Het maken van verstaanbare code en software waar de gebruiker zich goed in voelt en formele methoden en dergelijke meer gebruiken zijn geen twee exclusieve zaken. Men kan die twee zeker combineren. Dus het coder-plezier hoeft daarom niet af te nemen.

killgore · 13 jan 2007

compleet terzijde: er zijn trouwens zeer sterke vermoedens dat de schilders uit de 16e-18e eeuw vrij "geadvanceerde" wiskundige technieken gebruiken (meer bepaald projectiemethodes uit de meetkunde

).

Dit op basis van kleine puntjes in schilderijen die markeringen aanduiden die overeenkomen met bepaalde punten (waarvan ik de naam effe kwijt ben

).

In d ediscussie is denk ik gezegd wat er moest gezegd worden: software engineering en daadwerkelijk coden zijn 2 verschillende zaken.

kwitters · 13 jan 2007

QplQyer zei:
De echte ingenieurskant in dit beeld zou het vertalen van 3D-concepten naar een 2D-vlak zijn (zoals je ziet, van de concrete wereld naar het abstracte). En wat kunnen we daar ondermeer voor gebruiken? Wiskunde.

Waarom zou ik me hiermee bezig houden? De 3D engine doet dit al voor mij, net zoals een schilder zijn penselen in de winkel koopt. Ik hou me liever bezig met waar de camera best kan gepositioneerd worden, welke beweging van de camera het vlotste aanvoelt, hoe ik de real-time gerenderde wereld zo mooi mogelijk krijg, ... .

QplQyer zei:
Je zegt zelf dat we evolueren naar een meer natuurlijke taal, dat is net exact wat software-engineering doet, we vertalen wat we wensen enkel eerst in de taal van de wiskunde (liefst), in plaats van direct naar de programmeertaal.
In dat opzicht is de software-engineer dus reeds verder ge-evolueerd dan de code-schilder. Hij abstraheert in een veel hogere taal.

Alles naar wiskunde vertalen is een utopie.

killgore zei:
compleet terzijde: er zijn trouwens zeer sterke vermoedens dat de schilders uit de 16e-18e eeuw vrij "geadvanceerde" wiskundige technieken gebruiken (meer bepaald projectiemethodes uit de meetkunde ).

Ik ben heel blij dat je dit aanhaalt

. Schilders gebruiken veel wiskundige methodes, zelfs nu nog voor o.a. perspectief tekenen (wat ook op projectie methodes aankomt). Maar als ik zou beweren dat een schilder een engineer is dan zou iedereen mij hier voor zot verklaren. Schilders en coders gebruiken wiskundige technieken, maar dat maakt van hun geen engineers.

QplQyer · 13 jan 2007

kwitters zei:
Waarom zou ik me hiermee bezig houden? De 3D engine doet dit al voor mij, net zoals een schilder zijn penselen in de winkel koopt. Ik hou me liever bezig met waar de camera best kan gepositioneerd worden, welke beweging van de camera het vlotste aanvoelt, hoe ik de real-time gerenderde wereld zo mooi mogelijk krijg, ... .

Dat doet niets af aan wat ik zei. De schilder moet zelf het beeld van 3D naar 2D projecteren, zijn penselen doen dat niet automatisch. Dus die vergelijking loopt daar al mank.

Alles naar wiskunde vertalen is een utopie.

Dan is alles naar een programmeertaal vertalen evenzeer een utopie.

Ik ben heel blij dat je dit aanhaalt . Schilders gebruiken veel wiskundige methodes, zelfs nu nog voor o.a. perspectief tekenen (wat ook op projectie methodes aankomt). Maar als ik zou beweren dat een schilder een engineer is dan zou iedereen mij hier voor zot verklaren. Schilders en coders gebruiken wiskundige technieken, maar dat maakt van hun geen engineers.

Dat is nu net wat de definitie van engineering nochtans zei, het gebruiken van wiskundige technieken.

kwitters · 13 jan 2007

QplQyer zei:
Dan is alles naar een programmeertaal vertalen evenzeer een utopie.

Inderdaad! In software development zijn er enorm veel zaken die je niet formeel kan voorstellen.

QplQyer zei:
Dat is nu net wat de definitie van engineering nochtans zei, het gebruiken van wiskundige technieken.

Dus schilderen is een engineering practice?

killgore · 13 jan 2007

kwitters zei:
Inderdaad! In software development zijn er enorm veel zaken die je niet formeel kan voorstellen.

Dus schilderen is een engineering practice?

nee, de schilder kan wiskundige technieken gebruiken om hem te helpen bij het ontwerp, zaken als dieptezicht, anatomie, ..., dat zou je in zekere vorm engineering kunnen noemen ja.

Echter, het schilderen zelf heeft te maken met talent, creativiteit & vooral veel oefening. Alsook (natuurlijk) is wat ik aanhaalde maar een beperkte periode waar ze echt dat wiskundige gebruikten. Bij bv. abstracte ging men zich soms wel baseren op wiskundige figuren, maar wiskunde zelf werd nauwlijks toegepast. Dit deel kan je dan weer vergelijken met programmeurs, metsers, ...

.

Maar dit gaat ietsje te offtopic

.

Alles naar wiskunde vertalen is geen utopie. Je kan wel van alles een wiskundige beschrijving geven (aangezien de wiskunde ontstaan is uit het beschrijven van de werkelijkheid). Het probleem echter is dat sommige beschrijvingen zo immens complex zijn en dat we van andere beschrijvingen (ik denk aan intelligentie) gewoon nog niet weten hoe we er aan zouden moeten beginnen en dat we voor nog andere (4-kleuren probleem, traveling salesman, schrödingervergelijking van meerdere-elektronen systemen, ...) geen exacte oplossing hebben. Dat laatste geval houdt dus in dat er geen algoritme bestaat om een algoritme op te stellen, waaruit dus de creativiteit volgt die, zelfs bij engineering dus, hoogstnoodzakelijk is.

Wat men echter wel kan doen, en wat de bedoeling is bij SE, is de gekende wiskundige beschrijvingen samenvatten en proberen te bundelen in een theorie (combinatoriek, grafentheorie, algebra, ...). Hieruit kan men dan weer proberen om standaardtechnieken te ontwikkelen voor het oplossen van problemen. Jij als ingenieur moet dan zelf inzien welke techniek je kan gebruiken en ook hoe je die zo optimaal mogelijk kan gebruiken.

wlibaers · 14 jan 2007

Wel, als je het niet wiskundig kan voorstellen, dan kan je het ook niet programmeren, want een programma is gewoon een reeks wiskundige bewerkingen (discrete wiskunde uiteraard).

Het probleem van kwitters lijkt vooral te zijn dat een computer een bij uitstek wiskundige machine is, maar dat de meeste software tegenwoordig gemaakt wordt om de wiskunde zo goed mogelijk te verbergen. Er zijn waarschijnlijk veel programma's waarbij de GUI code complexer is dan de rest. Zelfs redelijk complexe wiskundige systemen zijn vaak vrij eenvoudig naar code te vertalen als je het wiskundig model begrijpt, maar de interface is altijd wat proberen en aanpassen.

En "software engineering"... Hangt ervan af wat ermee bedoeld wordt. Formele bewijzen van de software? (en dan nog door eerst de bewijzen te maken en dan pas te vertalen naar code)

Of misschien gewoon een hoop patterns aan elkaar plakken, zorgen dat een tab in de source het juiste aantal spaties geeft, en geen goto gebruiken? Dan kan je niet echt de vergelijking met bijvoorbeeld sterkteleer maken, eerder met een iemand die verschillende manieren kent om bakstenen te stapelen, maar niet precies weet waarom en hoe.

Hale · 14 jan 2007

effe off-topic beetje puriteins wezen

killgore zei:
...
en dat we voor nog andere (4-kleuren probleem, traveling salesman, schrödingervergelijking van meerdere-elektronen systemen, ...) geen exacte oplossing hebben.
...

er bestaan wel degelijk algoritmen die exacte oplossingen geven voor problemen zoals traveling salesmen (bereken bijvoorbeeld gewoon van alle permutaties de lengte en je bent er). Men kent echter (voorlopig? cfr. NP != P?) geen algoritmen die een oplossing berekenen in polynomiaal tijd.

Er zijn echter wel problemen waar geen algoritmen voor kunnen bestaan! Zoals bijvoorbeeld het halting-probleem en vele afgeleiden daarvan (bv. data flow analyse).

tot zover dit theoretisch intermezzo

Om terug on-topic te gaan:

Ik denk dat je SE veel ruimer moet zien dan alleen maar het gebruik van formele en wiskundige modellen.
SE is imho veel eerder het gestructureerd aanpakken (engineeren) van software projecten. Hierbij gebruik makend van o.a. concrete ontwikkelings processen (Xtreme Programming, Unified Process, waterfall, ...), design en architecturale patterns, (formele?) interface contracten, formele UML beschrijvingen, degelijke gestructureerde requirements analyses etc.
Heeft dit perse iets te maken met wiskunde en formele methodes? Laat het gebruik van een pipe en filter architectuur je toe om wiskundig iets te bewijzen? unlikely, MAAR het zorgt er wel voor dat je op een gestructureerde manier een werkend product verkrijgt ipv de trial en error methode. And that's what engineering is all about.

Natuurlijk zijn er wel degelijk plaatsen in het informatica landschap waar die nauwe rigoreuze wiskundige aanpak gebruikt wordt tijdens de ontwikkeling. Zo wordt er bijvoorbeeld aan het departement computerwetenschappen van de KUL onderzoek gedaan naar terminatie analyse van (prolog) programma's waarbij vertrokken wordt vanuit een wiskundig framework (meer bepaald door gebruik te maken van level mappings naar de natuurlijke getallen).

Unzip Attack · 15 jan 2007

ik heb maar klein deel gelezen maar de vergelijking van software engineering met 'het bouwen van een brug' is eigenlijk al verkeerd.

Wat hier over het hoofd wordt gezien is dat software engineering in 95% van de gevallen een creatief proces is. Dat wil zeggen dat er geen voorgetekend stappenplan bestaat dat leert hoe een specifiek software product in een specifiek probleem en oplossingsdomein te bouwen.
Dit in tegenstelling te het bouwen van een brug, dat tot in de puntjes een stappenplan heeft dat gevolgd kan worden. Op dat vlak is software een vreemde eend in de bijt, en wordt het onterecht door nogal wat project managers (die meestal geen ervaring met software projecten hebben) gezien als een traditioneel proces.

Dit houdt echter niet in dat modellen en modelgebaseerde ontwikkeling uitgesloten is. Dit is een methode als een ander, maar neemt niet weg dat een probleemdomein in software engineering ZEER complex kan zijn en daardoor VEEL te veel tijd inneemt om het eerst modelleren.
Toch wil dit alles behalve zeggen dat er geen 'gestructureerde' aanpak meer bestaat, kijk maar naar de komst van agile methodes (XP, Scrum,...) de laatste jaren. Alleen herkennen deze methodes het feit dat software engineering != traditionele processen (brug bouwen,...).

trouwens software patterns etc zijn maar een zeeer klein deeltje van software engineering, gezien op een lager (code) niveau. se is veeel meer dan dat.

QplQyer · 15 jan 2007

Unzip Attack zei:
ik heb maar klein deel gelezen maar de vergelijking van software engineering met 'het bouwen van een brug' is eigenlijk al verkeerd.

Dan heb je het niet goed gelezen.
De vergelijking klopt volledig zoals ze neergeschreven is, de vergelijking heeft natuurlijk enkel betrekking op het gebruiken van wiskundige modellen om iets te bouwen en omtrent wat engineering is.

Wat hier over het hoofd wordt gezien is dat software engineering in 95% van de gevallen een creatief proces is. Dat wil zeggen dat er geen voorgetekend stappenplan bestaat dat leert hoe een specifiek software product in een specifiek probleem en oplossingsdomein te bouwen.
Dit in tegenstelling te het bouwen van een brug, dat tot in de puntjes een stappenplan heeft dat gevolgd kan worden. Op dat vlak is software een vreemde eend in de bijt, en wordt het onterecht door nogal wat project managers (die meestal geen ervaring met software projecten hebben) gezien als een traditioneel proces.

Andere ingenieursdomeinen hebben ook geen stappenplan. Een elektrotechnieker die een component moet maken, die heeft ook veel creativiteit nodig en heeft ook geen vast stappenplan. Maar die valideert wel dat wat hij doet correct is en en zoals verwacht functioneert. Het feit dat iets een creatief proces is verhindert dus in geen enkele mate dat men het wel tot "engineering" kan maken.

killgore · 15 jan 2007

Unzip Attack zei:
Wat hier over het hoofd wordt gezien is dat software engineering in 95% van de gevallen een creatief proces is.

bs, waarom? Lees de replies van qplqyer en wlibaers (hij zegt trouwens iets korter &duidelijker hetzelfde als mij).

SE is juist de bedoeling om dat creatief gedeelte (zoals het hier gebruikt wordt niet meer dan een mooi woord voor: "probeer maar & kijk of het werkt") te verminderen, ze is voor een deel onvermijdelijk (programmastructuur bv.), maar men probeert er tot op zo hoog mogelijk niveau exactheid in te brengen (design patterns dan bv. voor die programmastructuur).

Daarnaast heeft SE nog te maken met keuzes als "welke algoritmes?". En dat heeft nu eens niets te maken met creatief zijn.

Je interpretatie van stappenplan is ook verkeerd, inzicht is een beter woordje, en dat inzicht maakt gebruik van gekende (wiskundige) modellen om een plan op te stellen en andere (wiskundige) modellen om het te toetsen

Unzip Attack · 18 jan 2007

killgore zei:
bs, waarom? Lees de replies van qplqyer en wlibaers (hij zegt trouwens iets korter &duidelijker hetzelfde als mij).

SE is juist de bedoeling om dat creatief gedeelte (zoals het hier gebruikt wordt niet meer dan een mooi woord voor: "probeer maar & kijk of het werkt") te verminderen, ze is voor een deel onvermijdelijk (programmastructuur bv.), maar men probeert er tot op zo hoog mogelijk niveau exactheid in te brengen (design patterns dan bv. voor die programmastructuur).

da's pas bullshit. met creatief wordt niet bedoelt "ik doe maar op en zie of er iets uitkomt". softwareontwikkeling is een creatief proces omdat het meestal (95% van de tijd) unieke producten levert. dat hoeft daarom nog geen nieuwe algoritmes te bevatten, het samenvoegen van bestaande componenten en denkwijzes leidt evenzeer tot een creatief nieuw product.

killgore zei:
Je interpretatie van stappenplan is ook verkeerd, inzicht is een beter woordje, en dat inzicht maakt gebruik van gekende (wiskundige) modellen om een plan op te stellen en andere (wiskundige) modellen om het te toetsen

dit is echt grappig en grappig in de hele discussie. men doet het hier af of er gewoon overal wiskundige modellen zijn die perfect passen op eender welk software project. de kennis van een probleemdomein is volgens die redenering VOLLEDIG op voorhand bepaalt en wiskundige modellen van dit probleemdomein gaan opstellen is dan precies ook totaal geen probleem. Imo 1 grote utopie die trouwens nog maar in weinig projecten succesvol is gebruikt, projecten die meestal een eenvoudig probleemdomein hebben...

agile development (iets dat zijn succes de laatste jaren enorm heeft bewezen) en het agile manifesto (http://agilemanifesto.org/) zetten mijn stelling enkel nog kracht bij, vermits ze "Responding to change over following a plan" zetten. Software development is namelijk niet zoals een ingenieursbrug tekenen en ze daarna mooi helemaal uitwerken. zo werk het simpelweg niet, software is namelijk enorm onderhevig aan verandering (creatieve verandering ("oh zo kunnen we dat ook maken", "die nieuwe lib is mss een goede toevoeging",...) en VOLLEDIG plangebasseerd werken is simpelweg een dikke grote illusie.

ik geloof wel in agile model-driven developement dat een combinatie tussen beiden zoekt, maar niet overdrijft in zijn modellen en dit vooral in de eerste iteraties doet.

Design patronen zijn imo altijd toepasbaar en zitten gewoon op compleet ander niveau...

killgore · 18 jan 2007

Unzip Attack zei:
da's pas bullshit. met creatief wordt niet bedoelt "ik doe maar op en zie of er iets uitkomt". softwareontwikkeling is een creatief proces omdat het meestal (95% van de tijd) unieke producten levert. dat hoeft daarom nog geen nieuwe algoritmes te bevatten, het samenvoegen van bestaande componenten en denkwijzes leidt evenzeer tot een creatief nieuw product.

Die indruk had ik niet bij 90% van het gebruik van dat woordje hier

Unzip Attack zei:
dit is echt grappig en grappig in de hele discussie. men doet het hier af of er gewoon overal wiskundige modellen zijn die perfect passen op eender welk software project. de kennis van een probleemdomein is volgens die redenering VOLLEDIG op voorhand bepaalt en wiskundige modellen van dit probleemdomein gaan opstellen is dan precies ook totaal geen probleem. Imo 1 grote utopie die trouwens nog maar in weinig projecten succesvol is gebruikt, projecten die meestal een eenvoudig probleemdomein hebben...

agile development (iets dat zijn succes de laatste jaren enorm heeft bewezen) en het agile manifesto (http://agilemanifesto.org/) zetten mijn stelling enkel nog kracht bij, vermits ze "Responding to change over following a plan" zetten. Software development is namelijk niet zoals een ingenieursbrug tekenen en ze daarna mooi helemaal uitwerken. zo werk het simpelweg niet, software is namelijk enorm onderhevig aan verandering (creatieve verandering ("oh zo kunnen we dat ook maken", "die nieuwe lib is mss een goede toevoeging",...) en VOLLEDIG plangebasseerd werken is simpelweg een dikke grote illusie.

ik geloof wel in agile model-driven developement dat een combinatie tussen beiden zoekt, maar niet overdrijft in zijn modellen en dit vooral in de eerste iteraties doet.

Design patronen zijn imo altijd toepasbaar en zitten gewoon op compleet ander niveau...

merk de () rond wiskundig op <_<.

kwitters · 18 jan 2007

QplQyer zei:
Het maken van verstaanbare code en software waar de gebruiker zich goed in voelt en formele methoden en dergelijke meer gebruiken zijn geen twee exclusieve zaken. Men kan die twee zeker combineren. Dus het coder-plezier hoeft daarom niet af te nemen.

Het maken van upfront ondubbelzinnige requirements die volledig wiskundig gespecifieerd zijn en het produceren van software waar de klant zich goed in voelt zijn 2 exclusieve zaken.

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.

Kijk anders eens op http://www.martinfowler.com/articles/newMethodology.html dan krijg je een idee van hoe software in de "echte" wereld gemaakt wordt. Uit het artikel: "We should be very wary of the traditional engineering metaphor for building software. It's a different kind of activity and requires a different process".

Software engineering is in het beste geval een slecht gekozen metafoor voor software development.

QplQyer · 18 jan 2007

Unzip Attack zei:
dit is echt grappig en grappig in de hele discussie. men doet het hier af of er gewoon overal wiskundige modellen zijn die perfect passen op eender welk software project. de kennis van een probleemdomein is volgens die redenering VOLLEDIG op voorhand bepaalt en wiskundige modellen van dit probleemdomein gaan opstellen is dan precies ook totaal geen probleem. Imo 1 grote utopie die trouwens nog maar in weinig projecten succesvol is gebruikt, projecten die meestal een eenvoudig probleemdomein hebben...

De kennis van het probleemdomein hoeft totaal niet volledig gekend te zijn op voorhand. Integendeel, het gebruik van wiskundige modellen dient net om het probleemdomein beter te begrijpen!

De reden dat het in weinig projecten succesvol is gebruikt is omdat geen enkele afgestudeerde voldoende kennis heeft meegekregen om dit succesvol toe te passen. Dit soort zaken vereisen namelijk nieuwe denkwijzen, die in ons hoger onderwijs niet voldoende onderwezen worden, deels omdat de lesgevers er niet genoeg met vertrouwd zijn, deels omdat studenten er nogal vaak over klagen omdat het te moeilijk zou zijn.

Trouwens, "formele methoden" worden gebruikt door de NASA, ook microsoft experimenteert ermee, Intel gebruikt ze om hun processoren te controleren, ... wat allemaal verre van simpele toepassingsdomeinen zijn.

QplQyer · 18 jan 2007

kwitters zei:
Het maken van upfront ondubbelzinnige requirements die volledig wiskundig gespecifieerd zijn en het produceren van software waar de klant zich goed in voelt zijn 2 exclusieve zaken.

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.

Kijk anders eens op http://www.martinfowler.com/articles/newMethodology.html dan krijg je een idee van hoe software in de "echte" wereld gemaakt wordt. Uit het artikel: "We should be very wary of the traditional engineering metaphor for building software. It's a different kind of activity and requires a different process".

Software engineering is in het beste geval een slecht gekozen metafoor voor software development.

Je verwart "de toestand nu" met "naar waar we moeten evolueren", typisch eigenlijk om zo een dooddoener te trachten posten ("kom maar eens terug als jullie echte ervaring hebben").

Opmerkingen over het gebrek aan ervaring "in the real world" zijn dus totaal ongepast, want gaan enkel maar over de huidige toestand in bedrijven, waar het beeld dat ik ophang gaat over waar men moet naar evolueren.

Zie ook mijn vorige opmerking, waar aangegeven wordt dat dit inderdaad nog niet gebruikt wordt in de praktijk en waardoor dit ondermeer komt (gebrek aan kennis en gebrek aan niet-kennis-vereisende tools).

kwitters · 18 jan 2007

QplQyer zei:
Je verwart "de toestand nu" met "naar waar we moeten evolueren", typisch eigenlijk om zo een dooddoener te trachten posten ("kom maar eens terug als jullie echte ervaring hebben").

Jij verwart "naar waar we moeten evolueren" met "vanwaar we komen en wat gefaald heeft".

QplQyer zei:
Zie ook mijn vorige opmerking, waar aangegeven wordt dat dit inderdaad nog niet gebruikt wordt in de praktijk en waardoor dit ondermeer komt (gebrek aan kennis en gebrek aan niet-kennis-vereisende tools).

Zie mijn vorige opmerkingen waarom dit nooit zal lukken en een utopie is. (Oh I love this welles-nietes spelleke

, k had eigelijk al lang moeten ophouden met deze discussie, maar ja, het was sterker dan mijzelf

).

QplQyer · 18 jan 2007

We komen helemaal nog niet van wat ik bedoel.

Enkele punten omtrent die tekst over agile development:

All of this brings a few questions to mind. The first is the matter of how difficult it is to get a UML-like design into a state that it can be handed over to programmers. The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing. The models that civil engineers use are based on many years of practice that are enshrined in engineering codes. Furthermore the key issues, such as the way forces play in the design, are amenable to mathematical analysis. The only checking we can do of UML-like diagrams is peer review. While this is helpful it leads to errors in the design that are often only uncovered during coding and testing. Even skilled designers, such as I consider myself to be, are often surprised when we turn such a design into software.

Dit probleem met UML is er één dat moet opgelost worden door UML net te formaliseren, zodat we dit wiskundig kunnen beschrijven. Daar gebeurt onderzoek naar.
Het zoeken van problemen in de design-fase is net één van de voordelen van een degelijk wiskundig model, in plaats van UML. Dit argument pro agile programming is er dus eerder één pro-wiskundige modellering.

Another issue is that of comparative cost. When you build a bridge, the cost of the design effort is about 10% of the job, with the rest being construction. In software the amount of time spent in coding is much, much less McConnell suggests that for a large project, only 15% of the project is code and unit test, an almost perfect reversal of the bridge building ratios. Even if you lump in all testing as part of construction, then design is still 50% of the work. This raises an important question about the nature of design in software compared to its role in other branches of engineering.

De kosten voor het maken van bugs, voor de geleden schade door de bug aan het bedrijfsimago, aan de klanten, zitten er wel niet bijgerekend.
Overigens leidt een goed design tot een aanzienlijke mindere hoeveelheid werk bij uitbreiding van een bestaand iets.

These kinds of questions led Jack Reeves to suggest that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker. Indeed anything that you can treat as construction can and should be automated.

Wanneer men dan nog verder denkt kan men argumenteren dat de source-code toch een constructie-proces is. Eén dat in de loop van de tijd kan geautomatiseerd worden (programma's genereren vanuit de specificaties, er gebeurt al een hele poos onderzoek naar).

Alles wat nu manueel gebeurt, maar kan geautomatiseerd worden is in essentie een constructie-fase volgens bovenstaande. Daar veel "code-schrijven" geautomatiseerd wordt, kan het schrijven van code niet anders zijn dan een constructie-fase. Bedenk ook de vele applicaties die point-and-click programming toelaten.

Een bijkomend voordeel van design te scheiden van het coden (en dat aantoont dat design verschillend is van het concrete coden) is dat men veel sneller met een design kan overstappen op een andere programmeertaal (eventueel na enkele jaren), dan door de code uit te pluizen.

De rest van de tekst gaat voornamelijk over het business-model van software-development als people-oriented process of niet, wat weinig te zien heeft met software-engineering zoals ik het bedoel. Eerder over de management-kant van de zaak. Overigens sluit het gebruik van de processen daar uitgelijnd wederom niet noodzakelijk het gebruik van formele methoden uit. Integendeel, veranderende specificaties kunnen net beter opgevangen worden door het gebruik van een wiskundig model. Men kan dan immers, door het voordeel van het wiskundig redeneren, de gelijkenissen tussen de oude en nieuwe specificaties beter inzien en zo code unificeren van specificaties die op het eerste zicht verschillend lijken. Iets wat onmogelijk is zonder de specificaties formeel te gaan beschrijven.
Een wiskundig model helpt dus net om op veranderende requirements in te gaan en past volledig binnen de agile requirements visie.

--

Wat de opmerking over het welles-nietes-spelletje betreft: ik geloof dat ik duidelijk beargumenteerd heb waarom creativiteit en wiskundige modellering elkaar niet in de weg staan. Daarna heb ik niet veel argumenten meer zien staan die het tegendeel zouden aantonen. Ik geloof dat ik alles wat ik heb gezegd wel redelijk beargumenteerd heb, van een welles-nietes-spelletje kan ik dus niet beticht worden.

killgore · 18 jan 2007

kwitters zei:
Jij verwart "naar waar we moeten evolueren" met "vanwaar we komen en wat gefaald heeft".

SE is voor 95% nog puur academisch. Hoe kan je dan in godsnaam spreken over iets "vanwaar we komen

? Zelfs op academisch niveau zijn er nog constante fluctuaties.

edit: en nogmaals: jij vergelijkt appelen met peren imho. Het programmeren zelf en SE zijn voor een zeer groot deel verschillende zaken. Jij verstaat/beschrijft software engineering alsof het mogelijk is computers te ontwerpen die zelf programma's kunnen schrijven. Dit is niet wat SE inhoudt

jodeman · 18 jan 2007

killgore zei:
SE is voor 95% nog puur academisch. Hoe kan je dan in godsnaam spreken over iets "vanwaar we komen ? Zelfs op academisch niveau zijn er nog constante fluctuaties.

edit: en nogmaals: jij vergelijkt appelen met peren imho. Het programmeren zelf en SE zijn voor een zeer groot deel verschillende zaken. Jij verstaat/beschrijft software engineering alsof het mogelijk is computers te ontwerpen die zelf programma's kunnen schrijven. Dit is niet wat SE inhoudt

Waar haalt ge die cijfers? Ik dacht dat dat in het bedrijfsleven enorm veel werd gedaan? Bij DHL waar ik vakantiewerk deed daar deden ze ook alles via modellen.
Ik denk dat er ergens de lijn moet getrokken worden, als je grote programma's maakt met enorm veel logica en moeilijke relaties is het nodig om te modelleren, dat moet daarom niet erg strikt zijn maar er moet toch iets van modellering gedaan worden denk ik.
Bij minder grote visuele programma's mag er vrijheid voor de programmeur bestaan en modelleren is dan alleen maar overbodig en tijdrovend.
Voor het visuele gedeelte vind ik dat er vrijheid moet bestaan voor de programmeur in samenspraak met de business partner.

Archief - [ALG]SE Software "engineering"

QplQyer

Legacy Member

killgore

Legacy Member

kwitters

Legacy Member

QplQyer

Legacy Member

kwitters

Legacy Member

killgore

Legacy Member

wlibaers

Legacy Member

Hale

Legacy Member

Unzip Attack

Legacy Member

QplQyer

Legacy Member

killgore

Legacy Member

Unzip Attack

Legacy Member

killgore

Legacy Member

kwitters

Legacy Member

QplQyer

Legacy Member

QplQyer

Legacy Member

kwitters

Legacy Member

QplQyer

Legacy Member

killgore

Legacy Member

jodeman

Legacy Member