4.1. سیستم مورد نیاز عمومی

4.1.1. الزامات ساختار و عملکرد سیستم.
4.1.2. الزامات تعداد و صلاحیت پرسنل سیستم و نحوه کار آن.
4.1.3. الزامات قابلیت اطمینان
4.1.4. الزامات ایمنی
4.1.5. الزامات ارگونومی و زیبایی فنی.
4.1.6. الزامات برای بهره برداری و نگهداری.
4.1.7. الزامات حفاظت از اطلاعات در برابر دسترسی غیرمجاز؛
4.1.8. الزامات ایمنی اطلاعات در صورت بروز حوادث.
4.1.9. الزامات محافظت در برابر تأثیرات خارجی.
4.1.10. الزامات ثبت اختراع
4.1.11. هر گونه الزامات اضافی

4.2. الزامات برای توابع (وظایف) انجام شده توسط سیستم.

(فهرست توابع (وظایف) که باید خودکار شوند؛ برنامه زمانی برای اجرای هر عملکرد (وظیفه)؛ الزامات برای کیفیت اجرای هر عملکرد (وظیفه)، برای شکل ارائه اطلاعات خروجی، برای دقت و زمان اجرا، برای قابلیت اطمینان خروجی نتایج؛ فهرست و معیارهای شکست برای هر تابع (وظیفه) که الزامات قابلیت اطمینان برای آن تعریف شده است)

4.3. الزامات انواع وثیقه.

4.3.1. الزامات برای پشتیبانی ریاضی سیستم.

(الزامات ترکیب، دامنه و روش‌های استفاده از روش‌ها و مدل‌های ریاضی، الگوریتم‌ها و الگوریتم‌های معمولی که در سیستم توسعه داده می‌شوند)

4.3.2. الزامات پشتیبانی اطلاعاتی سیستم

(الزامات برای ترکیب، ساختار و روش های سازماندهی داده ها در سیستم؛ برای تبادل اطلاعات بین اجزای سیستم؛ برای سازگاری اطلاعات با سیستم های مرتبط؛ برای استفاده از سیستم های مدیریت پایگاه داده؛ برای ساختار فرآیند جمع آوری، پردازش، انتقال. داده ها در سیستم و ارائه داده ها؛ برای محافظت از داده ها از تخریب در هنگام تصادفات و قطع برق سیستم؛ برای کنترل، ذخیره سازی، به روز رسانی و بازیابی داده ها)

4.3.3. الزامات پشتیبانی زبانی سیستم.

(الزامات استفاده در سیستم زبان های برنامه نویسی سطح بالا، زبان های تعامل با کاربر و ابزارهای فنی سیستم، و همچنین الزامات کدگذاری و رمزگشایی داده ها، زبان های ورودی-خروجی داده ها، زبان های دستکاری داده ها، ابزارهای توصیف حوزه موضوعی (مدل سازی اطلاعات)، روش های سازماندهی گفتگوها با کاربر و غیره)

4.3.4. نرم افزار مورد نیاز سیستم

(لیست محصولات نرم افزاری دارای مجوز که وجود آنها برای عملکرد سیستم در حالت عادی ضروری است)

4.3.5. الزامات پشتیبانی فنی

(الزامات انواع سخت افزار، نرم افزار و سیستم های سخت افزاری و سایر اجزای قابل استفاده در سیستم؛ برای ویژگی های عملکردی، طراحی و عملیاتی سخت افزار سیستم)

4.3.6. الزامات سازمانی

(الزامات ساختار و عملکرد بخش های درگیر در عملکرد سیستم یا اطمینان از عملکرد؛ برای سازماندهی عملکرد سیستم و روش تعامل پرسنل شی اتوماسیون؛ برای محافظت در برابر اقدامات اشتباه پرسنل از سیستم)

G O S U D A R S T V E N Y S T A N D A R T S O YU Z A S S R

تاریخ معرفی 01.01.90

این استاندارد برای سیستم های خودکار (AS) مورد استفاده در زمینه های مختلف فعالیت (مدیریت، تحقیق، طراحی و غیره) از جمله ترکیب آنها اعمال می شود و انواع، نام، کامل بودن و تعیین اسناد توسعه یافته در مراحل ایجاد AU را تعیین می کند. GOST 24.601 را ایجاد کرد.

توضیحی در مورد اصطلاحات استفاده شده در این استاندارد در پیوست 1 آورده شده است.

1. انواع و نام اسناد

1.1. ترکیب انواع اسناد توسعه یافته در مرحله "تحقیق و توجیه ایجاد AS" مطابق با بخش دوم تعیین می شود. 3 GOST 24.601، بر اساس نتایج مورد نیاز این مرحله.

1.2. در مرحله "شرایط مرجع"، یک شرایط مرجع (TOR) برای ایجاد یک سیستم خودکار مطابق با الزامات GOST 34.602 ایجاد می شود.

مجاز به توسعه مشخصات فنی خصوصی برای سیستم های فردی (زیر سیستم ها، مجتمع های وظیفه، مجتمع های نرم افزاری و سخت افزاری، اجزای سخت افزار و نرم افزار و غیره) است.

1.3. انواع اسناد توسعه یافته در مراحل "طراحی پیش نویس"، "طراحی فنی"، "مستندات کاری" در جدول آورده شده است. یکی

میز 1

1.3.1. نام اسناد خاصی که هنگام طراحی سیستم به عنوان یک کل یا بخشی از آن ایجاد می شود در جدول آورده شده است. 2.

جدول 2

(ویرایش تغییر یافته، کشیش شماره 1)

یادداشت:

• 1. عناوین زیر در جدول پذیرفته شده است:
  • EP - طراحی اولیه؛
  • TP - پروژه فنی؛
  • RD - اسناد کاری؛
  • OR - راه حل های گسترده سیستم؛
  • OO - راه حل هایی برای پشتیبانی سازمانی؛
  • TO - راه حل های پشتیبانی فنی؛
  • IO - راه حل هایی برای پشتیبانی اطلاعات؛
  • ON - راه حل های نرم افزاری؛
  • MO - راه حل های نرم افزاری.
• 2. علامت X - نشان دهنده تعلق به برآوردهای طراحی یا اسناد عملیاتی است.
• 3. نامگذاری اسنادی با همین نام بسته به تصمیمات طراحی اتخاذ شده در هنگام ایجاد سیستم ایجاد می شود.

1.3.2. انواع اسناد برای ابزارهای نرم افزاری مورد استفاده برای ایجاد AS (قطعات آن) - طبق GOST 19.101.77.

1.3.3. انواع اسناد برای وسایل فنی مورد استفاده در ایجاد AU (قطعات آن) - طبق GOST 2.102 و طبق GOST 2.601 از نظر اسناد عملیاتی.

1.3.4. بسته به روش های طراحی استفاده شده و ویژگی های AU ایجاد شده، مجاز است:

• 1) اسناد گروهی و اساسی را مطابق با Sec. 1، 3، 4، 6 GOST 2.113;
• 2) اسناد را در بخش های مستقل جداگانه مطابق با بخش های سند اصلی صادر کنید.
• 3) دامنه اسناد ایجاد شده توسط این استاندارد را گسترش دهید.

1.4. در مراحل "تولید اجزای غیر سریالی KSA" و "راه اندازی"، اسناد سازمانی و اداری زیر تهیه می شود:

• 1) عمل تکمیل کار؛
• 2) عمل پذیرش برای عملیات آزمایشی؛
• 3) عمل پذیرش برای عملیات تجاری؛
• 4) برنامه کاری؛
• 5) دستور در مورد ترکیب کمیته پذیرش؛
• 6) دستور انجام کار؛
• 7) برنامه کاری؛
• 8) گزارش تست؛
• 9) پروتکل توافق.

2. کامل بودن اسناد

2.1. فهرست اسامی اسناد در حال توسعه و کامل بودن آنها برای سیستم و قطعات آن باید در شرایط مرجع برای ایجاد یک سیستم خودکار (زیر سیستم) تعیین شود.

توجه داشته باشید.کامل بودن اسناد طراحی و برآورد مطابق با قوانین تعیین شده توسط سیستم اسناد طراحی برای ساخت و ساز (SPDS) تعیین می شود.

2.2. برای هر مجموعه باید فهرستی از اسناد تهیه شود.

2.3. کامل بودن اسنادی که توسعه، ساخت، پذیرش و نصب تجهیزات فنی را تضمین می کند مطابق با GOST 2.102 است. کامل بودن اسناد عملیاتی این وجوه مطابق با GOST 2.601 است.

2.4. کامل بودن اسناد نرم افزار کامپیوتری - مطابق با GOST 19.101.77.

2.5. در صورت توسعه مستقل بخشی از سیستم، اسناد مربوط به آن مطابق با الزامات این استاندارد تکمیل می شود.

3. نمادهای سند

3.1. به هر سند توسعه یافته باید یک نام مستقل اختصاص داده شود. سندی که بر روی حامل های داده مختلف ساخته شده است باید دارای یک نام باشد. حرف "M" به نام اسناد ساخته شده در رسانه ماشین اضافه می شود.

اسناد وام گرفته شده، نامگذاری قبلی خود را حفظ می کنند.

3.2. این قوانین برای اسنادی که قوانین تعیین آنها توسط استانداردهای دولتی سایر سیستم های اسناد تنظیم می شود، اعمال نمی شود.

3.3. تعیین سند دارای ساختار زیر است:

پیش> ___________
|___________|. XX. XX. ایکس- ایکس. م
تعیین سیستم | | | | | |
(بخش هایی از سیستم) | | | | | |
کد سند | | | | |
شماره سریال سند یک | | | |
نام ها | | | |
شماره ویرایش سند | | |
شماره قطعه سند | |
علامت سند اجرا شده روی ماشین |
رسانه |

3.3.1. قوانین تعیین یک سیستم (بخشی از یک سیستم) در پیوست 2 آورده شده است.

3.3.2. کد سند از دو کاراکتر الفبایی تشکیل شده است. کد اسناد تعریف شده توسط این استاندارد مطابق با ستون 3 جدول الصاق می شود. 2. کد اسناد اضافی به صورت زیر تشکیل می شود: کاراکتر اول یک حرف است که نوع سند را مطابق جدول نشان می دهد. 1، کاراکتر دوم یک عدد یا حرف است که شماره سریال یک سند از این نوع را نشان می دهد.

کد سند با یک نقطه از علامت قبلی جدا می شود.

3.3.3. شماره سریال اسنادی با همین نام (2 کاراکتر) از دومی شروع می شود و با یک نقطه از علامت قبلی جدا می شود.

3.3.4. شماره ویرایش سند اختصاص داده می شود که از دوم به ترتیب صعودی از 2 تا 9 شروع می شود و با یک نقطه از مقدار قبلی جدا می شود. شماره ویرایش بعدی در موارد حفظ (نه لغو) نسخه قبلی اختصاص داده می شود.

3.3.5. شماره قسمت سند با خط فاصله از نام قبلی جدا می شود. اگر سند از یک قسمت تشکیل شده باشد، خط فاصله کنار گذاشته نمی شود و شماره قطعه سند اختصاص داده نمی شود.

3.3.6. در صورت لزوم علامت سندی که روی رسانه ماشینی ساخته شده است وارد می شود. حرف "M" با یک نقطه از علامت قبلی جدا می شود.

پیوست 1
ارجاع

توضیح شرایط استفاده شده در این استاندارد

اسناد برای سیستم خودکار- مجموعه ای از اسناد مرتبط به هم که به طور کامل تمام تصمیمات مربوط به ایجاد و بهره برداری از سیستم و همچنین اسنادی که انطباق سیستم را با الزامات مشخصات فنی و آمادگی آن برای بهره برداری (عملکرد) تأیید می کند.

اسناد طراحی و برآورد نیروگاه های هسته ای- بخشی از اسناد NPP که برای انجام کارهای ساخت و ساز و نصب مربوط به ایجاد NPP تهیه شده است.

اسناد کاری برای AU- بخشی از اسناد NPP، لازم برای ساخت، ساخت، نصب و تنظیم سیستم خودکار به عنوان یک کل، و همچنین نرم افزار و سخت افزار، نرم افزار و مجتمع های روش شناختی و اجزای پشتیبانی فنی، نرم افزاری و اطلاعاتی شامل در سیستم

قوانین تعیین سیستم ها و قطعات آنها

1. ساختار تعیین یک سیستم خودکار یا بخشی از آن به شکل زیر است:

2. کد سازمان توسعه دهنده مطابق با طبقه بندی کننده همه اتحادیه های شرکت ها، مؤسسات و سازمان ها (OKPO) یا طبق قوانین تعیین شده توسط صنعت NTD اختصاص داده می شود.

3. کد مشخصه طبقه بندی سیستم یا بخشی از آن (زیر سیستم، مجتمع، جزء) مطابق با قوانین تعیین شده در صنعت بر اساس زیر کلاس 425 طبقه بندی کننده محصولات اتحادیه و / یا طبقه بندی کننده اتحادیه زیرسیستم ها و مجموعه وظایف سیستم های کنترل خودکار - 1 84 154.

4. شماره ثبت سریال سیستم (بخشی از سیستم) توسط سرویس سازمان توسعه دهنده که مسئولیت نگهداری پرونده و حسابداری تعیین ها را بر عهده دارد، اختصاص می یابد. برای هر کد مشخصه ثبت، شماره های ثبت از 001 تا 999 تخصیص داده می شود.

داده های اطلاعاتی

1. توسعه و معرفی شد
کمیته دولتی استانداردهای اتحاد جماهیر شوروی
وزارت ابزار دقیق، اتوماسیون و سیستم های کنترل اتحاد جماهیر شوروی

مجریان
آی پی واخلاکوف؛ Ya.G. ویلنچیک؛ N.M. ویتسین، دکتری. فن آوری علوم; F.R. سمور، Ph.D. فن آوری علوم; S.V. گرشین; بی.ا. دیوکوف; L.M. سیدنبرگ، Ph.D. فن آوری علوم; A.P. ایگوشین، Ph.D. فن آوری علوم; یو.بی. ایرز، دکتری. فن آوری علوم (رهبر موضوع)؛ V.Yu. کورولف؛ I.A. کوروتیف; E.S. کرانکوف، Ph.D. فن آوری علوم; در و. ماخناچ، دکتر تک. علوم; است. میتیایف; صبح. مستفین; E.I. نکریلوف، دکتری. فن آوری علوم; V.F. پوپوف به عنوان مثال. ساوینا؛ N.V. استپانچیکوف؛ VC. چیستوف، دکتری. فن آوری علوم; P.A. Shalaev، Ph.D. فن آوری علوم

2. تصویب و معرفی شده توسط فرمان کمیته دولتی استانداردهای اتحاد جماهیر شوروی مورخ 24 مارس 1989 شماره 664

3. مدت چک - 1999; فرکانس بازرسی - 10 سال

4. به جای GOST 24.101-80، GOST 24.102-80، RD 50-617-86

5. مقررات مرجع و اسناد فنی

اصلاحات شماره 1، (تصویب و اجرا شده توسط فرمان کمیته دولتی اتحاد جماهیر شوروی برای مدیریت کیفیت محصول و استانداردهای مورخ 12.29.90 شماره 3468، تاریخ معرفی 01.07.91) معرفی شد.

GOST 19.101-77

گروه T55

استاندارد بین ایالتی

سیستم یکپارچه اسناد برنامه

انواع برنامه ها و اسناد برنامه

سیستم یکپارچه برای اسناد برنامه انواع برنامه ها و اسناد برنامه

MKS 35.080

تاریخ معرفی 1980-01-01

با فرمان کمیته دولتی استانداردهای شورای وزیران اتحاد جماهیر شوروی مورخ 20 مه 1977 N 1268، تاریخ معرفی به تاریخ 01.01.80 تعیین شد.

EDITION (ژانويه 2010) با اصلاحيه شماره 1 تصويب شده در ژوئن 1981 (IUS 9-81).


این استاندارد انواع برنامه‌ها و اسناد نرم‌افزاری را برای رایانه‌ها، مجتمع‌ها و سیستم‌ها بدون توجه به هدف و دامنه آنها تعیین می‌کند.

استاندارد به طور کامل با ST SEV 1626-79 مطابقت دارد.

(چاپ تغییر یافته، کشیش N 1).

1. انواع برنامه ها

1. انواع برنامه ها

1.1. این برنامه (طبق GOST 19781-90) ممکن است به طور مستقل و (یا) به عنوان بخشی از برنامه های دیگر شناسایی و استفاده شود.

1.2. برنامه ها به انواع داده شده در جدول 1 تقسیم می شوند.

میز 1

1.3. اسناد توسعه یافته برای برنامه را می توان برای پیاده سازی و انتقال برنامه بر روی حامل های داده و همچنین برای ساخت محصول نرم افزاری استفاده کرد.

1.2، 1.3. (چاپ تغییر یافته، کشیش N 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. (چاپ تغییر یافته، کشیش N 1).

2.6. ترکیب انواع خاصی از اسناد عملیاتی (به استثنای بیانیه اسناد عملیاتی و فرم) مجاز است. نیاز به ترکیب این اسناد در شرایط مرجع ذکر شده است. به سند ادغام شده نام و نام یکی از اسناد ادغام شده اختصاص داده می شود.

اسناد ادغام شده باید حاوی اطلاعاتی باشد که باید در هر سند ادغام شده گنجانده شود.

2.7. در مرحله توسعه و تصویب شرایط مرجع، نیاز به تهیه شرایط فنی حاوی الزامات برای ساخت، کنترل و پذیرش برنامه تعیین می شود.

مشخصات در مرحله "طراحی دقیق" توسعه یافته است.

2.8. نیاز به تهیه مشخصات فنی برای قطعاتی که برای استفاده مستقل در نظر گرفته نشده اند و مجتمع های موجود در سایر مجتمع ها با توافق مشتری تعیین می شود.

(معرفی علاوه بر این، کشیش N 1).



متن الکترونیکی سند
تهیه شده توسط Kodeks JSC و تأیید شده در برابر:
انتشار رسمی
سیستم نرم افزاری یکپارچه
مستندات: شنبه GOSTs. -
M.: Standartinform، 2010

استفاده از الزامات سری GOST 19 و 34 هنگام تهیه اسناد در پروژه های فناوری اطلاعات برای ساختارهای دولتی

مقدمه

دنیای مدرن بدون ابزارهای اتوماسیون غیرقابل تصور است که به سرعت در همه جا در ساختارهای تجاری و دولتی معرفی می شوند که عملکرد کارآمدتر تجارت و بخش عمومی را تضمین می کند. معرفی برخی از ابزارهای اتوماسیون، به عنوان یک قاعده، شامل توسعه اسناد در مراحل مختلف است، مانند: تشکیل الزامات برای یک سیستم اطلاعاتی؛ در مرحله طراحی فنی؛ مراحل توسعه اسناد کاری.

در عین حال، شرایطی وجود دارد که توسعه دهندگان مستندات و مشتری همیشه ایده یکسانی در مورد تعداد، ساختار و محتوای اسناد توسعه یافته ندارند. این منجر به این واقعیت می شود که نتایج کار برای مشتری مناسب نیست و منابع اضافی باید برای نهایی کردن اسناد صرف شود. استفاده از الزامات GOST در توسعه اسناد به شما امکان می دهد از چنین شرایطی اجتناب کنید، زیرا علیرغم نظر غالب مبنی بر اینکه استانداردها از فناوری های مدرن عقب هستند، GOST ساختار واضحی را برای مستندات در حال توسعه ارائه می دهد، دارای ویژگی های کامل و سازگاری است و همچنین مسائل بحث برانگیز بین پیمانکار و مشتری در مورد نتایج کار را حذف می کند. علاوه بر این، در اکثر سازمان های دولتی، توسعه اسناد مطابق با GOST یک پیش نیاز است. در مرحله بعد، ما سعی خواهیم کرد پیچیدگی های توسعه اسناد را با توجه به الزامات GOST درک کنیم.

هنگام توسعه سیستم‌های خودکار (AS) مطابق با GOST 34 در پروژه‌های فناوری اطلاعات برای سازمان‌های دولتی، اغلب این سؤال مطرح می‌شود: براساس کدام GOST ها باید مستندات تهیه شود؟ در GOST 34 هیچ دستورالعمل صریحی در مورد استانداردهایی برای تهیه اسناد خاص که به عنوان بخشی از ایجاد AU ایجاد شده است وجود ندارد، به جز الزامات طراحی مشخصات فنی. بیایید سعی کنیم در صورت عدم وجود دستورالعمل های دقیق در قرارداد دولتی یا شرایط مرجع رقابتی (TOR) دریابیم که از کدام GOST ها در تهیه اسناد استفاده می شود. این مواد در درجه اول برای متخصصان فناوری اطلاعات در نظر گرفته شده است که می خواهند بدانند اسناد چگونه در پروژه های فناوری اطلاعات مطابق با الزامات GOST تهیه می شود.

تعریف استانداردهای مستندسازی

اجرای اسناد در GOST 34 به نوع سند (طراحی یا نرم افزار) و مرحله ایجاد AS که در آن سند آماده می شود بستگی دارد.

فهرست اسناد توسعه یافته در مراحل مختلف ایجاد AU در GOST 34.201-89 "انواع، کامل بودن و تعیین اسناد هنگام ایجاد سیستم های خودکار" آمده است. این شامل الزامات زیر است:

• در مرحله "شرایط مرجع"، یک TOR برای ایجاد یک AU مطابق با GOST 34.602 -89 "شرایط مرجع برای ایجاد یک سیستم خودکار" ایجاد می شود.
• انواع اسناد سیاست GOST 19.101-77"سیستم یکپارچه اسناد برنامه. انواع برنامه ها و اسناد برنامه. اینها شامل کتابچه های مختلف مانند کتابچه راهنمای کاربر است.
• انواع اسناد طراحی، توسعه یافته در مراحل مختلف ایجاد AS توسط تعیین می شود GOST 2.102-2013"سیستم یکپارچه اسناد طراحی. انواع و کامل بودن اسناد طراحی. به عنوان مثال، این موارد شامل بیانیه های پیش نویس و طراحی فنی، لیستی از محصولات خریداری شده، یادداشت های توضیحی پیش نویس، طرح های فنی است.

حال بیایید نگاهی دقیق تر به نحوه تعریف استانداردهای طراحی در پروژه های مختلف بیندازیم.

ثبت TK

با TK، همه چیز کاملاً واضح است: GOST 34.602-89 استانداردی را برای طراحی آن ارائه می دهد: بند 3.2. بیان می کند که "TK برای NPP مطابق با الزامات GOST 2.105 بر روی ورق های A4 مطابق با GOST 2.301 بدون قاب، کتیبه اصلی و ستون های اضافی به آن ترسیم شده است."

ثبت اسناد برنامه

با اسناد خط مشی توسعه یافته به عنوان بخشی از یک پروژه فناوری اطلاعات، دستورالعمل روشنی نیز برای استفاده از سری GOST 19 از نظر طراحی وجود دارد: GOST 19.101-77 فوق بخشی از سری GOST 19 سیستم یکپارچه برای مستندات برنامه (ESPD) است. ) سلسله. ESPD مجموعه ای از استانداردهای دولتی فدراسیون روسیه است که قوانین مرتبط با هم را برای توسعه، اجرا و گردش برنامه ها و اسناد برنامه ایجاد می کند.

اسناد در ESPD مطابق با GOST 19.104-78 "سیستم یکپارچه اسناد برنامه" تهیه شده است. کتیبه های اصلی، GOST 19.105-78 "سیستم یکپارچه اسناد برنامه. الزامات عمومی برای اسناد برنامه، GOST 19.106-78 "سیستم یکپارچه اسناد برنامه". الزامات برای اسناد برنامه ساخته شده به صورت چاپی.

ثبت اسناد طراحی

اکنون GOST 2.102-2013 را در نظر بگیرید. این استاندارد در سری GOST های سری 2 "سیستم یکپارچه برای اسناد طراحی" (ESKD) گنجانده شده است. ESKD مجموعه ای بین ایالتی از استانداردها است که هنجارها و قوانین مرتبط با یکدیگر را برای توسعه، اجرا و گردش اسناد طراحی ایجاد و در تمام مراحل چرخه عمر محصول (در طول طراحی، ساخت، بهره برداری، تعمیر و غیره) ایجاد و اعمال می کند.

مستندات در ESKD بر اساس چندین استاندارد تنظیم می شود. بیشترین استفاده از آنها (در رابطه با حوزه فناوری اطلاعات) GOST 2.105-95 "سیستم یکپارچه برای اسناد طراحی است. الزامات عمومی برای اسناد متنی" و GOST 2.106-96 "سیستم یکپارچه برای اسناد طراحی". اسناد متنی

در نگاه اول، نحوه تهیه اسناد برای AU از سری GOST 34 مشخص نیست. اغلب، در چارچوب یک پروژه فناوری اطلاعات، به ویژه برای مشتریان دولتی، الزاماتی در TOR برای تهیه اسناد مطابق با GOST 2.105-95 و GOST 2.106-96 وجود دارد. اما آیا در صورت عدم وجود الزامات صریح برای ثبت نام، لازم است اسناد مطابق با این GOST ها تهیه شود؟

چگونه ترتیب دهیم؟

سری 2 GOST شامل الزامات برای هدف هر استاندارد است و شاخه کاربرد آن را نشان می دهد: GOST 2.102-2013 - استاندارد انواع و کامل بودن اسناد طراحی را برای محصولات همه صنایع تعیین می کند.

اگر GOST 2.102-2013 برای محصولات همه صنایع از جمله بخش فناوری اطلاعات اعمال می شود، بیایید ببینیم سند طراحی چیست؟

طبق GOST 2.001-2013 "سیستم یکپارچه برای اسناد طراحی (ESKD). مقررات عمومی":

الف) «3.1.2 سند طراحی:سندی که به صورت جداگانه یا ترکیبی با سایر اسناد، طرح محصول را تعیین می کند و دارای بخش اساسی و ضروری از جمله امضاهای ثابت است.

ب) «3.1.5 مستندات طراحی:مجموعه ای از اسناد طراحی حاوی داده های لازم برای طراحی (توسعه)، ساخت، کنترل، پذیرش، تحویل، بهره برداری، تعمیر، نوسازی، دفع محصول"

با مقایسه منطقی الزامات ترکیب اسناد پروژه فناوری اطلاعات ما با مفاد ذکر شده در بالا، و تعیین اینکه آیا هر یک از اسناد به طراحی اشاره دارد یا خیر و تکمیل طراحی مطابق با استانداردهای سری GOST 2، این امر می تواند متوقف شود.

GOSTهای اصلی سری 2 برای یک پروژه فناوری اطلاعات از نظر طراحی

اکنون بیایید به GOST های اصلی سری 2 نگاه کنیم که اغلب برای کارهای کاغذی در یک پروژه فناوری اطلاعات استفاده می شود. به عنوان یک قاعده، از نظر استفاده از طراحی:

GOST 2.105-95 - استاندارد الزامات کلی را برای اجرای اسناد متنی برای محصولات مهندسی، ابزار دقیق و ساخت و ساز تعیین می کند.

GOST 2.106-96 - استاندارد فرم ها و قوانینی را برای اجرای اسناد طراحی برای محصولات مهندسی و ابزار دقیق تعیین می کند.

خواننده ممکن است سوالی داشته باشد، اگر این GOST ها را برای محصولات مهندسی مکانیک و ساخت ابزار در نظر گرفته اند، می توانیم برای AU اعمال کنیم؟

طبق تعریف دایره المعارف بزرگ شوروی، «ابزارسازی شاخه‌ای از مهندسی مکانیک است که وسایلی برای اندازه‌گیری، تجزیه و تحلیل، پردازش و ارائه اطلاعات، دستگاه‌های کنترل، سیستم‌های کنترل خودکار و خودکار تولید می‌کند. حوزه علم و فناوری که ابزارهای اتوماسیون و سیستم‌های کنترل را توسعه می‌دهد، یعنی هر چیزی که در موضوع ما از فناوری اطلاعات مدرن مورد نیاز است.

علاوه بر این، اگر به GOST 34.003-90 "سیستم های خودکار" نگاه کنید. اصطلاحات و تعاریف"، این استاندارد AU را به عنوان "سیستمی متشکل از پرسنل و مجموعه ای از وسایل برای خودکارسازی فعالیت های خود، پیاده سازی فناوری اطلاعات برای انجام وظایف تعیین شده" تعریف می کند.

بنابراین، AU متعلق به صنعت ابزارسازی است و بنابراین، اسناد طراحی AU مطابق با GOST 2.105-95 و GOST 2.106-96 تهیه می شود.

حال بیایید به نکات اصلی طراحی اسناد پروژه مطابق با GOST 2.105-95 و GOST 2.106-96 نگاه کنیم.

نکات برجسته در طراحی مطابق با GOST 2. 105

پارامترهای اصلی طراحی را طبق سری 2 GOST در نظر بگیرید.

طبق GOST 2.105-95، فاصله قاب فرم تا مرزهای متن در ابتدا و انتهای خطوط باید حداقل 3 میلی متر باشد. فاصله خط بالا یا پایین متن تا فریم بالا یا پایین باید حداقل 10 میلی متر باشد. پاراگراف های متن با یک تورفتگی برابر با پنج ضربه ماشین تحریر (15 - 17 میلی متر) شروع می شوند.

GOST 2.105-95 پارامترهایی را برای قالب بندی متن به شکل الکترونیکی تعریف نمی کند: نام قلم، ارتفاع قلم، فاصله بین خطوط. بنابراین، پارامترهای پردازش اسناد به صورت الکترونیکی، به عنوان یک قاعده، موضوع توافق با مشتری است.

در ابتدای کار بر روی ثبت نام به صورت الکترونیکی، پارامترهای قالب بندی تعیین می شود:

• قالب پاراگراف های متن - فونت استفاده شده، ارتفاع فونت، فاصله بین خطوط.
• قالب برای هر عنوان بر اساس سطوح (1، 2، 3) - فونت استفاده شده، ارتفاع قلم، تورفتگی در سانتی متر، فاصله بین خطوط.

جدول - فونت متن استفاده شده، فاصله خطوط، ضخامت حاشیه جدول، عرض جدول، تورفتگی سلول، عنوان قرار داده شده در بالای جدول. قالب بندی عنوان جدول مانند متن متن سند انجام می شود. طبق GOST 2.105-95، ارتفاع ردیف های جدول باید حداقل 8 میلی متر باشد. ارتفاع فونت ردیف های جدول نیز با مشتری قابل توافق است.

تصاویر در سند باید در مرکز قرار گیرند. عنوان دقیقاً در زیر تصویر قرار داده شده است. قالب عنوان مانند متن سند است.

قوانین طراحی جدول

جدول بسته به اندازه آن در زیر متنی که ابتدا به آن اشاره شده است یا در صفحه بعد و در صورت لزوم در ضمیمه سند قرار می گیرد.

جداول، به استثنای جداول کاربردی، از طریق شماره گذاری با اعداد عربی شماره گذاری می شوند. به عنوان مثال: "جدول 1".

جداول هر برنامه با شماره گذاری جداگانه با اعداد عربی با اضافه کردن نام برنامه قبل از شماره مشخص می شود. به عنوان مثال: "جدول B.1".

شماره گذاری جداول داخل بخش مجاز است. در این حالت، شماره جدول شامل شماره بخش و شماره ترتیبی جدول است که با یک نقطه از هم جدا شده اند. به عنوان مثال، در بخش 4 عدد "جدول 4.3" خواهد بود.

نام جدول باید محتوای آن را منعکس کند، دقیق و مختصر باشد. این نام از کلمه "جدول"، شماره جدول و متن تشکیل شده است. GOST 2.105-95 استفاده از خط فاصله یا خط تیره را در نام جدول تعریف نمی کند. در عمل، ممکن است از خط تیره استفاده شود، مانند استفاده از خط تیره در عنوان یک عکس. به عنوان مثال، "جدول 5 - کار انجام شده، محدوده و زمان." نقطه در انتهای نام قرار داده نشده است. عنوان در بالای جدول سمت چپ قرار می گیرد.

در GOST 2.105-95، در بند 4.4.3، شرط زیر آمده است: "همه جداول سند باید در متن سند ارجاع داده شوند، مرجع باید شامل کلمه "جدول" باشد که تعداد آن را نشان می دهد." در عمل، کلمه "جدول" در متن طبق قوانین زبان روسی رد می شود. به عنوان مثال: "توضیح مختصری از هدف و ویژگی های اصلی زیرسیستم های IS MP مرحله دوم در جدول 1 ارائه شده است."

اگر جدول دارای چندین صفحه است، عنوان آن را در بالای هر صفحه نمایش دهید.

در GOST 2.105-95 یک شرط اختیاری در بند 4.4.7 وجود دارد: "اگر جدول در انتهای صفحه قطع شود و ادامه آن در صفحه بعد باشد، در قسمت اول جدول خط افقی پایینی محدود می شود. ممکن است جدول کشیده نشود.» در عمل، خط افقی پایین ترسیم می شود، زیرا عدم وجود آن درک جدول توسط کاربر را مختل می کند.

قوانین طراحی تصاویر

تصاویر شامل تصاویر گرافیکی (نمودار، نمودار، عکس، نقاشی) است.

تصاویر، به استثنای تصاویر ضمیمه، با اعداد عربی شماره گذاری می شوند و شماره گذاری پیوسته است. به عنوان مثال: "شکل 3".

تصاویر هر برنامه با شماره گذاری جداگانه با اعداد عربی با اضافه کردن نام برنامه قبل از شماره مشخص می شود. به عنوان مثال: "شکل B.6".

شماره گذاری تصاویر در بخش مجاز است. در این حالت، شماره تصویر شامل شماره بخش و شماره تصویر است که با یک نقطه از هم جدا شده اند. به عنوان مثال، در بخش 5 عدد "شکل 5.2" خواهد بود.

مجاز به شماره گذاری تصاویر کوچک (نقشه های کوچک) که مستقیماً در متن قرار داده شده اند و هیچ ارجاع دیگری در متن به آنها وجود ندارد، داده نمی شود.

الزامات GOST 2.105-95 برای مکان: "تصاویر را می توان هم در متن سند (احتمالاً نزدیکتر به بخش های متناظر متن) و هم در انتهای آن قرار داد."

GOST 2.105-95 در پاراگراف 4.3.1 موارد زیر را بیان می کند: "هنگام ارجاع به تصاویر، باید "... مطابق با شکل 2" را برای شماره گذاری پیوسته و "... مطابق با شکل 1.2" را برای شماره گذاری بنویسید. بخش ".

نام زیر تصویر با فرمت "شکل 1 - جزئیات ابزار" نوشته شده است.

یک واقعیت جالب: اگر یک خطا را در یک سند کاغذی بپوشانید و یک تصحیح را با جوهر سیاه در بالا بنویسید، مطابق با GOST خواهد بود. GOST 2.105-95 امکان تصحیح اسناد را به صورت کاغذی فراهم می کند. در بند 3.7 آمده است: «اشتباهات چاپی، تایپی و اشتباهات گرافیکی کشف شده در حین اجرای سند را می توان با پاک کردن یا رنگ آمیزی با رنگ سفید و اعمال متن تصحیح شده (گرافیک) در همان مکان به صورت تایپی یا سیاه و سفید تصحیح کرد. جوهر، خمیر یا جوهر به صورت دست نویس. آسیب به برگه های اسناد متنی، لکه ها و آثار متن قدیمی (گرافیک) ناقص حذف شده مجاز نمی باشد.

یعنی اگر چیزی را پرینت کردید و خطایی پیدا کردید، می توان آن را به صورت دستی به روش بالا اصلاح کرد.

ثبت نام مطابق با GOST 2. 106-96

GOST 2.106-96 فرم ها و قوانین اجرای اسناد طراحی را تعیین می کند. برای هر نوع سند، GOST 2.106-96 یک الگوی طراحی برای قاب های اسناد ارائه می دهد.

GOST 2.106-96 نه تنها شکل قاب ها، بلکه کتیبه اصلی در قاب را نیز تعریف می کند. نمونه ای از GOST 2.106-96: "PP بر روی فرم های 9 و 9a پیوست A ترسیم شده است و نمودارها، جداول و نقشه های لازم به صورت کاغذی را می توان بر روی ورق هایی با هر قالبی که توسط GOST 2.301 تعیین شده است انجام داد، در حالی که کتیبه اصلی است. و ستون های اضافی به آن مطابق با الزامات GOST 2.104 (فرم 2a) انجام می شود.

خلاصه

علاوه بر موارد فوق، می توان گفت که هنگام توسعه AU طبق GOST 34 در پروژه های فناوری اطلاعات برای سازمان های دولتی، در صورت عدم وجود دستورالعمل های دقیق در یک قرارداد دولتی یا TOR رقابتی، برنامه و مستندات طراحی باید مطابق با آن تهیه شود. با GOST های زیر:

• اسناد برنامه توسعه یافته در مراحل مختلف ایجاد AU مطابق با GOST 19.104-78، GOST 19.105-78، GOST 19.106-78 تهیه شده است.
• اسناد طراحی توسعه یافته در مراحل مختلف ایجاد AU مطابق با GOST 2.105-95 و GOST 2.106-96 تهیه شده است. در عین حال، الزامات محتوا توسط RD 50.34-698-90 تنظیم می شود.

لازم است GOST ها را برای ارتباط بررسی کنید و از آخرین نسخه استانداردها استفاده کنید، زیرا آنها، اگرچه به ندرت، هنوز به روز می شوند. امیدوارم این مقاله به شما کمک کند تا الزامات GOST را بهتر مرور کنید، و در صورت لزوم، همیشه می توانید