GOST 19 201 78 نمونه مشخصات فنی. الزامات ساختارهای اطلاعاتی و روش های حل

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

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

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

بنابراین، مشخصات فنی سندی است که به توسعه‌دهنده و مشتری اجازه می‌دهد محصول نهایی را ارائه کنند و متعاقباً مطابقت با الزامات را بررسی کنند.

استانداردهای راهنمای نوشتن مشخصات فنی GOST 34.602.89 "مشخصات فنی برای ایجاد یک سیستم خودکار" و GOST 19.201-78 "مشخصات فنی" است. الزامات محتوا و طراحی." استاندارد اول برای توسعه دهندگان سیستم های خودکار در نظر گرفته شده است، دومی برای نرم افزار (ما در مقاله "GOST چیست" تفاوت بین این سری ها را مورد بحث قرار دادیم).

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

GOST 19.201-78 مشخصات فنی. الزامات محتوا و طراحی	GOST 34.602.89 مشخصات فنی برای ایجاد سیستم خودکار
1. معرفی	1. اطلاعات کلی
2. دلایل توسعه
3. هدف توسعه	2. هدف و اهداف ایجاد سیستم
	3. ویژگی های شی اتوماسیون
4. الزامات یک برنامه یا محصول نرم افزاری	4. سیستم مورد نیاز
4.1. الزامات به ویژگی های عملکردی	4.2. الزامات برای توابع (وظایف) انجام شده توسط سیستم
	4.1. الزامات برای سیستم به عنوان یک کل
	4.1.1. الزامات ساختار و عملکرد سیستم
	4.1.3. شاخص های مقصد
4.2. الزامات قابلیت اطمینان	4.1.4. الزامات قابلیت اطمینان
	4. 1.5. الزامات امنیتی
	4. 1.6. الزامات ارگونومی و زیبایی فنی
4.3. شرایط استفاده	4.1.2. الزامات تعداد و صلاحیت پرسنل سیستم و نحوه عملکرد آنها
	4. 1.9. الزامات برای محافظت از اطلاعات در برابر دسترسی غیرمجاز
	4. 1.10. الزامات ایمنی اطلاعات در صورت بروز حوادث
	4. 1.11. الزامات حفاظت از نفوذ تاثیرات خارجی
	4. 1.12. الزامات خلوص حق ثبت اختراع
	4. 1.13. الزامات استانداردسازی و یکسان سازی
4.4. الزامات ترکیب و پارامترهای وسایل فنی	4. 1.8. الزامات عملیاتی نگهداری، تعمیر و ذخیره سازی اجزای سیستم
4.5. الزامات برای سازگاری اطلاعات و نرم افزار
4.6. الزامات برچسب گذاری و بسته بندی
4.7. الزامات حمل و نقل و ذخیره سازی	4. 1.7. الزامات حمل و نقل برای سیستم های تلفن همراه
4.8. نیازمندی های ویژه	4. 1.14. الزامات اضافی
	4.3. الزامات انواع وثیقه
5. الزامات مستندات برنامه	8. مدارک مورد نیاز
6. شاخص های فنی و اقتصادی
7. مراحل و مراحل رشد	5. ترکیب و محتوای کار برای ایجاد سیستم
8. رویه کنترل و پذیرش	6. رویه کنترل و پذیرش سیستم
	7. الزامات ترکیب و محتوای کار برای آماده سازی شی اتوماسیون برای راه اندازی سیستم
	9. منابع توسعه

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

بر اساس جدول بالا، می توان بخش های اصلی مشخصات فنی را برجسته کرد:

• اطلاعات عمومی در مورد سیستم (برنامه)؛
• هدف، اهداف و اهداف سیستم (برنامه)؛
• الزامات سیستم (الزامات عملکردی، الزامات کاربر، الزامات سیستم به عنوان یک کل و غیره)؛
• الزامات برای انواع امنیت؛
• ملزومات مستندسازی؛
• مراحل و مراحل توسعه؛
• روش کنترل و پذیرش سیستم (برنامه).

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

مثال:

"که در این سندسیستم اطلاعاتی در حال ایجاد "پنجره واحد دسترسی به منابع آموزشی" نامیده می شود که به اختصار SW نامیده می شود.
پنجره واحد برای دسترسی به سیستم منابع آموزشی ممکن است به عنوان پنجره واحد یا سیستم در آینده در این سند نامیده شود.

همچنین در اینجا باید بخش‌های فرعی را درج کنید که جزئیات سازمان‌های درگیر در توسعه (مشتری و پیمانکار) را ارائه می‌کند.

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

بخشی جدایی ناپذیر از سند مشخصات فنی نیز باید فهرستی از اصطلاحات و اختصارات باشد. بهتر است اصطلاحات و اختصارات را در قالب یک جدول با دو ستون "Term" و "Full Form" ارائه کنید.

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

هدف و اهداف ایجاد سیستم

این بخش از سند مشخصات فنی باید شامل هدف و اهداف ایجاد سیستم باشد.

مثال:

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

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

ایجاد سیستم اطلاعاتی پنجره واحد باید تضمین کند:

• ارائه کاربران طیف گسترده ای منابع اطلاعات;
• سطح بالا امنیت اطلاعات;
• افزایش کارایی مؤسسات و بخش های آموزشی با بهینه سازی تعدادی از فرآیندهای تجاری؛
• افزایش کارایی فرآیند تعامل بین سیستم های اطلاعاتی و خدمات درون بخش.

ایجاد سیستم در نتیجه افزایش کارایی بخش، هزینه های عملیاتی را کاهش می دهد.

سیستم مورد نیاز

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

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

مثال:

"4.1 فرآیند کسب و کار "ارائه اطلاعات در مورد موسسات آموزشی فدراسیون روسیه

شرکت کنندگان زیر در این فرآیند تجاری شناسایی می شوند:

مجری کارمند بخش است که بخشی از آن است پرسنل خدماتیسیستم هایی که مسئول صحت داده های ارائه شده هستند

کاربر شهروندی است که نیاز به دریافت اطلاعات در مورد کار موسسات آموزشی فدراسیون روسیه دارد.

4.1.1 ثبت نام موسسه تحصیلیدر سیستم

ثبت نام یک موسسه آموزشی در فدراسیون روسیه توسط کارمند مسئول موسسه انجام می شود ("فرمان دولتی ...").

فرآیند ثبت نام موسسه آموزشی شامل مراحل زیر است:

• نویسنده یک رکورد در مورد سازمان ایجاد می کند.
• نویسنده داده های سازمان را وارد می کند.
• سیستم مجوز یک سازمان را بررسی می کند

• اگر مجوز در پایگاه داده وجود داشته باشد، سیستم پیامی درباره نویسنده به نویسنده ارسال می کند ثبت نام موفق;
• اگر مجوز در پایگاه داده یافت نشد، سیستم پیامی مبنی بر عدم وجود مجوز برای این سازمان به نویسنده ارسال می کند.

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

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

• الزامات حالت های عملیاتی سیستم
• شاخص های مقصد
• الزامات قابلیت اطمینان
• الزامات ایمنی
• الزامات مربوط به تعداد و صلاحیت پرسنل و برنامه کاری آنها
• الزامات حفاظت از اطلاعات
• الزامات ایمنی اطلاعات در صورت بروز حوادث
• الزامات ترخیص اختراع
• الزامات استانداردسازی و یکسان سازی
• و غیره.

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

این بخش از سند مشخصات فنی باید شامل الزامات مربوط به پشتیبانی ریاضی، اطلاعاتی، زبانی، نرم افزاری، فنی و سایر انواع پشتیبانی (در صورت وجود) باشد.

ملزومات مستندسازی

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

این بخش از مشخصات فنی به اندازه شرح الزامات عملکردی مهم است، بنابراین نباید خود را به عبارت "کلیه اسناد و مدارک مطابق با GOST 34 به مشتری ارائه شود" محدود نکنید. این بدان معنی است که شما باید کل بسته اسناد از جمله "فرم"، "گذرنامه" و غیره را ارائه دهید. اکثر اسناد لیست مشخص شده در GOST 34.201-89 نه توسط شما و نه برای مشتری مورد نیاز نیست، بنابراین بهتر است بلافاصله در مرحله توسعه سند مشخصات فنی با لیست موافقت کنید.

حداقل بسته اسناد معمولاً شامل:

• وظیفه فنی؛
• بیانیه طراحی اولیه (فنی)؛
• یادداشت توضیحیبه پروژه فنی;
• شرح سازمان پایگاه اطلاع رسانی;
• راهنمای کاربر؛
• راهنمای مدیر؛
• برنامه و روش آزمون؛
• گزارش آزمون پذیرش؛
• مدرک اتمام کار

بهتر است فهرست مدارک در مشخصات فنی به صورت جدولی ارائه شود که نشان دهنده نام سند و استانداردی است که بر اساس آن باید تدوین شود.

مراحل و مراحل توسعه

این بخش از سند شرایط مرجع باید اطلاعاتی در مورد تمام مراحل کاری که باید انجام شود ارائه دهد.

شرح مرحله باید شامل نام، زمان، شرح کار و نتیجه نهایی باشد.

مراحل کنترل و پذیرش سیستم

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

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

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

وظیفه فنی.

GOST 19.201-78

استاندارد دولتی اتحاد جماهیر شوروی

وظیفه فنی. الزامات برای محتوا و طراحی سیستم متحد برای اسناد برنامه. مشخصات فنی برای توسعه الزامات محتوا و شکل ارائه

GOST 19.201-78

وضوح کمیته دولتیاتحاد جماهیر شوروی مطابق با استانداردهای 18 دسامبر 1978 شماره 3351، تاریخ معرفی تاسیس شده است.

از 01/01/1980

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

1. مقررات عمومی

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

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

1.4. شرایط مرجع باید شامل بخش های زیر باشد:

نام و دامنه کاربرد؛

مبنای توسعه؛

هدف توسعه؛

الزامات فنی برای یک برنامه یا محصول نرم افزاری؛

شاخص های فنی و اقتصادی؛

مراحل و مراحل توسعه؛

رویه کنترل و پذیرش؛

برنامه های کاربردی.

بسته به ویژگی‌های برنامه یا محصول نرم‌افزاری، می‌توان محتوای بخش‌ها را روشن کرد، بخش‌های جدید معرفی کرد یا بخش‌های جداگانه را ترکیب کرد.

2. محتویات بخش

2.1. در بخش "نام و محدوده" نام را مشخص کنید، توضیح مختصردامنه کاربرد برنامه یا محصول نرم افزاری و شیئی که برنامه یا محصول نرم افزاری در آن استفاده می شود.

2.2. بخش "اساس توسعه" باید نشان دهد:

سند(هایی) که توسعه بر اساس آن انجام می شود؛

سازمانی که این سند را تأیید کرده و تاریخ تصویب آن؛

نام و (یا) سمبلموضوعات توسعه

2.3. بخش "هدف توسعه" باید هدف عملکردی و عملیاتی برنامه یا محصول نرم افزاری را نشان دهد.

2.4. بخش "الزامات فنی برای یک برنامه یا محصول نرم افزاری" باید شامل بخش های فرعی زیر باشد:

الزامات برای ویژگی های عملکردی؛

الزامات قابلیت اطمینان؛

شرایط استفاده؛

الزامات ترکیب و پارامترهای ابزار فنی؛

الزامات برای سازگاری اطلاعات و نرم افزار؛

الزامات برچسب زدن و بسته بندی؛

الزامات حمل و نقل و ذخیره سازی؛

نیازمندی های ویژه.

2.4.1. بخش فرعی "الزامات ویژگی های عملکردی" باید الزامات ترکیب عملکردهای انجام شده، سازماندهی داده های ورودی و خروجی، ویژگی های زمان بندی و غیره را نشان دهد.

2.4.2. بخش فرعی "الزامات قابلیت اطمینان" باید الزامات اطمینان از عملکرد قابل اعتماد (اطمینان از عملکرد پایدارکنترل اطلاعات ورودی و خروجی، زمان بازیابی پس از خرابی و غیره).

2.4.3. بخش فرعی "شرایط عملیاتی" باید شرایط عملیاتی را نشان دهد (دمای محیط، رطوبت نسبیو غیره برای انواع انتخاب شده از رسانه های ذخیره سازی)، که باید از ویژگی های مشخص شده و همچنین نوع خدمات اطمینان حاصل کند، مقدار مورد نیازو صلاحیت پرسنل

2.4.4. در بخش فرعی "الزامات ترکیب و پارامترهای ابزار فنی" نشان می دهد ترکیب مورد نیازابزار فنی که مشخصات فنی اصلی آنها را نشان می دهد.

2.4.5بخش فرعی "الزامات برای سازگاری اطلاعات و نرم افزار" باید الزامات مربوط به آن را نشان دهد ساختارهای اطلاعاتیدر روش های ورودی و خروجی و راه حل، کدهای منبع، زبانهای برنامه نویسی.

در صورت لزوم باید اطلاعات و برنامه ها ارائه شود.

2.4.6. در بخش فرعی «الزامات برچسب‌گذاری و بسته‌بندی» در مورد کلیالزامات برچسب گذاری محصول نرم افزاری، گزینه ها و روش های بسته بندی را نشان می دهد.

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

2.5. بخش "شاخص های فنی و اقتصادی" باید نشان دهد: تقریبی بهره وری اقتصادی، برآورد تقاضای سالانه، مزیت های اقتصادی توسعه نسبت به بهترین داخلی و نمونه های خارجییا آنالوگ ها

2.6. در بخش "مراحل و مراحل توسعه"، مراحل لازم توسعه، مراحل و محتوای کار تعیین می شود (فهرست اسناد برنامه، که باید توسعه یابد، مورد توافق قرار گیرد و تصویب شود)، و به عنوان یک قاعده، چارچوب زمانی توسعه، مجریان را تعیین می کند.

2.7. در قسمت "رویه کنترل و پذیرش" باید انواع آزمون ها و الزامات کلیبرای پذیرش کار

2.8. در ضمیمه مشخصات فنی در صورت لزوم موارد زیر آورده شده است:

فهرستی از تحقیقات و سایر کارهایی که توسعه را توجیه می کند.

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

سایر منابع توسعه

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

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

قوانین طراحی

شرایط مرجع مطابق با GOST 19.106-78 در برگه های فرمت 11 و 12 مطابق با GOST 2.301-68، به عنوان یک قاعده، بدون پر کردن فیلدهای برگه تهیه می شود. اعداد ورق (صفحه) در بالای صفحه بالای متن قرار می گیرند.

برگه تایید و برگه جلد

برگه تاییدیه و صفحه عنوانمطابق با GOST 19.104-78 تهیه شده است.

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

تغییرات و اضافات

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

تمام جزئیات را در نظر بگیرید مرحله اولیهتوسعه غیر ممکن است در تمرین رویکرد مشخص شدهاغلب استفاده می شود. در بخش "مراحل و مراحل توسعه"، امکان ایجاد تغییرات و اضافات در مشخصات فنی باید به وضوح ذکر شود: "محتوای بخش های این مشخصات فنی با توافق با مشتری قابل تغییر و تکمیل است."

ترکیب بخش های مشخصات فنی

شرایط مرجع باید شامل بخش های زیر باشد:

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

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

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

معرفی

این بخش نام، شرح مختصری از دامنه کاربرد برنامه یا محصول نرم افزاری و شیئی که برنامه یا محصول نرم افزاری در آن استفاده می شود را نشان می دهد.

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

نام برنامه

نام - "ویرایشگر متن برای کار با فایل های rtf."

شرح مختصری از حوزه کاربردی

این برنامه برای استفاده در بخش های تخصصی در امکانات مشتری در نظر گرفته شده است.

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

دلایل توسعه

بخش باید نشان دهد:

سند(های) که بر اساس آن توسعه انجام می شود؛ سازمانی که این سند را تأیید کرده و تاریخ تصویب آن؛ نام و (یا) نماد موضوع توسعه.

بخش فرعی باید حاوی اطلاعات مندرج در موافقتنامه باشد.

مبنای توسعه

مبنای توسعه موافقتنامه (نامه و غیره) شماره 000 مورخ 1 ژانویه 2001 (شماره دریافتی فلان و فلان از فلان و فلان). این توافق با مدیر شرکت دولتی واحد "Spetstyazhmontazhstroyselkhozavtomatika" ایوانوف پتر ایوانوویچ، به نام بیشتر توسط مشتری، و تایید شد مدیر کلبلومکینز ایوان آرونوویچ، که از این پس به عنوان مجری نامیده می شود، فلان و فلان مارس 2008.

استفاده از بخش "اطلاعات عمومی" GOST 34.602-89 راحت است، زیرا توسعه دهنده هر حقیتکمیل و حذف بخش هایی از مشخصات فنی به صلاحدید شما. در عین حال، اطلاعات ذکر شده در بالا در توافقنامه موجود است. اینکه آیا آنها باید در شرایط مرجع گنجانده شوند بستگی به مورد خاص دارد.

نام و نماد موضوع توسعه

نام موضوع توسعه «توسعه ویرایشگر متنبرای کار با فایل های rtf."

تعیین موضوع توسعه (کد موضوع) "RTF-007" است.

هدف توسعه

این بخش باید هدف عملکردی و عملیاتی برنامه یا محصول نرم افزاری را نشان دهد.

هدف عملکردی

هدف کاربردی این برنامه این است که فرصت کار با کاربر را فراهم کند اسناد متنیبا فرمت rtf

بخش فرعی باید "بزرگ شده" را نشان دهد هدف عملکردیبرنامه ها. جزئیات - لیست توابع و غیره - در قسمت های مربوطه در زیر آورده خواهد شد.

هدف عملیاتی را می توان به طور کلی تفسیر کرد. کجا، چگونه، توسط چه کسی، با چه برنامه ای باید استفاده شود؟

لاستیک های هم اندازه را می توان با موفقیت در وسایل نقلیه Zhiguli و Volga استفاده کرد، اما نه در KamAZ. و بالعکس. اما برای هر اندازه لاستیک خاص، هدف عملیاتی آن را می توان تعیین کرد.

بیایید از یک رویکرد رسمی استفاده کنیم:

هدف عملیاتی

این برنامه باید در بخش های تخصصی در امکانات مشتری استفاده شود.

کاربران نهایی برنامه باید کارکنان بخش های تخصصی امکانات مشتری باشند.

الزامات یک برنامه یا محصول نرم افزاری

بخش باید شامل زیربخش های زیر باشد:

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

اگر استانداردهایی حاوی الزامات عمومی (فنی) برای یک برنامه، سیستم یا محصول وجود داشته باشد، به عنوان مثال، "GOST. خودکار اطلاعات و سیستم های اندازه گیری. الزامات عمومی (فنی)، توسعه مشخصات فنی به طور قابل توجهی ساده شده است. بیشتر محتویات استاندارد مشخص شده به سادگی در مشخصات فنی بازنویسی می شود.

الزامات عملکردی

بخش فرعی باید الزامات ترکیب عملکردهای انجام شده، سازماندهی داده های ورودی و خروجی، ویژگی های زمان بندی و غیره را نشان دهد.

الزامات برای ترکیب عملکردهای انجام شده

برنامه باید توانایی انجام عملکردهای زیر را داشته باشد:

1. توابع برای ایجاد یک فایل جدید (خالی).

2. توابع برای باز کردن (بارگذاری) یک فایل موجود.

4. توابع برای ویرایش فایل فعلی با استفاده از بافرتبادل سیستم عامل.

5. توابع ذخیره فایل با نام اصلی.

6. توابع ذخیره یک فایل با نامی متفاوت از نام اصلی.

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

8. توابع برای نمایش اطلاعات آنلاین در قالب رشته (نکات).

9. توابع سیستم کمک آنلاین.

10. توابع برای نمایش نام برنامه، نسخه برنامه، کپی رایت و نظرات توسعه دهنده.

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

الزامات سازماندهی داده های ورودی

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

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

هیچ فایلی با فرمت متفاوت، اما با پسوند rtf، نباید باز شود.

فایل ها http:///file. rtf یا ftp:///file. rtf نباید باز بشه اگر سیستم فایل به عنوان FAT32 فرمت شده است، فایل های رسانه محلی یا قابل جابجایی فرمت شده، به عنوان مثال، با فرمت ext3 نباید باز شوند.

الزامات سازماندهی داده های خروجی

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

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

الزامات زمان بندی

هیچ الزامی برای ویژگی های زمان بندی برنامه وجود ندارد.

باید مشخص شود که آیا مشتری برای سرعت برنامه الزاماتی دارد یا خیر، به عنوان مثال، چه مدت طول می کشد تا برنامه شروع شود، فایل های با اندازه معین باز و بسته شود. اگر مشتری مشخص کند اعداد خاص، باید ایمن بازی کنید و در الزامات ترکیب و پارامترهای تجهیزات فنی یک ابر رایانه با قیمت 2500 دلار یا بیشتر قرار دهید. درست است ، چنین مبلغی باید توجیه شود. اگر ویژگی های زمانی برای مشتری مهم نیست، لازم است در مورد چشم پوشی از الزامات برای ویژگی های زمانی بنویسید (به عبارت بالا مراجعه کنید).

الزامات قابلیت اطمینان

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

قابلیت اطمینان یک چیز ظریف و بسیار خطرناک است. اما لیست توابع و حالت های خرابی آنها طبق بند 1.3.2. GOST 24.701-86، باید توسط مشتری تهیه شده و با پیمانکار موافقت شود. به احتمال زیاد، انتظار هیچ چیز قابل فهمی از مشتری وجود نخواهد داشت. شایان ذکر است به مشتری توضیح داده شود که عملکرد مطمئن برنامه نه چندان به پیمانکار، بلکه به قابلیت اطمینان سخت افزار و سیستم عامل بستگی دارد و همچنین تعدادی از اقدامات سختگیرانه برای افزایش قابلیت اطمینان و پایداری به مشتری ارائه می شود. از برنامه

الزامات برای اطمینان از عملکرد قابل اعتماد (پایدار) برنامه

عملکرد قابل اطمینان (پایدار) برنامه باید با اجرای مجموعه ای از اقدامات سازمانی و فنی توسط مشتری تضمین شود که لیست آنها در زیر آمده است:

سازمان تامین برق اضطراری تجهیزات فنی؛ با استفاده از مجوز نرم افزار; اجرای منظم توصیه های وزارت کار و توسعه اجتماعیفدراسیون روسیه، در قطعنامه 01.01.01 "در مورد تصویب بین بخشی استانداردهای استانداردزمان برای کار کردن سرویسرایانه های شخصی و تجهیزات اداری و پشتیبانی نرم افزار"؛ انطباق منظم با الزامات GOST. حفاظت از اطلاعات نرم افزار تست وجود ویروس های کامپیوتری.

می توانید ده ها مورد دیگر را به لیست اضافه کنید. اسناد نظارتی. در طی تایید اولیه مشخصات فنی، مشتری به احتمال زیاد تمایل به سازش را نشان خواهد داد.

رویکرد انسانی تر ممکن است. قابلیت اطمینان (اما طبق همان GOST یک سیستم) را می توان عملکرد بدون خرابی یک تابع i-ام خاص در یک بازه زمانی خاص در نظر گرفت. ما به مشتری پیشنهاد می کنیم که معیار عملکرد قابل اعتماد برنامه را در نظر بگیرد نشانگر بعدی: مشتری ظرف یک ساعت 100 بار فایل را باز و بسته می کند. اگر برنامه در بازه زمانی مشخص شده خراب نشود، الزامات قابلیت اطمینان برآورده شده در نظر گرفته می شود.

اگر مشتری در نهایت متقاعد شد که قابلیت اطمینان نه چندان به پیمانکار که به قابلیت اطمینان سخت افزار و سیستم عامل بستگی دارد و منصرف شد، عبارت زیر باید در قسمت نوشته شود:

هیچ الزامی برای اطمینان از عملکرد قابل اعتماد (پایدار) برنامه وجود ندارد.

زمان بهبودی پس از شکست

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

زمان بازیابی پس از خرابی ناشی از نقص سخت افزار یا خرابی کشنده (خراش) سیستم عامل نباید از زمان لازم برای رفع نقص سخت افزار و نصب مجدد نرم افزار تجاوز کند.

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

خرابی های ناشی از اقدامات نادرست اپراتور

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

شرایط استفاده

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

شرایط عملیاتی آب و هوایی

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

این برنامه از دمای مثبت 5 تا مثبت 35 درجه سانتیگراد با رطوبت نسبی 90 درصد و فشار اتمسفر 462 میلی متر کاملاً کار می کند. rt هنر، زیرا چنین شرایطی تقریباً با شرایط عملکرد رایانه های مدرن مطابقت دارد غیر صنعتیاجرا. اما، به محض اینکه مشخصات مشخص شد و کار تایید شد، مشتری یک فرصت عالی برای مجبور کردن پیمانکار به انجام آزمایش‌های آب و هوایی در تمام و کمالبه هزینه پیمانکار

الزامات برای انواع خدمات

به الزامات برای اطمینان از عملکرد قابل اعتماد (پایدار) برنامه مراجعه کنید.

این برنامه به هیچ نوع تعمیر و نگهداری نیاز ندارد.

انواع تعمیر و نگهداری باید از بخش فرعی "الزامات برای اطمینان از عملکرد قابل اعتماد (پایدار)" قرض گرفته شود.

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

الزامات برای تعداد و صلاحیت پرسنل

حداقل تعداد پرسنل مورد نیاز برای اجرای برنامه باید حداقل 2 نفر باشد واحدهای پرسنلی– مدیر سیستم و کاربر نهاییبرنامه ها - اپراتور.

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

وظیفه حفظ عملکرد وسایل فنی؛ وظایف نصب (نصب) و حفظ عملکرد نرم افزار سیستم - سیستم عامل؛ وظیفه نصب یک برنامه

کاربر نهایی برنامه (اپراتور) باید مهارت عملی در کار با رابط کاربری گرافیکی سیستم عامل داشته باشد.

پرسنل باید گواهینامه صلاحیت گروه II در ایمنی الکتریکی (برای کار با تجهیزات اداری) را داشته باشند.

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

پرسنل بدون II گروه صلاحیتبا توجه به ایمنی برق، حق ندارد حتی به رایانه شخصی و تجهیزات اداری نزدیک شود.

الزامات ترکیب و پارامترهای وسایل فنی

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

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

سخت افزار باید دارای یک IBM سازگار باشد کامپیوتر شخصی(کامپیوتر)، از جمله:

پردازنده Pentium-1000 با فرکانس ساعت 10 گیگاهرتز، نه کمتر؛ مادربردبا FSB، گیگاهرتز - 5، نه کمتر؛ رمحجم، Tb - 10، نه کمتر؛ و غیره…

الزامات برای سازگاری اطلاعات و نرم افزار

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

در صورت لزوم باید ارائه شود حفاظت از داده هاو برنامه ها

الزامات ساختارهای اطلاعاتی و روش های حل

ساختار اطلاعات فایل باید شامل متن حاوی نشانه گذاری مورد نیاز با مشخصات فرمت rtf باشد.

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

الزامات کدهای منبع و زبان های برنامه نویسی

کدهای منبع برنامه باید در C++ پیاده سازی شوند. محیط Borland C++ Buider باید به عنوان یک محیط توسعه برنامه یکپارچه استفاده شود.

الزامات نرم افزار مورد استفاده برنامه

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

الزامات حفاظت از اطلاعات و برنامه ها

هیچ الزامی برای حفاظت از اطلاعات و برنامه ها وجود ندارد.

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

الزامات برچسب گذاری و بسته بندی

این برنامه به عنوان یک محصول نرم افزاری - بر روی یک رسانه توزیع (نوری خارجی) (CD) عرضه می شود.

ما در مورد برچسب زدن و بسته بندی رسانه های توزیع - یک محصول نرم افزاری صحبت می کنیم (به GOST 19.004-80 مراجعه کنید).

الزامات برچسب زدن

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

علامت گذاری باید به صورت برچسبی که با چاپ و با در نظر گرفتن الزامات GOST 9181-74 ساخته شده است، روی محصول نرم افزار اعمال شود.

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

الزامات بسته بندی

محصول نرم افزاری باید در ظروف بسته بندی سازنده بسته بندی شود.

دقیقا سازنده پیمانکار نمی تواند و نباید مسئولیت بیشتری نسبت به سازنده کانتینر داشته باشد.

شرایط بسته بندی

بسته‌بندی محصول نرم‌افزاری باید در مکان‌های تهویه‌شده بسته در دمای مثبت ۱۵ تا مثبت ۴۰ درجه سانتی‌گراد و رطوبت نسبی حداکثر ۸۰ درصد در صورت عدم وجود ناخالصی‌های تهاجمی در محیط انجام شود.

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

روش بسته بندی

محصولات نرم افزاری تهیه شده برای بسته بندی در ظروف قرار می گیرند که جعبه های ساخته شده از مقوای راه راه (GOST 7376-89 یا GOST 79 طبق نقشه های سازنده بسته بندی هستند.

بسته بندی محصول نرم افزاری با استفاده از پوشش های ساخته شده از فیلم ضد آب با حضور اجباریماده خشک کننده شیمیایی غیر تهاجمی (سیلیکاژل).

برای پر کردن فضای خالیواشرهای ساخته شده از مقوای راه راه یا پلاستیک فوم در ظروف بسته بندی قرار می گیرند.

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

اسناد حمل و نقل در لایه بالایی مواد بالشتک قرار می گیرد - لیست بسته بندیو بیانیهبسته بندی.

بسته بندی مصرف کننده باید طبق GOST با نوار چسب 6-70 پوشانده شود.

محصولات نرم افزاری بسته بندی شده در بسته بندی مصرف کننده باید روی یک پالت قرار داده شوند، برای جلوگیری از از بین رفتن شکل محموله، با نوار بسته بندی شوند و برای محافظت در برابر رطوبت در فیلم پلی اتیلن M 0.2 بسته بندی شوند.

جعبه پالت باید حاوی اسناد حمل و نقل، از جمله لیست بسته بندی مطابق با GOST باشد.

ابعاد فضای بار نباید بیشتر از 1250*820*1180 میلی متر باشد.

وزن خالص - حداکثر 200 کیلوگرم.

وزن ناخالص - حداکثر 220 کیلوگرم.

بخش فرعی روش بسته بندی را از یک سند قبلاً توسعه یافته برای برخی تجهیزات فنی نشان می دهد. در زمینه یک محصول نرم افزاری تا حدودی غیرعادی به نظر می رسد. به بیان ساده در روسی- شوخی کامل

الزامات حمل و نقل و ذخیره سازی

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

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

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

شرایط حمل و نقل و نگهداری

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

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

دمای هوای محیط، درجه سانتیگراد - از مثبت 5 تا مثبت 50؛ فشار اتمسفر، کیلو پاسکال - چنین و چنان؛ رطوبت نسبی هوا در 25 درجه سانتیگراد چنین و چنان است.

نیازمندی های ویژه

این برنامه باید تعامل با کاربر (اپراتور) را از طریق یک رابط کاربری گرافیکی که مطابق با توصیه های سازنده سیستم عامل توسعه یافته است، فراهم کند.

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

الزامات اسناد نرم افزاری

این بخش باید ترکیب اولیه اسناد برنامه و در صورت لزوم الزامات ویژه برای آن را نشان دهد.

ترکیب اسناد برنامه توسط GOST 19.101-77 ارائه شده است.

ترکیب اولیه اسناد برنامه

ترکیب اسناد برنامه باید شامل موارد زیر باشد:

وظیفه فنی؛ برنامه و روش های تست؛ راهنمای برنامه نویس سیستم; راهنمای اپراتور؛ لیست اسناد عملیاتی

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

طبق بند 2.6. GOST 19.101-77 "مجاز است ترکیب شود گونه های منفرداسناد عملیاتی (به جز فهرست اسناد عملیاتی و فرم). نیاز به ترکیب این اسناد در مشخصات فنی نشان داده شده است. به سند ادغام شده نام و نام یکی از اسناد ادغام شده اختصاص داده می شود.

اسناد نرم افزار موجود در لیست اولیه، باید مطابق با الزامات GOST 19.106-78 صادر شود.

شاخص های فنی و اقتصادی

کارایی اقتصادی تخمینی محاسبه نشده است.

تعداد تخمینی استفاده از برنامه در سال 365 جلسه کاری در یک ایستگاه کاری است.

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

فرض کنید مشتری دوازده ایستگاه کاری را به این برنامه مجهز کرده است. پیمانکار برای توسعه 1000 دلار درخواست کرد. مشتری می تواند در ایستگاه های کاری نصب کند نرم افزاراز یک شرکت سوم، هزینه هر توزیع 500 دلار و برای هر ایستگاه کاری 100 دلار برای هر مجوز.

منافع اقتصادی توسعه

مزیت های اقتصادی توسعه در مقایسه با بهترین آنالوگ های داخلی و خارجی عبارتند از:

تعداد مشاغل

توسعه

مزایای اقتصادی

مراحل و مراحل توسعه

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

مراحل و مراحل توسعه توسط GOST 19.102-77 تنظیم می شود. GOST 19.102-77 مانع از حذف مراحل فردی کار و همچنین ترکیب نمی شود مراحل فردیآثار

مراحل توسعه

توسعه باید در سه مرحله انجام شود:

توسعه مشخصات فنی؛ طراحی دقیق و با جزییات; پیاده سازی.

مراحل توسعه

در مرحله تدوین مشخصات فنی، مرحله تدوین، هماهنگی و تایید این مشخصات فنی باید طی شود.

در مرحله طراحی دقیق، مراحل زیر باید انجام شود:

پیشرفت برنامه؛ توسعه مستندات برنامه؛ تست کردن برنامه

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

در مرحله توسعه مشخصات فنی، کارهای زیر باید انجام شود:

فرمول بندی مسئله؛ تعیین و شفاف سازی الزامات وسایل فنی؛ تعیین الزامات برنامه؛ تعیین مراحل، مراحل و زمان توسعه برنامه و مستندسازی آن؛ انتخاب زبان های برنامه نویسی؛ هماهنگی و تایید مشخصات فنی.

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

در مرحله توسعه اسناد برنامه، توسعه اسناد برنامه باید مطابق با الزامات GOST 19.101-77 با الزام بند ترکیب اولیه اسناد برنامه این مشخصات فنی انجام شود.

در مرحله آزمایش برنامه، انواع کارهای زیر باید انجام شود:

توسعه، هماهنگی و تصویب یک برنامه (به نظر می رسد در GOST اشتباه تایپی وجود دارد - "سفارش") و روش های آزمایش. انجام آزمون های پذیرش؛ تنظیم برنامه و مستندات برنامه بر اساس نتایج آزمایش.

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

مراحل کنترل و پذیرش

در این بخش باید انواع آزمون ها و الزامات عمومی برای پذیرش کار مشخص شود.

انواع تست

تست های پذیرش باید در سایت مشتری در مهلت های مقرر انجام شود ...

آزمون های پذیرش برنامه باید مطابق با برنامه و روش های آزمایشی که (حداکثر تا فلان دوره) توسط پیمانکار و با توافق مشتری ایجاد شده است، انجام شود.

مشتری و پیمانکار پیشرفت آزمون های پذیرش را در گزارش آزمون ثبت می کنند.

الزامات عمومی برای پذیرش کار

بر اساس پروتکل آزمایش، پیمانکار به همراه مشتری، گواهی پذیرش و راه اندازی برنامه را امضا می کند.

برنامه های کاربردی

در ضمیمه مشخصات فنی در صورت لزوم موارد زیر آورده شده است:

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

اگر هست چرا نمی آورید. و مطمئن شوید که لیستی از GOST ها را ارسال کنید که بر اساس آن توسعه باید انجام شود. مثلا:

GOST 19.201-78. مشخصات فنی، الزامات محتوا و طراحی؛ و غیره...

اخیراً آنها به من مراجعه کردند تا در مورد استانداردهای نوشتن مشخصات فنی (TOR) برای توسعه سیستم های خودکار (AS) و نرم افزار (نرم افزار) به من مشاوره دهند. من فکر می کنم، اکنون به Yandex می روم، یک مقاله مناسب پیدا می کنم و آن را ارسال می کنم. اما آنجا نبود! یک مقاله فهرست استانداردهای مشخصات فنی، از جمله الگوها و نمونه ها اسناد آماده، پیدا نکردم. این مقاله را باید خودتان بسازید...

و بنابراین، استانداردهای اصلی، روش‌شناسی و مجموعه‌ای از دانش که TK یا SRS (نرم‌افزار (یا سیستم) مشخصات مورد نیاز را ذکر می‌کنند):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK، BABOK، و غیره.

GOST 34

GOST 34.602-89 شرایط مرجع برای ایجاد یک سیستم خودکار، ساختار مشخصات فنی برای ایجاد سیستم را تنظیم می کند که شامل نرم افزار، سخت افزار، افرادی که با نرم افزار کار می کنند و فرآیندهای خودکار را شامل می شود.

طبق GOST 34، مشخصات فنی باید شامل بخش های زیر باشد:

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

هنگام توسعه مشخصات فنی برای پروژه های دولتیمشتریان، به عنوان یک قاعده، نیاز به رعایت این استاندارد خاص دارند.

GOST 19

"GOST 19.xxx یک سیستممستندات برنامه (ESPD)” یک مجموعه پیچیده است استانداردهای دولتی، ایجاد قوانین به هم پیوسته برای توسعه، طراحی و گردش برنامه ها (یا نرم افزارها) و مستندات برنامه. آن ها این استاندارد به طور خاص برای توسعه نرم افزار اعمال می شود.
طبق GOST 19.201-78 مشخصات فنی، الزامات محتوا و طراحی، مشخصات فنی باید شامل بخش های زیر باشد:

1. معرفی؛
2. دلایل توسعه;
3. هدف توسعه;
4. الزامات برای برنامه یا محصول نرم افزاری.
5. الزامات برای مستندات برنامه.
6. شاخص های فنی و اقتصادی;
7. مراحل و مراحل رشد;
8. رویه کنترل و پذیرش;
9. برنامه های کاربردی.

به طور طبیعی ، GOST 34 (و 19) قبلاً منسوخ شده است و من دوست ندارم از آنها استفاده کنم ، اما با تفسیر صحیح استانداردها ، می توانید مشخصات فنی خوبی دریافت کنید ، به نتیجه گیری مراجعه کنید.

IEEE STD 830-1998

تعریف نسبتاً خوبی از استاندارد 830-1998 - IEEE Recommended Practice for Software Requirements Specifications در توضیحات آن ارائه شده است:

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

طبق استاندارد، شرایط مرجع باید شامل بخش های زیر باشد:

1. معرفی

• 1. هدف
• 2. دامنه
• 3. تعاریف، کلمات اختصاری و اختصارات
• 4. پیوندها
• 5. مروری کوتاه

2. توضیحات کلی

• 1. تعاملات محصول (با سایر محصولات و اجزاء)
• 2. ویژگی های محصول (توضیح مختصر)
• 3. ویژگی های کاربر
• 4. محدودیت ها
• 5. مفروضات و وابستگی ها

3. الزامات دقیق (می توان به روش های مختلف سازماندهی کرد، به عنوان مثال مانند این)

• 1. الزامات برای رابط های خارجی
  • 1. رابط های کاربری
  • 2. رابط های سخت افزاری
  • 3. رابط های نرم افزاری
  • 4. رابط های تعامل
• 2. الزامات عملکردی
• 3. الزامات عملکرد
• 4. محدودیت های طراحی (و ارجاع به استانداردها)
• 5. الزامات غیر کاربردی (قابلیت اطمینان، در دسترس بودن، امنیت و غیره)
• 6. سایر الزامات

4. برنامه های کاربردی
5. فهرست الفبایی

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

خوب، هر کسی که تا آخر خواند - یک امتیاز وجود دارد: نمونه ای از مشخصات فنی که سال ها پیش نوشتم (اکنون مدت زیادی است که به عنوان تحلیلگر کار نمی کنم و دیگران بیشتر هستند نمونه های موفق NDA را از در دسترس قرار دادن عمومی منع می کند).

• ارائه توسط یوری بولوی طبقه بندی نیازمندی های نرم افزار و نمایش آن در استانداردها و متدولوژی ها.
• تجزیه و تحلیل الزامات برای خودکار سیستم های اطلاعاتی. سخنرانی 11: الزامات مستندسازی.
• قوانین تنظیم مشخصات مورد نیاز نرم افزار (به همراه نظرات بخوانید)
• نمونه هایی از مشخصات فنی و سایر اسناد برای توسعه AS برای وزارت توسعه اقتصادی
• سبک مدیریت GOST مقاله توسط Gaperton عملکرد مناسباز مشخصات فنی طبق GOST
• الگوهای اسناد تحلیلگر کسب و کار از