I122 våren 2003 oppgave 1, revisjon 1 Generelle krav til besvarelser ------------------------------ - Tidsfrister for delinnleveringer og sluttinnleveringer/presentasjoner skal overholdes. - Dokumentasjonsstandarder skal overholdes. - Alle dokument (inklusiv kildekode) legges i et cvs-arkiv som opprettes og kontrolleres av gruppeleder. Se egen introduksjon om å komme i gang med cvs. - Innleveringer skjer ved å si fra (dvs. sende e-post til gruppe- og kursledere) hvilke versjoner i gruppens cvs-arkiv som er inngår i innleveringen. Dette setter oss i stand til å hente ut og videreforedle det arbeidet som er gjort. Det anbefales å legge mellomversjoner inn i cvs-arkivet selv om disse ikke er en del av en innlevering. - Alle dokument skal ha - navn på forfatter og dato for ferdigstilling - eventuelt navn og dato for andre som har vært inne og rettet på dokumentet - navn på alle som var involvert i inspeksjon av dokumentet, hvilke roller de hadde, dato for når inspeksjonen ble utført, og om det kom frem vesentlige merknader - et automatisk gjenkjennbart cvs-versjonsnummer. Kortfattet informasjon om hvorfor denne versjonen ble laget (f.eks. oppretting av dokument, rettelse av feil slik og sånn, implementering av metoden sånn, osv.) - Implementasjon skal gjøres i Java. - Kvaliteten på dokumentene skal sikres ved å utføre dokumentinspeksjon. Ved inspeksjon er det naturlig at følgende roller dekkes: - forfatter av dokumentet/koden som noterer hva som må gjøres av forbedringer og gjennomfører disse - bruker av dokumentet/tester av kode - en megler som driver dokumentgjennomgangen videre og noterer vesentlige punkt som kommer opp, oppsummerer hovedmerknadene og avgjøre om retting og kanskje ny inspeksjon er nødvendig - inspektører som skal se kritisk men konstruktivt på dokumentet - Kvaliteten på kode skal i tillegg sikres ved å utvikle testprogram som så kjøres for å kontrollere at ting virker som forutsatt. - Programvare skal kunne kjøre på undervisningsanlegget (UA), et unix-anlegg ved institutt for insformatikk, UiB, og på PC med "windows". Sistnevnte type utstyr må studentene stille med selv, dvs. at minst en person på hver gruppe må ha tilgang til slikt utstyr. - Det vil være tilgjengelig en bærbar PC og videoprosjektør til presentasjonene. Tidsplan -------- Prosjektperioden er fra fredag 31.1.03, med ferdigstillelse senest mandag 17.2.03. Deretter følger presentasjoner av løsningene ved de enkelte gruppene i uken 18.2.03 til 21.2.03. Følgende aktiviteter skal gjennomføres til gitte tidspunkt: - Gruppene må starte arbeidet umiddelbart etter forelesningen fredag 31.1.03. Gruppelederne er tilstede for å avtale møtetider mm. på forelesningen. - Innleveringene skal være registrert i cvs-arkivet senest 0800 mandag 17.2.03. - Gruppene skal presentere sin besvarelse etter følgende tidsplan: - tirsdag 18.2. kl. 1415 rom 2143: Gruppe 5: overordnet system - tirsdag 18.2. kl. 1515 rom 2143: Gruppe 6: utvalgte klasser - torsdag 20.2. kl. 1015 rom 2142: Gruppe 3: brukergrensesnitt/klient - torsdag 20.2. kl. 1115 rom 2142: Gruppe 4: database/tjener - fredag 21.2. kl. 1015 rom 2143: Gruppe 1: nettverk 2001 - fredag 21.2. kl. 1115 rom 2143: Gruppe 2: nettverk 2002 Hver gruppe får en undervisningstime, 45 minutter, til disposisjon. Det vil være tilgjengelig tavle, lysarkprosjektør, en bærbar PC og en videokanon til presentasjoner. Instituttet er behjelpelig med å lage transparenter (utskrift i farger er mulig fra PC- og linux). Programvare som skal demonstreres bør være innstallert og testet på PCen senest 2 timer før presentasjonen tar til. Presentasjonene er en sentral del av pensum. Alle meldinger om innleveringer/godkjenninger og merknader sendes til gruppelederne med Cc til Magne. Oppgaver -------- Studentene som deltok på I122 våren 2001 satte i gang med utviklingen av FMS (forum og meldingssystemet). FMS ble så revidert av studentene på I122 våren 2002, og en prosjektgruppe jobbet videre med FMS sommeren og høsten 2002. Denne versjonen ble satt i prøvedrift høsten 2002. Ideen med FMS er at alle studenter og ansatte ved UiB som har datatilgang skal kunne bruke programmet til å lette kommuniseringen i og rundt de kurs som blir undervist. Programmet kan sees på som en hybrid mellom en meldingstjeneste og en nyhetsgruppeleser, men med fokus på interaktivitet. Målet er å få til større interaksjon mellom studentene, og å supplere slike tjenester som realfagsportalen. Programmet skal fungere slik at hvis en person som tar f.eks. I110 sitter og jobber med en oppgave, men ikke kommer noen vei pga. et lite problem; skal denne personen kunne sende en melding til de I110-studentene og andre interesserte som er pålogget. Denne meldingen kan andre lese og deretter besvare. Man kan se på dette som et intelligent e-postprogram som kun sender en melding til de som har behov for å lese denne. I tillegg kan den gjerne la være å levere ut meldinger til personer som logger inn et par timer senere, i motsetning til slik e-post ville ha fungert. FMS skal vi videreutvikle våren 2003. Oppgaven går på å kvalitetsforbedre dokumentasjon og kode for FMS. Den bedrede FMS skal tas i bruk etterhvert som den blir klar, til erstatning for den nåværende FMS. Alle aktuelle filer er lagret i et eget cvs-arkiv. For å få tak i informasjonen derfra følger du følgende enkle trinn: 1. Skriv "echo $SHELL". Hvis svaret du får er - "/bin/bash", skriver du videre "export CVSROOT=/Home/user/KURS/I122". - "/bin/csh" skriver du "setenv CVSROOT /Home/user/KURS/I122". Skulle svaret vise seg ikke å være noen av delene, trenger du ikke dette dokumentet for å vite hva du gjør i dette trinnet. 2. "cd" deg til en passende arbeidskatalog (en katalog med navnet "i122", for eksempel) og gi kommandoen "cvs checkout i122". Skjermen skal nå oversvømmes med lite hjelpsom tekst som hevder at noe foregår. La den fortsette med dette en stund. Du har nå sjekket ut I122-koden og kan fortsette med trinn 3. Skulle du få en feilmelding, bør du straks ta kontakt med Magne, Helge eller Gard og fortelle hva som skjer. 3. Systemet CVS har nå opprettet sin egen katalog med navnet "i122". Gå inn i denne katalogen og les README-fila med f.eks. kommandoen "less README". Følg instruksjonene her. Arbeidet med å gå kvalitetsforbedre dokument og kode fordeles på 6 grupper. Hver av gruppene skal presentere sin innsikt for de andre på kurset, slik at alle får en totalforståelse av FMS. Noe bakgrunnsinformasjon for analyse og vurderinger finnes i læreboken. - Gruppe 1: nettverksmodul fra 2001: integrasjon i versjon 2002 av FMS Gruppekoordinator: Helge Holm Hans Fredrik Nordhaug, Haakon Vik Nilsen, Bjørn Even Wahlstrøm, Tormod Lid - Gruppe 2: nettverksmodul fra 2002: sikre stabilitet og effektivitet Gruppekoordinator: Gard Vaaler Eirik Gaarden, Øystein S. Haaland, Dag Viggo Lokøen - Gruppe 3: klient/brukergrensesnitt Gruppekoordinator: Helge Holm Yngve Espelid, Jan Ivar Beddari, Anita Arianna Kyriacou - Gruppe 4: tjener/database Gruppekoordinator: Helge Holm Therese Sande, Audun Hegranes, Alexander Sewe - Gruppe 5: overordnet system Gruppekoordinator: Gard Vaaler Lars Skjærven, Mikal Carlson Østensen, Sondre Goberg - Gruppe 6: basisklasser Gruppekoordinator: Gard Vaaler Lars-Helge Netland, Brage Breivik, Bjørn Songe-Møller, Hallvar Helleseth, Martin Arver, Tom Erik Olsen Gruppene må selv fordele arbeidet slik at alle komponenter blir dekket. Gruppe 5 skal som tar seg av overordnet system har som oppgave passe på at fordelingen av arbeidsoppgaver (ut fra temaene over) fungerer. Videre skal de analysere systemet som helhet og overvåke integrasjonen av forbedrede biter til FMS-distribusjonen (konfigurasjonskontrollen). De har ikke ansvar for selve integrasjonen av de forbedrede kodebitene og uttesting av at de bedrede biter fungere med resten av FMS. Dette er ansvaret til den gruppen som har med forbedringen av koden å gjøre. Hver enkelt gruppe må i sitt arbeid forholde seg til følgende: - organisering av gruppen - livssyklusmodell for gruppens arbeid - kontinuerlig levere inn til gruppelederne forbedrede versjoner/konfigurasjoner av kode slik at dette kan innstalleres for bruk - bruke verktøy - overordnet dokumentasjon skrevet i latex med UML-diagram skrevet i dia. De nyttigste UML-diagrammene for oss er bruksmønster-, sekvens- og tilstandsdiagram for systemoversikt, eventuelt klasse- og komponentdiagram for mer oversikter over enkeltkomponenter. - modulspesifikk dokumentasjon skrevet i javadoc - testing skrevet i hht. teststandarder - FMS skal brukes til kommunikasjon om kurset og oppgavene - dokumentinspeksjon skal gjennomføres på alle innleverte dokumenter/koder. (Det er altså lov, og dette anbefales sterkt, å legge inn dokumenter i CVS etterhvert, og bruke CVS aktivt til å utveksle nye, ikke-ferdige, versjoner av dokumentene. Først når dokumentinspeksjon og tester er gjennomført anses dokumentet/koden som ferdige.) - Konfigurasjon beskrives i et eget cvs-dokument - forbered kvaliteten i utdelte moduler ved å sjekke at følgende er tilstede, komplettere det som mangler og eventuelt rette opp detekterte feil. Gruppelederne er behjelpelig med å avgjøre hvordan uklarheter i hva som er rett skal forstås. - Dokumentasjon som beskriver - spesifikasjon - implementasjonsskisse - Kode som omfatter - datainvariant, equal-metode - som kan (ved betinget aktivering) verifisere datainvariant, forkrav - testkode: - svart boks: tester i henhold til spesifikasjonen - klar boks: tester i forhold til problemområder i algoritmen - integrasjonstest: koden integreres i FMS og den nye FMS prøves ut - utført tester: - dokumenteres hvordan (regresjons-)tester skal utføres - dokumentere at svart/klarbokstester er utført og hva resultatet av disse ble - dokumentere hvordan integrasjonstesten ble utført og resultatet av denne Det er viktig at definerte standarder er fulgt. Påpek eventuelt hva som mangler av standarder og funksjonalitet i modulen dere er ansvarlig for. Om nødvendig må standarder utarbeides. - Innleveringen består av: - innsendelse av konfigurasjonsinformasjon og installasjonsinformasjon til begge gruppelederne og Magne via e-post. - en beskrivelse av hva som er gjort, hvordan arbeidet ble organisert og hvordn gruppearbeidet fungerte. - besvare følgende spørsmål - hva dere mente oppgaven var da dere begynte på den - hva hensikten med oppgaven egentlig var - hva dere har lært av oppgaven - Til slutt en plenumspresentasjon av oppgaven som er løst. Hver gruppe tildeles 45 minutter forelesningstid i uken 18.2.03-21.2.03. Etter følgende plan: - tirsdag: gruppe 5, gruppe 6 - fredag: gruppe 3, gruppe 4 - torsdag: gruppe 1, gruppe 2 Presentasjonshjelpemidler inkluderer: tavle, lysark, videokanon&bærbar PC. Instituttet er behjelpelig med å lage transparenter (utskrift i farger er mulig fra PC- og linux). Programvare som skal demonstreres bør være innstallert og testet på PCen senest 2 timer før presentasjonen tar til. 31.1.03 Magne Haveraaen kursansvarlig i122 vår 2003