Introduction

This document is the Software Development Plan for the GHOSTS project.

This document includes the following chapters :

• The chapter “Software overview” presents the vision (the reason for being of this software) and the high level architecture of the software
• The chapter “Standards” lists the standards applicable on this project
• The chapter “Software life cycle” presents the activities performed to develop this software
• The chapter “Software development environment” presents the tools used to develop this software

Software overview

Vision

GHOSTS is a software application intended to help genealogists in their activities. Those activities are the following : 

• storage of genealogical data
• publication of reports about genealogical data
• exchange with other genealogists
• analysis of genealogical data to provide guidance hints for research

More than a computer tool, GHOSTS aims to be a genealogical helper : its services shall be adapted to the Genealogist behavior, and answer to realist use-cases.

On a technical point of view, GHOSTS shall rely on the state-of-the-art technologies ; it shall intensively include effective open-source standards, in order to provide efficiency in its development (do not re-invent the wheel) and long-time reliability and maintainability (conformity to open-source standards should provide those benefits). To improve long-time reliability, GHOSTS shall depend only on free software components.

Architecture

Standards

The GHOSTS development standards shall comply with the GNU standards (ref. TBD).

The instantiation of those standards on this project is provided in the following paragraph, highlighting particular issues and deviations.

Software requirements standards

Requirements are developed at three levels:

• application requirements describe requirements applicable to GHOSTS ; those requirements list global functions provided by GHOSTS. 

• package level requirements describe requirements applicable to high level packages (GEDCOMPARSER or GEDCOMVIEWER)

Traceability shall be established between application requirements and software high level requirements

Each requirement shall have an unique identifier base on the format REQ_[GHOSTS|LIBGEDCOMPARSER|GEDCOMVIEWER]_X where X is a sequence number (1 or more digits).

Software design standards

Graphical representation of software design shall be performed using UML diagrams.

Software coding standards

C++ coding rules:

Naming:

• name of class shall use low case and upper case to separate words 
  • example : class IndividualRecord
• constructors and destructors shall be consistent with the name of the class and C++ constraints (i.e. NameOfTheClass and ~NameOfTheClass)
• assessors shall be named as following:
  • setAttr for the setter of the attribute Attr (exemple: setId)
  • getAttr for the setter of the attribute Attr (example: getAttr)
• other public methods shall use low case and upper case to separate words
  • example: Navigate()
• private methods shall use low case and underscore to separate words
  • example : init_record()

Mixity with other coding rules may occur since some external libraries complies with other rules (for instance in Gtk-- all the methods use low case and underscore to separate words, so derived class of Gtk-- class can have inconsistency in its public interface).

Documentation:

Each namespace shall be documented, presenting the following information:

• overall purpose of the namespace

Each class shall be documented, presenting the following information :

• overall purpose of the class
• known issues about the use of the class

Each public method shall be documented, presenting the following information:

• overall purpose of the class
• presentation of the output & parameters : purpose, range
• method overridden by the current method
• known issues about the use of the method, including robustness and side effect

Such documentation shall be written as comments in a style allowing the formatting of those comments in a more displayable way (useable by doxygen of doc++ for instance).

Software life cycle

The software life cycle is an Y life cycle : the development of GHOSTS is motivated by the overall goal expressed in the Vision, and constrained by the architecture chosen according to state-of-the-art and reliability / maintainability objectives. The Vision and Architecture are described in this SDP.

From those information (Vision and Architecture) starts the requirement analysis activity. This activity consists in writing down use-cases and man-machine interface specifications. The use-cases describe activities of the genealogist, without considering software as a means to realize or to help with this activity. The man-machine interface specifications introduces software aspects to realize use-cases with the assistance of a computer. Use-cases and man-machine interface are described in non deliverable documents. As a summary of those use-cases and man-machine interface, a list of application requirements is written in the requirement analysis document.

After the requirement analysis starts the design activity. This activity consists in two phases : 

• developing high level requirements needed to implement the application requirements, and also refining the architecture. 
• developing low level requirements 
• The Design document shows the result of this activity : it displays the architecture as a set of textual description and UML diagrams representing the software, and the list of high level requirements.

After the design activity starts the coding activity. This activity is the implementation of the design in the target programming language, mainly C++ in this software.

The overall verification process is the following :

• the coding activity is verified with a defensive programming strategy and complementary analysis : definition of assertions in the code, analysis of compilation reports, memory leaks analysis and coding rules conformity analysis.
• the design activity is verified with an analysis of consistency between derived requirements and design, and test of derived requirements against executable.
• the requirement analysis is verified with a validation of executable behavior against use-cases and man machine interface specifications.

The verification process results are not stored. Defects reports are submitted when their correction is not immediately performed.

The overall software life cycle is iterative : the vision is developed incrementally. Each increment engages the following activities.

Software development environment

Objecteering, Linux Mandrake 8.1, gcc 3.2, savannah, cvs, Mozilla, autotools, flex / bison, doc++