A Study of Enabling Factors for Rapid Fielding Combined Practices to Balance Speed and Stability

<p>Agile projects are showing greater promise in rapid fielding as compared to waterfall projects. However, there is a lack of clarity regarding what really constitutes and contributes to success. We interviewed project teams with incremental development lifecycles, from five government and commercial organizations, to gain a better understanding of success and failure factors for rapid fielding on their projects. A key area we explored involves how Agile projects deal with the pressure to rapidly deliver high-value capability, while maintaining project speed (delivering functionality to the users quickly) and product stability (providing reliable and flexible product architecture). For example, due to schedule pressure we often see a pattern of high initial velocity for weeks or months, followed by a slowing of velocity due to stability issues. Business stakeholders find this to be disruptive as the rate of capability delivery slows while the team addresses stability problems. We found that experienced practitioners, when faced with these challenges, do not apply Agile practices alone. Instead they combine practices—Agile, architecture, or other—in creative ways to respond quickly to unanticipated stability problems. In this paper, we summarize the practices practitioners we interviewed from Agile projects found most valuable and provide an overarching scenario that provides insight into how and why these practices emerge.</p

Elaboration on an Integrated Architecture and Requirement Practice: Prototyping with Quality Attribute Focus

<p>This experience report builds on an earlier study in which we interviewed eight project teams that were using iterative incremental lifecycles. In the study, we captured the practices the teams felt contributed to rapid delivery. We identified a mix of Agile and architecture practices that teams apply to rapidly field software and minimize disruption and delay. In this paper, we elaborate one practice from the study, prototyping with quality attribute focus. We compared two experiences in prototyping focused on quality attribute considerations applied on Scrum projects. We observe through interviews that feature development and prototyping practice spans multiple levels: feature development/sprint, release planning, and portfolio planning. We also observe other factors including rapid trade-off analysis, flexible architecture, and adoption of a set of enabling prototyping guidelines. The analysis of the observations sheds light on several aspects of the practice that enable the team to respond quickly and efficiently when prototype feedback suggests architectural change.</p

Quality-Attribute-Based Economic Valuation of Architectural Patterns

Quality attribute requirements are a driving force for software and system architecture design. Architectural patterns can be used to achieve quality attribute requirements. Consequently architectural patterns generate value based on the present and future utility of the quality attributes they achieve. This report makes the case that architectural patterns carry economic value in part in the form of real options, providing software architects the right, but not the obligation, to take subsequent design actions. The report shows, via a simple example, how an analysis of the options embodied within architectural patterns allows an architect or manager to make reasoned choices about the future value of design decisions, considering this value along multiple quality attribute dimensions

Deciding What to Design: Closing a Gap in Software Engineering Education

Software has jumped "out of the box" - it controls critical systems; it pervades business and commerce; it is embedded in myriad mechanisms; it infuses entertainment, communication, and other activities of everyday life. Designs for these applications are constrained not only by traditional considerations of capability and performance but also by economic, business, market, and policy issues and the context of intended use. The diversity of applications requires adaptability in responding to client needs, and the diversity of clients and contexts requires the ability to discriminate among criteria for success. As a result, software designers must also get out of their boxes: in addition to mastering traditional software development skills, they must understand the contextual issues that discriminate good solutions from merely competent ones. Current software engineering education, however, remains largely "in the box": it neglects the rich fabric of issues that lie between the client's problem and actual software development. At Carnegie Mellon we have addressed this major shortcoming with a course that teaches students to understand both the capabilities required by the client and the constraints imposed by the client's context. This paper presents our view of the engineering character of software engineering, describes the content and organization of our new course, reports on our experience from the first three offerings of our course, and suggests ways to adapt our course for other educational settings.</p

Enabling Incremental Iterative Development at Scale: Quality Attribute Refinement and Allocation in Practice

Software Engineering Institut

Parallel Worlds: Agile and Waterfall Differences and Similarities

<p>This technical note (TN) is part of the Software Engineering Institute’s series on Agile in the Department of Defense (DoD). It primarily addresses what at first seems a small issue on the road to Agile adoption—the confusion of terms. However, this is a much larger issue, as ineffective communications among and between stakeholders is often cited as a significant stumbling block on any project. Confusion over simple terms is a needless hurdle.</p> <p>Many terms and concepts used by Agile practitioners seem to confound those working in the DoD’s Traditional World of waterfall-based environment, and vice versa. The goal of this paper is to assemble terms and concepts from both environments to show both the similarities (of which there are many) and differences (of which there are also many). A comprehensive cross dictionary was beyond the scope of this work; the authors strove to select from those terms most commonly encountered when considering Agile adoption. Therefore, the authors selected terms based on suggestions from both inside and outside the SEI, but deliberately limited themselves to 25 terms from each environment.</p

A Comparison of Requirements Specification Methods from a Software Architecture Perspective

One of the key challenges to producing high-quality software architecture is identifying and understanding the software's architecturally significant requirements. These requirements are the ones that have the most far-reaching effect on the architecture. In this report, five methods for the elicitation and expression of requirements are evaluated with respect to their ability to capture architecturally significant requirements. The methods evaluated are requirements specification using natural language, use case analysis, the Quality Attribute Workshop (developed by the Carnegie Mellon Software Engineering Institute), global analysis, and an approach developed by Fergus O'Brien. These methods were chosen because they are in widespread use or emphasize the capture of architecturally significant requirements. Three problems must be solved to systematically transform business and mission goals into architecturally significant requirements: (1) the requirements must be expressed in a form that provides the information necessary for design; (2) the elicitation of the requirements must capture architecturally significant requirements; and (3) the business and mission goals must provide systematic input for elicitation process. The primary finding from the evaluation of these methods is that there are promising solutions to the first two problems. However, there is no method for systematically considering the business and mission goals in the requirements elicitation

Results of SEI Line-Funded Exploratory New Starts Projects

<p>The Software Engineering Institute (SEI) annually undertakes several line-funded exploratory new starts (LENS) projects. These projects serve to (1) support feasibility studies investigating whether further work by the SEI would be of potential benefit and (2) support further exploratory work to determine whether there is sufficient value in eventually funding the feasibility study work as an SEI initiative. Projects are chosen based on their potential to mature and/or transition software engineering practices, develop information that will help in deciding whether further work is worth funding, and set new directions for SEI work. This report describes the LENS projects that were conducted during fiscal year 2011 (October 2010 through September 2011).</p

Results of SEI Line-Funded Exploratory New Starts Projects

<p>The Software Engineering Institute (SEI) annually undertakes several line-funded exploratory new starts (LENS) projects. These projects serve to (1) support feasibility studies investigating whether further work by the SEI would be of potential benefit and (2) support further exploratory work to determine whether there is sufficient value in eventually funding the feasibility study work as an SEI initiative. Projects are chosen based on their potential to mature and/or transition software engineering practices, develop information that will help in deciding whether further work is worth funding, and set new directions for SEI work. This report describes the LENS projects that were conducted during fiscal year 2012 (October 2011 through September 2012).</p

Results of SEI Independent Research and Development Projects (FY 2010)

The Software Engineering Institute (SEI) annually undertakes several independent research and development (IRAD) projects. These projects serve to (1) support feasibility studies investigating whether further work by the SEI would be of potential benefit and (2) support further exploratory work to determine whether there is sufficient value in eventually funding the feasibility study work as an SEI initiative. Projects are chosen based on their potential to mature and/or transition software engineering practices, develop information that will help in deciding whether further work is worth funding, and set new directions for SEI work. This report describes the IRAD projects that were conducted during fiscal year 2010 (October 2009 through September 2010).</p