Las metodologías ágiles de desarrollo de software, y en particular Extreme Programming (XP), constituyen una de las tendencias de mayor impacto en la industria del desarrollo de software en la última década, gracias a su enfoque centrado en la generación temprana de valor y en su acento en el aspecto humano del desarrollo de software. Su adopción sin embargo ha demostrado ser bastante compleja debido a los cambios de paradigma que ellas plantean. Desde los inicios de estas metodologías surgió el interés de incorporar esta nueva mirada como una forma de enriquecer la formación de los futuros ingenieros de software. En este trabajo se plantea que un buen aprendizaje de las metodologías ágiles de desarrollo de software puede ser logrado por los alumnos a través de una experiencia educativa teóricopráctica basada en la aplicación de dichas metodologías en proyectos reales. Este enfoque ha sido aplicado desde el año 2002 en el curso CC62V “Taller de metodologías ágiles de desarrollo de software” delDepartamento de Ciencias de la Computación de la Universidad de Chile, y en esta investigación se pone a prueba esta hipótesis, a partir del análisis de una de las instancias del curso realizada entre los meses de agosto y noviembre del año 2005. Para realizar este análisis se construyó un modelo evaluativo de aprendizaje basado en cómo las metodologías ágiles, y en particular Extreme Programming (XP), organizan el entorno de un proyecto de desarrollo de software para mantener la sincronía entre los cambiantes elementos que allí están en juego. Dichos elementos son el problema de negocios, la tecnología, la experiencia y destrezas del equipo de desarrollo, y el producto en desarrollo. El modelo de evaluación fue aplicado sobre los trabajos generados por los alumnos de la versión del curso usado como experimento de esta investigación, complementados con las observaciones realizadas por el profesor en la sala de clases, y otras evidencias tales como las opiniones de los clientes y una encuesta de evaluación de impacto hecha a los alumnos aproximadamente 6 meses después de finalizado el curso. Con respecto al impacto en el aprendizaje de los alumnos, se observó una comprensión y aplicación generalizada del marco de prácticas de XP, aunque el nivel de logro estuvo muy relacionado al entorno de trabajo logrado por cada uno de los proyectos realizados. En particular se encontró que algunos elementos no considerados en la hipótesis original, tales como la complejidad del problema a resolver y la relación con el cliente, tenían también un impacto relevante sobre el éxito de los proyectos, y no sólo los aspectos pedagógicos. Se comprobó la eficacia de este modelo pedagógico que promueve el equilibro entre teoría y práctica, el ambiente humano de equipo y de colaboración con el cliente y las destrezas entrenadas. Por su parte, la práctica de XP más destacada por los alumnos es la “programación en parejas”, que presenta la mejor evaluación durante el curso y es la más aplicada a posteriori. Otra práctica que causa mucho interés es el “desarrollo guiado por test”, pero se indican problemas de tiempo y experiencia para poder aplicarla después del curso. En lo que se refiere al modelo pedagógico aplicado para que los alumnos conozcan e internalicen las prácticas de XP, se determina que las claves de su éxito se encuentran en: reproducir de manera fiel el ambiente de aprendizaje colaborativo acelerado que se genera en la práctica profesional de las metodologías ágiles, y complementar dicho ambiente con una leve capa de acciones docentes orientadas a reflexionar y retroalimentar el dominio de la metodología.

Dagens utveckling av mjukvara går snabbare och snabbare samtidigt som mjukvaran blir allt mer komplex. Att under dessa omständigheter kunna bibehålla en lika om inte högre kodkvalité är en utmaning. På UIQ bestämde de sig för att undersöka om ett automatiserat unit test kunde hjälpa dem. Metoderna för att komma fram till resultaten i denna rapport har varit intervjuer, en enkät, intern information och litteratur så som forskningsartiklar m.m. Denna rapport är en utredning av automatiserade test, vad man bör tänka på, vilka fördelarna är, vilka testfall som är möjliga att automatisera med mera. Rapporten kommer även att presentera grunderna i testning av mjukvara, en introduktion till eXtreme Programming och Test-Driven Development samt hur testningen utförs på UIQ idag. Då jag kom fram till att ett automatiserat unit test skulle passa sig bra på UIQ kommer jag i slutet av denna rapport presentera ett implementerings förslag. Man bör även införa en test driven utvecklings metodik för att säkerhetsställa att det kommer att utvecklas automatiserade testfall. / Det första en utvecklare tänker på när man hör de tre magiska orden automatisk unit testning är att han äntligen slipper sitta med den tråkiga testningen. Medan chefen och ekonomiansvarige börjar räkna på hur mycket pengar de kan spara efter de sagt upp halva testavdelningen. Tyvärr får båda tänka om då oftast den automatiska testningen har lika lång utvecklingstid men förhoppningvis om den blir lyckad så förbättrar den kodkvalitén. Vilket kan vara minst lika mycket värt som att man sparar några kronor i minskade personalkostnader.

Syftet med arbetet var att ta reda på om den ökade tidsåtgången som parprogrammeringen leder till uppvägs av de fördelar som den genererar i jämförelse med enskild programmering där arbetet delas mellan två programmerare och sedan integreras. I arbetet presenteras resultatet från en enkätundersökning som sju personer från fyra olika företag i Sverige har besvarat. Samtliga personer som besvarat enkäten har arbetat både med enskild programmering och parprogrammering. Vårt arbete bidrar till forskningsområdet programvaruteknik som intresserar sig för mjukvaruutvecklingsmetoder. På senare tid har detta forskningsområde också intresserat sig för lättrörlig mjukvaruutveckling där utvecklingsmetoden Extreme Programming (XP) ingår. XP tillämpar parprogrammering och är en mjukvaruteknisk metod som har att göra med klassisk mjukvaruteknik som bl.a. utgår ifrån kodkvalite och samspel mellan utvecklare. (Rittenbruch m.fl, 2002) I den litteratur vi läst har det presenterats en undersökning som gjorts i USA om parprogrammering. I den konstaterades att detta arbetssätt ger en ökad tidsåtgång och det framkom också ett antal fördelar med att programmera i par. Vi har utgått ifrån tidsåtgången och fördelarna när vi gjorde vår enkätundersökning. Vi fann att vår undersökning styrker de fördelar som finns med parprogrammering, men däremot bekräftar inte undersökningen att tidsåtgången ökar. Samtliga i undersökningen tycker att kodkvalitén förbättrats, dvs bättre struktur och design samt mindre fel på koden. Sammanhållningen och kommunikationen har blivit bättre och fler programmerare är involverade i samma kod. Detta innebär att projektgruppen inte påverkades så mycket när en person lämnar projektet. Det har också framkommit att parprogrammering inte är lämpligt att använda vid enklare uppgifter.

No description available.

Det här arbetet har med hjälp av en kvalitativ undersökning tagit fram framgångsfaktorer för parprogrammering. Detta har genomförts med hjälp av intervju samt enkätundersökningar med sex respondenter. Då litteraturen inte behandlar hur parprogrammering kan bli framgångsrikt har detta arbete haft som syfte för att göra detta. Resultatet har kategoriserats i fyra nivåer. Exempel på framtagna framgångsfaktorer är att: • ledningen måste införskaffa kunskaper om parprogrammering • projektledaren uppmuntrar till byte av par ofta • projektdeltagarna är öppna och mottagbara för konstruktiv kritik

No description available.

<p>Att sätta sig in i system kan vara krångligt utan rätt sorts dokumentation. Vi har undersökt vilken dokumentation som kan vara lämplig att lämna över till nya utvecklare, som ska arbeta vidare med systemet i software maintenance fasen.</p><p>Det har gjorts genom att vi har gjort en litteraturstudie om dokumentation samt undersökt vad för dokumentationsartefakter som används när man ska sätta sig in i datorsystem. Vi använde eXtreme Programming för att utveckla ett system som vi försökte dokumentera samtidigt som vi utvecklade det.</p><p>eXtreme Programming förordar muntlig kommunikation, vilket är svårt att lämna över till nya utvecklare. Vi upptäckte under vår utveckling att det var svårt att föra in dokumentation sam-tidigt som utvecklandet pågick,  därför använde vi bara enhetstester och  strukturerade kod-kommentarer under utvecklingsiterationerna.</p><p>Vi undersökte hur dokumentationen som skapats fungerade genom att göra en undersökning bestående av strukturerade intervjuer där de fick komma med kommentarer om hur dokumen-tationen hjälpte förståelsen för systemet.</p><p>Vi lämnar ifrån oss en vidareutveckling  av eXtreme Programming  som innefattar en doku-mentationsiteration  innan överlämnandet  samt en studie om vad för dokumentation som är värdefull att ha vid systemöverlämningar.</p> / <p>Understanding systems can be a tough task without the right sort of documentation. We have examined the documentation artifacts which may be appropriate to hand over to new develop-ers, who will continue working with the system during the software maintenance phase.</p><p>By doing a literature review on documentation and examined what documentation artifacts is used when you want to  understand a computer system. We used the eXtreme Programming system development methodology to develop a system that we tried to document as we devel-oped it.</p><p>eXtreme Programming favors oral communication, but that is hard to hand over to new devel-opers. We discovered during our development that it was difficult to introduce documentation while the development process was going on so we only used structured code comments and unit testing during the development iterations</p><p>We examined how the documentation that was created worked by doing a survey consisting of structured interviews where the respondents made comments about if and how the documen-tation improved their understanding of the system.</p><p>We pass on an evolved eXtreme Programming system development methodology, which in-cludes a standalone documentation iteration before the handover, and a study of what kind of documentation that is valuable to have when transferring systems to new developers.</p>

Die vorliegende Ausgabe beschäftigt sich mit der Entschleunigung von Konsum- und Unternehmens-prozessen. Entschleunigung ist ein aktuelles Thema in der Wissenschaft, dem immer mehr Aufmerksamkeit geschenkt wird. Umwelt und Bevölkerung können einer stetigen Beschleunigung nicht unbegrenzt standhalten, so dass eine gegenläufige Entwicklung auf Dauer unvermeidlich ist. Doch in welcher Form haben sich Aspekte der Entschleunigung bisher sowohl in Unternehmen als auch bei Individuen etablieren können? Um diese Frage zu beantworten, kommen in dieser Arbeit unterschiedliche empirische Methoden zur Anwendung. Mit Hilfe eines Experiments, durchgeführt mit Studenten der Wirtschaftswissenschaften an der TU Dresden, wird dabei die Zahlungsbereitschaft für Entschleunigung innerhalb der Bevölkerung untersucht. Zur weiteren empirischen Überprüfung des Kenntnisstan-des und Verbreitungsgrades des Themas Entschleunigung werden zwei Fragebögen, welche sich zum Zeitpunkt des Entstehens dieser Arbeit im Stadium des Pre-Tests befinden, entwickelt und im Rahmen dieser Arbeit vorgestellt und ausgewertet. Die Abfrage des Themas Entschleunigung erfolgt dabei über die Betrachtung verschiedener Sichtweisen (Unternehmens-, Kunden-, Mitarbeiter- und Gesundheitssicht), zu denen einleitend theoretische Grundlagen gelegt werden. Als konkretes Beispiel für eine mögliche Umsetzung von Entschleunigung wird für die IT-Branche das Extreme Programming vorgestellt, welches versucht, neue Wege in der Softwareentwicklung zu gehen. Innerhalb einer Fallstudie werden abschließend Netzwerke in der freien Marktwirtschaft und ihre möglichen Beiträge zur Entschleunigung untersucht.

[pt] Test Driven Development (TDD) é uma das práticas de eXtreme Programming (XP) mais fáceis de entender e ao mesmo tempo uma das mais difíceis de executar. Para que o TDD seja usado apropriadamente, é preciso empregar práticas complementares, utilizar ferramentas adequadas e tomar algumas precauções para que seja feito de forma correta. Este trabalho de mestrado apresenta um estudo baseado na experiência real - realizada em uma pequena empresa - na qual foi elaborada uma infra- estrutura favorável ao desenvolvimento dirigido por testes. Quais as vantagens e desvantagens de cada uma das práticas? Como introduzir essas práticas no dia-a- dia de uma pequena empresa? Que tipo de infra-estrutura deve ser montada? Quais as ferramentas? Quanto tempo e qual o tipo de investimento necessário para a implantação dessas melhorias? Estas e outras perguntas são respondidas no decorrer do trabalho. / [en] Test Driven Development (TDD) is one of the eXtreme Programming´s (XP) easiest practices to understand but at the same time difficult to implement. It is necessary to use complementary practices, appropriate tools, and follow carefully some rules for achieving good results. A real experiment creating an adequate environment for TDD was conducted in a small company. This study will show the results obtained. What are the advantages and disadvantages of each one of the practices? How to establish these practices in small company daily operations? What type of environment has to be built? Which tools? How much time and investment for implementing this kind of enhancement would be required? This work will present answers to these questions.

現今軟體開發專案普遍有時程延宕、預算及人&#63882;&#63847;足、軟體品質低&#63768;、無法應付客戶頻繁的需求變動等問題。為思考相關解決之道，本研究&#63851;考極致編程(Extreme Programming，簡稱XP)軟體開發方法，於校園內選擇特定專案，配合XP的四個核心價值觀與十二項實&#64008;原則實際進&#64008;軟體開發。於專案導入XP後，透過對開發過程的觀察、記&#63807;、資訊蒐集，及針對開發團隊所作的深入訪談，本研究綜合分析與評估XP於校園內軟體開發專案之適用性，並發掘可能的問題。 　　研究中發現XP在校園內&#63847;&#63968;達到完美實踐之目標，適用性&#63847;高，主要受限於時空環境難以配合、團隊專案經驗&#63847;足、缺乏激&#63871;誘因、缺乏團隊約束&#63882;等因素；&#63847;過施&#64008;XP也改善&#63930;團隊內外部的溝通與協調機制，促進團隊成員之間的知&#63996;與經驗分享，亦有&#64023;於系統架構之完整性。 　　本研究排除&#63930;完全無法實施的要項之後，依團隊實際情況提出&#63860;干改善及彈性應變之建議做法，以期將XP進一步應用於業界個案及後續學術研究。