Software developers seeking to engage with the SBR program to implement one or more of the forms in scope may consider reviewing the documentation on this site and contacting SBR.
The checklist below is intended to guide software developers through the steps from initial engagement through to delivery of an SBR compliant product to the marketplace. These steps are illustrative only, as each software developer should adopt their own variations to suit their specific needs. The SBR program aims to provide tools or services to facilitate each step.
|1.||Assess||Product management||Gain a high level understanding of the SBR program and it's scope with a view to assessing the value that SBR can provide to your customer base.||http://www.sbr.gov.au|
|2.||Decision point||Executive||Proceed to business case development|
|3.||Register||Product management||Register with the SBR program as a software developer to receive further information, and support services||Complete the entity registration process and email to SBRservicedesk@SBR.gov.au|
|4.||Understand the work required to have your software support SBR||Product management and business management/strategy||Covered in the above table|
|5.||Define form scope||Product management||Review the SBR forms in scope and select which ones you will support in your product. Use the Message Implementation Guides (MIGs) to gain a good understanding of how to implement each form.||SBR Forms in scope MIG Index|
|6.||Solution Blueprint||Product management and lead developer||
Prepare a high level solution blueprint for implementing SBR within your product.
Define key features and identify which government SDK components can be re‑used:
The SBR SDK Guide will advise you how to access
The SBR taxonomy will provide you with
You will need to develop the mapping and rendering capability.
|7.||Implementation Plan||Product management||Build an implementation plan and schedule with approximate costs. Include capacity building, design, build, and test of solution components, transformation & mapping for selected forms. Use the SBR master schedule to determine when you will implement support for specific forms.||
SBR Software developer sample implementation plan.
SBR program master schedule.
|8.||Business Case||Product management||Develop a business case for implementation of SBR services within your product. Prioritise forms to be implemented.||SBR Software developer business case template.|
|9.||Decision Point||Executive||Proceed to detailed design & prototype|
|10.||Capacity Building||Architect and developers||Develop the capacity within your organisation - or via outsourced providers in XBRL, the SBR taxonomy and how to leverage it, and other SBR technical services.||SBR Training curriculum. SBR Knowledgebase and forum.|
|11.||Prototype||developers and Product Manager||Develop a prototype implementation to test mapping and lodgement of one form - typically one for which your product can already create a printed version.||SBR SDK, documentation, knowledgebase and support services|
|12.||Design||Lead developer and Product Manager||Develop a detailed design for commercial implementation of the SBR solution within your product suite||Reference client implementation|
|13.||Decision Point||Executive||Proceed to implementation|
|14.||Solution Build||Architect / developer||Build production quality solution.||SDK and support services.|
|15.||Mapping||Developer / business analyst||Develop transformation and mappings necessary to create valid XBRL report instances. Effort depends on complexity of form and level of alignment between the taxonomy and your product data store.||Message Implementation Guides, SBR AU Taxonomy.|
|16.||Rendering / User interface||Developer / business analyst||Develop report presentations (to allow user to review / edit before lodgement). The level of effort depends on complexity of form and extent to which you leverage government provided templates.||Form presentation templates|
|17.||Test||Product management & QA||Test solution against SBR test services||SBR testing. Self assessment & compliance program.|
|18.||Document||Product management, tech writer||Prepare administrator and user documentation.|
|19.||Operations||Product management, support staff||Define and implement operational support process. Typically this will include a server based mechanism to automate distribution of taxonomy updates to your customers - alongside other product updates.||SBR taxonomy architecture and version / release strategy. SBR knowledge repository & Taxonomy server.|
|20.||Decision Point||Executive||Release to market|
|21.||Release||Product management||Market the "SBR compliant" version of your product and release to your customers.||SBR marketing support|
On-going support including:
|SBR customer support|
Last updated: 27 Apr 2016
Page ID: 14050