Initial proposal: “A web application that will fulfil organization (ex: university classroom) attendance through a survey system.”
In the original proposal, we had a specific product (a survey application) with a specific goal (classroom attendance). We believe that the original scope of design was too narrow. Therefore, our deviation in the final project was not trivial. We decided to create a generic application that can be adapted to suit our specific needs. By following a more global design, we have a stable project that can be tailored to various clients.
We closely followed the proposed requirements, use cases, and the UML diagram. We did add numerous use cases and changed a few attributes in the UML diagram.
Neither of the team members had any previous experience developing web applications, using Ruby, Ruby on Rails, or using a database. Moreover, we had no experience with any version control systems.
The app was modelled using the read-only interface pattern. We had two types of users: a super-user and a regular user. A super-user is any user that can create, modify, and delete any part of a survey; whereas, a regular user is any user that can only participate in a survey. Therefore, a regular user gets to view only the read-only survey.
gem 'rails' (4.1.5) - however, the gem file lists 4.2.0.beta4 as the project began following a tutorial
gem 'bcrypt' (3.1.7) - for user Auth
gem 'foundation-rails' (220.127.116.11) - for layout design
a databse - sqlite3 in development || pg in production
a web-server - unicorn