Software Engineering Informatiekunde 2003-2004 Prof. Maarten Boasson www.science.uva.nl/~boasson.

Presentatie over: "Software Engineering Informatiekunde 2003-2004 Prof. Maarten Boasson www.science.uva.nl/~boasson."— Transcript van de presentatie:

1 Software Engineering Informatiekunde 2003-2004 Prof. Maarten Boasson www.science.uva.nl/~boasson

2 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

3 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

4 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

5 Engineering idee specificatie ontwerp productiedata geen engineering engineering

6 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!

7 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

8 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)

9 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

10 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

11 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.

12 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

13 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

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

15 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

16 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

17 Waar gaat software engineering over? Idee! 0011010100101011 1100100101000101 0111100111010000 1111110001001100... software engineering

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

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

20 Engineering is niet zo eenvoudig...

21

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

23 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

24 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

25 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

26 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

27 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

28 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

29 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...

30 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

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

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

33 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

34 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...