С точки зрения разработчика, проектирование это последовательное разделение общих концепций, на более мелкие модули. Получившиеся модули разделяются на более мелкие, и так далее. Пока не получится объектная модель, реализация которой приведет к написанию работоспособного программного кода.
В предыдущей статье описывался предварительный этап, который на прямую не относился к проектированию, но позволял сделать самые первые шаги к проекту, и по возможности избежать типовых ошибок. Текущая статья описывает первый этап проектирования, предназначенный для уточнений требований заказчика и описания рамок проекта.
Под рамками проекта подразумевается перечень функциональных возможностей которые будут реализованы в текущей итерации.
Заказчики подходят к разработке программного обеспечения как к проектной деятельности, то есть, его интересуют только два параметра, время за которое он получит работоспособный продукт и бюджет. Даже если программа разрабатывается в рамках одной крупной организации, где разработчики являются ее структурным подразделением.
Из-за специфики разработки программного обеспечения невозможно представить заказчику полную реализацию поэтапно. В других отраслях, промежуточные этапы легко актуализировать. Например, просто посмотреть как и на какой стадии находится строительство здания или как идет сборка автомобиля.
Поэтому начальный этап проектирования так важен. На этом этапе заказчик и разработчик проверяют соответствует ли заявленный объем работ оцененному времени и стоимости проекта. Ошибки допущенные на этом этапе одинаково болезненны для обоих сторон. Довольно часто встречаются ситуации, когда проектировщики ошибаются в своих начальных оценках. В дальнейшем, эти проблемы переходят в компетенцию менеджеров проектов и в конце концов ложатся на плечи разработчиков в виде авралов и переработок.
Стало плохой традицией спрашивать у рядового разработчика, за какой период он выполнит ту или иную задачу и на основании этих данных, строить дальнейшие планы. Рядовые разработчики, даже имеющие достаточный опыт в разработке, склонны допускать ошибки. В результате это приводит к не соблюдению сроков проекта или выходу за рамки бюджета. Никакие современные методики управления проектами не способны исправить ошибки неправильного проектирования.
Существует формально описанный процесс разработки программного обеспечения, созданный компанией Rational Software (ныне часть IBM). Rational Unified Process (RUP) основан на лучших практиках индустрии и широко используется в разработке сложных программных продуктов.
Акцент делается именно на сложных программных продуктах, однако такой подход достаточно очевиден по своей сути, и его можно рассматривать как свободное переложение общих правил проектирования на сферу IT.
Не будем рассматривать все аспекты RUP, остановимся только на сводной диаграмме объединившей стадии исполнения проекта, рабочие процессы и распределение затрат при реализации. В рамках статьи рассмотрим только первые три рабочих процесса.
Бизнес-моделирование. Очевидно, что построение модели бизнеса выполняется в самом начале проекта, построенная модель является основой для построения будущей программы. Но разработчики часто упускают, что модель является только устаревшим «снимком» с бизнеса заказчика. Почему устаревшим? Да потому, что такая модель строится на устоявшихся представлениях. Автоматизация показывает, в каких местах можно упростить бизнес-процессы.
Проекты всегда открывают новые возможности и помогают заказчикам взглянуть на свой бизнес с другой стороны. Это вносит изменения в перечень требований, и в ходе разработки и внедрения возникают противоречия. Заказчик выдвигает новые требования, иногда противоречащие изначальным, и в таких ситуациях менеджер проектов вынужден вставать на сторону заказчика, дабы привести к успешному завершению проекта. В результате, приходится вносить изменения «на ходу», а это отрицательно сказывается на качестве программного обеспечения, и что важнее, влияет на сроки и стоимость проекта.
Следовательно, задача группы проектирования состоит не только в описании бизнес-процессов, а и к ограничению требований заказчика. Очевидно, что даже самые лучшие проектировщики не в состоянии предсказать будущее, поэтому результаты проектирования должны показать заказчику рамки проекта. Проектная группа должна иметь возможность предоставить менеджеру проекта инструменты для управлением требованиями. Красная фигура с диаграммы должна соответствовать реальному проекту. Нельзя допускать ее расширения на конечных этапах.
Управление требованиями. Как и говорилось выше, управление требованиями заключается в том, чтобы заказчик ясно понимал какие его требования выходят за рамки проекта. Используя эти же знания, менеджер проекта будет иметь поле для переговоров. В некоторых местах идя на уступки, а в принципиальных, требовать дополнительного времени или оплаты.
Как следует из диаграммы, вторая фигура имеет боле сложный рельеф. Она может меняться после каждой итерации. Каждая из таких итераций подразумевает собой предъявление готовой части заказчику, в полном соответствии с принципами Minimal Viable Product (MVP) минимально жизнеспособный продукт. Знакомясь с функционалом, заказчик на ранних стадиях, корректирует свои требования, а разработчик получает инструменты управления этими требованиями. Стараясь удовлетворить их на ранних этапах, снижая нагрузку на более поздние этапы.
Анализ и проектирование. Это основной этап команды участвующей в проектировании. Команда должна быть готова к меняющемуся от итерации к итерации списку требований, а следовательно, проектировать программный продукт таким образом, чтобы избежать существенных изменений, в ходе выполнения проекта. На данном этапе, помогает создание модульной структуры приложения и использование паттернов проектирования.
Теперь, когда с описательной частью покончено, перейдем непосредственно к первому этапу проектирования. В данной статье проектирование будет выполняться с помощью языка моделирования UML, но это не значит, что такой подход «самый правильный». На самом деле нет никакой разницы как будет описан проект, существует множество возможностей выразить суть проекта, начиная от обычного текста, и до 3D моделирования. Цель проектирования одна, сделать описание максимально доступным и понятным, как заказчику, так и команде разработчика.
Помимо того, что UML отвечает этим требованиям, диаграммы распределены таким образом, что с их помощью можно поэтапно проиллюстрировать все этапы проектирования, от начальных до сугубо технических.
Проектирование начинается с Диаграммы Прецедентов (англ. Use Case Diagram). Эта диаграмма имеет два устоявшихся наименования. Основное, более академичное, и Диаграмма Вариантов Использования, на мой взгляд лучше отражающее содержание.
Правила построения диаграммы и ее элементы вы можете посмотреть самостоятельно, во множестве источников, в данной статье мы остановимся только на содержательной части. Хотелось бы напомнить, что в описательной части статьи был сделан акцент на следующих аспектах проектирования:
- определение рамок проекта,
- управление требованиями,
- разделение на модули.
Изучение содержания диаграммы лучше начать с разбора уже составленных. На просторах всемирной сети была найдена диаграмма интернет магазина. Количество ошибок в ней такое, что скорее всего эта диаграмма была отрицательным примером при обучении, используем ее так же.
Красными овалами выделены ошибки допущенные при проектировании, давайте их рассмотрим.
- Здесь показана одна из самых распространенных ошибок при составлении диаграммы. Добавление второстепенного или технического функционала. Диаграмма Прецедентов самая первая в очереди проектных документов, а следовательно и ближайшая к бизнес-процессам. Возникает вопрос, как регистрация пользователя влияет на бизнес заказчика? Другими словами, регистрация приносит доход заказчику? Нет? Так зачем вообще такое включать в диаграмму.
- Указание функционала вне проектируемого программного обеспечения. Разработчик не бизнес аналитик, нам не надо брать ответственность за то, что происходит вне продукта. Для наших целей достаточно знать, что будет покупатель, и с ним мы будем взаимодействовать.
- Неоправданное усложнение проекта. В диаграмме указана необходимость работы с платежами. Зачем? Платежи это повышенные требования к безопасности, криптография и прочее. Всегда найдется банк который предоставит свои API для работы с платежами. Возможно, автор диаграммы неудачно выразил свою мысль, но тогда необходимо быть очень внимательным, ведь заказчик может понять такую запись буквально.
- Избыточная детализация. Заказчик знаком с продажами понимает, что список товаров может изменяться, как и список заказов. Так для кого необходима такая детализация? Все тонкости можно описать в последующих диаграммах.
- Указание на неполный или вырванный из контекста функционал.
- Добавление товара в корзину. А что происходило до этого, а что будет происходить после? Может лучше назвать, стратегия продаж?
- Поиск товара. Это какой поиск? Как он будет использован? В какой момент? Не лучше ли было, использовать понятие повышение конверсии через поиск товара. Согласитесь, такие формулировки меняют все.
В завершении статьи создадим Диаграмму Прецедентов для нашего сквозного примера, библиотеки электронных книг для обучения и научной работы.
В предыдущей статье, на основании маркетинговых исследований мы установили, что пользоваться нашей библиотекой будут всего три группы пользователей. Это и есть субъекты (Actor) нашей диаграммы.
Читатель. Пользователь, который может выбрать книгу включенную в состав библиотеки и при необходимости, в ходе изучения, цитировать текст и включить в текст свои комментарии. Цитаты и комментарии к книге объединяются в конспект.
Библиотекарь. Пользователь, который следит за достоверностью и актуальностью каталога книг и при необходимости проводит его реорганизацию.
Администратор библиотеки. Пользователь, который может дублировать работу библиотекаря и добавлять новые книги и удалять контент по запросу других пользователей.
Исходя из поставленной цели проекта мы можем сформировать список прецедентов (Use Case), или вариантов использования, или функционала, кому как удобнее.
Конспект. Набор данных объединяющих информацию о книге, месте цитирования, месте комментирования и содержание комментария. Думаю, из контекста понятно, что цитата, это не цитата в ее классическом виде, а просто ссылка на место в источнике, то есть в книге. Первая нормальная форма (1NF) в реляционной модели данных.
Каталог книг. Набор данных с описанием книг, организованных для упрощения их поиска. Велик соблазн, в этом пункте представить как будет организован каталог. Однако этого делать не следует, так как возможно, что в ходе проектирования или разработки будет предложен другой вариант. Лучше проектировать как отдельный модуль, черный ящик, от которого не зависит остальной функционал. Такой подход и является воплощением концепции управления требованиями.
Статистика. Этот прецедент можно было бы и исключить. При автоматизации существующего бизнеса проще понять, какие данные будут использованы для последующего анализа. Каждое предприятие накапливает свой портфель отчетной информации, мы же строим приложение с нуля и не знаем какая аналитика нам понадобится. Поэтому не отбрасываем ни каких вариантов. Будем хранить все что доступно, а формы вывода статистических данных оформим в виде отдельных модулей, которые сможем подключить позже.
Административные функции. На данном этапе проектирования к административным функциям отнесены возможности добавления новых книг и удаления контента.
Мы пока не знаем что из себя будет представлять функция добавления книг. Обычно, книги представлены в виде единицы хранения данных. Файла. Но файлы могут иметь различные форматы, и для онлайн чтения не все они подходят. Ведь нет необходимости загружать книгу целиком, достаточно показать текущий фрагмент.
Удаление контента тоже не простая задача, в реляционной модели данных любой контент может иметь несколько ссылок и на него можно ссылаться из множества мест. Следовательно, проще пометить его как удаленный и оставить в покое, но при активном использовании это может превратиться в проблему переполнения. Тогда появится необходимость в инструментах для корректной очистки хранилища.
Учитывая все это, на данном этапе, мы не можем точно определить, какие именно административные функции следует проектировать. Отложим эту проблему на последующие этапы. Возможно добавим дополнительные функции, а может оставим все как есть, или с возможностью подключения модулей.
Ранее мы определили ряд аспектов проектирования относящихся к этой диаграмме. Посмотрим, как с помощью Диаграммы Прецедентов реализовать их.
Определение рамок проекта. Теперь диаграмму можно показывать заказчику. Она проста в понимании и не перегружена техническими особенностями. Её можно вставить в презентацию, расширить комментариями к каждому элементу, или дополнить текстом, как это сделано в статье. Цель одна, довести до заказчика, что функционал включенный в диаграмму входит в рамки проекта. Все остальное является дополнительными требованиями.
Например, в ходе реализации и первых показах функционала, заказчик захочет дополнить проект, системой обмена сообщениями между читателем и библиотекарем. Что вполне логично. Всегда можно сослаться на эту диаграмму и обоснованно доказать, что это является дополнительным объемом работ, который должен быть дополнительно оценен.
А если менеджер проекта проследил за бюрократическим оформлением, то такие документы могут быть представлены и в качестве доказательства при юридических спорах.
Управление требованиями. Данная диаграмма, в последующем, детализируется другими диаграммами, каждая из которых все детальнее описывает объем работ, тем самым уменьшая область неопределенности в проекте. Полностью, эту неопределенность искоренить невозможно. Поэтому и появляется возможность управления требованиями.
Например. Заказчику, в дополнение к каталогу книг понадобился алфавитный указатель. Это когда все упоминания понятий в тексте перечислены в указателе в виде ссылок на страницы, где это понятие упоминается. Что-то вроде хештега, только более строгое. Формально это не упоминается в проекте, но и не выходит за рамки понятия каталога книг. К тому же, это не сложно реализовать. Та самая серая зона.
Менеджер проекта имеет возможность «торга», вы увеличиваете время на N дней, а мы реализуем этот функционал, и тому подобное.
Разделение на модули. Здесь, все очевидно, разделение на отдельные варианты использования, само по себе обеспечивает модульность подхода. На следующем этапе, каждый из описанных прецедентов рассматривается как отдельный модуль или как группа модулей, если это необходимо.
Автор: Юрий Е. - 2025 г.