I122 våren 2002 oppgave 2, revisjon 1 Generelle krav til besvarelsen ------------------------------ Se oppgave 1, http://www.ii.uib.no/~magne/i122v02-tekster/Oppgave1-v2 Bakgrunn for denne oppgaven --------------------------- Studentene som deltok på I122 våren 2001 satte i gang med utviklingen av FMS (forum og meldingssystemet). Dette er et programsystem som skal kunne benyttes av alle studenter og ansatte til å lette kommuniseringen i og rundt de kurs som blir undervist. FMS ble tenkt på som en hybrid mellom et diskusjonsforum, en meldingstjeneste og en nyhetsgruppeleser, men med fokus på interaktivitet. Programmet bør supplere tjenester som realfagsportalen (http://realfag.uib.no/). Planleggings- og utviklingsarbeidet som ble utført i fjor skal nå videreføres. Dette skjer i to steg, først som en planleggingsfase, og deretter som et utviklings- og vedlikeholdsarbeid. Følgende tidsplan settes opp for arbeidet: - uke 10, 11 og 12: planarbeid som utføres i konkurranse av 3 grupper, innlevering senest kl. 1600 onsdag 20.3.02 - uke 13: påskeferie - uke 14: gjennomgang av planarbeidet - uke 15, 16: utviklings- og vedlikeholdsarbeid av FMS som utføres av alle kursdeltakerne i samarbeid etter utarbeidet plan, prototyp av FMS som tåler minst 20 samtidige brukere skal kunne tas i bruk 22.4.02 kl. 1200. - uke 17, 18: sluttføring av utviklings- og vedlikeholdsarbeid, innlevering senest kl. 2359 tirsdag 30.4.02. Den beste planen, eventuelt en kombinasjon av de beste planene, vil danne basis for den tredje prosjektoppgaven på kurset. For mer bakgrunnsinformasjon: - se oppgave 1, i122 vår 2002: Oppgavetekst: http://www.ii.uib.no/~magne/i122v02-tekster/Oppgave1-v2 CVS/UML: http://www.ii.uib.no/~magne/i122v02-tekster/CVS-veiledning FMS-prosjektet: http://www.ii.uib.no/~magne/i122v02-tekster/FMS-filoversikt - CVS-arkivet for i122 med rot på "/Home/user/KURS/I122" - Oppsummering og vurdering av FMS fra vår 2001, i CVS-arkivet for i122, underkatalog "i122/dokumenter/presentasjon/" Arbeidsoppgave -------------- Planleggingsfasen går ut på å revidere det eksterne dokumentet og planlegge utviklingsfasen (eventuelt revidere fjorårets interne dokument). Det skal produseres og leveres inn: - et eksternt dokument som beskriver: - FMS fra et brukersynspunkt, men delt i 3 nivåer 1. hva som er en garantert minimumsversjon av FMS (prototypen som skal fungere fra uke 17) 2. hva som er realistisk å fullføre med de gitte rammebetingelser 3. hva som er en naturlig videreutvikling av FMS utover punkt 2 - oppsummert ressursbehov for de ulike delleveranser, gitt det utgangspunktet vi har i år med store deler av en implementasjon tilgjengelig - et internt dokument som gir en detaljert plan over utviklingsarbeidet for delleveranser i punkt 1 og 2 (i henhold til det eksterne dokumentet) og noe mer skissemessig plan og kostnadsanalyse for delleveranser etter punkt 3. Dette dokumentet kan være en videreutvikling og forfining av de gamle planene, eller en fullstendig omarbeiding av disse. Det er viktig at de reviderte planene, ut fra de forutsetninger vi har, analyserer og eventuelt revurderer: - avgrensning i forhold til, og eventuelt grensesnitt mot, andre tjenester studentene kan benytte seg av for undervisningsorganisering og -støtte - sårbarhets- og sikkerhetsvurdering av FMS, inkludert juridiske (så som personvernloven) og etiske/moralske sider - hvilken programvareprosess som skal brukes med beskrivelse av delaktiviteter, milepæler og allokering av ressurser (arbeidskraft og tid) til stegene - systemmodell, skisse til systemarkitektur, inndeling i ulike komponenter, beskrivelse av komponentene og hvordan de skal samvirke - detaljert kostnadsanalyse for de ulike delleveringene - hvilke fremdriftsrapporter og dokumenter som skal leveres til mellomledere og administrativt ansvarlig til hvilke tidspunkt - bruk av standarder, kvalitetskontrollrutiner og testplan. Ta også opp kostnader forbundet med å følge en uheldig standard versus kostnadene ved å skifte til en bedre standard og eventuelle besparelser det klan gi - forslag til organisering av tilgjengelige ressurser for å møte delleveransene. Forslaget til organisering må inneholde, med skikkelig begrunnelse: - hvordan arbeidet skal koordineres og ressursbruk rapporteres. - hvordan folk skal fordeles på arbeidsoppgaver. Det kan være greit å tenke seg programmererne fordelt på ulike små grupper, og kanskje at smågruppene har ulik kompetanse avhengig av hvilke arbeidsoppgaver de settes til. F.eks. kan personer med brukergrensesnitterfaring settes til å analysere og utvikle detaljer i et brukergrensesnitt, folk med ledererfaring kan fordeles på hver gruppe for å påta seg en gruppelederrolle og ha regelmessige koordineringsmøter med andre gruppeledere. Ta også hensyn til at tilgangen på arbeidskraft kan variere gjennom prosjektperioden (f.eks. pga. obligatoriske innleveringer i andre kurs). OBS! Prøv å tenk "roller" ved fordeling av folk - allokering av kursdeltakerne til de ulike "rollene"/ arbeidsgruppene er ikke en del av oppgaven og vil bli foretatt av de kursansvarlige. Det er viktig å tenke seg felles oppstartstreff, statusmøter, innleveringsfester som en del av arbeidsoppgavene, men alt dette er ikke en del av arbeidstiden. - bruk av CASE-verktøy og tid til opplæring i bruk av disse - risikoanalyse av prosjektplanen: hva kan gå galt/bra, indikatorer på at fremdriftsplaner/kvalitetsarbeid mm. glipper, og hva som da kan gjøres for å bringe prosjektet i havn: f.eks. redusere omfanget av delleveranser, forskyve milepæler, endre målsetting med prosjektet så som å lage mer detaljerte instrukser til de som eventuelt skal videreføre det ved en senere anledning - et selvstendig vedlegg som - forteller hvordan gruppen organiserte gruppearbeidet - forteller hvordan gruppen synes gruppearbeidet fungerte - forteller hva gruppen har lært av gjennomføringen av oppgaven - forteller hvor mye arbeidstid som gikk med til de forskjellige aktiviteter på prosjektet. Det er viktig å telle opp tid brukt til møtevirksomhet, opplæring, søking etter relevant bakgrunnsmateriale, kvalitetssikring mm. Programmene som FMS skal bestå av må være lette å innstallere, de må kunne kjøres som ikke-priviligerte brukere både lokalt på UA og over nettet, både hjemmefra men også fra f.eks. en internett-kafe i Sienna eller Managua. Kurset disponerer 14 personer i ca. 50% stilling til å gjennomføre utviklingsarbeidet, dessuten 2 mellomledere (Jan Christian og Kai) og 1 administrativt ansvarlig (Magne). Eksisterende dokument kan bearbeides eller deler av disse kan brukes i nye dokument. Med mindre et dokument er omarbeidet til det ugjenkjennelige må det ha en innledning som forteller hvor det skiller seg fra forrige hovedversjon. Bruk gjerne CVS til å utveksle og ta vare på mellomversjoner av et dokument. Den versjonen som leveres inn kan markeres spesielt i CVS, eventuelt gjenkjennes lett som den ferskeste versjonen i CVS-arkivet. Kostnadsanalyser kan baseres på en algoritmisk modell som COCOMO (dersom de nødvendige estimater kan gjøres), på erfaringer vunnet med systemutviklingen i fjor, eller ved en kombinasjon av disse og andre estimeringsteknikker. Argumentér for de kostnadsanalyseteknikkene dere velger, og husk å ta med forutsetningene for estimatene. CASE-verktøy som kan være aktuelle å bruke er - Forte for java: den er instalert på Solaris og Linux og startes med kommandoen "runide" som ved første gangs bruk setter i gang en lokal innstallasjonsprosedyre. Forte for java kan også installeres på egen PC ved å hente den selv fra http://www.sun.com/forte/ffj/index.html - Rational development studio: den er instalert på Solaris (SUN) og pakken klargjøres med "source /net/nume/rational/rs_setup.csh" - Feilrapproterings- og administrasjonssystem, så som "trouble" som ingeniørene ved instituttet benytter seg av. - Verktøy som er tilgjengelig og eventuelt kan installeres uten problem på UA. http://sourceforge.net/ er én kilde for relevant programvare. UML-notasjon skal brukes der dette er hensiktsmessig. Tidsplan for innleveringer prosjektoppgave 2 -------------------------------------------- - Alle dokumenter skal være innlevert senest kl. 1600 onsdag 20.3.02. Dokumentene skal være i redigerbar form (txt, tex, sdw, doc, etc., ikke ps, pdf, e.l.). Dokumentene skal legges i CVS-arkivet, på underkatalog i122/dokumenter/revisjon-v2002/gruppe-X (der X er A, B, eller C) og melding skal sendes til Magne, Jan Christian og Kai i hvordan og i hvilken rekkefølge deldokument skal skrives ut for å utgjøre en helhet. - Presentasjon skjer i uke 14 etter følgende plan: - torsdag 4.4., kl. 1215-1300, rom 2143 HiB, gruppe A - torsdag 4.4., kl. 1315-1400, rom 2143 HiB, gruppe B - fredag 5.4., kl. 1015-1100, rom 2143 HiB, gruppe C - fredag 5.4., kl. 1115-1200, rom 2143 HiB, diskusjon av løsningene Hver gruppe får 45 minutter til å presentere sitt arbeid. Presentasjonen skal dekke det eksterne dokumentet (der denne avviker fra fjorårets), det interne dokumentet, og dokumentet som beskriver planarbeidet. Det vil være tilgjengelig tavle, lysarkprosjektør, en bærbar PC og en videokanon til presentasjoner. Gruppelederne vil være behjelpelig med å lage transparenter og installere dokumenter på den bærbare PCen. Husk at det blir svært kort tid til å installere og klargjøre maskinen før en gruppes presentasjon. Alt må derfor være klart og sjekket ut på forhånd. Gruppene -------- Gruppene for planarbeidet består av: - gruppe A, tilsynsfører: Kai Tverrå Siv Hovland Erstad, Helge Skjellevik, Jon Svendsen, Fredrik Sæterdal - gruppe B, tilsynsfører: Kai Tverrå Kristian Blom, Helge Holm, Øystein Halseth Lund, Andres Ulsaker, Gard Vaaler - gruppe C, tilsynsfører: Kai Tverrå Harald Barsnes, Endre Bergesen, Bjørn Ove Johnsen, Jarle Mjåtveit, Saywan Pasha Gruppene må selv organisere seg mht. å velge struktur og roller, møtetider, fordeling av arbeidsoppgaver mm. Gruppene står også fritt til å reorganisere seg i løpet av prosjektoppgaven. Alle gruppene har samme arbeidsoppgave på dette prosjektet, og den beste innleveringen (eventuelt en kombinasjon av disse med justeringer) vil bli valgt som arbeidsplan for prosjektoppgave 3. Prosjektoppgave 3 foregår uke 15-18, med sluttinnlevering tirsdag 30.4.02. Den krever fullt samarbeid mellom alle deltakerne på kurset. 28.2.02 Magne Haveraaen kursansvarlig i122 vår 2002