Код курса.
У каждого курса есть свой уникальный код. Зная этот код вы можете быстро найти курс в форме поиска.
Выберите городМосква
Москва
Алматы
Екатеринбург
Тюмень
Новосибирск
Сочи
Москва
Москва
Алматы
Екатеринбург
Тюмень
Новосибирск
Сочи
Документирование автоматизированных систем по ГОСТ 34: от требований до приемки. Практический курс
Вендор
Тематика
Тип курса
Авторский
Длительность
24 ак. часов
Ближайшая дата
10 авг 2026
Стоимость
52 870 RUB
Описание
Курс " Документирование автоматизированных систем по ГОСТ 34: от требований до приемки. Практический курс" - это новый практический курс, который построен вокруг сквозного практического кейса. Это может быть система управления складом, заявками, документооборотом, техническим обслуживанием, закупками или производственным учетом. Курс предназначен для специалистов, участвующих в создании, внедрении, документировании и приемке автоматизированных систем.
Во время обучения, слушатели работают со сквозным кейсом и создают учебный комплект документов, который можно использовать как основу для реальных проектов. Теория дается ровно в том объеме, который нужен, чтобы документы были не ритуальными, а рабочими.
Баланс теории и практики: 35% теория / 65% практика
Курс разработан на основе актуальных стандартов, применяемых в России при создании, документировании и сопровождении автоматизированных систем. Основу программы составляет комплекс ГОСТ 34, который используется при разработке заказных АС, подготовке технических заданий, проектной, эксплуатационной и приемочной документации.
В программе учитываются следующие ключевые стандарты:
· ГОСТ Р 59853-2021 - термины и определения в области автоматизированных систем;
· ГОСТ Р 59793-2021 - стадии создания автоматизированных систем;
· ГОСТ 34.201-2020 - виды, комплектность и обозначение документов при создании АС;
· ГОСТ 34.602-2020 - требования к техническому заданию на создание АС;
· ГОСТ Р 59795-2021 - требования к содержанию документов при создании АС;
· ГОСТ 7.32-2017 - структура и оформление отчетов о НИР;
· ГОСТ Р 2.105-2019 - общие требования к текстовым документам;
· ГОСТ Р ИСО/МЭК 15910-2002 - процесс создания пользовательской документации программных средств.
Дополнительно курс опирается на практический опыт реализации проектов по созданию и внедрению информационных систем, а также на профессиональные публикации, статьи и монографии. Основной акцент сделан не на формальном цитировании стандартов, а на их практическом применении: как подготовить понятное ТЗ, определить состав документации, организовать согласование документов и избежать ситуации, когда проектная документация есть, но пользоваться ею страшнее, чем самой системой.
· ГОСТ Р 59793-2021 - стадии создания автоматизированных систем;
· ГОСТ 34.201-2020 - виды, комплектность и обозначение документов при создании АС;
· ГОСТ 34.602-2020 - требования к техническому заданию на создание АС;
· ГОСТ Р 59795-2021 - требования к содержанию документов при создании АС;
· ГОСТ 7.32-2017 - структура и оформление отчетов о НИР;
· ГОСТ Р 2.105-2019 - общие требования к текстовым документам;
· ГОСТ Р ИСО/МЭК 15910-2002 - процесс создания пользовательской документации программных средств.
Дополнительно курс опирается на практический опыт реализации проектов по созданию и внедрению информационных систем, а также на профессиональные публикации, статьи и монографии. Основной акцент сделан не на формальном цитировании стандартов, а на их практическом применении: как подготовить понятное ТЗ, определить состав документации, организовать согласование документов и избежать ситуации, когда проектная документация есть, но пользоваться ею страшнее, чем самой системой.
За 3 дня слушатели проходят полный практический цикл: определяют состав автоматизированной системы, формируют профиль стандартов, разрабатывают структуру технического задания, пишут проверяемые требования, определяют комплект документации, связывают требования с приемочными испытаниями и организуют управление документированием в проекте.
Важно! В дистанционном формате курс проводится только с включенными камерами.
Документы по итогам обучения
Программа курса разработана в соответствии с профессиональным стандартом. По окончании курса выдается удостоверение о повышении квалификации (при наличии среднего профессионального или высшего образования и предоставлении других необходимых для оформления документов). При отсутствии необходимого уровня образования либо документов об образовании выдается сертификат о прохождении обучения УЦ Микротест.
Уровень сложности курса
Базовый
Кому полезен курс
• руководителям ИТ-проектов;
• системным и бизнес-аналитикам;
• техническим писателям;
• архитекторам решений;
• специалистам по внедрению информационных систем;
• представителям заказчика, участвующим в согласовании ТЗ;
• специалистам службы эксплуатации;
• сотрудникам проектных офисов;
• специалистам, которые отвечают за приемку АС.
• системным и бизнес-аналитикам;
• техническим писателям;
• архитекторам решений;
• специалистам по внедрению информационных систем;
• представителям заказчика, участвующим в согласовании ТЗ;
• специалистам службы эксплуатации;
• сотрудникам проектных офисов;
• специалистам, которые отвечают за приемку АС.
Необходимая подготовка
· Базовое понимание жизненного цикла разработки и внедрения информационных систем, роли требований и проектной документации.
· Опыт участия в ИТ-проектах желателен, но не обязателен. Знание ГОСТ 34 не требуется — разберем подробно на курсе.
· Опыт участия в ИТ-проектах желателен, но не обязателен. Знание ГОСТ 34 не требуется — разберем подробно на курсе.
Учебно-методические материалы
Электронные учебные пособия на русском языке
Ваш результат обучения
После курса слушатели смогут:
1. Понимать, что такое автоматизированная система с точки зрения ГОСТ 34.
2. Формировать профиль стандартов для конкретного проекта.
3. Определять разумный комплект технической документации.
4. Разрабатывать структуру ТЗ по ГОСТ 34.602-2020.
5. Формулировать проверяемые требования к АС.
6. Связывать требования с приемочными испытаниями.
7. Планировать разработку документации.
8. Организовывать рецензирование и согласование документов.
9. Готовить пустографки документов.
10. Собирать учебный комплект документации для проекта создания АС.
Программа курса
День 1. Автоматизированная система, стандарты и требования
Лозунг дня - "Сначала понимаем, что создаем. Потом пишем документы. Не наоборот."
Модуль 1. Автоматизированная система с точки зрения ГОСТ
Формат: короткая теория + разбор кейса + мини-практика
Содержание
1. Что такое автоматизированная система.
2. Почему АС - это не только программное обеспечение.
3. Компоненты АС: персонал; программные средства; технические средства; данные; организационное обеспечение; методическое обеспечение; информационное обеспечение; интеграции; эксплуатационная среда.
4. Границы АС и внешняя среда.
5. Типовые ошибки:
"АС = программа";
"документация будет потом";
"пользователи сами разберутся";
"интеграции - это техническая мелочь".
Практика 1. "Разобрать АС на компоненты" используя описание автоматизированной системы. Карта состава АС.
Модуль 2. Актуальные стандарты и профиль стандартов проекта
Формат: теория + практическая таблица
Содержание
1. Зачем нужны стандарты при создании АС.
2. Добровольность и обязательность применения стандартов.
3. Когда стандарт становится обязательным: указан в договоре; указан в ТЗ; закреплен внутренним регламентом; требуется заказчиком; используется как основа приемки.
4. Актуальная нормативная база:
· ГОСТ Р 59853-2021 - термины и определения;
· ГОСТ Р 59793-2021 - стадии создания АС;
· ГОСТ 34.201-2020 - виды, комплектность и обозначение документов;
· ГОСТ 34.602-2020 - ТЗ на создание АС;
· ГОСТ Р 59795-2021 - требования к содержанию документов;
· ГОСТ 7.32-2017 - отчет о НИР;
· ГОСТ Р 2.105-2019 - текстовые документы;
· ГОСТ Р ИСО/МЭК 15910-2002 - пользовательская документация.
5. Как заменить устаревшие ссылки в старых программах и шаблонах.
6. Профиль стандартов проекта: что включать и зачем.
ГОСТ Р 2.105-2019 действует как стандарт по общим требованиям к текстовым документам, а ГОСТ 7.32-2017 - как актуальная основа для структуры и оформления отчетов о НИР.
Практика 2. "Сформировать профиль стандартов учебного проекта"
Модуль 3. Требования к АС: от пожеланий к проверяемым формулировкам
Формат: практика с короткими теоретическими вставками
Содержание
1. Требования как основа ТЗ.
2. Разница между: бизнес-потребностью; проблемой; целью; функциональным требованием; нефункциональным требованием; ограничением; проектным решением.
3. Признаки хорошего требования: однозначность; проверяемость; выполнимость; непротиворечивость; трассируемость.
4. Типовые плохие требования:
· "система должна быть удобной";
· "интерфейс должен быть современным";
· "интеграция должна быть нормальной";
· "отчеты должны формироваться быстро".
5. Как превращать "хотелки" в требования.
Практика 3. "Нормализация требований" используя список слабых формулировок. Набор проверяемых требований для будущего ТЗ.
Модуль 4. Структура ТЗ по ГОСТ 34.602-2020
Формат: разбор структуры + мини-практика
Содержание
1. Роль ТЗ в проекте создания АС.
2. Структура ТЗ по ГОСТ 34.602-2020.
3. Разделы ТЗ:
· общие сведения; цели и назначение создания АС; характеристика объектов автоматизации; требования к АС; состав и содержание работ; порядок разработки АС; порядок контроля и приемки; подготовка объекта автоматизации; требования к документированию; источники разработки.
4. Как не превратить ТЗ в энциклопедию всего проекта.
5. Что обязательно должно быть в хорошем ТЗ.
ГОСТ 34.602-2020 содержит обязательные разделы ТЗ на АС, включая раздел "Порядок разработки АС", который часто выпадает из старых шаблонов.
Практика 4. Подготовить структуру ТЗ для учебного кейса и определить, что будет в каждом разделе. Карта АС, профиль стандартов, набор проверяемых требований и структура ТЗ.
День 2. Техническое задание и комплект документации
Лозунг дня "Хорошее ТЗ - это документ, после которого заказчик, исполнитель и приемочная комиссия понимают одно и то же."
Модуль 5. Разработка учебного ТЗ на АС
Формат: интенсивная практическая работа
Содержание
1. Как заполнять раздел "Общие сведения".
2. Как формулировать цели и назначение АС.
3. Как описывать объект автоматизации.
4. Как структурировать требования: требования к системе в целом; требования к функциям; требования к видам обеспечения; требования к интеграциям; требования к надежности; требования к ИБ; требования к эксплуатации; требования к документированию.
5. Как связать требования с критериями приемки.
6. Идентификаторы требований.
7. Матрица трассировки требований.
Практика 5. "Написать фрагмент ТЗ" Разработать 4 ключевых раздела ТЗ, используя необходимый формат:
1. Цели и назначение создания АС.
2. Характеристика объекта автоматизации.
3. Требования к функциям.
4. Требования к интеграции / ИБ / надежности.
Результат: рабочий фрагмент ТЗ на 4–6 страниц.
Модуль 6. Состав комплекта технической документации на АС
Формат: разбор + групповая практика
Содержание
1. Техническая документация как инструмент, а не ритуал.
2. Мотивы включения документа в комплект: в интересах заказчика; в интересах исполнителя; для приемки; для эксплуатации; для сопровождения; для защиты от "мы думали, это тоже входит".
3. Документы на АС в целом.
4. Документы на подсистемы.
5. Документы на программные компоненты.
6. Документы на оборудование.
7. Документы на покупные и создаваемые компоненты.
8. Документы по стадиям создания АС.
ГОСТ 34.201-2020 устанавливает требования к видам, наименованию, комплектности и обозначению документов, разрабатываемых на стадиях создания АС.
Практика 6. "Сформировать обоснованный комплект документации для проекта"
Модуль 7. Документы по стадиям создания АС
Формат: короткая теория + карта
Содержание
1. Стадии создания АС.
2. Предпроектное обследование.
3. Концепция АС.
4. Техническое задание.
5. Эскизный проект.
6. Технический проект.
7. Рабочая документация.
8. Испытания.
9. Ввод в действие.
10. Эксплуатационная документация.
ГОСТ Р 59793-2021 устанавливает стадии и этапы создания АС, а ГОСТ Р 59795-2021 - требования к содержанию основных документов, разрабатываемых при создании АС.
Практика 7. "Карта стадий и документов"
Модуль 8. Программа и методика испытаний: как проверить требования
Формат: практика
Содержание
1. ПМИ как мост между ТЗ и приемкой.
2. Как из требований получить тестовые сценарии.
3. Что должно быть в приемочном сценарии: предусловие; шаги; ожидаемый результат; критерий успешности; подтверждающий документ.
4. Типовые ошибки ПМИ: проверяется не требование, а "ощущение"; нет ожидаемого результата; нет данных для проверки; сценарий невозможно повторить.
Практика 8. "Сделать приемочные сценарии", фрагмент ТЗ, комплект документации, карта стадий и документов, первые приемочные сценарии.
День 3. Управление документированием, рецензирование и финальная защита
Лозунг дня "Документ считается готовым не тогда, когда его написали, а когда он согласован, проверен, полезен и не вызывает желания открыть Excel 'для надежности'."
Модуль 9. Организация документирования в проекте
Формат: теория + RACI-практика
Содержание
1. Документирование как поток работ проекта.
2. Роли в документировании: руководитель проекта; аналитик; технический писатель; архитектор; разработчик; тестировщик; эксплуатация; ИБ; заказчик; ключевые пользователи.
3. Группа технической документации: функции; состав; взаимодействие с проектной командой.
4. Руководитель группы технической документации.
5. Ответственность за содержание и форму.
6. Отражение документирования в уставе проекта.
7. Типовая ошибка: "документы пишет тот, кто свободен".
Практика 9. "RACI по документации" Матрица ответственности по документации.
Модуль 10. Требования к документированию в ТЗ
Формат: практическое написание раздела
Содержание
1. Зачем в ТЗ нужен раздел "Требования к документированию".
2. Минимальный состав требований: перечень документов; стандарты; форматы; шаблоны; правила версионирования; порядок согласования; требования к пользовательской документации; требования к эксплуатационной документации; порядок актуализации.
3. Как избежать неопределенных формулировок при описании состава и объема проектной документации.
4.
Практика 10. "Написать раздел ТЗ" - Требования к документированию, для учебного проекта.
Модуль 11. Технология разработки документов
Формат: практика на шаблонах
Содержание
1. Стадии создания документа: требования к документу; пустографка; сбор исходных данных; первая версия; внутренняя проверка; рецензирование; правки; финальная версия.
2. Пустографка документа.
3. Как писать первую версию.
4. Как работать с замечаниями.
5. Таблица замечаний.
6. Статусы документа.
7. Финальная проверка.
Практика 11. "Создать пустографку документа" Варианты документов:
• руководство пользователя;
• описание системы;
• описание интеграций;
• ПМИ;
• руководство администратора.
Модуль 12. Планирование сроков и риски документирования
Формат: деловая мини-практика
Содержание
1. Два подхода к планированию сроков: от требований; от графика.
2. Что реально влияет на сроки: объем документа; доступность экспертов; качество исходных данных; количество согласующих; число циклов рецензирования; изменения требований.
3. Почему "там же только оформить" - тревожный сигнал, а не оценка трудозатрат.
4. Типовые риски: документацию начали поздно; нет владельца содержания; рецензенты спорят друг с другом; требования меняются, документы устаревают; пользовательские инструкции пишутся после запуска.
Практика 12. "План разработки документации и реестр рисков.
Модуль 13. Финальная командная симуляция
Формат: командная работа + защита
Задача Команды собирают мини-комплект документации по учебной АС.
Итоговый комплект:
1. Карта состава АС.
2. Профиль стандартов проекта.
3. Структура ТЗ.
4. Фрагмент ТЗ с проверяемыми требованиями.
5. Раздел "Требования к документированию".
6. Комплект технической документации.
7. Карта стадий и документов.
8. Матрица трассировки требований.
9. Приемочные сценарии.
10. RACI по документации.
11. План разработки документации.
12. Реестр рисков документирования.
Защита
Каждая команда отвечает на вопросы:
• Почему выбран именно такой комплект документов?
• Какие требования являются критичными?
• Как требования будут проверяться?
• Какие документы нужны заказчику?
• Какие документы нужны исполнителю?
• Какие документы нужны эксплуатации?
• Какие риски документирования наиболее опасны?
• Что произойдет, если документацию начать писать после разработки?
• Какие последствия возникают при недостаточной проработке проектной документации?
Лозунг дня - "Сначала понимаем, что создаем. Потом пишем документы. Не наоборот."
Модуль 1. Автоматизированная система с точки зрения ГОСТ
Формат: короткая теория + разбор кейса + мини-практика
Содержание
1. Что такое автоматизированная система.
2. Почему АС - это не только программное обеспечение.
3. Компоненты АС: персонал; программные средства; технические средства; данные; организационное обеспечение; методическое обеспечение; информационное обеспечение; интеграции; эксплуатационная среда.
4. Границы АС и внешняя среда.
5. Типовые ошибки:
"АС = программа";
"документация будет потом";
"пользователи сами разберутся";
"интеграции - это техническая мелочь".
Практика 1. "Разобрать АС на компоненты" используя описание автоматизированной системы. Карта состава АС.
Модуль 2. Актуальные стандарты и профиль стандартов проекта
Формат: теория + практическая таблица
Содержание
1. Зачем нужны стандарты при создании АС.
2. Добровольность и обязательность применения стандартов.
3. Когда стандарт становится обязательным: указан в договоре; указан в ТЗ; закреплен внутренним регламентом; требуется заказчиком; используется как основа приемки.
4. Актуальная нормативная база:
· ГОСТ Р 59853-2021 - термины и определения;
· ГОСТ Р 59793-2021 - стадии создания АС;
· ГОСТ 34.201-2020 - виды, комплектность и обозначение документов;
· ГОСТ 34.602-2020 - ТЗ на создание АС;
· ГОСТ Р 59795-2021 - требования к содержанию документов;
· ГОСТ 7.32-2017 - отчет о НИР;
· ГОСТ Р 2.105-2019 - текстовые документы;
· ГОСТ Р ИСО/МЭК 15910-2002 - пользовательская документация.
5. Как заменить устаревшие ссылки в старых программах и шаблонах.
6. Профиль стандартов проекта: что включать и зачем.
ГОСТ Р 2.105-2019 действует как стандарт по общим требованиям к текстовым документам, а ГОСТ 7.32-2017 - как актуальная основа для структуры и оформления отчетов о НИР.
Практика 2. "Сформировать профиль стандартов учебного проекта"
Модуль 3. Требования к АС: от пожеланий к проверяемым формулировкам
Формат: практика с короткими теоретическими вставками
Содержание
1. Требования как основа ТЗ.
2. Разница между: бизнес-потребностью; проблемой; целью; функциональным требованием; нефункциональным требованием; ограничением; проектным решением.
3. Признаки хорошего требования: однозначность; проверяемость; выполнимость; непротиворечивость; трассируемость.
4. Типовые плохие требования:
· "система должна быть удобной";
· "интерфейс должен быть современным";
· "интеграция должна быть нормальной";
· "отчеты должны формироваться быстро".
5. Как превращать "хотелки" в требования.
Практика 3. "Нормализация требований" используя список слабых формулировок. Набор проверяемых требований для будущего ТЗ.
Модуль 4. Структура ТЗ по ГОСТ 34.602-2020
Формат: разбор структуры + мини-практика
Содержание
1. Роль ТЗ в проекте создания АС.
2. Структура ТЗ по ГОСТ 34.602-2020.
3. Разделы ТЗ:
· общие сведения; цели и назначение создания АС; характеристика объектов автоматизации; требования к АС; состав и содержание работ; порядок разработки АС; порядок контроля и приемки; подготовка объекта автоматизации; требования к документированию; источники разработки.
4. Как не превратить ТЗ в энциклопедию всего проекта.
5. Что обязательно должно быть в хорошем ТЗ.
ГОСТ 34.602-2020 содержит обязательные разделы ТЗ на АС, включая раздел "Порядок разработки АС", который часто выпадает из старых шаблонов.
Практика 4. Подготовить структуру ТЗ для учебного кейса и определить, что будет в каждом разделе. Карта АС, профиль стандартов, набор проверяемых требований и структура ТЗ.
День 2. Техническое задание и комплект документации
Лозунг дня "Хорошее ТЗ - это документ, после которого заказчик, исполнитель и приемочная комиссия понимают одно и то же."
Модуль 5. Разработка учебного ТЗ на АС
Формат: интенсивная практическая работа
Содержание
1. Как заполнять раздел "Общие сведения".
2. Как формулировать цели и назначение АС.
3. Как описывать объект автоматизации.
4. Как структурировать требования: требования к системе в целом; требования к функциям; требования к видам обеспечения; требования к интеграциям; требования к надежности; требования к ИБ; требования к эксплуатации; требования к документированию.
5. Как связать требования с критериями приемки.
6. Идентификаторы требований.
7. Матрица трассировки требований.
Практика 5. "Написать фрагмент ТЗ" Разработать 4 ключевых раздела ТЗ, используя необходимый формат:
1. Цели и назначение создания АС.
2. Характеристика объекта автоматизации.
3. Требования к функциям.
4. Требования к интеграции / ИБ / надежности.
Результат: рабочий фрагмент ТЗ на 4–6 страниц.
Модуль 6. Состав комплекта технической документации на АС
Формат: разбор + групповая практика
Содержание
1. Техническая документация как инструмент, а не ритуал.
2. Мотивы включения документа в комплект: в интересах заказчика; в интересах исполнителя; для приемки; для эксплуатации; для сопровождения; для защиты от "мы думали, это тоже входит".
3. Документы на АС в целом.
4. Документы на подсистемы.
5. Документы на программные компоненты.
6. Документы на оборудование.
7. Документы на покупные и создаваемые компоненты.
8. Документы по стадиям создания АС.
ГОСТ 34.201-2020 устанавливает требования к видам, наименованию, комплектности и обозначению документов, разрабатываемых на стадиях создания АС.
Практика 6. "Сформировать обоснованный комплект документации для проекта"
Модуль 7. Документы по стадиям создания АС
Формат: короткая теория + карта
Содержание
1. Стадии создания АС.
2. Предпроектное обследование.
3. Концепция АС.
4. Техническое задание.
5. Эскизный проект.
6. Технический проект.
7. Рабочая документация.
8. Испытания.
9. Ввод в действие.
10. Эксплуатационная документация.
ГОСТ Р 59793-2021 устанавливает стадии и этапы создания АС, а ГОСТ Р 59795-2021 - требования к содержанию основных документов, разрабатываемых при создании АС.
Практика 7. "Карта стадий и документов"
Модуль 8. Программа и методика испытаний: как проверить требования
Формат: практика
Содержание
1. ПМИ как мост между ТЗ и приемкой.
2. Как из требований получить тестовые сценарии.
3. Что должно быть в приемочном сценарии: предусловие; шаги; ожидаемый результат; критерий успешности; подтверждающий документ.
4. Типовые ошибки ПМИ: проверяется не требование, а "ощущение"; нет ожидаемого результата; нет данных для проверки; сценарий невозможно повторить.
Практика 8. "Сделать приемочные сценарии", фрагмент ТЗ, комплект документации, карта стадий и документов, первые приемочные сценарии.
День 3. Управление документированием, рецензирование и финальная защита
Лозунг дня "Документ считается готовым не тогда, когда его написали, а когда он согласован, проверен, полезен и не вызывает желания открыть Excel 'для надежности'."
Модуль 9. Организация документирования в проекте
Формат: теория + RACI-практика
Содержание
1. Документирование как поток работ проекта.
2. Роли в документировании: руководитель проекта; аналитик; технический писатель; архитектор; разработчик; тестировщик; эксплуатация; ИБ; заказчик; ключевые пользователи.
3. Группа технической документации: функции; состав; взаимодействие с проектной командой.
4. Руководитель группы технической документации.
5. Ответственность за содержание и форму.
6. Отражение документирования в уставе проекта.
7. Типовая ошибка: "документы пишет тот, кто свободен".
Практика 9. "RACI по документации" Матрица ответственности по документации.
Модуль 10. Требования к документированию в ТЗ
Формат: практическое написание раздела
Содержание
1. Зачем в ТЗ нужен раздел "Требования к документированию".
2. Минимальный состав требований: перечень документов; стандарты; форматы; шаблоны; правила версионирования; порядок согласования; требования к пользовательской документации; требования к эксплуатационной документации; порядок актуализации.
3. Как избежать неопределенных формулировок при описании состава и объема проектной документации.
4.
Практика 10. "Написать раздел ТЗ" - Требования к документированию, для учебного проекта.
Модуль 11. Технология разработки документов
Формат: практика на шаблонах
Содержание
1. Стадии создания документа: требования к документу; пустографка; сбор исходных данных; первая версия; внутренняя проверка; рецензирование; правки; финальная версия.
2. Пустографка документа.
3. Как писать первую версию.
4. Как работать с замечаниями.
5. Таблица замечаний.
6. Статусы документа.
7. Финальная проверка.
Практика 11. "Создать пустографку документа" Варианты документов:
• руководство пользователя;
• описание системы;
• описание интеграций;
• ПМИ;
• руководство администратора.
Модуль 12. Планирование сроков и риски документирования
Формат: деловая мини-практика
Содержание
1. Два подхода к планированию сроков: от требований; от графика.
2. Что реально влияет на сроки: объем документа; доступность экспертов; качество исходных данных; количество согласующих; число циклов рецензирования; изменения требований.
3. Почему "там же только оформить" - тревожный сигнал, а не оценка трудозатрат.
4. Типовые риски: документацию начали поздно; нет владельца содержания; рецензенты спорят друг с другом; требования меняются, документы устаревают; пользовательские инструкции пишутся после запуска.
Практика 12. "План разработки документации и реестр рисков.
Модуль 13. Финальная командная симуляция
Формат: командная работа + защита
Задача Команды собирают мини-комплект документации по учебной АС.
Итоговый комплект:
1. Карта состава АС.
2. Профиль стандартов проекта.
3. Структура ТЗ.
4. Фрагмент ТЗ с проверяемыми требованиями.
5. Раздел "Требования к документированию".
6. Комплект технической документации.
7. Карта стадий и документов.
8. Матрица трассировки требований.
9. Приемочные сценарии.
10. RACI по документации.
11. План разработки документации.
12. Реестр рисков документирования.
Защита
Каждая команда отвечает на вопросы:
• Почему выбран именно такой комплект документов?
• Какие требования являются критичными?
• Как требования будут проверяться?
• Какие документы нужны заказчику?
• Какие документы нужны исполнителю?
• Какие документы нужны эксплуатации?
• Какие риски документирования наиболее опасны?
• Что произойдет, если документацию начать писать после разработки?
• Какие последствия возникают при недостаточной проработке проектной документации?
! Данный курс может быть заказан согласно 44-ФЗ, 223-ФЗ (закупка, аукцион, запрос котировок, конкурсные процедуры)
Доступные формы обучения
Описание фомата
Очная форма – это классическая форма обучения. Студенты посещают занятия в специально оборудованном классе на территории учебного центра в соответствии с установленным расписанием.
Занятие длится 8 академических часов в день, стандартное время начала обучения – 10:00.
Преимущество очного обучения – это личный контакт с тренером-преподавателем и с остальными студентами курса. Во время обучения студенты сдают лабораторные работы вендоров, к которым предоставляется доступ, а также лабораторные работы, специально разработанные тренерами-преподавателями. Обучающиеся выполняют практические занятия, получая доступ к оборудованию или при помощи его эмуляции.
Описание фомата
Дистанционное (онлайн) обучение проводится с применением Системы Дистанционного обучения УЦ Микротест - системы Mirapolis. По форме и содержанию дистанционное обучение полностью совпадает с аналогичными очными курсами.
Занятие длится 8 академических часов в день, стандартное время проведения обучения с 10:00 до 17.00.
Обучение проходит в реальном времени с преподавателем. В процессе обучения вы сможете задавать вопросы – в чате или голосом во время занятия. В зависимости от программы курса, каждому студенту предоставляется доступ к стенду с лабораторными работами. Для закрепления материала курса вам будут доступны записи прошедших вебинаров в вашем личном кабинете в ЛК Mirapolis.
Данный формат обучения позволяет существенно сократить командировочные издержки.
Расписание курса
FAQ
Онлайн обучение реализуется в Системе Дистанционного Обучения УЦ Микротест — Mirapolis и проходит в реальном времени с преподавателем. За несколько дней до начала обучения вы получаете необходимые ссылки для подключения к курсу и доступ к Личному кабинету.
Более подробно вы можете ознакомиться с информацией на странице дистанционного обучения.
Если у вас остались вопросы, то обратитесь к нам любым удобным для вас способом (тел. +7(495) 231-23-51 или training@training-microtest.ru), и мы ответим на все ваши вопросы.
Очное обучение проходит на территории Учебного центра Микротест по адресу: 127083, г. Москва, ул. Мишина, дом 35
За несколько дней до начала обучения участник получает приглашение, в котором указан адрес места проведения и другая полезная информация для обучения.
Если вы не получили приглашение — обратитесь к нам любым удобным для вас способом (тел. +7(495) 231-23-51 или training@training-microtest.ru), и мы ответим на ваши вопросы и продублируем приглашение на вашу почту.
- Обучение проходит в реальном времени с преподавателем, вы можете задавать свои вопросы и разбирать интересные кейсы сразу в процессе обучения.
- Вашу учебную группу будет сопровождать координатор, которому можно задавать организационные вопросы.
- Если вы по каким-то причинам пропустили онлайн-занятие, то все записи будут доступны 24/7 в вашем личном кабинете в Системе Дистанционного Обучения. Также вы можете их использовать для закрепления материала.
- Дополнительно для вашего удобства мы создаем чат в Telegram вашей группы, где вы сможете задавать вопросы преподавателю, координатору и обмениваться опытом с коллегами по обучению.
По итогу прохождения обучения слушатели получают либо Сертификат Учебного центра о прохождении курса, либо Удостоверение о повышении квалификации, зарегистрированное в ФРДО (Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении).
Помимо этого, по факту прохождения авторизованных курсов вендоров Eltex, PostgresPro, Astra Linux, QTECH, АЭРОДИСК и др. выдается электронный сертификат вендора.
В основном корпусе в Москве по адресу ул. Мишина, дом 35. Рядом муниципальная платная парковка на всех прилегающих улицах.
По поводу остальных филиалов и корпусов — уточняйте информацию у наших менеджеров. Мы постараемся сделать всё возможное для вашего комфортного обучения.
Да, во время занятий для слушателей всегда доступны чай, кофе, печенье и другие снеки на кофе-брейках.
Наш центр работает с корпоративными и частными клиентами. Для каждой категории клиентов мы разработали различные варианты сотрудничества, позволяющие гибко подходить к ценообразованию и вариантам оплаты.
Обо всех специальных условиях читайте в разделе Спецпредложения или обратитесь к нам любым удобным для вас способом (тел. +7(495) 231-23-51 или training@training-microtest.ru)
Также подпишитесь на новости нашего учебного центра, где вы первыми узнаете про интересные предложения от нас.
Не нашли подходящиего курса?
Оставьте заявку на обучение для вашей организации
Почему выбирают обучение у нас
Техническая
экспертиза
экспертиза
Эксперты в обучении:
- Сети передачи данных и связь
- ОС Linux и платформы виртуализации
- Центры обработки данных и СХД
Опытные преподаватели с мультивендорной экспертизой
Расширенный лабораторный полигон для практики
Подготовка ИТ-специалистов по государственным профессиональным стандартам
Образовательный девелопер
Проектирование и реализация мультивендорных образовательных решений, программ «под ключ»
Разработка и реализация технологических решений для оценки компетенций: тесты, лабораторные полигоны и стенды
Большой опыт создания технологических партнерств с ИТ-вендорами, дистрибьюторами и крупными интеграторами
Пул экспертов в управлении образовательными проектами + разработчики, методологи, педагогические дизайнеры
Подпишитесь и будьте в курсе
Информация о новинках, скидках и акциях. Уже более 36 000 подписчиков!
Оставить заявку
Оставить заявку