International Telemetering Conference Proceedings / October 25-28, 1999 / Riviera Hotel and Convention Center, Las Vegas, Nevada / Many view quality and productivity as competing concepts. After all, doesn’t high software quality come at a high cost? Doesn’t it mean that a large amount of "extra stuff" needs to be done during the software development cycle? And, doesn’t that mean that software productivity takes a back seat to (and a major hit from) quality efforts? This paper will explore these issues. This paper provides some preliminary data that supports how a disciplined software engineering process can (and has) resulted in high quality software while actually increasing productivity. Data has been gathered on organizations that have a disciplined, quality-oriented software engineering process in place. That data shows that quality and productivity can (and do) coexist. The data will be discussed along with an explanation of how these results can be achieved.

Software systems are getting larger and more complex, while the requirements are becoming vaguer and more rapidly changing. These trends make current software development more and more likely a team work. To integrate multiple developers into a coherent structured management process and make team software development a positive-sum game for both higher productivity and better quality, many team soft ware development methodologies have been proposed and practised. An emerging methodology is collaborative programming, which allows a group of programmers to work together on the same source code for design, implementation of individual components, and integration of individual components. Compared with other team software methodologies that only address needs in some phases or situations, collaborative programming is more adaptive to the variety of different phases or situations in a team software development process. A core technical component in collaborative programming is collaborative editing, which allows a group of programmers to view and edit the same source code. To support different phases or situations in an Internet-based collaborative programming process, collaborative editing must meet the requirements of supporting unconstrained, responsive, real-time collaborative editing; unconstrained, syncretic, non-real-time collaborative editing; and smooth, flexible switching between real-time and non-real-time collaborative editing. This thesis research contributes several novel techniques to address these requirements, and an Internet-based collaborative programming environment to integrate those techniques. These research contributions have advanced state-of-the-art technologies on col laborative editing for supporting Internet-based collaborative programming. First, we contribute a collaborative highlighting gestural communication technique for unconstrained, responsive, real-time collaborative editing. This technique is particularly effective in improving the quality of real-time interaction on text-based source code documents. The contribution to the operational transformation technology is the extension of the technology to support group awareness. It includes a package of operational transformation functions and transformation control algorithms for consistency maintenance in collaborative highlighting, and a flexible undo solution that has the capability of undoing any highlighting operation at any time. Second, we contribute a flexible operation-based merging technique for unconstrained, syncretic, non-real-time collaborative editing, which is efficient and has the capability of textually integrating all changes, and automatically detecting and resolving syntactic conflicts according to application-dependent user-specified policies. The contribution to the operational transformation technology is the extension of the technology to support unconstrained, syncretic, non-real-time collaborative editing. Its includes a log compression algorithm, a textual merging algorithm, and a syntactic merging algorithm. Moreover, we contribute a flexible notification technique to support flexible collaborative editing: unconstrained, responsive, real-time collaborative editing; uncon strained, syncretic, non-real-time collaborative editing; and smooth, flexible switching between them. The contribution to the operational transformation technology is the extension of the technology to support flexible collaborative editing. It includes a new transformation control algorithm that has a linear time complexity, two notification algorithms that support propagation and acceptance of any notifications at any time, and a notification propagation protocol that is efficient for both real-time and non-real-time collaborative editing.

Siekiant pagerinti kuriamų programinių produktų kokybę, IT įmonės taiko skirtingus proceso modelius. Populiariausi iš jų gebėjimo brandos modelis (CMMI) ir ISO 15504. Šie modeliai nusako, kas (kokie procesai) turi būti vykdoma brandžioje organizacijoje, tačiau neatsako į klausimą: kaip tai turi būti daroma. Komandinis programų kūrimo procesas (TSP) pateikia strategiją, kartu su procedūrų rinkiniu, skirtą disciplinuotų programų kūrimo metodų naudojimui komandos lygyje. Pagrindinė su TSP susijusi problema – oficialios dokumentacijos trūkumas. Pirmas darbo tikslas yra rekonstruoti TSP metodiką. Antras tikslas yra sukurti TSP diegimo metodiką. Pirmoje darbo dalyje yra aprašyta bendra TSP struktūra, TSP ryšys su asmeniniu programų kūrimo procesu (PSP) ir brandos modeliu CMMI. Antroje dalyje yra pateiktas rekonstruotas TSP modelis ir TSP diegimo metodika apibrėžtam projekto komandos tipui. / IT organizations use different models to guide their software process improvement efforts. The most popular are the Capability Maturity Model Integration for Software (CMMI-SW) and ISO 15504. Still these organizations often struggle with implementation details. Both the CMMI-SW and ISO 15504 describe what an organization at a high level of process maturity should be doing, but do not says how it should be implemented. The Team Software Process (TSP) provides a framework as well as a set of processes, procedures, guidelines, and tools for project teams to use in the mature software development process. The main problem of the Team Software Process is the lack of official documentation. So the first goal of this master thesis is to reconstruct TSP methodology. The second goal is to produce TSP implementation guide. This master thesis contains the main structure of the TSP, it’s relation with the Personal Software Process (PSP) ant the Capability Maturity Model (CMMI), reconstructed TSP model and TSP implementation guide for defined project team type.

This report evaluates the team-structure of three software maintenance teams in order to decide their level of featureness (a term that defines to what extent a team has the quality (the set of characteristics) of being a feature team). Simulations of changes that are expressed as beneficial in an agile environment and that could increase the teams‘ level of featureness within the team structure are performed. The results show that each team‘s level of featureness is affected differently by each change. Partly, this underlines the importance of understanding the current team-structure before implementing changes that aim to increase the level of featureness. And secondly, within the scope of the study, the change where a user expert is declared a team member is concluded as the change that increases the teams‘ level of featureness the most. Based on the results the report also concludes that it is essential to implement changes that affect different, which in combination can increase the level of featureness.

<p>In today’s society, serious organizations need protection against both internal and external attacks. There are many different technologies available that organizations can incorporate into their organization in order to enhance security for their networking applications. Unfortunately, security is way to often considered as an afterthought and therefore implemented as an external part of the applications. This is usually performed by introducing general security models and technologies.</p><p>However, an already developed, well structured and considered security approach – with proper implementation of security services and mechanisms – different security models can be used to apply security</p><p>within the security perimeter of an organization. It can range from built into the application to the edge of a private network, e.g. an appliance. No matter the choice, the involved people must possess security expertise to deploy the proposed security models in this paper, that have the soul purpose to secure applications.</p><p>By using the Recommendation X.800 as a comparison framework, the proposed models will be analyzed in detail and evaluated of how they provide the security services concerned in X.800. By reasoning about what security services that ought to be implemented in order to prevent or detect diverse security attacks, the organization needs to carry out a security plan and have a common understanding of the defined security policies.</p><p>An interesting finding during our work was that, using a methodology that leads to low KLOC-values results in high security, though low KLOC-values and high security go hand-in-hand.</p>

In today’s society, serious organizations need protection against both internal and external attacks. There are many different technologies available that organizations can incorporate into their organization in order to enhance security for their networking applications. Unfortunately, security is way to often considered as an afterthought and therefore implemented as an external part of the applications. This is usually performed by introducing general security models and technologies. However, an already developed, well structured and considered security approach – with proper implementation of security services and mechanisms – different security models can be used to apply security within the security perimeter of an organization. It can range from built into the application to the edge of a private network, e.g. an appliance. No matter the choice, the involved people must possess security expertise to deploy the proposed security models in this paper, that have the soul purpose to secure applications. By using the Recommendation X.800 as a comparison framework, the proposed models will be analyzed in detail and evaluated of how they provide the security services concerned in X.800. By reasoning about what security services that ought to be implemented in order to prevent or detect diverse security attacks, the organization needs to carry out a security plan and have a common understanding of the defined security policies. An interesting finding during our work was that, using a methodology that leads to low KLOC-values results in high security, though low KLOC-values and high security go hand-in-hand.

Användandet av agila metodiker har ökat under de senaste decennierna. Detta har lett till en uppskalning av agila metodiker då även stora organisationer vill uppnå fördelarna som kommer med det agila arbetssättet. Att skala upp agila metodiker, och använda dessa i storskaligt agila miljöer (författarnas koncept skagila miljöer, som återfinns i sektionen ’Begreppet ’skagil’'), kommer dock med flera nya organisatoriska utmaningar. En utmaning, som omnämns i både litteratur och i arbetets empiriska undersökning på företaget Avanza, är inter-teamsamordning i skagila miljöer. Avanza har identifierat problemen med beroenden mellan team i skagila mjukvaruutvecklingsprojekt. För att möta problemet med beroenden initierades det här arbetet med syftet att, utifrån Avanzas nuvarande projekt design, undersöka hur teamöverskridande arbete kan samordnas för att möta beroenden i projektprocessen. För att uppnå syftet genomfördes en fallstudie på Avanza innehållande intervjuer med tolv respondenter och observation av interna dokument. Den empiriska undersökningen bekräftade ursprungsproblematiken gällande inter-teamsamordning och bidrog även med information om företagets nuvarande projektdesign. Resultatet visade att projektorganisationen verkar som en hybrid organisation med starka, agila inslag. Dock visade sig Avanza uppleva sin projektdesignen som helt agil. Vidare ansågs projektets beroenden bidra till agilt slöseri, vilket påverkar både produktivitet och effektivitet negativt i mjukvaruutvecklingsprocessen. Fyra huvudområden av agilt slöseri identifierades vilka var väntan, rörelse, defekter och tilläggsprocesser. Genom att klustra ihop liknande slöseri framtogs tre problemområden kopplade till Avanzas projektprocess, nämligen ’viss frånvaro av proaktivt angreppssätt och planering’, ’viss frånvaro av forum för hantering av inter-teamberoenden’ och ’skillnader i implementering av agila metodiker och projektprioritering bland teamen’. För att möta problemen fastställdes sex åtgärder, nämligen implementering av en mer proaktiv projektledarroll, anammning av hybridkulturen, skapande av rollspecifika team, implementering av arrangerade forum för teamsynkronisering, kodifiering och utveckling av befintliga mekanismer och samordning samt skapande av ett gemensamt förhållningssätt till agila principer i projekt. Arbetets slutsatser är till viss del generaliserbara och skulle kunna adopteras av andra företag eller projektorganisationer som har liknande problem och projektdesign som Avanza. Dock krävs en viss ansträngning för att först identifiera vilken projektdesign intressentföretag har samt att identifiera projektrelaterat slöseri. Avanza är även verksamma inom tech-branschen där projektorganisationen verkar kring mjukvaruutveckling. Därför kan det antas att slutsatserna mer sannolikt, passar andra organisationer som jobbar med mjukvaruutveckling. / The usage of agile methodologies has rapidly increased over the last decades. This has led to an upscaling of agile methods since larger organizations want to gain the benefits of the agile way of working. However, this has not come without issues, and using agile at scale (authors’ concept scagile, in upcoming section ’Begreppet ’skagil”) has introduced new organizational challenges. One challenge that is mentioned both in literature and in the empirical findings at the case company, Avanza, is inter-team coordination in scagile environments. Today Avanza is struggling with dependencies between teams in scaled agile software projects. To address this issue this study was initiated with the purpose to, based on Avanza’s current project design, investigate how cross-team collaboration could be coordinated to face and overcome dependencies in the project process. To accomplish this a case study, containing interviews with twelve respondents and observation of internal documents, was made. The empirical findings confirmed the original issues related to inter-team coordination and also provided valuable information about the company’s project design. Regarding the project design the findings showed that the project organization is a hybrid organization with strong agile influences. However, the alleged perception of the project design was a fully agile organization. Further, the dependencies in the projects seem to cause agile waste, which has a negative influence on productivity and efficiancy in software projects. Four main areas of agile waste were detected, namely waiting, motion, defects and extra processes. By clustering similar waste, three main problem areas were detected, viz ’a certain absence of a proactive approach and planning’, ‘a certain absence of forums for handling inter-team dependencies’, and ‘differences between teams regarding the implementation and usage of agile principles, and project prioritization’. To face these issues, six measures were determined, namely implementation of a more proactive project management approach, embracing the hybrid culture, creating role specific teams, arranging forums for team synchronization, codifying and developing the current coordination mechanisms and deciding on a shared approach for project methodologies. The findings of this study is to some extent generalizable and could be adopted by other companies, or project organizations, that are struggling with the same problem areas and have the same project design as Avanza. However, some effort is required to first determine current project design and to identify project related waste. Further, the client company is operative in the fin-tech industry where the project organization orbits around software development. Therefore it can be assumed that the findings are more likely to fit another software organization.