Требования к элементам
Типовая структура пояснительной записки
- Титульный лист
- Задание на выполнение работы
- Содержание
- Список обозначений и сокращений
- Введение
- Анализ предметной области (Аналитическая часть)
- Разработка системы (Проектирование системы)
- Охрана труда при разработке (специфический раздел)
- Заключение
- Список использованных источников
- Приложения (листинги кода, скриншоты, руководство пользователя)
- Аннотация (не вшивается в пояснительную записку)
Описание каждого элемента структуры
1. Титульный лист
• Описание: Первая страница документа.
• Содержит: полное наименование учебного заведения, тему дипломной работы, сведения об авторе (ФИО, группа), сведения о руководителе (ФИО, учёная степень, должность), город и год выполнения. Оформляется строго по ГОСТу или методичке колледжа.
2. Задание на выполнение работы
• Описание: Официальный бланк, утверждённый кафедрой.
• Содержит: тему работы, исходные данные, перечень подлежащих разработке вопросов (план работы), сроки сдачи. Задание подписывается студентом, руководителем и заведующим кафедрой.
3. Содержание (Оглавление)
• Описание: автоматически собранный список всех разделов и подразделов работы с указанием номеров страниц.
4. Список обозначений и сокращений
• Описание: определения сокращений и редко употребляемых слов с расшифровкой и описанием.
5. Введение
• Описание: Вступительная часть, цель которой — показать актуальность темы и ввести читателя в курс дела.
• Содержит: Актуальность темы, цель работы, задачи работы, объект и предмет исследования, методы исследования, структуру работы и т.д.
6. Глава 1. Анализ предметной области (Аналитическая часть)
• Описание: Самая объёмная и важная часть. Нужно доказать, что вы понимаете, для чего и для кого делаете программу.
• Содержит: Обзор предметной области, анализ существующих аналогов, обоснование выбора технологии, постановка задачи (ТЗ), проектирование системы. Модели данных (ER-диаграммы): сущности, атрибуты, связи. UML-диаграммы: Use Case, Sequence, Class diagram.
7. Глава 2. Разработка системы (Проектирование системы)
• Описание: Описание того, как система будет устроена внутри до написания кода.
• Содержит: Разработка архитектуры (MVC, MVP и т.д.), описание модулей. Проектирование интерфейса: структура окон, навигация, wireframes. Описание программных модулей: алгоритмы, структуры классов. Тестирование: чек-листы, виды тестирования, анализ результатов.
8. Глава 3. Охрана труда при реализации проекта
• Описание: Специфический раздел для технических специальностей.
• Содержит: Анализ условий труда (эргономика, освещение, вентиляция, электробезопасность), меры по обеспечению безопасности, охрана труда при работе за компьютером.
9. Заключение
• Описание: Итог всей работы.
• Содержит: Выводы по проделанной работе, подтверждение достижения цели, перечисление результатов, пути дальнейшего развития.
10. Список использованных источников
• Описание: Библиографический список. Книги, статьи, веб-сайты. Оформляется по ГОСТ 7.1-2003 или ГОСТ Р 7.0.100-2018.
11. Приложения
• Описание: Дополнительные материалы.
• Содержит: Листинги кода, скриншоты, руководство пользователя, руководство программиста (если требуется).
12. Аннотация (Реферат)
• Описание: Краткое изложение сути работы. Не вшивается в пояснительную записку.
Дополнительные требования к тексту
По методическим рекомендациям к оформлению дипломной работы в тексте не допускается:
- применять обороты разговорной речи и произвольные словообразования;
- использовать разные термины для одного и того же понятия;
- заканчивать главу рисунком или таблицей;
- сокращать обозначения физических величин без цифр (кроме случаев, предусмотренных таблицами).
Допустимы общепринятые сокращения (м, кг, др., пр., см., т.д., т.п.). При первом упоминании аббревиатуры указывают полное название, затем сокращение.
Определение
Титульный лист — первая страница дипломной работы, содержащая наименование учебного заведения, информацию о допуске к защите, тип работы (ДИПЛОМНАЯ РАБОТА), специальность с кодом, тему в кавычках, данные исполнителя и руководителя. Все подписи и даты должны быть проверены.
Требования
Полное наименование колледжа; информация о допуске к защите; тип работы (ДИПЛОМНАЯ РАБОТА); специальность 09.02.07; тема в кавычках (точно соответствует заданию); данные исполнителя (ФИО, группа, подпись); данные руководителя (ФИО, учёная степень, подпись, дата); текущий год.
Пример оформления
ДЕПАРТАМЕНТ ОБРАЗОВАНИЯ И НАУКИ ГОРОДА МОСКВЫ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ «КОЛЛЕДЖ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ имени Героя Советского Союза М.Ф. Панова» Специальность 09.02.07 Информационные системы и программирование Тема: «_______________________________________________________________________»
Дополнительная информация
- Проверить полное название колледжа
- Указать точную специальность
- Проверить правильность темы
- Указать текущий год
- Проверить подписи
Определение
Содержание — структурный элемент работы, в котором перечисляются все главы, разделы и подразделы с номерами страниц. Формируется автоматически на основе стилей заголовков 1–3 уровней.
Требования
Автоматическая сборка из заголовков 1–3 уровней; указание названия раздела и номера страницы; страница с заголовком имеет нумерацию. Порядок в тексте после задания: содержание → список обозначений (при необходимости) → введение → глава 1 (1.1–1.7, 1.1.1–1.1.9) → глава 2 (2.1–2.5, 2.2.1–2.2.4) → глава 3 (3.1–3.4) → заключение → список источников → приложения.
Образец структуры содержания
Дополнительная информация
- Содержание собирается автоматически
- Заголовки — стили 1, 2, 3 уровней
- Страница с заголовком имеет нумерацию
Определение
Если в документе используют более трёх условных обозначений, требующих пояснения (включая специальные сокращения слов и словосочетаний, обозначения единиц физических величин и другие специальные символы), составляется их перечень.
В ДИПЛОМНОЙ определения, обозначения и сокращения приводятся в одном структурном элементе «ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ».
Если условных обозначений в ДИПЛОМНОЙ приведено менее трёх, отдельный перечень не составляют, а необходимые сведения указывают в тексте отчёта или в подстрочном примечании при первом упоминании.
ПЕРЕЧЕНЬ ДОЛЖЕН:
- располагаться столбцом без знаков препинания в конце строки;
- слева без абзацного отступа;
- обозначения располагаются в алфавитном порядке;
- слева приводятся сокращения, условные обозначения, символы, единицы физических величин, а справа через тире — их детальная расшифровка.
Пример оформления
Дополнительная информация
- Проверить алфавитный порядок
- Указать только используемые сокращения
- Проверить точность расшифровок
- Проверить формат (слева — справа)
Определение
Введение — составная часть пояснительной записки, содержит базовые понятия исследования. Все названия разделов выделяются полужирным.
Основные разделы введения:
Развёрнутый вывод о том, что, несмотря на имеющиеся исследования данного вопроса, научные знания в отрасли недостаточны. Актуальность должна быть подтверждена статистическими выкладками в виде диаграмм. Ссылка на источники статистических данных обязательна.
Пример 1 (Интернет-магазин):
Актуальность разработки системы управления интернет-магазином обусловлена ростом электронной коммерции и необходимостью автоматизации процессов обработки заказов, управления складом и аналитики продаж. Подтверждается диаграммой ниже.
Рис. 1 — Динамика роста электронной коммерции в России
Пример 2 (Мобильное приложение):
Создание мобильного приложения для управления задачами актуально в связи с увеличением количества удалённых работников и необходимостью эффективного планирования времени.
Результат, для достижения которого проводится исследование.
Цели при разработке информационной системы (ИТ-проекта) должны быть чёткими, измеримыми, достижимыми, релевантными и ограниченными по времени. Рекомендуется использовать подход SMART:
- Specific — конкретная цель, чётко формулирует, что должно быть достигнуто. Например, цель «Разработать мультибраузерную систему» не является конкретной, но «Разработать систему, работающую в браузерах Chrome, Firefox и Edge» — уже конкретизированная цель.
- Measurable — измеримая цель, позволяет объективно оценить результат. Например, «Увеличить количество пользователей» — не измеримая цель, но «Увеличить количество пользователей до 100 000» — уже измеримая.
- Attainable — достижимая цель, должна быть достаточно амбициозной и не слишком простой для достижения. Важно соблюдать баланс: очень лёгкая цель расхолаживает, а недостижимая демотивирует людей.
- Relevant — актуальная цель, должна соответствовать современным трендам, не противоречить стратегии компании. Например, цель «Внедрить систему на платформе 1С:Предприятие 7.7» лучше заменить на «Внедрить систему на платформе 1С:Предприятие 8.3».
- Time-bound — ограниченная во времени, самое оптимальное — 3 месяца, полгода, максимум, год. Если цель больше года, то она теряет свою актуальность и расфокусирует команду.
Пример 1 (Веб-приложение):
Разработка веб-приложения для автоматизации процесса бронирования столиков в ресторане с функционалом онлайн-оплаты.
Пример 2 (База данных):
Создание информационной системы учёта студентов и учебного процесса с возможностью формирования отчётности.
Ступени на пути по достижению цели.
Задачи – это последовательные шаги в достижении поставленной цели, поэтому они должны излагаться последовательно и могут быть в логике только последовательного выполнения, только параллельного выполнения или классически последовательно-параллельного выполнения.
В классической логике пример постановки задач:
- Изучить материал …...
- Проанализировать предметную область …...
- Спроектировать …….
- Смоделировать ……..
- Разработать …….
- Провести документирование …..
- Протестировать …….
- Представить проект на защиту….
Пример (Система аналитики):
- Проанализировать существующие системы аналитики веб-сайтов
- Разработать архитектуру системы сбора и визуализации данных
- Реализовать модуль сбора статистики посещений
- Создать интерфейс для отображения аналитических отчётов
- Протестировать работоспособность системы
То, что исследуется: объект или явление, порождающее проблемную ситуацию.
Пример (CRM-система):
Процессы взаимодействия с клиентами в малом и среднем бизнесе, включая ведение клиентской базы и управление продажами.
То, что в границах научного объекта получает научное объяснение.
Пример:
Методы и алгоритмы персонализации образовательного контента на основе анализа успеваемости учащихся.
Методы, используемые автором для разработки.
Пример (Разработка ПО):
- Объектно-ориентированное программирование (ООП)
- Методологии Agile и Scrum
- Технологии HTML5, CSS3, JavaScript
- СУБД MySQL
Труды учёных, авторов книг и пособий.
Пример:
- Мартин Фаулер «Архитектура корпоративных программных приложений»
- Роберт Мартин «Чистая архитектура»
- Томас Коннолли «Базы данных: проектирование и реализация»
Возможности использования содержащихся в работе выводов.
Пример:
Разработанная система может быть внедрена в малом и среднем бизнесе для автоматизации учёта и формирования отчётности.
Описание основных разделов своей работы с кратким содержанием.
Пример:
Работа состоит из введения, трёх глав, заключения и списка литературы. В первой главе проводится анализ предметной области. Во второй — проектирование архитектуры. В третьей — реализация и тестирование.
Пример (подробный):
Структура данной работы включает в себя обозначения и сокращения, введение, три главы, заключение, список источников и приложения.
Введение. Обоснована актуальность разработки информационной системы, поставлены цели и задачи работы.
В первой главе был проведён анализ предметной области, выбраны методологии и стандарты проектирования и моделирования для разработки.
Объём введения: от 2 до 5 страниц.
Дополнительная информация
- Указать актуальность
- Чётко сформулировать цель
- Перечислить задачи
- Определить объект и предмет
- Описать методы
- Подчеркнуть практическую значимость
Определение
Описание предметной области, анализ объекта автоматизации, нормативная база, концепция системы.
Требования
Подразделы: 1.1 Анализ предметной области, 1.2 Нормативная база, 1.3 Концепция ИС, 1.4 Обоснование среды, 1.5 Технология проектирования, 1.6 SADT/UML, 1.7 Дизайн-макетирование.
Пример оформления
Анализ предметной области включает изучение бизнес-процессов, выявление требований заказчика, формирование концепции информационной системы.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Описание разработки: интерфейс, элементы системы, технорабочий проект, тестирование.
Требования
2.1 Создание интерфейса. 2.2 Элементы ИС (2.2.1–2.2.4). 2.3 Технорабочий проект. 2.4 Тестирование. 2.5 Оценка стоимости.
Пример оформления
Мокапы, каркасы, вайрфреймы, интерактивные прототипы.
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Требования безопасности при работе за ПК и реализации проекта.
Требования
3.1 Перед началом работы. 3.2 Во время выполнения. 3.3 После окончания. 3.4 В аварийных ситуациях.
Пример оформления
Требования к рабочему месту, освещению, эргономике. Действия при аварии.
Дополнительная информация
- Указать требования по ГОСТ
- Описать действия в аварийных ситуациях
Определение
Итоговый раздел с выводами по теоретической и практической частям, соответствием целям и задачам введения. Структурированность, конкретика, научный стиль. Выводы по главам, перспективы развития, достижение целей. Без введения новых терминов. Объём: 2–3 страницы (не более 5).
Требования
Объём: 2–3 страницы (не более 5). Соответствие введению; выводы по каждой главе; общий итог; перспективы развития.
Пример оформления
Главное: Итоговый раздел 2–3 страницы (не более 5): выводы по теоретической и практической частям, соответствие целям и задачам введения.
Должно включать:
- Выводы по теоретической части (резюме исследованных подходов и технологий)
- Результаты практической части (описание системы, особенности, инновационность)
- Перспективы развития
- Достижение целей — явное указание решения поставленных задач
- Краткость, конкретика, научный стиль; без новых терминов
Пример:
В ходе выполнения дипломной работы была разработана информационная система для автоматизации учёта… В результате проведённого исследования достигнуты все поставленные цели. Практическая значимость заключается в возможности внедрения в малом бизнесе.
Структура заключения (логика построения)
Идеальное заключение строится по принципу пирамиды: от конкретных результатов к общим выводам и перспективам.
Начните с фразы, которая сигнализирует о завершении исследования.
Прямо укажите, что цель, сформулированная во введении, выполнена.
Сожмите содержание всей работы до 3–5 ключевых тезисов. Не пересказывайте содержание глав, а выделите главное. Для реферата по программированию это могут быть:
- Теоретические итоги: К какому пониманию проблемы вы пришли?
Пример: «В первой главе было установлено, что архитектура MVC позволяет эффективно разделить логику приложения, что критически важно для поддержки крупных проектов.» - Сравнительный анализ: Что лучше/хуже? (если тема сравнительная)
Пример: «Сравнение Python и Java показало, что для задач прототипирования Python предпочтительнее из-за простоты синтаксиса, тогда как Java обеспечивает более строгий контроль типов в крупных корпоративных решениях.» - Практические результаты: Что удалось создать или понять?
Пример: «Разработанная блок-схема алгоритма сортировки массива наглядно демонстрирует его преимущество в скорости над пузырьковой сортировкой при больших объёмах данных.» - Характеристики: Упомяните ключевые свойства, если они важны.
Пример: «Были выявлены ключевые особенности фреймворка Django: высокая скорость разработки, встроенная админ-панель и безопасность.»
Пример: «Анализ языка C++ показал его высокую производительность и гибкость управления памятью, что делает его незаменимым для системного программирования.»
Сформулируйте самую главную мысль, ради которой писалась работа. Это ответ на проблемный вопрос темы.
(Необязательно, но очень желательно для хорошей оценки)
Покажите, где можно применить полученные знания или в каком направлении можно развивать тему дальше.
Особенности заключения для рефератов по программированию
- Точность и конкретика. Избегайте общих фраз. Если вы писали о типах данных, не пишите «всё хорошо». Напишите: «Была подтверждена важность статической типизации для предотвращения ошибок на этапе компиляции.»
- Связь с кодом/алгоритмами. Если в реферате были листинги (куски кода) или схемы, в заключении можно коротко упомянуть, что они подтверждают ваши выводы.
Пример: «Приведённые в работе примеры кода наглядно иллюстрируют, как лямбда-выражения в Python позволяют сократить объём шаблонного кода.» - Акцент на производительность и эффективность. Программирование — это наука о решении задач. Старайтесь делать выводы в терминах «эффективность», «оптимизация», «скорость работы», «надёжность», «масштабируемость», если это уместно.
- Отсутствие новой информации. Это железное правило для любого реферата. В заключении нельзя вводить новые термины, понятия или идеи, которые не обсуждались в основной части. Всё, о чём вы пишете в конце, должно быть уже сказано (пусть и другими словами) в работе.
Клише и фразы-помощники
Чего следует избегать
- Воды и общих фраз. (Например: «Программирование — это очень важно и интересно».)
- Дословного копирования введения. Во введении вы обещали, что сделаете, а в заключении — отчитываетесь о сделанном.
- Субъективных оценок без аргументов. (Например: «Python — самый лучший язык». Лучше: «Python показался наиболее удобным для быстрого написания прототипов благодаря своему синтаксису».)
- Слишком большого объёма. Для дипломной работы заключение обычно 2–3 страницы (не более 5).
Основные требования к заключению
- Краткость и ёмкость: Заключение не должно быть чрезмерным. Для дипломной работы ориентир — 2–3 страницы (не более 5); для курсовой — обычно 1–2 страницы.
- Самостоятельность: Выводы должны быть сформулированы вами самостоятельно на основе проведённого анализа. Недопустимо механическое копирование фраз из введения или основной части.
- Логичность: Выводы должны вытекать из содержания работы и соответствовать задачам, поставленным во введении.
- Конкретность: Следует избегать общих фраз («вода», «мир во всём мире»). Нужно писать конкретно о полученных результатах (цифры, факты, выявленные закономерности).
- Научный стиль: Изложение должно быть чётким, без эмоциональной окраски.
Чего делать НЕЛЬЗЯ
- Писать о том, чего нет в работе. Все выводы должны строго соответствовать содержанию основной части.
- Использовать местоимение «Я». Допустимо: «автор пришёл к выводу», «в данной работе показано», «можно утверждать».
- Приводить новые факты или аргументы. Заключение — это подведение черты, а не место для новых дискуссий.
- Пересказывать содержание («В первой главе я написал то, во второй это»). Нужны именно выводы, а не оглавление.
Дополнительная информация
- Подвести итоги по главам
- Указать достижение цели
- Описать практическую значимость
Определение
Библиографический список литературы по ГОСТ 7.1-2003 (или ГОСТ Р 7.0.100-2018). Структура: нормативные документы; основная литература (не менее 5, до 5 лет); интернет-ресурсы с датой обращения. Все цитируемые источники должны быть в списке.
Требования
15–40 источников; основная литература не менее 5 (из них ≥2 по предметной области); нормативные не менее 7; интернет-ресурсы ≥3; оформление по ГОСТ; алфавитный порядок; ссылки в тексте обязательны.
Пример оформления
Главное: Библиографический список по ГОСТ 7.1-2003 (или ГОСТ Р 7.0.100-2018). Объём: 15–40 источников. Структура: нормативные → основная литература → интернет-ресурсы.
Должно включать:
- Нормативные документы (не менее 7, из них ≥2 ФЗ по предметной области)
- Основная литература (не менее 5, до 5 лет, из них ≥2 по предметной области)
- Интернет-ресурсы (≥3, с датой обращения)
- Алфавитный порядок, единый стиль оформления
- Все цитируемые в тексте источники должны быть в списке
Пример:
1. Иванов А.А. Разработка информационных систем: учебник. — М.: Юрайт, 2020. — 345 с. 2. Петров В.С. Подходы к проектированию БД // Информационные технологии. — 2022. — № 4. — С. 45-52. 3. Документация Django. URL: https://docs.djangoproject.com/ (Дата обращения: 12.05.2024 г.).
СПИСОК ИСТОЧНИКОВ ДЛЯ ДИПЛОМНОЙ РАБОТЫ
- Объём: 15–40 источников (по согласованию с руководителем и с учётом требований)
- Основная литература не менее 5 источников (до 5 лет), из них не менее 2 по предметной области
- Нормативные источники не менее 7, из них не менее 2 Федеральных законов по предметной области
- Интернет-ресурсы: 3 и более, из них не менее 2 относящихся к анализу предметной области
- Соответствие ГОСТу (например, ГОСТ 7.1-2003 или актуальному)
- Наличие всех цитируемых в работе источников
- Единый стиль оформления всех позиций
- Нормативные документы (законы, стандарты, ГОСТы)
- Основные источники
- Дополнительные источники
- Интернет-ресурсы (с указанием даты обращения)
- Алфавитный порядок (кроме нормативных документов)
- Для статей: ФИО автора, название, журнал, год, номер, страницы
- Для книг: ФИО автора, название, издательство, год, количество страниц
- Для электронных ресурсов: полный URL и дата обращения
- Нумерация сквозная по всему списку
- Используйте свежие источники (не старше 3–5 лет, кроме классических работ)
- Включайте источники из научных баз (Scopus, Web of Science, РИНЦ)
- Добавляйте документацию к используемым технологиям и фреймворкам
- Проверяйте авторитетность источников
- Указывайте страницы
Примеры оформления
1. Иванов А.А. Разработка информационных систем: учебник. — М.: Юрайт, 2020. — 345 с.
2. Петров В.С. Современные подходы к проектированию БД // Информационные технологии. — 2022. — № 4. — С. 45–52.
3. Сайт: Официальная документация Django Framework. URL: https://docs.djangoproject.com/ (Дата обращения: 12.05.2024 г.).
Важно: уточните у руководителя актуальные требования к оформлению списка литературы, так как они могут немного отличаться от стандартных!
- Проверить иерархию документов
- Убедиться в алфавитном порядке
- Проверить оформление ссылок
- Указать даты обращения
- Проверить актуальность
- Убедиться в наличии всех источников
- Проверить нумерацию
- Указать полные выходные данные
Дополнительная информация
- Оформить по ГОСТ
- Проверить алфавитный порядок
- Убедиться в наличии всех источников из текста
Определение
Дополнительные материалы по ГОСТ 2.105-95 и методическим указаниям. Каждое приложение начинается с новой страницы; слово «ПРИЛОЖЕНИЕ» и буква (например, ПРИЛОЖЕНИЕ А) оформляются в правом верхнем углу страницы. В основном тексте обязательны ссылки на приложения. Нумерация кириллицей (А, Б, В…).
Требования
Обязательные: А — ТЗ; Б — план-график; В — план управления; Г — AS-IS; Д — TO-BE; Е — варианты использования; Ж — концептуальная схема; К — схема данных; Л — диаграмма классов; О — проволочная диаграмма; П — чек-листы тестирования; С — руководство пользователя; Ф — антиплагиат.
Пример оформления
Главное: Дополнительные материалы по ГОСТ 2.105-95. Каждое приложение на новой странице; обозначение приложения (ПРИЛОЖЕНИЕ А и т.д.) — в правом верхнем углу. Нумерация кириллицей (А, Б, В…). В тексте обязательны ссылки.
Должно включать:
- А — ТЗ; Б — план-график; В — план управления; Г — AS-IS; Д — TO-BE
- Е — варианты использования; Ж — концептуальная схема; К — схема данных
- Л — диаграмма классов; О — проволочная диаграмма; П — чек-листы тестирования
- С — руководство пользователя; Ф — антиплагиат
- Заголовок: ПРИЛОЖЕНИЕ А (в правом верхнем углу), наименование приложения — по правилам методички.
Пример:
Приложение А — Техническое задание. Приложение Б — План-график (диаграмма Ганта). Приложение В — План управления проектом. Приложение Г — Диаграмма AS-IS. Приложение Д — Диаграмма TO-BE. Приложение Е — Диаграмма вариантов использования.
ПРИЛОЖЕНИЯ
Приложения оформляются в соответствии с ГОСТ 2.105-95 и методическими указаниями учебного заведения.
Каждое приложение должно начинаться с новой страницы и иметь заголовок с указанием номера (например, «ПРИЛОЖЕНИЕ А»).
В основном тексте работы должны быть ссылки на приложения.
ПЕРЕЧЕНЬ ПРИЛОЖЕНИЙ
Нажмите на приложение, чтобы перейти к его описанию на странице приложений:
Документ, содержащий требования к разрабатываемому продукту. Основные требования: полное описание функционала, технические требования, критерии приемки.
Графическое представление сроков выполнения задач проекта. Основные требования: временная шкала, список задач, зависимости между задачами, ответственные.
Документ, описывающий подход к управлению проектом. Основные требования: описание методологии, роли и ответственности, процессы управления, коммуникации.
Отображение текущего состояния процессов. Основные требования: графическое представление текущих процессов, детализация до необходимого уровня.
Отображение целевого состояния процессов после изменений. Основные требования: графическое представление будущих процессов, сравнение с AS-IS, детализация.
Показывает взаимодействие между акторами и системой. Основные требования: акторы, варианты использования, отношения между ними.
Высокоуровневое представление архитектуры. Основные требования: основные компоненты, их взаимодействие, ключевые технологии.
Показывает изменение состояния объекта в ответ на события. Основные требования: состояния, переходы, события, условия.
Показывает поток выполнения процессов. Основные требования: действия, решения, параллельные потоки, конечные точки.
Отображает структуру данных в системе. Основные требования: сущности, атрибуты, отношения, ключи.
Показывает структуру классов системы и их отношения. Основные требования: классы, атрибуты, методы, отношения (наследование, ассоциация и др.).
Показывает движение информации в системе. Основные требования: источники и получатели информации, направления потоков, форматы данных.
Документ, описывающий подход к тестированию системы. Основные требования: виды тестирования, тестовые сценарии, критерии прохождения, окружение.
Визуализация структуры экранов и форм приложения.
Перечень проверок для тестирования функционала. Основные требования: чёткие формулировки проверок, ожидаемые результаты, приоритеты.
Графическое представление бизнес-процессов организации. Основные требования: участники, действия, события, документы, решения.
Документ, помогающий пользователям работать с системой. Основные требования: пошаговые инструкции, скриншоты, FAQ, контакты поддержки.
Графическое представление статистических данных. Основные требования: наглядность, точность, подписи, легенда.
Показывает последовательность выполнения рабочих задач. Основные требования: этапы, участники, входы/выходы, условия перехода.
Документ, описывающий процесс установки и настройки системы. Основные требования: системные требования, пошаговая инструкция установки, настройка окружения, устранение неполадок.
Полный код разработанного программного обеспечения. Основные требования: структурированность, комментарии, соответствие стандартам кодирования.
Описание организации-заказчика.
Отчёт о проверке текста на заимствования. Основные требования: процент уникальности, источники заимствований, рекомендации. Минимальный уровень — 67%
- Каждое приложение начинается с новой страницы
- Нумерация приложений кириллицей (А, Б, В…)
- В тексте должны быть ссылки на приложения
- Приложения размещаются в порядке упоминания
- Объём приложений не ограничен
- Каждое приложение имеет заголовок
Дополнительная информация
- Нумеровать буквами
- Ссылки в тексте на приложения
- Каждое приложение с новой страницы
Определение
Обзор предметной области, анализ существующих аналогов, выявление требований, обоснование выбора технологии, постановка задачи (ТЗ).
Требования
Модели данных (ER-диаграммы), UML-диаграммы (Use Case, Sequence, Class diagram).
Пример оформления
Анализ предметной области включает изучение бизнес-процессов, выявление требований заказчика, формирование концепции информационной системы.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Перечень ГОСТов, стандартов и нормативных документов, применяемых при проектировании системы.
Требования
Актуальные редакции стандартов, ссылки в тексте. Международные акты → Конституция → Федеральные законы → ГОСТы.
Пример оформления
Главное: Перечень нормативных документов, регулирующих информацию, ИТ и защиту информации.
Должно включать:
- Международные акты
- Конституция РФ
- Федеральные законы (149-ФЗ, 63-ФЗ об электронной подписи, 152-ФЗ о персональных данных)
- ГОСТы (15971-90, 34.601, 34.602)
- Ссылки на источники
Пример:
149-ФЗ — об информации и ИТ. 63-ФЗ — об электронной подписи. ГОСТ 15971-90 — системы обработки информации. Последовательность: законы → постановления → ГОСТы.
| № | Тип документа | Название | Описание |
|---|---|---|---|
| 1 | ФЗ 149-ФЗ | Об информации и ИТ | Регулирует отношения в сфере информации и защиты |
| 2 | ФЗ 63-ФЗ | Об электронной подписи | Правовые основы использования ЭП |
| 3 | ГОСТ 15971-90 | Системы обработки информации | Термины и определения |
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Описание концепции информационной системы: назначение, основные функции, целевая аудитория.
Требования
Архитектура (клиент, сервер, БД, API). Концептуальная схема (ER или карта сайта). Классификация элементов. Описание сущностей. Перечень отчётов. Ожидаемый эффект.
Пример оформления
Главное: Описание концепции: архитектура, ключевые сущности, перечень отчётов, ожидаемый эффект.
Должно включать:
- Архитектура: клиент, сервер, БД, API
- Концептуальная схема (ER или карта сайта)
- Классификация по назначению, доступу, частоте
- Описание сущностей с атрибутами
- Перечень отчётов с частотой формирования
- Планируемые результаты внедрения
Пример:
Трёхзвенная архитектура: браузер ↔ Node.js ↔ PostgreSQL. Сущность "Продукт": ID, название, цена, категория. Отчёт по продажам — ежедневно. Эффект: скорость +40%, ручной труд −60%.
ТРЕБОВАНИЯ К КОНЦЕПТУАЛЬНОЙ СХЕМЕ ИС (САЙТА)
Ниже приведены требования к разработке концептуальной схемы информационной системы или сайта, охватывающие структуру, пользовательский опыт, техническую реализацию, визуальное оформление и маркетинговые цели.
Это требования к тому, как страницы связаны друг с другом и как организован контент.
- Схема должна четко показывать уровни вложенности: главная страница, разделы, подразделы, внутренние страницы.
- Не должно быть «потерянных» страниц, которые не привязаны к навигации.
- Контент должен группироваться по смыслу. Нельзя смешивать коммерческие предложения с контактами или блогом в одном разделе.
- Разделы не должны дублировать друг друга по смыслу.
Концептуальная схема создается не для роботов, а для людей, поэтому она должна отвечать на вопросы пользователя.
- Новый пользователь: зайдет на главную → в раздел «О нас» → в «Портфолио».
- Покупатель: зайдет сразу на страницу акции → в «Каталог» → в «Корзину».
- Структура должна обеспечивать выполнение этих сценариев.
То, как схема будет взаимодействовать с поисковыми системами и разработчиками.
Как оформляется документ для передачи заказчику или команде.
- Квадрат — раздел каталога.
- Круг — фильтр/поиск.
- Прямоугольник — информационная страница.
- Ромб — действие (отправка формы, регистрация).
Схема должна работать на бизнес-цели.
Итог: Пример качественной концептуальной схемы
Хорошая концептуальная схема — это документ, глядя на который:
- Заказчик видит, что его услуги и товары представлены правильно.
- Проектировщик (UX) видит логику перемещения пользователя.
- Разработчик понимает, сколько типов страниц нужно верстать и какие модули подключать.
- SEO-специалист видит структуру вложенности для построения правильных URL и расстановки веса страниц.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Обоснование выбора языка программирования, фреймворков, СУБД и других технологий.
Требования
Сравнение языков, сред разработки (VS Code, Sublime), локальных хостингов (OpenServer, XAMPP). Аналитическая таблица с обоснованием выбора.
Пример оформления
Главное: Обоснование по 3 направлениям: язык разработки, СУБД, среда разработки. Подтверждение аналитической таблицей.
Должно включать:
- Сравнение языков (C++, C#, Java, JavaScript)
- Сравнение сред (VS Code, Sublime, Atom): бесплатность, git, автодополнение
- Сравнение хостингов (OpenServer, XAMPP, Wamp)
- Плюсы и минусы выбранного стека
Пример:
VS Code: бесплатный, открытый код, интеграция с git. JavaScript: широкое применение, прототипное наследование. Таблица сравнения с +/−.
| Критерий | VS Code | Sublime | Atom |
|---|---|---|---|
| Бесплатность | + | − | + |
| Интеграция с git | + | + | + |
| Автодополнение кода | + | + | + |
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Описание применяемой методологии и технологии проектирования (итеративная, Agile и др.).
Требования
ГОСТ 34.601-90: стадии (формирование требований, концепция, техпроект, рабочее проектирование, ввод, сопровождение). Участники и документы. RAD, Agile, CASE-средства.
Пример оформления
Главное: Стадии создания АС по ГОСТ 34.601-90 и применяемая методология.
Должно включать:
- 1. Формирование требований (1–2 мес)
- 2. Разработка концепции (2–3 мес)
- 3. Техническое проектирование (3–4 мес)
- 4. Рабочее проектирование (4–6 мес)
- 5. Ввод в действие (2–3 мес)
- 6. Сопровождение АС
- Участники и подтверждающие документы
- RAD, Agile, CASE-средства
Пример:
ТЗ-2023-001 на стадии 1. Концепция АС v1.0 на стадии 2. Прототипирование и итеративная разработка по RAD.
СТАДИИ И ЭТАПЫ СОЗДАНИЯ СИСТЕМЫ
- Обследование объекта и обоснование необходимости создания ИС
- Формирование требований пользователя на основе Брифа
- Оформление отчета о выполнении и заявки на разработку
- Изучение объекта автоматизации
- Проведение необходимых исследований
- Выбор среды реализации
- Моделирование
- Проектирование
- Разработка проектных решений
- Разработка документации на ИС и ее части
- Разработка рабочей документации
- Разработка адаптируемых программных средств
- Тестирование системы
- Подготовка персонала
- Защита проекта
- Послегарантийное обслуживание
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Диаграммы SADT, UML: вариантов использования, последовательности, классов, развёртывания.
Требования
Обязательные: Use Case, концептуальная схема, диаграмма объектов, классов, деятельности, информационных потоков. Единый стиль, пояснения, сохранение в среде и PDF.
Пример оформления
Главное: Обязательные диаграммы UML/SADT в едином стиле, с пояснениями, в среде и PDF.
Должно включать:
- Use Case (обязательная)
- Концептуальная схема (обязательная)
- Диаграмма состояний, объектов (обяз.), классов (обяз.)
- Диаграмма деятельности (обяз.), информационных потоков (обяз.)
- Схема данных, алгоритм работы
Пример:
Интернет-магазин: Use Case — «Оформить заказ», «Оплатить товар», «Просмотреть каталог». Состояния заказа: Новый → Оплаченный → Отправленный → Доставленный.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Вайрфреймы, каркасные прототипы, макеты интерфейса.
Требования
Мокапы, каркасы, проволочные диаграммы. Низкодетализированные схемы для структуры и функционала. Тестирование на аудитории.
Пример оформления
Главное: Вайрфреймы — низкодетализированные схемы структуры и функционала. Этапы: каркас → визуал → тестирование.
Должно включать:
- Мокапы — визуальные прототипы
- Каркасы (wireframes) — блоки без детализации
- Проволочные диаграммы — серые схемы
- Инструменты: Balsamiq, Figma, Axure
- Тестирование на целевой аудитории
Пример:
Вайрфрейм главной: шапка, меню, слайдер, блок товаров, футер. Каркас формы заказа: поля ввода, кнопки. Итерация по обратной связи.
ДИЗАЙН-МАКЕТИРОВАНИЕ: КОМПОНЕНТЫ И ТРЕБОВАНИЯ
Дизайн-макетирование отвечает на вопрос «Как это выглядит и ощущается?» (сетка, шрифты, цвета, кнопки).
Требования к разработке отвечают на вопрос «Как это работает и будет ли это удобно/полезно?» (скорость, безопасность, адаптивность, интуитивность).
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Описание структуры окон, навигации, каркасных прототипов (wireframes) экранов.
Требования
Окно приветствия, авторизация/регистрация, главное окно. Мокапы, каркасы, вайрфреймы, интерактивные прототипы. Описание UX.
Пример оформления
Главное: Создание интерфейса: окно приветствия, авторизация/регистрация, главное окно. Мокапы, каркасы, вайрфреймы.
Должно включать:
- Окно приветствия (заставка, логотип)
- Форма авторизации (логин, пароль, «Запомнить меня»)
- Форма регистрации (обязательные поля, валидация)
- Главное окно (меню, рабочая область)
- Требования к UX: понятность, последовательность действий
Пример:
Приложение учёта: экран приветствия 2 с, форма входа (логин/пароль, кнопка «Вход», ссылка «Регистрация»), главное окно — боковое меню и список заказов.
ГРАФИЧЕСКИЙ ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС: ЭЛЕМЕНТЫ И КОМПОНЕНТЫ
Окно приветствия — первое, что видит пользователь при запуске приложения. Должно создавать положительное впечатление и представлять основные возможности системы.
- Логотип приложения в центре экрана
- Краткое описание возможностей (1–2 предложения)
- Кнопки для перехода к авторизации или регистрации
- Анимация плавного появления элементов
- Адаптивный дизайн для разных размеров экрана
- Создать базовый макет с логотипом и текстом
- Добавить кнопки навигации
- Реализовать анимацию появления
- Протестировать на разных устройствах
- Оптимизировать время загрузки
Экран для входа в систему или создания нового аккаунта. Должен быть простым, интуитивно понятным и безопасным.
- Поля для ввода email/логина и пароля
- Валидация вводимых данных
- Кнопка «Забыли пароль?»
- Переключатель между режимами входа и регистрации
- Индикатор сложности пароля при регистрации
Центральный интерфейс после успешной авторизации. Содержит основные функции и навигацию.
- Навигационное меню (боковое или верхнее)
- Область основного контента
- Быстрый доступ к важным функциям
- Информация о текущем пользователе
- Кнопка выхода из системы
- Адаптивный дизайн
- Интуитивно понятная структура
- Быстрый доступ к основным разделам
- Индикация текущего раздела
- Адаптивность для мобильных устройств
- Logofury и Logopond — галереи логотипов компаний и брендов со всего мира.
- Pinterest — социальная сеть, где пользователи делятся тематическими подборками фото и рисунков, объединённых одной темой, стилем или цветовой палитрой.
- Figma, Adobe Illustrator и Photoshop. Это графические и фоторедакторы с возможностью создания и отрисовки эскизов, подбора цветовой палитры, формы, графических элементов и шрифтов.
- Adobe Color, ColorScheme.Ru, Coolors и Designspiration — библиотеки готовых изображений и цветовых схем с учётом сочетаемости оттенков.
- «Шрифты онлайн» и Fontstorage — библиотеки и онлайн-сервисы для подбора шрифтов.
- Dribbble — профессиональное сообщество дизайнеров, где можно обсудить идеи и эскизы, а также прочитать о реальных кейсах разработки логотипов компаний с разбором всех деталей и нюансов.
- Muzli — онлайн-сервис (приложение и плагин для браузера), который объединяет дизайнеров, разработчиков и продакт-менеджеров, а также содержит подборки новостей, кейсов и иллюстраций на тему дизайна.
- Behance — популярный сервис для публикации портфолио, поиска вакансий и разовых проектов по графическому и веб-дизайну.
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Таблицы БД, запросы, формы, отчёты. Описание ключевых алгоритмов и структур.
Требования
2.2.1 Таблицы. 2.2.2 Запросы. 2.2.3 Формы. 2.2.4 Отчёты. База данных, макет схемы, описание таблиц.
Пример оформления
Главное: Разработка элементов ИС: база данных, макет схемы, таблицы; далее — запросы, формы, отчёты.
Должно включать:
- Создание БД в выбранной СУБД
- Макет (схема) данных
- Описание таблиц с полями и типами
- Ключевые запросы и связи
- Формы ввода/редактирования
- Шаблоны отчётов
Пример:
БД «Магазин»: таблицы users, products, orders, order_items. Схема с FK. Форма заказа — выбор товаров, количество, итог. Отчёт по продажам — период, группировка.
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Техническая документация: структура проекта, модули, зависимости. Порядок деятельности пользователя.
Требования
Установка, подключение к БД, настройка, обучение, устранение проблем, утилизация. Описание архитектуры, технологический стек.
Пример оформления
Главное: Технорабочий проект: порядок деятельности пользователя — установка, подключение к БД, настройка, обучение, устранение проблем, утилизация.
Должно включать:
- Установка ПО (сервер, клиент, СУБД)
- Подключение к базе данных
- Настройка конфигурации (config, .env)
- Обучение персонала (инструкции, видео)
- Устранение неисправностей (логи, FAQ)
- Утилизация при снятии с эксплуатации
Пример:
Установка: скачать дистрибутив → распаковать → настроить БД в config → запустить миграции → создать учётные записи. Инструкция: 5 шагов, скриншоты.
ТЕХНОРАБОЧИЙ ПРОЕКТ: ПОРЯДОК ДЕЯТЕЛЬНОСТИ ПОЛЬЗОВАТЕЛЯ
- Установку системы
- Подключение к базе данных
- Настройку системы
- Обучение пользованию
- Порядок устранения проблем
- Утилизацию системы
- Проверка системных требований
- Загрузка дистрибутива
- Запуск установщика
- Выбор параметров
- Завершение установки
- Создание базы данных
- Настройка прав доступа
- Конфигурация подключения (config, .env)
- Тестирование соединения
- Базовые параметры, пользователи и роли
- Ознакомление с интерфейсом
- Базовые и расширенные операции
- Диагностика → поиск решения → исправление → тестирование
- Архивирование данных, удаление системы, документирование
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Чек-листы, виды тестирования (модульное, интеграционное). Анализ результатов, скриншоты тестов.
Требования
Unit, UI, функциональное тестирование. Чек-листы. График тестирования. Протоколы, выводы.
Пример оформления
Главное: Тестирование: модульное (Unit), UI, функциональное. Чек-листы, график тестирования, протоколы, выводы.
Должно включать:
- Unit-тесты для критичных модулей
- UI-тесты (интерфейс, навигация)
- Функциональное (сценарии использования)
- Чек-листы по функционалу
- График (план) тестирования
- Протоколы, скриншоты, выводы
Пример:
Чек-лист: Вход под пользователем ✓, Создание заказа ✓, Экспорт отчёта ✓, Негативный тест: неверный пароль — ожидаемое сообщение ✓. Протокол: дата, тестировщик, результат.
ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Проверка отдельных компонентов на корректность. Выполняется разработчиками на этапе написания кода.
Проверка пользовательского интерфейса: соответствие требованиям, удобство, корректность отображения.
Проверка соответствия функциональным требованиям, бизнес-процессам, входным и выходным данным.
- Все публичные методы протестированы
- Проверены граничные условия
- Элементы интерфейса отображаются корректно
- Проверена адаптивность и доступность
- Основной сценарий выполняется полностью
- Обработка ошибок работает корректно
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Расчёт трудозатрат, оценка стоимости разработки проекта.
Требования
Состав команды, роли, почасовая оплата, диаграмма Ганта, расчёт по трудозатратам.
Пример оформления
Главное: Оценка стоимости: состав команды, роли, почасовая оплата, диаграмма Ганта, расчёт по трудозатратам.
Должно включать:
- Состав команды (роли: аналитик, разработчик, тестировщик)
- Почасовая ставка по ролям
- Трудозатраты по этапам (часы/чел-дни)
- Диаграмма Ганта (сроки, зависимости)
- Итоговая стоимость проекта
Пример:
Команда: 1 аналитик (2000 руб/ч), 2 разработчика (1500 руб/ч), 1 тестировщик (1200 руб/ч). Этап 1: 40 ч → 80 тыс. Этап 2: 120 ч → 360 тыс. Итого: 580 тыс. руб.
РАСЧЁТ СТОИМОСТИ РАЗРАБОТКИ ПРИЛОЖЕНИЯ
Расчёт происходит исходя из: состава разработчиков, распределения обязанностей, почасовой оплаты, диаграммы Ганта, расчёта по трудозатратам.
Состав команды зависит от типа приложения (веб, мобильное). Примерные роли: Аналитик, Архитектор, Дизайнер, Frontend/Backend-разработчик, Тестировщик, Менеджер проекта, DevOps.
Для каждой роли расписываются обязанности в проекте (ТЗ, архитектура, дизайн, разработка, тестирование и т.д.).
Указывается ставка по ролям, трудозатраты по этапам (часы/чел-дни), сроки и зависимости в диаграмме Ганта.
Итоговая стоимость = сумма (трудозатраты по этапу × ставка × количество специалистов) по всем этапам.
Пример расчёта
Команда: 1 аналитик (2000 руб/ч), 2 разработчика (1500 руб/ч), 1 тестировщик (1200 руб/ч). Этап 1: 40 ч → 80 тыс. Этап 2: 120 ч → 360 тыс. Итого: 580 тыс. руб.
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Проверка рабочего места, оборудования, инструктаж. Чек-лист подготовки к работе.
Требования
Организация рабочего места: освещение 300–500 люкс, высота стула, расстояние до монитора 50–70 см. Электробезопасность: проверка розеток, кабелей, ИБП. Безопасность данных: антивирус, резервные копии, надёжные пароли.
Пример оформления
Главное: Чек-лист перед началом работы: организация рабочего места, электробезопасность, безопасность данных, личная безопасность.
Должно включать:
- Организация места: освещение 300–500 люкс, высота стула, монитор 50–70 см, клавиатура и мышь
- Электробезопасность: проверка розеток, кабелей, ИБП, без перегрузки сети
- Безопасность данных: антивирус, резервные копии, надёжные пароли, блокировка ПК
- Личная: перерывы 45–60 мин, упражнения для глаз/шеи/рук, осанка, температура 20–24°C
Пример:
Чек-лист: □ Освещение проверено □ Стул отрегулирован □ Монитор на расстоянии 60 см □ Розетки исправны □ Антивирус обновлён □ Данные сохранены. При запахе гари — немедленно прекратить работу.
ТРЕБОВАНИЯ БЕЗОПАСНОСТИ ПЕРЕД НАЧАЛОМ РАБОТЫ ПРОГРАММИСТА
Соблюдение мер безопасности при работе за компьютером помогает сохранить здоровье и повысить продуктивность труда.
- Обеспечьте правильное освещение рабочего места (не менее 300–500 люкс)
- Отрегулируйте высоту стула так, чтобы ноги стояли на полу или на подставке
- Монитор должен находиться на расстоянии 50–70 см от глаз, верхний край на уровне глаз
- Клавиатура и мышь должны располагаться так, чтобы не приходилось излишне напрягать руки
- Проверьте исправность розеток и кабелей оборудования
- Не допускайте захламления проводов и их механического повреждения
- Используйте источник бесперебойного питания для критически важного оборудования
- Избегайте перегрузки электрических сетей
- Убедитесь, что установлены и обновлены антивирусные программы
- Проверьте наличие актуальных резервных копий важных данных
- Используйте надёжные пароли и двухфакторную аутентификацию
- Не оставляйте рабочее место без блокировки компьютера
- Делайте перерывы каждые 45–60 минут (рекомендуется 5–10 минут)
- Выполняйте простые упражнения для глаз, шеи и рук
- Соблюдайте правильную осанку во время работы
- Поддерживайте комфортную температуру и влажность в помещении (20–24°C, 40–60%)
При возникновении любых нештатных ситуаций (запах гари, необычные звуки от оборудования и т.д.) немедленно прекратите работу и сообщите ответственному лицу.
Дополнительная информация
- Указать требования по ГОСТ
- Описать действия в аварийных ситуациях
Определение
Эргономика, освещение, режим труда и отдыха при работе за ПК.
Требования
Режим работы: 45–60 мин работы, 5–10 мин перерыва. Осанка, упражнения для глаз и шеи. Оборудование: без перегрева, без еды рядом. Информационная и психологическая безопасность.
Пример оформления
Главное: Во время работы: режим труда и отдыха (45–60 мин работы, 5–10 мин перерыва), эргономика, гигиена труда, информационная безопасность.
Должно включать:
- Оборудование: без перегрева, без механических повреждений, без еды и напитков рядом
- Гигиена труда: перерывы, упражнения, осанка, моргание, гимнастика для глаз
- Информбезопасность: не открывать подозрительные файлы, не передавать учётные данные
- При дыме/запахе гари — отключить оборудование; учесть расположение огнетушителей и выходов
Пример:
Режим: 50 мин работы → 10 мин перерыва (встать, разминка, упражнения для глаз). Не сутулиться. Не работать более 4 ч без длительного перерыва.
ТРЕБОВАНИЯ БЕЗОПАСНОСТИ ВО ВРЕМЯ ВЫПОЛНЕНИЯ РАБОТЫ ПРОГРАММИСТА
- Не допускайте перегрева компьютерного оборудования
- Избегайте механических повреждений техники
- Не употребляйте пищу и напитки рядом с рабочим оборудованием
- При подключении/отключении устройств соблюдайте правильную последовательность
- Соблюдайте режим работы: 45–60 минут работы, затем 5–10 минут перерыва
- Во время перерывов выполняйте простые физические упражнения
- Следите за осанкой, не сутультесь
- Регулярно моргайте и делайте упражнения для глаз
- Не открывайте подозрительные файлы и ссылки
- Не передавайте учётные данные третьим лицам
- Регулярно сохраняйте результаты работы
- Используйте только лицензионное программное обеспечение
- При обнаружении дыма или запаха гари немедленно отключите оборудование
- В случае неисправности оборудования прекратите работу и сообщите ответственному
- При ухудшении самочувствия прекратите работу и обратитесь за медицинской помощью
- Знайте расположение огнетушителей и аварийных выходов
- Избегайте длительной работы в состоянии стресса
- Делайте перерывы при появлении раздражительности или усталости
- Соблюдайте баланс между работой и отдыхом
- Не работайте непрерывно более 4 часов без длительного перерыва
Дополнительная информация
- Указать требования по ГОСТ
- Описать действия в аварийных ситуациях
Определение
Порядок завершения работы, отключение оборудования, уборка рабочего места.
Требования
Корректное завершение программ, штатное выключение ПК. Сохранение и резервные копии данных. Приведение в порядок рабочего места, проверка кабелей. Документирование выполненной работы.
Пример оформления
Главное: После окончания: корректное завершение программ, сохранение данных, приведение в порядок рабочего места, электробезопасность, документирование.
Должно включать:
- Завершение: закрыть программы, штатное выключение ПК, отключить периферию
- Данные: проверить сохранение, создать резервные копии, завершить сеансы, заблокировать станцию
- Рабочее место: убрать посторонние предметы, проверить провода, закрыть панели
- Сообщить о неисправностях, обновить журнал учета
Пример:
Порядок: сохранить файлы → создать бэкап → закрыть IDE и браузер → выключить ПК → отключить монитор → убрать стол → сообщить руководителю.
ТРЕБОВАНИЯ БЕЗОПАСНОСТИ ПОСЛЕ ОКОНЧАНИЯ РАБОТЫ ПРОГРАММИСТА
- Корректно завершите работу всех программ
- Осуществите штатное выключение компьютера
- Отключите периферийные устройства (принтеры, сканеры и др.)
- Проверьте отсутствие нагрева оборудования
- Убедитесь, что все важные данные сохранены
- Создайте резервные копии изменённых файлов
- Завершите все сеансы работы с удалёнными системами
- Заблокируйте рабочую станцию (если оставляете включённой)
- Приведите в порядок рабочее место
- Уберите все посторонние предметы от оборудования
- Проверьте отсутствие оголённых проводов
- Закройте все технические отсеки и панели
- При необходимости отключите оборудование от сети
- Проверьте отключение неиспользуемых устройств
- Убедитесь в отсутствии повреждений кабелей
- Сообщите о любых неисправностях оборудования
- Зафиксируйте выполненные задачи и текущее состояние работы
- Оставьте заметки для следующей рабочей сессии
- Обновите журнал учёта рабочего времени
- Сообщите о завершении работы ответственному лицу (при необходимости)
Дополнительная информация
- Указать требования по ГОСТ
- Описать действия в аварийных ситуациях
Определение
Действия при пожаре, поражении электрическим током, неисправности оборудования.
Требования
Возгорание: обесточить, позвонить 101/112, углекислотный огнетушитель. Поражение током: отключить питание, не прикасаться, вызвать 103/112. Утечка данных, аварийное отключение питания, вредоносное ПО, травмы.
Пример оформления
Главное: Действия в ЧС: возгорание, поражение током, утечка данных, отключение питания, вредоносное ПО, травмы. Номера 101, 103, 112.
Должно включать:
- Возгорание: обесточить, вызвать 101/112, углекислотный огнетушитель (не водой!), эвакуация
- Поражение током: отключить питание, не трогать пострадавшего голыми руками, 103/112, СЛР при необходимости
- Утечка данных: изолировать систему, сообщить ИБ, документировать
- Вредоносное ПО: отключить от сети, не удалять самостоятельно, сообщить в службу ИБ
Пример:
Пожар: отключить питание горящего ПК → позвонить 112 → использовать углекислотный огнетушитель. Поражение током: выключить автомат → деревянной палкой оттащить пострадавшего → вызвать 103 → при отсутствии дыхания — СЛР.
ТРЕБОВАНИЯ БЕЗОПАСНОСТИ В АВАРИЙНЫХ СИТУАЦИЯХ ДЛЯ ПРОГРАММИСТА
- Немедленно обесточьте горящее оборудование
- Сообщите о возгорании в пожарную охрану (101 или 112)
- Используйте углекислотный огнетушитель (не порошковый!)
- Не пытайтесь тушить водой под напряжением
- Эвакуируйтесь из помещения при распространении огня
- Немедленно отключите источник питания
- Не прикасайтесь к пострадавшему голыми руками
- Вызовите скорую помощь (103 или 112)
- При отсутствии дыхания начните сердечно-лёгочную реанимацию
- Сохраните оборудование в том виде, в котором произошло поражение
- Немедленно изолируйте компрометированную систему
- Сообщите ответственному за информационную безопасность
- Задокументируйте все действия и время обнаружения
- Не пытайтесь самостоятельно устранять последствия без разрешения
- Сохраните все логи и доказательства инцидента
- Немедленно сохраните все текущие данные
- Отключите оборудование от сети
- Используйте ИБП для корректного завершения работы систем
- После восстановления питания проверьте целостность данных
- Сообщите о инциденте системному администратору
- Немедленно изолируйте заражённую систему от сети
- Не пытайтесь самостоятельно удалять вирус
- Сообщите в службу информационной безопасности
- Задокументируйте симптомы заражения
- Не подключайте носители информации к другим компьютерам
- Немедленно прекратите работу
- Вызовите медицинскую помощь (103 или 112)
- Сообщите коллегам или охране о проблеме
- При электротравме — см. пункт 2
- При проблемах со зрением — закройте глаза, не трите их
Дополнительная информация
- Указать требования по ГОСТ
- Описать действия в аварийных ситуациях
Определение
Количественный анализ данных, показателей, трендов в предметной области.
Требования
Количество предприятий, средний оборот, средняя численность персонала, другие показатели. Таблицы, диаграммы, сводная статистика.
Пример оформления
Главное: Сбор количественных данных о предприятиях (количество, оборот, персонал) и визуализация в виде минимум 3 диаграмм.
Должно включать:
- Количество аналогичных предприятий в регионе
- Средний годовой оборот по отрасли
- Средняя численность персонала
- Другие значимые статистические показатели
Пример:
Для сети кофеен в Москве: всего 850 кофеен, средний оборот 15 млн руб/год, 12 человек на заведение. Диаграммы — распределение по округам, динамика за 5 лет.
Структура статистической информации при анализе предметной области включает виды данных, методы сбора, обработку и интерпретацию результатов.
Цель статистического анализа — выявить закономерности, тенденции и взаимосвязи между различными переменными, чтобы сделать выводы для прогнозирования, оптимизации процессов или выявления закономерностей.
ВИДЫ
Некоторые виды статистической информации, используемые при анализе предметной области:
- Описательная статистика. Даёт общую характеристику исследуемой группы, популяции или процесса. Включает показатели: среднее значение, медиана, мода, дисперсия и стандартное отклонение. Эти метрики позволяют получить общее представление о распределении данных, их тенденциях и разбросе.
- Диагностический анализ. Цель — выявление причинно-следственных связей и факторов, влияющих на наблюдаемые явления. Часто применяется для исследования зависимостей между переменными. Например, корреляционный анализ позволяет оценить силу и направление связи между двумя величинами, а регрессионный анализ помогает построить модель, описывающую эту связь.
- Анализ временных рядов. Метод исследования последовательных данных, собранных через равные промежутки времени. Позволяет не только описывать характеристики временного ряда, но и прогнозировать его будущие значения.
ИНТЕРПРЕТАЦИЯ
После применения выбранных методов необходимо интерпретировать полученные результаты и сделать выводы. Некоторые аспекты интерпретации:
- Учёт контекста. Результаты помещаются в более широкий контекст исследовательской области, например, рассматривается, насколько они соответствуют существующим знаниям или отклоняются от них.
- Обращение к гипотезам. Если исследование включало гипотезы или исследовательские вопросы, оценивается, подтверждают ли данные их или противоречат им.
- Признание ограничений. Важно обсудить, как ограничения могли повлиять на результаты и в какой степени они влияют на обобщаемость результатов.
- Изучение практических последствий. Помимо статистической значимости, изучаются практические последствия выводов: как они связаны с реальными сценариями или проблемой, которую стремилось решить исследование.
- Предложение направлений для будущих исследований. В духе научных исследований предлагаются направления для будущих исследований: какие вопросы возникли в результате выводов, какие области остаются неисследованными или требуют дальнейшего изучения.
Интерпретация должна быть чёткой, логичной и подкреплённой данными. Например, если анализ показывает, что увеличение рекламного бюджета на 10% приводит к росту продаж на 5%, это может стать основанием для принятия бизнес-решений.
Количество диаграмм, представленных для анализа, — не менее 3.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Описание организации-заказчика: структура, функции, бизнес-процессы.
Требования
Наименование и описание; организационная структура; описание услуг; диаграмма процессов «Как есть» с узкими местами.
Пример оформления
Главное: Описание организации, её структуры, услуг и бизнес-процессов с визуализацией.
Должно включать:
- Наименование и описание организации
- Организационная структура (схема подразделений)
- Описание услуг (параметры, цена)
- Диаграмма бизнес-процессов «Как есть» с выделением узких мест
Пример:
Транспортная компания: отделы логистики, клиентской службы, бухгалтерии. Услуга — междугородние перевозки (48 ч Москва–СПб, от 5000 руб).
Чтобы заполнить карточку, нужно взять актуальные сведения из ЕГРЮЛ и устава организации. Совет: указать все рабочие счета компании, если есть несколько адресов или разные виды налогообложения, это тоже лучше прописать.
Для ИП
В карточке предприятия для ИП указывают, например:
- полное и сокращённое наименование (ФИО или бренд, под которым работает предприниматель);
- ИНН, ОГРН и КПП;
- коды ОКВЭД, которые показывают виды деятельности;
- юридический и фактический адрес;
- данные о банке: БИК, корреспондентский и расчётный счёт;
- контактную информацию: телефон, адрес электронной почты;
- подпись и ФИО предпринимателя.
Если предприниматель работает с разными режимами налогообложения, это нужно указать.
Для ООО
Обычно карточка предприятия для ООО содержит:
- полное и сокращённое наименование компании;
- ИНН, КПП, ОГРН;
- коды ОКВЭД, отражающие виды деятельности;
- данные о руководителе: должность, ФИО и подпись;
- адрес — юридический и фактический;
- реквизиты банка: номер счёта, БИК, корреспондентский счёт;
- контактную информацию: личный или рабочий номер телефона, а также адрес электронной почты.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Ключевые сущности, потоки данных, информационные объекты предметной области.
Требования
По типу (клиенты, услуги, транзакции), по частоте, по уровню доступа, по жизненному циклу. Описание информационных потоков, источников данных.
Пример оформления
Главное: Выявление ключевых сущностей и их классификация по минимум 3 основаниям.
Должно включать:
- По типу данных (клиенты, услуги, транзакции, сотрудники)
- По частоте использования (ежедневные, еженедельные, архивные)
- По уровню доступа (публичные, внутренние, конфиденциальные)
- По жизненному циклу (активные, завершённые, отменённые)
Классификация — это система распределения объектов предметной области (товаров, клиентов, документов, процессов) по классам (группам, категориям) на основе общих признаков (критериев) и установления связей между этими классами.
В ИС классификация нужна для:
- Структурирования данных: чтобы информация не лежала в одной огромной «куче».
- Организации поиска: чтобы пользователь мог быстро найти объект по категории.
- Настройки логики: Разные классы объектов могут обрабатываться системой по-разному (разные налоги, разные статусы, разные права доступа).
2. Основные правила (Принципы) классификации
При разработке классификатора предметной области следует придерживаться четырёх классических правил теории классификации:
- Деление объектов на классы должно производиться только по одному существенному признаку на каждом уровне иерархии.
- Ошибка: Смешивать признаки. Например, делить людей на «Студенты, Женщины и Пенсионеры». Это пересекающиеся множества.
- Объём делимого понятия должен быть равен сумме объёмов полученных классов.
- Смысл: Классификация должна охватывать все объекты предметной области. Не должно быть объектов, «про которые мы забыли». Если есть объекты, не попавшие в группы, создаётся группа «Прочее» или «Другое», но её использование должно быть сведено к минимуму.
- Члены деления (классы) должны исключать друг друга. Объект может принадлежать только одному классу на данном уровне иерархии.
- Исключение: Фасетный метод (см. ниже) допускает множественную классификацию, но в рамках жёсткой иерархии это правило критично.
- При многоступенчатой классификации нужно переходить к ближайшему нижестоящему уровню, не перескакивая через него.
3. Методы классификации
В разработке ИС используются два основных метода, которые часто комбинируют:
А. Иерархический метод
Объекты делятся на соподчинённые группы (от общего к частному).
- Пример: Книги → Художественная литература → Романы → Исторические романы.
- Плюсы: наглядность, логичность, удобство для агрегации отчётов (свернуть/развернуть данные).
- Минусы: жёсткость структуры (сложно добавить новый признак, не предусмотренный изначально).
- Правила: Глубина вложенности не должна быть слишком большой (обычно 3–7 уровней, иначе система становится непонятной). На каждом уровне можно использовать только одно основание.
Б. Фасетный метод
Объекты описываются набором независимых параллельных группировок (фасетов/признаков). Каждый фасет содержит перечень значений.
- Пример: Один и тот же товар может быть одновременно «Импортным», «Элитным» и «Хрупким». Это не взаимоисключающие признаки.
- Плюсы: Гибкость, возможность поиска по любому сочетанию признаков (фильтры).
- Минусы: Не всегда удобно для построения жёсткой отчётной иерархии (структуры отделов).
- Правила: Взаимоисключение значений внутри одного фасета (в фасете «Цвет» не могут быть одновременно «Красный» и «Зелёный» для одного объекта, если это не разноцветный товар).
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Выявление проблем, «узких мест», ограничений существующих решений.
Требования
Интервью, наблюдение, анализ документооборота, определение узких мест. Список проблем с обоснованием.
Пример оформления
Главное: Выявление проблем в текущей модели работы («Как есть») и предложения по решению.
Должно включать:
- Интервью с сотрудниками
- Наблюдение за процессами
- Анализ документооборота
- Выявление узких мест и потерь времени
Пример:
В ресторане: дублирование данных (официант и кухня), задержки сменного отчёта до 2 ч, отсутствие учёта остатков — 15% потерь.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Функциональные и нефункциональные требования к разрабатываемой ИС.
Требования
Функциональные, интерфейсные, по безопасности, технические. Задачи для автоматизации (учёт, заказы, отчётность, интеграция). Структурированный перечень требований.
Пример оформления
Главное: Формализация требований в табличной форме и определение области автоматизации.
Должно включать:
- Функциональные требования
- Требования к интерфейсу и безопасности
- Технические требования
- Задачи для автоматизации (учёт, заказы, отчётность)
Пример:
Таблица: Категория | Требование | Приоритет. Пример: Функциональность — Онлайн-бронирование — Высокий.
| Категория | Требование | Приоритет |
|---|---|---|
| Функциональность | Онлайн-бронирование | Высокий |
| Безопасность | Ролевой доступ | Средний |
| Интерфейс | Адаптивность | Высокий |
Раздел 1. Функциональные требования (Что система должна ДЕЛАТЬ)
Это самый большой и важный блок. Здесь нужно разбить систему на модули.
Это сценарии использования. Нужно описать типичный путь пользователя.
Что уточнять: Как происходит регистрация? Кто создает заказ? Какие статусы у заказа? Что происходит, если товар закончился? Нужно проговорить шаги от начала до конца (End-to-End scenarios).
Что уточнять: Какие типы пользователей будут (Админ, Менеджер, Бухгалтер, Гость)? Кто какие кнопки видит? Кто может удалять отчеты, а кто только смотреть?
Здесь мы собираем «скелет»:
- Личный кабинет / Профили: Что там должно быть (аватар, история действий, настройки)?
- Каталог / Товары / Услуги: Как загружать товары? Нужны ли характеристики, фильтры, поиск?
- Корзина / Заказы / Сделки: Как считать стоимость? Нужна ли корзина? Как меняется статус?
- Платежи / Интеграции: Какие способы оплаты? Интеграция с 1С, CRM, сайтом, банком?
Что уточнять: Какие цифры нужны для управления бизнесом? (Выручка за день, остатки на складе, конверсия). В каком виде выгружать (Excel, PDF, графики)?
Раздел 2. Нефункциональные требования (Как система должна РАБОТАТЬ)
Это требования к качеству системы. Их часто забывают, а потом система тормозит или падает.
Что уточнять: Сколько человек одновременно будет работать в системе (в пике)? Как быстро должна открываться страница (2 секунды или 10)? Что происходит 1-го числа месяца, когда все сдают отчеты?
Что уточнять: Где хранить пароли? Нужно ли шифровать данные? Есть ли отдел безопасности у заказчика, который будет проверять? Нужна ли двухфакторная аутентификация?
Что уточнять: Есть ли ограничения по языкам программирования (только Python, только 1С)? На каких серверах ставить (Windows/Linux)? Есть ли готовые сервера или покупаем новые?
Раздел 3. Требования к интерфейсу (UX/UI)
Как система будет выглядеть.
Что уточнять: Это будет веб-сайт (сайт в браузере), десктопная программа (ставят на компьютер) или мобильное приложение?
Что уточнять: Есть ли брендбук, логотип, фирменные цвета? Нужен ли уникальный дизайн или можно взять готовую библиотеку компонентов (типа Bootstrap)? Показать примеры сайтов, которые нравятся и не нравятся.
Раздел 4. Технические требования (Интеграции и Данные)
Система редко живет в вакууме.
Что уточнять: С какими системами нужно обмениваться данными?
1С: Туда уходят заказы, оттуда приходят цены и остатки.
Сайт: Выгружать ли товары на сайт?
CRM: Забирать ли клиентов оттуда?
Почта/SMS: Нужно ли отправлять уведомления?
Что уточнять: Как переносить данные из старой системы в новую? В каком формате (Excel, XML)?
Раздел 5. Требования к внедрению и сопровождению
Как мы отдадим систему и что дальше.
Что уточнять: Кого учить? Нужно ли писать инструкцию (документацию)? Проводить ли вебинар для 100 человек?
Что уточнять: Кто чинит, если система сломается ночью? За какое время нужно починить? Как принимаем работу (составляем акт приемки)?
Итог: Что должно быть выявлено в ПЕРВУЮ ОЧЕРЕДЬ?
Чтобы не утонуть в деталях, на первой встрече с заказчиком нужно закрыть Топ-5:
- Цель: Зачем нам это? (Если цели нет — проект не нужен).
- Пользователи: Кто будет нажимать кнопки? (Если пользователи — старушки бухгалтеры, интерфейс должен быть огромным и простым, а не модным и плоским).
- Критический функционал: Без чего система не имеет смысла? (MVP — минимальный продукт).
- Смежные системы: С кем нужно подружить систему? (Особенно с 1С и банком — это самые сложные моменты).
- Бюджет/Сроки: Сколько денег? (Если бюджет 100 тыс. руб., а вы хотите нейросеть — вы зря теряете время).
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Предложенные решения по устранению выявленных проблем.
Требования
Анализ проблем, предложения по оптимизации, модель As To Be, оценка эффекта. Описание решений, обоснование.
Пример оформления
Главное: Моделирование улучшенных процессов («Как будет») после внедрения ИС.
Должно включать:
- Анализ выявленных проблемных мест
- Разработка предложений по оптимизации
- Функциональная модель As To Be
- Оценка ожидаемого эффекта
Пример:
После автоматизации: обработка заказа 15→3 мин, сменный отчёт 2 ч→2 мин, потери остатков 15%→3%.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Обоснование выбора направления автоматизации, вариантов реализации.
Требования
Соответствие требованиям, стоимость, сроки, масштабируемость, интеграция. Сравнение вариантов, аргументация.
Пример оформления
Главное: Определение оптимального способа автоматизации предприятия/подразделения.
Должно включать:
- Соответствие требованиям заказчика
- Стоимость внедрения и владения
- Сроки реализации
- Масштабирование и интеграция
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Обзор существующих аналогов (ПО, сервисов) на рынке.
Требования
Статистика применения, перечень систем, стоимостное сравнение. Сравнительная таблица, выводы.
Пример оформления
Главное: Исследование существующих решений, их стоимости и особенностей обслуживания.
Должно включать:
- Статистика применения решений в отрасли
- Обзор доступных на рынке систем
- Стоимостное сравнение
Пример:
Рестораны: R-Keeper (от 50 тыс.), iiko (от 70 тыс.), Poster (от 25 тыс.). 60% используют iiko.
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Перечень отчётов, которые должна формировать информационная система.
Требования
Финансовые, операционные, по персоналу, аналитические отчёты. Описание отчётов, структура данных.
Пример оформления
Главное: Определение форм и видов отчётности, которую должна генерировать система.
Должно включать:
- Финансовые: прибыль/убытки, движение средств
- Операционные: загрузка, заказы
- Персонал: время, эффективность
- Аналитические: тренды, прогнозы
Пример:
1) Ежедневный отчёт по выручке. 2) Отчёт по клиентской базе. 3) Остатки с расчётом закупки. 4) Эффективность сотрудников.
Общие требования к отчетам (для всех форматов)
Каждый сформированный отчет, независимо от целевого формата экспорта, должен строго соответствовать следующим правилам:
- Название отчета: Полное наименование отчета в соответствии с утвержденным регламентом или руководящим документом. Название должно быть уникальным в пределах сессии формирования и отражать суть содержимого (например, «Акт сверки взаиморасчетов №...», «Сводная ведомость...»).
- Дата формирования: Дата и время (с точностью до минут) генерации отчета системой. Формат даты должен соответствовать корпоративному стандарту (например, ДД.ММ.ГГГГ ЧЧ:ММ).
- Автор отчета: Идентификатор пользователя (логин, ФИО), инициировавшего генерацию отчета, или автоматическая отметка системы.
- Наличие тела: Отчет обязательно должен содержать содержательную часть (данные).
- Правильное форматирование: Данные должны быть структурированы. Не допускается «сырой» экспорт необработанных данных.
- Соответствие стандартам: Тело отчета должно быть представлено либо в виде строгой таблицы (с заголовками колонок, итоговыми строками), либо в соответствии с утвержденной формой (шаблоном), зафиксированной в руководящих документах организации или отраслевых стандартах (например, форма строгой отчетности, унифицированная форма первичной документации).
Требования к формату PDF
PDF является форматом для финального предоставления пользователю, печати и архивации.
- Автоматическая ориентация страниц (книжная или альбомная) должна выбираться в зависимости от ширины таблицы для удобства чтения.
- Возможность масштабирования содержимого по ширине листа при печати.
- Обязательное наличие сквозной нумерации страниц.
- При печати многостраничных таблиц заголовок таблицы (шапка) должен дублироваться на каждой новой странице.
- В колонтитулах (верхних или нижних) могут дублироваться название отчета или дата формирования для удобства идентификации при печати стопки листов.
Требования к формату Excel (XLSX)
Excel предназначен для дальнейшей аналитической обработки, доработки данных и фильтрации.
- Числовые данные должны экспортироваться как числа (формат Number или General), а не как текст. Это необходимо для возможности суммирования и вычислений.
- Даты должны экспортироваться как даты (формат Date), а не строки.
- Первая строка (или несколько строк) должна содержать названия колонок (заголовки таблицы). Они должны быть выделены жирным шрифтом и/или заливкой.
- Применение автофильтра к строке с заголовками для удобства пользователя.
- Ширина столбцов должна быть автоматически подобрана по содержимому.
- Лишнее объединение ячеек (кроме случаев утвержденных форм) не допускается, так как это мешает сортировке.
Требования к формату Word (DOCX)
Word используется для подготовки документов к отправке контрагентам, встраивания в пояснительные записки и формирования текстовых отчетов сложной структуры.
- Таблицы должны быть корректно встроены в документ.
- Для длинных таблиц, переходящих на следующую страницу, необходимо настроить повторение строки заголовка.
- Границы таблиц должны быть видны (если иное не предусмотрено формой документа).
Дополнительная информация
- Показать анализ предметной области
- Обосновать выбор технологий
- Привести диаграммы
Определение
Проектирование и реализация таблиц базы данных. Структура, связи, индексы.
Требования
Создание БД в СУБД, макет схемы данных, описание таблиц. Семантическая разметка, ARIA, адаптивность.
Пример оформления
Главное: Проектирование таблиц БД: схема данных, типы полей, связи, индексы. Семантика, ARIA при отображении.
Должно включать:
- Схема БД (ER или логическая)
- Описание каждой таблицы (назначение, поля, типы)
- Связи: один-ко-многим, многие-ко-многим
- Первичные и внешние ключи
- Индексы для поиска и сортировки
- Пример таблицы users: id, login, password_hash, email, role
Пример:
Таблица users: id (PK, INT), login (VARCHAR 50, UNIQUE), password_hash (VARCHAR 255), role (ENUM: admin, user). Связь users → orders (1:N).
РАЗРАБОТКА ТАБЛИЦ ИНФОРМАЦИОННОЙ СИСТЕМЫ
На данном этапе: 1) Создаётся база данных в СУБД; 2) Макет схемы данных; 3) Выводятся все таблицы с описанием.
- Анализ требований к данным
- Проектирование структуры таблицы (столбцы, типы данных)
- Реализация HTML-разметки
- Добавление CSS-стилей
- Тестирование на разных устройствах
- Оптимизация производительности
- Использование семантической разметки
- Поддержка доступности (ARIA-атрибуты)
- Адаптивный дизайн
- Кросс-браузерная совместимость
| ID | Имя | Фамилия | Роль | |
|---|---|---|---|---|
| 1 | Иван | Иванов | ivanov@example.com | Администратор |
| 2 | Петр | Петров | petrov@example.com | Пользователь |
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Написание запросов выборки, обновления, связывания данных.
Требования
Анализ требований, проектирование, написание SQL, тестирование, оптимизация, документирование. Защита от SQL-инъекций.
Пример оформления
Главное: Разработка SQL-запросов по этапам: анализ требований → проектирование → написание → тестирование → оптимизация.
Должно включать:
- Типы: SELECT (выборка), JOIN (связи), подзапросы
- Поиск, фильтрация, сортировка, пагинация
- INSERT, UPDATE, DELETE с проверками
- Защита от SQL-инъекций (параметризованные запросы)
- Документирование назначения запросов
Пример:
Запрос списка заказов пользователя: SELECT o.*, SUM(oi.qty * p.price) AS total FROM orders o JOIN order_items oi ... WHERE o.user_id = ? ORDER BY o.created_at DESC.
РАЗРАБОТКА ЗАПРОСОВ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Создание SQL-запросов, хранимых процедур и механизмов извлечения данных. Запросы должны быть оптимизированы, безопасны и соответствовать бизнес-требованиям.
- Анализ требований — изучение документации, интервью
- Проектирование структуры запросов
- Написание SQL-кода с учётом производительности
- Тестирование корректности и производительности
- Оптимизация (EXPLAIN, индексация)
- Документирование
- Внедрение в ИС
- Соответствие бизнес-логике
- Оптимальная производительность
- Защита от SQL-инъекций
- Читаемость и поддерживаемость кода
- Корректная обработка ошибок
SELECT u.id, u.name, u.email, COUNT(o.id) as order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name, u.email ORDER BY order_count DESC;
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Создание форм ввода, редактирования и просмотра данных.
Требования
Анализ требований → проектирование → HTML → стили → интерактивность → тестирование. Логин, пароль, валидация.
Пример оформления
Главное: Разработка форм: этапы — анализ требований → проектирование макета → HTML/CSS → интерактивность → тестирование.
Должно включать:
- Макет формы (wireframe)
- Элементы: поля ввода, выпадающие списки, чекбоксы
- Валидация на клиенте и сервере
- Пример формы входа: логин, пароль, «Запомнить меня», «Забыли пароль?»
Пример:
Форма входа: поле «Логин» (обязательное), поле «Пароль» (скрытое), чекбокс «Запомнить меня», кнопка «Войти», ссылка «Забыли пароль?». Сообщения об ошибках под полями.
РАЗРАБОТКА ФОРМ
Алгоритм разработки формы входа и других форм системы.
- Определение полей (логин, пароль)
- Дополнительные функции
- Требования безопасности
- Создание макета
- Цветовая схема
- Состояния элементов
- Контейнер формы
- Поля ввода
- Вспомогательные элементы
- Оформление контейнера и полей
- Адаптивный дизайн
- Валидация на клиенте и сервере
- Эффекты наведения, обратная связь
- Кросс-браузерность
- Разные устройства
- Валидация кода
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Определение
Формирование отчётов: структура, источники данных, оформление.
Требования
Регламентные, оперативные, аналитические отчёты. Требования, проектирование, извлечение данных, визуализация, PDF/Excel.
Пример оформления
Главное: Отчёты: регламентные (периодические), оперативные (по запросу), аналитические (анализ данных).
Должно включать:
- Регламентные: ежедневные, еженедельные, ежемесячные
- Оперативные: на дату, по параметрам
- Аналитические: тренды, сравнения, прогнозы
- Требования: источник данных, формат (PDF, Excel), визуализация
Пример:
Отчёт по продажам: период, группировка по товарам/категориям, сумма, количество. Экспорт в Excel. Аналитический: динамика выручки за 12 мес, диаграмма.
РАЗРАБОТКА ОТЧЁТОВ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Отчёты служат для анализа данных, принятия управленческих решений и контроля за процессами.
- Регламентные (периодически по расписанию)
- Оперативные (по требованию пользователя)
- Аналитические (сложные вычисления и агрегации)
- Регламентированные (по стандартам и нормам)
- Определение требований
- Проектирование макета, источников данных
- Извлечение данных (SQL и др.)
- Обработка: фильтрация, сортировка, группировка
- Визуализация (таблицы, графики)
- Тестирование
- Внедрение и сопровождение
- Корректность данных
- Производительность
- Удобство восприятия
- Гибкость (фильтры, параметры)
- Безопасность доступа
- Форматы вывода (PDF, Excel, HTML)
Дополнительная информация
- Описать разработку по этапам
- Привести скриншоты интерфейса
- Отразить тестирование
Выберите главу в левом меню для просмотра деталей.
ОСНОВНОЙ РАЗДЕЛ
Содержит три главы: 1 — Описание предметной области (1.1–1.7), 2 — Разработка ИС (2.1–2.5), 3 — Охрана труда (3.1–3.4).