A design pattern is a particular prose form of recording design information such that designs which have worked well in the past can be applied again in similar situations in the future. The availability of a collection of design patterns can help both the experienced and the novice designer recognize situations in which design reuse could or should occur. We have found that design patterns: 1) provide an effective "shorthand" for communicating complex concepts effectively between designers, 2) can be used to record and encourage the reuse of "best practices", 3) capture the essential parts of a design in compact form, e.g. for documentation of existing software architectures. Since the patterns community is one that shares information in an open forum and builds on the experiences of others, we chose to submit a joint paper on our industrial experiences with patterns. We focus on the lessons learned in our respective industrial settings as a first step towards answering the questions...

This article describes our experience implementing this process. Why Scrum? As members of the Software Technology Group, our group is responsible for introducing new technologies and processes into our organization at AG Communication Systems in Phoenix, Arizona. We research new approaches and sponsor their introduction and growth. We also conduct development project checkups for ongoing projects and postmortems for completed ones. In our periodic postmortems and checkups, we noticed some recurring problems for our New Business Opportunity (NBO) projects. Figure 1 lists some comments arising from projects at our organization that faced significant challenges. In the new telecommunications market where our company operates, change is overwhelming. Software developers have always complained about changing requirements, but in traditional approaches they assumed they would understand the requirements before moving on to the next phase. In the current envir

Patterns have shown to be an effective means of capturing and communicating software design experience. However, there is more to patterns than software design patterns: We believe that patterns work for software development on several levels. In this paper we explore what we have come to understand as crucial aspects of the pattern concept, relate patterns to the different models built during software design, discuss pattern forms and how we think that patterns can form larger wholes like pattern handbooks. 1 Introduction Design patterns have become a hotly discussed topic in software development. We and many other researchers have been using and experimenting with patterns over the last years. We have applied patterns and observed their usage within software development. We have used and seen several definitions of patterns, and we have experimented with pattern forms. The emerging literature shows a flourishing and fruitful diversity of pattern definitions, forms and applications. ...

This paper describes the dotplot data visualization technique and its potential for contributingto the identification of design patterns. Pattern languages have been used in architectural design and urban planning to codify related rules-of-thumb for constructing vernacular buildings and towns. When applied to software design, pattern languages promote reuse while allowing novice designers to learn from the insights of experts. Dotplots have been used in biology to study similarity in genetic sequences. When applied to software, dotplots identify patterns that range in abstraction from the syntax of programming languages to the organizational uniformity of large, multi-component systems. Dotplots are useful for design by successive abstraction---replacing duplicated code with macros, subroutines, or classes. Dotplots reveal a pervasive design pattern for simplifying algorithms by increasing the complexity of initializations. Dotplots also reveal patterns of wordiness in languages---one...

Patterns are now widely used for describing software designs. However, they may also be used to describe process structure rather than the product structure. This may be accomplished by adapting the well known pattern description schemes to the software process domain. Within this scheme, I use the description techniques and notions of the UML wherever suitable. This, and superior degrees of detail, precision, and expressiveness set this paper apart from previous approaches in this area.

This paper discusses a three-year experiment to build a distributed research group, equipped with state-of-the-art computing facilities, spread over three cities in Australia. Despite the provision of the sorts of facilities to be expected in cooperative buildings, such as high-speed networks and videoconferencing, significant synergy (i.e., closely-coupled collaborations) among the distributed subgroups did not develop. This was not only due to the problems of distance, but was exacerbated by several political and organizational issues. An important lesson is that successful `cooperative buildings' will depend not just on the technology but also on an appropriate managerial, organizational and political climate in which these resources can be meaningfully exploited. The paper outlines the experiment, discusses why synergies did not emerge, and points to implications for cooperative buildings and design paradigms based on the notion of pattern languages.

This report describes an experiment carried out at ParcPlace-Digitalk which sought to increase the look-and-feel compliance of portable applications built using the company's Smalltalk-based VisualWorks product. We outline the structure of the current VisualWorks user interface framework, and the precise requirements which the experimental system sought to fulfill. We go on to show how we were able to reuse design patterns from the literature in a generative fashion, to direct the evolution of the new framework. This contrasts with most pattern-related work to date, which has concentrated on discerning design patterns in existing systems. Finally, we draw generalizations from our experience concerning the evolution of software architecture using patterns. 1.

this paper we describe how software processes can be supported using knowledge management, concentrating on the creativemanual tasks performed bydevelopers. The main support needed bydevelopers is the availability of the knowledge about the development processes relevant to their task. As a result, software process modeling can be considered as a knowledge managementtask

Global interorganizational software development projects are becoming common, but their management and the creation of practices and processes to support collaboration seem to be harder than what the companies expect. In this article, we present successful collaboration practices collected in an interview study of eight globally distributed interorganizational software development projects. On the basis of 34 semistructured interviews, we were able to identify several practices that the interviewees subjectively deemed successful. The identified collaboration practices include: milestone synchronization, frequent deliveries, and the establishment of peer-to-peer links. The need to plan for problem-solving communication was often neglected in the beginning of the project, despite its paramount importance. We identified several ways to ease related problems, such as having a dedicated person solve problems, using bulletin boards and e-mail lists or dedicated mailboxes. Successful projects had learned the value of two-way communication regarding project progress monitoring. Finally, practices helping in building and maintaining a working relationship included face-to-face meetings, distribution of organization charts, and having people travel to give all sites faces. Copyright © 2004 John Wiley & Sons, Ltd. KEY WORDS: global software development; interorganizational software development; collaboration practices; communication 1.

Factory pattern (see, for example, [Grand, 1998] for details of Abstract Factory). In fact, the Products that Builder constructs are often Composites.