Since release of first public test build of analysis in october last year good progress has been made. In judging progress it is important to recognize the nature of the EpiData Association, the size of economic contributions for development and the pricing principle - freeware.
The latest build is available from http://www.epidata.dk/testing.php
The list of what is fixed and remaing by build number is seen at: http://www.epidata.dk/analysisinfo/docs/versioninfo.htm
The bug reporting database is shown at: http://asp.epidata.dk/support/default.asp
The routine tests now include more than 350 conditions looking at as well overall, stratified and segmented conditions and comparing to external standard estimates. The aim of the complete test suite is to certify all available commands for a chosen number of representative datasets.
The definite condition to meet before release is that the quality system certifies as well stability as correctness of estimation.
But also that the implemented principles are logical in structure and documented such that decisions and requirements are clear to the end user. An example of this is the latest preparation of a detailed description of the principles of the output implementation of html and style sheets. The number of combinations of font selection, sizes and character sets is very large requiring control at the level of the end-user. This is available now, but for persons with very little or no knowledge in HTML and stylesheet principles the control of output can be a mystery.
The status list includes :
a. The main design principle of user interface, output formulation, number of commands, principle of missing data is final and most of it working.
b.Finalisation of a simple way for users to define interface with local fonts etc. as part of the installation is almost finished.
c. A coherent strategy for handling missing values across commands is being implemented.
d. Some issues of table estimation exist. E.g. with correct turning of outcome and exposure. Some "Floating point and "Pointer" error messages occurs with some combinations of data
e. Some aspects of graphing are giving problems. (Also relates to point b)
Re c: e.g. if the user requests frequency tables for say 5 variables: 1. freq a b c d e 2. freq a b c d e /nomissing the first will show all data for all records, whereas the second will demand complete data for all five variables. This principle should be the same across all commands. And the implementation is needed as part of the testing of handling the data correctly.
Kind regards