Detta examensarbete behandlar agenter och logiken som används för att styra dessa. ESR (Experimenterande Svenska Radioamatörer) är en geografiskt spridd organisation och fysiska möten mellan medlemmarna försvåras på grund av detta. Swap Meet, som är en del av Radioträff Syd, arrangeras årligen på olika platser runt om i Sverige. Medlemmar från andra platser i landet finner det då svårt att ta sig till dessa träffar. Dessutom vill många medlemmar köpa och sälja komponenter under hela året vilket inte är möjligt i dagsläget. På något sätt vill medlemmarna ha möjlighet köpa och sälja sina komponenter och dessutom förhandla om pris och kvantitet. Kan man utveckla en agent för att utföra detta på distans? Hur skall handelslogiken till en sådan agent struktureras? Syftet med denna rapport är att utveckla en lämplig handelslogik för en agent som förhandlar med andra agenter angående köp och försäljning av utrustning.

<p>Enligt Standish Group är det endast cirka 35 % av alla systemutvecklingsprojekt som avslutas på ett lyckat sätt när det gäller tid, budget och resurser. Inom systemutveckling är fastprisprojekt, där systemets kostnad är förbestämd, allt mer populärt. Dynamic Systems Development Method (DSDM) är en modell för utveckling som fokuserar på fasta resurser och tid med funktionalitet som den flexibla variabeln. Syftet med den här uppsatsen är att se om man kan driva fastprisprojekt med en modell som DSDM på ett sätt som gör det till en bra lösning för både beställare och leverantör.</p><p>Min slutsats är att det största problemet med DSDM är att få beställaren att godkänna den som projektmodell. Ett annat stort problem är att många projekt med DSDM blir stressiga eftersom tiden är fast. Flexibiliteten med funktionaliteten räcker med andra ord inte till. Önskvärda förbättringar inom DSDM är att ge mer underlag för hur man skall få en ny beställare att godkänna modellen. Dessutom att tillhandahålla guidelines för hur man kan hantera ett projekt med många och detaljerade krav. En annan viktig faktor som måste förbättras är hur man får projekt med DSDM att bli mindre stressiga.</p><p>DSDM är en modell som uppskattas av dem som har erfarenhet av den och som anses resultera i lyckade projekt, för både beställare och leverantör. Mina slutsatser är därför att DSDM kan fungera bra men att det ställer höga krav på projektet. Både beställare och leverantör måste vara engagerade. Beställaren måste kunna prioritera sina krav och räkna med att en del funktionalitet inte kommer med. Dessutom måste det finnas stor användarinvolvering och projektgruppen måste ha beslutsmandat.</p>

<p><p>För att utveckla informationssystem använder företag och organisationer ofta systemutvecklingsmetoder. Att välja en systemutvecklingsmetod kan många gånger vara svårt, då olika systemutvecklingsmetoder lämpar sig för olika sorters projekt.</p><p>Systemutvecklingsmetoder har bakomliggande filosofi som påverkar hur olika delar av informationssystemsutvecklingen sköts. Exempelvis är testning en viktig del i utvecklandet av informationssystem. Vi har därför i denna studie valt att inrikta oss på <em>hur</em> systemutvecklingsmetoder ser på testning.  </p><p>Denna studie grundar sig i en litteraturstudie där vi som syfte haft att jämföra systemutvecklingsmetoderna; RUP, DSDM och Scrum i avseende systemutvecklingsmetodernas syn på testning. Vi har använt oss av ett ramverk som vi vidareutvecklat med utgångspunkt från Avison & Fitzgeralds (2003) ramverk. Med hjälp av vårt ramverk har vi jämfört olika attribut hos systemutvecklingsmetoderna som rör testning och kommit fram till följande slutsatser:</p><ul type="disc"><li>RUP lägger stor vikt vid testning. Likt allt annat i RUP finns det dokumentation och stöd för hur testning bör utföras. RUP har även kvalitetsattribut som styr testning.</li><li>DSDM lägger stor vikt vid testning. Det finns dokumentation och stöd, men mycket lämnas öppet till SU-metodanvändaren. Testning styrs genom en teststrategi.</li><li>Scrum lägger vikt vid testning, men det finns inget stöd för hur testning ska utföras. Det är upp till SU-metodanvändaren att styra upp en testningsprocess.</li></ul></p>

För att utveckla informationssystem använder företag och organisationer ofta systemutvecklingsmetoder. Att välja en systemutvecklingsmetod kan många gånger vara svårt, då olika systemutvecklingsmetoder lämpar sig för olika sorters projekt. Systemutvecklingsmetoder har bakomliggande filosofi som påverkar hur olika delar av informationssystemsutvecklingen sköts. Exempelvis är testning en viktig del i utvecklandet av informationssystem. Vi har därför i denna studie valt att inrikta oss på hur systemutvecklingsmetoder ser på testning.   Denna studie grundar sig i en litteraturstudie där vi som syfte haft att jämföra systemutvecklingsmetoderna; RUP, DSDM och Scrum i avseende systemutvecklingsmetodernas syn på testning. Vi har använt oss av ett ramverk som vi vidareutvecklat med utgångspunkt från Avison &amp; Fitzgeralds (2003) ramverk. Med hjälp av vårt ramverk har vi jämfört olika attribut hos systemutvecklingsmetoderna som rör testning och kommit fram till följande slutsatser: <ul type="disc">RUP lägger stor vikt vid testning. Likt allt annat i RUP finns det dokumentation och stöd för hur testning bör utföras. RUP har även kvalitetsattribut som styr testning. DSDM lägger stor vikt vid testning. Det finns dokumentation och stöd, men mycket lämnas öppet till SU-metodanvändaren. Testning styrs genom en teststrategi. Scrum lägger vikt vid testning, men det finns inget stöd för hur testning ska utföras. Det är upp till SU-metodanvändaren att styra upp en testningsprocess.

Enligt Standish Group är det endast cirka 35 % av alla systemutvecklingsprojekt som avslutas på ett lyckat sätt när det gäller tid, budget och resurser. Inom systemutveckling är fastprisprojekt, där systemets kostnad är förbestämd, allt mer populärt. Dynamic Systems Development Method (DSDM) är en modell för utveckling som fokuserar på fasta resurser och tid med funktionalitet som den flexibla variabeln. Syftet med den här uppsatsen är att se om man kan driva fastprisprojekt med en modell som DSDM på ett sätt som gör det till en bra lösning för både beställare och leverantör. Min slutsats är att det största problemet med DSDM är att få beställaren att godkänna den som projektmodell. Ett annat stort problem är att många projekt med DSDM blir stressiga eftersom tiden är fast. Flexibiliteten med funktionaliteten räcker med andra ord inte till. Önskvärda förbättringar inom DSDM är att ge mer underlag för hur man skall få en ny beställare att godkänna modellen. Dessutom att tillhandahålla guidelines för hur man kan hantera ett projekt med många och detaljerade krav. En annan viktig faktor som måste förbättras är hur man får projekt med DSDM att bli mindre stressiga. DSDM är en modell som uppskattas av dem som har erfarenhet av den och som anses resultera i lyckade projekt, för både beställare och leverantör. Mina slutsatser är därför att DSDM kan fungera bra men att det ställer höga krav på projektet. Både beställare och leverantör måste vara engagerade. Beställaren måste kunna prioritera sina krav och räkna med att en del funktionalitet inte kommer med. Dessutom måste det finnas stor användarinvolvering och projektgruppen måste ha beslutsmandat.

In the software industry a number of different software processes has been used throughout the years to address known problems with software development, despite their intention complains has been raised that some of these are too bureaucratic. The Agile Alliance was formed in 2001 and aimed to solve this problem, they developed a manifesto and twelve principles which are supported by all Agile software processes. The purpose with the manifesto and its principles is to uncover better ways of developing software and these are by many intercessors of Agile seen as common sense and not completely new ideas. The aim with this master thesis is to answer the question if companies that explicitly claim that they do not use any Agile software process are already applying some of these ideas since they are thought of as obvious and common sense. The comparison in this thesis is performed between the project lifecycles used in specific projects by five non-Agile software companies and four identified lifecycle characteristics and two more general characteristics of the Agile software processes Extreme Programming (XP) and Dynamic Systems Development Method (DSDM). The result from the analysis of these interviews has shown that it is very difficult to decide if a software company really is working as described by XP or DSDM, this is due to that many different factors affect the final outcome. For example type of project and is the software company using different software processes for different kinds of projects. Since we just covered specific projects we were only able to conclude with absolute certainty actions that really were performed in just these projects. The project lifecycles of these software companies had some similarities with the above mentioned Agile software processes, but as a whole the analysis showed that they are quite different due to that two very important characteristics according to us, namely iterative development and frequent releases, were not applied by any of the software companies and that their project phases differed tremendously compared to XP and DSDM. Our common sense hypothesis for Agile software development was shown in this investigation to be incorrect since important activities were not performed by any of the software companies. Instead of using an iterative approach with frequent releases they all followed sequential waterfall like software processes.

A crescente demanda por sistemas e a alta velocidade com que seus requisitos evoluem têm evidenciado que desenvolvimento de software exige flexibilidade, pois muitas decisões precisam ser tomadas durante o projeto. Além disso, as dificuldades para a produção de sistemas vão muito além das questões técnicas. Fatores estratégicos, comerciais e humanos são responsáveis por algumas das variáveis que contribuem para tornar o desenvolvimento de sistemas de software uma atividade altamente complexa. Modelos tradicionais de desenvolvimento de software propõem processos prescritivos que não consideram toda essa complexidade. Por outro lado, Métodos Ágeis de desenvolvimento de software sugerem uma abordagem mais humanística com foco na entrega rápida e constante de software com valor de negócios. Porém, para conseguir isto, é preciso escolher um conjunto de práticas de desenvolvimento adequado às características do projeto e da equipe. Desta forma, a natureza única de cada projeto e a necessidade de alta qualidade e produtividade tornam importante a busca por práticas de desenvolvimento. A partir de projetos que conduzimos usando métodos ágeis na academia e na indústria, identificamos e descrevemos 22 práticas para desenvolvimento de software que podem ser adotadas por equipes para aumentar o seu desempenho e/ou a qualidade do software. / The growing demand for systems and the high speed with which their requirements evolve has shown that software development requires flexibility because many decisions need to be taken during the project. Also, the difficulties for the production of software systems go far beyond the technical issues. Strategic, commercial and human factors are responsible for some variables that contribute to make the software development a highly complex activity. Traditional models of software development propose prescritive processes that do not consider all this complexity. On the other hand, Agile Methods of software development suggest an humanistic approach focused on fast and often business valuable software deliveries. But, in order to get it, one needs to choose an appropriated group of development practices accordingly to the project and team features. In this way, the individuality of each project and the need for better quality and productivity motivate the search for software development practices. Based on projects that we conducted by using agile methods in academic and industry environments we identified and described 22 software development practices that can be used by teams to increase their performance and/or the software quality.

A crescente demanda por sistemas e a alta velocidade com que seus requisitos evoluem têm evidenciado que desenvolvimento de software exige flexibilidade, pois muitas decisões precisam ser tomadas durante o projeto. Além disso, as dificuldades para a produção de sistemas vão muito além das questões técnicas. Fatores estratégicos, comerciais e humanos são responsáveis por algumas das variáveis que contribuem para tornar o desenvolvimento de sistemas de software uma atividade altamente complexa. Modelos tradicionais de desenvolvimento de software propõem processos prescritivos que não consideram toda essa complexidade. Por outro lado, Métodos Ágeis de desenvolvimento de software sugerem uma abordagem mais humanística com foco na entrega rápida e constante de software com valor de negócios. Porém, para conseguir isto, é preciso escolher um conjunto de práticas de desenvolvimento adequado às características do projeto e da equipe. Desta forma, a natureza única de cada projeto e a necessidade de alta qualidade e produtividade tornam importante a busca por práticas de desenvolvimento. A partir de projetos que conduzimos usando métodos ágeis na academia e na indústria, identificamos e descrevemos 22 práticas para desenvolvimento de software que podem ser adotadas por equipes para aumentar o seu desempenho e/ou a qualidade do software. / The growing demand for systems and the high speed with which their requirements evolve has shown that software development requires flexibility because many decisions need to be taken during the project. Also, the difficulties for the production of software systems go far beyond the technical issues. Strategic, commercial and human factors are responsible for some variables that contribute to make the software development a highly complex activity. Traditional models of software development propose prescritive processes that do not consider all this complexity. On the other hand, Agile Methods of software development suggest an humanistic approach focused on fast and often business valuable software deliveries. But, in order to get it, one needs to choose an appropriated group of development practices accordingly to the project and team features. In this way, the individuality of each project and the need for better quality and productivity motivate the search for software development practices. Based on projects that we conducted by using agile methods in academic and industry environments we identified and described 22 software development practices that can be used by teams to increase their performance and/or the software quality.

No description available.

Choosing the Software Development Methodology is the very first step of any project; thus,has been a hot topic among, both, practitioners and academic people. After using plandrivensoftware development methodologies software development researchers came up withthe idea of agile software development methodologies as a masterpiece. Although, failurestories of some teams brought about fading the idea that agile methodologies are thebest recipe for any kind of development project. Considering the lack of studies in helpingpractitioners to select the most appropriate agile software methodology, this study aims atprovide the software development manager with a thorough knowledge of agile methodologiesand the criteria that should be considered, while selecting one of them. A case study is used asan empirical support. / Program: Magisterutbildning i informatik