Software Development

Software Development
(In a small-scale research context)

This page is a placeholder, or under current development; it is here principally to establish the logical framework of the site. The material on this page is correct, but incomplete.

There is much sophisticated methodology for software development, it mainly addresses the needs of large software companies and enterprise-scale systems. And no question: once development is the task of teams, and the systems become larger than what one person can remember confidently, in the absence of a well structured process failure is virtually guaranteed. But our work usually does not fit this paradigm, because nowhere do the requirements change faster and more radically than in the bioinformatics lab. The reason is obvious: most of what we do are one-off solutions. Once one analysis runs, we publish the results, and move on. There is limited value in doing an analysis over and over again and even if we think our database or service is the next and greatest thing, the funding panel who pays the bill won't agree. However, this does not mean we can't all profit from applying the basic principles of good software development. Fortunately that is easy. There actually is only one.

Make implicit knowledge explicit.

 

Introductory reading

 

Contents

Make implicit knowledge explicit. This maxim has many implications. It means to list out the requirements. It means to write down your stakeholder objectives. It means to specify the versions of your dependencies. It means to comment, and to document and to draw and to plan. [TBC...]

• Notation: compact and intuitive; consider information design (less ink!)
• What things to model: structural (data model, components) and behavioral (state changes, data flow)
• Consistency between model and implementation! "Seamlessness" (a single, continuous process) and reversibility (between analysis, design and implementation) see Walden and Nerson (). Only then can the model be part of the documentation. Implies: update, versioning, audit ...?
• Functional design vs. object oriented design (cf. Meyer 97)
• Correctness (Design by contract? Assertions?)
• Robust
• Easy to extend
• Reusable (standardization of interface conventions, option-operand separation, command-query separation and so on)
• Efficient

   

Further reading and resources

UML: The Positive Spin

Architecture modeling

• Kim Waldén and Jean-Marc Nerson: Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems, Prentice Hall, 1995.

• Software development process
• Software architecture