torsdag 27 september 2007

Målsättning

(Sid 356?)

Leveransmål
  • En prototyp till en informationsdatabas med tillhörande hemsida och mobilapplikation skall levereras.
  • Prototypen skall levereras med ett litet urval av fåglar (10-20 st).
  • Prototypen skall vara komplett vad gäller struktur, design och kodning så att databasen senare kan fyllas på med fåglar enkelt utan att någon extra programmering skall behöva göras.
  • Prototypen skall vara färdig att levereras vid utsatt tid.
  • Prototypen skall vara väl fungerande.
  • Demonstration skall visas för kund.
  • På hemsidan skall hjälpdokumentation finnas tillgänglig.
Produktmål
  • Informationsdatabas över fåglar skall skapas.
  • Upprätta en kommunikation mellan mobil och hemsida.
  • Produkt skall vara bättre än utvalda system[*] vad gäller design, funktionalitet och plattform.
    * De system som jämförs med är tipsade av kunden och innefattar: spoven.com, skof.se, tarsiger.com.
  • Produkten skall fungera på majoriteten av dator- och mobilsystem.
  • Hemsidan skall vara dynamisk och kompatibel med implementering av web 2.0 applikationer.
  • Hemsidan skall klara av streaming av media.
Affärsmål
  • Kunna expandera produkten att täcka hela Sverige.
  • Kunna omforma prototypen till en kommersiell produkt.
Domänmål
  • Vara bland de ledande portalerna på Internet inom vårt domän.
  • Produktkostnaden skall variera max 5% inom slutlig kostnad.
Kundmål
  • Underlätta hittandet av information över fåglar.
  • Kunna enkelt söka efter fåglar och annan relevant information.
  • Att locka till sig nya användare.
  • Att underlätta kundens vardag som fågelskådare.
  • Leverans enligt överenskommelse.
  • Nöjd kund

mer Datum

Kundmöte:
4/10 kl 15:00

Presentation och Quiz:
10/10


Domänanalys:
12/10 : DA handledningsmöte

25/10 : Deadline

vecka 41 : Kommit långt på DA... :S


Kravspec v1.0:
25/10 deadline

Kravspec v2.0:
20/11 Deadline

OFFERTEN

Hej här kommer det jag skrivit så här långt på offerten:

Offert:


Inledning:

Under vårt möte så beskrev ni att ni önskade erhålla en samlingsplats för information om fåglar och kartor över bra platser att se fåglar. Denna samlingsplats skulle gå att nå både via användarnas datorer och mobiltelefoner. Detta kommer kräva att vi utvecklar en tillgångsplats på internet med tillgång till en datasamling samt en liknande plats för mobiltelefonerna även dessa med tillgång till samma datasamling, dock lite begränsad för optimal funktionsduglighet. Vi har tagit fram några olika förslag på hur vi ska nå en komplett och väl genomtänkt lösning på er förfrågan. Att ta fram dessa lösningar kräver precis den kunskap som vi besitter.


Förslag:

-En datasamlingsplats om fåglarna och områdena (t.ex. Bilder, Ljud, Kartor och Information) byggs upp och samlas på en plats som går att nå via internet, en så kallad webbserver.

-Efter att datasamlingsplatsen är framtagen så börjar vi ta fram en stationärlösning, då vi anser att detta ger en bra grund att stå på då vi tar fram den mobilalösningen.

-När vi anser att vi har kommit tillräckligt långt med den stationäralösningen, så börjar vi utveckla en liknande version, dock anpassad för mobiltelefoner, till mobiltelefonerna.

-Testning av lösningarna påbörjas för att kontrollera att all funktionalitet fungerar som det bör.

-Då vi nått detta steget så presenterar vi en tidig beta för er då ni får komma med förslag på vad som borde eventuellt förändras och möjligen förbättras.

-Efter att vi fått era förslag och förbättringar så tar vi oss an att lösa dessa.

-Vi implementerar alla förslag och förbättringar som är möjliga.

-Åter igen så testar vi igenom all funktionalitet och ser till att vi har optimerat det.

-Ni presenteras nu med en stort sett fullständig version av vår lösning. Även här vill vi gärna ha "feedback" på vad ni saknar och önskar.

-Efter detta möte tar vi oss an att finslipa lösningen till att passa er perfekt.

-Sista testningen inleds.

-Vi levererar en fullständig produkt (enligt avtal) till er.

Argument för den valda lösningen ska vara här (vet inte riktigt hur vi ska argumentera när vi inte ens får välja vilken lösning vi ska använda....)

Tidplan


Offertvillkor:

För att lösningen ska bli så bra som möjligt kräver vi närvarande av kunden vid angivna genomgångsmöten. Samt att kunden tar fram en lämplig plats för placering av produkt för tillgång till internet (Detta kan ändras om kunden önskar att vi tar fram även denna plats).

I produkten ingår följande:
-En fungerande datasamlingsplats, med funktion för tillägg av fåglar och områden samt att tillhörande information till tidigare nämda.

-En fungerande lösning för stationär information.

-En fungerande lösning för mobil information.

-Installation kommer ske via kundens eller vår framtagna plats för placering av produkten.

-Underhållsservice ingår till och med 1 månad efter installation, men kan förlängas om annat avtal tas fram. I underhållsservicen ingår jourtider även på helger.


Pris:

-Tid spenderad till programmering ca. X hela arbetsveckor(á 40 timmar) per person i projektet, i detta fallet 5 personer. Kostnad:

-Underhållsservice 1 månad ingår. Kostnad: 0

-Ev. Installationsplats på internet, om inte kund tillför detta. Kostnad:

-Ev. kostnad för fortsatt underhållsservice om detta extra avtal skrivs. Kostnad:

-Totala kostnad:


Faktureringsvillkor:

Kunden skall betala ovanstående summa senast 30 dagar efter leverans.


Leverans:

Produkten levereras till tidigare överenskommen plats. I detta ingår leverans av: 1-stationärlösning, 1-Mobillösning och en datasamlingplats.


Giltighetstid:

Detta erbjudande gäller högst 30 dagar efter att det uppvisats för kund.


Garantier:

Garantier ingår i att vid leverans skall de ovan presenterade delarna vara fullt funktionsdugliga. Dock ingår även den avtalade underhållsservicen.


Överenskommelse har nåtts mellan båda parterna.
Parterna består utav och Birdproject gruppen.

onsdag 26 september 2007

Kommande möten och träffar!

Hej allihop!

För att ingen ska missa de datum vi har sagt så kommer de här:

Torsdag kl 12:15 i 6** - Träffas vi och pratar igenom datumen vi ska ge till Christine och Lise. (Domänanalys, Kravspec 1.0 och Kravspec 2.0).

Fredag kl 10:15 i 6** eller annan angiven plats från torsdagen - Träffas vi och går igenom Projektplanen, Algoritmen samt offerten.

Måndag kl 12:15 i 6** - Vi går igenom och fixar med det sista i våra inlämningsbitar (Projektplanen och Offerten).

Onsdag kl 17:00
sista chans att lämna in Projektplan och Offert. Kom ihåg att vi ska opponera på någon annans material också.

måndag 24 september 2007

Minnes anteckningarna från handledarmötet.

Lösningsförslag:

-Karta
-Böcker
-Interaktiviteten
-Features
-Hur rapporterar man fåglar i dagsläget?
-Projektkraven?
-Informationsflödet
-För tidigt beslut:
>>Släppa den infekterade diskussionen
>>Funktionskrav
>>Vilka medier har de idag?
>>Vad vill kunden ha?
>>Bredare analys av funktionen

Projektplan:

-Namn istället för TG
-Kvalitetsmål
>>Studiemål
>>Ordentliga mål?!
-Referenser
-Efternamn på gruppmedlemmar
-Fel modell (pratade vi om efteråt)
-Matris i riskanalysen
>>Påskyndat arbete (inte en bra lösning på risker)
>>Vem löser samarbetsproblem?
-Prioriterat arbete (inte dokument) *Kommer inte riktigt ihåg vad jag menade här*
-Definiering
-Prestanda ej en risk
-Leverans
-Hur ofta backup?
-Mall i dokumentet
-Konfigurationsmall = versionshantering

Algoritm:

-För många ord!
-Hieraki
-Ta bort 2/3 av allt vi har skrivit
-Saknas test?
-Test spec långt efter att vi har gjort testerna.
-Iteration istället för vattenfall
-Extra features i början av projektet
-Vad är slutprodukten?
-Funktionsanalys

Vecka 39

  • Projektplan klar
  • Valt lösningsförslag
  • Påbörja domänanalys
  • Skissa på kravspecifikation
  • Offert klar

lördag 22 september 2007

Lösningsförslag

Lösningsförslag 1:

Hemsida baserat på PHP :: Mobil baserat på en hemsida i PHP anpassad för mobiler.

Fördelar:

Egna

+ Oberoende plattform

Ekonomiska

+ Finns Open Source verktyg

Kundens

+ Ingen installation
+ Inga ev. uppdatering
+ Lätt igenkänsligt gränssnitt

Nackdelar:

Egna

- Alla har inte kunskap inom PHP

Ekonomiska

-

Kundens

- Kräver konstant Internet uppkoppling


Lösningsförslag 2:

Hemsida baserat på Java (Servlet) :: Mobil baserat på Java (Midlet).

Fördelar:

Egna

+

Ekonomiska

+

Kundens

+

Nackdelar:

Egna

- Alla har inte kunskap inom Servlet/Midlet
- Mer naturligt att programmera direkt i HTML än genom Java

Ekonomiska

- Servlet genererar mer kod (med tanke på att det är Java och HTML ”sammanflätat”), kostar mer tid.

Kundens

- Kräver konstant Internet uppkoppling
- Måste installera applikation
- Måste ev. uppdatera

Lösningsförslag 3:

Hemsida baserat på Flash :: Mobil baserat på Flash anspassad för mobilen.

Fördelar:

Egna

Asd

Ekonomiska

Asd

Kundens

asd

Nackdelar:

Egna

- Alla har inte kunskap inom Flash

Ekonomiska

Asd

Kundens

- Kräver konstant Internet uppkoppling



Hemsida
+ Kan uppdateras enkelt
+ Dynamiskt
+ Enkelt för användaren
- Kräver en modern webbläsare

Java
+ Enkelt gränssnitt?
- Måste laddas ner till telefonen vid varje uppdatering
- Kräver Java

onsdag 19 september 2007

Riskanalys


Projektrisker

  • Underskattning av tiden
    - P=3 - C=5 >> R=15
    - ÅTGÄRDER: Påskyndat arbete, bra planering
  • Sjukdom
    - P=3 - C=2 >> R=6
    - ÅTGÄRDER: Inte för beroende av en person, komplettera varandra
  • Gruppmedlemmar blir underkända på Quiz och kan inte fortsätta
    - P=3 - C=4 >> R=12
    - ÅTGÄRDER: Vara aktiv på föreläsningar, ta studier på allvar
  • Samarbetsproblem
    - P=2 - C=2 >> R=4
    - ÅTGÄRDER: Förmedling, kompromiss
  • Dokumentation tar för stor fokus
    - P=4 - C=4 >> R=16
    - ÅTGÄRDER: Fördela arbetet, sök handledning
  • Ofullständig kravspecifikation
    - P=5 - C=3 >> R=15
    - ÅTGÄRDER: Sätta större fokus vid skrivandet av kravspecifikationen, diskutera med kund och handläggare
Produktrisker

  • Hackningsrisk
    - P=1 - C=5 >> R=5
    - ÅTGÄRDER: Backup, öka säkerheten
  • Brist på mobil täckning
    - P=4 - C=5 >> R=20
    - ÅTGÄRDER: Lägga varnande text på hemsida
  • Hårdvaruhaverering
    - P=1 - C=3 >> R=3
    - ÅTGÄRD: Backup
  • För höga prestandakrav på mobiltelefonen
    - P=2 - C=2 >> R=4
    - ÅTGÄRDER: Koda mindre krävande applikationer, minska storlek på media
  • Dålig funktionalitet (exempelvis buggar)
    - P=3 - C=2 >> R=6
    - ÅTGÄRDER: Väl genomförda tester, låta utomstående testa produkten
Affärsrisker

  • Kunden ändrar sig
    - P=4 - C=5 >> R=20
    - ÅTGÄRDER: Bra korrespondens med kund, vara tydlig vid kontakt, presentera demo versioner, låta kunden aktivt vara med i utvecklingen
  • Upphovsrättsskyddat material
    - P=5 - C=4 >> R=20
    - ÅTGÄRDER: Begräna tillgång, hitta fritt material, använda symboliskt (fritt) material
  • Uppskjutet leveransdatum
    - P=2 - C=5 >> R=10
    - ÅTGÄRDER: Jobba extra, bra planering

tisdag 18 september 2007

Prototyp

Nu ska vi göra 3st prototyper också. Förslagsvis att vi gör dem antingen på papper eller skisser på en dator. Dock måste vi komma ihåg att lämna in dem till Lise och Christin på morgonen samma dag. 24/9 14:20

Förslag på prototyper:

-Webbsida baserad på PHP (snabbt ihopkok) samt en mobil webbsida byggd även den i PHP.

-Webbsida byggd på PHP samt en mobil applikation byggd med midlet.

-Webbsida byggd på HTML eller FLASH samt en mobil applikation av ovanstående slag men med en annan layout kanske.

8-15 torsdag lektioner: Tid till prototyp 12-13 + 15:00+

// Björn

måndag 17 september 2007

Mål vecka 38

  • Algoritm
  • Bestämma kvaliteten
  • Fördela roller
  • Förväntningar

Lösningsförslag

Lösningsförslag 1:

Hemsida baserat på PHP :: Mobil baserat på en hemsida i PHP anpassad för mobiler.

Fördelar:
  • Egna: Enkelt att komma igång med
  • Ekonomiska: Många Open Source-program
  • Kundens: Enkelt att använda, flexibelt

Nackdelar:
  • Egna: Alla kan inte programmering med PHP
  • Ekonomiska: Inga
  • Kundens: Kan inte göras lika avancerat som ett Java-program (men just vi i vår grupp kommer å andra sidan inte kunna göra ett Java-program som kan bli mer anvancerat än en webbsida)

Lösningsförslag 2:

Hemsida baserat på Java (Servlet) :: Mobil baserat på Java (Midlet).

Fördelar: Här är lite positiva saker.

Nackdelar:



Lösningsförslag 3:

Hemsida baserat på Flash :: Mobil baserat på Flash anspassad för mobilen.

Fördelar:

+

Nackdelar:

-


Hemsida

+ Kan uppdateras enkelt
+ Dynamiskt
+ Enkelt för användaren
- Kräver en modern webbläsare

Java
+ Enkelt gränssnitt?
- Måste laddas ner till telefonen vid varje uppdatering
- Kräver Java

söndag 16 september 2007

Webbsida

Vårt domännamn är birdproject.johanbengtsson.se. Jag har mailat ut uppgifter om FTP-kontot och vår databas.

torsdag 13 september 2007

Kundmötet

Här kommer en del information från kundmötet.

Vi ska satsa på en "riktig" och en mobil hemsida. På den riktiga ska det framför allt finnas information om de olika platserna där man kan se fåglar och hur man tar sig dit. Det ska även gå att lägga till fåglar.

På den mobila sidan ska det finnas information, ljud och bild till varje fågel, samt ev möjlighet att lägga till fåglar.

Vi ska själva göra ett grundarkiv med fåglar i området så det räcker inte med att bara lägga till en fågel som demonstration.

Bra länkar som vi fick av Lars Mårtensson

Här kommer länkarna:

Skånes Ornitolog Förening

Finsk sida med ljud och bilder från/på fåglar

Nordöstra Skånes Ornitolog förening

onsdag 12 september 2007

Algoritm

Utgångsläge

Förkunskaper i PHP, HTML, Java, MYSQL-databaser och design, men ingen om fåglar.

Vi har en idé om vad vi ska göra och hur vi ska göra det. Gruppindelningen har påbörjats. Kommunikationen inom gruppen är löst, bland annat genom att samla all viktig information på en blogg.

Resultat

Upprätta en informationsdatabas om fåglar för fågelskådare i Kristianstad. Informationen ska kunna nås från en Internetuppkopplad mobiltelefon.

Instruktioner

  • Diskussion förs om vad som bör göras för en funktionell produkt.

  • En indelning inom gruppen görs för att maximera produktionsprocessen i framtiden.

  • Vi börjar titta på olika lösningar.
    Förslag på plattformar för mobilen; en java applikation eller en hemsida anpassad för mobilen.

    >Information sökes kring de olika sätten samt vi försöker ta reda på för- och nackdelar för varje metod.

    >> Det som är definitivt är att en databas behövs för att strukturera, lagra och sortera all information (text, bild, film och ljud om fåglar). Vilken databastyp som väljs beslutas efter diskussion med kund. En fråga som kan vara avgörande i beslutet är om databasen ska klara av många fler områden än bara Kristianstad? Om så, bör vi titta på en lösning som klarar av många fler poster. Om inte bör en enklare och billigare lösning fungera.

    >>> Ska vi skapa ett program för den mobila lösningen eller ska man endast ha tillgång till sidan via sin webbläsare i telefonen?En applikation till mobilen ökar antagligen hastigheten dock begränsar det uppdateringsmöjligheterna. En mobil webbsida underlättar uppdateringar och nyreleaser men kan kanske strypa hastigheten då det inte hänger på telefonen utan på uppkopplingen.

    >>>> Fullskaliga hemsidans innehåll?Möjlighet för kartor, bilder, ljud och filmer? Kartor bilder och ljud bör inte vara några som helst problem att implementera, svåra frågan är videon. Är det värt platsen och tiden det kommer ta. Samt spaningsanteckningar via en karta på hemsidan? Kartorna har vi, dock måste det skrivas en lite applikation som klarar av att markera kartorna och lägga in detta i databasen. Kontaktmöjligheter mellan skådare t.ex. forum och chat? Forumet är enkelt fixat, chat däremot kräver att enklare protokoll skrivs.Samt lämpligaste kod att skriva både mobila hemsida och fullskaliga hemsida? Servlet, PHP eller HTML? PHP känns som enklaste och smidigaste koden att använda dock beror det helt på vad som har tänkts ska vara på de olika sidorna. Servlet kan krävas för inloggningsprotokoll.

  • Diskussion förs med kund för att ta reda på vad kunden verkligen önskar och vilka funktioner som behövs.

    >Skapa pappersprototyper för att kunna visa för kund, handledare och oss själva. Ger en bra översikt på hur det skulle kunna fungera.

  • En liten skiss på en kravspecifikation görs baserat på diskussionen med kunden.

  • Beroende på vad kunden sagt och med hjälp av informationen man införskaffat (tillsammans med för- och nackdelar) om varje plattform beslutar gruppen vilken plattform systemet skall baseras på samt vilken databastyp som skall användas.

  • Kraven specificeras ytterligare samt kompletteras till följd av att man vet vilken plattform systemet skall baseras på (och då även vet dess begränsningar men även möjligheter).

  • Gruppen delar in sig i mindre smågrupper ev. tilldelar olika bitar av det inledande arbetet till varje person.

  • En databas upprättas samt en grundstruktur för hemsida görs.

  • En enkel prototyp till den mobila delen görs och testas för att se hur systemet fungerar och interagerar.

  • Databas, hemsida och mobil binds ihop så de kan samspela med varandra.

  • En mindre testfas inleds där enklare tester, baserat på kravspecifikationen, formuleras.

    > Systemet testas och eventuella fel åtgärdas. Ställningstaganden tas också om något i grunden behöver förbättras, utökas eller tas bort. Resultatet av testen avgör också om ändringar i kravspecifikationen och annan dokumentation skall göras eller inte. När gruppen är nöjda med ändringar och anser att systemet är en stabil och tillfredsställande grund inleds "demofasen".

  • Design av hemsida börjar skissas och formas så sidan får färg och form.

    > Parallellt med design av hemsidan görs även design av mobila gränssnittet. De två ska ha liknande drag men behöver inte nödvändigtvis se identiska ut. Det är det mobila gränssnittet som "dominerar" vad gäller design i element som skall användas av bägge delar (t.ex. i val av logo, om en logo inte är lämplig för mobilen men passar bra för hemsidan skall inte den logon användas utan en annan logo skall göras som är bättre lämpad för mobilen).

  • Ett testutbud av material/fåglar sätts in i databasen, som syns både på hemsidan och i mobilen.

    > Om det behövs kan hemsida och mobila delen kompletteras där det brister så det blir en liten fungerande beta prototyp som kan visas upp för kund.

    >> Diskussion förs aktivt med både kund och experter under dessa steg.

  • Demoversionen av hemsidan och mobila applikationen sammanställs och visas upp för kund och eventuellt handledare för feedback.

  • Om kunden inte är nöjd och/eller önskar komplettering görs föregående steg om tills en tillfredsställande demoversion är klar och godkänd (av kunden).

  • Om kunden är nöjd fortsätter gruppen till "påbyggnadsfasen".

  • Kravspecifikation fullbordas.

    > Parallellt med kravspecifikation skrivs testspecifikation.

  • Gruppen tar reda på vilka möjligheter som finns vad gäller media (bilder och ljud). Om material som inte är upphovsrättskyddat hittas används detta för att fylla ett grundutbud med information om fåglar i hemsida och mobila applikation.

    > Om inget sådant media material hittas måste gruppen ta ett ställningstagande till var eller hur de skall få tag på media.
    Förslag: köpa media, använda skyddat material men begränsa sidan så utomstående trafik (utanför skolan) är minimal, lägga in figurer som senare kan ersättas med riktiga bilder om fritt material hittas.

  • Hemsidan fullgörs.

    > Parallellt med hemsidan fullgörs även mobila lösningen.

  • I mån av tid diskuterar och värderar gruppen inbördes om eventuell extra funktionalitet hos produkten.

    > Som exempelvis forum, chat, rapportering, medlemsida osv.

    >> Diskussion förs även med kund under detta steg.

  • Om extra funktionalitet har bestäms skall dessa implementeras.

    > Regressionstest införs då för att testa att varje enskild funktion samt att funktionens samspel med hela systemet fungerar felfritt.

  • En beta version lanseras och presenteras för kund och handledare.

    > Beta tester förs av gruppen men även utomstående som tas in för att testa systemets funktionalitet och användarvänlighet.

  • Om alla är nöjda lanseras produkten annars itereras föregående steg tills lösningen är fulländad.

  • Projektet avslutas.

Konsekvenser

  • Om man struntar i att göra sitt arbete (eller gör små felsteg) skall man bjuda gruppen på något symboliskt
  • Vid upprepade/allvarligare felsteg skrivs ej acceptanslappen under
  • Om första deadline ej hålls skall gruppen se till att den riktiga hålls (vilket kan kräva eventuellt extra arbete)

Ground Rules

  • Träff 1 gång/veckan
  • All väsentlig info skall finnas på bloggen
  • Avstämning: beskriva (varje vecka) vad man gjort och uppnåt
  • Vid problem >> fråga - alla skall ställa upp!
  • Sätt upp mål för varje vecka
  • Tidig första deadline med "tidsbuffert"
  • Flexibel arbetstid för gruppen med förståelse för fritid

måndag 10 september 2007

Release!

Bloggen är uppe. Nu är det bara att sätta igång och samla information, diskutera och samordna våra idéer och talang för att skapa ett innovativt och välfungerande system för fågelskådare!