JISC

JISC doesn't prescribe how you should perform technical development, but does expect you to follow best practiceBefore developing detailed technical plans, you should consult any background resources mentioned in the programme circular or ITT.

Software development

Any software development should follow a defined development process/methodology that is suitable for the type of development beginning undertaken. JISC doesn't stipulate a single methodology but does require you to define the process or methodology that will be followed. The development process/methodology should be clearly stated in the response to any circulars/ITTs and form part of the project quality plan.

Requirements

• Requirements not stated in detail in a circular/ITT should be specified at the earliest opportunity in the project lifecycle
• UML use cases, scenarios, and class diagrams should be used to express requirement/functional specifications - this may be supported by other methods of capturing and expressing requirements
• Requirements should be baselined through the configuration management process to scope exactly what the software will do within each release - changes to requirements must follow the change control process defined by the project
• Requirements should be re-used in developing test plans and user documentation
• Well-defined requirements should describe the software’s externally-perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be 'user-friendly' (too subjective)
• Where rapid development and agile development methods are used, requirements are refined through close interaction and cooperation between programmers and users

Design

• Design of the logical/functional and physical/internal system should be express using UML
• Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works correctly when implemented

Coding

• Coding of software should follow the stated design
• Coding and annotation standards must be consistently applied
• The project should apply the standard for coding and annotation consistently as defined in the project quality plan
• Code should be modular, tidy and well-documented internally (annotated)You should define the quality control procedures / techniques you will use

Quality control and audit processes

The quality control process should indicate:

• When or at what stage testing will take place
• How it will be carried out
• How results/faults will be recorded
• At what level software will be tested
• Any testing tools that will be used

The quality control process can be viewed as a high-level testing strategy. The audit process is the ability to trace back the tests/checks that have been performed as part of quality control. This is useful for tracing software faults and may be required as part of the project’s acceptance criteria to allow JISC or an external evaluator to review the rigour to which the software was constructed.

Change control and configuration management processes

Projects should define and implement a change control and configuration management process to ensure:

• Software and documentation is base-lined and version controlled
• Software and documentation is securely stored (e.g. CVS, Subversion, Source Safe or www.sourceforge.net)
• Intermediate versions of software are retained
• Changes to software and documentation are controlled, authorised, and auditable
• Releases of software and documentation have been quality assured (i.e. tested, versioned, and documented).

Change control is the process by which a project controls any changes to the project plan, scope, budget, specifications, requirements, deliverables, standard of quality, timescale are assessed and agreed/rejected. This can be as simple as a weekly project meeting where changes are discussed, documented in meeting minutes and actioned. It is important to define who has authority to accept or reject changes to the project. Any change to the original project plan, software specification, or user requirements should be traceable via audit and the reasoning for that change clearly recorded. A useful technique for documenting and managing change control is the use of an issue log which records all issues, requests for change and software faults/off-specification (e.g. test failures, over due software components). Held in the form of a spreadsheet, this can be use to provide an agenda for the weekly project meetings, record actions/decisions, and provide an audit trail.

Configuration management is the control of anything produced by the project (e.g. documents and software) providing the mechanism for managing, tracking, and keeping control of all the projects deliverables. For software this will take the form of a software storage system (e.g. CVS, Subversion, Source Safe, or http://sourceforge.net) that safely stores, versions, controls access to, and records status of the software.

Testing

• Testing plans and cases should be produced during design based on requirements and design specifications
• Testing should cover unit, module, system, integration, load and user testing
• A range of testing methods/techniques may be used e.g. automated testing
• Testing procedures should be auditable, i.e. results, faults and fixes are recorded and traceable
• Testing forms part of the configuration management process as only after software has been tested/quality checked can it be versioned and stored/released.
• Consideration should be given to the relevant standards compliancy and interoperability tests that need to be undertaken especially when developing standards based and open source software
• Projects should stage development to release incremental working but incomplete versions of software

Documentation

• Projects are expected to produce user, requirements, design, and system documentation
• Projects must provide requirements, design, and system documentation in UML version 1.4, and submit documentation in the source format (e.g. Word, Excel, Visio) and the open source format PDF unless otherwise agreed with JISC
• Documentation should be produced throughout the life of a project, in line with the software development acting as an audit trail. The production of documentation is not to be left until the end of a project
• Documentation must be in PDF and its original source format
• Criteria for the acceptance of documentation will be defined by the JISC programme manager

Further resources

Various projects and advisory services affiliated with JISC can also offer guidance on best practice:

• Digitisation  AHDS (Arts and Humanities Data Service) has an Introduction to creating digital resources, plus other guides and case studies.
• Digital Images  TASI (Technical Advisory Service for Images) has guidelines on all aspects of digitising images and creating image archives. They also offer training courses.
• Technology  TechWatch (Technology and Standards Watch) keeps track of developments in ICT that may impact on education. They commission reports on important technical and standards issues, and have links to resources for over 100 specific technologies.
• QA Focus was a post supporting the IE programmes to ensure that project deliverables were interoperable and projects adopted standards and best practice. The QA Focus website has best practice briefing papers on a range of topics, including digitisation, websites, metadata, and software.