SOFTWARESTANDARDS TECHNOLOGIES Formality, Agility, Security, and Evolution in Software Development Jonathan P. Bowen, Birmingham City University Mike Hinchey, Lero—the Irish Software Engineering Research Centre, University of Limerick Helge Janicke and Martin Ward, De Montfort University Hussein Zedan, Applied Science University Combining formal and agile techniques in software development has the potential to minimize change-related problems. omplex systems have problems if used carefully, follow- and security are central aspects of always been problematic ing standard patterns of use. Formal the system to be designed. While with respect to software methods have been advocated for im- a formal approach can be used to development. Simplic- proving the correctness of software derive a proof, potentially at great C 1 ity is desirable, but the reality of systems, and agile software develop- cost, a formal specification also pro- dealing with a customer means that ment has been promoted by the Agile vides a framework for undertaking requirements are likely to change, Manifesto (http://agilemanifesto.org) rigorous testing, potentially with resulting in a corresponding loss of and others for enabling adaptive de- cost savings since the specification elegance in the solution. velopment in the face of changing can be used to direct the tests that A good software engineer will requirements, typically introducing are needed.3 Without a formal speci- design with the knowledge that additional complexity in the process. fication, software testing is a much the system is likely to evolve over more haphazard affair. time, even if the exact nature of the FORMALITY Misunderstanding the term changes is unknown. Such exper- Although using formal methods to “formal methods” can also be an tise only comes with experience develop a software system can be issue. The relevance of the formal ap- and an innate aptitude, especially slow and cumbersome, these meth- proach must be understood by every in the understanding and use of ods deliver lower error rates because team member, even if formality won’t abstraction. Software engineering ap- they use a mathematical approach actually be used by everyone. In fact, proaches such as object orientation from the requirements specifica- teaching software engineers to read and modularization—for example, tion onward.2 Formal methods are formal specifications is much easier the Z notation schema construct— an important software engineer- than teaching engineers how to write can help minimize change-related ing technique in cases when safety them. Reading and understanding 86 COMPUTER Published by the IEEE Computer Society 0018-9162/14/$31.00 © 2014 IEEE the specification is necessary for and XP continue their advance into process is similar to the widely most members of a software de- mainstream software development, known agile technique planning velopment team—for example, with sometimes impressive results, poker, which is used to establish programmers and testers—whereas there are still reservations in areas effort estimates for user stories. specification writing requires the in- where security is a paramount The recent adaptation of Micro- volvement of a much smaller number concern to stakeholders. Until rela- soft’s Secure Development Lifecycle of more highly trained people. tively recently there was little focus (SDL) to integrate with agile prod- on how to integrate security best ucts shows that security is a major AGILITY Agile software development pro- vides an iterative approach where It’s necessary to integrate security activities in the the requirements and the associated agile development process and its practices. solution evolve through the collabo- ration of team members, and rapid response to change is encouraged. This contrasts with the traditional practices into agile development, concern for companies employing view of formal methods, but modern although these shortcomings have agile methodologies. The key prob- tools can enable a much more agile existed for at least a decade. lem addressed by Bryan Sullivan approach even within formal devel- To address this problem, it’s is how activities from the SDL can opment. For example, the RODIN tool important to make security re- be integrated effectively into the (http://rodin.cs.ncl.ac.uk) minimizes quirements explicit and to include short-release cycles that charac- the amount of re-proof that is needed security concerns in the product terize agile development projects.6 if the system is changed. Tools like backlog with adequate priority, so This approach divides SDL activi- the Alloy Analyzer (http://alloy.mit. that the concerns continue to be ad- ties into three categories: every edu) are relatively easy for a capable dressed by the development team sprint, such as running automated software engineer to learn and can during the iterations. Agile methods security-analysis tools and updating be quickly used in an agile manner.4 strive to satisfy the customer, which the threat model; bucket require- The concept of agile formal meth- frequently prioritizes the develop- ments consisting of verification ods first appeared in the literature ment of functionality that produces tasks, design review activities, and in the mid-2000s, with events such the primary business value. Secu- response planning; and one-time as the Formal Methods and Agile rity, on the other hand—because it’s requirements such as the develop- Methods (FM+AM) Workshop explic- concerned with managing risk and ment of a baseline threat model. itly addressing the issue.5 In 2009, a preventing the developed function- So, while efforts to integrate position paper on formal methods ality from being misused—is often security practices in agile method- and agile software development was unfortunately not as highly valued ologies are well underway, there published in Computer to highlight and therefore isn’t addressed in is a risk that many actual devel- the debate.4 early sprints. Consequently, it’s nec- opment efforts will ignore these While we don’t really hold the essary to integrate security activities efforts or that development teams view that agility may be used by in the agile development process lack the knowledge and training to “unscrupulous” developers, in and its practices. actually create secure products in general we do believe that agile de- One way to address security the short term. However, agile prin- velopers could benefit from some early in an agile development con- ciples such as communication and training on formal methods, at least text is by using evil stories. This is practices such as pair programming in reading formal specifications, an agile adoption of misuse cases to may help disseminate knowledge even if developers don’t apply the describe the functionality that an at- throughout the development team. approach rigorously. tacker would be able to exploit. The Certification remains a potential development then takes on two di- issue, as it requires detailed and SECURITY mensions: to implement user stories sometimes formal documentation. Can agile methods produce secure and to avoid implementing evil sto- The approach discussed in Sulli- software, perhaps in cases in which ries. Another practice that integrates van’s article6 can help by mandating the security properties have been security principles in agile develop- activities that need to be included formalized? Opinions regarding ment is a technique called protection in every sprint and by requiring this question remain split. While poker, in which security risks are a (scope-reduced) final security agile methodologies such as Scrum quantified by the agile team. This review at the end of each sprint. OCTOBER 2014 87 SOFTWARE TECHNOLOGIES so if a large body of assembler code The transformation process will typ- Formal Informal can be replaced by a smaller amount ically include the following stages: program implementation of high-level language code— specication ideas preserving its correctness without • formal specification; seriously affecting performance— • elaboration of the specification; then the potential savings in the • dividing and conquering to form of software and hardware handle the general case; Program 1 maintenance costs are very large. • recursion introduction; A sound agile approach to soft- • recursion removal, if an itera- ware evolution that is based on tive solution is desired; and Program n transformation theory and associ- • optimization, if required. ated with the industrial-strength FermaT program transformation Subspecifications can be ex- Figure 1. Transformational system has been developed. The ap- tracted and transformed separately programming method of algorithm proach to agility and evolution via at any stage in the process. The derivation. transformation involves four stages: main difference between this ap- proach and the invariant-based EVOLUTION • Translate the assembler to Wide programming approach (and similar Real software systems continually Spectrum Language (WSL). stepwise refinement methods) is that evolve. Their evolution is often in • Translate and restructure data loops can be introduced and manip- response to the evolution of their declarations. ulated while maintaining program environments: new functionalities • Apply generic semantics- correctness with no need to derive are added and/or existing ones are preserving WSL to WSL loop invariants. Another difference removed due to the need to address transformations. is that at every stage in the process, changes