Requirements for Re-Platforming: Difference between revisions

(3 intermediate revisions by the same user not shown)

Line 11:

* 15-20 users on laptops, sometimes working from home, sometimes not connected to the network due to lack of [[wifi]]

* About 2-2.5GB of data altogether as stored in various MS Access DBs (size may vary on other platforms)

* Uses a locally customized and optimized data entry front end with facilitation/automation; using a generic tool would slow down collection and might require additional staffing to do the same work

* Has several highly customized front-ends that facilitate efficient and low-error data entry and processing

** facilitates data entry from a daily dump received from ADT (and other intermittent dumps)

* Data we store is in [[Auto Data Dictionary]]

** it is currently stored in [[CCMDB Data Structure]] - this structure could be stored differently but would cause large changes

** it is currently stored in a relational [[CCMDB Data Structure]] - this structure could be stored differently but would cause large changes

* We have (and continuously improve) [[Data Integrity Checks]]

* Number of fields not necessarily relevant because of [[Entity–attribute–value model of the L Tmp V2 table]]

Line 33:

Line 34:

** Allow modification of multiple records via queries, programming and/or automation (5)

** Needs to work with poor or non-existent [[wifi]] (5)

** Team maintainable real-time [[Data Integrity Checks]] ([[Cross Check Engine]] implementation could provide team maintainability)

=== Data control and possibly transfer ===

* We have a "[[sending]]" process which currently includes both the movement of data from the locally-installed database to the central one, and the setting of the [[RecordStatus]] field that encodes whether the collector maintains "control" of the record or that control has been handed off to [[#Data processing]]; the collector maintains control of "incomplete" records until they "complete" the record, which triggers some mandatory ~~final~~ [[cross check]]s that will prevent completion unless passed.

* We have a "[[sending]]" process which currently includes both the movement of data from the locally-installed database to the central one, and the setting of the [[RecordStatus]] field that encodes whether the collector maintains "control" of the record or that control has been handed off to [[#Data processing]]; the collector maintains control of "incomplete" records until they "complete" the record, which triggers some mandatory [[cross check]]s for both final and [[Minimal Data Set]] data that will prevent completion unless passed.

* A new platform would need to provide this functionality:

** Make incomplete and complete data available to the [[#Data processing]] and [[#Data analysis]] stages(5)

Line 74:

Line 76:

[[Category: Re-platforming]]

[[Category:Re-platforming]]

@@ Line 11: / Line 11: @@
 * 15-20 users on laptops, sometimes working from home, sometimes not connected to the network due to lack of [[wifi]]
 * About 2-2.5GB of data altogether as stored in various MS Access DBs (size may vary on other platforms)
+* Uses a locally customized and optimized data entry front end with facilitation/automation; using a generic tool would slow down collection and might require additional staffing to do the same work
 * Has several highly customized front-ends that facilitate efficient and low-error data entry and processing
 ** facilitates data entry from a daily dump received from ADT (and other intermittent dumps)
 * Data we store is in [[Auto Data Dictionary]]
-** it is currently stored in [[CCMDB Data Structure]] - this structure could be stored differently but would cause large changes
+** it is currently stored in a relational [[CCMDB Data Structure]] - this structure could be stored differently but would cause large changes
 * We have (and continuously improve) [[Data Integrity Checks]]
 * Number of fields not necessarily relevant because of [[Entity–attribute–value model of the L Tmp V2 table]]
@@ Line 33: / Line 34: @@
 ** Allow modification of multiple records via queries, programming and/or automation (5)
 ** Needs to work with poor or non-existent [[wifi]] (5)
+** Team maintainable real-time [[Data Integrity Checks]] ([[Cross Check Engine]] implementation could provide team maintainability)
 === Data control and possibly transfer ===
-* We have a "[[sending]]" process which currently includes both the movement of data from the locally-installed database to the central one, and the setting of the [[RecordStatus]] field that encodes whether the collector maintains "control" of the record or that control has been handed off to [[#Data processing]]; the collector maintains control of "incomplete" records until they "complete" the record, which triggers some mandatory final [[cross check]]s that will prevent completion unless passed.
+* We have a "[[sending]]" process which currently includes both the movement of data from the locally-installed database to the central one, and the setting of the [[RecordStatus]] field that encodes whether the collector maintains "control" of the record or that control has been handed off to [[#Data processing]]; the collector maintains control of "incomplete" records until they "complete" the record, which triggers some mandatory [[cross check]]s for both final and [[Minimal Data Set]] data that will prevent completion unless passed.
 * A new platform would need to provide this functionality:
 ** Make incomplete and complete data available to the [[#Data processing]] and [[#Data analysis]] stages(5)
@@ Line 74: / Line 76: @@
-[[Category: Re-platforming]]
+[[Category:Re-platforming]]