Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Støtte for Læring i Individuelt Tempo

No description
by

Kim Lindtner

on 23 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Støtte for Læring i Individuelt Tempo

Tid
Prosess
Empirisk
Time boxing
Fast ramme
Sprint
Sprint 1
Sprint 2
Sprint 3
Utfordringer
Kunnskap
Analyse & programmering
Scrum
Løst i fellesskap
Erfaringer
Lærdom - prosess og modeller
Fokus
Hva ville vi gjort annerledes?
Scrum
"Expect the unexpected"
Agile Software Development with Scrum, Schwaber & Beedle, 2002
Støtte for Læring i Individuelt Tempo
Samhandle med systemet
Dynamisk
Basert på brukerhistoriene
Applikasjonsdomenet
er det systemet skal løse
Problemdomenet
Vi har tatt med "lest kommentar" som en hendelse
Systemutviklerne har tatt med personer som klasser
Forvirring rundt aggregering mellom fremdriftsplan og student
Clusteret blir brukt fordi alle brukerene har utvalgte klasser til felles

Vi har valgt å ha tilstanden "Under utvikling" fordi en modul kan i sjeldne tilfeller aldri bli publisert
Det er hensiktsmessig å ha med tidsstempler og ansvarlig for å ha logg over endringer
blir administrert, overvåket og kontrollert av systemet
beskriver hensikten med systemet
Modellene
skal modellere den virklige verden slik fremtidens brukere ser den for å skreddersy systemet og møte med deres behov
en enkel modell kan vise et komplisert system
ser på samme verden fra flere perspektiv
Systemdefinisjon
F – Functionality
A – Application domain
C – Conditions
T – Technology
O – Objects
R – Responsibility

en helhetlig definisjon av systemet som brukere, investorer og utviklere kan være enige om
den skal så langt det lar seg gjøre skrives i dagligdags tale
Funksjonalitet
Erstatter
Universitet
Sikkerhet
Passord
Passordsstyrke
Kritiske konsekvenser

Modulprogresjon og etikk
Skjult - beskyttelse
Gjennomsnitt - motivasjon
Hvorfor - sensitiv informasjon
Krav
Tilfredstille krav
Studenter
Kontroll
Informasjon
Frister
Forelsere
Oversikt
Progresjonsplan
Kriterier for implementasjon
Funksjoner for brukerhistorier
Gå tilbake
Må være på plass
Del av analysen
Tilfredstilles i implementasjon
Sjekket underveis og ved slutt
Testkriterier
Sjekke funksjoner
Teste systemet
Hver brukerhistorie
Nødvendige tester
Diskusjon
Inneholde hva og hva er målet?
Implementasjon
NetBeans
JSF
Grensesnittet
Ingen funksjon
Java Backing Bean
Get og set metoder
Enterprise Java Bean
Sette inn, oppdatere og slette
Entitetsklasser
Tabell i databasen
Felter = attributter
Velger PK
Persistence Unit
Databasenavn, passord,brukernavn
Hvordan hente inn brukerhistorier?
Intervjue brukerne
Stille åpne spørsmål
Iterativ prosess
Format
Format 1:
Som en(bruker)
Vil jeg ha(funksjon)
For å(formål)

Format 2:
For å(formål)
Som en(bruker)
Vil jeg ha(funksjon)



Argumenter for brukerhistorier
Funksjon og hensikt
Motstridende ønsker
Kritisk - forstå bruker
Prioriteringer
MoSCoW-teknikken
Must
Should
Could
Won't
Rich Picture
Skjermdump
Use case diagram
Funksjonsliste
Sekvensdiagram
Navigasjonsdiagram
Kriterier for implementasjon
Testkriterier
Ressurser
Funksjonalitet
Systemet
Full transcript