Adopting key lessons from agile manufacturing to agile software product development—A comparative study

Nowadays many new product development (NPD) software projects employ agile methodologies. Their basic premise is that a small, colocated team working closely together with the business customer can produce high‐value, high‐quality software efficiently with rapid iterations and frequent feedback. However, in large NPD organizations developing complex products those basic assumptions are not necessarily sufficient, and a more comprehensive view of agility is needed. On the basis of industrial experiences, this article presents a number of pragmatic suggestions about how and when agility could be utilized in large‐scale (embedded) software product development. We propose a framework for understanding the multidimensional nature of agility in such environments for successful software process improvement (SPI), and highlight certain practical considerations. Some industrial case examples are illustrated. We conclude that in large‐scale NPD organizations a holistic systemwide view is needed in order to really be able to take advantage of and improve software development agility. Copyright © 2007 John Wiley & Sons, Ltd.

Agile practices have recently gained popularity among large number of companies as a mechanism for reducing cost and increasing ability to handle change in dynamic market conditions. Based on the principles of the Agile manifesto [1, 2], researchers and practitioners have proposed several software development approaches such as Extreme Programming, Scrum and Feature-Driven Development. These and other agile approaches have had significant impact on industrial software development practices. However, there is also a significant concern and perplexity about the role and importance of the issues related to a system’s software architecture, which is considered one of the most important initial design artefacts. It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. Many practitioners of Agile approaches appear to view software architecture in the context of the plan-driven development paradigm [3]. For them, upfront design and evaluation of software architecture requires too much work, which may have very little value to the customers of a system. Hence, they perceive architectural work as part of high ceremony processes, which usually require large amount of documentation. We maintain that these two seemingly opposing views to software engineering can be integrated but it requires that experts from both fields work together to overcome evident challenges in bridging these two paradigms together. Indeed, software architecture researchers and practitioners appear to believe that sound architectural practices cannot be followed using Agile approaches. However, these two extreme views of Agile and architecture appear to neglect that many agile experts emphasises the importance of paying attention to good design and architecture early in the development process [4, 5]. Recently, there is growing recognition of the importance of paying more attention to architectural aspects in agile approaches [3, 6, 7]. We argue that there is a vital need for devising a research agenda for identifying and dealing with architecture-centric challenges in agile software development. Such research agenda should make it possible to guide the future research on integrating architecture-centric methods in agile approaches and give advice to the software industry on dealing with architecture related challenges. Some of the questions to stimulate discussion in the workshop are: What is the role of software architecture in Agile software development? What are the key architecture-centric challenges and potential solutions in Agile software development projects? What is the strength of the evidence that attention to architectural issues can be counterproductive in Agile development or vice versa? What are the prerequisites for integrating Architecture-Centric methods in agile development and potential implications of such integration?

Currently, a number of specific international standards are made available within software engineering discipline to support Software Process Improvement (SPI) such as Capability Maturity Model Integration (CMMI), ISO/IEC 15504, ISO/IEC 90003 and ISO/IEC 12207. Some suggest on integrating and harmonizing these standards to reduce risks and enhance practicality, however there is no official initiative being made to date to implement this reality. Integrated Software Process Assessment (iSPA) is a proposed initiative being developed on the premise to harmonize and integrate a number of existing software process assessments and practices including improvement standards, models and benchmarks. A survey was conducted on thirty software practitioners to measure the strength and weaknesses of their organization's current software process. The survey also attempts to evaluate the acceptance and needs of implementation of a customized SPI model for Malaysia's SME.

A practitioner’s guide to light weight software process assessment and improvement planning

Agile 방법론은 시간적 제약하에서도 효율적인 개발 프로세스로 빠르게 제품을 완성할 수 있는 방법으로 알려져 있다. 하지만 scrum, XP, DSDM 등과 같은 여타 Agile 방법들처럼 기능주도개발 (FDD) Agile 방법도 보안요소의 불가용성으로 인해 비판을 받고 있다. 이러한 이슈를 보다 자세히 살펴보기 위해 본 연구는 2001년부터 2012년사이에 나타난 연구들에 대한 체계적인 문헌연구를 수행하였다. 본 연구 결과, 현재 FDD 방법은 안전한 소프트웨어 개발을 부분적으로 지원하고 있는 것으로 나타났다. 하지만 안전한 소프트웨어 사용에 관한 상세한 정보가 문헌에 거의 나타나고 있지 않은 것으로 보아 이 분야에 대한 연구 노력은 거의 없어 보인다. 따라서 현재의 5단계 FDD 방법은 안전한 소프트웨어 개발에 충분하지 않음을 알 수 있고 결국, 본 연구는 FDD 방법에서 보안에 기반을 둔 새로운 수행 단계와 프랙티스가 제안될 필요가 있음을 보여준다. Agile methodologies have gained recognition as efficient development processes through their quick delivery of software, even under time constraints. However, like other agile methods such as Scrum, Extreme Programming (XP) and The Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD) has been criticized due to the unavailability of security elements in its twelve practices. In order to examine this matter more closely, we conducted a systematic literature review (SLR) and studied literature for the years 2001-2012. Our findings highlight that, in its current form, the FDD model partially supports the development of secure software. However, there is little research on this topic, as detailed information about the usage of secure software is rarely published. Thus, we have been able to conclude that the existing five phases of FDD have not been enough to develop secure software until recently. For this reason, security-based phase and practices in FDD need to be proposed.

Companies in either manufacturing or servicing have to be restructured or re-organized in order to overcome with challenges of the 21st century in which customers are not only satisfied but also delighted. In this competitive environment, organizations should use a flexible, adaptive and responsive paradigm that can be entitled by a unique term: agile manufacturing (AM). An AM system is able to develop a variety of product at low cost and in a short time period. For this, it has some of useful enabling technologies and physical tools. Among these, concurrent engineering (CE) is a systematic approach to the integrated, concurrent design of product and their related processes, including manufacture and support. It is then a useful and beneficial approach to reduce the development time and manufacturing cost, while simultaneously improving the quality of a product in order to better respond to the customer expectations. The aim of this study is to underline the synergistic impact of new product development (NPD) and CE, (which can be called CNPD), and to survey their methods and tools in association with the AM.

The emergence of agile methods and practices has not only changed the development processes but might also have affected how companies conduct software process improvement (SPI). Through a set of complementary studies, we aim to understand how SPI has changed in times of agile software development. Specifically, we aim (a) to identify and characterize the set of publications that connect elements of agility to SPI, (b) to explore to which extent agile methods/practices have been used in the context of SPI, and (c) to understand whether the topics addressed in the literature are relevant and useful for industry professionals. To study these questions, we conducted an in‐depth analysis of the literature identified in a previous mapping study, an interview study, and an analysis of the responses given by industry professionals to SPI‐related questions stemming from an independently conducted survey study. Regarding the first question, we identified 55 publications that focus on both SPI and agility of which 48 present and discuss how agile methods/practices are used to steer SPI initiatives. Regarding the second question, we found that the two most frequently mentioned agile methods in the context of SPI are Scrum and Extreme Programming (XP), while the most frequently mentioned agile practices are integrate often, test‐first, daily meeting, pair programming, retrospective, on‐site customer, and product backlog. Regarding the third question, we found that a majority of the interviewed and surveyed industry professionals see SPI as a continuous activity. They agree with the agile SPI literature that agile methods/practices play an important role in SPI activities but that the importance given to specific agile methods/practices does not always coincide with the frequency with which these methods/practices are mentioned in the literature.

In this chapter, we describe the case study of a real-time database system for a specific kind of operational data generated by an agile manufacturing system. The term agile manufacturing refers to a manufacturing system that can fabricate various products simultaneously without long downtimes for retooling. The agile manufacturing increases competitiveness of companies in the market by decreasing the downtime and reconfiguration overhead incurred due to product changes. The agile manufacturing concept is already in a stage of practical use in some companies, for example, pager manufacturing at Motorola [19], or customized bicycles from Panasonic [5].

Agile manufacturing, a recently popularized concept, has been advocated as the 21st century manufacturing paradigm. Markets become highly diversified and global, and continuous and unexpected change, become the key factors for success. The need for a method of rapidly and cost­ effectively developing products, production facilities, and supporting information technology has led to the concept of agile manufacturing. Agile manufacturing requires enriching of the customer, cooperating with competitor organizing to manage change, uncertainty and complexity; and leverage people and information. The key enabler of agile manufacturing include: i) virtual enterprises formation, ii) physically distributed teams, iii) integrated business information system. This framework as a basis for understanding the major strategies and relevant tecnnologies of agile manufacturing (AM).

This chapter discusses knowledge management (KM) aspects of how software process and software process improvement (SPI) is practiced within very small entities (VSEs) in the context of Irish software development industry. In particular, this study is concerned with the process of software development knowledge management in supporting the SPI. In order to understand the support process, the authors of this chapter have studied how KM processes are practiced within VSEs which includes communication, learning, sharing, and documentation process. This study also focuses in detail on the issues of the knowledge atrophy problem in VSEs. The findings explain how KM has been practiced and influenced the software development process and process improvement in VSEs. This result indicates that KM processes in VSEs are being undertaken in a very informal manner and also in indirect way. This is due to a small team size, autonomous working and macro-management style and caused VSEs to be more informal in their KM processes specifically and SPI generally. In addition, the results have indicated that the informal environment and culture helped VSEs to easily create and share knowledge between staff members and also assisted VSEs to mitigate the knowledge atrophy problem in their organization.

Purpose – The purpose of this paper is to conduct an empirical investigation on the new product development (NPD) practices in Indian manufacturing industries. The NPD best practices constructs are identified from the literature and then an effort have been made to statistically establish the underlying principal components of NPD practices by checking their reliability and validity for the case of Indian manufacturing industry. Design/methodology/approach – In all, 96 NPD best practices constructs are identified from literature articles published between 1998 and 2009. Principal component analysis (PCA) is conducted to establish the seven components of NPD practices. Cronbach's α values are computed to measure internal consistency or reliability of the established components of NPD practices. Further, confirmatory factor analysis is conducted on the established measurement model to test a hypothesized factor structure through construct validity, convergent validity and divergent validity. Findings – The PCA of NPD best practices identified the seven underlying components (latent variables) namely “NPD strategy,” “NPD support system,” “product portfolio management,” “NPD team,” “NPD tools,” “product launch” and “concept generation.” In NPD strategy, Indian manufacturing companies are highly inclined toward cost reduction, cycle time reduction, competitive advantage and fast follower strategies. All NPD support system constructs are information technology dependent tools which require hardware, software and databases to support it. Indian manufacturing organizations are fundamentally concentrating on right balance of portfolio through improvements in the current products, cost reduction and additions to existing lines by using modular architectures and the reliable and valid NPD tools are FMEA, six sigma/quality management, DFMA/DF’X and QFD. Originality/value – To the best of the author's knowledge, this research represents the first attempt to investigate empirically the NPD practices in Indian manufacturing industry.

work of W. Edwards Deming has convinced industry that must first measure quality and then emphasise process to improve quality. In response to Deming's arguments and in light of perception that software industry is unable to produce quality products on schedule, and within budget, more software development organisations are now emphasising process measurement, monitoring, and assessment. This paper describes what is meant by software process and discusses an approach for its measurement and improvement. INTRODUCTION Unreliable software makes big news, from emergency services disasters to social security payment blunders. Improved software quality is essential to ensure reliable products and services, and gain customer satisfaction. While software development has existed for more than four decades, we failed so far to make as an industry and as an engineering discipline rather than craft. Developing reliable and usable software that is delivered on and within budget still represents difficult endeavour for many organisations. As role of software becomes increasingly critical for businesses as well as for human lives, problems caused by software products that are late, over budget, or that do not work, become magnified. If lives are lost or people inconvenienced due to incapable computer software, news media is there to make big stories. Organisations are realising that their fundamental problems is immaturity of their software process. Robert Lai (1993) proposes that process improvement is second maturity wave of software industry. He states that the first wave of software was developed using waterfall model in 1970's. Today we are Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 216 Software Management in midst of second wave maturity movement as we attempt to formally define development process and best ways to continuously improve it (Lai 1993). Taking lead in this area has been Watts Humphrey (Humphrey 1989, 1990, 1991), and Software Engineering Institute (SEI) at Carnegie Mellon University. SEI started in 1986 to develop process maturity framework to help organisations appraise maturity of their software process, and to provide guidance for organisations to improve their software process capability. A brief description of framework was released in September 1987, including maturity questionnaire. SEI evolved model and questionnaire into 5 -Level Capability Maturity Model (CMM) in 1991. In February 1993, released CMM version 1.1 (Paulk et al 1993). This paper discusses software process and describes capability maturity model (CMM). It also shows how CMM can be used as basis to measure maturity of software process of an organisation and plan its improvement. SOFTWARE QUALITY AND PROCESS IMPROVEMENT In his book Quality is Free Phil Crosby states that: Quality is free. It is not gift, is free. What cost money are unqualify of things all actions that involve not doing jobs right first time (Crosby 1980). If such statement is true for many disciplines, is particularly true for evidence is abundant in number of software products which exceeded their budget, were produced late, failed to satisfy user requirements, and are full of bugs. demand for improved software quality is increasing to ensure reliable products and services. benefits of improved quality comes in form of reduction in failure costs. For software projects failure costs include (DTI 1992): • costs of correcting defects, both before and after delivery • overruns against and budget • unnecessary high maintenance costs • indirect costs which users incur due to poor quality software link between process maturity and software quality is expressed in premise that The quality of software system is governed by quality of process used to develop and maintain it. One stumbling block to improving software quality seems to be that not enough attention is paid to overall development process itself. While software professionals typically devote their to developing, testing or documenting software products, no one has prime responsibility for improving software process. Experience has shown that if Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 Managing Systems 217 no one is working on software process, orderly improvement is unlikely. process certainly won't improve itself, rather, most likely, will deteriorate over time. Continuous improvement can occur only if process infrastructure is in place. Watts Humphrey argues in an early article published in Datamation, April 1989 that: Without work on process, there will be little or no progress in improving software. THE SOFTWARE PROCESS Adopting process view of software development represents revolutionary change in perspective. A process orientation to software development involves elements of structure, focus, measurement, ownership, skills, and supporting technology. In this section we investigate what is meant by software process. What Is Software Process According to Webster's dictionary, process is a system of operations in producing something .. series of actions, changes, or functions that achieve an end result. Chambers Concise Dictionary defines process as a series of actions or events .. sequence of operations or changes undergone. IEEE defines process as a sequence of steps performed for given purpose. In general business context, process is defined as a structured, measured set of activities designed to produce specified output for particular customer or market (Davenport 1993). These definitions put strong emphasis on HOW work is done, in contrast to product focus's emphasis on WHAT. Accordingly, process can be considered as a specific ordering of work activities across and place, with beginning, an end, and clearly identified inputs and outputs: structure for action. In this paper we will adopt following definitions quoted in (Humphrey 1990, Paulk et al 1993) are intended to encompass software throughout its life, which covers new development, enhancement, and repair. software process is The set of activities, methods, and practices used in production and evolution of software. software engineering process is The total set of software engineering activities needed to transform user's requirements into software. Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 218 Software Management People and Software Process Software development is still people-intensive activity. Talented people are most important element in any software organisation. Even if you get best people available, if they do not follow common process, if everyone wrote in different programming languages, used different conventions, or didn't co-ordinate their design and code changes with their peers, results will be chaos. Successful software organisations have learned that even best professionals need structured and disciplined environment in which to do cooperative work. Software organisations that do not establish such disciplines condemn their people to endless hours of repetitively solving technically trivial problems. obvious fact is that attracting best people is vital, but is also essential to support them with an effectively managed software process. Technology and Software Process Another myth is widespread belief that some technologically advanced tool or method will provide magic answer to software crisis. This is not only wrong, but is dangerous. Organisations which jumped on bandwagon of CASE tools, and ended up in failure and wasted and effort have learned their lesson hard way. Just ask yourself before introducing technology: What do I want to automate? In absence of defined, practised, and managed process, introducing automation can lead to increased chaos. There are several factors which limit effective use of software technology: an illdefined process, inconsistent process implementation, and poor process management. Software technology cannot be fully effective until these problems have been properly addressed. Need for Defined Process If no effort is made to define and enhance software development process across whole organisation, each software development project latches on to its own tools, methods, and practices with little guidance available on how to use them. This ad hoc approach will not be sufficient to tackle task of developing complex software systems. goal of software process management is to enable organisations to produce software that meets cost, schedules, and quality objectives. principles are same that underpins statistical process control-principles that have been successfully used in controlling scientific experiments and in high -volume manufacturing operations. Statistical concepts have been found to be just as applicable to software development as they are to production of manufactured goods such as motor cars. Applying such concepts will only be possible if there is defined and managed process. Software Process Models Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

The emerging international standard ISO/IEC 15504 on ‘Information Technology – Software Process Assessment’ aims to harmonize the various assessment approaches used in software process improvement (SPI). While approaches based on the organization-focused ‘staged model’ (SW-CMM etc.) provide a ‘roadmap’ generally true for most organizations, the process-focused ‘continuous model’ of ISO/IEC 15504 does not prescribe any particular improvement path. SPI projects using the ISO/IEC 15504 approach are thus considered to have to deal with increased complexity in improvement planning. Targeting this problem, the basic ideas behind a generalized system dynamics model of ‘a set of improving software processes’ currently under development to support SPI action planning at a tactical level are presented. The basic intention is to determine the impact of a set of scheduled improvement actions on the strategic target variables of SPI (time-to-market, cost, quality). The approach integrates the two main ‘mental models’ behind ISO/IEC 15504: the process model described textually as a network of processes and work products, and the model of maturing single processes. The development of the model is oriented at organizations with lower capability and medium sized development projects. The results of preceding software process assessments are used as a major source for model initialization. How simulation can support software process improvement is discussed, and insights from sample applications are presented. Copyright © 2000 John Wiley & Sons Ltd

The flexibility required of an agile manufacturing system must be achieved largely through computer software. The system's control software must be adaptable to new products and to new system components without becoming unreliable or difficult to maintain. This requires designing the software specifically to facilitate future changes. As part of the Agile Manufacturing Project at Case Western Reserve University, we have developed a software architecture for control of an agile manufacturing workcell, and we have demonstrated its flexibility with rapid changeover and introduction of new products. In this paper, we describe the requirements for agile manufacturing software and how our software architecture addresses them.

Software development has challenged the traditional ways of delivering software as it provides a very different approach to software development. In recent decades, software process improvement (SPI) has been widely studied in the context of traditional software development, and its strengths and weaknesses have been recognized. As organizations increasingly adopt agile software development methodologies to be used alongside traditional methodologies, new challenges and opportunities for SPI are also emerging. One challenge is that traditional SPI methods often emphasize the continuous improvement of organizational software development processes, whereas the principles of agile software development focus on iterative adaptation. Keyword—Software processimprovement, software process improvement model, Requirement gathering, Process definition