Improve the HTML Form Entry module - Project Plan

Methodology used for GSOC

I’ll use an AGILE based methodology, emphasizing on short iterations (with tangible deliverables), so the community can immediately give feedback, early on the development stage.

I value documentation, especially about design and architectural decisions, so the community can also have a say and help me reach a solution, and about workflow processes, so the community can extend or recreate independently what I’ve done.

In order to better quantify and estimate my progress, I subdivided each iteration into tasks. These tasks will be tracked (manually) by myself in an Google Spreadsheet document. The tasks presented here are subject to change and to be divided into subtasks.

Plan for GSOC:

IT1 - May 23 - June 18 (Faculty Projects and evaluations):

This iteration is mostly about the major decisions on designing the solution for the htmlformentrydesigner module (should we keep some code from the previous version? should we start from scratch?) and the update form schemas project. During this time I’ll be quite busy with my faculty projects and evaluations, so it’s more a documentation and research phase than development.

T101 - Document the changes needed to be done on the htmlformentrydesigner module, to reflect changes in the OpenMRS architecture.

T102 - Document the changes needed to be done on the htmlformentrydesigner module, to reflect changes in the htmlformentry module.

T103 - Document how an HTML form can be updated on the OpenMRS Data Model (what attributes will it update?, from where comes the data to update?).

T104 - Document how a Form Schema on the OpenMRS Data Model should generate the code for an HTML Form.

IT2 - June 18 - July 9:

This iteration is focused on implementing the update of the form schema tables, when saving an HTML form. An initial structure for the HTML Form Entry Designer should also be implemented, depending on the Architectural Decisions on T101 and T102. Finally, documentation of how all functionality present on the current version of the HTML Form Entry module can be implemented in the HTML Form Entry Designer should be created.

T201 - Implement the update of the form schema, on the OpenMRS Data Model, by saving the HTML Form.

T202 - Structure the HTML Form Entry Designer module, according to the Architectural Decisions.

T203 - Document how the functionality of the current version of the HTML Form Entry module can be mirrored in the HTML Form Entry Designer module.

(Midterm Evaluations)

IT3 - July 9 - July 23:

This iteration is focused on documenting the architectural decisions on adding new functionality to the HTML Form Entry Designer module (mirroring changes in the HTML Form Entry module), based on the output of T203. This architecture should also be implemented on this iteration and the process of adding functionality to the HTML Form Entry Designer documented on T203 should be started.

T301 - Document the architecture on adding new functionality to the HTML Form Entry Designer module (for instance, the previous version used a poor-documented widget system)

T302 - Implement the architecture from the output of T303.

T303 - Implement some the functionality documented in T203.

IT4 - July 23 - August 6:

This iteration is focused on finishing implementing the functionality of the HTML Form Entry module in the HTML Form Entry Designer module. The HTML code generation from the Form Schemas should also be done. Basically, the whole project would be completely functional by the end of this iteration.

T401 - Implement the HTML code generation, for creating HTML forms, based on Form Schemas on the OpenMRS Data Model.

T402 - Integrate the HTML code generation with the HTML Form Entry module, by populating the htmlformentry_html_form

T403 - Finish the implementation of the HTML Form Entry Designer functionality (from T303).

IT5 - August 6 - August 15:

This iteration should be focused on integration, testing, documentation and last-minute bug-fixes.