Author: Alemi, R.
The present project was carried out to assess the UNICEF-supported software in health sector in Iran. The scenario of software development activities is more or less the same. Usually a manager asks a programmer to develop a software program, which he then gives to a group of end users to work with. The manager typically has little knowledge about the software development process, and the programmer has no idea about the system he is developing for. The end user is not invited in the process until the final phase, when the finished product is implemented.
Purpose / Objective
To assess the UNICEF-supported HMIS software developed in Iran, specially the DTARH project, and to document the current state and to propose solutions for this software to adapt the new concepts of the software engineering technology, hence avoiding the typical crisis. Selected similar activities of other parts of the health sector were also assessed to show that the solutions can be used in other projects as well.
Using WHO and academic guidelines, an assessment tool was developed in the form of a questionnaire, and a conference was held in which key people involved in five different software projects from different parts of the health sector were invited. These included high ranking managers, software engineers and the end users of this software. This group discussed the most prominent problems, most pressing needs, and the most practical ways of solving these problems, and a summation of their views was incorporated to the final plan of action.
Key Findings and Conclusions
There are various strengths and opportunities in the current environment. Managers and policy makers respect the value of information management and are ready to invest in reasonable projects. Software technology and industry can be easily imported and incorporated in the new projects. There is minimum client resistance to change and adaptation to the new strategies; in fact, the end users are the most eager group asking for changes and updates, because they see how a good software solution can help them with their responsibilities.
However, there are also weaknesses and threats. The managers fear having to depend on one programmer or group of programmers to maintain and upgrade the software once it is developed. The programmers complain that there are no defined standards and processes to define what is and what is not their duty. They have difficulty receiving their payments since there is no official place for a software programmer in the health system. The end users are confused as to what they can and can't expect the programmers to do for them. They don't know which upgrade they could ask for. There is no official way to report a bug on a project.
A plan of action is compiled to address the findings of this investigation. The most pressing need is to construct standard documentation for the existing software. This will eliminate the dependency on the original programmer and facilitate the delegation of maintenance and upgrade to third party software teams. A proposal to create a committee for the review and selection of information standards is compiled, to be handed to the Ministry of Health. Necessary steps are outlined to convert the existing software to component-based, fully-modeled solutions.
All software contracts should state that complete development documentation (and not merely the source) should be provided as the final requirement.
All Software contracts should ask for an object-oriented and component-based design that complies with one of the industry standards (e.g. UML, ORM, ...).
All Software contracts should include a website for the end users to report bugs and receive help and updates.
PDF files require Acrobat Reader.
Health - Other