This document is the Software Development Plan for the GHOSTS project.
This document includes the following chapters :
GHOSTS is a software application intended to help genealogists in their activities. Those activities are the following :
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.
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.
Requirements are developed at three levels:
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).
Graphical representation of software design shall be performed using UML diagrams.
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).
Each namespace shall be documented, presenting the following information:
Each class shall be documented, presenting the following information :
Each public method shall be documented, presenting the following information:
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).
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 :
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 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.
Objecteering, Linux Mandrake 8.1, gcc 3.2, savannah, cvs, Mozilla, autotools, flex / bison, doc++