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

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

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

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

Процитируем В.А. Липаева – патриарха отечественной программной инженерии. В книге «Программная инженерия» он привел следующее определение: «Под программной инженерией понимается комплекс задач, методов, средств и технологий создания, то есть проектирования и реализации сложных, расширяемых, тиражируемых, высококачественных программных систем, возможно включающих базы данных»[2]. Каждое слово в этом определении в полной мере применимо к корпоративным системам.

Согласно определению Липаева эта отрасль науки как раз и направлена на создание корпоративных информационных систем. И ввиду того, что они являются сложными, т. е. содержат большое количество первичных сущностей, большими по объему (тера-, петабайты данных) и расширяемыми, как правило, речь не идет о том, что мы революционным образом сразу заменяем все системы, которые используются в корпоративном программном комплексе. Чаще всего производится доработка какой-то отдельной системы. Они являются высококачественными и часто тиражируемыми.

Некоторые из примеров таких решений – Microsoft Dynamics, Oracle Applications и т. д. Под высоким качеством понимается и масштабируемость – плавное снижение производительности при достаточно резком увеличении интенсивности нагрузки на систему. Кроме того, нужно сказать, что эти системы должны быть надежными, вести себя предсказуемо, быть эргономичными, сопровождаемыми, т. е. должны быть настроены на то, чтобы обеспечивать достаточно гибкое и относительно эволюционное взаимодействие с пользователем на этапе опытной и промышленной эксплуатации. В определении также речь идет о проектировании и реализации, т. е. уже о полном жизненном цикле ПО. Важным дополнением является то, что информационные системы включают в ряде случаев базы данных. Если мы говорим о корпоративных системах, базы данных, как правило, являются неотъемлемой, важной частью этих систем. Другое дело, что эти базы данных могут строиться на различных принципах, являться гетерогенными, включать объектные составляющие, т. е. быть не чисто реляционными. Последние версии СУБД Oracle называются объектно-реляционными. Есть СУБД нового поколения, такие как O2, Orion и др., которые используют не только реляционные, но и другие, более новые объектно-ориентированные модели.

В корпоративных информационных системах необходимо разделять понятия программного проекта и программного продукта. В настоящем издании речь пойдет в основном о программных продуктах, т. е. о взгляде на ЖЦ с точки зрения системного архитектора. А с точки зрения программного проекта – это взгляд менеджера проектов, когда речь идет об управлении проектной командой, проектами, взаимодействием людей в проекте, сроками, стоимостью. С другой стороны, если говорить о программной инженерии, то речь может идти о разработке продукта для конкретного заказчика, но преимущественно и предпочтительно планировать все процессы и технологии, связанные с разработкой таким образом, чтобы по возможности обеспечить производство продукта, нацеленного на более широкую аудиторию потребителей, а в идеале сделать его коробочным или тиражируемым. Целесообразно обеспечить высокий процент повторного многократного использования элементов проекта – это и код, и документация, и структура СУБД, и программная архитектура, с тем чтобы при доработке проекта для «похожего» заказчика было затрачено минимум времени, средств и людских ресурсов.

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

Чем характеризуется программный продукт? Во-первых, как правило, он имеет определенную коммерческую ценность. Это значит не то, что не существует условно бесплатных программных продуктов, а что этот продукт решает конкретную задачу конкретного класса пользователей, потребителей продукта. Таким образом, продукт может называться рыночным и быть предложен рынку для удовлетворения его определенных потребностей и решения конкретных бизнес-задач. Какие примеры программного продукта можно привести? Часто это физические объекты, скажем, информационные носители (DVD, CD и т. д.), но это могут быть и нематериальные соглашения, такие как лицензия, соглашение о партнерстве и пр. Еще одним примером может выступать услуга по внедрению, сопровождению, консалтингу и т. д.

Программные продукты можно классифицировать по разным основаниям. Один из видов классификации – масштаб использования: это и личное использование, и некоммерческое, и коммерческое как коробочный продукт для широкого класса организаций и предприятий. Другой способ классификации – цель использования. Это может быть специализированное ПО, нацеленное на решение достаточно узкой задачи, например расчетное ПО для решения астрономических задач, лазерной дальнометрии, или ПО более общего назначения, такое как операционная система, офисные продукты и т. п. Еще один вид классификации – степень открытости. При этом можно говорить о компонентной ориентированности, скажем, API, библиотеки, такие как, например, библиотека классов Enterprise Libraries, которая используется для надстройки над. NET для построения Microsoft-продуктов корпоративного типа, библиотека классов для построения офисных приложений и т. д. или готовые продукты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующая стадия – подготовка проектных спецификаций. Она происходит на основе описания требований, т. е. тех документов, которые получены на предыдущей стадии ЖЦ. Эта и следующие стадии являются в основном прерогативой разработчика. Хотя в ряде методологий проектирования и реализаций программных комплексов, таких гибких, как Agile, X P, Scrum, заказчик участвует на всех этапах ЖЦ ПО. Для больших корпоративных систем, как правило, разработка ведется по методологиям RUP или MSF, и там основным действующим лицом является разработчик. Проектные спецификации содержат описания всей функциональности проекта и всех основных ограничений, желательно выраженных количественно. Здесь уже можно ограничить и программное обеспечение, и технологии, которые будут использованы, и архитектуру (например, сделать выбор между платформами Java или. NET). Необходимо четко ограничить количество одновременных пользователей, количество подключений, транзакций и их интенсивность, пропускную способность канала и ряд других параметров. При этом методологию или модель разработки ПО – каскадную, эволюционную, спиральную или иную – следует выбрать как можно раньше, поскольку выбор методологии или модели ЖЦ определяющим образом сказывается на сроках, стоимости и успехах проекта. Проектные спецификации должны ограничивать сроки и стоимость проекта исходя из договоренностей, которые достигли разработчик и заказчик на предыдущем этапе.

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

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

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

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

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

С точки зрения экономики сопровождение – самый затратный этап ЖЦ (порядка ²/₃ стоимости всего проекта) как по времени, так и по средствам. Нужно понимать, что сопровождение необходимо для любого ПО. Цель при разработке – не просто передача программного продукта заказчику, а продолжение продуктивных отношений с этим заказчиком. Задачами сопровождения программного продукта являются ликвидация ошибок, которые остались в программном продукте, коррекция проектных спецификаций, улучшение производительности и учет особенностей новой программной и аппаратной среды заказчика, если таковые имеются. Сопровождение включает следующие виды:

• корректирующее сопровождение (устранение существующих в продукте ошибок без изменения проектных спецификаций);

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

• адаптивное сопровождение (адаптация продукта к новой программно-аппаратной среде).

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

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

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

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

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

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