What are TSC's daily drivers doing? How would they know where to look in TSC?
TSC, being built with a combined data and business process model, introduces several paradigm shifts, hence it looks and feels entirely different to the legacy databases. TSC uses technology that's 20 years newer than the legacy databases. On the other hand, TSC also has not had yet every conceivable UX nice-to-have feature implemented yet.
Feature
Documentation
Daily tasks should ideally be captured in detailed requirements.
For each daily task:
write "how to do X" documentation
ensure the "golden path" and expected edge cases are covered by well-documented tests (test functions have docstrings)
auto-generate detailed documentation from test documentation
close off requirement and corresponding GH issue
Training
SCB and Regions have to be introduced once properly to TSC and the paradigm changes. Their data provision into TSC, as well as their reporting out of TSC will have to upgraded and supported.
Support
Ongoing support has to be provided to users:
how do I do X? -> Documentation
bug -> software engineering task
new report, new data source -> data engineering task
new linkage to other DBCA systems -> sw/d engineering task, plus devops
Problem
What are TSC's daily drivers doing? How would they know where to look in TSC? TSC, being built with a combined data and business process model, introduces several paradigm shifts, hence it looks and feels entirely different to the legacy databases. TSC uses technology that's 20 years newer than the legacy databases. On the other hand, TSC also has not had yet every conceivable UX nice-to-have feature implemented yet.
Feature
Documentation
Daily tasks should ideally be captured in detailed requirements. For each daily task:
Training
SCB and Regions have to be introduced once properly to TSC and the paradigm changes. Their data provision into TSC, as well as their reporting out of TSC will have to upgraded and supported.
Support
Ongoing support has to be provided to users: