FREE ELECTRONIC LIBRARY - Dissertations, online materials

Pages:   || 2 | 3 | 4 |

«Abstract. Handshaking between product management and R&D is key to the success of product development projects. Traditional requirements engineering ...»

-- [ Page 1 ] --

Handshaking between Software Projects and

Stakeholders Using Implementation Proposals

Samuel Fricker1,2, Tony Gorschek3, and Petri Myllyperkiö 4

1 ABB Switzerland Ltd., Corporate Research,

Segelhof, 5405 Baden-Daettwil, Switzerland


2 University of Zurich, Department of Informatics,

Binzmuehlestrasse 14, 8057 Zurich, Switzerland


3 Blekinge Institute of Technology, School of Engineering,

PO Box 520, 372 25 Ronneby, Sweden

tony.gorschek@bth.se 4 ABB Oy, Distribution Automation B.O. Box 699, 65101 Vaasa, Finland petri.myllyperkio@fi.abb.com Abstract. Handshaking between product management and R&D is key to the success of product development projects. Traditional requirements engineering processes build on good quality requirements specifications, which typically are not achievable in practical circumstances, especially not in distributed devel- opment where daily communication cannot easily be achieved to support the understanding of the specification and tacit knowledge cannot easily be spread.

Projects thus risk misunderstanding requirements and are likely to deliver in- adequate solutions. This paper presents an approach that uses downstream en- gineering artifacts, design decisions, to improve upstream information, a pro- ject’s requirements. During its preliminary validation, the approach yielded promising results. It is well suited for distributed software projects, where the negotiation on requirements and solution design need to be made explicit and potential problems and misunderstandings caught at early stages.

1 Introduction Distributed multi-site product development is increasingly becoming commonplace as companies become global not only in terms of customer base, but also with regards to large parts of the product development that is spread over continents and cultures.

Distribution enables companies to leverage their resources and to draw on the advan- tage of proximity to customers and markets for large-scale product development [1].

The potential opportunities, however, also come with new challenges that affect both product management and product development of a company, and the require- ments engineering of products. The threat of defect increase and cost overruns in multi-site development has been documented in literature and industry experience reports. Some of the main problems are attributed to heterogeneous understanding of requirements, and substantial differences in domain understanding and interpretation [2-4]. This is compounded by the fact that multi-site development usually is detrimental to informal communication between stakeholders, which include product managers, experts, and developers, as these roles are often separated geographically [2]. Informal communication and face-to-face meetings often help in augmenting imperfect specifications by building a common understanding of what is to be done, by whom, and when, and indirectly passing on domain knowledge and other tacit information crucial to the development effort. The ability for developers to seek out and regularly communicate with domain experts is prohibited by distance: all communication is associated with administrative and planning overhead, resulting in an raised threshold for daily validation of specification interpretations [3]. Cultural differences between sites can also lead to issues as some management styles prohibit developers from directly eliciting information: communication may be routed through one or a few central managers, further congesting communication [2].

A common result of these challenges is that defects, delays, and misunderstandings are caught very late, often during system integration. This dramatically increases the whole product development effort and is detrimental to time-to-market, which is recognized as one of the most important factors in market-driven development [5, 6].

In response to the challenges posed by distributed development this paper presents a technology developed in active collaboration with industry to alleviate some of the problems and enable explicit handshaking procedures between stakeholders. The technology, called implementation proposal, enables such handshaking by relating software design to requirements. It was primarily motivated by challenges identified at ABB, and relates to a case where large scale development was performed utilizing sites spread across North America, Europe, and Asia.

Implementation proposals and their proper use enable explicit communication between stakeholders at the critical phase of requirements interpretation, as well as mapping the implications of design decisions to the end product. In addition, the comparison of implementation proposals and requirements demands iteration until a joint understanding of requirements and domain implications can be reached. A positive spin-off effect is that requirements deliverers, e.g. product managers, are able to gauge the impact on system architecture early in the process.

The focus of this paper is on presenting the implementation proposal technology and the organizational and process implications that follow the utilization of the technology. The experiences of using implementation proposals are based on a pilot currently underway in a large scale development effort at ABB.

The paper is structured as follows. Section 2 discusses the background and related work. In Section 3 the implementation proposal concept and handshaking process is presented and discussed. Section 4 presents early handshaking results. Section 5 positions handshaking with related literature. Section 6 concludes the paper.

2 Background

Large scale distributed development demands management of physical distance, time zones, and the thin spread of domain and technology expertise, which impact requirements communication [2], and management of the overall solution architecture with multiple levels of product integration.

Key principles that are applied to manage these issues include allocation of responsibility for well-separated components of the software solution to various teams, ownership of such a team for the overall lifecycle of their contribution, a globally accessible requirements and configuration management infrastructure, and project roles and practices that enable critical communication to happen among the teams as well as between the teams and product management, project management, and architects.

The application of these principles leads to an organizational structure that is aligned either with the structure of the software product and its related domains [7] or with the overall development process with different roles located at different places.

Fig. 1 illustrates one such an alignment in a stylized and simplified manner that can be observed in ABB as it relates to the case presented in this paper.

Fig. 1. Alignment of organizational structure with the structure of the software product and its related domains.

In Fig. 1, product management is responsible for a software product’s markets and application domains and formulates relevant requirements, which are handed over to a software architecture team. The software architects, responsible for the overall architecture of the software product, communicate requirements to development teams, which are responsible for the development of the components assigned to them. Those components, finally, are integrated to form the software product, which after verification and validation gets deployed into the targeted application domains and markets.

There are several ways to handle the division of work and organizational structure with regards to distributed development [4, 7]. First, the case of hand-off can be seen in Fig.1, where different process steps are performed at different levels in the organization. Every such process step results in a deliverable that is handed down, like the requirements from product management to the architecture team. This implies that the deliverables have to be transferred across sites. Such a hand-off between sites can cause many of the issues discussed earlier in terms of heterogeneous understanding, and impossible compensation for imperfect deliverables due to lacking informal and day-to-day communication.

Second, the case of structural or functional division can be seen in Fig.1, where different parts of the product itself, i.e. some feature sets, are handled exclusively by one site. This implies that deliverables do not need to be transferred across sites, but are created and handed over locally. The main challenge is here to minimize coordination needs by a clear division of the product with low coupling between the parts that are distributed over sites. This is hard to achieve in practice.

In the ABB case hand-off challenges were predominant, even if some units on development level actually were organized according to product functions. The focus of this paper is on addressing the challenges to this type of distributed organization.

Looking at work performed previously in relation to the problem at hand, several investigations have been conducted for identifying the main challenges and recommending solutions [1-3, 5, 6]. Commonly recurring themes are face-to-face meetings and communication between sites. Solutions include introducing requirements management platforms for global access to requirements, employing communication technologies like chat, persistent video- and teleconferencing for enhanced communication, shared project workspaces, and configuration management systems.

A central issue was not only to address the problems of requirements understanding and communication, but also to find a technology that would enable explicit mapping of design decisions to the product requirements. Product management was the main author of requirements at early stages of the product development project and a central source of domain knowledge. However, the time available to product management for communicating requirements and for validating design decisions was limited. Thus, the communication between product management and the architecture team had to be explicit and concrete enough to avoid misunderstandings despite hand-off over sites, and efficient enough to make good use of time spent.

Traditional communication and face-to-face meetings are well established practices at ABB, as are the utilization of CASE tools over sites. However, the fundamental limitations of not being a team in one location demanded additional steps to be taken to ensure that a common understanding had been reached. One important goal was to increase the efficiency and effectiveness of the limited number of meetings by having relevant decision support material created beforehand as a part of the practices. This involved the creation of artefacts that would increase traceability between design decisions and requirements, the two main constituents of architectural impact.

3 Implementation Proposal Concept and Handshaking Process

It is well accepted that requirements are tightly linked to solution design. This holds for requirements and design decisions at any level of abstraction. This section elaborates on this relationship for the purposes of requirements communication and negotiation on an appropriate implementation approach by describing the structure and possible forms of implementation proposals and their relationships to requirements.

The relationship between requirements and solution design is bidirectional. Not only context and goals affect the design of a software solution, but also the emerging capabilities of the solution influences what goals can be achieved and how effective usage of the software shall be structured [8]. The impact of a targeted software solution on its context is particularly important to consider in situations with limited engineering resources, with limited capabilities of technology, and in projects that are building on legacy, as these factors pose demands on architecture and design regarding feasibility. The impact of a software solution is also important to consider, when errors have been introduced in the design, due to imperfect understanding of requirements for example, which cannot be corrected with given project resources and deadlines, resulting in quality deficiencies and cost overruns.

3.1 Implementation Proposals

Implementation proposals support the negotiation between requirements and solution providers, as shown in Fig. 2. The requirements provider, a stakeholder or customer that is responsible for a problem domain, contracts a solution provider to realize a software solution. The solution provider, the supplier or development team, is responsible for creating a software solution that satisfies the requirements.

Fig. 2. Communication between requirements and solution providers through requirements and implementation proposals.

Solely focusing on requirements during negotiations is not enough as requirements are often misunderstood and the impact of feasible architecture and design is largely ignored. To mitigate these risks, implementation proposals are introduced. Implementation proposals describe the targeted solution and its expected impact from the perspective of the supplier. As Fig. 2 illustrates, implementation proposals are an answer to requirements and flow from the solution provider to the requirements provider.

The situation described in Fig. 2 appears often in product development at ABB.

Referring to Fig. 1, the interaction pattern is of relevance between product management, the requirements provider, and the software architecture team, the solution provider, who need to coordinate the development of the overall software product. The pattern is also of relevance between the software architecture team, which now becomes the requirements provider, and every development team, the solution providers, that are responsible for the various software components. Not shown in Fig. 1 are the likely interactions between product management, the requirements provider, and some of the development teams, the solution providers, for coordinating lower-level requirements for design of externally visible software components.

Pages:   || 2 | 3 | 4 |

Similar works:

«People Detection based on Points Tracked by an Omnidirectional Camera and Interaction Distance for Service Robots System Tsuyoshi TASAKI Abstract A robotic system is expected to increase visitors for big facilities such as big shopping stores. The recent robotic system often has two kinds of service robots, interaction robots and mobile robots. The interaction robots attract many visitors simultaneously at a particular position in the facilities. The mobile robots provide services to each...»

«Venerable Robina Courtin The Bird Needs Two Wings (Unedited) Osel Shen Phen Ling, Missoula, MT 21 July 2011 Well, listen. I really have my doubts whether we’ll do this text that Bob wants us to do tonight, I’ve got my second thoughts, alright? We might do something completely different. Will you throw me out, Bob? Sack me? Send me back? It just feels we’ve talked enough about karma, this is just more karma, you know? I think I’d rather talk about the compassion wing and maybe some other...»

«This work is distributed as a Discussion Paper by the STANFORD INSTITUTE FOR ECONOMIC POLICY RESEARCH SIEPR Discussion Paper No. 16-011 Macroprudential Policy with Liquidity Panics By Daniel Garcia-Macia and Alonso Villacorta Stanford Institute for Economic Policy Research Stanford University Stanford, CA 94305 (650) 725-1874 The Stanford Institute for Economic Policy Research at Stanford University supports research bearing on economic and public policy issues. The SIEPR Discussion Paper...»

«Nanoscale study of pili from the probiotic Lactobacillus rhamnosus GG Prachi TRIPATHI Supervisors: Prof. Jos Vanderleyden, KU Leuven Prof. Yves F. Dufrêne, Université catholique de Louvain Prof. Sarah Lebeer, KU Leuven & Universiteit Antwerpen Dissertation presented in partial Members of the Examination Committee: fulfillment of the requirements Prof. René De Mot, KU Leuven for the degree of Doctor in Prof. Johan Hofkens, KU Leuven Bioscience Engineering Prof. Pascal Hols, Université...»

«Bulletin of Education and Research June 2010, Vol. 32, No. 1 pp 37-51 An Exploration of Emotional Intelligence of the Students of IIUI in Relation to Gender, Age and Academic Achievement Maliha Nasir* & Rehana Masrur** Abstract This correlational study was intended to examine the relationship of emotional intelligence (EI) with gender, age and academic achievement of students of International Islamic University Islamabad (IIUI). In this study the predictor variable was emotional intelligence...»

«University of Massachusetts Amherst ScholarWorks@UMass Amherst Dissertations Dissertations and Theses 9-1-2013 Contested Subjects: Biopolitics & the Moral Stakes of Social Cohesion in Post-Welfare Italy Milena Marchesi University of Massachusetts Amherst, milemarche@gmail.com Follow this and additional works at: http://scholarworks.umass.edu/open_access_dissertations Recommended Citation Marchesi, Milena, Contested Subjects: Biopolitics & the Moral Stakes of Social Cohesion in Post-Welfare...»

«UPDATED FEBRUARY 2014 LOW CARB CARB-FREE AND Carbohydrate free Products that contain minimal carbohydrate This is a list of products that contain minimal or no carbohydrate intended for use with the ketogenic diet. The ingredients have been provided by the manufacturer. Some manufacturers will not provide specific carbohydrate content therefore the ingredients are used as a guide. Check the ingredient label of the product with this list to ensure that the product has not changed. There may be...»

«Ling 6510: Readings & Research in Syntax Susi Wurmbrand Fall 2008, Mon 1:30 – 4:30 susanne.wurmbrand@uconn.edu Office hours: By appointment COURSE REQUIREMENTS  Readings & class participation  Participation in Abstract writing workshop (details to come later)  3 30-45 min presentations: one paper from each of Topics A, B, C; detailed handout required.  Term paper (your own work): come up with topic by Nov 10; final paper due December 9, 2008. A NOTE ON THE READINGS One aspect of...»

«Filed Washington State Court of Appeals Division Two May 25, 2016 N THE COURT OF APPEALS OF THE STATE OF WASHINGTON DIVISION II JAMES J. WHITE, No. 47079-9-II Appellant, v. CITY OF LAKEWOOD, PUBLISHED OPINION Respondent. LEE, J. — James J. White submitted three separate public records requests pursuant to the Public Records Act1 (PRA), requesting documents from the Lakewood Police Department. The city of Lakewood (City) withheld certain documents, claiming that the documents related to an...»

«MEDIA RELEASE For Immediate Release 22 Jun 2011 SHINE Youth Festival 2011: BIGGER AND BOLDER Annual SHINE Youth Festival set to encourage 250,000 youths to “Just do” SHINE will be back in a spectacular way come 2nd July, with a launch event featuring Singapore’s first-ever multi-decked concept party in the heart of town at *SCAPE. Organised by the National Youth Council (NYC) as an annual youth for youth festival to celebrate and showcase youth talent, SHINE 2011 continues to be a...»

«Principles of Microeconomics Professor Edward Morey ECON 2010-300 Final Exam December 18, 2008 Version A As a University of Colorado at Boulder student, I affirm that I have neither given nor received assistance on this exam. Name: _ Date: Signature: Questions that still need thought attention are 11 (the new graph in the answer key is not showing u), 21 (the answer is in yellow) Use the following to answer question 1. Figure: Demand and Supply of Gasoline 1. (Figure: Demand and Supply of...»

«MINUTES UTAH SUPREME COURT ADVISORY COMMITTEE ON THE RULES OF CIVIL PROCEDURE JANUARY 22, 2014 PRESENT: Jonathan Hafen, Chair, Sammi V. Anderson, W. Cullen Battle, Scott S. Bell, Hon. James T. Blanch, Frank Carney, Prof. Lincoln Davies, Hon. Evelyn J. Furse, Steven Marsden, Terrie T. McIntosh, Hon. Derek Pullan, David W. Scofield, Hon. Todd M. Shaughnessy, Trystan B. Smith, Barbara L. Townsend, Lori Woffinden STAFF: Timothy M. Shea, Nathan Whittaker EXCUSED: Hon. Lyle R. Anderson, Hon. John L....»

<<  HOME   |    CONTACTS
2016 www.dissertation.xlibx.info - Dissertations, online materials

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.