1. No category

Synopsis Modul 5
Systemudvikling
for fodboldtræner
E-konceptudvikling
Gruppe 1: Line Breum Sørensen, Ásdís Ólafsdóttir og Mads Nyborg
Indholdsfortegnelse
Casebeskrivelse................................................................................3
Problemformulering..........................................................................3
Problemfelt.......................................................................................3
Metodebeskrivelse............................................................................3
Metoder.............................................................................................3
Scrum.................................................................................................3
Produck backlog.............................................................3
Sprint backlog................................................................4
Sprint............................................................................3
Objekt orienteret analyse og design...................................................4
Hædelsesliste......................................................................................4
Aktør-konteksdiagram.........................................................................4
Systemdefinition (BATOFF)............................................4
Aktører..........................................................................4
Hovedsystem................................................................4
Dommersystem.............................................................5
User case diagram................................................................................6
User case beskrivelse....................................................7
Sekvenksdiagram..........................................................7
Aktivitetsdiagram................................................................................8
AS-IS............................................................................8
TO-BE...........................................................................8
Klassediagram....................................................................................9
Resultat...............................................................................................9
Brugerflade design ...............................................................................9
Brugerflade diagram............................................................................9
Konklusion........................................................................................10
Litteratur liste....................................................................................10
Casebeskrivelse
En fodboldklub med en fodboldtræner har brug for et online system til administration af hans arbejdsopgaver, samt fordeling af arbejdsopgaver i forbindelse med kampe. Foruden systemet ønskes også ny fremgangsmåde til reservering af dommer og bane.
Problemformulering
Hvordan kan man udvikle et system der understøtter en fodboldtræners administrative opgaver, og gør disse mere overskuelige?
Problemfelt
Fodboldtræneren har mange ting, som han skal arbejde med foruden at
træne sine spillere. Træneren skal lave alle træningsprogrammerne i hånden
med papir og blyant, ligesom han skal reservere faciliteter, bestille dommere
til camper og lave holdopstillinger til spillerne. Træneren mangler et computersystem der kan lette på hans administrative opgaver og gøre hans daglige
opgaver nemmere.
Metodebeskrivelse
Vi har at udviklet et system, et intranet til en fodboldstræner, ved at gøre
brug af scrum, til projekt styringen og OOA&D til selve sytemudviklingen.
Metoder
Scrum
Scrum er et projektledelses redskab, der bruges primært til udvikling af
software da dette kan være en kompliceret og uforudsigelig proces: Scrum
fungere derfor snarere som en form for kontrolleret black box frem for en
teoretisk proces. Fordelen ved at bruge Scrum frem for vandfalds- og spiralmetoder, er at Scrum giver plads til forandringer i selve udviklingsprocessen.
Hvorimod vandfalds- og spiralmetoderne anser udviklingsprocessen som en
færdig beskrevet proces.
Nogle af de største problemer med vandfalds- og spiralmetoderne er:
• Man kender ikke alle krav i begyndelsen af en proces.
• Krav kan ændre sig i løbet af processen.
• Processen bliver uforudsigelig når der bruges nye værktøjer og
teknologier.
Vandfalds- og spiralmetoderne er en lineær proces. Der i de fleste tilfælde
består af følgende fire aktiviteter: Analyse, Design, Implementation og Test.
Scrum sætter derimod ikke nogen retningslinjer for hvilken rækkefølge aktiviteterne skal implementeres. Et projekt kan derfor starte med en hvilken som
helst aktivitet, og skifte til en anden aktivitet på ethvert tidspunkt. Dette øger
projektets fleksibilitet og produktivitet.
Nogle af de ting som kendertegner Scrum er:
• Fleksible tidsplaner
• Fleksible deadlines
• Små udviklingshold
• Hyppige reviews
• Objektorientering
• Samarbejde mellem udviklingshold
Scrum opdeler et projekt i tre hovedeområder: Produkt backlog, Sprint backlog og sprint.
Produkt Backlog
En produkt backlog er der hvor alle de krav til det givne systemet er samlet. Der er ingen begrænsning på hvor mange krav der må være. Kravene i
produkt backloggen udføres udfra en prioteringsliste. Jo højere prioritet, jo
bedre specificeret skal kravene være.
3
Sprint Backlog
En udvalgt del af en Produkt Backlog som projekt gruppen vælger at implementere under den kommende Sprint.
Sprint
Arbejdet inddeles i Sprints. Hver sprint, som varer normalt 4-6 uger.
Vi valgte at bruge scrum1 til hjælp af udformningen af modul opgaven. Vores
udgave er selvfølgelig en meget forenklet og simpel udgave af scrum grundet tidsrammen for projektet. Vi valgte at gøre brug af scrum for at få en
fornemmelse af den fleksibilitet og struktur den ville give.
Det vi fandt var, at selv om tidsrammen for dette projekt var meget kort, at
scrum giver et godt overblik over hvad der skal laves, hvor langt man er, hvor
lang tid selve projketet som helhed kommer til at tager.
Objekt orienteret analyse og design
Hændelsesliste
Hændelseslisten2 er lavet for at inddele systemets aktører i kategorier, hvor
alle de aktiviteter de udfører i relation til systemet er listet under hver aktør.
Denne inddeling hjælper med at fastlægge hvilke funktioner systemet skal
indeholde, samt definere hvilken rolle de forskellige aktører har.
Aktør kontekst diagram
Systemdefinition (BATOFF)
Betingelser: Systemet skal være brugervenligt og let tilgængeligt.
Dataene i systemet skal opdateres fra en database via Internettet.
Anvendelsesområdet: Et planlægningssystem, der kan bruges i hjemmet med hovedvægt på administration af spillere, kampe, træningsprogrammer og turneringer.
Teknologi: Internetforbindelse, Online Database
Objektsystem: Et intranet for en fodboldklub, som har et brugervenligt CMS system.
Funktionalitet: Skal fungere uden ekstra software. Overskuelig
brugerflade der ikke kræver oplæring for at benytte.
Filosofi: Trænerens administrative arbejde skal reduceres og automatiseres, samt skabe overblik for de andre aktører
Aktører
Aktørerne i et system er de personer der bruger systemet eller på anden
måde har indflydelse på det. Selve systemet eller andre eksterne systemer kan dog også i nogle tilfælde være en aktør, da det kommunikerer med
brugerne.
I dette tilfælde er aktørerne de folk i fodboldklubben der skal bruge systemet, samt dommeren der skal reserveres til hver kamp. Vi har derfor inddelt
aktørerne i 2 systemer, da vi mener det er bedst at have et eksternt system
til reservation af dommer, da listen over dommere er tilgængelig for andre
klubber, og derfor ikke kun skal kunne reserveres gennem vores system.
Hovedsystem:
Træner: Træneren er den primære bruger af systemet, da det er ham
der styrer det administrative arbejde for sit fodboldhold.
Hjælpetræner: Har ligesom træneren adgang til oplysninger om
spillerne, dog i et begrænset omfang, da denne eksempelvis ikke har
rettigheder til at ændre holdopstilling.
Administrator: Administrators opgave er at holde systemet opdateret
med, ligesom det kun er ham der kan tilmelde/udmelde klubbens
spillere.
1
2
Bilag 1.
Bilag 2. Scrum
Hædelsesliste
4
Fodboldspiller: Kan bruge systemet til at finde generelle oplysninger,
som opstilling, sted, tidspunkt og dato for næste kamp.
Fysioterapeut: Fysioterapeuten står for dokumentering af spillernes
skader, og behandler spillerne, samt oplyser administrator om spillernes behandlingsperiode.
Dommersystem:
Administrator: Udformer skema til dommere, videregiver oplysninger
om dommernes tilgængelighed til hovedsystemet.
Dommer: Kan gennem et skema oplyse om denne er ledig, booket
eller reserveret for den pågældende dato. Hvis dommeren er ledig
markeres dato og tidspunkt med grøn farve, og hvis en klub har sendt
sin holdopstilling inden 24 timer før kampen og booker en dommer,
er dato og tidspunkt markeret med gul farve. Vælger dommeren at
bekræfte bookingen bliver dato og tid markeret med rød.
Aktør kontekst diagrammet viser hvilken tilgang aktørerne har til systemet
i forhold til hvem der kun har rettigheder til at se systemets oplysninger og
hvem der både kan se og ændre systemets oplysninger. Dette er defineret
ved de pile der går fra aktørerne mod systemet, hvor de almindelige pile symboliserer adgang til systemet, og de stiplede pile symboliserer fuld adgang til
systemet.
Aktør 1. Admin
Aktør 3. Træner -n
Aktør 6. System
Aktør 3. Hjælpe Træner -n
BATOFF:
Betingelser: Systemet skal være brugervenligt
og let tilgængeligt. Dataene i systemet skal
opdateres fra en database via Internettet.
Anvendelsesområdet: Et planlægningssystem, der kan bruges i hjemmet med hovedvægt på administration af spillere, kampe,
træningsprogrammer og turneringer.
Teknologi: Internetforbindelse, Online Database
Objektsystem: Et intranet for en fodboldklub,
som har et brugervenligt CMS system.
Funktionalitet: Skal fungere uden ekstra software. Overskuelig brugerflade der ikke kræver
oplæring for at benytte.
Filosofi: Trænerens administrative arbejde skal
reduceres og automatiseres, samt skabe
overblik for de andre aktører
Aktør 4. Fodboldspillere
Aktør 5. Fysioterapeut -n
Aktør 1. Admin
Ind- og udmedelse af spillere.
Spiller tilføjes et hold.
Registrere når en træner foretager reservation
af faciliteter.
Sørger for turnerings plan.
Aktør 2. Træner -n
Træningsprogram
-øvelser
Holdopstilling
Spiller oplysinger
-spiller status
Reserveringer/Booking
Aktør 3. Hjælpe træner -n
Træningsprogram
-øvelser
Holdopstilling
Spiller oplysinger
-spiller status
Reserveringer/Booking
Aktør 4. Fodboldspiller -n
- spilletider
- træningstider
- optræningstidspunkter
Aktør 5. Fysioterapeut -n
- spilletider
- træningstider
- optræningstidspunkter
Aktør 6. System
- dommer liste
- mulighed for booking
5
Use case diagram
Use case diagrammet bruges til at strukturere hvilke aktører der benytter
hvilke funktioner, hvor de almindelige streger symboliserer, at aktøren både
har adgang til hændelsen, men også kan lave ændringer i den. De stiplede
linier symboliserer derimod at aktøren kun har adgang til hændelsen, men
ikke har mulighed for at foretage ændringer.
System/Intranet
Aktør 1. Admin
Indsætte ny spiller
Spiller alm.oplysninger
Aktør 2. Træner -n
Aktør 3. Fodboldspillere
Spiller status
Træningsprogram
Hold opstilling
Aktør 4. Hjælpetræner -n
Reservation og booking
spiller skema
Dommer
6
Aktør 5. Fysioterapeut -n
Use case beskrivelse
Vores use case beskrivelse tager udgangspunkt i oprettelse af ny spiller i systemet, hvor administrator og systemets handlinger indgår. Use case beskrivelsen er derfor et af systemets mange handlinger, som bliver uddybet med
hensyn til betingelser for start og slut, ligesom handlingen eller kommunikationen mellem administrator og system er beskrevet trin for trin.
Sekvens diagram
Et sekvens diagram giver et overblik over hvordan forskellige processer interagerer med hinanden. Man kan bruge et sekvensdiagram til at specificere en
kompliceret user case, så denne bliver forståelig for eventuelle programmører. Vi har brugt det til at vise hvordan user casen “Oprettelse af ny spiller”
fungerer i systemet. Det giver et indtryk af hvordan oprettelsen af en spiller
kommer til at foregå i intranettet.
7
Aktivitetsdiagram
Man akn bruge aktivitetsdiagrammet på to måder:
1: AS-IS viser hvordan det eksisterende system, ved at udforme et AS-IS aktivitetsdiagram bliver det lettere at finde de steder hvor det nye system kan
forbedre det gamle.
2: TO-BE giver et overblik over hvordan det nye system kommer til at fungere. Det kan også give et overblik over evt. svagesteder i systemet som
man måske skal koordinere på inden den endelige version bliver sendt på
gaden.
Vi har lavet et AS-IS3 aktivitetsdiagram for at få et overblik over det eksisterende system og få et overblik over de forbedrings muligheder der kan foreligge.
Aktivitetsdiagrammet(TO-BE) viser en uddybning af systemets adfærd, hvor
vi har valgt at lave det som svømmebaner, hvor hver aktør har sin egen bane,
og pilene i diagrammet viser hvordan aktørerne og funktionerne er forbundet.
Dommer
Træner
Admin
System
Facyliteter/baner
Fysioteraput
Fodboldspiller
Reserv.af dommer
Ny spiller
Login og password
Bekræftelse
Reservation.fasilitet
Reserv. af ny Bane
ikke ledig
Bane eller Facilitet
Reservation
ActionState6
ændr.spillerstatus
Holdopstiling
PDF
Turneringsplan
PDF
Træning
3
Bilag. 3. AS-IS Aktivitetsdiagram
8
Spiller
Dato og tid
Hjælpetræner
Klassediagram
Klassediagrammet inddeler systemets objekter i klasser, hvor struktur, adfærdsmønster og andre attributter er ensartede. Hver klasse er defineret ud
fra objekternes egenskaber og funktioner..
Resultat
Brugerflade design
Vores system er designet som et simpelt intranet4, hvor man kan hente oplysninger uden en masse ligegyldige muligheder som fx mulighed for dialog i
form af fx et chatsystem og der gøres derfor ikke brug af web 2.0. Designet
er derfor upersonligt og ikke så farverigt, da der lægges stor vægt på professionalitet og funktionalitet, da tilgangen til systemet skal være let, selv for de
mindre øvede computerbrugere.
Brugerflade diagram
Brugerfladediagrammet viser hvordan arbejdsgangen er i systemet med hensyn til hvordan systemet bag brugerfladen opererer.
Sitemap/Brugerflade diagram:
Opretter forbindelse til iantranet.system.dk
File/Forside
Indtast spiller
Spillere
Kontrakter
Domæne: Admin
Nyt Hold
Hold
Login
Admin: adgang til det hele
Trænere: Begrænset
Fysioterapeut: Begrænset
Spillere: Begrænset
Turneringer
Træningsprogrammer
Trænere
Dommer
4
Bilag 4.
Skema
GUI
9
Skema
Planer
Baner
Skema
Karakter
Faciliteter
Konklusion
Vores problemformulering lød således:
Hvordan kan man udvikle et system der understøtter en fodboldtræners administrative opgaver, og gør disse mere overskuelige?
For at finde ud af dette har vi undersøgt hvordan de nuværende omstændigheder for træneren er og hvordan han arbejder med sine opgaver. Ved brug
af SCRUM i vores arbejdsproces fik vi et virkelig godt overblik over de nødvendige værktøjer, der hjalp os med at komme frem til vores løsning. Vi har
undersøgt og overvejet de fordele det kan give en træner at få et godt system til sin daglige arbejdsdag. Vi har lavet en enkelt GUI (Graphical User Interface) som består af en database, der kan gemme de oplysninger som skal
hentes eller indtastes af træner eller administrator. Disse funktioner er ikke
programmeret, da vi ikke er programmører, men de bagvedliggende funktioner er defineret i vores diagrammer. Vores GUI fungerer derfor kun som
grafisk layout for brugerfladens design, og er lavet som en enkel og simpel
bruger løsning, der skal programmeres i java så det kan virke på nettet.
Systemet er lavet således, at det hjælper træneren, administratoren og
resten af aktørerne som kommer til at bruge systemet, med at komme frem
til de ønskede oplysninger og ændre disse oplysninger.
Litteratur liste
Objekt Orienteret Analyse & Design
Lars Mathiassen; Andreas Munk-Madsen; Peter Axel Nielsen; Jan Stage
3. udgave
Forlag: Marko ApS
ISBN: 87-7751-153-0
Applying UML and Patterns:
An Introduction to Object-Oriented Analysis
and Design and the Unified Process
Craig Larman
3. udgave
Forlag: Parson Education, Inc.
ISBN: 0-13-148906-2
Sekundær litteratur
Adobe Creative Suite 4 Master Collection
herunder
-Photoshop
-Illustrator
-Indesign
Microsoft Office 2007
herunder
-Word
-Visio
10
Bilag Modul 5
Systemudvikling
for fodboldtræner
E-konceptudvikling
Gruppe 1: Line Breum Sørensen, Ásdís Ólafsdóttir og Mads Nyborg
Bilag 1. SCRUM
Product Baglog - Opstart
Product Baglog - I processen
Sprint Baglog - I processen
Færdigt analyse arbejde der skal implementeres i rapporten
- I processen
Status på Rapporten -I processen
Ting som skal laves til Rapporten
- I processen
Bilag 2. Hædelsesliste
Admin
ny spiller
start
intaster ny spiller
skrive navn
cpr
adresse
teefon
email
hvilke hold
trøj nummer
vægl kontrakt ja/nej
hvis ja dato fra og til
Tekst oplysninger
hvis nej start dato
tekstboks til oplysninger
uploade pasfoto
(ændre oplysninger om
spiller)
afmelde spiller
kan ændre i alle delene
slut
Fysioterapeuter
Holder sig opdateret
start
tager imod spiller
intaster nuværende
status
færdig med timen
laver update på status
fastlægger ny tid for
spiller
slut.
- spilletider
- træningstider
- optræningstids
punkter (evt.
bookning)
Træner: laver et hold
start
kigger på spillernes karakter
vælg 4 forsvarspillere
vælg 4 midtbanespillere
indtast 2 angribere
og en ekstra spiller
vælger udskiftningsspiller
enter
slut
Sted for kamp eller
træning
størrelse
udstir
externe muligheder
Reservationer
Faciliteter
Dækningsbidrag
Udgifter
Indtægter
sponsors
Hjælpetræner
start
kigger på spillernes karakter
Holdets træningsskema
nødvendige oplysninger om
spillere, tid og sted hvor
kampen afholdes
Finder et eksisterende
træningsprogram
vælger ude eller inde
opvarming
30, 60 90 min
kondition
30, 60 90 min
teknik
30, 60 90 min
fysik
30, 60 90 min
enter print ud/send til hold
lave nyt træningsprogram
Redigere i et eksisterende
træningsprogram
gem ændringer
Træner: trænigsprogrammer
start
Finder et eksisterende
træningsprogram
vælger ude eller inde
opvarming
30, 60 90 min
kondition
30, 60 90 min
teknik
30, 60 90 min
fysisk
30, 60 90 min
enter print ud/send til hold
lave nyt træningsprogram
Redigere i et eksisterende
træningsprogram
gem ændringer
slut
Ekstra hændelser
Kamper
Spillere
Ekstraplayers
Fasiliteter
Intast en ny kamp
Hold
Sted
Tid
Vælg en eksisterende kamp
Alfabetik, tid sted
DOMMER
StartS
Indtast ny dommer
Navn
Adresse
(e-mail)
Telefon
kategorie
eksisterende dommer
lave tidsplan
slut
Bilag 3. Aktivitets diagram - AS IS
Bilag 4. GUI