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.
2 kommentarer:
Här kommer mitt förslag till en algoritm:
- Gruppen diskuterar inbördes, går igenom vad som skall göras, fördelar roller samt börjar brainstorma och införskaffa information.
- Vi börjar titta på olika lösningar. Förslag på platformer för mobilen är en java applikation eller en hemsida anpassad för mobilen (WAP).
>> 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 definítivt är att en databas behövs för att strukturera, lagra och sortera all information (text, bild och ljud om fåglar etc). Vilken databastyp som väljs besultas efter diskussion med kund.
- Diskussion med kund för att ta reda på vad kunden verkligen önskar och vilka funktioner som behövs.
- 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 platform beslutar gruppen vilken platform systemet skall baseras på samt vilken databastyp som skall användas.
- Kraven specificeras ytterligare samt kompletteras till följd av att man vet vilken platform 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.
- Demo versionen 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 demo version är klar och godkänd (av kunden).
- Om kunden är nöjd fortsätter gruppen till "påbyggnadsfasen".
- 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.
Här kommer mitt förslag, har dock inte hunnit mer än till utökning av kravspecen då jag var tvungen att packa upp de sista lådorna i lägenheten:
>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.
>Efter att punkterna ovan är avklarade, börjar vi titta på realistiskalösningar:
-Ska databasen 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 mobilalö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.
-Fullskaligahemsidans 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 mobilhemsida 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 aktivt med både kund och expedrter under dessa steg.
>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 kravspecifikation tas fram. (Dock till största del en stomme).
>Beslut om vilken väg vi ska ta för att nå bästa resultat jämfört med kundens önskningar.
>Vi gör nu en grundlig undersökning av de olika delarana och utökar kravspecifikationen därefter. (Eftersom vi nu har en klarare bild av vad som är den lämpligaste lösningen).
Skicka en kommentar