Practitioner Tools and Workstyles for User-Interface Design

Many studies have analyzed general software development practices and how organizations can better support them. However, literature that qualitatively studies user-interface-related work practices in software development is relatively rare. Supporting workstyle transitions in UI practices is nonetheless important. A survey of 370 practitioners about their workstyles and tool use offers concrete examples of design tools that support the most important workstyle transitions. The survey also resulted in recommendations for making design tools more human-centric and appealing to practitioners interested in the UI aspects of software development     

Evidence-based software engineering for practitioners

Software managers and practitioners often must make decisions about what technologies to employ on their projects. They might be aware of problems with their current development practices (for example, production bottlenecks or numerous defect reports from customers) and want to resolve them. Or, they might have read about a new technology and want to take advantage of its promised benefits. However, practitioners can have difficulty making informed decisions about whether to adopt a new technology because there's little objective evidence to confirm its suitability, limits, qualities, costs, and inherent risks. This can lead to poor decisions about technology adoption. Software engineers might make incorrect decisions about adopting new techniques it they don't consider scientific evidence about the techniques' efficacy. They should consider using procedures similar to ones developed for evidence-based medicine. Software companies are often under pressure to adopt immature technologies because of market and management pressures. We suggest that practitioners consider evidence-based software engineering as a mechanism to support and improve their technology adoption decisions.     

The software design studio: an exploration

Some software designers have recently turned for inspiration to the process of building design to improve development practices and increase software's usefulness and effectiveness. Architects' education revolves around the studio course, which promotes: project based work on complex and open ended problems; very rapid iteration of design solutions; frequent formal and informal critique; consideration of heterogeneous issues; the use of precedent and thinking about the whole; the creative use of constraints; and the central importance of design media. M. Kapor (1991) suggested that software practitioners needed to “rethink the fundamentals of how software is made” and proposed the architect's role in building design as a fruitful analogy for software professionals seeking to reform software practice. This analogy helps us focus on usefulness, usability, user needs and practices, and other technical and nontechnical aspects of good software design. It highlights concerns about people's lives and work practices and how people “inhabit” systems. Several authors have explored similarities and differences between software design and building design, including some who have pursued the software implications of architect Christopher Alexander's design patterns     

Software Process Improvement barriers: A cross-cultural comparison

ContextSoftware Process Improvement initiatives have been around for many years with the growing globalisation of software development is making them increasingly important.ObjectiveThe objective of this exploratory research is to gain an in-depth understanding of barriers that can undermine SPI, in the context of Global Software Development, from the perspective of software development practitioners; this will enable SPI managers to better manage SPI initiatives. We intend to discover if the barriers to SPI initiatives in a developed country are different to those in a developing country.MethodIn an empirical study, Vietnamese software practitioners’ experiences of SPI barriers are compared with barriers identified by Australian practitioners. Face-to-face questionnaire-based survey sessions with 23 Vietnamese SPI practitioners were conducted. Our survey included barriers to SPI improvement initiatives identified in previous research. We asked the participants to rank each SPI barrier on a three-point scale (high, medium, low) to determine the importance of each barrier. We then compare our results, with results (identified in previous work), from 34 Australian software development practitioners.ResultsWe identify (1) lack of project management, (2) lack of resources, (3) lack of sponsorship, (4) inexperienced staff/lack of knowledge, and (5) lack of SPI awareness as ‘high’ value SPI barriers in Vietnam. The results also reveal similarities and differences between the experiences of Australian and Vietnamese practitioners regarding the importance of the SPI barriers identified. While the Australian practitioners were also concerned with (1) lack of SPI awareness, they were even more concerned with (2) organisational politics, and (3) lack of support.ConclusionsPractitioners identify SPI barriers based on previous SPI implementation experience. Their role(s) in their different organisations have helped them to understand the importance of that barrier. Vietnamese software practitioners cited more SPI barriers than their counterparts in Australia. The Vietnamese SPI barriers relate to project management, resources, and sponsorship while the Australian barriers are concerned with organisational politics and lack of support.     

Quality attribute trade-offs in the embedded systems industry: an exploratory case study

The embedded systems domain has grown exponentially over the past years. The industry is forced by the market to rapidly improve and release new products to beat the competition. Frenetic development rhythms thus shape this domain and give rise to several new challenges for software design and development. One of them is dealing with trade-offs between run-time and design-time quality attributes. To study practices, processes and tools concerning the management of run-time and design-time quality attributes as well as the trade-offs among them from the perspective of embedded systems software engineers. An exploratory case study with two qualitative data collection steps, namely interviews and a focus group, involving six different companies from the embedded systems domain with a total of twenty participants. The interviewed subjects showed a preference for run-time over design-time qualities. Trade-offs between design-time and run-time qualities are very common, but they are often implicit, due to the lack of adequate monitoring tools and practices. Practitioners prefer to deal with trade-offs in the most lightweight way possible, by applying ad-hoc practices, thus avoiding any overhead incurred. Finally, practitioners have elaborated on how they envision the ideal tool support for dealing with trade-offs. Although it is notoriously difficult to deal with trade-offs, constantly monitoring the quality attributes of interest with automated tools is key in making explicit and prudent trade-offs and mitigating the risk of incurring technical debt.     

Aligning the economic modeling of software reuse with reuse practices

In contrast to current practices where software reuse is applied recursively and reusable assets are tailored trough parameterization or specialization, existing reuse economic models assume that (i) the cost of reusing a software asset depends on its size and (ii) reusable assets are developed from scratch. The contribution of this paper is that it provides modeling elements and an economic model that is better aligned with current practices. The functioning of the model is illustrated in an example. The example also shows how the model can support practitioners in deciding whether it is economically feasible to apply software reuse recursively.     

Qualitative methods in empirical studies of software engineering

While empirical studies in software engineering are beginning to gain recognition in the research community, this subarea is also entering a new level of maturity by beginning to address the human aspects of software development. This added focus has added a new layer of complexity to an already challenging area of research. Along with new research questions, new research methods are needed to study nontechnical aspects of software engineering. In many other disciplines, qualitative research methods have been developed and are commonly used to handle the complexity of issues involving human behaviour. The paper presents several qualitative methods for data collection and analysis and describes them in terms of how they might be incorporated into empirical studies of software engineering, in particular how they might be combined with quantitative methods. To illustrate this use of qualitative methods, examples from real software engineering studies are used throughout     

Can software risk management improve system development: an exploratory study

Software risk management can be defined as an attempt to formalise risk oriented correlates of development success into a readily applicable set of principles and practices. Earlier research suggests that it can reduce the likelihood of a system failure. Using a survey instrument we investigate this claim further. The investigation addresses the following questions: (1) which characteristics of risk management practices; and (2) which other environmental and process factors (such as development methods, manager's experience) relate to improved performance in managing software risks? Our findings support in general the claim that the use of risk management methods improves system development performance. Yet, little support was found for the claim that specific risk management methods are instrumental in attacking specific software risks. Overall, risks are better managed with combined measures of having experienced project managers, selecting a correct project size, and investing in and obtaining experience in risk management deliberations.     

Adopting a software security improvement program

Leading software shops (including Microsoft) are working hard to improve the way they build security into their products. Software security initiatives have proven beneficial for those organizations that have implemented them. Such initiatives involve the adoption and rollout of various types of best practices. The article describes an approach that works, with an emphasis on business process engineering that might be unfamiliar to technical practitioners. By following some commonsense steps, a software security improvement program has a greater chance of achieving its ultimate goal: software security that makes business sense.     

Challenges of working with artifacts in requirements engineering and software engineering

When developing or evolving software systems of non-trivial size, having the requirements properly documented is a crucial success factor. The time and effort required for creating and maintaining non-code artifacts are significantly influenced by the tools with which practitioners view, navigate and edit these artifacts. This is not only true for requirements, but for any artifacts used when developing or evolving systems. However, there is not much evidence about how practitioners actually work with artifacts and how well software tools support them. Therefore, we conducted an exploratory study based on 29 interviews with software practitioners to understand the current practice of presenting and manipulating artifacts in tools, how practitioners deal with the challenges encountered, and how these challenges affect the usability of the tools used. We found that practitioners typically work with several interrelated artifacts concurrently, less than half of these artifacts can be displayed entirely on a large screen, the artifact interrelationship information is often missing, and practitioners work collaboratively on artifacts without sufficient support. We identify the existing challenges of working with artifacts and discuss existing solutions proposed addressing them. Our results contribute to the body of knowledge about how practitioners work with artifacts when developing or evolving software, the challenges they are faced with, and the attempts to address these challenges.     

Architecture reviews: practice and experience

Architecture reviews have evolved over the past decade to become a critical part of our continuing efforts to improve the state of affairs. We use them to identify project problems before they become costly to fix and to provide timely information to upper management so that they can make better-informed decisions. It provides the foundation for reuse, using commercially available software, and getting to the marketplace fast. The reviews also help identify best practices to projects and socialize such practices across the organization, thereby improving the organization's quality and operations.     

Toward the characterization of software testing practices in South America: looking at Brazil and Uruguay

Software testing is an important activity in the software development life cycle. Several previous studies reported the results of surveys on software testing practices among practitioners from different countries. In this paper, we analyze these surveys aiming to get their main questions, and replicate a survey with practitioners from Brazil and Uruguay, two emerging South American software development scenarios. This survey was previously conducted in Manaus/Brazil in 2006 and Buenos Aires/Argentina in 2013. The replication’s scope includes three regions (Northern Brazil, Southern Brazil, and Uruguay). A total of 150 software testing practitioners responded to the survey. Its results are compared with the previous executions and other software testing surveys identified in the technical literature, strengthening previous findings. The Brazilian and Uruguayan participants indicate that: (1) documentation of test artifacts (plan, cases, procedures, results) are useful and important for software testing practitioners; (2) system and regression testing are the two test types deemed most useful and important; (3) tools for monitoring and management of test process tasks and bug reports are considered useful and important; (4) it is usual for software companies to have a definition of a testing process and to have a dedicated testing team; (5) there is a lack of measurement of test tasks and coverage in the industry; and (6) tools to support automation of test case generation and execution or code coverage are still poorly used in their organizations.     

Patterns as a paradigm for theory in community-based learning

Learning about information technology is typically not a first-order goal for community-based volunteer organizations. Nonetheless, information technology is vital to such groups for member recruiting and management, communication and visibility to the community, and for primary group activities. During the past 12 years, we have worked with community groups in Centre County, Pennsylvania, and Montgomery County, Virginia. We have built partnerships with these groups to better understand and address their learning challenges with respect to information technology. In this paper, we suggest that patterns, standard solution schemata for recurring problems (as used in architecture and software engineering, among other design domains), can be a paradigm for codifying and developing an understanding of learning in and by community organizations. Patterns are middle-level abstractions; they capture regularities of practices in ways that are potentially intelligible, verifiable, and perhaps useful to the practitioners themselves. We present two example patterns and discuss issues and directions for developing patterns as a theoretical foundation for community-based learning.     

Bottom up process improvement tricks

Most everyone in our field acknowledges that software process improvement cannot succeed unless management is committed to implementing it. Fortunately, the move to SPI can be a two-way street, initiated as easily from the bottom up as from the top down. Taking this bottom-up approach, I present some tricks that practitioners down in the trenches can use to win upper management's approval of and support for SPI     

A comparative study of software tools for user story management

ContextUser stories have become widely accepted in agile software development. Consequently, a great number of software tools that provide, inter alia, support for practices based on user stories have emerged in recent years. These tools may have different features and focus in terms of support for agile requirements engineering (RE) concepts and practices.ObjectiveThe present study aims to provide a deep insight into the current capabilities and future trends of software support for agile RE practices based on user stories.MethodA comparative qualitative study of a set of agile software tools has been conducted according to the following criteria: coverage of the key functional requirements, support for basic agile RE concepts and practices, and user satisfaction with the tool. The criteria for tool selection were: diversity of software tools, high rating on the user-stories community Web site (http://www.userstories.com), and availability for review.ResultsThe results show a generally good coverage of key functional requirements related to management of user stories and epics, high-level release planning and low-level iteration planning. On the other hand, user-role modeling and persona support have not been addressed at all, and it has been found that requirements for acceptance testing support were completely covered by only one tool. More importantly, the study has revealed significant differences in the way different tools support agile RE concepts and practices (if at all). Finally, qualitative analysis of user reviews has demonstrated that practitioners prefer tools that are easy to set up, easy to learn, easy to use, and easy to customize, over more sophisticated but simultaneously more demanding tools.ConclusionAlthough the progress that has been made since the inception of these tools is quite clear, there is still room for improvements in terms of support for various agile RE practices within a specific agile process.     

Comparison of multi-criteria decision analytical software for supporting environmental planning processes

In this paper, we analyze 23 multi-criteria decision analysis software tools in terms of their applicability to support environmental planning processes. Our aim is to survey what kind of software is available, and compare the features they provide to meet the characteristics of environmental problems. Our focus is on useful or innovative features of the software from the viewpoint of supporting practitioners to systematically analyze and compare alternatives in environmental planning. The results can be utilized for selecting the most suitable software for supporting the needs of the environmental cases, but also for identifying good practices and innovative implementation solutions for software development.     

Why software developers refuse to improve

Many developers fail to acknowledge that there are more productive environments. When a software organization loses a bidding contest, the losers roll their eyes heavenward and tell each other, “Better luck next time”. Well, this is the reality: There are software development organizations that are more productive than others. “Luck” is not the whole story; you need to look for ways to improve. Use valid process; there are a dozen or so well-regarded methodologies. We especially need to reach two audiences. Sponsors, those who finance new ideas, need information tailored to the functions they perform in adopting and financing new ways of working. Practitioners those actually applying the new ideas, need detailed books, manuals, short courses, helpful supervision, and mentoring. They also need software tools to do what tools can do better than people. Even after simplification, there will still be a lot of changes to implement. Leading companies understand that implementation takes: Investment money up front (sometimes for years before payback begins); a champion; dedicated people, and consistent management, dedicated to long-term financial support. The accomplishment to which the idea leads has to be evident to all, and demonstrated by some type of metrics. The ultimate drivers that influence practitioners and management alike to sue a difficult course are results that establish the course's success     

Processes versus people: How should agile software development maturity be defined?

Maturity in software development is currently defined by models such as CMMI-DEV and ISO/IEC 15504, which emphasize the need to manage, establish, measure and optimize processes. Teams that develop software using these models are guided by defined, detailed processes. However, an increasing number of teams have been implementing agile software development methods that focus on people rather than processes. What, then, is maturity for these agile teams that focus less on detailed, defined processes? This is the question we sought to answer in this study. To this end, we asked agile practitioners about their perception of the maturity level of a number of practices and how they defined maturity in agile software development. We used cluster analysis to analyze quantitative data and triangulated the results with content analysis of the qualitative data. We then proposed a new definition for agile software development maturity. The findings show that practitioners do not see maturity in agile software development as process definition or quantitative management capabilities. Rather, agile maturity means fostering more subjective capabilities, such as collaboration, communication, commitment, care, sharing and self-organization.     

Usability Meanings and Interpretations in ISO Standards

The usability of a software product has recently become a key software quality factor. The International Organization for Standardization (ISO) has developed a variety of models to specify and measure software usability but these individual models do not support all usability aspects. Furthermore, they are not yet well integrated into current software engineering practices and lack tool support. The aim of this research is to survey the actual representation (meanings and interpretations) of usability in ISO standards, indicate some of existing limitations and address them by proposing an enhanced, normative model for the evaluation of software usability.     

Integrating Process and Project Management for Multi-Site Software Development

Recent advances in information technology have made Internet-based collaboration much easier. It is now possible for a software team to draw on talented developers from around the world without the need to gather them together physically. However, being able to tap into a large pool of talent does not guarantee success. Software managers have to be able to manage these distributed teams. They need to define sharper processes and ensure that they are followed. They also need to better control project execution. To do so effectively, we have developed a tool that integrates features for both project and process management. Existing project management tools were originally designed for projects on a single site. Many of them do not provide the features necessary to support cooperative multi-site software projects or process management. We have developed a tool, called IPPM, which supports these features. IPPM, which integrates features for process and project management, resolves differences between existing project and process tools, and provides a number of unique features to support multi-site development. IPPM has been implemented and used by several development teams working in different regions in Hong Kong and Mainland China.