A Closer Look at 804: A Summary of Considerations for DoD Program Managers

This report examines Section 804 National Defense Authorization Act (NDAA) for 2010 and related guidance documents through the lens of the Department of Defense (DoD) Information Technology (IT) Program Manager. The information in this report is intended to help the program manager reason about actions they may need to take to adapt and comply with the Section 804 NDAA for 2010 and associated guidance.</p

DoD Information Assurance and Agile: Challenges and Recommendations Gathered Through Interviews with Agile Program Managers and DoD Accreditation Reviewers

<p>This paper was produced by the Software Engineering Institute at Carnegie Mellon University in support of the Agile acquisition research agenda funded by the Office of the Secretary of Defense. This paper is part of a larger research study focused on understanding the implications of applying a rapid, incremental development approach, such as Agile, on the Department of Defense (DoD) acquisition process. An overarching goal of this research agenda is to identify areas of tension between Agile and existing processes and provide recommendations for improvement to those processes. In support of the overarching research agenda, several "point" papers are being developed on particular topic areas. The topic of this particular paper is the natural tension between rapid fielding and response to change (characterized as agility) and DoD information assurance policy. The authors gathered information for the paper primarily by conducting interviews with several DoD project managers and information assurance representatives. The interview findings are organized into a list of key challenges and recommendations. The paper also includes a five- to ten-year future outlook with respect to information assurance and agility in DoD. The opinions, findings, conclusions, and recommendations expressed in this Technical Note are those of the authors and do not necessarily reflect the views of the United States Department of Defense.</p

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

Toward Design Decisions to Enable Deployability Empirical Study of Three Projects Reaching for the Continuous Delivery Holy Grail

<p>There is growing interest in continuous delivery practices to enable rapid and reliable deployment. While practices are important, we suggest architectural design decisions are equally important for projects to achieve goals such continuous integration (CI) build, automated testing and reduced deployment-cycle time. Architectural design decisions that conflict with deployability goals can impede the team’s ability to achieve the desired state of deployment and may result in substantial technical debt. To explore this assertion, we interviewed three project teams striving to practicing continuous delivery. In this paper, we summarize examples of the deployability goals for each project as well as the architectural decisions that they have made to enable deployability. We present the deployability goals, design decisions, and deployability tactics collected and summarize the design tactics derived from the interviews in the form of an initial draft version hierarchical deployability tactic tree.</p

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

Software Engineering Institut

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