Praktische Opdracht Datebase



Dovnload 35.91 Kb.
Datum27.09.2016
Grootte35.91 Kb.
Praktische Opdracht Datebase

Inleiding

In deze afsluitende projectopdracht heb je de kennis en vaardigheden die je de afgelopen anderhalf jaar bij het vak informatica hebt verworven nodig. Denk hierbij aan:



  • Samenwerken

  • Plannen

  • Verzamelen van informatie

  • Bedenken van oplossingen

  • Vastleggen van het werkproces, door middel van het bijhouden van logboeken

  • Informatiemodellering

  • Ontwerpen van een database

  • Maken van queries in SQL

  • Ontwerpen van interfaces

  • Maken van programmastructuurdiagrammen

  • Programmeren in Visual Basic

  • Maken van HTML pagina’s met PHP

Jullie opdracht:



  • Maak producten die voldoen aan alle wensen van de opdrachtgever en je werkgever. Zie de casusbeschrijving.

  • Documenteer het gehele proces van ontwikkeling van de software.

Algemeen


  • Bij een groep van 3,4 of 5 personen bedraagt de studielast zo’n 30 a 40 uren per persoon.

  • Het project is gepland over meerdere weken.

  • Het systeem wordt ontwikkeld in Access, Visual Basic en HTML/PHP.

Werkverdeling:

Dit project voeren jullie uit in groepjes van 3 ,4 of 5 personen. Stel een projectleider aan die de voortgang van het project aanstuurt. Deze projectleider is ook de contactpersoon naar jullie docent en naar de opdrachtgever. De rol van opdrachtgever wordt gespeeld door je docent.


In te leveren producten:


Product

Projectweek

Lijst met naam van de groep en deelnemers
Plan van aanpak

1

Software requirements document + opzet uitwerking

2

Technisch ontwerp van of webdesign of stand alone programma

3

HTML

4

Alle eindproducten zoals
Database.

Een stand alone programma.

Toelichting van de code in het programma.

Handleiding.

Uitgevoerde test.

Logboek.


laatste

Zoals altijd levert te laat ingeleverd werk korting op je cijfer op!


Logboeken

Een belangrijk deel van jullie opdracht is dat het gehele ontwikkelproces goed wordt gedocumenteerd. Daarvoor gebruiken we een groepslogboek en individuele logboeken die jullie tijdens je werkzaamheden bijhouden. De individuele logboeken worden aan het eind van het project aan het groepslogboek toegevoegd. In het groepslogboek staan in ieder geval de volgende zaken:



  1. Cursusjaar

  2. Naam van de klas

  3. Namen van alle deelnemers.

  4. Naam van de schrijver van het groepslogboek.

  5. Naam van de casus

  6. Groepsprocesevaluatie

  1. Omschrijving van de tegengekomen problemen

  2. Omschrijving van de gevonden oplossingen.

Ter afsluiting van dit project houden jullie een presentatie (in de klas en met beamer). Je laat dan de werking van jullie software zien.en geeft een beschrijving van het ontwikkelproces.



Stappenplan:1

Vooronderzoek

  1. Lees de gehele opdracht van dit project door.

  2. Bespreek met de leden van jullie groep de gehele opdracht. Bekijk vooral ook de lijst van in te leveren producten.

  3. Maak een voorlopige werkverdeling.



Definitiestudie

  1. Bestudeer de casusbeschrijving. Zie casusbeschrijving.

  2. Maak een software requirements document. Dit is een lijst van de doelstellingen van de te ontwikkelen software. Dit wordt gemaakt in overleg met de opdrachtgever van het project. In dit project speelt je docent de rol van directeur of directrice van het relatiebemiddelingsbureau. Let op! Het software requirements document vormt het contract van jullie opdracht en MOET door zowel het softwarebedrijf als het relatiebemiddelingsbureau worden ondertekend voor dat het ontwikkelproces verder kan gaan. Dit document is ook de basis van de acceptatietest die uiteindelijk bepaalt of de software goed is. Wijzigingen in het software requirements document tijdens de ontwikkeling van de software kunnen alleen goedvinden na overleg met en schriftelijke goedkeuring door de opdrachtgever. Uitleg over een SRD (software requirements document, en een voorbeeld vindt je aan het eind van deze opdracht.



Technisch ontwerp

In deze fase wordt vastgelegd wat er in de volgende fase precies door de programmeurs moet worden gebouwd. Maak de volgende producten:

  1. Ontwerp van de database.
    Maak eerst een Entiteiten Structuur Diagram. Bepaal vervolgens welke tabellen jullie nodig hebben. Bepaal welke velden de tabellen bevatten. Bepaal de sleutelvelden. Bepaal de verbinding(en) tussen de tabellen. Maak een strokendiagram.

  2. Ontwerp van de schermen van de interfaces. Ten minste één van de schermen wordt gebruikt om de database met de gegevens van de klanten te muteren. Je maakt of een stand alone programma of een webdesign.

  3. Maak in elk geval een website waar je of het standaloneprogramma kunt downloaden of via webdesign rechtstreeks zaken kunt aanpassen.

  4. Voer een test uit om na te gaan of een en ander werkt.

  5. Maak een keuze voor de representatie. D.w.z. de uiterlijke kenmerken van het systeem, zoals lay-out, lettertype, eventueel gebruik van geluid en afbeeldingen, enz. Kortom alles wat voor de gebruiker zichtbaar wordt.

  6. Ontwerp van de queries.
    Er moeten bij het systeem een aantal queries geleverd worden, zodat er met behulp van deze “basis”-queries snel goede zoekopdrachten gemaakt kunnen worden. Bepaal wat de resultaten van de queries moeten zijn. Vermeld ook welke tabellen je bij de verschillende queries gebruikt en hoe je wilt gaan selecteren.

  7. Ontwerp van een gebruikershandleiding. Welke onderwerpen moeten er in staan?


Programmeren en toekennen van taken.

In deze fase worden de ontwerpen uit de vorige fase geïmplementeerd.



  1. Maak opnieuw een taakverdeling. Leg schriftelijk vast wie wat doet en vooral ook wanneer de onderdelen klaar moeten zijn.

  2. Implementeer de verschillende onderdelen en test ze.



Testen

  1. Black box test

Alle deelprogramma’s worden nu in samenhang getest. Om dit goed te kunnen doen zul je een testdatabase moeten aanmaken. Deze bevat de gegevens van tenminste 50 fictieve klanten. Maak een testrapport waarin duidelijk wordt beschreven wat er getest is en wat er wel en wat er (nog) niet goed werkt.


  1. Handleidingtest

Laat jullie handleiding testen door iemand die onbekend is met jullie software. Maak een testrapport waarin staat wat er nog verbeterd moet worden aan de gebruikershandleiding.


  1. Acceptatietest

Nadat jullie het programma zo hebben aangepast dat de software goed werkt, stel je het geheel ter beschikking van de klant, die een zogenaamde acceptatietest uitvoert.


  1. Verbeteringen

Nadat alle testen zijn afgerond moeten de noodzakelijke verbeteringen worden aangebracht. Tenslotte moeten de black box test en de acceptatietest nogmaals worden gedaan. Deze tweede acceptatietest neem 3 werkdagen in beslag. Pas als alles goed is bevonden kun je verder met de volgende fase.
Conversie (en invoering)

Het programma wordt klaar gemaakt voor aflevering aan de klant.



  1. Eventuele programmacode moet worden omgezet in een executable bestand.

  2. Alle benodigde bestanden moet op schijf worden verzameld.

  3. Zo mogelijk moet er een set-up bestand gemaakt worden.

  4. Tenslotte moet er een papieren of digitale handleiding worden toegevoegd.



Toelichting

Bronmateriaal:

Edu Aktief Informatica, deel 2, hoofdstukken 10 t/m 15

Instruct Visual Basic


Mogelijke tools:

Een tekstverwerker ( b.v. Microsoft Word 2007 of ouder)

Microsoft Access 2003 of 2007 of MySQL.

Microsoft Visual Basic.Net of 2003 of 2008 express

HTML editor (b.v. Internet Evolutions)http://www.internetevolutions.nl/

Software Requirements Document
Een document waarin de afspraken omtrent het functioneren van het te ontwikkelen systeem in overleg met de opdrachtgever/klant wordt vastgelegd. Deze eisen vallen uiteen in twee groepen:
Functionele eisen (deze omschrijven het pakket):


  • Beschrijf de minimumeisen waaraan het ontwikkelde pakket moet voldoen

  • De functionele eisen moeten zo duidelijk zijn dat ze slechts op één manier uit te leggen zijn. Zo kan er later ook geen misverstand zijn met de opdrachtgever over wat de software nu precies moet kunnen.

  • Elke uitbreiding van het eisenpakket door de opdrachtgever leidt tot meerwerk en zal dus moeten worden betaald. Stel dit duidelijk.


Niet-functionele eisen (deze omschrijven de omgeving waarin het pakket gaat functioneren):

  • Beschrijf de eisen waaraan het systeem waarop het pakket gaat draaien moet voldoen. Leg op zijn minst vast op welk besturingssysteem de software draait, welke andere software aanwezig moet zijn.

  • Bepaal of er ook papieren handleidingen gemaakt moeten worden.

  • Beschrijf de minimumeisen aan de kwaliteit van de gebruiker(s).

  • Geef een omschrijving van de minimumcapaciteit van het product. Beschrijf hoeveel records de database moet kunnen bevatten. Beschrijf eventueel hoe snel de software moet zijn.

  • Leg eventueel eisen wat betreft de interfaces vast.

  • Deze eisen worden vaak in overleg met de opdrachtgever/klant vast gesteld.

  • Niet-functionele eisen volgen vaak niet meteen uit de omschrijving van de opdracht. Je moet wellicht nadere uitleg vragen van de opdrachtgever.

Het totale Software Requirements Document dient als basis voor het maken van de contractafspraken en dient ook als basis voor het uitvoeren van de acceptatietest bij oplevering van het product. Het is een bindend document voor beide partijen.


Voorbeeld “Hardware” Requirements Document voor het product waakhond:
Functionele eisen:

  • Het product maakt middels afgesproken geluid duidelijk dat er sprake is van betreden van het te bewaken terrein door onbekenden.

  • Het product onderneemt pogingen om onbekenden te stoppen in hun bewegingen of te verjagen van het terrein.

  • Het product is binnen redelijke grenzen in staat om onderscheid te maken tussen bekend en onbekend en kiest in twijfelgevallen voor onbekend.

  • Het product blijft te allen tijde niet levensbedreigend voor ieder bezoek.


Niet functionele eisen:

  • Het product dient afdoende te worden voorzien van voedingsstoffen.

  • Het product dient voldoende te worden onderhouden op het terrein van lichaamsbeweging.

  • Het product dient afdoende en regelmatig in contact te worden gebracht met personen die de kwalificatie bekend dienen te krijgen.

  • Het product dient voldoende te worden onderhouden op het gebied van training, gehoorzaamheid en reactiepatronen.

  • Het product heeft op de momenten dat het in bedrijf is ongelimiteerde toegang tot het te bewaken terrein.

  • Het product is niet af te leiden van de taak door middel van snoep, seks of drugs.

Je ziet dat je je met de niet-functionele eisen voor een deel indekt tegen het mogelijk onvoldoende functioneren van je systeem, veroorzaakt door onvolkomenheden in de omgeving waarin je product moet functioneren. Voor een deel beschrijven deze niet functionele eisen verantwoordelijkheden van de opdrachtgever/klant!


Casusbeschrijving
Casus: Postduivenstamboom
Jullie groepje werkt bij een softwarebedrijf dat van de Nederlandse Postduiven Organisatie (NPO) de opdracht heeft gekregen de stambomen van postduiven te standaardiseren. Een voorbeeld van zo’n stamboom is als afbeelding toegevoegd aan dit document.
Omdat het op dit moment een chaos is als het gaat om de hoeveelheid en variatie in stambomen van postduiven heeft de overkoepelende organisatie, NPO, besloten een standaardprogramma te laten ontwikkelen waar alle duivenliefhebbers, ook wel duivenmelkers genoemd, mee uit de voeten kunnen.

In een verkennend gesprek tussen een contactpersoon van jullie softwarebedrijf en NPO is de volgende informatie gekomen:


Iedere duivenmelker heeft een aantal duiven in zijn of haar hok. Al deze duiven hebben een zogeheten vaste voetring met daarop:

  • Landcode (NL, B, DV)

  • het jaartal

  • nummer.

Hierdoor is ieder duif individueel te herkennen. Een voorbeeld is NL09-1080233.
Uiteraard geven de eigenaren hun dierbare duiven ook een naam. Daarnaast kan de herkenning kan ook geschieden door de “kleur” van de duif, mogelijke “kleuren” zijn:

  • blauwband

  • blauwband witpen

  • blauwbont

  • vetblauw

  • kras

  • kras witpen

  • krasbont

  • lichtkras

  • donkerkras

  • zwart

  • roodkras

  • vaal

  • schalie

Daarnaast is het noodzakelijk dat er wordt vermeld wie de duif gekweekt heeft en tot welk ras deze behoort.

Uiteraard hebben deze duiven ouders, grootouders enzovoort die ook allen een naam, ringnummer, en een kleur hebben.


Jullie softwarebedrijf wil in de toekomst vaker dit soort programma’s gaan ontwikkelen en jullie moeten het hele proces van ontwikkelen van de software goed documenteren zodat er naderhand een soort draaiboek gemaakt kan worden dat in de toekomst voor soortgelijke projecten gebruikt kan worden.



ringnummer




naam duif


kweker
kleur
evt. tekst

Let op!
Maak een technisch ontwerp.

Maak of een stand alone programma of een webdesign.

Maak een database.

Maak een handleiding voor “Postduivenstamboom”.

Houd een logboek bij.
Beoordelingsmodel Eindpo

De beoordeling vindt plaats volgens onderstaande tabel. In principe is het eindcijfer voor alle groepsleden het zelfde. Indien de docent daartoe aanleiding ziet kan hiervan worden afgeweken.





  • Logboek 5

  • Software requirements document 5

  • Of PSD of Strokendiagram 5

  • Database 10

  • Ontwerp van de queries 10

  • Ontwerp van de interfaces 5

  • Black box testrapport 5

  • Handleiding 10

  • Toelichting in code 15

  • Visual Basic I.C.M. de database 15

  • (Of PHP ODBC i.c.m. de database MSACCESS)

  • HTML/PHP gedeelte werkt naar behoren 15

Totaal aantal punten: 100


Groepseindcijfer: aantal punten/10

Namen Individuele eindcijfers



1 Raadpleeg bij twijfel je docent. Voor technieken: www.evertkok.nl/informatica.




De database wordt beschermd door het auteursrecht ©opleid.info 2017
stuur bericht

    Hoofdpagina