Чат поддержки

Практикум
Привет! Это поддержка Практикума 👋 Если что-то не получается — постараемся помочь. Пишите в чат или выберите другой способ связи

пт, 2 декабряв 17:21

Мы уже начали заниматься вашим вопросом, ответим в ближайшее время

Практикум

Здравствуйте!

Поддержка не сможет помочь с вопросами, связанными с теорией или задачам из курса «Системный аналитик» — в этой ситуации рекомендуем вам обратиться к вашему преподавателю в чате в Slack.

Если же у вас возникнут иные вопросы — обязательно пишите, будем рады помочь :)

17:24

Выбрать способ связи

Поменять когорту

Перейти в профиль

Выйти из профиля

Добавить аккаунт

Поддержка, обслуживание и оценка результатов

спринт Поддержка, обслуживание и оценка результатов

Рабочая документация

2/2

О чём этот спринт

Документирование по ГОСТ

План миграции

4/4

Постпроектная деятельность

1/1

Воркшоп и домашнее задание

2/2

Заключение

1/1

Пригласить друзей

Документирование по ГОСТ

В этом уроке вы узнаете, какие ГОСТы регламентируют формирование документации, какие документы они предусматривают, что входит в состав рабочей документации, для чего и как она формируется.

Айгуль

Начнём с документации. Скинула тебе ГОСТ 34 и ГОСТ 19. Посмотри!

Даня

Окей! А почему два?

Айгуль

Ну, они разные 😅 Но оба используются. Давай разберём!

О ГОСТах!

Для чего нужны стандарты на документацию и какие стандарты существуют?

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

Бывают ситуации, когда разработчики документации и заказчик имеют разное представление о количестве, структуре и содержании разрабатываемых документов. Это приводит к тому, что результаты работ не устраивают заказчика и приходится дополнительно тратить ресурсы на доработку документов. Использование стандартов при разработке документации позволяет избежать подобных ситуаций: стандарты дают чёткую структуру разрабатываемой документации, обладают свойствами полноты и непротиворечивости, а также снимают спорные вопросы между исполнителем и заказчиком к результатам работ.

Стандарты для написания документации делятся на два типа:

Международные стандарты (ISO, IEEE Std),

Советские и Российские стандарты (ГОСТ, ГОСТ Р).

В этом уроке мы рассмотрим основные российские стандарты. Для большинства государственных организаций и крупных корпоративных заказчиков в России разработка документации по ГОСТу является обязательным условием.

Российские государственные стандарты (ГОСТ) — это нормативно-правовые документы, в соответствии с требованиями которых производится стандартизация производственных процессов и оказания услуг. Каждый государственный стандарт обязательно проходит процедуру регистрации, которая проводится специальным государственным органом — Госстандартом. ГОСТы могут заменяться или отменяться.

Для написания документации на программные продукты используются две серии ГОСТов:

серия ГОСТ 34 Информационные технологии. Комплекс стандартов на автоматизированные системы, а также её актуальные преемники: ГОСТ Р 59793, ГОСТ Р 59792, ГОСТ Р 59795 и другие;

серия ГОСТ 19 Единая система программной документации (ЕСПД)

Ознакомиться с полным актуальным текстом этих стандартов можно на сайте Росстандарта.

Основные документы в составе серий ГОСТ 34 и 19

Состав требований по ГОСТ 34 и ГОСТ 19 отличается.

Каждая серия стандартов содержит множество документов, но на практике есть несколько наиболее часто используемых.

Основные документы в составе серии ГОСТ 34 (ИТ) и их производные:

ГОСТ Р 59853 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»

ГОСТ 34.201 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Виды, комплектность и обозначение документов»

ГОСТ Р 59793 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»

ГОСТ 34.602 «Техническое задание на создание автоматизированной системы»

ГОСТ Р 59792 «Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»

ГОСТ Р 59795 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»

Основные стандарты в составе серии ГОСТ 19 (ЕСПД):

ГОСТ 19.001 Единая система программной документации. Общие положения

ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов

ГОСТ 19.102 Единая система программной документации. Стадии разработки

ГОСТ 19.103 Единая система программной документации. Обозначения программ и программных документов

ГОСТ 19.105 Единая система программной документации. Общие требования к программным документам

ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

ГОСТ 19.301 Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению

ГОСТ 19.402 Единая система программной документации. Описание программы.Требования к содержанию и оформлению

ГОСТ 19.404 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению

ГОСТ 19.504 Единая система программной документации. Руководство программиста. Требования к содержанию и оформлению

ГОСТ 19.505 Единая система программной документации. Руководство оператора. Требования к содержанию и оформлению

ГОСТ 19.508 Единая система программной документации. Руководство по техническому обслуживанию. Требования к содержанию и оформлению

Полный список гораздо шире, но остальные документы используются очень редко.

Важно: необходимо проверять применяемые ГОСТы на актуальность на сайте Росстандарта и использовать последнюю редакцию, поскольку эти документы хоть и редко, но всё же обновляются.

ГОСТ 34 и ГОСТ 19: что регламентируют и в чём разница?

Рассмотрим, как эти 2 серии стандартов дают определение основному выходному продукту процесса разработки, и в чём их отличие:

Определения из ГОСТ 19 (ЕСПД)

ГОСТ 19 — это комплекс стандартов на программы и программную документацию.

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

Программное обеспечение (ПО) — совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.

Определение из ГОСТ 34 (ИТ)

ГОСТ 34 — это комплекс стандартов на автоматизированные системы. По ГОСТ 34 автоматизированная система (АС) — система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

Автоматизированная система — это комплекс организационных технических, программных и других элементов. Каждый такой элемент выполняет свои задачи, обеспечивая полноценную работу автоматизированной системы. Таким образом они являются обеспечением АС.

ГОСТ 34 выделяет следующие виды обеспечения АС:

организационное;

методическое;

техническое;

математическое;

программное обеспечение;

информационное;

лингвистическое;

правовое;

эргономическое.

Получается, что АС не тождественна своему программному обеспечению, а лишь содержит его среди прочих видов обеспечения.

В отличие от программного обеспечения, АС не может быть создана в отрыве от конкретной организации/пользователя, растиражирована или продана любому, кто пожелает её приобрести.

АС представляет собой техническое и организационное решение, которое автоматизирует деятельность людей на конкретном предприятии. В свою очередь программное обеспечение может быть создано без привязки к конкретному предприятию и тиражироваться на большое количество пользователей.

Например, на предприятии используется тиражируемое Программное обеспечение для ведения бухгалтерского учёта. Совокупность этого Программного обеспечения, его специфических настроек для этого конкретного предприятия, оборудования, на котором оно установлено, специалистов, которые с ним работают, регламентов и инструкций, на основании которых они выполняют свою работу — всё это вместе взятое является Автоматизированной системой.

Перечень документов, которые разрабатываются на разных стадиях создания АС, приведён в ГОСТ 34.201 «Виды, комплектность и обозначение документов при создании автоматизированных систем». В нём содержатся следующие требования:

на стадии «Техническое задание» разрабатывают ТЗ на создание АС по ГОСТ 34.602 «Техническое задание на создание автоматизированной системы»;

виды программных документов, разрабатываемых на различных стадиях создания АС, определяются по ГОСТ 19.101 «Единая система программной документации. Виды программ и программных документов».

Обратите внимание, что ГОСТ 34.201 одновременно ссылается и на ГОСТ 34.602 и на ГОСТ 19.101. Таким образом, указанные серии ГОСТов не противоречат друг другу, а скорее дополняют.

ГОСТ 34 описывает систему в целом, а ГОСТ 19 описывает её программное обеспечение.

Определите, что относится к ГОСТ 34, а что — к ГОСТ 19.

ГОСТ 19

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

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

Определяет виды программных документов, разрабатываемых на разных стадиях создания АС

Определяет виды программных документов, разрабатываемых на разных стадиях создания АС

ГОСТ 34

Комплекс государственных стандартов, которые устанавливают правила в области разработки автоматизированных систем

Комплекс государственных стандартов, которые устанавливают правила в области разработки автоматизированных систем

Используется для разработки технического задания

Используется для разработки технического задания

Проверить
Правильных ответов: 4, неправильных ответов: 0.
Ответить повторно

Рабочая документация

Все стандарты (и ГОСТ 34, и ГОСТ 19) делят все документы по двум осям:

предметная область (документы описывают определённые части системы);

время (документы разрабатываются на определённых стадиях создания системы).

ГОСТ 19.102 определяет следующие стадии разработки программ и программной документации:

техническое задание;

эскизный проект;

технический проект;

рабочий проект;

внедрение.

Основной объём документации создаётся на стадии Рабочий проект и называется рабочей документацией.

Рабочая документация (РД) — документы, предназначенные для успешного развертывания, ввода в действие и дальнейшей эксплуатации новой системы. Эти документы содержат конкретные сведения о системе и описывают физически существующие сущности, то есть реальную систему.

В состав рабочей документации могут входить следующие документы:

Описание программы;
Общие сведения о функциональном назначении и логической структуре программы.

Пояснительная записка;
Общее описание программы и технико-экономическое обоснование выбранных технических решений. Формируется на основе фактической реализации системы.

Описание применения;
Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств.

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

Руководство системного программиста;
Сведения для обеспечения функционирования и настройки программы (инструкция
по развертыванию, описание действий по настройке программы и др.)

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

Однако, ключевые документы, которые появляются в результате разработки рабочей документации это:

Руководство пользователя (оператора);

Программа и методика испытаний.

Полное описание перечня документов можно найти в ГОСТ 19.101.

Даня

Ох, столько документов придётся подготовить! 😞

Айгуль

Не волнуйся — не все документы на системном аналитике.

Системный аналитик и документация

Системный аналитик, как правило, занимается подготовкой двух документов: Руководство пользователя и Программа и методика испытаний.

Руководство пользователя

Руководство пользователя описывает порядок действий пользователя в системе для получения того или иного результата. Чем подробнее и понятнее написано руководство пользователя, тем проще вам будет сопровождать систему, поэтому важно дополнять текст иллюстрациями и примерами интерфейсов. Также часто используются короткие видеоинструкции на различные варианты использования системы. Подробнее о формате предоставления информации пользователям поговорим в следующих уроках спринта.

Программа и методика испытаний

Программа и методика испытаний (ПМИ) предназначена для формализации процесса приёмо-сдаточных испытаний (ПСИ), в ходе которого могут выявляться и устраняться недостатки в функциях системы и в разработанной документации.

Минимально ПМИ содержит следующие разделы:

объект испытаний;

цель испытаний;

требования к программе;

требования к программной документации;

средства и порядок испытаний;

методика испытаний.

ПМИ — это связка исходных требований Технического задания и конкретной реализации этих требований в разработанной системе. В ПМИ должны быть описаны чёткие алгоритмы проверки соответствия системы исходным требованиям. Эти шаги описывают в разделе «Методика испытаний».

Шаблон документа «Программа и методики испытаний» выглядит следующим образом:

Объект испытаний: Указывается наименование, область применения и обозначение испытуемой программы.

Цель испытаний: Должна быть указана цель проведения испытаний. Например, «Комплексная проверка соответствия выполненных Исполнителем работ предъявляемым к ним требованиям».

Требования к программе: Должны быть указаны требования, подлежащие проверке во время испытаний и заданные в Техническом задании.

Требования к документации: Должен быть указан состав документации, предъявляемой на испытания.

Средства и порядок испытаний: Должны быть указаны технические и программные средства, используемые во время испытаний, а также порядок проведения испытаний.

Методы испытаний: Приводятся описания проверок с указанием источника требования (пункт Технического задания и ожидаемого результата):

Требование технического задания

Предусловия

Шаг проверки

Конечный результат

Текст требования из технического задания или ссылка на пункт технического задания

Какие условия должны быть соблюдены для выполнения указанного требования

Последовательность шагов, которые приведут к конечному результату проверки

Итоговый результат, который позволит убедиться в прохождении проверки и выполнении требования ТЗ в полном объёме

Основой для наполнения таблицы с методами испытаний в ПМИ может послужить План тестирования, который мы разбирали в предыдущем спринте.

Рекомендации по оформлению ПМИ:

Описывать шаги проверки нужно подробно, с указанием конкретных тестовых данных (например, под каким пользователем нужно выполнить авторизацию, какой документ открыть и т. д.).

Количество шагов проверки не должно быть слишком большим (оптимальный вариант 7 +/- 2), чтобы процесс проверки был прозрачен и понятен всем участникам. Если шагов больше, то лучше разделить требование на несколько более мелких.

Если к шагу проверки необходимо приложить скриншоты, выгрузки отчётов или другие объёмные пояснения, то можно сформировать приложения к ПМИ и сослаться в тексте документа на них.

Перед вами фрагменты тест-кейсов с шагами проверки и результатами. Ваша задача определить, какое требование проверяет данный тест-кейс.

Идентификация, аутентификация и авторизация пользователя

Шаги проверки и результаты данного тест-кейса содержат слова авторизация, учётная запись и пр. Они указывают на то, что проверяется функция входа пользователя в систему, что соответствует требованиям к идентификации, аутентификации и авторизации пользователей.

Просмотр журнала действий пользователя

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

Оформление заказа с доставкой в ПВЗ в интернет-магазине

Шаги проверки и результат соответствуют функции оформления заказа с выбором способа доставки «ПВЗ».

Формирование и выгрузка отчёта

Несмотря на специфические шаги проверки, общий контекст говорит о том, что проверяется формирование и выгрузка отчёта — в данном случае оборотно-сальдовой ведомости.

Начать заново

Даня

Зачем вообще нужны эти стандарты? Я пока вижу только минусы 🙃

Айгуль

Плюсы тоже есть!

Какие?

Плюсы и минусы применения стандартов

Основной минус — стандарты очень громоздки, сложны для восприятия и редко актуализируются. В них заложено устаревшее представление об архитектуре автоматизированной системы.

Но есть и важные положительные моменты:

стандарты создавались большой группой грамотных специалистов (целыми НИИ), учитывают специфику и общие части различных проектов и предметных областей, годами проходили «обкатку» и у них есть чёткая цель — максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая информационная система. Мы можем забыть включить в состав нашей документации элементарные вещи, тогда как ГОСТ «помнит» обо всём;

стандарты позволяют заказчику и исполнителю говорить на одном языке и дают гарантию, что, по крайней мере, претензий «по форме» к передаваемой документации у заказчика не будет.

Варианты применения стандартов

В России действует федеральный закон «О техническом регулировании» от 27.12.2002 N 184-ФЗ, в соответствии с которым соблюдение стандартов (за исключением некоторых) — дело добровольное. Соблюдение определенного стандарта становится обязательным для заказчика и исполнителя, если они включают это условие в договор. На практике существуют следующие варианты применения стандартов:

Точное следование стандарту. Сложно представить, что кто-то будет придерживаться этого варианта добровольно. Полный комплект документов готовится по требованию заказчика, закреплённому техническим заданием и договором. Например, этот вариант применения стандартов обязателен в оборонной промышленности. В таком случае необходимо передать заказчику жёстко регламентированные по содержанию и оформлению документы. В ГОСТах приведён не только исчерпывающий перечень выходных документов и их структурных элементов, но и чёткие требования к визуальному оформлению, в частности, к формату листов, размеру колонтитулов, шрифтам, наличию рамки, правилам оформления таблиц и иллюстраций, нумерации страниц и т.д.

Гибкое следование стандарту. В больших компаниях любят стандарты, потому что они помогают людям лучше понимать друг друга. Если ваш заказчик ценит порядок и стандартизацию, постарайтесь придерживаться идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ.

Полное отсутствие требований по стандартизации. Подобный взгляд на документацию можно встретить у небольших заказчиков. С одной стороны вы можете сэкономить время и силы на подготовке документации, но с другой стороны рискуете потратить ещё больше времени на уточнения и разъяснения в ходе внедрения и сопровождения системы. Поэтому лучше все-таки фиксировать хотя бы основные положения в документации. Это облегчит вам жизнь на этапах сдачи-приёмки и эксплуатации вашего продукта.

В этом уроке вы познакомились с перечнем ключевых документов, входящих в ГОСТы. Сопоставьте название документа/группы документов и их назначение.

Перечень упорядоченных во времени, взаимосвязанных, объединённых в стадии и этапы работ

Стадии создания

Перечень стадий создания АС и перечень работ на каждой стадии фиксируется в документе «Стадии создания».

Основной документ, определяющий требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и её приёмка

Техническое задание на создание автоматизированной системы

Требования к разрабатываемой системе фиксируются в Техническом задании

Схема алгоритма, общее описание алгоритма и/или функционирования программы, а также обоснование принятых технических и технико-экономических решений

Пояснительная записка

Общие принципы работы программы и их обоснование раскрываются в Пояснительной записке

Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля

Программа и методика испытаний.

Порядок проведения испытаний фиксируется в документе, который называется Программа и методика испытаний или ПМИ

Сведения для применения тестовых и диагностических программ при обслуживании технических средств

Руководство по техническому обслуживанию.

Сведения, необходимые для повседневной работы с программой и её обслуживания приводятся в Руководствах

Начать заново

Выберите из списка именно те документы, которые входят в состав Рабочей документации.

Правильный ответ

Руководство пользователя (оператора)

Руководство пользователя один из ключевых документов в составе рабочей документации. Он описывает порядок действий пользователя в системе.

Техническое задание

Этот документ создаётся на стадии проектирования системы, он описывает желаемую функциональность, а не реально работающую систему.

Виды программ и программных документов

Это один из общих документов, описывающих область действия стандарта.

Правильный ответ

Программа и методика испытаний

ПМИ — ключевой документ в составе рабочей документации. В нём описывается порядок проверки соответствия готовой системы исходным требованиям.

Правильный ответ

Пояснительная записка

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

Неправильный ответ

Стадии разработки

Этот документ входит в состав программной документации, но не относится к рабочей документации

Тоже правильный ответ

Руководство системного программиста

Руководства системного программиста и другие виды руководств входят в состав рабочей документации.

Подведём итоги

Для написания документации на программные продукты в соответствии с требованиями российских компаний используются две серии ГОСТов:

серия ГОСТ 19 Единая система программной документации;

серия ГОСТ 34 Информационные технологии.

ГОСТ 34 описывает систему в целом, а ГОСТ 19 описывает её программное обеспечение.

ГОСТы иногда обновляются. Актуальный текст стандартов можно найти на сайте Росстандарта.

Рабочая документация — это документы, предназначенные для успешного развёртывания, ввода в действие и дальнейшей эксплуатации системы.

В состав рабочей документации входит:

программа и методика испытаний;

руководство пользователя (оператора);

описание программы;

пояснительная записка;

руководство программиста;

руководство системного программиста;

руководство по техническому обслуживанию;

описание применения.

Структура документации по ГОСТ полная и непротиворечивая, а следование стандартам снимает многие проектные риски, о существовании которых мы можем поначалу не догадываться.

ГОСТ носит рекомендательный характер. Конкретный набор документов, который готовится в ходе реализации и внедрения системы, зависит от договорённостей с Заказчиком. Обсуждать и фиксировать этот набор необходимо на старте проекта.

Документирование является важной и ответственной работой. Здесь важна аккуратность, как и при написании хороших требований и хорошего кода.

Программа и методика испытаний предназначена для проверки соответствия исходных требований Технического задания и реализованного функционала. Для каждого требования должны быть описаны шаги проверки и конечный результат.

Ведение документации позволяет предотвратить многие недоразумения и злоупотребления. Без документации вероятность и болезненность всевозможных разбирательств сильно повышается.

К следующей теме

Курсы

Вводный модуль

Понимание профессии системного аналитика

Разработка требований

Проект 1. Спецификация требований ко второму релизу Chatty

SQL для аналитиков

Моделирование данных

Проект 2. Моделирование данных и работа с базой данных интернет-магазина «Накарабине»

Моделирование процессов

Пользовательские интерфейсы

Agile-практики

Проект 3. Бэклог приложения для сети клиник «Вита»

Трудоустройство

Архитектура системы

Программные интерфейсы

Проект 4

Реализация системы

Поддержка, обслуживание и оценка результатов

Дипломный проект

Дополнительные материалы

x

Draggable item. Ensure your screen reader is not in browse mode and then press space bar to lift.