Skip to content

INAR Project

December 7, 2012

This semester we worked on a system called the Indian National Autism Registry for an organization called Action for Autism.  Action for Autism is an organization based in India whose goal is to “put autism on the Indian map.”  Our project was an online survey tool that allowed the parents of a person with autism to fill out surveys collecting information about the person’s demographics and medical information.  The data collected can be used to assist in autism research, as well as to make India’s government more aware of the prevalence of autism in their country in order to drive related policies.  

We used an existing open source project Limesurvey as a starting point for our project.  The survey that AFA had designed for INAR was far from simple.  It had many question types: free answer, numeric only, multiple choices, grid of answers, date selection, etc.  Some questions needed to change their text based on the responses to previous questions.  Questions needed to be shown or hidden based on other responses.  And to top it all off it all needed to be editable by a non-programmer in the future.

Limesurvey was great because it had support for all of the above.  Limesurvey was not exactly what AFA needed though: There was no concept of a participant account or login.  However it did allow survey access to be restricted by generating a one-use key that could be given to the participant.  So we started down the path of trying to merge an account management system with Limesurvey such that a participant could register, and sign into an account and be provided with a link to take the survey.  We ended up dropping the idea of the participant needing to sign in to take the survey.  Instead a link to take the survey was just emailed to the user. 

For the administrative side of the product we created admin pages allowing an administrator to assign participants to surveys, and select which surveys a participant should be automatically assigned to.  Originally these admin features were accessed through an admin interface on the main site and the survey editing was done through the Limesurvey admin interface.  We eventually merged all the admin features together by adding additional pages to the Limesurvey admin interface, but not before first trying to recreate lots of the interaction with Limesurvey through our own admin interface.

There were also a lot of changes on how we interfaced with Limesurvey.  The admin interface for assigning participants at first interfaced with Limesurvey by just inserting data into its database.  Later we found that Limesurvey had API functionality, and we could interact with it through API calls.  This seemed like the right thing to do, because even if database structure changed in a future version of Limesurvey the API calls would probably remain the same.  However it also ended up causing slower page load times.  When we eventually moved all the admin pages into the Limesurvey interface we change everything to interface directly with the Limesurvey objects.

As you can see there was a lot of back and forth on this project.  I think some of this could have been avoided.  The day we learned what project we would be working on there was a huge push to have a working prototype in 2 weeks.  This meant there was no time to plan or design anything.  We just had to make something and make it now.  It didn’t have to be that way though, there was over a month at the start of the semester before we were finally told what project we would be working on.  Had we know earlier that time could have been used for planning and design.  I urge the professor to try and have project teams sorted out with two weeks of the start of the semester in the future.  In most (much less demanding) project based courses projects teams are determined within that time frame.

The experience has pushed me away from agile development, at least for new projects.  I do think it has its place for products that have matured and require several relativity minor updates.  Maybe also for a project where requirements are poorly specified, although I think non-functional prototypes serve that case better.

In the end we made something that will help the AFA toward their goal of collection data to spread autism awareness, and I am happy about that.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: