Тех раз

1. Основные этапы работы по созданию программного продукта

ОСНОВНЫЕ ЭТАПЫ РАБОТЫ
ПО СОЗДАНИЮ
ПРОГРАММНОГО ПРОДУКТА

2. Введение

■ Создание программного продукта – это сложный и
многоэтапный процесс, требующий четкой
организации и системного подхода. Для того чтобы
продукт получился качественным, удобным и
соответствовал ожиданиям заказчика,
разработчики следуют определённым стадиям
жизненного цикла разработки программного
обеспечения.

3. Планирование и анализ требований

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

4. Основные задачи этапа

■ Изучение предметной области
понимание специфики бизнеса заказчика;
выявление текущих проблем, которые должен решить будущий продукт;
анализ существующих решений и их недостатков.

5. Основные задачи этапа

■ Сбор требований
проведение интервью с заказчиком и будущими пользователями;
анализ документации предприятия или бизнес-процессов;
использование анкетирования, наблюдений, анализа статистики;
фиксация пожеланий, даже если они кажутся противоречивыми.

6. Основные задачи этапа

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

7. Основные задачи этапа

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

8. Основные задачи этапа

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

9. Основные задачи этапа

■ Оценка рисков
возможные технические сложности;
вероятность изменения требований в процессе разработки;
зависимость от сторонних сервисов и технологий.

10. Результаты этапа

■ Подробное Техническое задание (ТЗ), где описано:
– цели и задачи продукта,
– функциональные и нефункциональные требования,
– условия эксплуатации,
– ограничения и критерии успешности.
■ План проекта: сроки, ресурсы, предварительная смета.
■ Согласованные ожидания заказчика и команды разработки.

11. Значимость этапа

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

12. Методы и инструменты

■ Диаграммы UML для визуализации требований;
■ Use-case диаграммы (сценарии использования системы);
■ Agile User Stories («как пользователь, я хочу …, чтобы …»);
■ Прототипирование (создание макетов интерфейсов для проверки идей);
■ Метод SWOT-анализа (сильные и слабые стороны, возможности, угрозы проекта).

13. Пример из практики

■ Представим, что создаётся CRM-система для автосалона.
На этапе анализа требований нужно выяснить:
■ Какие задачи должна решать система? (ведение клиентской базы, учёт
автомобилей, отслеживание сделок).
■ Кто будет работать с системой? (менеджеры по продажам, бухгалтер,
администратор).
■ Какие функции обязательны, а какие – дополнительные? (обязательное: учёт
клиентов, дополнительное: аналитические отчёты).
■ Какие ограничения есть? (бюджет, поддержка только Windows или также
мобильных устройств).

14. Задание

■
Задание
Шаги выполнения
■
Определите цель продукта.
–
Для чего нужна система?
–
Какую проблему она должна решить?
■
Опишите пользователей (роли).
–
Кто будет работать с системой?
–
Какие у них задачи?
■
Составьте список функциональных требований.
Примеры:
–
регистрация и авторизация пользователей;
–
учёт студентов и преподавателей;
–
расписание занятий;
–
отчёты и статистика.
■
Определите нефункциональные требования.
Примеры:
–
удобный интерфейс;
–
поддержка работы в браузере и на телефоне;
–
безопасность данных;
–
скорость отклика системы не более 2 секунд.
■
Определите ограничения.
–
бюджет (например, ограниченные ресурсы);
–
сроки (например, система должна быть готова за 4 месяца);
–
технические (например, только Windows или кроссплатформенность).

15. Пример оформления

Категория
Пример требований
Цель продукта
Автоматизация учёта студентов и занятий в
колледже
Пользователи
Администратор, преподаватель, студент
Функциональные
1. Ведение базы студентов
2. Составление расписания
3. Просмотр оценок
Нефункциональные
Удобный интерфейс, работа через браузер,
защита паролем
Ограничения
Разработка за 3 месяца, работа только в
локальной сети колледжа

16. Проектирование (дизайн системы)

■ Общая характеристика
■ Этап проектирования начинается после того, как требования к системе собраны
и согласованы с заказчиком.
Здесь разработчики и аналитики превращают требования в техническое
решение, формируя архитектуру будущего продукта.
Именно на этом этапе создаётся модель системы, которая определяет, как будут
связаны между собой её компоненты.

17. Основные задачи этапа

■ Разработка архитектуры системы
■ выбор архитектурного стиля (монолит, клиент-сервер, микросервисы,
многослойная архитектура);
■ определение основных модулей программы и их взаимодействия;
■ выбор технологий и инструментов (например, C# + ASP.NET + PostgreSQL).

18. Основные задачи этапа

■ Проектирование структуры базы данных
■ выделение основных сущностей (например: Пользователь, Клиент, Заказ, Товар);
■ определение связей между таблицами (один-ко-многим, многие-ко-многим);
■ создание ER-диаграмм (диаграмм сущностей и связей);
■ определение ограничений (уникальность, обязательность полей и т.д.).

19. Основные задачи этапа

■ Определение интерфейсов между модулями
■ описание API (какие данные передаются между компонентами);
■ проектирование REST API или gRPC-сервисов;
■ определение протоколов обмена (JSON, XML, бинарные форматы).

20. Основные задачи этапа

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

21. Результаты этапа

■ Архитектурная схема системы (например, диаграммы UML или блок-схемы).
■ Модель базы данных (ER-диаграмма, SQL-скрипты для создания таблиц).
■ Описание API (спецификация REST, OpenAPI/Swagger).
■ Прототипы интерфейса (например, в Figma, Balsamiq или в виде набросков на
бумаге).
■ Документация по проектированию, где зафиксировано устройство системы.

22. Значимость этапа

■ закладывается фундамент всей системы;
■ на основе архитектуры определяется сложность разработки и масштабируемость
продукта;
■ качественное проектирование уменьшает количество ошибок на стадии
кодирования;
■ хорошо продуманная база данных и интерфейс ускоряют работу команды и
делают систему удобной для пользователей.

23. Методы и инструменты

■ UML-диаграммы (диаграмма классов, диаграмма компонентов, диаграмма
последовательности).
■ ER-диаграммы (Entity-Relationship).
■ CASE-средства для моделирования (Enterprise Architect, draw.io, Visual Paradigm).
■ Прототипирование интерфейсов в Figma, Adobe XD, Balsamiq.

24. Пример из практики

■ Предположим, заказчику нужна CRM-система для автосалона.
■ Архитектура: многослойная (UI – бизнес-логика – база данных).
■ Сущности в базе: Клиенты, Автомобили, Сделки, Сотрудники.
■ Интерфейсы между модулями: REST API для связи веб-интерфейса и сервера.
■ Прототип интерфейса:
– форма для добавления клиента,
– список автомобилей,
– карточка сделки с кнопкой "Закрыть продажу".

25.

■ Проектирование – это переход от
абстрактных требований к конкретной
структуре будущей системы. Чем лучше
выполнено проектирование, тем легче
будет реализация, а конечный продукт
получится надёжным и удобным.

26. Реализация (кодирование)

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

27. Основные задачи этапа

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

28. Основные задачи этапа

■ Использование языков программирования и инструментов
■ выбор технологий определяется на этапе проектирования;
■ используются фреймворки (например, ASP.NET Core, Spring, Django) для
ускорения разработки;
■ применяются библиотеки, чтобы не писать всё "с нуля".

29. Основные задачи этапа

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

30. Основные задачи этапа

■ Документирование кода
■ добавление комментариев и описание логики работы функций;
■ создание документации для разработчиков и будущих сопровождающих;
■ оформление API-документации (например, Swagger, OpenAPI).

31. Результаты этапа

■ Рабочий исходный код программы.
■ Скомпилированное или развернутое приложение (альфа- или бета-версия).
■ Документация коду и интерфейсам.
■ Набор автоматизированных тестов для проверки модулей.

32. Значимость этапа

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

33. Практики и подходы

■ Code Review (проверка кода коллегами) – помогает улучшить качество и выявить
ошибки;
■ Версионный контроль (Git, GitHub, GitLab) – позволяет команде работать над
одним проектом;
■ Модульное тестирование – проверка отдельных частей программы на раннем
этапе;
■ Непрерывная интеграция (CI/CD) – автоматическая сборка и тестирование при
каждом изменении кода;
■ Стандарты кодирования – единый стиль кода для всей команды.

34. Методы и инструменты

■ Среды разработки (IDE): Visual Studio, IntelliJ IDEA, PyCharm, Eclipse.
■ Системы контроля версий: Git, Subversion.
■ Системы сборки: Maven, Gradle, MSBuild.
■ Инструменты CI/CD: Jenkins, GitHub Actions, GitLab CI.
■ Средства документирования: Swagger, Javadoc, Doxygen.

35. Пример из практики

■ Создаётся CRM-система для автосалона.
■ Один разработчик пишет модуль "Клиенты" (регистрация, хранение данных,
поиск).
■ Другой отвечает за модуль "Автомобили" (характеристики, цены, наличие).
■ Третий занимается API для обмена данными между фронтендом и сервером.
■ Все модули объединяются через REST API и проверяются на корректность
работы.
■ Код хранится в GitHub, перед слиянием в основную ветку проводится code
review.

36. Тестирование и отладка

■ Общая характеристика
■ Этап тестирования и отладки начинается после реализации (кодирования) и
интеграции системы. Его цель — проверить, что продукт работает корректно,
безопасно и соответствует требованиям заказчика.
■ Этот этап позволяет выявить и устранить ошибки до передачи продукта
пользователю, что снижает затраты на исправления и повышает надёжность
системы.

37. Основные задачи этапа

■ Функциональное тестирование
■ проверка всех функций системы на соответствие требованиям;
■ тестируются отдельные модули и их взаимодействие;
■ примеры: регистрация пользователя, авторизация, создание заказа, расчёт
стоимости.

38. Основные задачи этапа

■ Нефункциональное тестирование
■ проверка параметров качества:
– производительность (время отклика, нагрузка на систему),
– надёжность (устойчивость к сбоям),
– безопасность (защита данных, работа с паролями),
– удобство интерфейса (UX).

39. Основные задачи этапа

■ Поиск и устранение ошибок (отладка)
■ воспроизведение найденных багов;
■ локализация причины в коде;
■ исправление и повторная проверка.

40. Основные задачи этапа

■ Проверка соответствия требованиям заказчика
■ тестирование проводится на основе технического задания и пользовательских
сценариев;
■ заказчик может участвовать в приёмочном тестировании (acceptance testing).

41. Результаты этапа

■ Отчёты о тестировании (список найденных ошибок, статус исправления).
■ Исправленный и стабильный программный продукт.
■ Подтверждение, что система готова к внедрению.

42. Значимость этапа

■ предотвращает выпуск "сырого" продукта;
■ снижает риск отказов в реальной эксплуатации;
■ повышает доверие заказчика и пользователей;
■ экономит ресурсы: исправление ошибки на стадии тестирования в десятки раз
дешевле, чем в эксплуатации.

43. Виды тестирования

•Модульное (unit testing) – проверка отдельных функций
и классов.
•Интеграционное – проверка взаимодействия модулей.
•Системное – проверка всей системы в целом.
•Регрессионное – проверка, что исправление багов не
сломало старый функционал.
•Нагрузочное – проверка работы под большим
количеством пользователей.
•Приёмочное (acceptance testing) – проверка, что
продукт соответствует ожиданиям заказчика.

44. Инструменты тестирования

■ JUnit, NUnit, xUnit – модульное тестирование.
■ Selenium – автоматизация тестирования веб-интерфейсов.
■ Postman – тестирование API.
■ JMeter, Locust – нагрузочное тестирование.
■ Bug-tracking системы: Jira, Redmine, Trello.

45. Пример из практики

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

46. Внедрение (развертывание)

■ Общая характеристика
■ Этап внедрения (развертывания) — это стадия, когда программный продукт после
разработки и тестирования передаётся заказчику и вводится в эксплуатацию.
Здесь разработчики не просто устанавливают программу, но и обеспечивают её
адаптацию под конкретные условия работы организации, а также обучают
пользователей.

47. Основные задачи этапа

■ Установка программного обеспечения
■ перенос системы из тестовой среды в рабочую (production);
■ установка серверов, баз данных, клиентских приложений;
■ настройка интеграции с другими системами (например, бухгалтерией, CRM).

48. Основные задачи этапа

■ Настройка системы и адаптация под условия эксплуатации
■ конфигурирование параметров (язык, валюта, права пользователей);
■ перенос данных из старых систем (миграция данных);
■ оптимизация работы под нагрузку реальных пользователей.

49. Основные задачи этапа

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

50. Основные задачи этапа

■ Подготовка документации
■ для администраторов: руководство по установке, настройке, резервному
копированию;
■ для пользователей: инструкции по работе с системой, описание интерфейса;
■ для разработчиков: документация API и архитектуры (если планируется
доработка).

51. Результаты этапа

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

52. Значимость этапа

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

53. Варианты внедрения

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

54. Инструменты и методы

■ CI/CD системы (GitLab CI, Jenkins, Azure DevOps) для автоматического
развертывания.
■ Docker и Kubernetes для управления контейнерами и масштабируемостью.
■ Системы миграции данных (ETL-процессы, скрипты переноса).
■ Системы мониторинга (Grafana, Zabbix) для отслеживания состояния системы
после запуска.

55. Пример из практики

■
Представим внедрение CRM-системы для автосалона:
■
Установлена серверная часть системы на локальный сервер автосалона.
■
Настроены базы данных и создано несколько ролей пользователей: администратор, менеджер,
бухгалтер.
■
Проведена миграция данных из Excel-таблиц в новую систему.
■
Менеджерам проведено обучение: как регистрировать клиентов, оформлять сделки,
формировать отчёты.
■
Подготовлена документация:
– "Краткая инструкция для менеджеров";
– "Руководство администратора системы".
■
В течение первого месяца внедрение сопровождалось поддержкой команды разработчиков.

56. Сопровождение и поддержка

■ Общая характеристика
■ Этап сопровождения начинается после внедрения системы и продолжается весь
период эксплуатации программного продукта.
Здесь разработчики и техническая поддержка следят за тем, чтобы программа
работала исправно, обновлялась и соответствовала новым требованиям бизнеса
и пользователей.
■ Можно сказать, что именно сопровождение обеспечивает «жизнь» продукта
после его запуска.

57. Основные задачи этапа

■ Устранение ошибок (поддержка)
■ исправление багов, выявленных пользователями в процессе работы;
■ решение проблем, которые не удалось обнаружить на этапе тестирования;
■ выпуск «патчей» (небольших обновлений для исправления ошибок).

58. Основные задачи этапа

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

59. Основные задачи этапа

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

60. Основные задачи этапа

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

61. Результаты этапа

■ Рабочая и актуальная версия программного продукта.
■ Удовлетворённые пользователи, которые понимают, что система развивается.
■ Уменьшение рисков отказа системы и потери данных.
■ Повышение конкурентоспособности продукта на рынке.

62. Значимость этапа

■ без регулярного обновления продукт устаревает и перестаёт быть полезным;
■ именно на этом этапе устраняются проблемы, которые в реальных условиях
выявляются только при эксплуатации;
■ сопровождение повышает доверие заказчика — он видит, что система «жива» и
развивается;
■ конкурентоспособность напрямую зависит от уровня поддержки (например,
пользователи выбирают продукт, где быстрее помогают и выпускают
обновления).

63. Виды сопровождения

■ Корректирующее – исправление ошибок, выявленных в процессе эксплуатации.
■ Адаптивное – подстройка системы под новые условия (ОС, оборудование,
законы).
■ Совершенствующее – добавление новых функций, повышение удобства и
скорости работы.
■ Превентивное – профилактические меры, предотвращение будущих проблем
(оптимизация кода, обновление библиотек).

64. Инструменты и методы

■ Системы баг-трекинга: Jira, Redmine, YouTrack, Trello.
■ Системы обновлений: автоматическая установка патчей, CI/CD.
■ Мониторинг системы: Zabbix, Grafana, Prometheus.
■ Поддержка пользователей: Service Desk, HelpDesk.

65. Пример из практики

■ Возьмём CRM-систему для автосалона.
■ Через месяц после внедрения менеджеры пожаловались, что поиск клиентов
работает медленно → разработчики оптимизировали базу данных.
■ Через полгода появились новые требования: добавить интеграцию с сервисом
рассылки SMS → был выпущен обновлённый модуль.
■ Через год изменились налоговые правила → пришлось обновить модуль
бухгалтерии.
■ В процессе эксплуатации периодически выпускались патчи для исправления
мелких багов.

66. Жизненный цикл программного продукта

■ Жизненный цикл программного продукта — это последовательность этапов, через
которые проходит программа от идеи до полноценной эксплуатации. Он включает
шесть ключевых шагов:

67. Жизненный цикл программного продукта

■ Планирование и анализ требований – здесь определяется, что именно нужно
создать. От точности сбора требований зависит, будет ли конечный продукт
решать задачи заказчика. Ошибки на этом этапе могут привести к тому, что всё
остальное окажется напрасным.

68. Жизненный цикл программного продукта

■ Проектирование (дизайн системы) – на основе собранных требований создаётся
архитектура будущего продукта: схема базы данных, модули, интерфейсы,
прототипы. Этот этап формирует «каркас», на котором строится весь проект.

69. Жизненный цикл программного продукта

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

70. Жизненный цикл программного продукта

■ Тестирование и отладка – программа проверяется на соответствие требованиям.
Исправляются ошибки, оцениваются производительность, безопасность и
надёжность. Тщательное тестирование позволяет избежать серьёзных проблем в
будущем.

71. Жизненный цикл программного продукта

■ Внедрение (развертывание) – система передаётся заказчику, устанавливается в
рабочую среду, проводится настройка, миграция данных и обучение
пользователей. Это момент, когда программа начинает работать в реальных
условиях.

72. Жизненный цикл программного продукта

■ Сопровождение и поддержка – этап, который продолжается на протяжении всего
жизненного цикла продукта. Сюда входит исправление ошибок, выпуск
обновлений, адаптация под новые требования и помощь пользователям. Именно
сопровождение делает систему «живой» и актуальной.

73. Значение грамотной организации жизненного цикла

■ Каждый этап играет свою роль, и пропустить или «сэкономить» на каком-то шаге
невозможно без ущерба для качества продукта.
■ Если плохо проанализировать требования — продукт окажется ненужным.
■ Если не продумать архитектуру — система будет нестабильной.
■ Если пренебречь тестированием — пользователи столкнутся с множеством ошибок.
■ Если забыть о сопровождении — продукт быстро устареет.
■ Только целостный подход и грамотная организация всех этапов обеспечивают:
■ востребованность продукта на рынке,
■ удобство работы пользователей,
■ надёжность и долгосрочную актуальность системы.

74.

■ Итог: Жизненный цикл программного продукта — это не просто формальная
последовательность шагов, а практическая модель создания качественного ПО.
Следуя ей, можно добиться того, чтобы программа не только заработала, но и
приносила пользу в течение многих лет