
%% --------------------------------------------------------------
%% Mall för IPVT-tenta 
%% Henrik Bergström 2005 
%% (minimala ändringar av Tobias)
%% (Uppdaterad med rättningsmall och förtydliganden Henrik 2006)
%% --------------------------------------------------------------

%% När du är klar skickar du tex-filen *och* dvi-filen till
%% henrikbe@dsv.su.se. Skicka inte med ps eller pdf-filer, packa
%% inte heller filerna eller kopiera in tex-filen i brevet utan
%% skicka dem som helt vanliga bilagor. Skicka inte heller till
%% henrikbe@fc.dsv.su.se utan enbart till @dsv-adressen.

%% Observera också att du inte får ändra på några av
%% inställningarna i dokumentet, att kunna kontrollera det är en
%% av anledningarna till att vi vill ha in tex-filen också.

%% Om ni använder bibTeX -- skicka även med .bib-filen.

%% --------------------------------------------------------------
%% OBS! Se till att testkompilera filen först. Verifiera att
%% ditt dokument ser bra ut innan du lämnar in det. 
%%
%% DSV:s LaTeX-hemsida: www.dsv.su.se/datorer/latex
%% Forebys kompendium: http://www.efd.lth.se/perf/handledning/
%% 
%% Titta även gära på tipsen för hur man skriver bra LaTeX-kod
%% som är tillgänlig från startsidan på kursen. 
%%
%% Ändra texten direkt i den här filen och kompilera med
%% latex answertemplate 
%% --------------------------------------------------------------

\documentclass[a4paper,11pt,twoside]{report}

\usepackage[swedish]{babel} % Ta bort denna rad om du vill skriva
                            % dina tentasvar på engelska
\usepackage[latin1]{inputenc}
\usepackage{url}
\usepackage{fancyhdr}
\addtolength{\headheight}{18pt}
\pagestyle{fancy}

% Fyll i nedanstående data om vem du är och vilka frågor du har
% besvarat.  Naturligtvis plockar du bort den text som redan står
% där.

\newcommand{\name}{
  % Här skriver du ditt namn
  Josef Cotaidis
}
\newcommand{\ssn}{
  % Här skriver du ditt *fullständiga* personnummer
  810323--0499
}
\newcommand{\email}{\texttt{%
  % Här skriver du din epostadress på DSV/KTH. Inga privata
  % adresser tack
  jose-cot@dsv.su.se
}}

\newcommand{\qonehead}{
  Plandrivet kontra lättrörligt
}

\newcommand{\qonetext}{
\noindent
Beskriv kortfattat skillnaden mellan plandrivna och lättrörliga
metoder. Vilken är den stora styrkan med plandrivna metoder, och
vilken är den stora styrkan med lättrörliga metoder? Beskriv när
det kan vara nödvändigt att använda plandrivna metoder, och när
det kan vara lämpligt att använda lättrörliga metoder. Av de
skillnader som du har beskrivit, vilken är den viktigaste och
vilken är den näst viktigaste? (Motivera varför, och varför du
tycker att den enda är viktigare än den andra.)
}

\newcommand{\qtwohead}{
Fördelar och nackdelar med parallell utveckling
}

\newcommand{\qtwotext}{
\noindent
Nämn och beskriv kortfattat erkända effekter, två positiva och två
negativa, av att använda flera team som utvecklar olika delar av
ett system parallellt. Ur svaret måste det framgå att effekten
verkligen är erkänd. "Alla vet" eller "Jag anser" är inte
godtagbara motivationer. Referenser är ett kraftfullt verktyg här.
}

\newcommand{\heading}[1]{\subsection*{#1}}

\newcommand{\markline}[1]{
 #1 &&&&& \\
  \cline{2-6}
}

\newcommand{\exammark}{

\begin{tabular}{r|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|}
  \multicolumn{1}{c}{} & \multicolumn{1}{c}{-} & \multicolumn{1}{c}{}& \multicolumn{1}{c}{Ok} & \multicolumn{1}{c}{} & \multicolumn{1}{c}{Bra} \\
  \cline{2-6}
  \markline{Språk}
  \markline{Disposition}
  \markline{Relevans}
  \markline{Resonemang}
  \markline{Referenser -- användning}
  \markline{Referenser -- relevans \& tyngd}
\end{tabular}
}

% Rör inte nedanstående rader
\fancyhead[LE,RO]{\name{}~\ssn{}\\\email{}}
\title{Inlämning hemtentamen IPVT VT06}
\author{
Namn: \name{} \\
Personnummer: \ssn{} \\
Epost: \email{}
}

\date{
  \today
  \\
  \vspace{1cm}
	\exammark 
  \\
  \vspace{1cm}
	\exammark
  \\
  \vspace{4cm}
  Betyg:
}

\begin{document}
\maketitle

\section*{1 \qonehead}

\begin{quotation}
\qonetext
\end{quotation}

% Här *nedanför* skriver du svaret på den första av de två frågor
% du har fått dig tilldelad. Observera att de *enda* taggar du får
% använda är \url och \cite.  Ingen av dem är dock nödvändiga, man
% klarar sig utmärkt utan dem.
%
% Du får alltså inte lägga till några rubriker förutom den redan
% ditlagda, göra saker kursiverat etc.  Du får heller inte använda
% \\. Avsluta istället stycken med en tom rad.
%
% Efter genomgången idag bestämde vi oss för att även tillåta följande
% taggar:
% listor - itemize, enumerate och description
% quote och quotation
% emph
% heading - ett egendefinerat kommando som ger en rubrik: 
% \heading{Rubriktext}
%
% Att vi tillåter dem betyder dock inte att ni ska använda dem.
% Det finns tillfällen när tex en lista är jättebra, men för många 
% använder det på tok för mycket vilket bara leder till en oläsbar
% text. 

Lättrörlig mjukvarukonstruktion (i fortsättningen LRMK) uppfattas oftast som motsatsen till plandriven mjukvarukonstruktion(i fortsättningen PDMK), denna uppfattning är felaktig eftersom den antyder att LRMK skulle vara oplanerad. Istället skulle en uppdelning i adaptiva och prediktiva metoder(jag tänker inte gå in på vad de betyder, namnen är ändå väldigt deskriptiva) vara mer passande, där LRMK hör till de adaptiva metoderna och PDMK hör till de prediktiva ref.wikipedia. Med LRMK menas att man fokuserar på att snabbt kunna rätta sig efter nya behov. Det finns ingen projektplan(dokumentation) och därför ingen styrning utan arbetssättet är något som projektgruppen måste anpassa till den aktuella situationen. Ett angreppssätt som tillhör LRMK är (eng)extreeme programing. LRMK  har inte så mycket gemensamt med vattenfallsmodellen däremot kan man lite vågat säga att en delmängd ur LRMK tillhör även RUP, med tanke på att LRMK har korta utvecklingscykler men i mycket större grad än RUP. Man utvecklar i princip små färdiga system som man visar kunden, och successivt bygger man upp det kunden verkligen önskar sig. Om man väljer LRMK som angreppsätt så har man stora svårigheter i att beskriva vad som skall hända vid en specifik kalenderdag i nästa månad. Men däremot skulle man vara bra på att förklara vad som skall hända under nästa vecka. LRMK passar bäst för mindre projekt med färre än tio medarbetare. Med PDMK menas att man planerar framtiden för projektet i detalj. Om man väljer PDMK som angreppssätt har man en klar uppfattning om vad som skall göras under hela livslängden av projektet. Man har svårigheter i att ändra på den ursprungliga projektplanen, där detaljerad resursplanering har skett, vilken kan sätta igång en kedjereaktion. Att ändra en liten detalj kan sätta hela projektet i rubbning och i vissa fall innebära att projektet avbryts. Det vanligaste angreppssättet för PDMK är utan tvekan vattenfallsmodellen där systemutvecklingsprocessen delas upp i ett antal steg. För att komma till nästa steg måste allt vara klart i det aktuella steget och man kan inte ta något steg bakåt, till skillnad från LRMK. PDMK passar bäst för större projekt med fler än tio medarbetare. Styrkan med PDMK är att man kan driva stora projekt med många medarbetare. Slutkunden kan från början få besked om hur mycket produkten kommer att kosta. Kunden kan i varje steg besluta om projektet skall fortsätta, avslutas eller läggas på is. Tack vare dokumentationen kan ett projekt även återupptas. Det som levereras är testat och kvalitetssäkrat. Den stora styrkan med LRMK är att man åstadkommer struktur utan pappersarbete, beställaren har hela tiden insyn i hur utvecklingsarbetet går och slipper obehagliga överraskningar sent i projektet samtidigt som utvecklarna får information om vad som är högst prioriterat och kan disponera sin tid bättre. Förändringar hanteras mycket smidigt och är själva grundtanken med LRMK. Det kan vara lämpligt att använda PDMK vid större projekt med många inblandade, eller när systemutvecklarna är mindre erfarna ref.Bengtsson, Karlsson 2005. Det kan vara lämpligt att använda LRMK vid mindre projekt eller i projekt där kunden inte riktigt vet vad han vill ha. Det är även lämpligt att systemutvecklarna har god erfarenhet så att de kan hantera den kaotiska situationen som LRMK bidrar till ref.Bengtsson, Karlsson 2005. Jag tycker den största skillnaden är att PDMK är hårt styrt och uträttas utefter projektplanen, medan LRMK inte innefattar någon projektplanering alls. Jag tycker att denna skillnad är viktig därför att den ger upphov till väldigt olika tillvägagångssätt. Den näst största skillnaden är att PDMK uträttas i klart definierade steg medan vid LRMK så förekommer en hel del itteration där man börjar smått och successivt bygger på. Jag tycker att denna skillnad är viktig därför att man lätt kan avgöra vad som passar till ett specifikt projekt. Jag tycker att den ena skillnaden är viktigare än den andra, eftersom den första påverkar många fler variabler såsom tid, kostnad, kvalitet, resurser, struktur m.fl.



% Plocka inte bort detta \newpage
\newpage
\section*{2 \qtwohead}

\begin{quotation}
\qtwotext
\end{quotation}

% Här *nedanför* skriver du svaret på den andra av dina
% frågor. Samma regler som ovan gäller

En positiv effekt av parallell utveckling är att den ger snabbare resultat och förkortar utvecklingstiden. Ref. Aoyama menar att parallell utveckling är nödvändig i följande situationer: När vi har en explosion av krav, när snabb leverans önskas och vid snabb evolution av system för att hinna ikapp samhällets dynamiska förändringar och de krav dessa ställer. Sedan finns det system som är gigantiska som är tänkta att bestå av ett stort antal delsystem, där är det egentligen inget alternativ att utveckla systemet sekventiellt, det skulle nämligen vara i årtionden. En annan positiv effekt är att den geografiska spridningen av arbetskraften inte behöver vara ett hinder. Detta kan till exempel stora multinationella företag dra fördel av vid sin utveckling av stora och komplexa system. Hur stor är sannolikheten att alla stjärnprogrammerare kommer från ett och samma land egentligen. Parallell utveckling ger möjligheten att driva verksamhetskritiska mjukvaruprojekt över gränserna och låter stora företag utnyttja hela sin kapacitet. En negativ effekt är enligt Aoyama att en speciell metodologi krävs för styrning av parallell utveckling, där följande tekniker innefattas. Kontrollen av schemaläggningen måste vara mycket sträng och noggrann, samtidigt som den måste vara flexibel, det bör alltså finnas flera alternativa vägar genom projektet. Dynamisk distribution utav arbetsbördan är nödvändig. Kommunikation och synkronisering mellan varje aktivitet är väldigt viktig då utvecklarna annars kan råka ut för förseningar, exempelvis om ett delsystem som borde vara levererat försenas så kan detta medföra andra delar av projektet hamnar i obalans gentemot planen. Integritetskontroll bör utföras regelbundet för att kontrollera att delsystemen fungerar med varandra, vilket även bidrar till att eventuella integritetsproblem kan upptäckas tidigt. För att stödja alla de just nämnda teknikerna ställs den nya krav på de verktyg och system som bör används för att hantera koordinationen av projektet. En annan negativ effekt är att man riskerar få en övertro för detta sätt att utveckla system på. Att man tror att genom parallell utveckling kan blåsa upp ett projekt till att bli hur stort som helst. Blackburn & co har genom sin forskning konstaterat att parallell utveckling inte löser den så kallade produktivitetsparadoxen. Empirisk forskning har visat att ju mindre en projektgrupp är desto produktiv är den. Man kan lätt falla i fällan och tro att eftersom parallell utveckling förespråkar fler och mindre grupper, så skulle den ha stöd i den just nämnda forskningen. Det håller i alla fall inte Blackburn & co med om. De menar att medan man delar ett system i mindre bitar så ökas interfacekomplexiteten exponentiellt, och den totala produktiviteten får ett bakslag i form av integritetsproblem och testningssvårigheter bl.a. De menar att detta problem går endast att attackera genom att projektledarna skapar förutsättningar för bättre kommunikation och att man ser till att interfacen är enkla och eleganta.



% Plocka inte bort detta \newpage
\newpage
\section*{Referenslista}

% Här listar du samtliga referenser som har använts i *bägge*
% svaren. Om du använder bibtex för att hålla reda på referenserna
% automatiskt kan du plocka bort ovanstående rubrik. Bibtex sätter
% ut en egen.

% Se till att inkludera all relevant information i referenserna.
% En URL räcker inte, inte heller namnet på en bok. Det behövs författare,
% titel, eventuell organisation etc etc.

% Naturligtvis får du använda taggar för att formater referenslistan 
% på ett snyggt sätt. Det är bara i frågetexten som du är förbjuden
% att göra det.

\end{document}
