Making software work
You're working on your computer, maybe writing a document or putting data in a spreadsheet. Suddenly the computer program crashes, and anything that you didn't save is lost. As consumers, many of us only think about the software we use when it goes wrong. And as frustrating as it is to see a chunk of work going down the tubes, imagine how much worse it would be if the software that crashed had been controlling your heart pacemaker, or the anti-lock-brakes on your car.
Ensuring that software is developed so that works reliably and usefully is a major research theme of Lero, the Irish Software Engineering Research Centre. Funded by Science Foundation Ireland (SFI), Lero is headquartered in the University of Limerick, with Lero researchers also based in the partner universities of Trinity College Dublin, University College Dublin, Dublin City University, Dundalk IT and NUI Galway.
Much of Lero’s research looks at the life cycle of software development and strives to ensure that the right products are built the right way.
The wider context is the emerging need for standards and regulation in software, explains Jack Downey, industry liaison officer at Lero.
"Say you went into a hardware store and got an M12 bolt and then you went to another and got an M12 nut - you would expect to be able to screw one into the other because they are made to a standard," he explains.
However for software, those broad standards aren't in place, according to Downey, and consumers will not always be happy just to sign a standard disclaimer when they install a programme.
"I think the software industry really is heading towards a collision course with the consumer groups because software is becoming more pervasive, we are placing more trust in it," he says. "The software industry is going to have to come up to the mark and submit to the regulation standards that we expect other industries to have."
Part of the problem has been the rush to develop new, game-changing technologies, explains Downey - because it leaves little time to develop standards and regulations, which could be obsolete anyway by the time they are implemented.
But the 'first-to-market' mindset doesn't stand up to scrutiny, he notes:
"It is invalid because what is the verb we use for searching the Internet? To Google! But Google wasn't the first to market; it arrived late yet it is now the dominant player," he says. "Yet that's the way the market has evolved - everyone wants to be first to change the world."
So how to improve the processes and help make sure that clients get something they want that's reliable?
One route is through verification - which is about making sure that a product is built correctly by proving that the finished code actually maps to the design, explains Downey.
"Verification is something we know how to do now but it's very expensive. There are formal methods, - mathematical proofs - so you have got to specify your software as a mathematical statement and then you can prove that the software design and code maps on to the specification."
The maths involved can be off-putting for software developers, so Lero is working on ways for people to harness the power of the formal methods more easily, explains Downey.
"We are trying to develop toolkits that will give you the benefit of the formality without being exposed to the maths that is going on behind the scenes."
As well as supporting people to build products right, Lero is also looking to make sure the right products are being built in the first place. "In my personal view, one the biggest problems we face in the software industry is that software is everywhere, and we have to deal with people who know nothing about computers and we know nothing about their business," says Downey.
He describes how Lero is working on making development processes more agile, building incremental versions and engaging the customer along the way to ensure there is a shared understanding.
Lero also wants to ensure that ‘finished’ software products can evolve as users and developers see new ways to use them.
“Even if you did produce mathematically verified programs, the nature of software is such that it changes,” says Downey. “As soon as people get used to a new piece of software, they see further possibilities and are quick to voice their opinions about what the program should do in future versions. So how do you develop version 2.0 and version 3.0 subsequently? Is the same amount of formal verification and testing required, or can we be clever and reduce the cost of producing subsequent releases – building on the initial investment in verification? This is the question Lero will be trying to answer in the coming years.”
