An iterative approach, how Blackboard works in partnership with customers to develop a unique experience for end users. In this session Kim will talk about how Blackboard works with Enterprise Moodle clients to achieve client goals, through custom technical development.

1. Kim Edgar, Blackboard
Technical Development
An iterative approach

2. Welcome
2
Kim Edgar
Open source lead, International Consulting
Moodlerooms Enterprise, Product Manager
• PMP, MBA
• Based in Adelaide
• Managed educational technology projects since
2005
• Manage a Private RTO

3. What is Moodlerooms Enterprise (formerly Enterprise Moodle)
3
Moodle
Customisations
&
Special sauce
Moodlerooms
features
• Universities and large
organisations
• Large user numbers
• Flexible release cycle
• On demand customisations

4. Sharing
4
Client layer
• Client customisation
• Client configuration
ME Base
• ME Customisations
• ME Features
Moodle
Core • Moodle core features

5. Blackboard support
Moodlerooms Enterprise Customer
Application support Consulting
Service Delivery Manager
5

6. 6

7. Moodlerooms Enterprise Environments / releases
Test (UAT)
•Iterative
•Less
controlled
Stage
•Controlled
•Same as
production
Production
•Live
•Highly
controlled
7

8. Workflow
Issue
raised
App support
triage
Assign to
Client Dev
Quoted
Approved
Development
begins
On Test
Client
Testing
Remediation
Client
approval
Stage
Stage
verification
Client
approval
Production
8

9. Issue
raised
App support
triage
Assign to
Client Dev
Quoted
Approved
Developme
nt begins
On Test
Client
Testing
Remediation
Client
approval
Stage
Stage
verification
Client
approval
Production
Workflow
9
Client
conversation
SDM
conversation
Scope
changes
Ideas /
suggestions
Ideas /
suggestions
Scope
changes
Client
conversation Client
conversation
Client
conversation
Ideas /
suggestions
Client
conversation

10. Special Projects
Traditional
• Client provides: Business requirements, use
cases, desired outcomes etc
• Blackboard provides: Initial scope statement,
and initial estimate
• Client signs off
• Blackboard provides: Wire frames, test cases
and detailed scope statement, final estimate
• Client signs off
• Development begins
• Blackboard completes testing and hands back
to client once all test cases are satisfied.
10
Iterative
• Client provides: Business requirements, use
cases, desired outcomes etc
• Blackboard provides: Initial scope statement,
and estimate
• Client signs off
• Development begins
• Blackboard provides client with first version
• Client provides feedback
• Blackboard fixes (there could be several rounds
of fixes and client testing)
• Client signs off

11. Use Case
11
• Challenge / Problem / issue:
• Business need:
• Outcome:
Request raised

12. Ticket triage
12
• Application support team review the ticket
– Decide it is a large development project
– Pass to Client Development team
– Mat picks up the ticket
– Reviews if there is any current functionality that would satisfy the need
– Reviews if there is any work via Moodle HQ tracker
– Provides a high level estimate for the work
Client approval of estimate

13. Development
13
• Development is undertaken on Mat’s local machine
• Then passed to the automated testing tool, once passed
• Queued for Peer review
• Marcus picks up the development and conduct peer review
• Once passed he applies the code to the client environment
Client testing starts

14. Client testing
14
• Running pre-defined test cases testing of the specific
functionality
• Regression testing, to ensure the custom development
hasn’t had an unexpected result on other functionality
Client provides feedback

15. Fixes
15
• Mat, as the original developer, picks up the issues and develops to the
clients requirements
• This could involve straight development of a fix or meetings / calls to
clarify what’s needed
• If the fixes are new functionality, which doesn’t “fit” within the initial
high level estimate a quote is provided
• Further automated testing.
• Marcus Peer reviews
Client re-tests

16. Questions / thoughts / experiences
16