تطوير المواصفات الفنية وفقًا لـ GOST 34 بسيط وسهل

غالبًا ما تسمع رأيًا مفاده أن إعداد الشروط المرجعية وفقًا لـ GOST 34 (TK) ليس شاقًا فحسب ، بل مزعج للغاية ، لأنك يجب أن تكتب الكثير من جميع أنواع الهراء والماء. لكن فكر في الأمر: لقد شاركت معاهد بحث بأكملها في تطوير GOST ، وكان مشروعًا على مستوى الولاية ، وتجربة مئات من مشاريع الأتمتة ، وتم تلخيص مشاريع معقدة. هل يمكن أن يكتبوا حقا هراء؟

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

في هذه المقالة ، سنقوم بتحليل جميع متطلبات GOST خطوة بخطوة ونحاول جعل تطوير المعارف التقليدية وفقًا لـ GOST 34 ليس عبئًا ، ولكن مساعدة كبيرة في المشروع.

1. ما هو المقال حول؟

غالبًا ما تسمع رأيًا مفاده أن إعداد الشروط المرجعية وفقًا لـ GOST 34 (TK) ليس شاقًا فحسب ، بل مزعج للغاية ، لأنه يتعين عليك كتابة الكثير من جميع أنواع الهراء والماء. لكن فكر في الأمر: لقد شاركت معاهد بحث بأكملها في تطوير GOST ، وكان مشروعًا على مستوى الولاية ، وتجربة مئات من مشاريع الأتمتة ، وتم تعميم المشروعات المعقدة. هل يمكن أن يكتبوا حقا هراء؟

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

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

تنبيه: الغرض من هذه المقالة ليس استبدال GOST ، وتوضيح بعض أحكامها.

2. الخصائص المميزة للمواصفات الفنية وفقًا لـ GOST 34

2.1. بأي معيار يتم تجميع ToR؟

الاسم الكامل لمعيار TK وفقًا لـ GOST 34 هو كما يلي: GOST 34.602-89 "تكنولوجيا المعلومات (IT). مجموعة من المعايير للأنظمة الآلية. الشروط المرجعية لإنشاء نظام آلي. "

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

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

2.2. لماذا تحتاج إلى GOST للصلاحيات؟

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

2.3. ما هو الدور الذي تلعبه الاختصاصات في المشروع؟

وفقًا للفقرة 1.7 من المعيار RD 50-682-89 ، "تعد الاختصاصات هي الوثيقة الرئيسية التي يتم بموجبها إنشاء الاتحاد الأفريقي وقبول العميل." وهذا هو حقا المستند الرئيسي. يجب أن تصف كل ما هو ضروري لتطوير وتنفيذ النظام.

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

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

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

2.4. كم يبلغ عمر GOST 34.602-89 وهل هناك معايير أحدث؟

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

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

• IEEE 830-1998. منهجية تجميع المواصفات لمتطلبات البرامج.
• GOST R ISO / IEC 12207-2010. تكنولوجيا المعلومات. هندسة النظم والبرمجيات. عمليات دورة حياة البرنامج.
• ISO / IEC / IEEE 29148-2011. هندسة النظم والبرامج - عمليات دورة الحياة - هندسة المتطلبات.
• GOST R 54869-2011. إدارة المشاريع. متطلبات إدارة المشروع.
• حسنا والدولة المواصفات القياسية 34 سلسلة.

3. المبادئ العامة لإعداد المواصفات الفنية وفقًا لـ GOST 34

3.1. أي متخصص يجب أن يضع الشروط المرجعية وفقًا لـ GOST 34؟

في كثير من الأحيان ، أقسم المطورون كثيرًا عند صياغة المعارف التقليدية وفقًا لـ GOST 34. لماذا؟ نعم ، لأنها ليست من عمل المبرمجين. لا يمكن بشكل عام إظهار الاختصاصات وفقًا لـ GOST 34 للمبرمجين. هناك وثائق المشروع الفني لهذا الغرض. الشروط المرجعية - وثيقة يتم الاتفاق عليها مع العميل ، والتي يتم عرضها باستمرار على طاولة مدير المشروع. يجيب TK عن سؤالين: ما الذي يجب أن يفعله النظام وكيف يجب إنشاؤه. يجيب المشروع الفني على السؤال التالي: كيف ينبغي تلبية متطلبات الشروط المرجعية. على سبيل المثال ، في المعارف التقليدية ، تنص على أنه يجب أن يكون هناك تفويض من خلال تسجيل الدخول وكلمة المرور ، وفي TP تعطي تخطيطات للواجهة والنصوص وبنية قاعدة البيانات. لماذا يوجد تقسيم إلى مراحل مختلفة ولماذا لا يجب عليك القيام بالمهمة على الفور للمبرمجين ، انظر في مقالاتي " أسرار التصميم الناجح للملكية الفكرية (نظام المعلومات)" على سبيل المثال لبناء مستشفى ومسح ما قبل التصميم عند تطوير نظام معلومات .

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

3.2. أي جانب يجب أن يكون الاختصاصات؟

أساسا ، يتم تجميع الشروط المرجعية من قبل المقاول؟ لماذا؟

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

3.3. إلى أي مدى يمكنك الذهاب من GOST 34؟

أي قالب لديه أيضا عيب كبير - وهذا هو القالب. أي أن الخطوة نحو اليمين واليسار هي أعلى مقياس للحماية الاجتماعية (كما كانت تسمى عقوبة الإعدام من قبل).

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

لا تصدق؟ ثم اقرأ الفقرة 2.2 من GOST 34.602-89 (بالمناسبة ، الأرقام بعد الواصلة هي سنة نشر المعيار أو نسخته): "اعتمادًا على النوع والغرض والميزات المحددة لكائن التشغيل الآلي وشروط تشغيل النظام ، يُسمح بوضع أقسام من المعارف التقليدية في شكل تطبيقات ، وإدخال إضافية ، استبعاد أو دمج الأقسام الفرعية للمعارف التقليدية. " أيضا في الفقرة 1.2. ينص RD 34.698-90: "إن محتوى المستندات شائع في جميع أنواع AS ، وإذا لزم الأمر ، يمكن أن يستكمل من قبل مطور الوثائق اعتمادًا على ميزات AS التي تم إنشاؤها. يُسمح بتضمين أقسام ومعلومات إضافية في المستندات ، للجمع بين الأقسام واستبعادها. "

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

3.4. لماذا تصف المعارف التقليدية وفقًا لـ GOST 34 العديد من المتطلبات التي لا ترتبط مباشرة بوظائف النظام؟

في الواقع ، في TOR من 30 صفحة ، يمكن تخصيص 7-10 صفحات فقط لوظائف. هذا له تفسير. الحقيقة هي أن مطوري GOST 34 نظروا إلى مشروع الأتمتة بطريقة مختلفة تمامًا عما فعلنا. وظهروا بشكل صحيح ، وأكثر شمولاً.

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

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

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

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

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

3.5. لماذا الأقسام المختلفة تقول نفس الشيء؟

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

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

3.6. هل أحتاج إلى إصدار المعارف التقليدية بطريقة جيدة؟

على الرغم من أن متطلبات تصميم المعارف التقليدية ترد في الفقرة 3 من GOST 34.602-89 ، دعنا نقول بضع كلمات حول هذا الجانب.

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

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

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

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

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

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

لاحظ أنه وفقًا لقواعد صارمة ، يتم وضع بيان العمل بدون إطار (وهذا مذكور في الفقرة 3) ، لكن بقية الوثائق مؤطرة. تم تأسيس هذا في GOST 24.301-80 "نظام التوثيق الفني لـ ACS. المتطلبات العامة لتنفيذ الوثائق النصية (بصيغتها المعدلة رقم 1 ، 2). " تحدد هذه المواصفة القياسية قواعد تنفيذ جميع المستندات باستثناء المعارف التقليدية والمستندات التي تم إنشاؤها في مراحل ما قبل التصميم. على الرغم من أنني شخصيا لا أحب الإطار في أي وثائق.

4. القسم 1. "معلومات عامة" / ص. 2.3 GOST 34.602-89 /

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

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

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

5. القسم 2. "غرض وأهداف إنشاء (تطوير) النظام" / ع. 2.4 GOST 34.602-89 /

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

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

مع الهدف ، كل شيء مختلف. الهدف هو ما نخطط لمشروع. يمكنك أن تسميها أهداف العمل. أبرز الأهداف المحتملة التالية لمشاريع الأتمتة:

1. ( , ..)
2. (, -, , ).
3. ( , , ).
4. : , .
5. , . , , «», .

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

6. القسم 3. "خصائص كائن التشغيل الآلي" / ص. 2.5 GOST 34.602-89 /

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

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

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

يجب أن يشمل هذا القسم:

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

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

7. القسم 4 "متطلبات النظام"

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

• متطلبات النظام ككل.
• متطلبات الوظائف (المهام) التي يؤديها النظام.
• متطلبات أنواع الضمان.

سننظر في هذه الأقسام الفرعية بشكل منفصل.

7.1. القسم الفرعي 4.1. "متطلبات النظام ككل" / ص. 2.6.1 GOST 34.602-89 /

في القسم الفرعي 4.1 "متطلبات النظام ككل" ، يتم وصف المتطلبات العامة غير الوظيفية التي تصف النظام الذي يتم إنشاؤه من زوايا مختلفة.

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

7.1.1. البند 4.1.1. "متطلبات هيكل وأداء النظام" / ع. 2.6.1.1 GOST 34.602-89 /

هذا البند واسع للغاية ، ينبغي أن يعطي فكرة عامة عن بنية النظام. سنقوم بتحليل هذه المتطلبات بمزيد من التفصيل.

1. قائمة الأنظمة الفرعية ، غرضها وخصائصها الرئيسية ، متطلبات عدد مستويات التسلسل الهرمي ودرجة مركزية النظام.

في هذه الفقرة ، أقتبس عادة:

• ( , , , -, , , ) , ( , SMTP, SMS-, -, -, , , ..);
• .

إذا كنت تخطط لهندسة الخدمات المصغرة ، فمن المنطقي أن تسرد وتصف وظيفة الخدمات.

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



... أو نحو ذلك:



2. متطلبات طرق الاتصال ووسائل لتبادل المعلومات بين مكونات النظام.

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

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

• قائمة بالمعلومات المرسلة ، على الأقل وصف عام ، لفهم سبب دمجنا مع نظام معين ؛
• وصف البروتوكول (أو روابط الوصف) ، خاصة في حالة مرفق الجهاز ؛
• هيكل الشبكة المحلية ؛
• معدل البيانات المطلوبة ؛
• استخدام الإنترنت المحمول أو WiFi ؛
• وصف طرق نقل البيانات غير الآلية.

4. متطلبات أوضاع تشغيل النظام.
يمكن أن تحتوي أساليب التشغيل على العديد من التصنيفات:

• : , , (, , , API, );
• : , , , ;
• : 24/7 ( );
• : ;
• : , , ( );
• : -, , (, , );
• : ( ), , (, , , );
• : , « »;
• رؤية التطبيق: الحوار أو الخلفية
• على التأثير المحتمل على النظام: أنماط التدريب ، التدريب ، العادية.

5. متطلبات تشخيص النظام.

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

6. آفاق تطوير وتحديث النظام.

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

أو الآن أنت تعمل من مؤسسة واحدة ، وخلال ستة أشهر سيكون هناك العديد منها ، مما يعني أنه من الضروري التنبؤ بإمكانية التوسع مسبقًا.

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

7.1.2. البند 4.1.2. "متطلبات عدد ومؤهلات الموظفين" / ص. 2.6.1.2 GOST 34.602-89 /

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

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

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

7.1.3. البند 4.1.3. "متطلبات مؤشرات الأداء" / p. 2.6.1.3 GOST 34.602-89 /

في هذا القسم الفرعي ، غالبًا ما يكتب ما تريد ، لأن قائمة المؤشرات المحتملة مفقودة في نص GOST ، ويكاد يكون من المستحيل العثور عليها في المصادر المفتوحة. يرجى ملاحظة أن "درجة القدرة على التكيف" و "حدود التحديث" و "خصائص وقت الاحتمال" الواردة في GOST ، يتم الإشارة إليها أولاً ، بالنسبة لـ ACS (نظام التحكم الآلي) ، وثانياً ، يصعب قياسها. وبالتالي ، هذه الخصائص ليست دائما مناسبة.

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

تشمل مؤشرات الوجهة:

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

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

7.1.4. البند 4.1.4. "متطلبات الموثوقية" / ص. 2.6.1.4 GOST 34.602-89 /

يصف نص GOST بتفاصيل كافية ما يجب الإشارة إليه في متطلبات الموثوقية. ومع ذلك ، لفهم الطريقة التي تضمن الموثوقية الكامنة في هذا المعيار ، يجب عليك دراسة GOST من سلسلة 27. في البداية ، يجب أن تتعرف على المصطلحات: هذا سيكون كافياً لفهم مفهوم الموثوقية نفسه ، وكيف يتم قياسه وكيف يتم توفيره. لذلك ، يرجى الرجوع إلى GOST 27.002-89. الموثوقية في التكنولوجيا. المفاهيم الأساسية. المصطلحات والتعاريف. "

المفهوم الأساسي الذي يمكن تطبيقه على الأنظمة الآلية هو عامل التوافر: 99 ٪ ، 99.9 ٪ ، 99.99 ٪. يتم توفير كل عدد من "تسعة" من قبل تدابير معينة.

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

7.1.5. البند 4.1.5. "متطلبات الأمان" / p. 2.6.1.5 GOST 34.602-89 /

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

7.1.6. البند 4.1.6. "متطلبات بيئة العمل وعلم الجمال الفني" / ص. 2.6.1.6 GOST 34.602-89 /

نقدم متطلبات GOST: "تتضمن متطلبات بيئة العمل والجماليات الفنية مؤشرات AC التي تحدد الجودة اللازمة للتفاعل البشري مع الجهاز وراحة ظروف عمل الموظفين.

عادة في هذه الفقرة هو مكتوب أن النظام يجب أن يكون واجهة مريحة وجميلة. ولكن كيف تقيس الراحة والجمال؟ لذلك ، إما أن نتجاهل هذا المطلب ، أو نقول أن الواجهة ستتوافق مع مشروع تصميم تم تطويره لاحقًا ، أو نوفر معايير ، على سبيل المثال ، ما يسمى "الإرشادات" لتطوير تطبيقات الأجهزة المحمولة: تصميم المواد لإرشادات Android و Human Interface لـ iOS.

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

7.1.7. البند 4.1.7. "متطلبات النقل للمتحدثين المحمول" / ص. 2.6.1.7 GOST 34.602-89 /

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

7.1.8. البند 4.1.8. "متطلبات التشغيل والصيانة والإصلاح والتخزين" / ص. 2.6.1.8 GOST 34.602-89 /

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

7.1.9. البند 4.1.9. "متطلبات حماية المعلومات من الوصول غير المصرح به" / ص. 2.6.1.9 GOST 34.602-89 /

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

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

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

بشكل عام ، يمكن تقسيم معدات الحماية إلى الأنواع التالية:

1. الوسائل التي يوفرها منتج البرنامج الذي تم إنشاؤه.
2. التدابير التي يقدمها مسؤول النظام.
3. تدابير الحماية المادية.
4. التدابير التنظيمية العامة.
5. التدابير المتخذة خلال عملية تطوير البرمجيات.

1. تدابير الأمان التي يوفرها منتج البرنامج الذي تم إنشاؤه:

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

2. التدابير التي يقدمها مسؤول النظام:

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

3. تدابير الحماية المادية:

• الوصول المقيد إلى الغرف الحرجة.
• افصل موصلات الشبكة في الأماكن العامة.
• تركيب كاميرات الدوائر التلفزيونية المغلقة للمباني الحرجة.

4. التدابير التنظيمية العامة:

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

5. التدابير المتخذة خلال عملية تطوير البرمجيات:

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

7.1.10. البند 4.1.10. "متطلبات سلامة المعلومات في حالة وقوع حوادث" / ص. 2.6.1.10 GOST 34.602-89 /

يقدم هذا القسم قائمة بالحوادث والفشل المحتمل الذي يجب فيه ضمان سلامة المعلومات. قد تشمل هذه الأحداث:

• فقدان التغذية ؛
• فشل الخادم ؛
• فشل جهاز التخزين (القرص الصلب).

7.1.11. البند 4.1.11. "متطلبات الحماية من تأثير التأثيرات الخارجية" / p. 2.6.1.11 GOST 34.602-89 /

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

7.1.12. القسم الفرعي 4.1.12. "متطلبات نقاء البراءة" / ص. 2.6.1.12 GOST 34.602-89 /

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

7.1.13. البند 4.1.13. "متطلبات التقييس والتوحيد" / ص. 2.6.1.13 GOST 34.602-89 /

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

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

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

7.1.14. البند 4.1.14. "متطلبات إضافية" / ص. 2.6.1.14 GOST 34.602-89 /

يجب أن توجد هذه الفقرة في نص GOST. إنه لا يحتاج إلى تعليقات.

7.2. القسم الفرعي 4.2. "متطلبات الوظائف (المهام) التي يؤديها النظام" / ص. 2.6.2 GOST 34.602-89 /

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

7.2.1. هيكل الوصف الوظيفي

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

إذا كان نظامك يتكون من عدة أنظمة فرعية ، فيجب على المعارف التقليدية في الأساس أن تقدم قائمة من الوظائف للأنظمة الفرعية ، وأن تصف بالفعل بالتفصيل المتطلبات الوظيفية للأنظمة الفرعية في المعارف التقليدية الفردية للأنظمة الفرعية (يطلق عليها غالبًا CTZ الآن - مهمة فنية خاصة).

7.2.2. أنواع الوظائف من حيث تنفيذها

في الواقع ، يمكن تقسيم جميع الوظائف (أو مهامها ؛ يمكن أن توجد عدة مهام في وظيفة في وقت واحد) إلى الأنواع التالية:

• إدخال المعلومات. يشار إليها أحيانًا باسم "المعلومات المحاسبية".
• إخراج المعلومات.
• المعالجة التلقائية للمعلومات.

7.2.3. أنواع الوظائف من حيث دورها

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

7.2.4. الشرط ، وليس النصي

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

يمكن أن يختلف هيكل وظائف TOR والمشروع الفني اختلافًا كبيرًا: في أحد السيناريوهات ، يمكن تنفيذ العديد من الوظائف ، والعكس صحيح.

7.2.5. المتطلبات الوظيفية

فيما يلي بعض التوصيات حول كيفية إعداد وصف للوظائف:

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

7.2.6. وصف وظيفة مثال

5.6. تسجيل مركبة في النظام

يتم تقديم المتطلبات التالية:

1) يجب أن يسمح النظام بأخذ المعلومات العامة التالية في الاعتبار:

• علامة تسجيل الحالة (GRNZ) ؛
• اسم المالك
• عنوان المالك
• البيانات من خدمة الحصول على بيانات السيارة (انظر الفقرة 3.3 ، الملحق ب) ؛
• ملاحظة.

2) يجب أن يسمح النظام بمراعاة المعلومات التالية المتعلقة بدفع الأجرة (المعلومات المحددة ذات طبيعة إعلامية ، وإمكانية تغييرها مباشرة في بطاقة تسجيل السيارة غير مطلوبة):

• فئة السيارة الحالية (انظر الفقرة 3.3 ، الملحق أ) ؛
• التعريفة الحالية (انظر الفقرة 5.1 ، الملحق أ) ؛
• العقد الحالي (انظر الفقرة 5.5 ، الملحق أ) ؛
• فئة مركبة وفقًا للمعلومات الواردة من وزارة الشؤون الداخلية لجمهورية كازاخستان ؛
• معلومات حول الحساب الشخصي وحالته (انظر الفقرة 3.6 ، الملحق أ) ؛
• معلومات حول التواجد في سجل المركبة بتكلفة مخفضة (انظر الفقرة 3.5 ، الملحق أ).

3) يجب أن يسمح النظام بتسجيل وتغيير معلومات حول السيارة بالطرق التالية:

• يدويا من قبل المشغل.
• عند استلام المعلومات من نظام تسجيل علامات RFID (انظر الفقرة 1.1 ، الملحق ب) ؛
• عند تحديد السيارة باستخدام الكاميرا GRNZ.

4) عند تسجيل سيارة جديدة في النظام ، يجب على النظام طلب بيانات حول السيارة من الخدمة لتلقي البيانات حول السيارة (انظر الفقرة 3.3 ، الملحق ب). يجب أن يكون من الممكن تحديث المعلومات المحددة للسيارة الفردية.

7.3. القسم الفرعي 4.3. "متطلبات أنواع الأمان" / p. 2.6.3 GOST 34.602-89 /

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

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

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

7.3.1. بند 4.3.1 "البرمجيات" / ص. 2.6.3.1 GOST 34.602-89 /

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

7.3.2. الفقرة 4.3.2 "دعم المعلومات" / ص. 2.6.3.2 GOST 34.602-89 /

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

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

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

7.3.3. الفقرة 4.3.3 "الدعم اللغوي" / ص. 2.6.3.3 GOST 34.602-89 /

تنص هذه الفقرة على:

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

7.3.4. بند 4.3.4 "البرمجيات" / ص. 2.6.3.4 GOST 34.602-89 /

توفر هذه الفقرة قائمة بالبرامج التي تم شراؤها ، إذا تم تحديدها في مرحلة تطوير ToR.

7.3.5. بند 4.3.5 "الدعم الفني" / ع. 2.6.3.5 GOST 34.602-89 /

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

7.3.6. بند 4.3.6 "الدعم المترولوجي" / ص. 2.6.3.6 GOST 34.602-89 /

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

7.3.7. البند 4.3.7 "الدعم التنظيمي" / ص. 2.6.3.7 GOST 34.602-89 /

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

7.3.8. البند 4.3.8 "الدعم المنهجي" / ص. 2.6.3.8 GOST 34.602-89 /

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

7.3.9. أنواع أخرى من الضمان

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

8. القسم 5 "تكوين ومحتوى العمل على إنشاء (تطوير) النظام" / ع. 2.7 GOST 34.602-89 /

هذا القسم تنظيمي وغالبًا ما يتم وضعه في العقد. ومع ذلك ، يمكن تحديد هذه المعلومات في ToR.

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

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

ويرد مثال على محتويات هذا القسم في الجدول أدناه.

9. القسم 6 "إجراءات مراقبة وقبول النظام" / ص. 2.8 GOST 34.602-89 /

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

9.1. القسم الفرعي 6.1. "أنواع وتكوين وحجم وطرق اختبار النظام ومكوناته" / ع. 2.8.1 GOST 34.602-89 /

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

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

دعونا نحاول فهم نوع الاختبارات:

1. تنقسم الاختبارات إلى الأنواع التالية:

• الأولية.
• التشغيل التجريبي.
• القبول.

2. تنقسم الاختبارات الأولية (والقبول الجزئي) بدورها إلى:

• ( ).
• ( ).

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

دعنا نحاول وصف عملية الاختبار بكلمات بسيطة:

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

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

3. اختبارات شاملة أولية. يتم اختبار النظام بطريقة متكاملة ، أي بالتفاعل مع الأنظمة المجاورة. في هذا النموذج ، يتم نقل النظام إلى العميل للتشغيل التجريبي.

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

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

يشار أيضًا في هذه الفقرة إلى المستندات التي سيتم فيها منح طرق الاختبار:

• « () ». . — 34.603-92 (. 2.2.2 4.1) — 50-34.698-90 « . . . . ».
• « », . 3.1 34.003-90. « » (. . 3.2 34.603-92), .

9.2. القسم الفرعي 6.2. "المتطلبات العامة لقبول العمل على مراحل" / ص. 2.8.2 GOST 34.602-89 /

في هذا القسم ، أشير عادة إلى:

1. سيتم إجراء الاختبارات على أراضيهم وعلى معداتهم: العميل أو المقاول.
2. وصف عام لكيفية إجراء الاختبارات (على سبيل المثال ، سيتم فحص المستندات ، ووجود عناصر واجهة المستخدم ، والبرامج النصية).
3. قائمة المشاركين.
4. قائمة الوثائق التي تضع نتيجة الاختبار:
   
   
   • بالنسبة للاختبارات الأولية واختبارات القبول ، هذا تقرير اختبار يوفر قائمة بالتحققات ونتائجها.
   • للتشغيل التجريبي - مجلة العملية التجريبية.

10. القسم 7 "متطلبات تكوين ومحتوى العمل على إعداد كائن التشغيل الآلي لتشغيل النظام" / ص. 2.9 GOST 34.602-89 /

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

عند تحضير كائن ، كقاعدة عامة ، يجب تنفيذ العمل التالي:

1. إعادة تنظيم وتوظيف موظفين جدد ، إذا لزم الأمر.
2. تدريب الموظفين.
3. لتطبيقات الويب: تطوير أقسام مشتركة من الموقع واتفاق المستخدم (الموافقة على معالجة البيانات الشخصية).
4. ملء الأدلة وغيرها من المعلومات الأساسية.
5. نقل البيانات من النظام القديم.
6. نشر النظام على الخوادم الصناعية.
7. تكوين التكامل مع الأنظمة المجاورة.
8. إعداد نظام الوصول وإنشاء الحسابات.

يجب وصف بعض هذه النقاط بتفصيل كبير ، خاصة فيما يتعلق بنقل البيانات وتعبئة الأدلة.

11. القسم 8 "متطلبات التوثيق" / ص. 2.10 GOST 34.602-89 /

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

يتم توثيق وثائق مشروع الأتمتة وفقًا لـ GOST 34 وفقًا للمعايير التالية:

• GOST 34.201-89 أنواع المستندات واكتمالها وتعيينها عند إنشاء أنظمة آلية.
• RD 50-34.698-90 المبادئ التوجيهية. تكنولوجيا المعلومات. مجموعة من المعايير والإرشادات للأنظمة الآلية. الأنظمة الآلية. متطلبات محتوى الوثائق.
• بالنسبة للشروط المرجعية - GOST 34.602-89 ، والتي نناقشها الآن.

المعيار الأول (GOST 34.201-89) يوفر قائمة وهيكل الوثائق. في الثانية - RD 50-34.698-90 - يشار إلى محتوى الوثائق التالية:

• وثائق التصميم الأولي والمشاريع الفنية.
• المستندات التي تم تطويرها في مراحل ما قبل التصميم.
• الوثائق التنظيمية والإدارية (الأفعال ، البروتوكولات ، إلخ)

11.1 ميزات هيكل الوثائق

عند تجميع قائمة بالوثائق اللازمة ، عادة ما ينظرون إلى RD 50-34.698-90 واختيار الوثائق المطلوبة. في الوقت نفسه ، يتم ارتكاب الكثير من الأخطاء ، لأن الوثائق بها هيكل معقد إلى حد ما ، وهو موضح في GOST 34.201-89.

دعنا نحاول تحديد بعض القواعد التي ستساعد في تجميع قائمة الوثائق.

1. كل مرحلة لديها مجموعة من الوثائق الخاصة بها.

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

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

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

2. يتم تقسيم الوثائق إلى مواضيع (أجزاء من المشروع).

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

3. يمكن الجمع بين الوثائق.

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

4. يتم تمييز تقديرات التشغيل والتصميم بشكل منفصل.

المجمعون من GOST 34.201-89 في أعمدة منفصلة من الجدول مع قائمة الوثائق المشار إليها تنتمي إلى تقديرات التشغيل والتصميم.

تتضمن تقديرات التصميم المستندات التي تحكم أعمال الإنشاءات والكهرباء: التقديرات وخطط المشتريات والرسومات والمخططات الكهربائية.

تتضمن المستندات التشغيلية المستندات التي توجه استخدام النظام وصيانته: أدلة وتعليمات وقوائم المواد والبيانات والمستندات التي تحتوي على معلومات حول الانتهاكات أثناء التشغيل.

11.2 ميزات تصميم قائمة الوثائق

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

في قواعد الوثائق ، عادةً ما أعطي جدولًا يحتوي على الأعمدة التالية:

• المرحلة.
• اسم المستند.
• ملاحظة: يشير إلى مستوى التطوير والغرض والملخص والميزات الرئيسية للوثيقة.

11.3 مثال على قائمة الوثائق

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

12. 9 « » /. 2.11 34.602-89/

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

إذا كان هناك العديد من المصادر ، فيجب تقسيمها إلى أقسام فرعية ، على سبيل المثال:

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

الخاتمة

بالطبع ، لا يمكن اعتبار إعداد الشروط المرجعية وفقًا لـ GOST 34 سهلًا وبسيطًا. ليس لأن GOST سيء ، لكن GOST يجعلك تفكر في المشروع بأكمله ، قم برسم كل الأشياء الصغيرة. لكن TOR مكتوبة بشكل جيد هو نصف نجاح المشروع.

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

قراءة مقالات أخرى للمؤلف:

• .
• ( ) .
• .