Evolution: a Grand Challenge

Evolution: a Grand Challenge Pennine Forum September 2004 Keith Bennett School of Engineering, Durham Keith.bennett@durham.ac.uk

Contents • What is the Grand Challenge programme? • Evolution: the problem space • Evolution: the solution space • Discussion • Next steps

The Grand Challenge in Computing • http://www.nesc.ac.uk/esi/events/Grand_Challenges/ • Tony Hoare proposed the idea of identifying grand challenges in computing, to focus the community, to address important long term problems, and to influence bodies like EPSRC • Currently some 6 areas – Pennine is involved in GC6 “Strong Software Engineering”, with a focus on software evolution. Our motto “right first time, every time”

Where are we? • Several workshops (KHB, DB) • Workshop next week (OPB, NEG) • Steering committee • Politics

Problem domain • It is still the case that evolution as a problem is not well understood

Problem 1 • Software maintenance/evolution is not just “one activity”, (post initial implementation). As software ages, it goes through a number of irreversible stages: • Strategic change • Servicing • Phase out • Close down

Problem 2 • There is very little evidence-based analysis of evolution methods, processes and tools. Coupled with lack of theory, there is very little objective understanding (that’s not to say maintenance isn’t done well; some organisations such as IBM have super mature processes)

Problem 3 • Over the lifetime of much software, all lifecycle products evolve, not just the code. So we must sustain requirements, design, test suites, configuration, general documentation etc. in synchronism. It is not just code: data evolves too, and meta data and semantics.

Problem 4 • Over the lifecycle, the context changes: staff education, the technology, trust, legal aspects, performance, acceptable behaviours, user expectation etc. The domain evolves. Lifecycle processes evolve. In a modern distributed system, components will be drawn from software with a great variety of age.

Problem 5 • Over the lifecycle, human domain expertise leaks away (retirement, promotion etc.)

Problem 6 • For much evolution, the software will be required to change in ways inconceivable to the original designers.

Summary • Even with experienced software engineers, the problems of evolution are not fully appreciated. I think there is actually a deep understanding now – the issue is that we do not understand the solution space!! • It’s a wicked problem at its most general

Solution space • Strategy: To partition the solution space into a spectrum of difficulty • Need: a coherent framework for evidence-based analysis of results. Without this, how can we judge when we are successful? • Read alongside the criteria for a grand challenge

Solution 0 • Design software systems to be flexible and easy to change from the outset. Almost certainly, this will involve getting rid of early binding in of design decisions. What level of granularity are the components? This sounds great, but in fact we know very little, and we are unsure even how to partition the solution space or give criteria for success (so we know when we have an answer)

Solution 1 • Anticipate change at requirements capture time. Future changes can then be provided for by parameterisation, inheritance etc. This is low cost (and the cost can often be estimated during requirements).

Solution 2 • Apply a delta. If a system is well defined (even, formally defined), we can think of techniques which will ripple through changes. We make lots of assumptions e.g that only one technology is used, that staff are au fait with it. There are probably a number of approaches

Solution 3 • Maybe we can identify some standard problems using open source, for researchers to try their solution on. (Benchmarks).

Solution 4 • Determine processes and maturity models which lead to successful evolution.

Solution n • Coping with old legacy software, in obsolete technology, with poorly qualified staff, with poor cost models. • I personally don’t think that reverse engineering helps. I can see that converting old legacy code into a modern language may help, as may coding tidying. But we ask business to invest in a very expensive, error prone task with no defined benefits.

Next steps • Sheffield workshop on SE • GC workshop on SE (solutions not problems) • I would like to put lots of input to GC; but actually, I think it needs (i) more thought and (ii) more community agreement first.

Discussion • The problem lies in the solution space for evolution • How do we formulate evidence • How do we identify a spectrum of solutions • How do we build new software which is flexible? • How do we use an open source repository as a test for the community

Evolution: a Grand Challenge