Boundary Objects and their Use in Agile Systems Engineering

Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry

<i>Trace++</i>: A Traceability Approach for Agile Software Engineering

Agile methodologies have been introduced as an alternative to traditional software engineering methodologies. However, despite the advantages of using agile methodologies, the transition between traditional and agile methodologies is not an easy task. There are several problems associated with the use of agile methodologies. Examples of these problems are related to (i) lack of metrics to measure the amount of rework that occurs per sprint, (ii) interruption of a project after several iterations, (iii) changes in the requirements, (iv) lack of documentation, and (v) lack of management control. In this paper we present Trace++, a traceability technique that extends traditional traceability relationships with extra information in order to support the transition between traditional and agile software development. The use of Trace++ has been evaluated in two real projects of different software development companies to measure the benefits of using Trace++ to support agile software development

Impediments in Transitioning to Agile Time-boxing Testing Efforts

In agile framework, the system is developed in sprints. Some value-based products for the customers are created with completion of work in a sprint. There are firm dates of commencement and end in sprints, and duration of each sprint is normally equal. During a sprint, any change in scope or resources cannot be made. But sometimes it becomes difficult to follow this rule on account of the business needs. This time-boxing approach is seen responsible to cause more hindrance than propel organizations towards time-efficient development of products. This type of project demands a much more flexible time-line as compared to standard agile project management practices of ‘Sprint’ used for creating cost-effective products within time. Similar problems are faced by the organizations transitioning from traditional method to agile practices. From different sources of research it is found the transition could not be smooth in all cases and sometimes was unable to achieve the expected business growth due to various factors. A number of options and approaches are discussed for helping an organization transitioning from traditional to agile methodology but any unique and full-proof approach cannot be arrived at. Ultimately it becomes a question: can we overcome difficulty in time-boxing approach with discrepancies in testing efforts and get a systematic and tabulated solution of the problem in transitioning to agile? Through this research having limitations the answer in all respect cannot be reached. The question is left with ample scope for further research by future researchers as well

Redefining the Role of Testers in Organisational Transition to Agile Methodologies

Many challenges confront companies when they change their current software development process to an agile development methodology. Those challenges could be rather difficult but one that requires considerable attention is the integration of testing with development. This is because in heavyweight processes, as in the traditional waterfall approach, testing is a phase often conducted by testers as part of a quality assurance team towards the end of the development cycle whereas in the agile methodology testing is part of a continuous development activity with no specific “tester” role defined. In this paper we consider several options for testers when an organisation transit to agile methodology, and propose a new project mentor role for them. This role aims to utilize the knowledge that testers already have in both the business domain and the development technology together with their expertise in quality practices. This role will enhance the stature of testers as well as enable the company to effectively deploy the testers in the new environment. Motivations and benefits for this role are presented in this paper together with our plan for evaluation of this proposal

Jatkuvaan ohjelmistokehitykseen siirtyminen vakiintuneessa organisaatiossa

Software development today has rapidly developed into a significant part of business and its value creation chain. Increasingly more stakeholders within an organization are tied in with more frequent software releases. This has driven organizations to adapt to more flexible and continuous software development methods. This Master’s Thesis addresses the challenges, advantages and disadvantages associated in shifting an organization’s software development culture towards that of continuous development. The specific type of continuous development within this research considers the new software development culture of DevOps. DevOps is seen as a fundamental change in the IT world today for the transition towards continuous software development, where dedication is given to the successful collaboration between development and operations. The aim of this research is to discover the vastness of attempting to change an organizational culture for an improved and modern software development process for all stakeholders involved. Furthermore, this research attempts to provide the organization at hand with information on how and where to begin initiating the required changes. New cloud computing technologies have enabled development teams to become less dependent on companies’ traditional IT departments. The research is conducted via literature review and the data collected through interviews with employees of the organization attempting to shift towards continuous development. Further information is gathered through three case studies of other companies that have successfully undergone a transition towards continuous development and DevOps.Tänä päivänä ohjelmistokehityksestä on nopeasti muodostunut merkittävä osa liiketoimintaa ja sen lisäarvon tuottamista. Yhtiöiden sisällä yhä useampi sidosryhmä on osallisena yhä useammin toistuvissa ohjelmistojulkaisuissa. Tästä johtuen yritykset ovat joutuneet sopeutumaan joustaviin ja jatkuviin tapoihin kehittää ohjelmistoa. Tämä diplomityö tutkii yhtiön jatkuvaan ohjelmistokehitykseen siirtymisen haasteita, hyötyjä ja haittoja. Jatkuvan ohjelmistokehityksen tyyppi, jota tässä työssä tutkitaan, on nimeltään DevOps. DevOps:ia pidetään keskeisenä muutoksena nykypäivän IT-alalla jatkuvaan kehitykseen siirtymisessä. Sen pääpiirteeksi koetaan sulava yhteistyö kehityksen ja ylläpidon välillä. Tämän tutkimuksen tavoite on selvittää yrityksen ohjelmistokehityksen muuttamisen laajuuden ottamalla samalla sen kaikki sidosryhmät huomioon. Lisäksi tämä tutkimus pyrkii tuottamaan yritykselle, jolle tutkimus tehdään, lisätietoa siitä miten tarvittavat muutokset voidaan käynnistää ja toteuttaa. Uudet pilvipalvelut ovat lisänneet kehityksen autonomisia työskentelytapoja ja vähentäneet heidän riippuvuuksia perinteisen IT-osaston toiminnollisuuksista. Tutkimus toteutetaan kirjallisuuskatsauksen sekä yrityksen eri sidosryhmien haastattelujen kautta. Lisätietoa kerätään esimerkkien avulla, joissa tutkitaan kolmen eri yrityksen menestyksekkäitä siirtymisiä jatkuvan ohjelmistokehityksen pariin