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

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

Если говорить подробнее об экономике ЖЦ программного продукта, то нужно сказать, что он проходит целый ряд стадий и эти стадии вносят различный вклад в прибыль и динамику продаж. И если на стадии создания и вывода на рынок проект преимущественно находится в минусе по прибылям, то после вывода на рынок, когда наблюдается рост и зрелость, прибыль становится положительной. В период зрелости, как правило, прибыль имеет отрицательный прирост, но положительное значение. В районе упадка наблюдается уже существенное падение и невысокое значение как прибыли, так и продаж с точки зрения их динамики. Все это характерно как для коробочного продукта, когда речь идет о количестве инсталляций, так и в случае, когда взаимодействие осуществляется с конкретным заказчиком, с учетом всех классов пользователей продукта.

Можно рассмотреть более подробно экономику ЖЦ на основе сопоставления критериев развития, скорости роста бизнеса и доли рынка, которую занимает программный продукт. Здесь, в начале пути, нужны инвестиции, поскольку неизвестно о дальнейшей судьбе программного продукта. Затем программный продукт выходит на рынок, приносит доход и, наконец, прибыль, и это без существенных затрат на поддержку продаж. Через некоторое время наступает этап, когда доходы относительно невысоки и продажи влекут за собой существенные затраты.

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

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

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