Oplossingen Examenvragen Software Engineering 1.
Wat is software engineering? Het instellen en gebruiken van gezonde ingenieursprincipes om economisch verantwoorde software te verkrijgen dat betrouwbaar is en efficiënt werkt op reële machines. Invoeren van methodologie o klassieke levenscyclus (basis) o prototyping: als klant enkel globale doelen; als ontwikkelaar niet zeker van efficiëntie algoritme aanpasbaarheid OS human-machine interface o spiraalmodel o Unified Proces o Extreme Programming Klassieke levenscyclus (waterval model): - Specificatie - Analyse en ontwerp - Implementatie - Test - Onderhoud
Prototyping: - Bouwen en gebruiken van een model van een systeem o beter begrijpen van omgeving en vereisten o demonstratie van wat mogelijk is met bestaande technologie o efficiente manier om doelstellingen van ontwerp door te geven aan ontwikkelaars o vroegere interactie met klant mogelijk, duidelijker zicht
-
o mogelijkheid om eisen te valideren en aan te passen Types: o Throway om klant te helpen de vereisten op te stellen kan niet evolueren naar een leverbaar systeem o Quick and dirty snel versie van systeem, dan wijzigen tot aanvaardbaar opgelet dat iets tijdelijks niet iets permanents wordt aan die van de klant o Detail Design-Driven afgeleid van andere ingenieursdisciplines: preproductiemodel model is test-gestuurd: ontdekken van fouten o Nonfunctioning Mock-ups visuele voorbeelden van inputs en outputs naar klant (geen echte data, geen berekeningen) niet voldoende voor functionele eisen, want geen interactieve experimenten mogelijk o Evolutionary rapid prototyping eenvoudig aanpasbaar en uitbreidbaar werkend model van systeem (meestal niet volledig systeem) tonen van sleutelelementen voor implementatiefase ontdekken van functionele eisen (rekening houdend met budget) prototype evolueert naar leverbaar systeem
Spiraalmodel: - Klassiek iteratief model - Metamodel: kan alle andere modellen bevatten - Herhaling van: planning, risico analyse (eindigt met go/no go), engineering (software ontwikkeling), evaluatie door klant - Meer een manier van denken dan goed gedocumenteerde levenscyclus
2.
Conclusies CHAOS-rapport: - Er moet onderzocht worden daarom software projecten falen. Elke fout moet onderzocht, bestudeerd, gerapporteerd en bekend gemaakt worden. - De “succes potential” grafiek kan een handige tool zijn bij het voorspellen van het succes van een project of bij het evalueren van het falen van een project. - Het is moeilijk om iedereen van het managment te overtuigen om zich te houden aan een aantal regels en dat die regels het best zijn voor het bedrijf maar niet noodzakelijk voor hen zelf. - Kortere periodes waarin regelmatig softwarecomponenten afgewerkt, bekeken en getest (prototypes) worden verhogen het succes op slagen. (Groeiende software). Kleine componnenten zijn minder complex, dus minder duur. - fouten Æ brengt kennis Æ leiden tot succes - "Changes, changes, changes; they're the real killers." - De belangrijkste problemen bij projecten zijn: o Herstarten van het project o Overschrijden vooropgestelde budget o Overschrijden van de deadline o Onvolledigheid - De punten die het succes van een project waarborgen: o Samenwerking met de klant o Steun van het management o Duidelijke eisen van de klant o Goede planning o Realistische verwachtingen o Kleinere mijlpalen o Geschikte programmeurs o Duidelijke visie en doelen o Hard werkende en geconcentreerde programmeurs
3.
Fasen bij projectmanagment Initiatiefase
planningsfase
uitvoeringsfase
controlefase
afsluitfase
-
Initiatiefase: o Uitvoering project accepteren of niet: ongeschikt, ongepast ondoenbaar (niet genoeg kennis, mensen, tijd) verschuiven naar latere datum, meerdere projecten noodzakelijkheid, verkoop, marktpositie doenbaarheid: technisch, tijd, budget risico's: opstappen belangrijke personen o Doelen definiëren o Algemene verwachtingen definiëren (van klanten, van managment) o Scope project inschatten o Initiële teamleden selecteren taken van project: wat nodig? teamwerker ipv enkeling mensen met verschillende kennis, vaardigheden, …
-
Planningsfase: o Verfijnde scope: evenwicht tussen resultaten, tijd en middelen. o Opstellen takenlijst om doel te bereiken o Efficiëntste taaksequentie opstellen o Rooster opmaken + toekennen middelen o Plan laten goedkeuren o Opsplitsen project in beheersbare taken o Mijlpalen opstellen o Netwerkdiagramma opstellen toont sequenties en relaties tussen taken identificeert mijlpalen (voor controle van verloop) opgesteld vanuit de taaklijst grafische voorstelling o Scheduling (schat de tijd voor elke taak) o Budget bepalen: 1/3 voor heen 1/3 voor terug 1/3 voor onverwachte omstandigheden
-
Uitvoeringsfase: o Leiden v/h team o Vergaderen met team o Communiceren met management en klanten o Oplossen problemen en conflicten o Zorgen voor voldoende middelen o Starten uitvoering: Projectbijeenkomst o leiding o communicatie (groepsvergaderingen, individuele gesprekken, feedbacks, …)
-
Controlefase:
o o o o o o -
4. -
5. -
-
-
-
Kijken of er geen afwijkingen zijn van het plan Corrigeren plan behandelen aanvragen voor projectwijzigingen Herschikken indien nodig Aanpassen middelen als nodig Eventueel terug naar planning
Afsluitfase : o wat bereikt? o Team ontmantelen o bespreken van projectverloop en -resultaten o schrijven van rapport 12 Gouden regels voor een projectleider: Zoeken naar consensus voor projectresultaten (wat te bereiken) Zoeken naar het beste team (mensen motiveren en werk verdelen) Ontwikkel een goed plan en houd het up-to-date Bepaal hoeveel middelen er nodig zijn voor het project (eventueel onderhandelen) Zorg voor een realistisch schema Niet meer doen dan mogelijk en nodig (WAT duidelijk maken voor iedereen) Onthoud dat mensen tellen. Het succes van het project is afhankelijk van mensen. Formele en blijvende ondersteuning v/h management winnen Bereid zijn om aanpassingen door te voeren Mensen informeren (“If they know nothing of what you are doing, they suspect you are doing nothing”) Bereid zijn om nieuwe zaken te proberen Word een leider Doelstellingen van projecten: Voordelen leveren bv. softwareproject voor klant o beter systeem voor klant (tijd-, kostenbesparend) o winst voor onderneming Duidelijk de verwachte resultaten en winsten beschrijven o goed overdacht o criteria om het eindresultaat te beoordelen (i.f.v. tijd, kost, resultaten) o consensus: iedereen moet akkoord gaan Goed product maken dat voldoet aan de eisen van klant Criteria: specifiek bekijken en beschrijven. Niet enkel als winst maken bekijken realistisch (geen huis bouwen met 1 miljoen fr als land al 4 miljoen fr) einddatum meetbaar (klaar, kwaliteit) overeenstemming verantwoordelijkheden voor bereikte doelen Risico's en beperkingen:
6. -
7. -
8. -
doenbaarheid binnen beperkingen van economy, politiek, wetten, structuren risico's: weer, werken aan elektriciteit, failliet leverancier, staking, reorganisatie bedrijf, … beperkingen: budget, mensen technologische risico's OO: ervaring? technologie opgedrongen: werkt goed? genoeg mogelijkheden?
Wat zijn taken en hoe kaderen zij zich binnen een project: Een taak is een duidelijk, voldoende gedetailleerd beschreven opdracht Een taak moet één geheel vormen Een taak moet in een schema gevoegd kunnen worden Een taak moet meetbaar zijn Een taak moet de nodige middelen bepalen (tijd, mensen,…) Een taak kadert zich binnen een project via mijlpalen Bespreek communicatie tijdens de uitvoering van een project: Regelmatig groepsvergadering (kort en to-the-point, niet aflassen!) Individuele gesprekken, sommige zaken niet geschikt voor in groep Alles is bespreekbaar Feedback over projectstatus Grote feestjes enkel voor belangrijke mijlpalen Geschreven boodschappen: Zo weinig mogelijk Kort en to-the-point Zorg dat de boodschap overkomt zoals bedoeld Nagaan of de boodschap is aangekomen Opletten dat de boodschap niet in de verkeerde handen valt. Welke conflicten kunnen tijdens het verloop van het project opduiken: De teamleden staan niet achter hetzelfde doel : niet aanvaarden volgorde taken, misverstaan van verwachte resultaten. Taakbeschrijving niet specifiek genoeg Administratieve procedures : aantal/vorm rapporten , verspreiding geheime info Teamleden weten niet goed wat ze moeten doen. Technische onzekerheid Verdeling taken ( vb saaie taken, leiden subgroep ) Budgetten ( vb deelgroep verbruikt teveel) Schema: niet genoeg tijd om taken te volbrengen Persoonlijke conflicten
9. Wat is een model? Wat is een goed model? Waarom modelleren? Hoe kan men modellen klasseren? - Een model is de abstractie (selectief onderzoeken/bekijken van bepaalde aspecten van een probleem ) van iets met het doel het beter te verstaan, vooraleer men het bouwt. isoleer de aspecten die belangrijk zijn voor een bepaald doel altijd incompleet - Goed model: vangt de cruciale aspecten verwijdert de niet-cruciale aspecten programmeertaal is geen goed hulpmiddel! - Waarom modelleren: Testen van fysisch iets voor bouw Communicatie met klanten Visualisatie: ontwerper ziet idee, opbouw Reduceren van complexiteit: menselijk brein is beperkt - Modellen klasseren volgens soort: dynamisch model (beschrijft het gedrag) statisch model (beschrijft de structuur) functioneel model (beschrijft de functie, relatie I/O) - Modellen klasseren volgens doel: domein model (vereisten systeem) analyse model (implicaties van de eisen onderzoeken) design model (invullen van de interne structuur) 10. -
-
-
Wat is UML ? Geef ook een lijst van de diagrammen: Unified Modeling Language : verzameling van visuale modelleertalen standaard UML 1.0 1997 UML 2.0 2003 Diagrammen UML1.0: Use case diagram Class diagram Interaction diagram (sequentie/collaboratie) Package diagram State diagram Activity diagram Deployment diagram Diagrammen UML2.0: Structuurdiagrammen Gedragsdiagrammen
11. Dynamisch gedrag kan men modelleren met interactie-, toestands- en activiteitsdiagrammen. Wanneer gaat men wat gebruiken? Geef voor elk een voorbeeld: - Interactiediagram: o Beschrijven hoe groepen van objecten samenwerken.
o Typisch: gedrag van 1 use case. o Niet gebruiken: gedrag van 1 object over meerdere use cases Æ toestandsdiagram gedrag meerdere use cases Æ activiteitendiagram o 2 soorten : Sequentie: focus op sequentie van boodschappen verstuurd en ontvangen door objecten. Collaboratie: meer ruimtelijke relaties tonen ( sequentie => tijd ) -
Toestandsdiagram: o Gedrag van systeem te beschrijven o OOmodel: gebruikt voor 1 klasse, gedrag van 1 object niet goed om gedrag van interagerende objecten te tonen o Beschrijven alle mogelijke toestanden v/e object. o Beschrijving van overgangen tussen toestanden o niet tekenen voor elke klasse, enkel als interessant gedrag opstellen diagram helpt om te begrijpen o vooral voor userinterface-objecten controle-objecten
-
Activiteitsdiagram: o Modelleren van workflow. o Analyse v/e use case: welke acties moeten er plaatsgrijpen o Verstaan van workflow over verschillende use cases, als verscillende use cases met elkaar interageren. o Behandelen van multi-threaded toepassingen (parallelisme) o Werk uit te voeren in een operatie/methode o Niet gebruiken: zien hoe objecten samenwerken Æ interactiediagram zien hoe een object zich gedraagt Æ toestandsdiagram
12. -
Waarmee moet men rekening houden bij het ontwerp van een User Interface? gemakkelijk te leren zijn, eenvoudig zijn in gebruik, logisch zijn, vergevingsgezind zijn. Het moet geschikt zijn voor alle soorten gebruikers. (niveau van kunde, cultuur, …) "user friendly" (relatief begrip, afhankelijk van gebruiker) user familiarity: termen en concepten uit de ervaringen van de belangrijkste gebruikers consistency: vergelijkbare operaties op dezelfde manier activeren gebruiker nooit verrassen verschillende interactiemogelijkheden voorzien systeem antwoordtijd niet te lang en niet te kort, alles ongeveer even snel. foutboodschappen (en/of waarschuwingen) o duidelijke formulering van gestelde probleem o constructieve raad om fout op te lossen
o melden van mogelijke gevolgen (corrupte file) o aandacht trekken (auditief of visueel) o nooit gebruiker beschuldigen -
-
-
13. -
-
-
-
help o uitleg over huidige opdracht of i/o waarde o on-line manuals tonen informatie o enkel relevante informatie o beste vorm (bv grafiek ipv tabel met waarden) o tekstuele informatie: zo duidelijk mogelijk (gebruik hoofdletters, indentatie, tekstgroepering, …) o ≠ vensters voor ≠ informatie User input beperken, beperk typen gebruiker oefent controle uit (geen sequenties opdringen) help voorzien voor commando's en input-waarden standaard gegevens voorzien, defaultwaarden Hoe kan men goede programmacode schrijven? Keuze juiste programmeertaal (OO, mogelijkheden vd taal, …) code moet herbruikbaar zijn: o samenhangende methodes o Beperkte/korte methodes. o Methodes die controle uitoefenen scheiden van berekeningsmethoden. o Zoveel mogelijk inputmogelijkheden dekken. o Zo algemeen mogelijk. o Geen globale info (alles met parameter/attributen) o vermijd modes (files die van gedrag veranderen afhankelijk van context) De code moet gemakkelijk uitbreidbaar zijn: o Object georienteerd o Inkapseling: interne structuur verborgen voor ander klassen o Zorg ervoor dat de operatie de andere klassen gecontroleerd kan bereiken. o Overerving De code moet robuust zijn: o Vermijd vooraf gedefinieerde limieten (dynamisch geheugen) o Beschermen tegen incorrecte user input o Check de actuele parameter. o Foutafhandeling o Voorzie debug mogelijkheden o Omgaan met schade: forward error recovery (beschadigde data herstellen), backward error recovery (recovery punten aanmaken) o N-versie programmering: meerdere versies v/h systeem ontwikkelen. De code moet verstaanbaar zijn voor anderen: o eerst ontwerp, dan code o zelfde namen als in ontwerp o Goede, duidelijke namen o Nooit dezelfde naam voor semantische verschillende operaties.
o o o o 14. -
-
-
-
-
-
-
-
Geen te diep geneste uitdrukkingen. Gebruik niet dezelfde tijdelijke variabele voor verschillende doelen. goede documentatie. Volg programmeerrichtlijnen binnen organisatie en/of groep.
Geef 15 puntjes over het schrijven van ononderhoudbare code. Lie in the comments. You don’t have to activliy lie, just fail to keep comments as up to date with the code. Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method. Make sure that every method does a little bit more (or less) than its name suggests. In the name of efficiency, use cut/paste/clone/modify. This works much faster than using many small reusable modules. Never put a comment on a variable. Facts about how the variable is used, its bounds, its legal values, its implied/displayed number of decimal points, its units of measure, its display format, its data entry rules, when its value can be trusted etc. should be gleaned from the procedural code. Try to pack as much as possible into a single line. This saves the overhead of temporary variables, and makes source files shorter by eliminating new line characters and white space. Tip: remove all white space around operators. Never put in any { } surrounding your if/else blocks unless they are syntactically obligatory. If you have a deeply nested mixture of if/else statements and blocks, especially with misleading indentation, you can trip up even an expert maintenance programmer. Use very long variable names or class names that differ from each other by only one character, or only in upper/lower case. An ideal variable name pair is swimmer and swimner. Never use local variables. Whenever you feel the temptation to use one, make it into an instance or static variable instead to unselfishly share it with all the other methods of the class. This will save you work later when other methods need similar declarations. C++ programmers can go a step further by making all variables global Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. If you have ideas about how the code should be reorganised or rewritten, for heaven’s sake, do not write them down. Remember the words of Thumper ”If you can’t say anything nice, don’t say anything at all”. What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired Choose your variable names to have absolutely no relation to the labels used when such variables are displayed on the screen. E.g. on the screen label the field ”Postal Code” but in the code call the associated variable ”zip”. Exceptions are a pain in the behind. Properly-written code never fails, so exceptions are actually unnecessary. Don’t waste time on them. Subclassing exceptions is for incompetents who know their code will fail. You can greatly simplify your program by having only a single try/catch in the entire application (in main) that calls System.exit().
-
-
-
15. -
-
Declare every method and variable public. After all, somebody, sometime might want to use it. If the boss asks if you are out of your mind, tell him you are following the classic principles of transparent interfaces. Never check input data for any kind of correctness or discrepancies. It will demonstrate that you absolutely trust the company’s equipment as well as that you are a perfect team player who trusts all project partners system operators. Always return reasonable values even when data inputs are questionable or erroneous. Include powerful third party libraries in your project and then don’t use them. Never use layouts. That way when the maintenance programmer adds one more field he will have to manually adjust the absolute co-ordinates of every other thing displayed on the screen. If your boss forces you to use a layout, use a single giant GridBagLayout, and hard code in absolute grid co-ordinates. Bespreek white and black box testing. Black Box Testing: o Aantonen dat: functies werken inputs goed geaccepteerd worden outputs correct geproduceerd worden integriteit van externe informatie bewaard blijft o Niet kijken hoe systeem er vanbinnen uitziet. o Meestal gebruikt na white box testing o Meer gericht op de informatie o Hoe: 1 geldige en 2 ongeldige inputs proberen Grenzen van inputdomein uittesten. Vergelijkingstesten White box testing: interne werking nagaan o waarom niet gewoon black box testing? logische fouten en verkeerde veronderstellingen zijn omgekeerd evenredig met de kans dat een pad wordt uitgevoerd pad kan regelmatig gevolgd worden, terwijl gedacht dat dit zelden zou gebeuren o Gebruikt controlestructuur van ontwerp/code om testen te onderwerpen: alle mogelijke paden doorlopen alle logische beslissingen bekijken alle lussen uitvoeren op grenzen en erbinnen datastructuren bekijken o Basispadtesten: Garandeert dat elke uitdrukking minstens 1x wordt uitgevoerd. Complexiteit van programma bepaalt aantal onafhankelijke paden. (graaftheorie) o Testen van condities: boolean operator errror boolean variable error relational operator error
arithmetic expression error o Dataflow testen: definities variabelen gebruik (inhoud) van variabelen o Lustesten: Enkelvoudig, genest, geconcateneert, ongestructureert genest: • 1 lus tegelijk • beginnen met binnenste ongestructureerde lussen herontwerpen
16. -
-
17. -
Waarom moet software onderhouden worden en wat zijn de mogelijke problemen? Waarom: o Verbeteren van achtergebleven fouten (20%) in de specificatie, het ontwerp, de implementatie en de documentatie. o Verbeteren van het software product (60%): extra functionaliteit, betere algoritmen o Veranderingen in de omgeving (20%): nieuwe hardware, nieuwe os’s Problemen: o Geen of slechte documentatie (Meestal hekel aan administratief papierwerk) o Wijzigingen slecht gedocumenteerd o Software niet ontwikkeld met mogelijke veranderingen, uitbreidingen in gedachte. o Moeilijk om iemand anders zijn programma te verstaan. o Vaak reverse engineering, uit code model halen o Fouten verbeteren = vaak nieuwe fouten Bespreek kort het Unified Proces. Use-case driven:
-
-
18. -
-
-
-
o Levenscyclus van het proces bestaat uit een aantal cycli, elke cyclus produceert een nieuwe release van product naar de klant (een nieuwe executable) o Ontwikkelaars moeten nagaan of alle opeenvolgende modellen conform de use cases zijn o Bij de implementatie moet mens steeds de gevraagde functionaliteit in het achterhoofd hebben. o Testers moeten de implementatie testen om zeker te zijn dat de use cases correct geimplementeerd zijn en dat het systeem voldoet aan de eisen van de klant Architectuur staat centraal: o architectuur: opbouw van systeem, wat zijn de verschillende onderdelen, de relaties en interacties tussen onderdelen. o belangrijk: verdeel systeem logisch in subsystemen waarbij de afhankelijkheden tussen subsystemen eenvoudig en beperkt zijn. Iteratief en incrementeel: o iteratie: aanpakken van een groep use cases die samen het product, zoals het dan is, uitbreidt. o incrementeel: groei van product (toevoegen van een extra functionaliteit) Bespreek kort Extreme Programming. Algemeen: o Alle projectmedewerkers verstaan ten gronde wat gebruikers willen o Ontwikkel software incrementeel o Herbekijk de eisen na elke kleine stap o Lever kleine incrementele componenten elke 3 weken o Bewijs dat zonder defecten o Herbekijk alle vragen van klant elke 3 weken o Voor kleine projecten, ander terug naar iteraties. Extreme: o Iedereen ontwerpt elke dag o Altijd het eenvoudigste kiezen o Code steed herzien o Altijd testen o Ontwerp en verfijn steeds de architectuur o Nieuwe code elke dag integreren en testen o elke dag afleveren Vereisten: o Klant/gebruiker moet steeds beschikbaar zijn (voor vragen en evaluatie) o Pair programming o Code van iedereen => iedereen mag wijzigen o Elke dag half uurtje samen zitten om het werk te verdelen. o Optimale teamgrootte: 6 o Optimale projectlengte: 6-9 maanden Nadelen:
Planning max 3 weken vooruit => onmogelijk om gehele kostprijs van het project op voorhand te schatten. o Werken aan kleine blokjes en onmiddellijke integratie in groot geheel => Structuur van groot geheel? o Gebruiker/klant steeds beschikbaar o
19. -
-
-
-
-
-
-
-
Hoe ga je de kwaliteit van software beoordelen? 3 belangrijke punten: o voldoen aan expliciete vereisten (bv gevraagde printfaciliteit ontbreekt of werkt niet naar behoren -> kwaliteit daalt) o niet volgen van ontwikkelingscriteria (vastgelegd in standaard) -> meestal kwaliteitsverlies (bv controle model voldoet aan functionele vereisten) o voldoen aan impliciete eisen (bv onderhoudbaarheid) Correctheid: correspondentie tussen software product en zijn functionele specificatie o niet mogelijk om correctheid te bewijzen in complexe producten zoals software o functionele specificaties zijn zelden precies en stabiel genoeg Betrouwbaarheid: software gedraagt zich goed en zoals gebruiker verwacht Robuustheid: onwaarschijnlijk dat software faalt (crasht) of onherstelbaar faalt Performantie: o Binnen vooropgestelde doelen, meestal response time o Zwart/wit-kwaliteit Bruikbaarheid: o gebruiksvriendelijkheid o zeer subjectief o vooral voor user interface ontwerp o hoe meer standaard hoe bruikbaarder Verstaanbaarheid: o Interne structuur en gedrag software o Voorwaarde voor onderhoudbaarheid Onderhoudbaarheid: o Corrigeren van fouten en onvolkomenheden o Aanpassen aan nieuwe eisen o Software verbeteren om nieuwe kwaliteiten te geven Schaalbaarheid: o Gemak waarmee software groeiende vraag kan volgen Herbruikbaarheid: o hoeverre kunnen componenten worden herbruikt Overdraagbaarheid: o Op verschillende platvormen draaibaar zonder of met kleine aanpassingen. Interoperability: o samenleven of samenwerken met andere software o open systeem Productiviteit: o efficiëntie en performantie van een proces
-
20. -
o snelheid waarmee sofware wordt geproduceerd Timeliness: o mogelijkheid om software op tijd te leveren Visibility: o transparant proces: duidelijk gedefinieerde en gedocumenteerde stappen en activiteiten o Vereiste voor CMM en ISO Bespreek kort Capability Maturity Model en ISO 9000. CMM: o Levert mogelijkheid om de softwareprocescapaciteit van een onderneming te meten o Zet doelen en prioriteiten voor procesverbetering o Helpt om acties te plannen o Geeft een methode om procesmanagement en kwaliteitsverbeteringsconcepten toe te passen op softwareontwikkeling en -onderhoud o Leidt een organisatie naar software engineering excellence o Immature proces: ad hoc: geïmproviseerd proces door ontwikkelaars en hun management. Niet nauwgezet gevolgd Zwaar afhankelijk van huidige ontwikkelaars Moeilijk om kwaliteit te voorspellen Door minder goede schattingen, grote kans op kost en planningsproblemen. Vaak productfunctionaliteit en -kwaliteit afgebrokkeld ten voordele van halen planning. o Mature proces: Gedefinieerd en gedocumenteerd: verstaan, gebruikt en levend Zichtbaar ondersteund door management Rollen en verantwoordelijkheden goed gedefinieerd en verstaan Trouwheid aan proces wordt nagekeken en afgedwongen Consistent met manier van werken ondersteund door technologie 5 optimaliserend 4 gemanaged 3 gedefinieerd 2 herhaalbaar 1 initieel
continue procesverbetering door kwantitatieve feedback van proces en door testen van nieuwe ideeën en technologiën softwareproces en productkwaliteit worden gedetailleerd gemeten en gecontroleerd softwareproces voor management en engineering is gestandaardiseerd, gedocumenteerd en geïntegreerd binnen een organisatie-wijd proces er is een basis projectmanagementproces voor het volgen van cost planning en functionaliteit. er is procesdiscipline om vroegere successen te herhalen processen zijn ad hoc en chaotisch
o Testing : Fase 0: geen verschil tussen testen en debuggen Fase 1: doel van testen is tonen dat software werkt Fase 2: doel van testen is: • tonen dat software niet werkt • fouten te vermijden in toekomst Fase 3: • Doel van testen is niet om iets te bewijzen • Risico op fouten reduceren tot het aanvaardbare Fase 4: doel van testen is fouten te vermijden in toekomst. -
ISO 9000: o Voor alle industrietakken o ISO 9001: meest algemeen: ontwerp, ontwikkeling en onderhoud o ISO 9000-3: Interpreteert ISO 9001 voor software Niet specifiek gericht op software, maar algemene principes die op software kunnen toegepast worden. o Bedrijf moet: organisatorische standaarden en procedures definiëren gedocumenteerd in organisatorisch handboek proces definiëren met beschrijving van nodige documenten. o ISO 9000 legt geen kwaliteitsproces vast o ISO 9000 certificatie:
21. -
-
-
-
22. -
Na audit Niet noodzakelijk betere software Geen aandacht voor best practices en kwaliteit Mogelijk om bv testprocedure te definiëren die die leidt tot incomplete software testing, zolang bedrijf procedures volgen en documenteert conform met de standaard Niet zelf toekennen, externe audit door Registrar.
Wat is software configuration management? Versiecontrole: o 1 persoon, 1 programma (release 1.0, release 1.1, release 1.2, … iemand fout gevonden, welke versie?) o tijdsdruk, terzelfdertijd meerder wijzigingen aan zelfde software o grote groepen ontwikkelaars op meerdere sites over de hele wereld verspreid. Identificatie: o naam + versienummer o elk deel dat onafhankelijk gebruikt getest of verkocht kan worden. o Alles in 1 repository soms kopiën in verschillende Geografische verspreide sites => periodische synch. Communicatie: o Informatie over taken: te doen, mee bezig, afgehandeld o wie welke taken? Kostcontrole: o Elke wijziging aanvragen en laten goedkeuren o Prioriteiten o Op elk ogenblik zicht op staat project Wat is een patroon ? Wat is een raamwerk? Wat zijn hun voor- en nadelen? Patroon: o Specifiek probleem dat herhaaldelijk voorkomt o Beschrijving van de kernoplossing o Kan niet onmiddellijk gebruik worden, zelf implementeren volgens noden probleem o Een patroon voor software architectuur beschrijft een specifiek terugkomend ontwikkelingsprobleem dat voorkomt in een specifieke ontwerpcontext en stelt een goed bewezen schema als oplossing voor. Context: situatie die een probleem stelt Problem: probleem dat zich herhaardelijk stelt in die context Solution: oplossing voor het probleem dat zijn nut reeds bewezen heeft o 3 types: architectural pattern: structureel organisatieschema voor software systemen vb. Model-View-Controller, Layer design patterns idioms: Hoe schrijf je de code? Implementatie.
o Voordelen: Gemakkelijk wijzigbaar, herbruikbaar Natuurlijke opsplitsing Gemakkelijker bij meerdere ontwikkelaars -
23. -
-
Raamwerk: o Verzameling van samenwerkende klassen die herbruikbaar zijn voor een specifieke klasse van software: voor een familie van problemen binnen eenzelfde specifiek domein Gebruikt door overerving of compositie Kunnen gebasseerd zijn op verschillende patterns klaar voor direct gebruik Bespreek kort de layer en broker patronen. Layer: o Structureren van toepassingen die onderverdeeld kunnen worden in groepen van deeltaken, waarin elke groep zich op een specifiek niveau van abstractie bevindt. o Context: een groot systeem dat decompositie (ontleding) vereist o Problemen: systeem ontwerpen met laag en hoog niveau aspect… Overdraagbaarheid naar ander platvormen… forces: late wijzigingen enkel binnen 1 component component verwisselen met alternatieve implementatie zonder de rest te beïnvloeden lage niveaus herbruikbaar later logische opbouw o Oplossing: opdelen in aantal lagen, begin met onderste laag en werk naar boven tot hoogste niveau o Dynamics: client vraag aan laag N, kan niet antwoorden, geeft deel door aan N-1, ... Broker : o Gedistribueerde systemen: computers met meerdere cpu’s, lan’s o Structureren van gedistribueerde softwaresystemen met ontkoppelde componenten die interageren via remote service oproepen. Een brokercomponent is verantwoordelijk voor coördineren van communicatie en voor doorgeven van resultaten en uitzonderingen. (vb stadsinformatiesysteem) o Context: De omgeving is een gedistribueerd en mogelijk heterogeen systeem met onafhankelijke samenwerkende componenten o Probleem: Bouwen complex software systeem dmv aantal ontkoppelde, samenwerkende componenten, resulterend in grotere flexibiliteit en onderhoudbaarheid, systeem mogelijks distribueerbaar en schaalbaar. Interproces-communicatie nodig
24. -
-
Bespreek kort the Model-View-Controller en het Observer patroon. Model-View-Controller: o Splitst interactieve toepassingen in 3 componenten: Model : kern data en functionaliteit View : toont info aan gebruiker Controller: handelt user-inputs af o Consistentie tussen model en UI garanderen o Context: interactieve applicaties met flexibele Human-Computer-Interface o Problemen: UI vaak gewijzigd Informatie op ongelijke manieren tonen Duur en veel fouten als UI nauw verweven is met functionele kern. Observer: o Definieert een 1-veel afhankelijkheid tussen objecten, zodat als 1 object wijzigt, alle afhankelijk objecten gewaarschuwd en ge-update worden. o Probleem: data op 1 plaats wijzigt en andere componenten zijn daar van afhankelijk. o forces: 1 of meer componenten op hoogte brengen als 1 component wijzigt. aantal en identiteit van afhankelijkheden niet op voorhand gekend. geen hechte koppeling tussen Publisher en afhankelijkheden o Oplossing: 1 publisher/subject, afhankelijke componenten= subscriber/observer Publisher houdt lijst van geregistreerde subscribers bij subscribers registreren en de-registreren bij Publisher Wijziging Publisher=> stuurt notificatie naar subscriber; subscribers halen zelf gewijzigde data op
25. -
-
Bespreek kort de facade en decorator patronen. Facade: o 1 interface naar verzameling componenten/functies o Complex systeem makkelijker maken voor gebruiker o nadeel: alles ligt vast => vrijheid kwijt, je kan niet meer aan alles, enkel aan wat de facada biedt. Decorator: o Toevoegen van functionaliteit aan 1 object ipv aan klasse van objecten, onmogelijk via overerving o Decorator of wrapper: (vb Integer, Character, Streams) is object met identische interface als object dat het bevat elke oproep wordt naar dat object doorgegeven, eventueel met extra functionaliteit
