Polus Solutions

Polus Solutions is an independent contractor who handles software development tasks for the Research Admin System and related projects. Their role is generally to create bugfixes and customizations for Kuali Coeus as well as the Award Budget Tool (which they originally developed in conjunction with MIT).

Contacts

• Sabari Nair - sabari@polussolutions.com
  • Managing partner at Polus
  • Coordinates high-level tasks for Tufts, occasionally assists with production support
    
    
• Krishna Prasad (KP) - rkprasad@polussoftware.com 
  • Lead developer for Polus's software team that handles Tufts bugfixes/customizations
  • Main point of contact for development tasks and issues
    
    
• Anu Johnson - anu@polussolutions.com
  • QA Tester for Tufts/RAS tasks
  • OVPR (Angela/Philippa) usually coordinate with her for QA plans

Tasks

Polus is equipped to handle a subset of RAS-related development and support tasks. Tickets that we've previously assigned to them can be found by looking at the 'Polus' label in the RAS JIRA. 

Tasks typically performed by Polus include:

• Bugfixes and customizations for Kuali Coeus (PD, IP, and Award modules)
• Fixes or enhancements for the Award Budget Tool

Tasks which Polus does not typically handle:

• Production support of any kind (they only have access to our dev/test environments)
• Integration of new vendor updates for Kuali Coeus
• Deployment of code to Tufts environments (they check in code to our Git repositories, and we build/test/deploy the code from there)
• Configuration or setup that is Tufts-specific (department config, route paths, etc)
• Integration with other Tufts systems (Data Warehouse, LDAP, HR, PeopleSoft Financials)

Process

The process of Polus's work is usually as follows:

1. Tufts developers/BAs create JIRA tickets which detail the requirements for the requirements for the desired changes. The more specific the better, and screenshots or mockups are often helpful.
2. The JIRA tickets are assigned to the 'DEV2' user in JIRA, and the ticket numbers are sent to KP (contact info above).
3. KP and the Polus team will analyze the tickets, request any clarifications necessary, and provide a estimate for the required development hours along with an estimated delivery date.
4. The Tufts team confirms that the estimates are good an authorizes work to begin.
5. When work is complete, Polus will push the changes to the Tufts git repositories as new branches.
6. The Tufts developer compiles the changes and deploys them to the dev environment for basic testing.
   1. If code does not compile or the change does not appear to be correct at a basic level, the ticket is returned to KP with clarifications.
7. When the change appears to be working, the Tufts developer merges the changes and deploys them to the dev/test environments.
8. The Tufts BAs test the changes.
   1. If further work is required, the Tufts developer returns the relevant tickets to KP with clarifications.
9. When testing passes, the JIRA is marked as resolved and the changes are ready to be deployed to production as part of the next RAS upgrade.

Sabari submits invoices for Polus's work every few months. These invoices are reviewed against the tickets assigned to Polus (i.e. does the work billed generally match what was assigned and the estimates they provided) and then submiteed to TSS for processing.