DB Flow fra prototype til forretningsplan
ii
Institut for Datalogi Selma Lagerlöfs Vej 300 9220 Aalborg Øst Telefon: (45) 9635 8080 Telefax: (45) 9815 9889 http://www.cs.aau.dk Titel: DB Flow fra prototype til forretningsplan Tema: Programmeringsteknologi Projekt periode: DAT7, efterår 2007 Projekt gruppe: dat7e071 Gruppe medlemmer: Jacob Volstrup Vejleder: Kurt Nørmark Bi-vejleder: Henrik Knudsen Synopsis: I denne opgave har jeg set på hvad der skal til for at planlægge den proces, der skal til for at gå fra en software prototype, til et færdigt produkt. Herunder har jeg klarlagt mulighederne for at kommercialisere produktet DB Flow, og som en del af dette lavet en milepælsplan og tilhørende tidsplan, som skal bruges i den videre udvikling af DB Flow. Da der var usikkerheder omkring kundegrundlaget blev dele af forretningsplanen baseret på estimater, for at vise at man ikke nødvendigvis behøver at vide alt om markedet for at kunne starte på forretningsplanen. I stedet har jeg lagt op til at revidere forretningsplanen når markedsundersøgelsen er foretaget. Antal eksemplarer: 4 Antal sider: 52 Afleveret: 15. januar 2008
ii
Indhold I Problem 1 1 Indledning 3 2 Motivation 5 3 Problemformulering 7 II Baggrund 9 4 Specialeprojektet Vivid Data Objects 11 4.1 Hvorfor Vivid Data Objects..................... 11 4.1.1 Impedance mismatch..................... 12 4.1.2 Data typer........................... 13 4.1.3 Dataudtræk fra databasen.................. 13 4.1.4 Simuleret samtidighed.................... 15 4.2 Eksisterende løsninger........................ 15 4.2.1 Hibernate........................... 17 4.2.2 LINQ............................. 17 4.3 Vivid Data Objects.......................... 18 5 Forretningsmuligheder 21 5.1 DB Flow................................ 21 5.2 Opstart af virksomhed........................ 23 5.2.1 Forretningsplanen....................... 23 III Planlægning 25 6 Forretningsplan 27 6.1 Baggrundsoplysninger........................ 27 6.2 Resumé................................ 28 6.3 Idégrundlag.............................. 28 6.4 Personlige ressourcer og mål..................... 29 6.5 Produkter og ydelser......................... 31 iii
INDHOLD INDHOLD 6.6 Markedsbeskrivelse.......................... 33 6.6.1 Kundegruppe......................... 33 6.6.2 Kundegrundlag........................ 34 6.6.3 Konkurrenter......................... 34 6.6.4 Trends............................. 35 6.7 Salg og markedsføring........................ 35 6.7.1 Kommunikationsstrategi................... 35 6.7.2 Salgskanaler.......................... 36 6.8 Organisering af virksomheden.................... 36 6.8.1 Forretningspolitikker..................... 37 6.9 Virksomhedens udvikling....................... 38 6.10 Økonomi................................ 38 6.10.1 Prissætning.......................... 39 6.10.2 Opstartskapital........................ 39 6.10.3 Forventede opstartsomkostninger for Aps.......... 39 6.10.4 Forventede etableringsomkostninger............. 40 6.10.5 Forventede udgifter...................... 40 6.10.6 Forventede indtægter..................... 40 6.10.7 Budget for år 1........................ 41 7 Produktudvikling 43 7.1 Milepælsplan............................. 43 7.2 Tidsplan................................ 43 IV Afslutning 47 8 Konklusion 49 Litteratur 51 iv
1 IProblem
1 Indledning Det kan være en stor beslutning at vælge at blive selvstændig, også selvom man føler man har det rette produkt på det rette tidspunkt. Denne rapport vil beskrive tanker og overvejelser omkring produktet DB Flow, herunder gennmgå nogle af de produkter som er de nærmeste konkurrenter, samt hvor den primære inspiration til produktet kommer fra. Som en vigtig del af dette produkt vil jeg planlægge hvordan produktet udvikles fra prototype til færdigt produkt, og hvordan produktet kan bruges som fundament i en virksomhed. For at kunne bruge produktet i virksomhedssammenhæng er det derfor også vigtigt at se på de aspekter som vedrører opstart af virksomhed, og bruge disse til at lave en forretningsplan. Forhåbentlig vil læsningen af denne rapport vise at det ikke er en uoverkommelig opgave at bruge en prototype til at planlægge udvikling af produkt og opstart af virksomhed. Rapporten henvender sig primært til personer som har udviklet noget software som de føler kan danne grundlag for opstart af en virksomhed. Ved at læse rapporten skulle der gerne blive kastet lys over hvilke aspekter man bør overveje i den forbindelse, og derved blive inspireret til selv at springe ud i planlægningen, enten for at starte egen virksomhed eller på et tidligt tidspunkt konstatere at fundamentet ikke kan holde til at starte en virksomhed. Uanset hvilket resultat man når frem til, vil tiden brugt på planlægning ikke være spildt, da den kan bringe klarhed ind i de overvejelser man måtte have. Da dele af rapporten bygger direkte videre på arbejdet fra [6] vil der enkelte steder også være sammenfald mellem indholdet i denne rapport og [6]. 3
4 1. Indledning
2 Motivation I løbet af hvert semester på Aalborg Universitet har jeg været med til at lave et projekt, som i større eller mindre grad har resulteret i et produkt, som har opfyldt en klarlagt problemstilling. Efter endt eksamen er hver af projekternes rapporter endt på hylden, og produkterne er ikke blevet brugt efterfølgende. Dette er ikke enestående, da mange universitetsprojekter ofte ikke når længere end til at være pynt (eller måske blot fyld) på en hylde. I enkelte tilfælde vil det projekt, man har lavet, dog blive ved med at føles interessant, så man har lyst til at sprede kendskabet hertil videre end universitetet, og måske endda bruge den viden, som er tilegnet i forbindelse med projektet, til at etablere en virksomhed. At etablere en virksomhed på baggrund af viden kan virke spinkelt og usikkert for nogle, måske endda skræmmende, især fordi det ligger så fjernt fra den vanlige tankegang på universitetet. I forbindelse med mit speciale udarbejdede jeg sammen med Alex H. Johannesen (herefter AHJ) en prototype til automatisk generering af et værktøj, som skal hjælpe en programmør med at benytte en database i et stykke software [6]. Vi fik værktøjet til at virke, men da vi fokuserede på slutproduktet, dvs. selve værktøjet, kan det heller ikke tilskrives at være andet end blot en prototype med tilhørende viden, som var resultatet. Specialeprojektet lå i direkte forlængelse af et tidligere projekt, vi lavede sammen, hvor vi kiggede på forskellige løsninger til at benytte en database i et stykke software, samt hvilke fordele og ulemper vi så ved de løsninger, vi kiggede på [7]. Netop fordi vores værktøj var resultatet af lang tids arbejde, samt fordi jeg synes prototypen på vores værktøj åbner op for rigtig mange muligheder, er jeg ikke interesseret i, at specialet blot bliver endnu et hyldeprojekt. Min interesse for projektet denne gang er derfor at afsøge de muligheder, jeg umiddelbart ser for at etablere en virksomhed med den viden, som jeg har tilegnet mig gennem arbejdet med specialeprojektet. Jeg vil kortlægge, hvad der skal til for at bevæge produktet i retning af noget, som er forretningsegnet og fokusere 5
2. Motivation på netop processen, der skal til for at bevæge sig fra prototype til et slutprodukt, som kan sælges; Fra idé til handling. En del af denne proces er at se udover slutproduktet, se på hvad der kræves for at kunne starte virksomheden op, samt dokumentere hvilket forarbejde som kræves. 6
3 Problemformulering I denne rapport vil jeg se på mulighederne for at planlægge processen fra en software prototype af et værktøj, frembragt i en studiemæssig kontekst, til et færdigt produkt. Som en del af dette vil en forretningsplan klarlægge hvordan det færdige produkt kan kommercialiseres, samt belyse hvilke områder som vil kræve yderligere afklaring. Den planlagte proces vil belyse, hvordan den videre udvikling af værktøjet skal forløbe, samt hvilke forretningsmæssige tiltag, som skal udføres sideløbende med denne udvikling. Den videre udvikling skal planlægges, så der tages hensyn til både forretningsplanen og målgruppen for værktøjet. 7
8 3. Problemformulering
IIBaggrund 9
4 Specialeprojektet Vivid Data Objects I dette kapitel vil jeg beskrive specialeprojektet Vivid Data Objects (VDO), der fungerer som er den primære inspiration til produktet DB Flow. Som en del af denne beskrivelse vil jeg gennemgå den underliggende motivation for VDO sammen med nogle af de eksisterende løsninger, som i større eller mindre grad forsøger at løse de samme problemer som VDO. Efter beskrivelsen af VDO vil jeg gennemgå stadiet for prototypen ved specialets afslutning, både på den brugsmæssige og den tekniske side. Jeg vil i den forbindelse præcisere de største styrker og svagheder ved VDO. 4.1 Hvorfor Vivid Data Objects I forbindelse med udarbejdelsen af projekterne An Exploration of the Impedance Mismatch [7] og efterfølgende Vivid Data Objects [6] (VDO), blev det klart, at der stadig findes nogle helt fundamentale problemer, som skal løses, når man udvikler en applikation, som skal benytte en relationel database til lagring af informationer. Det første skridt på vejen mod at løse problemerne med at benytte en database, var at klarlægge hvilke problemer, som er de største og vigtigste at løse. I de følgende afsnit vil jeg beskrive problemerne, så læseren får indsigt i, hvorfor problemerne bør løses for programmøren. Det første problem jeg belyser, Impedance Mismatch, er samtidig det problem som de fleste andre af problemerne hører under. I afsnit 4.2 på side 15 vil jeg beskrive nogle eksisterende løsninger, som i større eller mindre grad forsøger at løse problemerne. Efter gennemgang af de eksisterende løsninger skal det gerne stå klart for læseren, at ingen af de eksisterende løsninger til fulde løser de fremlagte problemer og dermed forklare, hvorfor vi 11
4.1 Hvorfor Vivid Data Objects 4. Specialeprojektet Vivid Data Objects fandt det nødvendigt at udvikle VDO. 4.1.1 Impedance mismatch Impedance mismatch (IM) er et udtryk som stammer fra den elektriske verden, hvor det beskriver forskellen mellem to systemer, som gør det svært for systemerne at arbejde sammen. I datalogiske sammenhænge dækker IM over det generelle problem mellem at benytte en relationel database til at gemme data fra et programmeringssprog [4]. Definitionen på IM er ikke præcis, men generelt set dækker det over problemet med at repræsentere mulige data fra programmeringssproget i database og omvendt. For at gøre dette muligt kræver det enten et programmeringssprog som indeholder de samme typer som databasen eller en database som indeholder de samme typer som programmeringssproget. Grundet udbredelsen af relationelle databaser er det denne slags som har interesse, hvilket passer dårligt sammen med det objektorienterede programmeringssprog C# som er valgt grundet dets udbredelse og muligheder. Grunden til at der er så stor forskel på relationelle databaser og programmeringssprog hænger sammen med at de befinder sig i vidt forskellige paradigmer. Programmeringssprog kan inddeles i forskellige paradigmer (fx. Java og C# i det objektorienterede paradigme) imens SQL ligger i sit eget paradigme, da sproget er svært at sætte i bås. På mange måder er forskellige dele af sproget inspireret af forskellige paradigmer, hvilket slutteligt giver et sprog som ikke passer i bås hos de gængse paradigmer, men blot er sit eget. Når der forespørges på data kan det på visse områder minde om sprog som Prolog fra det logiske paradigme, men i andre sammenhænge minder det i høj grad om procedurale sprog. Eftersom sproget ikke passer ind i de gængse paradigmer for programmeringssprog, betyder det at programmøren, uanset udviklingssprog, vil ende med at skulle skifte mellem to paradigmer hvis en database skal bruges. I objektorienterede sprog findes der primitive typer som umiddelbart kan gemmes i en database, og det er derfor ikke disse som giver problemer. I stedet er problemet at gemme de komplekse typer som programmøren selv konstruerer, som i objektorienterede sammenhænge er klasser. Klasserne indeholder variable som enten kan være primitive datatyper som også findes i databasen samtidig med at de kan være andre komplekse typer. En klasse kan groft set oversættes til en række i en tabel med de forskellige variables værdier gemt i tilsvarende kolonner. Dette er dog ikke tilfældet hvis variablen er en kompleks type, da denne ikke umiddelbart kan gemmes i en kolonne. I stedet kan den komplekse type, som jo er en klasse, oversættes til en række i en anden tabel, og der kan laves en relation imellem rækkerne i disse tabeller, for at tilsvare referencen fra det objektorienterede sprog. For at kunne lave relationen i databasen er der behov for at tabellerne har unikker nøgler der kan relateres til, 12
4. Specialeprojektet Vivid Data Objects 4.1 Hvorfor Vivid Data Objects hvilket betyder at der er behov for ekstra data i forhold til den objektorienterede repræsentation, hvis man vil have mulighed for at genskabe referencen mellem objekterne på et senere tidspunkt. 4.1.2 Data typer Når de forskellige former for data gemmes i databasen, skal de gemmes som en bestemt type af hensyn til måden, de gemmes på og muligheder for at optimere i forhold til søgning. Groft set kan typerne i databasen derfor deles op i nummeriske typer, teksttyper og datotyper. Der findes derudover typer til at gemme store mængder af rådata, fx. indholdet af en fil, men disse er uden for interesse i denne kontekst. Når man indlæser data fra databasen til en applikation, er det vigtigt at repræsentere denne data på en tilsvarende måde, dels for at gøre det simpelt at gemme i databasen igen og dels, fordi der er forskel på den måde, man kan bruge de forskellige repræsentationer. For de fleste af typerne findes der tilsvarende typer i de sprog, man skriver programmerne i, men for enkelte er der ikke en type, som direkte matcher, og man er derfor nødt til at finde et kompromis. Fordelen ved at bruge typer, som tilsvarer hinanden, er at fejl i brug af typerne vil blive fanget, når programmet compiles fremfor under afvikling. For teksttyper gælder der desuden det specielle, at objektorienterede programmeringssprog har strenge uden begrænsning på længde, modsat en database, hvor man kan definere en maksimal længde. Dette betyder også, at der kan opstå problemer, når man vil gemme en streng fra sit program, da den måske er længere end den tilladte længde i databasen. Da denne type fejl ikke kan findes, når programmet compiles, er det nødvendigt at benytte overvågning under afvikling af programmet. For alle datatyper, som gemmes i databasen, gælder desuden, at de kan have den specielle værdi null, som dækker over ingenting, dvs. at værdien ikke er sat. I de fleste programmeringssprog findes der ikke en tilsvarende løsning, da alle typer skal have en værdi sat fra starten. I projektet An Exploration of the Impedance Mismatch [7] konstaterede vi, at der ikke findes en smart løsning til dette, hvis ikke værtssproget understøtter null-værdier. I forbindelse med dette fandt vi, at det eneste objektorienterede sprog indenfor vores målgruppe, som understøtter null-værdier er C#. Da jeg også på nuværende tidspunkt har stor interesse i at løse problemet med null-værdier, vil de eksisterende løsninger, jeg kigger på, udelukkende være til C#. 4.1.3 Dataudtræk fra databasen Når man almindeligvis laver forespørgsler til databasen, sker det igennem forespørgsler skrevet i sproget SQL. Disse forespørgsler er markant anderledes opbygget end en applikation skrevet i et objektorienteret sprog, da SQL er skabt med 13
4.1 Hvorfor Vivid Data Objects 4. Specialeprojektet Vivid Data Objects henblik på at forespørge efter data. Som det kan ses i listing 4.1, kan en SQL forespørgsel minde om almindeligt tale- og skriftsprog i sin opbygning. I det viste eksempel er det adresser på alle, som hedder Jens Jensen, der forespørges efter. En sådan forespørgsel vil returnere resultatet af forespørgslen som et antal rækker med data fra tabellen. I det viste eksempel vil det eneste felt i de returnerede rækker være adressefeltet fra tabellen brugere. 1 SELECT adresse FROM brugere WHERE navn= Jens Jensen ; Listing 4.1: Simpel SQL forespørgsel. Denne måde at tilgå og behandle data på afviger meget fra den objektorienterede tilgang til data, som benyttes i bla. C# og Java, især i kraft af, at man udvælger hvilken data, man vil have retur. Den store forskel ligger i de vidt forskellige paradigmer, som sprogene bevæger sig indenfor; C# og Java i det objektorienterede paradigme og SQL i sit eget paradigme. Når man som softwareudvikler har behov for at benytte en database, vil man derfor ofte ende med at blande de to paradigmer grundet måden som man bruger databasen på. I listing 4.2 er vist et eksempel skrevet i Java, med metoden hentadresse som tager et navn som argument og returnerer de adresser, som opfylder det givne navn. 1 public ResultSet hentadresse ( String navn ) { 2 String query = SELECT a d r e s s e FROM brugere 3 + WHERE navn= + navn + ; 4 Statement stmt ; 5 ResultSet rs ; 6 stmt = connection. createstatement ( ) ; 7 rs = stmt. executequery ( query ) ; 8 9 return rs ; 10 } Listing 4.2: Java metode med indlejret SQL. Da SQL forespørgsler er opbygget som tekststrenge når de sendes til databasen, er det nødvendigt at sikre sig mod at slutbrugeren kan få udført ondsindet kode på databasen. Dette kan ske hvis slutbrugeren har mulighed for at give fx. et tekst kriterie med til en søgning. Hvis slutbrugeren i denne indsætter et vil strengen i SQL sammenhæng være afsluttet. Dette kan udnyttes på mange måder, afhængig af databasen som benyttes, og beskrives overordnet som injection attacks. Hvis programmøren skal hjælpes til at forhindre injection attacks er det derfor vigtigt at dette sker automatisk, så programmøren ikke behøver tage særlige forholdsregler hver gang en streng behandles. 14
4. Specialeprojektet Vivid Data Objects 4.2 Eksisterende løsninger 4.1.4 Simuleret samtidighed Slutbrugeren af et system som udvikles, vil i de fleste tilfælde forvente at ændringer foretaget på én klient, vil afspejle sig umiddelbart herefter på andre klienter, tilknyttet den samme fælles database. I samme øjeblik man udvikler et stykke software, som skal kunne afvikles på flere forskellige klienter samtidig, med brug af fælles database, er det derfor nødvendigt at have indtænkt samtidighed. Da SQL servere er opbygget på en måde, så klienterne altid forespørger efter data, skal SQL serveren udelukkende holde styr på data og ikke hvilke data de enkelte klienter har indlæst. Grundet denne opbygning er det derfor nødvendigt, at de enkelte klienter selv forespørger efter ændringer, da serveren ikke automatisk leverer disse. Når der skal tages højde for data, som bliver ændret i databasen, involverer det en vis form for kompleksitet, da det kræver hyppige kontrolforespørgsler til databasen. Derudover er det nødvendigt at tage specielle hensyn for at finde ud af om data er blevet slettet fra databasen efter det blev indlæst. Dette bunder i, at data bliver fjernet fra databasen straks, og programmøren derfor ikke kan få en liste over hvilke data, som er blevet slettet, men i stedet har to muligheder for at tjekke om den allerede indlæste data er blevet slettet af en anden klient: 1. For hver enkelt af de i forvejen indlæste data kan databasen forespørges for at se, om dataen stadig findes deri. 2. Indlæse alle data fra en given tabel og herefter krydstjekke denne med de allerede indlæste data. For programmøren betyder det, at der skal lægges ekstra arbejde i at holde de indlæste oplysninger opdaterede, i forhold til ændringer fra andre klienter, samtidig med at der skal tages forbehold, så ændringerne ikke overskrives uforvarende. Processen med at holde indlæst data opdateret i forhold til databasen er bestemt ikke umulig for programmøren, men den er besværlig, omstændig og ligger langt fra den vanlige objektorienterede tankegang. Et værktøj, som skal hjælpe programmøren med at løse samtidighedsproblemerne, skal derfor holde den indlæste data opdateret i forhold til databasen, især med henblik på ikke at overskrive ændringer fra andre klienter. 4.2 Eksisterende løsninger Som beskrevet i de foregående afsnit er der en del problemer at tage hensyn til under udviklingen af en applikation, som benytter en database til lagring af informationer. Først og fremmest er det uhensigtmæssigt at programmøren skal benytte to vidt forskellige paradigmer under udviklingen, da det medfører unødig forvirring 15
4.2 Eksisterende løsninger 4. Specialeprojektet Vivid Data Objects grundet de meget forskellige måder data repræsenteres og behandles på. Derudover er det unødvendigt komplekst, at programmøren selv skal håndtere de mange problemer, da det ofte vil være de samme problemer, som skal løses igen og igen. For at lette programmeringsbyrden vil det derfor være nærliggende at finde et værktøj, som kan automatisere håndteringen af data fra databasen, enten helt eller delvist. I den forbindelse er det vigtigt at finde et værktøj, som er rettet mod brugeren, dvs. i dette tilfælde skal værktøjet være rettet mod programmøren. Netop af hensyn til programmøren er det vigtigt at holde sig indenfor det paradigme der udvikles indenfor, i dette tilfælde, det objektorienterede. Paradigmeproblemet kan løses igennem semantisk integration med værtssproget, enten ved at udvide sproget eller ved at benytte de muligheder, som allerede findes i sproget. En udvidelse af sproget vil helt klart tale imod målet om at gøre det mere simpelt for programmøren at benytte, så den mest oplagt mulighed må være at benytte sprogets eksisterende muligheder, fx. ved at pakke funktionaliteten ind gennem passende klasser og metoder. At benytte sprogets elementer, fremfor at udvide det, passer samtidig godt overens med P. J. Landin s artikel The Next 700 Programming Languages [3], hvori han argumenterer for at have bestemt funktionalitet i pakker som kan bruges i et mere generelt sprog, fremfor at have et sprog, med specialiseret funktionalitet til mange forskellige ting. Dette betyder at hvis man har behov for at arbejde med en database fra sproget, så indlæser man fx. en grænseflade med funktionaliteten hertil i sproget, fremfor at indbygge det i selve sproget. Det er desuden vigtigt, at programmøren ikke skal tænke over de forskelle, som måtte være mellem typerne i det objektorienterede sprog, både i forbindelse med de simple typer, men i lige så stor grad med en kompleks type. I tilfælde hvor der ikke findes en direkte ækvivalent type i sproget, må der bruges den, som er tættest på at være en pendant og derudover tilføres en vis form for overvågning under programmets udførsel, som kan fange eventuelle fejl inden de sendes til databasen. Sidst er det vigtigt, at der tages hensyn til samtidighed (som beskrevet i afsnit 4.1.4) på en måde, så programmøren er fri for at skulle tage forholdsregler for dette, netop fordi området er komplekst og dermed en unødig byrde for programmøren at holde styr på. I de kommende afsnit vil jeg løst beskrive to af de løsninger, som allerede findes på markedet for afspejling af relationel data som objekter til C#, udvalgt fra listen på [10]. De løsninger jeg beskriver, er udvalgt ud fra den funktionalitet, de tilbyder samt ud fra, hvor stor brugerskaren for løsningen skønnes at være. For de beskrevne løsninger gælder det, at de ikke løser problemerne fuldt ud, set fra mit synspunkt. Jeg vil for løsningerne fokusere på de områder hvor de ikke svarer til interesseområdet. 16
4. Specialeprojektet Vivid Data Objects 4.2 Eksisterende løsninger Grunden til at jeg udelukkende har udvalgt to løsninger fra listen er, at de resterende løsninger har væsentlige ligheder med de to udvalgte, og derfor ikke vil bringe andre informationer frem. 4.2.1 Hibernate Hibernate er et værktøj som hjælper med at bygge bro fra en relationel database til et objektorienteret miljø, i enten Java eller C# [9]. Hibernate giver mulighed for persistens, associering, nedarvning samt mange andre objektorienterede aspekter som ikke findes i den relationelle verden. Hibernate er langt fra et automatiseret værktøj, men skal i stedet ses som et mellemlag som kan hjælpe programmøren med at håndtere forbindelsen med databasen, samt muligheden for at sammenkæde håndskrevne klasser med tabeller i databasen (persistens). Det er muligt for programmøren at styre hvordan sammenkædningen forgår, ned til mindste detalje, hvilket naturligvis giver en stor grad af frihed og muligheder. Denne frihedsgrad dækker over at programmøren selv definerer på hvilken måde objekterne gemmes i databasen samt hvordan de efterfølgende indlæses derfra igen. Programmøren slipper dog langt fra for stadig at skulle skrive forespørgsler i en vis grad, men har med Hibernate mulighed for, udover SQL, at benytte Hibernate s eget sprog, HQL. I sin opbygning minder HQL en del om SQL, som vist i listing 4.3 1 s e l e c t adresse from Brugere where Navn = Jens Jensen Listing 4.3: Dataforspørgsel med HQL. Med Hibernate slipper programmøren altså ikke for at skulle skrive forespørgsler i det sprog, som ligger i et andet paradigme. Derudover skal programmøren manuelt holde de oplysninger opdaterede som bruges for at tilbyde persistens til klasserne. Selvom Hibernate tilbyder meget af den funktionalitet som jeg søger at løse, bla. mht. persistens, kræver det stadig i for stor grad manuelt arbejde fra programmørense side, som skal rettes hver gang databaseskemaet ændrer sig. 4.2.2 LINQ LINQ adskiller sig væsentligt fra de andre løsninger som er beskrevet her, men bør alligevel nævnes, da mange programmører er interesserede i de muligheder som den giver. LINQ er en udvidelse til.net, og dermed også tilgængelig i C#, som giver mulighed for at udtrykke dataforspørgsler på bla. SQL databaser og XML data [1]. Integrationen i C# har betydet at der er indført en del nye begreber, primært 17
4.3 Vivid Data Objects 4. Specialeprojektet Vivid Data Objects fra den funktionelle og logiske verden, for at kunne tilsvare de muligheder der er til rådighed i almindelige SQL forespørgsler. I listing 4.4 kan det ses hvordan udtrykket har mange ligheder med en SQL forespørgsel, hvilket ikke vil hjælpe programmøren i den grad som jeg er interesseret i. Til gengæld tilbyder LINQ integreret typetjek, som bestemt vil komme til nytte for programmøren under udviklingen. 1 string navn = Jens Jensen ; 2 IEnumerable<string> expr = from s in Brugere 3 where s. Navn == navn ; Listing 4.4: Dataforspørgsel med LINQ. Selvom LINQ har mange gode muligheder, så er det mest centrale problem med at slippe for paradigmeskift langt fra opfyldt med LINQ, hvorfor den ikke er interessant. 4.3 Vivid Data Objects I de foregående afsnit har jeg beskrevet nogle af de allerede eksisterende løsninger på markedet indenfor afspejling af relationelle data som objekter til C#. Eftersom ingen af de funde løsninger løser de problemer som jeg beskrev i afsnit 4.1 valgte AHJ og jeg at lave værktøjet Vivid Data Objects (VDO) [6], som jeg i dette afsnit vil beskrive nærmere. Jeg vil beskrive både styrker og svagheder i denne, så læseren får indblik i hvilke dele som virker i den producerede prototype. Det overordnede mål med VDO var at lave et værktøj som er rettet mod programmøren som skal bruge det, på en måde så det kan virke tidsbesparende. Det var derfor vigtigt for os at automatisere så stor en del af processen som muligt, og dermed slække en smule på valgfriheden i opbygningen af klasserne som skal repræsentere data. En af grundene hertil bunder i vores observationer fra andre værktøjer, hvor programmøren slipper for at skrive SQL forespørgsler, blot for at skulle skrive noget andet tilsvarende i stedet for. Derfor var det vigtigt at lave en automatiseret løsning, dvs. at programmøren ikke behøver at konfigurere en hel masse, men hurtigt kan gå i gang med at bruge værktøjet. Udover de overordnede mål for VDO valgte vi også at basere vores løsning på C# da det er det eneste sprog indenfor vores interesseområde som gav os en fornuftig måde at løse problematikken omkring null-værdier. Derudover tilpassede vi kun VDO til at fungere sammen med Microsoft SQL Server 2005 for bedre at kunne fokusere på funktionaliteten, fremfor at understøtte mange forskellige databaser. Rammerne for VDO værktøjet blev valgt til at være velkendte design mønstre, eftersom de er de bedste fremgangsmåder til at løse ikke-trivielle opgaver [6, s. 55]. Endnu en fordel ved at bruge velkendte design mønstre er at programmørerne som skal bruge værktøjet sandsynligvis allerede kender noget til disse 18
4. Specialeprojektet Vivid Data Objects 4.3 Vivid Data Objects Figur 4.1: Abonnering på ændringer i liste. mønstre, eller som minimum har let ved at sætte sig ind i hvordan mønstret bruges, da mønstrene er beskrevet grundigt i litteraturen, bla. i [2]. De mønstre som blev valgt var Active Record, Identity Map, Lazy Load samt Observer, og er alle beskrevet grundigt i [6, kap. 5] og [2]. Udover de velkendte mønstre valgte vi at opbygge en synkroniseringsmekanisme som står for at holde de indlæste data opdateret i forhold til databasen, så programmøren ikke behøver tænke på dette. Synkroniseringsmekanismen simulerer derfor samtidighed, som var endnu et af de ønskede kriterier vi opstillede. Denne mekanisme er samtidig også grunden til at vi indbyggede Observer mønstret, da programmøren igennem dette har mulighed for at udføre bestemte handlinger hvis de indlæste data ændres gennem synkroniseringsmekanismen. I figur 4.1 kan vi se hvordan programmøren kan få sit program til at udskrive en besked når data ændrer sig for elementerne i den indlæste liste. For at det skal give mening at kunne abonnere på ændringer i data elementer, eller søgeresultater som i det viste eksempel, er det vigtigt at alle indlæste data er unikke. Det betyder at hver gang et bestemt data element tilgås, på den ene eller anden måde, så er det nøjagtigt det samme data element. Det samme gælder for søgeresultater, hvor to søgninger med de samme kriterier skal resultere i den samme liste. Fordi der genereres klasser, opfyldes ønsket om semantisk integration, samtidig med at løsningen er meget rettet mod programmøren i sin opbygninge jf. Active Record mønstret. Samtidig bliver alle typer pakket ind så programmøren slipper for at tage specielle hensyn for at sikre sig imod fx. injection attacks. Det er også denne indpakning som sørger for at typer som ikke kan oversættes direkte, alligevel kan bruges ud fra den type som tilsvarer mest. Dermed gøres det også let for programmøren at tage hensyn til tekststrenge som er blevet længere end hvad der kan gemmes i databasen, på en simpel måde. Direkte på de objekter man arbejder med er det muligt at udføre lette opratio- 19
4.3 Vivid Data Objects 4. Specialeprojektet Vivid Data Objects Figur 4.2: Gem et objekt. ner, som fx. at gemme i databasen, hvilket er illustreret i figur 4.2. Programmøren skal ikke tage hensyn til om objektets data tidligere har været gemt i databasen, som ellers ville være nødvendigt uden grænsefladen. Måden som klasserne opbygges på gør det kort sagt lettere for programmøren at tilgå, gemme og slette data elementer fra databasen, på en objektorienteret facon. Hvis man skal tilgå data, findes der statiske søgemetoder på klasserne, som man giver søgekriterier, og returnerer en liste med data elementer som opfylder det givne søgekriterie. Da formålet med VDO compileren var at teste funktionalitet i grænsefladen, blev denne opbygget uden at benytte gængse teknikker for compilerdesign, da vi ikke skønnede at resultatet hermed ville stå mål med det krævede arbejde. Umiddelbart gør denne opbygning af compileren ingen forskel på resultatet den genererer, men det gør det meget besværligt at ændre på hvordan grænsefladen genereres. VDO compileren fungerer ved at den indlæser informationer om databaseskemaet, hvorefter den ud fra dette genererer en grænseflade som er tilpasset det specifikke skema. Programmøren skal derfor ikke foretage ændringerne manuelt andre steder end i databasens skema, herefter er det nok at eksekvere compileren for at grænsefladen igen er tilpasset det ændrede skema. Når programmet som benytter grænsefladen compiles, vil det blive påpeget hvis ændringerne bevirker at der skal rettes i applikationen, så programmøren ikke risikerer at der opstår fejl som følge af ændringerne. Den største styrke i VDO er måden synkroniseringsmekanismen fungerer på, så programmøren ikke behøver at tænke over at der er også er andre klienter som benytter de samme data. Derudover bevirker de mønstre som bruges, at data repræsenteres på en fornuftig måde i forhold til databaseskemaet. Derudover er det praktisk at applikationer som benytter VDO kan fungere sideløbende med ældre applikationer, uden at miste funktionalitet. De største svagheder i VDO er især at der mangler integreret dokumentation for metoderne, samt de meget begrænsede søgemuligheder. Det er sjældent man kun har behov for at søge ud fra et enkelt søgekriterie, som er eneste mulighed man har med VDO. 20
5 Forretningsmuligheder I det foregående kapitel om specialeprojektet Vivid Data Objects, som jeg udarbejdede sammen med AHJ, gennemgik jeg incitamentet for at lave VDO og beskrev hvor langt arbejdet med dette nåede. Da jeg stadig mener, at mange programmører har behov for at få løst problemerne som jeg beskrev i kapitel 4, vil jeg nu se på, hvordan dette kan udnyttes i en kommerciel sammenhæng. Jeg vil derfor, med udgangspunkt i VDO, se på hvad et produkt, henvendt mod at løse problemerne i forbindelse med brug af database, skal indeholde. Produktet har jeg valgt at kalde DB Flow, da jeg synes det bedre beskriver, at det drejer sig om at gøre data fra en database lettere tilgængelig, samt for at adskille det fra VDO. Jeg vil afdække de overordnede rammer for DB Flow, som skal hjælpe med at holde fokus på, hvilken funktionalitet der skal være en del af DB Flow. Med rammerne på plads vil jeg beskrive, hvordan DB Flow kan bruges som fundament til opstart af en virksomhed, og hvordan der herefter kan skrives en forretningsplan. Jeg vil desuden se på, hvilken rolle forretningsplanen spiller ved opstart af virksomhed, samt hvordan man som iværksætter kan bruge forretningsplanen til at holde fokus gennem opstart. 5.1 DB Flow Eftersom VDO er den direkte inspirationskilde til DB Flow vil de naturligt nok have en del lighedspunkter, men der vil samtidig være områder hvor de adskiller sig markant fra hinanden, eftersom VDO udelukkende har været ment som en prototype til at teste nogle grundlæggende idéer. Jeg vil i dette afsnit primært beskæftige mig med de områder hvor DB Flow adskiller sig fra VDO. Derudover vil den følgende beskrivelse af DB Flow være det primære referencepunkt for den fremtidige udvikling af produktet, og vil blive brugt nærmere i kapitel 7.1 hvor jeg vil prioritere funktionaliteterne på en liste, og ud fra denne liste beskrive hvordan udviklingen skal foregå med opstilling af milepæle. 21
5.1 DB Flow 5. Forretningsmuligheder Figur 5.1: Integreret dokumentation af Save metoden. DB Flow er skabt for at repræsentere data fra en relationel database i et objektorienteret miljø, på en måde så opbygningen i databasens tabeller danner grundlag for de klasser som bliver stillet til rådighed. Da grænsefladen er målrettet mod programmøren som skal bruge den, kræver den kun et minimum af inputs for at kunne generere grænsefladen ud fra det givne databaseskema. Derudover er der valgt nogle passende mønstre for design i den genererede grænseflade, som ikke skjuler tilknytningen til databasen, samtidig med at programmøren på en simpel måde kan bruge denne, og derfor ikke behøver have stort kendskab til databaser og SQL. Selvom den endelige adfærd af DB Flow skal tilpasses hvad kunderne ønsker, er det vigtigt at have for øje at grænsefladen ikke skal tilbyde andet end repræsentation af data med tilhørende søgemuligheder. Hvis der indføres funktionalitet som går udover dette skal det overvejes nøje, da det let kan ende ud med at gå imod de overordnede principper om at gøre det let og overskueligt for programmøren at benytte databasen. I den genererede grænseflade er det også meget vigtigt at der er integreret en grundig dokumentation, så programmøren aldrig er i tvivl om hvad der sker når der benyttes en bestemt metode, hvilket er illusteret i figur 5.1. Selvom navnene på metoderne er valgt, så de er meget beskrivende, er det dokumentationen som sikrer, at programmøren aldrig er i tvivl om hvilken funktion der udføres. Udover at beskrive adfæren for metoderne, skal dokumenationen også forklare hvilke potentielle undtagelser (exceptions) som kan opstå, så programmøren kan tage hensyn til disse i sin kode. For at tiltrække så stort et publikum som muligt, er det vigtigt at understøtte de mest ubredte databasesystemer, herunder MySQL og PostgreSQL, udover den allerede understøttede MSSQL 2005. Noget af det som der skal ofres mest udviklingstid på er søgemulighederne, da det er vigtigt for programmøren at have rigeligt med kriterier for at udvælge den data som skal bruges. Søgemulighederne skal opbygges på en måde så de er simple at bruge, samtidig med at de giver rigeligt med frihed i søgningerne. For at de skal være simple at bruge, er det vigtigt at de også tilpasses det enkelte 22
5. Forretningsmuligheder 5.2 Opstart af virksomhed databaseskema, så programmøren ikke behøver at frygte fejl i søgningerne, og samtidig gør programmøren opmærksom på de muligheder der er med søgningerne. Søgemulighederne skal opbygges på en måde så det passer til det behov en typisk programmør vil have. Noget banebrydende for DB Flow ville være at give mulighed for at gå offline med databasens indhold. Denne funktionalitet kunne bruges i forbindelse med programmer udviklet til at bruge steder hvor der ikke er adgang til databasen, fx. programmer til omrejsende salgspersoner. Mulighed for at gå offline ville kræve en lokal udgave af databasens indhold, hvilket kan klares med en integreret database som fx. SQLite [11], og dermed sikre at programmøren ikke får ekstra arbejde ud af denne ekstra funktionalitet. I forbindelse med en offline mulighed skal det overvejes om data i tabellerne skal være skrivebeskyttet, da der ellers kan opstå mange problemer hvis flere offline klienter har ændret i de samme data. Ved kun at tillade oprettelse af nye data, og ingen redigering af eksisterende data, vil dette blive undgået. Da denne beskrivelse af DB Flow udelukkende skal ses som en initierende rettesnor for udviklingen, vil den fremtidige udvikling ske i samarbejde med brugerne, så grænsefladen vil være tilpasset de behov som skulle opstå. 5.2 Opstart af virksomhed Når man som iværksætter skal springe ud i at starte en virksomhed op vil der næsten altid være mange spørgsmål som gør sig gældende, sammen med en stor usikkerhed. Dette gælder uanset om man skal starte en virksomhed op helt fra bunden, eller som i mit tilfælde, hvor det er en allerede eksisterende virksomhed der skal vækkes fra dvale. Denne virksomhed vil blive introduceret nærmere i starten af forretningsplanen i kapitel 6. Det kan derfor godt betale sig at man, inden virksomhedens opstart, får gennemtænkt grundlaget som man vil bygge virksomheden på, og planlagt ud fra dette grundlag [5, s. 11]. Grundlaget for virksomheden dokumenteres i en forretningsplan som kan bruges til at samle de idéer og planer man har for at føre en forretningsidé ud i livet, og for at se om det hele hænger fornuftigt sammen. Processen med at producere forretningsplanen kan desuden bruges til at belyse hvilke kompetencer virksomheden ikke selv er i besiddelse af og derfor har brug for at samarbejde med andre om [5, s. 12]. 5.2.1 Forretningsplanen Forretningsplanen skrives dels for at holde fokus og dels for at gøre andre parter interesserede i virksomheden [8]. De parter som forretningsplanen skal henvende 23
5.2 Opstart af virksomhed 5. Forretningsmuligheder sig til ses som målgruppen, som i mange tilfælde vil være investorer eller andre former for samarbejdspartnere. Når forretningsplanen udfærdiges er det derfor vigtigt at tage hensyn til målgruppen, da det ellers vil være spildt arbejde at lave forretningsplanen. Der kan dog være visse tilfælde hvor nogle parter i målgruppen vil være vigtigere end andre, fx. hvis man har behov for at tiltrække investorer. I disse tilfælde er det vigtigt at tage mest hensyn til de vigtigste parter i målgruppen, hvilket kan have stor betydning for indholdet. Det største succeskriterie for forretningsplanen må dermed være at målgruppens vigtigste parter forstår forretningsplanen, og den bør derfor tage specielt hensyn til disse. Med en forretningsplan er det muligt at planlægge opstarten af virksomheden, og når virksomheden er etableret bør forretningsplanen desuden bruges til at holde øje med den daglige drift og tjekke om denne stemmer overens med det planlagte. Dermed ikke sagt at forretningsplanen ikke kan ændres, da det vil være naturligt at bearbejde den forfra hvis virksomheden skal udvikles. Derimod er det farligt at føre virksomheden ud på områder som forretningsplanen ikke omhandler, da man let kan overse nogle af de punkter, som man i forretningsplanen vil gennemgå, og dermed overse hvordan det vil påvirke hele virksomheden. I mit konkrete tilfælde skal forretningsplanen derfor omhandle produktet DB Flow og vurdere hvorledes dette kan bruges i forbindelse med opstart af virksomhed. I den forbindelse vil de vigtigste målgrupper være de samarbejdspartnere som jeg har brug for i opstartsfasen, da jeg nødvendigvis skal fremstå troværdigt, især for at samarbejdspartnere skal have lyst til at investere tid i implementering af DB Flow. Derudover er det også vigtigt at forretningsplanen vil virke overbevisende overfor bank eller en investor, så jeg kan skaffe opstartskapital, samt overfor et af de mange mulige netværk man som nystartet virksomhed kan blive en del af. Min forretningsplan er fremlagt i kapitel 6, og er ment til at kunne tages ud af konteksten fra denne rapport, dvs. bruges i forbindelse med mulige investorer og samarbejdspartnere. 24
III Planlægning 25
6 Forretningsplan Denne forretningsplan beskriver, hvorledes det er min hensigt, at bringe fokus ind i min virksomhed Netspecialisten, som jeg har drevet siden sommeren 2001. Virksomheden har jeg brugt til mange forskellige aktiviteter, herunder design af hjemmesider, opsætning af computere samt salg af netværksudstyr. Målet er nu, at jeg med produktet DB Flow, kan bringe fokus ind i Netspecialisten, og derefter lade virksomhedens fremtid forme sig omkring dette. Herefter er det planen, at virksomheden skal blive min fuldtidsbeskæftigelse, når jeg er færdig med at være studerende på AAU, fra sommeren 2008. Jeg vil derfor se på mit firma Netspecialisten på samme måde som hvis det var en hel ny virksomhed der skulle startes op. Enkelte dele af forretningsplanen kræver stadig yderligere arbejde for at være fyldestgørende, da der er behov for yderligere undersøgelser til at træffe beslutninger ud fra. Dette gælder bla. prissætningen af produktet DB Flow, da kunderne gerne skulle opleve en besparelse ved at benytte DB Flow. For de dele af forretningsplanen som mangler yderligere arbejde vil dette blive præciseret med oplæg til hvordan de kan færdiggøres inden forretningsplanen skal tages i brug ved endt studietid. 6.1 Baggrundsoplysninger Netspecialisten Jacob Volstrup Tlf: 28715844 E-mail: volstrup@avanceret.dk Stud. scient i Datalogi 27
6.2 Resumé 6. Forretningsplan 6.2 Resumé DB Flow er en specialtilpasset grænseflade til at lette brugen af en SQL database fra programmeringssproget C#. Grænsefladen automatiserer kommunikationen med databasen, så programmøren kan beskæftige sig med mere krævende opgaver. Da der ikke findes andre lignende værktøjer på markedet, findes der med stor sandsynlighed en stor potentiel kundegruppe, som har behov for at bruge deres tilgængelige arbejdsressourcer på de krævende opgaver. Da der allerede er planlagt en konstant udvikling af værktøjet, vil det med stor sandsynlighed virke mere tillokkende overfor potentielle kunder, da de garanteres at fejl bliver løst inden for overskuelig tid, samt at værktøjet vil modnes med tiden. Ved at opstarte virksomheden som et Aps. skal der lånes 135.000 kr., hvorefter det skulle være muligt at klare det første år (juli 2008 - juni 2009) uden yderligere indskud. Hvis der i løbet af det første år ikke kommer indtægter vil der opstå et underskud på 32.200 kr. i forhold til tilgængelig kapital, hvilket samtidig betyder at der kun kræves begrænset salg for at undgå at løbe tør for kapital. Efter det første år skulle virksomheden gerne hvile i sig selv, med potentiale til at generere overskud allerede efter det første år. Der er opstillet et positivt estimat med et samlet salg for 209.000 kr. for det første driftsår, hvilket vil give et overskud på 51.800 kr. som ikke burde være helt urealistisk. 6.3 Idégrundlag I store dele af den software som udvikles, benyttes en SQL database til at gemme informatiner på tværs af programsessioner. Når denne software skal skrives er programmørerne nødt til at arbejde med vidt forskellige programmeringsparadigmer, da SQL adskiller sig fra de sprog som programmerne udvikles i. Desuden er der stor risiko for at programmørerne vil komme til at lave fejl i kommunikationen med databasen, enten i større eller mindre grad. Målsætningen for DB Flow er, at programmører i fremtiden kan slippe for paradigmeskift under udviklingen af software, som benytter en database. Ved at skifte paradigme er det sværere for programmøren at holde fokus på den funktionalitet, som arbejdes med, og der er stor risiko for at lave fejl. Modsat sproglige udvidelser som Linq til C# vil dette værktøj hjælpe programmøren med at holde fokus indenfor det objektorienterede paradigme. Gennem udarbejdelsen af tidligere IT systemer har jeg flere gange haft behov for at lette arbejdet med at benytte en database som underliggende platform til at gemme data på tværs af program sessioner, især i miljøer hvor flere klienter benyttes samtidig. Almindeligvis er det en besværlig opgave for programmøren især i kraft af, at denne konstant skal skifte sin tankevirksomhed mellem flere uafhængige paradigmer, hvilket kan virke negativt for udviklingsprocessen. 28
6. Forretningsplan 6.4 Personlige ressourcer og mål Hver gang der ændres i databasens skema skal det tilsvarende modellag tilpasses, hvilket medfører en vis risiko for, at der indtræder nye fejl, samtidig med at det er en tidskrævende procedure. Der findes værktøjer som er beregnet til at hjælpe med at benytte en database, men disse er lavet meget generelle, hvilket ofte betyder at programmøren reelt set ikke sparer ret meget tid, sammenlignet med at benytte databasen uden disse værktøjer. Da der de seneste år er opstået et stigende behov for højtuddannede indenfor de fleste faggrupper, kan det virke grotesk at lade disse sidde og udarbejde den samme type programkode hver gang der ændres i strukturen for en database. DB Flow er et værktøj som genererer en grænseflade som er specielt tilpasset til en given database. Ved at benytte denne grænseflade slipper programmøren for at udføre de samme opgavetyper hver gang strukturen for databasen ændres, og får derved frigjort potentielle arbejdskræfter, som er til rådighed, til mere krævende opgaver. Den specialiserede grænseflade giver programmøren ekstra muligheder, som normalt kræver lang tids arbejde, samtidig med at risikoen for fejl er kraftigt reduceret. DB Flow grænsefladen tager sig af al kommunikationen med databasen, og lader dermed programmøren bruge sin tid på de mere komplekse dele af programudviklingen, som ikke lader sig automatisere igennem generalisering. Da grænsefladen genereres ud fra databasens skema, simplificeres ændringerne for programmøren, da tilpasningen i modellaget automatiseres igennem genereringen. Derved fjernes risikoen for fejl efter ændringer på data strukturen, grundet mange indbyggede tjek på korrekthed. Desuden er grænsefladen opbygget efter udbredte design mønstre, som derved letter brugen af databasen yderligere. Da DB Flow i udviklingsfasen skal gennemgå større ændringer for at tilpasse sig kundernes krav og behov, er det en fordel at have en lille virksomhed uden lange beslutningsgange. Derved kan jeg let tilpasse værktøjet til de behov, som skulle være til stede hos kunden. Set fra Netspecialistens synspunkt så er planen på længere sigt at blive underleverandør til softwarefirmaer som kan drage stor nytte af automatisering i deres udvikling, først med henblik på brug af database, men senere vil det være naturligt at kigge på andre områder og til disse bruge den erfaring, som er indsamlet under arbejdet med DB Flow. I det lange løb skal Netspecialisten derfor gerne blive den foretrukne samarbejdspartner, når dele af softwareudviklingen skal automatiseres. 6.4 Personlige ressourcer og mål Jeg har gennem de sidste 10 år arbejdet med både større og mindre systemer til administrativt brug, og i den forbindelse fået mig en del erfaringer med brug af databaser. Da jeg helt fra starten har haft en stor interesse i brug af databaser, 29
6.4 Personlige ressourcer og mål 6. Forretningsplan har jeg gennem arbejdet med disse systemer fået en stor viden omkring brugen af databaser, og denne viden kan jeg nu drage stor nytte af. Et af disse systemer jeg tidligere har udarbejdet, er et større administrativt IT system for nogle sekretærer på en afdeling af AAU, som bruger systemet i deres dagligdag. Som en del af dette system er tilknyttet en hjemmeside som giver de studerende en vis grad af selvbetjening, og begge systemer er koblet op mod den samme database. På nuværende tidspunkt studerer jeg datalogi og har skrevet speciale indenfor Programmeringsteknologier. De primære interesser indenfor programmering ligger på automatisering af opgaver, herunder især opgaver for programmøren. Dette har bla. resulteret i en rapport som analyserer problemer og mulige løsninger på at bruge en relationel database fra et objektorienteret programmeringssprog, samt et speciale som søger at skabe en løsning på dette problem. Det er desuden dette speciale som danner grobund for DB Flow. Den primære grund til at jeg har lyst til at overføre min viden fra mit specialeprojekt til en virksomhed, er netop lysten til at gøre det lettere at være programmør og jeg føler netop, at det er muligt med værktøjet DB Flow. I en tid hvor flere og flere opgaver automatiseres, virker det samtidig oplagt at hjælpe softwarehuse med at flytte deres ressourcer væk fra den trivielle udvikling omkring brug af databaser. Jeg ser det som en ekstra personlig force at jeg gennem mange år har arbejdet med den type applikationer som DB Flow henvender sig til, og dermed har indblik i hvilke problemer og frustrationer man normalt støder på når man udvikler disse. Dette indgående kendskab kan jeg bruge i den indledende fase af udviklingen af DB Flow, til at bestemme hvilken funktionalitet som værktøjet skal indeholde. I forbindelse med opstart af virksomhed har jeg i efteråret 2007 fulgt kurset Iværksættertræning med mentor hos SEA (Supporting Entrepreneurship at Aalborg University), som er en del af iværksætternetværket på AAU. Forløbet på 30 timer omhandlede de forskellige elementer af en forretningsplan, samt gav mulighed for at få råd og vejledning fra oplægsholderne. Jeg fravalgte at få tilknyttet en mentor da det først var meget sent i forløbet det blev muligt, og jeg på daværende tidspunkt ikke følte jeg havde tid til at kunne drage nytte. Kurset har vist mange forskellige aspekter omkring opstart af egen virksomhed, som jeg håber at kunne drage nytte af når jeg bringer fokus tilbage i min virksomhed Netspecialisten. Derudover har jeg igennem kurset skabt kontakt til nogle personer jeg kan benytte mig af under opstarten, både oplægsholdere og andre deltagere i kurset. Mine stærkeste sider i forhold til konkurrenterne ser jeg som værende mit indgående kendskab til brug af database fra objektorienterede programmeringssprog, med fokus på at lette arbejdet i denne forbindelse. Derudover mener jeg selv at 30