Weston P. Bioinformatics Software Engineering: Delivering Effective Applications
Подождите немного. Документ загружается.
Acknowledgements
Everyone that I have worked with has helped me write this book.
Thank you all.
Particular thanks are due to:
• Lee Cave-Berry, for getting me interested in what you can do with
computers;
• Jo Wixon, for the continuous encouragement that turned my ideas
into a book;
• Damien Counsell and Phil North, for reviewing the manuscript in
draft; and
• Phil Gardner, the best boss I have ever had.
Part 1
Introduction
Bioinformatics Software Engineering: Delivering Effective Applications. Paul Weston
Copyright
2004 John Wiley & Sons, Ltd. ISBN: 0-470-85772-2
1
What You Need to Know
This chapter introduces some basic software engineering concepts that
the book will use, and provides a brief tour of what is covered and
why.
The software development process: what is it you
do all day?
Some people think that application development just means cranking
out code. They are nearly right, and almost completely wrong. If you
just crank out code, you will never deliver an effective application.
Writing software properly involves talking to people – often lots of
people – and plenty of non-coding work on your part. It requires the
ability to dream up new solutions to problems so complicated that they
are hard to describe.
You have to be a detective, following up clues and examining
evidence to discover what has gone wrong and why. And you have to
be a politician, understanding what people want, both in public and
in private, and how this is likely to affect what you are trying to do.
This book cannot teach you to do all of that, but it can help.
The actual coding is a small part of application development. This
process starts long before you sit down at your computer and ends long
after you have switched it off. For example, what is the point of writing
code if you don’t know what your users want it to do? You might think
Bioinformatics Software Engineering: Delivering Effective Applications. Paul Weston
Copyright
2004 John Wiley & Sons, Ltd. ISBN: 0-470-85772-2
you know what they want. But even if you are right, can you be sure
that is all that they will ever want it to do? And can you prove this to
them?
The application lifecycle: from concept to construct
Requirements capture (finding out what your customers want), testing
(making sure that your product does what they specify), and demon-
strating your application to users (showing them that they have got
what they asked for) are three parts of the application lifecycle.
A program begins as an idea, and becomes a tool for others to use.
That’s the theory, anyway; in practice, this journey from one mind to
many is often very convoluted. You can make it easier for everyone
involved if you can learn what sort of situations to expect along the
way and are suitably prepared for them.
In the preface to this book, I mentioned a number of aspects of what
is known as ‘software engineering’. Let’s take a look at each and explain
what we mean by them.
Agreeing requirements
Agreeing requirements means more than finding out what your cus-
tomers want. It means coming up with a definition that tells you what
your program has to do and tells them what they can expect to receive,
and which all parties are happy with.
The work you do at this stage should also generate enough infor-
mation for you to start thinking about how to plan tests and specify
the criteria by which the success of the program will be measured. Later
on, we will explore a couple of techniques that I have found useful in
this situation.
Design tools and techniques
Next, you need to think about how you are going to start the design
of your solution to your customer’s problem. One of the first things
that you will need to do is decide which tools and techniques are appro-
priate. There are many ways that you can write software; you need to
identify the best for your situation.
4 WHAT YOU NEED TO KNOW
These decisions need to be made once you know what the problem
you have to solve is, as the choices that you make at this point will
determine what options are available to you later on.
Defining appropriate documentation
You will need to consider the documentation that will be required. The
volume and type of documentation that you need to produce will
depend on your organization’s culture and way of working, as well as
on the tools and methodology that you decide to use. Its nature will
also be determined by what sort of customers you have, and what
environment your program will be used in.
Hints and tips on development and coding
At some point you have to stop designing and documenting, and start
developing. Whether you are working from a complete formal specifi-
cation, or creating an initial prototype, this can be a daunting step. We
will look at ways to make this easier.
Test planning and execution
As soon as you begin coding, you begin testing. It can be helpful to
plan not only what you are going to test, but also how and when. This
is an area we will examine in more detail.
Rollout and delivery
Your customers will want to try what you are building for them as soon
as possible. We will discuss ways of managing this process of rollout
and delivery to make it as painless as possible for all concerned.
Support, maintenance and enhancement
Once you have delivered what was promised, you move into the
support, maintenance and enhancement period. ‘Support’ means
THE APPLICATION LIFECYCLE: FROM CONCEPT TO CONSTRUCT 5
looking after your program’s users as they get to grips with its
capabilities. ‘Maintenance’ means making sure it keeps on working
for them, and dealing with unexpected occurrences. ‘Enhancement’
involves adding new functionality; often the need for this is identified
as your program is used.
Project signoff
Finally, we will look at how to end each project gracefully, signing off
and moving on. This is a time to look at lessons learned and at things
that could be done better next time. It is also a time to celebrate your
success.
Each chapter from now on will cover one stage in the journey of an
application from inside your head to the hands of your customers, and
will discuss what is involved and what to watch out for.
Always keep your customers in mind
Even if you are in a not-for-profit environment, it is useful to adopt a
customer-focused approach. All software development is funded by
somebody for some reason, even if you are writing it in your free time
simply because you enjoy it so much.
If you are your own customer, you will know better than anyone
else what you want. If your customers are colleagues, treat them as
you would like to be treated if they were building something for
you.
How to deliver effective bioinformatics applications
The most important thing that you can do in order to ensure that the
applications you deliver are effective is to listen.
• Listen when people are talking about what they want.
• Listen to what they aren’t saying – what is being assumed?
• Listen to what they say or don’t say when you show them what you
have done – what were they expecting to see?
6 WHAT YOU NEED TO KNOW
• Listen to what other developers say, and learn from their experi-
ence – especially their mistakes.
• Listen to senior colleagues and learn about your organization from
what they imply or allude to.
• Listen to more general discussions and get a feel for the trends in
your field.
• Listen to yourself – do you feel that you can be proud of your work?
HOW TO DELIVER EFFECTIVE BIOINFORMATICS APPLICATIONS 7
2
What Is Software
Engineering?
We have looked briefly in the last chapter at some aspects of what is
called ‘software engineering’. Before we go on to examine it in more
detail, let’s first think about what software engineering is, why it is
useful and why it is sometimes not enough.
Software engineering: applying formal rules
to creativity
There is an interesting tension between the left-brain and right-brain
aspects of software development. On one side is a creative process; on
the other, the need to produce accurate results, every time.
Many attempts have been made to formally define a successful
approach to this situation. Some have proved more popular than
others. I do not propose to review any; several other works already do
this better than I could. What I am going to try to do is take the best
bits of all of them, and show you how you can use these ideas in your
work.
In my experience, any way of applying engineering to software devel-
opment is probably better than no engineering at all, simply because
we can learn a lot about how to build structures of the imagination
from structures of the physical world.
I was standing on top of a C-130 Hercules transport aircraft, watch-
ing the bustle in the hangar around it, when I started to realize what
Bioinformatics Software Engineering: Delivering Effective Applications. Paul Weston
Copyright
2004 John Wiley & Sons, Ltd. ISBN: 0-470-85772-2
‘engineering’ meant. I had come across the road from the Technical
Publications department to find out how the fitters had put in the latest
modification, so that I could write the installation instructions that
would be sent with it to airfields around the world.
I could have asked the designers – after all, they had already
explained to the fitters what was needed – but there were problems
with this. By now, the designers were already deeply involved in new
projects and would not relish having to turn their attention back to
something that they had moved on from. Moreover, the fitters were
used to working from rough sketches and their experiences when trying
to install the modification often led to changes in its design.
What I had to create was a set of instructions that covered exactly
what a fitter needed to do at each stage. Therefore, I spoke to those
who had thought up ways of how to make tab A actually fit into slot
B, and asked them how they did it, then wrote that down, and then
got them to check that I had described it properly.
Without the creativity of the designers, able to invent solutions, and
the ability of the fitters to think up the best way to implement them in
their often cramped, crowded and inaccessible locations, the improve-
ment would not have happened.
But without someone writing down, step by step, the best way to fit
the modification, in aircraft all around the world, engineers would have
to work out their own ways of doing it – and chances are it would not
be as the designers planned it.
But the designers would not just have had the idea and then gone off
to celebrate. And the fitters hadn’t just slotted the modification in first
time. ‘Trial and error’ means what it says. You try a possible solution
and it’s wrong. So you try another. The fitters and designers who stay
employed are those who are good at quickly identifying solutions that
work.
Both the fitters and the designers made progress steadily; creativity
had been accompanied by analysis, contemplation, experimentation.
There had been setbacks, but these had been overcome. Everybody
worked together as a team to achieve a common objective – everybody
played their part.
My writing the installation instructions was itself a step in the
process of engineering a solution to a problem. In the same way as a
designer or a fitter, I had to determine what was wanted and deliver it
as efficiently as possible.
When you write software, you invent solutions and find the best way
to implement them in your environment. Adding engineering to this
10 WHAT IS SOFTWARE ENGINEERING?
basically means that you use what you have learnt before and do things
in a logical fashion. Using software engineering principles and tech-
niques doesn’t mean that you have stopped being creative; it means that
you are taking your creativity seriously.
The benefits of discipline: reproducibility, stability,
solidity, reliability
Let’s take a look at the advantages of supporting our programming
creativity with the disciplined, methodical way of working found in
traditional engineering.
One thing that we need to do is produce reproducible results; if you
run your program ten times on the same sample data with the same
program settings and you don’t get the same output each time, you are
going to be concerned.
You want to get the same results from that dataset with those
parameters, whoever runs the program and whatever external con-
ditions it runs under. What’s more, you don’t want the program to crash
halfway through the seventh run – it needs to be designed to fail
gracefully, if at all.
Once you have your error-handling routines in place, you will then
need to minimize the number of times that this code is called, by fixing
all the bugs and pre-empting possible problems. Eventually, the only
unexpected program terminations should be those caused by factors
outside your control, such as hardware failures or operating system
bugs.
The formality of an engineering approach will ensure that the
application is seen as solid to its users and they will come to rely on
your software – and on you – if what you build has been well
constructed.
This is much more important than fancy bells and whistles. A car
that looks flash but rusts easily and won’t start on cold wet days doesn’t
have a long-term future. If you don’t write reliable software that does
what its users want it to, what will your future be like?
A limitation of engineering
One limitation of the engineering approach is at first glance an
advantage: it copes well with fixed and clearly defined requirements.
A LIMITATION OF ENGINEERING 11