Software Development

From "A B C"
Jump to navigation Jump to search

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, failure is virtually guaranteed if in a well structured process is not in place. 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



 

Principles

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


A standard in the discussion of software development is the waterfall model, in which the process cascades from step to step, each one dependent on the results of the former. A reasonably good overview is given in Software development process where other models such as Agile Development are also discussed. In terms of tasks to fulfil, it is probably a good aproach to

Analysis

  • Requirements analysis

Design

  • Architecture
  • Modeling
    • Structural modeling



Implementation

Constructing the system

I hesitate to call this coding, because coding is only one part of the task.

Testing


Documentin


Validation, Deployment, and Maintenance

These may not be distinct in the scenario we are considering here: validation may comprise the one run of discovery we are aiming for, deployment may not apply and maintencae may be foregone as the research agenda moves on.



   

Further reading and resources

  • Kim Waldén and Jean-Marc Nerson: Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems, Prentice Hall, 1995.
  • Article in Nature Biotechnology; note that successful here is meant to imply used by many researchers. David Baker's Rosetta package is not mentioned, for example. Nevertheless: good insights in this.
Altschul et al. (2013) The anatomy of successful computational biology software. Nat Biotechnol 31:894-7. (pmid: 24104757)

PubMed ] [ DOI ]