High-Speed Software Development Practices: What Works, What Doesn't

Increasingly short software development cycles have forced software companies and engineers to strike a balance between informal development--in Internet-time--and more traditional agile and plan-driven methods. The authors review six common practices and how they are blended to maximize time-sensitive development.     

Helping small companies assess software processes

A first step toward process improvement is identifying the strengths and weaknesses of an organization's software processes to determine effective improvement actions. An assessment can help an organization examine its processes against a reference model to determine the processes' capability or the organization's maturity, to meet quality, cost, and schedule goals, but small companies have difficulty running them. MARES, a set of guidelines for conducting 15504-conformant software process assessment focuses on small companies.     

The effect of moving from a plan-driven to an incremental software development approach with agile practices

So far, only few in-depth studies focused on the direct comparison of process models in general, and between plan-driven and incremental/agile approaches in particular. That is, it is not made explicit what the effect is of moving from one model to another model. Furthermore, there is limited evidence on advantages and issues encountered in agile software development, this is specifically true in the context of large-scale development. The objective of the paper is to investigate how the perception of bottlenecks, unnecessary work, and rework (from hereon referred to as issues) changes when migrating from a plan-driven to an incremental software development approach with agile practices (flexible product backlog, face-to-face interaction, and frequent integration), and how commonly perceived these practices are across different systems and development roles. The context in which the objective should be achieved is large-scale development with a market-driven focus. The selection of the context was based on the observation in related work that mostly small software development projects were investigated and that the investigation was focused on one agile model (eXtreme programming). A case study was conducted at a development site of Ericsson AB, located in Sweden in the end of 2007. In total 33 interviews were conducted in order to investigate the perceived change when migrating from plan-driven to incremental and agile software development, the interviews being the primary source of evidence. For triangulation purposes measurements collected by Ericsson were considered, the measurements relating to unnecessary work (amount of discarded requirements) and rework (data on testing efficiency and maintenance effort). Triangulation in this context means that the measurements were used to confirm the perceived changes with an additional data source. In total 64 issues were identified, 24 being of general nature and the remaining 40 being local and therefore unique to individual’s opinions or a specific system. The most common ones were documented and analyzed in detail. The commonality refers to how many persons in different roles and across the systems studied have mentioned the issues for each of the process models. The majority of the most common issues relates to plan-driven development. We also identified common issues remaining for agile after the migration, which were related to testing lead-time, test coverage, software release, and coordination overhead. Improvements were identified as many issues commonly raised for the plan-driven approach were not raised anymore for the incremental and agile approach. It is concluded that the recent introduction (start in 2005 with the study being conducted in the end of 2007) of incremental and agile practices brings added values in comparison to the plan-driven approach, which is evident from the absence of critical issues that are encountered in plan-driven development.     

Introducing an agile process to an organization [software development]

The transition from a plan-driven to an agile software development process affects not only the development team members, but also other teams, departments, and management. Any new process will likely attract developers excited to try it while repelling those opposed to change. Thus, how an agile process is introduced into an organization significantly affects its ultimate success.     

Software architecture-centric methods and agile development

The agile software development paradigm and plan-driven approaches each have their strengths and shortcomings. The former emphasizes rapid, flexible development, while the latter emphasizes project and process infrastructure. Many practitioners, particularly of agile methods, tend-to view software architecture in light of the plan-driven side of the spectrum. They think that architecture-centric methods are too much work, equating them with high-ceremony processes emphasizing document production. But many elements make up a successful development approach, including process, product, technology, people, and tools. Software architecture is part of product quality and isn't tied to a particular process, technology, culture, or tool. This article explores the relationship and synergies between architecture-centric design and analysis methods and the extreme programming framework. We chose to focus on XP because it's one of the most mature and best-known agile practices.     

Assessment methodology for software process improvement in small organizations

ContextDiagnosing processes in a small company requires process assessment practices which give qualitative and quantitative results; these should offer an overall view of the process capability. The purpose is to obtain relevant information about the running of processes, for use in their control and improvement. However, small organizations have some problems in running process assessment, due to their specific characteristics and limitations.ObjectiveThis paper presents a methodology for assessing software processes which assist the activity of software process diagnosis in small organizations. There is an attempt to address issues such as the fact that: (i) process assessment is expensive and typically requires major company resources and (ii) many light assessment methods do not provide information that is detailed enough for diagnosing and improving processes.MethodTo achieve all this, the METvalCOMPETISOFT assessment methodology was developed. This methodology: (i) incorporates the strategy of internal assessments known as rapid assessment, meaning that these assessments do not take up too much time or use an excessive quantity of resources, nor are they too rigorous and (ii) meets all the requirements described in the literature for an assessment proposal which is customized to the typical features of small companies.ResultsThis paper also describes the experience of the application of this methodology in eight small software organizations that took part in the COMPETISOFT project. The results obtained show that this approach allows us to obtain reliable information about the strengths and weaknesses of software processes, along with information to companies on opportunities for improvement.ConclusionThe assessment methodology proposed sets out the elements needed to assist with diagnosing the process in small organizations step-by-step while seeking to make its application economically feasible in terms of resources and time. From the initial application it may be seen that this assessment methodology can be useful, practical and suitable for diagnosing processes in this type of organizations.     

Managing software process measurement: A metamodel-based approach

The evaluation of software processes is nowadays a very important issue due to the growing interest of software companies in the improvement of the productivity and quality of delivered products. Software measurement plays a fundamental role here. Given the great diversity of entities which are candidates for measurement in the software process improvement context (process models, projects, resources, products) this measurement must be performed in a consistent and integrated way. This will facilitate the making of decisions in process improvement. In this paper, a proposal for the integrated management of the software measurement is presented. The goal is to provide companies with a generic and flexible environment for software measurement which facilitates and establishes the basis for a common and effective measurement process and which is not restricted to only one kind of software entity or to a single quality or evaluation model. In order to achieve this, the proposal adopts the Model Driven Engineering philosophy and provides: a metamodel for the definition of software measurement models; a flexible method to measure any kind of software entity represented by its corresponding metamodel and GenMETRIC, which is the software tool that supports the framework.     

Debugging‐workflow‐aware software reliability growth analysis

Software reliability growth models support the prediction/assessment of product quality, release time, and testing/debugging cost. Several software reliability growth model extensions take into account the bug correction process. However, their estimates may be significantly inaccurate when debugging fails to fully fit modelling assumptions. This paper proposes debugging‐workflow‐aware software reliability growth method (DWA‐SRGM), a method for reliability growth analysis leveraging the debugging data usually managed by companies in bug tracking systems. On the basis of a characterization of the debugging workflow within the software project under consideration (in terms of bug features and treatment phases), DWA‐SRGM pinpoints the factors impacting the estimates and to spot bottlenecks, thus supporting process improvement decisions. Two industrial case studies are presented, a customer relationship management system and an enterprise resource planning system, whose defects span a period of about 17 and 13 months, respectively. DWA‐SRGM revealed effective to obtain more realistic estimates and to capitalize on the awareness of critical factors for improving debugging.     

Get ready for agile methods, with care

Although many of their advocates consider the agile and plan-driven software development methods polar opposites, synthesizing the two can provide developers with a comprehensive spectrum of tools and options. Real-world examples argue for and against agile methods. Responding to change has been cited as the critical technical success factor in the Internet browser battle between Microsoft and Netscape. But overresponding to change has been cited as the source of many software disasters, such as the $3 billion overrun of the US Federal Aviation Administration's Advanced Automation System for national air traffic control. The author believes that both agile and plan-driven approaches have a responsible center and overinterpreting radical fringes. Agile and plan-driven methods both form part of the planning spectrum. Thus, while each approach has a home ground within which it performs very well, and much better than the other, a combined approach is feasible and preferable in some circumstances     

Bootstrap: fine-tuning process assessment

Bootstrap was a project done as part of the European Strategic Program for Research in Information Technology. Its goal was to develop a method for software-process assessment, quantitative measurement, and improvement. In executing that goal, Bootstrap enhanced and refined the Software Engineering Institute's process-assessment method and adapted it to the needs of the European software industry-including nondefense sectors like banking, insurance, and administration. This adaptation provided a method that could be applied to a variety of software-producing units, small to medium software companies or departments that produce software within a large company. Although the Bootstrap project completed in 1993, its attribute-based method for assessing process maturity continues to evolve. The authors describe the elements of the method, how it can be used to determine readiness for ISO 9001 certification, and how it was applied in two instances to substantially improve processes     

Using Scrum to guide the execution of software process improvement in small organizations

For software process improvement - SPI - there are few small organizations using models that guide the management and deployment of their improvement initiatives. This is largely because a lot of these models do not consider the special characteristics of small businesses, nor the appropriate strategies for deploying an SPI initiative in this type of organization. It should also be noted that the models which direct improvement implementation for small settings do not present an explicit process with which to organize and guide the internal work of the employees involved in the implementation of the improvement opportunities. In this paper we propose a lightweight process, which takes into account appropriate strategies for this type of organization. Our proposal, known as a “Lightweight process to incorporate improvements”, uses the philosophy of the Scrum agile method, aiming to give detailed guidelines for supporting the management and performance of the incorporation of improvement opportunities within processes and their putting into practice in small companies. We have applied the proposed process in two small companies by means of the case study research method, and from the initial results, we have observed that it is indeed suitable for small businesses.     

软件过程集成框架的实践与思考

软件实践表明产品开发的过程和产品品质有产非常密切的联系,因此很多软件企业都把提高软件开发过程作为提高软件品质的重要手段。现有的过程模型中CMM/CMMI是很多企业采用的一个框架,CMMI模型非常复杂(描述性文档就有超过1000页),因此很需要有一种软件来支持软件过程的改进。本文给出了一个软件过程改进集成框架SPIF,较为详细地叙述了SPIF中项目计划与进度监控的实现。SPIF对CMM/CMMI有着良好的支持,经过几个软件公司的实践表明SPIF实现了软件过程可视化、管理效率化,可以对软件企业实施CMM/CMMI过程改进有着很好的促进作用。     

Operational release planning in large-scale Scrum with multiple stakeholders – A longitudinal case study at F-Secure Corporation

ContextThe analysis and selection of requirements are important parts of any release planning process. Previous studies on release planning have focused on plan-driven optimization models. Unfortunately, solving the release planning problem mechanistically is difficult in an agile development context.ObjectiveWe describe how a release planning method was employed in two case projects in F-Secure, a large Finnish software company. We identify the benefits which the projects gained from the method, and analyze challenges in the cases and improvements made to the method during the case projects.MethodWe observed five release planning events and four retrospectives and we conducted surveys in the first two events. We conducted six post-project interviews. We conjoined the observation notes, survey results and interviews and analyzed them qualitatively and quantitatively.ResultsThe focal point of the method was release planning events where the whole project organization gathered to plan the next release. The planning was conducted by the development teams in close collaboration with each other and with the other stakeholders. We identified ten benefits which included improved communication, transparency, dependency management and decision making. We identified nine challenges which included the lacking preparation and prioritization of requirements, unrealistic schedules, insufficient architectural planning and lacking agile mindset. The biggest improvements to the method were the introduction of frequent status checks and a big visible planning status board.ConclusionThe release planning method ameliorated many difficult characteristics of the release planning problem but its efficiency was negatively affected by the performing organization that was in transition from a plan-driven to an agile development mindset. Even in this case the benefits clearly outweighed the challenges and the method enabled the early identification of the issues in the project.     

Software Process Improvement Problems in Twelve Software Companies: An Empirical Analysis

In this paper we discuss our study of the problems 12 software companies experienced in software development. In total we present qualitative data collected from 45 focus groups that involved over 200 software staff. We look at how different practitioner groups respond to software process improvement problems. We show our classification and analysis of this data using correspondence analysis. Correspondence analysis is a graphical data representation method new to software development research. The aim of the work we present is to develop a more holistic understanding of the problems practitioners are experiencing in their attempts to improve their software processes. Our main finding is that there is an association between a company's capability maturity and patterns of reported problems. Organizational problems are more associated with high maturity companies than with low maturity companies. Low maturity companies are closely linked to problems relating directly to projects such as documentation, timescales, tools and technology. Our findings also confirm differences in practitioner group problems. Senior managers cite problems with goals, culture and politics. Project managers are concerned with timescales, change management, budgets and estimates. Developers are experiencing problems with requirements, testing, documentation, communication, tools and technology. These associations are displayed graphically through correspondence analysis maps.     

敏捷软件开发与计划驱动开发的概述比较

人们在设想、确定以及创建软件时,身边的环境不断在变更.敏捷是为了在动荡的业务环境中获益而创造变革和响应变革的能力.极限编程是最著名的敏捷软件开发方法.传统的开发侧重于计划和架构,计划驱动开发关注的是软件的质量和过程的可预见性.计划驱动开发最佳范例是能力成熟度模型.两种表面上有不同观点的方法在争夺着软件开发的主导权,对敏捷软件开发与计划驱动开发进行了概述,并就特征、擅长领域和关键要素等进行比较.     

成功实施软件过程改进的三个要素

ISO9000、CMM和CMMI在国内软件企业已经实施了相当一段时间,目前实施后的软件公司CMM/CMMI等级都上去了,可是效果却各不相同.本文从软件过程改进整个过程来探讨成功实施软件过程改进要注意的方方面面,以及如何才能够让软件过程改进取得最佳效果.     

Process improvement for small firms: An evaluation of the RAPID assessment-based method

With increasing interest by the software development community in software process improvement (SPI), it is vital that SPI programs are evaluated and the reports of lessons learned disseminated. This paper presents an evaluation of a program in which low-rigour, one-day SPI assessments were offered at no cost to 22 small Australian software development firms. The assessment model was based on ISO/IEC 15504 (SPICE). About 12 months after the assessment, the firms were contacted to arrange a follow-up meeting to determine the extent to which they had implemented the recommendations from the assessment.Comparison of the process capability levels at the time of assessment and the follow-up meetings revealed that the process improvement program was effective in improving the process capability of 15 of these small software development firms. Analysis of the assessment and follow-up reports explored important issues relating to SPI: elapsed time from assessment to follow-up meeting, the need for mentoring, the readiness of firms for SPI, the role of the owner/manager, the advice provided by the assessors, and the need to record costs and benefits. Based on an analysis of the program and its outcomes, firms are warned not to undertake SPI if their operation is likely to be disrupted by events internal to the firm or in the external environment. Firms are urged to draw on the expertise of assessors and consultants as mentors, and to ensure the action plan from the assessment is feasible in terms of the timeframe for evaluation. The RAPID method can be improved by fostering a closer relationship between the assessor and the firm sponsor; by making more extensive use of feedback questionnaires after the assessment and follow-up meeting; by facilitating the collection and reporting of cost benefit metrics; and by providing more detailed guidance for the follow-up meeting.As well as providing an evaluation of the assessment model and method, the outcomes from this research have the potential to better equip practitioners and consultants to undertake software process improvement, hence increasing the success of small software development firms in domestic and global markets.     

TAPISTRY—A Software Process Improvement Approach Tailored for Small Enterprises

TAPISTRY is a tutored process improvement approach tailored for small enterprises. The approach was developed, used and validated in an ongoing ESSI Esprit project (No 24238), called “TAPISTRY.” The TAPISTRY project adopted a downscaled assessment model of the BOOTSTRAP assessment methodology, called BootCheck, and developed a workshop-based assessment and improvement method, to form together a process improvement approach for small-to-medium-sized enterprises. In TAPISTRY workshops the participants are tutored in self-assessment and improvement planning by software process improvement experts. The resulting TAPISTRY approach was validated through the experiments performed during the TAPISTRY project. This revised version was published online in August 2006 with corrections to the Cover Date.     

When agile meets the enterprise

ContextWhile renowned agile methods like XP and Scrum were initially intended for projects with small teams, traditional enterprise environments, i.e. environments where plan-driven development is prevalent, have also become attracted by the promises of a faster time to market through agility. Agile software development methods emphasize lightweight software development. Projects within enterprise environments, however, are typically confronted with a large and complex IT landscape, where mission-critical information is at play whose criticality requires prudence regarding design and development. In many an organization, both approaches are used simultaneously.ObjectiveFind out which challenges the co-existence of agile methods and plan-driven development brings, and how organizations deal with those challenges.MethodWe present a grounded theory of the challenges of using agile methods in traditional enterprise environments, based on a Grounded Theory research involving 21 agile practitioners from two large enterprise organizations in the Netherlands.ResultsWe organized the challenges under two factors: Increased landscape complexity and Lack of business involvement. For both factors, we identify successful mitigation strategies. These mitigation strategies concern the communication between the agile and traditional part of the organization, and the timing of that communication.ConclusionAgile practices can coexist with plan-driven development. One should, however, keep in mind the context and take actions to mitigate the challenges incurred.