Module 08 Quiz: DHGS Case Study - PDM Academy

Checking your access…

Sign in to take the quiz

PDM Academy is open access with no payment required, but you need to be signed in so we can save your score. Sign-in takes one click from your inbox.

Sign in to continue

⚠

Complete all lessons first

You need to finish every lesson in this module before taking the quiz. Go back to the dashboard to see which lessons are still outstanding.

Back to your course

Fourteen questions: five on the DHGS scenario you have followed, then a nine-part Gap Analysis & Mapping exercise - mapping the legacy Kelsey Pit equipment data onto the new Equipment DB, field by field. Refer back to the foldouts in Lessons 03.03 and 03.04 if you need to. Retake it as often as you like - your best score is saved.

1What kind of organisation is DHGS?

A regional gravel and infill-products company A national retail bank A healthcare provider A software vendor

2Roughly how many disconnected legacy systems does DHGS need to migrate?

Around ten Exactly two More than fifty Just one

3In the SI assessment, which proposal did the analysis recommend, and how?

HAL, conditionally Logia, unconditionally Neither proposal Both, equally

4The undeclared Kelsey Pit equipment spreadsheet was owned by:

Whit Bissell, the production manager the Finance Manager the Systems Integrator nobody in particular

5What finally forces DHGS's disconnected data together onto one platform?

The move to Activity-Based Costing A regulator's order A cyber-security incident A company merger

6GAM exercise - in the target Equipment DB, Equipment ID is a primary key the application generates on load. What is the correct mapping decision?

No legacy mapping is required - it is system-generated (but a parent's ID must be preserved to load onto its child records) Map it directly from the Kelsey Pit Equipment Shortname Raise a DQR, because every target field must have a legacy source Leave it null and let the business fill it in after go-live

7GAM exercise - Kelsey Pit stores a Description up to 200 characters; the target Description is 100 characters and technically optional. Why can't it simply be truncated or dropped?

Business rules (the System Retirement Plan) make it effectively mandatory - a length clash raises a DQR for the Business Domain Experts The target validation rejects any record with a short description Truncating text always breaks data lineage Optional fields must still be fully populated to load

8GAM exercise - one Kelsey Pit equipment type (e.g. 'Pump') legitimately maps to several different target Equipment Types. This is a ___ mapping, and it is hard because:

one-to-many - a rule plus Business Domain and Technical experts are needed to decide which record goes to which target type one-to-one - it is a simple direct copy many-to-one - several values collapse into one, which is easy once agreed a null mapping - there is no usable source

9GAM exercise - several Kelsey Pit statuses ('In Use', 'Pumping', 'Working') all map to the single target status 'Productive'. What kind of mapping is this?

Many-to-one - straightforward once there is an agreed cross-reference list One-to-many - the hardest kind to manage Many-to-many - prone to the One Way Street problem A null mapping - no agreement is possible

10GAM exercise - Equipment Location maps many-to-many between Kelsey Pit and the target. In GAM terms, many-to-many mappings are most associated with:

The One Way Street problem - the hardest to manage; migration software with built-in data lineage is especially valuable here Exclusion rules - the records are simply dropped A one-to-one fallback No DQR being required

11GAM exercise - the target 'Owner' field is mandatory, but the Kelsey Pit application has no matching field. What is the best PDM response?

Search the Legacy Data Store list for another source held outside the main system, and confirm it with the Business Domain Experts Leave Owner null, because Kelsey Pit has no equivalent Exclude every equipment record that has no owner Invent a placeholder owner code with no business meaning

12GAM exercise - the target 'Operator' field is not mandatory and there is genuinely no legacy data for it. The correct mapping is:

Leave it null - a null value is a valid mapping when the field is optional and no source data exists Raise a DQR and hold the migration until data is found Copy the Owner value into it as a default Exclude the record from migration

13GAM exercise - 'Input By' is mandatory in the target, but no Kelsey Pit field and no other store records who entered the data. The PDM approach is to:

Raise a DQR and agree a default value (e.g. 'Migrated Data') with the Business Domain Experts and the target Technical System Experts Leave it null and accept the load will fail Use the migration analyst's own user ID Exclude every record, since the field cannot be sourced

14GAM exercise - only about 3% of Kelsey Pit cost centres fail to map to a valid target Account Code. How does PDM handle this fallout?

An exclusion rule lets them fall out, then a Transitional Business Process fixes them in the target after load - recorded in the Detailed Cutover Plan Force all 3% to a single default account code Delay the whole migration until 100% map cleanly Drop the Account Code field from scope entirely