GOST за софтуерни типове документи. Регистрация на програмата според GOST (как да). Единна система за програмна документация
Регистрация на програмна документация
Техническо задание за разработка на програмен продукт
3.2. Описание на програмата
3.3. Програмен текст
Тестова програма и методика
3.5. Изисквания към програмните документи, изработени в печатен вид
Приложение. Формата на технически спецификации за разработване на софтуерен продукт (продукти, модели)
Въведение. Общи сведения за Единната система за програмна документация (ЕСПД).
Единната система за програмна документация е набор от държавни стандарти, които установяват взаимосвързани правила за разработване, проектиране и разпространение на програми и програмна документация.
Стандартите ESPD определят общите разпоредби и основните стандарти, правилата за прилагане на документация за развитие, правилата за прилагане на производствена документация, правилата за прилагане на документация за поддръжка, правилата за прилагане на оперативна документация, правила за работа с програмна документация и други стандарти.
ESPD включва:
Основни и организационно-методически стандарти;
· стандарти, които определят формите и съдържанието на програмните документи, използвани при обработката на данни;
· стандарти, които осигуряват автоматизация на разработването на програмни документи.
Списъкът с ESPD документи включва следните GOST:
ГОСТ 19.001-77 ESPD. Общи положения.
ГОСТ 19.101-77 ESPD. Видове програми и програмни документи (преиздадени ноември 1987 г. с изменения).
ГОСТ 19.102-77 ESPD. Етапи на развитие.
ГОСТ 19.103-77 ESPD. Обозначаване на програми и програмни документи.
ГОСТ 19.104-78 ESPD. Основни надписи.
ГОСТ 19.105-78 ESPD. Общи изисквания към програмните документи.
ГОСТ 19.106-78 ESPD. Изисквания към програмните документи, изработени в печатен вид.
ГОСТ 19.201-78 ESPD. Техническо задание. Изисквания за съдържание и дизайн.
ГОСТ 19.202-78 ESPD. Спецификация. Изисквания за съдържание и дизайн.
ГОСТ 19.301-79 ESPD. Програма и тест процедура.
ГОСТ 19.401-78 ESPD. Програмен текст. Изисквания за съдържание и дизайн.
ГОСТ 19.402-78 ESPD. Описание на програмата.
ГОСТ 19.404-79 ESPD. Обяснителна бележка. Изисквания за съдържание и дизайн.
ГОСТ 19.501-78 ESPD. форма. Изисквания за съдържание и дизайн.
ГОСТ 19.502-78 ESPD. Описание на приложението. Изисквания за съдържание и дизайн.
ГОСТ 19.503-79 ESPD. Ръководство на системния програмист. Изисквания за съдържание и дизайн.
ГОСТ 19.504-79 ESPD. Наръчник на програмиста.
ГОСТ 19.505-79 ESPD. Ръководство за експлоатация.
ГОСТ 19.506-79 ESPD. Описание на езика.
ГОСТ 19.508-79 ESPD. Ръководство за поддръжка. Изисквания за съдържание и дизайн.
ГОСТ 19.604-78 ESPD. Правила за извършване на промени в програмните документи, които се отпечатват.
ГОСТ 19.701-90 ESPD. Схеми на алгоритми, програми, данни и системи. Конвенции и правила за изпълнение.
ГОСТ 19.781-90. Предоставяне на софтуер за системи за обработка на информация.
Други стандарти в областта на документиращите софтуерни системи (PS) включват:
ГОСТ 34.602-89 Информационни технологии. Набор от стандарти за автоматизирани системи. Техническо задание за създаване на автоматизирана система.
ГОСТ 34.601-90 Информационни технологии. Набор от стандарти за автоматизирани системи. автоматизирана система. Етапи на създаване.
GOST R ISO/IEC TO 12182-2002 Информационни технологии. Класификация на софтуера.
GOST R ISO/IEC 12207-99 Информационни технологии. Процеси на жизнения цикъл на софтуера.
GOST R ISO/IEC 14764-2002 Информационни технологии. Поддръжка на софтуер.
GOST R ISO/IEC 15026-2002 Информационни технологии. Нива на интегритет на системите и софтуера.
GOST R ISO/IEC TO 15271-2002 Информационни технологии. Указания за прилагане на GOST R ISO / IEC 12207-99.
GOST R ISO/IEC 15910-2002 Информационни технологии. Процесът на създаване на потребителска документация за софтуерен инструмент.
Международни стандарти ISO/IEC:
ISO/IEC 12207:2008 Системно и софтуерно инженерство – Процеси на жизнения цикъл на софтуера.
ISO/IEC 15288:2008 Системно и софтуерно инженерство - Процеси на жизнения цикъл на системата.
IEEE 830-1998 Препоръчителна практика за спецификации на софтуерни изисквания.
IEEE 1233-1998 Ръководство за разработване на спецификации на системни изисквания.
IEEE 1016-1998 Препоръчителна практика за описания на софтуерния дизайн.
ISO/IEC 42010 IEEE Std 1471-2000 Системно и софтуерно инженерство – Препоръчителна практика за описание на архитектурата на системи с интензивно използване на софтуер.
ISO 9001:2000 Системи за управление на качеството - Изисквания.
ISO/IEC 90003:2004 Софтуерно инженерство – Насоки за прилагане на ISO 9001:2000 към компютърен софтуер.
ISO/IEC TR 90005:2008 Софтуерно инженерство – Насоки за прилагане на ISO 9001:2000 към процесите на жизнения цикъл на системата.
ISO/IEC 9126-1:2001 Софтуерно инженерство - Качество на продукта - Част 1: Модел на качеството.
ISO/IEC 9126-2:2003 Софтуерно инженерство - Качество на продукта - Част 2: Външни показатели.
ISO/IEC 9126-3:2003 Софтуерно инженерство - Качество на продукта - Част 3: Вътрешни показатели.
ISO/IEC 9126-4:2004 Софтуерно инженерство - Качество на продукта - Част 4: Показатели за качество при използване.
ISO/IEC 25051:2006 Софтуерно инженерство – Изисквания за качество и оценка на софтуерен продукт (SQuaRE) – Изисквания за качество на търговски стандартен (COTS) софтуерен продукт и инструкции за тестване.
IEEE 829-1998 стандарт за документация за тестване на софтуер.
IEEE 829-2008 Стандарт за софтуерна и системна тестова документация.
IEEE 1008-1987 (R1993, R2002) Стандарт за тестване на софтуерни модули.
ISO/IEC 14598-1:1999 Информационни технологии - Оценка на софтуерен продукт - Част 1: Общ преглед.
ISO/IEC 14598-2:2000 Софтуерно инженерство - Оценка на продукта - Част 2: Планиране и управление.
ISO/IEC 14598-3:2000 Софтуерно инженерство - Оценка на продукта - Част 3: Процес за разработчици.
ISO/IEC 14598-4:1999 Софтуерно инженерство - Оценка на продукта - Част 4: Процес за придобиващи.
ISO/IEC 14598-5:1998 Информационни технологии - Оценка на софтуерен продукт - Част 5: Процес за оценители.
ISO/IEC 14598-6:2001 Софтуерно инженерство - Оценка на продукта - Част 6: Документиране на модули за оценка.
Както можете да видите, основната част от набора от вътрешни стандарти ESPD е разработена през 70-те и 80-те години. Отчасти тези стандарти са остарели и освен това не са лишени от някои недостатъци: първо, те не отразяват някои съвременни тенденции в дизайна на програми и програмна документация, и второ, тези стандарти съдържат многократно дублиране на фрагменти от програмна документация. Въпреки това, поради липса на по-добър начин, човек трябва да се съсредоточи върху тях.
Стандартите ESPD рационализират процеса на документиране на софтуерни системи. В същото време стандартите ESPD, въз основа на изискванията на клиента, позволяват да се направят някои промени в комплекта документация за софтуерни системи както в структурата, така и в съдържанието на установените видове програмни документи.
Освен това изброените по-горе стандарти имат консултативен характер и стават задължителни на договорна основа – т.е. когато се позовават на тях в договор за разработка или доставка на софтуер.
При разглеждане на правилата за съставяне на програмна документация трябва да се има предвид, че е желателно всеки документ да се предшества с въведение.
Уводът съдържа общи думи за уместност, необходимост и значимост и др. разработен софтуерен продукт.
Г О С У Д Р С Т В Е Н И С Т А Н Д А Р Т С О Ю З А С С Р
|
Единна система за програмна документация |
ГОСТ 19.401-78(ST SEV 3746-82) |
ПРОГРАМЕН ТЕКСТ.
|
|
|
Единна система за програмна документация. |
Постановление на Държавния комитет по стандартите на СССР от 18 декември 1978 г. № 3350 установи крайния срок за въвеждане
от 01.01. 1980 г
1. Този стандарт установява изисквания за съдържанието и дизайна на програмния документ "Програмен текст", определен от GOST 19.101-77.
Стандартът напълно отговаря на ST SEV 3746-82.
2. Структурата и дизайнът на документа са установени в съответствие с GOST 19.105-78.
Съставянето на информационната част (резюме и съдържание) не е задължително. За текста на програмата на изходния език, ако има анотация, тя включва кратко описание на функциите на програмата.
(Ревизирано издание, Рев. № 1).
3. Основната част на документа трябва да се състои от текстовете на един или повече раздели, които имат заглавия.
Също така е позволено да въвеждате имена за набор от секции.
4. Всеки от тези раздели се реализира чрез един от видовете символна нотация, например:
- символна нотация в изходния език;
- символна нотация в междинни езици;
- символно представяне на машинни кодове и др.
Преиздание (ноември 1987 г.) с поправки № 1, одобрени март 1983 г. (IUS 7-83)
Програмната документация е неразделна част от програмния продукт и трябва да бъде съставена в съответствие с Единната система за програмна документация (ESPD - GOST серия 19). Като част от обучителната работа е разрешено цялото съдържание на програмната документация да се включи в един „програмен доклад“, докато формалните изисквания за дизайн на такъв доклад съответстват на изискванията за доклада за научноизследователска и развойна дейност. Програмната документация, с изключение на официални документи (спецификация, списък на оригиналните притежатели, формуляр и др.), включва:
- · Техническо задание (цел, обхват на програмата, изисквания към програмата).
- · Текст на програмата (запис на програмата с необходимите коментари).
- · Описание на програмата (информация за логическата структура и функциониране на програмата).
- · Обяснителна бележка (схема на алгоритъма, общо описание на работата на алгоритъма и/или програмата, обосновка на взетите решения).
- · Оперативни документи.
Програмният документ "Обяснителна бележка" се изготвя на етапа на проект или технически проект на програмата. По правило не се използва на етапа на работния проект.
Оперативните документи включват:
- · Описание на приложението (информация за целта на програмата, обхват, прилагани методи, клас на задачите за решаване, ограничения за приложение, минимална конфигурация на хардуера).
- · Ръководство на системния програмист (информация за проверка, осигуряване на работата и настройка на програмата за условията на конкретно приложение).
- · Ръководство на програмиста (информация за работата на програмата).
- · Ръководство за оператора (информация за осигуряване на комуникация между оператора и компютърната система по време на изпълнение на програмата).
- · Описание на езика (описание на синтаксиса и семантиката на езика).
- · Ръководство за поддръжка (информация за използване на тестови и диагностични програми при поддръжката на хардуера).
Основната част от програмната документация се съставя на етап работен проект. Необходимостта от конкретен документ се определя на етапа на изготвяне на заданието. Допуска се комбиниране на отделни видове документи. Оперативният документ "Описание на езика" е включен в документацията на софтуера, ако разработеният софтуерен продукт изпълнява определен език за програмиране, управление на задачи, организация на изчислителния процес и др. Оперативният документ "Ръководство за поддръжка" е включен в документацията на софтуера, ако разработеният софтуерен продукт изисква използването на тестови или диагностични програми.
Програмен текстпредставлява символна нотация в изходен или междинен език или символно представяне на машинни кодове. Текстът на програмата е форматиран с шрифт monospace (Courier, Lucida Console и т.н.) в съответствие с общоприетите стандарти за дизайн:
- 1. Броят на операторите на ред трябва да бъде равен на 1.
- 2. Всички изрази, включени в съставен оператор, трябва да бъдат изместени надясно с еднакъв брой позиции, докато операторните скоби (т.е. това, което ограничава съставния оператор), свързани със същия блок, трябва да бъдат разположени по следния начин: отварящата скоба трябва да бъде на същия ред като оператора, който отваря блока, а затварящият трябва да е в същата колона, с която започва операторът, който отваря блока. Разрешено е поставянето на отваряща скоба на реда след оператора, който отваря блока, в същата колона, с която започва този оператор.
- 3. Ред от изходния текст на програмата трябва да бъде изцяло разположен в един типографски ред (до 80 знака в зависимост от шрифта). Неспазването на това правило показва твърде много блоково влагане, което означава неуспешен алгоритъм или програмна структура. В този случай се препоръчва преосмисляне на структурата на програмата, въвеждане на допълнителни функции, замяна на някои големи части от кода с техните извиквания, преработване на алгоритъма и т.н.
- 4. Ако синтаксисът на езика позволява, е желателно да се разделят знаците на операциите с интервали от операндите. Както в нормалния текст, запетаите трябва да бъдат последвани от интервал.
- 5. Дефинициите на функциите или логическите части на програмата трябва да бъдат разделени една от друга с празни редове.
- 6. Идентификаторите (имена на променливи, типове, подпрограми) трябва да бъдат достатъчно значими, така че читателят на програмния текст да може да разбере значението им без присъствието на автора наблизо. Ако е необходимо, декларацията на променлива или тип може да бъде придружена от коментар.
- 7. Текстът на програмата трябва да съдържа коментари, отразяващи функционалната цел на определен блок от програмата, структурата на програмата.
Документ Описание на програматасъдържа:
- · Обща информация (наименование на програмата, софтуер, необходим за работата на програмата, езици за програмиране, на които е написана програмата);
- Функционално предназначение (класове задачи за решаване, информация за функционални ограничения на приложението);
- Описание на логическата структура (алгоритъм на програмата, използвани методи, структура на програмата с описание на съставните части и връзката между тях);
- · Използван хардуер (видове компютри и устройства, които се използват в програмата);
- · Извикване и зареждане (метод за извикване на програмата от съответния носител на данни);
- · Входни данни (същност, организация и предварителна подготовка на входните данни, както и техния формат, описание и метод на кодиране);
- · Изходни данни (характер и организация на изходните данни, както и техния формат, описание и метод на кодиране).
Описанието на логическата структура на програмата трябва да бъде придружено от блок-схема на програмата. Документът "Описание на програмата" може също да съдържа схеми за данни, схеми за взаимодействие на програми, схеми за системни ресурси и др., Изготвени в съответствие с GOST 19.701-90.
Документ Описание на приложениетосе отнася за оперативни документи и се състои от следните раздели:
- · Цел на програмата (възможности, основни характеристики, ограничения на обхвата).
- · Условия за прилагане (изисквания за хардуер и софтуер, общи характеристики на входната и изходната информация, както и изисквания и условия от организационен, технически и технологичен характер).
- Описание на задачата (посочени са дефиниции на задачата и методи за нейното решаване).
- · Входни и изходни данни.
Документ Ръководство на системния програмистсе отнася за експлоатационни документи и се включва в документацията на програмата, ако разработеният софтуерен продукт изисква поддръжка от системен програмист. Документът се състои от следните раздели:
- · Обща информация за програмата (назначаване и функции на програмата, информация за техническите и софтуерни инструменти, които осигуряват изпълнението на тази програма).
- · Структурата на програмата (информация за структурата, връзката между модулите на програмата и с други програми).
- * Настройка на програмата (настройка на състава на техническите средства, избор на функции) /
- * Проверка на програмата (методи и методи за проверка, тестови случаи, методи за изпълнение, резултати).
- * Допълнителни функции.
- * Съобщения до системния програмист (текстове на съобщения, издадени по време на настройка, проверка на програмата, по време на изпълнение на програмата и описание на действията, които трябва да се предприемат спрямо тези съобщения).
Документът Ръководство за програмиста се отнася за оперативни документи и се включва в документацията на програмата, ако разработеният софтуерен продукт изисква поддръжка от програмиста. Документът се състои от следните раздели:
- * Целта и условията за прилагане на програмата (целта и функциите на програмата, информация за хардуера и софтуера, които осигуряват изпълнението на тази програма).
- * Характеристики на програмата (времеви характеристики, режими на работа, средства за наблюдение на правилното изпълнение и др.).
- * Обжалване на програмата (методи за прехвърляне на контрол и параметри на данни).
- * Входни и изходни данни (формат и кодиране).
- * Съобщения (текстове на съобщения, издавани на програмиста или оператора по време на изпълнение на програмата и описание на действията, които трябва да бъдат предприети по тези съобщения).
Ръководството на оператора се отнася до оперативни документи и се състои от следните раздели:
- * Целта на програмата (информация, достатъчна за разбиране на функциите на програмата и нейната работа);
- * Условия за изпълнение на програмата (минимален и/или максимален набор от хардуер и софтуер и др.);
- * Изпълнение на програмата (последователност от действия на оператора, които осигуряват зареждането, стартирането, изпълнението и завършването на програмата; описва функциите, форматите и опциите за команди, с които операторът зарежда и контролира изпълнението на програмата, както и на програмата отговори на тези команди);
- * Съобщения до оператора (текстове на съобщения, издадени на оператора по време на изпълнение на програмата и описание на действията, които трябва да бъдат предприети по тези съобщения).
При проектирането на текстови и графични материали, включени в програмната документация, трябва да се спазват действащите стандарти. Някои от тези стандарти са изброени по-долу. Дизайн на текст и графика. Текстовите документи се изготвят на листове А4, а графичният материал може да бъде представен на листове А3. Полетата на листа се определят в съответствие с общите изисквания: ляво - най-малко 30, дясно - най-малко 10, горно - най-малко 15 и долно - най-малко 20 mm. В текстовите редактори за дизайн на бележки параметрите на страницата се подреждат в зависимост от печатащото устройство. Когато ръчно подготвяте документи, настройките на страницата се избират за удобство. Номерацията на всички страници е непрекъсната. Номерът се поставя горе вдясно с арабски цифри. Страниците се считат за листове с текстове и чертежи, както и листове за приложение. Заглавната страница се счита за първа страница. Номерът на страницата на заглавната страница не е поставен. Имената на секциите се изписват с главни букви в средата на реда. Разстоянието между заглавията и текста, както и между заглавията на разделите и подразделите трябва да бъде равно на:
- * При машинописно изпълнение на документ - два интервала.
- * При ръкописно изпълнение - 10 мм.
Имената на подразделите и параграфите се поставят с абзацно отстъпление и се отпечатват подред с главна буква, без подчертаване и без точка в края. Разстоянието между последния ред на текста на предишния раздел и следващото заглавие, когато е поставено на една страница, трябва да бъде равно на:
- * При машинописно изпълнение на документ - три интервала.
- * При ръчно изпълнение - минимум 15 мм.
- * При използване на текстови редактори – определя се от възможностите на редактора.
Разделите и подразделите се номерират с арабски цифри с точка. Разделите трябва да имат поредни номера 1, 2 и т.н. Номерът на подраздела включва номера на раздела и серийния номер на подраздела, включени в този раздел, разделени с точка. Например: 2.1, 3.5. Препратките към параграфи, раздели и подраздели се обозначават с помощта на поредния номер на раздела или параграфа, например „в разд. 4", "в клауза 3.3.4". Текстът на разделите се отпечатва през 1,5-2 интервала. При използване на текстови редактори височината на буквите и цифрите трябва да бъде най-малко 1,8 мм (шрифтове № 11-12). Изброяванията се номерират с арабски цифри със скоба, например: 2), 3) и т.н. - с абзацно отстъп. Позволено е да се подчертае изброяването чрез поставяне на тире пред текстов елемент или знак, който го замества в текстови редактори. Проектиране на чертежи, схеми на алгоритми, таблици и формули. В съответствие с GOST 2.105-79 „Общи изисквания за текстови документи“ илюстрации (графики, диаграми, диаграми) могат да бъдат дадени както в основния текст, така и в приложението. Всички илюстрации се наричат чертежи. Всички фигури, таблици и формули са номерирани с арабски цифри последователно (чрез номерация) или в рамките на раздел (относителна номерация). В приложението - в рамките на приложението. Всяка фигура трябва да има надпис - заглавие, поставено под фигурата, например: Фиг.12. Формата на прозореца на главното меню.
Всички фигури, таблици и формули в бележката трябва да бъдат посочени във формата: „(Фиг. 12)“ или „формата на прозореца на главното меню е показана на фиг. 12". Ако мястото позволява, фигурите и таблиците трябва да се поставят непосредствено след параграфа, в който са споменати за първи път, или възможно най-близо до този параграф на следващите страници. Ако фигурата заема повече от една страница, на всички страници, с изключение на първата, се поставя номерът на фигурата и думата "Продължение". Например: Фиг. 12. Продължение.
Фигурите трябва да бъдат поставени така, че да могат да се разглеждат, без да се обръща страницата. Ако това разположение не е възможно, фигурите трябва да бъдат подредени така, че страницата да се завърти по посока на часовниковата стрелка, за да се види. В този случай горният ръб е левият ръб на страницата. Местоположението и размерите на полетата са запазени.
Алгоритъмните схеми трябва да бъдат направени в съответствие със стандарта ESPD. Дебелината на плътна линия при изчертаване на схеми на алгоритми трябва да бъде от 0,6 ... 1,5 mm. Надписите върху диаграмите трябва да са чертежни, височината на буквите и цифрите трябва да бъде най-малко 3,5 mm.
Номерът на таблицата се поставя в горния десен ъгъл или преди заглавието на таблицата, ако има такова. Заглавието, с изключение на първата буква, се прави с малки букви. Препратките към таблици в текста на обяснителната бележка са посочени под формата на думата "таблица". и номера на таблици. Например: Резултатите от теста са дадени в табл. 4.
Номерът на формулата се поставя от дясната страна на страницата в скоби на ниво формула. Например: z:=sin(x)+ln(y); (12)
Проектиране на приложения. Всяка кандидатура трябва да започва на нова страница с надпис „ПРИЛОЖЕНИЕ“ с главни букви в десния ъгъл и да има тематично заглавие. Ако заявките са повече от една, всички те се номерират с арабски цифри: ПРИЛОЖЕНИЕ 1, ПРИЛОЖЕНИЕ 2 и т.н. Например: ПРИЛОЖЕНИЕ 2 Заглавна страница на споразумението и обяснителна записка.
Фигурите и таблиците, поставени в приложението, са номерирани с арабски цифри във всяко приложение с добавяне на буквата „P“, Например: Фиг. С. 12 - 12-та рисунка на приложението; Ориз. P1.2 - 2-ри чертеж на 1-во приложение.
Ако приложението съдържа текста на програмата, тогава всеки файл се изготвя като картина с името на файла и неговото предназначение, например: Фиг. P2.4. Файлът menuran.pas е програма за преместване на курсора на главното меню.
Списъкът с литература трябва да включва всички използвани източници. Информацията за книги (монографии, учебници, ръководства, справочници и др.) трябва да съдържа: фамилия и инициали на автора, заглавие на книгата, място на издаване, издателство, година на издаване. При трима или повече автори се допуска посочване на фамилията и инициалите само на първия от тях с думите „и др.“. Издателството трябва да се цитира изцяло в именителен падеж: само два града могат да бъдат съкратени: Москва (М.) и Санкт Петербург (Санкт Петербург).
Информацията за статия от периодично издание трябва да включва: фамилия и инициали на автора, заглавие на статията, издание (списание), серия (ако има), година на издаване, том (ако има), номер на издание (списание). и номера на страници, на които е публикувана статията.
По този начин обмислихме как правилно да изготвим документация, така че да няма претенции от клиента. Разгледахме подробно какво съдържат документите като програмен текст, описание на програмата, описание на приложението, ръководство за системен програмист, ръководство за програмист, ръководство за оператора и как да съставим тези документи.
Основната цел на този текст е да разкаже какво представлява Единната система за програмна документация (ESPD) и как тези стандарти да се прилагат на практика. Ще започна с разказ за това какво представляват стандартите и ще завърша с опита от прилагането на всеки от стандартите ESPD поотделно.По едно време, когато тъкмо започвах да работя като програмист, често чувах „моля, напишете документация за вашата програма“. Честно описах всичко, дадох го на шефа, след което започна сесията на черната магия. След известно време шефът ме извика и започна да мърмори нечленоразделни звуци, мачкаше разпечатката на „най-добрия“ ми текст в ръцете си, тичаше с очи. Общият смисъл на неговото мучене беше, че се оказа „погрешно“, „погрешно“ и „вижте как правят другите“. Тъй като беше невъзможно да извлека друг отговор от него, отидох за примери на документи при „други“. Като правило това бяха весели момчета, смисълът на чиито речи беше, че „ето примери“, „всъщност според GOST“ и „никой не се нуждае от всичко това“. Така за първи път научих, че един програмист може да влезе в контакт с ужасни държавни стандарти.
Удивително е, че сред много десетки мои колеги, много интелигентни програмисти, нямаше никой, който да третира GOST по различен начин. Дори тези няколко души, които ги познаваха и, изглежда, дори знаеха как да съставят документи, се отнасяха към тях презрително-формално. Ситуацията, когато дори хората, отговорни за управлението на развитието, не разбират защо са необходими GOST и как ще бъдат приложени, се случва в много предприятия през цялото време. Да, имаше компании, които разбираха как „Описанието на програмата“ се различава от „Описанието на приложението“, но те бяха явно малцинство. В Интернет като цяло доминира гледната точка, че GOST за програмистите са очевиден рудимент и са необходими само ако се „огъват“ под тях. Проектът се смята за „сравнително честен начин да се вземат допълнителни банкноти от клиента“. Трябваше да се заровя и да го разбера сравнително наскоро - в процеса на разработване на система за управление на изискванията, съобразена с домашните специфики. Документация, която, разбира се, трябва да се генерира „според GOST“.
Тук искам да се съсредоточа само върху една тема, с която програмистът трябва да се занимава в местни предприятия, особено в изследователски институти - върху набор от стандарти ESPD. Не се смятам за голям експерт по ESPD - има хора, които работят по него от десетилетия и със сигурност ще ме коригират. Статията по-скоро се опитва да очертае контурите на „пътна карта“ за тези, които тепърва започват.
Стандарти
Нека разгледаме накратко какво представляват стандартите (с фокус върху ИТ областта).- международни. Отличителна черта - приета от международна организация. Пример за такава организация е ISO (Международна организация по стандартизация). Пример за неговия стандарт е ISO 2382-12:1988 (Периферно оборудване). Съвместните стандарти на ISO и Международната електротехническа комисия (IEC, на руски - IEC) са общи: например ISO / IEC 12207:2008 (жизнен цикъл на софтуера);
- регионален. Отличителна черта - приета от регионалната комисия по стандартизация. Например много съветски GOST вече са регионален стандарт, защото приет от междудържавния съвет, който включва някои от бившите съветски републики. Този съвет също приема нови стандарти - и те също получават обозначението GOST. Пример: GOST 12.4.240-2013;
- стандарти на обществени сдружения; Например, същият IEC: IEC 60255;
- национални стандарти. За Русия в началото на такива стандарти - „GOST R“. Може да има три вида:
- точни копия на международни или регионални. Те са обозначени по неразличим начин от „самостоятелно написани“ (национални, написани самостоятелно);
- копия на международни или регионални с допълнения. Те се обозначават чрез добавяне към шифъра на вътрешния стандарт на международния шифър, който е взет за основа. Например: GOST R ISO/IEC 12207;
- всъщност национални стандарти. Например GOST R 34.11-94.
Системите за нотиране на всяко ниво и във всяка организация са различни, за всеки случай ще е необходимо да се разбира отделно. За да разберете бързо „чий“ стандарт е пред очите ви, можете да използвате мамят лист.
ГОСТ
И така: стандартите са международни, междудържавни (регионални) и национални. GOST, както разбрахме, е регионален стандарт. GOST имат доста объркваща, според мен, система за нотиране. Той е напълно изложен в GOST R 1.5-2004, ще дам минимум, за да се ориентирам в него. Първо, необходимо е да се прави разлика между обозначението на GOST и неговата класификация. Обозначението е, грубо казано, уникален идентификатор на стандарта. Кодът на класификатора е спомагателен код, който ви помага да намерите стандарт или да определите към коя област на знанието принадлежи. Може да има много класификатори, като основно се използват два: KGS (класификатор на държавните стандарти) и неговият наследник OKS (общоруски класификатор на стандартите). Например: „ГОСТ Р 50628-2000" е обозначението на стандарта. Единственото, което е ясно от обозначението е, че е приет през 2000 г. Има OKS код „33.100;35.160“: т.е. “33” - раздел “Телекомуникации, аудио, видео”, “100” - подраздел “електромагнитна съвместимост”. Той обаче е включен и в клона на класификатора 35.160. “35” - “Информационни технологии. Офис машини”, “160” - “Микропроцесорни системи....”. И според CSC има код „E02“, което означава „E“ - „Електронна техника, радиоелектроника и съобщения“, „0“ - „Общи правила и разпоредби за електронна техника, радиоелектроника и съобщения“ и др. .Ако обозначението на стандарта е известно, тогава можете да получите неговите кодове за KGS и OKS, например, на този разумен сайт.
И така, обратно към обозначенията на GOSTs. Може да има два варианта:
- стандарт се отнася до поредица от стандарти. В този случай след индекса на категорията на стандарта (например GOST, GOST R или GOST RV) идва кодът на серията, точката и обозначението на стандарта в серията. Правилата за обозначаване на стандарти в серия се установяват от правилата на серията. Например: GOST RV 15.201-2000, GOST R 22.8.0-99, GOST 19.101-77;
- стандартът не принадлежи към поредица от стандарти. След това след индекса на категорията има просто пореден номер на стандарта, тире и годината на приемане. Например GOST R 50628-2000.
ESPD
ESPD е една от тези серии GOST, номер 19. Т.е. всички стандарти, свързани с ESPD, започват с префикса "19.": например GOST 19.106-78. Това означава "Единна система за програмна документация". Има и други серии:- GOST ESKD (унифицирана система за проектна документация, префикс "2.");
- GOST ESTD (унифицирана система за технологична документация, префикс "3.");
- GOST R, Система за разработване и производство на продукти, префикс "15.";
- GOST RV, Въоръжение и военна техника. Система за разработване и въвеждане на продукти в производство, префикс “15.”;
- GOST, Система от техническа документация за автоматизирани системи за управление, префикс "24.";
- GOST, Набор от стандарти за автоматизирани системи, префикс "34.".
19.001-77. Общи положения
Описва правилата за присвояване на обозначения на стандарти в серията ESPD. Не е необходимо на практика.19.102-80. Схеми на алгоритми и програми. Правила за изпълнение.
Описва правилата за конструиране и проектиране на алгоритми. Използва нотация от 19.103. В моята практика единственото време беше необходимо, когато лабораторията за сертифициране почиваше на формална основа, че е необходима схемата на алгоритъма. От моя гледна точка класическите блок-схеми с два крака са в миналото и единственото място, където са останали повече или по-малко актуални, е ако авторът иска да фокусира вниманието на читателя върху алгоритъма в презентацията.19.003-80. Схеми на алгоритми и програми. Условни графични символи
Дадени са графични обозначения на допустимите типове елементи на блоковата схема. Задължително, ако се използват блок-схеми.19.004-80. Термини и дефиниции.
Лош речник. От интересното - съдържа официални дефиниции на програмни и оперативни документи.19.005-85. P-схеми на алгоритми и програми
Един почти забравен език. По едно време P-диаграмите бяха широко използвани в ракетната и космическата индустрия, превръщайки се в де факто стандарт за писане на програми за контрол на изстрелването и симулация на изстрелване. Сега обаче този език е напълно забравен. В работата си никога не съм срещал R-схеми. Въпреки че в сравнение с блок-схемите те имат забележими предимства: те са компактни, подходящи за визуализиране на нелинейни алгоритми (например класове в C ++) или структури от данни. В същото време в интернет практически няма информация за тях: намерих този и този сайт за полезни. Във всеки случай, ако сега трябва да вмъкна диаграма на алгоритъм в документацията на софтуера, бих избрал P-диаграми, а не блок-схеми.19.101-77. Видове програми и програмни документи
Съдържа таблица на съответствието между вида на документа и неговия код, както и разделянето на видовете документи на оперативни и програмни. Въвежда се понятието комплекс и компонент. Няма нищо по-полезно.19.102-77. Етапи на развитие
Важен и необходим стандарт, който описва видовете документи и предоставя кодове за видовете програмни документи. Този стандарт (заедно с 19.103-77) е един от ключовете за „разкриване“ на обозначенията на документи като ABVG.10473-01 32 01-1.Стандартът въвежда концепцията за комплекс и компонент (някои предприятия добавят трети тип - комплект, когато става дума за несвързани софтуерни елементи), дава се разделение: кои документи са оперативни, кои не.
Внимателно трябва да се третира таблица 4, която показва кой документ на какъв етап на развитие се изпълнява. Етапите на разработка обикновено са регламентирани в стандартите за научноизследователска и развойна дейност и също така посочва кои документи трябва да бъдат представени на клиента на всеки етап.
19.102-77. Етапи на развитие
По мое спомен този стандарт никога не е бил прилаган: кой какво прави на какъв етап и как докладва е предписано в TTZ или се прави препратка към GOSTs, където това е по-ясно изписано (например GOST RV 15.203). В същото време, за начинаещ, той съдържа обобщение на работата на основните етапи на научноизследователската и развойна дейност, което не е лошо в своята сбитост.19.103-77. Обозначения на програми и програмни документи
Това е необходимо главно, за да се научите как да четете обозначенията на документи като горния. Разбирането на нотационната схема обаче е полезно, когато трябва да отидете отвъд типичната работа: например, не забравяйте, че документите с кодове след 90 са дефинирани от потребителя, т.е. всякакви. В моята практика издадохме документ 93, който нарекохме „Лист с програмна документация“, документ 96 - „Инструкции за сглобяване“.Общата фраза „версия на изпълнение“ отсъства в ESPD и се заменя с „номер на ревизия“. От една страна, това не е съвсем правилно: номерът на ревизията е замислен, за да проследи развитието на програмата: първо се пуска първото издание, а след това, например, след ревизия, второто. Но на практика, когато трябва да пуснете версия на софтуера за няколко операционни системи (междуплатформен софтуер), няма друг изход. По-точно - има, но грешно: задайте версия за всяка операционна система на нейното собствено обозначение - и поставете в архива няколко диска с изходни кодове (според броя на операционните системи), разработете (всъщност - копирайте) целия комплект на документация и др ... Т.е. чиста вода тъпа и объркваща дейност. Решението под формата на присвояване на версия за всяка операционна система на собствен номер на ревизия позволява някои от документите да бъдат общи.
В ESPD се използва обозначаването на изходните текстове на програмата и резултата от сглобяването като „документи“, което обърква много програмисти. Документът „Програмен текст“, съгласно 19.101-77, има обозначение 12. Освен това се предполага, че изходните кодове са обозначени като 12 01 - т.е. 01(първи) документ от тип 12, и двоични - като 12 02 - т.е. вторият документ на формуляр 12. В някои случаи са необходими допълнителни инструменти за изграждане на програмата - компилатори, генератори на инсталатори и др. Тези. програми, които не са включени в доставката, но са необходими за сглобяване. Решението може да бъде да ги обозначите като 12 03 - т.е. трети документ от тип 12.
19.104-78. Основни надписи
Описва двата листа на документа - лист за одобрение (AL) и заглавна страница. Листът за одобрение в ЕЕДОП съдържа подписите както на органите, одобрили документа, така и на разработчиците, нормативните контрольори, приемните представители и др. Тези. съдържа доста чувствителна информация за предприятието. Следователно в стандарта е прието, че LU остава в развиващото се предприятие и се изпраща само по специални инструкции. Още веднъж, LU не е част от документа, а е като че ли отделен документ и е включен в спецификацията като отделен ред.Първоначално смущаващата странност при отделянето на LL от самия документ има много добри причини:
- както вече споменахме, често предприятието не иска да разкрива информация за разработчика. Разделянето на LU и неговото „затягане“ позволява това да се направи (няма печат в ESPD върху листовете на документа, цялата информация е локализирана само в LU);
- редица предприятия използват смесен документооборот: оригиналните документи се съхраняват в електронен вид в архива на предприятието, а регистрационните номера за тях (с оригинални подписи) се съхраняват на хартиен носител;
Също така трябва да се помни, че LU не е номерирано и първата страница е заглавната страница, а първата страница, на която се поставя номерът, е тази, която следва заглавната страница. Но в случай, че LU е повече от едно (това се случва, ако всички подписи не се поберат на листа), тогава LU се номерират отделно.
19.105-78. Общи изисквания към програмните документи
Въвежда се общата структура на документа, която не зависи от начина на неговото изпълнение. Тези. още през 1978 г. в стандарта беше заложено, че документът не е задължително да е на хартиен носител. По-специално се въвежда понятието съдържание за изцяло електронни документи. За хартиената версия, обичайна по това време, беше приет GOST 19.106-78.Понастоящем този стандарт трябва да се използва много рядко: освен че се забравя редът на основните части на документа.
19.106-78. Общи изисквания към печатните програмни документи
Най-обемният стандарт от ESPD, отстъпващ само на описанието на R-схемите. Това е основният работен стандарт при подготовката на документацията. Въвежда правила за форматиране на текст, елементи от структурата на документа, изображения, формули и др. Въпреки това, за разлика от съответния 2.106 от ESKD, 19.106 е значително по-малко подробен, което води до множество несигурности.Първо, стандартът всъщност не определя разстоянието между редовете и размера на вертикалния отстъп между заглавията. Той въвежда три правила за интервали: за машинописен текст, машинен текст и типографски текст.
Машинописният текст е текст, набран на пишеща машина. Преместването на следващия ред спрямо предишния се извършва автоматично по време на така нареченото „връщане на каретката“ - преходът към отпечатване на следващия ред, произведен чрез преместване на специален лост. Обикновено разстоянието може да се регулира ръчно чрез завъртане на ролката за подаване на хартия и има "настройка", за да зададе разстоянието на единично или двойно.
Машина - това най-вероятно е отпечатаният текст. Но за него има само указание, че резултатът трябва да е подходящ за микрофилмиране. Това е косвена препратка към 13.1.002-2003, която, за съжаление, задава разстоянието между редовете (и, между другото, минималната височина на шрифта) само за ръкописни документи (клауза 4.2.5).
Типографски - текст, набран в типография. Като се има предвид годината на приемане на стандарта, най-вероятно говорим
[висок печат, където разстоянието между редовете се определя от използваните знаци. Не съм експерт по типография и сега има много малко информация за методите за набор.
Кой интервал да се използва в крайна сметка често се определя от местния регулаторен контрол или сервизи. Типичните стойности са 1,5 интервал и 14 размер на шрифта.
Начинът, по който е структуриран един документ, често повдига много въпроси. 19.106 счита, че целият документ е разделен на раздели, подраздели, параграфи и подпараграфи. Всички те (с изключение на раздела и подраздела) могат или не могат да имат заглавие. при което:
- „съдържанието на документа включва броя на разделите, подразделите, параграфите и подпараграфите, които имат заглавие“ (клауза 2.1.4). Това е пряка индикация, че подточката може да има заглавие и да бъде включена в съдържанието;
- „Разрешено е поставянето на текст между заглавията на раздел и подраздел, между заглавията на подраздел и параграф.“ Важно е да се отбележи, че неномериран текст може да бъде само между заглавията и само на горните 2 нива.
Този стандарт има редица „дупки“, несъответствия. Например се казва: „Илюстрациите, ако има повече от една в даден документ, се номерират с арабски цифри в целия документ. „Но ако има само една илюстрация, тогава тя е неномерирана и как тогава да се позоваваме на нея? Същото важи и за масите. За бележките под линия GOST не посочва как са номерирани - в рамките на целия документ или в рамките на страницата.
Маси. Самият документ съдържа препратка към GOST 1.5.68. Съдейки по първата серия, лесно е да се заключи, че това е стандарт за разработване на стандарти. И ето го, не е ясно. По смисъл съответства на правилата за проектиране на таблици в ESKD, с малки изключения. Този стандарт беше отменен, вместо това въведен след няколко итерации, 1.5-2012, в които правилата за форматиране на таблици ... просто изчезнаха. Още през 1,5-2002 г. бяха, а вече през 1,5-2004 г. изчезнаха. В реалния живот съставяме таблици според ESKD.
Приложения. Стандартът не посочва дали фигури, формули и таблици от приложения попадат в общия списък. По същия начин не се казва дали съдържанието трябва да разкрива структурата на приложението, ако то съдържа свои собствени раздели, параграфи и т.н. В нашата практика ние не разкриваме вътрешността на приложенията.
И накрая, трябва да се каже за отстъпите. Абзацният отстъп от 5 знака е обичаен за:
- червена линия;
- отстъп на елемента от структурата на документа след раздела (подраздел, параграф, подпараграф);
- елемент enum.
В този случай текстът, разположен на следващия ред след реда с отстъп, вече е подравнен към лявото поле. Често има грешки, когато отстъпът скочи - червената линия - една стойност, номерът на елемента - нас с различен интервал, във вложени отстъпи в списъци - това обикновено е необходимо.
В следващите части планирам да стигна до края на списъка с ESPD стандарти.
Правила за регистрация и изисквания към съдържанието на курсовата работа |
издание 2 |
||||
проекти (работи) и финални квалификационни работи |
страница 39 от 73 |
||||
Монтажен чертеж на монтажна единица |
|||||
под номер 8, включен в продукт 1 |
PK.760108.000 SB |
||||
Монтажен чертеж на отделен монтаж |
|||||
единици 4 |
PK.760004.000 SB |
||||
Чертеж на общ изглед на отделен монтаж |
|||||
единици 4 |
PK.760004.000 VO |
||||
Чертеж на част номер 16, включен в |
|||||
монтажна единица 8 продукт 1 |
|||||
Чертеж на част номер 120 включен в |
|||||
отделна монтажна единица 4 |
|||||
Електрическа схема на продукта 1 |
PK.760100.000 E3 |
||||
Схема кинематична принципна отделна |
|||||
монтажна единица 4 |
PK.760400.000 K3 |
||||
Спецификация на монтажната единица 8 продукт 1 |
|||||
10 Регистриране на технологични документи
10.1 Технологичните документи на курсови проекти (работи) и заключителни квалификационни работи се изготвят в съответствие с изискванията на стандартите ESTD.
10.2 Технологичните документи трябва да включват:
– заглавна страница, проектирана в съответствие с GOST 3.1105-84 „ESTD. Формуляр и правила за издаване на документи с общо предназначение” (Формуляр 2а).
– карта на маршрута, издадена в съответствие с GOST 3.1118-82 „ESTD. Образци и правила за издаване на маршрутни карти”;
– работни диаграми за обработка и работа
сетълмент и схеми за технологични операции, на машини с ЦПУ - в съответствие с GOST 3.1404-86 “ESTD. Формуляри и правила за обработка на документи за технологични процеси и разкройни операции”;
– ключарски работни карти,шлосерски и монтажни работи в съответствие с GOST 3.1407-86 „ESTD. Формуляри и изисквания за попълване и оформяне на документи за технологични процеси (операции), специализирани в монтажните методи”;
– карти за скици (ако е необходимо) съгласно GOST 3.1105-84 и GOST 3.1128-93 „ESTD. Общи правила за изпълнение на графични технологични документи”;
– оперативни карти за технологичен контрол в съответствие с GOST 3.1502-85 „ESTD. Формуляри и правила за оформяне на документи за технически контрол”;
– други технологични документи (при необходимост или по решение на ръководителя на проекта).
10.3 Чертежите за ремонт се правят в съответствие с правилата, определени от GOST 2.604-88 "Чертежи за ремонт".
10.4 Технологичните документи трябва да бъдат подвързани
директно в обяснителната бележка на курсовата (проектната) работа или след приложения, спецификации и списъци с елементи. Технологичните документи имат собствена номерация.
11 Изпълнение на полици
11.1 Разработени в курсови проекти (работи) и финални квалификационни документи, документите от различни проблемни области трябва да бъдат форматирани, както следва:
– програмни документи - съгласно изискванията на ЕЕДОП,
– документи за автоматизираната система за управление - съгласно държавните стандарти на системата за технологична документация за автоматизирани системи за управление. 11.2 Програмните документи (списъци с програми) трябва да включват:
– текстът на програмата, проектиран в съответствие с GOST 19.401;
– описание на програмата, направено в съответствие с GOST 19.402;
– описание на бележката, дадено в съответствие с GOST 19.502;
– други програмни документи (при необходимост).
11.3 Списъци с програми се поставят в приложения със задължителни връзки към тях в PP.
11.4 Програмният код може да бъде придружен от коментари. При изготвяне на обяви е препоръчително използването на шрифт Courier New, размер - 12 pt, разстояние между редовете - единично. Препоръчително е да разделяте семантичните блокове с празни редове, както и да обозначавате визуално вложени конструкции с помощта на отстъпи.
11.5 Ключовите думи и коментари в списъка с програми могат да бъдат в курсив. В основния текст на PP имената на библиотеки, подпрограми, константи, променливи и т.н. трябва да бъдат в курсив.
11.6 Списъците с програми трябва да бъдат последователно номерирани в приложението. Номерът на списъка трябва да се състои от обозначението на приложението и серийния номер на списъка, разделени с точка, например: "Списък A.3" - третият списък на Приложение А. Ако проектът (работата) съдържа само един списък, той е обозначен като "Листинг 1". При позоваване на обява в текста на ПП трябва да се изпише думата „Обява“ с посочване на нейния номер.
11.7 Името на списъка с програми е форматирано със същия шрифт като основния текст и се поставя над списъка вляво, без отстъп на абзаца, през тире, след номера на списъка.
Пример за дизайн на списъка на програмата Листинг A.3 - Програмата "Изход на двумерен масив"
mas:масив от цяло число; ( декларация на двумерен масив) i,j:цяло число;
Правила за регистрация и изисквания към съдържанието на курсови проекти (работи) и заключителни квалификационни работи - 09.1
(Въведете стойности на елемент от масив) за i:=1 до 5 do
за j:=1 до 5 направете readln(mas);
(Стойностите на елемента на изходния масив) за i:=1 до 5 започват
за j:=1 до 5 do write(" ",mas); writeln;
12 Съответствие
12.1 Контролът на нормата е последният етап в разработването на документи за курсов проект (работа) и WRC.
12.2 Стандартният контрол трябва да отговаря на изискванията на GOST 2.111.
12.3 Матурите подлежат на нормативен контрол. Нормативният контрол на курсовите проекти (работи) се извършва от преподавателя при защита на работата. Провеждането на нормативен контрол е насочено към правилното изпълнение на текстови и графични документи на курсови проекти (работи) и WRC (наричани по-долу документи) в съответствие с изискванията на стандартите GOST, ESKD, ESPD и ESTD.
12.4 Стандартният контрол се извършва от стандартния контролер, като се вземат предвид действащите изисквания, стандарти инормативни и технически документи.
12.5 В процеса на нормативен контрол на обяснителни бележки на курсови проекти (работи) и WRC се проверява следното:
– спазване на правилата за регистрация в съответствие с настоящия правилник;
- външен вид на софтуера;
- пълнота на ПП в съответствие със заданието за проектиране;
- правилността на попълване на заглавната страница, наличието на необходимите подписи;
- коректност на попълване на отчета за проекта (работата);
- наличието и коректността на рамката, основните надписи на всички страници;
- подчертаване на заглавия, раздели и подраздели, наличие на червени линии;
- правилността на дизайна на съдържанието, съответствието на заглавията на раздели и подраздели в съдържанието на съответните заглавия в текста на бележката;
- правилно номериране на страници, раздели, подраздели, фигури, таблици, формули;
- правилността на дизайна на чертежите;
- правилността на дизайна на масите;
- правилността на размерите на физическите величини, тяхното съответствие със SI;
– спазване на нормите на съвременния руски език;
- правилността на прилаганите съкращения на думите;
Правила за регистрация и изисквания към съдържанието на курсови проекти (работи) и заключителни квалификационни работи - 09.1
– наличие и коректност на препратките към използваните източници;
– наличие и коректност на препратките към нормативни документи;
– коректността на списъка с използвани източници;
– коректността на приложенията.
12.6 В процеса на нормативен контрол на графични документи на курсови проекти (работи) и WRC се проверява следното:
– съответствие на чертежите с изискванията на действащите стандарти;
– изпълнение на чертежи в съответствие с изискванията на нормативните документи;
– съответствие с форматите, правилността на техния дизайн;
– правилно рисуване и нанасяне на линии;
– съответствие с мащаба, правилността на тяхното обозначение;
– достатъчност на изображенията (изгледи, разрези, разрези), правилността на тяхното обозначение и местоположение;
– съответствие със символите на елементите в диаграмите и правилата за тяхното изпълнение в съответствие с изискванията на ESKD.
12.7. Препоръчително е да се извърши нормативен контрол на окончателните квалификационни работи на два етапа: след изготвяне (или в тънки линии) и окончателно разработване на оригинални документи. Разработените документи трябва да се представят за стандартен контрол в пълен комплект, т.е. текстова (обяснителна записка) и графична документация (чертежи, спецификации и др.).
12.8 Списъкът с коментари на нормативния контрольор се съставя в случай, че контролът се извършва в отсъствието на студент-разработчик и естеството на грешките може да бъде изтълкувано погрешно от него.
12.9 Документите, проверени от нормативния проверяващ в присъствието на студента-разработчик, заедно със списъка с коментари (ако е съставен), се връщат на студента за корекции и преглед. Ако има забележки, записките на нормоконтролера се запазват до подписването на документа. Ако документът е повторно обработен от студента, тогава двата екземпляра се предават за повторен контрол: с оценките на нормативния контрольор и преработени.
12.10 Документите, представени за подпис на нормативния контрольор, трябва да имат всички визи за одобрение, с изключение на визата на ръководителя на отдела. Окончателните оригинали на курсови и дипломни проекти (работи) се подписват от нормативника
V колона "N.counter." основен надпис.
12.11 Забранява се извършването без знанието на нормоконтролоравсякакви промени в документа, след като този документ бъде подписан и заверен от контрольора.
12.12 Контрольорът има право в обосновани случаи да не подпише представения документ:
- при неспазване на изискванията на нормативните документи;
- при липса на задължителни подписи;
- при небрежно изпълнение;
- при нарушаване на установената пълнота.
Правила за регистрация и изисквания към съдържанието на курсови проекти (работи) и заключителни квалификационни работи - 09.1
12.13 Нормативният контрольор отговаря за спазването на изискванията на действащите стандарти и други нормативни и технически документи в разработената документация наравно с разработчиците на документацията.
13 преглед на WRC
13.1 За получаване на допълнителна обективна оценка на окончателната квалификационна работа, представена за защита, се извършва външна проверка на крайната квалификационна работа от специалисти в съответната област.
13.2 Рецензентите на окончателните квалификационни работи са висококвалифицирани специалисти, чийто личен списък се определя от дипломиращия отдел. Може да се използва като рецензентпрактици и преподаватели от други университети.
Направлението за рецензия се издава от завършващата катедра, чийто образец е представен в Приложение Т на тези Правила.
13.3 Рецензентът трябва да е запознат с всички изисквания за крайната квалификационна работа (WQR).
13.4 Рецензията се извършва в писмена форма и съдържа мотивирани оценки:
– актуалността на темата за WRC;
– съответствие на съдържанието на WRC със заданието за разработването му;
– правилността на логическата структура на WRC;
– ефективност и обоснованост на проектните решения;
- предимствата и недостатъците на WRC, съответствието му с квалификационните изисквания на завършилия в областта на обучение;
- WRC регистрация.
В заключителната част на прегледа се правят изводи за пълнотата на разработването на темата, в съответствие с поставените задачи, за теоретичното или практическото значение на WRC, за възможната област на използване на резултати от WRC. Рецензентът оценява работата по скала от четири точки („отличен“, „добър“, „задоволителен“, „незадоволителен“) и посочва възможността за присвояване на подходящата квалификация на студента.
13.5 Обемът на прегледа на крайната квалификационна работа трябва да бъде 2-3 страници печатен или ясно ръкописен текст. Подписаната рецензия се предава в катедрата не по-късно от три дни преди защитата на WRC.
13.6 Прегледът може да бъде направен на бланката на организацията (място на работа на рецензента) или във формуляра на установения формуляр, регламентиран от тези правила (Приложение D) и заверен от печата на организацията или от печата на отдел "Личен състав" (общ отдел, канцелария) с отметка "верен подпис".
13.7 За защитата на WRC на държавната сертификационна комисия можете допълнително да представите преглед на водещата организация, по поръчка на която
Правила за регистрация и изисквания към съдържанието на курсови проекти (работи) и заключителни квалификационни работи - 09.1
извършено от WRC. Обратната връзка трябва да отбелязва практическата стойност на получените резултати.
14 Преглед на WRC
14.1 Обратната връзка за крайната квалификационна работа се съставя директно от нейния ръководител. Обратната връзка трябва да характеризира WRC от различни ъгли: от гледна точка на съдържание, структура, пълнота на разкриването на избраната тема и др.
14.2 Ръководителят е длъжен да изложи в рецензията обективното си мнение за крайната квалификационна работа на студента. По-специално прегледът трябва да съдържа информация за:
- относно уместността на темата на работа;
– относно съответствието на заключителната квалификационна работа с изискванията на стандартите;
- за притежанието на студента на методи за събиране, обработка и анализ на информация, използвана в областта на професионалната дейност;
- за способността на ученика самостоятелно да работи с източници ясно, ясно и последователно да представя материала;
- за положителните страни на работата;
- за недостатъците и забележките по съдържанието на работата и др.
14.3 Обратната връзка за крайната квалификационна работа на ръководителя може да съдържа предложения за цялостна оценка на работата.
14.4 В края на рецензията научният ръководител дава заключение за възможност за представяне на заключителната квалификационна работа за защита във ВАС.
14.5 Текстът на рецензията на ръководителя на WRC се отпечатва на листове А4 и се подписва от ръководителя. Формулярът за обратна връзка за WRC е представен в Приложение F.
15 Доклад и презентация
15.1 Докладът (речта) е произведение с представителен характер, отразяващо същността на WRC.
Докладът трябва да засяга уместността на избраната тема, теоретичните и методологическите основи на работата, както и да обобщава и обобщава резултатите, получени по време на изследването.
В края на речта е необходимо да се отрази практическото значение на резултатите, възможността за тяхното прилагане на практика или използване в обучението.
15.2 Докладът е предназначен за дадено ограничено време за изказване и е неразривно свързан с презентацията (хандата).
Правила за регистрация и изисквания към съдържанието на курсови проекти (работи) и заключителни квалификационни работи - 09.1
15.3 Презентация (хандут) е визуален цифров, табличен и илюстративен материал, изготвен с помощта на специални програми (например Microsoft PowerPoint), който е пряко свързан с доклада.
15.4 За презентацията се подбира необходимия илюстративен материал, който може да бъде взет както от текста на работата, така и от приложения. Това могат да бъдат таблици, фигури, диаграми, диаграми, формули и др. Таблиците не трябва да са обемисти, фигурите не трябва да бъдат прекалено подробни, формулите трябва да са ясни.
Материалът трябва да илюстрира всички тези, изведени в доклада.
15.5 Презентацията може да бъде показана по два начина:
– използване на проектора и на стойката;
– с помощта на листовки под формата на хартиени копия за всеки член на комисията.
Обемът на презентацията може да бъде от 8 до 12 слайда.
15.6 Докладът трябва да съдържа само същността на разглеждания въпрос, минимум цифрови данни, специални имена, изброявания.
Докладът е изграден по същата логическа схема като проекта (работата), а именно: уводна част, основна част и заключения. Уводната част трябва да съдържа уместността и целта на работата, основната част трябва да разкрива напълно разглежданата тема. Изводите трябва да са кратки и недвусмислени, трябва
в 1-2 изречения помислете за препоръки за решаване на поставените проблеми.
15.7 Първият трябва да бъде слайд с темата на проекта (работата) и данните на изпълнителя, т.е.: фамилно име, име, бащино име, група, специалност (направление). Желателно е да се посочи ръководител.
15.8 Курсовият проект (работа) и WRC се предават в архива заедно с презентация, направена в електронна форма и записана на цифров носител (например CD / DVD-диск).
Правила за регистрация и изисквания към съдържанието на курсови проекти (работи) и заключителни квалификационни работи - 09.1
Приложение А
Правила за регистрация и изисквания към съдържанието на курсови проекти (работи) и заключителни квалификационни работи - 09.1
Приложение Б
(име на факултета)
(име на отдела)
____________ ________________
ОБЯСНИТЕЛНА ЗАПИСКА
към курсовия проект (работа) по дисциплината (модул) __
(наименование на учебната дисциплина (модул))
по темата _________________________________________________________________________________
_____
_______________________ |
______________________________ |
|
Направление / специалност, профил / специализация:
___________ _________________________________________________________________
код на направление име на направление (специалност)
________________________________________________________________________________
име на профил (специализация)
Обозначаване на курсов проект (работа) _________________________ Група _______
Ростов на Дон
Приложение Б
МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО И НАУКАТА НА РУСКАТА ФЕДЕРАЦИЯ
ФЕДЕРАЛЕН ДЪРЖАВЕН БЮДЖЕТ ОБРАЗОВАТЕЛНА ИНСТИТУЦИЯ ЗА ВИСШЕ ПРОФЕСИОНАЛНО ОБРАЗОВАНИЕ
"ДОНСКИ ДЪРЖАВЕН ТЕХНИЧЕСКИ УНИВЕРСИТЕТ" (DSTU)
Факултет _______________________________________________________
(име на факултета)
Отдел ________________________________________________________________
(име на отдела)
Глава отдел "______________"
____________ ________________
ОБЯСНИТЕЛНА ЗАПИСКА
за дипломен проект (работа) на тема:
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
__________________________ |
||||
(подпис, дата) |
||||
Определяне на дипломния проект ______________________ |
Група ______________ |
|||
Направление (специалност) ___________ |
___________________________________ |
|||
(Име) |
||||
Мениджър на проекти (работа) |
____________________________ |
|||
(подпис, дата) |
(позиция, I.O.F.) |
|||
Консултанти по секция: |
||||
_______________________________ |
_____________________ |
|||
(име на раздел) |
(подпис, дата) |
(позиция, I.O.F.) |
||
_______________________________ |
_____________________ |
|||
(име на раздел) |
(подпис, дата) |
(позиция, I.O.F.) |
||
Нормален контрол |
_____________________ |
|||
(подпис, дата) |
(позиция, I.O.F.) |
|||
Ростов на Дон
Правила за регистрация и изисквания към съдържанието на курсови проекти (работи) и заключителни квалификационни работи - 09.1
