Difference between revisions of "Software Development"
m |
|||
| Line 9: | Line 9: | ||
| − | 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 | + | 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. |
<div style="font-size:140%; border: 1px solid #000000; background-color:#EEF8FF; padding:10px; margin:10px;"> | <div style="font-size:140%; border: 1px solid #000000; background-color:#EEF8FF; padding:10px; margin:10px;"> | ||
| Line 28: | Line 28: | ||
| | ||
| − | == | + | ==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...] | 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...] | ||
| Line 43: | Line 43: | ||
| + | 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 {{WP|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. | ||
Revision as of 06:10, 8 November 2013
Software Development
(In a small-scale research context)
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.
Contents
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
- 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.
