“When in Rome do as the Romans do” – this hundreds years old proverb is still very actual today. Even more, nowadays you don’t even have to go to Rome to feel cultural differences. The communication technology have changed the world economy, thousands of people work now for multinational companies, interacting daily not just with a culture, but possibly with as much as 5 or 6 different ones. Some teams even work in different geographical locations communicating exclusively by electronic means. Today’s managers just have to deal with culture whether they like it or not, but the whole employee-manager relationship may be turned upside down on another side of the globe. So what should we do and what do we do about it? Ho do we manage effectively? These are the questions that this study aims to answer at. The main research objects of this study are rather small software engineering teams and companies that are working in cross-cultural environment, but do have little or no special company policies and other formal ways to manage cultural differences. Yet we found out that managers develop there own understanding of cultural issues and are practicing different methods to deal with them. / mkitsul@yahoo.com; seza@km.ru

Abstract The purpose of writing this thesis was to improve methods during requirements engineering phase. Usercentred system engineering has some problem areas, which are examined and verified to create a new guideline for developers. This guideline tends to make requirements engineering more effective and help developers create more concrete requirements. It is not uncommon that system development projects ends up with unsatisfied users or delay in deliveries. The reasons are different kinds of communication problems between users and developers during verification of requirements. There is a therapy model, called solution-focused therapy, used in family and individual therapy. The model focuses on solutions for the future instead of problems in the past. This method has never been used in system developing until today. Based on literature studies and scenarios we have shown that it is possible to transfer this pedagogy into the system developing branch especially in requirements engineering. During our investigation we have shown that the pedagogy refute the difficulties within usercentred design. The pedagogy model can be used in four kinds of methods for capturing requirements; questionnaires, interviews, workshops and observations. The model activates and makes the user more implicated. To show this, we have applied the pedagogy model on scenarios taken from earlier experiences of requirements engineering. The outcome of this investigation is that developers can create a more pleasant communication atmosphere with this pedagogy. A result of this is that users becomes more willing and helpful to create a new system and therefore makes it easier for developers and users to cooperate. You can avoid many communication problems if you know how to go around them.

Object-Oriented frameworks, OO frameworks, have been discussed over a long period of time, that when introducing Object-Oriented frameworks, the defect-density will decrease and the quality of software will increase. Capgemini had developed a framework that had been in the organization for nine years. Since then, the framework has been reengineered several times to meet the continuously changing requirements of the software systems the framework supports. My work was to develop a new framework to make the maintainability and evolution of the framework easier while not compromising the quality of the framework or the applications built on it. The new framework that I developed was called the Capgemini Development Framework, CDF. Results from the case study, conducted to test the differences between these two frameworks, showed that the CDF framework preserved the maintainability of the applications built on the framework. The architecture of the CDF framework made it also easier to handle any future updates to the core functionality of the framework.

Problemområde: Fler och fler privatpersoner kopplar upp sig mot Internet via bredband. En anledning till detta är att fastighetsbolagen allt oftare erbjuder sina hyresgäster fast uppkoppling. Vad hyresgästerna kanske inte tänker på när de är uppkopplade flera timmar i sträck, är att det är lättare för någon utomstående att göra intrång i deras datorer. Frågeställning: 1. Informerar bredbandsleverantörer sina kunder om risker för intrång? 2. Har bredbandsleverantörer någon skyldighet att informera sina kunder om risker för intrång och kan de ställas till svars för om deras kund utsätts för/gör intrång? 3. Anser bredbandsleverantörer att det är viktigt att deras kunder har en brandvägg? 4. Finns det något samband mellan ökat antal intrång och ökat antal bredbandsanvändare? Slutsats: Nästan en tredjedel av bredbandsleverantörerna informerar inte sina kunder om risker för intrång. De har inte någon skyldighet att informera om riskerna och som en följd av att sådan skyldighet saknas kan de inte ställas till svars för om kunden utsätts för/gör intrång. 78 % av leverantörerna rekommenderar sina kunder att installera en brandvägg, dock erbjuder endast en fjärdedel sina kunder brandvägg. Utifrån undersökningar har vi kommit fram till att ökat antal intrång och ökat antal bredbandsanvändare har ett samband.

Companies around the world work more globally than ever and it reflects in the system development projects that run. The companies work span continents and the employees work together over the borders. This way of working, the global distributed, brings a number of opportunities for the company but also presents a lot of problems. The distributed way of working means that the teams and/or individuals are divided. I wanted to connect this way of working with the agile framework Scrum, partly due to my own interest on the subject and partly as it is a contradiction to me, distributed work and Scrum, therefore a challenge to combine. To be able to investigate this way of working I got in touch with two companies that work globally and distributed, using the Scrum technique, I read literature and papers on the subject to be able to reach my conclusions. My conclusions are based on the success factors I found in both the literature and the dialogs performed. The study shows three important qualities in a leader, a scrum master, in a globally distributed development team: Coaching leadership, clear leadership and smaller distributed teams not individuals.

With the introduction of the peer-to-peer paradigm in the world of software, a lot of applications have been created in order to such architecture. Most of them are developed for providing a data sharing service among users connected to a network and programs such as Napster, Gnutella, eMule and BitTorrent have became the so called killer-applications. However some eorts have been spent in order to develop other solutions with the usage of peer-to-peer paradigm. In the case of databases some projects are started with the general purpose of sharing data sets with other databases. Generally they push on the idea of providing the data contained in their database schemes with other peers in the network showing concepts such schema matching, mapping tables and others which are necessary to establish connections and data sending. The thesis analyzes some of such projects in order to see which of them is the most dened and well-supported by concepts and deni- tions. Hyperion Project of the University of Torono in collaboration with the University of Trento is the most promising and it aims to be one of the rst Peer-to-Peer Database Management Systems. However the common idea of considering the peer-to-peer paradigm equal to data sharing - in the way presented by applications such as Napster or others - leads to a lot diculties, it is hard to handle the data sets, some operations must be done manually and there can be some cases where the peer-to-peer paradigm is not applied at all. For this reason the goal is to dene and show the concept of peer-to-peer database built from the scratch with a suitable DBMS for it. A real denition of peer-to-peer database has not been ever made and here for the rst time we tried to give one according to our vision. The denition depends on some precise concepts such global schema - which is the original design of the database -, sub-schema - a well logical dened sub-set of entities of the original schema - and binding tables - necessary to allow the creation of constraints and relations among the entities. Then to show the validity of such concepts and how a management system for peer-to-peer databases can be developed and used, a prototype (named Dionysius) has been realized by modifying HSQLDB - an ordinary DBMS developed in Java - and adding the peer-to-peer platform by using the JXTA libray set.

Software process improvement is often mentioned in today?s software marketplace. To be able to do process improvement, the organisation must have a process to improve from. These processes are commonly deviated from, and the PDU/PAY organisation at Ericsson AB has experienced that this happens too often within their organisation. The aim of this master thesis was to investigate why such deviations occur and how they could be prevented at PDU/PAY. A survey including a qualitative and a quantitative part was conducted at PDU/PAY to investigate this issue. The result was that processes were often deviated from due to lack of: management commitment, user involvement, synchronisation between processes, change management, anchoring of processes, and communication of processes. In addition to the conducted studies, an improvement proposal is given to the PDU/PAY organisation. This includes one organisational part and one part that is directly related to the actual work with processes. The proposal is intended to give PDU/PAY an essence of how to improve their work with their organisational processes.

Att hitta ett lämpligt tillvägagångssätt för att utföra testning i små utvecklingsteam är en utmaning. Många små företag upplever traditionella testprocesser och testförbättringsprocesser som alltför resurskrävande. Minimal Test Practice Framework (MTPF) är ett ramverk för testning vars syfte är att tillhandahålla ett minimalistiskt tillvägagångssätt för testförbättring. Målet med denna studie var att undersöka hur MTPF kan implementeras och anpassas till ett litet utvecklingsteam utan att den medför en för stor tidsinvestering. Studien utfördes på avdelningen Webb \& Mobilt i företaget Exsitec där team om 2-6 personer utvecklar webbapplikationer till företagskunder. I nära samarbete med utvecklarna på avdelningen togs en testprocess fram med målet att den skulle anpassas till verksamheten i så stor utsträckning som möjligt. Studien genomfördes som aktionsforskning i tre faser utefter Cooperative Method Development i ett projekt med två utvecklare. Under studiens första fas intervjuades alla utvecklare på avdelningen för att skapa en grundförståelse för verksamheten. Under den andra fasen togs ett antal förbättringsförslag fram tillsammans med utvecklarna. Under den tredje fasen infördes och utvärderades dessa förbättringar. Genom att fokusera på enhetstestning av central affärslogik i applikationen uppnåddes en testprocess som gav utvecklarna ett ökat förtroende för kodens kvalitet utan att upplevas som för resursintensiv. / Finding a suitable approach for testing in small development teams is a challenge. Many small companies view traditional test processes and test process improvement models as too resource intensive for their needs. Minimal Test Practice Framework (MTPF) is a framework for testing which purpose is to provide a minimalistic approach to test improvement. The goal of this study was to examine how MTPF can be adapted to a small development team without incurring a time cost that the team would experience as too high. The study was performed in the department Web \& Mobile of the company Exsitec. At the department teams of 2-6 people develop web applications to business customers. During the study a testprocess was developed in close cooperation with the developers of the department with the aim of adapting it as well as possible to the needs of the department. The study was performed as action research in three phases, according to the method Cooperative Method Development, in a project with two developers. During the first phase all developers in the department were interviewed to establish an understanding of the environment for the study. During the second phase a set of possible improvements was developed together with the developers. During the third phase some of these improvements were implemented and evaluated. By focusing on unit testing central business logic in the application the developed test process improved the developers confidence in the code quality without being perceived as too resource intensive.

I dagens samhälle blir fler och fler enheter uppkopplade mot Internet vilket kan ge en annars begränsad hårdvara möjlighet att genomföra större beräkningar. Detta projekt avser att skapa ett system som hanterar en användares radarenheter i ett molnbaserat system. Systemet erbjuder även möjligheten att ladda upp användarens egna applikationer vilka använder data från radarenheten, körs på virtuella maskiner och vid behov har möjlighet att skicka notiser till användarens mobila applikationer. För att underlätta utveckling har systemet delats upp i tre delsystem. Dessa är radarenhet, molntjänst och mobilapplikation. Projektet resulterade i ett komplett system med en webbapplikation som erbjuder användaren möjlighet att registrera sina radarenheter, ladda upp källkod som kompileras och körs på en molntjänst samt möjlighet att skicka notiser till en mobilapplikation. / Todays age sees more and more devices connected to the internet providing otherwise quite limited hardware with the ability to perform more complex calculations. This project aims to create a system for managing a users radar devices using a cloud platform. The system also provides the ability for the user to upload their own custom applications which can make use of data provided by the radar device, run on virtual machines and if required have the ability to push notifications to the users mobile applications. To simplify the system development, it has been divided into three separate subsystems, specifically the radar device, the cloud service and the mobile application. The result of the project is a complete system with a web application which provides the user with the ability to register their radar device(s), upload source code which is compiled and run on the cloud platform and the ability to send push notices to a mobile application.

Context. The approach of developing software systems with the use of third partycomponents i.e. COTS or OSS has increased globally. In this study API product refers toeither a software component or a software service or both packaged together, that can beaccessed through an API. Developers are faced with plethora of alternative choices to selectan API product. With this increase in components adoption, API product providers are facedwith challenge of designing their product to be more attractive than others. This needs theproviders to be educated about the developer behavior when they choose an API product.Understanding the selection practices of developers can help providers to improve thepackaging of API products, making them more suitable for selection. Objectives. The objectives of this study is to investigate the criteria that developers usewhen reasoning about acceptability of a software component. Methods. A background study is performed to identify the evaluation criteria proposed inthe literature. An empirical study using Qualitative content analysis is performed. In the study the 480 reviews of different API products are analyzed to understand the criteria frompractitioners’ perspective. Results. 9 relevant criteria that developer use to reason about accepting or rejecting an APIProduct are identified. 30 sub criteria related to the 9 criteria are described in the study. Conclusions. This study concludes that the identified 9 criteria play an important role indeveloper assessment of the API product. It is also found that the criteria have significantimpact on the ratings of API product. These criteria could guide API product providers tomake better choices when developing the product.