Search

The capacity to reflect on past practice is important for continuous learning in software development. Reflection often takes place in cycles of experience followed by conscious application of learning from that experience, during which a software developer might explore comparisons, ponder alternatives, take diverse perspectives, and draw inferences, especially in new and/or complex situations. Such reflective practice has been shown in different disciplines to be an effective developmental practice for organizations, for teams, and for individuals. The guest editors of this special issue on reflection describe the concept in general and the selected articles in particular. [ABSTRACT FROM PUBLISHER]

The theoretical underpinnings of agile principles emphasize regular reflection as a means to attain a sustainable development pace and continuous learning. In practice, high iteration pressure can diminish opportunities for ongoing learning and reflection threatening to deprive software teams of learning and reflection and possibly stagnating process evolution. The Reflective Agile Learning Model (REALM) combines insights and results from studies of agile development practices in India, New Zealand, and the US with Schön's theory of reflective practice. Using REALM, agile teams can establish self-organized learning as well as regular process maintenance and opportunities for process evolution to continuously improve practice. [ABSTRACT FROM PUBLISHER]

Developers of embedded systems are driven to constantly improve product quality, reduce cost, and rapidly deliver reliable working code. The embedded software domain applies constraints which can hinder agile methodologies commonly used to achieve such benefits. Simulation-based software development is one proven method that addresses these constraints. When tailored to work in conjunction with agile principles, simulation centric development facilitates meeting product goals. In this article, the authors discuss techniques for leveraging software-in-simulation (SiS) in conjunction with agile methodologies, and illustrate how combining agile with SiS contributes to gaining more benefit from agile practices and facilitates better software development. [ABSTRACT FROM PUBLISHER]

The SATURN Conference is an international forum for software engineers and anyone else interested in software architecture. SATURN regularly partners with IEEE Software, a relationship that continues to offer strong content on both sides. [ABSTRACT FROM PUBLISHER]

It was May 2010 when my "call for insights" first appeared in this magazine. For nearly four years, you, gentle readers, have responded to that call and have shared your experiences, challenges, and learnings. I appreciate all of you who submitted, who revised and responded to shepherding, but especially, all who stayed the course and produced a published article. This article is my farewell to the series, but it will continue on even though I'm no longer steering it. If you haven't yet submitted something for publication, I encourage you to do that. We need to hear your insights! [ABSTRACT FROM PUBLISHER]

The challenges issued by next-generation mobile communication scenarios clearly emphasize the inadequacy of traditional communication solutions in supporting efficient mobile and pervasive applications. Research so far has focused on higher-layer middleware or on the optimization of TCP-based solutions for wireless environments, but there's an obvious need to focus on communication middleware that can provide the right set of concepts and tools to support future applications. [ABSTRACT FROM PUBLISHER]

Usually we read about agile development practices that seem like no more than hand waving. If that's how you feel, you'll enjoy traveling this detailed design journey and seeing up close how test-driven development (TDD) and refactoring are done in an agile environment. This article is especially insightful because of the collaborative shepherding by Rebecca Wirfs-Brock. [ABSTRACT FROM PUBLISHER]

Agility without objective governance cannot scale, and governance without agility cannot compete. Agile methods are mainstream, and software enterprises are adopting these practices in diverse delivery contexts and at enterprise scale. IBM's broad industry experience with agile transformations and deep internal know-how point to two key principles to deliver sustained improvements in software business outcomes with higher confidence: measure and streamline change costs, and steer with economic governance and Bayesian analytics. Applying these two principles in context is the crux of measured improvement in continuous delivery of smarter software-intensive systems. This article describes more meaningful measurement and prediction foundations for economic governance. The Web extra at http://youtu.be/ghAM8ifyeVI is a video in which Walker Royce, author, IEEE Software editorial board member, and IBM Chief Software Economist, describes how to reason about software delivery governance with lean principles. [ABSTRACT FROM PUBLISHER]

Agile processes seek "just enough" requirements. However, this focus on simple software solutions can come at the expense of solutions that meet more creative requirements. To explore alternatives, this article reports results from extending one agile process with creativity techniques in a project for a large media organization. Domain experts ranked the requirements generated with the process as more novel than baseline epics from the product backlog of the same project, while the requirements' usefulness increased overall after incubation over the duration of a sprint. [ABSTRACT FROM PUBLISHER]

A personal narrative is presented which explores the author's experience of training people about agile software development through storytelling in presentations. The article further discusses guidelines for crafting a story by discussing two stories entitled "The Castle Fairy Tale" and "A Soviet Economist in Rotterdam." Information about the author of the article is also presented. INSETS: CRAFTING A STORY: GUIDELINES FOR DOING IT YOURSELF;EXAMPLE 1: THE CASTLE FAIRY TALE;EXAMPLE 2: A SOVIET ECONOMIST IN ROTTERDAM.

Agile teams create business value by responding to changing business environments and delivering working software at regular intervals. While doing so, they make design tradeoffs to satisfy business needs such as meeting a release schedule. Technical debt is the result of such decisions or tradeoffs. When this happens, agile teams must pay off the accumulated debt by improving designs during subsequent iterations in order to improve maintainability. This must happen in a systematic way so that technical debt does not swell up and damage the project. Accomplishing this is one of the major challenges in distributed agile projects. The scope of technical debt in software projects is spread across all areas including architecture, design, code, and test scripts. [ABSTRACT FROM PUBLISHER]

Proponents of various processes and methods in the agile and lean communities have made many bold claims about usefulness, but those claims are rarely supported by empirical investigations. Data gathered from more than 12,000 work items collected over two years sheds light on Kanban versus Scrum.To acquire more knowledge about the performance of different agile or lean methods, scholars should conduct similar studies in different organizations in different application domains and with people of different cultures and competences. [ABSTRACT FROM PUBLISHER]

“Lean Software Development” has become a popular term over the last few years. This tutorial describes where it comes from, what it means, how it relates to well-known agile development practices, and how it will evolve in the future. [ABSTRACT FROM PUBLISHER]

The article discusses the relationship of agile and architecture practices in balancing business and architectural priorities. The author says that agile development and architecture work together in software development. He explains the agile methods that simplify development which will help a skilled architect to meet the needs of the present business and attain technically stable business for years to come.

The author focuses on services offered by software architects in collaboration with developers and their importance in agile development projects. The author emphasizes that software architects should provide appropriate documentation along with direct communication with the customer in order to succeed. An overview of the architecture process which requires preparation and support is also discussed.

The article explains the impact of agile software development on industrial software development practices. The author mentions that agile software development does not pay sufficient attention to software architecture. He cites that this method applies to domains such as automobiles, telecommunications, finance and medical devices which require large software intensive systems. Also cited are multiple levels to understanding the conflict between agile development and architecture.

The article offers information on agile software development. The concept is developed in response to plan-based or traditional methods. The authors examine the benefits and limitations of agile methods to determine its effectiveness. Three overviews conducted in 2002, 2004, and 2005 are presented to discuss the concept of agile development and to describe its status based on the lessons learned from the applications of various agile methods. The authors also present a comparative study of traditional and agile software developments.

The article discusses the application of an Extreme Programming-inspired (XPI) software framework to the development of embedded system software. The usefulness of the XPI framework in the life cycle and testing of embedded systems is noted. The authors' experience in using a prototype test-driven development (TDD) test framework to work with embedded systems in undergraduate classes and research work is also noted, mentioning that the TDD environment allowed students to apply basic agile concepts more effectively than industrial firms which do not use the TDD environment.

The article focuses on the booming market for application life-cycle management (ALM) tools for agile development. It presents categories of vendors and tools within the market such as the full life-cycle management tools offered by Rally and VersionOne, the agile ALM tool used as a consulting component by ResultSpace and the ALM Plug-ins such as the GreenHopper solution sold by Pyxis Technologies and Microsoft's Team Foundation Server (TFS). It mentions that software as a service (SaaS) is a major driver for the agile development industry.

The article offers information on how to manage agile project requirements through storytest-driven development, a complementary form of test-driven development applied to overall system development. It discusses the use of FitLibrary, a wiki-based tool that supports storytests, in easing storytest-driven development which draws requirements and automated testing ideas and practices to support agile software development. The author describes storytest-driven development practices and presents storytest examples developed with FitLibrary. In addition, the process of structuring storytests and the challenges in storytest-driven development are presented.

The article examines an empirical study which focuses on the requirements engineering (RE) practices employed by agile software developers and the benefits and challenges posed by these practices. It discusses an analysis of data from 16 software development organizations which reveals seven agile RE methodologies. The study has two phases including the carrying of case studies in 10 organizations involved in high-speed software development and the taking of data from six organizations which used Extreme Programming and Scrum. The study analyzes the difference between agile RE and traditional RE and suggests that the intensive communication between the developers and customers is the most important RE practice.

The article presents the author's comment on issues concerning the agile software development. The author argues that the agile software development is showing signs of saturation. He insists that like any other business trends, software engineers must keep the agile software development updated, to overcome its limitations. He also analyzed the outcomings of surveys that he conducted to show the evolution in the agile software development.

Release engineering affects the software we build, how we build it, and how we can make money out of it. It also presents many challenges that will take time to overcome. [ABSTRACT FROM PUBLISHER]

In this article, the author's views are presented related to changing scenario of requirements engineering and agility in the computer software development industry as of May 2013. Topics discussed include developing techniques for improving the requirements process, impact of the challenges on agile software development and increasing global nature of software development environment.

The author explains the significance of vehicle software in the automotive industry. He says that software devices are highly reliable and have improved performance of automotives allowing more agile engines and increased safety such as the antilock braking system and electronic stability control (ESC). He mentions that the future of engine software is promising since consumer electronics and multimedia have entered the automotive industry.

The article presents a survey administered to IBM software developers on the possibility of agile development and software architecture coexistence. Results of the study showed that majority of agile developers saw the importance of incorporating architectural practices such as architecture analysis, design and review into agile approach. It also showed that software architecture is equally important as agile values.

The Table of Contents for the March/April 2014 issue of "IEEE Software" magazine is presented which includes articles on middleware, cloud architecture, and agile software development.

Ambiguity in requirements isn't always a bad thing. In the right hands, it can be positively useful. [ABSTRACT FROM PUBLISHER]

The author discusses the importance of thinking through numerous work ideas instead of settling on the first one that comes up. He says that software developers who use agile development rarely think about other possibilities once they have begun their work. He suggests having a team meeting in which team members use sketchboards to draw and think through their ideas.

As the last standardization effort was done in 2004, the software engineering curriculum is currently being revised. Haven't we reached the point where agile development should be part of all software engineering curricula? And if so, shouldn't new curriculum standards ensure that it is? [ABSTRACT FROM PUBLISHER]

Agile 2012 Advertisement [ABSTRACT FROM PUBLISHER]

Leadership is the key for architects to balance all their activities and duties with the interests of different stakeholders without losing control of the architecture under development. They must have a clear vision and strict focus on key aspects of success. All their activities should be goal-driven and in direct cooperation and interaction with the relevant stakeholder groups. [ABSTRACT FROM PUBLISHER]

Reflection is a characteristic of good professional practice. If, as requirements professionals, we're expected to do it, then we should embrace it and apply it directly to our requirements work. [ABSTRACT FROM PUBLISHER]

Agile software development involves self-managing teams that are empowered and responsible for meeting project goals in whatever way they deem suitable. Managers must place more trust in such teams than they do in teams following more traditional development methodologies. The authors highlight how the use of agile practices can enhance trust amongst agile team members. They also present challenges that agile teams can face as a result of using agile practices. Their results are based on the findings from three case studies of agile software development teams. [ABSTRACT FROM PUBLISHER]

There is broad consensus that architects should code. Yet the challenging question is: how can architects program without being lost in myriads of local code details? Even when they program they should be in full control of a system's entire architecture. Thus, architects should not program for fun or to be accepted by developers. Instead they should program to guide an architecture's realization and get feedback on the sustainability and habitability of their own designs! Agile practices help architects to balance their coding activities with other duties, allowing them to be in control of the amount of time they spend on programming and the concerns and system parts on which they program. [ABSTRACT FROM PUBLISHER]

You'll have to read further to find out! There are so many interesting things about this article—it's the first in a series based on presentations from the SATURN conference. My first college degree was in chemistry, so there was an immediate connection for me with this story about chemical abstracts. The author brings us architectural wisdom, combined with an agile point of view and weather forecasting. [ABSTRACT FROM PUBLISHER]

Our growing ability to swiftly put together sophisticated software affords us the luxury to listen to our customers, to try out new things, to make mistakes, to redesign as we move along—in short to be agile. On the technological front, the main driving forces are powerful operating systems, the widespread availability database management systems, a wide selection of libraries, interoperability standards, versatile programming languages, ample processing power, and sophisticated development tools. On the environment front, agility is driven by specialized education, informal management structures, Web access, open source software, shifting user expectations, and the ubiquitous availability of IT infrastructures. Where agility drivers are present, we must adjust our development processes, demand more from our software suppliers, and develop in-house capacity to organically grow applications and services that will delight and even captivate our users and customers. [ABSTRACT FROM AUTHOR]

Requirements engineering (RE) tools are increasingly used to ease the RE processes and allow for more systematic and formalized handling of requirements, change management and traceability. For developers and companies evaluating the use of RE tools it is thus essential to know which RE processes are supported by tools and how they fit to their own priorities. The answer isn't easy because many sales prospects highlight numerous features—yet leave out to which degree they're supported and whether all features really matter. To gain insight into how current RE tools adapt to RE activities, we ran a 146-item survey based on the features covered by the ISO/IEC TR 24766:2009, a new framework for assessing RE tool capabilities. We received responses from 37 participants, covering all relevant tools. In addition to the tools' score in each activity, we assessed their performance in three concrete use scenarios. Our findings can help practitioners select an RE tool as well as provide areas for improvement for RE tools developers. [ABSTRACT FROM AUTHOR]

Requirements analysts need a new toolbox with both the right tools and the instructions to use them including agile development and user-centered design for techniques such as analysis of Web analytics, wire-framing, and user stories. We can also look to the creativity literature and take techniques such as constraint removal, storytelling, and other worlds. [ABSTRACT FROM AUTHOR]

TomTom worked with the automotive industry to align traditional, risk-eliminating, slow development processes focusing on quality with high-speed, innovative development processes such as those introduced by the smart phone industry. In doing so, TomTom achieved short lead times without compromising on quality by adopting an agile development approach combined with explicit management of specification and schedule buffers. [ABSTRACT FROM AUTHOR]

A systematic review of global software engineering (GSE) literature from 2000 to 2007 shows the field to be immature. Studies report many challenges but little evidence regarding specific GSE practices directly related to project success or failure. There is evidence that distance matters and, furthermore, that GSE--although driven by cost-reduction goals--seldom brings immediate cost savings. [ABSTRACT FROM AUTHOR]

Both the software industry and academia promote collaboration to solve challenges together that neither can solve alone. Collaboration brings opportunities to understand and improve in ways not possible when working apart, but it succeeds only if both parties are contributing. A collaboration model developed from eight years' experience setting up and managing a research center explicitly focused on industry needs is based on five success factors enabling research results (need orientation, industry goal alignment, deployment impact, industry benefit, and innovativeness), five success factors enabling research activities (management engagement, network access, collaborator match, communication ability, and continuity), and 10 action principles for industry-academia collaboration management. [ABSTRACT FROM AUTHOR]

There's a common perception that, although developers might experience some "teething" problems during the initial transition to agile methods, they're much happier, more engaged, and ultimately more productive with agile methods. However, this belief might not always hold true. Case studies identified many serious "people" challenges that 17 large multinational organizations experienced after using agile methods for more than three years. Challenges range from recruitment of agile staff to training, motivation, and performance evaluation. The studies produced a set of actionable recommendations on how organizations can overcome these challenges on the basis of better practices uncovered during the studies. [ABSTRACT FROM AUTHOR]

A proposed approach adapts use-case point (UCP) estimation to agile development of interactive software. To create product cost estimates early during development, developers must agree on the concepts driving the estimations and rely on substantial data from past projects, along with constant feedback and fine-tuning. To enhance the estimations' consistency, interactive UCP (iUCP) uses information extracted according to the concepts of usage-centered design (usageCD). It assigns complexity factors to actors and use cases and uses those factors to calculate unadjusted UCPs reflecting the requirements' complexity. The main basis for weighting complex actors is the user roles. The bases for weighting use cases are essential use-case steps portrayed as user intentions and system responsibilities along with analysis classes extracted from the usageCD architecture. An empirical study shows that estimations based on iUCP are more consistent than those based on the UCP method. [ABSTRACT FROM AUTHOR]

This article presents practical experiences and lessons learned in defining and implementing an agile model-driven development process using the MDD tools chain. This process and its implementation inherit the merits of scrum, extreme programming, and the Unified Software Development Processes. The experience data demonstrates that combining MDD practices with agile development process can significantly reduce software development cycle time and increase productivity and quality. [ABSTRACT FROM PUBLISHER]

CS Press and CS Social Networking advertisement [ABSTRACT FROM AUTHOR]

To some, the phrase "agile architecture" is an oxymoron. This paper explores why we view the meaning behind the phrase to be a very good idea, helping a team attend to building the right software at the right time with the right amount of resources. [ABSTRACT FROM PUBLISHER]

A common and frequent complaint from software practitioners is that academic research doesn't meet their requirements or expectations. During XP 2010 in Trondheim this year, practitioners were asked to suggest research topics that they'd like to see addressed. Around 60 different suggestions were made. They were collected and displayed so that attendees at the conference could vote for their favorite topic, and from this we developed a prioritized backlog of research issues. This article presents the top ten issues according to the voting, discusses the range of themes across the complete set of suggestions, and poses several questions that need answering for this backlog to be processed. The Web extra is an erratum to the acknowledgments. [ABSTRACT FROM PUBLISHER]