م. أوستروجورسكي, 2008

من أجل تطبيق GOST 34 بنجاح، من الضروري فهم كيفية بناء النظام الآلي، من وجهة نظر هذه المجموعة من المعايير. خلاف ذلك، لن نرى أي شيء في الضيف، باستثناء قائمة طويلة من المستندات ذات الأسماء الغامضة، ومتطلبات محتواها ستقنعنا مرة أخرى أنه في كثير من الحكمة هناك الكثير من الحزن. لذلك، قبل مناقشة الوثائق نفسها، يجب أن نفهم ما هو موضوع التوثيق.

النظام الآلي ووظائفه ومهامه

تعريف النظام الآلي

يحتوي GOST 34.003-90 على التعريف التالي للنظام الآلي: نظام يتكون من موظفين ومجموعة من أدوات الأتمتة لأنشطتهم، وتنفيذ تكنولوجيا المعلومات لأداء الوظائف المحددة. ماذا يعني هذا التعريف في الواقع؟ لا يمكنك فهم ذلك إلا من خلال قراءة التعريفات الأخرى لهذا المعيار ومقارنتها مع بعضها البعض. ماذا سنفعل الان؟

أهداف النشاط

لا يمكن للنظام الآلي أن يوجد إلا في حالة وجود موظفين يشاركون في نشاط معين. عادة، نحن نتحدث عن الأنشطة التي تكون نتائجها مفيدة لشخص ما، بغض النظر عن الأدوات المستخدمة. على سبيل المثال، أذهب إلى شباك التذاكر في المسرح للحصول على تذكرة، وأكون سعيدًا جدًا إذا كتب لي أمين الصندوق ذلك بالقلم على النموذج، طالما سمحوا لي بالدخول إلى المسرح باستخدامها. أمين الصندوق، بشكل عام، لا يهتم أيضًا بكيفية إصدار التذكرة بالضبط. ستكون مناسبة لأي طريقة طالما أنها لا تتطلب جهدًا كبيرًا وتوفر لها الفرصة لبيع تذكرة لي. بمعنى آخر، أنا وهي لدينا هدف مشترك. يستخدم GOST 34.003-90 المصطلح للإشارة إليه الغرض من النشاط. في كل مرة يغادر فيها مشاهد آخر النافذة وفي يده تذكرة، ويصبح المسرح أكثر ثراءً قليلاً، يتم تحقيق هذا الهدف من النشاط.

وظائف النظام الآلي

يمكن أن يكون هناك (وكقاعدة عامة) عدة أهداف للنشاط. وأي نتيجة مفيدة خارج النشاط نفسه يمكن اعتبارها هدفاً له. لذلك، إذا كان أمين الصندوق لا يبيع تذكرة فحسب، بل يقوم أيضًا في نهاية يوم العمل بإعداد تقرير مبيعات لرؤسائه، فيمكن اعتبار تجميع تقرير يومي هدفًا آخر للنشاط.

إذا وضعنا جهاز كمبيوتر وطابعة على مكتب أمين الصندوق، وأصدر رئيس أمين الصندوق أمرًا لها بكتابة التذاكر والتقارير في معالج النصوص وطباعتها على الطابعة، فسنحصل على نظام آلي. وفقا للأفكار الحديثة، فهي بدائية للغاية رسميا؛ يرجى العلم أن أهداف النشاط لم تتغير نتيجة تطبيق النظام الآلي، بل تغيرت طريقة تحقيقها فقط. وما كان يتم في السابق "بهذه الطريقة" يتم الآن في إطار نظام آلي. تسمى مجموعة إجراءات النظام الآلي التي تهدف إلى تحقيق هدف محدد وفقًا لـ GOST 34.003-90 وظيفة. ملحوظة: بغض النظر عن نظرتك للأمر، يعتبر الموظفون جزءًا من النظام.

تعتبر وظيفة النظام الآلي مفهومًا أساسيًا في GOST 34. يعتبر النظام الآلي، في المقام الأول، بمثابة مجموع وظائفه وبعد ذلك فقط كمجموعة من "البرامج" و"الأجهزة". الشيء الأكثر أهمية هو ما يفعله النظام، وما يتكون منه هو ثانوي.

ما سبق يمكن أن يقود القارئ إلى استنتاج مفاده أن كل هدف نشاط في النظام الآلي يتوافق مع وظيفة واحدة فقط. من السهل تخيل مثل هذا النظام، لكن الممارسة أكثر تنوعًا. فمن ناحية، لا تكون الأنشطة مؤتمتة دائمًا بشكل كامل. لا يزال يتعين تحقيق بعض الأهداف يدويًا حتى بعد تطبيق النظام الآلي. من ناحية أخرى، نظرًا لأنه يمكن تحقيق نفس النتيجة في ظل ظروف مختلفة بطرق مختلفة، فيمكن توجيه العديد من الوظائف نحو هدف واحد من النشاط في نظام آلي، على سبيل المثال، بيع تذكرة في شباك التذاكر وبيع تذكرة عبر إنترنت. وبالإضافة إلى ذلك، فإن أي نظام آلي يتطلب صيانة معينة، لذلك علينا أن نقدم مفهوم الوظيفة المساعدة. المثال النموذجي هو إنشاء نسخة احتياطية من البيانات.

مهام النظام الآلي

في الحالة العامة، عند أداء وظيفة ما، يتم تنفيذ جزء من العمل من قبل الموظفين، وجزء من خلال التكنولوجيا، على سبيل المثال، تتم طباعة التذكرة تلقائيًا ويتم تسليمها للمشتري يدويًا بواسطة أمين الصندوق. يتم استدعاء سلسلة من الإجراءات التلقائية (كذا) التي تؤدي إلى نتيجة من نوع معين في GOST 34.003-90 مهمة.

هنا لا يتم نقل تعريف المشكلة بدقة كاملة، ولكن في الوقت الحالي سيكون هذا كافيًا بالنسبة لنا، لأنه ليس من العار أن يقرأ أي شخص المعيار بنفسه. من المهم أن تكون المهمة هي الجزء الأكثر رسمية بشكل واضح من النشاط الآلي. يمكنك أن تتخيل وظيفة يتم تنفيذها بشكل تلقائي تمامًا، مثل النسخ الاحتياطي المذكور أعلاه. في هذه الحالة، يتم تقليل الوظيفة إلى مهمة واحدة.

يمكن حل نفس المهمة عن طريق أداء وظائف مختلفة. على سبيل المثال، إذا كان النظام الآلي يحتوي على عدة وظائف لبيع تذكرة، فإن تنفيذ كل منها قد يتطلب في مرحلة ما طباعة التذكرة.

تكوين النظام الآلي

الأنظمة الفرعية

إذا كان النظام الآلي معقدًا جدًا، فسيتم تقسيمه إلى الأنظمة الفرعية. ماذا يعني ذلك، معقد للغاية، من الصعب جدًا تحديده. تصف نظرية النظم مستويات ومعايير مختلفة من التعقيد. من الناحية العملية، غالبًا ما تكون الحاجة إلى تخصيص عدة أنظمة فرعية في نظام آلي لأسباب تنظيمية ومالية، على سبيل المثال، يتم تطوير الأنظمة الفرعية وتشغيلها بشكل تسلسلي.

على الرغم من استخدام مصطلح النظام الفرعي عدة مرات في GOST 34، يبدو أنه لا يوجد تعريف رسمي لهذا المفهوم هناك. تشير التجربة إلى أن النظام الفرعي هو جزء من نظام آلي يفي أيضًا بتعريف النظام الآلي، على وجه الخصوص، لديه وظائف كاملة.

وبالعودة إلى مثال التذاكر، يمكننا أن نقرر أن النظام الآلي يتكون من نظامين فرعيين: نظام فرعي للتذاكر ونظام فرعي لإعداد التقارير اليومية. دعونا نتفق، لمزيد من الوضوح، على أن يقوم أمين الصندوق بكتابة التذاكر في محرر النصوص، والتقارير في جداول البيانات.

عناصر

إن تحديد أهداف النشاط ووظائف النظام الآلي وأنظمته الفرعية إذا لزم الأمر هو أمر شخصي إلى حد كبير ويعتمد على وجهة نظر الموضوع الذي قرر القيام بذلك. إذا كانت بعض النتائج مهمة في سياق المشكلة التي يتم حلها، فيمكننا اعتبارها هدفًا، وإلا فإننا نتجاهلها. كما سنقوم بتقسيم النظام الآلي إلى أنظمة فرعية بالطريقة التي تناسبنا، طالما أن قراراتنا لا تتعارض مع محتوى هذا المفهوم.

المكونات هي الأجزاء التي نبني منها، في الواقع الموضوعي، نظامًا آليًا. يتكون النظام فعليًا من مكوناته، لذا فإن تقسيم النظام الآلي إلى مكونات هو الأكثر موضوعية.

نقوم بشراء كل مكون، وتثبيته وتوصيله (إذا كان جهازًا)، وتثبيته (إذا كان برنامجًا) وصيانته بشكل منفصل عن المكونات الأخرى. اشترينا جهاز كمبيوتر ووضعناه على الطاولة - إنه مكون. لقد قمنا بتطوير محرر نصوص خاص لكتابة التذاكر - وهو مكون آخر. تم تنزيل جداول البيانات المجانية من الإنترنت - مرة أخرى مكون. وحتى أمين الصندوق نفسه، بطريقة ما، هو أيضًا أحد مكونات النظام الآلي.

يعد تكوين مكونات النظام الآلي مهمًا جدًا من وجهة نظر توثيقه، حيث يتم التعامل مع الوثائق الفنية للنظام في حد ذاته وللمكونات بشكل مختلف. بشكل عام، يجب تطويره بواسطة أشخاص مختلفين، وهو مصمم وفقًا لمعايير مختلفة اعتمادًا على نوع المكون.

أنواع الضمانات

أحد أصعب المفاهيم بالنسبة للمستخدم المبتدئ لـ GOST 34 هو نوع من الأمن. أي نوع من الأمن هذا؟ هل يمكنك رؤيتها أو لمسها؟ بيع أو شراء؟

يجمع كل نوع من البرامج بين مكونات أو حلول تقنية ذات طبيعة معينة. يذكر GOST 34 العديد من أنواع الأمان المختلفة، ولن نصف كلًا منها بالتسلسل هنا، ولكننا سندرج فقط أكثرها وضوحًا:

• دعم المعلومات - جميع البيانات والبيانات الوصفية التي يعمل بها النظام؛
• البرامج - جميع البرامج التي تشكل جزءًا من النظام؛
• الدعم الفني - جميع الوسائل التقنية (وبعبارة أخرى، المعدات والأجهزة) التي تشكل جزءًا من النظام.

دعونا نكرر مرة أخرى، هذه ليست جميع أنواع الأمان. لا يمكننا حتى أن نقول على وجه اليقين أنهم الأكثر أهمية. على سبيل المثال، يعد الدعم المترولوجي ذا أهمية كبيرة لأنظمة التحكم الآلي في العمليات (APCS). تتطلب العديد من الأنظمة الآلية دعمًا رياضيًا ولغويًا معقدًا. ولكن من الصعب أن نتصور نظامًا آليًا يخلو تمامًا من أحد أنواع الدعم الثلاثة المذكورة أعلاه (التمرين: جربه).

اليوم سنتحدث عن المعايير المحلية لوثائق التصميم. كيف تعمل هذه المعايير في الممارسة العملية، ولماذا هي سيئة ولماذا هي جيدة. عند تطوير الوثائق للعملاء الحكوميين والعملاء الخاصين الجادين، ليس لدينا عادةً أي خيار - يتم تضمين الامتثال للمعايير في متطلبات توثيق المواصفات الفنية. في الممارسة العملية، واجهت أمثلة مختلفة على سوء فهم هيكل المعايير، وما يجب أن يكون في الوثائق ولماذا تكون هذه الوثائق مطلوبة. ونتيجة لذلك، تنتج أقلام الكتاب التقنيين والمحللين والمتخصصين في بعض الأحيان مثل هذه الجواهر التي ليس من الواضح في أي حالة من الوعي كتبتها. ولكن في الواقع، كل شيء بسيط للغاية. لم يُرجع البحث في حبر أي روابط لمواد أكثر أو أقل اكتمالًا حول هذا الموضوع، لذلك أقترح ملء هذه الفجوة المزعجة.

ما هي معايير التوثيق؟

في السلسلة 34 المعنية، لا يوجد سوى 3 معايير توثيق رئيسية:

المعيار الأكثر شعبية وشعبية لتطوير المواصفات الفنية. الشيء الوحيد الذي يجب ألا تنساه هو أنه يرتبط ارتباطًا وثيقًا بالمعايير الأخرى للسلسلة، وإذا كنت قد حصلت على مواصفات فنية مصنوعة وفقًا لهذا المعيار، فمن المستحسن بشدة الالتزام بالمعايير الأخرى، حتى لو لم تكن هناك متطلبات مباشرة لهذا. على الأقل من حيث الأيديولوجية العامة (حولها أدناه)

هذه وثيقة أساسية توفر قائمة كاملة بوثائق GOST 34، وتوصيات لترميز المستندات، ومراحل المشروع التي تنتمي إليها المستندات (المراحل موصوفة في GOST 34.601-90)، بالإضافة إلى كيفية دمجها مع بعضها البعض .

في الواقع، هذا المعيار عبارة عن جدول كبير به تعليقات. ويمكن وضعه في برنامج Excel لسهولة الاستخدام.

معيار ضخم يصف محتوى وثائق المشروع بدرجات متفاوتة من التفاصيل. يتم استخدام GOST 34.201-89 المذكور أعلاه كمؤشر.

هناك العديد من الأسئلة والتفسيرات لأحكامه فيما يتعلق بمعيار RD 50-34.698-90، والتي غالبًا ما يتم فهمها بشكل مختلف من قبل العميل والمقاول، أو حتى أعضاء فريق المشروع، بسبب غموضها. لكن، لسوء الحظ، ليس لدينا أي شيء ملموس أكثر.

دعونا الآن نفكر في إيجابيات وسلبيات المعايير، بدءًا تقليديًا بالسلبيات.

عيوب المعايير

العيب الرئيسي واضح للجميع - المعايير قديمة. أنها تحتوي على فكرة قديمة عن بنية النظام الآلي. على سبيل المثال:

• تطبيقات ذات مستويين، تتكون من برنامج عميل وخادم DBMS (لا يوجد ثلاثة أو أكثر من تطبيقات "الطبقة"، ولا يوجد Weblogic أو JBoss)
• هيكل جداول قاعدة البيانات الموصوفة سيعطي فكرة عن نموذج البيانات المنطقي (حقيقة أنه قد يكون هناك نوع من السبات بين التطبيق وقاعدة البيانات بدا وكأنه فائض سيئ في ذلك الوقت)
• واجهة المستخدم عبارة عن نافذة واحدة (هل هناك أي شيء آخر؟ ما هو "المتصفح"؟)
• يوجد عدد قليل من التقارير في النظام، وجميعها ورقية ومطبوعة على طابعة نقطية.
• ويركز البرنامج الذي يجري تطويره على حل "مشكلة معالجة المعلومات" التي لها مدخلات ومخرجات واضحة وشديدة التخصص. تعتمد معالجة المعلومات على "خوارزمية". في بعض الأحيان يكون هناك العديد من "الخوارزميات". (كانت البرمجة الشيئية في ذلك الوقت تتخذ خطواتها الأولى ولم يتم النظر فيها بجدية).
• يفهم مسؤول قاعدة البيانات المعلومات الموجودة في الجداول ويشارك بنشاط في تحرير أدلة النظام (هل يوجد بالفعل خادم DBMS واحد لـ 50 تطبيقًا مختلفًا؟)

وبناءً على ذلك، يحتوي المعيار على عناصر مثل ما يلي:

5.8. رسم نموذج الوثيقة (إطار الفيديو)
يجب أن تحتوي الوثيقة على صورة لشكل الوثيقة أو إطار الفيديو وفقا لمتطلبات معايير الدولة لنظام التوثيق الموحد R 50-77 والشروحات اللازمة.

الهدف من الوثيقة هو أن الشركات السوفيتية استخدمت ما يسمى بـ "مناطق الطباعة"، حيث كانت هناك طابعات مصفوفة عالية السرعة، والتي غالبًا ما كان المهندسون أنفسهم يكتبون برامج التشغيل الخاصة بها. ولذلك، كان عليهم الاحتفاظ بسجل لجميع المستندات التي يلزم طباعتها للتأكد من أن المستندات تبدو كما ينبغي عند طباعتها.

يعد "إطار الفيديو" أيضًا مستندًا تم عرضه على شاشة عرض النص. لم تكن شاشات العرض تدعم دائمًا الأحرف المطلوبة والعدد المطلوب من الأحرف الأفقية والخطوط الرأسية (ولم تدعم الرسومات على الإطلاق). لذلك، كان من الضروري هنا أيضًا تنسيق نماذج جميع مستندات الشاشة.

الآن الكلمات "machineogram"، "إطار الفيديو"، "ADC" لم تعد تخبرنا بأي شيء. كما أنني لم أجدها قيد الاستخدام رغم أنني تخرجت من معهد متخصص في التسعينيات. كان هذا هو وقت ظهور Windows 3.1 وشاشات VGA والأقراص المرنة مقاس 3 بوصات وأول مواقع الإنترنت المحلية. لكن هذه الكلمات موجودة في المعيار، ويطلب العميل أحيانًا بشكل متقلب أن نزوده بمجموعة كاملة من الوثائق وفقًا لـ GOST 34.201-89. علاوة على ذلك، فإن مثل هذه الصياغة في الاختصاصات تنتقل من وزارة إلى أخرى وأصبحت بالفعل نوعًا من القالب غير المعلن الذي يتم فيه التوصل إلى المحتوى.

لذا فإن المستند الذي يحمل الاسم الغبي "رسم نموذج المستند (إطار الفيديو)" في المشروع يجب ألا يكون فارغًا.

ما هو جيد في المعيار

يعد أي معيار جيدًا لأنه يسمح للعميل والمقاول بالتحدث بنفس اللغة ويوفر ضمانًا بأنه على الأقل لن يكون لدى العميل أي شكاوى "شكليًا" بشأن النتائج المرسلة.

وتعد معايير GOST 34 جيدة أيضًا لأنها تم تجميعها بواسطة أشخاص أذكياء، وتم اختبارها على مر السنين، ولديها هدف واضح - لوصف الجوهر المجرد المعقد على الورق قدر الإمكان، والذي يمثله أي نظام تحكم آلي.

عندما تحتاج إلى تعيين مهمة بكفاءة للمقاولين الغربيين الذين لم يسمعوا أبدًا عن معايير GOST الخاصة بنا، يمكنك أيضًا الاعتماد على هذه المعايير، أو بالأحرى على محتواها ومكونها الدلالي. لأنني أكرر أن ضمان اكتمال المعلومات يستحق الكثير. بغض النظر عن مدى تملقنا أنفسنا بالمستوى العالي من احترافنا، فقد ننسى تضمين الأشياء الأولية في متطلباتنا، في حين أن نفس GOST 34.602-89 "يتذكر" كل شيء. إذا لم يكن من الواضح لك كيف يجب أن تبدو نتيجة عمل المقاولين الغربيين، فاطلع على متطلبات التوثيق والأقسام الموصى بها. أؤكد لك أنه من الأفضل عدم التفكير في الأمر! على الأرجح، هناك نظائرها الغربية لمعاييرنا، حيث يمكن أن يكون كل شيء أكثر اكتمالا وأكثر حداثة وأفضل. لسوء الحظ، أنا لست على دراية بهم، لأنه لم تكن هناك حالة واحدة لم تكن فيها معايير GOST لدينا كافية.

يمكنك أن تضحك من حقيقة أن منشئي المعايير لم يعرفوا شيئًا عن جافا أو .NET، وعن الشاشات عالية الدقة والإنترنت، لكنني لا أنصح بالتقليل من حجم العمل الذي قاموا به وقيمته لمجتمعنا المهني.

كيفية قراءة وفهم معايير التوثيق وفقًا لسلسلة GOST 34

يقسم المعيار جميع المستندات على محورين - الوقت ومجال الموضوع. إذا نظرت إلى الجدول 2 في GOST 34.201-89، فيمكنك رؤية هذا التقسيم بوضوح (أعمدة "مرحلة الإنشاء" و"جزء من المشروع"

مراحل إنشاء نظام التحكم الآلي

يتم تعريف مراحل الخلق في GOST 34.601-90. ثلاثة منها تتعلق بالتوثيق:

• مسودة التصميم (ED)
• التصميم الفني (TP)
• تطوير وثائق العمل (DD)

التصميم الأولييتبع مرحلة المواصفات الفنية ويعمل على تطوير حلول التصميم الأولية.

مشروع فنييصف النظام المستقبلي من جميع الزوايا. يجب أن تترك المستندات في مرحلة TP، بعد قراءتها، الوضوح الكامل في المناهج والأساليب والحلول المعمارية والتقنية المقترحة. في المرحلة التالية، سيكون الوقت قد فات لوصف المناهج وتبرير الحلول التقنية، لذا فإن المرحلة P هي المفتاح لإنجاز العمل بنجاح، حيث يجب أن تنعكس جميع المتطلبات المتنوعة للمواصفات الفنية في وثائق المرحلة P في المرحلة P، قد لا يكون النظام موجودًا على الإطلاق.

وثائق العملمصممة للنشر الناجح والتكليف ومواصلة تشغيل النظام الجديد. هذه هي المستندات التي تحتوي على معلومات محددة للغاية تصف الكيانات الموجودة فعليًا، على عكس المرحلة P، التي تصف روعة المستقبل.

أجزاء (أقسام) من وثائق المشروع لإنشاء نظام تحكم آلي

وينقسم مجال الموضوع إلى "أحكام". للوهلة الأولى، يبدو أن مثل هذا التقسيم زائد عن الحاجة وغير ضروري. ولكن عندما تبدأ العمل باستخدام مجموعة الأدوات هذه عمليًا، تصبح الأيديولوجية المضمنة فيها واضحة تدريجيًا.

النظام الآلي، كما حدده مجمعو GOST، هو مزيج من الأجهزة والبرامج وقنوات الاتصال التي تعالج المعلومات الواردة من مصادر مختلفة وفقًا لخوارزميات معينة وتنتج نتائج المعالجة في شكل مستندات أو هياكل بيانات أو إجراءات تحكم. نموذج بدائي لأبسط مدفع رشاش.

من أجل وصف هذه "الآلة" بشكل كامل، يتم عمل الأقسام التالية (كما في الرسم):

البرمجيات (MS)إجابة على الأسئلة: ما هو المنطق الموجود داخل "الصندوق الأسود"؟ لماذا تم اختيار هذه الخوارزميات المحددة، وهذه الصيغ المحددة، وهذه المعاملات المحددة؟

البرمجيات الرياضية لا تعرف شيئًا عن المعالجات أو قواعد البيانات. وهذه منطقة تجريدية منفصلة، ​​وهي موطن "الخيول الكروية في الفراغ". لكن البرامج الرياضية يمكن أن تكون مرتبطة ارتباطًا وثيقًا بمجال الموضوع، المعروف أيضًا باسم الحياة الحقيقية. على سبيل المثال، يجب أن تتم الموافقة على خوارزميات التحكم لأنظمة التحكم في حركة المرور من قبل مفتشية السلامة المرورية الحكومية قبل أن تتم الموافقة عليها من قبل العميل. وبعد ذلك تفهم سبب إدراجها في كتاب منفصل. لأنه لا أحد في شرطة المرور مهتم بنظام التشغيل الذي سيعمل عليه خادم التطبيق، ولكن ما هي الإشارة والحد الأقصى للسرعة الذي سيظهر على اللوحة أثناء المطر أو الثلج، وهو أمر مثير للاهتمام للغاية. إنهم مسؤولون عن دورهم ولن يوقعوا على أي شيء آخر. ومن ناحية أخرى، عندما وقعوا، لن تكون هناك أسئلة حول الجانب الفني للمسألة - لماذا اختاروا تلك اللوحات أو إشارات المرور دون غيرها. تتجلى حكمة "الأسلاف" بدقة في مثل هذه الحالات العملية.

دعم المعلومات (IS). شريحة أخرى من النظام. هذه المرة أصبح الصندوق الأسود لنظامنا شفافًا وننظر إلى المعلومات المتداولة فيه. تخيل نموذجًا لجهاز الدورة الدموية عند الإنسان عندما تكون جميع الأعضاء الأخرى غير مرئية. شيء من هذا القبيل هو دعم المعلومات. فهو يصف تكوين وطرق تدفق المعلومات في الداخل والخارج، والتنظيم المنطقي للمعلومات في النظام، ووصف الكتب المرجعية وأنظمة الترميز (أولئك الذين صنعوا برامج للإنتاج يعرفون مدى أهميتها). يقع الجزء الوصفي الرئيسي في مرحلة TP، ولكن تتدفق بعض "الأساسيات" إلى مرحلة RD، مثل مستند "كتالوج قاعدة البيانات". من الواضح أنه كان يحتوي في السابق على ما هو مكتوب في العنوان بالضبط. ولكن اليوم، حاول إنشاء مثل هذا المستند لنظام معقد معقد، عندما يستخدم النظام في كثير من الأحيان الأنظمة الفرعية المشتراة مع مخازن المعلومات الغامضة الخاصة بها. أنا لا أقول حتى أن هذه الوثيقة ليست مطلوبة بشكل خاص الآن.

أو هنا "بيان وسائط تخزين الكمبيوتر". ومن الواضح أنها كانت تحتوي في السابق على أعداد من البراميل المغناطيسية أو بكرات الأفلام. الآن ماذا يجب أن أضع هناك؟

باختصار، في مرحلة RD، تمثل وثائق دعم المعلومات بداية ضارة إلى حد ما، حيث يجب أن تكون موجودة رسميا، ولكن لا يوجد شيء خاص لملءها.

برمجة. الجزء المفضل لدى الجميع من وثائق المشروع. نعم، فقط لأنها وثيقة واحدة فقط! وبعد ذلك، يفهم الجميع ما يجب كتابته هناك. لكنني سأكررها على أي حال.

في هذا المستند، يجب أن نخبرك بمساعدة البرنامج الذي يتم تنفيذ الخوارزميات الموضحة في تعلم الآلة، ومعالجة المعلومات الموضحة في IR. أي أنه ليست هناك حاجة لتكرار المعلومات من الأقسام الأخرى هنا. يتم هنا تقديم بنية النظام، والأساس المنطقي لتقنيات البرامج المختارة، ووصفها (جميع أنواع أشياء النظام: لغات البرمجة، والأطر، وأنظمة التشغيل، وما إلى ذلك). كما نصف في هذه الوثيقة كيفية تنظيم أدوات معالجة المعلومات (قوائم انتظار الرسائل، والتخزين، وأدوات النسخ الاحتياطي، وحلول الإتاحة، وجميع أنواع تجمعات التطبيقات، وما إلى ذلك). يحتوي المعيار على وصف تفصيلي لمحتويات هذه الوثيقة، والتي سوف يفهمها أي متخصص.

الدعم الفني (TO). ما لا يقل عن جزء محبوب من وثائق المشروع. ولا تخيم على الصورة الوردية إلا كثرة الوثائق التي تحتاج إلى تطوير. في المجمل، يتطلب المعيار تطوير 22 وثيقة، منها 9 في مرحلة TC.

والحقيقة هي أن المعيار يوفر وصفًا لجميع أشكال الدعم الفني، بما في ذلك أجهزة الكمبيوتر والشبكات والأنظمة الهندسية وحتى الجزء الإنشائي (إذا لزم الأمر). ويتم تنظيم هذا الاقتصاد من خلال عدد كبير من المعايير واللوائح المنسقة في منظمات مختلفة، وبالتالي يكون أكثر ملاءمة لتقسيم كل شيء إلى أجزاء وتنسيق (تحرير) في أجزاء. وفي الوقت نفسه، يسمح لك المعيار بدمج بعض المستندات مع بعضها البعض، وهو أمر منطقي إذا وافق شخص واحد على المجموعة بأكملها.

لا تنس أيضًا أن مجموعة معايير الجودة تتضمن تسجيل وتخزين المستندات الفنية، وقد يتم توزيع "كتبنا" من العميل بين أرشيفات مختلفة، اعتمادًا على موضوع الوصف. هذه حجة أخرى لصالح تجزئة الوثائق.

الدعم التنظيمي (OO). بعد أن قمت بقمع الرغبة المعتادة في التقنية لتخطي هذا القسم في أسرع وقت ممكن، على العكس من ذلك، سأفكر في الأمر بمزيد من التفصيل. منذ ذلك الحين، أيها الزملاء، ظهرت مؤخرًا بعض الاتجاهات السيئة في المشاريع التي تتطلب التوضيح في هذا القسم.

في مرحلة TP يحتوي القسم على مستند واحد فقط " وصف الهيكل التنظيمي"، حيث يجب أن نخبر العميل بما يجب عليه الاستعداد له من حيث تغيير الهيكل التنظيمي. فجأة تحتاج إلى تنظيم قسم جديد لتشغيل نظامك، وإدخال وظائف جديدة، وما إلى ذلك.

في مرحلة البحث والتطوير، تظهر مستندات أخرى أكثر إثارة للاهتمام، والتي أود النظر فيها بشكل منفصل.

دليل المستخدم. أعتقد أن التعليقات ليست ضرورية.

منهجية (تقنية) التصميم بمساعدة الكمبيوتر. إذا لزم الأمر، يمكنك تضمين وصف لعملية إنشاء البرنامج والتحكم في الإصدار والاختبار وما إلى ذلك في هذا المستند. ولكن هذا إذا كان العميل في المواصفات الفنية يرغب في تجميع البرنامج شخصيًا. إذا لم يطلب ذلك (ولا يدفع ثمنه)، فإن مطبخك الداخلي بالكامل ليس من اختصاصه، ولا يلزم عمل هذه الوثيقة.

التعليمات التكنولوجية. نظرًا لموضة إضفاء الطابع الرسمي على العمليات التجارية، يحاول العميل الماكر أحيانًا إدخال لوائح التشغيل في هذه الوثيقة. لذا، لا ينبغي عليك القيام بذلك تحت أي ظرف من الظروف.

وصف العمليات التجارية، والوصف الوظيفي والوظيفي، ولوائح العمل - كل هذا هو ORD، أي الوثائق التنظيمية والإدارية. وهو نتاج مشروع استشاري، والذي، على حد علمي، لم يتم شراؤه منك. وقمنا بشراء مشروع فني منك وكذلك الوثائق الفنية الخاصة به.

التعليمات التكنولوجية هي طبقة بين تعليمات التشغيل ودليل المستخدم. يصف RP بالتفصيل كيفتحتاج إلى القيام بإجراءات معينة في النظام. التعليمات التكنولوجية تقول ذلك أيّيجب تنفيذ الإجراءات في بعض الحالات المتعلقة بتشغيل النظام. بشكل تقريبي، يعد التعليم التكنولوجي ملخصًا قصيرًا لبرنامج RP لمنصب أو دور معين. إذا لم يكن لدى العميل أدوار تم تشكيلها أو أراد منك إنشاء الأدوار ومتطلبات الوظيفة بنفسك، فقم بتضمين الأدوار الأساسية في المستند، على سبيل المثال: المشغل، المشغل الأول، المسؤول. يجب أن تكون تعليقات العميل حول موضوع "لكن الأمر ليس كذلك معنا" أو "لا نحب ذلك" مصحوبة بقائمة الأدوار ووصف مسؤوليات الوظيفة. لأن العمليات التجارية نحن نحن لا نضعها. نحن هذه العمليات التجارية أتمتة.

سأكتب عن المكابس الموصوفة بشكل منفصل، مع أمثلة ملونة، فهذه ليست المرة الأولى التي يتكرر فيها ذلك في قطاعات مختلفة من «الاقتصاد الوطني».

وصف العملية التكنولوجية لمعالجة البيانات (بما في ذلك المعالجة عن بعد). بقايا مثيرة للشفقة من عصر الكهف، عندما كان هناك "مشغلو كمبيوتر" معينون خصيصًا يقومون بتزويد الآلة بالبطاقات المثقوبة وقاموا بتغليف نسخة مطبوعة من النتيجة في مظروف. هذه التعليمات لهم. لا أستطيع أن أخبرك بالضبط ما الذي يجب كتابته فيه في القرن الحادي والعشرين. اخرج بنفسك. أفضل شيء هو أن ننسى هذه الوثيقة.

الحلول على مستوى النظام (WSO). ينص المعيار على 17 مستندًا في قسم OP. أولاً، هذه هي جميع وثائق المرحلة الأولية للتصميم التخطيطي تقريبًا. ثانيا، هذه هي جميع أنواع التقديرات والحسابات والأوصاف الموجزة للوظائف الآلية. وهذا يعني معلومات للأشخاص ليس من إنتاج تكنولوجيا المعلومات الرئيسي، ولكن لموظفي الدعم - المديرين والمقدرين ومتخصصي المشتريات والاقتصاديين، وما إلى ذلك.

وثالثًا، يتضمن البروتوكول الاختياري مستندًا ضخمًا يسمى "مذكرة توضيحية للمشروع الفني"، والذي يهدف إلى أن يكون نوعًا من الملخص التنفيذي، ولكن في الواقع، يقوم العديد من المصممين بإدخال كل المحتوى المفيد لمرحلة TP فيه. يمكن تبرير مثل هذا النهج الجذري، بل ويحقق منفعة متبادلة لكل من العميل والمقاول، ولكن في حالات معينة.

خيارات لاستخدام GOST 34

1. الالتزام الكامل والدقيق بالمعيار. بطبيعة الحال، لن يكتب أحد مثل هذه السحابة من المستندات طوعا. لذلك، يتم إعداد مجموعة كاملة من المستندات فقط بناءً على الطلب العاجل من العميل، والذي قام بتأمينه في المواصفات الفنية وتثبيته أيضًا باتفاقية في الأعلى. في هذه الحالة، عليك أن تأخذ كل شيء حرفيًا وتعطي "الكتب" المادية للعميل، والتي ستكون عليها أسماء المستندات من الجدول 2 في GOST 34.201-89، باستثناء الكتب غير الضرورية تمامًا، والتي يجب مناقشة وتأمين في الكتابة. يجب أيضًا أن يتوافق محتوى المستندات، دون أي خيال، مع RD 50-34.698-90، وصولاً إلى أسماء الأقسام. من أجل تفجير عقل العميل، يتم في بعض الأحيان تقسيم نظام كبير إلى أنظمة فرعية، ويتم إصدار وثائق تصميم منفصلة لكل نظام فرعي. يبدو مرعبًا ولا يخضع للسيطرة الطبيعية بمساعدة العقل الأرضي. وخاصة فيما يتعلق بتكامل النظم الفرعية. مما يبسط القبول إلى حد كبير. الشيء الرئيسي هو أنك لا تشعر بالارتباك وأن نظامك لا يزال يعمل كما ينبغي.
2. نحن فقط نحب GOSTs. الشركات الكبيرة الجادة تحب المعايير. لأنها تساعد الناس على فهم بعضهم البعض بشكل أفضل. إذا كان عميلك معروفًا بحبه للنظام والتوحيد القياسي، فحاول الالتزام بأيديولوجية GOST القياسية عند تطوير المستندات، حتى لو لم تكن المواصفات الفنية تتطلب ذلك. سيتم فهمك واعتمادك بشكل أفضل من قبل المتخصصين المعتمدين، ولن تنسى أنت بنفسك تضمين معلومات مهمة في الوثائق، وسترى الهيكل المستهدف للمستندات بشكل أفضل، وتخطط بشكل أكثر دقة لكتابتها، وستنقذ نفسك وزملائك الكثير من الأعصاب والمال.
3. نحن لا نهتم بالتوثيق، طالما أن كل شيء يعمل. المظهر المتلاشي للعميل غير المسؤول. لا يزال من الممكن العثور على وجهة نظر مماثلة للتوثيق بين العملاء الصغار والفقراء، وكذلك في "الأنظمة الحمقاء" الاستبدادية المتبقية من زمن البيريسترويكا، حيث يكون الرئيس محاطًا بالأصدقاء المخلصين - المديرين، ويتم حل جميع المشكلات في المحادثات الشخصية . في مثل هذه الظروف، أنت حر في إهمال التوثيق تمامًا، ولكن من الأفضل، بعد كل شيء، عدم إسقاط البصر وملء التوثيق بالمحتوى بشكل تخطيطي على الأقل. إذا لم يكن لهذا العميل، فقم بتمريره (بيعه) إلى العميل التالي.

خاتمة

كانت هذه المقالة حول معايير GOST الخاصة بنا لتوثيق أنظمة التحكم الآلية. إن GOSTs قديمة، ولكن، كما اتضح، فهي لا تزال مفيدة للغاية في الأسرة. وبصرف النظر عن بعض الأساسيات الواضحة، فإن هيكل التوثيق يتمتع بخصائص الاكتمال والاتساق، كما أن الالتزام بالمعيار يزيل العديد من مخاطر المشروع، والتي قد لا نكون على علم بوجودها في البداية.

آمل أن تكون المادة المقدمة مفيدة لك، أو على الأقل مثيرة للاهتمام. على الرغم من الملل الواضح، فإن التوثيق هو عمل مهم ومسؤول، حيث تكون الدقة فيه بنفس أهمية كتابة التعليمات البرمجية الجيدة. اكتب وثائق جيدة أيها الزملاء! وفي الأسبوع المقبل، سأذهب في رحلتين عمل على التوالي، لذلك لا أستطيع ضمان نشر مواد جديدة (ليس لدي ذاكرة تخزين مؤقت، أنا أكتب من رأسي).

معايير أنظمة التحكم الآلي التي لم يتم دمجها في سلسلة.

غوست 15971-90. نظم معالجة المعلومات. المصطلحات والتعاريف.

غوست 19781-90. برامج لأنظمة معالجة المعلومات. المصطلحات والتعاريف.

غوست 28806-90. جودة البرمجيات. المصطلحات والتعاريف. تم تقديمه في 1 يناير 1992.

غوست 28195-89. تقييم جودة البرمجيات. الأحكام العامة.

غوست 25868-91. المعدات الطرفية لأنظمة معالجة المعلومات. المصطلحات والتعاريف. م. دار نشر المواصفات. 1992، 34 ص. تم تقديمه في 1 يناير 1993.

غوست 28147-89. نظم معالجة المعلومات. حماية التشفير. خوارزميات تحويل التشفير.

غوست 28803-90 (آيزو 6523-84). تبادل البيانات. هيكل تعريف المنظمة. تم تقديمه اعتبارًا من 01/01/93.

غوست آر آيزو/آي إي سي 9125-93. تكنولوجيا المعلومات. تقييم المنتجات البرمجية. خصائص الجودة والمبادئ التوجيهية لاستخدامها.

GOST R ISO/IEC إلى 9294-93. تكنولوجيا المعلومات. دليل إدارة وثائق البرمجيات.

غوست آر آيزو 9127-94. نظم معالجة المعلومات. وثائق المستخدم ومعلومات التعبئة والتغليف لحزم البرامج الاستهلاكية.

ريسو 9126-93. نظم معالجة المعلومات. وثائق المستخدم ومعلومات التعبئة والتغليف لحزم البرامج الاستهلاكية.

GOST RISO/IEC 12207. عمليات دورة حياة البرمجيات. تم تقديمه اعتبارًا من 07/01/2000.

غوست R50739-95. مرافق الكمبيوتر. الحماية ضد الوصول غير المصرح به إلى المعلومات. المتطلبات الفنية العامة.

غوست R51188-98. حماية البيانات. برامج اختبار فيروسات الكمبيوتر. دليل النموذج.

غوست 28140-89. نظم معالجة المعلومات. لغة برمجة باسكال.

غوست ص 51169-98. جودة معلومات الخدمة. نظام شهادات تكنولوجيا المعلومات في مجال جودة معلومات الخدمة. المصطلحات والتعاريف.

غوست ص 51168-98. جودة معلومات الخدمة. رموز لعناصر العمليات التكنولوجية لمعالجة البيانات.

غوست ص 51170-98. جودة معلومات الخدمة. المصطلحات والتعاريف.

غوست ص 51171-98. جودة معلومات الخدمة. قواعد تقديم تكنولوجيات المعلومات للحصول على الشهادات.

سلسلة GOST 34. "تكنولوجيا المعلومات (IT)".

أردي 50-680-88. الأنظمة الآلية. الأحكام الأساسية.

أ د 50-682-89. تكنولوجيا المعلومات. مجموعة من المعايير والمبادئ التوجيهية للأنظمة الآلية. الأحكام العامة.

غوست 34.003-90. هو - هي. الأنظمة الآلية. المصطلحات والتعاريف.

غوست 34.201-89. هو - هي. مجموعة معايير للأنظمة الآلية. أنواع واكتمال وتعيين الوثائق عند إنشاء الأنظمة الآلية.

غوست 34.601-90. هو - هي. مجموعة معايير للأنظمة الآلية. الأنظمة الآلية. مراحل الخلق. (بدلاً من GOST 24.601-86، 24.602-86).

غوست 34.602-89. هو - هي. مجموعة معايير للأنظمة الآلية. الشروط المرجعية لإنشاء نظام آلي.

غوست 34.603-89. هو - هي. أنواع اختبارات الأنظمة الآلية.

د 50-34.698-90. هو - هي. الأنظمة الآلية. متطلبات محتوى الوثائق.

غوست 34.1501.1-92 (ISO/TR 10314-1-90). هو - هي. الأتمتة الصناعية. الإنتاج الأولي. الجزء 1. النموذج المرجعي للتقييس ومنهجية تحديد متطلبات التقييس.

سلسلة GOST 19. "النظام الموحد لتوثيق البرامج (USPD)".

غوست 19.001-77. النظام الموحد لتوثيق البرامج. الأحكام العامة.

غوست 19.701-90. (ايزو 5807-85). إسبد. مخططات الخوارزميات والبرامج والبيانات والأنظمة. الاتفاقيات وقواعد التنفيذ. (بدلاً من GOST 19.002-80، 19.003-80).

غوست 19.005-85. إسبد. P- مخططات الخوارزميات والبرامج. التسميات الرسومية التقليدية وقواعد التنفيذ.

غوست 19.101-77. إسبد. أنواع البرامج ووثائق البرنامج.

غوست 19.102-77. إسبد. مراحل التطوير.

غوست 19.103-77. إسبد. تسميات البرامج ووثائق البرنامج.

غوست 19.104-78. إسبد. النقوش الأساسية.

غوست 19.105-78. إسبد. المتطلبات العامة لوثائق البرنامج.

غوست 19.106-78. إسبد. متطلبات وثائق البرنامج المطبوعة.

غوست 19.201-78. إسبد. مهمة فنية. متطلبات الخلق والتصميم.

غوست 19.202-78. إسبد. تخصيص. متطلبات المحتوى والتصميم.

غوست 19.301-78 إسبد. برنامج ومنهجية الاختبار. متطلبات المحتوى والتصميم.

غوست 19.401-78. إسبد. نص البرنامج. متطلبات المحتوى والتصميم.

غوست 19.402-78. إسبد. وصف البرنامج.

غوست 19.403-79. إسبد. قائمة أصحاب الأصلي.

غوست 19.404-79. إسبد. مذكرة توضيحية. متطلبات المحتوى والتصميم.

غوست 19.501-78. إسبد. استمارة. متطلبات الوصف والتصميم.

غوست 19.502-78. إسبد. وصف التطبيق. متطلبات الوصف والتصميم.

غوست 19.503-79. إسبد. دليل مبرمج النظام. متطلبات الوصف والتصميم.

غوست 19.504-79. إسبد. دليل المبرمج. متطلبات الوصف والتصميم.

غوست 19.505-79. إسبد. دليل المشغل. متطلبات الوصف والتصميم.

غوست 19.506-79. إسبد. وصف اللغة. متطلبات الوصف والتصميم.

غوست 19.507-79. إسبد. قائمة الوثائق التشغيلية.

غوست 19.508-79. إسبد. دليل الصيانة. متطلبات المحتوى والتصميم.

غوست 19.601-78. إسبد. القواعد العامة للنسخ والمحاسبة والتخزين.

غوست 19.602-78. إسبد. قواعد النسخ والمحاسبة وتخزين المستندات المطبوعة.

غوست 19.603-78. إسبد. القواعد العامة لإجراء التغييرات.

غوست 19.604-78. إسبد. قواعد إجراء التغييرات على المستندات المطبوعة.

سلسلة GOST 24. "النظام الموحد للمعايير لأنظمة التحكم الآلي (ESSASU)".

غوست 24.104-85. ايساسو. أنظمة التحكم الآلي. المتطلبات العامة.

غوست 24.301-80. نظام التوثيق الفني لأنظمة التحكم الآلي. المتطلبات العامة لتنفيذ المستندات النصية.

غوست 24.302-80. نظام التوثيق الفني لأنظمة التحكم الآلي. المتطلبات العامة لتنفيذ المخططات.

غوست 24.701-86. ايساسو. موثوقية أنظمة التحكم الآلي. الأحكام الأساسية.

غوست 24.702-85. كفاءة أنظمة التحكم الآلي. الأحكام الأساسية.

غوست 24.703-85. حلول التصميم النموذجية في أنظمة التحكم الآلي. الأحكام الأساسية.

بدلاً من GOST 24.601-86 و24.602-86، راجع GOST 34.601-90.

المعايير في مجال أمن المعلومات.

غوست ص 50922-96. حماية البيانات. المصطلحات والتعاريف الأساسية.

غوست ص 50934-96. حماية البيانات. تنظيم ومحتوى العمل لحماية المعلومات المتعلقة بالمعدات العسكرية من الاستخبارات الفنية. الأحكام العامة.

غوست ص 50739-95. مرافق الكمبيوتر. الحماية ضد الوصول غير المصرح به إلى المعلومات. المتطلبات الفنية العامة.

غوست ص 51188-98. حماية البيانات. برامج اختبار فيروسات الكمبيوتر. دليل النموذج.

غوست ص 51275-99. حماية البيانات. كائن المعلومات. العوامل المؤثرة على المعلومات. الأحكام العامة.

غوست ص 51241-98. أدوات وأنظمة التحكم في الوصول. تصنيف. المتطلبات الفنية العامة. طرق الاختبار.

غوست آر 51583-2000. حماية البيانات. الإجراء الخاص بإنشاء أنظمة آلية في تصميم آمن. المتطلبات العامة.

آيزو/آي إي سي 15408-99. معايير أمن تكنولوجيا المعلومات.

تصنيف وترميز المعلومات.

مواد التوحيد القياسي.

قواعد التقييس. الأحكام والإجراءات الأساسية لتنفيذ العمل على تطوير وصيانة وتطبيق المصنفات الروسية بالكامل. بي آر 50.1.024-2005. الوكالة الفيدرالية للتنظيم الفني والمقاييس. أمر رقم 311 بتاريخ 14 ديسمبر 2005.

غوست 34.601-90

المجموعة ص87

معيار الطريق السريع

تكنولوجيا المعلومات

مجموعة معايير للأنظمة الآلية

الأنظمة الآلية

مراحل الخلق

تكنولوجيا المعلومات. مجموعة معايير للأنظمة الآلية. الأنظمة الآلية. مراحل التنمية

مكس 35.080
أوكستو 0034

تاريخ التقديم 1992-01-01

بيانات المعلومات

1. تم تطويره وتقديمه من قبل لجنة الدولة في اتحاد الجمهوريات الاشتراكية السوفياتية لإدارة ومعايير جودة المنتج

2. تمت الموافقة عليها ودخلت حيز التنفيذ بموجب قرار اللجنة الحكومية لإدارة جودة المنتج ومعايير اتحاد الجمهوريات الاشتراكية السوفياتية بتاريخ 29 ديسمبر 1990 رقم 3469

3. بدلاً من ذلك GOST 24.601-86، GOST 24.602-86

4. الوثائق التنظيمية والفنية المرجعية

	رقم البند، التطبيق
غوست 19.101-77	المرفق 1
غوست 34.201-89	المرفق 1

6*. اعادة اصدار. يوليو 2009
________________
*الترقيم مطابق للأصل. - مذكرة الشركة المصنعة لقاعدة البيانات.


تنطبق هذه المواصفة القياسية على الأنظمة الآلية (AS) المستخدمة في أنواع مختلفة من الأنشطة (البحث والتصميم والإدارة وما إلى ذلك)، بما في ذلك مجموعاتها التي تم إنشاؤها في المنظمات والجمعيات والمؤسسات (المشار إليها فيما يلي باسم المنظمات).

يحدد المعيار مراحل ومراحل إنشاء AS.

ويبين الملحق 1 محتوى العمل في كل مرحلة.

1. أحكام عامة

1. أحكام عامة

1.1. إن عملية إنشاء AS هي مجموعة من الأعمال المطلوبة في الوقت المناسب، والمترابطة، والمدمجة في مراحل ومراحل، والتي يكون تنفيذها ضروريًا وكافيًا لإنشاء AS الذي يلبي المتطلبات المحددة.

1.2. تتميز مراحل ومراحل إنشاء AS بأنها أجزاء من عملية الإنشاء لأسباب تتعلق بالتخطيط العقلاني وتنظيم العمل الذي ينتهي بنتيجة معينة.

1.3. يتم العمل على تطوير AS وفقًا للمراحل والخطوات المستخدمة لإنشاء AS.

1.4. يتم تحديد تكوين وقواعد أداء العمل في المراحل والمراحل التي يحددها هذا المعيار في الوثائق ذات الصلة للمنظمات المشاركة في إنشاء أنواع معينة من محطات الطاقة النووية.

ترد قائمة المنظمات المشاركة في إنشاء محطات الطاقة النووية في الملحق 2.

2. مراحل ومراحل إنشاء AS

2.1. يتم عرض مراحل ومراحل إنشاء AS بشكل عام في الجدول.

	مراحل العمل
1. تشكيل المتطلبات للمتحدثين	1.1. التفتيش على المنشأة وتبرير الحاجة إلى إنشاء محطة للطاقة النووية
	1.2. تشكيل متطلبات المستخدم للمتحدثين
	1.3. إعداد تقرير عن العمل المنجز وطلب تطوير AS (المواصفات التكتيكية والفنية)
2. تطوير مفهوم التكييف	2.1. دراسة الكائن
	2.2. القيام بالأعمال البحثية اللازمة
	2.3. تطوير خيارات مفهوم التيار المتردد واختيار خيار مفهوم التيار المتردد الذي يلبي متطلبات المستخدم
	2.4. إعداد تقرير عن العمل المنجز
3. الاختصاصات	3.1. وضع واعتماد المواصفات الفنية لإنشاء محطات الطاقة النووية
4. مشروع التصميم	4.1. تطوير حلول التصميم الأولية للنظام وأجزائه
	4.2. تطوير التوثيق لنظام السماعات وأجزائه
5. التصميم الفني	5.1. تطوير الحلول التصميمية للنظام وأجزائه
	5.2. تطوير التوثيق لنظام السماعات وأجزائه
	5.3. تطوير وتنفيذ الوثائق الخاصة بتوريد المنتجات لاستكمال محطة الطاقة النووية و (أو) المتطلبات الفنية (المواصفات الفنية) لتطويرها
	5.4. تطوير مهام التصميم في الأجزاء المجاورة لمشروع مرفق الأتمتة
6. وثائق العمل	6.1. تطوير وثائق العمل للنظام وأجزائه
	6.2. تطوير أو تكييف البرامج
7. التكليف	7.1. إعداد كائن الأتمتة لتشغيل NPP
	7.2. مدرب شخصي
	7.3. مجموعة كاملة من مكبرات الصوت المتوفرة مع المنتجات (البرامج والأجهزة، ومجمعات البرامج والأجهزة، ومنتجات المعلومات)
	7.4. أعمال البناء والتركيب
	7.5. أعمال التكليف
	7.6. إجراء الاختبارات الأولية
	7.7. إجراء العملية التجريبية
	7.8. إجراء اختبارات القبول
8. دعم التيار المتردد	8.1. تنفيذ العمل وفقا لالتزامات الضمان
	8.2. خدمة ما بعد الضمان

2.2. يتم تحديد المراحل والمراحل التي تقوم بها المنظمات المشاركة في إنشاء محطات الطاقة النووية في العقود والمواصفات الفنية بناءً على هذا المعيار.

يُسمح باستبعاد مرحلة "التصميم التخطيطي" ومراحل العمل الفردية في جميع المراحل، ودمج مرحلتي "التصميم الفني" و"توثيق العمل" في مرحلة واحدة "التصميم الفني التفصيلي". اعتمادًا على تفاصيل AS التي تم إنشاؤها وشروط إنشائها، يُسمح بتنفيذ مراحل فردية من العمل قبل الانتهاء من المراحل السابقة، أو التنفيذ الموازي لمراحل العمل، أو إدراج مراحل عمل جديدة.

الملحق 1 (للرجوع إليها). محتوى العمل

المرفق 1
معلومة

1. في المرحلة 1.1 "تفتيش المنشأة وتبرير الحاجة إلى إنشاء محطة طاقة نووية"، في الحالة العامة، يتم تنفيذ ما يلي:

- جمع البيانات حول كائن الأتمتة وأنواع الأنشطة المنفذة؛

- تقييم جودة عمل المنشأة وأنواع الأنشطة المنفذة، وتحديد المشاكل التي يمكن حلها عن طريق الأتمتة؛

- التقييم (الفني والاقتصادي والاجتماعي وما إلى ذلك) لجدوى إنشاء محطة طاقة نووية.

2. في المرحلة 1.2 "تشكيل متطلبات المستخدم للمتحدثين" يتم تنفيذ ما يلي:

- إعداد البيانات الأولية لتشكيل متطلبات النظام الآلي (خصائص كائن الأتمتة، وصف متطلبات النظام، والقيود على التكاليف المقبولة للتطوير والتشغيل والتشغيل، والتأثير المتوقع من النظام، وشروط التشغيل) إنشاء وتشغيل النظام)؛

- صياغة وتنفيذ متطلبات المستخدم للمتحدثين.

3. في المرحلة 1.3 "استكمال تقرير عن العمل المنجز وطلب تطوير AS (المواصفات التكتيكية والفنية)"، تقرير عن العمل المنجز في هذه المرحلة وطلب تطوير AS (تكتيكي) والمواصفات الفنية) أو مستند آخر يحل محله مكتمل بمحتوى مماثل.

4. في المرحلتين 2.1 "دراسة الكائن" و2.2 "تنفيذ الأعمال البحثية اللازمة"، تجري منظمة التطوير دراسة تفصيلية لكائن الأتمتة والأعمال البحثية اللازمة (R&D) المتعلقة بإيجاد الطرق وتقييم إمكانية تنفيذ متطلبات المستخدم وإعداد التقارير البحثية والموافقة عليها.

5. في المرحلة 2.3 "تطوير خيارات لمفهوم AS واختيار خيار لمفهوم AS الذي يلبي متطلبات المستخدم"، في الحالة العامة، تكون الخيارات البديلة لمفهوم AS الذي يتم إنشاؤه وخطط تنفيذها هي متطور؛ تقييم الموارد اللازمة لتنفيذها وصيانتها؛ تقييم مزايا وعيوب كل خيار؛ مقارنة متطلبات المستخدم وخصائص النظام المقترح واختيار الخيار الأمثل؛ تحديد إجراءات تقييم الجودة وشروط قبول النظام؛ تقييم الآثار التي تم الحصول عليها من النظام.

6. في المرحلة 2.4 "إعداد تقرير عن العمل المنجز"، قم بإعداد وإعداد تقرير يحتوي على وصف للعمل المنجز في المرحلة، ووصف وتبرير للنسخة المقترحة لمفهوم النظام.

7. في المرحلة 3.1 "وضع واعتماد المواصفات الفنية لإنشاء محطة للطاقة النووية"، تطوير وتنفيذ وتنسيق واعتماد المواصفات الفنية لمحطة الطاقة النووية، وإذا لزم الأمر، المواصفات الفنية لأجزاء من المحطة النووية يتم تنفيذ محطة توليد الكهرباء.

8. في المرحلة 4.1 "تطوير حلول التصميم الأولية للنظام وأجزائه" يتم تحديد ما يلي: وظائف AS؛ وظائف النظم الفرعية وأهدافها وآثارها؛ تكوين مجمعات المهام والمهام الفردية؛ مفاهيم قاعدة المعلومات، وهيكلها الموسع؛ وظائف نظام إدارة قاعدة البيانات؛ تكوين نظام الكمبيوتر. وظائف ومعلمات البرامج الأساسية.

9. في المرحلة 5.1 "تطوير حلول التصميم للنظام وأجزائه"، يتم التأكد من تطوير الحلول العامة للنظام وأجزائه، والهيكل الوظيفي الخوارزمي للنظام، ووظائف الموظفين والهيكل التنظيمي، هيكل الوسائل التقنية، وخوارزميات حل المشكلات، واللغات المستخدمة، وتنظيم وصيانة قاعدة المعلومات، ونظام تصنيف المعلومات وترميزها، على البرامج.

10. في المرحلتين 4.2 و5.2 "تطوير الوثائق الخاصة بمحطة الطاقة النووية وأجزائها"، يتم تطوير وتنفيذ وتنسيق والموافقة على الوثائق بالقدر اللازم لوصف المجموعة الكاملة لقرارات التصميم المتخذة والكافية للمستقبل. تنفيذ العمل على إنشاء NPP. أنواع المستندات - وفقًا لـ GOST 34.201.

11. في المرحلة 5.3 "تطوير وتنفيذ الوثائق الخاصة بتوريد المنتجات لاستكمال محطات الطاقة النووية و (أو) المتطلبات الفنية (المواصفات الفنية) لتطويرها" يتم تنفيذ ما يلي: إعداد وتنفيذ الوثائق الخاصة بتوريد المنتجات لـ واستكمال محطات الطاقة النووية؛ تحديد المتطلبات الفنية ووضع المواصفات الفنية لتطوير المنتجات التي لا يتم إنتاجها بكميات كبيرة.

12. في المرحلة 5.4 "تطوير مهام التصميم في الأجزاء المجاورة لمشروع مرفق الأتمتة"، يتم تنفيذ تطوير وتنفيذ وتنسيق والموافقة على مهام التصميم في الأجزاء المجاورة من مشروع مرفق الأتمتة لتنفيذ أعمال البناء والكهرباء والصرف الصحي والأعمال التحضيرية الأخرى المتعلقة بإنشاء AS.

13. في المرحلة 6.1 "تطوير وثائق العمل للنظام وأجزائه"، يتم تطوير وثائق العمل التي تحتوي على جميع المعلومات الضرورية والكافية لضمان تنفيذ العمل على تشغيل محطة الطاقة النووية وتشغيلها، وكذلك الحفاظ على مستوى الخصائص التشغيلية (الجودة) للنظام وفقًا لقرارات التصميم المعتمدة وتنفيذها وتنسيقها واعتمادها. أنواع المستندات - وفقًا لـ GOST 34.201.

14. في المرحلة 6.2 "تطوير البرامج أو تكييفها"، يتم تطوير برامج وبرامج النظام واختيار وتكييف و (أو) ربط البرامج المشتراة وتطوير وثائق البرنامج وفقًا لـ GOST 19.101.

15. في المرحلة 7.1 "إعداد كائن الأتمتة لتشغيل المصنع"، يتم العمل على الإعداد التنظيمي لكائن الأتمتة لتشغيل المصنع، بما في ذلك: تنفيذ حلول التصميم للهيكل التنظيمي للمصنع نبات؛ تزويد أقسام المنشأة الإدارية بالمواد التعليمية والمنهجية؛ تنفيذ مصنفات المعلومات.

16. في المرحلة 7.2 "تدريب الموظفين"، يتم تدريب الموظفين وفحص قدرتهم على ضمان عمل المحطة.

17. في مرحلة "استكمال السماعات بالمنتجات الموردة"، يضمنون استلام مكونات الإنتاج والمواد ومنتجات التثبيت التسلسلية والفردية. يتم تنفيذ مراقبة الجودة الواردة.

18. في المرحلة 7.4 "أعمال البناء والتركيب" يتم تنفيذ ما يلي: العمل على تشييد المباني المتخصصة (المباني) لاستيعاب المعدات الفنية وموظفي الطاقة النووية؛ بناء قنوات الكابل. القيام بالعمل على تركيب المعدات التقنية وخطوط الاتصال؛ اختبار المعدات التقنية المثبتة؛ تسليم المعدات التقنية للتشغيل.

19. في المرحلة 7.5 "التشغيل"، يقومون بإجراء تعديل مستقل للأجهزة والبرامج، وتحميل المعلومات في قاعدة البيانات والتحقق من النظام لصيانتها؛ الإعداد الشامل لجميع أدوات النظام.

20. في المرحلة 7.6 "إجراء الاختبارات الأولية" يتم تنفيذ ما يلي:

- اختبارات AS للتشغيل والامتثال للمواصفات الفنية وفقا لبرنامج ومنهجية الاختبارات الأولية؛

- استكشاف الأخطاء وإصلاحها وإجراء تغييرات على وثائق محطة الطاقة النووية، بما في ذلك الوثائق التشغيلية وفقًا لتقرير الاختبار؛

- إعداد شهادة قبول محطة الطاقة النووية للتشغيل التجريبي.

21. في المرحلة 7.7 "إجراء التشغيل التجريبي"، يتم تنفيذ ما يلي: التشغيل التجريبي لمحطة الطاقة النووية؛ تحليل نتائج التشغيل التجريبي لمحطة الطاقة النووية؛ تعديل (إذا لزم الأمر) لبرنامج AS؛ تعديل إضافي (إذا لزم الأمر) للمعدات التقنية لمحطات الطاقة النووية؛ تنفيذ شهادة إتمام التشغيل التجريبي.

22. في المرحلة 7.8 "إجراء اختبارات القبول" يتم تنفيذ ما يلي:

اختبارات الالتزام بالمواصفات الفنية وفق برنامج ومنهجية اختبارات القبول؛

- تحليل نتائج اختبار NPP والقضاء على أوجه القصور التي تم تحديدها أثناء الاختبار؛

- تنفيذ قانون قبول محطة الطاقة النووية للتشغيل الدائم.

23. في المرحلة 8.1 "أداء العمل وفقًا لالتزامات الضمان"، يتم تنفيذ العمل لإزالة أوجه القصور التي تم تحديدها أثناء تشغيل محطة الطاقة النووية خلال فترات الضمان المحددة، وإجراء التغييرات اللازمة على وثائق محطة الطاقة النووية.

24. في المرحلة 8.2 يتم تنفيذ العمل "خدمة ما بعد الضمان" على:

- تحليل أداء النظام؛

- تحديد انحرافات الخصائص التشغيلية الفعلية لمحطة الطاقة النووية عن القيم التصميمية؛

- تحديد أسباب هذه الانحرافات؛

- القضاء على أوجه القصور التي تم تحديدها وضمان استقرار الخصائص التشغيلية لمحطة الطاقة النووية؛

- إجراء التغييرات اللازمة على الوثائق الخاصة بالمتحدثين.

الملحق 2 (للرجوع إليها). قائمة المنظمات المشاركة في إنشاء الاتحاد الأفريقي

الملحق 2
معلومة

1. منظمة العملاء (المستخدم) التي تم إنشاء محطة الطاقة النووية من أجلها والتي توفر التمويل وقبول العمل وتشغيل محطة الطاقة النووية، فضلاً عن تنفيذ العمل الفردي بشأن إنشاء محطة الطاقة النووية؛

2. منظمة تطويرية تقوم بأعمال إنشاء نظام AS، حيث تقدم للعميل مجموعة من الخدمات العلمية والتقنية في مراحل ومراحل الإنشاء المختلفة، بالإضافة إلى تطوير وتوريد البرامج والأجهزة المختلفة لنظام AS؛

3. منظمة موردة تقوم بتصنيع وتوريد البرامج والأجهزة لطلب المطور أو العميل؛

4. المصمم العام للمنظمة لمرفق التشغيل الآلي.

5. المنظمات - المصممون لأجزاء مختلفة من مشروع منشأة الأتمتة لتنفيذ الأعمال الإنشائية والكهربائية والصحية وغيرها من الأعمال التحضيرية المتعلقة بإنشاء محطة الطاقة النووية؛

6. البناء والتركيب والتكليف وغيرها من المنظمات.

ملحوظات:

1. اعتمادًا على شروط إنشاء NPP، من الممكن وجود مجموعات مختلفة من وظائف العميل والمطور والمورد والمنظمات الأخرى المشاركة في إنشاء NPP.

2. يتم تحديد مراحل ومراحل العمل الذي يقومون به لإنشاء المحطة النووية على أساس هذا المعيار.

نص الوثيقة الإلكترونية
تم إعداده بواسطة Kodeks JSC وتم التحقق منه مقابل:
النشر الرسمي
م: ستاندارتينفورم، 2009

لماذا، من حيث المبدأ، هناك حاجة إليها عند التصميم؟

اتضح أن GOSTs تساعد المصمم نفسه.

المشكلة الرئيسية في التصميم هي عدم وجود التصميم نفسه. هناك قصاصات معينة من الأفكار والرغبات، ولكن دون تشكيلها في نوع من الصورة الشاملة. يعد هذا أمرًا نموذجيًا لكل من مسؤولي النظام المبتدئين ومهندسي النظام المبتدئين. هناك عفوية معينة في التفكير. بالمناسبة، هذا أيضًا نموذجي للعديد من العملاء. لكنهم في وضع أكثر فائدة قليلاً من فناني الأداء.

يطرح سؤال مثير للاهتمام: من يحتاج إلى كل هذه الملاحظات التوضيحية والمواصفات الفنية وما إلى ذلك؟ وهنا إجابة مثيرة للاهتمام حصلنا عليها: 85% من الوثائق ضرورية للمؤدي. يحتاج العميل إلى نسبة 15٪ المتبقية للحصول على فهم عام لما يحدث. ولكن يجب على المقاول أن يحدد بوضوح حدود المشروع وعلامات تنفيذه. يجب أن يكون المقاول قادرًا على حماية نفسه من التفكير الفوضوي للعميل.

لذلك، دعونا ننتقل إلى معايير GOST للمطور. لدينا نوعان رئيسيان: سلسلة GOST 34 وسلسلة GOST 19. تتعلق السلسلة الرابعة والثلاثون بتطوير الأنظمة الآلية، بينما تتعلق السلسلة التاسعة عشرة بتطوير البرمجيات.
سنتحدث عن سلسلة GOST 34.

هناك العديد من GOSTs المختلفة في السلسلة 34. سنكون مهتمين فقط بعدد قليل منهم. يسمى:

1. غوست 34.003-90 تكنولوجيا المعلومات. مجموعة معايير للأنظمة الآلية. المصطلحات والتعاريف
2. GOST 34.601-90 تكنولوجيا المعلومات. مجموعة معايير للأنظمة الآلية. الأنظمة الآلية. مراحل الخلق
3. GOST 34.602-89 تكنولوجيا المعلومات. مجموعة معايير للأنظمة الآلية. الشروط المرجعية لإنشاء نظام آلي
4. GOST 34.603-92 تكنولوجيا المعلومات. أنواع اختبارات الأنظمة الآلية
5. GOST 34.201-89 تكنولوجيا المعلومات. مجموعة معايير للأنظمة الآلية. أنواع واكتمال وتعيين الوثائق عند إنشاء الأنظمة الآلية
6. RD 50-34.698-90 الأنظمة الآلية. متطلبات محتوى الوثائق.

تتشابه GOSTs إلى حد ما في بنيتها الهرمية مع الكتالوج. مثل، على سبيل المثال، Active Directory. من المحتمل أنه إذا كتبت الوثائق وفقًا لمعايير GOST بدقة، فستسمح لك الإحالات التبادلية بالتعرف على عدد كبير من المستندات. ولكن الأهم في GOSTs هو النموذج الواضح "من العام إلى الخاص". بدءًا من العبارات العامة، سنصل إلى آخر RJ45 في النظام.

والآن بمزيد من التفاصيل. GOST الرئيسي، الذي يوجد حوله ما يسمى. الرقص هو GOST 34.601-90 (مراحل الخلق). دعونا نلقي نظرة فاحصة على هذه الوثيقة.

هذا هو الهيكل الذي يستقبلنا في هذه الوثيقة. ما هو الشيء العظيم في هذا؟ والشيء الرائع في هذا هو أننا نرى تقريبًا دورة الحياة الكاملة للنظام الآلي. لماذا تقريبا؟ لأنه لا توجد مرحلة مثل وقف التشغيل والتخلص. لكننا لسنا بحاجة لهذا حقًا. في الوقت الحالي، المراحل الحالية أكثر من كافية. علاوة على ذلك، فإن مرحلة إعادة التدوير تعتبر في أحد معايير الدولة الأخرى، لكن هذا خارج نطاق هذه المقالة.

كما قلت أعلاه، تحتوي GOSTs على إحالات مرجعية. وللمضي قدمًا في تفكيرنا، سنلقي نظرة سريعة على GOST 34.003-90 (المصطلحات والتعريفات). وهو مهتم بتعريف النظام الآلي. وهذا مهم لأنه ما زلنا بحاجة إلى الحصول على فكرة عما سنقوم بإنشائه.

يخبرنا GOST 34.003-90 في تعريف النظام الآلي بما يلي: النظام الآلي؛ AS: نظام يتكون من الموظفين ومجموعة من أدوات التشغيل الآلي لأنشطتهم، ويطبق تكنولوجيا المعلومات لأداء الوظائف المقررة. أولئك. بمعنى آخر، يتكون مكيف الهواء من

1. الموظفين
2. مجمع الأموال
3. أن تكون بعض الأنشطة آلية.

سوف نتحقق أيضًا من GOST 34.003-90

1. مجموعة من أدوات التشغيل الآلي للنظام الآلي. KSA AS: مجمل جميع مكونات AS، باستثناء الأشخاص
2. مستخدم النظام الآلي. مستخدم جهاز تكييف الهواء: الشخص الذي يشارك في عمل جهاز تكييف الهواء أو يستخدم نتائج عمله
3. العاملون في تشغيل النظام الآلي. موظفو تشغيل محطة الطاقة النووية
4. مكون النظام الآلي. المكون AC: جزء من التيار المتردد، يتم تحديده بخاصية معينة أو مجموعة من الخصائص ويعتبر ككل

إذن ماذا نحصل؟ لكن اتضح أننا شعرنا ببعض الأساس تحت أقدامنا والذي سنعتمد عليه. نحن نعرف مما يتكون النظام الآلي وأوضحنا أن هناك نوعين من الموظفين: المستخدم والتشغيلي. ونحن نستنتج منطقيا أن المكون AC، الذي تم اختياره وفقا لخاصية معينة، سيكون t.s. "الأجهزة" و"البرمجيات"، بكل بساطة. وسيكون الجمع بين البرامج والأجهزة عبارة عن مجموعة من معدات التشغيل الآلي.

وهذا يعني أنه إذا قال العميل، على سبيل المثال، "قم بتثبيت Exchange بالنسبة لي"، فلن يكون هذا AS بمثابة AS لسبب واحد بسيط: على الأقل في مثل هذه المهمة لا يوجد أي نوع من النشاط الآلي. أو ربما لا يحتاج العميل إلى Exchange على الإطلاق. أو ربما لا يحتاج إلى Exchange على الإطلاق. وهذا يعني أن فحص كائن الأتمتة مطلوب. وهذا يعني أن المرحلة الأولى من GOST 34.601-90 تبدأ (مراحل الإنشاء). "تشكيل متطلبات المتحدثين"

في هذه المرحلة، يطلب منا GOST إكمال عدة خطوات. إذا ترجمنا هذا إلى لغة بشرية، فيجب علينا تحديد ما إذا كان من الضروري تطوير أي شيء على الإطلاق. هل من المستحسن من وجهات نظر مختلفة. بشكل عام، تقييم الحاجة لبدء العمل. نتيجة العمل في هذه المرحلة هي تقرير يسجل النتيجة.

بمجرد أن نقرر مع العميل أن هناك أسبابًا كافية للتطوير، يمكننا الانتقال إلى المرحلة التالية، “تطوير مفهوم مكيف الهواء”.

في المفهوم، نحن بحاجة إلى دراسة الكائن الذي يتطلب التنفيذ. إذا كنا نبحث في المرحلة الأولى عن سبب إنشاء نظام السماعات بشكل عام (استنادًا إلى أهداف العمل فقط، فقد تمت كتابة GOST ببساطة عندما لم يتم استخدام هذه الكلمات)، ثم في المرحلة الثانية نحتاج إلى العثور على الخيارات الممكنة التي تلبي متطلبات العميل. على سبيل المثال، إذا كان العميل يريد نظام بريد، فيمكن تنفيذ ذلك على Exchange أو Postfix أو أي شيء آخر. مع إيجابياته وسلبياته وخيارات التطوير. يتم إجراء فحص عام للمنشأة ويتم تقدير تكاليف العمالة بشكل مبدئي. نحن، كفناني الأداء، نبحث أيضًا عن الخيار الأمثل لأنفسنا.
بعد أن نتوصل إلى إجماع معين مع العميل حول خيار الحل الذي يناسبه أكثر بشكل عام، ننتقل إلى النقطة الأهم في المشروع “المواصفات الفنية” وأجرؤ على قولها.

المواصفات الفنية، إذا نظرت إلى تعريف GOST 34.602-89، هي الوثيقة الرئيسية التي تحدد متطلبات وإجراءات إنشاء (تطوير أو تحديث - ثم إنشاء) نظام آلي، وفقًا لذلك يتم تطوير AS يتم تنفيذها وقبولها عند التكليف.

تعد المواصفات الفنية وثيقة مهمة حيث يتم تخصيص GOST شخصي لها. الآن لن نتناول هذا بالتفصيل. سأشير فقط إلى أنه من أجل التكوين الصحيح للمواصفات الفنية، من الضروري إكمال مراحل GOST 34.601-90 "تشكيل متطلبات الطاقة النووية" و"تطوير مفهوم الطاقة النووية". تعتمد دقة وصحة إنشاء المواصفات الفنية على جودة تنفيذ هذه المراحل.

اترك تعليقك!