Samenvatting - compleet - 1-10 PDF

Preview

Summary

1-10...

Description

Theorie Eisenanalyse

Inhoudsopgave 1.

Inleiding ............................................................................................................................... 3 1.1.

Waarom failen projecten?....................................................................................................... 3

1.2.

De informatici .......................................................................................................................... 3

2.

Webapplicatie ’s ................................................................................................................... 4

3.

Eisenanalyse ......................................................................................................................... 5 3.1.

Niet-functionele eisen ............................................................................................................. 5

3.1.1.

SLA ................................................................................................................................... 5

3.2.

Functionele eisen .................................................................................................................... 6

3.3.

Het usecasemodel ................................................................................................................... 6

3.3.1.

Systeemgrens .................................................................................................................. 6

3.3.2.

Actor ................................................................................................................................ 6

3.3.3.

Overerving ....................................................................................................................... 7

3.3.4.

Use-case........................................................................................................................... 7

3.3.5.

Use-caserelaties............................................................................................................... 7

3.3.6.

Usecasebeschrijving ........................................................................................................ 8

3.3.7.

Veelgemaakte fouten ...................................................................................................... 8

3.4.

Inleiding ................................................................................................................................... 9

3.5.

Verschillende niveaus .............................................................................................................. 9

3.6.

Procesmodel ............................................................................................................................ 9

3.7.

Include-relaties ...................................................................................................................... 10

3.8.

Extend-relaties....................................................................................................................... 10

4.

Gesprek opdrachtgever (onbelangrijk) ................................................................................. 11

5.

Prototyping......................................................................................................................... 11 5.1.

Definities................................................................................................................................ 11

5.2.

Doel ....................................................................................................................................... 11

5.3.

Voordelen .............................................................................................................................. 11

5.4.

Soorten .................................................................................................................................. 11

5.4.1.

Low-Fidelity (LO-FI)........................................................................................................ 11

5.4.2.

High Fidelity(HI-FI)......................................................................................................... 11

5.4.3.

Vergelijking .................................................................................................................... 11

5.5.

Stappen.................................................................................................................................. 12

5.6.

Besluit .................................................................................................................................... 12

5.7.

WRM (Weighted Ranking Methode) ..................................................................................... 12

Theorie Eisenanalyse

1

6.

MoSCoW ............................................................................................................................ 13

7.

Synthesemethode (zie de synthesemethode.pdf ) ................................................................ 13 7.1.

Entiteit ................................................................................................................................... 13

7.2.

Attribuut ................................................................................................................................ 14

7.2.1.

Foreign keys + eigenschappen....................................................................................... 14

8.

Special topics NOG AANVULLEN .......................................................................................... 14

9.

Supertype en subtype ......................................................................................................... 15 9.1.

3 modelleringsmogelijkheden ............................................................................................... 15

9.1.1.

Modelleren op supertype .............................................................................................. 15

9.1.2.

Modelleren op subtype ................................................................................................. 15

9.1.3.

Gecombineerd ............................................................................................................... 15

9.2.

Waarom supertype, subtype of gecombineerd? .................................................................. 16

9.3.

Voorwaarden, gevolgen, voor-en nadelen............................................................................ 16

9.4.

Criteria voor keuze modellering ............................................................................................ 16

10. Eisenanalyse en datamodellering in perspectief ................................................................... 17 10.1.

Analyse .............................................................................................................................. 17

10.2.

Ontwerp............................................................................................................................. 17

10.3.

Bouw.................................................................................................................................. 18

Theorie Eisenanalyse

2

1. Inleiding 1.1.

Waarom failen projecten?

Reden: -

Niet genoeg tijd Te weinig budget Slechte communicatie Slechte onderlinge samenwerking Nooit de vooruitgang nakijken Onvoldoende testen Testen in de productieomgeving Niet voldoen aan de standaarden

Dit kan veroorzaakt worden doordat: 1. Verkeerde interpretatie van de opdracht :  Slecht specifiëren wat er gebouwd moet worden: niet duidelijk, onvolledig, tegenstellig,… 2. Zaken moeten aangepast worden 3. Veel tijd- en geld gaat verloren aan iets dat vervangen wordt 4. Soms: herwerken niet doenbaar  project faalt Conclusie: projecten failen omdat er op voorhand niet genoeg gecommuniceerd en geanalyseerd is.

1.2.

De informatici

Informaticus = Een breeds kluwen van profielen die de diagnose (helpen) maken van de informatieen communcatiestroom van de bedrijven en organisaties en deze conditie houden en/of trachten te genezen. (vergelijkbaar met de term ‘medicus’ = specialist, chirurg, tandarts, apotheker, … ) Er wordt een onderscheid gemaakt tussen fundamenteel, infrastructuur en onderhoud. Tekort aan informatici: oplossingen -

Activiteiten uitbesteden naar Oost-Europa en Zuidoost Azië  Oplossing voor schaarste probleem MAAR vaak onvoldoende contact met klanten Buitenlanders aanwerven om hier aan de slag te gaan  Economisch, cultureel en administratief moeilijk Jongeren stimuleren om I(C)T te studeren  Jongeren beter informeren, sensibiliseren, …

Theorie Eisenanalyse

3

2. Webapplicatie ’s Website =/= Webapplicatie Website

Webapplicatie Verschillende doelen Aanzetten tot surfen, zoeken, ontdekken Taak gerelateerde, gebruiksvriendelijke Aantrekken van bezoekers invoerformulieren Bezoekers interesseren Snel en gemakkelijk Weinig tekst Gebruiker-en taakanalyse Inhoud, topics, home- en mainpages, navigatie, Hoofdtaken, welke taken zijn nodig om gerelateerde onderwerpen,… hoofdtaak te ondersteunen, welke taken worden vaak gebruikt, hoe deze organiseren, hoe gebruiker ondersteunen, … Layout Bezochte link: andere kleur Bezochte link: zelfde kleur Paginatitels: uniek op elke pagina Paginatitels: op elke pagina hetzelfde hyperlink: goed gebruik hyperlink: vergemakkelijken navigatie tussen formulieren Browsers: alle browsers Browsers: zelf te kiezen … … De homepage Inleiding van het onderwerp, nieuwe verhalen, Hoofdmenu, geen specifiek doel, systeem promotie van nieuwe producten/diensten, … statistieken, live data, …  Overbodig Help FAQ, site map, hoe gebruiken, … Traditionele online help, informatie over de applicatie, systeemboodschappen, …

Theorie Eisenanalyse

4

3. Eisenanalyse Eisen omvatten de mogelijkheden van het systeem (functies of kenmerken), evenals voorwaarden of beperkingen op hoe deze mogelijkheden kunnen toegepast worden. Het “externe gedrag” van het systeem.

3.1.

Niet-functionele eisen

= randvoorwaarden waarbinnen de functionaliteiten moeten worden aangeboden, omstandigheden/beperkingen onder dewelke de functionele eisen moeten geïmplementeerd moeten worden (operationeel moeten zijn). Enkele niet-functionele eisen: -

-

-

-

-

Schaalbaarheid  Hoeveel keer het systeem of de functionaliteit tegelijkertijd kan worden gebruikt Beveiliging  Maatregelen: preventief, detectief, repressief en correctief.  Gericht op het garanderen van de beschikbaarheid, exclusiviteit/confidentialiteit en integriteit van de informatie. Kritikaliteit  Meet het effect van het uitvallen van een use-case  Hoelang kan het bedrijf werken zonder de functionaliteit? Beschikbaarheid  Hersteltijd vanaf crash (MTTR: Mean Time To Repair)  Hoelang susteem gebruiken tot het crasht (MTBF: Mean Time Between Failures) Uitvoeringsfrequentie en responsetijd  Des te meer een functionaliteit wordt gebruikt, des te efficiënter dient het te werken Bruikbaarheid  Menselijke factor; ook ondersteuning anders validen; snel toetsen/grotere font/muis/…  Welke Help ondersteuning? (F1?Online boeken?..)  Documentatie: tutorial? Users manual? Anderen: implementatie, interfaces, packaging, legal, gebruikersondersteuning,…

3.1.1. SLA = Service Level Agreement. Dienstenniveau overeenkomst (DNO) is een type overeenkomst waarin afspraken staan tussen aanbieder en afnemer van een dienst of product. Er wordt afgesproken wat de prestatie-indicatoren en kwaliteitseisen zijn van de te leveren dienst of product, om deze later te kunnen toetsen. In een SLA worden de rechten en plichten van beide partijen omschreven. Inhoud: De functionaliteit van de diensten (aangeboden functies, openstellingstijden, opleidingen, ..), de prestatie-eisen die aan de dienst gesteld worden (de niet-functionele eisen, zie hierboven) en de restricties die gelden(maximaal aantal gebruikers, transacties, …).

Theorie Eisenanalyse

5

3.2.

Functionele eisen

= Wat wil de gebruiker dat het systeem kan? Te weten komen wat de gebruiker wil: d.m.v. interviews, do’s and don’ts, tegenvoorstellen doen/verbeteringen,… Functionele eisen bepalen: -

Analyseer de bedrijfsprocessen/identificeer welke functies elke type gebruiker moet uitvoeren Bedenk een “Job description” voor elke gebruiker Een algemene functie (bv “beheer leden”) kan in meer detail worden uitgesplitst (bv. leden inschrijven, lidkaarten versturen, lidgeld betalen, …).

3.3.

Het usecasemodel

= een hulpmiddel om eisen te vatten. Bevat de functionele eisen, de details hiervan staan in de usecasebschrijving. Het is een beschrijving van hoe de gebruikers het systeem (willen) gebruiken. De focus ligt op wathet systeem kan doen, niet hoe. 3.3.1. Systeemgrens = Het afgrenzen van het systeem. Systeem = rechthoek met systeemnaam Bv. VOORRAADBEHEER

3.3.2. Actor = een entiteit die buiten het systeem staat en dit systeem gebruikt, er een interactie mee heeft of hiermee communiceert. Deze kan actief (initieert een functionaliteit) of passief (neemt deel, nadat een ander heeft geïnitialiseerd) zijn. Bv.

Theorie Eisenanalyse

6

3.3.3. Overerving = Wanneer verschillende actors (gedeeltelijk) dezelfde taken hebben maken we gebruik van overerving. Bv

.

3.3.4. Use-case = Een zinvolle actie tussen één of meer actoren en het systeem. Een geval/situatie waarvoor de gebruiker het systeem wil gebruiken of de ondersteuning van een doelstalling van het systeem/waarvoor één of meerdere actoren het system willen gebruiken. Een usecase kan primair (ondersteund de hoofdfunctionaliteit, kan op zichzelf staan, is compleet en levert een eindwaarde)of secundair (ondersteunt een functionaliteit die nodig is om hoofdfunctionaliteit mogelijk te maken bv inloggen/uitloggen, gebruikers beheren, …) zijn. De primaire usecase staan altijd boven de secundaire usecases. Bv.

3.3.5. Use-caserelaties = Duidt op communicatie in twee richtingen. Lijn tussen usecases en actoren, meestal zonder pijl. Indien mét pijl: wie de interactie initieert. Bv.

Theorie Eisenanalyse

7

Actieve relatie

passieve relatie

3.3.6. Usecasebeschrijving Naam: naam zoals in het usecasediagram Samenvatting: korte omschrijving van het doel Actoren: Opsomming van betrokken actoren bij de usecase (zie usecasediagram) Pre condities: voorwaarde die vervuld moeten zijn vooraleer de usecase kan starten Scenario: Primair pad = successcenario, Alternatief pad = uitzonderingsscenario Postconditie: Het eindresultaat Bv. Naam: Nieuwsbrief uitschrijven Samenvatting: Uitschrijven om geen nieuwsbrief e-mails meer te ontvangen. Actoren: deelnemer Pre condities: De actor heeft aangegeven dat hij zich wil uitschrijven voor de nieuwsbrief Scenario: Actor

Systeem 1.Opent pagina in web browser en vraagt om uitschrijven te bevestigen

2. bevestigt

Altern. Uitz.

(a) 3. Toont bericht dat A. geen nieuwe nieuwsbrieven meer zal ontvangen en het betreffende e)mail adres geschrapt

4. Klikt ‘OK’ 5. Naar beginpagina van de site

Altern. Uitz. (a)

Verklaring a. annuleert

Actie S. naar stap 5.

Postconditie: De deelnemer krijgt geen nieuwe nieuwsbrieven meer aan. 3.3.7. Veelgemaakte fouten Geen volle pijl:

-

GOED: FOUT: Actor: GEEN GEZICHT OF ANDERE DETAILS Voorkom spinnenwebben

Theorie Eisenanalyse

8

-

Gebruik overerving Symbool overerving: LEGE driehoek richtend naar de actor waarvan wordt overgeërfd Extend en include: pijlen zijn anders! Bij extend van tweede naar eerste, bij include van eerste naar tweede Extend-en includerelaties hebben een stippellijn-pijl, geen volledige lijn.

3.4. -

-

-

Inleiding

Actergrond  Waarom wil men dit systeem? Hoe verloopt het proces op dit moment?  Wat loopt er nu mis? Doelstelling project  Wat zal men opleveren met welk doel?  Wat zal het opleveren voor de organisatie? Primaire doelgroep  Wie zal er baat hebben bij dit systeem?

3.5.

Verschillende niveaus

Cockburn: persoon die verschillende usecase niveaus bedacht heeft. 1. Cloud /white 2. Kite Toonthoe de sea level usecases gebruikt worden in het hele systeem. Meestal zijn deze business-gerelateerd, en sea level zijn meestal systeem gerelateerd. 3. Sea level (=meeste usecases) /blue De belangrijkste usecases zijn gedefinieerd op sea level. Typisch laten deze een interactie zien tussen een primaire actor en het systeem. Deze usecases geven algemeen gezien een waarde aan het programma. 4. Fish De usecases die enkel en alleen bestaan om de sea level usecases te ondersteunen. De overgang van sea level  fish = prototype 5. Clam/black Bv. Cloud Kite Sea Fish Clam

3.6.

Koop auto-onderdelen Koop auto-onderdelen voor maken van een Volvo Bestel Volvo-onderdelen bij een leverancier Kies een leverancier voor onderdelen Encrypteren van data voor een veilig transactie

OVERZICHT

DETAILS

Procesmodel

= Een overzicht van alle processen. In dit overzicht moeten alle usecases komen, gestructureerd en met titels, maak hiervoor gebruik van de nodige niveaus (zie hierboven). Bv.

Theorie Eisenanalyse

9

3.7.

Include-relaties

= Verbinding tussen use-case en sub-use-case. Zonder de tweede use-case kan de eerste use-case niet plaatsvinden. De eerste kan enkel plaatsvinden als de tweede succesvol is beëindigd. Bv.

3.8.

Extend-relaties

= Wordt optioneel uitgevoerd (soms wel, soms niet). De eerste use-case dient een uitbreidingspunt te hebben. De gebruikte use-case valideert de conditie. Bv.

Theorie Eisenanalyse

10

4. Gesprek opdrachtgever (onbelangrijk) Doel: start van de analyse-en het ontwerp van je project. Inhoud: Achtergrond van het project, Type gebruikers, welke functionaliteiten voor welke gebruiker en de niet-functionele eisen. Tips: Gsm uit, goede inleiding, actief luisteren, notities nemen, niet teveel geslote vragen stellen, geen informatieve termen gebruiken, theorie ijsberg, …

5. Prototyping 5.1.

Definities

Prototyping is het proces om prototypes te maken. Prototypes zijn experimentele en onvolledige ontwerpen die snel ontwikkeld kunnen worden en niet duur zijn.

5.2. -

Visies en ideeën visualiseren om goede feedback van de gebruiker te krijgen in een vroege fase. Nieuwe mogelijkheden en oplossingen beschouwen in een gemeenschappelijke taal

5.3. -

Doel

Voordelen<...