<p>New Concept&rsquo;s initial proposal to UNICEF regarding developing the MAPEDIR web based system including the following section on Iterative software development. Phase II represents the next major iteration in the development of MAPEDIR as it aims to build in features that were not envisioned as necessary in phase I but were found to be important during the development or user testing of the Phase I MAPEDIR system. <br />Iterative Software Development<br />Software development is necessarily an iterative exercise. Software is developed in versions. Once the software has been developed, the user may find new reports or features it would like incorporated into the system. These can be recorded and when substantial functionality needs to be developed a separate contract can be created to develop this functionality in subsequent version of the software.</p>
<p><br />The Post Deployment Feature Request File:</p>
<p>It has been recommended that during the field testing process, a Feature Request File be maintained by UNICEF. This will list all the features that users in the field are recommending. After 6 months of user testing this Features Request File can be examined by UNICEF and New Concept to determine which features they would like to incorporate into the software.</p>
<p>This Feature Request File will serve to be a repository of feedback from the field that will highlight the possible areas for change in the system from a crucial user perspective. Not all the features listed here need to be executed. However this provides a good starting point for management to determine the features that are to be included in later versions of the software.</p>
<p>Immediate Requirements for MAPEDIR Phase II:</p>
<p>Post the development of MAPEDIR Phase I, several key requirements have come to light in user testing and also discussions between UNICEF and NC. These are the most important requirements and are listed below. It is envisioned that the Feature Request File will gather additional requirements however these can be addressed in Phase III which can be a refining phase. MAPEDIR Phase II whose requirements are described below comprises of crucial changes that are of key importance to the use of the MAPEDIR software. They are as follows:</p>
<p>1)&nbsp;The Ability to Save and Go Back To Previous Forms<br />2)&nbsp;The Creation and Deployment of an Offline Version of the Software</p>
<p>Description of the Phase I MAPEDIR System:<br />The MAPEDIR system is very large system. There are two versions of the Phase I system, version 1 and version 2. These versions reflect 2 survey formats, the old survey format and the new survey format. These are very large surveys.</p>
<p>The version 1 survey is implemented in the MAPEDIR system and has the following specifications:</p>
<p>No of web forms: Approx 65<br />No of reports: Approx 60<br />Fields in the forms: Approx Over 1000<br />Validations in the forms including data type checks and skips: Approx 1000</p>
<p><br />Similarly version 2 of the system which is a variation of version 1 due to a slightly different format of the survey has the following specifications:<br />&nbsp;</p>
<p>No of web forms: Approx 12<br />No of reports: Approx 60 (Reports are the same as version 1) <br />Fields in the forms: Approx over 800<br />Validations in the forms including data type checks and skips: Approx 800</p>
<p>The above specifications make clear the large scale of the MAPEDIR system. This large scale has one corollorary. Changes that are to be made system across the whole system are very time consuming given that they have to be executed for so many fields, forms and reports. This must be kept in mind in recommending system wide changes. They will be time consuming and hence expensive. However where specific changes are needed, i.e. changes to a particular report or form or field, these are relatively straightforward as they are limited in nature and do not have to be rolled out across the entire vast system.</p>
<p>Analysis of the MAPEDIR Phase II Requirements:</p>
<p>Having described the scale and nature of MAPEDIR Phase I above, we can now proceed to analyze how the critical changes that comprise the Phase II can be approached. These are listed and discussed below:</p>
<p>1)&nbsp;The Ability to Save and Go Back To Previous Forms</p>
<p>Given such a vast system and so many forms, an essential feature is that there needs to be a way to go back and forth between the forms by the user. Currently when the user is entering data they start by filling out form 1, then they proceed to form 2 and so one till they reach the last form (and this could span approx 20 forms for version 1 and approx 12 forms for version 2) Given that data entry is currently done online, this is a very difficult task. This is because:<br />1)&nbsp;Human attention span is limited and it is very difficult for a user to enter 20 forms all together. There is currently no feature to enter some of the forms at a time and come back and enter the rest later.<br />2)&nbsp;Internet connectivity and electricity are unreliable in the field. In the case of a gap in internet connectivity or electricity (without power backup) the connection will break and if the user is in the midst of entering 20 forms, this process will be disrupted and they will have to start again.<br />3)&nbsp;Given the above two simple but crucial considerations, it is envisioned that it will be very difficult for users to complete data entry the way the system is currently structured.</p>
<p>Therefore it is recommended that in MAPEDIR Phase II, a system be put into place that allows the user to save each form as they complete it. This is however complicated by the fact that the MAPEDIR survey has an indicate system of &ldquo;Skips&rdquo;. For example when a certain field is filled out, the system may want the user to skip several pages ahead and then proceed from there. A different choice will cause them to skip to another page. Given the large scale of the system, in this &ldquo;skip&rdquo; scenario, there is only one logical possibility for saving the forms taking skips into account.</p>
<p>This is that at every form the user will be given a choice to 1) Save the form as is 2) Go back to a particular form number. If they choose to save the form this is straightforward.&nbsp; If on the other hand, they feel they have made a mistake and they would like to go back to a certain previous form, the system will warn them, which all forms between the forms they have chosen to go to, and the current form will be deleted. If they select yes to this option, then they will go back to the form they have requested, all data in the interim forms being deleted.</p>
<p>This deletion of data in the interim forms in a logical necessity given skips. This is made clear by the fact that if the user chooses a certain skip path in a previous form, then returns to the same form and chooses a different skip path, then the interim forms will contain wrong data and hence logically, the correct solution is for them to be deleted and reentered.</p>
<p>The above has been arrived at after substantial discussion of the technical team at New Concept and is envisioned as absolutely necessary for the web enabled system to be viable in the field.</p>
<p><br />2)&nbsp;The Creation and Deployment of an Offline Version of the Software</p>
<p>The incorporation of the functionality to go back and to save forms will help the users a lot. However another important feature is to have an offline version of the software that the users can fill out offline and once a record is complete, they can press and upload button to upload the data to the online system.</p>
<p>This still requires the back functionality as the users even when working offline might make a mistake on form 19 and want to go back a few forms rather than start again from form 1. Given this back functionality, the offline system allows the user to work at ease without the sword of internet access or electricity breaking their connection with the system.</p>
<p>However there are several considerations to implement the offline solution:</p>
<p>1)&nbsp;A version of the online system will have to be installed at each offline location. This will require the installation of a Microsoft Operating system (like XP or 2003) and MS Sql server. There are out of pocket costs related. Further the installation of the system offline will require a technical person to go to the location and set up the system. Further methods to address computer failures and reinstallations will have to be put into place. <br />2)&nbsp;An offline system has the above overheads. And needs to be evaluated from the point of view of necessity given the Back functionality of the online system.<br />3)&nbsp;The offline system needs to be discussed between NC and UNICEF regarding its necessity in MAPEDIR phase II.<br />If implemented the offline module will allow users to enter data offline and upload it at once. However given that users can save online if the first part of the MAPEDIR Phase II is implemented, a valid question is whether the Offline version is necessary, given the costs of offline installation and maintenance.</p>