У дома » Алергия » Определение на софтуерен информационен комплекс съгласно GOST. Изисквания за информационно осигуряване на автоматизирани системи за управление. Изисквания за Ace

Определение на софтуерен информационен комплекс съгласно GOST. Изисквания за информационно осигуряване на автоматизирани системи за управление. Изисквания за Ace

Днес ще говорим за вътрешни стандарти за проектна документация. Как тези стандарти работят на практика, защо са лоши и защо са добри. Когато разработваме документация за публични и сериозни частни клиенти, обикновено нямаме избор - съответствието със стандартите е включено в изискванията за документиране на технически спецификации. На практика трябваше да се справям с различни примери за неразбиране на структурата на стандартите, какво трябва да има в документите и защо са необходими тези документи. В резултат на това понякога от писалката на технически писатели, анализатори и специалисти излизат такива бисери, че не е ясно в какво състояние на съзнанието са били написани. Но всъщност всичко е съвсем просто. Търсенето в Habr не върна връзки към повече или по-малко пълен материал за тази тема, затова предлагам да рисувам тази досадна празнина.

Какво представляват стандартите за документация?

Във въпросните 34 серии има само 3 основни стандарта за документация:

Най-обичаният и популярен стандарт за разработване на технически спецификации. Единственото нещо, което не трябва да забравяте е, че той е тясно свързан с други стандарти от серията и ако сте получили техническа спецификация, направена в съответствие с този стандарт, е много желателно да се придържате към други стандарти, дори и да няма директни изисквания за това. Поне по отношение на обща идеология (която е обсъдена по-долу)

Това е основен документ, който съдържа пълен списък на документацията GOST 34, препоръки за кодиране на документи, към кои етапи на проекта принадлежат документите (етапите са описани в GOST 34.601-90), както и как могат да се комбинират с всеки друго.

Всъщност този стандарт е голяма таблица с коментари. Може да се въведе в Excel за по-лесно използване.

Обемист стандарт, описващ съдържанието на проектните документи с различна степен на детайлност. Като индекс се използва горепосоченият GOST 34.201-89.

Има много въпроси и тълкувания на неговите разпоредби към стандарта RD 50-34.698-90, които поради тяхната неяснота често се разбират по различен начин от клиента и изпълнителя или дори от членовете на екипа по проекта. Но, за съжаление, нямаме нищо по-конкретно.

Помислете сега за плюсовете и минусите на стандартите, като традиционно започвате с минусите.

Минуси на стандартите

Основният недостатък е очевиден за всички - стандартите са стари. Те съдържат остаряла идея за архитектурата на автоматизирана система. Например:

двуслойни приложения, състоящи се от клиентска програма и DBMS сървър (без три- или повече "ниво" приложения, без Weblogic или JBoss)
описаната структура на таблиците на базата данни ще даде представа за логическия модел на данни (фактът, че може да има някакъв вид хибернация между приложението и базата данни, тогава изглеждаше като лошо преувеличение)
потребителският интерфейс е с един прозорец (има ли друг? И какво е „браузър“?)
Докладите в системата са малко, всички са хартиени и отпечатани на матричен принтер
Разработената програма е насочена към решаване на „задачата за обработка на информацията“, която има ясен вход и изход и е тясно специализирана. В основата на обработката на информация е "алгоритъм". Понякога има няколко "алгоритъма". (Обектно-ориентираното програмиране тогава прави само първите си стъпки и не се разглежда сериозно).
администраторът на базата данни разбира каква информация има в таблиците и активно участва в редактирането на системните директории (наистина ли има един СУБД сървър за 50 различни приложения?)

Съответно в стандарта има артефакти, като следното:

5.8. Чертеж на формата на документ (видео рамка)
Документът трябва да съдържа изображение на формата на документа или видеокадър в съответствие с изискванията държавни стандартиединна система за документация R 50-77 и необходимите разяснения.

Смисълът на документа е, че така наречените „Зони за печат“ са били използвани в съветски предприятия, където са били разположени високоскоростни матрични принтери, драйверите за които често са били написани от самите инженери. Поради това те трябваше да поддържат регистър на всички документи, които трябваше да бъдат отпечатани, за да гарантират, че когато бъдат отпечатани, документите ще изглеждат така, както трябва.

„Видео кадър“ също е документ, който е показан на текстов дисплей. Дисплеите не винаги поддържаха необходимите знаци и необходимия брой хоризонтални знаци и вертикални линии (и изобщо не поддържаха графики). Ето защо и тук беше необходимо допълнително да се съгласуват формулярите на всички екранни документи.

Сега думите „машинограма“, „видео рамка“, „ATsPU“ не ни казват нищо. Аз също не ги намерих в употреба, въпреки че съм завършил специализиран институт през 90-те години. Това беше времето, когато се появи Windows 3.1, VGA дисплеи, три-инчови дискети и първите местни интернет сайтове. Но тези думи са в стандарта и клиентът понякога капризно изисква да му предостави пълен набор от документация в съответствие с GOST 34.201-89. Освен това подобни формулировки в ТЗ се лутат от едно министерство в друго и вече са се превърнали в някакъв негласен шаблон, в който се набива съдържанието.

Така че документ с глупаво име "Чертеж на формата на документ (видеокадър)" в проекта трябва да бъде и не трябва да е празен.

Какво е добро в стандарта

Всеки стандарт е добър вече, защото позволява на клиента и изпълнителя да говорят на един и същи език и гарантира, че най-малкото клиентът няма да има претенции „под формата“ към предадените резултати.

И стандартите GOST 34 също са добри, защото са съставени умни хора, се изпълняват от години и имат ясна цел - да опишат възможно най-пълно на хартия сложната абстрактна същност, която представлява всяка автоматизирана система за управление.

Когато трябва компетентно да поставите задача на западни изпълнители, които никога не са чували за нашите GOST, можете също да разчитате на тези стандарти или по-скоро на тяхното съдържание, семантичния компонент. Защото, повтарям, гаранцията за пълнота на информацията струва много. Колкото и да се забавляваме с високото ниво на нашия професионализъм, можем да забравим да включим елементарни неща в нашите изисквания, докато същият ГОСТ 34.602-89 „помни“ всичко. Ако не разбирате как трябва да изглежда резултатът от работата на западните изпълнители, вижте изискванията за документация, за препоръчаните раздели. Уверявам ви, по-добре е да не мислите! Най-вероятно има западни аналози на нашите стандарти, в които всичко може да бъде по-пълно, по-модерно и по-добро. За съжаление не съм запознат с тях, тъй като все още не е имало нито един случай, когато нашите GOST не са достатъчни.

Можете да се смеете, че създателите на стандартите не знаеха нищо за java или .NET, за HD монитори и интернет, но не бих посъветвал да подценяваме обхвата на тяхната работа и нейната стойност за нашата професионална общност.

Как да четем и разбираме GOST Series 34 Стандарти за документация

Стандартът разделя всички документи по две оси – време и предметна област. Ако погледнете таблица 2 в GOST 34.201-89, тогава това разделение е ясно видимо (колони "Етап на създаване" и "Част от проекта"

Етапи на създаване на автоматизирана система за управление

Етапите на създаване са определени в GOST 34.601-90. Три от тях са от значение за документацията:

Проект на проект (EP)
Технически проект (ТП)
Разработване на работна документация (РД)

Идеен проектследва след етапа на техническото задание и служи за разработване на идейни проектни решения.

Технически проектописва бъдещата система от всички ъгли. Документите от етапа на ТП след прочитане трябва да оставят пълна яснота в предлаганите подходи, методи, архитектурни и технически решения. В следващата фаза ще бъде твърде късно да се опишат подходи и да се обосноват техническите решения, така че P фазата е ключът към успешното изпълнение на работата, тъй като цялото разнообразие от изисквания на TOR трябва да бъде отразено в документите на P фаза , На етап P системата може изобщо да не съществува.

работна документацияе предназначен за успешното внедряване, пускане в експлоатация и по-нататъшна работа на новата система. Това са документи, съдържащи много специфична информация, която описва физически съществуващи обекти, за разлика от P фазата, която описва бъдещия блясък.

Части (раздели) от проектна документация за създаване на автоматизирани системи за управление

Предметната област е разделена на "Провизии". Първоначално изглежда, че подобно разделение е излишно и ненужно. Но когато започнете да работите с този инструментариум на практика, идеологията, вложена в него, постепенно излиза наяве.

Автоматизираната система от гледна точка на компилаторите на GOST е комбинация от хардуер, софтуер и комуникационни канали, която обработва информация, идваща от различни източници в съответствие с определени алгоритми, и произвежда резултати от обработката под формата на документи, структури от данни или контролни действия. Примитивен модел на най-простия автомат.

За да се опише напълно този "автомат", се правят следните разрези (както е на чертежа):

Математически софтуер (МО), отговаряйки на въпросите: каква логика е заложена в "черната кутия"? Защо са избрани точно тези алгоритми, точно тези формули и точно тези коефициенти?

Софтуерът не знае нищо за процесори или бази данни. Това е отделна абстрактна област, обиталището на "сферичните коне във вакуум". Но математическият софтуер може да бъде много тясно свързан с предметна област, известен още като Истинския живот. Например алгоритми за управление на системи за управление движение по пътищатаизисква се съгласуване с КАТ, преди да бъдат съгласувани от клиента. И тогава разбирате защо са отделени в отделна книга. Защото никой в КАТ не се интересува на каква операционна система ще работи сървърът за приложения, но какъв знак и ограничение на скоростта ще изскочи на таблото при дъжд или сняг е много интересно. Те отговарят за своята част и няма да подписват нищо друго. От друга страна, когато подпишат, няма да има въпроси към техническата страна на въпроса - защо са избрали тези, а не други табла или светофари. Мъдростта на "предците" се проявява в такива практически случаи.

Информационна поддръжка (ИС). Друга част от системата. Този път черната кутия на нашата система става прозрачна и ние гледаме информацията, която циркулира в нея. Представете си модел кръвоносна системачовек, когато всички други органи са невидими. Ето нещо подобно и има информационна поддръжка. Описва състава и маршрутите на информационния поток отвътре и отвън, логическата организация на информацията в системата, описанието на директориите и системите за кодиране (който е правил програми за производство, знае колко са важни). Основната описателна част попада на етапа на TP, но някои „рудименти“ се вливат в етапа на RD, като документа „Каталог на базата данни“. Ясно е, че по-рано тя съдържаше точно това, което пише в заглавието. Но днес се опитайте да създадете такъв документ за сложна комплексна система, когато закупените подсистеми с техните мистериозни информационни хранилища много често се използват като част от системата. Не говоря за това, че сега този документ не е особено необходим.

Или тук е "Изявлението за носители за съхранение на машината." Ясно е, че по-рано в него е имало няколко магнитни барабана или филмови ролки. Сега какво трябва да бъде включено?

Накратко, във фазата на RD документите за информационна поддръжка са доста злонамерен остатък, тъй като формално трябва да бъдат, но няма нищо специално, с което да ги попълните.

Софтуер (софтуер). Любима част от проектната документация на всички. Да, дори само защото това е само един документ! И тогава всеки разбира какво трябва да пише там. Но въпреки това ще повторя.

В този документ трябва да ви кажем какви софтуерни инструменти се използват за изпълнение на алгоритмите, описани в ML, които обработват информацията, описана в IO. Тоест тук няма нужда да дублирате информация от други секции. Тук е дадена архитектурата на системата, обосновката на избраните софтуерни технологии, тяхното описание (всякакви системни неща: езици за програмиране, рамки, операционни системи и т.н.). Също така в този документ ние описваме как са организирани инструментите за обработка на информация (опашки от съобщения, хранилища, инструменти за архивиране, решения за достъпност, всички видове пулове приложения и т.н.). Стандартът има Подробно описаниесъдържанието на този документ, което ще бъде разбрано от всеки специалист.

Техническа поддръжка (TO). Не по-малко обичана от всички част от проектната документация. Розовата картина е помрачена само от изобилието от документи, които трябва да бъдат разработени. Общо, съгласно стандарта, трябва да бъдат разработени 22 документа, 9 от които са на етап ТП.

Факт е, че стандартът дава описание на всичко техническа поддръжка, включително компютърен хардуер и мрежи, инженерни системи и дори строителната част (ако е необходима). И тази икономика се регулира от огромен брой стандарти и нормативни актове, координира се в различни организации и затова е по-удобно всичко да се раздели на части и да се координира (редактира) на части. В същото време стандартът ви позволява да комбинирате някои документи един с друг, което има смисъл, ако един човек е съгласен с целия пакет.

Не забравяйте също, че набор от стандарти за качество предполага отчитане и съхранение на техническите документи, а нашите "брошури" на сайта на клиента могат да бъдат разпространени в различни архиви, в зависимост от предмета на описанието. Това е още един аргумент в полза на разделянето на документацията.

Организационна поддръжка (ОС). След като потиснах в себе си желанието, нормално за техник, да пропусна този раздел възможно най-скоро, напротив, ще го разгледам по-подробно. Тъй като, колеги, напоследък има някои лоши тенденции в проектите, които изискват пояснение точно в този раздел.

На етап TP разделът съдържа само един документ " Описание на организационната структура”, в който трябва да кажем на клиента за какво трябва да се подготви по отношение на промяна на организационната структура. Изведнъж трябва да организирате нов отдел, който да управлява вашата система, да въведете нови позиции и т.н.

На етап RD има други, по-интересни документи, които бих искал да разгледам отделно.

Упътване. Коментарите са излишни според мен.

Методология (технология) на компютърно проектиране. В този документ, ако е необходимо, можете да поставите описание на процеса на изграждане на софтуера, контрол на версиите, тестване и др. Но това е, ако в TOR клиентът иска лично да сглоби софтуера. Ако той не изисква това (и не плаща за това), тогава цялата ви вътрешна кухня не е негова работа и този документ не е необходимо да се прави.

Технологична инструкция. Във връзка с модата за формализиране на бизнес процесите, хитър клиент понякога се стреми да набута правилата на оперативната услуга в този документ. Така че, няма нужда да правите това.

Описание на бизнес процеси, роля и длъжностни характеристики, правила за работа - всичко това е ORD, тоест организационна и административна документация. Което е продукт на консултантски проект, който, доколкото разбирам, не сте купили. И закупиха технически проект от вас и техническа документация към него.

Технологичната инструкция е слой между ORD и ръководството за потребителя. RP описва подробно кактрябва да извършите определени действия в системата. Ръководството за технологията казва какъв видтрябва да се извършват действия в определени случаи, свързани с работата на системата. Грубо казано, технологичната инструкция е кратък преглед на RP за конкретна позиция или роля. Ако клиентът няма оформени роли или иска вие сами да оформите ролите и изискванията за позициите, включете в документа най-много основни роли, например: оператор, старши оператор, администратор. Коментарите на клиентите по темата „но ние не го харесваме“ или „но не ни харесва“ трябва да бъдат придружени от списък с роли и описание служебни задължения. Тъй като бизнес процесите не задавайте. Ние сме тези бизнес процеси ние автоматизираме.

За описания рейк ще пиша отделно, с колоритни примери, тъй като това не се повтаря за първи път в различни сектори на „националната икономика“.

Описание на технологичния процес на обработка на данни (включително телеобработка). Жалък рудимент от пещерната епоха, когато имаше специално посветени "Компютърни оператори", които подадоха перфокарти в машината и опаковаха разпечатката на резултата в плик. Това ръководство е за тях. Какво да напиша в него в 21 век - не мога да ви кажа със сигурност. Излезте сами. Най-доброто нещо е просто да забравите за този документ.

Цялостни системни решения (ИЛИ). Стандартът предвижда 17 документа от секцията ИЛИ. Първо, това са почти всички документи от предварителния етап на предварителния проект. Второ, това са всякакви оценки, изчисления и Кратко описаниеавтоматизирани функции. Тоест информация за хора не от основното ИТ производство, а за помощен персонал - мениджъри, оценители, специалисти по доставки, икономисти и т.н.

И трето, PR включва мегадокумент, наречен „Обяснителна бележка към техническия проект“, който по замисъл е нещо като резюме, но всъщност много дизайнери вкарват цялото полезно съдържание на етапа на TP в него. Такъв радикален подход може да бъде оправдан и дори взаимноизгоден както за клиента, така и за изпълнителя, но в определени случаи.

Опции за използване на GOST 34

Пълно и точно спазване на стандарта. Естествено, никой няма да напише доброволно такъв облак от документи. Следователно пълен набор от документи се изготвя само при спешно искане на клиента, което той е заложил в ТЗ и също така е натиснал върху договора. В този случай се изисква да разберете всичко буквално и да дадете на клиента физически „книги“, в които ще се появят имената на документите от таблица 2 на GOST 34.201-89, с изключение на абсолютно ненужните, чийто списък трябва да направите обсъдете и коригирайте писмено. Съдържанието на документите също трябва, без никакво въображение, да отговаря на RD 50-34.698-90, до заглавието на разделите. За да избухне мозъкът на клиента, понякога голяма система се разделя на подсистеми и за всяка подсистема се издава отделна проектна документация. Изглежда плашещо и не подлежи на нормален контрол с помощта на земния разум. Особено по отношение на подсистемната интеграция. Това значително опростява приемането. Основното нещо е вие самите да не се обърквате и системата ви да работи както трябва.
Ние просто обичаме GOSTs. Сериозните големи компании обичат стандартите. Защото помагат на хората да се разбират по-добре. Ако вашият клиент е забелязан в любовта към реда и стандартизацията, опитайте се да се придържате към стандартната идеология на GOST при разработването на документи, дори ако това не се изисква от TOR. Ще бъдете по-добре разбрани и одобрени от координиращите специалисти, а вие самите няма да забравите да включите в документацията важна информация, ще видите по-добре целевата структура на документите, ще планирате по-точно работата по писането им и ще спестите на себе си и на колегите си много нерви и пари.
Не ни интересува документацията, стига всичко да работи. Изчезващ поглед на безотговорен клиент. Подобен поглед върху документацията все още може да се намери сред малките и бедни клиенти, както и в авторитарните "идиокрации", останали от времето на перестройката, където шефът е заобиколен от истински приятели - директори, а всички въпроси се решават в лични разговори. В такива условия можете да забравите за документацията като цяло, но все пак е по-добре да не сваляте гледката и поне схематично да попълвате документацията със съдържание. Ако не на този клиент, тогава предайте (продайте) на следващия.

Заключение

Тази статия беше за нашите GOSTs за документиране на автоматизирани системи за управление. GOST са стари, но, както се оказа, те все още са много полезни в икономиката. Освен някои очевидни елементи, структурата на документацията има свойствата на пълнота и последователност и следването на стандарта премахва много рискове при проектирането, които може да не сме предположили в началото.

Надявам се, че представеният материал е бил полезен за вас или поне интересен. Колкото и скучно да изглежда, документирането е важна и отговорна работа, където точността е също толкова важна, колкото и при писането на добър код. Пишете добри документи, колеги! И аз съм на следващата седмицаОтивам в две поредни командировки, така че не мога да гарантирам публикуването на нови материали (нямам джоб за газ, пиша от главата си).

ГОСТ 34.601-90 Информационни технологии. Набор от стандарти за автоматизирани системи. Автоматизирани системи. Етапи на създаване.

Г О С У Д Р С Т В Е Н И С Т А Н Д А Р Т С О Ю З А С С Р

Дата на въвеждане
от 01.01.1992г

Този стандарт се прилага за автоматизирани системи (АС), използвани в различни видоведейности (изследователска, проектантска, управленска и др.), включително техните комбинации, създадени в организации, сдружения и предприятия (наричани по-нататък - организации).

Стандартът установява етапите и етапите на създаване на АС. Приложение 1 показва съдържанието на работата на всеки етап.

1. ОБЩИ ПОЛОЖЕНИЯ

1.1. Процесът на създаване на АС е съвкупност от подредени във времето, взаимосвързани, обединени в етапи и етапи работа, чието изпълнение е необходимо и достатъчно за създаване на АС, отговаряща на зададените изисквания.

1.2. Етапите и етапите на създаване на АС се разграничават като части от процеса на създаване от съображения за рационално планиране и организация на работата, завършващи с даден резултат.

1.3. Работата по разработването на AU се извършва според етапите и етапите, използвани за създаване на AU.

1.4. Съставът и правилата за извършване на работа на етапите и етапите, установени от този стандарт, се определят в съответната документация на организациите, участващи в създаването на конкретни видове атомни електроцентрали.

Списъкът на организациите, участващи в създаването на АС, е даден в Приложение 2.

2. ЕТАПИ И ЕТАПИ НА СЪЗДАВАНЕ НА АС

2.1. Етапите и етапите на създаване на АС в общия случай са дадени в таблицата.

	Етапи на работа
1. Формиране на изисквания към АС	1.1. Проверка на съоръжението и обосновка на необходимостта от създаване на АС. 1.2. Формиране на потребителски изисквания за АС. 1.3. Регистриране на отчет за извършената работа и заявление за разработване на AS (тактически техническо задание)
2. Развитие на концепцията за АС.	2.1. Проучване на обекта. 2.2. Извършване на необходимата изследователска работа. 2.3. Разработване на опции за концепцията на АС, която отговаря на изискванията на потребителя. 2.4. Изготвяне на отчет за извършената работа.
3. Техническо задание.	Разработване и утвърждаване на техническо задание за създаване на АС.
4. Ескизен дизайн.	4.1. Разработване на идейни проектни решения за системата и нейните части. 4.2. Разработване на документация за АС и неговите части.
5. Технически проект.	5.1. Разработване на проектни решения за системата и нейните части. 5.2. Разработване на документация за АС и неговите части. 5.3. Разработване и изпълнение на документация за доставка на продукти за придобиване на атомни електроцентрали и (или) Технически изисквания(технически спецификации) за тяхното развитие. 5.4. Разработване на задания за проектиране в съседни части на проекта на обекта за автоматизация.
6. Работна документация.	6.1. Разработване на работна документация за системата и нейните части. 6.2. Разработване или адаптиране на програми.
7. Въвеждане в експлоатация.	7.1. Подготовка на обекта за автоматизация за въвеждане в експлоатация на АС. 7.2. Обучение на персонала. 7.3. Окомплектоване на АС с доставени продукти (софтуер и хардуер, софтуерни и хардуерни системи, информационни продукти). 7.4. СМР. 7.5. Пусконаладъчни работи. 7.6. Задържане предварителни тестове. 7.7. Провеждане на пробна експлоатация. 7.8. Провеждане на приемни тестове.
8. Придружаващи лектори	8.1. Извършване на работа в съответствие с гаранционните задължения. 8.2. Следгаранционен сервиз.

2.2. Етапите на етапите, изпълнявани от организациите - участници в работата по създаването на атомни електроцентрали, са установени в договори и технически задания въз основа на този стандарт.

Разрешено е да се изключи етапът "Идеен проект" и отделните етапи на работа на всички етапи, да се комбинират етапите "Технически проект" и "Подробна документация" в един етап "Детайлен проект". В зависимост от спецификата на създаваните АС и условията за тяхното създаване е разрешено извършването на отделни етапи на работа до завършване на предходните етапи, паралелното изпълнение на етапите на работа във времето, включването на нови етапи на работа.

ПРИЛОЖЕНИЕ 1
(справка)

1. На етап 1.1. "Проверка на обекта и обосновка на необходимостта от създаване в AU" в общия случай се извършва:

а) събиране на данни за обекта на автоматизация и видовете извършвани дейности;
б) оценка на качеството на функциониране на обекта и видовете извършвани дейности, идентифициране на проблеми, които могат да бъдат решени с помощта на автоматизацията;
в) оценка (техническа, икономическа, социална и др.) на целесъобразността от създаване на атомна електроцентрала.

2. На етап 1.2. „Формиране на потребителски изисквания за AU“ се извършва:

а) подготовка на изходни данни за формиране на изискванията на AU (характеристики на обекта за автоматизация, описание на изискванията към системата, граници на допустимите разходи за разработка, въвеждане в експлоатация и експлоатация, ефектът, очакван от системата, условия за създаване и функциониране на системата);
б) формулиране и изпълнение на потребителски изисквания за AU.

3. На етап 1.3. „Подаване на отчет за извършената работа и заявление за разработване на AU (техническо и техническо задание)“ изготвя отчет за извършената работа на този етап и съставя заявление за разработване на AU (тактически и техническо задание) или друг заместващ го документ с подобно съдържание.

4. На етапи 2.1. "Проучване на обекта" и 2.2. „Провеждане на изследователска работа“ организацията разработчик провежда подробно проучване на обекта на автоматизация и необходимата изследователска работа (R&D), свързана с намирането на начини и оценка на възможността за изпълнение на изискванията на потребителите, съставя и одобрява доклади за R&D.

5. На етап 2.3. „Разработване на варианти за концепцията на AU и избор на вариант на концепцията на AU, който отговаря на изискванията на потребителя“ в общия случай те разработват алтернативни варианти за концепцията на създадения AU и планове за тяхното изпълнение; оценка на необходимите ресурси за тяхното изпълнение и функциониране; оценка на предимствата и недостатъците на всеки вариант; определяне на процедурата за оценка на качеството и условията за приемане на системата; оценка на ефектите, получени от системата.

6. На стъпка 2.4. „Формулиране на отчет за извършената работа“ изготвя и изготвя доклад, съдържащ описание на извършената работа на етапа на описание и обосновка на предложената версия на концепцията на системата.

7. На стъпка 3.1. „Разработване и утвърждаване на техническото задание за създаване на АЕЦ“ извършва разработването, изпълнението, съгласуването и одобряването на техническото задание за АЕЦ и, ако е необходимо, техническото задание за части от АЕЦ.

8. На стъпка 4.1. „Разработване на идейни проектни решения на системата и нейните части” са определени: функциите на АС; функции на подсистемите, техните цели и ефекти; съставяне на комплекси от задачи и индивидуални задачи; концепцията за информационната база, нейната разширена структура; функции на системата за управление на бази данни; състав на компютърната система; функции и параметри на основните софтуерни средства.

9. На стъпка 5.1. „Разработване на проектни решения за системата и нейните части“ осигурява разработката общи решенияот системата и нейните части, от функционалната и алгоритмична структура на системата, от функциите на персонала и организационна структура, от структурата на техническите средства, от алгоритми за решаване на проблеми и от използваните езици, от организиране и поддържане на информационна база, от система за класифициране и кодиране на информация, от софтуер.

10. На стъпки 4.2. и 5.2. „Разработване на документация за АЕЦ и нейните части“ извършва разработването, изпълнението, съгласуването и одобряването на документация в размер, необходим за описание на пълния набор от взети проектни решения и достатъчен за по-нататъшна работа по създаването на АЕЦ. Видове документи - съгласно GOST 34.201-89.

11. На стъпка 5.3. „Разработване и изпълнение на документация за доставка на продукти за завършване на АЕЦ и (или) технически изисквания (технически спецификации) за тяхното разработване“ извършва: подготовка и изпълнение на документация за доставка на продукти за завършване на АЕЦ; определяне на технически изисквания и изготвяне на технически спецификации за разработване на продукти, които не се произвеждат масово.

12. На етап 5.4 "Разработване на проектни задания в прилежащи части на проекта на обекта за автоматизация" разработват, изпълняват, съгласуват и одобряват проектни задания в прилежащи части на проекта на обекта за автоматизация за строителни, електрически, санитарни и други подготвителни работи, свързани с създаване на АС.

13. На етап 6.1 "Разработване на работна документация за системата и нейните части" се разработва работна документация, съдържаща цялата необходима и достатъчна информация за осигуряване на изпълнението на работата по въвеждане в експлоатация на АЕЦ и нейната експлоатация, както и за поддържане на ниво на експлоатационни характеристики (качество) на системата в съответствие с приетите проектни решения, нейното проектиране, съгласуване и одобрение. Видове документи съгласно GOST 34.201-89.

14. На етап 6.2 „Разработване или адаптиране на програми“ се разработват програми и софтуер на системата, избор, адаптиране и (или) обвързване на закупен софтуер, разработване на софтуерна документация в съответствие с GOST 19.101.

изпълнение на проектни решения по организационната структура на атомната централа;
осигуряване на звена на контролния обект с инструктивни и методически материали;
въвеждане на информационни класификатори.

16. На етап 7.2 "Обучение на персонала" се обучава персонал и се тества способността му да осигурява функционирането на АЕЦ.

17. На етап 7.3 „Опаковане на AU с доставени продукти (софтуер и хардуер, софтуерни и хардуерни системи, информационни продукти)“ се осигурява получаването на серийни и единични производствени компоненти, материали и монтажни продукти, провеждане на входящ контрол на качеството.

18. На етап 7.4 "СМР" се извършват:

извършване на работи по изграждането на специализирани сгради (помещения) за разполагане на технически съоръжения и персонал на АЕЦ;
изграждане на кабелни канали;
извършване на работи по монтаж на технически средства и комуникационни линии;
изпитване на монтирани технически средства;
доставка на технически средства за въвеждане в експлоатация.

19. На етап 7.5 "Въвеждане в експлоатация" извършете:

автономна настройка на хардуер и софтуер,
зареждане на информация в базата данни и проверка на системата за нейното поддържане;
комплексна настройка на всички средства на системата.

20. На етап 7.6 "Провеждане на предварителни тестове" се извършват:

а) тестване на АС за производителност и съответствие с техническото задание в съответствие с програмата и методологията на предварителните тестове;
б) Отстраняване на неизправности и извършване на промени в документацията на АЕЦ, включително експлоатационната документация в съответствие с протокола за изпитване;
в) регистрация на акта за приемане на АЕЦ за опитна експлоатация.

21. На етап 7.7 "Провеждане на пробна експлоатация" се извършва:

опитна експлоатация на АС;
анализ на резултатите от пробната експлоатация на АЕЦ;
ревизия (ако е необходимо) софтуер AC;
допълнителна настройка (при необходимост) на технически средства на АС;
регистрация на сертификата за завършване на пробна експлоатация.

22. На етап 7.8 "Провеждане на тестове за приемане" извършете:

а) изпитвания за съответствие с техническото задание в съответствие с програмата и методиката на приемните изпитвания;
б) анализ на резултатите от тестовете на AU и отстраняване на недостатъците, установени по време на тестовете;
в) регистриране на акта за приемане на АЕЦ в постоянна експлоатация.

23. На етап 8.1 "Извършване на работа в съответствие с гаранционните задължения" се извършва работа по отстраняване на недостатъците, установени по време на експлоатацията на АЕЦ през установените гаранционни срокове, извършване на необходимите промени в документацията за АЕЦ.

24. На етап 8.2 "Следгаранционно обслужване" се извършват работи по:

а) анализ на функционирането на системата;
б) установяване на отклонения на действителните експлоатационни характеристики на АЕЦ от проектните стойности;
в) установяване на причините за тези отклонения;
г) отстраняване на констатираните недостатъци и осигуряване на стабилност на експлоатационните характеристики на АЕЦ;
д) извършване на необходимите промени в документацията за АС.

ПРИЛОЖЕНИЕ 2
(справка)

СПИСЪК НА ОРГАНИЗАЦИИТЕ, УЧАСТВАЛИ В СЪЗДАВАНЕТО НА АС.

1. Клиентската организация (потребител), за която е създаден AU и който осигурява финансиране, приемане на работа и експлоатация на AU, както и извършването на отделни работи по създаването на AU.

2. Организацията разработчик, която извършва работа по създаването на AU, предоставя на клиента набор от научни и технически услуги по различни етапии етапи на създаване, а също така разработва и доставя различен софтуер и технически средстваКАТО.

3. Организация доставчик, която произвежда и доставя софтуер и хардуер по поръчка на разработчик или клиент.

4. Организация-генерален проектант на обекта за автоматизация.

5. Проектантски организации различни частипроект на обект за автоматизация за строителни, електрически, санитарни и други подготвителни работи, свързани със създаването на АЕЦ.

6. Строително-монтажни, наладъчни и други организации.

Бележки:

а) в зависимост от условията за създаване на AU са възможни различни комбинации от функции на клиента, разработчика, доставчика и други организации, участващи в създаването на AU;
б) етапите и етапите на тяхната работа по създаването на AU се определят въз основа на този стандарт.

Дата на въвеждане 01.01.92г

Този стандарт се прилага за автоматизирани системи (АС), използвани в различни дейности (изследвания, проектиране, управление и др.), включително техните комбинации, създадени в организации, асоциации и предприятия (наричани по-нататък - организации).

1. Общи положения

2. Етапи и етапи на създаване на АС

Приложение 1 (информативно)

Приложение 2 (информативно)

1. ОБЩИ ПОЛОЖЕНИЯ

1.1. е съвкупност от подредени във времето, взаимосвързани, обединени в етапи и етапи работа, чието изпълнение е необходимо и достатъчно за създаване на АС, отговаряща на зададените изисквания.

1.3. Работата по разработването на AU се извършва според етапите и етапите, използвани за създаване на AU.

Списъкът на организациите, участващи в създаването на АС, е даден в Приложение 2.

2. ЕТАПИ И ЕТАПИ НА СЪЗДАВАНЕ НА АС

2.1. Етапите и етапите на създаване на АС в общия случай са дадени в таблицата.

етапи	Етапи на работа
1. Формиране на изисквания към АС	1.1. Проверка на обекта и обосновка на необходимостта от създаване на AU
	1.2. Формиране на потребителски изисквания за АС
	1.3. Регистриране на отчет за извършената работа и заявление за разработване на AU (тактически и технически спецификации)
2. Развитие на концепцията за АС	2.1. Проучване на обекта
	2.2. Извършване на необходимата изследователска работа
	2.3. Разработване на опции за концепцията на AU и избор на вариант на концепцията на AU, който отговаря на изискванията на потребителя
	2.4. Изготвяне на отчет за извършената работа
3. Техническо задание	3.1. Разработване и утвърждаване на техническо задание за създаване на АС
4. Ескизен дизайн	4.1. Разработване на идейни проектни решения за системата и нейните части
4. Ескизен дизайн	4.2. Разработване на документация за АС и неговите части
5. Технически проект	5.1. Разработване на проектни решения за системата и нейните части
	5.2. Разработване на документация за АС и неговите части
	5.3. Разработване и изпълнение на документация за доставка на продукти за придобиване на атомни електроцентрали и (или) технически изисквания (технически спецификации) за тяхното разработване
	5.4. Разработване на задания за проектиране в съседни части на проекта на обекта за автоматизация
6. Работна документация	6.1. Разработване на работна документация за системата и нейните части
6. Работна документация	6.2. Разработване или адаптиране на програми
7. Въвеждане и действие	7.1. Подготовка на обекта за автоматизация за въвеждане в експлоатация на АС
	7.2. Обучение на персонала
	7.3. Завършване на АС с доставени продукти (софтуер и хардуер, софтуерни и хардуерни системи, информационни продукти)
	7.4. СМР
	7.5. Пусконаладъчни работи
	7.6. Провеждане на предварителни тестове
	7.7. Провеждане на пробна експлоатация
	7.8. Провеждане на приемни тестове
8. Придружаващи лектори	8.1. Извършване на работа в съответствие с гаранционните задължения
8. Придружаващи лектори	8.2. Следгаранционен сервиз

2.2. Етапите и етапите, извършвани от организациите - участници в създаването на атомни електроцентрали, се определят в договори и технически задания на базата на този стандарт.

Позволено е да се изключи етапът "Идеен проект" и отделните етапи на работа на всички етапи, да се комбинират етапите "Технически проект" и "Подробна документация" в един етап "Технически проект". В зависимост от спецификата на създаваните АС и условията за тяхното създаване е разрешено извършването на отделни етапи на работа до завършване на предходните етапи, паралелното изпълнение на етапите на работа във времето, включването на нови етапи на работа.

ПРИЛОЖЕНИЕ 1. Справка

1. На етап 1.1 "Обследване на обекта и обосновка на необходимостта от създаване на АЕЦ" в общия случай се извършва следното:

събиране на данни за обекта на автоматизация и извършваните дейности;
оценка на качеството на функциониране на обекта и видовете извършвани дейности, идентифициране на проблеми, които могат да бъдат решени чрез автоматизация;
оценка (техническа, икономическа, социална и др.) на възможността за създаване на атомна електроцентрала.

2. На етап 1.2 се извършва "формиране на потребителски изисквания за AU":

подготовка на изходни данни за формиране на изисквания към AU (характеристики на обекта на автоматизация, описание на изискванията към системата, граници на допустимите разходи за разработка, въвеждане в експлоатация и експлоатация, ефектът, който се очаква от системата, условията за създаване и експлоатация на системата);
формулиране и изпълнение на потребителски изисквания за AU.

3. На етап 1.3 „Подаване на отчет за извършената работа и заявление за разработване на АС (тактико-техническо задание)“ се съставя отчет за извършената работа на този етап и заявление за разработване на AU (тактико-техническо задание) или друг заместващ го документ с подобно съдържание.

4. На етапи 2.1 „Проучване на обекта“ и 2.2 „Провеждане на необходимата изследователска работа“ организацията разработчик провежда подробно проучване на обекта на автоматизация и необходимата изследователска работа (R&D), свързана с намирането на начини и оценката на възможността за внедряване на потребителя изисквания, изготвят и одобряват доклади за научни изследвания.

5. На етап 2.3 „Разработване на опции за концепцията на AU и избор на вариант на концепцията на AU, който отговаря на изискванията на потребителя“, в общия случай, алтернативни варианти за концепцията на създадения AU и се разработват планове за тяхното изпълнение; оценка на необходимите ресурси за тяхното изпълнение и функциониране; оценка на предимствата и недостатъците на всеки вариант; сравнение на потребителските изисквания и характеристики на предложената система и избор най-добрият вариант; определяне на процедурата за оценка на качеството и условията за приемане на системата; оценка на ефектите, получени от системата.

6. На етап 2.4 „Формулиране на отчета за извършената работа“ се изготвя и изготвя доклад, съдържащ описание на извършената работа на етапа, описание и обосновка на предложената версия на концепцията на системата.

7. На етап 3.1 „Разработване и утвърждаване на техническо задание за създаване на АЕЦ“ се извършва разработването, изпълнението, съгласуването и одобряването на техническото задание за АЕЦ и, ако е необходимо, техническото задание за части от АЕЦ се извършват.

8. На етап 4.1 „Разработване на идейни проектни решения за системата и нейните части” се определят: функциите на АС; функции на подсистемите, техните цели и ефекти; съставяне на комплекси от задачи и индивидуални задачи; концепции за информационната база, нейната разширена структура; функции на системата за управление на бази данни; състав на компютърната система; функции и параметри на основните софтуерни средства.

9. На етап 5.1 "Разработване на проектни решения за системата и нейните части" те осигуряват разработването на общи решения за системата и нейните части, функционалната и алгоритмичната структура на системата, функциите на персонала и организационната структура, структурата на техническите средства, алгоритмите за решаване на проблеми и използваните езици, организацията и поддръжката на информационната база, системата за класифициране и кодиране на информация, софтуер.

10. На етапи 4.2 и 5.2 „Разработване на документация за АЕЦ и нейните части“ се извършва разработването, изпълнението, съгласуването и одобряването на документация в размер, необходим за описване на пълния набор от взети проектни решения и достатъчен за по-нататъшна работа за създаването на АЕЦ. Видове документи - съгласно GOST 34.201.

11. На етап 5.3 „Разработване и изпълнение на документация за доставка на продукти за завършване на АЕЦ и (или) технически изисквания (технически спецификации) за тяхното разработване“ подготовка и изпълнение на документация за доставка на продукти за завършване на АЕЦ; определяне на технически изисквания и изготвяне на технически спецификации за разработване на продукти, които не се произвеждат масово.

12. На етап 5.4 „Разработване на задания за проектиране в прилежащи части на проекта за автоматизация“ разработват, изпълняват, съгласуват и одобряват задания за проектиране в прилежащи части на проекта на обекта за автоматизация за строителни, електрически, санитарни и други подготвителни работи, свързани с създаване AS.

13. На етап 6.1 "Разработване на работна документация за системата и нейните части" се разработва работна документация, съдържаща цялата необходима и достатъчна информация за осигуряване на изпълнението на работата по въвеждане в експлоатация на АЕЦ и нейната експлоатация, както и за поддържане на нивото на експлоатационните характеристики (качество) на системата в съответствие с приетите проектни решения, нейното изпълнение, съгласуване и одобрение. Видове документи - съгласно GOST 34.201.

14. На етап 6.2 „Разработване или адаптиране на програми“ се извършва разработването на програми и софтуерни инструменти на системата, изборът, адаптирането и (или) обвързването на закупени софтуерни инструменти, разработването на софтуерна документация в съответствие с GOST 19.101 навън.

15. На етап 7.1 "Подготовка на обекта за автоматизация за въвеждане в експлоатация на АС" се извършва работа по организационната подготовка на обекта за автоматизация за въвеждане в експлоатация на АС, включително: изпълнение на проектни решения относно организационната структура на AU; осигуряване на звена на контролния обект с инструктивни и методически материали; въвеждане на информационни класификатори.

16. На етап 7.2 "Обучение на персонала" се обучава персонал и се проверява способността му да осигурява функционирането на АЕЦ.

17. На етапа "Опаковане на АЕЦ с доставени продукти" се осигурява получаването на компоненти от серийно и единично производство, материали и монтажни продукти. Извършете контрол на качеството на входа.

18. На етап 7.4 "СМР" се извършват: изграждане на специализирани сгради (помещения) за разполагане на технически съоръжения и персонал на АЕЦ; изграждане на кабелни канали; извършване на работи по монтаж на технически средства и комуникационни линии; изпитване на монтирани технически средства; доставка на технически средства за въвеждане в експлоатация.

19. На етап 7.5 „Въвеждане в експлоатация“ извършва офлайн настройка на хардуер и софтуер, зареждане на информация в базата данни и проверка на системата за нейната поддръжка; комплексна настройка на всички средства на системата.

20. На етап 7.6 "Провеждане на предварителни тестове" се извършват:

изпитвания на АС за изпълнение и съответствие с техническото задание в съответствие с програмата и методиката на предварителните изпитвания;
отстраняване на неизправности и извършване на промени в документацията за АЕЦ, включително експлоатационната документация в съответствие с протокола за изпитване;
регистрация на акта за приемане на АЕЦ за опитна експлоатация.

21. На етап 7.7 "Провеждане на опитна експлоатация" се провежда опитна експлоатация на АЕЦ; анализ на резултатите от пробната експлоатация на АЕЦ; финализиране (при необходимост) на софтуера на АС; допълнителна настройка (при необходимост) на технически средства на АС; регистрация на сертификата за завършване на пробна експлоатация.

22. На етап 7.8 "Провеждане на тестове за приемане" извършете:

изпитвания за съответствие с техническите спецификации в съответствие с програмата и методиката на приемни изпитвания;
анализ на резултатите от тестовете на AU и отстраняване на недостатъците, установени по време на тестовете;
регистрация на акта за приемане на АЕЦ в постоянна експлоатация.

23. На етап 8.1 "Извършване на работа в съответствие с гаранционните задължения" се извършва работа по отстраняване на недостатъците, установени по време на експлоатацията на АЕЦ в установените гаранционни срокове, извършване на необходимите промени в документацията за АЕЦ.

24. На етап 8.2 "Следгаранционно обслужване" се извършват работи по:

анализ на функционирането на системата;
установяване на отклонения на действителните експлоатационни характеристики на АЕЦ от проектните стойности;
установяване на причините за тези отклонения;
отстраняване на установените недостатъци и осигуряване на стабилност на експлоатационните характеристики на АЕЦ;
извършване на необходимите промени в документацията за АС.

ПРИЛОЖЕНИЕ 2. Справка

СПИСЪК НА ОРГАНИЗАЦИИТЕ УЧАСТВАЛИ В СЪЗДАВАНЕТО НА АС

1. Клиентската организация (потребител), за която ще бъде създаден AU и който осигурява финансиране, приемане на работа и експлоатация на AU, както и изпълнението на отделни работи за създаване на AU.

2. Организация-разработчик, която извършва работа по създаването на AU, предоставяйки на клиента набор от научни и технически услуги на различни етапи и етапи на създаване, както и разработване и доставка на различен софтуер и хардуер на AU.

3. Организация доставчик, която произвежда и доставя софтуер и хардуер по поръчка на разработчик или клиент.

4. Организация-генерален проектант на обекта за автоматизация.

5. Организации-проектанти на различни части от проекта на обекта за автоматизация за строителни, електрически, санитарни и други подготвителни работи, свързани със създаването на АС.

6. Строително-монтажни, наладъчни и други организации.

Бележки:

1. В зависимост от условията за създаване на AU са възможни различни комбинации от функции на клиента, разработчика, доставчика и други организации, участващи в създаването на AU.

2. Етапите и етапите на тяхната работа по създаването на AU се определят въз основа на този стандарт.

ИНФОРМАЦИОННИ ДАННИ

1. РАЗРАБОТЕНО И ВЪВЕДЕНО от Държавния комитет на СССР за управление на качеството и стандартите на продуктите

РАЗРАБОТЧИЦИ

Ю.Х. Вермишев, д-р техн. науки; Я.Г. Виленчик; В И. Воропаев, д.т.н. науки; Л.М. Зайденберг, д-р. техн. науки; Ю.Б. Ирц, д-р. техн. науки; В.Д. Костюков, д.ф.н. техн. науки; М.А. Лабутин, конд. техн. науки; Н.П. Лесковская; И.С. Митяев; V.F. Попов (водещ на темата); С.В. Гаршин; ИИ глух вярващ; ЮГ. Жуков, д.ф.н. науки; З.П. Задубовская; В.Г. Иванов; Ю.И. Караванов, гл. науки; А.А. Клочков; В.Ю. Королев; В И. Махнач, д-р. техн. науки; С.Б. Михалев, д-р техн. науки; В.Н. Петрикевич; В.А. Рахманов, д-р. икономика науки; А.А. Раткович; Р.С. Седегов, доктор по икономика. науки; Н.В. Степанчиков; ГОСПОЖИЦА. Суровец; А.В. Флегентов; Л.О. Хвилевски, д-р. техн. науки; VC. Чистов, д.ф.н. икономика науки

2. УТВЪРДЕНИ И ВЪВЕДЕНИ С Указ Държавен комитетСССР за управление на качеството на продуктите и стандарти от 29.12.90 г. № 3469

Въведение

AT модерен святВсеки ден се появяват десетки и стотици различни програми, приложения, информационни системи. Те могат да бъдат разработени за публичния или търговския сектор, както и за обикновени потребители. 90% от всички потребители не четат документацията, смятат я за скучна, скучна и безинтересна и отварят ръководството за потребителя само когато нещо не работи или е напълно невъзможно да го разберете без инструкции. Вече е обичайно да се изгражда потребителски интерфейс по такъв начин, че да е интуитивен и потребителят да може да разбере системата, без да прибягва до четене на дълги ръководства. Въпреки това, когато работите с големи клиенти, почти винаги е необходимо да представите определен пакет от документи - ръководства, инструкции, дизайнерски решения, изготвени в съответствие с GOST.
Когато за първи път се сблъскате с писане на документация в съответствие с GOST, изпадате в ступор и пълен шок, тъй като тези GOST са „морето“ и как и какво да пишете върху тях става неясно.
Тази статия разглежда GOSTs за писане на документация и техните основни точки.

Какво представляват GOST?

Първо трябва да разберете какво представляват GOST. Всички просто знаят, че GOST е нещо, което е разработено в рамките на Съюза и има просто безкраен брой от тях. Бързам да ви уверя, че няма толкова много GOST за ИТ сферата и всички те, въпреки времето на създаване, не са загубили своята актуалност.
На първо място, стандартите за писане на документация са разделени на два вида:

Международни стандарти (ISO, IEEE Std);
Руски или съветски ГОСТ.

Международни стандарти
Международните стандарти се използват за разработване на документация на международно ниво. По правило те не са безплатни, тъй като не се разработват от държавни организации, но за разлика от нашите са разработени съвсем наскоро. Темата за международните стандарти е много обширна, така че ще бъде разгледана в друга статия. Веднага се засягат няколко стандарта, които са тясно свързани с писането на документация.
Списък на основните международни стандарти за писане на документация:

IEEE Std 1063-2001 "IEEE Standard for Software User Documentation" - стандарт за писане на потребителско ръководство;
IEEE Std 1016-1998 "IEEE Recommended Practice for Software Design Descriptions" - стандарт за писане на техническо описание на програма;
ISO/IEC FDIS 18019:2004 „Указания за проектиране и подготовка на потребителска документация за приложен софтуер“ е друг стандарт за писане на ръководство за потребителя. Този документ има голям бройпримери. Така да се каже, това е по-скоро ръководство за писане на ръководство за потребителя. Начинаещите ще бъдат особено полезни;
ISO/IEC 26514:2008 „Изисквания за дизайнери и разработчици на потребителска документация“ е друг стандарт за дизайнери и разработчици на потребителска документация.

Всъщност има много международни стандарти и всяка страна има свои собствени, тъй като един и същ стандарт може не винаги да отговаря на европейските и азиатските компании.

Руски стандарти
Руските стандарти се разработват на държавно ниво. Всички те са абсолютно безплатни и всеки от тях е лесен за намиране в интернет. За да напишете документацията за програмата, се използват две серии от GOST 19 и 34. Именно за тях ще обсъдим по-нататък.

Каква е разликата между GOSTs от серия 19 и 34?

Първият въпрос, който възниква, е как по принцип тези GOST 19 и 34 се различават един от друг.
В GOST 19.781-90 " една системасофтуерна документация. Софтуер за системи за обработка на информация. Термини и определения” са дадени определения:

Програма - данни, предназначени за управление на специфични компоненти на система за обработка на информация с цел реализиране на определен алгоритъм.
Софтуер - набор от програми на системата за обработка на информация и програмни документи, необходими за работата на тези програми.

В GOST 34.003-90 „Информационни технологии. Набор от стандарти за автоматизирани системи. Автоматизирани системи. Термини и определения" е посочено определение:

Автоматизирана система (АС) - система, състояща се от персонал и набор от средства за автоматизиране на неговата дейност, прилагаща информационни технологии за изпълнение на установени функции.
В зависимост от вида на дейността, например, се разграничават следните видове АС: автоматизирани системи за управление (ACS), системи за компютърно проектиране (CAD), автоматизирани системи научно изследване(ASNI) и др.

В зависимост от вида на контролирания обект (процес) АСУ се разделя например на: АСУ технологични процеси(APCS), автоматизирани системи за управление на предприятия (APCS) и др.
GOST 34 също прави разделение на видове поддръжка на АЕЦ:

Организационни;
методичен;
Технически;
математически;
софтуер;
Информационни;
езикови;
юридически;
Ергономичен.

В резултат на това автоматизираната система не е програма, а комплекс от видове поддръжка, сред които има и софтуер. AS, като правило, носи организационно решение за конкретен потребител и клиент, а програмата може да бъде създадена и репликирана за голям брой потребители, без да е обвързана с което и да е предприятие.
Следователно, ако разработвате документация за програма, която сте създали за конкретно предприятие, тогава вашият GOST 34. Ако пишете документи за масова програма, тогава вашият GOST 19.

ГОСТ 34

Серията GOST 34 (GOST 34.xxx Стандарти за информационни технологии) се състои от:

GOST 34.201-89 Видове, пълнота и обозначения на документи при създаване на автоматизирани системи - този стандарт установява видовете, името, пълнотата и номерата на документите. Това е един от основните документи от серията GOST 34. Всъщност това е основен документ, така че начинаещите трябва първо да се запознаят с него.
GOST 34.320-96 Концепции и терминология за концептуални схеми и информационни бази - този стандарт установява основните концепции и термини на концептуални схеми и информационни бази, обхващащи разработването, описанието и прилагането на концептуални схеми и информационни бази, манипулирането на информация и описанието и прилагането на информационен процес. Стандартът определя ролята на концептуалната схема. Разпоредбите, изложени в него, имат препоръчителен характер и могат да се използват за оценка на системи за управление на бази данни (СУБД). Този документ не описва конкретни методи за използване на инструментите за поддръжка на концептуална схема. Езиците на концептуалната схема, описани в стандарта, не трябва да се считат за стандартни.
ГОСТ 34.321-96 Информационни технологии. Стандартна система за база данни. Референтен модел за управление - Този документ установява референтен модел за управление на данни.
Референтният модел дефинира обща терминология и концепции, свързани с данните на информационните системи. Такива термини се използват за дефиниране на услугите, предоставяни от системи за управление на бази данни или системи от речници на данни.
Референтният модел не взема предвид протоколи за управление на данни.
Обхватът на референтния модел включва процеси, които се занимават с управлението на постоянни данни и тяхното взаимодействие с процеси, които се различават от изискванията на конкретна информационна система, както и общи услуги за управление на данни за дефиниране, съхранение, търсене, актуализиране, въвеждане, копиране, възстановяване и прехвърляне на данни.
ГОСТ 34.601-90 Автоматизирани системи. Етапи на създаване - стандартът установява етапите и етапите на създаване на AU.
GOST 34.602-89 Техническо задание за създаване на автоматизирана система (Вместо GOST 24.201-85) - установява състава, съдържанието, правилата за обработка на документа „Техническо задание за създаване (разработване или модернизация) на системата. "
Този документ е един от често използваните документи от серията GOST 34. При разработването на TOR за този GOST трябва да се имат предвид други стандарти, дори ако този документ не съдържа препратки към тези стандарти.
ГОСТ 34.603-92 Информационни технологии. Видове тестове на автоматизирани системи - стандартът установява видовете тестове на AU автономни, интегрирани, тестове за приемане и пилотна експлоатация) и общите изисквания за тяхното изпълнение.
RD 50-34.698-90 Автоматизирани системи. Изисквания към съдържанието на документите – едно от важни документи 34 GOST, тъй като в него е описано съдържанието на почти всички документи, както и описание на всеки елемент в документа.
GOST R ISO/IEC 8824-3-2002 Информационни технологии. Абстрактна синтактична нотация, версия едно - Този международен стандарт е част от абстрактна синтактична нотация, версия 1 (ASN.1) и установява нотация за спецификацията на потребителски дефинирани и таблични ограничения.
GOST R ISO/IEC 10746-3-2001 Управление на данни и отворена разпределена обработка.
В този стандарт:
- определя как се специфицират системите с отворена разпределена обработка (ODP) с помощта на концепции, въведени в GOST R ISO/IEC 10746-2;
- идентифицират се характеристиките, по които системите се класифицират като ODP системи.
Стандартът установява рамка за координиране на разработването на стандарти за ODP системи.
GOST R ISO/IEC 15271-02 Процеси кръговат на животасофтуерни инструменти - този GOST е необходим повече, според мен, за анализатори в проектирането и моделирането на AU.
Този документ е полезен, от моя гледна точка, за чисто образователни цели.
GOST R ISO/IEC 15910-2002 Процес на създаване на потребителска документация на софтуерен инструмент - определя минимално необходимия процес за създаване на всички видове потребителска документация за софтуерен инструмент, който има потребителски интерфейс. Тези типове обхващат печатна документация (напр. ръководства за потребителя и карти за бърза справка), онлайн (онлайн) документация, помощен текст („помощи“) и системи за онлайн документация.

И така, въз основа на всичко написано по-горе, става ясно, че основните документи в 34 GOST 3: GOST 34.201-89, RD 50-34.698-90 и GOST 34.602-89.
Когато разработвате пакет от документация, за начало трябва да отворите GOST 34.201-89 и да изберете етапа на създаване Проектен проект, Технически проект и Работна документация. След това трябва да изберете документи за разработване, които съответстват на етапа на създаване.

Списък на документите 34 GOST

сцена създаване	Заглавие на документа	Кодът	Част проект	Приложено мързел да се проект но-оценка ноа док ченге ции	Приложено мързел да се експлоатация тация ноа горе кимион ции	Допълнителни инструкции
ЕП	Проектен лист	EP*	ИЛИ	—	—	—
ЕП	Обяснителна бележка Към черновата	P1	ИЛИ	—	—	—
EP, TP	Органиграма	ТАКА	ИЛИ	—	—	Допуска се включване в документа P3 или PV
	Структурна схема на комплекса технически средства	C1*	ТОГАВА	х	—
	Диаграма на функционалната структура	C2*	ИЛИ	—	—	При разработването на документи CO, C1, C2, C3 на етапа на ES е позволено да ги включите в документа P1
	специализиран (нов) технически средства	НА 9	ТОГАВА	х	—	По време на разработката на етап TP разрешено за включване към документ P2
	Схема за автоматизация	С3*	ТОГАВА	х	—	—
	Техническо задание за разработка специализиран (нов) технически средства	—	ТОГАВА	—	—	Проектът не включва
TP	Задачи за развитие санитарни и други раздели свързани с проекта със създаването на система	—	ТОГАВА	х	—	Проектът не включва
	Лист за технически проект	TP*	ИЛИ	—	—	—
	Списък на закупените продукти	VP*	ИЛИ	—	—	—
	Списък на входните сигнали и данни	В 1	И ОТНОСНО	—	—	—
	Списък на изходните сигнали (документи)	В 2	И ОТНОСНО	—	—	—
	Списък на задачите за развитие строителство, електричество, санитарни и други раздели свързани с проекта със създаването на система	НА 3	ТОГАВА	х	—	Разрешено е да се включи в документа P2
	Обяснителна бележка към техническия проект	P2	ИЛИ	—	—	Включва план за действие подготовка на обекта за въвеждане в експлоатация системи в експлоатация
	Описание на автоматизираните функции	P3	ИЛИ	—	—	—
	Описание на настройката на задачата (набор от задачи)	P4	ИЛИ	—	—	Разрешено е включването в P2 или P3 документи
	Описание на информацията осигуряване на система	P5	И ОТНОСНО	—	—	—
	Описание на организацията информационна база	P6	И ОТНОСНО	—	—	—
TP	Описание на системите за класификация и кодиране	P7	И ОТНОСНО	—	—	—
	Описание на масива информация	P8	И ОТНОСНО	—	—	—
	Описание на комплекса технически средства	P9	ТОГАВА	—	—	За задача е разрешено да се включи в документ 46 в съответствие с GOST 19.101
	Описание на софтуера осигурете	PA	НА	—	—	—
	Описание на алгоритъма (процедура на проектиране)	PB	МО	—	—	Допуска се включване в документи P2, P3 или P4
	Описание на организационната структури	PV	ОО	—	—	—
	Разположен план	C8	ТОГАВА	х	—	Разрешено е да се включи в документа P9
	Списък на оборудването и материали	—	ТОГАВА	х	—	—
	Изчисляване на местния бюджет	B2	ИЛИ	х	—	—
TP, RD	Оценка на проекта надеждност на системата	B1	ИЛИ	—	—	—
TP, RD	Чертеж на формуляр на документ (видео кадър)	C9	И ОТНОСНО	—	х	На етапа на ТП се допуска включват в документи P4 или P5
RD	Списък на притежателите оригинали	DP*	ИЛИ	—	—	—
	Декларация за оперативен документи	ED*	ИЛИ	—	х	—
	Хардуерна спецификация	НА 4	ТОГАВА	х	—	—
	Лист с изисквания в материали	НА 5	ТОГАВА	х	—	—
	Изявление за машинни медии информация	VM*	И ОТНОСНО	—	х	—
	Входен масив	НА 6	И ОТНОСНО	—	х	—
RD	Директория на бази данни	НА 7	И ОТНОСНО	—	х	—
	Състав на продукцията (съобщения)	НА 8	И ОТНОСНО	—	х	—
	Местни оценки	B3	ИЛИ	х	—	—
	Методика (технология) автоматизиран дизайн	I1	ОО	—	х	—
	Технологична инструкция	И 2	ОО	—	х	—
	Упътване	I3	ОО	—	х	—
	Инструкции за формиране и управление на бази данни (набор от данни)	I4	И ОТНОСНО	—	х	—
	Ръководство с инструкции за KTS	IE	ТОГАВА	—	х	—
	Схема на свързване на външно окабеляване	С4*	ТОГАВА	х	—	Разрешено е извършването в маси
	Електрическа схема външни публикации	С5*	ТОГАВА	х	—	Един и същ
	Таблица на връзките и връзките	C6	ТОГАВА	х	—	—
	Диаграма на разделяне на системата (структурен)	E1*	ТОГАВА	—	—	—
	Чертеж на общ изглед	В*	ТОГАВА	х	—	—
	Инсталационен чертеж на технически средства	SA	ТОГАВА	х	—	—
	електрическа схема	сб	ТОГАВА	х	—	—
	Структурна схема на комплекса технически средства	C1*	ТОГАВА	х	—	—
	Разположение на оборудването и окабеляването	C7	ТОГАВА	х	—	—
	Описание на технологичните процес на обработка данни (вкл дистанционна работа)	PG	ОО	—	х	—
	Общо описание на системата	PD	ИЛИ	—	х	—
	Програма и методология за изпитване (компоненти, комплекси от оборудване за автоматизация, подсистеми, системи)	PM*	ИЛИ	—	—	—
	форма	FD*	ИЛИ	—	х	—
	Паспортът	PS*	ИЛИ	—	х	—
*Документи, чийто код е зададен в съответствие с изискванията на стандартите ESKD

Бележка към таблицата:

В таблицата се приемат следните обозначения:
- ЕП - идеен проект;
- ТП - технически проект;
- РД - работна документация;
- ИЛИ - системни решения;
- OO - решения за организационна поддръжка;
- ТО - решения за техническа поддръжка;
- IO - решения за информационна поддръжка;
- Софтуер - софтуерни решения;
- MO - софтуерни решения.
Знак X - показва принадлежност към проектните оценки или експлоатационната документация.
Номенклатурата на едноименните документи се установява в зависимост от дизайнерските решения, приети при създаването на системата.

Когато се определи списъкът с документи, тогава в RD 50-34.698-90 трябва да намерите избраните документи и да ги разработите стриктно според посочените точки. Всички елементи от съдържанието, които са посочени, трябва да присъстват в документа.
Ако се разработва Техническото задание, тогава незабавно трябва да отворите GOST 34.602-89 и да разработите TOR стриктно според точките.

ГОСТ 19

Серия от GOSTs 19 (GOST 19.xxx Единна система за програмна документация (ESPD)) се състои от:

1. ГОСТ 19.001-77 Общи разпоредби - също общ документ, няма практическа полза. Следователно може да се пропусне.
2. GOST 19781-90 Термини и определения - добър списъкопределения в областта на софтуера за системи за обработка на информация. Не съдържа нищо повече от дефиниции.
3. GOST 19.101-77 Видове програми и политически документи - един от основните документи на 19 GOST. Именно с него трябва да започнете да работите с GOST 19, тъй като той съдържа пълен списък и обозначения на GOST документи.

Списък на документите 19 GOST

Кодът	Тип документ	Етапи на развитие
		Схематично проект	Технически проект	работен вариант
		Схематично проект	Технически проект	компонент	комплекс
—	Спецификация	—	—
05	Списък на оригиналните притежатели	—	—	—
12	Програмен текст	—	—
13	Описание на програмата	—	—
20	Декларация на оперативни документи	—	—
30	форма	—	—
31	Описание на приложението	—	—
32	Управление системен програмист	—	—
33	Наръчник на програмиста	—	—
34	Ръководство за експлоатация	—	—
35	Езиково описание	—	—
46	Техническо ръководство обслужване	—	—
51	Тестова програма и методика	—	—
81	Обяснителна бележка			—	—
90-99	Други документи

Легенда:
- документът е задължителен;
- документ, задължителен за компоненти със самостоятелна употреба;
- необходимостта от изготвяне на документ се определя на етапа на разработване и одобряване на заданието;
- - документът не е съставен.

GOST 19.102-77 Етапи на развитие - съдържа описание на етапите на развитие. Полезно за образователни цели. Според мен особена практическа полза няма.
GOST 19.103-77 Обозначения на програми и програмни документи - съдържа описание на присвояване на номер (код) на документ. Дори след като прочетете този GOST, има много въпроси за това как да присвоите същия номер на документ.
GOST 19.104-78 Основни надписи - установява формите, размерите, местоположението и процедурата за попълване на основните надписи на листа за одобрение и заглавна страницав документите за политиката, предвидени от стандартите ESPD, независимо от това как се прилагат. Тъй като документите на 19 GOST са съставени в рамки, този документ е много важен.
GOST 19.105-78 Общи изисквания за програмни документи - установява общи изисквания за проектиране на програмни документи. Изискванията са твърде общи. По правило този GOST почти никога не се използва за разработване на документ, тъй като има достатъчно специален GOST за документа, но за общи познания е по-добре да погледнете този GOST веднъж.
GOST 19.106-78 Изисквания за печатни програмни документи - съдържа изисквания за дизайна на всички документи от 19 GOST.
GOST 19.201-78 Техническо задание, изисквания за съдържание и дизайн - установява процедурата за изграждане и изпълнение на задание за разработване на програма или софтуерен продукт.
Клаузите на TK 34 GOST и 19 GOST са различни.
GOST 19.601-78 Общи правила за копиране, отчитане и съхранение - Общи правилатиражиране, тиражиране, осчетоводяване и съхранение на програмни документи. В GOST няколко параграфа описват как да се уверите, че документите не се губят.
GOST 19.602-78 Правила за дублиране, отчитане и съхранение на програмни документи, извършвани чрез печат. Метод - допълнение към GOST 19.601-78.
GOST 19.603-78 Общи правила за извършване на промени - установява общи правила за извършване на промени в програмни документи. Всъщност той описва дълъг бюрократичен алгоритъм за извършване на промени в документи.
GOST 19.604-78 Правила за извършване на промени в печатни програмни документи - описва процедурата за работа и попълване от листа за регистрация на промените.

Списък на специализирани GOST, т.е. всеки от тях описва съдържанието и изискванията за конкретен документ:

GOST 19.202-78 Спецификация. Изисквания за съдържание и дизайн;
ГОСТ 19.301-79 Програма и процедура за изпитване. Изисквания за съдържание и дизайн;
GOST 19.401-78 Текст на програмата. Изисквания за съдържание и дизайн;
GOST 19.402-78 Описание на програмата;
GOST 19.403-79 Списък на оригиналните държачи;
GOST 19.404-79 Обяснителна бележка. Изисквания за съдържание и дизайн;
GOST 19.501-78 Форма. Изисквания за съдържание и дизайн;
ГОСТ 19.502-78 Описание на приложението. Изисквания за съдържание и дизайн;
GOST 19.503-79 Ръководство на системния програмист. Изисквания за съдържание и дизайн;
GOST 19.504-79 Ръководство на програмиста. Изисквания за съдържание и дизайн;
GOST 19.505-79 Ръководство за оператора. Изисквания за съдържание и дизайн;
ГОСТ 19.506-79 Езиково описание. Изисквания за съдържание и дизайн;
GOST 19.507-79 Декларация на експлоатационните документи;
GOST 19.508-79 Ръководство за поддръжка. Изисквания за съдържание и дизайн.

Процедурата за работа с 19 GOST:

В GOST 19.101-77 изберете документ и неговия код според етапа на разработка.
Съгласно GOST 19.103-77, задайте номер на документа.
След това, съгласно GOSTs 19.104-78 и 19.106-78, съставете документ.
От специализиран списък с GOST трябва да изберете този, който съответства на документа, който се разработва.

Заключение

GOST - не е страшно и лесно! Основното нещо е да разберете какво трябва да се напише и какъв GOST се използва за това. Основните ни GOST 19 и 34 за писане на документация са много стари, но все още са актуални и до днес. Писането на документация според стандарта премахва много проблеми между изпълнителя и клиента. Следователно спестява време и пари.

Дял: