The automation project on attendance started in our college by the active involvement and support of Dr. S. Balaji and my colleague Vivekavardhana Reddy. Also present in the team were me, Ramesh Babu along with Nallamma and Suma Manjunath. We as a team worked under the guidance of Balaji sir. We developed a small webpage to enter every days attendance into a database.
Every faculty had to write on a slip the student USN's who were absent on a particular day on a particular hour. Information in these slips were to be entered into a database using this interface on the same day.
Our webpage is almost ready except for minor changes in looks or features.
We intend to publish this package to the open source community so that it could be used by other colleges. I still need to figure out how to publish software as a package/application.
Final modification to our project was to make it work on the mobile so that the faculty can enter the attendance in his tablet or handheld. We also have capability to send sms to parents everyday about the attendance of their sons/daughters.
Key Takeaways:
If you go through these pages you will get an idea of creating a website of your own or a similar website for an ERP package. Alternatively you could get involved and help us in developing this package further.
Learnings:
Looking back at the project and its complexities if i were given another chance to develop this package what were the things i would have done differently?
1) Low entry barriers: An ERP package for educational institutions is surprisingly simple to develop. Although several features like accounting package or interface to our website with it is still lacking, we were quite capable of doing that.
2) Using the wrong model: I see that we kept learning the language and the database interfacing as we developed the code. At some point in time after learning enough, we should have taken a decision to refurbish the software entirely. i.e discarded the entire code and started from scratch with a new design. We kept on modifying legacy code iteratively. We should have gone back to the design board and think big. "See now we have learn't something useful. Lets make something big and useful out of it". It requires audacity and courage to venture afresh. We knew our software would not be 100% success. We should have tried to take failure in our stride and achieve 100% reliable code. In software projects the pain of developing software and the experience is what remains with you. Your code might not be with you after some time but if given another opportunity you know you can do it again and much better.
3) Faulty database schema: Our initial database schema was incapable of handling new requirements. We had to go back to design and develop a new database schema(it never occurred). Instead of discussing the disagreements openly we kept skirting the issues until it blew out of proportion. We consoled ourselves that ours was a project to learn something. We did not intend to develop production level code. At-least we thought so. But the expectation was for a package which would satisfy all requirements.
4) Inadequate testing: We should have devoted some time to discuss future problems that may arise and to keep an eye on the scope of the project. Lack of rigorous testing can also be counted as one of the drawbacks in our package. There were many anxious moments and considering inadequate manpower we were handicapped.
5) Job Security: We were teachers basically and somehow we thought our jobs would not go away if we fail.
5) Job Security: We were teachers basically and somehow we thought our jobs would not go away if we fail.
No comments:
Post a Comment