Main points

There are three basic parts to the initial and later development of the web site and the application.  Each should contain some record of what was done.

Development and Testing should contain at least the requirements for what is wanted, a detailed specification for how each requirement will be achieved, some source for any program code and details of how the final result will be tested.

Change control is meant to detail any changes made to any previous requirement, specification or code.

Release Control covers the details of what version of the software an end user is getting (which should be easily identifiable within the application itself) and lists any changes made from any previous version.

The larger and more formal the development the more documentation is produced and the more detail it contains, documents may be split into even more separate documents.

Here we will keep the number of documents to a minimum, so for example our 'specification' will cover requirements and detailed design for the initial project.

In this project ideas and notes will filter down from the 'blog' linked to the web site, into the specification document and then into the web site or application as appropriate.  For the application itself, the user guide contains a simple diagram showing the workflow for bugs and new features.  So the blog will act as a kind of requirements document. The project architecture page also shows how information flows into the few documents required to support the project.

The nature of the application itself (being web page based) means that the pages are the source code and the 'programs' are interpreted by the browser, so the application should be self-documented to some extent and comments inserted where appropriate.

Now to cover the above points in a little more detail.

Developing and Testing the Application

There are a number of methods or models used in software development and testing, and as probably stated before, we have no intention in covering the whole 'Software Development Lifecycle' in this project, just the minimum required to get the job done and not bore everybody to death. Again, this project is aimed at anyone with an interest in developing their own applications (but have not really had vast experience) and particularly those interested in science - in this case Astrophysics - but 'programming' is not their main subject. If you want to know more about all the various methods then Wikipedia is not a bad place to start and there are plenty books on the subject, and of course you can Google it.

In the basic waterfall model of application development the process simply moves down in a series of steps from specification to the final software product.  In the V-model (a software development process which follows on from the waterfall model), instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the V shape as shown below.

The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model can be said to have developed as a result of the evolution of software testing, which is the more interesting quality control aspect - making sure the application does what you want! Various testing techniques were defined and various kinds of testing were clearly separated from each other which led to the waterfall model evolving into the V-model.

V Model The tests in the ascending (Validation) side are derived directly from their design / requirements documents in the descending (Verification) side. The V can also stand for the terms Verifications and Validations. V-Model should reduce the time for whole development of a new product as tests should be designed at each stage and feedback used to ensure the documents at each stage are correct, rather than wait till the application is installed to be tested and find major changes are needed because the design documents were not checked sufficiently.

This is a more formal development and testing model for large projects and can involve a lot of documentation and reviews, no stage should be signed off as complete before any previous stage.

Testing is the process that covers both the documentation and the final software (at appropriate stages) to ensure both are of good quality, and good documentation should produce good code and final application.  If you want to know more about software testing read.

info LEARN MORE: Software Testing - An ISEB Foundation - this book provides an introduction to the breadth of software testing activities in real life projects and gives and idea of how projects are developed.

As well as explaining the basic steps of the testing process and how to perform effective tests, it provides an overview of different techniques, both dynamic and static, and how to apply them. 

This book supports the revised ISEB Foundation Certificate in Software Testing.  This will go into more depth than is required for this project, but is very useful if you want to learn more about the stages of software development and testing.

Software Testing: An ISEB Foundation Author: Brian Hambling (Ed), Peter Morgan, Angelina Samaroo, Geoff Thompson, Peter Williams
Publication Date: September 2006
ISBN: 978-1-902505-79-4
Format: Pbk, 246 x 172mm

Iterative and Incremental development - our chosen software development method

This  is a cyclic software development process developed in response to the weaknesses of the waterfall model. It is a part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks talked about on the net.  These are all meant to produce software more quickly in smaller quantities at a time and incorporate user changes in the next 'version' if still not correct.

Iterative Model

The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of a subset of the software requirements and 'iteratively' enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.

This method suits our project as we do not need to go through a whole series of documents before writing some code that works in order to see if it does what we want. This will make the subject of more interest to those who are just interested in how to start off in software development, we are not aiming at the professional developer!

The Procedure itself consists of the Initialization step, the Iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can use for real. It should offer a sampling of their key requirements and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase.

The specification for this project contains a short list of starting features which is sufficient to produce a working application and find out if it can a) work and b) help find easiest way standardise and write the code. What we learn here should then make the next iteration to add a new function(s) easier.

The iteration involves the redesign and implementation of a task from project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a mission-critical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results.

In our project we have restricted the documents to a specification and a list of 'artifacts' making up the application - these will be mostly web pages, images and some javascript files common to several pages.

These documents are under revision as we go round our cycle, feeding back information from the 'coding' side.

Change Control

Here we are talking about controlling the changes to our application development so we know what we have changed since the last iteration and do not break something that worked previously.  Regular backups are important and development is split into different folders, with each application release being copied to a new folder to make any major additions or fixes for the next release, which is then tested before being made available to users, and then becoming the basis of the next release and so on.

Release or Version Control

Here we want to know what version of the application we are running, what the most recent version is and what new about it or what 'bugs' have been fixed.

Software may have a version number, release number and build number of that version / release. How it appears will depend on that software developers own standard. 'Version 1.0' is generally accepted as the first real working version of the application generally available and acceptable to users.

In this project we will use a simple version number and date e.g. v0.30 20080512, if we change the application 20 times in one day the changes will be cumulative so only the final change will affect the version number (if at all) and changes will be summarised in a text file AstroChgLog.txt that is included with the documents supporting the application.   The reverse date number shows the date the software version was changed, so this basically there is no argument over which is the most recent version! New features will change the v N.00 and bug fixes will change the v 0.nn.

This principle can be applied to supporting documentation as well as software to identify the most recent version.

New versions of the application will be made available on the main web site and Any files that support the application may be available as separate downloads.