V

viewpoints

DOI:10.1145/3133233 Roderick Chapman, Neil White, and Jim Woodcock

Viewpoints
What Can Agile Methods
Bring to High-Integrity
Software Development?
Considering the issues and opportunities raised by Agile
practices in the development of high-integrity software.

T
HERE IS MUCH interest in
Agile engineering, espe-
cially for software develop-
ment. Agile’s proponents
promote its flexibility, lean-
ness, and ability to manage changing
requirements, and deride the plan-
driven or waterfall approach. Detrac-
tors criticize Agile’s free-for-all.
At Altran U.K., we use disciplined
and planned engineering, particu-
larly when it comes to high-integrity
systems that involve safety, security,
or other critical properties. A shallow
analysis is that Agile is anathema to
high-integrity systems development,
but this is a naïve reaction. Pertinent
questions include:
˲˲ Is Agile compatible with high-
integrity systems development?
˲˲ Where is Agile inappropriate?
˲˲ Do Agile’s assumptions hold for
high-integrity or embedded systems?
PHOTO BY UK’ S GOVERNM ENT DIGITA L SERVICE/F LICKR (C C BY 2 .0)

˲˲ Could high-integrity best-practice

improve Agile?
We don’t have all the answers, but are not amenable to change. Neither seven iterations, but delivered after
we hope this Viewpoint continues to myth rings true with our experience. 13, owing to a barrage of change re-
provoke debate on this important As our projects develop, they must quests. Nevertheless, it worked, and
topic. absorb change and respond to de- we were able to keep a substantial
Why bother with Agile at all? We fects just like any other. This led to formal specification and all the oth-
often encounter two myths regarding an observation: your project is going er design documentation up to date
the “traditional” approach to high- to become iterative whatever you do, as the project evolved. Knowing that
integrity software development: that so you might as well plan it that way “change” and “iteration” were at the
we somehow manage to perform a from the beginning. This lesson was heart of the Agile manifesto, we de-
single-iteration waterfall style pro- put to good effect in the MULTOS CA cided to see what we could learn and
cess, and that “formal” notations project,6 which initially planned for bring to future projects.

38 COM MUNICATIO NS O F TH E AC M | O C TO BER 201 7 | VO L . 60 | NO. 1 0

 viewpoints

Background and Sources break the proof (or the tests) … ”

Many consider Agile as beginning Upfront Activities and Architec-
with XP,1 but its roots are much older. How do Agile’s ture. Agile advocates building what is
Many of XP’s core practices were well practices and needed now, using refactoring to defer
established long ago—their combina- decisions. Refactoring must be cheap,
tion and rigorous practice was novel. assumptions match fast, and limit rework to source code.
A survey9 notes that both incremen- real high-integrity Our principal weapon in meeting
tal and iterative styles of engineering non-functional requirements is system
were used in the 1950s. Redmill’s work projects? (not just software) architecture, in-
on evolutionary delivery12 predicted cluding redundancy and separation of
many of the problems faced by Agile critical from non-critical. Such things
projects. Boehm2 provides some use- can be prohibitively expensive to refac-
ful insight, while the development of tor late in the day. We need just enough
MULTOS CA6 compared Correctness- upfront architecture work to argue sat-
by-Construction with XP,3 showing difficult—corner-case vulnerabilities, isfaction of key properties. We also do
that the two were not such strange such as HeartBleed—defy an arbitrari- a “What If?” exercise to ensure the pro-
bedfellows after all. ly large amount of testing and use. In posed architecture can accommodate
Lockheed Martin developed the high-integrity development, we use di- foreseeable changes.
Mission Computers for the C130J by verse forms of verification, including The MULTOS CA project had some
combining semi-formal specification, checklist-driven reviews, automated extraordinary security requirements,
strong static verification, iterative de- static verification, traceability analy- which were met by a carefully consid-
velopment, and a strongly Lean mind- sis, and structural coverage analysis. ered combination of physical, opera-
set.11 Use of Agile has been reported by There is no barrier between these tional, and computer-based mecha-
Thales Avionics,5 while SINTEF have verification techniques and Agile, es- nisms. The software design was much
reported success with SafeScrum.13 A pecially with an automated integra- simplified as a result of this whole
recent and plain-speaking evaluation tion pipeline. We try to use verifica- system view. The physical measures
of Agile comes from Meyer,10 although tion techniques that complement, not included the provision of a bank vault
he does not specifically deal with high- repeat each other. If possible, we ad- and enclosing Faraday cage—hardly
integrity issues. vocate for sound static analyses (tools items that we could have ignored and
that find all the bugs, not just some of then “refactored in” later.
Agile Assumptions and Issues them), since this gives greater assur- User Stories and Non-Functional
How do Agile’s practices and assump- ance and reduces pre-test defect den- Requirements. For security and safety,
tions match real high-integrity proj- sity. With careful consideration of the we must ensure our specification cov-
ects? Here are some of the most obvi- assumptions that underpin the static,8 ers all possible inputs and states. Ag-
ous clashes. For each issue, we start we can reduce or entirely remove later ile uses stories to document require-
with a brief recap of the practice in testing activities. ments, but these sample behavior,
question, then go on to describe the is- The NATS iFACTS system4 augments with no completeness guarantee. The
sue or perceived clash, followed by our the software tools available to air-traf- gaps between stories may contain vul-
ideas and experiences in overcoming fic controllers in the U.K. It supplies nerabilities, bugs, unexpected termi-
it. Where possible, we close each sec- electronic flight-strip management, nation, and undefined behavior. Mey-
tion with an example of our experience trajectory prediction, and medium- er files user stories under “Bad and
from the C130J, MULTOS, or iFACTS term conflict detection for the U.K.’s Ugly,” and we agree.
projects. en-route airspace, giving controllers For critical systems, we prefer a
substantially improved ability to plan (semi-)formal specification that of-
Dependence on “Test” ahead and predict potential loss-of- fers some hope of completeness. The
Agile calls for continuous integra- separation in a sector. The developers C130J used Parnas tables to specify
tion, with a regression test suit, and a precede commit, build, and testing critical functions. They seemed to
test-first development style, with each activities with static analysis using the work well—they were simple enough
function associated with specific tests. SPARK toolset. Overnight, the integra- to be understood by system engineers,
Meyer calls these practices “brilliant” tion server rebuilds an entire proof of yet sufficiently formal to be imple-
in his summary analysis,10 but Agile as- the software, populating a persistent mented and analyzed for correctness.
sumes that dynamic test is the princi- cache, accessible to all developers the Sprint Pipeline. Agile usually re-
pal (possibly only) verification activity, next morning. Working on an isolated quires a single active “Sprint,” deliv-
saying when refactoring is complete, change, the developers can repro- ered immediately to the customer, so
or when the product is good enough to duce the proof of the entire system in only two builds are ever of interest:
ship. about 15 minutes on their desktop ma- ˲˲ Build N: in operation with the cus-
The safety-critical community hit chines, or in a matter of seconds for a tomer; used to report defects.
the limits of testing long ago. Ultra- change to a single module. While Agile ˲˲ Build N+1: the current develop-
reliability cannot be claimed from projects might have a “don’t break the ment sprint.
“lots of testing.” Security is even more tests” mantra, on iFACTS it’s “don’t This assumes the customer is al-

O C TO B E R 2 0 1 7 | VO L. 6 0 | N O. 1 0 | C OM M U N IC AT ION S OF T HE ACM 39
viewpoints

High-integrity Agile evidence engine.

ways able to accept delivery of the build (perhaps once every six months) In mitigation, we reduce on-target
product and use it immediately. This has a complete assurance package, in- testing with more static verification.
is not realistic for high-integrity proj- cluding a safety case, and is designed Secondly, if we know that code is com-
ects. Some customers have their own for eventual operation. The trick is pletely unambiguous, then we can jus-
acceptance process, and regulators to make the iteration rates harmonic, tify testing on host development ma-
may have to assess the system before both with each other and with the cus- chines and reduce the need to repeat
deployment. These processes can be tomer and regulator’s ability to accept the test runs on target. Hardware sim-
orders-of-magnitude slower than a and deploy releases. ulation can give each developer a desk-
typical Agile tempo. Embedded Systems Issues. Agile top virtual target or a fast cloud for the
iFACTS uses a deeper pipeline and presumes plentiful availability of fast deployment pipeline. While virtual-
multiple iteration rates, with at least testing resources to drive the devel- ization of popular microprocessors is
four builds in the pipeline: opment pipeline. For embedded sys- common, high-fidelity simulation of
˲˲ Build N: in operation with the cus- tems, if the hardware exists, there may a target’s operating environment re-
tomer. be just one or two target rigs that are mains a significant challenge.
˲˲ Build N+1: undergoing customer slow, hostile to automation, and dif- On one embedded project, all de-
acceptance. This process is subject to ficult to access. We have seen projects velopment of code, static analysis, and
regulatory requirements, and so can revert to 24-hour-a-day shift-working testing is done on developers’ host ma-
take months. to allow access to the target hardware. chines, which are plentiful, fast, and
˲˲ Build N+2: in development and offer a friendly environment. A final
test. re-run of the test cases is performed
˲˲ Build N+3: undergoing require-
Agile presumes on the target hardware with the expec-
ments and formal specification. tation of pass-first-time, and allowing
All four pipeline stages run concur- plentiful availability the collection of structural coverage
rently with multiple internal iteration of fast testing data at the object-code level.
rates and delivery standards. The de-
velopment team can deliver to our test resources to drive the Opportunities
team several times a day. A rapid build development pipeline. High-integrity practices can comple-
can be delivered to the customer (in, ment Agile. We previously mentioned
say, 24 hours), but comes with limita- the use of static verification tools.
tions on its assurance package and While we have a preference for devel-
allowed use: it is not intended for op- oper-led, sound analysis, we recog-
erational use, but for feedback from nize that some projects might find
the customer on a new feature. A full more benefit in unsound, but easier to

40 COM MUNICATIO NS O F TH E ACM | O C TO BER 201 7 | VO L . 60 | NO. 1 0

 viewpoints

adopt, technologies, such as bounded ification activity, minimizing upfront

model checking. Computing power is activities in the face of non-functional
readily available to make these analy- How can we adopt requirements, the incompleteness of
ses tractable at an Agile tempo. an Agile approach, user stories (especially for secure sys-
A second opportunity comes with tems), the need to align sprints and it-
the realization that, if we can automate and still estimate, eration rates with customers and regu-
analysis, building and testing of code, bid, win, and lators ability to accept deliveries, and
why not automate the production of the (non-)availability of test hardware
other artifacts, such as synthesis of deliver projects for embedded systems.
code from formal models, traceability at a reasonable ˲˲ Agile assumptions: customer deci-
analysis, and all the other documenta- sion-making power and tempo, avail-
tion that might be required by a partic- profit? ability of plentiful test hardware, and
ular customer, regulator, or standard? commercial and contractual models
An example of such an “Evidence En- needed to “procure Agile.”
gine” is shown in the accompanying ˲˲ Opportunities: Adoption of formal
figure. languages, automated synthesis, and
static verification as part of the deploy-
Commercial Issues High-Integrity Deployment Pipeline ment pipeline. Generalization of con-
A crucial issue: How can we adopt an We have used the ideas described in tinuous integration into an “Evidence
Agile approach, and still estimate, bid, this Viewpoint at Altran, but we have Engine.”
win, and deliver projects at a reason- yet to deploy all of them at once. An We are deploying these ideas on fur-
able profit? Our customers’ default ap- idealized Agile development process ther projects, and look forward to be-
proach is often to require a competi- would use: ing able to report the results. We hope
tive bid at a fixed price, but how can ˲˲ Principled requirements engi- others will do the same.
this be possible in an Agile fashion if neering,7 concentrating initially on
we are brave enough to admit that we non-functional requirements and de- References
1. Beck, K. Extreme Programming Explained: Embrace
don’t know everything at the start of a velopment of architecture, specifica- Change. Addison Wesley, 1999.
project? In most of our projects, the tion, and associated satisfaction argu- 2. Boehm, B. and Turner, R. Balancing Agility and Discipline:
A Guide for the Perplexed. Addison Wesley, 2003.
users, procurers, and regulators are ments. 3. Chapman, R. and Amey, P. Static verification and
˲˲ A rolling formal specification, extreme programming. In Proceedings of the ACM
distinct groups, all of whom may have SIGAda Conference (2003).
wildly different views of what “Agile” with just enough formality to estimate 4. Chapman, R. and Schanda, F. Are we there yet? 20
years of industrial theorem proving with SPARK. In
means anyway. the remaining work and opening de- Proceedings of Interactive Theorem Proving 2014.
We have had good experience with velopment iterations. Springer LNCS Vol. 8558, (2014), 17–26.
5. Chenu, E. Agility and Lean for Avionics. Thales
a two-phase approach to contracting, ˲˲ An evidence engine, combining
Avionics, 2009; http://www.open-do.org/2009/05/07/
akin to the “architect/builder” model static verification, continuous regres- avionics-agility-and-lean/
6. Hall, A. and Chapman, R. Correctness by construction:
for building a house. Phase 1 consists sion testing, automated generation of Building a commercial secure system. IEEE Software
of the “Upfront” work—requirements, documents and assurance evidence, 19, 1 (2002), 18–25.
7. Jackson, M. Problem Frames. Pearson, 2000.
architectural design, and construction and a cloud of virtualized target plat- 8. Kanig, J. et al. Explicit assumptions—A prenup for
of a skeletal satisfaction argument. forms for integration and deployment marrying static and dynamic program verification. In
Proceedings of Tests and Proofs 2014. Springer-Verlag
The “just enough” termination criteria testing. LNCS, 8570, (2014), 142–157; DOI: 10.1007/978-3-
for phase 1 are: ˲˲ A planned, iterative development 319-09099-3_11
9. Larman, C. and Basili, V. Iterative and incremental
˲˲ Convincing evidence that the arc style, starting with a partial-order development: A brief history. IEEE Computer, 2003.
hitecture will work, meet non-func- over system infrastructure and fea- 10. Meyer, B. Agile! The Good, the Hype, and the Ugly.
Springer, 2014.
tional requirements, and can accom- tures that exposes potential for paral- 11. Middleton, P. and Sutton, J. Lean Software Strategies.
Productivity Press, 2005.
modate foreseeable change. lel development. Early iterations are 12. Redmill, F. Software Projects: Evolutionary vs. Big-
˲˲ An estimate of the size (and there- planned in detail, while the plans for Bang Delivery. Wiley, 1997; http://www.safetycritical.
info/library/NFR/.
fore cost) of the remaining work, given later iterations are left open to accom- 13. SINTEF. SafeScrum website, 2015; http://www.sintef.
the currently understood scope. modate change. no/safescrum.
˲˲ Established ground rules for agree-
ing the scope, size, and additional cost Conclusion Roderick Chapman ([email protected]) is an
independent consultant software engineer, and an
of change requests, and commitment Returning to the questions posed at honorary visiting professor at the University of York, U.K.
to the tempo of decision making for the beginning of this Viewpoint, we Neil White ([email protected]) is Director of the
triage of changes and defects. could summarize our findings as fol- Intelligent Systems Expertise Centre of Altran U.K.

Phase 2 (possibly a competitive lows: Jim Woodcock ([email protected]) is Professor

of Software Engineering in the Department of Computer
bid) could be planned as an iterative ˲˲ No clash: continuous integration, Science at the University of York, U.K.
development, using the ideas set out verification-driven development style,
here. The MULTOS CA was delivered continuous regression testing, and an Thanks to Felix Redmill, Jon Davies, Mike Parsons, Harold
Thimbleby, and Communications’ reviewers for their
in this fashion, with phase 1 on a time- explicitly planned iterative approach. comments on earlier versions of this Viewpoint.
and-materials basis, and phase 2 on a ˲˲ Potential clash or inappropriate:
capped-price risk-sharing contract. overdependence on test as the sole ver- Copyright held by authors.

O C TO B E R 2 0 1 7 | VO L. 6 0 | N O. 1 0 | C OM M U N IC AT ION S OF T HE ACM 41