Обозначаване на документи според GOST 19. Дизайн на програмата според GOST (как да). Упражнение по компютърна грамотност

В.Е. Карпов

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

ТЕХНИЧЕСКО ЗАДАНИЕ (ГОСТ 19.201-78)

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

ЕТАПИ НА РАЗВИТИЕ (ГОСТ 19.102-77)

ОПИСАНИЕ НА ПРОГРАМАТА (ГОСТ 19.402-78)

ТЕКСТ НА ПРОГРАМАТА (ГОСТ 19.401-78)

ПРОГРАМА И МЕТОДИ ЗА ИЗПИТВАНЕ (ГОСТ 19.301-79)

ИЗИСКВАНИЯ КЪМ ПРОГРАМНИТЕ ДОКУМЕНТИ, НАПРАВЕНИ ПО ПЕЧАТНИЯ МЕТОД (ГОСТ 19.106-78)

Стандартизация в областта на софтуерната документация

Как да продължим напред

Подготовка на документация за софтуерни инструменти (PS) в съответствие със съществуващите GOSTs

2. Обща характеристика на държавата

2.3. Държавни стандарти на Руската федерация (GOST R)

2.4. Международен стандарт ISO/IEC 12207: 1995-08-01

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

Първо, способността за създаване на програмна документация определя професионалното ниво на програмиста. Клиентът няма да се задълбочи в тънкостите и характеристиките дори на най-прекрасната програма. Клиентът първо ще прочете документацията. Психологическият фактор също играе важна роля в това. По-специално, бившата съветска школа по програмиране беше ценена (и се цени сега) в целия свят. Съвременните местни програмисти са престанали да бъдат цитирани. Класът не е същият. В днешно време програмите вече не се пишат, а се компилират (и това са "две големи разлики"). Така че пакет от софтуерна документация (наричан по-долу PD), създаден в "класически" стил, ще създаде най-благоприятното впечатление за вашия клиент или работодател. Особено ако авторът на PD избягва фрази като "щракнете върху лентата за превъртане ...", "винт" и т.н. За съжаление, подобно бърборене на жаргон обикновено крие или недостиг на мисли, или пълна празнота (авторът беше незаличимо впечатлен от историята на един от неговите познати за определен „геймър“, който или „чати“ с някого там, или се занимаваше с „умеряване“ " Или нещо подобно.). Езикът на PD е вид бюрократичен, много консервативен език. Има свой собствен особен чар. Съгласете се, че термините твърд диск, флопи дисково устройство, ръчен манипулатор като "мишка" (или "колобок", както беше в един от старите PD пакети) звучат напълно различно от съответните "винт", "флоп" и просто "мишка". Между другото, нещата вече са стигнали до там, казват, дори се е появила специална специалност - технически писател, т.е. човек, който може да създава софтуерна документация.

Второ, добре съставен (по-точно създаден) PD пакет ще ви спести от много проблеми. По-специално, можете да се отървете от досадни въпроси и неоснователни твърдения, просто като насочите потребителя към документацията. Това се отнася на първо място за най-важния документ – техническото задание. Ще говорим за това по-долу, а сега можем да си припомним многомилионния иск срещу IBM. Този иск беше заведен от голяма издателска къща, недоволна от качеството на BT и софтуера. IBM спечели делото. И тя спечели само благодарение на това, че представи техническо задание, подписано от двете страни. Беше много отдавна, още през 70-те години, но това не променя същността на въпроса.

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

Първо трябва да се въоръжите с GOSTs. GOST определя всичко. По-конкретно, включва и интересуващата ни Единна система за програмна документация (ЕСПД). Може би най-трудното нещо е да получите самия GOST. GOST трябва да бъде само в печатна оригинална форма. Продават се (поне така беше) в специализирани магазини. По-специално, за придобиване на стандарти в областта на документацията, можете да се свържете със следните организации:

• ИПК "Издателство на стандарти", Териториален отдел за разпространение на научни и технически документи (магазин "Стандарти"), 17961, Москва, ул. Донская, д. 8, тел. 236-50-34, 237-00-02, факс/тел. 236-34-48 (относно GOST и GOST R).
• VNIIKI на Държавния стандарт на Русия (читалня), 103001, Москва, Granatny per. 4, тел. 290-50-94 (по отношение на международни, чуждестранни стандарти и други научно-технически документи).

И без цитати и вторични източници. GOST е законът. И още повече, че няма интернет (представете си съд, който произнася присъда, използвайки разпечатка на Наказателния кодекс, изтеглен от някакъв сайт). Не се доверявайте на никого освен на оригинала. По-нататък обаче авторът ще трябва да прибегне до цитиране на ESPD, като същевременно се освобождава от всякаква отговорност.

Нека започнем с общите разпоредби относно Единната система за програмна документация (които също са определени в съответния стандарт GOST 19.001-77).

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

Стандартите 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. Предоставяне на софтуер за системи за обработка на информация.

Както можете да видите, основната част от комплекса ESPD е разработена през 70-те и 80-те години. Отчасти тези стандарти са остарели и освен това не са лишени от някои недостатъци. Първо, те не отразяват някои съвременни тенденции в дизайна на програми и програмна документация, и второ, тези стандарти съдържат многократно дублиране на фрагменти от програмна документация. Въпреки това, поради липса на по-добър начин, човек трябва да се съсредоточи върху тях.

И така, стандартите ESPD рационализират процеса на документиране на софтуерни системи. Въпреки това, първо, съставът на програмните документи, предвиден от стандартите ESPD, изобщо не е толкова „твърд“, колкото може да изглежда: стандартите позволяват допълнителни типове да бъдат включени в комплекта документация на софтуерната система (PS), и, второ, въз основа на изискванията на клиента, някои промени както в структурата, така и в съдържанието на установените видове PD. Освен това може да се отбележи, че стандартите ESPD (и това важи и за всички останали стандарти в областта на PS - GOST 34, международния стандарт ISO / IEC и др.) имат консултативен характер. Факт е, че в съответствие със Закона на Руската федерация "За стандартизацията" тези стандарти стават задължителни на договорна основа - т.е. при позоваване на тях в договора за разработване (доставка) на ПС.

Преди да преминете към разглеждане на правилата за съставяне на програмна документация, е необходимо да направите следната забележка. Желателно е всеки документ да се предшества с въведение. Въведението е общо. За уместност, необходимост и т.н. Целта на Изпълнителя тук е да покаже значението и необходимостта от извършването на тази работа. Началото обикновено е стандартно: „Множеството съществуващи в момента системи ... ... отварят реални перспективи в ...“ и т.н. Тук обикновено се вмъкват цитати от изказвания на различни фигури (това е чисто психологически аспект): "... както беше казано на последния пленум, конгрес, конференция и т.н.). Можете също да започнете с факта, че ". .. Днес, в ерата на местните социално-икономически трансформации ... и т.н. ". Като цяло, основното тук е да не прекалявате.

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

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

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

Техническото задание се съставя на листове с формат А4 и / или А3, като правило, без попълване на полетата на листа. Номерата на листовете (страниците) се поставят в горната част на листа над текста.

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

Техническото задание трябва да съдържа следните раздели:

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

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

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

В глава Основа за развитиетрябва да се посочи:

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

По отношение на спецификата на учебния процес, заданието за курсово проектиране може да послужи като основа заповедта за института от __.__. за N ___., договор __.__. за N___. , и така нататък.

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

Например: Програмата е ядрото на автоматизираната работна станция (AWS) на разработчика на непрекъснати линейни автоматични системи за управление (ACS), което позволява на потребителя да решава проблемите с анализа на прости модели.

Глава Технически изисквания към програмата или програмния продукттрябва да съдържа следните подраздели:

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

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

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

Например: Програмата трябва да позволява ... да изчислява ... да изгражда ... да създава ...

Изходни данни: текстов файл с зададен ...

Изходни данни: графична и текстова информация – резултатите от анализа на системата ...; текстови файлове - отчети за ... диагностика на състоянието на системата и докладване на възникнали грешки.

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

Тук е трудно да се "отгатне" нещо. В най-добрия случай може да мине вариант, при който програмата ви работи само с абсолютно коректни данни. Обикновено Клиентът не е съгласен с това, но можете да опитате.

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

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

С тази точка обикновено не възникват трудности. За съжаление, въпросът за професионализма на потребителя задължително се подразбира от клиента. Това, разбира се, е още една причина да откриете грешки във вашата програма. Тук обаче можете да се ограничите до фрази като "Условията на работа на програмата съвпадат с условията на работа на IBM PC и съвместими компютри", "Програмата трябва да е предназначена за непрофесионален потребител." и така нататък.

Изисквания към състава и параметрите на техническите средства. Посочете необходимия състав от технически средства с посочване на техните технически характеристики.

Основното нещо тук е да не забравяте нищо и да предвидите всичко, от една страна (в противен случай ще подхлъзнат някой IBM PC / XT с монохромен дисплей и без мишка), а от друга страна, не прекалявайте с увеличените изисквания, в противен случай Клиентът ще намери по-отговорчив Изпълнител.

Например: Имате нужда от IBM PC съвместим компютър с EGA (VGA) графичен адаптер. Необходимото дисково пространство е поне 600 Kb, обемът на свободната RAM памет е поне 400 Kb. Желателно е да има EMS драйвер и мишка.

Изисквания за информационна и софтуерна съвместимост. Характеристиките са същите като в предишния параграф. Тук трябва да се посочат изискванията за информационните структури на входа и изхода и методите за решаване, изходните кодове, езиците за програмиране. Когато е необходимо, информацията и програмите трябва да бъдат защитени.

Например: Програмата трябва да работи автономно под MS DOS версия 3.3 или по-нова. Основният език за програмиране е Turbo Pascal 6.0.

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

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

Например: Няма специални изисквания към времевите характеристики на програмата. Няма специални изисквания към капацитивните характеристики на програмата.

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

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

Освен това е желателно да се даде определение както на прогнозната цена за разработване на програма, така и на определението за сложността на програмирането.

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

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

Основните и задължителни етапи и етапи са самото задание, идеен проект, технически и работни проекти.

• Идеен проект. На този етап се разработват подробно структурите на входните и изходните данни, определя се формата на тяхното представяне. Разработват се общо описание на алгоритъма, самият алгоритъм и структурата на програмата. Разработва се план за действие за разработване и изпълнение на програмата.
• Технически проект. Съдържа разработения алгоритъм за решаване на проблема, както и методи за контрол на първоначалната информация. Той също така разработва инструменти за обработка на грешки и издаване на диагностични съобщения, определя формите на представяне на първоначалните данни и конфигурацията на техническите средства.
• Работен проект. На този етап се извършва програмиране и отстраняване на грешки в програмата, разработване на програмни документи, програми и методи за тестване. Подготвят се примери за тестване и отстраняване на грешки. Документацията и графичният материал са финализирани. Обикновено се уточнява, че по време на разработването на програмата трябва да се подготви следната документация:

• програмен текст;
• описание на програмата;
• програма и тестова методика;
• описание на приложението;
• упътване за употреба.

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

Графиките може или не могат да бъдат налични. Особено когато няма да отчитате резултатите от работата си. Но за сериозни проекти този елемент е задължителен.

Например: При разработването на програмата трябва да се подготви следният графичен материал:

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

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

Например: Контролът и приемането на разработката се извършват въз основа на тестове за контрол и примери за отстраняване на грешки. Това проверява изпълнението на всички функции на програмата.

IN Приложениякъм заданието, ако е необходимо, водят:

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

• други източници на развитие.

Този стандарт установява етапите на разработване на програми, програмна документация, както и етапите и съдържанието на работата:

Етапи на развитие	Етапи на работа
Техническо задание	Обосновка за необходимостта от разработване на програма	Формулиране на проблема. Колекция от изворови материали. Избор и обосновка на критерии за ефективност и качество на разработената програма. Обосновка на необходимостта от изследователска работа.
	Изследователска работа	Определяне на структурата на входните и изходните данни. Предварителен избор на методи за решаване на проблеми. Обосновка на целесъобразността от използване на предварително разработени програми. Определяне на изискванията към техническите средства. Обосновка на принципната възможност за решаване на проблема.
	Разработване и утвърждаване на техническо задание	Определяне на изискванията към програмата. Разработване на предпроектно проучване за развитие на програмата. Определяне на етапи, етапи и срокове за разработване на програмата и документация по нея. Избор на езици за програмиране. Определяне на необходимостта от изследователска работа на следващите етапи. Съгласуване и утвърждаване на техническо задание.
Идеен проект	Разработване на идеен проект	Предварителна разработка на структурата на входните и изходните данни. Усъвършенстване на методите за решаване на проблема. Разработване на общо описание на алгоритъма за решаване на проблема. Разработване на предпроектно проучване.
	Одобрение на идеен проект	Съгласуване и одобряване на проектния проект
Технически проект	Разработване на технически проект	Усъвършенстване на структурата на входните и изходните данни. Разработване на алгоритъм за решаване на задачата. Определяне на формата на представяне на входните и изходните данни. Дефиниране на семантика и синтаксис на езика. Разработване на програмната структура. Окончателна дефиниция на хардуерната конфигурация.
	Одобрение на техническия проект	Разработване на план за действие за разработване и изпълнение на програми. Разработване на обяснителна записка. Съгласуване и одобрение на техническия проект.
работен вариант	Разработка на програма	Програмиране и отстраняване на грешки в програма
	Разработване на програмна документация	Разработване на програмни документи в съответствие с изискванията на GOST 19.101-77.
	Програмни изпитания	Разработване, съгласуване и утвърждаване на програмата и методите за изпитване. Провеждане на предварителни държавни, междуведомствени, приемни и други видове тестове. Корекция на програмата и програмната документация въз основа на резултатите от теста.
Внедряване	Подготовка и предаване на програмата	Подготовка и прехвърляне на програмата и програмната документация за поддръжка и (или) производство. Регистрация и одобрение на акта за прехвърляне на програмата за поддръжка и (или) производство. Прехвърляне на програмата във фонда от алгоритми и програми.

Бележки:

1. Допуска се изключване на втория етап на развитие, а в технически обосновани случаи - на втория и третия етап. Необходимостта от тези етапи е посочена в техническото задание.
2. Разрешено е комбиниране, изключване на работни етапи и (или) тяхното съдържание, както и въвеждане на други работни етапи, съгласувани с клиента.

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

Строго погледнато, има два различни документа, които обаче имат много общи неща. Това са ОБЩО ОПИСАНИЕ (ГОСТ 19.502-78) и ПРОГРАМНО ОПИСАНИЕ (ГОСТ 19.402-78). Въпреки това, поради факта, че е много трудно да се създаде качествено както едното, така и другото, без да се прибягва до почти пълно дублиране, разкъсване на парчета, би било достатъчно да се приложи един, по-общ, "хибриден" документ. Нека го наречем "Описание на програмата".

Всъщност „Описанието на програмата“ в своето съдържание може да бъде допълнено от раздели и параграфи, взети от стандартите за други описателни документи и ръководства: GOST 19.404-79 ESPD. Обяснителна бележка, GOST 19.503-79 ESPD. Ръководство на системния програмист, GOST 19.504-79 ESPD. Ръководство за програмист, GOST 19.505-79 ESPD. Ръководство за експлоатация и др. По-специално, от обяснителната бележка може да се вземе схемата на алгоритъма, общо описание на алгоритъма и (или) функционирането на програмата, както и обосновката на приетите технически и технически и икономически решения.

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

Основната част на документа трябва да се състои от уводна част и следните раздели:

• функционална цел;
• описание на логиката.
• условия за използване;
• състав и функции.

В зависимост от характеристиките на програмата е разрешено въвеждането на допълнителни секции.

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

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

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

Например: Програмата е предназначена да решава проблеми ... Програмата е ядрото на автоматизирано работно място ...

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

В глава " Описание на логиката" посочете:

• описание на структурата на програмата и нейните основни части

(например: Програмата включва следното:

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

• описание на функциите на съставните части и връзките между тях;

Например: Програмата се състои от шест модула: интерфейсен модул; дефиниционен модул ...; изчислителен модул ...; модул... и т.н.

Интерфейсният модул е ​​изграден от два типа диалогови прозорци: диалогов прозорец "въпрос - отговор" и диалогов прозорец тип "меню". Интерфейсният модул управлява...

Модул за дефиниция... Това е...

Модул за изчисление...и др.

• информация за езика за програмиране;

Например: Програмата е написана на езика ... с помощта на компилатора ...

• описание на входните и изходните данни за всеки от компонентите;

Например: ВХОДНИ ДАННИ. Входните данни за програмата са текстов файл, който описва разширената матрица на инцидентност на графиката на изследваната система.

ИЗХОД. Резултатът е:

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

• описание на логиката на съставните части (ако е необходимо, трябва да се състави описание на програмните схеми).

При описание на логиката на програмата е необходимо да се направи връзка към текста на програмата.

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

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

Например: Програмата се управлява на персонален компютър (PC), като IBM PC/AT. За работа в интерактивен режим се използват екранът на дисплея, клавиатурата и мишката. Необходим е EGA (VGA) адаптер за поддръжка на графичен режим. Входните данни се съхраняват на флопи и/или твърди дискове. Програмата работи на OS...

В допълнение към описанието могат да бъдат включени справочни материали (илюстрации, таблици, графики, примери и др.).

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

Система за повикване и зареждане

Изискванията за дизайна на текста на програмата са доста прости и естествени за компетентен програмист. Основното, от което трябва да се ръководите при създаването на този документ, е текстът на програмата да бъде четим.

Все още е задължително да се изготви информационна част - анотации и съдържание.

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

Текстът на всеки програмен файл започва с "заглавие", което показва:

• име на програмата,
• автор,
• дата на създаване на програмата,
• номер на версията
• дата на последна модификация.

Коментарите са задължителни, както и стриктно спазване на правилата за отстъп. Не забравяйте, че дори невъзможността да напишете програмна документация може да бъде оправдана. А грозният текст на програмата – никога. Позоваванията, че този текст е ясен за самия автор, не се приемат на сериозно. Програмните текстове не трябва да се срамуват да бъдат прочетени от други хора.

По-долу е даден пример за такъв добре четен програмен текст (взет от уебсайта на Николай Гехт, имейл: [имейл защитен], http://users.omskreg.ru/~geht)

/* Източници на Windows"98

Изходен код за Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # дефинирайте INSTALL = HARD char make_prog_look_big; void main() ( while(!CRASHED) ( display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) ( make_50_megabyte_swapfile(); do_nothing_loop(); totally_screw_up_HPFS_file_system(); search_and_destroy_the_rest_of_OS/2(); disable_Net disable_RealPlayer(); disable_Corel_Products(); hang_system(); ) write_something(anything); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(still_not_crashed) ( display_copyright_message(); do_nothing_loop(); basically_run_windows_3.1(); do_nothing_loop (); do_nothing_loop(); ) ) if(detect_cache()) disable_cache(); if(fast_cpu()) ( set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(реакция, понякога ); ) /* printf("Добре дошли в Windows 3.11"); */ /* printf("Добре дошли в Windows 95"); */ printf("Добре дошли в Windows 98"); if(system_ok()) crash(to_dos_prompt ) else system_memory = open("a:\swp0001.swp", O_CREATE); while(something) ( sleep(5); get_user_input(); сън(5); act_on_user_input(); сън(5); ) create_general_protection_fault();

Този документ съдържа описание на това какво трябва да се направи и как да се уверите (и убедите Клиента), че програмата работи правилно. Всъщност този документ е решаващ за тестовете за приемане. Добре разработената програма и методология за тестване са ключът към подписването на сертификат за приемане, т.е. тази, за която сте отделили толкова много време и усилия.

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

Компонентите на този документ са по-лесни и ясни за незабавно описване под формата на примери.

Тестови обект

Пример: Тестовият обект е програма ... предназначена за ...

Цел на тестването

Пример: Проверка на надеждността на програмата.

Програмни изисквания

Пример: Работата на програмата не трябва да води до повреда (фатално прекъсване на системата). Организацията на диалога трябва да осигурява защита срещу въвеждане на неверни данни. Програмата трябва да издава диагностика на състоянието на системата и съобщения за възникнали грешки ... и т.н.

Изисквания към софтуерната документация

Пример: Съставът на програмната документация, представена за тестване:

• описание на програмата (GOST 19.402-78);
• програма и методика за изпитване (GOST 19.301-79);
• програмен текст (GOST 19.401-78).

Средства и процедура за изпитване

Пример: Програмата работи в съответствие с условията на работа на MS DOS (версия 3.0 или по-нова) на компютър като IBM PC/AT, както и съвместим с него. За работа е необходим и EGA (VGA) адаптер.

Процедура на изпитване:

1. Програмата стартира...
2. Избрано...
3. Натиснат...
4. Последователно избрани...

Тестови случаи

Пример: За тестване се предлагат ..., чието описание се съдържа във файловете ... Съдържанието на тестовите файлове и резултатите от програмата са дадени в Приложение 1.

И накрая, помислете за най-новия стандарт ESPD, който се нарича

Този стандарт установява правилата за прилагане на програмни документи за компютри, комплекси и системи, независимо от тяхното предназначение и обхват и предвидени от стандартите ESPD.

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

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

Не се допускат повреди на листове с документи, петна и следи от ненапълно изтрит текст (графика).

Програмните документи се изготвят на листове формат А4. Освен това:

• дизайн на листове с формат A3 е приемлив;
• с машинния метод на изпълнение на документи се допускат отклонения в размера на листовете, съответстващи на формати А4 и А3, определени от възможностите на използваните технически средства; на листове формати А4 и А3, предвидени от изходните характеристики на устройствата за извеждане на данни, при машинно изготвяне на документ;
• когато правите документ по типографски начин, е възможно да използвате листове с типографски формати.

Местоположението на материалите на програмния документ се извършва в следната последователност:

• заглавна част:

• лист за одобрение (не е включен в общия брой листове с документи);
• заглавна страница (първата страница на документа);

• информационна част:

• анотация;
• лист със съдържание;

• Главна част:

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

• част за регистриране:

• промяна на регистрационния лист.

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

Допуска се включване в документа на части от програмния текст, съставен в съответствие с правилата на езика, на който е написан програмният текст.

Резюмето се поставя на отделна страница (страници), снабдена със заглавие "РЕЗЮМЕ", номерирана и включена в съдържанието на документа.

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

Заглавията на разделите се изписват с главни букви и се разполагат симетрично спрямо дясната и лявата граница на текста. Подзаглавията се пишат от абзаца с малки букви (с изключение на първата главна). Сричките на думите в заглавията не са разрешени. Не поставяйте точка в края на заглавието. Всеки раздел се препоръчва да започне на нов лист.

Разделите, подразделите, параграфите и алинеите се номерират с арабски цифри с точка. Секциите трябва да имат пореден номер (1, 2 и т.н.)

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

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

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

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

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

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

Препратките в текста към поредния номер на формулата се дават в скоби, например: "във формула (3)". При разделяне на документ на части номерът на частта се поставя пред поредния номер на формулата и се отделя от последната точка, например: "във формула (1.4)".

Значението на символите, включени във формулата, трябва да бъде дадено директно под формулата. Стойността на всеки знак се отпечатва на нов ред в реда, в който са дадени във формулата. Първият ред за дешифриране трябва да започва с думата "къде", без двоеточие след нея.

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

Позволено е да се посочи само обозначението на документа и (или) раздели, без да се посочват имената им. Не се допускат връзки към отделни подраздели, параграфи и илюстрации на друг документ. Допускат се препратки в документа към параграфи, илюстрации и отделни подраздели.

Бележки.Бележките към текста и таблиците показват само справочни и обяснителни данни. Една бележка не е номерирана. След думата "Забележка" поставете точка. Няколко бележки трябва да бъдат номерирани последователно с арабски цифри с точка. Думата "Забележка" е последвана от двоеточие. Допуска се текстът на бележките да се отпечатва само с един интервал.

Съкращения.Не се допускат съкращения на думи в текста и надписи под илюстрации, с изключение на:

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

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

Всяко приложение трябва да започва на нова страница с надпис "Приложение" в горния десен ъгъл и да има тематично заглавие. Ако в документа има повече от едно приложение, всички приложения се номерират с арабски цифри (без знака за цифра), например:

Приложение 1, Приложение 2 и др.

Когато заявлението се издава като отделен документ, на заглавната страница под името на документа трябва да се посочи думата "Заявление", а ако има няколко приложения, посочете и неговия пореден номер.

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

Единна система за програмна документация	ГОСТ 19.003-80 Вместо ГОСТ 19428-74
СХЕМИ НА АЛГОРИТМИ И ПРОГРАМИ. ОЗНАЧЕНИЕ УСЛОВНО ГРАФИЧНО
Единна система за програмна документация. Символи на графична блок-схема.

С Постановление на Държавния комитет на СССР по стандартите от 24 април 1980 г. № 1867 крайният срок за въвеждане

от 01.07.1981г

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

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

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

Стандартът отговаря на MS ISO 1028-73 по отношение на символите

1. СПИСЪК, НАИМЕНОВАНИЕ, ОЗНАЧЕНИЕ НА СИМВОЛИТЕ И ФУНКЦИИТЕ, ПОКАЗВАНИ ОТ ТЯХ

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

Маса 1.

Име	Обозначение и размери в мм	функция
1. Процес		Извършване на операции или група от операции, които променят стойността, формата на представяне или местоположението на данните
2. Разтвор		Избор на посоката на изпълнение на алгоритъм или програма в зависимост от някои променливи условия
3. Модификация		Извършване на операции, които променят команди или група от команди, които променят програмата
4. Предварително дефиниран процес		Използване на предварително създадени и отделно описани алгоритми или програми
5. Ръчна работа		Автономен процес, извършван ръчно или с неавтоматични средства
6. Спомагателна операция		Самостоятелен процес, изпълняван от устройство, което не се контролира директно от процесора
7. Обединяване		Комбиниране на два или повече комплекта в един комплект
8. Маркирайте		Премахване на един или повече комплекта от един комплект
9. Групиране		Обединение на два или повече комплекта с избор на няколко други комплекта
10. Сортирайте		Поръчване на комплект по зададени критерии
11. Ръчно въвеждане		Ръчно въвеждане на данни чрез on-line устройства с клавиатура, набор от ключове, бутони
12. Вход-изход		Преобразуване на данни във вид, подходящ за обработка (вход) или показване на резултатите от обработката (изход)
13. Онлайн памет		Входно-изходни данни в случай на използване на устройство за съхранение, управлявано директно от процесора
14. Офлайн памет		Вход/изход на данни в случай на използване на устройство за съхранение, което не се управлява директно от процесора
15. Документ		Вход-изход на данни, чийто носител е хартия
16. Перфокарта		Вход-изход на данни, чийто носител е перфокарта
17. Тесте перфокарти		Показване на набор от перфокарти
18. Файл		Представяне на данни, организирани на базата на общи характеристики, характеризиращи в съвкупност някакъв обект на обработка на данни. Символът се използва в комбинация със символи на специфични носители на данни, които изпълняват I/O функции.
19. Перфорирана лента		Вход-изход на данни, чийто носител е перфолента
20. Магнитна лента		Вход-изход на данни, чийто носител е магнитна лента
21. Магнитен барабан		Вход-изход на данни, чийто носител е магнитен барабан
22. Магнитен диск		Вход-изход на данни, чийто носител е магнитен диск
23. RAM		Вход-изход на данни, чийто носител е магнитопровод
24. Дисплей		Вход-изход на данни, ако устройство, директно свързано с процеса, възпроизвежда данни и позволява на компютърния оператор да прави промени по време на тяхната обработка
25. Комуникационен канал		Пренос на данни по комуникационни канали
26. Поточна линия		Задаване на последователност между знаците
27. Паралелни действия		Начало или край на две или повече едновременни операции
28. Конектор		Указване на връзка между прекъснати линии на потока, свързващи символи
29. Старт - стоп		Начало, край, прекъсване на обработка на данни или изпълнение на програма
30. Коментар		Връзка между схематичен елемент и обяснение

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

таблица 2

Име	Обозначение и размери в мм	функция
1. Съединител извън страницата		Индикация за връзката между несвързаните части на диаграмите на алгоритми и програми, разположени на различни листове
2. Магнитна карта		Вход-изход на данни, чийто носител е магнитна карта
3. Ръчен документ		Формиране на документ в резултат на ръчни операции
4. Архив		Съхраняване на набор от организирани носители за съхранение за повторна употреба
5. Офлайн обработка		Трансформация на изходни данни в резултат на офлайн операции
6. Декриптиране		Четене от носител за съхранение, транскодиране и отпечатване на същия или друг носител за съхранение в резултат на офлайн операция
7. Кодиране		Прилагане на кодирана информация към носителя в резултат на офлайн операция
8. Копиране

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

Единна система за програмна документация	ГОСТ 19.103-77
ОПРЕДЕЛЯНЕ НА ПРОГРАМИ И ПРОГРАМНИ ДОКУМЕНТИ
Единна система за програмна документация. Индексиране на програми и програмни документи.

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

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

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

3. Създава се регистрационна система за именуване на програми и програмни документи.

Структурата на обозначението на програмите и неговия програмен документ - спецификации:

А.б.XXXXX-XX
Обща част на обозначението / Код на държавата | | | |
програми и софтуер | Код на организацията на разработчика | | |
документи по него Регистрационен номер | |
Номер на изданието (за програмата) |
Номер на редакция (за документ) |

4. Структурата на обозначението на други политически документи:

A.B.XXXXX-XX XX XX-х
Обща част от обозначението на програмата | | | | |
и програмни документи за него | | | | |
Номер на редакция на документа | | | |
Код на вида на документа | | |
Номер на документа от този тип | |
Част номер на документа |

5. Кодът на страната-разработчик и кодът на организацията (предприятието)-разработчик се присвояват по предписания начин.

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

Преди одобрението на Всесъюзния класификатор на програмите е разрешено да се присвои регистрационен номер във възходящ ред, като се започне от 00001 до 99999, за всяка организация (предприятие)-разработчик.

Номерът на изданието на програмата или номерът на редакцията на документа се присвоява във възходящ ред от 01 до 99.

6. Кодът на вида на документа се определя в съответствие с изискванията ГОСТ 19.101-77.

7. Номерът на документа от този тип се присвоява във възходящ ред от 01 до 99.

8. Номерът на частта на същия документ се задава във възходящ ред от 1 до 9.

Забележка.Ако документът се състои от една част, тирето и серийният номер на частта не се посочват.

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

Преиздаване. ноември 1987 г