ТРЕБОВАНИЯ К ПРИЛОЖЕНИЯМ: ПОЛНОЕ РУКОВОДСТВО
Приложения учебных работ — дополнительная часть, содержащая вспомогательные материалы: первичные данные, иллюстрации, диаграммы, многостраничные документы, таблицы и расчёты.
1. НАЗНАЧЕНИЕ ПРИЛОЖЕНИЙ
Приложения должны содержать вспомогательные материалы, которые:
Приложения учебных работ — это дополнительная часть учебной работы, которая содержит вспомогательные материалы: первичные данные, иллюстрации, диаграммы, планы, многостраничные документы, большие таблицы и расчёты.
Приложения содержат данные и графики, подтверждающие выводы основной части работы.
Приложения служат эмпирической базой исследования, содержащей исходные данные и результаты вычислительных экспериментов. Наличие этих материалов позволяет верифицировать выводы, представленные в основной части работы, и подтверждает корректность проведённого анализа.
Примеры:
Скриншоты работы алгоритмов, таблицы с результатами замеров производительности (бенчмарки), графики сравнения временной сложности, дампы выходных данных.
Нормативное подтверждение:
ГОСТ 7.32-2017 (п. 5.12) рекомендует включать в приложения материалы, дополняющие текст работы, в том числе промежуточные математические доказательства и таблицы вспомогательных цифровых данных.
Большие объёмы данных, исходный код или сложные алгоритмы выносятся в приложения.
В целях соблюдения требований к объёму основной части и улучшения читаемости текста, листинги программного кода, объёмные таблицы идентификаторов, структуры баз данных и длинные логи выносятся в приложения. Это позволяет не перегружать основную часть техническими деталями.
Примеры:
Исходный код модулей (Java, Python, C#), SQL-скрипты создания базы данных, файлы конфигураций, XML/JSON схемы данных.
Нормативное подтверждение:
Согласно ГОСТ 2.105-95 (ЕСКД, п. 4.3.3), допускается выполнять документ с приложениями, оформляя их на последующих листах, что актуально для размещения листингов программ.
Приложения помогают визуализировать теоретические материалы из основной части.
Визуальные материалы (схемы, диаграммы), поясняющие сложные теоретические концепции, алгоритмы или архитектуру системы, выносятся в приложения для детального рассмотрения. Это помогает глубже понять методологию исследования, не отвлекаясь от текста главы.
Примеры:
Блок-схемы алгоритмов (в соответствии с ГОСТ 19.701-90), диаграммы классов UML, графы переходов состояний, ER-диаграммы базы данных.
Нормативное подтверждение:
ГОСТ 19.701-90 (ЕСПД) устанавливает правила выполнения схем алгоритмов и программ, которые могут быть приведены в приложении как иллюстративный материал.
Данные, графики и таблицы подтверждают выводы дипломной или курсовой работы.
Приложения содержат необработанные (первичные) и обработанные данные, полученные в ходе экспериментальной части работы. Графический и табличный материал наглядно демонстрирует достижение поставленных целей и подтверждает научную или практическую значимость разработки.
Примеры:
Сравнительные диаграммы, скриншоты интерфейса с результатами выполнения запросов, отчёты генерации тестовых данных.
Нормативное подтверждение:
Соответствует ГОСТ 7.32-2017 (п. 5.6), где указано, что выводы должны быть краткими и подтверждаться данными, приведёнными в работе (включая данные приложений).
Дополнительные данные, важные для понимания темы, но не вошедшие в основной текст.
Включает справочную информацию, расшифровку терминов или данные, имеющие косвенное отношение к основной теме, но необходимые для всестороннего рассмотрения предметной области. Это позволяет заинтересованному читателю получить исчерпывающую информацию без нарушения логики основного повествования.
Примеры:
Глоссарий предметной области, описание API сторонних сервисов, техническое задание (ТЗ) на разработку, руководство пользователя.
Нормативное подтверждение:
Опирается на принципы оформления технической документации, где дополнительные сведения выносятся в отдельные разделы (приложения) для обеспечения наглядности.
Работа с приложениями развивает навыки проектирования, разработки и тестирования.
Структурирование материалов в приложениях (оформление спецификаций, написание пояснительных записок к коду, создание документации) моделирует реальные задачи разработчика программного обеспечения. Это способствует формированию навыков проектирования, документирования и тестирования.
Примеры:
Тест-кейсы, документ «Описание программы» по ГОСТ 19.402-78, руководство системного программиста.
Нормативное подтверждение:
Соответствует требованиям образовательных стандартов (ФГОС) к практической подготовке, где работа с технической документацией является обязательным навыком выпускника.
Документация и описание процессов на различных этапах разработки проекта.
Приложения содержат материалы, отражающие эволюцию проекта: от технического задания до внедрения. Это позволяет проследить логику принятия проектных решений и оценить глубину проработки темы студентом.
Примеры:
Техническое задание (ТЗ), календарный план, отчёты о предпроектном обследовании, схемы декомпозиции работ (WBS).
Нормативное подтверждение:
Ссылка на ГОСТ 19.201-78 (ТЗ. Требования к содержанию и оформлению) и ГОСТ 34.601-90 (стадии создания автоматизированной системы).
Отчёты о тестировании, метрики и выводы для оценки качества ПО.
В приложениях приводятся протоколы тестирования, подтверждающие работоспособность, надёжность и эффективность разработанного программного обеспечения. Эти документы служат объективным доказательством качества готового продукта.
Примеры:
Таблицы с тест-кейсами, отчёты о покрытии кода тестами (JaCoCo, pytest-cov), результаты нагрузочного тестирования, журналы ошибок (bug reports).
Нормативное подтверждение:
Ориентация на международные стандарты качества ПО (ISO/IEC 25000) и ГОСТ Р 56920-2016/ISO/IEC 25051:2014 по тестированию.
Умения студента в разработке ПО, использовании технологий и инструментов.
Представленный в приложениях код, конфигурации и архитектурные схемы служат прямым доказательством уровня владения студентом современными языками программирования, фреймворками и инструментами разработки.
Примеры:
Реализация сложных алгоритмов, примеры интеграции со сторонними API, Dockerfile и docker-compose файлы, скриншоты работы в IDE.
Нормативное подтверждение:
Подтверждается паспортом специальности или профилем образовательной программы, требующим демонстрации результатов инженерно-технической деятельности.
Приложения структурируют информацию и делают её более доступной.
Разгрузка основного текста от второстепенных, но необходимых элементов и структурирование их в приложениях позволяет читателю сконцентрироваться на ключевых идеях работы. При этом сохраняется логическая полнота исследования.
Примеры:
Аннотированный листинг кода, алфавитный указатель, расшифровки аббревиатур.
Нормативное подтверждение:
Общее правило оформления научных работ (ГОСТ 7.32-2017), направленное на улучшение восприятия материала.
Наличие приложений облегчает процесс проверки и оценки работы преподавателями.
Систематизированные приложения позволяют преподавателю или рецензенту оперативно найти и проверить ключевые артефакты разработки, а также убедиться в самостоятельности выполнения работы и корректности использованных решений.
Примеры:
Распечатки ключевых участков кода с комментариями, скриншоты интерфейса с подписями, отчёты антиплагиата.
Нормативное подтверждение:
Опирается на локальные акты вузов (Положения о ВКР), регламентирующие процедуру защиты и проверки работ.
Документация этапов разработки и тестирования для понимания процесса.
Приложения аккумулируют полный цикл документирования проекта, что является необходимым условием промышленной разработки ПО. Фиксация этапов проектирования, разработки и тестирования обеспечивает возможность дальнейшего сопровождения и модернизации системы.
Примеры:
Журнал версий (changelog), описание программного интерфейса (API), инструкция по развёртыванию (Deployment Guide).
Нормативное подтверждение:
Соответствует требованиям Единой системы программной документации (ЕСПД), в частности ГОСТ 19.402-78 и ГОСТ 19.502-78.
2. ОБЩИЕ ТРЕБОВАНИЯ
Правила оформления приложений к учебным работам:
Общие требования — распространяются на все виды приложений: нумерация, расположение, ссылки в тексте, оформление титульных надписей и нумерации страниц.
Все приложения должны быть оформлены в едином стиле.
Все приложения должны быть оформлены в едином стиле: одинаковые шрифты, размеры полей, отступы, оформление заголовков и подписей.
Непрерывная нумерация страниц или приложений.
Приложения нумеруются последовательно прописными буквами русского алфавита, начиная с «А», за исключением букв Ё, З, Й, О, Ч, Ь, Ы, Ъ. Сквозная нумерация по всему документу.
Приложение Б
…
Приложение К и т.д.
Требования к заголовкам приложений.
Заголовки приложений оформляются в верхнем регистре, жирным шрифтом, выравнивание по центру. Точка в конце заголовка не ставится.
Шрифт Times New Roman, 12–14 пт.
Основной текст приложений набирается тем же шрифтом, что и основной текст работы (Times New Roman), размером 12–14 пт.
Поля страницы и межстрочные интервалы.
Стандартные поля: левое — 3 см, правое — 1 см, верхнее и нижнее — 2 см. В тексте каждый абзац начинается с отступа 1,25 см.
Оформление таблиц в приложениях.
Таблицы нумеруются в пределах приложения (например, «Таблица А.3»). Над таблицей — номер и название, под таблицей — источник (обязательно).
Таблица | Модель | Производитель | Характеристики | Цена
MacBook Pro 16″ | Apple | M2 Pro/32GB/1TB SSD | 274 990 ₽
…
Источник: составлено автором по данным Росстата
Подписи, нумерация рисунков и диаграмм.
Рисунки (графики, диаграммы, схемы) нумеруются аналогично таблицам. Подпись размещается под рисунком по центру.
Источник: составлено автором
Как ссылаться на приложения в основном тексте.
В основном тексте работы делаются ссылки на приложения с указанием их номеров.
Математические формулы в приложениях.
Формулы нумеруются в пределах приложения арабскими цифрами, номер указывается справа в круглых скобках.
где E — энергия, m — масса, c — скорость света
Вставка диаграмм, схем, изображений.
Все иллюстративные материалы, диаграммы вставляются в приложение как объекты (с возможностью редактирования).
Проверка на плагиат, уникальность.
Приложения должны содержать оригинальные материалы, созданные автором, или иметь соответствующие ссылки на источники.
Продолжение нумерации со основной части.
Нумерация страниц многостраничных приложений — ГОСТ Р 2.105-2019. Страницы приложений нумеруются в пределах каждого приложения.
Рекомендуемый объём приложений.
Объём приложений не ограничивается, но должен быть обоснованным. Рекомендуется 30–50% от объёма работы.
Расчёты, формулы, математические выкладки.
Объёмные расчёты выносятся в приложения с указанием всех исходных данных и формул.
Разрешение, формат, чёткость изображений.
Все графические материалы должны быть чёткими, читаемыми, с разрешением не менее 300 dpi.
Оформление листингов кода.
Код должен быть хорошо читаемым, с комментариями. Моноширинный шрифт (Courier New, Consolas), нумерация строк.
function calculateProfit(revenue, costs) {
return revenue - costs; // Чистая прибыль
}
Копии документов, сканы.
Копии официальных документов должны быть чёткими, с видимыми печатями и подписями.
Форматы файлов, размеры.
Электронная версия: отдельная папка «Приложения», форматы .pdf (документы), .zip (код), .sql (БД), README-файл с описанием структуры.
Печатная версия: скриншоты — разрешение ≥ 300 dpi; диаграммы — чёткие подписи; код — не более 5 страниц на 1 приложение.
3. ТРЕБОВАНИЯ К МНОГОСТРАНИЧНЫМ ПРИЛОЖЕНИЯМ
Особенности оформления приложений, занимающих несколько страниц:
Многостраничные приложения — каждое приложение на отдельном листе, нумерация продолжает основной текст, в содержании указываются все приложения с номерами страниц.
4. ПРИМЕРЫ ПРИЛОЖЕНИЙ
Ниже представлены примеры приложений с описаниями, иллюстрациями и шаблонами документов для скачивания.
ПРИЛОЖЕНИЕ А – ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Написание в текстовом редакторе. Сохраняется в формате: docx
Практическая работа: 5-7 страниц
Курсовая работа: 10-12 страниц
Дипломная работа: 10-15 страниц
• Титульный лист
• Содержание
• Список сокращений
• Общие сведения
• Назначение и цели
• Характеристика объектов
• Требования к сайту
• Требования к видам обеспечения
• Этапы разработки
• Порядок контроля
• Документация
• Источники разработки
ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы"
IEEE 830 "Рекомендуемая практика для спецификации требований к программному обеспечению"
ПРИЛОЖЕНИЕ Б – ПЛАН-ГРАФИК (ДИАГРАММА ГАНТА)
Написание в текстовом редакторе. Сохраняется в формате: .xml, .mpp
Рекомендуемый объём: 1-2 страницы
ISO 21500
Microsoft Project/Excel-шаблоны
- Определение целей и структуры проекта
- Цели проекта
- Основные этапы (анализ, проектирование, разработка, тестирование, внедрение)
- Критерии успеха
- Декомпозиция работ (WBS)
- Анализ требований
- Проектирование
- Разработка
- Тестирование
- Внедрение
- Оценка длительности задач
- Оптимистичный, пессимистичный, наиболее вероятный срок
- Экспертная оценка, аналогии, PERT
- Определение зависимостей
- Финиш-Старт (FS)
- Старт-Старт (SS)
- Финиш-Финиш (FF)
- Назначение ресурсов
- Ответственные за задачи
- Инструменты и технологии
- Построение диаграммы
- Excel, MS Project, Jira, GanttPRO
- Таблица с задачами, сроками
- Временная шкала
- Контроль и корректировка
- Мониторинг прогресса
- Управление рисками
Диаграмма Ганта — инструмент визуализации этапов проекта, сроков, ресурсов и зависимостей. Создание в Microsoft Project или Excel.
ПРИЛОЖЕНИЕ В – ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ РАЗРАБОТКИ ИС
Написание в текстовом редакторе. Сохраняется в формате: docx
Практическая: 1-3 стр.
Курсовая: 3-5 стр.
Дипломная: 5-7 стр.
• Введение и общие положения
• Содержание и границы проекта (Scope)
• Иерархическая структура работ (ИСР/WBS)
• Расписание и вехи
• Бюджет и ресурсы
• План управления рисками
• План управления изменениями
• План коммуникаций
• Управление качеством
• Конфигурационное управление
ISO 21500
PMBOK
ГОСТ Р 54869-2011
ЧТО ТАКОЕ ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ (ПУП)?
Это главный координирующий документ проекта. Он описывает, как проект будет выполняться, мониториться, контролироваться и закрываться. ПУП объединяет все вспомогательные планы (по срокам, рискам, коммуникациям и т.д.) и задает «правила игры» для команды и заказчика.
СТРУКТУРА И ТРЕБОВАНИЯ К ПЛАНУ УПРАВЛЕНИЯ ПРОЕКТОМ
1. Введение и общие положения
- Цель документа: Зафиксировать, для чего создается этот план и на какой проект он распространяется.
- Краткое описание проекта: 2–3 абзаца о том, какая ИС создается (например, «CRM-система для отдела продаж»).
- Бизнес-цели: Чего хочет добиться бизнес от внедрения ИС (рост продаж, снижение времени обработки заявок).
- Допущения и ограничения: Допущения: например, «Серверное оборудование будет предоставлено заказчиком к 1 числу». Ограничения: фиксированный бюджет, жесткий дедлайн, необходимость использования конкретного стека технологий.
2. Содержание и границы проекта (Scope)
- Что входит (In Scope): Полный перечень функций и модулей ИС (ТЗ или ссылка на него).
- Что НЕ входит (Out of Scope): Важный пункт для избегания споров. Например: «Интеграция с SAP не входит в объем проекта», «Разработка мобильного приложения не входит».
- Критерии приемки: Условия, при которых заказчик подпишет акт сдачи-приемки (например, успешное прохождение тест-кейсов).
3. Иерархическая структура работ (ИСР / WBS)
Требование: Декомпозиция работ до уровня пакетов, которые можно оценить по срокам и стоимости.
Пример: Проект → Этап «Бэкенд» → Задача «Разработка API авторизации» → Подзадача «Написание кода контроллера».
4. Расписание и вехи (Schedule & Milestones)
- Методология планирования: Диаграмма Ганта или гибкое планирование (Scrum с горизонтом на спринт).
- Ключевые вехи: Старт проекта; Завершение проектирования (утверждение ТЗ); Готовность прототипа; Начало тестирования; Передача в опытно-промышленную эксплуатацию; Финал (Project Closed).
- Требование: У каждой вехи должна быть четкая дата и критерий ее достижения.
5. Бюджет и ресурсы
- Бюджет: Общая стоимость, резервы на непредвиденные расходы (Management Reserve).
- Команда: Роли (Project Manager, Analyst, Developer, QA) и занятость (в часах или процентах).
- Материальные ресурсы: Требования к серверам, ПО, лицензиям.
6. План управления рисками
Реестр рисков: Таблица с колонками: Риск → Вероятность → Влияние → Важность (произведение) → План А (Митигация) → План Б (Реагирование).
Пример: «Риск: Уход ключевого разработчика. Митигация: Кросс-функциональность и документирование кода».
7. План управления изменениями (Change Management)
- Процедура: Как подается запрос на изменение (CR), кто его утверждает (Change Control Board), как пересматриваются сроки и бюджет.
- Требование: Описать, что считается незначительным изменением (делает PM) и что значительным (требует санкции заказчика).
8. План управления коммуникациями
Кому, что, когда и как сообщаем.
Пример: Заказчик: отчет раз в неделю по e-mail (статус, вехи, риски). Команда: Daily Stand-up (15 мин утром). Стейкхолдеры: демо в конце каждого спринта.
9. Управление качеством (QA)
- Стандарты: Какие стандарты кода используются? (PEP8, Checkstyle и т.д.)
- Метрики качества: Плотность багов, покрытие кода тестами (>80%), время отклика системы (<200 мс).
- Виды тестирования: Юнит-тесты, интеграционное, нагрузочное, UAT (приемочное тестирование пользователями).
10. Конфигурационное управление
- Хранение кода: Git (ветки, политика мержей).
- Хранение документации: Confluence, Wiki или папка на Sharepoint.
РЕКОМЕНДАЦИИ ПО РАЗРАБОТКЕ ПЛАНА
- Адаптируйте методологию под проект. Если требования «плывут» или продукт инновационный — используйте гибридный подход. Планируйте этап проектирования жестко, а разработку — итеративно (Scrum). В ПУП это нужно отразить.
- Детализируйте ровно настолько, насколько нужно. Плохо: расписывать каждую кнопку в интерфейсе на год вперед (все равно изменится). Хорошо: планировать первый квартал помесячно, а следующие кварталы — покрупному (вехи), уточняя планы ближе к делу (принцип «накатывающейся волны»).
- Согласуйте с командой, а не спустите сверху. Оценки сроков должны давать разработчики и аналитики, а не менеджер. Если план составил PM без участия команды, команда не будет за него «болеть». Проведите сессию планирования (Planning Poker).
- Создайте отдельный «Глоссарий». В проектах ИС много аббревиатур (API, БД, UI/UX, CMS). Вынесите их значения в приложение к плану, чтобы заказчик и новички в команде говорили с вами на одном языке.
- Бюджетируйте время на «технический долг» и баги. Опытные команды закладывают в план 20% времени на рефакторинг и исправление ошибок, иначе к концу проекта скорость разработки упадет до нуля.
- Используйте инструменты визуализации. Не храните План управления проектом только в Word. Интегрируйте его с системами: Jira / Redmine (для задач и багов), MS Project / GanttPRO (для календарного графика), Miro (для карт рисков и Mind Maps).
- Живой документ. План управления проектом должен регулярно пересматриваться (например, раз в месяц или на ретроспективе спринта). Устаревший план вреднее, чем его отсутствие.
- Особое внимание — «критериям готовности» (DoD). Четко пропишите в плане (или в приложении), что значит «Задача сделана»: написан код; проведено код-ревью; написаны тесты; обновлена документация API; задеплоено на стенд. Это спасет от ситуации, когда разработчик говорит «готово», а система падает при первом же нажатии кнопки.
План разработки проекта
СкачатьПРИЛОЖЕНИЕ Г – ДИАГРАММА AS-IS И ДЕКОМПОЗИЦИЯ
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
BPMN 2.0
IDEF0
UML
Отражение процессов:
Отражение всех ключевых процессов
Входы/выходы:
Чёткое обозначение входов/выходов
Участники:
Указание участников процессов
Задача (Task): Прямоугольник с закруглёнными углами
Событие (Event): Круг — начало/конец процесса
Шлюз (Gateway): Ромб — точки принятия решений
Поток (Sequence Flow): Стрелка — последовательность действий
Дорожки (Swimlanes): Разделение по ролям/отделам
AS-IS («как есть») — модель текущего состояния бизнес-процессов организации перед внедрением ИС.
ПРИЛОЖЕНИЕ Д – ДИАГРАММА TO-BE И ДЕКОМПОЗИЦИЯ
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
BPMN 2.0 (основная)
IDEF0 (если меняется функциональная структура)
Устранение недостатков:
Должна устранять недостатки AS-IS
Автоматизация:
Включает автоматизированные шаги
Реалистичность:
Должна быть реалистичной
TO-BE («Как будет») — модель будущего состояния процесса после оптимизации.
ПРИЛОЖЕНИЕ Е – ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (ПРЕЦЕДЕНТОВ)
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
Понятность:
Должна быть понятной для заказчика
Элементы:
Включает акторов и use case
Актор: Стилизованный человечек
Use Case: Овал с названием функции
Связь: Линия между актором и вариантом использования
- Определение цели и области системы
- Определите информационную систему
- Определите основные функции
- Сбор требований
- Соберите функциональные требования
- Определите действия пользователей
- Выявление акторов
- Определите, кто будет взаимодействовать с системой
- Определение вариантов использования
- Для каждого актора определите функции
- Создание диаграммы
- Используйте UML-редакторы
- Расположите акторов и use case
- Проверка и доработка
- Проверьте полноту диаграммы
Показывает взаимодействие пользователей с системой.
ПРИЛОЖЕНИЕ Ж – КОНЦЕПТУАЛЬНАЯ СХЕМА
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
Древовидная диаграмма
Блок-схема
Структура навигации:
Должна отражать структуру навигации
Элементы:
Включает главную страницу и разделы
Иерархия страниц и структура навигации.
ПРИЛОЖЕНИЕ З – ДИАГРАММА ФОРМ (ПРОВОЛОЧНАЯ)
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
Элементы нотации проволочной диаграммы
Диалоговые окна
| Форма диалога | Прямоугольное окно с заголовком «Заголовок диалогового окна» и областью контента. |
| Форма приложения | Основное окно приложения с заголовком и маркерами изменения размера. |
| Выход из... | Облако — процесс, внешняя система или граница в потоковых диаграммах. |
| Кнопки диалогов | Восстановить, Закрыть, Свернуть, Развернуть — стандартные кнопки управления окном. |
| Предупреждение | Восклицательный знак в круге — предупреждающее сообщение. |
| Флажок | Квадрат с галочкой — выбранное состояние (checkbox). |
| Кнопка | Прямоугольник с текстом — кнопка действия. |
| Поле ввода | Прямоугольник с плейсхолдером «Ввод текста» — поле для ввода. |
| Раскрывающееся меню | Прямоугольник с пунктами меню под ним. |
| Раскрывающееся список | Поле с стрелкой вниз — выпадающий список (combobox). |
| Элемент списка | Прямоугольник с текстом — пункт списка. |
| Переключатель | Круг с заливкой — радио-кнопка или переключатель (on/off). |
| Ползунок | Горизонтальная линия с треугольным ползунком — регулятор значения. |
Значки управления
Стандартные иконки: Назад, Вперёд, Добавить, Удалить, Фильтр, Настройки, Календарь, Документ, База данных, Пользователи, Справка, Печать, Отмена, Повтор, Редактировать, Вырезать, Папка, Сохранить, Копирование документов.
Визуал:
Черно-белая или в оттенках серого
Элементы:
Включает основные блоки интерфейса
Прямоугольники: Области контента (изображения, текстовые блоки)
Линии: Навигация и связи между элементами
Кнопки: Прямоугольники с закруглёнными углами
Текстовые поля: Прямоугольники с надписью
Стрелки: Направление навигации или действия
- Определение цели и задач
- Определите, что достичь
- Сформулируйте функции и элементы
- Сбор требований
- Исследование потребностей пользователей
- Сбор информации о функциональности
- Создание структуры
- Определите разделы и элементы
- Разработайте схему навигации
- Рисование диаграммы
- Используйте простые формы
- Разместите элементы по логике
- Добавление деталей
- Текстовые метки, кнопки
- Убедитесь в полноте функций
Схематичное представление интерфейса без дизайна.
ПРИЛОЖЕНИЕ И – ДИАГРАММА ДЕЯТЕЛЬНОСТИ
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
Элементы нотации диаграммы деятельности
ActionState1 Имя действия | Действие или деятельность — овал с закруглёнными углами, внутри указывается имя действия. |
| Начальное состояние — закрашенный чёрный круг, точка входа в процесс. | |
| Конечное состояние — закрашенный круг внутри контура круга (символ «мишень»), точка выхода. | |
| Параллельное разделение — толстая горизонтальная черта, один поток разветвляется на несколько параллельных. | |
| Поток управления — сплошная стрелка, направление последовательности действий. | |
| Поток объектов — пунктирная стрелка, передача объектов между действиями. | |
| Решение — ромб, точка ветвления по условию (один вход, несколько выходов). | |
| Параллельное соединение — толстая горизонтальная черта, слияние параллельных потоков в один. | |
Отдел продаж Имя дорожки | Плавательная дорожка — вертикальный прямоугольник, зона ответственности участника (роль, подразделение). |
◻◻◻◻◻ Входной набор → Выходной набор ◻◻◻◻◻ | Область расширения — прямоугольник с пунктирной границей. Квадратики ◻ обозначают элементы коллекции (входного и выходного наборов); действие выполняется для каждого такого элемента. |
Последовательность:
Отображает последовательность действий
Условия:
Включает условия и параллельные процессы
Начальное состояние: Чёрный круг
Действие: Прямоугольник с закруглёнными углами
Конечное состояние: Двойной круг
Плавательная дорожка: Прямоугольник с пояснением
Параллельное разделение: Сведение стрелок к линии
Решение: Ромб с входами и выходами
Визуализация алгоритмов и workflow.
ПРИЛОЖЕНИЕ К – СХЕМА ДАННЫХ
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
Внешние сущности:
Отображает внешние сущности и процессы
Хранилища:
Включает хранилища данных и потоки
По Чену: Сущности, атрибуты, связи (ER-диаграмма)
Упрощённый вариант: Упрощённая нотация для модели данных
Показывает движение данных в системе.
ПРИЛОЖЕНИЕ Л – ДИАГРАММА КЛАССОВ
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
Классы:
Включает классы с атрибутами и методами
Связи:
Показывает связи между классами
Класс: Прямоугольник с тремя секциями (имя, атрибуты, методы)
Ассоциация: Сплошная линия
Агрегация: Линия с ромбом
Композиция: Линия с закрашенным ромбом
Наследование: Линия со стрелкой
ПРИЛОЖЕНИЕ М – ДИАГРАММА ОБЪЕКТОВ
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
Элементы диаграммы объектов в UML
Диаграмма объектов в UML включает следующие элементы:
Объекты
Каждый объект обозначается в виде прямоугольника, в котором имя объекта и его класс подчеркнуты и разделены двоеточием. При необходимости над именем объекта может помещаться стереотип класса в угловых кавычках, а название класса может содержать полный путь до внешнего пакета, где находится данный класс.
Атрибуты объекта
Каждому объекту присваиваются атрибуты, но, в отличие от классов, атрибутам объектов должны быть присвоены значения.
Связи
Используются для представления взаимосвязи между двумя объектами. При необходимости направление связи указывают с помощью стрелок.
Важно: объект может быть анонимным — это нужно, если в данный момент не важно, какой именно объект данного класса принимает участие во взаимодействии.
Правила построения
Некоторые рекомендации по построению диаграммы объектов в UML:
- Учесть все сущности, важные с точки зрения контекста модели. Отсутствие тех или иных элементов на диаграмме служит признаком неполноты модели и может потребовать её последующей доработки.
- Все сущности на диаграмме модели должны быть одного концептуального уровня. Это означает согласованность имён одинаковых элементов и возможность вложения отдельных диаграмм друг в друга для достижения полноты представлений.
- Вся информация о сущностях должна быть явно представлена на диаграммах. Хотя в языке UML при отсутствии некоторых символов на диаграмме могут быть использованы их значения по умолчанию, необходимо стремиться к явному указанию свойств всех элементов диаграмм.
- Диаграммы не должны содержать противоречивой информации.
Применение
Диаграмма объектов в UML используется для:
- Документирования структур данных и создания статических снимков состояний объектов, принимая во внимание реальные экземпляры или прототипы.
- Пояснения и детализации диаграмм взаимодействия — например, диаграмм последовательностей.
- Создания тестовых примеров для проверки точности и полноты диаграммы классов.
Объекты:
Показывает конкретные объекты и их состояния
Связи:
Включает связи между объектами
Объект: Прямоугольник с подчёркнутым названием objectName: ClassName
Связь объектов: Линия между объектами
Экземпляры классов в конкретный момент времени.
ПРИЛОЖЕНИЕ Н – ГРАФИК (ПЛАН) ТЕСТИРОВАНИЯ
Написание в текстовом редакторе. Сохраняется в формате: docx
• Цели и объём тестирования
• Подходы и методы
• Расписание
• Ресурсы и роли
• Критерии входа/выхода
Содержание:
Включает этапы, сроки и ответственных
Критерии:
Содержит критерии приемки
Стратегия и расписание тестирования системы.
Шаблон плана тестирования
СкачатьПРИЛОЖЕНИЕ О – ЧЕК-ЛИСТЫ ТЕСТИРОВАНИЯ
Написание в текстовом редакторе. Сохраняется в формате: .docx, .xml
• Функциональное тестирование
• Юзабилити тестирование
• Тестирование безопасности
• Кроссбраузерное тестирование
Структура:
Структурированы по модулям/функциям
Результаты:
Содержат ожидаемые результаты
Списки проверок для разных видов тестирования. Написание в Microsoft Excel, Word.
ПРИЛОЖЕНИЕ П – ИЕРАРХИЧЕСКАЯ ОРГАНИЗАЦИОННАЯ ДИАГРАММА
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
• Линейная
• Функциональная
• Матричная
• Проектная
Иерархия:
Отображает иерархию подчинения
Должности:
Включает должности и ФИО сотрудников
Структура подразделений и должностей в организации.
ПРИЛОЖЕНИЕ Р – РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
Написание в текстовом редакторе. Сохраняется в формате: docx
• Введение и назначение
• Требования к системе
• Установка и настройка
• Описание функций
• Решение проблем
ОТЛИЧИЕ ИНСТРУКЦИИ ПОЛЬЗОВАТЕЛЯ И РУКОВОДСТВА ПОЛЬЗОВАТЕЛЯ
Инструкция — это пошаговое описание действий, которое помогает пользователю быстро разобраться с задачей. Некоторые особенности инструкции:
- Содержит чёткие указания, например, «нажмите сюда» или «выберите это».
- Ориентирована на конкретную цель или проблему.
- Может быть адаптируема к реальным сценариям использования.
- Не должна объяснять понятия — объяснения здесь только встанут на пути действия. Если объяснения необходимы, на них дают ссылку.
Пример инструкции — «как откалибровать радиолокационную решётку».
Руководство пользователя — это структурированный документ, который объясняет, как пользоваться продуктом, будь то программа, сервис, устройство или комплексная система. Некоторые элементы руководства:
- Введение и обзор — краткая информация о назначении продукта и его основных функциях.
- Пошаговые инструкции — как установить программу, как начать новый проект, как выполнить ту или иную операцию (на основе картинок и текста).
- Описание интерфейса — объяснение назначения кнопок, меню и окон программы.
- Решение типичных задач — примеры использования функционала программы на практике.
- Советы и ответы на вопросы — раздел с часто задаваемыми вопросами (FAQ) или распространёнными ошибками и их решениями.
ОБЩИЕ ТРЕБОВАНИЯ К РУКОВОДСТВАМ ПОЛЬЗОВАТЕЛЯ
Общие требования к руководствам пользователя включают принципы, связанные с содержанием, оформлением и языком, а также требования к проверке готового документа.
Некоторые общие требования к содержанию руководства пользователя:
- Чёткая структура. Блоки должны идти в логичной последовательности — от первых шагов до продвинутых возможностей.
- Описание функций. Важно перевести технические возможности на язык практических действий. Например, если руководство предназначено для начинающих, необходимо предоставить более детальные пошаговые инструкции. Если аудитория — люди, которым нужны особые, нечасто используемые функции, то руководство должно иметь другую глубину изложения материала.
- Наглядные элементы. Схемы, примеры, иллюстрации или скриншоты, помогающие сразу увидеть результат действий.
- Раздел с типичными ошибками и способами их устранения. Он снижает нагрузку на поддержку.
- Поисковая навигация, перечень функций и актуальные ссылки.
- Создать содержание — оно поможет пользователю ориентироваться в тексте.
- Указать основные элементы интерфейса — например, объяснить предназначение всех окон, кнопок.
- Включить контактную информацию — это даст пользователю возможность связаться с разработчиком.
ПРИЛОЖЕНИЕ С – РИСУНКИ ПРОЕКТИРОВАНИЯ (СТАТИСТИКА)
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio, .xml) и в формате pdf
• Столбчатые и линейные
• Круговые и кольцевые
• Точечные и пузырьковые
• Гистограммы и ящик с усами
Подписи:
Чёткие подписи осей и легенда
Масштаб:
Адекватный масштаб
Источник:
Указание источника данных
Графическое представление статистических данных. Инструменты: Visio, drawio, Excel.
ПРИЛОЖЕНИЕ Т – СХЕМА РАБОЧЕГО ПРОЦЕССА
Написание в текстовом редакторе. Сохраняется в формате: в среде разработки (.vsdx, .ndb, .drawio) и в формате pdf
BPMN 2.0
IDEF0
UML Activity
Событие (Event): Круг — начальное и конечное состояние процесса (старт/финиш)
Задача (Task): Прямоугольник с закруглёнными углами — действие или операция
Шлюз (Gateway): Ромб — точка ветвления, условие или слияние потоков
Поток (Sequence Flow): Стрелка — последовательность выполнения шагов
Дорожки (Swimlanes): Горизонтальные/вертикальные полосы — разделение по ролям или подразделениям
Пул (Pool): Контейнер для участника процесса — отдельный исполнитель или система
- Определение границ процесса
- Укажите начальное событие (старт)
- Укажите конечное событие (финиш)
- Определите входы и выходы
- Выявление участников
- Определите, кто выполняет шаги
- Создайте дорожки (swimlanes) или пулы для каждого участника
- Добавление задач
- Перечислите действия в порядке выполнения
- Разместите задачи в соответствующих дорожках
- Добавление шлюзов
- Обозначьте условия и ветвления (ромбы)
- Укажите исключающее ИЛИ, параллельное ИЛИ или И
- Связывание элементов потоками
- Соедините события, задачи и шлюзы стрелками
- Проверьте логику переходов
- Проверка и доработка
- Убедитесь, что каждый поток имеет начало и конец
- Проверьте полноту и корректность процесса
Workflow, бизнес-процесс. BPMN, блок-схема. Последовательность операций.
ПРИЛОЖЕНИЕ У – ПРОВЕРКА УНИКАЛЬНОСТИ (АНТИПЛАГИАТ)
Общие требования:
Полный отчёт системы антиплагиат; с указанием процента уникальности; с выделением заимствованных фрагментов.
Форматы отчетов:
PDF с цветовой маркировкой; HTML с интерактивной проверкой; текстовый отчёт с детализацией.
Результаты проверки на заимствования.
ПРИЛОЖЕНИЕ Х – РУКОВОДСТВО ПО РАЗВЕРТЫВАНИЮ
Написание в текстовом редакторе. Сохраняется в формате: docx
10–20 страниц
• Требования к системе
• Подготовка окружения
• Установка зависимостей
• Настройка конфигурации
• Развертывание приложения
• Проверка работоспособности
• Решение типовых проблем
Последовательность работ:
Подготовка серверной инфраструктуры; установка необходимого ПО; настройка базы данных; развертывание приложения; настройка безопасности; тестирование развёрнутой системы.
# Клонирование репозитория git clone https://repository.example.com/project.git # Установка зависимостей npm install # Настройка окружения cp .env.example .env # Запуск миграций базы данных npm run migrate # Запуск приложения npm start
Инструкция по установке и развёртыванию системы. Требования к окружению, шаги установки, настройка.
Шаблон руководства по развёртыванию системы
СкачатьПРИЛОЖЕНИЕ Ц – ЛИСТИНГ КОДА
Написание в текстовом редакторе. Сохраняется в формате: docx
• Заголовок с названием программы
• Информация о языке и версии
• Основной код с комментариями
• Описание ключевых функций
Шрифт:
Моноширинный (Courier New, Consolas, Arial) — 12 pt
Интервал:
Одинарный (1,0) между строками кода
Нумерация:
Обязательная нумерация строк кода слева
Подсветка:
Синтаксическое выделение ключевых слов и конструкций
Комментарии:
На русском языке; поясняют неочевидные фрагменты; docstring для функций и классов
Заголовок:
Указание имени файла, языка программирования и версии
Форматирование:
Сохранение отступов и переносов строк как в исходнике
Объём:
Включать только ключевые фрагменты, а не весь проект
Идентификаторы:
Осмысленные имена по стилю языка (CamelCase, snake_case)
Приложение с фрагментами исходного кода для пояснения реализации. Оформляется как отдельный раздел с сохранением читаемости и структуры кода.
Листинг кода
СкачатьПРИЛОЖЕНИЕ Ч – КАРТОЧКА ПРЕДПРИЯТИЯ
Написание в текстовом редакторе. Сохраняется в формате: docx
• Общие сведения о предприятии
• Организационная структура
• Основные виды деятельности
• Технико-экономические показатели
• Контактная информация
Реквизиты:
Реквизиты организации
ОПФ:
Организационно-правовая форма
Показатели:
Основные экономические показатели
Структура:
Структура управления
Продукты:
Основные продукты/услуги
География:
География деятельности
Описание организации, где проводилось исследование или внедрялась система.
ПРИЛОЖЕНИЕ Ш – АНКЕТЫ И БРИФЫ
Написание в текстовом редакторе. Сохраняется в формате: docx
Анкета: 2-3 страницы
Бриф на разработку: 3-5 страниц
Четкая структура:
Логическое разделение на блоки (общая информация, функциональные требования, технические требования)
Простота формулировок:
Вопросы должны быть понятны респондентам без технического образования
Разнообразие типов вопросов:
Открытые, закрытые, шкальные, множественный выбор
Обязательные и дополнительные вопросы:
Выделение критически важной информации
Инструкция для респондента:
Пояснения по заполнению каждого раздела
Поля для комментариев:
Возможность уточнить или дополнить ответ
1. ОБЩАЯ ИНФОРМАЦИЯ О ПРОЕКТЕ
- Название проекта/системы
- Краткое описание бизнес-идеи
- Основные цели создания системы
- Ожидаемые результаты от внедрения
- Сроки реализации (желаемые даты начала и завершения)
2. ЦЕЛЕВАЯ АУДИТОРИЯ
- Основные группы пользователей
- Уровень технической подготовки пользователей
- Количество одновременных пользователей
- Географическое расположение пользователей
3. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
- Ключевые функции системы
- Бизнес-процессы, подлежащие автоматизации
- Интеграции с существующими системами
- Отчетность и аналитика
- Роли пользователей и права доступа
4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
- Платформа (веб, мобильное приложение, desktop)
- Технологический стек (предпочтения или ограничения)
- Требования к производительности
- Безопасность и защита данных
- Масштабируемость
5. ДИЗАЙН И ИНТЕРФЕЙС
- Корпоративный стиль (брендбук)
- Примеры понравившихся интерфейсов
- Требования к юзабилити
- Адаптивность под мобильные устройства
6. БЮДЖЕТ И РЕСУРСЫ
- Плановый бюджет проекта
- Наличие команды для сопровождения
- Техническая инфраструктура
- Сроки окупаемости
РАЗДЕЛ: ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ
Какие основные задачи должна решать система?
□ Учет клиентов и сделок
□ Управление проектами
□ Автоматизация документооборота
□ Аналитика и отчетность
□ Другое: ________________
Оцените важность следующих функций по шкале от 1 до 5:
Интуитивный интерфейс: 1 2 3 4 5
Быстрый поиск: 1 2 3 4 5
Мобильный доступ: 1 2 3 4 5
