Summary Software engineering

-
ISBN-10 0137053460 ISBN-13 9780137053469
398 Flashcards & Notes
11 Students
  • These summaries

  • +380.000 other summaries

  • A unique study tool

  • A rehearsal system for this summary

  • Studycoaching with videos

Remember faster, study better. Scientifically proven.

Summary 1:

  • Software engineering
  • Ian Sommerville
  • 9780137053469 or 0137053460
  • 9th ed., International ed.

Summary - Software engineering

  • 3.3 Extreme programming

  • De naam Extreme programming is uitgevonden door Beck omdat de gebruikte benadering bij ontwikkeling, erkende goede praktijken zoals iteratieve ontwikkeling tot in extreme mate worden toegepast.
  • In Extreme programing worden de vereisten uitgedrukt in scenario's, user stories genaamd, die meteen ge¨implementeerd worden in taken. Programmeurs werken in paren en schrijven testscenario's voordat ze beginnen met het schrijven van de code.
    Wanneer nieuwe code in het systeem wordt ge¨integreerd moeten alle testen succesvol kunnen worden uitgevoerd.
  • Goede praktijken van Extreme Programming:
    • Incrementele ontwikkeling wordt ondersteund door kleine, frequente afleveringen van het systeem
    • De klant wordt betrokken doordat hij betrokken wordt in het ontwikkelteam
    • Mensen, niet de processen worden ondersteund door pair programming, collective ownership en een onderhoudbaar ontwikkelproces.
    • Verandering wordt ondersteund door dat het systeem op regelmatige basis wordt uitgebracht aan de klant, test-first development en refactoring
    • Het onderhouden van eenvoud wordt ondersteund door constante refactoring die de kwaliteit van de code opwaardeert en door eenvoudige ontwerpen te gebruiken.
  • Spike: een increment waar er niet aan programmering wordt gedaan; goed om de architectuur van het systeem te ontwerpen of documentatie te schrijven.
  • 3.3.1 Testing in XP

  • De belangrijkste kenmerken van het testen in XP:
    • Test-first development: je schrijft de test voordat je de code schrijft. Zorgt er ook voor dat er geen "test-lag" optreedt, waarbij de ontwikkelaar sneller werkt dan de tester, zodat de neiging ontstaat om testen over te slaan, om de ontwikkelingskalender te kunnen behouden.
    • incrementaal testontwikkeling vanuit de scenario's; elke taak geneert één of meer unit tests die de implementatie testen die in de taak beschreven wordt.
    • Gebruikersparticipatie in de testontwikkeling en de validatie; net als e ontwikkeling zijn de acceptance testen incrementeel. Soms is het moeilijk hier de volledige medewerking van de klant te kunnen verwachten.
    • Het gebruik van geautomatiseerde testframeworks
  • Meestal leidt dit tot veel testen, maar dit verzekerd niet dat het programma noodzakelijk grondig getest wordt.
    Daar zijn drie redenen voor:
    • Programmeurs programmeren liever dan dat ze testen
    • soms kan het moeilijk zijn een test incrementeel op te stellen
    • Het is moeilijk om de volledigheid van een aantal tests te beoordelen.
  • 3.3.2 Pair programming

  • Dat wil zeggen dat de programmeurs in paren werken. Ze zitten aan hetzelfde workstation om de software te ontwikkelen.
    Voordelen:
    • Het ondersteunt het idee van collectief bezit en collectieve verantwoordelijkheid van het systeem.
    • Het handelt als een informal review proces omdat elke regel code door tenminste twee personen wordt bekeken.
    • Het helpt om refactoring te ondersteunen, wat de softwareontwikkeling ten goede komt.
  • 3.4 Agile project management

  • De standaard benadering van project management is plan-driven
  • Scrum
    Dit is een algemene agile methode maar de nadruk ligt op het beheren van iteratieve ontwikkeling, in plaats van op technische benaderingen van agile software development.
    In scrum zijn er drie fasen:
    • Een planning fase, waar de algemene objectieven foor het project worden opgesteld, en waar het ontwerp van de softwarearchitectuur wordt vermeld.
    • Daarna volgen een aantal spring cyclie, waar in elke cyclus een increment van het systeem wordt ontwikkeld
    • In de sluitfase wordt het project afgesloten; hier worden eventueel handleidingen geschreven, en worden de lessen die van het project geleerd werden besproken.
  • Het is de tweede fase die vernieuwend is.
    Aan het einde van een sprint wordt de gecompleteerde functionaliteit aan de stakeholders afgeleverd.
    Kenmerken:
    • Een spring heeft een vaste lengte van ongeveer twee tot vier weken
    • Het startpunt is het product backlog, die de lijst van werkzaamheden beschrijft die aan het project gedaan moeten worden.
    • In de selectiefase wordt tezamen met de klant bekeken welke kenmerken en functionele gedurende deze sprint zullen verwezenlijkt worden.
    • Vervolgens wordt het team georganiseerd om het systeem te ontwikkelen. Hierbij worden er dagelijkse korte vergaderingen gehouden. In deze fase worden de ontwikkelaars afgezonderd, en alle communicatie van de klant of anderen naar het ontwikkelteam wordt verzorgd door een zogenaame scrum-master.
    • Aan het einde van de sprint wordt het werk bekeken en aan de stakeholders gepresenteerd.
  • Voordelen van Scrum:
    • Het product wordt opgesplitst in kleine, onderhoudbare delen.
    • Onstabiele vereisten vertragen het geheel niet
    • team communicatie is verbeterd doordat iedereen zicht heeft op het hele systeem.
    • Klanten krijgen op tijd gedeelten van het systeem te zien waar ze feedback op kunnen geven.
    • Er is vertrouwen tussen de klant en de ontwikkelaars
  • 3.5 Scaling agile methods

  • Er zijn twee perspectieven voor het opschalen van agile methoden:
    • "Scaling up", deze behandelt het gebruiken van deze methoden op grote softwaresystemen te ontwikkelen, die niet door een klein ontwikkelteam kunnen ontwikkeld worden.
    • "Scaling out"; deze behandelt het introduceren van agile methoden in grote organisaties met vele jaren van softwareontwikkelervaring
  • Kritieke aanpassingen die moeten gebeuren:
    • bij het ontwikkelen van grote systemen is het niet mogelijk enkel op de code te focusen. Er dient dus meer ontworpen en gedocumenteerd te worden.
    • Er dienen Cross-team communicatie-middelen ontworpen en gebruikt te worden.
    • Het is belangrijk dat het systeem op frequente tijden gebouwd wordt en dat er frequente releases van het systeem worden uitgebracht.
  • 4 Requirements engineering

  • De vereisten van een systeem zijn de beschijving van wat een systeem zou moeten doen, de diensten die het aanbied en de constraints die opgelegd worden.
    user requirements: zijn stellingen in natuurlijke taal en diagrammen van welke diensten het systeem wordt verwacht aan te bieden, en de constraints waaraan het systeem onderworpen is.
    System requirements: zijn meer gedetailleerde beschrijvingen van de functies van het systeem en zijn operationele constraints.
Read the full summary
This summary. +380.000 other summaries. A unique study tool. A rehearsal system for this summary. Studycoaching with videos.

Summary 2:

  • Software engineering
  • Ian Sommerville
  • or
  • 2011

Summary - Software engineering

  • 1 Introduction

  • a.Wat zijn de 4 belangrijke attributen die alle profesionele softwar zou moeten hebben?

    b.Noem er nog 4 die soms ook belangrijk kunnen zijn

    a.Maintainability

    dependability

    performance

    usability

    b. reusability

    distributability

    portability (meerdere platformen)

    inter-operability (meerdere softwaresystemen)

    security

    safety

    availability

     

     

     

  • Verklaar waarom het universeel gebruik van het Web software systemen heeft veranderd.

    - Systemen kunnen op op al bestaande systemen worden opgebouwd

    - Systemen kunnen incrementeel ontwikkeld worden

    - Systemen kennen beperkingen in de gebruikersinterface ten gevolge van de beperkingen van webbrowsers

     

  • Om terrorisme te bestrijden, worden veel activiteiten van gebruikers gelogd. Dit heeft privicy issues. Geef argumenten waarom dit ethiesche problemen geeft als je werkt met de ontwikkelingen van dit systeem.

    Op een aantal punten kunnen conflicten ontstaan tot de ethische code:

    - Public: is het systeem volgens u wel in het algemeen belang? Wellicht spelen hier persoonlijke en politieke motieven een rol

    - Client en employer: idem

    - Judgement: conflicteren uw persoonlijke en professionele oordeel hier

    - Profession: schaadt dit volgens u de reputatie van het beroep niet?

    - Collegueas: wat doet u als uw collega's een hele andere opinie hebben?

  • Wat wordt in het tekstboek verstaan onder software en wat onder software engineering?

    Software is een computer programma inclusief documentatie

    Software engineering is een vak die zich bezig houdt met alle aspecten van het produceren van software

  • Waarin onderscheidt software engineering zich enerzijds van informatica en anderzijds van system engineeering?

    Software engineering is een technisch vak: het gaat als alle technische vakken over hoe iets geconstrueerd wordt. Informatica is een theoretisch vak, waarin de inzichten wel de grondslag vormen voor software engineering.

    System engineering is breder; dit vak houdt zich bezig met de constructie van verschillende systemen, waarbij een systeem een verzameling onderling afhankelijke componenten is die samenwerken om een gegeven doel te verwezenlijken. In de praktijk houdt system engineering zich vooral bezig met systemen die software bevatten als een van de componenten.

  • Wat zijn de 4 belangrijkste soorten activiteiten in ieder software proces?

    specificatie

    ontwikkeling

    validatie

    evolutie

  • Wat zijn de belangrijkste punten uit de Software Engineering Code of Ethics and Professional Practise?

    1. Public: software engineers moeten consistent met een publieke interesse werken

    2. Client en employer: belang van de client en employer werken

    3. Product: hoogste professionele standaard

    4. Judgement: integriteit en ongafhankelijk professioneel oordeel

    5. Management: ethische benadering naar het management van software ontwikkeling en onderhoud

    6. Profession: integriteit en reputatie van het beroep met een publieke interesse

    7. Collegues: eerlijk en sportief naar collega's

    8. Self: levenslang leren en een ethische benadering aanmoedigen bij het uitoefenen van hun beroep

  • 2 Software processes

  • Welk software proces model zou je gebruiken bij het maken van de onderstaande systemen;

    a. een systeem om het anti-lock braking systeem van een auto te maken

    b. Een virtual reality systeem om onderhoudt to support software maintenance

    c. Een university accounting system die een bestaand systeem vervangt

    d. Een interactief vakantieplanning systeem die gebruikers helpt om reizen te plannen met de laagste environmental impact

    a. een systeem om het anti-lock braking systeem van een auto te maken -> Dit is een safity-critical systeem, die veel analyse aan het begin vereist. Dit heeft echt een plan-driven aanpak nodig om te maken, waarbij de requirements goed geanaliseerd moeten woden. Een waterfall methode zal hierom dan ook de beste methode zijn

    b. Een virtual reality systeem om onderhoudt to support software maintenance -> Dit is een syseteem waarbij de requirements zullen veranderen en de UI zal een grote bijdrage moeten leveren. Incremental development en enige UI prototyping is de meest geschikte model. Een agile process is nodig.

    c. Een university accounting system die een bestaand systeem vervangt -> Van dit systeem zijn de requirements ook erg bekend en wordt gebruikt in een omgeving met veel andere systemne. Hierom zal een reuse-based aanpak het meest geshcikt zijn.

    d. Een interactief vakantieplanning systeem die gebruikers helpt om reizen te plannen met de laagste environmental impact -> Systemen met een complexe UI maar moeten stabiel en betrouwbaar zijn. Een incremental onwikkel aanpak is het meest geschikt omdat de system requirements zullen veranderen wanneer echte gebruikers het systeem gaan gebuiken

  • Welke van de onderstaande stadia helpen bij de verificatie van het systeem en welke bij de validatie?

    a. development testing 

    b. system testing

    c. acceptance testing

    a. development testing -> verificatie

    b. system testing -> verificatie

    c. acceptance testing -> verificatie en validatie (omdat hier nog fouten in de requirements naar voren kunnen komen)

  • Leg uit waaarom verandering onvermijdelijk is in een complex software systeem en geef voorbeelden van process activiteiten die je helpen om software veranderingen te voorspellen en om de software te ontwerpen die beter tegen veranderingen kan.

    Systemen moeten veranderen omdat ze geinstalleerd zijn in een omgeving. De omgeving past zich aan en deze aanpassing genereerd nieuwe systeem requirements. Tevens is de omgevbing dynamisch en genereerd steeds nieuwe requirements. Als het systeem zich niet aanpast aan de veranderingen zal het systeem steeds minder bruikbaar zijn.

    Voorbeelden van processen die verandering ondersteunen zijn:

    1. Reden van requirement opnemen in de requirements, dit help bij toekomstige veranderingen

    2. Afhankleijkheden tussen requirements en de design/code opnemen

    3. Disign modeling, waarbij het design model de documentaie is van de structuur van de software

    4. Code refactoring die de kwaliteit van de code beter maakt, zodat het makkelijker is aan te passen

  • Wat zijn de voordelen om statische en dynamische views van de software processen te maken in het Ratitional Unified Proces (RUP)?

    In de meeste gevallen zijn de statisch eactiviteiten interleafed, dus een sequentieel proces model beschrijft dit niet. Door dit te scheiden van het dynamische perspectief, kun je het er over hebben hoe elk van deze statische activiteiten wordt gebruikt in elke fase van het proces.

  • a. Noem 4 procesmodellen, geef een korte karakterisering en geef aan voor welk type project het model geschikt is.

    b. Leg uit waarom het incrementele model en het signaalmodel van Boehm beschouwd worden als hybride modellen of raamwerken

    1. Watervalmodel. Dit is een lineair ontwikkelingsmodel waarin een systeem stap voor stap wordt ontwikkeld. Iedere stap wordt afgesloten met een document. Dit model is alleen geschikt voor conventionele projecten waarvan het verloop goed in te schatten is.

    2. Incrementele ontwikkeling. Hierbij gaan specificatie, ontwikkeling en validatie hand in hand. Er wordt snel een 1e prototype ontwikkeld, dat vat vervolgens stap voor stap groeit. De klant levert op iedere tussenstap commentaar . Evolutionaire ontwikkeling is geschikt voor systemen waarvan vooraf niet duidelijk is aan welke eisen ze moeten voldoen, bijvoorbeeld omdat het een nieuw toepassingsgebied betreft of een toepassingsgebied waar de klant weinig ervaring mee heeft.

    3. Formele systeemontwikkeling. Gaat uit van een gedetailleerde formele specificatie, die via een reeks correctheidsbehoudende (formele) transformaties wordt omgezet in een implementatie. Formele systeemontwikkeling is geschikt voor relatief kleine systemen met strikte eisen aan veiligheid. (safety and security).

    4. Reuse-oriented ontwikkeling. Probeert een systeem op te bouwen uit beschikbare herbruikbare en/of standaardcomponenten. Deze werkwijze is vooral geschikt in situaties waar de systeemeisen licht aangepast kunnen worden aan de beschikbaarheid van bestaande componenten.

    b. Deze modellen zijn geparametriseerd en beschrijven dus een familie van procesmodellen

     

  • Wat is 'throwaway prototyping'?

    Het gaat om wegwerp-prototypes. Deze worden bewust simpel gehouden en dus snel ontwikkeld. Het wegwerpaspect is bedoeld om te voorkomen dat deze prototypes deel uit gaan maken van het systeem. Het gaat om het snel testen van een bepaalde geïsoleerde functionaliteit van het uiteindelijke systeem

  • a. Wat zijn de belangrijkste kenmerken van het spiraalmodel van Boehm?

    b. Kan elk procesmodel dat met behulp van het incrementele model beschreven kan worden, ook worden beschreven met het spiraalmodel van Boehm? En omgekeerd?

    a. Iteratieve ontwikkeling, waarbij iedere iteratie bestaat uit 4 fasen. Risicanalyse speelt een belangrijke rol

    b. Een incrementeel proces kan makkelijk worden oondergebracht in Boehm's spiraalmodel. Het voortraject wordt ondergebracht in de 1e cyclus en verder per iteratie een cyclus.

    Omgekeerd is dat niet het geval, omdat in het incrementele model activiteiten als prototypering en risicoanalyse ontbreken. Het spiraalmodel is dus algemener dan het incrementele model.

  • a. Teken het schema van Rational Unified Process (RUP)?

    b. Kunnen de iteraties in het Rational Unified Process (RUP) ook worden gemodelllerd volgens het spiraalmodel van Boehm?

    a. Inception, Elaboration, Construction, Transition (figuur 2.12)

    b. Het spiralmodel van Boehm loopt in elke iteratie door alle fasen van het proces heen, In het RUP kun je binnen een fase itereren. De iteraties binnen het RUP zijn dan ook niet zomaar te modelleren volgens het spiraalmodel van Boehm. De achterliggende reden is dat binnen het spiraalmodel van Boehm de dynamisch en statich eviews die gegeven worden voor het RUP niet zo duidelijk te scheiden zijn, en de workflows dus enigszins aan de verschillende kwadranten gekoppeld zijn.

Read the full summary
This summary. +380.000 other summaries. A unique study tool. A rehearsal system for this summary. Studycoaching with videos.

Latest added flashcards

Welke argumenten pleiten voor plan-driven ontwikkeling ten opzichte van agile ontwikkeling?
  • Er moet een gedetailleerd ontwerp zijn voordat begonnen wordt met de implementatie
  • Er moet een uitgebreide analyse worden uitgevoerd voordat begonnen wordt met de implementatie
  • Het gaat om een groot project waarbij veel medewerkers zijn betrokken
  • Het systeem moet lang meegaan, waardoor het belang van documentatie toeneemt
  • De organisatie die software ontwikkelt is gewend om plan-based te werken
  • De software moet gekwalificeerd worden door een derde
[3.2]
Welke argumenten pleiten voor agile ontwikkeling ten opzichte van plan-driven ontwikkeling?
  • Incremental delivery met snelle feedback van de gebruikers
  • Het systeem wordt ontwikkeld door een klein team waarbij de communicatie informeel kan verlopen
  • Men heeft de beschikking over tools die het gebrek aan documentatie kunnen compenseren
  • De projectmedewerkers hebben de juiste skills voor agile ontwikkeling
[3.2]
Wat zijn de risico's van een gebrekkig configuratiemanagement?
  • De verkeerde versie van een systeem wordt gewijzigd
  • De klant ontvangt een verkeerde versie van het systeem
  • Het zoekraken van de broncode van een bepaalde systeemversie of component
[25]
Noem enkele voorbeelden van softwareontwikkeling met reuse
  • Architectural patterns
  • Design patterns
  • Component-based development
  • Application frameworks
  • Legacy system wrapping
  • Service-oriented systems
  • Software product lines
  • COTS product reuse
  • ERP systems
  • Configurable vertical applications
  • Program libraries
  • Model-driven engineering
  • Program generators
  • Aspect-oriented software development
[16.1]
Noem drie factoren die het testen op beveiliging bemoeilijken
  • De eisen zijn vaak 'shall not'-eisen. Het is onmogelijk om aan te tonen dat een systeem iets niet doet.
  • Men kan niet testen op aanvallen waarvan men het bestaan niet kent
  • Aanvallers hebben veel meer tijd om zwakke plekken in het systeem te ontdekken dan testers. Daarbij kunnen zij zich baseren op de aannames die bij de ontwikkeling van het systeem zijn gedaan.
[15.3]
Safety of dependability cases worden meestal opgesteld na afloop van de ontwikkeling van een systeem. Welk risico's brengt dit met zich mee?
  • Tijdens de ontwikkeling van het systeem zijn niet de benodigde gegevens of documentatie voor de safety of dependability case verzameld
  • Tijdens de ontwikkeling van het systeem zijn  keuzes zijn gemaakt die het opstellen van de safety of dependability case bemoeilijken.
[15.5]
Wat wordt bedoeld met formele technieken?
Formele technieken zijn gebaseerd op een specificatie van het systeem in de vorm van een formeel model. Ze bestaan in hoofdzaak uit:
  • Mathematische analyse van de specificatie
  • Transformatie van de specificatie in een gedetailleerde representatie van het systeem
  • Het vergelijken van verschillende representaties van het systeem.
[15.1]
Noem enkele consequenties van de introductie van een socio-technisch systeem voor de omgeving
  • Proceswijzigingen: het systeem kan leiden tot een aanpassing van de werkprocessen
  • Taakwijzigingen: het systeem kan ertoe leiden dat de werkzaamheden van mensen wijzigingen (de-skilling)
  • Organisatiewijzigingen: het systeem kan de machtsverhoudingen binnen een organisatie veranderen
[10.1]
Noem enkele richtlijnen voor het ontwerpen van testcases voor system testing
  • Test alle functies die via menu's toegankelijk zijn
  • Test combinaties van de functies die via hetzelfde menu toegankelijk zijn
  • Test zowel met correcte gebruikersinvoer als met foutieve gebruikersinvoer
[8.1]
Geef aan in welke stappen reuse-oriented ontwikkeling verloopt
  • Requirements specification
  • Component analysis: onderzoeken welke componenten geschikt zijn
  • Requirements modification
  • System design with reuse: de ontwikkeling van een framework
  • Development and integration
[2.1]