Handledningsmöte

Saker som endast påpekades lite snabbt

• Förklara hjälpfunktionen - vad ingår?
• Beskriva vad man är inloggad som.
• Varför man ska sortera efter läte.

Fixa på hemsidan

• Sökfunktionen fungerar inte i den usla webbläsaren IE7.
• Göra reklam för den vanliga och mobila sidan på respektive sidor, fast tvärtom.
• Kontrollera felmeddelanden.

Slutrapporten

• Skriva den rapportmässigt - inte krönikamässigt.
• Beskriva produkten mer ingående med dess mervärde. Skillnad mellan mobil sida och vanlig.
• Vilka språk vi valt och varför. PHP, E/R-diagram osv.
• Avslutning med en beskrivning av processen.

"Förenkla vardagen"

Här kommer ett antal punkter som beskriver hur vår produkt förenklar vardagen för en fågelskådare. Punkter som är markerade med (+) innebär att detta är en fördel som fågelböcker inte har:

1) Samlar all info på en plats
2) Interaktiv karta (+)
3) Rapportering (+)
4) Läte (+)
5) Sortera i lista med bilder istället för med namn (+)
6) Socialt nätverkt (+)
7) Interaktiv information över fåglar (+)
8) Avancerad sökning (+)
9) Populäraste fåglar och lokaler, samt senaste rapporter moduler (+)
10) Nyheter/Senaste nytt (+)
11) (Taggar/Etiketter) (+)

Kommentarer från möte Christine (Krav kursen)

• Bryta ner utvecklingsdelen i progressrapporten
  
  

Domänanalys

• Pilar i grafisk del
• Förenkla vardag <<>
• Väder-plugin?
• Observation!
• Existerande gränssnitt - intressanta
• Fler kravstilar - Virtual Windows
• Säkerhet - prestanda
• Vad i sökfunktion som ska användas (punkt 8)
• Utmärkande drag hos Club300's rapporteringssystem
  

Kravspecifikation

• Sökning/listning? Var konsekvent!
• Infoga inledande kapitel: vad SRS:en täcker, beskrivning, hur numreringen har skett i SRS:en etc
• Grund krav: Innehåll på svenska <<>
• Ta bort teckensnitt/storlek
• Virtual Windows
• Grund krav: skriv att gäller både mobil & hemsida!
• Ett klick?
• Innehåll=? Specificera vad som innebär!
• 206: punkt >> Ska bli nytt krav "lista efter..."
• XX ändra till __
• 213: Skärmstorlek?
• 217: omformuleras
• 223: Går eller ej? Sök alternativ <<>
• SRS1 endast grunden >> funktionella SRS2
• 303: ta bort "i praktiken"
• Fågelrapportering i hemsida och mobil? Dela upp/var konsekvent
• Beskrivande text för fågelrapportering: Specificera hur mycket!
• Definiera "profilsida"
• Inga krav på "commynity"
• Hur sker bekräftelse? Mail? Pop up?
• Vad är skillnaden mellan 355 och 220? 359 och 226?
• Medlemskap >> strukturera, endast på hemsida!
• Saknas: prestanda krav, leverans krav, säkeher, design, utvecklingsmiljö, programmeringsspråk, manualer?, hjälptext?, kravtext till E/R diagram.

Kundmöte 8/11

• Lokaler istället för kartor
• Designen är bra
• Fåglar ska kunna grupperas efter familj (svenska familjnamnet)
  
• Fågelrapporteringen ska bl a innehålla datum, art, antal och plats
• Ev olika läten, men vi skulle bara ta hanens läte?
• Ev olika bilder, men vi skulle bara ta bild på hanen?
• Kort info om varje fågel med vad som skiljer hanen från honan och karakteriktika (?)
  
• Den långa informationen måste man aktivt klicka sig fram till
• Sammanfattningsvis gillade han Spanet!
  

Kravspecifikation 0.1

Generella krav

BPG_1: Innehåll skall vara på svenska.

BPG_2: Teckensnitt skall variera.

BPG_3: Storlek på teckensnitt skall variera.

BPG_4: Design av innehåll skall styras via en extern CSS stilmapp.

BPG_5: Det skall alltid gå att återvända till föregående sida.

BPG_6: Startsidan skall alltid gå att återvända till via ett klick.

BPG_7: Fågelarter skall kunna listas efter bokstavsordning.

BPG_8: Fågelarter skall kunna listas efter landskap.

BPG_9: Fågelarter skall kunna listas efter kommun.

Funktionella krav för hemsida

BPR_1: 95% av allt innehåll skall fungera på webbläsarna Fireox, Internet Explorer, Safari, Opera.

BPR_2: 95% av allt innehåll skall fungera på operativsystemen Linux, Mac och Windows.

BPR_3: Huvudpunkterna i startmenyn på hemsidan skall synas på alla undersidor.

BFR_4: Fågelarter som finns tillgängliga på hemsidan skall ha en egen undersida.

BFR_5: Fågelartens undersida skall innehålla följande textbaserad information: artnamn (svenska och latin), landskap, kommun och beskrivande text.

BFR_6: På fågelartens undersida skall en länk finnas till sektionen för fågelrapportering där alla rapporteringar av fågelarten skall listas ordnat efter fallande datum.

BFR_7: På fågelartens undersida skall en fullskallig huvudbild finnas, antingen på fågelarten eller en generell ersättande utfyllande huvudbild.

BFR_8: Huvudbilden på fågelarten i fågelartens undersida skall ha storleken XX pixlar.

BFR_9: Den generella ersättande utfyllande huvudbilden på fågelartens undersida skall ha storleken XX pixlar.

BFR_10: Fågelartens undersida skall, i mån av fler bilder, ha möjligheten att lista fler bilder på fågelarten.

BFR_11: Om fågelartens undersida listar fler bilder på fågelarten skall dessa listas som miniatyrer med en länk till fullskalig upplösning på bilden.

BFR_12: Miniatyrerna på fågelartens undersida skall ha storleken XX pixlar.

BFR_13: Bilden med fullskalig upplösning som miniatyren länkar till skall inte ha en storlek större än skärmens upplösning.

BFR_14: På fågelartens undersida skall möjligheten finnas att lista ljudklipp på fågelarten.

BFR_15: Ljudklippen på fågelartens undersida skall vara av filtyperna MP3 och RealMedia.

BFR_16: Ljudklippen på fågelartens undersida skall gå att ladda ner.

BFR_17: På fågelartens undersida skall en länk finnas till ett formulär där en länk till den aktuella fågelartens undersida skickas till den e-post man anger i formuläret.

BFR_18: Då fågelarter listas skall även ett sökfält finnas.

BFR_19: Sökfunktionen där fågelarter listas skall kunna söka efter fågelarter baserat på artnamn.

BFR_20: Sökfunktionen där fågelarter listas skall kunna söka efter fågelarter baserat på beskrivande text.

BFR_21: Att lista endast fåglar som har bild skall kunna finnas som sökalternativ för sökfunktionen där fågelarter listas.

BFR_22: Att lista endast fåglar som har ljudklipp skall kunna finnas som sökalternativ för sökfunktionen där fågelarter listas.

BFR_23: Det skall gå att kombinera sökalternativ för sökfunktionen där fågelarter listas.

BFR_24: Om sökfältet där fågelarterna listas lämnas tomt och användaren utför sökningen skall alla fågelarter listas efter bokstavsordning.

BFR_25: Om sökfältet där fågelarterna listas lämnas tomt men söksalternativ bockas för och användaren utför sökningen skall fågelarter listas efter bokstavsordning där listan är filtrerad enligt de förbockade sökalternativen.

BFR_26: Hela ord behöver inte skrivas in i sökfältet där fågelarter listas utan sökfunktionen skall klara av att söka baserad på enstaka bokstäver eller delar av ord.

Funktionella krav för fågelrapporterings rapporteringsformulär

BFR_27: Endast registrerade medlemmar på hemsidan skall kunna fågelrapportera.

BFR_28: Medlemmar måste vara inloggade för att kunna fågelrapportera.

BFR_29: Flera medlemmar skall i praktiken kunna fågelrapportera samtidigt.

BFR_30: Det skall gå att fågelrapportera från mobilen.

BFR_31: Innehållet av formuläret för fågelrapportering skall vara samma för hemsida och mobil.

BFR_32: Formuläret för fågelrapportering skall innehålla följande obligatoriska fält att fylla i: landskap, kommun och fågelart.

BFR_33: Formuläret för fågelrapportering skall innehålla följande frivilliga fält att fylla i: beskrivande text och antal.

BFR_34: Formuläret för fågelrapportering skall innehålla ett alternativ för att ange om fåglarna är döda.

BFR_35: Alternativ för att ange om fåglarna är döda i formuläret för fågelrapportering skall som standard vara avbockad (dvs. fåglarna är levande).

BFR_36: Val av landskap, kommun och fågelart i formuläret för fågelrapportering skall göras i en lista.

BFR_37: Om alternativet i val av kommun och fågelart i formuläret för fågelrapportering inte finns skall rapporteraren kunna skriva in ett nytt.

BFR_38: Det nya alternativet som rapporteraren skrivit in som val av kommun och fågelart i formuläret för fågelrapportering skall därefter finnas som valbart alternativ i listan.

BFR_39: Administratör skall kunna rätta felstavningar/ändra namn på nya alternativ som rapporterare har skrivit in som val av kommun och fågelart i formuläret för fågelrapportering.

BFR_40: Namnet på fågelarten i formuläret för fågelrapportering skall vara på svenska.

BFR_41: Om rapportören skriver in en fågelart eller kommun i formuläret för fågelrapportering som redan finns skall inte ett nytt element i listan skapas utan rapporten skall lagras under existerande fågelart/kommun.

BFR_42: Fält för användarnamn, datum och tid i formuläret för fågelrapportering skall fyllas i automatiskt.

BFR_43: En länk till medlemmens profilsida skall finnas om man klickar på användarnamnet i listan för fågelrapportering.

BFR_44: Om fågelarten som rapporterats finns i listan över fågelarter skall en länk till fågelartens undersida finnas om man klickar på fågelarten i listan för fågelrapportering.

BFR_45: Om en fågelart läggs till i listan över fågelarter skall fågelartens namn även läggas till som ett valbart alternativ i listan över fågelarter i formuläret för fågelrapportering.

BFR_46: Om obligatoriska fält i formuläret för fågelrapportering är ifyllda och man skickar iväg fågelrapporten skall ett bekräftelsemeddelande ges.

BFR_47: Om obligatoriska fält i formuläret för fågelrapportering inte är ifyllda skall ett felmeddelande ges.

Funktionella krav för fågelrapporterings sökfunktion

BFR_48: Användare måste inte vara registrerade för att se eller söka efter alla fågelrapporteringar.

BFR_49: Fågelrapporter skall listas efter datum-tid i fallande ordning.

BFR_50: Då fågelrapporter listas skall även ett sökfält finnas.

BFR_51: Sökfunktionen där fågelrapporter listas skall kunna söka efter fågelrapporter baserat på datum, landskap, kommun, artnamn och användarnamn.

BFR_52: Sökfunktionen där fågelrapporter listas skall kunna söka efter fågelrapporter baserat på beskrivande text.

BFR_53: Att lista endast fåglar som är döda eller levande i fågelrapporteringen skall kunna finnas som sökalternativ för sökfunktionen där fågelarter listas.

BFR_54: Det skall gå att kombinera sökalternativ för sökfunktionen där fågelrapporter listas.

BFR_55: Om sökfältet där fågelrapporter listas lämnas tomt och användaren utför sökningen skall alla fågelrapporter listas efter datum-tid i fallande ordning.

BFR_56: Hela ord behöver inte skrivas in i sökfältet där fågelrapporter listas utan sökfunktionen skall klara av att söka baserad på enstaka bokstäver eller delar av ord.

BFR_57: Fågelrapporteringens sökfunktion och listning av fågelrapporter skall vara samma för hemsida och mobil.

Funktionella krav för mobilen

Kraven BFR_4-7, 10-11, 13-14, 18-26 skall gälla även för mobilen.

BFR_58: Huvudbilden på fågelarten i fågelartens undersida skall ha storleken XX pixlar.

BFR_59: Den generella ersättande utfyllande huvudbilden på fågelartens undersida skall ha storleken XX pixlar.

BFR_60: Miniatyrerna på fågelartens undersida skall ha storleken XX pixlar.

BFR_61: Ljudklippen på fågelartens undersida skall vara av filtypen MP3.

BFR_62: Ljudklippen på fågelartens undersida skall gå att ladda ner.

BFR_63: På fågelartens undersida skall en länk finnas till ett formulär där en länk till den aktuella fågelartens undersida skickas till den e-post man anger i formuläret.

Funktionella krav för medlemskap

BFR_64: Formuläret för registrering av medlemskap skall innehålla följande obligatoriska fält att fylla i: användarnamn, lösenord och mail.

BFR_65: Formuläret för registrering av medlemskap skall innehålla följande frivilliga fält att fylla i: personlig beskrivning, valfri bild, intressen, stad, mobil.

BFR_66: Medlemskapet bekräftas och aktiveras genom ett autogenererat utskickat mail med en aktiveringslänk för kontot.

BFR_67: Medlemmens lösenord skall bestå utav minst 4 tecken och högst 12 tecken.

---

Att göra

Krav för:
- Kartor
- Medlemsprofil
- Extra funktionalitet
- - Väderlek, hitta hit, aktuellt, forum, länkgalleri, hjälp/manual…

>> Login

- Obligatoriska infofält att fylla i: användarnamn, mail
- Frivilla infofält att fylla i: stad, intressen, personlig beskrivning
- Medlemsskap bekräftas och aktiveras genom länk i utskickat mail
- Skall login modul vara länk i meny, en login ruta under menyn som syns alltid/på startsida?

>> Profilsida (?)

- Medlemslista i menyn

- Varje medlem skall ha sin personliga sida/profil
- - Info som kan fyllas in i profil: se login info (vad mer ska gå att skriva?)
- - Alla rapporteringar som medlemmen har gjort skall listas

- Medlemmens profilsida skall länkas i fågelrapportering när medlemmen rapporterar

När planerade ni nästa möte med Christin och Lise?

Hej!

Undrade mest när Ehsan och Irfan planerade nästa möte med C och L?
Har blivit av med datumen, och ngn lovade mig att skriva det på bloggen *host*. :D

Möte med Christin 12/10

Studieanvisningar till tenta:

-Föreläsningar och kapitlena som tillhör dem.
-Titta på kursplanen.

Allmänt:

C tycker att vi är efter i tidplanen och borde ha påbörjat Kravspecen redan.

DA:

-Vi måste göra en grafiskbild till yttredomänen.

-Kommunikations nät är mer av ett interface.

-Aktörer och intressenter ska beskrivas i detalj.

-Samla ihop och gör en profil på intressenterna
>>Förväntningar
>>Kompetenser

-Profil på kund, frågor.

-Allmän uppfattning: fågelskådare

-Gruppera ihop.

-Eliciteringstekniker
>>mer detaljer
>>interview borde läggas till
>>När ska vi använda de olika teknikerna?
>>Vad är målet?
>>Tillföra någoting nytt

-Kravstilar
>>Typ av krav
>>Vilken stil vi vill använda på de olika teknikerna.
>>kontextdiagram
>>Virtual windows

-Liknande läösningar och app:
>>Tala om vad vi har tittat på.
>>För- och Nackdelar
>>Varför blir vi bättre?

-Existerande interfaces:
>>Kommnät
>>Telefonen
>>DAtorn

-Speciella termer:
>>Allt som kan tänkas vara viktigt för alla i gruppen att veta.

-Hur detaljerade skall kraven vara för hemsidans och mobilens GUI?
>>Beror helt på hur mkt vi vill låsa det.
>>Virtual windows

-Övrigt:
>>Få struktur på kravspec. Så vi vet vad vi vill ha.
>>Använd DA
>>Hur delar vi upp det?

Domän analys

Grafisk presentation av intressenter: s.23

Aktörer

- Användare
- Administratörer
- Kommunikationsnät

Frågor att besvara till intressent analys (i domän analysen):

Vilka är intressenter?
1) Projektgruppen
2) Föreningen
3) Alla andra fågelskådare

Vilka mål har olika intressenter?
1)
- Göra kund nöjd
- Leverera en produkt som underlättar för fågelskådare
- Bli godkända på kursen
- Berika vårt kunskapsförråd och källa av erfarenhet

2)
- Underlättar vardagen för fågelskådare
- Samlar relevant information på en plats
- Får tillgång till information ute i fält

3)
- Få lätt tillgänglig information om fåglar
- Knyta kontakter med andra fågelskådare

Vad vinner de olika intressenterna på det?
1)
- Vi utökar vårt kontaktnät
- Inkomst
- Kunskap och erfarenhet
- Vi sätter oss på kartan

2)
- Information om fågelskådning blir tillgängling för alla
- Potentiala fågelskådare rekryteras
- Kristianstad Vattenrike får större spridning och kännedom

3)
- De sparar tid
- Får information
- Knyter nya kontakter

Vilka risker och kostnader har de olika intressenterna?
1)
- Leverar ett instabilt system
- Kund blir missnöjd
- Dåligt rykte på marknaden

2)
- Media kan bli dyrt
- Produkten försenas
- Produkten blir inte tillfredsställande

3)
- Mobil och internet taxa
- Mobil täckning saknas
- Internetleverantörens nät är nere

Arbetsområde (s.92-100)

1) Hemsida
- Databas
- - Fågelinformation
- - Användarinformation
- - Fågelrapportering

- Information om fåglar
- Bilder av fåglar
- Fågelljud
- Fågelrapportering
- Kartor
- Väderlek
etc?

2) Mobil
- Databas
- Fåglars ljud
- Information om fåglar
- Bild på fåglar
- Sökfunktion
etc?

Övrigt

Kraveliciteringstekniker (s.338 + http://www.student.hbg.lu.se/lth/christin/krav07/L2-Elicitation.pdf):
- Stakeholder Analysis
- Focus Groups
- Prototyping
- Design Workshops
- Domain Workshop

Kravstilar
- Feature requirements (då vi inte kan visualisera kraven med bild)
- Screens and prototypes (för hemsida och mobil)
- E/R diagram för databas (?)

Liknande lösningar och applikationer
- Tarsiger.com, Spoven.com, Skof.se
- Club300:s fågelrapporterings java applikation för mobilen
- Förra årets lösning i Projekt ÅK3

Existerande interfaces
Samma som liknande lösningar (se ovan)?
s.201?

Frågor

- Speciella termer? Obsar speciell term?
- Existerande interfaces?
- Hur detaljerade skall kraven för hemsidans och mobilens GUI vara? (Skall man exempelvis specificera vart sök knappen skall vara, vilken färg den skall ha etc etc?!)

Planering nästa vecka!

Måndag: Domänanalys- + Labbplanering. Oponering på offert och projektplan måste planeras med och göras innan onsdag.
tisdag: Plugga till quiz och förebereda framträdande.
onsdag: Presentation (vi måste fixa PPP till projektplanen)
torsdag: Labb DA!
Fredag: ?


Fick mail av Christine:

Handledar möte 15/10 kl 10:15 rum 622!

minnesanteckningar

kommer här i punktform som jag skrev ner dem:

-Spoven.com: Karakteristiska fåglar.
-Obs: Antal, art, plats, datum, tid
-Karta: Bekymmer -> pricka in stigar
-Frittfram med design
-Sökning sker efter namn på fågel
-Gränssnitt simpelt!
-Skådar antal: ca. 100
-Video ej öväsentlig men inte viktigt!
-Unika arter men hittas på annat håll (alltså även om en fågel är unik för Kristianstad så finns de på andra platser..)
-Fågelflytt är av intresse
-Blåst, väder viktigt för havsskådning. Lokalt väder?
-Lokal rapportering
-Områden, typiska arter, titta på spoven.com sa han.
-Begränsning av användning
-rariteter
-Döda fåglar, kan vara viktiga att rapportera
-Han tillhör KOF
-Nyheter i bloggform.

Presentationslistan!

Så äntligen kom listan (en dag senare...):

Hej,
Onsdag den 10 är det dags för presentation av projektplanerna och vi ser framemot en rad välförberedda och professionella presentationer.

Varje projektgrupp ska se till att gruppens kritikgrupp har tillgång till allt relevant material i god tid innan redovisningen.
Projektgruppen har 10 min till sin presentation och kritikgruppen har 8 min till att ge konstruktiv kritik.

Här nedan kommer redovisningstiderna. OBS! Det förväntas att hela klassen är närvarande kl 10.15 - 12.00

mvh
Lise

Tid Redovisning Kritik
10.15 – 10.35 RFID SAAB
10.35 – 10.55 Självgående fordon 1 Kristianstads vattenrike
10.55 – 11.15 Självgående fordon 2 RFID
11.20 – 11.40 Kristianstads vattenrike Självgående fordon 1
11.40 – 12.00 SAAB Självgående fordon 2

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.

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å.

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ö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

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

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å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

Webbsida

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

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

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

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!