But first, let's talk about the differences between developing software for a LIMS (Laboratory Information Management System) project compared to other types of software projects. Because the software used in a pharmaceutical or chemical laboratories is heavily regulated and must be validated to strict standards, version control requirements are often multifarious. It is not enough to simply know the latest stable and development versions of a file, as is acceptable in many projects.

Also, most LIMS projects use the waterfall methodology. In the waterfall methodology, each phase must generally be completed before the next one can begin. While this can be much slower than a more modern or agile methodology, such as XP, the checks and balances that come from one phase flowing into the next are, I assume, what cause the people who make big decisions at pharmaceutical companies to choose waterfalls (or maybe, like the author, they all just have a strange obsession with Hawaii).

A software development project that follows the waterfall methodology may have the following lifecycle phases:

• User Requirements gathering
• Functional Requirements gathering
• Design
• Development
• Code Review
• Unit Testing
• Integration Testing
• System Acceptance Testing

It is worth noting that the testing phases are quite different from other methodologies. For example, while many projects execute unit testing every day (maybe multiple times every day!), unit testing in a validated LIMS environment usually occurs officially only one time, at which point documentation is instantiated to prove the soundness of the code. Once a file has passed unit testing, the test is not repeated unless the code is changed.

With all that said, all you really need to know is that a given file on a typical LIMS project has significant version tracking requirements at each phase of the development lifecycle. Before we start exploring how Subversion can be extended to satisfy those requirements, let's materialize some of the requirements by looking at questions that might be asked regarding the deliverables of a LIMS project:

• At what stage in the development lifecycle is the deliverable? For example, is foo.pkg currently in code review or unit testing?
• What version of a given file was used for a particular development stage? For example, what version of foo.pkg did we most recently unit test?
• What is the name of the unit test execution document for the foo package? What are all the files (and versions) that are tested in the foo unit test?
• When was the unit test execution document for the foo package created/approved/executed?
• What document version of the foo package unit test document was most recently executed?
• For a given stage, how many deliverables are complete and how many still need to be completed? For example, during a big unit testing effort, what percentage of deliverables have completed testing?
• What documented requirement(s) does the foo package satisfy?
• What project/sub-project/module does the foo package belong to? What are all the files (and versions) that make up the foo project/sub-project/module?

Someone unfamiliar with the inner workings of a LIMS project may consider this amount of versioning information excessive. But I assure you, the data required to answer these questions is absolutely necessary to maintain control of a validated LIMS project. Next week, we will explore how Subversion can be extended to answer these questions.