تسجيل وثائق البرنامج حسب espd, espd. إعداد الوثائق للبرنامج وفقًا لـ GOST مثال على مذكرة توضيحية وفقًا لـ ESP GOST 19.101
G O S U D A R S T V E N N Y S T A N D A R T S O U Z A S S R
|
نظام التوثيق الفني لأنظمة التحكم الآلي |
غوست 24.207-80 |
متطلبات محتوى وثائق البرنامج |
|
| نظام الوثائق الفنية لأنظمة التحكم بالكمبيوتر. متطلبات محتويات الوثائق على البرمجيات |
بموجب مرسوم صادر عن لجنة الدولة للمعايير في اتحاد الجمهوريات الاشتراكية السوفياتية بتاريخ 14 مايو 1980 رقم 2101، تم تحديد تاريخ التقديم
من 01/01/1981
تنطبق هذه المواصفة القياسية على الوثائق الفنية الخاصة بـ الأنظمة الآليةأنظمة الإدارة (ACS) بجميع أنواعها، تم تطويرها لجميع مستويات الإدارة (باستثناء المستوى الوطني)، وتحدد متطلبات محتوى المستندات المدرجة في الوثائق وفقًا لـ GOST 24.101-80 برمجةفي مشاريع ACS.
1. أحكام عامة
1.1. تهدف وثائق البرنامج إلى:
- لوصف حلول التصميم للبرامج في مستند "وصف برنامج ACS".
- لتحديد متطلبات برنامج (مجموعة البرامج) في وثيقة "المواصفات الفنية"؛
- لوصف الحلول التي توفر الصيانة والإنتاج والتشغيل لبرنامج (مجموعة البرامج) في المستندات "مذكرة توضيحية"، "وصف التطبيق"، "وصف البرنامج"، "المواصفات"، "دليل المبرمج"، "دليل المشغل" "الدليل"، "نص البرنامج"، "النموذج"، "الإجراءات وطرق الاختبار"؛
- للتحقق من وظائف البرنامج (مجموعة البرامج) في مستند "وصف حالة الاختبار".
1.2. عند تطوير المستندات لأجزاء من نظام التحكم الآلي، يقتصر محتوى أقسام كل مستند على إطار الجزء المقابل.
1.3. اعتمادًا على الغرض والميزات المحددة لأنظمة التحكم الآلي التي تم إنشاؤها، يُسمح بتضمين أقسام إضافية في المستندات التي لم يتم تحديد متطلبات محتواها بموجب هذا المعيار. يتم تسجيل غياب الحلول التصميمية لقسم من المستند في القسم المناسب مع التوضيحات اللازمة.
1.4. تم تحديد متطلبات محتوى المستندات "المواصفات الفنية" و"الملاحظة التوضيحية" و"وصف التطبيق" و"المواصفات" و"دليل المشغل" و"نص البرنامج" و"النموذج" و"إجراءات ومنهجية الاختبار" من قبل GOST 19.201-78، GOST 19.404-79، GOST 19.502-78، GOST 19.202-78، GOST 19.505-79، GOST 19.401-78، GOST 19.501-78 وGOST 19.301-79.
(طبعة منقحة، تعديل رقم 1).
2. متطلبات محتوى المستندات
2.1. وصف برنامج ACS
2.1.1. يجب أن تحتوي الوثيقة على جزء تمهيدي وأقسام:
- هيكل البرمجيات.
- الوظائف الرئيسية لأجزاء البرنامج؛
- أساليب وأدوات تطوير البرمجيات؛
- نظام التشغيل
- الأدوات التي تعمل على توسيع قدرات نظام التشغيل.
2.1.2. يجب أن يحتوي الجزء التمهيدي على معلومات أساسية حول الدعم الفني والمعلوماتي والأنواع الأخرى من دعم نظام التحكم الآلي اللازم لتطوير البرمجيات، أو رابط للوثائق ذات الصلة بمشروع نظام التحكم الآلي.
2.1.3. يجب أن يحتوي قسم "بنية البرنامج" على قائمة بأجزاء البرنامج، مع الإشارة إلى علاقاتها والسبب المنطقي لتحديد كل منها.
2.1.4. يجب أن يحتوي قسم "الوظائف الرئيسية لأجزاء البرنامج" على أقسام فرعية يتم فيها توضيح غرض ووصف الوظائف الرئيسية لكل جزء من أجزاء البرنامج.
(طبعة منقحة، تعديل رقم 1).
2.1.5. يجب أن يحتوي قسم "طرق وأدوات تطوير البرمجيات" على قائمة بأساليب وأدوات البرمجة لتطوير برامج نظام التحكم الآلي، مع الإشارة إلى أجزاء البرنامج التي يجب استخدام الأساليب والأدوات المناسبة في تطويرها.
2.1.6. يجب أن يحتوي قسم "نظام التشغيل" على:
- اسم وتسمية ووصف موجز لنظام التشغيل المختار ونسخته، والتي سيتم من خلالها تنفيذ البرامج المطورة، مع مبرر الاختيار وإشارة المصادر في حالة ذكرها وصف تفصيليالنسخة المختارة
- اسم الدليل الذي سيتم بموجبه إنشاء الإصدار المحدد من نظام التشغيل؛
- متطلبات خيار الإنشاء لإصدار نظام التشغيل المحدد.
2.1.7. يجب أن يحتوي قسم "الأدوات التي تعمل على توسيع قدرات نظام التشغيل" على أقسام فرعية يجب الإشارة فيها إلى كل أداة مستخدمة تعمل على توسيع قدرات نظام التشغيل:
- اسم المنتج وتسميته ووصفه الموجز، مع تبرير الحاجة إلى استخدامه وإشارة إلى المصدر، مما يوفر وصفًا تفصيليًا للمنتج المحدد؛
- اسم الدليل الذي يجب بموجبه تكوين المنتج المستخدم لتطبيق معين؛
- متطلبات إعداد الأداة المستخدمة.
2.2. وصف البرنامج
2.2.2. للحصول على برنامج (مجموعة برامج) تم الحصول عليه من خلال استخدام ما تم تطويره مسبقًا برمجة، يجب استكمال مستند "وصف البرنامج" بقسم "إعداد البرنامج".
2.2.3. يجب أن يحتوي قسم "تكوين البرنامج" على:
- الاسم، وتعيين البرنامج المستخدم، ووصف الإجراءات المطلوبة لتكوينها، أو الروابط إلى الوثائق التشغيلية لهذه الأدوات؛
- قائمة بعناصر البرامج المستخدمة اللازمة للحصول على البرنامج (مجموعة البرامج)؛
- وصف الإعدادات باللغة المقدمة في الوثائق التشغيلية للبرنامج المستخدم.
2.3. دليل المبرمج
2.3.1. يجب أن تتوافق الوثيقة الخاصة بتكوين الأقسام ومحتواها مع GOST 19.504-79، بالإضافة إلى تضمين قسم "معلومات عن شكل عرض البرنامج (مجموعة البرامج)".
2.3.2. يجب أن يحتوي قسم "معلومات حول شكل عرض البرنامج (مجموعة البرامج)" على معلومات حول الوسيط الذي يتم تسجيل البرنامج عليه، وحول محتوى ونظام ترميز المعلومات المسجلة على الوسيط، بالإضافة إلى المعلومات اللازمة لـ قراءة المعلومات من الوسط.
2.3.3. بالنسبة لبرنامج (مجموعة برامج) يمكن تخصيصه ليناسب شروط تطبيق معين، تتضمن وثيقة "دليل المبرمج" أقسامًا:
- هيكل البرنامج
- إعدادات البرنامج
- ميزات إضافية;
- رسائل إلى مبرمج النظام.
2.3.4. يُسمح لبرنامج (مجموعة برامج) يمكن تخصيصه ليناسب شروط تطبيق معين، بدلاً من الأقسام المذكورة في البند 2.3.3، تطوير وثيقة منفصلة "دليل مبرمج النظام" تلبي متطلبات GOST 19.503-79.
2.4. وصف حالة الاختبار
2.4.1. يجب أن تحتوي الوثيقة على أقسام:
- ميعاد؛
- بيانات المصدر؛
- نتائج الحساب؛
- التحقق من البرنامج (مجموعة من البرامج).
2.4.2. يجب أن يحتوي قسم "الغرض" على قائمة المعلمات ووصف موجز للوظيفة التي ينفذها البرنامج (مجموعة البرامج) الذي تم اختباره بواسطة مثال الاختبار.
2.4.3. يجب أن يحتوي قسم "البيانات الأولية" على وصف للبيانات الأولية لاختبار البرنامج (مجموعة البرامج) مع عرض البيانات الأولية. يُسمح بتقديم البيانات المصدر في شكل نسخة مطبوعة من ADCP.
2.4.4. يجب أن يحتوي قسم "نتائج الحساب" على نتائج معالجة البيانات الأولية بواسطة برنامج (مجموعة برامج)، مما يسمح بتقييم التنفيذ الصحيح للوظائف التي يتم اختبارها وقيمة المعلمات التي يتم اختبارها. يُسمح بتقديم نتائج الحساب في شكل نسخة مطبوعة من ADCP.
2.4.5. يجب أن يحتوي قسم "التحقق من البرنامج (مجموعة البرامج)" على:
- وصف لتكوين الوسائل التقنية اللازمة لتشغيل البرنامج (مجموعة البرامج)، أو رابط لوثائق البرنامج ذات الصلة؛
- وصف إجراءات إنشاء البيانات الأولية لفحص البرنامج (مجموعة البرامج)، واستدعاء البرنامج (مجموعة البرامج) الذي يتم اختباره والحصول على نتائج الحساب؛
- وصف تصرفات المشغل عند إعداد البيانات الأولية واختبار البرنامج (مجموعة البرامج) باستخدام مثال اختبار.
ثقافة تطوير البرمجيات
أي برمجة، من البسيط موقع إلكترونيإلى قوية أنظمة إدارة قواعد البيانات، هو منتج عالي التقنية ويجب أن يستوفي المعايير التالية:
- مصداقية؛
- التعامل المناسب مع حالات الطوارئ؛
- سهولة الترقية.
لا يمكن للبرامج تلبية هذه المتطلبات إلا إذا امتثلت للجميع بعناية تقنيات تطوير البرمجيات.
عام مراحل تطوير البرنامج:
- تحديد متطلبات البرنامج؛
- تطوير الاختصاصات;
- تطوير مشروع البرنامج؛
- ترميز البرنامج؛
- تجميع البرنامج
- اختبار وحدات البرمجيات؛
- التشغيل التجريبي للبرنامج؛
- تطوير البرمجيات؛
- وضع البرنامج في وضع التشغيل الدائم؛
- دعم البرنامج؛
- تحديد المتطلبات ل نسخة جديدةالبرامج؛
ل تحديد متطلبات البرنامجيحتاج المطور إلى الحصول على إجابة على السؤال: "ما مدى اهتمام العميل بتطوير البرنامج؟"
إذا لم يكن العميل مستعدًا للمشاركة بشكل فعال في الاجتماعات والمؤتمرات مع المطور أو قال أن هناك مرشحين آخرين للقيام بالعمل، فيجب إكمال العمل على البرنامج في هذه المرحلة.
إذا كانت نوايا العميل جادة، فإن تحديد متطلبات البرنامج على الأغلب يكون مسألة أكثر من اجتماع لا بد فيه من توضيح وتوضيح المسائل:
- ما هو الغرض (الأغراض) من البرنامج؟
- نطاق مستخدمي البرنامج.
- الأساس التنظيمي (القانوني، المرجعي) الذي تعتمد عليه العمليات الخوارزمية في البرنامج.
- إمكانية وضرورة مواصلة تطوير البرنامج.
- جهة اتصال مخولة لحل جميع المشكلات نيابة عن العميل.
- توفر المواد الموجودة أو خطط العميل للتحضير لاستخدامها في البرنامج (!!! هذه النقطة مهمة بشكل خاص لتطوير مواقع الويب).
تطوير المواصفات الفنيةمن الناحية المثالية ينبغي أن يتم تنفيذها من قبل العميل. من الناحية العملية، غالبًا ما يتم ذلك من قبل المطور بسبب عدم وجود المتخصصين المؤهلين، على دراية بمجال تطوير البرمجيات. يتم تطوير الاختصاصات، كقاعدة عامة، على أساس GOST 19.201-78 “ESPD. المواصفات الفنية. متطلبات المحتوى والتصميم." في حالات تطوير البرامج التقنية كجزء من الأنظمة الآلية، GOST 34.602-89 "تكنولوجيا المعلومات. المواصفات الفنية لإنشاء نظام آلي."
تخضع المواصفات الفنية لإجراءات الموافقة بين العميل والمطور بعد التحقق من صحة تنفيذها من قبل خدمة الرقابة التنظيمية للمطور.
بناء على المواصفات الفنية المعتمدة يجري تطوير وثائق التصميم (مشروع). يعتمد محتوى المشروع على نوع البرنامج وتقاليد مؤسسة المطور.
يجب أن تكون المكونات الإلزامية للمشروع:
- مذكرة توضيحية (وفقًا لـ GOST 19.404-79 "ESPD. مذكرة توضيحية. متطلبات المحتوى والتصميم").
- وصف البرنامج (وفقًا لـ GOST 19.402-78 "ESPD. وصف البرنامج").
- قائمة المصطلحات المستخدمة في المشروع. بالنسبة للمواقع الإلكترونية، يتضمن المشروع:
- رسم تخطيطي لتصميم الموقع؛
- قائمة المواد المستخدمة كجزء من الموقع؛
- هيكل قاعدة البيانات (إن وجد)
بالنسبة للبرامج التي تعمل مع قواعد البيانات، يعد هيكلها مكونًا إلزاميًا.
المشروع هو الوثيقة التي على أساسها تم تطوير البرنامج، وأي تغييرات في هيكل ووظائف البرنامج دون إجراء تغييرات على المشروع غير مقبولة. إن المشروع هو الوثيقة التي يتم على أساسها تحليل البرنامج لاحقًا وإعداد إصدار الإصدارات اللاحقة.
للتنفيذ ترميز البرنامجيصدر المصمم المهام إلى المبرمج لوحدات برنامج الترميز. تحدد المهمة متطلبات هيكل بيانات الإدخال والإخراج للوحدة، وأسماء المتغيرات المستخدمة في الوحدة، وخوارزمية معالجة البيانات بواسطة الوحدة، وتقنيات البرمجة (إذا لزم الأمر). رمز البرنامجمصحوبًا بتعليق مفصل تحدد جودته إمكانية إصدار إصدارات لاحقة من البرنامج.
يجب أن يصف الكود بعناية معنى بيانات الإدخال والإخراج لكل وحدة، بالإضافة إلى معنى ووظائف الوحدة نفسها. وهذا أمر مهم لنجاح بناء البرنامج.
لكل مرحلة يبني البرنامجمدير المشروع هو المسؤول. في هذه المرحلة، يتم تشكيل البرنامج ككل واحد. نظرًا لأن جميع مكونات البرنامج تم إنشاؤها بواسطة مبرمجين مختلفين، فإن هذه المرحلة مهمة بشكل خاص لإزالة التناقضات وعدم التوافق بين جميع الوحدات التي تم إنشاؤها.
اختبار البرنامجيتم على النحو التالي:
- يتم تحديد مجموعة من المعدات للاختبار.
- يتم تطوير السيناريوهات (حالات الاختبار) للاختبار.
- بناءً على السيناريوهات، يتم التحقق من تشغيل البرنامج في الوضع العادي (يتم التحقق من التنفيذ الصحيح للوظائف التي من المفترض أن يؤديها البرنامج).
- يتم التحقق من تشغيل البرنامج في الأوضاع غير الطبيعية (يتم التحقق مما إذا كان البرنامج يعمل بثبات في الأوضاع التي يمكن أن تنشأ فقط عندما ينتهك المستخدمون قواعد تشغيل البرنامج، على سبيل المثال، إدخال الحروف في حقل رقمي).
- يتم إجراء الاختبار لسهولة إدارة البرنامج وجودة الواجهة.
- تتم معالجة وتوثيق بيانات الاختبار ونتائجه وفقًا لـ GOST 34.603-92 "تكنولوجيا المعلومات. أنواع اختبار الأنظمة الآلية."
- وبمجرد تحديد الأخطاء، يتم تصحيحها وتكرار الاختبار.
- بعد تصحيح كافة الأخطاء، يتم نقل البرنامج إلى التشغيل التجريبي.
للعميل على المسرح عملية تجريبيةيتم نقل البرنامج و حزمة الوثائق المطلوبة:
- قائمة الوثائق التشغيلية (وفقًا لـ GOST 19.507-79 "ESPD. قائمة الوثائق التشغيلية")
- النموذج (وفقًا لـ GOST 19.501-78 "ESPD. النموذج. متطلبات المحتوى والتصميم")
- وصف التطبيق (وفقًا لـ GOST 19.502-78 "ESPD. وصف التطبيق. متطلبات المحتوى والتصميم")
- دليل مبرمج النظام (وفقًا لـ GOST 19.503-79 "ESPD. دليل مبرمج النظام. متطلبات المحتوى والتصميم")
- دليل المشغل (وفقًا لـ GOST 19.505-79 "ESPD. دليل المشغل. متطلبات المحتوى والتصميم").
اعتمادًا على نوع المهمة، قد يتم أيضًا إرسال ما يلي:
- دليل المبرمج (وفقًا لـ GOST 19.504-79 "ESPD. دليل المبرمج. متطلبات المحتوى والتصميم")
- دليل على t / o (وفقًا لـ GOST 19.508-79 "ESPD. دليل على صيانة. متطلبات المحتوى والتصميم").
على المسرح عملية تجريبيةيقوم البرنامج بتسجيل تعليقات العميل والأخطاء التي تم تحديدها.
وعلى هذا الأساس يتم إنتاجه تطوير البرمجياتأي حذف التعليقات والأخطاء ونقل البرنامج إلى العميل في عملية مستمرة.
دعم البرنامجاعتمادًا على مدى تعقيدها، يتم تنفيذها إما بواسطة العميل أو المطور. يتكون الدعم من أداء أنواع العمل التالية:
- المشاورات؛
- صيانة الأجهزة التي يُستخدم عليها البرنامج؛
- فحص وتحليل قواعد البيانات؛
- التحقق من صحة تقنيات معالجة البيانات؛
- توثيق وتحليل متطلبات البرنامج الجديدة.
النقطة الأخيرة هي الأساس للبدء تطوير نسخة جديدة من البرنامج.
فقط عملية تطوير البرنامج المختصة هي التي تضمنهم جودة عاليةوعمر طويل!!!
غوست 19.101-77
المجموعة T55
معيار الطريق السريع
النظام الموحدوثائق البرنامج
أنواع البرامج ووثائق البرنامج
النظام الموحد لتوثيق البرامج. أنواع البرامج ووثائق البرنامج
مكس 35.080
تاريخ التقديم 1980-01-01
بقرار من لجنة الدولة للمعايير التابعة لمجلس وزراء اتحاد الجمهوريات الاشتراكية السوفياتية بتاريخ 20 مايو 1977 رقم 1268، تم تحديد تاريخ التقديم في 01/01/80
الطبعة (يناير 2010) مع التعديل رقم 1، تمت الموافقة عليها في يونيو 1981 (IUS 9-81).
تحدد هذه المواصفة القياسية أنواع البرامج ووثائق البرامج الخاصة بها أجهزة الكمبيوتروالمجمعات والأنظمة بغض النظر عن غرضها ونطاقها.
يتوافق المعيار تمامًا مع ST SEV 1626-79.
(طبعة منقحة، تعديل رقم 1).
1. أنواع البرامج
1. أنواع البرامج
1.1. يمكن تحديد البرنامج (وفقًا لـ GOST 19781-90) واستخدامه بشكل مستقل و (أو) كجزء من برامج أخرى.
1.2. وتنقسم البرامج إلى الأنواع الموضحة في الجدول 1.
الجدول 1
نوع البرنامج | تعريف |
عنصر | برنامج يعتبر ككل، يؤدي وظيفة كاملة ويستخدم بشكل مستقل أو كجزء من مجمع |
معقد | برنامج يتكون من مكونين أو أكثر و (أو) مجمعات تؤدي وظائف مترابطة، ويتم استخدامها بشكل مستقل أو كجزء من مجمع آخر |
1.3. يمكن استخدام الوثائق التي تم تطويرها للبرنامج لتنفيذ البرنامج ونقله على وسائط التخزين، وكذلك لتصنيع منتج برمجي.
1.2، 1.3. (طبعة منقحة، تعديل رقم 1).
2. أنواع وثائق البرنامج
2.1. تتضمن وثائق البرامج المستندات التي تحتوي على المعلومات اللازمة لتطوير البرامج وإنتاجها وصيانتها وتشغيلها.
2.2. يتم عرض أنواع وثائق البرنامج ومحتوياتها في الجدول 2.
الجدول 2
نوع وثيقة البرنامج | |
مواصفة | تكوين البرنامج وتوثيقه |
قائمة الشركات التي تقوم بتخزين وثائق البرنامج الأصلية |
|
نص البرنامج | تسجيل البرنامج مع التعليقات اللازمة |
وصف البرنامج | معلومات حول البنية المنطقية وتشغيل البرنامج |
المتطلبات التي يجب التحقق منها عند اختبار البرنامج، وكذلك إجراءات وطرق التحكم بها |
|
الاختصاصات | الغرض ونطاق البرنامج، المتطلبات الفنية والتقنية والاقتصادية والخاصة بالبرنامج، المراحل وشروط التطوير اللازمة، أنواع الاختبارات |
مذكرة توضيحية | مخطط الخوارزمية, وصف عامخوارزمية و (أو) عمل البرنامج، وكذلك تبرير القرارات الفنية والتقنية والاقتصادية المعتمدة |
الوثائق التشغيلية | معلومات لضمان عمل البرنامج وتشغيله |
2.3. وترد في الجدول 3 أنواع الوثائق التشغيلية ومحتوياتها.
الجدول 3
نوع الوثيقة التشغيلية | |
قائمة الوثائق التشغيلية للبرنامج |
|
استمارة | الخصائص الرئيسية للبرنامج واكتماله ومعلومات حول تشغيل البرنامج |
وصف التطبيق | معلومات حول الغرض من البرنامج، ونطاق التطبيق، والأساليب المستخدمة، وفئة المشكلات التي يتعين حلها، وقيود الاستخدام، والحد الأدنى من تكوين الأجهزة |
معلومات للتحقق وضمان الأداء وتخصيص البرنامج لشروط تطبيق معين |
|
دليل المبرمج | معلومات لاستخدام البرنامج |
دليل المشغل | معلومات لضمان إجراءات التواصل مع المشغل نظام الحوسبةأثناء تنفيذ البرنامج |
وصف اللغة | وصف بناء الجملة ودلالات اللغة |
معلومات حول استخدام برامج الاختبار والتشخيص عند صيانة المعدات التقنية |
2.4. اعتمادًا على طريقة التنفيذ وطبيعة التطبيق، تنقسم وثائق البرنامج إلى أصلية ونسخة ونسخة (GOST 2.102-68)، مخصصة لتطوير البرنامج وصيانته وتشغيله.
2.5. يتم عرض أنواع وثائق البرنامج التي تم تطويرها في مراحل مختلفة ورموزها في الجدول 4.
الجدول 4
شفرة | نوع الوثيقة | مراحل التطوير |
|||
مشروع التصميم | مشروع فني | مسودة العمل |
|||
عنصر | معقد |
||||
مواصفة | |||||
قائمة أصحاب الأصلي | |||||
نص البرنامج | |||||
وصف البرنامج | |||||
قائمة الوثائق التشغيلية | |||||
استمارة | |||||
وصف التطبيق | |||||
دليل مبرمج النظام | |||||
دليل المبرمج | |||||
دليل المشغل | |||||
وصف اللغة | |||||
دليل الصيانة | |||||
برنامج ومنهجية الاختبار | |||||
مذكرة توضيحية | |||||
وثائق أخرى | |||||
أسطورة:
- الوثيقة إلزامية؛
- الوثيقة إلزامية للمكونات التي لها استخدام مستقل؛
- يتم تحديد الحاجة إلى إعداد وثيقة في مرحلة التطوير والموافقة على المواصفات الفنية؛
- - لم يتم إعداد الوثيقة.
2.2-2.5. (طبعة منقحة، تعديل رقم 1).
2.6. يُسمح بدمج أنواع معينة من المستندات التشغيلية (باستثناء قائمة المستندات التشغيلية والنموذج). يشار إلى الحاجة إلى الجمع بين هذه الوثائق في المواصفات الفنية. يتم تعيين اسم وتعيين للمستند المدمج لأحد المستندات المدمجة.
يجب أن تحدد المستندات المدمجة المعلومات التي يجب تضمينها في كل مستند يتم دمجه.
2.7. في مرحلة تطوير المواصفات الفنية والموافقة عليها، يتم تحديد الحاجة إلى وضع مواصفات فنية تحتوي على متطلبات إنتاج البرنامج ومراقبته وقبوله.
يتم تطوير المواصفات الفنية في مرحلة "التصميم التفصيلي".
2.8. يتم تحديد الحاجة إلى وضع المواصفات الفنية للمكونات غير المخصصة للاستخدام المستقل، والمجمعات المدرجة في المجمعات الأخرى، بالاتفاق مع العميل.
(مقدم بشكل إضافي، التعديل رقم 1).
نص الوثيقة الإلكترونية
تم إعداده بواسطة Kodeks JSC وتم التحقق منه مقابل:
النشر الرسمي
نظام برمجي موحد
الوثائق: السبت. غوست. -
م: ستاندارتينفورم، 2010
في وقت ما، عندما كنت قد بدأت للتو العمل كمبرمج، كنت أسمع في كثير من الأحيان "من فضلك اكتب وثائق لبرنامجك". لقد وصفت كل شيء بصدق، وأعطيته لرئيسي، وبعد ذلك بدأت جلسة السحر الأسود. بعد فترة، اتصل بي المدير وبدأ يتمتم بأصوات غير واضحة، ويجعّد النسخة المطبوعة من النص "الأفضل" بين يديه، ويحرك عينيه. كان المعنى العام لتذمره هو أنه تبين أنه "خطأ" و"خطأ" و"انظر إلى ما يفعله الآخرون". وبما أنه كان من المستحيل انتزاع أي إجابة أخرى منه، فقد ذهبت إلى "الآخرين" للحصول على أمثلة من المستندات. كقاعدة عامة، كان هؤلاء رجال مبتهجين، وكان معنى خطبهم أن "هذه أمثلة"، "بشكل عام، وفقا ل GOST"، و "كل هذا لا يحتاج إلى أحد". هذه هي الطريقة التي تعلمت بها لأول مرة أنه يمكن للمبرمج أن يتعامل مع معايير GOST الرهيبة.
إنه لأمر مدهش أنه من بين العشرات من زملائي، المبرمجين الأذكياء للغاية، لم يكن هناك من يعامل GOST بشكل مختلف. حتى الأشخاص القلائل الذين عرفوهم، ويبدو أنهم يعرفون كيفية إعداد المستندات، عاملوهم بازدراء وشكليات. إن الموقف الذي لا يفهم فيه حتى الأشخاص المسؤولون عن إدارة التطوير سبب الحاجة إلى معايير GOST وكيف سيتم تطبيقها يحدث في العديد من المؤسسات طوال الوقت. نعم، كانت هناك شركات أدركت كيف يختلف "وصف البرنامج" عن "وصف التطبيق"، ولكن كانت هناك أقلية واضحة. على شبكة الإنترنت، وجهة النظر السائدة هي أن معايير الدولة بالنسبة للمبرمجين هي بدائية واضحة، ولا تكون هناك حاجة إليها إلا إذا "انحنوا" لهم. وتعتبر مسودة التصميم “وسيلة عادلة نسبياً لسحب الأوراق النقدية الزائدة من العميل”. كان علي أن أتعمق فيه وأفهمه مؤخرًا نسبيًا - في عملية تطوير نظام إدارة المتطلبات المصمم خصيصًا للمواصفات المحلية. الوثائق التي، بالطبع، يجب أن يتم إنشاؤها "وفقًا لـ GOST".
أريد هنا التركيز على موضوع واحد فقط يجب على المبرمج في المؤسسات المحلية، وخاصة في معاهد البحوث، التعامل معه - مجموعة معايير ESPD. أنا لا أعتبر نفسي خبيرًا كبيرًا في ESPD - فهناك أشخاص يعملون عليها منذ عقود وسيصححون لي بالتأكيد. تحاول المقالة بدلاً من ذلك تحديد الخطوط العريضة لـ "خارطة الطريق" لأولئك الذين بدأوا للتو في تأرجح الأمور.
المعايير
دعونا نلقي نظرة سريعة على المعايير الموجودة (مع التركيز على مجال تكنولوجيا المعلومات).- دولي. والسمة المميزة هي أنه تم اعتماده من قبل منظمة دولية. مثال على هذه المنظمة هو ISO (المنظمة الدولية للتوحيد القياسي). مثال على معيارها: ISO 2382-12:1988 (المعدات الطرفية). المعايير المشتركة بين ISO واللجنة الكهروتقنية الدولية (IEC، باللغة الروسية - IEC) منتشرة على نطاق واسع: على سبيل المثال، ISO/IEC 12207:2008 (دورة حياة البرنامج)؛
- إقليمي. سمة مميزة - اعتمدتها الهيئة الإقليمية للتقييس. على سبيل المثال، أصبحت العديد من معايير GOST السوفيتية الآن معايير إقليمية، لأن الذي اعتمده المجلس المشترك بين الدول، والذي يضم بعض الجمهوريات السوفيتية السابقة. يتبنى هذا المجلس أيضًا معايير جديدة - ويحصلون أيضًا على تصنيف GOST. مثال: GOST 12.4.240-2013؛
- معايير الجمعيات العامة؛ على سبيل المثال، نفس IEC: IEC 60255؛
- المعايير الوطنية. بالنسبة لروسيا، بداية هذه المعايير هي "GOST R". يمكن أن يكون هناك ثلاثة أنواع:
- نسخ طبق الأصل من تلك الدولية أو الإقليمية. وقد تم تصنيفها بشكل لا يمكن تمييزه عن "المكتوبة ذاتيًا" (الوطنية، والمكتوبة بشكل مستقل)؛
- نسخ دولية أو إقليمية مع الإضافات. يتم الإشارة إليها عن طريق إضافة التشفير الدولي إلى تشفير المعيار المحلي، والذي تم اتخاذه كأساس. على سبيل المثال: GOST R ISO/IEC 12207؛
- في الواقع، المعايير الوطنية. على سبيل المثال، GOST R 34.11-94.
تختلف أنظمة التدوين على كل مستوى وفي كل منظمة، ويجب تحليل كل حالة على حدة. لفهم معيار "من" أمام عينيك بسرعة، يمكنك استخدام ورقة الغش.
غوست
إذن: المعايير دولية ومشتركة بين الولايات (إقليمية) ووطنية. GOST، كما اكتشفنا، هو معيار إقليمي. لدى GOST نظام تدوين محير إلى حد ما، في رأيي. تم تحديده بالكامل في GOST R 1.5-2004، وسأقدم الحد الأدنى للتنقل فيه. أولا، من الضروري التمييز بين تعيين GOST وتصنيفها. يعتبر التعيين، تقريبًا، معرفًا فريدًا للمعيار. رمز المصنف هو رمز مساعد يساعد في العثور على معيار أو تحديد مجال المعرفة الذي ينتمي إليه. يمكن أن يكون هناك العديد من المصنفات، ويتم استخدام اثنين بشكل أساسي: KGS (مصنف معايير الدولة) وخلفه OKS (مصنف المعايير الروسي بالكامل). على سبيل المثال: "GOST R 50628-2000" هو تسمية المعيار ومن الواضح فقط أنه تم اعتماده في عام 2000. يحتوي على رمز OKS "33.100;35.160": أي. "33" - قسم "الاتصالات والصوت والفيديو"، "100" - القسم الفرعي "التوافق الكهرومغناطيسي". ومع ذلك، يتم تضمينه أيضًا في فرع المصنف 35.160. "35" - "" تكنولوجيا المعلومات. الأجهزة المكتبية"، "160" - "أنظمة المعالجات الدقيقة...". ووفقًا لـ KGS فهي تحتوي على الرمز "E02"، والذي يعني "E" - "التكنولوجيا الإلكترونية والإلكترونيات الراديوية والاتصالات"، "0" - " القواعد العامةومعايير التكنولوجيا الإلكترونية والإلكترونيات الراديوية والاتصالات، وما إلى ذلك.إذا كنت تعرف تسمية المعيار، فيمكنك الحصول على رموزه الخاصة بـ KGS وOKS، على سبيل المثال، على هذا الموقع الذكي.
لذلك، دعونا نعود إلى تسميات GOST. يمكن أن يكون هناك خياران:
- يشير المعيار إلى سلسلة من المعايير. في هذه الحالة، بعد فهرس الفئة القياسية (على سبيل المثال، GOST أو GOST R أو GOST RV) يوجد رمز سلسلة ونقطة وتعيين المعيار داخل السلسلة. يتم تحديد قواعد تعيين المعايير ضمن السلسلة من خلال قواعد السلسلة. على سبيل المثال: GOST RV 15.201-2000، GOST R 22.8.0-99، GOST 19.101-77؛
- المعيار لا ينتمي إلى سلسلة من المعايير. ثم بعد فهرس الفئة يذهب ببساطة رقم سريالمعيار والشرطة وسنة الاعتماد. على سبيل المثال، GOST R 50628-2000.
إسبد
ESPD هي واحدة من سلسلة GOST، رقم 19. هذا هو. تبدأ جميع المعايير المتعلقة بـ ESPD بالبادئة "19": على سبيل المثال، GOST 19.106-78. تعني "النظام الموحد لتوثيق البرامج". هناك سلسلة أخرى:- GOST ESKD (النظام الموحد لوثائق التصميم، البادئة "2.")؛
- GOST ESTD (النظام الموحد للتوثيق التكنولوجي، البادئة "3.")؛
- GOST R، نظام تطوير وإنتاج المنتجات، البادئة "15".
- GOST RV، التسلح والمعدات العسكرية. نظام تطوير المنتجات وإطلاقها في الإنتاج، البادئة "15".
- GOST، نظام التوثيق الفني لأنظمة التحكم الآلي، البادئة "24".
- GOST، مجموعة معايير الأنظمة الآلية، البادئة "34".
19.001-77. أحكام عامة
يصف قواعد تعيين التسميات للمعايير في سلسلة ESPD. لا حاجة لها في الحياة العملية.19.102-80. مخططات الخوارزميات والبرامج. قواعد التنفيذ.
يصف قواعد بناء وتصميم الخوارزميات. يستخدم التدوين من 19.103. في ممارستي، المرة الوحيدة التي كانت هناك حاجة إليها كانت عندما أصر مختبر إصدار الشهادات على أساس رسمي على أن مخطط الخوارزمية هو المطلوب. من وجهة نظري، أصبحت المخططات الانسيابية الكلاسيكية شيئًا من الماضي، والمكان الوحيد الذي تظل فيه مناسبة إلى حد ما هو إذا أراد المؤلف، عند العرض، تركيز انتباه القارئ على الخوارزمية.19.003-80. مخططات الخوارزميات والبرامج. الرموز الرسومية التقليدية
يتم إعطاء التسميات الرسومية للأنواع المقبولة من عناصر المخطط الهيكلي. مطلوبة في حالة استخدام المخططات الكتلية.19.004-80. المصطلحات والتعاريف.
معجم هزيل. والشيء الأكثر إثارة للاهتمام هو أنه يحتوي على تعريفات رسمية للوثائق البرنامجية والتشغيلية.19.005-85. P- مخططات الخوارزميات والبرامج
لغة منسية تقريبا. في وقت ما، تم استخدام مخططات P على نطاق واسع في صناعة الصواريخ والفضاء، لتصبح المعيار الفعلي لكتابة برامج التحكم في الإطلاق ومحاكاة عمليات الإطلاق. ومع ذلك، الآن تم نسيان هذه اللغة تماما. في عملي، لم أواجه أبدًا مخططات P. على الرغم من أنها تتمتع بمزايا ملحوظة مقارنة بالمخططات الانسيابية: فهي مدمجة ومناسبة لتصور الخوارزميات غير الخطية (على سبيل المثال، الفئات في C++) أو هياكل البيانات. في الوقت نفسه، لا توجد معلومات عنها عمليا على الإنترنت: لقد وجدت هذا وهذا الموقع مفيدا. على أية حال، إذا اضطررت الآن إلى إدراج مخطط خوارزمي في وثائق البرنامج، فسأختار المخططات P بدلاً من المخططات الانسيابية.19.101-77. أنواع البرامج ووثائق البرنامج
يحتوي على جدول المراسلات بين نوع المستند ورمزه، بالإضافة إلى تقسيم أنواع المستندات إلى تشغيلية وبرنامجية. تم تقديم مفهوم المعقد والمكون. لا يوجد شيء آخر مفيد.19.102-77. مراحل التطوير
معيار مهم وضروري يصف أنواع المستندات ويوفر رموزًا لأنواع مستندات البرنامج. يعد هذا المعيار (مع 19.103-77) أحد مفاتيح "كشف" تسميات المستندات مثل ABVG.10473-01 32 01-1.يقدم المعيار مفهوم المعقد والمكون (يضيف عدد من المؤسسات نوعًا ثالثًا - مجموعة، عندما يتعلق الأمر بأشياء غير مرتبطة عناصر البرنامج)، يتم إعطاء التقسيم: ما هي الوثائق العاملة، والتي ليست كذلك.
يجب أن تكون حذرًا فيما يتعلق بالجدول 4، الذي يوضح الوثيقة التي يتم تنفيذها وفي أي مرحلة من التطوير. عادة ما يتم تنظيم مراحل التطوير في معايير تنفيذ أعمال التصميم والتطوير، كما أنها توضح ما هي المستندات التي يجب تقديمها للعميل في كل مرحلة.
19.102-77. مراحل التطوير
في ذاكرتي، لم يتم استخدام هذا المعيار مطلقًا: من يفعل ماذا وفي أي مرحلة وما يقدم تقريرًا عنه، يتم تدوينه في المواصفات الفنية أو يتم الإشارة إلى GOSTs، حيث يتم ذكر ذلك بشكل أكثر وضوحًا (على سبيل المثال، GOST RV 15.203) ). في الوقت نفسه، بالنسبة للمبتدئين، فهو يحتوي على مخطط موجز إلى حد ما للعمل على المراحل الرئيسية للوسواس القهري.19.103-77. تسميات البرامج ووثائق البرنامج
إنه ضروري بشكل أساسي لتعلم قراءة رموز المستندات المشابهة لتلك المذكورة أعلاه. ومع ذلك، فإن فهم نظام التدوين مفيد عندما يتعين عليك تجاوز العمل القياسي: على سبيل المثال، تذكر أن المستندات التي تحتوي على رموز بعد 90 تكون محددة من قبل المستخدم، أي. أي. في ممارستي، أصدرنا الوثيقة 93، والتي أطلقنا عليها "بيان توثيق البرنامج"، الوثيقة 96 - "تعليمات التجميع".العبارة الشائعة "خيار التنفيذ" غائبة عن ESPD ويتم استبدالها بـ "رقم المراجعة". من ناحية، هذا ليس صحيحا تماما: كان المقصود من رقم المراجعة تتبع تطور البرنامج: أولا يتم إصدار الطبعة الأولى، ثم، على سبيل المثال، بعد المراجعة، الثانية. ولكن في الممارسة العملية، عندما تحتاج إلى إصدار إصدار برنامج لعدة أنظمة التشغيل(البرمجيات عبر منصة)، ليس هناك خيار آخر. بتعبير أدق، يوجد، لكنه غير صحيح: قم بتعيين الإصدار لكل نظام تشغيل بتسميته الخاصة - وقم بوضع عدة أقراص في الأرشيف مع رموز المصدر (حسب عدد أنظمة التشغيل)، وقم بتطوير (في الواقع، نسخ) مجموعة كاملة من الوثائق، الخ.... هذا هو. نشاط غبي ومربك خالص. الحل المتمثل في تعيين رقم إصدار لكل نظام تشغيل يجعل من الممكن جعل بعض المستندات مشتركة.
يستخدم ESPD تسمية الكود المصدري للبرنامج ونتيجة التجميع على أنها "مستندات"، الأمر الذي يربك العديد من المبرمجين. وثيقة "نص البرنامج"، وفقًا للرقم 19.101-77، تحمل التصنيف 12. ومن المقبول أيضًا أن يتم تعيين رموز المصدر على أنها 12 01 - أي. 01 (الأولى) مستند من النوع 12، والثنائيات - مثل 12 02 - أي. الوثيقة الثانية من النوع 12. في بعض الحالات، تكون هناك حاجة إلى أدوات إضافية لإنشاء برنامج - المترجمين، ومولدات التثبيت، وما إلى ذلك. أولئك. البرامج التي لم يتم تضمينها في التسليم، ولكنها ضرورية للتجميع. قد يكون الحل هو تعيينهم على أنهم 12 03 - أي. الوثيقة الثالثة من النوع 12.
19.104-78. النقوش الأساسية
يصف ورقتين من المستند - ورقة الموافقة (AL) وصفحة العنوان. تحتوي ورقة الموافقة في ESPD على توقيعات كل من السلطات التي وافقت على الوثيقة والمطورين والمفتشين المعياريين وممثلي القبول، وما إلى ذلك. أولئك. أنه يحتوي على الكثير من المعلومات الحساسة للمؤسسة. لذلك، يفترض المعيار أن تبقى LU في المؤسسة النامية ويتم إرسالها فقط بناءً على إرشادات خاصة. مرة أخرى - LU ليس جزءًا من المستند، ولكنه، كما كان، مستند منفصل، ويتم تضمينه في المواصفات كسطر منفصل.إن الغرابة المربكة في البداية في فصل LU عن المستند نفسه لها أسباب وجيهة جدًا:
- كما ذكرنا سابقًا، غالبًا ما لا ترغب المؤسسة في الكشف عن معلومات حول المطور. يسمح فصل LU و"الضغط" بالقيام بذلك (على عكس ESKD، لا يوجد ختم على أوراق المستندات في ESPD؛ يتم ترجمة جميع المعلومات فقط في LU)؛
- يستخدم عدد من المؤسسات تدفق المستندات المختلط: يتم تخزين المستندات الأصلية فيها النموذج الإلكترونيفي أرشيفات المؤسسة، ولوحات الترخيص عليها (بالتوقيعات الأصلية) - ورقية؛
يجب أيضًا أن نتذكر أن LU غير مرقمة، والصفحة الأولى هي صفحة العنوان، والصفحة الأولى التي تم وضع الرقم عليها موجودة بجوار صفحة العنوان. ولكن إذا كان هناك أكثر من LU (يحدث هذا إذا لم يتم احتواء كافة التوقيعات على الورقة)، فسيتم ترقيم LUs بشكل منفصل.
19.105-78. المتطلبات العامة لوثائق البرنامج
يتم تقديم الهيكل العام للوثيقة، بغض النظر عن طريقة تنفيذها. أولئك. في عام 1978، تم تحديد معيار مفاده أن المستند قد لا يكون ورقًا بالضرورة. وعلى وجه الخصوص، تم تقديم مفهوم المحتوى للمستندات الإلكترونية بالكامل. بالنسبة للتنفيذ الورقي، الشائع في ذلك الوقت، تم اعتماد GOST 19.106-78.في الوقت الحالي، نادرًا ما يتعين على المرء الرجوع إلى هذا المعيار: إلا إذا نسي المرء ترتيب الأجزاء الرئيسية من الوثيقة.
19.106-78. المتطلبات العامة لوثائق البرنامج المطبوعة
المعيار الأكثر شمولاً من ESPD، يأتي في المرتبة الثانية بعد وصف مخططات R. إنه معيار العمل الرئيسي عند إعداد الوثائق. يقدم قواعد لتنسيق النص وعناصر بنية المستند والصور والصيغ وما إلى ذلك. ومع ذلك، على عكس 2.106 المقابل من ESKD، فإن 19.106 أقل تفصيلاً بشكل ملحوظ، مما يؤدي إلى العديد من الشكوك.أولاً، لا يحدد المعيار فعليًا تباعد الأسطر ومقدار المسافة الرأسية بين العناوين. يقدم ثلاث قواعد لتحديد المسافات: للنص المكتوب والآلي والمطبعي.
Typescript هو نص مكتوب على الآلة الكاتبة. تم إجراء تغيير السطر التالي بالنسبة إلى السطر السابق تلقائيًا أثناء ما يسمى بـ "عودة السطر" - الانتقال إلى طباعة السطر التالي، والذي يتم عن طريق تحريك رافعة خاصة. عادةً، يمكن ضبط التباعد يدويًا عن طريق تدوير عمود تغذية الورق، ويكون له "إعداد" يسمح لك بتعيين حجم التباعد - فردي أو مزدوج.
من المرجح أن يكون نوع الجهاز هو النص المطبوع. لكن بالنسبة له لا يوجد سوى إشارة إلى أن النتيجة يجب أن تكون مناسبة للميكروفيلم. هذه إشارة ضمنية إلى 13.1.002-2003، والتي، للأسف، تحدد تباعد الأسطر (وبالمناسبة، الحد الأدنى لارتفاع الخط) فقط للمستندات المكتوبة بخط اليد (البند 4.2.5).
مطبعي - نص مكتوب في المطبعة. وبالنظر إلى العام الذي تم فيه اعتماد المعيار، فمن المرجح أننا نتحدث عنه
[طباعة الحروف، حيث يتم تحديد تباعد الأسطر حسب النوع المستخدم. أنا لست خبيرًا في الطباعة، وهناك القليل جدًا من المعلومات حول طرق التنضيد في الوقت الحالي.
غالبًا ما يتم تحديد الفاصل الزمني الذي يجب استخدامه في النهاية من خلال اللوائح المحلية أو محطات الخدمة. القيم النموذجية هي تباعد واحد ونصف وحجم الخط 14.
غالبًا ما تثير الطريقة التي يتم بها تنظيم المستند العديد من الأسئلة. 19.106 يعتبر أن الوثيقة بأكملها مقسمة إلى أقسام وأقسام فرعية وفقرات وفقرات فرعية. كل منهم (باستثناء الأقسام والأقسام الفرعية) قد يكون أو لا يكون له عنوان. في هذه الحالة:
- "تتضمن محتويات الوثيقة عدد الأقسام والأقسام الفرعية والبنود والبنود الفرعية التي لها عنوان" (البند 2.1.4). وهذا مؤشر مباشر على أن الفقرة الفرعية قد يكون لها عنوان ويتم تضمينها في جدول المحتويات؛
- "يُسمح بوضع النص بين عناوين الأقسام والأقسام الفرعية، وبين عناوين الأقسام الفرعية وعناوين الفقرات." من المهم ملاحظة أن النص غير المرقم يمكن أن يكون فقط بين العناوين، وفي المستويين العلويين فقط.
يحتوي هذا المعيار على عدد من "الثغرات" والتناقضات. فمثلاً يقال: «الرسوم التوضيحية إذا كانت فيها هذه الوثيقةأكثر من واحدة، مرقمة بالأرقام العربية في جميع أنحاء الوثيقة. "ولكن إذا كان هناك مثل واحد فقط، فهو غير مرقم، فكيف يمكنك الرجوع إليه؟ الشيء نفسه ينطبق على الجداول. بالنسبة للحواشي السفلية، لا يشير GOST إلى طريقة ترقيمها - داخل المستند بأكمله أو داخل الصفحة.
الجداول. تحتوي الوثيقة نفسها على إشارة إلى GOST 1.5.68. انطلاقا من الحلقة الأولى، من السهل أن نستنتج أن هذا معيار لتطوير المعايير. ما يجب أن يفعله به غير واضح. في المعنى، فهو يتوافق مع قواعد تصميم الجداول في ESKD، مع استثناءات بسيطة. تم إلغاء هذا المعيار واستبداله، من خلال عدة تكرارات، بحلول 1.5-2012، حيث اختفت قواعد تصميم الجدول ببساطة. مرة أخرى في 1.5-2002 كانوا هناك، ولكن بالفعل في 1.5-2004 اختفوا. في الحياة الحقيقيةنقوم بإعداد الجداول وفقًا لـ ESKD.
التطبيقات. لا يشير المعيار إلى ما إذا كانت الأشكال والصيغ والجداول من الملاحق مدرجة في القائمة العامة. وبالمثل، لا يُقال ما إذا كان جدول المحتويات يحتاج إلى الكشف عن بنية التطبيق إذا كان يحتوي على أقسامه وفقراته وما إلى ذلك. في ممارستنا، نحن لا نكشف عن الدواخل الداخلية للتطبيقات.
وأخيرا، ينبغي أن يقال شيئا عن المسافة البادئة. المسافة البادئة للفقرة المكونة من 5 أحرف شائعة في:
- خط أحمر؛
- المسافة البادئة لعنصر بنية المستند بعد القسم (قسم فرعي، جملة، فقرة فرعية)؛
- عنصر التعداد
في هذه الحالة، تتم محاذاة النص الموجود في السطر التالي بعد السطر ذي المسافة البادئة إلى الهامش الأيسر. غالبًا ما تكون هناك أخطاء عندما تقفز المسافة البادئة - الخط الأحمر - قيمة واحدة، رقم العنصر - لنا بفاصل زمني مختلف، في المسافات البادئة المتداخلة في القوائم - وهذا ضروري بشكل عام.
في الأجزاء التالية، أخطط للوصول إلى نهاية قائمة معايير ESPD.
G O S U D A R S T V E N N Y S T A N D A R T S O U Z A S S R
|
النظام الموحد لتوثيق البرامج |
غوست 19.101-77(ST SEV 1626-79) |
أنواع البرامج ووثائق البرنامج |
|
النظام المتحد لتوثيق البرامج. أنواع البرامج ووثائق البرنامج |
تاريخ التقديم من 01.01.80
تحدد هذه المواصفة القياسية أنواع البرامج ووثائق البرامج لأجهزة الكمبيوتر والمجمعات والأنظمة، بغض النظر عن غرضها ونطاقها.
يتوافق المعيار تمامًا مع ST SEV 1626-79.
1. أنواع البرامج
1.1. يمكن تحديد البرنامج (وفقًا لـ GOST 19781-90) واستخدامه بشكل مستقل و (أو) كجزء من برامج أخرى.
1.2. وتنقسم البرامج إلى أنواع موضحة في الجدول. 1
الجدول 1
1.3. يمكن استخدام الوثائق التي تم تطويرها للبرنامج لتنفيذ البرنامج ونقله على وسائط التخزين، وكذلك لتصنيع منتج برمجي.
1.2,1.3.
2. أنواع وثائق البرنامج
2.1. تتضمن وثائق البرامج المستندات التي تحتوي على المعلومات اللازمة لتطوير البرامج وإنتاجها وصيانتها وتشغيلها.
2.2. يتم عرض أنواع وثائق البرنامج ومحتوياتها في الجدول. 2.
الجدول 2
| نوع وثيقة البرنامج | محتويات وثيقة السياسة |
|---|---|
| مواصفة | تكوين البرنامج وتوثيقه |
| قائمة الشركات التي تقوم بتخزين وثائق البرنامج الأصلية | |
| نص البرنامج | تسجيل البرنامج مع التعليقات اللازمة |
| وصف البرنامج | معلومات حول البنية المنطقية وتشغيل البرنامج |
| المتطلبات التي يجب التحقق منها عند اختبار البرنامج، وكذلك إجراءات وطرق التحكم بها | |
| الاختصاصات | الغرض ونطاق البرنامج، المتطلبات الفنية والتقنية والاقتصادية والخاصة بالبرنامج، المراحل وشروط التطوير اللازمة، أنواع الاختبارات |
| مذكرة توضيحية | مخطط الخوارزمية، وصف عام للخوارزمية و (أو) تشغيل البرنامج، بالإضافة إلى تبرير القرارات الفنية والتقنية والاقتصادية المعتمدة |
| الوثائق التشغيلية | معلومات لضمان عمل البرنامج وتشغيله |
(طبعة منقحة، تعديل رقم 1).
2.3. وترد في الجدول 3 أنواع الوثائق التشغيلية ومحتوياتها.
الجدول 3
| نوع الوثيقة التشغيلية | محتويات الوثيقة التشغيلية |
|---|---|
| قائمة الوثائق التشغيلية للبرنامج | |
| استمارة | الخصائص الرئيسية للبرنامج واكتماله ومعلومات حول تشغيل البرنامج |
| وصف التطبيق | معلومات حول الغرض من البرنامج، ونطاق التطبيق، والأساليب المستخدمة، وفئة المشكلات التي يتعين حلها، وقيود الاستخدام، والحد الأدنى من تكوين الأجهزة |
| معلومات للتحقق وضمان الأداء وتخصيص البرنامج لشروط تطبيق معين | |
| دليل المبرمج | معلومات لاستخدام البرنامج |
| دليل المشغل | معلومات لضمان إجراء الاتصال بين المشغل ونظام الكمبيوتر أثناء تنفيذ البرنامج |
| وصف اللغة | وصف بناء الجملة ودلالات اللغة |
| معلومات حول استخدام برامج الاختبار والتشخيص عند صيانة المعدات التقنية |
(طبعة منقحة، تعديل رقم 1).
2.4. اعتمادًا على طريقة التنفيذ وطبيعة التطبيق، تنقسم وثائق البرنامج إلى أصلية ونسخة ونسخة (GOST 2.102-68)، مخصصة لتطوير البرنامج وصيانته وتشغيله.
2.5. يتم عرض أنواع وثائق البرنامج التي تم تطويرها في مراحل مختلفة وأكوادها في جدول النقر. 4.
الجدول 4
| كود نوع الوثيقة | نوع الوثيقة | مراحل التطوير | |||
|---|---|---|---|---|---|
| مشروع التصميم | مشروع فني | مسودة العمل | |||
| عنصر | معقد | ||||
| - | مواصفة | - | - | ||
| 05 | قائمة أصحاب الأصلي | - | - | - | |
| 12 | نص البرنامج | - | - | ||
| 13 | وصف البرنامج | - | - | ||
| 20 | قائمة الوثائق التشغيلية | - | - | ||
| 30 | استمارة | - | - | ||
| 31 | وصف التطبيق | - | - | ||
| 32 | دليل مبرمج النظام | - | - | ||
| 33 | دليل المبرمج | - | - | ||
| 34 | دليل المشغل | - | - | ||
| 35 | وصف اللغة | - | - | ||
| 46 | دليل الصيانة | - | - | ||
| 51 | برنامج ومنهجية الاختبار | - | - | ||
| 81 | مذكرة توضيحية | - | - | ||
| 90-99 | وثائق أخرى | ||||
أسطورة:
- الوثيقة إلزامية؛
- الوثيقة إلزامية للمكونات التي لها استخدام مستقل؛
- يتم تحديد الحاجة إلى إعداد وثيقة في مرحلة التطوير والموافقة على المواصفات الفنية؛
- - لم يتم إعداد الوثيقة.
2.2-2.5. (طبعة منقحة، تعديل رقم 1).
2.6. يُسمح بدمج أنواع معينة من المستندات التشغيلية (باستثناء قائمة المستندات التشغيلية والنموذج). يشار إلى الحاجة إلى الجمع بين هذه الوثائق في المواصفات الفنية. يتم تعيين اسم وتعيين للمستند المدمج لأحد المستندات المدمجة.
يجب أن تحدد المستندات المدمجة المعلومات التي يجب تضمينها في كل مستند يتم دمجه.
2.7. في مرحلة تطوير المواصفات الفنية والموافقة عليها، يتم تحديد الحاجة إلى وضع مواصفات فنية تحتوي على متطلبات إنتاج البرنامج ومراقبته وقبوله.
يتم تطوير المواصفات الفنية في مرحلة "التصميم التفصيلي".
2.8. يتم تحديد الحاجة إلى وضع المواصفات الفنية للمكونات غير المخصصة للاستخدام المستقل، والمجمعات المدرجة في المجمعات الأخرى، بالاتفاق مع العميل.
(مقدم بشكل إضافي، التعديل رقم 1).
إعادة الإصدار (نوفمبر 1987) مع التغيير رقم 1، تمت الموافقة عليه في يونيو 1981 (IUS 9-81)
-
17 أبريل 2015برامج مجانية للويندوز تحميل مجاني تحميل تطبيق جوجل ايرث -
17 أبريل 2015نافذة التنقل للأخطاء 1s 8
