By Douglas C. Schmidt
While agile methods have become popular in commercial software development organizations, the engineering disciplines needed to apply agility to mission-critical, software-reliant systems are not as well defined or practiced. To help bridge this gap, the SEI recently hosted the Agile Research Forum. The event brought together researchers and practitioners from around the world to discuss when and how to best apply agile methods in mission-critical environments found in government and many industries. This blog posting, the fourth installment in a multi-part series highlighting research presented during the forum, summarizes a talk by James Over, manager of the Team Software Process (TSP) initiative, who advocated the building of self-managed teams, planning and measuring project process, designing before building, and making quality the top priority, among other principles associated with applying agile methods at-scale.
By Bill Nichols,
Senior Member of the Technical Staff
Software Engineering Process Management
In his book Drive, Daniel Pink
writes that knowledge workers want autonomy, purpose, and mastery in
their work. A big problem with any change in processes is getting the
people who do the work to change how they work. Too often, people are
told what to do instead of being given the information, autonomy, and
authority to analyze and adopt the new methods for themselves. This
posting—the first in a two-part series—describes a case study that shows
how Team Software Process (TSP) principles
allowed developers at a large bank to address challenges, improve their
productivity, and thrive in an agile environment.
By Mike Phillips
Acquisition Support Program
In my preceding blog post, I promised to provide more examples highlighting the importance of software sustainment in the US Department of Defense (DoD). My focus is on certain configurations of weapons systems that are no longer in production for the United States Air Force, but are expected to remain a key component of our defense capability for decades to come, and thus software upgrade cycles need to refresh capabilities every 18 to 24 months. Throughout this series on efficient and effective software sustainment, I will highlight examples from each branch of the military. This second blog post describes effective sustainment engineering efforts in the Air Force, using examples from across the service’s Air Logistics Centers (ALCs).
By Dave Zubrow, Manager
Software Engineering Measurement and Analysis Initiative
The SEI has been actively engaged in defining and studying high maturity software engineering practices for several years. Levels 4 and 5 of the CMMI (Capability Maturity Model Integration)
are considered high maturity and are predominantly characterized by
quantitative improvement. This blog posting briefly discusses high
maturity and highlights several recent works in the area of high
maturity measurement and analysis, motivated in part by a recent comment on a Jan. 30 post
asking about the latest research in this area. I’ve also included links
where the published research can be accessed on the SEI website.
By Douglas C. Schmidt
use the SEI Blog to inform you about the latest work at the SEI, so
this week I'm summarizing some video presentations recently posted to
the SEI website from the SEI Technologies Forum.
This virtual event held in late 2011 brought together participants from
more than 50 countries to engage with SEI researchers on a sample of
our latest work, including cloud computing, insider threat, Agile
development, software architecture, security, measurement, process
improvement, and acquisition dynamics. This post includes a description
of all the video presentations from the first event, along with links
where you can view the full presentations on the SEI website.