Forprosjektdokument. Høgskolen i Buskerud Avdeling for Ingeniørutdanning Institutt for Datateknikk. Geir Øverby

Transkript

1 Høgskolen i Buskerud Avdeling for Ingeniørutdanning Institutt for Datateknikk Tilgjengelig JA NEI Referanse Revisjon 2 Dato Antall sider vedlegg Forprosjektdokument Dokument historie Revisjon Dato Godkjent Antall sider Geir Øverby Jørn Tharaldsen Ivana Novotna Godkjent: Dato Godkjent: Dato Oddny Ra Signatur Alexander Farstad Signatur Asgeir Ryen Torgeir Usland

2 Dokumentendringer Dette er tredje utgave Kapittel Dato Endringer alle Generell rettskriving Opprettet nytt kapittel om involverte i systemet Vedlegg Budsjettet er ferdig og godkjent Forside Logo er lagt til Copyright 20 00, gruppe DV Side 2 av 33

3 Innholdsfortegnelse 1 Innledning Om ez systems Om dette dokumentet Generell imformasjon Prosjektgruppe Veiledere og sensorer Oppdragsgiver Prosjektomgivelser Prosjektbeskrivelse Konseptuelt nivå Mer detaljert nivå Teknisk nivå Programmeringsspråk HTML PHP Databasespråk MySQL Web-server Apache Hvordan virker systemet Relaterte prosjekter Funksjonelle krav Databasens funksjoner Grensesnitt Kommunikasjon m/databaser Analyse av problemer og begrensninger Kunnskap og modningstid Tidsbegrensninger Upløyd mark Dersom lisenser uteblir Kommunikasjon Kommunikasjon med ez systems Intern kommunikasjon Konklusjon Løsningsforslag Forslag Modul 1, Pålogging Modul 2, Brukerkontroll Modul 3, Søke etter data Modul 4, Presentasjon av data Modul 5, Opplasting av dokumenter Forslag Modul 1, Pålogging Modul 2, Brukerkontroll Modul 3, Søke etter data Copyright 20 00, gruppe DV Side 3 av 33

4 6.2.4 Modul 4, Treffliste Modul 5, Presentasjon av data Modul 6, Opplasting av registrerte data Forslag Modul 1, Pålogging Modul 2, Legge inn data Modul 3, Endre eksisterende data Modul 4, Slette data Modul 5, Søke etter data Modul 6, Presentasjon av søk Modul 7, Presentasjon av valgte treff fra søk Modul 8, Enkel presentasjon av innlagte data Modul 9, Opplasting av dokumenter Analyse av utviklingsmodeller Vannfallsmodellen DOD Vannfallsmodellen med tilbakemelding DOD-2167a Evolusjonær utvikling Inkrementell utvikling Prototyping: Kast og lag ny utviklingsmetode Spiral Top down Grunnlinje styring (Baseline management) Objektorientert prosjektmodell Hacking modellen (Adhoc) Unified Process Konsekvensanalyse Konsekvenser ved å starte prosjektet Konsekvenser ved ikke å starte prosjektet En oppdeling i hoved aktiviteter, med målformuleringer for hver aktivitet Hovedaktiviteter Målformuleringer Grov aktivitetsfordeling Prosjektidéfasen Forstudiefasen Spesifikasjonsfasen Planleggingsfasen Konstruksjonsfasen Realiseringsfasen Etteranalysefasen Ressurser som prosjektet vil kreve Prosjektidé Forstudie Spesifikasjon Planlegging Konstruksjon Realisering Etteranalyse Budsjett Copyright 20 00, gruppe DV Side 4 av 33

5 10 Tidsplan med hovedmilepæler Gantt diagram med ressursallokering Ansvarskart Ordforklaringer Konklusjon Referanser/Kilder Copyright 20 00, gruppe DV Side 5 av 33

6 1 Innledning 1.1 Om ez systems ez systems et et lite software firma som holder til i Kongsberg og Skien. De leverer software løsninger til små og mellomstore bedrifter. Firmaet er delt opp i to avdelinger: Avdeling for systemutvikling: Denne avdelingen lager programvare som kan kjøres på multiplatform (Linux og Windows miljø). Avdeling for Web: Denne avdelingen designer skreddersydde internett løsninger. ez systems visjon er: Enkle (teknisk), brukervennlige, stabile og raske systemer. Produkter: ez time lanseres nå i Januar/Februar Fakta om ez systems: Hovedkontor: Kverndalsgate 8 Skien 4 ansatte 1.2 Om dette dokumentet Forstudiet skal inneholde en beskrivelse av målet med prosjektet, løsningsanalyse, konsekvenser ved å enten starte eller ikke starte prosjektet, utredning av utviklingsmetoder og verktøy, en fastlegging av milepæler og en kartlegging av ressurser som kreves. Copyright 20 00, gruppe DV Side 6 av 33

7 2 Generell imformasjon 2.1 Prosjektgruppe Navn: Geir Øverby, Prosjektleder Utdannelse: Høgskoleingeniør i optometri Adresse: Frogsvei 4, 3600 Kongsberg E-post: geirov@eunet.no Telefon: Navn: Jørn Tharaldsen Utdannelse: Høgskole ingeniør i elektronikk Adresse: Hans Becksvei 2, 3600 Kongsberg E-post: jt@tux.hibu.no ; thara@online.no Telefon: , (mobil) Navn: Asgeir Ryen Utdannelse: Sivil ingeniør fra tekniske fag, NLH Fordypning i næringsmiddel Adresse: Holbergvei 9, 3679 Notodden E-post: ar@tux.hibu.no ; mantis@spray.no Telefon: Navn: Ivana Novotna Utdannelse: Sivil ingeniør i kjemi Adresse: Meinsgate 7, 3600 Kongsberg E-post: iv@tux.hibu.no ; ivano9@srksda2.hibu.no Telefon: Navn: Utdannelse: Adresse: E-post: Telefon: Torgeir Usland Høgskoleingeniør i flyteknikk, HIA Kløversvingen 53, 3600 Kongsberg tu@tux.hibu.no ; peusland@online.no , (mobil) Copyright 20 00, gruppe DV Side 7 av 33

8 2.2 Veiledere og sensorer Intern veileder: Navn: Oddny Ra E-post: Ekstern veileder: Navn: Aleksander Farstad E-post: Intern sensor: Navn: E-post: Øyvind Eek Jensen Ekstern sensor: TBA 2.3 Oppdragsgiver ez systems Hovedkontor: Kverndalsgate 8 Skien 4 ansatte Copyright 20 00, gruppe DV Side 8 av 33

9 3 Prosjektomgivelser 3.1 Prosjektbeskrivelse Konseptuelt nivå Prosjektet går ut på å lage en applikasjon som skal kommunisere med en database. Denne kommunikasjonen skal sørge for manipulering av databasen. Applikasjon Informasjon Bruker Fig Mer detaljert nivå Informasjonen skal gjøres tilgjengelig for brukeren via bedriftens intranett. Brukeren har et sett med muligheter for hva han/hun vil gjøre med informasjonen. Intranett Applikasjon Informasjon Bruker Fig Teknisk nivå Bruker benytter en nettleser for å aksessere databasen der informasjonen er lagret. Applikasjonen som ligger på en Apache web-server kommuniserer med databasen, og sørger for at bruker får den informasjonen han/hun ønsker. Nettleser HTML Apache web-server PHP Database MySQL Bruker Fig 3.3 Bruker benytter en nettleser for å : Aksessere database Redigere databasen Applikasjon: Kommuniserer med database Genererer HTML ut fra database Copyright 20 00, gruppe DV Side 9 av 33

10 3.2 Programmeringsspråk Programmeringsspråk, databasespråk og aktuell web-server ble fastsatt av vår oppdragsgiver ez systems. Derfor følger det kun en kort presentasjon av de aktuelle språk HTML Hypertext Markup Language er en samling plattform uavhengige stiler, som vha såkalte tagger (<Tagger>) definerer de forskjellige komponentene i et WWW dokument. Selv om de fleste på gruppa ikke har programmert noe særlig inen HTML regner vi ikke med at dette skal bli noe problem PHP3 PHP, Hypertext PreProsessor, er et server -side skript språk. PHP koden skrives inn mellom <Tagger> i HTML koden, noe som gjør det mulig å hoppe inn og ut av PHPmodus. Mye av PHP koden er en kombinasjon av Perl, Java og C. Syntaks strukturen er veldig likt C. Et eksempel beskriver bedre. <html><head><title>example</title> <body> <?php echo Hei, jeg er et php script! ;?> </body></html> Det som skiller PHP fra såkalte client-side skript språk, som javascript, er at koden blir eksekvert på web-serveren. Blandingen av HTML og PHP lagres på serveren med etternavnet.php3. På det mest grunnleggende kan PHP gjør alt det ethvert annet CGI (Common Gateway Interface) program kan, som samle inn data, generere dynamiske deler av en side, eller sende og motta cookies. Men PHP s kanskje sterkeste side er at det støtter en rekke ulike database typer. I dette prosjektet er det bestemt av oppdragsgiver at det skal benyttes MySQL. PHP kan også benytte seg av en rekke andre protokoller som IMAP, SNMP, NNTP, POP3 og HTTP. Ettersom PHP låner veldig mye av syntaks strukturen til C er ikke dette et helt ukjent programmeringsspråk. Men det er en helt klar utfordring for prosjektgruppa å skulle løse oppgaven i dette språket. Copyright 20 00, gruppe DV Side 10 av 33

11 3.3 Databasespråk Databasespråket som skal benyttes i oppgaven ble bestemt av vår oppdragsgiver ez systems MySQL Databasen skal bygges vha MySQL på en Apache server. MySQL er en flerbruker, flerprosess SQL database server. SQL er det mest brukte og best standardiserte databasespråket i verden i dag. Følgende kvaliteter blir fremhevet for MySQL: Mulighet for å tjene et uendelig antall samtidige brukere. Kapasitet på oppføringer. Rask eksekvering av kommandoer, muligens den raskeste på markedet. Enkel og effektiv. MySQL er for UNIX og OS/2 gratis, mens det må betales lisens dersom den skal kjøres på en av Microsofts operativsystemer. 3.4 Web-server Apache Apache er den helt klart ledende web-serveren som finnes på markedet i dag, med en andel på ca 60%. Det sies at den er stabil og har bra ytelse. Kildekoden er fritt tilgjengelig, noe som gjør at det stadig kommer forbedringer/forbedringsforslag fra brukere overalt i verden. Apache har en mengde funksjoner tilgjengelig bl.a. en PHPmodul, som skal benyttes i dette prosjektet. Web-serveren kan benyttes av Windows NT og UNIX. På det nåværende tidspunkt vil vi bruke UNIX X-terminaler for oppkobling mot serveren. Copyright 20 00, gruppe DV Side 11 av 33

12 3.5 Hvordan virker systemet Her følger en beskrivelse av hvordan HTML, PHP, MySQL og Apache samarbeider for at brukerne skal se resultatet i sin nettleser. 3 PHP script 2 5 Apache 1 6 Web side i nettleser MySQL Database server 4 PHP Fig 3.4 Scenarioet er som følger: Brukeren skal via en web-side hente informasjon ut av en database. Brukeren adresserer web-siden vha en nettleser. Da brukeren får kontakt med webserveren kaller denne et PHP script som kjøres vha PHP preprocesssoren, som igjen henter den aktuelle informasjonen ut av databasen. Informasjonen som blir hentet blir behandlet av den gjenstående koden i PHP scriptet, og gjort om til HTML. Det siste HTML resultatet blir sent tilbake til brukerens nettleser. Steg for steg vil det foregå omtrent som dette (følg nummereringen på figuren): 1. Bruker klikker på en link i nettleseren sin, nettleseren sender en forespørsel til en internettadresse, for eksempel 2. Apache får forespørselen for foofoo.php3. Denne vet at.php3 filer blir behandlet av PHP preprocessoren, og gir beskjed til PHP at denne får ta seg av dette. 3. foofoo.php3 er et PHP script som inneholder forskjellige kommandoer. En av disse kommandoene er å etablere en kommunikasjonskanal til en database og hente noen data. PHP vet hvordan den skal kommunisere med databasen. 4. Dataene kommer tilbake fra databasen, og foofoo.php3 formaterer disse dataene. Typisk vil dette være hvordan dataene skal presenteres i HTML. 5. HTML koden kommer tilbake til apache. 6. Apache sender HTML koden tilbake til til brukerens nettleser som en respons på hans forespørsel. Brukeren ser nå en fin web-side med noe informasjon fra databasen. Copyright 20 00, gruppe DV Side 12 av 33

13 3.6 Relaterte prosjekter Prosjektgruppe D har også et prosjekt hos ez systems, og benytter de samme programmeringsspråk og utviklingsverktøy. Men fra tidligere år er det ingen prosjekter å sammenligne med. Copyright 20 00, gruppe DV Side 13 av 33

14 4 Funksjonelle krav 4.1 Databasens funksjoner Det skal utvikles en kunde database som skal innholde relevant informasjon for alle kundene til ez systems. Det bør også være mulighet for å registrere eventuelle notater angående firma/person. Informasjonsflyt (dokumenter) mellom ez systems og kunde bør også kunne lastes opp via web. Denne databasen skal ha et Web-grensesnitt som skal benyttes på ez systems intranett. Her skal det være mulig å søke etter eksisterende, legge til, endre eller slette kunder fra databasen. Det skal også utvikles en modul som presenterer en oversikt over registerte kunder i databasen. Systemet skal selvsagt ikke kunne aksesseres av alle, så det må utvikles et påloggingssystem. 4.2 Grensesnitt Ingen spesielle krav om utseende er stilt, bortset fra at det skal være et enkelt og lettfattelig. Det skal utvikles vha HTML og PHP. 4.3 Kommunikasjon m/databaser Utvikling av webgrensesnittet skal gjøres vha HTML og PHP. PHP delen av grensesnittet tar seg av kommunikasjonen mot databasen som skal være avtypen MySQL. HTML PHP Database server MySQL Fig 4.1 Copyright 20 00, gruppe DV Side 14 av 33

15 5 Analyse av problemer og begrensninger 5.1 Kunnskap og modningstid Siden dette er en forholdsvis stor og krevende oppgave og ingen av gruppas medlemmer har noen videre erfaring innen programmering og prosjektarbeid, vil det selvsagt bli en del utfordringer. En av de første utfordringene vi vil møte, er å få en god forståelse av selve oppgaven. Her tenker vi blant annet på faktorer som oppbygning av databasemiljøet som er basert på multiplatform og hvordan dette skal implementeresinn i et lett forståelig brukergrensesnitt som er kompatibelt med databasen. Noe som vil dukke opp ganske tidlig, er den manglende kunnskapen innen UML, databaser og PHP/html. Siden vi ikke tidligere har hatt noen erfaring med hverken MySql og PHP vil dette selvsakt kreve en del ekstra jobb fra gruppaens side, men det er noe som vi ser på som en ekstra utfordring. 5.2 Tidsbegrensninger En annen utfordring er tiden. Dette semesteret inneholder både vinterferie og påskeferie, men da tiden er knapp, har deler av disse feriene blitt satt av til jobbing med prosjektet (jfr. Vedlegg 1). 5.3 Upløyd mark Software-prosjekt er i utgangspunktet en prosjekttype som ingen av gruppas medlemmer har vært borti før. Her ligger det en klar utfordring i gjennomføringen av prosjektet. 5.4 Dersom lisenser uteblir En manglende tilgang på planlagte utviklingsverktøy, vil medføre forandringer i planene. Copyright 20 00, gruppe DV Side 15 av 33

16 5.5 Kommunikasjon Kommunikasjon med ez systems For å kunne få et brukbart resultat, stilles det krav til en god kommunikasjon mel lom prosjektgruppas medlemmer og ez systems kontaktpersoner. Det er veldig positivt at ez systems tar prosjektet seriøst, og at tilstrekkelig med hjelp, informasjon, tid og ressurser er til rådighet, da dette er en nødvendighet for å få prosjektet i havn.hvis deler av dette bortfaller, vil dette kunne forsinke prosessen. Av Vedlegg 1, kommer det tydelig fram at forsinkelser vil medføre store utfordringer for gruppa for å få gjennomført prosjektet til angitte frister. En manglende kommunikasjon eller forståelse av ez systems krav/ønsker under utviklingen av Kravspesifikasjonen, kan gi et produkt som blir annerledes enn det bedriften ønsker seg. Derfor er det bedre å spørre en gang for mye, enn en gang for lite Intern kommunikasjon. En god intern kommunikasjon er minst like viktig. Den interne kommunikasjonen går både på forholdet mellom prosjektgruppas medlemmer og intern veileder. En manglende kommunikasjon kan medføre forsinkelser i forhold til angitt tidsplan, men også nye utfordringer som misforståelser, dobbeltarbeid og konflikter innad i gruppa. 5.6 Konklusjon Dette kommer til å bli et veldig interessant og lærerikt prosjekt på mange måter. Her vil vi få prøvd ut evnen til å utvikle en database med tilhørende brukergrensesnitt, komme med ideer til løsninger, tenke brukervennlighet, tilegne oss masse kunnskap på egenhånd, i tillegg til selve prosjektgjennomføringen. Vi er nødt til å tenke i nye baner; på kunden og dens ønsker, skolens krav og forventninger, og det å jobbe flere personer mot ett og samme mål. Det blir viktig å tenke samhold og progresjon. Vi er alle innstilt på å gjøre vårt beste, slik at vi kan få et produkt som vi kan være stolte av, våre forutsetninger tatt i betraktning. Copyright 20 00, gruppe DV Side 16 av 33

17 6 Løsningsforslag 6.1 Forslag Modul 1, Pålogging Av sikkerhetsmessige hensyn ønskes det en påloggingsmodul med brukernavn og passord. Det er også meningen at forskjellige brukere har forskjellige rettigheter. For eksempel at den som legger inn data om et firma eller en person eier denne Modul 2, Brukerkontroll Modul for å legge inn, endre eller slette data fra databasen Modul 3, Søke etter data Modul for å søke etter visse kriterier i databasen Modul 4, Presentasjon av data Oversiktelig presentasjon av registrerte data Modul 5, Opplasting av dokumenter Informasjonsflyten mellom ez Systems og kunde ønskes lagret i databasen. 6.2 Forslag Modul 1, Pålogging Av sikkerhetsmessige hensyn ønskes det en påloggingsmodul med brukernavn og passord. Det er også meningen at forskjellige brukere har forskjellige rettigheter. For eksempel at den som legger inn data om et firma eller en person eier denne Modul 2, Brukerkontroll Modul for å legge inn, endre eller slette data fra databasen. Copyright 20 00, gruppe DV Side 17 av 33

18 6.2.3 Modul 3, Søke etter data Modul for å søke etter visse kriterier i databasen. Resultatet av søket legges inn i modul 4, slik at bruker kan velge dersom det er flere treff Modul 4, Treffliste Treffliste med resultater fra søk i databasen Modul 5, Presentasjon av data Oversiktelig presentasjon av registrerte data Modul 6, Opplasting av registrerte data. Informasjonsflyten mellom ez Systems og kunde ønskes lagret i databasen. 6.3 Forslag Modul 1, Pålogging Av sikkerhetsmessige hensyn ønskes det en påloggingsmodul med brukernavn og passord. Det er også meningen at forskjellige brukere har forskjellige rettigheter. For eksempel at den som legger inn data om et firma eller en person eier denne Modul 2, Legge inn data Egen modul der bruker kan legge inn nye data i databasen Modul 3, Endre eksisterende data Modul for å endre eksisterende data i databasen Modul 4, Slette data Modul for å slette data fra databasen Modul 5, Søke etter data Modul for å søke etter data i databasen. Copyright 20 00, gruppe DV Side 18 av 33

19 6.3.6 Modul 6, Presentasjon av søk Modul som viser resultat av søk i databasen Modul 7, Presentasjon av valgte treff fra søk Det valgte treffet fra søket presenteres. Her kan det være valgmuligheter for hva som ønskes å gjøre med dataene Modul 8, Enkel presentasjon av innlagte data Oversiktelig presentasjon av registrerte data Modul 9, Opplasting av dokumenter Informasjonsflyten mellom ez Systems og kunde ønskes lagret i databasen. Dette er kun en foreløpig oversikt over antatte moduler i systemet. Disse vil kunne bli delt opp i mindre funksjonelle moduler etter hvert som vi får en bedre oversikt over hva som er mest hensiktsmessig. Copyright 20 00, gruppe DV Side 19 av 33

20 6.4 Analyse av utviklingsmodeller Det finnes i dag en rekke forskjellige utviklingsmodeller for gjennomføring av prosjekter. Vi skal i denne delen av forstudiet se på en del eksempler, og gjøre vurderinger av hver modell. Det som er viktigst for oss, er å finne en prosjektmodell som samsvarer best med prosjektgruppens oppgave, dead-line og kvalifikasjoner Vannfallsmodellen DOD-2167 Dette er den klassiske utviklingsmodellen, og den ble utviklet for det amerikanske forsvardepartementet. Dette er en sekvensiell modell. Her blir hvert steg i prosessen gjrt helt ferdig, og muligheten for redesign er ikke til stedet. Fig Vannfallsmodell Definering av krav Planlegging Utvikling av testspek Design Realisering Systemtest Bruk og vedlikehold Kommentar: Denne modellen er veldig grei og forholde seg til (teoretisk), og den er konkret. Problemet er at vi i prosjektgruppen skal bevege oss inn på ukjent territorium. Muligheten for eventuell redesign av de forskjellige fasene er derfor et krav vi stiller til utviklingsmodellen. Samtidig så er vi avhengige av at alle på gruppen har noe å gjøre fra starten av, og går ikke med denne modellen. Copyright 20 00, gruppe DV Side 20 av 33

21 6.4.2 Vannfallsmodellen med tilbakemelding DOD-2167a Det som er spesielt i denne modellen, er du kan gjøre tilbakeløp i en hvilke som helst fase i modellen. Dette betyr at du kan gå tilbake og redesigne f.eks kravspesifikasjen hvis det skulle vise seg å være nødvendig. Definering av krav Planlegging Utvikling av testspek Design Realisering Systemtest Bruk og vedlikehold Fig Vannfalsmodell med tilbakeløp Antall blokker som er med i diagrammene kan var iere mye. Kommentar: Her står man veldig fritt. Fordelen er at man kan redsigne når og hvor som helst. Ulempene blir derfor at spesielt planlegging kan bli slapp, og at graden av frihet kan medføre at prosjektet ikke blir ferdig i tide. Copyright 20 00, gruppe DV Side 21 av 33

22 6.4.3 Evolusjonær utvikling Denne metoden går ut på å lage en enkel versjon av produktet. Denne versjonen blir så brukt i det videre arbeidet. Dette finnes to typer utviklingsmodeller for hvordan dette enkle produktet skal utvikles videre Inkrementell utvikling I denne modellen så bygges et og et modul av gangen, helt fram til konstruksjonsfasen. Når man kommer hit, så er det vanlig å realisere de viktigste/vanskeligste kravene først og teste disse. Når dette er gjort, så går man tilbake og gjentar syklusen med noen flere krav (med lavere prioritet) helt til man er ferdig. ProsjektIdé Forstudie Spesifikasjon Planlegging Konstruksjon Realisering Systemtest Ferdig? Etteranalyse Kommentar: Vedlikehold Fig Inkrementel modell Dette er en modell som på veldig mange områder samsvarer med vår prosjektoppgave. Implementasjon av noen få krav om gangen vil gjøredet letter for oss å fokusere på det vi driver med (får delt opp kravene i mindre mengder). Muligheten for tilbakeløp i konstruksjonsfasen er også en fordel. Copyright 20 00, gruppe DV Side 22 av 33

23 Prototyping: Kast og lag ny utviklingsmetode Kort forklart så går denne modellen med at du lager en enkel kravspesifikasjon. Deretter lages en prototype som er basert på kravspesifikasjonen. Lærdommen som vi nå har skaffet oss brukes til å lage en ny og (forhåpentligvis) bedre kravspesifikasjon som blir til et enda bedre produkt. Slik forsetter en til en er fornøyd. ProsjektIdè Forstudie Spesifikasjon Planlegging Konstruksjon Realisering Systemtest Ferdig? Etteranalyse Vedlikehold Fig Prototyping Kommentar: Dette virker i utgangspunktet som en tidskrevende prosess da man gjennomgår hele prosjektet flere ganger. Med tanke på den fastsatte dead-linen vi har, så vil dette være en vanskelig løsning. Det positive her, er at muligheten for å ende opp med et bra sluttprodukt er stor. Copyright 20 00, gruppe DV Side 23 av 33

24 6.4.4 Spiral Spiralmodellen bygger på at risikoanalyse skal gjennomføres med jevne mellomrom i løpet av prosjektet. Modellen tegnes som en spiral som består av fire kvadranter. 1. Planlegging Kartlegge alternative løsninger og finne begrensninger. 2. Risikoanalyse Analysere løsninger og gjøre valg. 3. Jobbe Konstruere, realisere og teste den delen av prosjektet som vi nå har planlagt. 4. Evaluere Evaluering av neste produktnivå. Fig Spiralmodell Kommentar: Ligner mye på Prototyping,. Copyright 20 00, gruppe DV Side 24 av 33

25 6.4.5 Top down Denne modellen deler opp aktivitetene i prosjektet i et hierarki. Når man har gjort dette, så gjør man først ferdig de underordnede aktivitetene. Når dette er gjort, så vil også den overordnede aktiviteten være gjort. Et annet poeng er at det er viktig å alltid gå løs på de vanskeligste aktivitetene/problemene først, og ta de lette til slutt. For vær aktivitet som gjennomføres (d.v.s aktiviteter på nederst nivå i hierarkiet), gjøres det slik: Krav Konstruksjon Realisering Test. Kommentar: Kan bli litt vanskelig å identifisere hvor de største utfordringene ligger da en del av det vi skal bruke av verktøy foreløpig er nytt for oss Grunnlinje styring (Baseline management) Grunnlinje modellen er basert på bruk av f.eks vannfallsmodellen. Man tar så å deler prosjektet opp i deler, og kontrolerer at disse aktivitetene blir gjennomført. Hvis vi har de fire fasene Krav, Konstruksjon, Realisering og Test så skal følgende gjøres. 1.Etablere på slutten av hver av de fire delene over Milepæler Dokumenter Gjennomganger 1. Etablere en grunnlinje med periodisk intervall. 2. Bruke konfigurasjonsstyring for å kontrollere grunnlinjen Objektorientert prosjektmodell Det finnes mange objektorienterte prosjektmodeller, og felles for dem alle er at de deler opp problemområdene i klasser og objekter. I en slik modell er det vanlig å gjenomgå en rekke punkter for hver iterasjon. 1. Kravanalyse Jobber sammen med kunden for å finne ut hva det ferdige systemet skal gjøre. Bruker use case r for å gjøre kommunikasjon med kunde lettere. 2. Analyse Finne ut hvilke klasser og objekter som er i problemområdet. Du skal vise og forstå sammenhengen mellom disse klassene. Copyright 20 00, gruppe DV Side 25 av 33

26 3. Design Gjøre analysen om til en teknisk løsning. Komme fram til en detaljert spesifikasjon av klassene og objektene. 4. Konstruksjon Klassene skal gjøres om til kode i et objektorientert programmeringsspråk. 5. Test Skal her sjekke at alle kravene er oppfylt Hacking modellen (Adhoc) Denne modellen blir som regel brukt på små og ukompliserte prosjekter som en liten laboppgave eller et regnestykke. Med andre ord så begynner man rett på oppgaven uten å forberede seg. Kommentar: Prosjektstyringsdelen er 50% av prosjektet, og det har vi ikke råd til å kaste bort. Copyright 20 00, gruppe DV Side 26 av 33

27 6.4.9 Unified Process Dette er en utviklingsmodell som bruker UML som modelleringsverktøy. Unified Process (UP) er Iterativ og incrementel Use case basert Arkitektur sentrert UP er en modell der mange av fasene (analyse, design etc) overlapper hverandre i tid. Det betyr at man så godt som hele tiden vil få en videreutvikling av f. eks kravspesifikasjonen.. På denne måten blir de forskjellige fasene i prosjektet automatisk oppdatert av hverandre slik at man for en gjevn og stabil utvikling i prosjektet. Core Workflows Requirements Analysis Iterations and Workflow Phases Inception Elaboration Construction Transition An Aniteration in inthe elaboration phase Design Implementation Test Test P re relim limin ina ry ry Ite Itera ratio tion (s) (s) iter. iter. # 1 ite iter. r. # 2 ite iter. r. # n ite iter. r. # n ite iter. r. # n iter. iter. # m ite iter. r. #m #m IIte tera ratio tions ns Figur Unified Process Som figuren viser så har vi fire faser langs tidsaksen. 1. Inception Phase (start fasen) Definenerer mål og visjon for prosjektet. Vil prosjektet lønne seg? Skal prosjektet startes eller ikk startes 2. Elaboration Phase (forarbeid fase) Planlegge fremtidige aktiviteter Spesifisere krav Definere høyest Software arkitektur Copyright 20 00, gruppe DV Side 27 av 33

28 3. Construction phase (konstruksjon) Delt opp mange iterasjoner Koding og testing av produkt 4. Transition Phase (overgangs fase) Forbruker overtar produktet Slipp av mk I, mk II utgaver etc. Fasen er over når forbruker er fornøyd med produktet Kommentar: Da vi lærer om UML paralellt med starten av prosjektet, så er dette en fordel. Samtidig så gjør Unified Process det mulig for samtlige på gruppen til å begynne å arbeide med sine respektive ting med en gang. Parallelliteten vil også tvinge gruppen til å jobbe mere sammen for å få de forskjellige fasene samkjørt. 6.5 Konsekvensanalyse Konsekvenser ved å starte prosjektet Vi vil få kjennskap til UML, databaser (MySQL), og intranett programering (PHP, HTML). Vi vil få erfaring med å utvikle et software-prosjekt for en kunde, og dokumentering av dette. ez systems vil få et produkt som vil kunne forbedre kundekontakten. ez systems vil få et program som vil holde rede på kundekontakter og interne notater om kunden. ez systems vil få en oversikt over hvem som har arbeidet med en problemstilling iforhold til en kunde Konsekvenser ved ikke å starte prosjektet Dersom prosjektet ikke startes, er det for sent å begynne på et nytt prosjekt. ez-systems vil ikke få den applikasjonen de ønsker fra oss. Vi vil gå glipp av mye kunnskap og erfaring i forbindelse med prosjektstyring, se problemstillinger, komme med ideer, tenke brukervennlighet, modellering av design og realisere et software-prosjekt. Copyright 20 00, gruppe DV Side 28 av 33

29 7 En oppdeling i hoved aktiviteter, med målformuleringer for hver aktivitet 7.1 Hovedaktiviteter Vi har valgt en inkrementell og iterativ modell med unntakav vedlikeholdsfasen, da denne ikke er en del av et studentprosjekt. Her følger fasene i prosjektet, samt de dokumenter som vil utarbeides i hver enkelt fase: Prosjektidé ProsjektIdeDokument Forstudie Forstudiedokument Spesifikasjon Kravspesifikasjonsdokument, Testspesifikasjonsdokument Planlegging Prosjektplan Konstruksjon KonstruksjonsDokument Realisering RealiseringsDokument Etteranalyse EtteranalyseDokument 7.2 Målformuleringer Grov aktivitetsfordeling Tidspunkt når de forskjellige fasene skal være gjennomført er angitt i Gantt diagrammet i Vedlegg Prosjektidéfasen Prosjektidéfasen har som mål å utarbeide et prosjektidédokument. Dette dokumentet inneholder blant annet målet med prosjektet, og i korte trekk hva prosjektet går ut på Forstudiefasen Forstudiefasen har som mål å utarbeide et forstudie dokument. Dette dokumentet inneholder blant annet en analyse av prosjektet, en ikke-detaljert plan for hele prosjektet, og en delvis detaljert plan for spesifikasjonsfasen og planleggingsfasen Spesifikasjonsfasen Spesifikasjonsfasen har som mål å utarbeide et kravspesifikasjons dokument og et testspesifikasjons dokument. Det første dokumentet inneholder krav til systemet, og det andre dokumentet inneholder beskrivelse av tester som skal bevise om kravene i kravspesifikasjonen er nådd eller ikke. Copyright 20 00, gruppe DV Side 29 av 33