Сергей Зыков - Основы проектирования корпоративных систем

При разговоре о ЖЦ необходимо сделать ряд важных замечаний. Прежде всего, нужно сказать, что процесс ЖЦ как создания, так и смены стадий ПО включает целый ряд сторон. Как минимум, это представители заказчика, представители разработчика и руководство. При этом представители заказчика – те, кто будут принимать продукт, во многом технически грамотные люди. В итоге они входят в группу контроля качества программного продукта. Со стороны разработчика – это весьма широкий спектр специалистов: аналитики, оценщики рисков, проектировщики, системные архитекторы, документаторы, программисты, тестировщики, специалисты по созданию приемочных тестов, специалисты по сопровождению. И руководство, которое разделяется, например, как в MSF, на руководителя проекта и руководителя продукта. То есть у руководства тоже различные цели, не говоря уже о том, что у руководства заказчиков и руководства разработчика они во многом расходятся.

У этих разных сторон зачастую совершенно различные цели и ожидания от продукта, от того, какую функциональность он должен реализовывать, и от проектных ограничений и по срокам, и по стоимости, и по функциональности и даже различное понимание определенных терминов и особенностей. Ведь заказчик смотрит на процесс производства ПО, достаточно хорошо понимая свои производственные потребности, но он может не вполне владеть особенностями производства ПО, которые приняты у разработчиков. И в этой связи даже разумные взгляды, подходы и отношения к ЖЦ, к тем требованиям и ограничениям, которые имеются у заказчика и разработчика и различных представителей заказчика и разработчика на различных уровнях, могут приводить к значительному увеличению сроков и стоимости проекта. Большое значение имеет согласование этих подходов между разработчиком и заказчиком: нужно прийти к некоему общему пониманию, прежде всего ограничений проекта. И надо помнить, что заказчик тут стремится ограничить проект снизу, заявить о том, что количество пользователей не может быть меньше, чем некое число, и т. д. А разработчик должен прийти к соглашению с заказчиком (к юридическому документу, техническому заданию, списку-требованию или какому-то иному документу). Разработчик при этом стремится ограничить проект сверху (количество пользователей, пропускная способность), т. е. показать, что технологии, которые используются, и бюджет, который заложен в проект, не могут обеспечить производительность более установленного предела.

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

Какой же целью задаются разработчики? Главная цель – это создать хороший продукт. (Что такое «хороший», будет расшифрованно далее, а также какие именно факторы разработки ПО должны в первую очередь приниматься во внимание.)

Следует напомнить, что производство ПО представляет собой многофакторную оптимизацию, поскольку, по сути, разработчикам необходимо согласовывать с заказчиком некий взгляд и набор требований к проекту. Это будет основным сырьем, по которому будет создаваться программный продукт, включающий документацию. При этом выход по программному обеспечению может быть множественным, потому как очень часто приходится сталкиваться с ситуацией, когда существует огромное количество вариаций кода, которое решает поставленные перед разработчиком задачи. При этом, если говорить о ЖЦ ПО, следует нужным, предсказуемым и правильным образом с точки зрения сроков, стоимости и функциональности обеспечить выбор методологии этого ЖЦ. Необходимо показать, каким образом будут меняться фазы и сколько раз, сколько итераций нужно будет для того, чтобы получить продукт должной функциональности, сложности и качества. При этом производится многомерная, многофакторная оптимизация, которая учитывает прежде всего следующие параметры: сроки выполнения проекта, стоимость продукта, качество продукта как по документации, так и по коду. Качество документации можно отслеживать трассировкой документации, сопоставлением артефактов, или элементов документации, на внутреннюю корректность, на соответствие друг другу, на полноту, на непротиворечивость, на целостность и на соответствие исходной постановке задачи. Также важным фактором оптимизации является сопровождаемость – обеспечение сокращений затрат на самую ресурсоемкую часть ЖЦ продукта. Важно сказать, что приоритетность факторов не жестко детерминирована, а во многом определяется характером и масштабом программного проекта. О каких масштабах имеет смысл говорить в отношении корпоративных программных систем? Для малых систем масштаб условно можно ограничивать 10 человеко-годами, для средних систем – 10–100, для больших – 100–1000 человеко-лет. Несколько тысяч – это уже огромные системы. Корпоративные системы – скорее от 100 человеко-лет и выше. То есть это весьма большие затраты, но это не означает, что не нужно искать возможности для экономии. Конечно, это нужно делать, и в первую очередь можно сэкономить гораздо существеннее на внедрении корпоративного приложения.