Software Engineering Informatiekunde Prof. Maarten Boasson

Wat beoogt dit college? Gevoel geven voor de problemen van het bouwen van echte software-intensieve systemen Enigszins wegwijs maken in de gebruikte technieken Een beeld schetsen van het vak

Wat niet? Onderwijs in methoden en tools –dat staat in ontelbare boeken, oa Sommerville McConnell, Pfleeger, Pressman –Ik ga niet voorlezen, maar wil graag vragen beantwoorden

Opzet hoorcolleges (liefst interactief) een probleem dat als een rode draad door het college loopt –probleem definitie wordt vandaag uitgereikt –jullie mogen suggesties doen voor oplossingen tentamen gaat over hoofdzaken uit Sommerville + colleges en heeft betrekking op hetzelfde probleem

Engineering idee specificatie ontwerp productiedata geen engineering engineering

Engineering in het algemeen Methode om van ontwerp tot realisatie te komen, waarbij: –methode aangeeft welke stappen worden gezet –theorie bestaat om vast te stellen dat we het goed doen Engineering gaat over de productie van artefacten!

Methode geeft aan welke stappen worden gezet: –na elke stap moet het op te lossen probleem kleiner geworden zijn –methode bevat vuistregels die ervaring codificeren –Civiele techniek: bruggen, wegen, spoorlijnen, etc –Chemische techniek: raffinaderijen, medicijnen, kunstsoffen,... –Vliegtuigbouw, auto’s, enz –Verschillende optimalisatiecriteria: value engineering, safety, duurzaamheid, enz

Theorie is nodig om juistheid van gemaakte keuzes vast te stellen: – natuurkunde, scheikunde, sterkteleer (statisch en dynamisch), aerodynamica,... –bijvoorbeeld: een brug kan (bijna) helemaal worden uitgerekend; het gedrag van een auto onder de meest uiteenlopende omstandigheden kan worden berekend in de chemie worden experimenten gedaan om de theorie te valideren (proeffabrieken)

Essentie van engineering Van ontwerp naar productie Vuistregels –Beperken de zoekruimte –Garanderen voortgang: het op te lossen probleem wordt gaandeweg kleiner Theorie –Maakt verificatie van genomen beslissingen mogelijk: we weten tegenwoordig zonder experiment dat een nieuw vliegtuig luchtwaardig is! Leereffect –Analyse van mislukte projecten –Opstellen van nieuwe vuistregels –Goed inzicht in wat wel en wat niet kan

Waarom software engineering? In 1968 was er een NATO workshop over de software crisis: Projecten –duurde langer dan voorzien –waren duurder dan begroot –leverden niet de beoogde kwaliteit

Tijdens die workshop is de term “software engineering” bedacht naar analogie van traditionele engineering en is er een plan opgesteld om in ca 10 jaar tot het beoogde resultaat te komen.

Waar zijn we nu? Software projecten –lopen nog steeds uit (en meer dan toen) –zijn nog steeds veel duurder dan begroot –leveren nog steeds onvoldoende kwaliteit en toch is er ruim 30 jaar onderzoek gedaan... en erg veel geld uitgegeven aan tools

Voorbeelden FAA: air traffic control systeem USA –loopt al 10 (20?) jaar –heeft miljarden $$ gekost –werkt nog steeds niet: er worden regelmatig delen in bedrijf gesteld die worden spoorslags weer gestopt

UK Nimrod (radar vliegtuig, cf AWACS) –heeft honderden miljoenen gekost –project is gestaakt zonder resultaat

Reserveringssysteem van een grote US airline –2 hubs: NW en ZO –semi-autonoom systeem in iedere hub –synchronisatie van beide systemen –synchronisatie bleek niet te bouwen  $70M weg

C2000 (communicatie politie, brandweer, etc) –heeft nu al miljoenen meer gekost dan begroot –is ruim over tijd en nog steeds niet in bedrijf –gaat nog veel geld kosten

Waar gaat software engineering over? Idee! software engineering

Software Engineering gangbare visie idee specificatie If then else While Loop call ontwerp

software engineering requirements (eisen) specificatie design (ontwerp) implementatie testen maintenance kunnen we niet

Engineering is niet zo eenvoudig...

Requirements Door beoogde gebruikers geformuleerde eigenschappen van het systeem –in termen van applicatiedomein –meetbare grootheden –stabiel tijdens realisatie van het systeem

Specificatie Technische eisen voor het systeem –systeem dat voldoet aan de specificatie moet het in gebruikerseisen beschreven gedrag vertonen –relatie tussen requirements en specificatie vastleggen dmv (belangrijkste) technische functies –minimaal, zodat voor realisatie voldoende keuzes blijven bestaan (“wat”, niet “hoe”) –grens tussen req en spec niet altijd duidelijk

Design (ontwerp) Beschrijft hoe het systeem in elkaar zit –moet aantoonbaar de spec realiseren –traceability –beschrijving op niveau van functies en hun interacties, interfaces –niet noodzakelijkerwijs executeerbaar

Implementatie Executeerbare code met de in het ontwerp bepaalde structuur, die de spec realiseert –te beschouwen als ontwerp op steeds gedetailleerder niveau –verschil tussen ontwerp en implementatie niet altijd duidelijk

Testen Verificatie dat geproduceerde code een systeem vormt dat aan de eisen voldoet –criteria nodig voor beslissingen –onmogelijk alle denkbare situaties te testen combinatorische explosie van mogelijkheden historie bij ontstaan van fouten belangijk

Maintenance Varieert van bug-fixes tot implementatie van nieuwe requirements –niemand vindt het leuk: wordt beschouwd als 2e-rangs werk –veroorzaakt “slijtage” oorspronkelijke ontwerp niet bekend/begrepen moet met te weinig middelen: onverstandige shortcuts

Is software maken wel engineering? Software –kent geen productiefase in de huidige praktijk –is vergelijkbaar met ontwerpfase die voorafgaat aan engineering in andere disciplines –traditionele engineeering taken (value engineering etc) zijn verweven met ontwerp, als ze al gedaan worden

Huidige praktijk van SE Blind vertrouwen in de laatste mode –we leren niet van het verleden –we vergeten verworvenheden en vinden het wiel steeds opnieuw uit (en steeds weer 6- of 8-hoekig) –gedomineerd door Guru’s Tools –zonder duidelijke theoretische ondergrond –als resultaat uitblijft/onvoldoende: meer tools Proces belangrijker dan inhoud –weer een valse analogie – software is geen productie! Ongebreideld optimisme –We nemen alles aan, beloven gouden bergen en men trapt er nog in ook Ondanks 30 jaar onderzoek is er nauwelijks iets verbeterd...

Mode verschijnselen SP PSE OO UML CMM XP Agents Software architectuur ADL MBA Heeft iemand ooit het nut onderzocht? Op zich nuttige begrippen verwateren tot het punt dat ze geen betekenis meer hebben en dan komt er dus iets nieuws

Software engineering Drie onderling samenhangende aspecten –Techniek –Proces –Organisatie

Techniek –Methoden tbv Eisen Specificatie Ontwerp Implementatie Testen –Er zijn legio “methoden”, met daarvan afgeleide tools – maar ze werken niet echt

Proces –Wat er allemaal moet gebeuren tbv de techniek Planningen Overdragen tussenresultaten Quality control Bijstellen eisen als dat technisch beter uitkomt Verbeteren van kundigheden.... –Processen zijn de laatste jaren het denken gaan overheersen

Organisatie –Welke organisatie ondersteunt de gekozen processen het beste? –Vaak worden die processen gekozen die het beste passen bij een bestaande organisatie De vraag is niet wat het beste resultaat levert, maar hoe de bazen kunnen blijven zitten...