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

• Название: Основы проектирования корпоративных систем
• Автор: Сергей Зыков
• Жанр: Управление, подбор персонала
• Год: 2012
• ISBN: 978-5-7598-0862-6

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

Для студентов, аспирантов и исследователей, а также специалистов-практиков, область интересов которых связана с разработкой крупномасштабных программных систем.

---

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

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

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

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

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

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

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