prospect explorer 2.0 hovedprosjekt...

Prospect Explorer 2.0 Hovedprosjekt 2011

1


2


3

HOVEDPROSJEKT 2011

HOVEDPROSJEKTETS TITTEL

Prospect Explorer 2.0

DATO

30.05.2011

ANTALL SIDER / BILAG

135

PROSJEKTDELTAKERE

Tomas Magnussen (s156180) André Søberg (s155470) Thomas Norén (s156154)

Stian Bay (s155495) Bjørn Thoresen (s155477)

INTERN VEILEDER

Geir Skjevling

OPPDRAGSGIVER

Unit4 Agresso

KONTAKTPERSON

Kjetil Smith, Anders Hauan

SAMMENDRAG

Oppgaven har gått ut på å utvikle ett program som skal sortere og organisere prospekter for

selgerne i Unit4 Agresso.

Applikasjonen er utviklet ved hjelp av MS ASP.NET, C#, HTML, Javascript, AJAX, CSS og SQL.

3 STIKKORD

Microsoft .NET

C#

Web-applikasjon

Studieprogram:Informasjonsteknologi/Ingeniør

Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Besøksadresse: Holbergs plass, Oslo

PROSJEKT NR.

20

TILGJENGELIGHET

Åpen

Telefon: 22 45 32 00

Telefaks: 22 45 32 05


4

Produktdokumentasjon .................................................................................. 11

Innledning ................................................................................................................................. 13

Rammebetingelser ............................................................................................................... 13

Prosjektets mål ..................................................................................................................... 13

Sammendrag av kravspesifikasjon ....................................................................................... 13

Teknologi .................................................................................................................................. 14

SQL-database ........................................................................................................................ 14

Visual Studio 2010 ................................................................................................................ 14

C# .......................................................................................................................................... 14

Beskrivelse av programmet ...................................................................................................... 14

Lagdeling............................................................................................................................... 14

Presentasjonslaget (PE_Web) .............................................................................................. 15

Programlogikk (BLL) .............................................................................................................. 16

Dataaksesslaget .................................................................................................................... 16

Model ................................................................................................................................... 17

Klasser .................................................................................................................................. 18

PE_Web ............................................................................................................................ 18

BLL .................................................................................................................................... 20

Dal ..................................................................................................................................... 22

Model ............................................................................................................................... 23

Enhetstest ......................................................................................................................... 24

Master Pages .................................................................................................................... 24

LINQ – Language Integrated Query .................................................................................. 25

Sentrale datastrukturer .................................................................................................... 25

Hovedprogram ......................................................................................................................... 27

GUI ........................................................................................................................................ 27

Sikkerhet ............................................................................................................................... 28

Passord sniffing ................................................................................................................ 28

SQL-injection .................................................................................................................... 28

Cross Site Scripting (XSS) .................................................................................................. 29

Utvidelsesmuligheter ........................................................................................................... 29

Dokumentasjon .................................................................................................................... 29

Konklusjon ............................................................................................................................ 29


5

Prosessdokumentasjon ................................................................................... 31

Forord ....................................................................................................................................... 32

Innholdsliste ............................................................................................................................. 33

Innleding ................................................................................................................................... 36

Bakgrunn for prosjektet ....................................................................................................... 36

Bakgrunn for oppgaven ........................................................................................................ 36

Oppgavens mål og rammebetingelser ................................................................................. 36

Begrensinger......................................................................................................................... 37

Planlegging og metode ............................................................................................................. 37

Hvordan starte? .................................................................................................................... 37

Prosessmetode ..................................................................................................................... 37

Fremdriftsplan ...................................................................................................................... 37

Arbeidsplan .......................................................................................................................... 37

Gruppemøter ........................................................................................................................ 38

Dokumentstyring .................................................................................................................. 38

Prosjekthjemmeside ............................................................................................................. 38

Møtelogg/Arbeidslogg.......................................................................................................... 38

Dialoger med arbeidsgiver og veileder ................................................................................ 38

Anvendt programvare .............................................................................................................. 39

Visual Studio 2010 ................................................................................................................ 39

VMware ................................................................................................................................ 40

MS SQL Server R2 2010 ........................................................................................................ 40

Firefox ................................................................................................................................... 40

Firebug .................................................................................................................................. 40

Skype .................................................................................................................................... 40

Mumble ................................................................................................................................ 40

Valg ........................................................................................................................................... 41

Programmeringsspråk .......................................................................................................... 41

Layout på web-app ............................................................................................................... 41

Database og database-oppkobling ....................................................................................... 41

Lagdeling............................................................................................................................... 42

Meny ..................................................................................................................................... 42

Visning av prospekter ........................................................................................................... 42

Håndtering av objekter ........................................................................................................ 43

Ajax Control Toolkit .............................................................................................................. 43


6

Web Service .......................................................................................................................... 44

Hva måtte vi lære? ................................................................................................................... 44

Arbeidsmåter ............................................................................................................................ 45

Om utviklingsprosessen ........................................................................................................... 46

Forberedelser ....................................................................................................................... 46

1) Kravspecc.......................................................................................................................... 46

2) Basic oppsett av GUI ........................................................................................................ 46

3) Lagdeling & metodeplanlegging ...................................................................................... 47

4) Grov oppbygning av skjelett ............................................................................................ 47

5) Databaser opp .................................................................................................................. 47

6) Oppstart programmering ................................................................................................. 47

7) Sammenkobling av DAL til BLL ......................................................................................... 48

8) Hovedsiden kommer til liv ............................................................................................... 48

9) Excel eksportering ............................................................................................................ 48

10) Programmet tar form ..................................................................................................... 49

11) Overgang til XML-dokumentasjon ................................................................................. 49

12) Budsjett og prognose våkner til liv ................................................................................. 49

13) Skjule/vise unødvendig informasjon .............................................................................. 49

14) Dropdown lister og filtrering .......................................................................................... 50

15) Implementering av AjaxToolkit ...................................................................................... 50

16) Budsjett og Prognose fullføres ....................................................................................... 50

16) Statusfelt ........................................................................................................................ 51

17) Redigere eksisterende settings ...................................................................................... 51

18) Validering på settings ..................................................................................................... 51

19) Admin blir implementert ............................................................................................... 52

20) Fikse småbugs ................................................................................................................ 52

Kravspesifikasjonen og dens rolle ............................................................................................ 53

Endringer .............................................................................................................................. 53

Samsvar mellom spesifikasjon og produkt ........................................................................... 53

Om resultatet ....................................................................................................................... 53

Avslutning og konklusjon ......................................................................................................... 53

Hva har vi lært ...................................................................................................................... 54

Gruppen ................................................................................................................................ 54

Hva ville vi gjort annerledes? ............................................................................................... 54

Fremtiden ............................................................................................................................. 54


7

Testdokumentasjon ............................................................................................ 56

Forord ....................................................................................................................................... 57

Tids- og Resursplan for testing ................................................................................................. 59

Intern testing ........................................................................................................................ 59

Ekstern testing ...................................................................................................................... 59

Tidsplanen ............................................................................................................................ 59

Intern testing ............................................................................................................................ 59

Testprosessen ....................................................................................................................... 59

Testrapporter ....................................................................................................................... 59

Test av funksjonalitet ....................................................................................................... 60

Ytelsestester ..................................................................................................................... 65

Nettleser test .................................................................................................................... 68

Sikkerhet ................................................................................................................................... 70

Passord sniffing .................................................................................................................... 70

SQL-injection ........................................................................................................................ 70

Cross Site Scripting (XSS) ...................................................................................................... 70

Konklusjon ................................................................................................................................ 71

Brukerdokumentasjon .............................................................................................................. 72

Forord ....................................................................................................................................... 73

Installasjon................................................................................................................................ 75

Funksjonskart ........................................................................................................................... 76

Gridview ............................................................................................................................... 77

Treeview ............................................................................................................................... 77

Menylinje .............................................................................................................................. 77

Brukerveiledning ...................................................................................................................... 78

Tilgang og roller .................................................................................................................... 78

Innlogging ............................................................................................................................. 78

Hjem vindu ........................................................................................................................... 79

Settings ................................................................................................................................. 80

Instruksjon for Selger/Salgsleder ......................................................................................... 84

Oppdater prospekt ........................................................................................................... 84

Legge til ny selger ............................................................................................................. 84

Tree-view .......................................................................................................................... 84

Grid-view .......................................................................................................................... 85


8

Kravspesifikasjon ................................................................................................... 86

Forord ....................................................................................................................................... 87

1 Leseveiledning ............................................................................................................... 89

2 Innledning ......................................................................................................................... 90

2.1 Om bedriften ............................................................................................................. 90

2.2 Bakgrunn for prosjektet ............................................................................................. 90

2.3 Dagens situasjon ........................................................................................................ 90

3 Krav ................................................................................................................................... 91

3.1 Funksjonelle krav ....................................................................................................... 91

3.1.1 Bruker/Selger krav .............................................................................................. 91

3.1.2 Administrator/Leder krav ................................................................................... 91

3.1.3 Brukstilfeller (Use-Case Model) – Oversikt ....................................................... 91

3.1.4 Forutsetninger og avhengigheter ....................................................................... 93

3.1.5 Detaljert beskrivelse av utvalgte Use Case ........................................................ 93

3.2 Ikke – funksjonelle krav ........................................................................................... 105

3.2.1 Tekniske krav .................................................................................................... 105

3.2.2 Krav til sikkerhet ............................................................................................... 105

3.2.3 Krav til brukervennlighet og design ................................................................. 105

3.2.4 Krav til vedlikeholdbarhet og videreutvikling .................................................. 105

4 Dokumentasjon .............................................................................................................. 106

Vedlegg- Databaseforklaring .................................................................................................. 107

Branch................................................................................................................................. 107

Databases ........................................................................................................................... 107

Department ........................................................................................................................ 107

DepartmentBudget ............................................................................................................ 108

Modules .............................................................................................................................. 108

Prospect .............................................................................................................................. 108

ProspectStatus .................................................................................................................... 110

SalesBudget ........................................................................................................................ 110

SalesPerson ........................................................................................................................ 110

SaleType ............................................................................................................................. 110

Source ................................................................................................................................. 111

Vedlegg - Database CREATE scripts ........................................................................................ 112

Branch................................................................................................................................. 112

Databases ........................................................................................................................... 112


9

Department ........................................................................................................................ 113

DepartmentBudget ............................................................................................................ 113

Modules .............................................................................................................................. 115

Prospect (Innhold er begrenset til en enkelt linje grunnet størrelse) ............................... 116

ProspectStatus .................................................................................................................... 118

SalesBudget ........................................................................................................................ 118

SalesPerson ........................................................................................................................ 119

SalesType ............................................................................................................................ 121

Source ................................................................................................................................. 121

Titles ................................................................................................................................... 122

IIS – Internet Information Services (IIS) ................................................................................. 123

Brukerveiledning ................................................................................................................ 123

1. Installere IIS Manager ................................................................................................. 123

2. Åpne IIS Manager ....................................................................................................... 125

Kilder................................................................................................................................... 129

Ordforklaringer ....................................................................................................................... 130

Kildehenvisninger ................................................................................................................... 133


10


11

Produktdokumentasjon

Under produktdokumentasjon vil du finne dokumentasjon som forklarer oppbygning og

struktur av programmet.


12

Innholdsliste Innledning ................................................................................................................................. 13

Rammebetingelser ............................................................................................................... 13

Prosjektets mål ..................................................................................................................... 13

Sammendrag av kravspesifikasjon ....................................................................................... 13

Teknologi .................................................................................................................................. 14

SQL-database ........................................................................................................................ 14

Visual Studio 2010 ................................................................................................................ 14

C# .......................................................................................................................................... 14

Beskrivelse av programmet ...................................................................................................... 14

Lagdeling............................................................................................................................... 14

Presentasjonslaget (PE_Web) .............................................................................................. 15

Programlogikk (BLL) .............................................................................................................. 16

Dataaksesslaget .................................................................................................................... 16

Model ................................................................................................................................... 17

Klasser .................................................................................................................................. 18

PE_Web ............................................................................................................................ 18

BLL .................................................................................................................................... 20

Dal ..................................................................................................................................... 22

Model ............................................................................................................................... 23

Enhetstest ......................................................................................................................... 24

Master Pages .................................................................................................................... 24

LINQ – Language Integrated Query .................................................................................. 25

Sentrale datastrukturer .................................................................................................... 25

Hovedprogram ......................................................................................................................... 27

GUI ........................................................................................................................................ 27

Sikkerhet ............................................................................................................................... 28

Passord sniffing ................................................................................................................ 28

SQL-injection .................................................................................................................... 28

Cross Site Scripting (XSS) .................................................................................................. 29

Utvidelsesmuligheter ........................................................................................................... 29

Dokumentasjon .................................................................................................................... 29

Konklusjon ............................................................................................................................ 29


13

Innledning Prospect Explorer 2.0 skal være ett hjelpemiddel til selgere ved Unit4 Agresso AS. Der skal de kunne legge inn prospekter over mulige salg de har (Lønningssystemer/lisenser/service/vedlikehold/oppgradering osv). Prospektene har også en sannsynlighetsvariabel for salg i prosent. Etter hvert som de blir godkjent eller avslått setter selgeren denne variabelen i programmet. Selgere har også forventede kvartal-budsjetter de skal nå.

På den vedlagte CD-en finner du instrukser på hvordan å kjøre web-applikasjonen lokalt, men applikasjonen vil også ligge ute på denne adressen: http://dotnet.iu.hio.no/s155495/

Rammebetingelser Det skal ikke koste noe for oppdragsgiveren, skolen eller gruppen å utvikle det nye systemet. Det eneste oppdragsgiveren har ansvar for er å gi oss på gruppen den informasjonen vi er avhengig av for å komme i mål med oppgaven.

Prosjektgruppen har hele vårsemesteret 2011 til å utvikle systemet. Den endelige innleveringsfristen er 31.mai 2011.

Prosjektets mål All informasjon legges i en SQL-database, der brukere, avdelinger og prospekter skal kunne legges inn og redigeres. Dersom noe skal slettes må admin gjøre dette manuelt. Informasjonen som ligger lagret i databasen skal brukes til bl.a.:

Beregne/estimere kvartalresultater og årsresultater for alle selgerne

Huskeliste for selgere, hente fram alle kunder som de har/nesten har

Sjekke hvilke kunder andre selgere allerede har kontaktet

Salgssjefer kan holde øye med selgeres progresjon

Arkiv for alle salg som er gjort hos Unit4 Agresso

Sammendrag av kravspesifikasjon Det nye systemet skulle være nettbasert og virke som en intranettside. Gruppen kunne designe brukergrensesnittet som vi selv ønsket, men det skulle være brukervennlig.

Prosjektet gikk ut på å utvikle ett program som viser oversikt over selgeres prospekter, forventede inntekter, sannsynlighetsberegninger for om salg går inn, og generelt alle oversikter om forventede kvartal inntekter, utgifter, salg osv.

http://dotnet.iu.hio.no/s155495/


14

Teknologi

SQL-database Gammelt system benytter SQL-databasen, og vårt program skal støtte samme database. Vi har satt opp databasen på HiO-serveren. Dette er en relasjonsdatabase der dataene er organisert i tabeller.

Visual Studio 2010 Visual Studio er Microsofts utviklingsverktøy for utvikling av programmer. VS2010 støtter utvikling av desktop-applikasjoner, web applikasjoner og web services som kjøres på alle Microsoft plattformer med .NET Framework.

Høgskolen tilbyr Visual Studio, og dette benyttes også i Agresso.

C# Vi bruker C# da dette er standardspråket (i tillegg til C++) hos Agresso. Vi har også god erfaring med C# fra tidligere fag. C# har også likhetstrekk med java.

C# (C Sharp) er en videreutvikling av C og C++. C# gir mindre kodemengde fordi det tilbys ett stort klassebibliotek med ferdiglagde metoder.

Beskrivelse av programmet

Lagdeling Vi har valgt en 4–delt programstruktur med et presentasjonslag (GUI), objektlag (Model), virksomhetslag (BLL) og dataaksesslag (DAL). Hensikten med denne lagdelingen er å skille brukergrensesnittet, objekter, virksomhetsregler og datakilde fra hverandre. På denne måten blir det lettere for både oss og andre å holde oversikten i utviklingsprosessen og med tanke på gjenbruk og videreutvikling av kildekoden.


15

Figuren viser hvordan de forskjellige lagene i systemet vårt er koblet sammen:

Presentasjonslaget (PE_Web) Dette er det øverste laget som kommuniserer med sluttbrukeren (GUI/View). Her er systemets brukergrensesnitt. Hensikten med dette laget er å presentere data fra virksomhetslaget på en måte slik at det er forståelig for sluttbruker. Laget har også som ansvar å videresende inputdata fra sluttbrukeren til virksomhetslaget.

Her ligger blant annet CSS – filene samt Site.Master. Site.Master er en Masterpage som inneholder en mal som alle .aspx filene følger. Dette gjør at hele applikasjonen har samme stil og gjør at når man går til

en annen side så endres kun en bestemt del av siden. Dette gjøres for at sluttbruker skal få en følelse av at det er samme applikasjon, men med forskjellig innhold.

CSS – filene som her ligger i mappen "Styles" er filene som bestemmer utseende på siden. Her endrer man for eksempel til ønsket farge på siden og bestemmer utseende til selve applikasjonen.

Figur 1 Hentet fra F8 Lagdeling v2.ppt av Tor Krattebøl


16

De forskjellige .aspx filene er selve innholdet på siden som sluttbrukeren kan manøvrere seg i.

Programlogikk (BLL) Brukes av: Presentasjonslaget

Bruker: DAL og Model

BLL, eller Business Logic Layer håndterer all logikken i programmet, som f.eks. å motta og validerer data som sendes fra presentasjonslaget. Dette laget inneholder også bestemte regler for å gjennomføre valideringen. Laget fungerer som en slags mellomstasjon mellom presentasjonslaget og dataaksesslaget. Virksomhetslaget

henter blant annet informasjon fra dataaksesslaget og videresender informasjonen til presentasjonslaget.

Vi har dyttet ut logikken fra presentasjonslaget fordi vi får mye av data-logikken tilgjengelig for gjenbruk dersom den skal brukes flere steder/ganger. Dette fører til mindre repetisjon av kode. Det er også hensiktsmessig med dette laget dersom programmet skal porteres/gjøres tilgjengelig andre steder enn en webapplikasjon (Eneste som trenger reprogrammering er presentasjonslaget). Her kan f.eks. desktop- og mobilapplikasjon nevnes.

Dataaksesslaget (DAL) Brukes av: BLL

Bruker: Model

DAL, eller Data Access Layer håndterer alle spørringer mot databasen i form av metoder. Disse klassene mottar ett knippe parametere, putter de inn i en SQL-query, kommuniserer med databasen, mottar resultat fra databasen og returnerer dette til BLL som oftest i form av en resultatliste av respektivt objekt.


17

Eksempel:

Denne metoden endrer en linje i Modules – tabellen.

1) Metoden mottar ett objekt av typen Mmodule. 2) Linq henter så ut linjen med modulens id for endring (db.Modules.Single(...)). 3) Feltene i tabellen endres, og endringer skrives til databasen (db.SubmitChanges();). 4) Dersom linjen er endret returneres true til BLL, ellers returneres false.

Model Dette laget inneholder klasser som fungerer som objekter. Disse brukes til å transportere større mengder informasjon mellom de ulike lagene. Dette er hensiktsmessig når vi skal hente mange tusen linjer fra databasen. Som også er nevnt i prosessdokumentasjonen, dette gjør at programmeringen blir mer selvforklarende etter man har satt seg inn i koden. Det er tross alt lettere å skjønne betydningen av MUser.Name fremfor user[3] (arrayliste som itereres gjennom). Vi tror også dette vil forhindre en god del slurve-feil (Name/Username osv. sier mer om hvilken informasjon som skal hentes enn 1/2/3/4).


18

Klasser Her vil du få en kort beskrivelse av hva de ulike klassene og .aspx-sidene brukes til. Dette vil forhåpentligvis gi deg en oversikt over hvordan programmet er strukturert, og hvilke filer som brukes i hvilke sammenhenger.

PE_Web PE_Web er det grafiske brukergrensesnittet (GUI). Som nevnt tidligere inneholder dette laget alt design og oppsett av sider. Her ligger bilder, CSS-filer og .aspx-sider med sine respektive .cs-filer.

Site.Master Site.Master er hovedsiden. Denne filen inneholder Toppmenyen, tremenyen på venstre side, hovedinnholden (variert innhold ut ifra hvilken .aspx side som er valgt), og footeren som inneholder statusfeltet.

Hver gang brukeren åpner en .aspx-side vil denne ha Site.Master “rundt” seg.

Login og programstart Default.aspx/.cs – Denne siden er startsiden for hele applikasjonen. Dette er en tom side som enten sender deg videre til login dersom du ikke er logget inn, eller GridView dersom du er logget inn.

Login.aspx/.cs – Dette er login-siden som kun består av brukernavn og passordfelt med en logg-inn knapp.

De tre hovedsidene Vi har tre sider som utgjør hovedfunksjonaliteten i programmet. Dette er sidene vi kan nå fra nedtrekkslisten øverst på siden:

Budsjett.aspx/.cs – Denne siden viser oversikt over valgt budsjett. Hva som vises, bestemmes ut ifra hva man har valgt i nedtrekksmenyen for år, i tillegg til hva man har valgt i tremenyen. Eksempler på bruk er selgere/salgsledere som skal sjekke hvor mye en selger eller avdeling har i budsjett. Gridview.aspx/.cs – Her vises en tabell som inneholder prospekter. Hva som vises her bestemmes også ut ifra hva man har valgt som år og i tremenyen. Eksempler på bruk er selger/salgsleder som viser prospekter.

Prognose.aspx/.cs – Her vises en kalkulering av prospect-salg (igjen bestemt ut ifra år og tremeny) som er gjort for gitt år. Her hentes informasjon fra databasen, og kalkuleres kvartalvis i fem felter:

Virkelig – viser beløp selger/avdeling HAR solgt for

Prospect – viser beløp selger/avdeling HAR MULIGHET til å selge for

Sum – Sum av Virkelig og Prospect


19

Budsjett – viser budsjettet for selger/avdeling

Avvik – Viser differansen mellom sum og budsjett, og forteller hvor mye dette viker fra selger/avdelings årsbudsjett.

Error Error.aspx/.cs – Dette er en feilside som viser bl.a. StackTrace. Denne har vi noen ganger benyttet oss av under testing, og valgte å beholde den i tilfelle videreutvikling av arbeidsgiver eller oss.

Settings Settings_main.aspx/.cs – Dette er hovedsiden for alle instillinger man kan foreta i programmet. Siden inneholder kun linker til alle sidene under.

Branch.aspx/.cs – Instillinger for Bransje. Her kan man Legge til, vise og endre hvilke bransjer ett prospect/salg ligger under. Bransje beskriver hvilket område bedriften el. opererer innenfor, f.eks. Shipping, Bank, Kommune, Helse osv.

Databases.aspx/.cs – Innstillinger for Databaser. Her kan man legge til, vise og endre hvilken database som skal brukes. Denne brukes ikke da Agresso benytter Microsoft, og web-applikasjonen da kommer til å spørre mot en MS SQL Server.

Department.aspx/.cs – Innstillinger for Avdelinger. Her kan man legge til, vise og endre informasjon om avdelinger. Avdelinger kan for eksempel være Privat, Offentlig, Danmark osv. Holder oversikten over hvilken avdeling de ansatte tilhører.

Modules.aspx/.cs – Innstillinger for Moduler. Her kan man legge til, vise og endre moduler. Moduler beskriver hva slags type salg det dreier seg om i prospektet. Her har vi innhold som bl.a. Økonomi, Time/Prosjekt, Verktøy og Lønn/Personal. Dette Gir en indikasjon på om det er økonomi-, timeregistrering- eller lønnings-systemer som skal selges til kunden.

Prospect.aspx/.cs – Innstillinger for prospekter. Her kan man se prospekter, endre og legge til. Et prospekt er aktiviteten, sett av institusjoner, og prosesser for å lage, kommunisere, levere og utveksle tilbud som har verdi for kunder, klienter, partnere og samfunnet.

ProspSC.aspx/.cs – Innstillinger for Prospekt Status koder. Her kan man legge til, vise og endre hvilke statuser et prospekt kan ha. Det kan for eksempel være Kunde, Prospekt eller Tapt.

Salestype.aspx/.cs – Innstilinger for forskjellige salgstyper et prospekt har. Her kan man legge til, vise og endre salgstyper. En salgstype er hva kunden har bestilt hos UNIT4 Agresso. Det kan være om det er Ny Kunde, Konsulenttjenester, Vedlikehold/Support eller om det for eksempel er forprosjekt.

Sources.aspx/.cs – Innstillinger for Kilder. Her kan man legge til, vise og endre Kilder. Et prospekt har en opprinnelse eller en oppstart som det hele starter med, dette kan for eksempel være Inngående telefon, Partner, forespørsel eller utgående telefon.

Users.aspx/.cs – Innstillinger for Brukere. Her kan man legge til, vise og endre brukere. Alle ansatte i salgsavdelingen er registrert her.


20

BLL Budsjett.cs – Her bygges tabellen for budsjett. Det er to forskjellige tabeller som bygges med hensyn på hvilken informasjon som mottas. Det kan lages en tabell om bruker og år er valgte parametere og en for avdeling og år som valgte parametere.

Figur 2 Utlipp fra Budsjett.cs

Metoden i figuren over bygger en tabell som sorterer med hensyn på valgt bruker og år.

Login.cs – Her blir passord kryptert, dvs at teksten som brukeren skriver i passordfeltet konverteres til en hash og lagres kryptert i databasen. Det sjekkes også at passordet som brukeren prøver å logge inn med stemmer overens med passordet som er lagret kryptert i databasen.

Figur 3 Utklipp fra Login.cs

Metoden i figuren over konverterer innkommende passord til en hash med MD5 Kryptering.


21

Prognose.cs – Her bygges tabellen for prognose. Dette gjøres på samme måte som i Budsjett.cs, ved hjelp av 2 forskjellige input – kriterier. Prognose sorteres da som nevnt over enten ved hensyn på bruker og år eller på avdeling og år.

Prospect.cs – Her er logikklagets legg til, vis og endre metoder for prospekter.

Figur 4 Utklipp fra Prospect.cs

Metoden i figuren over er en legg til metode for prospekt. Metoden lager et objekt av prospektinformasjonen via Dataaksesslaget og returnerer dette objektet. Ved å gjøre det på denne måten kan man endre selve SQL – kallene i dataaksesslaget uten å måtte lage hele metoden på nytt.

Settings.cs – Logikklagets legg til, vis og endre metoder for resten av funksjonaliteten. For eksempel legg til bruker, avdeling osv.

Figur 5 Utklipp fra Settings.cs

Metoden i figuren over lister ut alle avdelinger som er lagret i databasen. Metoden ligger i logikklaget og fungerer på samme måte som beskrevet i Prospect.cs.


22

Dal DB.dbml – DB.dbml er en LINQ to SQL klasse.

sqlLogin.cs – I denne filen sjekkes inntastet passord fra PE_WEB/Login.aspx mot databasen.

Figur 6 Utklipp fra sqlLogin.cs

Metoden over sjekker om inntastet logg inn – informasjon stemmer overens med brukernavn og passord i databasen. Samtidig sjekker den om brukeren har administrator rettigheter eller bruker rettigheter.

sqlProspect.cs – I denne filen ligger alle metodene for legg til og vis prospekter. Dette ligger i dataaksesslaget og derfor er alle SQL – spørringene mot databasen i denne filen. Her ligger og metoden for filtrering av prospekter med hensyn på år, disse prospektene returneres i en liste.

sqlSettings.cs – Her ligger alle metodene for legg til, vis og endre resten av funksjonaliteten. For eksempel brukere, avdelinger, kilder, statuskoder samt resten av databasene som skal kunne endres på.

Figur 7 Utklipp fra sqlSetting.cs


23

Metoden i figuren over er en rediger bruker metode. Metoden mottar ett bruker – objekt med en unik ID og oppdaterer informasjonen i databasen med informasjonen som metoden mottar. Det eneste som ikke endres er bruker ID som er konstant og unik.

Model I Model laget lages det objekter av verdiene som skal inn i databasen. Disse verdiene må stemme overens med kolonnene i databasen.

MBranch.cs – Her lages det et objekt av Branch med verdier som stemmer med verdiene som skal inn i databasen.

MBudsjett.cs – Her lages det et objekt av Budsjett med verdier som stemmer med verdiene som skal inn i tabellen på siden Budsjett.aspx i Pe_Web.

MDatabase.cs – Her lages det et objekt av Database med verdier som stemmer med verdiene som skal inn i databasen.

MDepartment.cs – Her lages det et objekt av Avdeling med verdier som stemmer med verdiene som skal inn i databasen.

MDepartmentBudget.cs – Her lages det et objekt av DepartmentBudget med verdier som stemmer med verdiene som skal inn i databasen.

MModule.cs – Her lages det et objekt av Module med verdier som stemmer med verdiene som skal inn i databasen.

MPrognose.cs – Her lages det et objekt av Prognose med verdier som stemmer med verdiene som skal inn i tabellen på siden Prognose.aspx i Pe_Web.

MProspect.cs – Her lages det et objekt av Prospect med verdier som stemmer med verdiene som skal inn i databasen.

MProspSC.cs – Her lages det et objekt av ProspectStatusCodes med verdier som stemmer med verdiene som skal inn i databasen.

MSalesBudget.cs – Her lages det et objekt av SalesBudget med verdier som stemmer med verdiene som skal inn i databasen.

MSalesType.cs – Her lages det et objekt av SalesType med verdier som stemmer med verdiene som skal inn i databasen.

MSource.cs – Her lages det et objekt av Kilde med verdier som stemmer med verdiene som skal inn i databasen.

MUser.cs – Her lages det et objekt av Bruker med verdier som stemmer med verdiene som skal inn i databasen.


24

Enhetstest Enhetstester er testing som verifiserer enkeltdeler i en applikasjon for seg. Tester du en funksjon isolert og ikke dens kommunikasjon med andre funksjoner eller objekter er det enhetstesting.

sqlProspectTest.cs – Her ligger programmets enhetstester.

Master Pages

Fremstilling av master pages hentet fra http://www.asp.net/guided-tour/s15.aspx

Master Pages gjør at vi får et konsistent utseende på sidene i applikasjonen vår. Den sørger for at ulike elementer på siden blir definert på samme måte gjennom hele applikasjonen. For å fylle master pagen med innhold bruker vi content placeholders. Disse fyller innholdet sitt innenfor de gitte områdene i master pagen.

http://www.asp.net/guided-tour/s15.aspx


25

LINQ – Language Integrated Query

Her ser vi et bilde av noen av tabellene vi finner i databasen vår

For å hente ut dataene fra databasen vår har vi brukt LINQ. Med LINQ lager vi klasser av de forskjellige tabellene i databasen. Vi kan da bruke innebygde metoder for å hente ut, endre og legge til data.

Sentrale datastrukturer Ajax Controll Toolkit er noe vi brukte mer og mer i Prospect Explorer, enten om det var en spesiell funksjon vi trengte eller om vi utvidet noen av de standard asp funksjonene som var i programmet.

Når vi skal bruke en av metodene i ajax controll toolkitet må vi først registrere prefixen på toppen av aspx siden - <%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="asp" %>

Når man skal bruke et eller flere toolkit elementer på siden kreves det først at du legger til en toolscript manager, det gjøres på flg måte: asp:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server"></asp:ToolkitScriptManager>

Etter at dette er gjort kan vi nå bruke alle de forskjellige verktøyene ajax controll toolkit. Et av verktøyene vi har brukt mye på siden er AccordionPane Dette er noe som erstatter vanlig asp panel slik at vi kan konfigurere det og det er også lagt til fine animasjoner som standard.


26

Vi bruker også vanlige asp paneler når vi skjuler header og menyen, og har i tillegg på disse panelene lagt til CollapsiblePanelExtender som igjen gir oss en fin animasjon og mulighet for å konfigurere panelets egenskaper mer. Ajax Controll Toolkit er et åpen kildekode prosjekt og det finnes en egen side fra AJAX med mange eksempler og fine videoer om hvordan man bruker toolkitet.

Update Panel, Collapsible Panel Extender, Accordion og Accordion Panel Extender er eksempler på hvor vi har brukt ajax for å få det til å få et bedre visuelt utseende og brukeropplevelse.

Accordion og Accordion Panel Extender brukes på omtrent alle sider. Det Accordion gjør er å utvide et vanlig asp panel. Isteden for Asp Panel bruker vi AccordionPane og en extender i tillegg. Dette gir oss en haug av forskjellige muligheter vi kan bruke på forskjellige paneler, ved å skjule et panel og vise et annet ved hjelp av gjevne animasjoner og egne css stiler. Hvis vi tar avdelinger (Department.aspx) som et eksempel må vi først legge til en referanse til ajax controll toolkitet som vi har lastet ned og knyttet dll filen opp mot prosjektet vårt. Denne referansen skal ligge i Refrences mappen i PE_Web mappen, dette er noe som må gjøres på nytt hvis man skal kompilere koden på en annen pc siden dette ikke er standard. Det vi også må gjøre er å legge til en Script manager, dette er noe som må gjøres før alle de forskjellige ajax funksjonene som vi skal bruke fra toolkitet. Dette trenger vi ikke gjøre her siden Script Manageren allerede er lagt til på Site.Master siden i header content placeholderen og denne er da allerede lagt til på alle Content sidene, og man kan kun ha en Script Manager per side. Tilbake til avdelinger definerer vi nå Accordion som er vår hovedfunksjon til å gjøre instillinger på alle de påfølgende AccordionPanes. AccordionPanes fungerer på mange måter likt som et vanlig panel, men forskjellen er at Accordian panelene ligger innenfor hele funksjonen Accordion. På hvert av panelene kan man sette en overskrift og derreter innholdet i panelet. I Accordion finnes det en haug av forskjellige instillinger man kan sette opp, de vi har brukt er css classer og hvilket panel som skal være oppe/utvidet når siden lastes.

Vi brukte også Ajax Controll Toolkitet ved validering av input, Masked Edit Extender, Filtered TextBox Extender og Validator Callout var noe av de vi så på. Vi bruker Masked edit i avdelinger hvor vi sette en mask i hvert at Qx feltene slik at det ikke skal være noe tvil om hva som skal stå i disse feltene siden det automatisk kommer __ % når du trykker i det feltet og bruker skjønner det at det er her en er en prosent verdi som skal legges inn. Her går det nå heller ikke ann å taste inn noen bokstaver eller spesial tegn, kun tall fra 0-9


27

Hovedprogram

GUI

Prototyp av GUI for WEB-applikasjonen. (MERK! Dette er alpha-prototypen vi lagde, den vil fravike mye fra det endelige designet da mye er bygget på skjermdumper fra tidligere applikasjon!)

Programmet er satt opp på samme måte som den tidligere versjonen av Prospect Explorer. Siden vi også skal lage en webapplikasjon så er det noen endringer av utseende og hvor forskjellige knapper og menyer legges.

Som i den tidligere versjonen benyttes tree-view til å navigere seg frem. Denne vil endres dynamisk ut ifra hvilke selgere, bransjer osv som legges til.

For å skrive ut prospektene, bruker vi grid-view. Dette er også likt oppsett som før, men vi kommer til å benytte tabeller fremfor spreadsheet. Datafeltene vil være ikke-redigerbare, men det skal nå finnes en “edit” knapp som gjør det enkelt å endre data (pop-up eller redirect til ny side).

Øverst finner vi knapper som har forskjellige oppgaver:

Excel knappen brukes når man skal eksportere dataene som ligger i griden til et Excel dokument.

Disketten brukes for å lagre endringer som er gjort.

Dropdown-menyen brukes for å navigere mellom de forskjellige tilstandene(måten data presenteres på) til programmet (Prospect, Prognose, Budsjett).

Slett knapp. For å ”slette” prospecter, altså gjøre de tapt. Ikonet er litt misvisende, så knappen vil sannsynligvis erstattes med Tapt- og Solgt-knapper i endelig design.


28

Søk knapp brukes for å finne prospekter som inneholder ett gitt nøkkelord. Dette er en tilleggsfunksjon som ikke er veldig sentral da brukere oftest vil navigere ved hjelp av tre-menyen.

Pluss knapp. For å opprette nye prospekter.

Settings. Brukes som en erstatter for program-menyen. Brukes når du f.eks. skal endre info om bransjer, databaser, moduler, avdelinger, selgere eller salgstyper. I tillegg til denne vil det være hensiktsmessig med en litt annen presentasjon av settings-menyen, men den designes etter undersøkelser vi vil ha med fremtidige

I senere tid har vi valgt å gå bort ifra noen av menyknappene:

Disketten trenger vi ikke lengre, da info vil lagres så fort man har trykket på den respektive Legg til-/endre-knappen.

Slett knappen vil også forsvinne, da det ikke skal være mulig å slette elementer i programmet. Dette må i så fall slettes direkte i databasen, og må godkjennes av en administrator. Dette skyldes at programmets integritet og relasjoner til hverandre kan ødelegges.

Fritekst-søk er unødvendig, da en selger som oftest er ute etter å vise egne prospekter, og salgsledere er interessert i å gjøre en helhetlig vurdering av en selger.

Sikkerhet

Passord sniffing Siden webapplikasjonen skal kjøres internt hos Agresso har vi, som nevnt tidligere, hatt fokus på funksjonalitet fremfor sikkerhet i første omgang.

Selv om den kjøres internt har vi utført sikkerhetstiltak pluss noen få tester for å forsikre oss om at det ikke skal være helt enkelt å plukke opp sensitiv informasjon fra webapplikasjonen. De testene vi har utført krever at personen som prøver å hente ut brukernavn/passord befinner seg på samme nettverket som personen som bruker systemet.

For å prøve ut dette har vi brukt et sniffeprogram som heter “Cain & Abel”. På bilde under ser man hvordan dette programmet enkelt plukker opp passord som sendes i klartekst:

Når vi kjørte denne snifferen opp moten webapplikasjonen vår så fikk den ikke hentet ut noe som helst.

SQL-injection Vi har beskyttet oss mot SQL-injection ved å legge til validering på alle tekst-/input-felter. En kjent svakhet er nedtrekkslister som kan endres til input-felter ved hjelp av visse verktøy. Vår validering sørger derimot for at alle felter fortsatt er av samme type (input/radioknapp/nedtrekksliste/osv) som da siden ble lastet. Hvis noen prøver å skrive inn ondsinnet kode, vil de få en feilmelding, eller i sistnevnte en server error:


29

Cross Site Scripting (XSS) Cross site scripting er når en bruker legger inn (som oftest ondsinnet) kode i form av scripts f.eks. i et input-felt til en database. Hver gang denne informasjonen fra databasen hentes (Dette kan eksempelvis være en av prospektene), vil også brukerens script kjøres samtidig.

Vi har også sikret oss mot denne svakheten ved å validere inputfelter, og sjekke at feltene er av samme type som da de ble lastet (Ref. SQL-injection).

Utvidelsesmuligheter Vi ser for oss at Webservicer kan lages som trekker ut små deler av funksjonaliteten for presentasjon. Enten med tabeller, eller grafiske diagrammer i silverlight eller liknende. Det er ikke skrikende behov for dette, men absolutt en fin utvidelse.

Dokumentasjon All dokumentasjon fra prosjektet ligger på CD’en vi har levert. Her inkluderer Produktdokumentasjon(dette dokumentet), prosessdokumentasjon, testdokumentasjon, brukerveiledning og kravspesifikasjonen.

Kildekode er også tilgjengelig på denne CD’en.

Vi har lagt ved “installasjonsveiledning” (OBS! Mulig å kjøre web-applikasjonen lokalt, men veldig mye enklere å kjøre den fra .NET serveren).

På hjemmesiden til gruppen finner man også en auto generert XML dokumentasjon for alle klasser og metoder.

Konklusjon Vi er fornøyd med resultatet, og føler vi har laget ett oversiktlig program, både på bruker-nivå og kodemessig. Det blir selvfølgelig en del kode som krever at man setter seg inn i det, men så fort man har oversikten vil det være lett å skjønne hva vi har gjort. Å lage programmet viste seg å være mer arbeid enn vi hadde trodd, men tiden strakk til.

Vi er fornøyd med resultatet. Vi har ett brukbart og kjørbart program som er brukervennlig. Alt dette har vi laget innen prosjektets deadline, og håper Agressos selgere kan erstatte dette programmet med eksisterende desktop-applikasjon etter det er implementert i bedriften.


30


31

Prosessdokumentasjon

Under prosessdokumentasjon vil du finne en oversikt over hvordan vi har løst

hovedprosjektoppgaven


32

Forord Her vil vi ta for oss hvordan vi tok de valgene vi har endt opp med, og hvorfor vi tok disse. I tillegg vil det komme fram hvordan vi har jobbet sammen som gruppe, hvilke hjelpeverktøy vi har brukt osv.

Denne rapporten er optimalisert for Word/PDF.

Vi endte opp med å gjøre hovedprosjektet vårt for bedriften Unit4 Agresso. Vi kom i kontakt med Agresso gjennom Tomas på gruppen, som hadde ett søskenbarn som jobbet der. Etter vi hadde møte med Agresso var det ingen tvil for noen av oss, her ville vi ha hovedprosjektet vårt! Inntrykket var godt, og Agresso virket som en spennende bedrift som kunne gi oss et godt innblikk i hvordan en stor programutviklings-bedrift fungerer i praksis.

Hensikten med arbeidet vårt var å utvikle en web-applikasjon for selgere og salgsledere i Agresso. Gjennom hele perioden har vi hatt jevnlige møter og fått hjelp dersom vi stod fast på noe.

Vi vil gjerne takke Kjetil Smith og Anders Hauan som har hjulpet oss mye, og gjort dette til en læringsrik og morsom prosess.


33

Innholdsliste Forord ....................................................................................................................................... 32

Innholdsliste ............................................................................................................................. 33

Innleding ................................................................................................................................... 36

Bakgrunn for prosjektet ....................................................................................................... 36

Bakgrunn for oppgaven ........................................................................................................ 36

Oppgavens mål og rammebetingelser ................................................................................. 36

Begrensinger......................................................................................................................... 37

Planlegging og metode ............................................................................................................. 37

Hvordan starte? .................................................................................................................... 37

Prosessmetode ..................................................................................................................... 37

Fremdriftsplan ...................................................................................................................... 37

Arbeidsplan .......................................................................................................................... 37

Gruppemøter ........................................................................................................................ 38

Dokumentstyring .................................................................................................................. 38

Prosjekthjemmeside ............................................................................................................. 38

Møtelogg/Arbeidslogg.......................................................................................................... 38

Dialoger med arbeidsgiver og veileder ................................................................................ 38

Anvendt programvare .............................................................................................................. 39

Visual Studio 2010 ................................................................................................................ 39

VMware ................................................................................................................................ 40

MS SQL Server R2 2010 ........................................................................................................ 40

Firefox ................................................................................................................................... 40

Firebug .................................................................................................................................. 40

Skype .................................................................................................................................... 40

Mumble ................................................................................................................................ 40

Valg ........................................................................................................................................... 41

Programmeringsspråk .......................................................................................................... 41

Layout på web-app ............................................................................................................... 41

Database og database-oppkobling ....................................................................................... 41

Lagdeling............................................................................................................................... 42

Meny ..................................................................................................................................... 42

Visning av prospekter ........................................................................................................... 42

Håndtering av objekter ........................................................................................................ 43

Ajax Control Toolkit .............................................................................................................. 43


34

Web Service .......................................................................................................................... 44

Hva måtte vi lære? ................................................................................................................... 44

Arbeidsmåter ............................................................................................................................ 45

Om utviklingsprosessen ........................................................................................................... 46

Forberedelser ....................................................................................................................... 46

1) Kravspecc.......................................................................................................................... 46

2) Basic oppsett av GUI ........................................................................................................ 46

3) Lagdeling & metodeplanlegging ...................................................................................... 47

4) Grov oppbygning av skjelett ............................................................................................ 47

5) Databaser opp .................................................................................................................. 47

6) Oppstart programmering ................................................................................................. 47

7) Sammenkobling av DAL til BLL ......................................................................................... 48

8) Hovedsiden kommer til liv ............................................................................................... 48

9) Excel eksportering ............................................................................................................ 48

10) Programmet tar form ..................................................................................................... 49

11) Overgang til XML-dokumentasjon ................................................................................. 49

12) Budsjett og prognose våkner til liv ................................................................................. 49

13) Skjule/vise unødvendig informasjon .............................................................................. 49

14) Dropdown lister og filtrering .......................................................................................... 50

15) Implementering av AjaxToolkit ...................................................................................... 50

16) Budsjett og Prognose fullføres ....................................................................................... 50

16) Statusfelt ........................................................................................................................ 51

17) Redigere eksisterende settings ...................................................................................... 51

18) Validering på settings ..................................................................................................... 51

19) Admin blir implementert ............................................................................................... 52

20) Fikse småbugs ................................................................................................................ 52

Kravspesifikasjonen og dens rolle ............................................................................................ 53

Endringer .............................................................................................................................. 53

Samsvar mellom spesifikasjon og produkt ........................................................................... 53

Om resultatet ....................................................................................................................... 53

Avslutning og konklusjon ......................................................................................................... 53

Hva har vi lært ...................................................................................................................... 54

Gruppen ................................................................................................................................ 54

Hva ville vi gjort annerledes? ............................................................................................... 54

Fremtiden ............................................................................................................................. 54


35


36

Innleding

Bakgrunn for prosjektet Det siste semesteret på Høgskolen i Oslo skal alle avgangsstudenter gjennomføre ett hovedprosjekt for en bedrift. Dette hovedprosjektet utgjør 20 studiepoeng. Prosjektet skal være ett gruppearbeid på mellom to og fem studenter, der vi har valgt å være fem.

Da vi satte oss ned i november 2010 for å finne oppgave, hadde vi valget mellom hovedsakelig Norconsult og Unit4 Agresso. Vi var i kontakt med begge, men vi var mest interessert i Agressos prosjekt. Dette var hovedsakelig fordi vi i deres oppgave kunne bruke våre datakunnskaper til å utvikle en web-applikasjon i .NET. Vi godtok oppgaven, skrev kontrakt med Agresso og startet med forberedelsene.

Bakgrunn for oppgaven Programmet som selgerne i Unit4 Agresso bruker til å håndtere prospekter i dag er 10 år gammelt og skrevet i Visual Basic. Programmet fungerer fortsatt fint, men det er på tide med en oppfriskning, da det på ingen måte er optimalisert for dagens datamaskiner.

De har en eksisterende database som inneholder all informasjon i programmet. Mot denne databasen skal man kunne legge inn og endre prospekter så hver selger har oversikt over hvilke salg de har hatt, eller har sannsynlighet for å få igjennom. Salgsledere skal også kunne gå inn å se oversikter over hvor mye hver avdeling/bruker har solgt for osv.

De har derfor behov for en web-applikasjon som skal ligge internt i bedriftens nettverk.

Oppgavens mål og rammebetingelser Målet med oppgaven er å utvikle en webapplikasjon som samsvarer med den eksisterende funksjonaliteten i desktop-applikasjonen, i tillegg til eventuelle ønsker om forbedringer. Selv om mange av selgerne har god teknisk kunnskap, skal programmet være enkelt å bruke. Vi skal i samsvar med selgere finne ut hva som ønskes av funksjonalitet og hvordan dette skal vises på skjermen.

I samsvar med arbeidsgiver kom vi fram til at vi skulle undersøke med selgerne om det er ønskelig med utvidelser i web-applikasjonen som de manglet i desktop-appen. Vi har derfor hatt hovedfokus på å lage en web-applikasjon. Programmet skal i grove trekk kunne:

Mulighet for å eksportere til Excel. Innlogging med forskjellige brukere og forskjellige rettigheter En oversiktlig måte å få frem dataene som lagt inn En GUI som gjør det enkelt å navigere seg rundt i programmet og legge inn/fjerne

data. Skjemaer for å legge inn data om (mulige) salg i databasen, og programmet vil

automatisk beregne en rekke sannsynlighetsfaktorer(ved hjelp av forhåndsbestemte formler) automatisk for brukeren.


37

Begrensinger Vi er påkrevd å benytte oss av SQL-databaser, og eksisterende databasetabeller er levert til oss på USB, så vi kan tilpasse programmet disse databasene.

Utover dette står vi ganske fritt til å ta egne valg, da Agresso spesifikt ønsket at vi skal foreslå løsninger som vi synes er fornuftige, fremfor at de forteller oss hva vi skal gjøre ned til hver detalj. Her var det opp til oss å være innovative og bevise at vi kunne være nytenkende.

Planlegging og metode

Hvordan starte? Denne oppgaven var større enn noe vi har hatt på høgskolen hittil. Vi hadde god erfaring med både å programmere og skrive rapporter. Kravspesifikasjonen vår var gitt av det forrige programmet, men det var opp til oss å formulere denne, for deretter å få den godkjent av bedriften.

Vi har jobbet mye med hverandre fra før, så gruppearbeidet inkludert samarbeid er ikke noe problem. Vi hadde ett innledende møte med veileder i starten.

Prosessmetode Vi har valgt Agile som utviklingsmetode.

Vi har jobbet agilt, der vi i starten satte opp ett grovt skjelett av programmet, for deretter å kjøre sprinter der vi fullfører oppgave for oppgave fortløpende, med en liste der vi har skrevet opp alle ting vi må implementere. For hver gang vi har implementert et nytt element, tester vi dette og sjekker at det virker, før vi hopper videre på neste oppgave. Vi så noen ganger at vi måtte tilbake å tilpasse ferdigstilte elementer pga. ny funksjonalitet, men det er akkurat dette som er fint med å jobbe agilt. Det er ingen spesifikasjon som er fastlåst, så nødvendige endringer er da lett å dytte inn her.

Fremdriftsplan Vi lagde fremdriftsplanen tidlig, og vi lagde denne for å ha en mal å jobbe etter. Vi visste at det ville oppstå forskyvninger i planen, så vi bestemte oss for å ha denne som en grunn mal som fortalte den optimale arbeidsprosessen. Vi så senere at vi hadde prioritert litt for liten tid til selve utviklingen, men vi hadde lagt inn gode marginer med testing, så forskyvninger her var ikke noe problem.

Arbeidsplan Arbeidsplanen ble laget samtidig som fremdriftsplanen. Denne reflekterte over de ulike arbeidsoppgavene vi hadde i fremdriftsplanen.


38

Gruppemøter Vi avtalte at vi skulle møtes regelmessig, helst to til tre ganger i uken. Med “å møtes” menes å arbeide enten sammen på f.eks. skolen, eller over skype/mumble hjemmefra. Vi hadde mulighet til å benytte grupperom hos bedriften, men vi så ikke dette som hensiktsmessig så lenge vi kunne sitte hjemme eller på skolen.

Vi valgte å ikke ha møter som kun fokuserte på status og fremdrift i prosjektet, da det var bedre å ta disse i starten eller slutten av hvert møte vi hadde for å programmere.

Når prosjektets slutt nærmet seg, avtalte vi obligatorisk oppmøte hver gang vi skulle jobbe.

Dokumentstyring I starten hadde vi planer om å benytte oss av Google-docs, men siden vi allerede var dreven med bruken av Dropbox valgte vi denne, da googledocs ikke tilbyr alle muligheter i “word”. Med dropbox fikk vi også automatisk backup av dokumenter. Dersom noe ble overskrevet, kunne vi bare revertere til eldre versjoner gjennom dropbox sin hjemmeside.

Prosjekthjemmeside Vi lagde en hjemmeside for hovedprosjektet. Den fungerte som en blogg, der man enten kunne legge inn referater fra bl.a. møter osv, eller laste opp filer og dokumenter.

Denne siden var ment som en informasjonskilde for interessenter i prosjektet (bedrift og veileder), og en påminnelse til gruppen når vi senere skulle skrive rapporter og sammendrag av arbeidet vårt.

Adressen var: http://student.iu.hio.no/~s155495/Hovedprosjekt

Vi opprettet også twitterkonto for hovedprosjektet, men denne var bare en alternativ løsning som vi ikke brukte så mye i det hele tatt.

For ordens skyld legger vi linken her: http://twitter.com/#!/hovedprosjekt

Møtelogg/Arbeidslogg Vi førte dagbok for hver gang vi jobbet med prosjektet, og la dette i ett dokument. Dette ble også replisert til prosjektsiden vår som blogginnlegg.

Det var noen ganger vi hadde glemt å skrive logger, og da gikk mye av tiden på neste møte til å skrive loggene. Dette førte til at vi fikk kodet mindre, men vi så viktigheten av å ha oversikten over ting vi hadde gjort og hva vi hadde problemer med. Dette lønnet seg da vi senere skulle skrive dokumentasjonen for arbeidet vårt.

Dialoger med arbeidsgiver og veileder Vi hadde møter med arbeidsgiver etter eget eller bedriftens ønske. Disse møtene var som oftest statusmøter der vi viste hvor langt vi hadde kommet, i tillegg til at vi stilte spørsmål om problemer som hadde oppstått siden sist.

Vi hadde ikke så mange møter med veileder, da arbeidsgiver var ekstremt hjelpsomme dersom det var noe vi lurte på. Mail ble som oftest besvart i løpet av dagen. Vi sa ifra til veileder at dersom det var noe han lurte på, så skulle han ta kontakt, men begge parter var enige om at så lenge bedriften bisto oss på så god måte som de gjorde var det ingen hensikt med regelmessige møter.

http://student.iu.hio.no/~s155495/Hovedprosjekt

http://twitter.com/#!/hovedprosjekt


39

Anvendt programvare

Visual Studio 2010

Hoved utviklingsverktøyet vi har brukt er Visual Studio 2010 ultimate/professional. Siden dette er et helt overlegent IDE til .NET utvikling i tillegg til at vi er kjent med programmet fra tidligere, så var ikke valget så vanskelig. VS2010 har masse ferdige biblioteker med det meste av funksjoner og elementer man kan trenge. VS gir oss også god

fargelegging av syntakskoden, en god oversikt over klasser og automatisk kodefullførelse.

HiO tilbyr oss .NET-servere der vi kan legge ut og kjøre applikasjonen. Denne serveren har også Team Foundation funksjonalitet, noe som også gir oss tilgang til versjonskontroll.

(her er et screenshot av VS2010 som viser hvordan det ser ut i bruk)


40

VMware Dette er et program som gir oss muligheten til å kjøre virtuelle maskiner på våre egne PCer. Dette brukte vi for å kjørt den tidligere versjonen av programmet vi skulle lage. Ved hjelp av dette fikk vi muligheten til å gå inn å se på funksjonaliteten dersom det var noe vi var usikre på. Vmware ble benyttet da dette var formatet på

MS SQL Server R2 2010 For å få databasene vi fikk utdelt av arbeidsgiveren vår opp på serveren på skolen brukte vi MS SQL Server 2010. Ingen på gruppen hadde brukt dette programmet før, men etter en liten stund fikk vi orden på det. For å få databasene opp på riktig måte så måtte vi først generere create scripts fra de filene vi hadde lokalt. For så å utføre disse opp mot serveren på HiO.

Firefox Vi har benyttet oss av Firefox som standard-nettleser når vi programmerer og tester. Dette hovedsakelig fordi Firefox er har mange nyttige verktøy til web-utvikling og feilsøking. I tillegg er dette en meget populær nettleser som vokser kraftig i antall brukere verden rundt.

Firebug Firebug er en utvidelse til Firefox, dette er hovedsakelig et feilsøkingsverktøy som vi har brukt mye under utviklingen av web-applikasjonen. Ved hjelp av Firebug kan du inspisere og endre HTML og CSS kode rett i nettleseren slik at man ser hvordan endringene vil påvirke siden.

Skype Skype er ett program der man kan ha tale/video/tekstbaserte samtaler over internett. Dette minimaliserer ringepriser og kjapp kontakt ved behov.

Vi har benyttet dette i starten av prosjektet til å ha forberedelser til neste dag, eksempelvis hva vi må lese oss opp på av kode.

Mumble Vi har etterhvert valgt å benytte oss av Mumble istedenfor Skype. Vi foretrakk mumble grunnet den såkalte PTT (Push To Talk) funksjonen der man må holde inne en valgt knapp for å snakke(mulig skype også har dette). Det var en stund problemer med bakgrunnsstøy når vi satt fem personer på samme Skype-samtale.


41

Valg

Programmeringsspråk Vi har valgt å bruke .NET og C# til å utvikle med. Dette er først og fremst fordi Unit4 Agresso bruker dette som standard innad i firmaet, men også fordi vi har best personlig erfaring med det. Vi tror mye kommer av at vi har brukt Visual Studio 2010, som er ett veldig kraftig og brukervennlig utviklingsverktøy. I tillegg tilbyr VS en rekke biblioteker og funksjoner som gjør mye av presentasjonen av data mye lettere. Her sikter vi til for eksempel menyer, tabeller og SQL-kommunikasjon som står veldig sentralt innenfor oppgaven vår.

Layout på web-app Vi har tenkt å bygge opp feltene i web-applikasjonen ved hjelp av såkalt div-grid, der man bruker div-tagger (Ref. HTML <div>) til å bygge opp en gui. Denne måten å bygge opp siden på baserer seg på å legge div-tagger rundt de ulike delene av siden, for deretter og legge informasjonen inni taggene. Da vil vi styre sidens størrelse kun ved hjelp av CSS-filen, der man først setter en bredde for hele siden, og setter størrelsen på div-elementene respektivt ut ifra totalbredden.

Vi kunne valgt å bygge opp denne div-griden på egenhånd, men det eksisterer allerede mange ferdiglagde CSS-filer som fokuserer på akkurat dette. De to som utmerket seg var Blueprint og 960.

Vi prøvde oss litt fram med disse to, men kom til slutt fram til at vi skulle bruke Blueprint. Her deler man standard inn siden i 24 usynlige kolonner med totalbredde 950pixels (Vi mener pixels gir den beste standarden for størrelser i HTML og CSS). For div-taggene refererer man til en av de 24 klassene span-1 til span-24 der bredden på elementet settes. Span-1 vil generere ett element som er 1kolonne bred(med 10px margin) mens span-12 vil dekke halve området. Span-24 vil dekke hele. For alle disse vil høyden være uendelig, dvs. høyden vil kun variere ut ifra hvor mye innhold taggene skal inneholde. Vi kommer også mest sannsynlig til å prøve såkalt liquid layout(skalerer når du gjør vinduet større og mindre), da man kun trenger å inkludere en CSS-fil som gir span-klassene en prosent-størrelse i stedet for pixels. For mer detaljer om Blueprint, ref. lenken under.

Innenfor div-taggene vil vi plassere såkalte Content Place Holders(CPH, er standard i ASP .NET) som gjør at vi slipper å oppdatere hele siden for hver gang vi skal presentere en ny prospect-tabell. Vi benytter ett rammevindu som består av en header, meny og footer(footer kan sløyfes).

Database og database-oppkobling Tidligere har vi jobbet mye med SQL-databaser. Vi har erfaring med både statiske queries, ADO og Linq.

Valget vårt sto mellom ADO og Linq, men valget var åpenbart fra første stund: Linq vil hovedsakelig bli brukt, men ADO vil benyttes dersom vi skal hente tabeller med veldig avanserte queries.

Linq falt mest i smak for alle, da Linq automatiserer mye av prosessen som har med databasekallet å gjøre. Her kan vi skrive til databasen nesten på samme måte som vi skriver variable til objekter. Da vil for det første koden bli mer oversiktlig, men vi får en tilnærmet


42

standardisert måte å skrive/oppdatere data i databasen. ADO har vist seg å være veldig lett å bruke for å hente data fra en database, uansett om querien er helt simpel eller meget avansert. Derfor konkluderer vi med at vi først og fremst vil benytte Linq til SQL-delen av oppgaven, men der SQL-kallene er avanserte vil vi benytte ADO.

Lagdeling Vi har valgt å benytte en ganske standard lagdeling der vi har ett lag for objekter(Model), ett for Datalogikken/Business Logic Layer(BLL), ett for databasekall/Data Access Layer(DAL) og ett for gui/view.

Når vi setter opp programmet på denne måten vil det bli enklere å få programmet tilgjengelig på flere måter, bl.a. som web-applikasjon, desktop-applikasjon, mobilapplikasjon og generelt alle andre plattformer.

Hvis vi setter opp slike delinger vil det bli mye lettere å bytte ut deler av programmet. Eksempelvis skal vi hovedsakelig fokusere på å lage en web-app, men om det var ønsket med en desktop eller mobil-app, ville den eneste delen vi trengte å bytte ut være view/GUI-delen. Alle andre lag vil oppføre seg helt likt, og vi vil ha muligheten til å gjenbruke disse(Dersom det var snakk om en mobil-app måtte vi evt ha konvertert/skrevet om koden til ett annet språk).

Meny Menyen vår kommer til å være en standard .NET Tree-View. Denne er standard i Visual Studio, og godt integrert mht bruksmåter og programmering. Den oppfyller også alle krav vi har til menyen, der det viktigste er å opprette menyen dynamisk, da brukeren skal kunne legge til menyobjekter. Vi valgte denne fremfor andre grunnet at denne er allerede implementert og støttet fullt ut i VS2010.

Visning av prospekter For å vise prospektinformasjonen kommer vi til å benytte standart .NET GridView. Som menyen nevnt over, følger denne også med i Visual Studio. Vi har sett etter andre GridView´s som likner mer på spreadsheets(Excel) men gikk bort fra disse, da de aller fleste krevde betalte lisenser($900-$3000 per utvikler).

Vi kom også fram til at om vi kunne presentere dataen som spreadsheet ville det bli omfattende dersom brukeren skulle endre noen felter. For å laste opp oppdatert data ville vi blitt nødt til å ha metoder som sammenliknet hver enkelt linje i spreadsheeten, for deretter og kun laste opp de feltene som var endret til databasen. Derfor fant vi ut at det var bedre med skrivebeskyttede felter i GridView, og om bruker ønsker å endre noe benytter han en edit-link på siden som resulterer i at valgt prospekt vil komme enten som en pop-up eller ny side der feltene er editerbare. Da vil vi minimere kall/trafikk mot SQL-databasen og også ressurser benyttet på klient-maskinen.


43

Håndtering av objekter Vi har valgt å opprette objekt-klasser i Model(Ref. lagdeling) for alle typer elementer vi har i programmet:

Bransjer/MBranche

Budsjett/MBudsjett

Databaser/MDatabase

Avdelinger/MDepartment

Avdelingsbudsjett/MDepartmentBudget

Moduler/MModule

Prognose/MPrognose

Prospekt/MProspect

Prospekt statuskoder/MProspSC

Salgsbudsjett/MSalesBudget

Salgstype/MSalestype

Kilde/MSource

Bruker/MUser

Dette gjør vi for å forenkle alle håndteringer av disse objektene, om det skulle være visning på skjermen eller oppdatering til databasen ved hjelp av Linq. Prospekt-klassen vil imidlertidig bare bli brukt når ett prospekt skal endres/legges til osv, men ikke når de vises i GridView. Dette fordi det er lite hensiktsmessig å opprette ett objekt for hver linje av en SQL-tabelliste for deretter å sette de inn i en tabell igjen.

Ajax Control Toolkit Vi har benyttet oss av AJAX i prosjektet. Sitatet fra wikipedia sier det meste:

Ajax, eller Asynkron JavaScript og XML, er en webutviklingsteknikk for å lage interaktive

nettsider. Tanken er å lage nettsider som føles mer responsive. Dette gjøres ved at sidene

utveksler litt og litt data med serveren i bakgrunnen, i stedet for å laste hele siden på nytt hver

gang brukeren gjør en forandring. Dette skal øke nettsidenes interaktivitet, hastighet og

brukskvalitet.

Ajax bruker en kombinasjon av:

HTML (eller XHTML) og stilark (CSS) for presentasjon. DOM (Document Object Model) manipuleres ved hjelp av JavaScript for å dynamisk

generere informasjon som blir presentert. XMLHttpRequest-objektet for å kommunisere asynkront med en web-server.

Ajax er ikke en teknologi i seg selv, men en betegnelse som refererer til en gruppe

teknologier.

http://no.wikipedia.org/w/index.php?title=Asynkron&action=edit&redlink=1

http://no.wikipedia.org/wiki/JavaScript

http://no.wikipedia.org/wiki/XML

http://no.wikipedia.org/wiki/Nettside

http://no.wikipedia.org/wiki/Brukskvalitet

http://no.wikipedia.org/wiki/HTML

http://no.wikipedia.org/wiki/XHTML

http://no.wikipedia.org/wiki/Cascading_Style_Sheets

http://no.wikipedia.org/wiki/DOM


http://no.wikipedia.org/w/index.php?title=XMLHttpRequest&action=edit&redlink=1


44

Web Service Vi har opprettet en web service slik at det blir enkelt å utvikle applikasjoner opp mot de samme dataene som vi bruker.

Ved å bruke en web service kan applikasjonen vår lett dele funksjoner og data med en tredjepart.

Web servicer bruker XML til å kode og til å dekode data, og SOAP til å transportere den.

Med tanke på at det kan bli aktuelt å utvikle en iPhone app med noe av samme funksjonaliteten som det ordinære programmet vårt, så virket det smart å sette opp denne web servicen. Når noen evt. skal lage en slik iPhone app, vil det da kun være nødvendig å lage det ytre skallet, for så å koble seg opp mot web servicen og hente ut nødvendig data.

I vårt eksempel er det lagt inn noen få metoder for å vise hvordan en slik tjeneste henter ut data. GetDep() metoden skriver f.eks. ut alle de forskjellige avdelingene i XML format.

Hva måtte vi lære? Visual Studio og .NET har vi brukt fra før, men det var absolutt nødvendig å sette seg dypere inn i hva .NET og VS tilbyr. Vi hadde aldri drevet med tree-views før, så dette måtte vi sette oss inn i. Tabeller, knapper, Linq, GridView osv hadde vi vært innom tidligere, men også her var det nye ting å sette seg inn i.

Blueprint-CSS stylen hadde de fleste hørt om, men aldri benyttet til noe fornuftig. Vi har hørt mye bra om denne formen for layout, så vi tenkte at dette var en fin mulighet til å lære det.

Lagdelingen var samme lagdeling vi benyttet forrige semester i Web-applikasjoner. Da var lagdeling relativt nytt for oss, men etterhvert som vi lærte å jobbe på den måten, ble vi overbevist om at dette var den beste måten å strukturere applikasjoner på. Her var det ikke så mye vi hadde behov for å lære.

Det samme gjaldt også den måten vi benytter oss av objekter (ref. Model-laget). Dette gjør at programmeringen blir mer selvforklarende etter man har satt seg inn i koden. Det er tross alt lettere å skjønne betydningen av MUser.Name fremfor user[3] (arrayliste som itereres gjennom). Vi tror også dette vil forhindre en god del slurve-feil (Name/Username osv. sier mer om hvilken informasjon som skal hentes enn 1/2/3/4).

AJAX hadde ingen av oss brukt før, men når vi fikk implementert det og testet litt, så gikk det bra etterhvert.

Vi hadde ikke hørt om Web services før de nevnte det på Agresso, men vi likte prinsippet om å filtrere ut en spesifikk del av programmet for bruk andre steder, f.eks. mobilapplikasjoner eller andre former for presentasjoner. Vi fikk en liten veiledning i dette, og skjønte etterhvert hvordan vi lagde disse. Vi tenkte derfor det ville være fint å inkludere ett lite eksempel på dette i oppgaven.


45

Arbeidsmåter Vår gruppe har fulgt hverandre jevnt siden vi startet på HiO. Vi har hatt ett godt samarbeid hele veien, og det var en selvfølge at vi skulle ta hovedprosjektet sammen også. Vi har jobbet på samme måte som vi har gjort før, der vi møtes på skolen (datalabber) og programmerer de programmeringstunge oppgavene.

Vi fant raskt ut at det var mer effektivt å sitte hver for oss hjemme med skikkelige skjermer/maskiner isteden for å sitte med laptop på skolen. For å kommunisere med hverandre brukte vi et program som heter Mumble, dette fungerer på nesten samme måte som skype men det har i tillegg en PPT(Push To Talk) funksjon som gjør at man slipper å høre ALT de forskjellige på gruppen drev med til enhver tid.

For å kunne kode samtidig på samme prosjekt brukte Team Foundation Server som er en funksjon som er innebygd i Visual Studio 2010. Denne passer på at ikke flere personer kan jobbe i samme fil samtidig (i hvert fall at endringer i samme fil må merges/flettes).

For å dele filer som ikke er en del av selve programmet har vi brukt ”dropbox”. Det lager en delt mappe på alle gruppemedlemmene sin PC som alle kan laste opp filer til.

Når det var snakk om lett delelige arbeidsoppgaver som mindre implementeringer, småfikser og dokumentasjon, har vi sittet hver for oss med kommunikasjon over skype/mumble (voIP-applikasjoner). Til tider har vi også møtt hverandre på skolen, for deretter dra hver for seg.

Vi jobbet agilt med klart fordelte arbeidsoppgaver, og hadde alltid definerte mål og oppgaver for hver enkelt dag/uke. Før vi sa oss ferdige med en type funksjonalitet, testet først den ansvarlige koden grundig, før evt de andre på gruppa gikk gjennom og forsøkte å finne feil. Som en følge av denne måten å jobbe på, var feilfiksing i slutten stort sett av mindre kompliserte problemstillinger, men vi hadde en del utfordringer med å få de norske tegnene til å håndteres korrekt i alle sammenhenger (f.eks. ved sammenligning av strenger, og ved utskrift til skjerm).

Vi fikk gode tilbakemeldinger fra Kjetil (vår kontaktperson, via mail og møter), Anders (vår opprinnelige kontaktperson, via møter) og salgsleder (via møter). De var meget flinke til å gi oss konstruktiv kritikk på ting vi hadde gjort. Dersom vi hadde spørsmål sende vi disse over mail, eller nevnte det på møtene. Vi har fått et inntrykk av at de er fornøyde med hva vi har klart å prestere mht applikasjonen.


46

Om utviklingsprosessen Utviklingsprosessen er beskrevet i nummererte faser for ulike sprinter (MERK! Hvert nummer representerer ikke en enkelt sprint, vi har slått sprinter sammen der vi finner det hensiktsmessig/naturlig for oversiktens skyld). Under hvert element beskriver vi hvordan vi jobbet.

Under utviklingen hadde vi ikke veldig mange valg å ta med hensyn til programmet vårt, da en god og grundig forberedelsesfase sørget for at de fleste valg var tatt, og vi kunne fokusere på koding. Valgene vi har tatt har vi beskrevet i ett avsnitt over (Under “Valg”).

Forberedelser Vi gikk sammen med arbeidsgiver og definerte krav til web-applikasjonen. Det gikk ut på at arbeidsgiver og salgsleder viste oss hvordan programmet ble brukt, mens vi noterte. Videre kom gruppen med mer detaljerte spørsmål angående programfunksjonalitet. Selve forberedelsesfasen gikk smertefritt, da vi som oftest klarte å definere hva vi måtte gjøre. Der vi skulle ha uklarheter var arbeidsgiver veldig hjelpsom enten via mail eller møter. Ett stort pluss var at vi hadde tilgang til et Vmware bilde som hadde det gamle Prospect Explorer installert. Her kunne vi enkelt gå inn å se hva vi trengte å ha med i vårt program.

1) Kravspecc Før vi satte oss ned og skrev kravspeccen hadde vi en intervjurunde med selgere som skulle bruke systemet. Her fant vi ut hvilke funksjoner av programmet de ønsket å forandre, og hvilke de ønsket å beholde. Vi hadde også fått en gjennomføring av eksisterende applikasjon der vi fikk ett grovt inntrykk av programmet. Deretter satt gruppen seg ned og ble enige om hvordan vi skulle sette det hele sammen. Siden Agresso ønsket at vi skulle komme frem til løsninger på egenhånd, valgte vi å kun bruke Vmware-imaget vi hadde fått til å sammenlikne funksjonaliteten grafisk, ikke dypt i koden. Vi ønsket med denne oppgaven å komme fram til løsninger ved hjelp av egen tenking, ikke ved hjelp av eksisterende kildekode.

2) Basic oppsett av GUI Første steg vi tok i utviklingen var å opprette en tom aspx-side. Deretter lagde vi div-taggene vi skulle bygge programmet rundt. Fra øverst i venstre hjørne lagde vi en div for logoen. Til høyre for denne, en div for topp-menyen. Under disse lagde vi div-tagger for tre-menyen og GridView, og til slutt la vi til en footer-div nederst på siden. Vi er ikke sikre på om denne skal eksistere, men vi ser for oss denne som ett statusfelt som viser infomeldinger og feilmeldinger ut ifra hva brukeren trykker på, status om det er kontakt med databasen osv.

Neste step var å plassere ContentPlaceHolders(CPH) innenfor de respektive div-taggene. Da alt var satt opp la vi inn test-data for å teste at alt var satt opp riktig; alt fungerte perfekt!


47

3) Lagdeling & metodeplanlegging Vi opprettet de ulike lagene vi hadde bestemt oss for å lage: Model(objektene), BLL(program-logikken) og DAL(SQL-Databaselaget). View eksisterer allerede.

Deretter opprettet vi en del klasser så vi fikk delt opp programmet ytterligere ut ifra hva som var logisk i henhold til struktur. Vi laget separate klasser for Prospect (Model:Prospect, BLL:Prospect, DAL:SQLProspect) da hovedfunksjonaliteten til applikasjonen er å vise prospekter. Vi lagde også klasser for settings, som skal inneholde alle endringer man kan gjøre i programmet. Det samme gjorde vi for settings (klassen som omhandler alle settings-funksjonene).

Returverdier består hovedsakelig av objekter som befinner seg i Model, men også lister med disse. På login benytter vi oss av int på logginnsjekk, der 2 betyr admin, 1 betyr vanlig bruker og 0 betyr feil.

4) Grov oppbygning av skjelett Når lagdeling var satt opp begynte vi å fylle inn med klasser, metoder og variable. Først uten innhold, slik at alt var klart til å fylles inn med kode senere. I starten fokuserte vi på å få prospekt tilstanden av programmet til å fungere, for så å begynne med budsjett og prognose.

5) Databaser opp Vi bestemte oss for å laste opp databasene vi fikk utdelt av agresso på HiO sin dotnet server. Vi fant ut av at dette var den enkleste måten å gjøre det på, etter mye trøbbel med MS SQL Server R2 2010 lokalt. Vi knotet en hel dag med å installere og avinstallere ulike versjoner av programmet, men bestemte oss til slutt for å redigere scriptene manuelt, da dette gikk betydelig raskere.

Vi brukte derimot MS SQL Server R2 2010 for å kjøre create-scriptene mot HiO serveren, og koblet senere Visual Studio 2010 opp mot denne. Når databasene var oppe, var alt klart for å starte programmeringen.

6) Oppstart programmering Vi implementerte først en gridview/tabell som etterhvert skulle bli til hovedsiden som viser prospektene. Siden vi hadde denne oppe ville det bli lettere å teste at fuksjonaliteten var ok. Vi så fort at å først opprette en grafisk prototyp av siden gjorde det lettere å gjennomføre implementeringene.

Vi opprettet samtidig samtlige aspx-sider for hver del av settings. Her skulle vi ha felter for å fylle inn informasjon som etter godkjent validering skulle legges i databasen. Her skulle vi også ha gridviews som var koplet til sqlDataSources (En måte å hente data fra databasetabeller i Visual Studio) som viste eksisterende linjer/rader i tabellene.

Mens vi bygde opp programmet grafisk, startet den andre delen av gruppen å lage metodene i DAL, som skulle hente data fra de ulike tabellene. Vi lagde i første omgang metoder som kunne legge til, redigere, hente unik rad og hente alle rader. I tillegg lagde vi unik-sjekker for de ulike settings. Vi var ikke sikre på om vi skulle benytte oss av alle get-metodene, men det var like greit å ha disse tilgjengelig i tilfelle. Hvis ikke vi kommer til å bruke de, ligger de klare dersom noen skal foreta en videreutvikling av programmet i senere tid.


48

Vi bestemte oss for å benytte oss av sessions i størst mulig grad, da Prospect Explorer er ett typisk program der man lagrer permanente endringer i databaser, mens midlertidig informasjon som f.eks. valgt år og selger kan lagres i sessions. Sessions er også veldig hendige å bruke i web-applikasjoner. Vi er klar over at det er en viss sikkerhetsrisiko ved å bruke sessions, men denne servicen skal ligge internt på Agressos nettverk, og skal ikke være tilgjengelig for offentligheten.

7) Sammenkobling av DAL til BLL Etter de fleste metodene i DAL var ferdigstilt lagde vi metoder i BLL som reflekterte sine respektive metoder i DAL. Utvidet funksjonalitet i BLL kommer senere, og f.eks. stripping av stringer (SQL-injection) ble lagt inn, men ikke implementert overalt. Programmet hadde nå mulighet til å kalle opp sql-query metodene via BLL.

8) Hovedsiden kommer til liv Vi prioriterte å lage menyen på venstre side, så siden etterhvert ble funksjonell. Vi lagde metoder som hentet ut brukere og avdelinger, og la dette inn i tre menyen dynamisk. Dette krevde litt prøving og feiling, men etterhvert fikk vi det til. Da var det klart for å binde de enkelte nodene til hvilke filtre som skal benyttes. Vi gjorde dette først ved hjelp av en Response.Redirect(“eksempel.aspx”); der vi sendte med id for hva som var valgt. Vi gikk fort bort fra denne løsningen, da vi så det som mer oversiktlig å lagre valg i sessions. Da ville sessions sjekkes i hver page load, for deretter å skrive ut data med gitte filtre.

Design og layout var forhåndsdefinert, både utseende og hvordan sidene skulle bygges opp teknisk. Vi hadde derfor ingen kritiske valg å ta i etterkant.

9) Excel eksportering Vi implementerte eksportering av excel i .csv format. Dette så rart ut når vi åpnet dokumenter i vår versjon av excel. Når vi tok opp dette med arbeidsgiver forklarte de at sånn vi hadde gjort det var riktig, og at grunnen til at det så rart ut var at det er forskjell på norsk og engelsk .csv der engelske har kommaseparert, mens norske har semikolonseparert. Siden vi hadde gjort det riktig satte vi denne som ok.

Vi implementerte denne på de fleste settings-sidene.

Dette viste seg å være litt mer krevende enn vi først antok. Å lage metodene gikk som smurt, men håndtering av æ/ø/å var problematisk. Vi prøvde å skifte mellom UTF-8, ulike ISO-standarder og Unicode, men ingen av disse så ut til å virke. Når vi testet ut med regex (Ref. erstatte spesifikke bokstaver med andre som håndteres) fikk vi sikkerhets-advarsler, og vi var ikke helt overbevist om vi skulle slippe disse gjennom eller ikke. Vi utsatte dette til senere, men implementerte export allikevel.


49

10) Programmet tar form Vi lagde alle legg til-funksjonaliteter for de ulike settings-gruppene. Vi benyttet samme måte på alle sidene, så dette var mest å fullføre en av sidene helt riktig, og når vi så oss fornøyd implementerte vi det samme på alle de andre sidene.

Når vi skulle legge til verdier i tabellen kom vi over ett felt som het agrtid. Dette viste seg å være en måte Agresso hold styr på hvor mange ganger en rad hadde blitt oppdatert. Denne skulle vi bare se bort ifra, da den måtte innom interne rutiner i Agresso som vi ikke hadde tilgang til. Derfor setter vi bare disse til en statisk verdi i alle legg-til metoder.

Gridview/Prospect-tabellen henter nå ut data, med en begrensning på at den bare viser forrige år og årets prospekter.

11) Overgang til XML-dokumentasjon Etter vi hadde ett møte med Agresso viste de oss en ny måte å dokumentere på. Istedet for å bruke de vanlige // og /* */ gikk vi over koden og lagde XML-kommentarer i programmet ved hjelp av ///.

/// <summary> /// This method adds a new prospect to the database /// </summary> /// <param name="prosp">Object containing prospect-information</param> /// <returns>true if success, false if error</returns>

Her ser vi at det er generert XML-tags som lager en strukturert dokumentasjon av metodene. <summary> er en beskrivelse av hva metoden gjør. <param name> er tags som definerer hvilke parametere som inneholder hva, eller hva de brukes til. <returns> beskriver hva metoden returnerer tilbake. Når vi kommenterer på denne måten kan man raskt og enkelt se over kommentaren og luke ut de tags man ikke er interessert i. Disse kommentarene kan også eksporteres til XML eller Microsoft HELP filer, så vi kan generere en programdokumentasjon raskt og enkelt ferdig til bruk.

12) Budsjett og prognose våkner til liv Siden prospect nå var klar til å implementere filtrering, lagde vi Budsjett og Prognose. Vi satte opp disse med statiske verdier, så vi fikk ett inntrykk av hvordan det skulle se ut. Dette var først å fremst for å sjekke at verdier ble beregnet riktig (Definitivt lettere å sjekke når man har satt statiske verdier).

Vi startet også på legg til prospekt. Dette var omfattende, da det var 53 ulike felter i denne tabellen. Det var ikke alle som skulle brukes eller fylles inn av bruker, men det skulle vi få en klargjøring av ved ett senere tidspunkt.

13) Skjule/vise unødvendig informasjon Vi implementerte knapper som gir bruker mulighet til å collapse/skjule både header(logo, og brukerinfo) og menyen. Da vil større del av skjermbildet vise tabellinformasjon. Det er ikke nødvendig for selgere som ser programmet hver dag å dekke skjermen med logoer osv., så dersom man ser dette som unødvendig kan man velge å fjerne de, for deretter å vise de ved behov.

Dette var relativt lett å implementere så fort vi hadde forstått hvordan vi gjorde det. Hva brukeren har valgt (f.eks. skjul meny med inne overskrift) lagres som vanlig i sessions.


50

14) Dropdown lister og filtrering Vi lagde dropdown-lister der man kunne velge hvilken måte man ville se informasjonen (Prospekt, Budsjett eller Prognose) man hentet ut. Prospekt viser hvert enkelt prospekt linje for linje, Budsjett viser hva avdelinger eller selgere har som budsjett i løpet av ett år og Prognose viser en kalkulering av hva selgere/avdelinger har solgt for, nesten solgt for, disse to summert, budsjettet sitt og hvor mye avvik det er.

Vi lagde også en dropdown for år som kunne brukes til å velge ønsket år (“Arkiv-søk”). Denne ble populært ut ifra alle eksisterende elementer i databasen. Her kunne selgere gå tilbake å se informasjon fra tidligere år. Dette ble satt i sessions, og disse blir hentet i pageload sammen med valgt node i tre menyen.

15) Implementering av AjaxToolkit Vi benyttet oss av AJAX til å lage flotte paneler til settings-sidene. Disse vil nå ha eksempelvis et panel som inneholder legg til/endre felter, og ett som viser eksisterende data i tabellen. Dette fører til en mer oversiktlig/strukturert visning av de ulike elementene. De fungerer slik at man enten må ha (eks.) fanen “Ny selger” ELLER “Vis eksisterende”. Når man bytter mellom disse vil den man har valgt ekspandere, og den andre kollapse.

16) Budsjett og Prognose fullføres Tidligere hadde vi satt opp disse med statiske felter, men siden vi nå hadde lagt in funksjonalitet som satte sessions når vi valgte år/selger/avdeling, var tiden inne for å implementere metoder som hentet ut informasjon i henhold til valgte filtre.

Dette var en litt mer omfattende prosess enn vi hadde regnet med, men med runder med robust testing fikk vi til slutt ut de resultatene vi ønsket. Her var det ikke bare å hente ut data fra databasen, men vi måtte summere sammen disse også, for deretter å sette de opp i tabeller manuelt. Vi kunne laget en veldig avansert SQL-query, men valgte å gå bort fra dette. Eneste grunnen var at vi så på det som mer oversiktlig å gjøre det på denne måten fremfor å ha en hel side med en eneste SQL-query. Samme resultat ville vi jo fått uansett.


51

16) Statusfelt

Statusfelt ble etterhvert testet ut. Vi lagde en klasse (PageWithStatus.cs) som arver egenskapene til Page. (Dette er klassen en vanlig .aspx side vanligvis arver). I de .aspx sidene vi trenger statusfeltet kan vi bare fjerne arvingen av System.Web.UI.Page, og erstatte denne med PageWithStatus. Da har vi tilgang til denne globalt. Merk at vi også lagrer denne i en session, men bestemte oss for at isteden for å editere session direkte, måtte vi gå via klassen. Da ville vi få mer kontroll på når en statusmelding settes og ikke.

Vi kan også utvide denne klassen betydelig, men kun etter behov i første omgang.

17) Redigere eksisterende settings

Vi la inn rediger-knapper som hentet informasjonen i raden, og satte disse til feltene i Legg-til ny panelet. Legg-til knappen ble også erstattet med en oppdater- og en avbryt-knapp. Dette gikk mer knirkefritt enn vi hadde fryktet, det eneste problemet var at vi ikke implementerte validering sammen med rediger, så vi måtte ta enda en runde i settings for å implementere dette.

18) Validering på settings Vi la inn validering av felter. Får å sjekke obligatoriske felter brukte vi den integrerte validerings-sjekken i Visual Studio som heter RequiredFieldValidator. Dersom man trykker på en knapp i denne valideringsgruppen, vil feltene sjekkes, og dersom feltet ikke er fylt ut vil en rød stjerne (Farger og tekst settes manuelt) vises til høyre for feltet. Vi har også laget en feilmeldings-boks der alle feil bruker har gjort skrives ut.

I de feltene vi hadde behov for å sjekke at feltene kun inneholdt godkjente tegn (f.eks. a-å/A-Å og 0-9) brukte vi igjen en integrert validering i Visual Studio kalt RegularExpressionValidator. Her velger man manuelt hvilke tegn som skal være lov. Dersom bruker har tastet inn tegn utenfor RegExVal sin regel, vil en feilmelding komme i feilmeldings-boksen.

Dette var igjen relativt enkelt å implementere så fort vi hadde lest oss opp og skjønt hvordan vi skulle bruke disse elementene. Igjen var settings-sidene ganske like, så så fort det virket 100% på en side, gikk det raskt å implementere på de andre sidene.


52

19) Admin blir implementert Vi la inn sjekker for om man var logget inn på alle sider bortsett fra forsiden. Vi la også inn sjekker for admin på de sidene der kun admin og salgsleder skal ha tilgang. Vi gjorde dette først nå, fordi testing gikk mye raskere uten behov for å logge inn hver eneste gang.

Dette gjorde vi veldig enkelt ved å sjekke i Page_Load. Hver gang en side lastes hentes sessions for loggedin (og evt adm). Dersom disse sier at bruker er logget inn, vil bruker få lov til å fortsette lastingen av siden. Hvis ikke, blir bruker sendt videre til enten login-siden eller standard-siden som viser prospect.

20) Fikse småbugs Siste innspurt besto av å teste funksjonaliteten i programmet. Vi fikset feil der vi fant de, og forberedte siste versjon til leveranse.


53

Kravspesifikasjonen og dens rolle Kravspesifikasjonen var det viktigste dokumentet vi hadde gjennom hele prosjektet. Dette dokumentet var i tillegg til Vmware bildet vårt retningslinjene og rammebetingelsene vi hadde til programmet.

Endringer Fordi dette var en rekreasjon av ett eksisterende system var kravspesifikasjonen en utdypning av Vmware bildet, som beskrev krav til funksjonalitet grovt, mer detaljert ved behov. Arbeidsgiver hadde ingen endringer eller tilføringer på kravspesifikasjonen, og det eneste vi endret på var sammenslåing av funksjonalitet som var lik (Alle settings har akkurat samme rutiner). I slutten endret vi hvordan designet på tabeller så ut, men ellers ingenting.

Samsvar mellom spesifikasjon og produkt Vi mener vi har dekket de behov som er krevd i kravspesifikasjonen. Vi fikk implementert alt av funksjonalitet, og arbeidsgiver var også fornøyd med resultatet.

Om resultatet All dokumentasjon fra prosjektet ligger på CD‘en vi har levert. Her inkluderer Produktdokumentasjon(dette dokumentet), prosessdokumentasjon, testdokumentasjon og brukerveiledning.

Kildekode er også tilgjengelig på denne CD’en.

Vi har lagt ved “installasjonsveiledning” (OBS! Denne må ligge på en .NET server, vi har allerede lastet opp denne på HiO-serveren).

Avslutning og konklusjon Det har vært en god arbeidsprosess jevnt over. I starten slet vi med å komme i gang fordi vi syntes prosjektet var stort, og vi visste ikke helt hvor vi skulle begynne. Ettersom vi fikk gjennomgang av programmet og stilt spørsmål om funksjonalitet, fikk vi gradvis bedre oversikt, og etterhvert kunne vi starte med å skrive kravspesifikasjonen.

Vi måtte bruke en del tid på å sette oss inn i programmet, men siden det allerede eksisterte fra før ble det lettere å forsikre seg om at kravene stemte overens med ønsket resultat. Det var viktig at vi hadde planleggingsfasen, men vi så at tidsforbruket vi hadde satt av til dette var tilstrekkelig. Mer enn dette hadde vært bortkastet programmeringstid. Vi hadde en klar og tydelig plan som vi kunne referere til dersom vi lurte på når vi skulle bli ferdig med ulike faser.


54

Hva har vi lært Under prosjektperioden har vi lært at god planlegging resulterer som oftest med gode resultater. Vi har også funnet ut at antagelser av tidsforbruk ofte ikke stemmer overens med faktiske forbruk (Dette har gått begge veier).

Punktvis har vi lært at følgende er viktig i ett prosjektarbeid:

Grundig forarbeid

Om man står fast, spør andre om råd eller hjelp, eller søk på internett

Tydelige retningslinjer for kravspesifikasjon

Gruppen Innad i gruppen fikk vi god erfaring med bruk av Visual Studio og C#. Vi har lært masse nytt, blant annet AJAX og validering av felter. Vi har også påvist enda en gang at det viktigste når man lager ett program er programmeringen, med ett kraftig grunnlag i bunnen som forklarer hvordan ting skal se ut, og bygges opp. Vi har hatt ett godt samarbeid hele tiden.

Hva ville vi gjort annerledes? Dersom vi kunne startet på nytt, ville vi fokusert litt mer på enhetstesting.

Vi ville også jobbet mer i starten av prosjektet, men det er nok ytterst sjelden man kan se statistikker fra prosjekter som har mer gjort i starten enn i slutten. Vi føler ikke at tiden ikke strakk til, men de siste ukene har man alltids mer press på seg, og jobber dermed mer fokusert samtidig som man har lengre økter.

Samarbeidet med bedriften var godt, men gruppen kunne tatt mer initiativ til samarbeid med dem. Da hadde vi nok kunne tatt det litt roligere i sluttfasen (dokumenteringen).

Vi hadde også fokusert mer på utviklingen av en iPhone app. Fra dag én ønsket gruppen å gjøre dette, men ble dessverre prioritert ned fordi arbeidsgiver ønsket dette som noe vi skulle se på etter web-applikasjonen var ferdig, og så bra ut.

Fremtiden I fremtiden ser vi for oss at dette programmet erstatter tidligere program for selgere i Agresso. Dette vil da være ett av verktøyene selgere benytter daglig når de er i kontakt med kunder. Forhåpentligvis har vi laget ett program som er brukervennlig og forståelig, så applikasjonen er til hjelp og ikke til bry. Arbeidsgiver har imidlertidig gitt uttrykk for at applikasjonen er innenfor disse kategoriene, så vi har god tro på dette.

Vi sto til slutt igjen med et program som var fullt brukbart på HiO-serveren. Denne ble overlevert til Agresso. For å få programmet til å virke, må de integrere agrtid(Den interne variabelen i hver database som forteller hvor mange ganger ett element har blitt endret) i programmet. De må også endre noen små-innstillinger i programmet så de støttes med de interne databasene (Vårt program støtter HiO-databasen). Dette er i grove trekk små-fikser, og arbeidsgiver er klar over dette. Vi går også ut ifra at en av de ansatte skal gjennomgå koden og bekrefte at alt fungerer før det integreres og erstatter gammelt system. Det er ikke kritisk i første omgang, da de har eksisterende system i drift. Det samme gjelder ved senere anledninger, da selgere kan velge å benytte seg av gammel desktop- eller ny web-applikasjon (Begge programmene er kompatible med hverandre).


55


56

Testdokumentasjon

Under testdokumentasjon vil du finne en oversikt over testingen vi har utført på programmet


57

Forord Denne testdokumentasjonen er en del av bacheloroppgaven ved Høgskolen i Oslo, avdeling for ingeniørutdanning, i vårsemesterperioden 2011.

Dokumentet beskriver alle tester som er utført på systemet Prospect Explorer 2.0. Rapporten fungerer også som et viktig hjelpemiddel for andre utviklere som ønsker en oversikt over tidligere tester som er utført på systemet.


58


Tids- og Resursplan for testing ................................................................................................. 59

Intern testing ........................................................................................................................ 59

Ekstern testing ...................................................................................................................... 59

Tidsplanen ............................................................................................................................ 59

Intern testing ............................................................................................................................ 59

Testprosessen ....................................................................................................................... 59

Testrapporter ....................................................................................................................... 59

Test av funksjonalitet ....................................................................................................... 60

Ytelsestester ..................................................................................................................... 65

Nettleser test .................................................................................................................... 68

Sikkerhet ................................................................................................................................... 70

Passord sniffing .................................................................................................................... 70

SQL-injection ........................................................................................................................ 70

Cross Site Scripting (XSS) ...................................................................................................... 70

Konklusjon ................................................................................................................................ 71


59

Tids- og Resursplan for testing

Intern testing Den interne testingen har foregått fortløpende gjennom hele utviklingsprosessen. Etterhvert som deler av programmet ble ferdigstilt så har andre personer på gruppen fått i oppdrag å finne mangler/feil før vi har implementert det. De gangene vi kom over feil eller mangler så har disse blitt utbedret så fort som mulig.

Ekstern testing Vi har hatt jevnlig kontakt med selgerne som skal være brukerne av systemet, og på denne måten avdekket mangler som de kommer over og utbedret disse etter ønske fra dem.

Tidsplanen Vi har satt av 14 arbeidsdager for å kjøre tester på det endelige sluttproduktet. Gruppen følte at dette var tilstrekkelig med tid, siden mye av testingen ble utført underveis.

Intern testing Den interne testingen av systemet har blitt foretatt av gruppemedlemmene selv. Formålet med testing var å finne feil/mangler som har blitt forbigått i utviklingsprosessen og forsikre oss om at systemet tilfredsstiller alle krav som er satt.

Testprosessen Den interne testingen foregikk ved å fylle ut testrapporter som dekker alle funksjonene som systemet er påkrevd å ha. Resultatet har blitt markert med “OK” der systemet virker som det skal, og “ikke OK” hvis det har blitt avdekket en feil. Alle funksjoner som er merket “ikke OK” vil bli utbedret og beskrevet under testrapporten.

Testrapporter Vi kommer til å kjøre testen med følgende nettlesere: Firefox 4, Chrome, IE 8 og Opera. Vi kommer til å kjøre testen med følgende OS: Windows 7, Windows XP, OS X 10.6.7(kun Chrome og Firefox).

Den minste oppløsningen webapplikasjonen vår støtter er 1024x768. Dette er den laveste oppløsningen som normalt støttes av webapplikasjoner. Datamaskiner blir i dag levert med dette eller høyere oppløsning.

Hentet fra http://www.w3schools.com/browsers/browsers_display.asp

http://www.w3schools.com/browsers/browsers_display.asp


60

Test av funksjonalitet Testing har blitt gjennomført ved å gå punktvis gjennom tabellene vi har laget under. Hvor vi beskriver fremgangsmåten vi bruker for å teste funksjonen, samt resultatet.

Logg inn Funksjon Testet Resultat

Logge inn Logget inn med en selgers brukernavn/passord

OK

Logge inn med feil brukernavn / passord

Logget inn med korrekt brukernavn, men feil passord. Logget inn med feil brukernavn og feil passord

OK, men ingen feilmelding

Logge inn som admin Logget inn med en admin sitt brukeravn/passord

OK

Linker / Knapper / Dropdown list Funksjon Testet Resultat

Alle linker/knaper leder til riktig side.

Har fått testpersoner I tilleg til oss selv til å navigere seg rundt på siden og passet på at alle linker på alle sider fungerer og tar deg dit de skal.

OK

Alle knapper gir feilmelding dersom noe gikk galt.

Vi har gått systematisk gjennom alle knapper og lagt alle knapper til i en “Validation Group” for å validere input å gi korrekte feilmeldinger. Testpersonene våre har også testet forskjellige knapper.

OK

Dropdown endrer tilstanden når den velges

Droppdownlisten tar deg til den valgte tilstanden.

OK

Dropdown listen tar deg til den valgte tilstanden

Sjekket om man blir videreført til den ønskede siden man velger fra dropdown listen.

OK


61

Selger Funksjon Testet Resultat

Registrere ny selger La inn en ny selger via Users.aspx og sjekket at denne ble lagt til I databsen og vises I gridview.

OK

Registrere ny selger uten å fylle inn alle nødvendige data

Legger inn selger med informasjon og utelater forskjellige felter for å se om vi får feilmelding

OK

Unik personalia Legger til 2 selgere med same personalia og ser om vi får en feilmelding

OK

Oppdatere Selgerinformasjon

Velger en eksisterende selger, redigerer info og ser om det blir lagret i databasen

Avdeling Funksjon Testet Resultat

Registrere ny avdeling La inn en ny avdeling via Department.aspx, sjekket at denne ble lagt til i databasen og vises i gridview

OK

Registrere ny avdeling med feil/manglende data

Legger inn avdeling med feil/manglende data for å se om vi får feilmelding

OK

Unike avdelingsnavn Registrerer 2 avdelinger med samme navn for å se om vi får feilmelding

OK

Oppdatere avdeling Velger en eksisterende selger, endrer info og ser rom det blir lagret I databasen

OK


62

Modul Funksjon Testet Resultat

Registrere ny modul La inn en ny avdeling via Modules.aspx, sjekket at denne ble lagt til i databasen og vises i gridview

OK

Registrere ny Modul med feil/manglende data

Legger inn modul med feil/manglende data for å se om vi får feilmelding

OK

Unike modulnavn Registrerer 2 moduler med samme navn for å se om vi får feilmelding

OK

Oppdatere Modul Velger en eksisterende modul, endrer info og ser rom det blir lagret I database

OK

Bransje Funksjon Testet Resultat

Registrere ny bransje La inn en ny bransje via Branch.aspx, sjekket at denne ble lagt til i databasen og vises i gridview

OK

Registrere ny bransje med feil/manglende data

Legger inn en bransje med feil/manglende data for å se om vi får feilmelding

IKKE OK

Unike bransjenavn Registrer 2 moduler med samme navn for å se om vi får feilmelding

OK, men får ikke feilmelding.

Oppdatere bransje Velger en eksisterende branje, endrer info og ser rom den blir lagret I databasen

OK


63

Salgstype Funksjon Testet Resultat

Registrere ny salgstype La inn en ny salgstype via Salestype.aspx, sjekket at denne ble lagt til I database og vises I gridview

OK, men ingen melding om at den er lagt til

Registrere ny salgstype med feil/manglende data

Legger inn en salgstype med feil/manglende data for å se om vi får feilmelding

OK

Unike Salgstyper Registrerer 2 salgstyper med samme navn for å se om vi får feilmelding

OK, men får ingen feilmelding

Oppdatere Salgstype Velger en eksisterende salgstype, endrer info og ser rom den blir lagret I databasen

OK

Prospektstatuskode Funksjon Testet Resultat

Registrere ny prospektstatuskode

La inn en ny prospektstatuskode, sjekket at denne ble lagt til I database og vises I gridview

IKKE OK

Registrere prospektstatuskode med feil/manglende data

Legger inn en statuskode med feil/manglende data for å se om vi får feilmelding

IKKE OK

Unike statuskoder Registrerer 2 statuskoder med samme navn for å se om vi får feilmelding

IKKE OK

Oppdatere prospektstatuskode

Velger en eksisterende statuskode, endrer info og ser rom den blir lagret I databasen

IKKE OK


64

Database Funksjon Testet Resultat

Registrere ny Database La inn en ny database, sjekket at denne ble lagt til I databasen og vises I gridview

OK

Registrere en database med feil/manglende data

Legger inn en database med feil/manglende data for å se om vi får feilmelding

OK

Unike databaser Registrere 2 databaser med samme navn for å se om vi får feilmelding

OK

Oppdatere databaser Velger en eksisterende database, endrer info og ser rom den blir lagret I databasen

OK

Kilder Funksjon Testet Resultat

Registrere ny Kilde La inn en ny Kilde, sjekket at denne ble lagt til I database og vises I gridview

OK

Registrere en kilde med feil/manglende data

Legger inn en kilde med feil/manglende data for å se om vi får feilmelding

OK

Unike Kilder Registrerer 2 kilder med samme navn for å se om vi får feilmelding

OK

Oppdatere kilder Velger en eksisterende kilde, endrer info og ser rom den blir lagret I databasen

OK


65

Prospekter Funksjon Testet Resultat

Registrere nytt Prospekt La inn ett nyttprospekt, sjekket at dette ble lagt til I database og vises I gridview

OK

Registrere et prospekt med feil/manglende data

Legger inn et prospekt med feil/manglende data for å se om vi får feilmelding

IKKE OK

Unike prospekter Registrerer 2 prospekter med samme navn for å se om vi får feilmelding

IKKE OK

Oppdatere prospect Velger ett eksisterende prospekt, endrer info og ser rom den blir lagret I databasen

OK

De testene som feilet har blitt rettet opp og utbedret. Feilmeldinger ble lagt inn og vi har satt validering på de feltene som manglet dette.

Etter å ha kikket nærmere på prospektstatuscodes tabellen fant vi ut at denne må settes opp helt på nytt siden den ikke inneholdt noen nøkler. Denne tabellen har heller ikke vært mulig å endre i den tidligere versjonen av systemet.

Etter å ha gjennomført disse testene som var satt opp i forkant så fant vi også ut at inputfeltene ikke blir blanket ut etter man har oppdatert/lagt inn data.

Ytelsestester For å optimalisere siden vår har vi brukt en Add-On til Firefox 4.0 som heter YSlow. Dette er utviklet av yahoo og gir oss mye informasjon om hvilke elementer som er trege til å laste, og hva vi kan gjøre med dette.

Med litt justeringer etter å ha kjørt YSlow endte vi opp med en karakter på 80-85/100 på alle sidene våre. (Ref. figurer under)


66

Karakteren som YSlow gir blir regnet ut på denne måten (hentet fra YSlow sine FAQ sider):

“The grades for individual rules are computed differently depending on the rule. For example, for Rule 1, three external scripts are allowed. For each script above that, four points are deducted from the grade. The code for grading each rule is found in rules.js. The overall grade is a weighted average of the individual grades for each rule, calculated in controller.js The rules are approximately in order of importance, most important first. The specific weights are in the ruleset objects in rules.js. Rule weights of YSlow V2 Ruleset.”


67


68

Nettleser test For å forsikre oss om at siden vår fungerer i alle de mest populære nettleserne måtte vi prøve den i alle sammen.

Internet Explorer:

Forefox:


69

Chrome:

Opera:

Her ser vi at siden fungerer fint i de mest populære nettleserne. Det eneste som vises litt forskjellig er de avrundede kantene våre, som blir kantete i Opera og Internet Explorer.


70

Sikkerhet

Passord sniffing Siden webapplikasjonen skal kjøres internt hos agresso har vi, som nevnt tidligere, hatt fokus på funksjonalitet fremfor sikkerhet i første omgang.

Selv om den kjøres internt har vi utført sikkerhetstiltak pluss noen få tester for å forsikre oss om at det ikke skal være helt enkelt å plukke opp sensitiv informasjon fra webapplikasjonen. De testene vi har utført krever at personen som prøver å hente ut brukernavn/passord befinner seg på samme nettverket som personen som bruker systemet.

For å prøve ut dette har vi brukt et sniffeprogram som heter “Cain & Abel”. På bilde under ser man hvordan dette programmet enkelt plukker opp passord som sendes i klartekst:

Når vi kjørte denne snifferen opp moten webapplikasjonen vår så fikk den ikke hentet ut noe som helst.

SQL-injection Vi har beskyttet oss mot SQL-injection ved å legge til validering på alle tekst-/input-felter. En kjent svakhet er nedtrekkslister som kan endres til input-felter ved hjelp av visse verktøy. Vår validering sørger derimot for at alle felter fortsatt er av samme type (input/radioknapp/nedtrekksliste/osv) som da siden ble lastet. Hvis noen prøver å skrive inn ondsinnet kode, vil de få en feilmelding, eller i sistnevnte en server error:

Cross Site Scripting (XSS) Cross site scripting er når en bruker legger inn (som oftest ondsinnet) kode i form av scripts f.eks. i et input-felt til en database. Hver gang denne informasjonen fra databasen hentes (Dette kan eksempelvis være ett blogginlegg), vil også brukerens script kjøres samtidig.


71

Vi har også sikret oss mot denne svakheten ved å validere inputfelter, og sjekke at feltene er av samme type som da de ble lastet.

Konklusjon Ut ifra resultatet på de testene vi har kjørt var det noen små endringer som må gjøres, særlig når det gjelder feilmeldinger og validering. Sikkerhetsmessig føler vi at mange viktige tiltak er gjort for å hindre uvedkommende tilgang til informasjonen i systemet. En god grunn til dette er også sikkerheten som følger standard med .NET rammeverket.


72

Brukerdokumentasjon

Under brukerdokumentasjon vil du finne en guide/brukermanual som beskriver programmets

funksjonalitet og hvordan man bruker disse


73

Forord Dette dokumentet er brukerdokumentasjonen som er en del av hovedprosjektet utført ved Høgskolen i Oslo, avdeling for Ingeniørutdanning i vårsemester perioden 2011. Hovedprosjektet er blitt utført i samarbeid med Unit4 Agresso og har gått ut på å utvikle en ny versjon av programmet “Prospect Explorer” som selgerne i bedriften bruker til å holde oversikten over bedriftens prospekter. Denne brukerdokumentasjonen inneholder en brukerveiledning som beskriver hvordan man skal ta i bruk de forskjellige funksjonene webapplikasjonen Prospect Explorer tilbyr og er ment å fungere som et godt hjelpemiddel til brukerne av det. Brukerne av webapplikasjonen er begrenset. Det vil si at webapplikasjonen kun er tilgjengelig for ansatte hos Unit4 Agresso siden systemet kun er tilgjengelig på deres intranett. Leserne av denne brukerdokumentasjonen er alle brukere av systemet. Brukeren av systemet trenger ingen større IT-kompetanse for å lese denne manualen. Det er derimot forventet at brukeren har grunnleggende kunnskap om Microsoft sine operativsystemer.


74

Innholdsliste Forord .......................................................................................................................... 73

Installasjon................................................................................................................... 75

Funksjonskart .............................................................................................................. 76

Gridview .................................................................................................................. 77

Treeview .................................................................................................................. 77

Menylinje ................................................................................................................. 77

Brukerveiledning ......................................................................................................... 78

Tilgang og roller ....................................................................................................... 78

Innlogging ................................................................................................................ 78

Hjem vindu .............................................................................................................. 79

Settings .................................................................................................................... 80

Instruksjon for Selger/Salgsleder ............................................................................ 84

Oppdater prospekt .............................................................................................. 84

Legge til ny selger ................................................................................................ 84

Tree-view ............................................................................................................. 84

Grid-view ............................................................................................................. 85


75

Installasjon Programmet kan kjøres fra .net server, eller lokalt. For instruksjoner om hvordan å kjøre applikasjonen lokalt se: Vedlegget om IIS oppsett

Det følger også med instruksjoner på CD´en programmet ligger på.

Web-applikasjonen finner man også på denne adressen: http://dotnet.iu.hio.no/s155495/

http://dotnet.iu.hio.no/s155495/


76

Funksjonskart

Kartet forteller hvilke funksjoner som er tilgjengelige ved hjelp av de 3 hovedelementene i webapplikasjonen.


77

Gridview Gridview sin hovedoppgave er utskrift av data. Den viser informasjonen som er lagret i databasen om de forskjellige prospektene, alt etter hvordan du velger å sortere dataene.

Treeview Treeview brukes for å filtrere ut den informasjonen man ikke er interessert i fra gridview. I denne tre-menyen kan man filtrere dataene etter avdeling eller person

Menylinje Kartet viser hvilke funksjoner som er tilgjengelige fra menylinjen. Herifra kan du navigere deg inn i settingsdelen av programmet, oppdatere den gjeldende siden og få eksportert dataen som ligger i gridview til Excel.

Gridview 1

Treeview 1


78

Brukerveiledning

Tilgang og roller Avhengig av om brukeren er administrator eller ikke, vil man ha tilgang til forskjellige grader av funksjonalitet i websiden. De forskjellige rollene bestemmer hvilke data som vises og hva brukeren kan gjøre endringer på.

Admin vil kunne legge til/oppdatere info i alle settings delene.

En vanlig bruker vil kun ha mulighet til å oppdatere sine egne prospekter.

Innlogging Siden Prospect Explorer kun er tilgjengelig på Agresso sitt intranett, så er det kun ansatte som er logget inn på dette nettverket som har tilgang til webapplikasjonen. I tillegg må personen som prøver å logge seg inn ha ett gyldig brukernavn og passord.

Innlogging 1

Skulle det være ønskelig å jobbe hjemme eller andre steder enn Agresso, så må personen ha installert VPN for å få tilgang til applikasjonen (Høgskolens servere er ett unntak).


79

Hjem vindu

Hjem-vindu 1

1. Eksporter til Excel knapp 2. Oppdater side knapp 3. Knapp som tar deg videre til “settings” 4. Dropdownliste som lar deg velge programmets tilstand 5. Dropdownliste for å velge hvilket år du vil vise prospekter fra 6. Viser hvilke kriterier som er satt for sorteringen av data i gridview 7. Viser informasjon om pålogget bruker 8. Lister opp de forskjellige avdelingene/brukerne det er mulig å sortere etter 9. Gridview – Utskriftsområde for sortert data. 10. Statusfelt

Eksporter til Excel Denne knappen vil eksportere den synlige griden til en “.csv” fil som er leselig i Excel.

Oppdater Fungerer på samme måte som oppdater knappen man finner i de fleste nettlesere, altså at den oppdaterer/laster siden på nytt.


80

Settings Når man er logget inn som admin har man tilgang til hele ”settings” delen av systemet, deler av denne vil ikke vises dersom du er logget in som vanlig bruker.

i setting har du mulighet til å endre/legge til nye data i databasen. Man har forskjellige valg når man kommer inn på setting (disse tar for seg hver sin tabell i databasen).

Selgere For å redigere eksisterende brukere benyttes ”edit” knappen som man finner på venstre side av gridview. Ved å trykke på denne åpnes alle felter som er mulig å endre på til redigering. Når admin har endret de feltene han ønsker, klikker man på update (til venstre for feltene) for å legge inn de nye verdiene. For å legge til nye selgere trykker man på ”Ny Selger”. Da vises de feltene som er nødvendig å fylle ut for å legge til en ny selger.

Selger 1

Settings 1


81

Avdelinger For å redigere eksisterende avdelinger benyttes ”edit” knappen som man finner på venstre side av gridview. Ved å trykke på denne åpnes alle felter som er mulig å endre på til redigering. Når admin har endret de feltene han ønsker, klikker man på update (til venstre for feltene) for å legge inn de nye verdiene. For å legge til nye selgere trykker man på ”Ny Avdeling”. Da vises de feltene som er nødvendig å fylle ut for å legge til en ny avdeling.

Avdeling 1

Modules, Branches, Sales type, Prospect status codes, Databases og Sources For å endre eksisterende data, bruker man samme fremgangsmåte som i Selgere og Avdelinger. Dersom man skal legge inn noe nytt, fyller man ut feltene som vises når man trykker ”Ny Modul/Bransje/osv”. Videre må du velge status som sier om den nye dataen skal vises som ”aktiv” eller ikke.

(Modules. Modules, Branches, Salestype, Prospect status codes, Databases og Sources har omtrent identisk utseende)

Modul 1


82

Prospect Under “Add Prospect” fyller brukeren ut de feltene som vises med den infoen som det blir spurt etter. Noen av feltene hentes ut fra databasen, og velges fra droppdown list.

Prospekt 1

Dropdown (Type)– Prospekt/Budsjett/Prognose

Dropdown (Type) 1

Dropdownlisten man finner i menylinjen har 3 valgmuligheter, Prospekt, Budsjett og Prognose. Disse valgene bestemmer hvilken tilstand du ønsker å sette programmet i.

Prospekt viser lagrede prospekter for den valgte selger/avdeling i tre-menyen. Den viser disse ved å oppdatere innholdet i Content Place Holderen som viser gridview.

Budsjett tilstanden viser en oversikt over en valgt selger/avdeling for det gitte året. Her vises totalen helt til venstre og listet mot høyre finner du tallene for 1,2,3 og 4 kvartal.

Prognose viser utregningene for en avdeling/selger for det gitte året. Her er dataene delt opp i 5 kolonner (Virkelig, Prospect, SUM, Budsjett og Avvik) og 5 rader (Lisens, Vedlikehold, Tjenester, Annet og SUM). Også her vises det en individuell utregning for hvert kvartal.


83

Dropdown (År)

Dropdown (År) 1

Den verdien som velges her bestemmer hvilket år verdiene som vises på skjermen gjelder for. Denne sorteringen må brukes sammen med et valg fra tre-menyen for å få skrevet ut data.

Aktive kriterier Helt til høyre på menylinjen finner vi informasjon om hvilke filter som er aktive. Den lister altså hvilket år som er valgt og hvilken bruker/avdeling som vises.

Header Headeren på websiden viser informasjon om hvilken bruker som er logget på, hvilken ID denne brukeren har og hvilke rettigheter personen har. I tillegg til dette vises navnet på siden, og logoen til bedriften vi har utviklet den for.

Header 1

Skulle brukeren ønske å skjule headeren grunnet liten skjerm/lav oppløsning etc. kan han/hun benytte knappen øverst til venstre som heter “skjul header”.


84

Header 2

Instruksjon for Selger/Salgsleder En innlogget selger har tilgang til hovedfunksjonaliteten i programmet. Dvs. personen kan sortere utskriften i gridview ved hjelp av tre-menyen på venstresiden. Selgeren vil også kunne endre informasjonen som er lagret i de prospektene der han/hun er listet som eier. Her har salgslederen tilgang til alle prospektene som er registrert under den avdelingen som han/hun er leder for.

Oppdater prospekt For å oppdatere infoen til ett prospekt klikker man på “Rediger” knappen som finner til på venstresiden av prospectlisten. Da vil man bli videresendt til ett ferdig registreringsskjema og brukeren kan endre ønsket informasjon for så å klikke “Oppdater”. Når dette er gjort vil prospektet vises i listen med oppdatert informasjon.

Legge til ny selger For å få lagt til en ny selger må du enten være admin eller salgsleder for den avdelingen selgeren skal legges til i.

1. Klikk settingsknappen på menylinjen 2. Klikk på linken som heter “Selgere” 3. Klikk på “Ny Selger” 4. Fyll inn påkrevd informasjon 5. Klikk “Legg til” knappen for å lagre den nye selgeren i databasen

Tree-view Ved hjelp av denne menyen kan selgeren sortere de ulike prospektene ut ifra forskjellige betingelser. Den er delt opp i de forskjellige avdelingene, og under hver avdeling finner man selgerne som tilhører den avdelingen. Trykker man på en avdeling så listes alle gjeldende prospekter i denne avdelingen, det samme gjelder om man trykker på en selger. Akkurat som Header, kan denne menyen også skjules ved å benytte link helt på toppen av siden. (se bilde til venstre, Treeview 2)

Treeview 2


85

Grid-view Grid-viewen er den delen av siden som opptar mest plass på skjermen. Den viser den informasjonen man ønsker sortert ved hjelp av tre-menyen for de tre hovedvinduene prospekt, budsjett og prognose. Selgere kan også redigere informasjonen i de forskjellige prospektene direkte i grid-view dersom de er listet som eiere av dette prospektet.

For å få redigert de eksisterende feltene i et prospekt må selgeren trykke på ”edit” knappen for at feltene skal åpne seg. Når ønsket data er endret trykker man på ”oppdater” for å lagre endringene som er gjort.

Gridview 2


86

Kravspesifikasjon

Under produktdokumentasjon vil du finne dokumentasjon som forklarer oppbygning og

struktur av programmet.


87

Forord

Dette dokumentet gir en kort beskrivelse av oppdragsgiver og bakgrunn for prosjektet. I tillegg skal kravspesifikasjonen utrede hvilke krav, rammebetingelser og funksjoner løsningen skal inneholde.

Hensikten med kravspesifikasjonen er å gi en grundig beskrivelse av funksjoner og krav til løsningen som oppdragsgiver og gruppen i samråd har kommet frem til. Videre skal dokumentet inngå som en del av styringsdokumentasjonen og dermed fungere som en veiledning for gruppen i utviklingsarbeidet.


88


1 Leseveiledning ................................................................................................................... 89

2 Innledning ......................................................................................................................... 90

2.1 Om bedriften ................................................................................................................. 90

2.2 Bakgrunn for prosjektet ................................................................................................ 90

2.3 Dagens situasjon............................................................................................................ 90

3 Krav ................................................................................................................................... 91

3.1 Funksjonelle krav ........................................................................................................... 91

3.1.1 Bruker/Selger krav ................................................................................................. 91

3.1.2 Administrator/Leder krav ...................................................................................... 91

3.1.3 Brukstilfeller (Use-Case Model) – Oversikt ........................................................... 91

3.1.4 Forutsetninger og avhengigheter .......................................................................... 93

3.1.5 Detaljert beskrivelse av utvalgte Use Case ............................................................ 93

3.2 Ikke – funksjonelle krav ............................................................................................... 105

3.2.1 Tekniske krav ........................................................................................................ 105

3.2.2 Krav til sikkerhet .................................................................................................. 105

3.2.3 Krav til brukervennlighet og design ..................................................................... 105

3.2.4 Krav til vedlikeholdbarhet og videreutvikling ...................................................... 105

4 Dokumentasjon ............................................................................................................... 106


89

1 Leseveiledning

Kapittel 2 er en presentasjonsdel i dokumentet. Kapittelet vil gi en overordnet beskrivelse av oppdragsgiver, bakgrunnen for oppgaven, samt dagens situasjon.

I kapittel 3 vil gå igjennom de forskjellige kravene vi og oppdragsgiver har til løsningen. Vi har tre kategorier av krav, funksjonelle og ikke-funksjonelle krav, samt ønskede krav. Her kan det forekomme ord som kan være uforståelig for lite datakyndige personer, derfor er det laget en ordforklarings liste bakerst i dokumentet.

Kapittel 4 forklarer kravene til dokumentasjon.


90

2 Innledning

2.1 Om bedriften

UNIT4 Agresso AS leverer ERP-system, økonomisystem og HR - system for Lønn og Personal med tilhørende konsulenttjenester og kundeservice til det norske markedet. Sammen med sine partnere betjener selskapet ca. 800 kunder i Norge. UNIT4 Agresso AS trenger derfor et solid system for å ha oversikt og vedlikeholde prospektene som bedriften har.

2.2 Bakgrunn for prosjektet

Et av gruppemedlemmene har en slektning som er ansatt i UNIT4 Agresso A/S. Vi ble derfor enig innad i gruppen om å forhøre oss om det kunne være interessant for bedriften å ha et møte med oss for å finne en passende oppgave. I løpet av møtet kom vi til enighet om en oppgave som passet gruppen og bedriften.

2.3 Dagens situasjon

Selskapet har i dag et program som er utdatert og vanskelig å vedlikeholde da det er laget i 2001. De ønsket derfor at dette skulle utvikles på nytt i en mer moderne plattform. I tillegg er dagens program en desktop-applikasjon og det er ønskelig med en løsning på web, da mange av brukerne ofte er ute på oppdrag.


91

3 Krav

3.1 Funksjonelle krav

3.1.1 Bruker/Selger krav

Selger skal kunne logge inn Selger skal kunne vise alle prospekter Selger skal kunne redigere egne prospekter Selger skal kunne legge til nye prospekter Selger skal kunne endre egen brukerinformasjon inkl passord Selger skal kunne liste alle registrerte avdelinger Selger skal kunne eksportere ønsket tabell til MS Excel

3.1.2 Administrator/Leder krav

Administrator/Leder skal kunne logge inn Administrator/Leder skal kunne vise alle prospekter Administrator/Leder skal kunne redigere alle prospekter Administrator/Leder skal kunne legge til nye prospekter Administrator/Leder skal kunne endre brukerinformasjon på alle registrerte selgere. Administrator/Leder skal kunne registrere ny selger Administrator/Leder skal kunne liste alle registrerte avdelinger Administrator/Leder skal kunne registrere ny avdeling Administrator/Leder skal kunne deaktivere en selger Administrator/Leder skal kunne eksportere ønsket tabell til MS Excel

3.1.3 Brukstilfeller (Use-Case Model) – Oversikt

Vi bruker Use Case til å beskrive systemets funksjonalitet. Systemet består kun av to aktører, selger og administrator.


92

Tabell 1: Beskrivelse av alle Use Case.

Brukstilfelle Aktører Beskrivelse

Vis prospekt(er) Selger/Leder En selger får opp info om

Prospekt(er) i en tabell

Registrere et nytt prospekt Selger/Leder Legger til et nytt prospekt i databasen

Endre prospekt(er) Selger/Leder Endre detaljinformasjon på prospekt(er). Leder kan endre alle prospekter. Selger kan endre sine egne prospekter.

Endre egen info Selger/Leder Alle brukere av systemet skal kunne endre info om seg selv. Ledere har rettigheter til å endre alle sin info.

Skrive ut data til Excel Selger/Leder Skrive ut data fra tabell til ett MS Excel dokument.

Søke etter prospekt Selger/Leder Finne info om forskjellige prospekter.

Registrere selger Leder Legge til ny selger.

Deaktivere selger Leder Deaktivere en selger ved oppsigelse (Salg som selgeren har utført skal fortsatt stå registrert på han).

Søke etter en Selger Leder Finne info om selgere.

Endre passord Selger/Leder En Selger/Leder skal kunne endre passord på sin bruker.

Registrere avdeling Leder En leder skal kunne registrere en ny avdeling.

Vis Selger Selger/Leder En bruker skal kunne liste alle registrerte selgere

Vis Avdeling Selger/Leder En bruker skal kunne liste ale registrerte avdelinger

Endre Avdeling Leder En Leder skal kunne endre informasjon om en avdeling


93

3.1.4 Forutsetninger og avhengigheter

For å kunne bruke systemet må brukeren være logget inn med brukernavn og passord. Systemet må være koblet til internett ved bruk.

3.1.5 Detaljert beskrivelse av utvalgte Use Case

Tabell 2: Detaljert beskrivelse av Vis Prospekt

Vis

Prospekt En bruker viser prospekt(er) relativt til valgt menyobjekt

Primære aktører

Selger / Leder

Interessenter Ingen

Prioritet Må kunne finne prospektet hvis det eksisterer.

Må komme med passende feilmelding hvis prospektene ikke finnes.

Må være enkelt nok til at alle kan bruke det uten opplæring.

Henter info fra database med filter i henhold til valg fra liste (årstall, innlogget bruker, avdeling) og type visning som er valgt.

Åpne spørsmål


94

Flyt Bruker logger seg inn, velger avdeling:

Viser prospekter for valgt avdeling

Bruker velger selger:

Viser prospekter for valgt selger

Bruker velger årstall:

Viser prospekter med valgt estimert år

Bruker velger årstall og avdeling:

Viser prospekter med valgt estimert år og tilhørende valgt avdeling

Bruker velger årstall og selger:

Viser prospekter med valgt estimert år og tilhørende valgt selger


95

Tabell 3: Detaljert beskrivelse av Registrer nytt Prospekt

Registrer

Prospekt En selger/leder registrerer et prospekt

Primære aktører

Selger / Leder

Interessenter At den sentrale databasens integritet blir opprettholdt

Prioritet Må kunne registrere nytt prospekt, hvordan kunde dette er og hvem som har ansvaret for den.

Må være enkelt nok slik at selger har liten mulighet for å kunne taste feil.

Prospektet skal få et unikt prospektNr og bli lagt til i databasen.

Må bekrefte registrering.

Åpne spørsmål

Flyt 1. Bruker logger inn

2. Bruker går inn på "settings" – siden

3. Bruker velger Prospect

4. Bruker velger Nytt Prospect

5. Bruker fyller inn nødvendige verdier

6. Bruker trykker "Legg til"

7. Verdiene legges til i databasen og de veide feltene regnes ut ifra inntastede verdier.

8. Bruker får beskjed om at innleggingen er OK eller en passende feilmelding.


96

Tabell 4: Detaljert beskrivelse av Endre Prospekt

Endre Prospekt

En selger/leder ønsker å redigere et eksiterende prospekt

Primære aktører

Selger / Leder


Prioritet Må kunne endre prospekt, hvordan kunde dette er og hvem som har ansvaret for den.

Må være enkelt nok slik at selger har liten mulighet for å kunne taste feil.

Prospektet skal beholde unikt prospektNr og bli oppdatert i databasen.

Må bekrefte oppdatering.

Åpne spørsmål

Flyt 1. Bruker logger seg inn

2. Finner ønsket prospekt. Beskrevet i Tabell 2

3. Trykker "Rediger" i tabellen for ønsket prospekt

4. Verdifeltene i tabellen blir da mulige å endre på

5. Bruker fyller inn ønskede verdier

6. Bruker trykker "Lagre oppdatering"

7. De nye verdiene blir oppdatert i databasen

8. Bruker får beskjed om at oppdateringen er OK


97

Tabell 5: Detaljert beskrivelse av Vis Selger

Finn Selger/Vis Selger

En selger/Leder ønsker å finne en Selger

Primære aktører Selger/Leder


Prioritet Må kunne vise alle registrerte selgere/Ledere

Må være enkelt nok slik at selger/Leder har liten mulighet for å kunne taste feil.

Åpne spørsmål


2. Velger "Settings" - siden

3. Velger Selger/User

4. Alle registrerte brukere vises nå i en liste


98

Tabell 6: Detaljert beskrivelse av Registrer ny Selger.

Registrere ny Selger

En Leder ønsker å legge til en ny Selger





Må få beskjed at registreringen er OK

Åpne spørsmål





5. Bruker velger knappen "Ny selger"

6. Tekstfelter kommer til syne og bruker begynner å skrive inn ønskede verdier

7. Bruker trykker "Lagre"

8. Får beskjed om at Selgeren er registrert.


99

Tabell 7: Detaljert beskrivelse av Rediger Selger.

Endre brukerinformasjon

En Selger/Leder ønsker å endre informasjon om en registrert bruker





Må få beskjed at oppdateringen er OK

Åpne spørsmål





5. Velger ønsket selger i listen som skal redigeres.

6. Trykker "rediger"

7. Bruker får da opp nåværende verdier i tekstfelt og kan redigere de verdiene som ønsket.

8. Bruker trykker "Oppdater"

9. Bruker får beskjed om at ønsket bruker er oppdatert.


100

Tabell 8: Detaljert beskrivelse av Eksporter til MS Excel

Eksportere til MS Excel

En Selger/Leder ønsker å eksportere en tabell til MS Excel


Interessenter

Prioritet Må kunne vise alle registrerte selgere/Ledere, Prospekt, Avdelinger osv.


MS Excel må åpnes automatisk

Åpne spørsmål


2. Bruker velger ønsket tabell, Vis Prospekt, Vis Selgere, Vis Avdeliger osv.

3. Bruker trykker på MS Excel symbolet

4. MS Excel skal da starte automatisk og ønskede verdier vises nå i MS Excel


101

Tabell 9: Detaljert beskrivelse av Deaktiver Selger

Deaktivere Selger

En Selger/Leder ønsker å endre status på selger fra Aktiv til Inaktive






Åpne spørsmål





5. Velger ønsket selger i listen som skal redigeres.



8. Bruker endrer status fra Aktiv til Inaktiv


10. Bruker får beskjed om at ønsket bruker er oppdatert.


102

Tabell 10: Detaljert beskrivelse av Vis Avdeling

Vis Avdeling

En selger/Leder ønsker å liste alle registrerte avdelinger



Prioritet Må kunne vise alle registrerte Avdelinger


Åpne spørsmål



3. Velger Avdeling

4. Alle registrerte avdelinger vises nå i en liste


103

Tabell 11: Detaljert beskrivelse av Legg til ny avdeling

Registrere ny Avdeling

En Leder ønsker å legge til en ny Avdeling





Må få beskjed at registreringen er OK

Åpne spørsmål



3. Velger Avdeling

4. Alle registrerte Avdelinger vises nå i en liste

5. Bruker velger knappen "Ny avdelingr"

6. Tekstfelter kommer til syne og bruker begynner å skrive inn ønskede verdier

7. Bruker trykker "Lagre"

8. Får beskjed om at Avdelingen er registrert.


104

Tabell 12: Detaljert beskrivelse av endre avdeling

Endre avdelingsinformasjon

En Selger/Leder ønsker å endre informasjon om en registrert avdeling






Åpne spørsmål



3. Velger avdeling

4. Alle registrerte avdelinger vises nå i en liste

5. Velger ønsket avdeling i listen som skal redigeres.




9. Bruker får beskjed om at ønsket avdeling er oppdatert.


105

3.2 Ikke – funksjonelle krav

3.2.1 Tekniske krav

Løsningen skal lages i Visual Studio 2010 i C#.

Det ytre laget (GUI) skal være på norsk.

Systemet skal gi forklarende statusmeldinger.

Systemet skal vises feilfritt i kjente nettlesere som Internet Explorer, Mozilla Firefox, Chrome og Safari.

Vi bruker C#, AJAX, XHTML, CSS, og noe JQuery.

3.2.2 Krav til sikkerhet

Applikasjonen er laget for web og da er vanligvis høye krav til sikkerhet. Men oppdragsgiver skal kjøre applikasjonen innad i nettverket til bedriften, og der er det allerede implementert gode sikkerhetsløsninger og dermed er ikke sikkerhet en så viktig faktor for oss. Vi har implementert en "log inn" funksjon. Denne funksjonen fungerer mest som en logg/signatur og for å skille mellom våre to tilgangsnivåer som er Selger og Leder/Administrator.

3.2.3 Krav til brukervennlighet og design

Systemet skal være intuitivt og sikkert. Samtidig skal det være lav læringskurve, skal kunne brukes med tilnærmet ingen opplæring av personer med tidligere kjennskap til systemet. Det skal også være mulig å alternere mellom stiler, for eksempel enkel visning uten header og meny, widescreen osv.

3.2.4 Krav til vedlikeholdbarhet og videreutvikling

Løsningen skal være relativt enkel å vedlikeholde og videreutvikle. Det skal samtidig være mulig å lage en desktop – applikajson om dette er ønskelig. Dette gjøres ved å dokumentere hver enkelt metode samtidig som vi lagdeler applikasjonen med Business Logic Layer(BLL), Data Access Layer(DAL) og Model. Dermed kan man bruke de samme metodene i annen applikasjon.


106

4 Dokumentasjon

På datalinjen er det fastsatt en dokumentasjonsstandard for hovedprosjekter. Denne standarden skal normalt følges. Prosjektgruppen avtaler med sin veileder hva som ellers skal lages av dokumentasjon. (http://www.iu.hio.no/data/hovedprosjekt/student/prosjektrapport.html) av Ann-Mari

Torvatn.

Vi kommer til å bruke denne standarden i dokumentasjonsarbeidet. Diverse andre styringsdokumenter leses selvstendig og legges ut på vårt hjemmeområde (http://student.iu.hio.no/~s155495/Hovedprosjekt/forside.php).


107

Vedlegg- Databaseforklaring I de fleste tabellene er det et felt som het agrtid. Dette viste seg å være en måte Agresso hold styr på hvor mange ganger en rad hadde blitt oppdatert. Denne skulle vi bare se bort ifra, da den måtte innom interne rutiner i Agresso som vi ikke hadde tilgang til. Derfor ser vi bort ifra dokumentasjon på agrtid i database tabellene.

Branch Dette er en database som lagrer bransjer som er i bruk.

Alle de ulike bransjene lagres med forskjellige ider i BranchID feltet

Her er det generelt kun informasjon om bransjen i feltene:

Description

LastUpdate

Sign

Også er det Status feltet som avgjør om bransjen er i bruk.

Databases Dette er en database som lagrer databasene som er i bruk.

Alle de ulike databasene lagres med forskjellige ider i DatabaseID feltet.

Her er det generelt kun informasjon om databasen i feltene:

Description

LastUpdate

Sign

Også er det Status feltet som avgjør om bransjen er i bruk.

Department Dette er en database som lagrer generell informasjon om avdelingen

Alle de ulike avdelingene lagres med forskjellige ider i DepartmentID feltet.

Her er det 4 felter som sier hvor mye som er beregnet i hvert kvartal og disse feltene er:

BudQ1

BudQ2

BudQ3

BudQ4

Videre i department er det også de feltene der den generelle informasjonen lagres, og disse

feltene er:

Manager

Name

TreeSortCode

Det er også et felt som lagrer om avdelingen er i bruk, dette er da feltet Status.


108

DepartmentBudget I denne databasen lagres det informasjon om avdelings budsjettet.

Her viser feltet DepartmentID til hvilken avdeling budsjettet gjelder.

Quarter feltet viser til hvilket kvartal avdelings budsjettet gjelder.

Disse feltene beskriver de ulike salgs opplysningene

Maintenance

License

Services

ThirdParty

Year feltet viser hvilket år avdelings budsjettet gjelder.

Modules Dette er en database som lagrer informasjonen om de forskjellige modulene.

Alle de ulike modulene blir lagret i ModuleID feltet

Her er det generelt kun informasjon om modulen i feltene:

Description

LastUpdate

Sign

Også er det Status feltet som avgjør om modulen er i bruk.

Prospect Her er det informasjonen om de forskjellige prospektene blir lagret.

Alle de ulike prospektene blir lagret med forskjellige ider i ProspectID feltet

Felter som henter IDer fra andre databaser:

AgressoCustID

BranchID

DatabaseID

HeasCustID

SalespersonID

SalesTypeID

SourceID

Dato relaterte felter:

EndDate

EstMonth

EstYear

StartDate

Disse feltene beskriver de ulike salgs opplysningene:

xConsult

xDatabaseValue

xLicense

xLicenseThirdP

xmaintenance

xMainThirdP


109

xManagedServices

xSupport

xSupportThirdP

xTotal

xTraining

LicenseValue

MaintenanceValue

DatabaseValue

ExtraValue1

ExtraValue2

OtherValue

SalesLicValue

SalesMaintValue

LicenseThirdP

MaintThridP

SupportThridP

Felter som omhandler informasjon prospektene:

Comment

Consult

Customization

Sign

Support

Training

Name

Installation

Likelihood

LostTo

DepLikelihood

ManagedServices

SaleType2

Status feltet som avgjør om prospektet er i bruk.

ProspectType viser hvordan prospekt type det er.


110

ProspectStatus I denne databasen lagres det informasjon om prospekt satusene

Her er det generelt kun informasjon om prospekt status i feltene:

Description

LastUpdate

Sign

Også er det Status feltet som avgjør om prospekt er i bruk.

SalesBudget Dette er en database som lagrer informasjon om de forskjellige salgs budsjettene

SalesPersonID feltet viser til hvilken salgs person som er ansvarlig for dette salgs budsjettet.

Quarter feltet viser til hvilket kvartal salgs budsjettet gjelder.

Disse feltene beskriver de ulike salgs opplysningene

Maintenance

License

Services

ThirdParty

Year feltet viser hvilket år avdelings salgs budsjettet.

SalesPerson Dette er en database som lagrer informasjon om de forskjellige salgs personene

Alle salgs personene blir lagret i SalesPersonID feltet

DepartmentID feltet viset til hvilken avdeling salgs personen tilhører.

Her er det generelt kun informasjon om salgs person i feltene:

FirstName

LastName

LastUpdate

OSUser

Password

Sign

Også er det Status feltet som avgjør om modulen er i bruk og IsAdministrator feltet viser

om brukeren er administrator.

SaleType Dette er en database som lagrer informasjonen om de forskjellige salgs typene.

Alle de ulike modulene blir lagret i SaleTypeID feltet

Her er det generelt kun informasjon om salgs type i feltene:

Description

LastUpdate

Sign

Også er det Status feltet som avgjør om salgs type er i bruk.


111

Source Dette er en database som lagrer informasjonen om de forskjellige kildene.

Alle de ulike modulene blir lagret i SourceID feltet

Her er det generelt kun informasjon kildene i feltene:

Description

LastUpdate

Sign

Også er det Status feltet som avgjør om kildene er i bruk.


112

Vedlegg - Database CREATE scripts Disse er generert via Microsoft SQL server 2008 R2, fra kopi av database vi har fått av Agresso.

Videre er disse redigert manuelt av gruppen for å kunne kjøres på HiO serveren.

Branch USE `s155495`; CREATE TABLE IF NOT EXISTS `Branch`( `BranchID` int NOT NULL, `Descreption` varchar(50) NOT NULL, `LastUpdate` datetime NOT NULL, `ModuleID` int NOT NULL, `Sign` varchar(50) NOT NULL, `Status` int NOT NULL, àgrtid` bigint NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ; INSERT INTO `Branch` (`BranchID`, `Descreption`, `LastUpdate`, `ModuleID`,`Sign`, `Status`, àgrtid`) VALUES (1, 'Økonomi', CAST(0x000091B000C8D480 AS DateTime), 20, 'okonom',1,1), (2, 'Logistikk', CAST(0x000091B000C8D480 AS DateTime), 21, 'logisti',1,2), (3, 'Lønn/personal', CAST(0x000091B000C8D480 AS DateTime), 22, 'lonnpers',1,3), (4, 'Verktøy', CAST(0x000091B000C8D480 AS DateTime), 23, 'verktø', 1,4), (5, 'Budsjett', CAST(0x000091B000C8D480 AS DateTime), 24, 'budsje',1,5);

Databases use `s155495`; CREATE TABLE IF NOT EXISTS `Databases`( `Description` varchar(50) NOT NULL, `LastUpdate` datetime NOT NULL, `DatabaseID` int NOT NULL, `Sign` varchar(50) NOT NULL, `Status` int NOT NULL, àgrtid` bigint NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ;


113

INSERT INTO `Database` (`Description`, `LastUpdate`, `DatabaseID`, `Sign`, `Status`, àgrtid`) VALUES ('Oracle', CAST(0x000091B000CD107C AS DateTime), N'Jarstein, Trond', N'1', 1) ('MS SQL Server', CAST(0x000091B000CD107C AS DateTime), N'Jarstein, Trond', N'1', 2)

Department use `s155495`; CREATE TABLE IF NOT EXISTS `Databases`( `BudQ1` int NOT NULL, `BudQ2` int NOT NULL, `BudQ3` int NOT NULL, `BudQ4` int NOT NULL, `DepartmentID` int NOT NULL, `Manager` int NOT NULL, `Name` varchar(50) NOT NULL, `Status` int NOT NULL, `TreeSortCode` int NOT NULL, àgrtid` bigint NOT NULL, ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ; INSERT INTO `Department` (`BudQ1`, `BudQ2`, `BudQ3`, `BudQ4`, `DepartmentID`, `Manager`, `Name`, `Status`, `TreeSortCode`, àgrtid`) VALUES (15, 30, 20, 35, 1, 3, N'Privat', 1, 1, 1), (15, 30, 20, 35, 6, 0, N'Spørrebrukere', 1, 4, 2), (15, 30, 20, 35, 7, 23, N'Danmark', 0, 3, 3), (15, 30, 20, 35, 8, 3, N'Løsningsarkitekter', 1, 5, 4), (20, 25, 20, 35, 9, 22, N'Kundeutvikling', 0, 6, 5), (10, 35, 15, 40, 10, 28, N'Offentlig', 1, 2, 6), (20, 20, 20, 40, 11, 94, N' ', 1, 0, 7), (40, 20, 20, 20, 12, 94, N'Produkt', 1, 0, 8);

DepartmentBudget use `s155495`; CREATE TABLE IF NOT EXISTS `DepartmentBudget`( `DepartmentID` int NOT NULL, `License` decimal(28, 8) NOT NULL, `Maintenance` decimal(28, 8) NOT NULL, `Quarter` int NOT NULL, `Services` decimal(28, 8) NOT NULL, `ThirdParty` decimal(28, 8) NOT NULL, `Year` int NOT NULL,


114

`agrtid` bigint NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35; INSERT INTO `PE_DepartmentBudget` (`DepartmentID`, `License`, `Maintenance`, `Quarter`, `Services`, `ThirdParty`, `Year`, `agrtid`) VALUES (1, CAST(3757500.00000000 AS Decimal(28, 8)), CAST(864225.00000000 AS Decimal(28, 8)), 1, CAST(690750.00000000 AS Decimal(28, 8)), CAST(312750.00000000 AS Decimal(28, 8)), 2010, 1), (1, CAST(7515000.00000000 AS Decimal(28, 8)), CAST(1728450.00000000 AS Decimal(28, 8)), 2, CAST(1381500.00000000 AS Decimal(28, 8)), CAST(625500.00000000 AS Decimal(28, 8)), 2010, 2), (1, CAST(5010000.00000000 AS Decimal(28, 8)), CAST(1152300.00000000 AS Decimal(28, 8)), 3, CAST(921000.00000000 AS Decimal(28, 8)), CAST(417000.00000000 AS Decimal(28, 8)), 2010, 3), (1, CAST(8767500.00000000 AS Decimal(28, 8)), CAST(2016525.00000000 AS Decimal(28, 8)), 4, CAST(1611750.00000000 AS Decimal(28, 8)), CAST(729750.00000000 AS Decimal(28, 8)), 2010, 4), (6, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 1, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 2002, 5), (6, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 2, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 2002, 6), (6, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 3, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 2002, 7), (6, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 4, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 2002, 8), (7, CAST(1350000.00000000 AS Decimal(28, 8)), CAST(297000.00000000 AS Decimal(28, 8)), 1, CAST(1350000.00000000 AS Decimal(28, 8)), CAST(3000.00000000 AS Decimal(28, 8)), 2003, 9), (7, CAST(2700000.00000000 AS Decimal(28, 8)), CAST(594000.00000000 AS Decimal(28, 8)), 2, CAST(2700000.00000000 AS Decimal(28, 8)), CAST(6000.00000000 AS Decimal(28, 8)), 2003, 10), (7, CAST(1800000.00000000 AS Decimal(28, 8)), CAST(396000.00000000 AS Decimal(28, 8)), 3, CAST(1800000.00000000 AS Decimal(28, 8)), CAST(4000.00000000 AS Decimal(28, 8)), 2003, 11), (7, CAST(3150000.00000000 AS Decimal(28, 8)), CAST(693000.00000000 AS Decimal(28, 8)), 4, CAST(3150000.00000000 AS Decimal(28, 8)), CAST(7000.00000000 AS Decimal(28, 8)), 2003, 12), (9, CAST(3200000.00000000 AS Decimal(28, 8)), CAST(800000.00000000 AS Decimal(28, 8)), 1, CAST(4200000.00000000 AS Decimal(28, 8)), CAST(200000.00000000 AS Decimal(28, 8)), 2004, 13), (9, CAST(4000000.00000000 AS Decimal(28, 8)), CAST(1000000.00000000 AS Decimal(28, 8)), 2, CAST(5250000.00000000 AS Decimal(28, 8)), CAST(250000.00000000 AS Decimal(28, 8)), 2004, 14), (9, CAST(3200000.00000000 AS Decimal(28, 8)), CAST(800000.00000000 AS Decimal(28, 8)), 3, CAST(4200000.00000000 AS Decimal(28, 8)), CAST(200000.00000000 AS Decimal(28, 8)), 2004, 15),


115

(9, CAST(5600000.00000000 AS Decimal(28, 8)), CAST(1400000.00000000 AS Decimal(28, 8)), 4, CAST(7350000.00000000 AS Decimal(28, 8)), CAST(350000.00000000 AS Decimal(28, 8)), 2004, 16), (10, CAST(2300000.00000000 AS Decimal(28, 8)), CAST(460000.00000000 AS Decimal(28, 8)), 1, CAST(0.00000000 AS Decimal(28, 8)), CAST(150000.00000000 AS Decimal(28, 8)), 2010, 17), (10, CAST(8050000.00000000 AS Decimal(28, 8)), CAST(1610000.00000000 AS Decimal(28, 8)), 2, CAST(0.00000000 AS Decimal(28, 8)), CAST(525000.00000000 AS Decimal(28, 8)), 2010, 18), (10, CAST(3450000.00000000 AS Decimal(28, 8)), CAST(690000.00000000 AS Decimal(28, 8)), 3, CAST(0.00000000 AS Decimal(28, 8)), CAST(225000.00000000 AS Decimal(28, 8)), 2010, 19), (10, CAST(9200000.00000000 AS Decimal(28, 8)), CAST(1840000.00000000 AS Decimal(28, 8)), 4, CAST(0.00000000 AS Decimal(28, 8)), CAST(600000.00000000 AS Decimal(28, 8)), 2010, 20);

Modules use `s155495`; CREATE TABLE IF NOT EXISTS `Modules`( `Description` varchar(50) NOT NULL, `LastUpdate` datetime NOT NULL, `ModuleID` int NOT NULL, `Sign` varchar(50) NOT NULL, `Status` int NOT NULL, `agrtid` bigint NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ; INSERT INTO `Modules` (`Description`, `LastUpdate`, `ModuleID`, `Sign`, `Status`, `agrtid`) VALUES ('Økonomi', CAST(0x000091EB00CB79D8 AS DateTime), 11, N'Jarstein, Trond', 1, 1), ('Logistikk', CAST(0x000091EB00CB79D8 AS DateTime), 12, N'Jarstein, Trond', 1, 2), ('Time/Prosjekt', CAST(0x000091EB00CB79D8 AS DateTime), 13, N'Jarstein, Trond', 1, 3), ('Lønn/Personal', CAST(0x000091EB00CB79D8 AS DateTime), 14, N'Jarstein, Trond', 1, 4), ('Verktøy', CAST(0x000091EB00CB79D8 AS DateTime), 15, N'Jarstein, Trond', 1, 5), ('Budsjett', CAST(0x000091EB00CB79D8 AS DateTime), 16, N'Jarstein, Trond', 1, 6), ('Web - Lønn/Personal', CAST(0x000091EB00CB79D8 AS DateTime), 17, N'Jarstein, Trond', 1, 7), ('Web - Time/Prosjekt', CAST(0x000091EB00CB79D8 AS DateTime), 18, N'Jarstein, Trond', 1, 8), ('Invoice Manager', CAST(0x000091EB00CB79D8 AS DateTime), 19, N'Jarstein, Trond', 1, 9);


116

Prospect (Innhold er begrenset til en enkelt linje grunnet størrelse) use `s155495`; CREATE TABLE IF NOT EXISTS `Prospect`( ÀgressoCustID` int NOT NULL, `BranchID` int NOT NULL, `Comment` varchar(255) NOT NULL, `Consult` decimal(28, 8) NOT NULL, `Customization` decimal(28, 8) NOT NULL, `DatabaseID` int NOT NULL, `DatabaseValue` decimal(28, 8) NOT NULL, `DepLikelihood` int NOT NULL, ÈndDate` datetime NOT NULL, ÈstMonth` int NOT NULL, ÈstYear` int NOT NULL, ÈxtraValue1` decimal(28, 8) NOT NULL, ÈxtraValue2` decimal(28, 8) NOT NULL, `HeatCustID` int NOT NULL, Ìnstallation` decimal(28, 8) NOT NULL, `LastUpdate` datetime NOT NULL, `LicenseThirdP` decimal(28, 8) NOT NULL, `LicenseValue` decimal(28, 8) NOT NULL, `Likelihood` int NOT NULL, `LostTo` varchar(50) NOT NULL, `MaintenanceValue` decimal(28, 8) NOT NULL, `MaintThirdP` decimal(28, 8) NOT NULL, `ManagedServices` decimal(28, 8) NOT NULL, `Name` varchar(50) NOT NULL, ÒtherValue` decimal(28, 8) NOT NULL, `ProspectID` int NOT NULL, `ProspectType` varchar(1) NOT NULL, `SalesLicValue` decimal(28, 8) NOT NULL, `SalesMaintValue` decimal(28, 8) NOT NULL, `SalespersonID` int NOT NULL, `SaleType2` varchar(1) NOT NULL, `SaleTypeID` int NOT NULL, `Sign` varchar(50) NOT NULL, `SourceID` int NOT NULL, `StartDate` datetime NOT NULL, `Status` int NOT NULL, `Support` decimal(28, 8) NOT NULL, `SupportThirdP` decimal(28, 8) NOT NULL, `Training` decimal(28, 8) NOT NULL, `xConsult` decimal(28, 8) NOT NULL, `xDatabaseValue` decimal(28, 8) NOT NULL, `xLicense` decimal(28, 8) NOT NULL, `xLicenseThirdP` decimal(28, 8) NOT NULL,


117

`xmaintenance` decimal(28, 8) NOT NULL, `xMaintThirdP` decimal(28, 8) NOT NULL, `xManagedServices` decimal(28, 8) NOT NULL, `xSupport` decimal(28, 8) NOT NULL, `xSupportThirdP` decimal(28, 8) NOT NULL, `xTotal` decimal(28, 8) NOT NULL, `xTraining` decimal(28, 8) NOT NULL, `agrtid` bigint IDENTITY(1,1) NOT NULL, ) INSERT INTO `PE_Prospect` (AgressoCustID, BranchID, Comment, Consult, Customization, DatabaseID, DatabaseValue, DepLikelihood, EndDate, EstMonth, EstYear, ExtraValue1, ExtraValue2, HeatCustID, Installation, LastUpdate, LicenseThirdP, LicenseValue, Likelihood, LostTo, MaintenanceValue, MaintThirdP, ManagedServices, Name, OtherValue, ProspectID, ProspectType, SalesLicValue, SalesMaintValue, SalespersonID, SaleType2, SaleTypeID, Sign, SourceID, StartDate, Status, Support, SupportThirdP, Training, xConsult, xDatabaseValue, xLicense, xLicenseThirdP, xmaintenance, xMaintThirdP, xManagedServices, xSupport, xSupportThirdP, xTotal, xTraining, agrtid) VALUES (0, 27, N'KommentarP232', CAST(320000.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 0, CAST(0.00000000 AS Decimal(28, 8)), 0, CAST(0x0000000000000000 AS DateTime), 19, 2002, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 0, CAST(0.00000000 AS Decimal(28, 8)), CAST(0x0000920600ECB6D4 AS DateTime), CAST(0.00000000 AS Decimal(28, 8)), CAST(159395.00000000 AS Decimal(28, 8)), 100, N' ', CAST(18963.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), N'P232', CAST(0.00000000 AS Decimal(28, 8)), 232, N'5', CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), 18, N' ', 1, N'En Bruker', 10, CAST(0x000091B000D9DF64 AS DateTime), 20, CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(320000.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(159395.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(18963.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(0.00000000 AS Decimal(28, 8)), CAST(498358.00000000 AS Decimal(28, 8)), CAST(320000.00000000 AS Decimal(28, 8)), 2);


118

ProspectStatus use `s155495`; CREATE TABLE IF NOT EXISTS `SalesBudget`( `Description` varchar(50) NOT NULL, `LastUpdate` datetime NOT NULL, `Name` varchar(10) NOT NULL, `Sign` varchar(50) NOT NULL, `Status` int NOT NULL, àgrtid` bigint IDENTITY(1,1) NOT NULL, UNIQUE NONCLUSTERED ( INSERT INTO `ProspectStatus` (`Description`, `LastUpdate`, `Name`, `Sign`, `Status`, àgrtid`) VALUES (N'Prospect', CAST(0x000091B000CF4FE0 AS DateTime), N'Prospect', N'Jarstein, Trond', 19, 1), (N'Kunde', CAST(0x000091BF00FEC838 AS DateTime), N'Kunde', N'Jarstein, Trond', 20, 2), (N'Tapt', CAST(0x000091EB00C7F4AC AS DateTime), N'Tapt', N'Jarstein, Trond', 21, 3);

SalesBudget use `s155495`; CREATE TABLE IF NOT EXISTS `SalesBudget`( `License` decimal(28, 8) NOT NULL, `Maintenance` decimal(28, 8) NOT NULL, `Quarter` int NOT NULL, `SalesPersonID` int NOT NULL, `Services` decimal(28, 8) NOT NULL, `ThirdParty` decimal(28, 8) NOT NULL, `Year` int NOT NULL, àgrtid` bigint NOT NULL, ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ; INSERT INTO `PE_SalesBudget` (`License`, `Maintenance`, `Quarter`, `SalesPersonID`, `Services`, `ThirdParty`, `Year`, àgrtid`) VALUES (CAST(850000.00000000 AS Decimal(28, 8)), CAST(170000.00000000 AS Decimal(28, 8)), 1, 3, CAST(0.00000000 AS Decimal(28, 8)), CAST(50000.00000000 AS Decimal(28, 8)), 2010, 1), (CAST(2975000.00000000 AS Decimal(28, 8)), CAST(595000.00000000 AS Decimal(28, 8)), 2, 3, CAST(0.00000000 AS Decimal(28, 8)), CAST(175000.00000000 AS Decimal(28, 8)), 2010, 2), (CAST(1275000.00000000 AS Decimal(28, 8)), CAST(255000.00000000 AS Decimal(28, 8)), 3, 3, CAST(0.00000000 AS Decimal(28, 8)), CAST(75000.00000000 AS Decimal(28, 8)), 2010, 3), (CAST(3400000.00000000 AS Decimal(28, 8)), CAST(680000.00000000 AS Decimal(28, 8)), 4, 3, CAST(0.00000000 AS Decimal(28, 8)), CAST(200000.00000000 AS Decimal(28, 8)), 2010, 4),


119

(CAST(800000.00000000 AS Decimal(28, 8)), CAST(200000.00000000 AS Decimal(28, 8)), 1, 16, CAST(1050000.00000000 AS Decimal(28, 8)), CAST(50000.00000000 AS Decimal(28, 8)), 2004, 5), (CAST(1000000.00000000 AS Decimal(28, 8)), CAST(250000.00000000 AS Decimal(28, 8)), 2, 16, CAST(1312500.00000000 AS Decimal(28, 8)), CAST(62500.00000000 AS Decimal(28, 8)), 2004, 6), (CAST(800000.00000000 AS Decimal(28, 8)), CAST(200000.00000000 AS Decimal(28, 8)), 3, 16, CAST(1050000.00000000 AS Decimal(28, 8)), CAST(50000.00000000 AS Decimal(28, 8)), 2004, 7), (CAST(1400000.00000000 AS Decimal(28, 8)), CAST(350000.00000000 AS Decimal(28, 8)), 4, 16, CAST(1837500.00000000 AS Decimal(28, 8)), CAST(87500.00000000 AS Decimal(28, 8)), 2004, 8), (CAST(776250.00000000 AS Decimal(28, 8)), CAST(170775.00000000 AS Decimal(28, 8)), 1, 17, CAST(776250.00000000 AS Decimal(28, 8)), CAST(1725.00000000 AS Decimal(28, 8)), 2003, 9), (CAST(1552500.00000000 AS Decimal(28, 8)), CAST(341550.00000000 AS Decimal(28, 8)), 2, 17, CAST(1552500.00000000 AS Decimal(28, 8)), CAST(3450.00000000 AS Decimal(28, 8)), 2003, 10);

SalesPerson use `s155495`; CREATE TABLE IF NOT EXISTS `SalesPerson`( ÀgrResourceId` varchar(10) NOT NULL, `DepartmentID` int NOT NULL, `FirstName` varchar(50) NOT NULL, ÌsAdministrator` int NOT NULL, `LastName` varchar(50) NOT NULL, `LastUpdate` datetime NOT NULL, ÒSUser` varchar(255) NOT NULL, `Password` varchar(50) NOT NULL, `SalesPersonID` int NOT NULL, `Sign` varchar(50) NOT NULL, `Status` int NOT NULL, àgrtid` bigint IDENTITY(1,1) NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ; INSERT INTO `pe_SalesPerson` (ÀgrResourceId`, `DepartmentID`, `FirstName`, ÌsAdministrator`, `LastName`, `LastUpdate`, ÒSUser`, `Password`, `SalesPersonID`, `Sign`, `Status`, àgrtid`) VALUES ('test', 1, 'Rolf', 1, 'Andersen', CAST(0x000091B000CA8F78 AS DateTime), 'rolf.andersen', 'rolf.andersen', 1, 'rolf.andersen', 1, 1), ('test', 1, 'Bjorn', 1, 'Larsen', CAST(0x000091B000CA8F78 AS DateTime), 'bjorn.larsen', 'bjorn.larsen', 1, 'bjorn.larsen', 1, 2),


120

('test', 1, 'Roger', 1, 'Hansen', CAST(0x000091B000CA8F78 AS DateTime), 'andre.terning', 'andre.terning', 1, 'andre.terning', 1, 3), ('test', 1, 'Hans', 1, 'Hansen', CAST(0x000091B000CA8F78 AS DateTime), 'hans.hansen', 'hans.hansen', 1, 'hans.hansen', 1, 4), ('test', 1, 'Gard', 1, 'Johnsen', CAST(0x000091B000CA8F78 AS DateTime), 'gard.johnsen', 'gard.johnsen', 1, 'gard.johnsen', 1, 5),


121

SalesType use `s155495`; CREATE TABLE IF NOT EXISTS `SalesType`( `Description` varchar(50) NOT NULL, `LastUpdate` datetime NOT NULL, `SaleTypeID` int NOT NULL, `Sign` varchar(50) NOT NULL, `Status` int NOT NULL, `agrtid` bigint NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ; INSERT INTO `Modules` (`Description`, `LastUpdate`, `SaleTypeID` ,`Sign`, `Status`, `agrtid`) VALUES (N'Ny Kunde', CAST(0x0000917200B4666C AS DateTime), 1, N'Jarstein, Trond', 1, 1), (N'Tillegg - Officemoduler', CAST(0x0000923E009F3BAC AS DateTime), 2, N'Jarstein, Trond', 1, 2), (N'Ikke i bruk', CAST(0x000091B000E17530 AS DateTime), 3, N'Jarstein, Trond', 2, 3), (N'Ny Kunde - Budsjett', CAST(0x0000917200B3E200 AS DateTime), 4, N'Jarstein, Trond', 1, 4), (N'Tillegg - Modulgruppe', CAST(0x0000923E0097A25C AS DateTime), 5, N'Jarstein, Trond', 1, 5), (N'Konsulenttjenester', CAST(0x000091B000E11C20 AS DateTime), 6, N'Jarstein, Trond', 1, 6), (N'Forprosjekt', CAST(0x000091B000E11C20 AS DateTime), 7, N'Jarstein, Trond', 1, 7), (N'Vedlikehold/support', CAST(0x0000923E00971CC4 AS DateTime), 8, N'Jarstein, Trond', 1, 8), (N'Tillegg - Brukere', CAST(0x0000923E0097A25C AS DateTime), 9, N'Jarstein, Trond', 1, 9), (N'Tillegg - Webmoduler', CAST(0x0000923E009F3BAC AS DateTime), 10, N'Jarstein, Trond', 1, 10), (N'AGRESSO 5.5', CAST(0x0000992200C189B4 AS DateTime), 11, N'Hellmann, Rune', 1, 11), (N'Agresso Investering', CAST(0x00009D5101484EE0 AS DateTime), 12, N'Hellmann, Rune', 1, 12), (N'PM Lønnsforhandling', CAST(0x00009A19000FFFB4 AS DateTime), 13, N'Hellmann, Rune', 1, 13), (N'PM AIM', CAST(0x00009A19000FFFB4 AS DateTime), 14, N'Hellmann, Rune', 1, 14);

Source use `s155495`; CREATE TABLE IF NOT EXISTS `SalesType`( `Description` varchar(50) NOT NULL, `LastUpdate` datetime NOT NULL, `SaleTypeID` int NOT NULL,


122

`Sign` varchar(50) NOT NULL, `Status` int NOT NULL, `agrtid` bigint NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ; INSERT INTO `Modules` (`Description`, `LastUpdate`, `SaleTypeID` ,`Sign`, `Status`, `agrtid`) VALUES (N'Ny Kunde', CAST(0x0000917200B4666C AS DateTime), 1, N'Jarstein, Trond', 1, 1), (N'Tillegg - Officemoduler', CAST(0x0000923E009F3BAC AS DateTime), 2, N'Jarstein, Trond', 1, 2), (N'Ikke i bruk', CAST(0x000091B000E17530 AS DateTime), 3, N'Jarstein, Trond', 2, 3), (N'Ny Kunde - Budsjett', CAST(0x0000917200B3E200 AS DateTime), 4, N'Jarstein, Trond', 1, 4), (N'Tillegg - Modulgruppe', CAST(0x0000923E0097A25C AS DateTime), 5, N'Jarstein, Trond', 1, 5), (N'Konsulenttjenester', CAST(0x000091B000E11C20 AS DateTime), 6, N'Jarstein, Trond', 1, 6), (N'Forprosjekt', CAST(0x000091B000E11C20 AS DateTime), 7, N'Jarstein, Trond', 1, 7), (N'Vedlikehold/support', CAST(0x0000923E00971CC4 AS DateTime), 8, N'Jarstein, Trond', 1, 8), (N'Tillegg - Brukere', CAST(0x0000923E0097A25C AS DateTime), 9, N'Jarstein, Trond', 1, 9), (N'Tillegg - Webmoduler', CAST(0x0000923E009F3BAC AS DateTime), 10, N'Jarstein, Trond', 1, 10), (N'AGRESSO 5.5', CAST(0x0000992200C189B4 AS DateTime), 11, N'Hellmann, Rune', 1, 11), (N'Agresso Investering', CAST(0x00009D5101484EE0 AS DateTime), 12, N'Hellmann, Rune', 1, 12), (N'PM Lønnsforhandling', CAST(0x00009A19000FFFB4 AS DateTime), 13, N'Hellmann, Rune', 1, 13), (N'PM AIM', CAST(0x00009A19000FFFB4 AS DateTime), 14, N'Hellmann, Rune', 1, 14);

Titles USE `s155495`; CREATE TABLE IF NOT EXISTS 'Titles'( 'title' varchar(25) NOT NULL, 'title_id' varchar(25) NOT NULL, 'agrtid' bigint IDENTITY(1,1) NOT NULL, ( ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=35 ;


123

IIS – Internet Information Services (IIS) IIS er et web – server program laget av Microsoft for Windows. Dette programmet gjør at brukeren kan kjøre en webapplikasjon lokalt på sin datamaskin. IIS har også flere funksjoner som HTTP – moduler, Sikkerhets – moduler, Komprimerings – moduler og Logging – og diagnose – moduler.

Hovedgrunnen for at vi valgte å se nærmere på IIS var på grunn av en pre – kompileringsfunksjon. Når man åpner en nettside må siden kompileres, dette betyr at kildekoden (programmeringsspråk) oversettes til et kjørbart program (maskinkode). Dette kan forøvrig sammenlignes med funksjonen til en tolk, to personer som ikke forstår hverandre, tolken oversetter det den ene sier slik at den andre personen kan dra nytte av det og forstå informasjonen. Pre – kompilering gjør at siden lastes raskere og fører til en mer behagelig brukeropplevelse.

Brukerveiledning IIS er normalt ikke forhåndsinstallert på operativsystemet, man må derfor installere programmet manuelt. Vi skal nå gå igjennom steg for steg hvordan dette settes opp.

1. Installere IIS Manager

Trykk "Avinstaller et Program"

Så velger man "Slå Windows – funksjoner på eller av"


124

Deretter velger man Internet Information Services og Internet Information Services Hostable Web Core (HWC). Trykk på + tegnet for å utdype valget.

Velg alle under FTP – Server om man ønsker denne funksjonaliteten. Denne er nyttig om du skal dele den lokale web – siden din med andre.


125

Huk av for alle under Funksjoner for applikasjonsutvikling. Nå er det klart til å trykke "OK". Nå installeres IIS funksjonaliteten.

2. Åpne IIS Manager

Trykk på Category/Kategori øverst til høyre. Vel Vis etter små ikoner/small icons.


126

Øverst i andre kolonne er Administrative verktøy/Administrative tools, trykk her.

'

Velg så Internet Information Services (IIS) Manager


127

Du får nå dette vinduet presentert

For å legge til en ny webside, velger du pilen i menyen øverst til venstre.

Høyreklikk på Områder/Sites, velg Legg til nytt webområde.


128

Når du lager nytt webområde er det viktig å velge rett applikasjonsutvalg, velg et som støtter Microsoft.NET Framework 4.0. Den fysiske banen er mappen prosjektet ligger i. Her er det viktig å merke seg at når man installerte IIS opprettet det seg en mappe ved navn "inetpub" i C:. i denne mappen ligger det en undermappe ved navn "wwwroot", her skal prosjektet du skal kjøre lokalt ligge. Port kan man for eksempel velge 8080-8081.

Lag et applikasjonsutvalg som støtter Microsoft.NET Framework 4.0.


129

Du skal nå kunne kjøre prosjektet fra nettleseren lokalt på adressen http://localhost:8080/"prosjektmappen" eventuelt http://127.0.0.1:8080/"prosjektmappen"

Kilder Wikipedia – 25.05.2011 http://no.wikipedia.org/wiki/Kompilator

Wikipedia – 25.05.2011 http://en.wikipedia.org/wiki/Internet_Information_Services


130

Ordforklaringer

Grid-Framework

En rutenett visning eller en DataGrid er et grafisk brukergrensesnittelement (widget) som presenterer en tabellarisk visning av data. En typisk rutenettvisning støtter også noen eller alle av følgende:

Klikker på en kolonneoverskrift for å endre rekkefølgen i rutenettet

Dra kolonneoverskrifter for å endre størrelsen og rekkefølgen

"I-tabell redigering" av data

Rad og kolonne separatorer, og vekslende rad bakgrunnsfarger

MS Excel 2010(PC)/2011(Mac)

Microsoft Office Excel, også kalt Microsoft Excel, er et program produsert av Microsoft og er en del av Microsoft Office-pakken. Programmet er basert på regneark der man kan utføre beregninger, ofte i form av matematiske problemer, analysere informasjon, behandle lister og talldata i regneark eller websider. Programmet har avanserte matematiske funksjoner, og har en hel del formler og funksjoner inkludert. Programmet brukes også til å produsere diagrammer og statistikk.

.NET 4.0

.NET eller .NET Framework er en samling teknologier rundt programvareutvikling fra Microsoft som først ble introdusert i 2002. Siden har plattformen fått fotfeste og er i dag en av de mest brukte utviklingsplattformene i verden. Microsoft benytter et mellomlag mellom applikasjon og operativsystem, ikke ulikt det som er brukt i Java-basert utvikling og er et rammeverk for applikasjoner.

C#

C# (uttales C sharp) er et programmeringsspråk for objekt-orientert programmering, utviklet av Microsoft som en del av deres satsing på .NET. Microsoft valgte å basere C# på programmeringsspråkene C++ og Java. C# ble designet for å balansere styrke (C++) og rask utvikling (Java).

Visual Basic

http://no.wikipedia.org/wiki/Microsoft

http://no.wikipedia.org/wiki/Microsoft_Office

http://no.wikipedia.org/wiki/Regneark

http://no.wikipedia.org/wiki/Matematikk

http://no.wikipedia.org/wiki/Diagram

http://no.wikipedia.org/wiki/Statistikk

http://no.wikipedia.org/wiki/Programvareutvikling


http://no.wikipedia.org/wiki/2002

http://no.wikipedia.org/wiki/Java_(programmeringsspr%C3%A5k)

http://no.wikipedia.org/wiki/Programmeringsspr%C3%A5k

http://no.wikipedia.org/wiki/Objektorientert_programmering


http://no.wikipedia.org/wiki/.NET

http://no.wikipedia.org/wiki/C_Pluss_Pluss

http://no.wikipedia.org/wiki/Java_(programmeringsspr%C3%A5k)


131

Visual Basic er et programmeringsspråk utgitt av Microsoft. Syntaksen er avledet fra programmeringsspråket BASIC.

ERP-system

Enterprise resource planning (ERP) er betegnelsen på programvare som støtter opp om et flertall av en bedrifts virksomhetsområder, som produksjon, lager, salg, innkjøp og økonomi. ERP er ikke en produktbetegnelse, men en beskrivelse av kvaliteten på integrasjonen mellom de nevnte områdene.

HR – system

Menneskelige ressurser er mennesklige evner, egenskaper, kunnskap, erfaringer og ferdigheter som kan settes inn for å skape og formidle varer, tjenester og informasjon, dvs. forutsetninger for teknologi og økonomi.

Desktop-applikasjon

Et program som kjøres lokalt på PC’en, trenger ikke kjøres via en nettleser eller lignende. Et eksempel er Microsoft Word eller MS Excel.

Visual Studio 2010

Visual Studio er et integrert utviklingsmiljø (IDE) for Microsofts .NET platform. Programmet hjelper utviklere å utvikle programmer for Windows, såkalte Windows Forms, websider og mobil programvare for Microsofts mobile operativsystemer.

GUI

Et grafisk brukergrensesnitt (GUI) er et brukergrensesnitt for dataprogrammer som i motsetning til shell-applikasjoner ikke består av en rekke kommandoer, derimot at brukeren ved hjelp av en mus klikker på forskjellige knapper, tekstbokser og informasjonsfelt for å få gjort ting. Ofte kan det også betjenes med hurtigtaster. En rekke slike er ofte standard. I Windows gjelder det f.eks. tastekombinasjonen Alt+F4 (hold <Alt> inne mens du trykker F4), som brukes til å lukke et program eller avslutte Windows.


http://no.wikipedia.org/wiki/Programmeringsspr%C3%A5k

http://no.wikipedia.org/wiki/BASIC

http://no.wikipedia.org/wiki/Programvare

http://no.wikipedia.org/wiki/Bedrift

http://no.wikipedia.org/wiki/%C3%98konomi

http://no.wikipedia.org/wiki/Kvalitet

http://no.wikipedia.org/wiki/Integrasjon



http://no.wikipedia.org/wiki/Windows

http://no.wikipedia.org/wiki/Brukergrensesnitt

http://no.wikipedia.org/wiki/Dataprogrammer

http://no.wikipedia.org/wiki/Shell-applikasjon

http://no.wikipedia.org/wiki/Datamus

http://no.wikipedia.org/wiki/Hurtigtaster

http://no.wikipedia.org/wiki/Microsoft_Windows


132

Business Logic Layer(BLL)

Et forretningslogikk lag (BLL), også kjent som domenet laget, er en software engineering praksis compartmentalizing. Det forretningslogikk laget er vanligvis et av de lagene i en multitier arkitektur. Det skiller forretningslogikken fra andre moduler, slik som datatilgang laget (DAL) og brukergrensesnitt (UI). Ved å gjøre dette, kan virksomheten logikken i et program ofte motstå endringer eller bytte av andre nivåer. For eksempel, i et program med en skikkelig atskilt forretningslogikk lag og datatilgang laget, kan datatilgangen laget bli omskrevet til å hente data fra en annen database, uten å påvirke noe av forretningslogikken. Denne praksisen gjør at program utvikling mer effektivt delt inn i lag, med for eksempel flere team som arbeider på forskjellige nivå samtidig.

Data Access Layer(DAL)

DAL er det laget i programmet som har ansvar for kommunikasjon til og fra databasen. Denne legger til, henter og endrer informasjonen vi har lagret der.

Model

En datamodell i programvareutvikling er en abstrakt modell, som dokumenterer og organiserer virksomheten data for kommunikasjon mellom gruppemedlemmer og brukes som en plan for utvikling av applikasjoner, spesielt hvordan dataene lagres og åpnes.

jQuery og AJAX

Ajax, eller Asynkron JavaScript og XML, er en webutviklingsteknikk for å lage interaktive nettsider. Tanken er å lage nettsider som føles mer responsive. Dette gjøres ved at sidene utveksler litt og litt data med serveren i bakgrunnen, i stedet for å laste hele siden på nytt hver gang brukeren gjør en forandring. Dette skal øke nettsidenes interaktivitet, hastighet og brukskvalitet.

http://no.wikipedia.org/w/index.php?title=Asynkron&action=edit&redlink=1


http://no.wikipedia.org/wiki/XML

http://no.wikipedia.org/wiki/Nettside

http://no.wikipedia.org/wiki/Brukskvalitet


133

Kildehenvisninger

1. Dokumentasjonsstandard – Gitt av Høgskolen i Oslo http://www.iu.hio.no/data/hovedprosjekt/dokumenter/dokumentasjonsstandard.pdf

2. Blueprint - Css for kolonne oppsettet av siden http://www.blueprintcss.org/

3. .NET Framework – Rammeverket siden er programmert i

http://www.microsoft.com/net/

4. C#: - Språket siden er programmert i

http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29

5. Visual Studio 2010 Ultimate – Programmet vi brukte til å programmerer siden med

http://www.microsoft.com/visualstudio/en-us/

6. Team Foundation Server – Innebygd funksjon I Visual Studio for å holde alle prosjekfiler oppdatert http://en.wikipedia.org/wiki/Team_Foundation_Server

7. Dropbox – Online backup for hele prosjektet mellom gruppemedlemmer http://www.dropbox.com/

8. Mumble – Kommunikasjonsprogram slik at gruppemedlemmer kan snakke/skrive meldinger til hverandre http://mumble.sourceforge.net/

9. Skype - Kommunikasjonsprogram slik at gruppemedlemmer kan snakke/skrive meldinger til hverandre http://www.skype.com/intl/no/home

10. Firebug – Feilsøking og debuggingsverktøy for nettsteder – Addon til Mozilla Firefox http://getfirebug.com/

11. Mozilla Firefox – Nettleseren vi har brukt mest http://www.mozilla.com/en-US/firefox/new/

12. Internet Explorer – Annet nettleser hvor vi har sjekket kompabilitet http://windows.microsoft.com/en-US/internet-explorer/products/ie/home

13. WMware Player – Program vi har brukt til å kjøre Windows xp http://www.vmware.com/products/player/

14. ASP.net forum – Forum kanal hvor vi har fått hjelp til forskjellige problemer http://forums.asp.net/

http://www.iu.hio.no/data/hovedprosjekt/dokumenter/dokumentasjonsstandard.pdf

http://www.blueprintcss.org/

http://www.microsoft.com/net/

http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29

http://www.microsoft.com/visualstudio/en-us/

http://en.wikipedia.org/wiki/Team_Foundation_Server

http://www.dropbox.com/

http://mumble.sourceforge.net/

http://www.skype.com/intl/no/home

http://getfirebug.com/

http://www.mozilla.com/en-US/firefox/new/

http://windows.microsoft.com/en-US/internet-explorer/products/ie/home

http://www.vmware.com/products/player/

http://forums.asp.net/


134

15. Gliffy – en side vi har brukt for å generere funksjonskart http://www.gliffy.com/gliffy/

16. Grid View (Wikipedia 20.mai 2011) – Metoden vi bruker for å vise data i web-applikasjonen http://en.wikipedia.org/wiki/Grid_view

17. MS Excel (Wikipedia 20.mai 2011) – Regneark program http://no.wikipedia.org/wiki/Excel

18. .NET (Wikipedia 20.mai 2011) – Plattformen vi har brukt http://no.wikipedia.org/wiki/.NET

19. C# (Wikipedia 20.mai 2011) – Programmeringsspråket vi har brukt http://no.wikipedia.org/wiki/C_sharp

20. Visual Basic (Wikipedia 20.mai 2011) – Utviklingsmiljø for den gamle versjonen av systemet http://no.wikipedia.org/wiki/Visual_Basic

21. ERP (Wikipedia 20.mai 2011) http://no.wikipedia.org/wiki/ERP

22. HR (Wikipedia 20.mai 2011) http://no.wikipedia.org/wiki/Menneskelige_ressurser

23. Visual Studio (Wikipedia 20.mai 2011) – Utviklingsmiljøet vi har brukt for å utvikle we-applikasjonen vår http://no.wikipedia.org/wiki/Visual_Studio

24. GUI (Wikipedia 20.mai 2011) http://no.wikipedia.org/wiki/GUI

25. Business Logic Layer (BLL) (Wikipedia 20.mai 2011) http://en.wikipedia.org/wiki/Business_logic_layer

26. Data Access Layer (DAL) (Wikipedia 20.mai 2011) http://en.wikipedia.org/wiki/Data_access_layer

27. Model (Wikipedia 20.mai 2011) http://en.wikipedia.org/wiki/Data_model

28. AJAX (Wikipedia 20.mai 2011) http://no.wikipedia.org/wiki/Ajax_(programmering)

29. W3Schools – Browser Displays http://www.w3schools.com/browsers/browsers_display.asp

http://www.gliffy.com/gliffy/

http://en.wikipedia.org/wiki/Grid_view

http://no.wikipedia.org/wiki/Excel


http://no.wikipedia.org/wiki/C_sharp

http://no.wikipedia.org/wiki/Visual_Basic

http://no.wikipedia.org/wiki/ERP

http://no.wikipedia.org/wiki/Menneskelige_ressurser

http://no.wikipedia.org/wiki/Visual_Studio

http://no.wikipedia.org/wiki/GUI

http://en.wikipedia.org/wiki/Business_logic_layer

http://en.wikipedia.org/wiki/Data_access_layer

http://en.wikipedia.org/wiki/Data_model

http://no.wikipedia.org/wiki/Ajax_(programmering)

http://www.w3schools.com/browsers/browsers_display.asp


135

30. Google Chrome - Nettleser http://www.google.com/chrome/intl/no/more/index.html?hl=no

31. Firefox - Nettleser http://www.mozilla.com/en-US/firefox/fx/

32. Yslow – Addon til Firefox som vi har brukt for å teste ytelsen til siden http://developer.yahoo.com/yslow/

33. JQuery http://jquery.com/

http://www.google.com/chrome/intl/no/more/index.html?hl=no

http://www.mozilla.com/en-US/firefox/fx/

http://developer.yahoo.com/yslow/

http://jquery.com/

prospect explorer 2.0 hovedprosjekt...

Documents