Final Report

Product-related information:

Current status of product:

• The product is at completion. It is ready for beta testing with a larger subset of customers.
• Because some of our compenents have open source-tested components, our product has been adequetly tested for the majority of what it is designed to accomplish. The modules that we added for this senior project we feel are adequetly tested and ready for use.
• If we had more time we would have different payment methods for customers.

Recommended work:

• Known Faults
  • A user can delete his files once his task has been accepted/rejected. The work around currently is that the file is stored on the server, so once he uploads it he cannot completely delete it. However, we wanted to change the permissions for the workflow states. This turned out to take longer than we anticipated.
  • It might be possible for a user to accept a task that he doesn't have permission to look at by directly navigating the the node creation page of the acceptance node. This won't allow the user to create a closes task or one that already has enough people working on it. However they might be able to avoid the taxonomy access control.
• Suggestions for new features
  • We would have liked to incorporate a better structure to identify videos, MP3s and PDFs. Right now it just lists the files as they are grabbed from the database as text identifiers, but a preview button would have been cool.

Advice to teams continuing this project:

We'd definitely recommend reading the book Pro Drupal Development and testing the whole system for several hours before jumping into development first hand. PHP and MySQL are the easy part of Drupal, it is understanding how Drupal uses them together in their framework that has a difficult learning curve, at least for us.

Project team information

Management objectives and prioritories:

Drupal is a modular framework, so we were able to effectively divide the workload into modules that we could later incorporate. We had two people in charge of documentation, Mike and Steve.

Final team structure:

• Who was responsible for which tasks?
  • Mike - Team Lead, SQL programmer
  • Steve - PHP programmer, Documentation
  • Dustin - PHP programmer
  • Matt - PHP programmer
• Did you rotate any of the roles?
  • Yes, we all wrote code and contributed to the documentation throughout the semester.
• Pretend you are just starting the project armed with your current experience. What would your team change about the team structure (if anything)?
  • In our team meetings, we would focus on drupal development mainly. We spent too much time focusing on documentation which was detrimental.
• What advice do you have for teams wanting to use the same structure?
  • We found that online meetings were not as effective as actual meetings.
• The team leader should evaluate the team members' fulfillment of roles, particiapation and contribution.
  • Everyone fulfilled their assigned roles. Steve wrote several modules for Paypal which were a great feature for our project. Matt was great in working with the expire node and Taxonomy access controls. Dustin wrote the task accept structure which is what our project hinges on in a nut shell. Mike wrote the userbalance tables and modules that kept track of how much TAA owed a user.

Schedule and planning:

• Which aspects of your team's scheduling and planning procedures worked well?
  • Standardized meetings were helpful. Our pair programming meetings were helpful as well.
• Which problems did your team have with scheduling and planning?
  • We could only meet all together a couple time a week. This made it difficult to have regular meetings.
• What tools did your team use to assist you in planning and tracking the project?
  • We used Mike's laptop and remote desktop/FTP to keep track of code.
• How could your team have improved its scheduling and planning?
  • We could have been more productive in our meetings, focusing on documentation.

Support functions:

• Effectiveness of our Quality Assurance and Configuration Management functions.
  • We had several meetings where we would go over each other's code. This was very effective.
• Defect tracking
  • Drupal is a well tested open source framework that was good at letting us know when our modules were not compatible with Drupal's system. Our procedure for testing was mainly enabling our module, then seeing if Drupal would load. If not, we would examine the console error line and then our code. We also would thoroughly test use cases. We faithfully followed these procedures.
• Lessons Learned
  • We would have started on pair programming meetings from the beginning. All of us were new to the project, so it would have been much better if we had learned this together.

Work with the clients:

• How did your team's relationship with the client work out?
  • It worked out well. We kept constant communication with them throughout the semester.
• What would you go back and change about this relationship to make it more effective?
  • We would have not met every week, but once a month would have been sufficient. We would have requested better Drupal books for programming as well.
• What could the instructor have done to make the client-team contact more effective?
  • The instructor could have been more proactive with the communication about the needs of our group.

Work with project mentors:

• Discuss your team's experiences with the project mentor arrangement.
  • We met every week with TAA to discuss the project.
• What advice does your team have for how this program can be made more useful from the point of view of the student teams?
  • We feel that it would have been more useful to meet and document less and code more.
• Which aspects should remain unchanged?
  • We liked the consistency of weekly meetings with our team where we would pair program and solve problems.

Other issues:

• N/A

Feedback from the mentors

• Ask the mentors for their observations about the team's accomplishments,the mentoring process, or other aspects of this semester's mentoring interactions.
  • After giving our final acceptance test with TAA and Professor Henderson, TAA indicated that they were pleased with our final product. They also mentioned how that before spring break, we did not seem to have any concrete product yet (due to the learning curve of drupal and planning). However, the last two months we took the ideas that had been on the drawing board and put them to use.

Advice to future teams as they start out

Three general pieces of advice to future teams as they start out

• If you start with Drupal, be sure to send a lot of time studying how hooks work.
• Don't meet as frequently with the sponsoring company.
• Pair programming meetings can be incredibly effective.