Merged

documents/kandidatarbete/enskilda/erik.tex

@@ -15,7 +15,7 @@ \subsubsection{Frågeställning}
 
 \begin{itemize}
 \item Hur kan man använda Travis CI tillsammans med Jasmine för att testa en 
-webbapplikation byggd på javascript och node.js.
+webbapplikation byggd på javascript och node.js?
 \item Hur många tester hinner Travis CI köra på en sekund?
 \item Vilka typer av tester är svåra att utföra?
 \end{itemize}
@@ -62,6 +62,11 @@ \subsubsection{Javascript}
 Document Object Model (DOM).
 
 \subsubsection{JQuery}
+JQuery är ett javascript-bibliotek som kan användas för att förenkla programeringen
+av javascript på klientsidan av en webbsida. JQuery innehåller lättanvänd
+funktionalitet för händelsehantering och modifiering av HTML-objekt.
+JQuery är gratis och baserat på öppen källkod som är tillgänglig under en
+MIT-licens.
 
 \subsubsection{Node.js}
 Node.js är en runtime environment för internetapplikationer. Det kan till exempel 
@@ -165,7 +170,8 @@ \subsection{Metod}
 som förväntats. Flera expect-funktioner kan användas i samma testfall.\\
 
 Ett speciellt testfall skrevs
-för att besvara frågeställningen om hur många tester som Travis CI kan köra
+för att besvara den andra frågeställningen om hur många tester som 
+Travis CI kan köra
 på en sekund. Det speciella testfallet visas nedan.
 
 \begin{lstlisting}[
@@ -197,8 +203,11 @@ \subsection{Metod}
 
 Testfallet testar funktionen splitOnce() så många gånger som möjligt
 under en sekund. Antalet gånger som funktionen hann köras skrivs
-sedan ut på skärmen med en console.log(). För att antalet ska
-fåen konkret betydelse visas även funktionen splitOnce() nedan.
+sedan ut på skärmen med en console.log(). 
+Testfallet har körts flera gånger på olika datum och olika tidpunkter.
+Resultatet av testerna presenteras i en tabell under rubriken Resultat.
+För att antalet ska
+få en konkret betydelse visas även funktionen splitOnce() nedan.
 
 \begin{lstlisting}[
   basicstyle = \small
@@ -213,7 +222,46 @@ \subsection{Metod}
 };
 \end{lstlisting}
 
+Funktionen tar två paramterar. En sträng (str) som ska delas upp och 
+en sträng (split) som anger vilket tecken eller vilken teckenkombination
+som ska dela upp strängen. Funktionen delar endast upp strängen i två delar
+även om (split) förekommer påflera positioner i (str). Funktionen returnerar 
+en array med två element.
+De två elementen är de två delarna av den ursprungliga strängen. Om den andra
+parametern (split) inte existerar i den första parametern (str) så returneras
+hela strängen i det första elementet och en tom sträng i det andra elementet.\\
+
+För att besvara den tredje frågeställningen om vilka tester som är svåra att
+utföra så gicks koden igenom och försök till att skriva testfall genomfördes
+med de olika delarna av koden.
+
 \subsection{Resultat}
+Här presenteras resultatet av rapporten, det vill säga svaren på
+frågeställningarna.
+
+\subsubsection{Hur kan man använda Travis CI tillsammans med Jasmine 
+för att testa en webbapplikation byggd på javascript och node.js?}
+
+\subsubsection{Hur många tester hinner Travis CI köra på en sekund?}
+Resultatet av testerna som utfördes för att besvara den andra frågeställningen
+visas i tabellen nedan.
+
+\begin{center}
+  \begin{tabular}{| l | l | l | l |}
+  \hline
+  Testnummer & Datum (ÅÅ-MM-DD) & Tid (hh-mm-ss) & Test per sekund\\ \hline
+  1 & 15-05-01 & 13:53:34 & 11380\\ \hline
+  2 & 15-05-01 & 14:27:27 & 12462\\ \hline
+  3 & 15-05-01 & 14:47:14 & 9386\\ \hline 
+  4 & 15-05-03 & 10:21:57 & 14093\\ \hline 
+  5 & 15-05-03 & 15:43:20 & 9875\\ \hline 
+  6 & 15-05-04 & 09:42:39 & 10156\\ \hline 
+  7 & 15-05-04 & 11:14:43 & 11933\\ \hline 
+  \end{tabular}
+\end{center}
+
+\subsubsection{Vilka typer av tester är svåra att utföra?}
+
 \subsection{Diskussion}
 \subsubsection{Resultat}
 \subsubsection{Metod}

documents/kandidatarbete/enskilda/falk.tex

@@ -1,6 +1,6 @@
 \section{Daniel Falk}
 \subsection{Inledning}
-Jag har i detta projekt haft rollen som analysansvarig vilket innebär en analys av kundens behov och framställning av krav utifrån dessa. Rapporten beskriver hur kravframställningen gått till i detta projekt och hur prototyper har använts för att kommunicera idéer.
+Jag har i detta projekt haft rollen som analysansvarig vilket innebär en analys av kundens behov och framställning av krav utifrån dessa. Rapporten beskriver hur kravframställningen gått till i detta projekt och hur prototyper har använts för att kommunicera idéer. 
 \subsubsection{Syfte}
 Syftet med denna del av rapporten är att ta reda på hur man kan samla in krav som kunden har på produkten. Fokus ligger på användningen av prototyper med utgångspunkt i detta projekt.
 \subsubsection{Frågeställning}
@@ -19,6 +19,10 @@ \subsubsection{Problem}
 
 \subsubsection{Vertktyg}
 Prototyper
+Prototyp är ett ord som har sina rötter i grekiskan och betyder \textit{första form}\cite{Arvola}. Deras syfte är att i ett tidigt skede beskriva hur det färdiga systemet ska fungera. Prototyper kan användas för att testa olika ideér och designer och kan variera i detaljrikedom. En tydlig skillnad är den mellan enkla LoFi-prototyper skissade på papper och datorbaserade HiFi-prototyper som mer liknar det riktiga systemet. LoFi-prototyper är ett bra verktyg för att snabbt kunna diskutera ett designval då det kräver väldigt lite arbete. En styrka hos LoFi-prototyper är att användare har lätt att komma med kritiska kommentarer utan att känna att de förolämpar designern\cite{Arvola}.
+Prototyper kan vara temopära eller evolutionära\cite{Arvola}. En temporär prototyp är en prototyp som slängs efter att man har använt den och utvärderat den. En evolutionär prototyp slängs inte utan byggs vidare på. Man kan se det som en tidig version av det slutgiltiga systemet.
+
+
 \subsubsection{Kravinsamlingsmetoder}
 \subsection{Metod}
 Denna del beskriver hur kravframställningen gått till i detta projekt. Först beskrivs arbetet med att analysera kundens behov under förstudien. Vidare beskrivs mer ingående vilka metoder som använts och hur kraven valdes att representeras. Avslutningsvis beskrivs vilka användartester som genomfördes och hur dessa bedrog till utvecklingen.
@@ -40,7 +44,6 @@ \subsubsection{Kravrepresentation}
 Enligt standarden uttrycktes kraven på ska-form. Ett exempel på ett krav från projektet är följande: "Plocklistor ska innehålla information om artikelns namn, förråd, sektion, hylla och fack".
 \subsubsection{Prototyning}
 Under förstudien valde vi att göra LoFi-prototyper som vi tog med till kund. Vid dessa tester kunde vi se om vi var på rätt bana när det gällde design och struktur. LoFi-protptyperna utjordes av enkla pappersskisser. Ett exempel visas i figur~\ref{fig:lofiprototyper}.
-
 \begin{figure}[htbp]
 \begin{center}
 \includegraphics[scale=0.2]{lofiprototyper.png}
@@ -50,6 +53,7 @@ \subsubsection{Prototyning}
 \end{figure}
 Vi hade vid vissa tillfällen olika förslag på design och samlade då in positiva och negativa kommentaren om de olika prototyperna.
 
+Själva systemet kan ses som en evolutionär HiFi-prototyp som vid varje iterationsslut utvärderades i samband med kundmöten. 
 
 
 \subsubsection{Användartest}
@@ -61,11 +65,13 @@ \subsubsection{Resultat}
 \subsubsection{Metod}
 \subsection{Slutsatser}
 \subsection{Referenser}
+%Note to self:Dubbelkolla referenserna
+
 \vspace{-9mm}
 \begin{thebibliography}{9}
 \bibitem{Lauesen}
 Lauesen, S. (2002) Software Requirements: Styles and Techniques. Harlow: AddisonWessly.
+\bibitem{Arvola}
+Arvola, M. (2014) Interaktionsdesign och UX: Om att skapa en god användarupplevelse. %Kolla upp förlag!!!!!!!!
 \end{thebibliography}
 
-%Lauesen, S. (2002) Software Requirements: Styles and Techniques. Harlow: AddisonWessly. %Note to self:Dubbelkolla
-

documents/kandidatarbete/enskilda/pal.tex

@@ -1,7 +1,6 @@
 \section{Pål Kastman}
 \subsection{Inledning}
-I detta projekt så har vi valt att inledningsvis skriva dokumentationen i Googles ordbehandlingsprogram Google Docs för att 
-i ett senare skede då det var dags att påbörja denna rapport gå över till att använda typsättningssystemet Latex. 
+I detta projekt så har vi valt att inledningsvis skriva dokumentationen i Googles ordbehandlingsprogram Google Docs för att i ett senare skede, då det var dags att påbörja denna rapport gå över till att använda typsättningssystemet Latex. 
 
 Vi valde att göra på detta sätt för att så snabbt som möjligt komma igång, då man bland annat i Google Docs kan se live 
 vad andra skriver.
@@ -16,52 +15,43 @@ \subsubsection{Frågeställning}
 \end{itemize}
 
 \subsubsection{Avgränsningar}
-Denna rapport kommer att avgränsas för att endast jämföra Latex, Microsoft Office och Google Docs, detta för att 
-inte behöva jämföra alla olika ordbenhandlingsprogram.
+Denna rapport kommer att avgränsas för att endast jämföra Latex, Microsoft Office och Google Docs, detta för att inte behöva jämföra alla olika ordbenhandlingsprogram.
 
 \subsection{Bakgrund}
-Dokumentering är någonting som är viktigt att göra när man arbetar i projektform, dels för egen del utifall man behöver 
-gå tillbaka och se vad som gjorts, men även för andras skull ifall man kanske får en ny medarbetare som ska integreras i 
-projektet. En fråga som man alltid behöver besvara är i vilket ordbehandlingsprogram dokumentationen skall skrivas. Det populäraste 
-alternativet kan tänkas vara Microsoft Word, vilket har funnits sedan 1983 \cite{word_ursprung}.
+Dokumentering är någonting som är viktigt att göra när man arbetar i projektform, dels för egen del utifall man behöver gå tillbaka och se vad som gjorts, men även för andras skull ifall man kanske får en ny medarbetare som ska integreras i 
+projektet. En fråga som man alltid behöver besvara är i vilket ordbehandlingsprogram dokumentationen skall skrivas. Det populäraste alternativet kan tänkas vara Microsoft Word, vilket har funnits sedan 1983 \cite{word_ursprung}.
 
 Ett annat alternativ som blir allt vanligare är Google Docs, vilket är ett web-baserat ordbehandlingsprogram som lanserades av Google 2006 \cite{docs_launch} efter att man hade köpt upp företaget Upstartle \cite{upstartle}.
 
-Ett tredje och inte lika vanligt alternativ är Latex, vilket inte är ett ordbehandlingsprogram utan istället ett märkspråk
- så som t.ex. HTML, där man istället för med ett grafiskt gränssnitt formaterar sin text,sätter sin text inom speciella taggar så att när koden senare kompileras får rätt utseende.
+Ett tredje och inte lika vanligt alternativ är Latex, vilket inte är ett ordbehandlingsprogram utan istället ett märkspråk så som t.ex. HTML, där man istället för med ett grafiskt gränssnitt formaterar sin text,sätter sin text inom speciella taggar så att när koden senare kompileras får rätt utseende.
 
 Latex är egentligen bara en uppsättning makron skrivna för språket Tex, vilket skapades av den amerikanske matimatikern Donald Knuth 1978 \cite{donald_knuth}. I början av 80-talet så vidareutvecklade Leslie Lamport Tex med hjälp av dess makrospråk till det som 
 idag är Latex \cite{leslie_lamport}.
 
-Vad det gäller min egen bakgrund i Latex så hade jag när detta projektet påbörjades endast använt det i ett tidigare projekt, under det projektet
-blev jag dock inte så insatt i Latex utan fyllde endast i material i de redan färdiga mallarna vi hade.
+Vad det gäller min egen bakgrund i Latex så hade jag när detta projektet påbörjades endast använt det i ett tidigare projekt, under det projektet blev jag dock inte så insatt i Latex utan fyllde endast i material i de redan färdiga mallarna vi hade.
 
 Under kursens gång har jag dock skrivit en laborationsrapport i Latex och därigenom skaffat mig lite mer erfarenhet.
 
 
 \subsection{Teori}
-När Microsoft utvecklade Word på 80-talet så ville de naturligtvis att dåtidens datorer skulle klara av att ladda 
-dokument utan att det skulle vara alltför prestandakrävande, därför konstruerade man dess filformat (.doc) binärt och gjorde konstruktionen 
-väldigt komplex. Detta medförde att bara personer som var riktigt insatta i detta filformat klarade att ändra direkt i dessa filer. Google docs däremot använder sig av "molnet" för att spara filer och man behöver därför aldrig oroa sig över säkerhetskopiering. Textformatering i båda dessa program görs främst genom att använda det grafiska gränssnittet, men kan även göras genom tangentbordskommandon.
+När Microsoft utvecklade Word på 80-talet så ville de naturligtvis att dåtidens datorer skulle klara av att ladda dokument utan att det skulle vara alltför prestandakrävande, därför konstruerade man dess filformat (.doc) binärt och gjorde konstruktionen väldigt komplex. Detta medförde att bara personer som var riktigt insatta i detta filformat klarade att ändra direkt i dessa filer. Google docs däremot använder sig av "molnet" för att spara filer och man behöver därför aldrig oroa sig över säkerhetskopiering. Textformatering i båda dessa program görs främst genom att använda det grafiska gränssnittet, men kan även göras genom tangentbordskommandon.
 
-Latex är i motsats till Word och Google docs inget ordbehandlingsprogram, utan istället ett märkspråk liksom HTML. När man i Word och Google docs 
-ändrar textformateringen genom ett grafiskt gränssnitt så markerar man istället sin text med taggar, som senare när man kompilerar koden ger
-det önskade utseendet. Detta gör att man som användare behöver bry sig mindre om utseendet av dokumentet och kan istället fokusera på innehållet.
-Eftersom inte är något program i sig utan mer ett programspråk så behöver man något program att redigera koden i, detta kan göras i vilken textredigerare som helst egentligen men det finns även alternativ som kan kompilera koden åt användaren så att man kan se direkt i programmet vilka ändringar som görs. Det har på senare år dykt upp flera webbsidor där man kan skriva Latexdokument tillsammans med andra användare, exempel på sådana sidor kan vara Overleaf \cite{overleaf}, eller Authorea \cite{authorea}. Latex har väldigt många inbyggda kommandon och det är väldigt lätt att t.ex. skriva formler vilket har gjort Latex till standard inom den vetenskapliga sektorn \cite{latex_standard}.
+Latex är i motsats till Word och Google docs inget ordbehandlingsprogram, utan istället ett märkspråk liksom HTML. När man i Word och Google docs ändrar textformateringen genom ett grafiskt gränssnitt så markerar man istället sin text med taggar, som senare när man kompilerar koden ger det önskade utseendet. 
+
+%exempelkod vore bra här!
+
+Detta gör att man som användare behöver bry sig mindre om utseendet av dokumentet och kan istället fokusera på innehållet. Eftersom Latex inte är något program i sig utan mer ett programspråk så behöver man något program att redigera koden i, detta kan göras i vilken textredigerare som helst, men det finns även program som kan kompilera koden åt användaren så att man kan se direkt vilka ändringar som görs. Det har på senare år dykt upp flera webbsidor där man kan skriva Latexdokument live, tillsammans med andra användare (ungefär som Google docs). Exempel på sådana sidor kan vara Overleaf \cite{overleaf}, eller Authorea \cite{authorea}. Latex har väldigt många inbyggda kommandon och det är väldigt lätt att t.ex. skriva formler vilket har gjort Latex till standard inom den vetenskapliga sektorn \cite{latex_standard}.
 
 
 \subsection{Metod}
-Vi har till en början valt att under projektets gång arbeta i endast en fil för den gemensamma delen av kandidatprojektet. Vad det gäller 
-de individuella delarna så har vi valt att lägga dessa i separata filer och sedan importera dessa till den gemensamma. Vi 
-sparar alla dokumentfiler i samma repository på github som vi har källkoden.
+Vi har till en början valt att under projektets gång arbeta i endast en fil för den gemensamma delen av kandidatprojektet. Vad det gäller de individuella delarna så har vi valt att lägga dessa i separata filer och sedan importera dessa till den gemensamma. Vi sparar alla dokumentfiler i samma repository på github som vi har källkoden.
 
-Genom att göra på detta sätt så kan vi garantera att det inte kommer att uppstå några konflikter i de individuella delarna.
-Det som vi inte vet, är huruvuda det kommer att uppstå problem då alla gruppmedlemmar skall skriva på den gemensamma delen.
+Genom att göra på detta sätt så kan vi garantera att det inte kommer att uppstå några konflikter i de individuella delarna.Det som vi inte vet, är huruvuda det kommer att uppstå problem då alla gruppmedlemmar skall skriva på den gemensamma delen.
 
 \subsection{Resultat}
-När vi i projektets inledning använde Google docs så märkte vi att det var väldigt svårt att hålla sig till någon sorts dokumentstandard där man t.ex. använder samma typsnitt på rubriker och text. Även om alla projektmedlemmar har försökt att hålla sig till den standard vi satt upp så blev det ändå ibland att någon del av dokumenten blev annorlunda när vi redigerar samtidigt i dessa. Detta fungerade mycket bättre i Latex då vi skrev kandidatrapporten. Latex hjälper verkligen användaren till att hela hålla samma standard i dokumenten.
+När vi i projektets inledning använde Google docs så märkte vi att det var väldigt svårt att hålla sig till någon sorts dokumentstandard där man t.ex. använder samma typsnitt på rubriker och text. Även om alla projektmedlemmar har försökt att hålla sig till den standard vi satt upp så blev det ändå ibland att någon del av dokumenten blev annorlunda när vi redigerade samtidigt i dessa. Detta fungerade mycket bättre i Latex när vi skrev kandidatrapporten, latex hjälper verkligen användaren till att hela tiden hålla samma standard i dokumenten.
 
-Vi har under projektet försökt att hålla isär på alla olika revisioner av dokument så att man senare kan gå tillbaka och se vilka ändringar som har gjorts mellan de olika iterationerna, detta har varit lite svårt att upprätthålla med Google docs då dessa dokument hela tiden sparas kontinuerligt och det inte finns något sätt att gå tillbaka i ett dokument för att se ändringar som gjorts, detta har gjort att när vi gjort ändringar i dokument, behöver vi spara undan en kopia av den föregående revisionen vilket inte alltid har gjorts. I kandidatrapporten däremot då vi haft alla våra Latexfiler i samma repository på github så har vi enkelt kunnat gå tilbaka i historiken för att se vilka ändringar som gjorts, och då även lätt kunnat korrekturläsa varandras texter.
+Vi har under projektet försökt att hålla isär på alla olika revisioner av dokument så att man senare kan gå tillbaka och se vilka ändringar som har gjorts från en iteration till en annan, detta har varit svårt att upprätthålla med Google docs då dessa dokument hela tiden sparas kontinuerligt och det inte finns något sätt att gå tillbaka i ett dokument för att se vilka ändringar som gjorts. Detta har gjort att när vi ändrat i dokument, behövt spara undan en kopia av den föregående revisionen vilket inte alltid har gjorts. I kandidatrapporten däremot har vi använt oss utav revisionshanteringsprogrammet git och på så sätt lätt kunnat revisionshantera även våra dokument och enkelt kunnat se vilka ändringar som gjorts. Detta har även hjälpt oss så att vi smidigt har kunnat korrekturläsa varandras texter.
 \subsection{Diskussion}
 \subsubsection{Resultat}
 \subsubsection{Metod}
@@ -70,6 +60,7 @@ \subsection{Referenser}
 \vspace{-9mm}
 \renewcommand{\refname}{}
 \begin{thebibliography}{9}
+\footnotesize
 \bibitem{word_ursprung}
 \url{http://ia801406.us.archive.org/21/items/A_History_of_the_Personal_Computer/eBook12.pdf}\\
  Sida 11-12. Hämtad 2015-04-20.
@@ -103,3 +94,4 @@ \subsection{Referenser}
 Sida 2. Hämtad 2015-04-28.
 
 \end{thebibliography}
+