No description available.

<p>The biggest field in the recent decade in software development has been a subject known as Agile Development. In Agile development the construction of the software is an iterative process and is done with close contact with the costumer. One of the most well-known agile methods is Extreme Programming, which suggests a number of practices to develop software. One of those practices is test-Driven Development, which is the writing of the test code before you write the actual code. This means that one can test the code after it is finished. This creates an opportunity to change the design of the code and then test it again with your test code and discover if any functionality has been lost. The purpose of refactoring is the improvement of the design of existing code. How refactoring affects the performance is not widely discussed and therefore this thesis is going to examine that field. Code examples with and without refactoring principles have been tested. The investigation has been divided into two parts, part one tests individual refactoring principles and part two tests a test application. There are many opinions how to interpret the results of a performance test. After an extensive investigation the arithmetic mean was chosen, mainly because it reflects the total runtime for a series of executions. To test the hypothesis that total execution time will change with refactoring the Students t-test was used. It was chosen because it can be applied even when the variance is unknown. The results were clear, the arithmetic mean increased in five out of six refactoring principles. The test application also increased, but with only 4 %. The reason for the small increase was that it is not possible to go from a non refactored application to a fully refactored application. Another reason is that is was developed with Swedish Rail Administration’s framework which of course was not refactored. The conclusion of this thesis was that one should be careful with refactoring the parts of the code that is executed the most. One should have the “90-10 rule” in mind, it states that 90 % of the execution time is done in 10 % of the code. Another important aspect is that very often is an existing framework used, if you only refactor the new code and not the framework it leads to that only a subset of the code is being refactored. This means that the application does not get fully refactored and therefore the consequences of the refactoring mitigates.</p>

No description available.

The biggest field in the recent decade in software development has been a subject known as Agile Development. In Agile development the construction of the software is an iterative process and is done with close contact with the costumer. One of the most well-known agile methods is Extreme Programming, which suggests a number of practices to develop software. One of those practices is test-Driven Development, which is the writing of the test code before you write the actual code. This means that one can test the code after it is finished. This creates an opportunity to change the design of the code and then test it again with your test code and discover if any functionality has been lost. The purpose of refactoring is the improvement of the design of existing code. How refactoring affects the performance is not widely discussed and therefore this thesis is going to examine that field. Code examples with and without refactoring principles have been tested. The investigation has been divided into two parts, part one tests individual refactoring principles and part two tests a test application. There are many opinions how to interpret the results of a performance test. After an extensive investigation the arithmetic mean was chosen, mainly because it reflects the total runtime for a series of executions. To test the hypothesis that total execution time will change with refactoring the Students t-test was used. It was chosen because it can be applied even when the variance is unknown. The results were clear, the arithmetic mean increased in five out of six refactoring principles. The test application also increased, but with only 4 %. The reason for the small increase was that it is not possible to go from a non refactored application to a fully refactored application. Another reason is that is was developed with Swedish Rail Administration’s framework which of course was not refactored. The conclusion of this thesis was that one should be careful with refactoring the parts of the code that is executed the most. One should have the “90-10 rule” in mind, it states that 90 % of the execution time is done in 10 % of the code. Another important aspect is that very often is an existing framework used, if you only refactor the new code and not the framework it leads to that only a subset of the code is being refactored. This means that the application does not get fully refactored and therefore the consequences of the refactoring mitigates.

Test Driven Development is a software technique which uses automated unit tests to drive software design and to force decoupling of dependencies. This report describes the pilot study that was conducted to understand Test Driven Development process and to evaluate its pros and cons before adopting it completely across the software team. The goal of the pilot study was to use TDD principles to build part of a real life software project - in particular, to completely implement 3 user stories - and to evaluate the resulting software. The main questions being discussed are - Is it feasible to adopt TDD in the development of a real life system with databases and UI? How easy is it to convert a user story into a set of unit tests? Can a set of unit tests adequately represent a user story or are requirements lost in translation? / text

Bachelor-Arbeit Univ. St. Gallen, 2005.

University, Diss., 2004--Würzburg.

Thesis--Auburn University, 2009. / Abstract. Vita. Includes bibliographical references (p. 73-75).

Thesis (doctoral)--Universität St. Gallen, 2006.

Made available in DSpace on 2014-06-12T16:01:12Z (GMT). No. of bitstreams: 2 arquivo7178_1.pdf: 1473982 bytes, checksum: a80205c97e4d02bb017cd160eec998a0 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2005 / A evolução da indústria de software vem seguindo as tendências do mercado global, onde fatores como alta qualidade, baixo custo de produção e manutenção, uso efetivo de recursos e time-to-market ditam os objetivos dos negócios. Além destas demandas, um novo fator está sendo incorporado: a customização de produtos para atender às necessidades únicas de cada cliente. Apesar de novas estratégias terem surgido na indústria de software no sentido de sistematizar o desenvolvimento de produtos de software, ainda existem vários desafios em torno da necessidade de construir produtos modulares e que possuam um alto grau de flexibilidade, como, por exemplo, o amadurecimento de um processo para a construção sistemática de produtos customizáveis de software e a solução dos problemas em torno da instanciação destes produtos para atender às necessidades particulares de diversos clientes. Através de uma análise de processos de software existentes foi possível identificar as lacunas deixadas pelos processos RUP e XP, no âmbito da customização e implantação de produtos de software. As abordagens focam no desenvolvimento de produtos de software, seja ele um serviço para um cliente específico (software sob encomenda) ou um produto fechado. Como resultado deste estudo, foi definida uma abordagem de processo de software cujo objetivo é orientar e apoiar na condução de projetos cujo foco é a customização e implantação de produtos de software. As principais contribuições deste trabalho são a formalização de um processo eficaz para a customização e implantação de produtos de software e que, ao mesmo tempo, seja vantajoso em termos de tempo e custo em relação ao desenvolvimento tradicional de software