diff --git a/documents/plant/Reactor/I&C Systems/Plant Control System/index.yaml b/documents/plant/Reactor/I&C Systems/Plant Control System/index.yaml index 8ae5f93..aa79c14 100644 --- a/documents/plant/Reactor/I&C Systems/Plant Control System/index.yaml +++ b/documents/plant/Reactor/I&C Systems/Plant Control System/index.yaml @@ -1,5 +1,5 @@ -- name: Reactor plant control system - params: - - name: Quantity - val: 1 - tags: INTERFACE +name: Reactor plant control system +params: + - name: Quantity + val: 1 + tags: INTERFACE diff --git a/documents/procedures/administration/document_management.rst b/documents/procedures/administration/document_management.rst deleted file mode 100644 index 89d993c..0000000 --- a/documents/procedures/administration/document_management.rst +++ /dev/null @@ -1,101 +0,0 @@ -Records and Document Management Procedure ------------------------------------------ - -This procedure governs the creation, maintenance, and retention of -:term:`Records ` and :term:`Documents `. - -.. impl:: Define processes for lifetime records - :links: R_GDC_01_04 - -.. impl:: Define processes for Document Control - :links: R_APPB_45 - -.. impl:: Define processes for Quality Records - :links: R_APPB_79 - - -.. _rmdc-systems: - -Systems -^^^^^^^ - -Documents and records are managed in the following systems. - -.. datatemplate:yaml:: - :source: /_data/it-systems.yaml - - {{ make_list_table_from_mappings( - [('Name', 'name'), ('Use case(s)', 'use-cases'), ('Location', 'location')], - data['rmdc-systems'], - title='RMDC Systems', - ) }} - -.. _rmdc-origination: - -Origination -^^^^^^^^^^^ -New records and new or revised documents are originated as invoked by other procedures -and processes. The following steps shall be taken at such times: - -* **Originator** shall specify key data defining the new record/document, including: - * Required: - * Title --- a single-line description of what the record/document is - * Record/document type --- This determines template, review, and - retention rules. Should be from :ref:`rmdc-doctypes` - * Originating organization --- the organization or group assigned primary authorship. - Internally-generated records/documents shall be contained on the :ref:`org-chart`, while - others should be the name and department of external entities. - * Optional - * Keywords --- words or phrases to assist in future searches/lookups - - -.. impl:: Require document index to be updated upon origination - of any new document or record - :links: R_APPB_83 - - Updating the index at the point of creation is a robust - way to ensure compliance that each document/record will always - be discoverable and retrievable. - -.. _rmdc-doctypes: - -Record/Document Types -^^^^^^^^^^^^^^^^^^^^^ -One of the following record/document types should be assigned to each -record/document. The types are generally associated with specific forms or -templates that include the expected content/sections, and are often created to -satisfy the needs of a lower-level procedure. - -.. impl:: Define numerous Record/Document types - - There is a timeless debate about having too many vs. too few doc types. - Additional types are added to support more mature procedure sets, but then - people start to struggle to know what type they should use, leading to - cleanup efforts, followed by management declarations to reduce the number of - types. - - A good solution to this problem is to be very explicit in your procedural - culture. Ensure that whenever a record or document is being originated, that - each staff member has the relevant procedure open and is following it - precisely. Ensure that the procedures are rigorous and precise about which - record/document types should be generated in each scenario. When a procedure - is written, ensure that any new record/document types are added to the list - of known types. - - .. warning:: Don't make one rec/doc type for each individual checklist or form - in each procedure though. Those can all be forms. Or maybe do make them - all form subtypes? Could be nice to really have specific evidence. - Need easy way to make auto-generated forms per procedure then. - -.. datatemplate:yaml:: - :source: doc-types.yaml - - {{ make_list_table_from_mappings( - [('Type', 'name'), ('Abbrev', 'abbrev'), ('Use case(s)', 'use-cases'), - ('Record', 'record'), ('Retention', 'retention')], - data, - title='Record/Document types', - ) }} - -See Also -^^^^^^^^ diff --git a/documents/procedures/administration/index.rst b/documents/procedures/administration/index.rst index 89ad3d2..43d42df 100644 --- a/documents/procedures/administration/index.rst +++ b/documents/procedures/administration/index.rst @@ -7,4 +7,5 @@ and the management of procedures themselves. .. toctree:: :glob: + information_management/index * \ No newline at end of file diff --git a/documents/procedures/administration/information_management/document_management.rst b/documents/procedures/administration/information_management/document_management.rst new file mode 100644 index 0000000..eee7106 --- /dev/null +++ b/documents/procedures/administration/information_management/document_management.rst @@ -0,0 +1,296 @@ +.. _rmdc-proc: + +Records and Document Management Procedure +========================================= +This procedure governs the creation, intake, maintenance, authorization, +distribution, and retention of :term:`Records ` and :term:`Documents +`. + +Purpose +------- +Systematic management of Records and Documents helps teams execute +large, long-term, and complex projects in a coordinated fashion. +Furthermore, management of quality-related documents is required by +regulations. This procedure implements the following requirements: + +.. impl:: Define processes for lifetime records + :links: R_GDC_01_04 + +.. impl:: Define processes for Document Control + :links: R_APPB_45 + +.. impl:: Define processes for Quality Records + :links: R_APPB_79 + +Roles +----- +Roles involved in this procedure include: + +Originator + Person who authors a new or revised document + +Reviewer + Person who is assigned to review a submitted document, checking for quality + and content + +Approver + Person in the releasing organization who is authorized to mark a document as + Approved, thereby enabling its use across the project. + +Manager + Person in any organization who is authorized to request document reservations + +RMDC Staff + Person responsible for receiving documents and administering :term:`RMDC` IT + systems such as the :term:`EDMS` + +Staff + Person in any organization who is authorized to access or submit project + documents/records + +Procedure +--------- + +.. _rmdc-access: + +Accessing a document/record +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Internal project staff shall follow these steps when seeking documents or records +to perform project work. + +* **Staff** navigates to the project :term:`EDMS` as defined in :ref:`rmdc-systems` +* **Staff** searches EDMS for desired document/record by number, title, and/or other fields +* **Staff** checks ``status`` field and ensures they choose a revision that is + approved for their current work task (generally this requires an APPROVED status). +* **Staff** checks the ``usage`` field and ensures to choose a revision with a + usage marking that is appropriate for their current work task. +* **Staff** accesses the file(s) via the EDMS download or access feature +* If an expected Document/Record cannot be found, appears to have erroneous data, or + is not accessible, **Staff** contacts **RMDC Staff** for assistance + + +.. _rmdc-origination: + +Originating a new document/record +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +New records and new or revised documents are originated as invoked by other procedures +and processes, or by third parties. The following steps shall be taken whenever a new +document or record or document reservation is requested, created, or received: + +* **Staff** shall specify document data defining the new record/document in + accordance with the content rules listed in :py:class:`nrsk.models.Document` + + * Required: + + * Title --- a single-line description of what the record/document is + * Record/document type --- This determines template, review, and + retention rules. Should be from :ref:`rmdc-doctypes` + * Originating organization --- the organization or group assigned primary authorship. + Internally-generated records/documents shall be contained on the :ref:`org-chart`, while + others should be the name and department of external entities. + + * Optional + + * Keywords --- words or phrases to assist in future searches/lookups + + +.. impl:: Require document index to be updated upon origination + of any new document or record + :links: R_APPB_83 + + Updating the index at the point of creation is a robust + way to ensure compliance that each document/record will always + be discoverable and retrievable. + + +Intake +^^^^^^ +Upon receipt of Document/Records from an external party, the following process shall occur: + +* **Receiver** determines whether the Document/Record is eligible for + entry into the Document Index. +* **Receiver** inspects Document Index to ensure consistency with the Index and the + received Document + + * If the received document/record is not already listed in the Document Index, then + **Receiver** takes on the role of **Originator** and follows the process in + :ref:`rmdc-origination`. + * If the data is incorrect or outdated, **Receiver** updates the data + +* **Receiver** uploads the received file(s) to the EDMS. +* **Receiver** updates metadata in the Document Index, including the latest + revision number, authors, received date, and location/URL in the EDMS +* **Receiver** assigns acceptance review task to appropriate person based on + the work breakdown structure that the document was produced under. +* **Reviewer** views Document Index and downloads file(s) as listed +* **Reviewer** inspects files and performs acceptance review as appropriate, potentially + generating a Review Record +* **Reviewer** updates Document Index acceptance metadata field according to review +* If the document/records are not accepted, **Reviewer** informs originating + institution of deficiencies and requests update + +Document/Record data management +------------------------------- + +.. _rmdc-doctypes: + +Record/Document Types +^^^^^^^^^^^^^^^^^^^^^ +One of the following record/document types should be assigned to each +record/document. The types are generally associated with specific forms or +templates that include the expected content/sections, and are often created to +satisfy the needs of a lower-level procedure. + +.. impl:: Define numerous Record/Document types + + There is a timeless debate about having too many vs. too few doc types. + Additional types are added to support more mature procedure sets, but then + people start to struggle to know what type they should use, leading to + cleanup efforts, followed by management declarations to reduce the number of + types. + + A good solution to this problem is to be very explicit in your procedural + culture. Ensure that whenever a record or document is being originated, that + each staff member has the relevant procedure open and is following it + precisely. Ensure that the procedures are rigorous and precise about which + record/document types should be generated in each scenario. When a procedure + is written, ensure that any new record/document types are added to the list + of known types. + + .. warning:: Don't make one rec/doc type for each individual checklist or form + in each procedure though. Those can all be forms. Or maybe do make them + all form subtypes? Could be nice to really have specific evidence. + Need easy way to make auto-generated forms per procedure then. + +.. datatemplate:yaml:: + :source: /_data/doc-types.yaml + + {{ make_list_table_from_mappings( + [('Type', 'name'), ('Abbrev', 'abbrev'), ('Use case(s)', 'use_cases'), + ('Record', 'record'), ('Retention', 'retention')], + data, + title='Record/Document types', + ) }} + + +Document Numbering +^^^^^^^^^^^^^^^^^^ + +Document numbers (or IDs) are human-usable codes that uniquely identify +the document/record for purposes of cross-referencing and discussion. + +All projects may use |inst| corporate-level document numbering as appropriate +in addition to the project-specific policies. Corporate number shall + +For corporate-level documents/records not associated with any specific project +or system, the document numbers shall be of the form: ``AMS-{type}-00000``, +where {type} is the document type abbreviation in all CAPS, and the number +starts at 00001 and increments from there. When 100,000 or more numbers are +needed, the number continues increasing. + +For project-level documents/records not associated with any specific system, +numbers shall be of the same form, but with ``{AMS}}`` replaced with the +project abbreviation, e.g. ``TTP``. + +Documents/records associated with a specific project and system shall have document +numbers of the form: + +``{proj}-{sys}-{type}-00000`` + +where `{sys}` is the system abbreviation in all CAPS. + +Active projects and their abbreviations may be found in :ref:`projects`. + + +.. _rmdc-doc-status: + +Document Statuses +^^^^^^^^^^^^^^^^^ +Document Status indicates where a document or record is in its lifecycle, and +determines if and how it may be used in design or operation. Statuses fall into +three top-level categories. These statuses are derived from +:cite:p:`cloverDocumentControlRecords2010`. + +.. autoclass:: nrsk.models.Document.STATUS + :no-index: + :no-members: + + * **Not Yet Approved** --- The following statuses apply to Documents that + generally shall not be used to support plant design or operations: + + .. autoattribute:: nrsk.models.Document.STATUS.RESERVED + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.IN_PROGRESS + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.IN_REVIEW + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.REJECTED + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.REFERENCE + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.NATIVE + :no-index: + :no-value: + + * **Approved** --- The following statuses apply to active documents that allow + plant design or operations: + + .. autoattribute:: nrsk.models.Document.STATUS.APPROVED + :no-index: + :no-value: + + * **No Longer Approved** --- The following statuses apply to documents + that are no longer approved for use other than reference: + + .. autoattribute:: nrsk.models.Document.STATUS.QUARANTINED + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.SUPERSEDED + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.REVISED + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.VOIDED + :no-index: + :no-value: + + .. autoattribute:: nrsk.models.Document.STATUS.CLOSED + :no-index: + :no-value: + +.. note:: These statuses are validated in the data dictionary + in :py:class:`~nrsk.models.Document` + +.. _rmdc-systems: + +Document/Record Management Systems +---------------------------------- + +Documents and records are managed in the following systems. + +.. datatemplate:yaml:: + :source: /_data/it-systems.yaml + + {{ make_list_table_from_mappings( + [('Name', 'name'), ('Use case(s)', 'use_cases'), ('Location', 'location')], + data['RMDC'], + title='RMDC Systems', + ) }} + + +See Also +-------- diff --git a/documents/procedures/administration/information_management/index.rst b/documents/procedures/administration/information_management/index.rst new file mode 100644 index 0000000..96f9997 --- /dev/null +++ b/documents/procedures/administration/information_management/index.rst @@ -0,0 +1,9 @@ +********************************* +Information Management Procedures +********************************* + +.. toctree:: + + information_management_plan + document_management + \ No newline at end of file diff --git a/documents/procedures/administration/information_management.rst b/documents/procedures/administration/information_management/information_management_plan.rst similarity index 99% rename from documents/procedures/administration/information_management.rst rename to documents/procedures/administration/information_management/information_management_plan.rst index df29c57..5115672 100644 --- a/documents/procedures/administration/information_management.rst +++ b/documents/procedures/administration/information_management/information_management_plan.rst @@ -1,4 +1,3 @@ - Information Management Plan =========================== diff --git a/src/nrsk/schedule/load_schedule.py b/src/nrsk/schedule/load_schedule.py index 16c7d19..0ccab88 100644 --- a/src/nrsk/schedule/load_schedule.py +++ b/src/nrsk/schedule/load_schedule.py @@ -59,9 +59,17 @@ def create_task(parent, name, duration): """Make a planned task.""" task = parent.addTask() task.setName(name) - task.setDuration(duration) - task.setActualDuration(Duration.getInstance(0, duration.getUnits())) - task.setRemainingDuration(duration) + if duration: + # apply duration in way that makes schedule solver solve for it + + # Some tasks may not have durations but then will require appropriate + # predecessor links to become scheduled + # but then they'll need a work resource or else you'll get error: + # >>> Task has no duration value and no resource assignments with a work + # value: [Task id=35 uniqueID=35 name=Pre-licensing activities] + task.setDuration(duration) + task.setActualDuration(Duration.getInstance(0, duration.getUnits())) + task.setRemainingDuration(duration) return task @@ -90,11 +98,12 @@ def load_from_yaml(fname: str = "schedule.yaml") -> ProjectFile: summary, task_d.name, Duration.getInstance(0, TimeUnit.DAYS) ) else: - task = create_task( - summary, - task_d.name, - Duration.getInstance(task_d.duration.days, TimeUnit.DAYS), + duration = ( + Duration.getInstance(task_d.duration.days, TimeUnit.DAYS) + if task_d.duration + else None ) + task = create_task(summary, task_d.name, duration) # track predecessors to build after all tasks exist if tid := task_d.id: tasks_by_id[tid] = task