ENGLISH ABSTRACT: Most people working in the software industry recognise that developing software to predictable schedules is risky and not easy. They experience problems to estimate how long the development of software will take. Underestimation leads to under staffing and setting too short a schedule. That in turn leads to staff burnout, low quality and missed deadlines. Overestimation can be almost as bad: Parkinson's Law that work expands to fill available time comes into action, which means the project will take as long as estimated even if overestimated. Currently people do no put in much effort to estimate jobs and therefore projects take as long as they take. Methods to manage uncertainty lead to putting in excessive safety and then wasting it. Business usually presents a target for the project with tremendous pressure for low 'estimates' during the bidding process and in the end this target becomes the plan. Best practice appears to manage the gap between this target and the estimate as a risk on the project. Without an efficient work breakdown structure (WBS) one cannot accurately estimate. Subject experts should help the project manager to plan the detail of how the work should be done. A functional design by a systems architect helps to break down the technical tasks. This is very important because omitted tasks will not be estimated for. The first step towards sound estimates is to estimate the size. This is extremely difficult at the initial phase but can be overcome if the company store history of size and completion time in a repository. Although lines of code are most often used as a size measure, function points or function blocks appear to be better, especially for the initial estimate. If an organisation has not kept historic data, now is the time to start doing it. The suggested procedure to follow before starting to gather information, is to define what is going to be kept (the norms), to delimit the defined data, to discipline the collection, to deposit it in an established repository and to deliver it in readily usable format. The tool used for storing these metrics must provide building in factors that influence effort like complexity, skills level, elapsed time, staff turnover, etc. There are many different techniques for estimation. The best option seems to use a combination of estimates and include developer opinion and a mathematical method like function point analysis. Estimation of software development, like all other work processes, need management control and this is called metrics management. This process includes establishing some kind of modeL Empirical models, based on a database with data stored by ones own company, give the best results. Two very good models are the Putnam model and the Parr model (for smaller projects). Even the best model and process is never perfect. Therefore the estimation process must be continuously monitored by comparing actual duration times to estimates. Be careful with feedback on how accurate estimates were. No feedback is the worst response. Carefully discussing the implications of underestimation and putting heads together to solve the problem appears to be the best solution. / AFRIKAANSE OPSOMMING: Die meeste mense in die sagteware industrie erken dat om sagteware te ontwikkel teen voorspelbare tydskedules, gevaar inhou en nie maklik is nie. Hulle ondervind probleme om te skat hoe lank die ontwikkeling van sagteware hulle gaan neem. Onderskatting lei tot te min hulpbronne en te kort skedules. Dit veroorsaak uitbrand van mense, lae kwaliteit en einddatums wat nie gehaal word nie. Oorskatting is byna net so erg. Parkinson se Wet dat werk geskep word om beskikbare tyd te vul, kom in aksie en aan die einde beteken dit die projek neem so lank as wat geskat is, selfs al is dit oorskat. Huidiglik doen mense nie veel moeite om tyd te skat op take nie en daarom neem projekte so lank as wat dit neem om te voltooi. Metodes om onsekerheid te bestuur lei tot die byvoeg van oormatige veiligheidstyd net om dit daarna weer te verkwis. Die besigheid verskaf gewoonlik 'n mikpunt vir die projek met geweldige druk vir lae skattings tydens bieery en op die ou end raak hierdie mikpunt die projekplan. Die beste manier om dit die hoof te bied is om die gaping tussen hierdie mikpunt en die skatting te bestuur as 'n projek risiko. Niemand kan akkuraat skat sonder 'n effektiewe metode van werk afbreek nie. Vakkundiges behoort die projekbestuurder te help om die detail van hoe die werk gedoen gaan word, te beplan. 'n Funksionele ontwerp deur 'n stelselsargitek help om die tegniese take verder af te breek. Dit is baie belangrik aangesien take wat uitgelaat word, nie in die skatting ingesluit gaan word nie. Die eerste stap om by gesonde skattings uit te kom, is om grootte te skat. Dit is besonder moeilik in die aanvanklike fase, dog kan oorkom word indien die maatskappy geskiedenis stoor van hoe groot voltooide take was en hoe lank dit geneem het. Alhoewel Iyne kodering die mees algemeenste vorm van meting van grootte is, Iyk dit asof funksie punte of funksie blokke beter werk, veral by die aanvanklike skatting. Indien 'n organisasie nie historiese data stoor nie, is dit nou die tyd om daarmee te begin. Die voorgestelde prosedure om te volg voordat informasie gestoor word, is om te definieer wat gestoor gaan word (norme te bepaal), om die data af te baken, dissipline toe te pas by die insameling, dit te stoor in 'n gevestigde databasis en dit beskikbaar te stel in bruikbare formaat. Die instrument wat gebruik word om hierdie syfers te stoor moet voorsiening maak vir die inbou van faktore wat produksie beinvloed, soos kompleksiteit, vlak van vaardigheid, verstreke tyd, personeel omset, ens. Daar bestaan menige verskillende tegnieke vir skatting. Die beste opsie blyk 'n kombinasie van skattings te wees. Die opinie van die programmeur asook een wiskundige metode soos funksie punt analise, behoort deel te wees hiervan. Soos alle ander werksprosesse, moet skattings vir sagteware ontwikkeling ook bestuur word en dit word metrieke bestuur genoem. Hierdie proses behels dat daar besluit moet word op een of ander model. Empiriese modelle gebaseer op 'n databasis waarin data gestoor word deur die maatskappy self, gee die beste resultate. Twee baie goeie modelle is die Putnam model en die Parr model (vir kleiner projekte). Selfs die beste model en proses is egter nooit perfek nie. Die estimasie proses moet dus voortdurend gemonitor word deur werklike tye met geskatte tye te vergelyk. Wees versigtig met terugvoer aangaande hoe akkuraat skattings was. Geen terugvoer is die ergste oortreding. Die beste oplossing skyn te wees om die implikasie van die onderskatting met die persoon wat die skatting gedoen het, te bespreek en koppe bymekaar te sit om die probleem op te los.

A adoção de métodos ágeis é uma forma eficaz de reduzir o ciclo de entrega no desenvolvimento de software, fornecendo software de qualidade em curto espaço de tempo. Porém, a adoção desta nova abordagem de desenvolvimento de software torna necessário repensar a forma de medir e controlar os projetos. Os métodos ágeis não tratam claramente sobre os assuntos utilização de métricas e adoção de um processo de medição para projetos de softwares desta natureza, faltando estudos que tragam recomendações em como estabelecer métricas para projetos ágeis e como adotar um processo de medição compatível com esta abordagem. Visando contribuir neste sentido esta tese tem como objetivo definir um conjunto de métricas adequadas às necessidades de monitoramento e propor um processo de medição, compatível com a abordagem ágil de desenvolvimento de software. Como método de pesquisa foi realizado um trabalho exploratório através de revisão de literatura e de pesquisa de campo com entrevista em profundidade em empresas de desenvolvimento de software experientes em métodos ágeis. O primeiro resultado do trabalho é a apresentação de um conjunto de métricas consolidados para auxiliar na gestão de projetos ágeis de desenvolvimento de software nas fases de projeto/releases, iteração e diário. As métricas são especificadas detalhadamente contendo as informações necessárias para seu entendimento e aplicação. Posteriormente é proposto um processo de medição compatível com a abordagem ágil de desenvolvimento de software, visando apoiar as empresas que adotam métodos ágeis na definição de métricas adequadas para suas necessidades de medição e no monitoramento. O processo contempla as fases de planejamento de medição, monitoramento da iteração, ações da iteração, monitoramento do projeto/releases, ações sobre o projeto/releases e avaliação final, sendo que em cada fase do processo são apresentadas recomendações para a sua implantação. O processo está estruturado num ciclo de gestão baseado em etapas de planejar, executar, verificar, atuar, refletir e melhorar, respeitando as características dos projetos ágeis de desenvolvimento de software, e na proposição de um quadro visual de monitoramento que permita a gestão do processo de medição de forma visual. Além dos resultados apresentados foram deixadas hipoteses e recomendações para trabalhos futuros. / The adoption of agile methods is effective way to reduce the delivery cycle on software development, providing quality software in a short time. However, the adoption of this new approach to software development is necessary rethink how to measure and control projects. Agile methods not explain about adoption metrics and measurement process for software projects of this approach, lacking studies providing recommendations on how to establish metrics for agile projects and how to adopt a process measurement compatible with this approach. Contributing this thesis goal produce a set of metrics adequate monitoring needs and propose a measurement processcompatible with agile software development. Method of research was exploratory through literature review and field research with depth interviews in experienced software development companies in agile methods. The first result of this work is the presentation of a consolidated metrics set to help the management of agile development at the phases of project/releases, iteration and daily. The metrics are specified detailed containing the information necessary for their understanding and application. Later we propose a measurement process compatible with agile approach to software development, to support businesses that adopt agile methods in defining adequate metrics for your measurement needs and monitoring. The process include the steps of measurement planning, monitoring of the iteration, the iteration actions, monitoring project/releases, actions on the project/releases and final evaluation, in each stage of the process provides recommendations for implementation. The process is structured in a management cycle based on steps to plan, implement, check, act, reflect and improve, respecting the characteristics of agile software development projects and propose a visual tracking board that allows for the management of the measurement process. In addition to the results were allowed hypotheses and recommendations for future work.

A adoção de métodos ágeis é uma forma eficaz de reduzir o ciclo de entrega no desenvolvimento de software, fornecendo software de qualidade em curto espaço de tempo. Porém, a adoção desta nova abordagem de desenvolvimento de software torna necessário repensar a forma de medir e controlar os projetos. Os métodos ágeis não tratam claramente sobre os assuntos utilização de métricas e adoção de um processo de medição para projetos de softwares desta natureza, faltando estudos que tragam recomendações em como estabelecer métricas para projetos ágeis e como adotar um processo de medição compatível com esta abordagem. Visando contribuir neste sentido esta tese tem como objetivo definir um conjunto de métricas adequadas às necessidades de monitoramento e propor um processo de medição, compatível com a abordagem ágil de desenvolvimento de software. Como método de pesquisa foi realizado um trabalho exploratório através de revisão de literatura e de pesquisa de campo com entrevista em profundidade em empresas de desenvolvimento de software experientes em métodos ágeis. O primeiro resultado do trabalho é a apresentação de um conjunto de métricas consolidados para auxiliar na gestão de projetos ágeis de desenvolvimento de software nas fases de projeto/releases, iteração e diário. As métricas são especificadas detalhadamente contendo as informações necessárias para seu entendimento e aplicação. Posteriormente é proposto um processo de medição compatível com a abordagem ágil de desenvolvimento de software, visando apoiar as empresas que adotam métodos ágeis na definição de métricas adequadas para suas necessidades de medição e no monitoramento. O processo contempla as fases de planejamento de medição, monitoramento da iteração, ações da iteração, monitoramento do projeto/releases, ações sobre o projeto/releases e avaliação final, sendo que em cada fase do processo são apresentadas recomendações para a sua implantação. O processo está estruturado num ciclo de gestão baseado em etapas de planejar, executar, verificar, atuar, refletir e melhorar, respeitando as características dos projetos ágeis de desenvolvimento de software, e na proposição de um quadro visual de monitoramento que permita a gestão do processo de medição de forma visual. Além dos resultados apresentados foram deixadas hipoteses e recomendações para trabalhos futuros. / The adoption of agile methods is effective way to reduce the delivery cycle on software development, providing quality software in a short time. However, the adoption of this new approach to software development is necessary rethink how to measure and control projects. Agile methods not explain about adoption metrics and measurement process for software projects of this approach, lacking studies providing recommendations on how to establish metrics for agile projects and how to adopt a process measurement compatible with this approach. Contributing this thesis goal produce a set of metrics adequate monitoring needs and propose a measurement processcompatible with agile software development. Method of research was exploratory through literature review and field research with depth interviews in experienced software development companies in agile methods. The first result of this work is the presentation of a consolidated metrics set to help the management of agile development at the phases of project/releases, iteration and daily. The metrics are specified detailed containing the information necessary for their understanding and application. Later we propose a measurement process compatible with agile approach to software development, to support businesses that adopt agile methods in defining adequate metrics for your measurement needs and monitoring. The process include the steps of measurement planning, monitoring of the iteration, the iteration actions, monitoring project/releases, actions on the project/releases and final evaluation, in each stage of the process provides recommendations for implementation. The process is structured in a management cycle based on steps to plan, implement, check, act, reflect and improve, respecting the characteristics of agile software development projects and propose a visual tracking board that allows for the management of the measurement process. In addition to the results were allowed hypotheses and recommendations for future work.

A adoção de métodos ágeis é uma forma eficaz de reduzir o ciclo de entrega no desenvolvimento de software, fornecendo software de qualidade em curto espaço de tempo. Porém, a adoção desta nova abordagem de desenvolvimento de software torna necessário repensar a forma de medir e controlar os projetos. Os métodos ágeis não tratam claramente sobre os assuntos utilização de métricas e adoção de um processo de medição para projetos de softwares desta natureza, faltando estudos que tragam recomendações em como estabelecer métricas para projetos ágeis e como adotar um processo de medição compatível com esta abordagem. Visando contribuir neste sentido esta tese tem como objetivo definir um conjunto de métricas adequadas às necessidades de monitoramento e propor um processo de medição, compatível com a abordagem ágil de desenvolvimento de software. Como método de pesquisa foi realizado um trabalho exploratório através de revisão de literatura e de pesquisa de campo com entrevista em profundidade em empresas de desenvolvimento de software experientes em métodos ágeis. O primeiro resultado do trabalho é a apresentação de um conjunto de métricas consolidados para auxiliar na gestão de projetos ágeis de desenvolvimento de software nas fases de projeto/releases, iteração e diário. As métricas são especificadas detalhadamente contendo as informações necessárias para seu entendimento e aplicação. Posteriormente é proposto um processo de medição compatível com a abordagem ágil de desenvolvimento de software, visando apoiar as empresas que adotam métodos ágeis na definição de métricas adequadas para suas necessidades de medição e no monitoramento. O processo contempla as fases de planejamento de medição, monitoramento da iteração, ações da iteração, monitoramento do projeto/releases, ações sobre o projeto/releases e avaliação final, sendo que em cada fase do processo são apresentadas recomendações para a sua implantação. O processo está estruturado num ciclo de gestão baseado em etapas de planejar, executar, verificar, atuar, refletir e melhorar, respeitando as características dos projetos ágeis de desenvolvimento de software, e na proposição de um quadro visual de monitoramento que permita a gestão do processo de medição de forma visual. Além dos resultados apresentados foram deixadas hipoteses e recomendações para trabalhos futuros. / The adoption of agile methods is effective way to reduce the delivery cycle on software development, providing quality software in a short time. However, the adoption of this new approach to software development is necessary rethink how to measure and control projects. Agile methods not explain about adoption metrics and measurement process for software projects of this approach, lacking studies providing recommendations on how to establish metrics for agile projects and how to adopt a process measurement compatible with this approach. Contributing this thesis goal produce a set of metrics adequate monitoring needs and propose a measurement processcompatible with agile software development. Method of research was exploratory through literature review and field research with depth interviews in experienced software development companies in agile methods. The first result of this work is the presentation of a consolidated metrics set to help the management of agile development at the phases of project/releases, iteration and daily. The metrics are specified detailed containing the information necessary for their understanding and application. Later we propose a measurement process compatible with agile approach to software development, to support businesses that adopt agile methods in defining adequate metrics for your measurement needs and monitoring. The process include the steps of measurement planning, monitoring of the iteration, the iteration actions, monitoring project/releases, actions on the project/releases and final evaluation, in each stage of the process provides recommendations for implementation. The process is structured in a management cycle based on steps to plan, implement, check, act, reflect and improve, respecting the characteristics of agile software development projects and propose a visual tracking board that allows for the management of the measurement process. In addition to the results were allowed hypotheses and recommendations for future work.

Background: Effort estimation is one of the cornerstones in project management with the purpose of creating efficient planning and the ability to keep budgets. Despite the extensive research done within this area, one of the biggest and most complex problems in project management within software development is still considered to be the estimation process. Objectives: The main objectives of this thesis were threefold: i) firstly to define the characteristics for a large project, ii) secondly to identify factors causing inaccurate effort estimates and iii) lastly to understand how the identified factors impact the effort estimation process, all of this within the context of large-scale agile software development and from the perspective of a project team.Methods: To fulfill the purpose of this thesis, an exploratory case study was executed. The data collection consisted of archival research, questionnaire, and interviews. The data analysis was partly conducted using the statistical software toolStata.Results: The definition of a large project is from a project team’s perspective based on high complexity and a large scope of requirements. The following identified factors were identified to affect the estimation process in large projects: deficient requirements, changes in scope, complexity, impact in multiple areas, coordination, and required expertise, and the findings indicate that these are affecting estimation accuracy negatively. Conclusions: The conclusion of this study is that besides the identified factors affecting the estimation process there are many different aspects that can directly or indirectly contribute to inaccurate effort estimates, categorized as requirements, complexity, coordination, input and estimation process, management, and usage of estimates.

Introduction to problem: Many software development projects today have a tendency to fail on some level. Even though they may not fail entirely, they might be completed with schedule delays, budget overrun or with poor quality that do not meet the customer?s requirements. When a project fails in some way, it is because one or many project risks have occurred. Our own opinion in this matter is that if the project team members are more aware of the project?s risks, it might increase the probability of project success. Therefore, we wanted to explore the area of risk awareness. We contacted Volvo Information Technology AB and through discussions we decided to investigate risk awareness when using one of their software project methods. That method was the Rational Unified Process. This report has not been conducted because Volvo IT considers this to be a problem that they wanted to investigate. Instead, we wanted to investigate this since we find the area of risk awareness among project team members interesting and we were able to do this with help from Volvo IT. Even though we mention the term ?project success? in this report, we will not investigate this in the report. Hypothesis: ?By using the Rational Unified Process, a higher awareness of the risks can be achieved by all team members of the project? Aim: The aim of this report is to investigate if risk awareness among project team members increases when software development projects make use of the Rational Unified Process. Method: We have used a web-based questionnaire to gather information. Four projects at Volvo Information Technology AB were contacted and asked to participate in the questionnaire. Two of these were using RUP and two did not use RUP. Personal e-mails were later sent out to each of the project managers with a description of the aim of our research and the way it would be carried out. The participants had a total of seven workdays to fill out the questionnaire. After seven days the site of the questionnaire were closed down. Conclusion: The differences in answers to certain questions have been rather significant between the two project methods. On the whole though, the answers have been positive for both project methods from a risk awareness point of view. Therefore, it seems to us that risk awareness is not dependent on the project method that is being used. We feel that we have not received enough convincing proof that members of RUP projects possess a higher awareness of project risks than non-RUP project members. Therefore we are of the opinion that we cannot verify our hypothesis. / Introduktion till problem: Många av dagens mjukvaru-projekt har en tendens till att misslyckas på ett eller annat sätt. Även om de inte misslyckas helt, kan det hända att de slutförs med förseningar, stora kostnader utanför budgetens ramar eller med otillräcklig kvalitet som inte motsvarar kundernas krav. Anledningen till att ett projekt misslyckas på något sätt är att en eller flera projekt-risker har inträffat. Vår åsikt i detta ämne är att om projekt-medlemmarna har högre medvetenhet om sitt projekts risker kan detta leda till en ökad sannolikhet att projektet "lyckas". Vi ville därför undersöka området risk-medvetenhet närmare. Vi kontaktade Volvo Information Technology AB och genom diskussioner bestämde vi oss för att undersöka risk-medvetenhet vid användandet av en av deras mjukvaru-projekts metoder. Denna metod var The Rational Unified Process. Denna rapport har inte genomförts på grund av att Volvo IT anser detta vara ett problem som de ville ha undersökt. Istället ville vi själva undersöka detta eftersom vi tycker att risk-medvetenhet bland projektets medlemmar är ett intressant område som borde undersökas. Vi kunde genomföra detta tack vare hjälp från Volvo IT. Även om vi nämner begreppet "lyckade projekt" i rapporten, kommer vi i rapporten inte att undersöka detta. Hypotes: "Genom att använda sig av the Rational Unified Process, kan man uppnå en högre risk-medvetenhet bland projektets samtliga medlemmar" Syfte: Syftet med denna rapport är att undersöka om risk-medvetenheten bland projektets medlemmar ökar när mjukvaru-projekt använder sig av the Rational Unified Process. Metod: Vi har använt en web-baserad enkät för att samla information. Vi kontaktade fyra projekt på Volvo Information Technology AB och frågade om de ville medverka i vår enkät. Två av dessa projekt använde the Rational Unified Process och två gjorde det inte. Personliga e-mail skickades senare ut till varje projektledare med förklaring till syftet med undersökningen samt sättet den skulle genomföras på. Deltagarna hade totalt sju arbetsdagar att fylla i enkäten. Efter dessa sju dagar stängdes sidan med undersökningen. Slutsats: Skillnaden i svar på vissa av frågorna var ganska markanta mellan de två projekt metoderna. Dock, från ett risk-medvetenhets perspektiv, var svaren på det hela taget positiva för båda projekt metoderna. Därför verkar det som att risk-medvetenhet inte är beroende av vilken projekt-metod som används. Vi anser oss inte ha tillräckliga belägg för att medlemmar av projekt som använder the Rational Unified Process besitter en högre risk-medvetenhet än projekt som inte använder sig av denna metod. Vi anser därför att vi inte kan verifiera vår hypotes. / Sophie Eklund 0739-078698 Daniel Gunnarsson 0737-344243

The increased usage and need for software as part of products has challenged traditional project management, nevertheless for hardware heavy organisations that are used to rely on the linear prediction and tracking of project outcomes. The developments in projects with embedded systems have countless dependencies and almost impossible to predict. Literature shows that software development projects have problems meeting the initial goals of budget, time, and scope. This is discovered too late due to insufficient methods of tracking progress. The purpose of this thesis was to investigate how large agile software development projects can continuously be followed to evaluate their performance and meet initial customer agreements fixed in time, budget, and scope. The thesis was conducted at Saab, active in the defense and security industry. This qualitative exploratory study was conducted with semistructured interviews and focus group discussions at the case company Saab, benchmark interviews with two additional companies, and an extensive literature study. The issues with the existing tracking approach were explored to determine how progress tracking may be created to continuously measure progress and indicate if project goals will be accomplished or not. The more general challenges in software development were also investigated to provide knowledge about areas in need of additional metrics which could indicate the problem and mitigate it. One industry-specific challenge is the security aspect that is unavoidable and requires a lot of documentation that holds up the development activities. Other detected challenges were difficulties in understanding requirements that lead to faulty estimations and work in the wrong direction, undiscovered dependencies that lead to a lot of rework and waiting for additional parts, insufficient testing environments that lead to late feedback, and holds up the development. It was also visible that the projects were conducted with different management approaches and no best-proven practice existed for tracking performance. From an analysis of the empirical data and existing literature, a suggestion of method tracking design was developed for large agile software projects with fixed contracts. The models were proposed to allow flexibility, enable control, and provide a holistic view. As Saab intends to introduce Earned Value Management in their software projects, this method was complemented with COMOD, TRL, IRL, and SRL to provide these three characteristics. Transparency and visibility of both products and processes are also found to be key to project success, thus additional metrics to increase visibility in projects are suggested to enable efficient project leading. / Den ökade användningen och behovet av mjukvara har utmanat traditionell projektledning, speciellt för hårdvaruorganisationer som är vana att kunna förlita sig på den linjära utvecklingen av ett projek. Utvecklingen av projekt som inkluderar inbyggda system med otaliga beroenden är nästan omöjliga att förutsäga. Litteratur visar att mjukvaruutvecklingsprojekt har problem att nå de ursprungliga målen för budget, tid och omfattning. Detta upptäcks för sent på grund av otillräckliga metoder för att mäta framsteg i projekt. Detta examensarbete genomfördes som en fallstudie på Saab, aktiv inom försvar- och säkerhetssektorn. Syftet med denna avhandling har varit att utvärdera hur projektledning för stora agila mjukvaruutvecklingsprojekt kontinuerligt kan följa utvecklingen för att möta de ursprungliga kundavtalen som är fastställda i tid, budget och omfattning. Denna kvalitativa undersökningsstudie genomfördes med semistrukturerade intervjuer och fokusgrupp intervjuer på företaget Saab, benchmarking intervjuer med ytterligare två företag och en omfattande litteraturstudie. För att utvärdera hur en metod för utvärdering av projektstatus ska utformas för att i tid ange om projektmålen inte kommer att uppnås, undersöktes utmaningarna med mjukvaruutveckling och därifrån har möjliga mätvärden och metoder för att mildra eller upptäcka dessa problem utvärderats. Några av de upptäckta problemen verkar överlappa flera industrier medan andra verkar vara mer specifika för just militär- och försvarsindustrin. En branschspecifik utmaning är säkerhetsaspekten som är oundviklig och kräver mycket dokumentation som stannar upp utvecklingsaktiviteterna. Andra upptäckta utmaningar var svårigheter att förstå krav som leder till felaktiga uppskattningar och arbete i fel riktning, oupptäckta beroenden som leder till mycket omarbetning och väntande på ytterligare delar, otillräckliga testmiljöer som leder till sen feedback och håller upp utvecklingen. Stora skillnader i de metoder som idag tillämpas från projektledning i dessa projekt var synligt under projektet, vilket indikerar på att det idag inte finns någon accepteras bästa metod i uppföjlning. Från analys av samlad empirisk data samt befintlig litteratur utvecklades ett förslag på hur en metod för uppföljning av stora agila mjukvaruprojekt skulle kunna se ut. Design på föreslagen modell skulle möjliggöra flexibilitet och kontroll samt förmedla ett helhetsperpektiv. Eftersom Saab avser att introducera Earned Value Management i sina mjukvaruprojekt kompletterades denna metod med COMOD, TRL, IRL och SRL för att få dessa tre egenskaper. Öppenhet och synlighet för både produkt och process visar sig också vara nyckeln till framgång i projektutveckling, vilket är möjligt med ytterligare mått för att öka synligheten i projektet.