Groot Software Project Informatica 2004-2005 Maarten Boasson

Presentatie over: "Groot Software Project Informatica 2004-2005 Maarten Boasson"— Transcript van de presentatie:

1 Groot Software Project Informatica 2004-2005 Maarten Boasson boasson@science.uva.nl

2 Wat beoogt dit vak? Een beeld schetsen van de problemen van het bouwen van echte software-intensieve systemen Enigszins wegwijs maken in de gebruikte technieken Gevoel geven voor wat het betekent een complex software systeem te bouwen: er moet op “industriële” wijze een product gemaakt worden.

3 Wat niet? Onderwijs in methoden en tools –dat staat allemaal in vele boeken, oa, McConnell, Pfleeger, Pressman, Sommerville, van Vliet –jullie kunnen allemaal lezen...

4 Informatie over vak Blackboard carol.science.uva.nl/~boasson –Groot Software Project –Er staat niet veel Oude beschrijving van het ontwerpprobleem Een leerzaam artikel over een experiment student assistent –Simon Pauw (spauw@science.uva.nl)

5 Spelregels Iedereen doet enthousiast mee –Geen spijbelen –Waarschuwing bij verhindering en alleen met goede reden –Zelfwerkzaamheid Geen tentamen –Wel beoordeling van participatie kwaliteit van geleverde prestaties Samenwerking in teamverband

6 Inhoud hoorcolleges Weet ik nog niet helemaal Mogelijk gastsprekers –Specialisten op verschillende gebieden Testen, programmamanagement, formele methoden,... allen met praktijkervaring

7 Doel werkcolleges Thuis geraken in software engineering –dwz boeken lezen Team bouwen –Verdeling van taken en verantwoordelijkheden –Onderlinge communicatie –... Requirements analyse van ET probleem Plan van aanpak

8 E-ticketing

9 Engineering idee specificatie ontwerp productiedata geen engineering engineering

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

11 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

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

13 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

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

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

16 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

17 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

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

19 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

20 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

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

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

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

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

25 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 eisen en specificatie niet altijd duidelijk

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

27 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

28 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

29 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

30 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

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

32 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

33 Engineering is niet zo eenvoudig...

34