| Differences in Jazz project leaders' competencies and behaviors: A preliminary empirical investigation | | BIBAK | Full-Text | 1-8 | |
| S. A. Licorish; S. G. MacDonell | |||
| Studying the human factors that impact on software development, and
assigning individuals with specific competencies and qualities to particular
software roles, have been shown to aid software project performance. For
instance, prior evidence suggests that extroverted software project leaders are
most successful. Role assignment based on individuals' competencies and
behaviors may be especially relevant in distributed software development
contexts where teams are often affected by distance, cultural, and personality
issues. Project leaders in these environments need to possess high levels of
interpersonal, intra-personal and organizational competencies if they are to
appropriately manage such issues and maintain positive project performance.
With a view to understanding and explaining the specific competencies and
behaviors that are required of project leaders in these settings, we used
psycholinguistic and directed content analysis to study the way six successful
IBM Rational Jazz leaders operated while coordinating their three distributed
projects. Contrary to previous evidence reported in personality studies, our
results did not reveal universal competencies and behaviors among these Jazz
leaders. Instead, Jazz project leaders' competencies and behaviors varied with
their project portfolio of tasks. Our findings suggest that a pragmatic
approach that considers the nature of the software tasks being developed is
likely to be a more effective strategy for assigning leaders to distributed
software teams, as against a strategy that promotes a specific personality
type. We discuss these findings and outline implications for distributed
software project governance. Keywords: cultural aspects; distributed programming; human factors; human resource management; software development management; IBM Rational Jazz leaders; Jazz project leader behaviors; Jazz project leader competencies; cultural issues; directed content analysis; distributed software development; distributed software project governance; distributed software teams; extroverted software project leaders; human factors; interpersonal competencies; intra-personal competencies; organizational competencies; personality issues; positive project performance maintenance; project portfolio; psycholinguistic analysis; role assignment; software project performance; software roles; software tasks; Context; Encoding; Lead; Pragmatics; Project management; Psychology; Software; Jazz; Software development; competencies and behaviors; content analysis; project leaders; psycholinguistics | |||
| Motivation of software engineers: A qualitative case study of a research and development organisation | | BIBAK | Full-Text | 9-16 | |
| A. C. C. França; A. C. M. L. de Araujo; F. Q. B. Da Silva | |||
| Understanding motivation of software engineers has important implications
for industrial practice. This complex construct seems to be affected by diverse
environmental conditions and can affect multiple dimensions of work
effectiveness. In this article, we present a grounded theory that describes the
motivation of software engineers working in a not-for-profit private research
and development organisation. We carried out a holistic case study for seven
months, using structured interviews, diary studies, and documental analysis for
data collection, and grounded theory techniques for data analysis and
synthesis. The results point to task variety and technical challenges as the
main drivers of motivation, and inequity and high workload (caused by poor
estimations in the software process) as the main obstacles to motivation in the
organisation. Keywords: data analysis; environmental factors; research and development; software engineering; data analysis; data collection; data synthesis; diary studies; documental analysis; environmental conditions; grounded theory; industrial practice; not-for-profit private research and development organisation; software engineering; structured interviews; Context; Data collection; Employment; Engineering profession; Interviews; Software; Software engineering; People motivation; people management; qualitative case study; software development; software engineering | |||
| Collaborative bug triaging using textual similarities and change set analysis | | BIBAK | Full-Text | 17-24 | |
| K. Kevic; S. C. Müller; T. Fritz; H. C. Gall | |||
| Bug triaging assigns a bug report, which is also known as a work item, an
issue, a task or simply a bug, to the most appropriate software developer for
fixing or implementing it. However, this task is tedious, time-consuming and
error-prone if not supported by effective means. Current techniques either use
information retrieval and machine learning to find the most similar bugs
already fixed and recommend expert developers, or they analyze change
information stemming from source code to propose expert bug solvers. Neither
technique combines textual similarity with change set analysis and thereby
exploits the potential of the interlinking between bug reports and change sets.
In this paper, we present our approach to identify potential experts by
identifying similar bug reports and analyzing the associated change sets.
Studies have shown that effective bug triaging is done collaboratively in a
meeting, as it requires the coordination of multiple individuals, the
understanding of the project context and the understanding of the specific work
practices. Therefore, we implemented our approach on a multi-touch table to
allow multiple stakeholders to interact simultaneously in the bug triaging and
to foster their collaboration. In the current stage of our experiments we have
experienced that the expert recommendations are more specific and useful when
the rationale behind the expert selection is also presented to the users. Keywords: program debugging; text analysis; bug report identification; change information analysis; change set analysis; collaborative bug triaging; information retrieval; machine learning; multitouch table approach; software developer; source code; textual similarity; work item; Collaboration; Computer bugs; Data models; Prototypes; Software; User interfaces; Vectors; bug triaging; collaboration; expert recommendation; multi-touch | |||
| Why do newcomers abandon open source software projects? | | BIBAK | Full-Text | 25-32 | |
| I. Steinmacher; I. Wiese; A. P. Chaves; M. A. Gerosa | |||
| Open source software projects, are based on volunteers collaboration and
require a continuous influx of newcomers for their continuity. Newcomers face
difficulties and obstacles when starting their contributions, resulting in a
low retention rate. This paper presents an analysis of the first interactions
of newcomers on a project, checking if the dropout may have been influenced by
lack of answer, answers politeness and helpfulness, and the answer author. We
have collected five years data from the developers' mailing list communication
and issue manager (Jira) discussions of the Hadoop Common project. We observed
developers' communication, identifying newcomers and classifying questions and
answers content. In the analyzed period, less than 20% of newcomers became
long-term contributors. There are evidences that the newcomers decision to
abandon the project was influenced by the authors of the answers and by the
type of answer received. However, the lack of answer was not evidenced as a
factor that influences newcomers' decision to remain or abandon the project. Keywords: groupware; public domain software; software development management; Hadoop Common project; collaboration; open source software project; Brain modeling; Communities; Data mining; Electronic mail; Open source software; Newcomer; collaboration; communication; open source software; retention | |||
| Emergence of developer teams in the collaboration network | | BIBAK | Full-Text | 33-40 | |
| B. Caglayan; A. B. Bener; A. Miranskyy | |||
| Developer teams may naturally emerge independent of managerial decisions,
organizational structure, or work locations in large software. Such self
organized collaboration teams of developers can be traced from the source code
repositories. In this paper, we identify the developer teams in the
collaboration network in order to present the work team evolution and the
factors that affect team stability for a large, globally developed, commercial
software. Our findings indicate that: a) Number of collaboration teams do not
change over time, b) Size of the collaboration teams increases over time, c)
Team activity is not related with team size, d) Factors related to team size,
location and activity affect the stability of teams over time. Keywords: organisational aspects; software development management; source coding; collaboration network; commercial software; large software; managerial decisions; organizational structure; self organized developer collaboration teams; source code repositories; team activity; team stability; work locations; Clustering algorithms; Collaboration; Communities; Correlation; Market research; Software; Stability analysis | |||
| How software architects collaborate: Insights from collaborative software design in practice | | BIBAK | Full-Text | 41-48 | |
| Jae Young Bang; I. Krka; N. Medvidovic; N. Kulkarni; S. Padmanabhuni | |||
| The increasingly complex software systems are developed by globally
distributed engineering teams consisting of a number of members who collaborate
to gather the requirements, as well as design, implement, and test the system.
Unlike other development activities, collaborative software design has not yet
been studied extensively, and thus it is not fully understood how it is
conducted in practice. We have commenced a series of studies to address this.
As the first step, we have interviewed architects at a global software
solutions provider to observe how collaborative software design works in
practice. In this paper, we report the observations and insights we gained from
the interviews related to (1) the various roles of software architects in
collaborative software design, (2) the project-specific networks of software
architects, (3) the impacts of geographic distribution, and (4) the
collaboration cost drivers. We also discuss how we are using these insights to
shape up our subsequent research. Keywords: distributed processing; groupware; software architecture; collaboration cost drivers; collaborative software design; distributed engineering; geographic distribution; global software solutions; software architecture collaboration; software systems; Collaborative software; Computer architecture; Interviews; Organizations; Software; Topology | |||
| The rise and fall of a central contributor: Dynamics of social organization and performance in the GENTOO community | | BIBAK | Full-Text | 49-56 | |
| M. S. Zanetti; I. Scholtes; C. J. Tessone; F. Schweitzer | |||
| Social organization and division of labor crucially influence the
performance of collaborative software engineering efforts. In this paper, we
provide a quantitative analysis of the relation between social organization and
performance in Gentoo, an Open Source community developing a Linux
distribution. We study the structure and dynamics of collaborations as recorded
in the project's bug tracking system over a period of ten years. We identify a
period of increasing centralization after which most interactions in the
community were mediated by a single central contributor. In this period of
maximum centralization, the central contributor unexpectedly left the project,
thus posing a significant challenge for the community. We quantify how the
rise, the activity as well as the subsequent sudden dropout of this central
contributor affected both the social organization and the bug handling
performance of the Gentoo community. We analyze social organization from the
perspective of network theory and augment our quantitative findings by
interviews with prominent members of the Gentoo community which shared their
personal insights. Keywords: Linux; program debugging; public domain software; GENTOO community; Linux distribution; bug handling performance; bug tracking system; central contributor; collaboration dynamics; collaboration structure; collaborative software engineering; labor division; maximum centralization; network theory; open source community; social organization; Collaboration; Communities; Computer bugs; Network topology; Organizations; Peer-to-peer computing; Topology | |||
| Cooperation wordle using pre-attentive processing techniques | | BIBAK | Full-Text | 57-64 | |
| I. Fronza; A. Janes; A. Sillitti; G. Succi; S. Trebeschi | |||
| Developer turnover can result in a major problem when developing software.
Senior developers leaving the team cause a loss of knowledge; on the other
hand, new developers need some time to become fully productive. In this paper,
we propose to use a wordle to visualize quickly the level of cooperation of the
team in the project. Each word is the name of a class; the size of the word
depends on the total effort spent by the team on the corresponding class, and
the color is determined by the percentage of team working on the class. We
applied pre-attentive processing techniques in the designing phase, so that the
user can find out quickly those classes requiring high effort of a small part
of the team. This information allows to take corrective actions, such as
re-allocating some resources. Thus, this visualization can help in mitigating
the knowledge loss and the slowing down due to turnover. On the base of our
wordle, we describe four possible cases of development activities. A sample
application of our visualization, in the context of a multi-developer project,
shows concretely its potentials. We checked, through simulations, that the
interpretation of our wordles remains the same for color blind users. Keywords: handicapped aids; program visualisation; project management; resource allocation; software development management; team working; color blind observers; cooperation wordle; corrective actions; knowledge loss mitigation; multideveloper project; pre-attentive processing techniques; resource reallocation; software development; software visualization; team cooperation; team working; Color; Context; Data visualization; Image color analysis; Software; Team working; Visualization; Cooperation; Effort; Software visualization; Turnover; Visual perception; Wordle | |||
| Social media in transparent work environments | | BIBAK | Full-Text | 65-72 | |
| J. Tsay; L. Dabbish; J. D. Herbsleb | |||
| Social media is being integrated into work environments making them more
transparent. When the work environment is transparent, it has the potential to
allow projects to transmit information about work artifacts and events quickly
through a large network. Using signaling theory, we propose a theory that users
interpret this information and then make work-related decisions about attention
and effort allocation in a principled manner. In the open source context of
voluntary participation, broadcast activity information act as signals that
allow developers to make highly informed choices about where to expend their
attention and effort and with whom to collaborate. We propose four potential
signals from literature and interviews with developers in our research setting
and discuss the implications for social media in software development
environments. Keywords: decision making; multimedia computing; public domain software; social networking (online); software development management; broadcast activity information; decision making; information transmission; open source software; signaling theory; social media; software development environment; transparent work environment; voluntary participation; Communities; Electronic publishing; Information services; Interviews; Media; Production; Social network services; Social media; open source; signaling theory; social computing; software development; transparency | |||
| A qualitative study about the life cycle of lessons learned | | BIBAK | Full-Text | 73-76 | |
| D. Viana; J. Rabelo; T. Conte; A. Vieira; E. Barroso; M. Dib | |||
| Software activities are executed by people and demand great knowledge. For
this reason, knowledge dissemination activities are important in software
organizations. One of the ways of sharing knowledge is through the practice of
lessons learned dissemination. The form of dissemination could help to clarify
questions about how lessons learned are shared in the organization. This paper
aims to analyze the life cycle of lessons learned in a software organization,
in order to understand how they are treated during the course of the projects.
Results show that discussions of the lessons encourage the exchange of
knowledge between the team members. However, it is necessary to improve the
form of knowledge dissemination in all the organization, as well as encourage
learning this knowledge. Keywords: DP industry; knowledge management; project management; software management; team working; knowledge dissemination activities; knowledge exchange; knowledge sharing; lessons learned dissemination; lessons learned life cycle; project; software activities; software organizations; team members; Interviews; Knowledge management; Monitoring; Organizations; Registers; Software; Software engineering; Knowledge management; ethnography; interviews; lessons learned; qualitative analysis | |||
| A study of architectural decision practices | | BIBAK | Full-Text | 77-80 | |
| T. D. LaToza; E. Shabani; A. Van der Hoek | |||
| Architectural decisions shape a software architecture and determine its
ability to meet its requirements. To better understand architectural decisions
in practice, we interviewed developers at two organizations. The results
revealed that architectural decisions often become technology decisions, which
are in turn influenced by both technical and social factors. Meetings and
knowledge repositories help to communicate architectural decisions, but code
reviews are ultimately necessary to ensure conformance. Costly changes to
architectural decisions are caused by the discovery of an Achilles' heel, an
important scenario that cannot be supported by an architectural decision. These
findings suggest an important need for social development tools that help
developers more easily and successfully share valuable technology knowledge and
more effectively make technology choices. Keywords: organisational aspects; software architecture; software development management; Achilles heel; architectural decision practices; knowledge repositories; organizations; social development tools; social factors; software architecture; technical factors; technology choices; technology decisions; valuable technology knowledge; Companies; Computer architecture; Databases; Decision making; Software; Software architecture; architectural decisions; architecture; developer practices; empirical study | |||
| App-directed learning: An exploratory study | | BIBAK | Full-Text | 81-84 | |
| J. Sillito; A. Begel | |||
| Learning a new platform is a common, yet difficult task for software
developers today. A range of resources, both official resources (i.e., those
provided by the platform owner) and those provided by the wider developer
community are available to help developers. To increase our understanding of
the learning process and the resources developers use, we conducted an
interview and diary study in which ten developers told us about their
experience learning to develop Windows Phone applications. We report on a
preliminary analysis of our data viewed through the lens of self-directed
learning. Using this lens, we characterize the learning strategies of our
subjects as app-directed, and describe some of the particular challenges our
subjects faced due to this strategy. Keywords: learning (artificial intelligence); software engineering; Windows phone applications; app-directed learning; official resources; platform owner; resources developers; self-directed learning; software developers; Blogs; Communities; Context; Documentation; Encoding; Interviews; Software | |||
| Crowd development | | BIBAK | Full-Text | 85-88 | |
| T. D. LaToza; W. Ben Towne; A. Van der Hoek; J. D. Herbsleb | |||
| Crowd development is a development process designed for transient workers of
varying skill. Work is organized into microtasks, which are short,
self-descriptive, and modular. Microtasks recursively spawn microtasks and are
matched to workers, who accrue points reflecting value created. Crowd
development might help to reduce time to market and software development costs,
increase programmer productivity, and make programming more fun. Keywords: cost reduction; groupware; software engineering; time to market; crowd development; modular microtasks; programmer productivity; self-descriptive microtasks; short microtasks; software development cost reduction; time to market reduction; transient workers; Educational institutions; Games; Programming; Software; Software engineering; Testing; Transient analysis; crowdsourcing; distributed development; gamification; social software development | |||
| Improving developer participation rates in surveys | | BIBAK | Full-Text | 89-92 | |
| E. Smith; R. Loftin; E. Murphy-Hill; C. Bird; T. Zimmermann | |||
| Doing high quality research about the human side of software engineering
necessitates the participation of real software developers in studies, but
getting high levels of participation is a challenge for software engineering
researchers. In this paper, we discuss several factors that software
engineering researchers can use when recruiting participants, drawn from a
combination of general research on survey design, research on persuasion, and
our experience in conducting surveys. We study these factors by performing
post-hoc analysis on several previously conducted surveys. Our results provide
insight into the factors associated with increased response rates, which are
neither wholly composed of factors associated strictly with persuasion
research, nor those of conventional wisdom in software engineering. Keywords: software engineering; post-hoc analysis; software developer participation rates; software engineering researchers; survey design; Educational institutions; Electronic mail; Guidelines; Medical services; Psychology; Software; Software engineering; participation; software developers; surveys | |||
| What is social debt in software engineering? | | BIBAK | Full-Text | 93-96 | |
| D. A. Tamburri; P. Kruchten; P. Lago; H. van Vliet | |||
| "Social debt" in software engineering informally refers to unforeseen
project cost connected to a "suboptimal" development community. The causes of
suboptimal development communities can be many, ranging from global distance to
organisational barriers to wrong or uninformed socio-technical decisions (i.e.,
decisions that influence both social and technical aspects of software
development). Much like technical debt, social debt impacts heavily on software
development success. We argue that, to ensure quality software engineering,
practitioners should be provided with mechanisms to detect and manage the
social debt connected to their development communities. This paper defines and
elaborates on social debt, pointing out relevant research paths. We illustrate
social debt by comparison with technical debt and discuss common real-life
scenarios that exhibit "sub-optimal" development communities. Keywords: social aspects of automation; software engineering; global distance; organisational barriers; social aspects; social debt detection; social debt management; socio-technical decisions; software development; software engineering quality; suboptimal development communities; suboptimal development community; technical aspects; Collaboration; Communities; Companies; Open source software; Software engineering; Visualization; Global Software Engineering; Human Factors in Software Engineering; Social Communities; Social Debt; Social Networks; Social Structure; Software Architecture; Software Engineering; Technical Debt | |||
| On the development of a theoretical model of the impact of trust in the performance of distributed software projects | | BIBAK | Full-Text | 97-100 | |
| S. Marczak; V. Gomes | |||
| Trust is often defined as the belief that the trustee will meet the positive
expectations of the trustor. Although several studies have discussed the topic,
little is still known about the impact of trust (or lack of it) in the
performance of distributed software projects. In this paper we present initial
findings of an empirically informed study that aimed to identify which factors
influence positively or negatively one's perceived trustworthiness of others in
the project and the impact of such factors on specific project performance
measures. Availability, competence, expertise, face-to-face communication, and
leadership are among the factors considered to positively influence the
development of trust and the consequent achievement of performance metrics.
This is a first step on a larger investigation aiming to develop a theoretical
model of the impact of trust in the performance of distributed software
projects. Such a model can be used by researchers as a reference framework to
further investigate the topic and by practitioners to better manage and
organize distributed software teams. Keywords: distributed processing; software engineering; trusted computing; competence; distributed software project; expertise; face-to-face communication; leadership; project performance measures; trustworthiness; Availability; Companies; Instruments; Lead; Measurement; Productivity; Software; Distributed software development; empirical study; project performance; theoretical model; trust; trust influential factors | |||
| Toward social-technical code search | | BIBAK | Full-Text | 101-104 | |
| L. Martie; A. Van der Hoek | |||
| With the vast amount of source code that is publicly available today,
searching for code has become an integral part of the programming experience.
While a few dedicated code search engines are available, we contend in this
paper that they have not nearly reached their full potential. Particularly, we
believe that it is necessary for code search engines to not merely index code,
but also construct a rich network of social-technical information that
surrounds that code. With such information, much richer queries can be issued
and novel interfaces can be built through which the results of such queries can
be explored more intuitively. We make the case for social-technical code
search, introduce six categories of social-technical information and how it
would enhance search, and briefly introduce CodeExchange, our prototype
platform we are developing to explore social-technical code search. Keywords: query processing; search engines; software reusability; source coding; CodeExchange; code search engines; programming experience; richer queries; social-technical code search; social-technical information; source code; Conferences; Data mining; Java; Programming; Prototypes; Search engines; Software; IDE; code search; social-technical information | |||
| Exploring social structures in Extended Team Model | | BIBAK | Full-Text | 105-108 | |
| M. Zahedi; M. A. Babar | |||
| Extended Team Model (ETM) as a type of offshore outsourcing is increasingly
becoming popular mode of Global Software Development (GSD). There is little
knowledge about the social structures in ETM and their impact on collaboration.
Within a large interdisciplinary project to develop the next generation of GSD
technologies, we are exploring the role of social structures to support
collaboration. This paper reports some details of our research design and
initial findings about the mechanisms to support social structures and their
impact on collaboration in an ETM. Keywords: groupware; outsourcing; software engineering; ETM; GSD; extended team model; global software development; large-interdisciplinary project; offshore outsourcing; social structures; Buildings; Collaboration; Outsourcing; Resource management; Social network services; Software; Software engineering; Global software development; case study; extended team model; social networks; social structures | |||
| Towards collaboration-centric pattern-based software development support | | BIBAK | Full-Text | 109-112 | |
| C. Dorn; A. Egyed | |||
| Software engineering activities tend to be loosely coupled to allow for
flexibly reacting to unforeseen development complexity, requirements changes,
and progress delays. This flexibility comes a the price of hidden dependencies
among design and code artifacts that make it difficult or even impossible to
assess change impact. Incorrect change propagation subsequently results in
costly errors. This position paper proposes a novel approach based on
monitoring engineering activities for subsequent high-level pattern detection.
Patterns of (i) collaboration structures, (ii) temporal action sequences, and
(iii) artifact consistency constraints serve as input to recommendation and
automatic reconfiguration algorithms for ultimately avoiding and correcting
artifact inconsistencies. Keywords: groupware; software development management; artifact inconsistency constraint; automatic reconfiguration algorithm; code artifact; collaboration centric pattern-based software development; collaboration structure; design artifact; engineering activity monitoring; pattern detection; temporal action sequence; Adaptation models; Collaboration; Computer architecture; Software; Software engineering; Uncertainty; Unified modeling language; collaboration structures; monitoring; pattern detection; recommendation; software engineering | |||
| An examination of shared understanding in free/libre open source project maintenance | | BIBAK | Full-Text | 113-116 | |
| B. Braunschweig; C. Seaman | |||
| Many problems in software development are rooted in the difficulties of
coordination and communication in the software development team. Aranda's
Theory of Shared Understanding for Software Organizations explains the role of
shared understanding in coordination and suggests four attributes of team
interaction that influence shared understanding and, therefore, the quality of
coordination. To find evidence supporting this theory, we investigated cases of
rework in the bug fixing activities of a Free/Libre Open Source software
project. We look at the role of coordination breakdown in these cases of rework
and examine them in terms of the theory. We found overall coordination patterns
that are consistent with the Theory but we do not find evidence that a lack of
shared understanding was a factor of rework in the cases examined. Keywords: program debugging; public domain software; software maintenance; bug fixing activities; free open source software project maintenance; libre open source software project maintenance; shared understanding; software development; Communication channels; Electric breakdown; Maintenance engineering; Media; Open source software; Organizations; Coordination; Free and Open Source Software; Shared Understanding; Software Maintenance | |||
| Using experimental games to understand communication and trust in Agile software teams | | BIBAK | Full-Text | 117-120 | |
| E. Hasnain; T. Hall; M. Shepperd | |||
| Trust plays an important role in enabling software development teams to
function effectively. Trust between individual team members has been shown to
improve the independence of software teams and reduce the amount of project
management effort required by those teams. Our main aims are to investigate (i)
the impact communication has on trust between team members in Agile software
development and (ii) the usefulness of iterated games as an experimental
methodology. We use Game Theory in a simulated Agile development environment.
We run 28 iterated games with 56 practitioner and student participants.
Stand-up meetings are used as the communication intervention compared to games
without such meetings to assess the levels of trust. Our findings are that
increased communication has a very large positive effect upon the level of
trust between team members in an Agile setting. Our results suggest that
communication improves trust in development teams. Opportunities for
communication should be built into development processes. Experimental games
are a complementary (to qualitative approaches) and effective method for
investigating human issues in software engineering. Keywords: game theory; human factors; project management; security of data; software prototyping; agile software development teams; communication understanding; experimental games; game theory; human issues; iterated games; project management effort reduction; software engineering; software team independence improvement; trust understanding; Educational institutions; Game theory; Games; Linear matrix inequalities; Software; Software engineering; Standards; Agile Methods; Game Theory; Software engineering; communication; iterated experimental games; stand-up meetings; trust | |||
| Less is more: Architecture documentation for agile development | | BIBAK | Full-Text | 121-124 | |
| I. Hadar; S. Sherman; E. Hadar; J. J. Harrison | |||
| The use of agile development methodologies in the software industry has
increased significantly over the past decade. This has led to efforts to adjust
these methodologies to enterprise products and complex systems' development,
and specifically to combine the requirement of minimalism with the need for
well-defined up-front architecture artifacts. Nevertheless, in many cases,
architecture is accompanied with extensive documentation that requires
significant effort to review and maintain throughout the development lifecycle.
This paper presents a case study that aims at identifying difficulties
architects and other stakeholders encounter when dealing with architecture
documentation in agile development. The findings indicate that the architecture
specification document is usually very long, complex, and not self-explanatory.
In order to adjust the architecture documentation to the lean and minimal
documentation approach of agile processes, we propose a considerably shorter
abstract specification document, requiring reduced documentation efforts and
resulting in a lean documentation that is easier to review, update, and
communicate. Keywords: abstracting; formal specification; large-scale systems; software architecture; software houses; software prototyping; system documentation; abstract specification document; agile development; architecture documentation; architecture specification document; complex system development; development lifecycle; enterprise products; software industry; up-front architecture artifacts; Abstracts; Computer architecture; Documentation; Face; Information systems; Software; Software architecture; Software architecture in agile development; architecture documentation | |||
| How does Kanban impact communication and collaboration in software engineering teams? | | BIBAK | Full-Text | 125-128 | |
| N. Oza; F. Fagerholm; J. Munch | |||
| Highly iterative development processes such as Kanban have gained
significant importance in industry. However, the impact of such processes on
team collaboration and communication is widely unknown. In this paper, we
analyze how the Kanban process aids software team's behaviors -- in particular,
communication and collaboration. The team under study developed a mobile
payment software product in six iterations over seven weeks. The data were
collected by a questionnaire, repeated at the end of each iteration. The
results indicate that Kanban has a positive effect at the beginning to get the
team working together to identify and coordinate the work. Later phases, when
the team members have established good rapport among them, the importance for
facilitating team collaboration could not be shown. Results also indicate that
Kanban helps team members to collectively identify and surface the missing
tasks to keep the pace of the development harmonized across the whole team,
resulting into increased collaboration. Besides presenting the study and the
results, the article gives an outlook on future work. Keywords: electronic money; kanban; mobile computing; project management; software development management; team working; Kanban process; highly iterative development process; kanban; mobile payment software product; software engineering team; software team behavior; team collaboration; team communication; team members; team working; work coordination; Collaboration; Correlation; Industries; Production facilities; Software; Software engineering; Team working; Kanban; human factors in software development; software project management; software teams; team behaviors | |||
| Motivations for collaboration in software design decision making | | BIBAK | Full-Text | 129-132 | |
| A. Alali; J. Sillito | |||
| Software design is a result of software design decisions made at different
stages of the development process and these decisions are often made
collaboratively. As part of an ongoing research project to understand and
improve this collaborative process we have interviewed 13 designers about their
design processes. In this paper we report on a preliminary analysis of our
interview data focusing on why people collaborate around design decisions. We
found that designers collaborate to improve their design decisions, save or
share decision making effort, and in response to social or organizational work
contexts. Keywords: decision making; groupware; software engineering; collaborative process; development process; organizational work context; social work context; software design decision making; Collaboration; Context; Decision making; Interviews; Organizations; Software design; Collaboration; Software Design Decision Making | |||
| Soft skills in software engineering: A study of its demand by software companies in Uruguay | | BIBAK | Full-Text | 133-136 | |
| G. Matturro | |||
| Software development requires professionals with knowledge and experience on
many different methodologies, tools, and techniques. However, the so-called
soft skills, such as interpersonal skills, teamwork, problem solving and
customer orientation to name just a few, are as important as, or even more
important, than traditional qualifications and technical skills. In this paper
we review a set of jobs advertisements offering job positions related to
software engineering in order to identify what soft skills are most in demand
by software companies in Uruguay. We also compare our findings with the ones
reported in other recent studies carried out with data from other countries.
This comparison shows that evidence exists about a common set of basic soft
skills software companies demand when looking for new staff for software
engineering activities. Keywords: organisational aspects; personnel; software development management; Uruguay; customer orientation; interpersonal skills; job advertisements; problem solving; soft skills; software companies; software development; software engineering activities; teamwork; technical skills; Companies; Problem-solving; Software design; Software engineering; Software testing; Teamwork; Soft skills; software engineering | |||
| A descriptive classification for end user-relevant decisions of large-scale IT projects | | BIBAK | Full-Text | 137-140 | |
| U. Abelein; B. Paech | |||
| Large-scale IT projects with traditional development methods are still very
common in practice. These projects mostly involve the end user in the beginning
and at the end of the development. However, there are also user-relevant
decisions in the phases between. Thus, it is important to investigate what
decisions are made and which of them are user-relevant. Thus we suggested in
our previous work a preliminary classification based on the TORE method to
structure decisions. In this paper, we validate this classification and
collected exemplary user-relevant decisions by experts in large-scale IT
projects. As part of our research in user-developer communication, we conducted
an interview series with twelve experts. The interviews confirmed that our
previously suggested classification is comprehensive and helpful to structure
decisions and revealed several amendments. The examples given by the experts
enabled us to collect a comprehensive list of end user-relevant decisions, and
thus lead to our descriptive classification. Keywords: software engineering; systems analysis; TORE method; UPI; descriptive classification; end user-relevant decisions; interview series; large-scale IT projects; software development methods; structure decisions; task-oriented requirement engineering; user participation and involvement; user-developer communication; Contracts; Industries; Insurance; Interviews; Manuals; Standards; Expert Interviews; Software Development; User Involvement; User Participation; User-Developer Communication | |||
| Aduno: Real-time collaborative work design in a shared workspace | | BIBAK | Full-Text | 141-144 | |
| B. Simpson; E. Kalliamvakou; N. Lambert; D. Damian | |||
| In this paper we describe the design and evaluation of Aduno, a shared
workspace tool that allows distributed software teams to collaboratively
establish and prioritize work items for the purposes of task management and
planning during the design phase. Aduno is highly visual and real-time,
offering features that are often lacking from other popular collaborative
development tools. Aduno also links to Github's issue tracker and easily
translates work items on a whiteboard to project work items. Here, we describe
the concept and design of Aduno and present its initial evaluation. Keywords: groupware; planning; software development management; software tools; task analysis; Aduno; collaborative development tool; distributed software; real-time collaborative work design; shared workspace tool; task management; task planning; whiteboard; Collaborative software; Collaborative work; Real-time systems; Software; Visualization | |||
| The need of a person oriented approach to software process assessment | | BIBAK | Full-Text | 145-148 | |
| A. Sampaio; I. B. Sampaio; E. Gray | |||
| This paper represents a coherent critique of software process assessment,
focusing on the concerns and perceived shortcomings present. A call is made to
re-direct attention and resources toward understanding the true nature of
people in software process assessment. The important, possibly crucial role of
people at an individual, team-based and organizational level in the assessment
process that precedes software process improvement is discussed by considering
such factors as the relationship between a person's perception of the software
process, the learning process and motivation and using theory and empirical
findings published in the literature. It is suggested that the poor recognition
of the many human factors may be a major reason why the software process is so
difficult to improve. It is argued that the clarification of such important
issues will help to achieve a significant step forward in software process
assessment and improvement; and lead to significant improvements in quality,
satisfaction and performance. In order to systematize our position and future
research, several statements are formulated concerning the importance of
people. Keywords: human factors; software process improvement; human factor recognition; learning process; motivation; person oriented approach; software process assessment; software process improvement; Biological system modeling; Educational institutions; Organizations; Presses; Psychology; Software; Standards organizations; human oriented; involvement; motivation; perception; software process | |||
| Understanding cheap talk and the emergence of trust in global software engineering: An evolutionary game theory perspective | | BIBAK | Full-Text | 149-152 | |
| Yi Wang; D. Redmiles | |||
| While studying global software engineering teams, we found that informal
non-work related conversations are positively associated with trust. We sought
to investigate this phenomenon more carefully. To this end, we employed
evolutionary game theory. In that literature, the kind of non-work related
conversations we observed are referred to as "cheap talk". We modified the
original Stag-hunt game, and have it "play" repeatedly by a fixed population.
Doing so, we are able to demonstrate how cheap talk in remote collaborations
over the Internet is powerful enough to facilitate the emergence of trust and
improve the probability of collaboration. We elaborate on the conditions for
success and discuss both theoretical and practical implications of our findings
for collaboration. Keywords: game theory; probability; security of data; software engineering; cheap talk understanding; collaboration probability improvement; evolutionary game theory; global software engineering teams; informal nonwork related conversations; remote collaborations; stag-hunt game; trust emergence; Collaboration; Game theory; Games; Internet; Mathematical model; Sociology; Statistics; Cheap talk; Evolution Game Theory (EGT); Global Software Engineering (GSE); Stag-hunt game; trust | |||
| Meeting intensity as an indicator for project pressure: Exploring meeting profiles | | BIBAK | Full-Text | 153-156 | |
| O. Liskin; K. Schneider; S. Kiesling; S. Kauffeld | |||
| Meetings are hot spots of communication and collaboration in software
development teams. Both distributed and co-located teams need to meet for
coordination, communication, and collaboration. It is difficult to assess the
quality of these three crucial aspects, or the social effectiveness and impact
of a meeting: Personalities, psychological and professional aspects interact.
It is, therefore, challenging to identify emerging communication problems or to
improve collaboration by studying a wealth of interrelated details of project
meetings. However, it is relatively easy to count meetings, and to measure when
and how long they took place. This is objective information, does not violate
privacy of participants, and the data might even be retrieved from project
calendars automatically. In an exploratory study, we observed 14 student teams
working on comparable four-month projects. Among many other aspects, we counted
and measured meetings. In this contribution, we compare the meeting profiles
qualitatively, and derive a number of hypotheses relevant for software
projects. Keywords: project management; software management; team working; co-located team; distributed team; meeting intensity; meeting profiles; objective information; project calendars; project meetings; project pressure; social effectiveness; software development teams; software projects; student teams; Calendars; Collaboration; Electronic mail; Logic gates; Programming; Software; Software engineering; meeting culture; software development; team communication | |||
| Agile offsharing: Using pair work to overcome nearshoring difficulties | | BIBAK | Full-Text | 157-158 | |
| L. Prechelt | |||
| A major problem in distributed development situations, in particular
offshoring situations, is often creating a proper understanding of the
requirements at the remote site. It is difficult even if such understanding is
available at the local site. This note argues why cross-site, synchronous,
closely-coupled pair work at an engineering level, such as pair programming,
may be a method for solving this problem and that corresponding research should
be carried out. Keywords: outsourcing; software development management; software prototyping; agile offsharing; cross-site synchronous closely-coupled pair; distributed development situations; local site; nearshoring difficulties; pair programming; pair work; remote site; Collaboration; Companies; Couplings; Joints; Programming; Software | |||
| Analyzing the friendliness of exchanges in an online software developer community | | BIBAK | Full-Text | 159-160 | |
| B. Cleary; C. Gomez; M.-A. Storey; L. Singer; C. Treude | |||
| Many online communities struggle with conflicts -- e.g. between newcomers
and elders -- at some point. In July 2012, the Stack Exchange organization
attempted to assess the overall "niceness" of the Stack Overflow community by
rating the "friendliness" of 7,000 comments made on the site over a 4 year
period. We performed a deeper examination of the comment dataset published by
Stack Exchange. We find a high degree of comment repetition in the Stack
Overflow database and suggest some simple heuristics that may help in
automatically identifying unfriendly comments, providing managers of developer
communities with simple means that could counter hostility. Keywords: Web sites; human computer interaction; software engineering; Stack Exchange friendliness analysis; Stack Exchange organization; Stack Overflow community; Stack Overflow database; automatic unfriendly comment identification; comment dataset; comment repetition degree; developer community managers; heuristics; online software developer community; Buildings; Communities; Databases; Educational institutions; Organizations; Software; Vocabulary | |||