Лк3. Разработка и оформление конструкторской документации

1. Разработка и оформление конструкторской документации

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

2. Стадии разработки конструкторской документации

в рамках единой
системы
конструкторской
документации
(ГОСТ 2.103-68)

3. Пять стадий разработки конструкторской документации в рамках единой системы конструкторской документации

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

4. ГОСТ 2.103-2013

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

5.

ГОСТ 19.101-77 ЕСПД. Виды программ и программных
документов
ГОСТ 19.102-77 ЕСПД. Стадии разработки
ГОСТ 19.103-77 ЕСПД. Обозначение программ и
программных документов

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

7. Конструкторская документация

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

8. Этапы разработки конструкторской документации

Этап 1: Подготовка технического задания
Определение целей проекта
Анализ требований заказчика
Формирование структуры будущего приложения
Подготовка качественного технического задания включает четкую постановку
целей, глубокий анализ требований заказчика и продуманную структуру
будущего приложения. Это залог успешного завершения проекта и
удовлетворенности всех участников процесса.

9. Этапы разработки конструкторской документации

Этап 2: Проектирование архитектуры программы
Разработка структурных схем
Создание диаграмм классов и компонентов
Детализация модулей и функций

10. Этапы разработки конструкторской документации

Этап 3: Документирование процесса разработки
Написание инструкций по установке и настройке
Составление руководства пользователя
Оформление отчетов о тестировании

11. Требования к разработке документации

Четкость изложения материала
Структурированность текста
Логичность и последовательность изложения
Использование общепринятых стандартов оформления (например
ГОСТ)

12. Примеры документов

Техническое задание (ТЗ)
Основные цели и задачи проекта
Перечень функциональных возможностей системы
Спецификация оборудования и ПО

13. Основные цели и задачи проекта

Цель проекта — основной ожидаемый итог работ, выраженный в достижении
конкретных результатов. Цель должна быть сформулирована чётко и
однозначно
Примеры правильно поставленной цели:
Повышение
производительности отдела продаж путём автоматизации
обработки заказов
Улучшение качества обслуживания клиентов за счёт интеграции CRMсистемы с телефонией

14. Основные цели и задачи проекта

Задачи проекта — конкретные шаги и мероприятия, необходимые для
достижения поставленной цели. Они должны быть реалистичными,
измеримыми и выполнимыми.
Примеры задач проекта:
Создать модуль импорта заказов из Excel-файлов;
Реализовать интеграцию корпоративной почтовой службы с системой
аналитики клиентских запросов.

15. Пример: Описание сервиса

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

16. Перечень функциональных возможностей системы

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

17. Пример: Описание функциональных требования

В каталоге должно храниться актуальное доступное для заказа количество
товарных позиций, то есть сочетаний модели, цвета и размера
Для каждого сочетания цвета и модели в каталоге должно сохраняться
изображение. При формировании заказа пользователь может просмотреть
изображение футболки с выбранными параметрами
Должна быть возможность выбрать принт из перечня доступных принтов. Не
все принты могут размещаться на футболках определенного цвета и/или
размера, поэтому в каталоге должна сохраняться информация о сочетаемости
товарных позиций футболок с различными принтами.
У пользователя должна быть возможность выбрать из каталога одну или
несколько футболок доступного размера, цвета, модели и либо выбрать свой
собственный принт для каждой из них, либо выбрать один принт для всех
выбранных товарных позиций.

18. Как составить перечень функциональных возможностей

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

19. Спецификация оборудования и ПО

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

20. Спецификация оборудования и ПО

• Программная спецификация
Определяются минимальные и рекомендуемые версии операционных
систем, баз данных, библиотек и прочих инструментов, необходимых для
установки и функционирования программного обеспечения.
Пример раздела программной спецификации:
Операционная система: Windows Server 2019 или Linux Ubuntu 20.04 LTS.
СУБД: PostgreSQL 12.x или MySQL 8.x.
Язык программирования: Python 3.8+.

21. Этапы разработки конструкторской документации

Этап 2: Проектирование архитектуры программы
Разработка структурных схем
Создание диаграмм классов и компонентов
Детализация модулей и функций

22. Понятие архитектуры

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

23. Проектирование архитектуры программы

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

24. Проектирование архитектуры

В Архитектуре приложений, как правило, выделяют три основных
уровня управления, характеризуемых используемыми инструментами:
Карта приложений (АС)
Реестр приложений (АС)
Архитектура АС (Software Architecture)

25. Карта приложений

Карта приложений (АС) — это инструмент, позволяющий анализировать
зрелость ИТ в организации (текущее состояние — As Is), планировать
целевое состояние (To Be) и управлять изменениями (план перехода —
Road map)
Карта в своих координатах отражает бизнес-компетенции (по
вертикали), организационные единицы (по горизонтали), а на пересечении
– АС, в которых реализуются бизнес-компетенции компании. Важным
применением такого инструмента считается оценка соответствия
стратегии утверждённым решениям или корпоративным стандартам.
Традиционно в легенде такой карты выделяют несколько цветов:
Синий цвет - общекорпоративный продукт, который реализован на
платформе и удовлетворяет стандартам
Зелёный цвет - локальное решение, реализованное не на платформе, но
удовлетворяющее стандартам
Жёлтый цвет - локальное решение, реализованное не на платформе и не
удовлетворяющее стандартам
Красный цвет - функция не автоматизирована или автоматизирована
неудовлетворительно — информационная система не удовлетворяет
стандартам
Серый цвет - нет необходимости в автоматизации функции
Белый цвет - нет информации об автоматизации бизнес-компетенции

26. Реестр приложений

Реестр АС содержит
более подробные
характеристики
каждой системы

27. Архитектура АС

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

28. Проектирование архитектуры программы

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

29. Проектирование архитектуры программы

Разработка структурных схем
Структурные схемы представляют собой визуальное отображение
основных компонент системы и связей между ними. Это начальная стадия
проектирования, позволяющая определить высокоуровневую организацию
программы
Примеры: UML-диаграммы, ER-модели баз данных

30. Разработка структурных схем. Пример модели бизнес-процесса оформления заказа футболок с принтом

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

31. Разработка структурных схем. Пример логической модели

32. Проектирование архитектуры программы

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

33. Пример диаграммы классов

34. Проектирование архитектуры программы

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

35. Проектирование архитектуры программы

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

36. Виды масштабирования системы

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

37. Этапы разработки конструкторской документации

Этап 3: Документирование процесса разработки
Написание инструкций по установке и настройке
Составление руководства пользователя
Оформление отчетов о тестировании

38. Документирование процесса разработки Примеры документов

Руководство пользователя
Инструкция по запуску и работе с приложением
Информация о поддерживаемых устройствах и операционных системах
Ответы на часто задаваемые вопросы
Обеспечение прозрачности и понимания процессов
- Поддержка коммуникаций внутри команды
- Контроль качества и регламентация действий
- Возможность передачи знаний новым сотрудникам
- Соответствие стандартам и требованиям заказчиков

39. Этапы разработки документации программного продукта

1.
Техническое задание (ТЗ) / Product Requirements Document
(PRD)
2.
Техническое предложение / Эскизный проект
(Feasibility Study)
3.
Технический проект / Системный проект (System
Design)
4.
Спецификация требований к программному
обеспечению (Software Requirements Specification - SRS)
5.
Рабочая проектная документация (Detailed Design)
6.
Эксплуатационная документация (User Documentation)
Техническое Задание
↓
Технический проект
↓
Спецификация требований
↓
Рабочая документация
↓
Эксплуатационная документация