We are a small startup organization that provides training for technical environments.  We are experts in our respective technical fields and are looking to utilize Moodle as a platform for some of our training.  Moodle lacks some of the features needed to make this possible although it takes us 95% of the way there.

 

General Requirements

·        Developer is the person or persons authoring the software.

·        Client is the entity requesting and paying for the software.

·        Customer refers to any entity having a business obligation to the Client.  The developer shall have no relationship with customers.

·        Developer must not work for a competitor or release any intellectual property, methods, or other business information to any potential competitors.  Developer will be asked to sign a non-disclosure agreement (NDA).  Any breach of the NDA will constitute liquidated damages.

·        Support.  Developer will provide Client a Moodle plugin compatible with current Moodle major version (e.g. Moodle 3.x).  Developer will provide plugin development support to assure compatibility with the major version of Moodle available at the time plugin is completed for as long as that Moodle version is used by Customer.  For example, if the plugin is completed with Moodle 3.1, being the most current release, then the developer must assure continued support to assure compatibility with Moodle 3.x for as long as Customer uses that major version of Moodle.  Support is not required with the next major version of Moodle (e.g. 4.x) is installed and deployed by Customer.  Note: Client may continue to use Moodle 3.x even though Moodle 4.x is available. In this case, developer must still support compatibility with client installed Moodle 3.x.

·        Plugin source code, pseudocode, and documentation are the intellectual property of Client.  Copyright shall be granted entirely to Client.

·        Source code must include comments to allow another developer to understand code.  Client may request Developer to provide additional documentation for any complex code.

·        Proprietary libraries may not be used unless that library is granted full Copyright to Client or subsequent developers.

o   Open source libraries may be used provided the open source library is compatible with commercial intellectual property licensing.  The source code of the plugin will never be released to a third party.

·        The plugin must be designed to work on shared hosting environments where significant server customization cannot be granted.  Documentation must be provided explaining configuration of the plugin within the existing production environment. 

·        Data may be stored in the same relational database as the Moodle installation.  The relational database schema must be documented to allow another developer to understand the intention and use of each database table, field, and relation.  Data must not be stored in the same database as core Moodle database entries.

·        Developer must be fluent in spoken and written English.

·        Mission critical system.  Developer must be able to respond to Client within 12 hrs of being contacted to resolve any emergency situations that may arise.  It is the responsibility of the developer to remain sufficiently accessible to be notified of an issue either by email, text message, or telephone call.  The 12 hour contact requirement begins when the Client initiates contact by the last of any 2 methods.  For example, if the Client attempts to contact the developer by text message at 0500 CST on 12 March, then at 0600 CST on 12 March, then the developer must be available to communicate extensively with Client no later than 1800 CST on 12 March.  Extensive communication is defined as being available to conduct a land-line telephone call, cell phone based call, VOIP call, or other equivalent system that provides reliable contact of at least 60 minutes by voice and can simultaneously involve screen sharing/remote access software (TeamViewer). 

·        Testing.  Developer must create a testing methodology to assure intended operation.  Methodology and results must be demonstrated to Customer.  Customer will conduct Acceptance Testing after reviewing Developer’s test results.  Software must be tested by developer by creating a representative number of test use cases.

·        Payment.  Payment will be issued in full once module is tested and accepted by Client.  Client must assess proper functionality of plugin before payment is rendered.  Payment does not constitute the end of support obligations to Client (see Support paragraph). 

·        Functions requested.

o   Overview.  Plugin will mostly utilize existing Moodle platform.  It’s purpose is to oversee the training progress of various users grouped by companies and then by series of assigned courses.  The plugin will automatically enroll students into courses based on tracked eligibility windows.  The Moodle Administrator will define the various pipelines and intervals.  Students, Training Managers, and the Administrator shall be given friendly reminders of upcoming scheduled training or consequences of delinquency or failure.

o   Plugin will extend the Moodle concept of Courses to create different “pipelines”.  Plugin will utilize existing Moodle features (Courses, Certificates, Activities, etc.) to create a higher level system of various courses put together to create “pipelines”.  A pipeline consists of various courses (administrator defined) in which a student is enrolled based on timed intervals.  For example, a new student will be created and is enrolled into “initial training”.  1 year later, that same student is automatically enrolled into “recurrent training”. 

§  Moodle Admin will be able to create various pipelines.  An interface will be provided allowing the Moodle Admin to arrange various courses in series to create a specific pipeline separated by time intervals.  For example, a pipeline named “regular student” consists of a course named “initial training” followed 1 year later by “recurrent training”, then every year after that “recurrent training” until the student is disenrolled.  The plugin will monitor course completion to assure proper sequencing and time limit enforcement.

§  Administrator will be able to specify which courses make up a pipeline.

§  Courses within a pipeline must have customizable intervals expressed in units of years, months, or days.

§  Intervals will have early and late windows.  Students must complete the assigned course within the early/late window or the student is placed in a special status.

o   Plugin will (overall) manage training lifecycles for various Students corresponding to various Customers (different companies).  Plugin will create new Moodle users which correspond to a specific company and can be enrolled in Administrator defined training pipelines.  After user is created, plugin will manage the lifecycle of a student matriculated in a pipeline. 

o   Student view.  Student will be able to see their progress in the current assigned course (existing Moodle capability) and within their pipeline.  Student will be able to see what they upcoming eligibility window is for their next training.  Student will be presented an overview of the entire training pipeline assigned to him.  Student will be allowed to audit past taken courses without changing their grade.  Grades will only be changed during their early/late timeframe windows.

o   Training Manager view.  If logged into Moodle as a company’s Training Manager, the TM shall be able to view the progress of all assigned company students.  There will be multiple TMs;  one TM shall exist for each company.  Any number of company training shall be hosted on one Moodle installation/sever.  Training manager shall be provided the ability to retrieve all historical events related to student progress (enrollment events, completion events, delinquency events, unenrollment events, etc.)

o   Administrator view.  The Moodle Administrator will have complete control over all plugin functions, user assignments, status override of any student, define pipelines, and to be able to enroll/unenroll students.

o   All views shall be print-friendly or offer an export feature suitable for printing or archiving. 

o   Notifications.  The software will have a sufficiently robust mechanism to allow for event based email messaging of events (e.g. emailing TM when a user finishes training, emailing student/admin/TM if a student fails to accomplish assigned course within specified timeline, etc.).  Administrator should be able to customize email messages by editing an HTML “include” file or similar rich text based interface (possibly available via browser).  It should offer variables that can be used throughout the “include” file such as student name, various dates, course names, upcoming course names, and so on.

If you are interested, please contact me at support at the domain trainingng.com.  I would be glad to discuss the details or answer any questions.