Groot Software Project Informatica Maarten Boasson
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.
Wat niet? Onderwijs in methoden en tools –dat staat allemaal in vele boeken, oa, McConnell, Pfleeger, Pressman, Sommerville, van Vliet –jullie kunnen allemaal lezen...
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
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
Inhoud hoorcolleges Weet ik nog niet helemaal Mogelijk gastsprekers –Specialisten op verschillende gebieden Testen, programmamanagement, formele methoden,... allen met praktijkervaring
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
E-ticketing
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 –duurden 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
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 eisen en specificatie niet altijd duidelijk
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
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
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
Engineering is niet zo eenvoudig...