Process Description

This is the process description.

Software Toolset

Because this is a web based project, we are using the LAMP stack (Linux, Apache, MySQL, and PHP). This is a common combination of software used for web development. It is commonly used for the following reasons:

• "Easy to code: Novices can build something and get it up and running very quickly with PHP and MySQL" [1].

• "Easy to deploy: PHP is easy to deploy as files can be edited directly on the server and saved in the document root. By comparison, Java Servlets require that the developer compile the web application into a WAR file and deploy it with a servlet engine such as Apache Tomcat" [1].

• "Cheap and ubiquitous hosting: Many inexpensive web hosts provide packaged services like CGI scripting, PHP coding access and MySQL services" [1].

Frameworks are commonly used to speed up development by minimizing overhead associwith common activities in development. As a result, we are using the Saros Framework (PHP). The Saros Framework (http://sarosoftware.com/products) is built drawing from the best of Zend Framework, CakePHP, and Symphony, but doesn’t have such a long history. This allows it to have important features implemented in a deliberate manner rather than as an afterthought with the evolution of popular technologies. It also better fits the size of the project we are working on. Zend would be the other logical option, but it is bloated and isn’t as well designed as the Saros Framework for the core functionality we will be using. Saros Framework also uses PHP 5.3, which provides more “correct” object oriented programming (OOP) than we would be able to use with ZF (PHP 5.2).

Also, to improve the user-friendliness of our site, we will commonly perform actions on the client-side. Thus, we will be using the JavaScript library jQuery. “jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development” [2]. It has a vast number of plugin libraries to increase development speed, and improve the user experience.

For version control and bug tracking, we will be using GitHub. GitHub “is an extremely fast, efficient, distributed version control system ideal for the collaborative development of software” [3]. If offers a very easy way to manage changes, as well as provides wiki for documentation, if required.

Group Dynamic

The group is essentially going to be split into 3 categories: Profile and Poll Management, Database and Backend Algorithm, and Web Interface (Note: there is some overlap between teams). The Profile and Poll group will be primarily responsible for creating the forms and submitting form data to the database. They will also be responsible for managing logins, and making sure only the poll creator can access his polls and poll solutions. The Database and Backend Algorithm group will be responsible for creating the database schema, managing the databases, and creating the optimal group-match search algorithm. The Web Interface group will be responsible for implementing and extremely friendly user interface, as well as ensuring proper linking between the pages.

Within each group, everyone will share the roles of designers and testers. We chose to each share these roles because everyone was interested in development. This shared role structure allows everyone to participate in the development process, and quickly analyze most of their own issues. Since this product is relatively small in size, this flat structure makes the most sense. If we had teammates that only did testing, they would not be able to work on much until the project had progressed significantly. In other words, much time would be wasted. Also this flat structure is disaster preventative: if a single person drop the class or becomes sick, another person in their group will already have great familiarity with what is being produced and tested. In other words, having someone take over a role (either temporarily or permanently) will be an easy transition because at least one other member will already be familiar with that portion of the product. When black-box testing is required, we will either find users to test out our site, or use people in other groups to perform testing.

In order to ensure that all of the groups communicate well, there is one overlapping member between the Web User Interface group, and the Profile and Poll group, and one overlapping member between the Profile and Poll group and the Database and Backend Algorithm group. These portions will constantly interact with each other, so it is important to have good communication between said groups.

In addition to these categories, Nicholas Castorina will be the Project Manager (PM) of the group

The Profile and Poll group will consist of the following teammates:

• Nicholas Castorina

• Kyle Zemek

• Eli White

These members were chosen to be in the Profile and Poll group due to their experience in web development and form management.

The Database and Backend Algorithm group will consist of the following teammates:

• Hayden Jensen

• Vikram Kudva

• Kyle Zemek

These members were chosen to be in the Database and Backend Algorithm group due to their experience in algorithms and data structures.

The Web User Interface group will consist of the following teammates:

• Justin Ryll

• Nicholas Castorina

These members were chosen to be in the Web User Interface group due to their experience in user interfaces and cross-browser CSS.

Timing and Scheduling

• Setup repository: Since most of the coding will be done in PHP we want to have some form of version control to facilitate work being done in parallel. This will include both a repository system and periodic pushes to the actual server and will be setup by Eli by the end of week 2.
• Setup database schema: We need to maintain information about each user and information about each poll so that the values can be updated and displayed. The actual setup of the schema will be completed by the backend team by the end of week 3.
• Build front end shell frame: All of the pages have at least some common attributes that are not unique to the user. For this reason we need a shell of the site with dummy links in the very least. These shells will be torn down and values will be re injected depending on the user, but basic links and common display will remain. This will be handled by the Web UI group with a first working iteration to be complete by week 4 and a final version by week 8.
• Hook up page injection: Once we have basic shells we will need to hookin injection of actual values. The maintenance and calls to get these values will be provided by the Profile and Poll group team and the Web UI group will actually link in the hookups. Both of these steps should be complete by week 6.
• Make backend algorithm: An algorithm to generate a solution is essential to the project. An initial version will be completed by week two with iterations being provided every two weeks in response to evolution of inputs and performance requirements.
• Hookup account generation and login: Given user information the system needs to verify, store, and authenticate user information. These hook ins will be provided by the Profile and Poll group by week 4 with actual transfer of information and rendering of pages to be completed by the Web group in week 6.
• Hook up poll creation: On request a poll needs to be generated and stored in our system. The front end form will be completed by the Web UI group by week 4 with the backend hookins to be completed by the Poll and Profile group by the end of week 7.
• Hook up poll response: Similarly on request a poll response needs to be generated and stored in our system. The front end form will be completed by the Web Ui group by week 5 with the backend hookins to be completed by the Poll and Profile group by the end of week 7.
• Hook up solution generation: Once a poll is generated the backend algorithm needs to be hooked up with our UI for poll generation. Iterations of the algorithm are provided every two weeks so it will be on the Web UI team to hook up the submission and presentation from page response based in weeks 7 and 8 accordingly.

Risk Summary

The biggest major risk regarding this project is the complexity of the backend algorithm for determining the optimal way to match groups. This requires extensive searching and recursive backtracking. Because of this, we are unsure if we will be able to do the algorithm strictly in PHP. PHP is a scripting language. As a result of it being an interpreted language, it is slow. Thus we may have to write the algorithm in a compilable language.

If PHP is too slow to determine the optimal way to match groups, we need to determine which language we are going to use, and how we are going to connect it to our front end. If this is the case, we will most likely use Java and Apache Tomcat to do the backend algorithm. However, determining how to properly connect this to the front end could be extremely time consuming. This feature is critical to our finished product. Thus if we fall behind due to this, we must readjust the group dynamic to incorporate more people working on the interconnection behind the backend algorithm and the front end.

There is also a major risk in the case that we cannot get a web server from the class that is running PHP 5.3. PHP 5.3 is a requirement for the Saros Framework and is the framework that we are most familiar with. In the case that we don’t have 5.3, we will need to switch to another framework such as the Zend Framework. This will require a significant amount of ramp up time for us and should be avoided if at all possible.

Another risk is if we cannot get remote access to the MySQL database we are using. If we don’t have remote access, our group members cannot work locally and then push a working version to the web. We would need to work live on the server, thus conflicting with each other, and possibly breaking the live version in the process.

The success of this project will be largely based on how user-friendly the interface is to all users, including those with little computer knowledge. Thus, user input would be most valuable directly after the creation of the zero feature release, and immediately after the entire product is developed. Having user input directly after the zero-feature release will allow us to assess whether or not the flow of our website is easily understood by a user. Having user input after the full product (or product with all of the basic features developed as listed above), will allow us to do a very similar assessment for our client-side error checking features. Because this product is intended to be used by nearly anyone with group-matching needs, it should be rather easy to find people to test our product. We could have teachers of project based classes test our product. We could also have peers use our product.