Formal Methods

In my last two blog posts I’ve been writing about trust and virtual teams and I will continue to explore critical success factors for teams, as I believe that the ability to make teams work effectively and efficiently is the key driver of good software engineering.

Methods are important as well and recently I was reading an article on Use-Case 2.0 which introduced use-case slices as a way to make formal Use-Case based software engineering applicable to Agile development approaches like Scrum and Kanban (Jacobson, Spence & Kerr, 2016).  Formal methods are based upon modeling techniques to design, implement and test software.  The Unified Modeling Language (UML) is one formal method for specifying, visualizing, constructing, and documenting the artifacts of software systems around which tools and methods have been developed to enable software development that is delivered with increased quality and reduced cost.  UML or other formal methods, combined with strong software engineering techniques have been proven, and are used regularly in some software domains such as communications systems and plant control systems but are not well adopted in business software development.

In the past I’ve always been interested in formal methods in Business Software and an advocate of them, but today I’ve concluded that quality, reliability and cost benefits can be achieved in other ways that are easier to implement with the developers and testers that work on most business systems.  Most of the software we develop for business has a focus on user interface, less complex logic and need for rapid time to market.

I’ve worked with four software development teams in startup or growing software companies over the last year. None of those teams would have been able to adopt formal methods. The ses teams had in common the need to move quickly, and a lack of experience and training in software engineering.  By introducing agile approaches based upon SCRUM, lightweight requirements documentation based upon user stories, tools and frameworks and a focus on testing we were able to achieve goals of time and quality without the investment and delay to implement formal methods.

I still have a gut belief that with time a team could become highly productive with formal methods, but I haven’t seen a business building business software that could take that time to develop the capability and make the investment in training and practice.  So Agile it is.


Jacobson, I., Spence, I. & Kerr, B.  (2016). Use-Case 2.0. Communications Of The ACM59(5), 61-69. DOI:10.1145/2890778