No matter which tools, techniques, and methodologies are used for software development, it remains an error-prone process. Nevertheless, changing such important constituents of the software process surely has an effect on the types of faults inherent in the developed software. For instance, some types of faults are typical for structured development, whereas others are typical for object-oriented development. This chapter explores the question of whether component-based software requires new testing techniques, and proposes an integrated testing technique. This technique integrates various tasks during testing component-based software: whiteand black-box testing of the main component (i.e., the top level component controlling the other components), black-box testing of components, black-box testing of the middleware and integration testing of the main component with other components. Benefits of this technique are shown using a real-world example: the technique is automatable and applicable to existing component-based software.

No description available.

No description available.

This study investigates the impact of consumer sophistication on emerging market firms’ ability to innovate. Three constructs, namely, innovation capabilities, sources of information and strategies, were identified as critical factors in the innovation process. By leveraging off these factors emerging market firms may gain sustainable competitive advantages in a highly competitive environment. The context of the study was South African based software development firms competing in more developed markets (wealthier), less developed markets (poorer) and domestic markets only (middle income). Data collection took place via telephonic survey. It was found that the size of the firm as measured by the number of employees is related to the consumer sophistication. Firms in less developed markets tend to be significantly larger than firms in more developed markets and the domestic market. Suppliers and clients as sources of information that impact the firms’ innovation development were found to be statistically significant. Firms in the more developed markets made considerable use of international clients for innovation ideas whereas firms in the domestic market leveraged ideas off local suppliers. The firms’ resource strategy was found to be significantly different across the three groups. Domestic market firms considered themselves ahead of the industry compared to less developed markets who considered themselves average with regard to having the latest equipment. / Dissertation (MBA)--University of Pretoria, 2010. / Gordon Institute of Business Science (GIBS) / unrestricted

No description available.

3D printing for microfluidic device fabrication has received considerable interest in recent years, in part driven by the potential to dramatically speed up device development by reducing device fabrication time to the minutes timescale. Moreover, in contrast to traditional cleanroom-based fabrication processes that require manual production and stacking of a limited number of layers, 3D printing allows full use of the 3D fabrication volume to lay out microfluidic elements with complex yet compact 3D geometries. The Nordin group has successfully developed multiple generations of high resolution printers and materials for microfluidic devices that achieve this vision. However, because of the customizability of design in the Nordin microfluidics lab, finding settings that lead to a successful print can involve a taxing cycle of adjustments. The current 3D microfluidics design flow, which requires each student to find settings for each design, makes it difficult for new students to rapidly print successful designs with new components. In this thesis I present an Improved Microfluidic Design Approach (IMDA) that is based on a pre-defined component library. It allows students to reuse a library of components such that a new designer can utilize the work of more experienced predecessors, allowing the lab to avoid repeating the same parameter tuning process with each student. So far the tool has shown the feasibility of printing new designs based on previously tested components. Ultimately, my work demonstrates an attractive path to make the 3D printed microfluidic design experience more robust, repeatable, and easier for newcomers to learn.

The aim of this thesis is to analyse and if possible improve the communication, mainly seen from a pedagogical perspective, between the IT company (Nostratic) and their clients in a first meeting. The analysis covers the preparation part, communication during the meetings, the technical terminology used during the meetings as well as the follow up of the meetings. Due to the lack of research within this area and the lack of personal experience on my part, the conducted study has been explorative with the use of qualitative methods. Although my first aim was to put emphisis on the pedagogical part of the communication, I found while conducting the study that there were other areas of higher importance to analyse in order to improve the customer meetings. Unfortunately the company went bankrupt in the middle of my study which resulted in me not beeing able to try out the potential improvements. My conclusion of the analysis is that the problem lies not only, as I first thought, in the lack of pedagogical skills of the company representatives but also, and even more apparent, were the company’s lack of organisation and routines concerning meetings.Key

Background: Organizations want to reach shorter development cycles to stay competitive, meanwhile, many organization wants to globalize their business to obtain benefits like reduced cost, get hold of specific talent or gain global presence.  Typically in software development projects, there is a gap between development and operation resulting in a longer development cycle due to inferior communication and collaboration. DevOps is a framework that intends to reduce this gap with the purpose to reach shorter development cycles. However, currently, there is a lack of literature covering whether it is possible to adopt DevOps and keeping an offshore strategy.  Purpose: The purpose of this thesis is to increase understanding about the use of DevOps in offshore projects. This increased understanding will be the start of filling the current gap in the literature about DevOps in distributed setups and form a basis for future research. The study aims to suggest how DevOps framework can bridge the gap between development and operation in offshore projects.  Method: An exploratory case study was conducted and three different offshore projects, who had adopted DevOps, were investigated. In this study, 15 members from different projects were interviewed to find out how DevOps had been adopted in their projects. Based on a survey, a Social Network Analysis was conducted for each project with the purpose to identify communication patterns between members.  Results: The result of this study provided information, specific to each project, about the setup, DevOps definition, and goal, DevOps practices as well as benefits and challenges with DevOps. Furthermore, the result presented information related to the performance of the project and, information about the collaboration, communication, and trust within the project.  Conclusion: This study presented four possible distribution possibilities of DevOps in an offshore project and suggested different ways to manage the work roles when adopting DevOps. The study indicates that DevOps can be adopted in an offshore project in order to decrease the gap between development and operation by considering three perspectives; roles and responsibility, automated workflow and DevOps practices, and knowledge sharing  Delimitations: This study is limited to only investigate projects from one company. Furthermore, the scope of this study does not include any economic aspects.

Den 25 maj 2018 trädde den nya dataskyddsförordningen, GDPR, i kraft. GDPR kräver att organisationer och företag, som behandlar persondata, att anpassa sig och andra sina system och produkter för att uppfylla kraven som förordningen ställer. Om organisationer och företag, som faller under förordningen, inte kan uppfylla dem kraven som förordningen ställer måste administrativa böter betalas, vilket kan orsaka att dessa organisationer och företag går i konkurs. Beträffande den praktiska implementeringen av GDPR inom mjukvaruutvecklande företag, är lite forskning som gjorts på det området. Den praktiska implementeringen av GDPR i mjukvaruutvecklande företag är också sällan diskuterat. Syftet med denna studie är att förstå; hur mjukvaruutvecklande företag implementerade GDPR i deras verksamheter; hur dem arbetar med GDPR i dagsläget; och hur dem kommer att arbeta med GDPR i framtiden. Litteraturstudien presenterar dem utmaningar under regleringen som tidigare forskning identifierat och presenterar även hur dem juridiska kraven som GDPR ställer översätts till tekniska lösningar; vilka mjukvaruutvecklande företag behöver implementera för att bli kompatibla med GDPR. Genom kvalitativ forskningsmetod går denna uppsats in i djupet på hur GDPR implementerades i mjukvaruutvecklande företag. Elva respondenter från sex olika företag av tre olika storlekar intervjuades genom semi-strukturerade intervjuer. Intervjufrågorna var baserade på faktorer som är relevanta för denna studie. Det empiriska materialet var sedan sammanställt, analyserat och jämfördes med insamlad litteratur som används i litteraturstudien. Det empiriska materialet visade att omfattningen av implementeringen av GDPR i mjukvaruutvecklande företag inte är beroende på storleken på organisationerna, men snarare beroende på vad för personlig data som bearbetas. Upptäckterna från denna studie kommer fungera som en guide till GDPR kompatibilitet för mjukvaruutvecklande företag som presenteras i slutsatsen. Denna studie har identifierat följande principer att vara essentiella för mjukvaruutvecklande företag att bli GDPR kompatibla. Mjukvaruutvecklare måste nu försäkra: förståelse över vad GDPR betyder för just deras verksamhet, skapa förståelse och medvetenhet om GDPR inom hela organisationen, genomsynlighet i förhållande till organisationens kunder och användare, att persondata lokaliseras och kartläggs i befintliga system and applikationer, att data minimeras under principerna som GDPR tillhandahåller, att persondata krypteras, att principen privacy by design & default följs under all mjukvaruutveckling, rådgivning inom GDPR, att dagliga protokoll följs och att dessa följs upp. / The General Data Protection Regulation came into force on the 25th of may 2018. The GDPR requires organizations and companies, who process personal data, to adjust and change their existing systems in order to meet the requirements that the GDPR puts forward. If organizations and companies fail to comply with the regulation, administrative fines and penalties will be enforced which can lead to bankruptcy for these organizations and companies. There is a lack of research made on the practical implementation of the GDPR into software developing companies and is rarely discussed. Thus, the purpose of this thesis is to understand how the GDPR was implemented into software developing companies; how software developing companies work with the GDPR today; and how software developing companies will work with the GDPR in the future. The literature review presents the challenges of the regulation that previous research has brought forward and how the legal requirements translates into technical solutions, which software developing companies need to implement in order to become compliant with the regulation. Through a qualitative research method, this thesis investigates the depth of how the GDPR was implemented into software developing companies. Eleven respondents representing six different organizations of three different sizes, was interviewed through semi-structured interviews. The interview questions was based on key factors brought forward in the literature review chapter; which are of relevance for this thesis. The empirical evidence was then summarized, analysed and compared to the used literature. The empirical evidence showed that the extent of the implementation of GDPR into software developing companies was not depending on the size of the organization, but rather depending on what personal data is being processed. The findings in this study will serve as a software developers guide to GDPR compliance which is presented in the conclusion. This study has identified the following principles to be essential for software developing companies in order to become GDPR compliant: understanding what the GDPR means for their business, awareness within their organization, transparency, locating personal data, data minimization, encryption of data, privacy by design & default, GDPR guidance, daily GDPR protocols and follow up on previous implementations.

Legacykod är något som är svårt för utvecklare att förhindra. Medan det finns mycket forskning kring att motarbeta legacykod och förnya legacysystem som använder utdaterade teknologier och designer, så har inte mycket fokus lagts på hur legacykod kan identifieras i sitt tidigaste skede. Hur dessutom definierar man legacykod? I denna studie så görs en litteraturstudie för att ta reda på vad för forskningsbakgrund det finns bakom legacykod i allmänhet. Därefter så utvecklas två prototyper i syfte att upptäcka mönster under utvecklingen som kan vara egenskaper till legacykod. I slutändan så utförs en enkät riktade åt mjukvaruutvecklare för att få insyn och tankar på vad legacykod betyder för dem och för att testa idéerna som togs fram från implementationerna. Den rekommenderade definitionen för legacykod är kod som inte har testats, ingen eller för lite dokumentation och är allmänt svår att förstå, vare sig med dokumentation eller utan. Observationerna från implementation av de två prototyperna bildade 7 riktlinjer som tar upp hur man kan identifiera uppväxten av legacykod. / Legacy code proves to be something difficult for developers to prevent. While much research exists to combat legacy code and renewing legacy systems that use outdated technologies and designs, not much focus has been put on how legacy code can be detected at its earliest stage. And how do you define legacy code? In this study, a literature review is done to find out the scientific background behind legacy code in general. Afterwards, two implementations of the same software are done to observe any events during the software development that can be characteristics of legacy code. In the end phase, a questionnaire-based survey is handed out to developers to get their insight and thoughts on what legacy code means to them and to test the ideas brought up from the implementations. A recommended definition for legacy code is code with no testing and little to no documentation and generally being hard to understand, whether with documentation or not. From the observations implementing the prototypes, 7 guidelines are formed to help identify and discover legacy code evolution.