- -
- 100%
- +
2.5 Схема жизненного цикла больших программных комплексов по В. В. Липаеву
Владимир Васильевич Липаев является одним из основателей отечественной школы программной инженерии. В его работах жизненный цикл крупных программных комплексов рассматривается как сложный, повторяющийся и управляемый процесс, включающий не только первоначальную разработку, но и длительную эксплуатацию, сопровождение и модернизацию. Схема жизненного цикла больших программных комплексов по В. В. Липаеву создавалась с учетом особенностей крупных систем, разработка которых требует участия коллективов специалистов, значительных ресурсов, формального управления, документирования, испытаний и длительного сопровождения. Липаев подчеркивал различие между небольшими программами, которые могут создаваться одним разработчиком, и крупными программными комплексами. Большой программный комплекс имеет множество компонентов, высокую стоимость, длительный срок эксплуатации, существенные требования к надежности и сложные связи с внешними системами. Для него необходимы регламентированные процессы, управление конфигурацией, документирование и независимый контроль качества. В обобщенном виде схема включает системный анализ, проектирование и разработку, внедрение и эксплуатацию, а также сопровождение и модернизацию. Между этими частями существуют обратные связи, позволяющие исправлять локальные ошибки, пересматривать архитектуру и при необходимости начинать новый цикл системного анализа. Первой крупной областью является системный анализ. Он начинается с постановки задачи и изучения объекта, в котором предполагается использовать информационную систему. Анализируется текущее состояние организации, действующие процессы, информационные потребности, недостатки существующей системы и причины необходимости автоматизации. В ходе системного анализа определяется, какие цели должна обеспечивать будущая система, какие функции подлежат автоматизации, какие ограничения существуют и какой эффект предполагается получить. Например, при анализе деятельности склада изучаются порядок приема товаров, размещение, инвентаризация, комплектование заказов, выдача, возвраты и взаимодействие с бухгалтерией. Выявляются задержки, дублирование данных и ошибки ручного учета. На основе выявленных проблем формируется потребность в новой системе и выполняется технико-экономическое обоснование. Необходимо определить, даст ли автоматизация достаточный результат и соответствует ли предполагаемая стоимость ожидаемому эффекту. Далее выбирается направление совершенствования объекта. Может быть принято решение разработать новую систему, приобрести готовый программный продукт, модернизировать существующую систему или изменить организацию процессов. Фаза системного анализа завершается формированием и утверждением технического задания. Техническое задание связывает потребности организации с последующим проектированием. Оно определяет назначение, функции, требования, ограничения, состав работ и порядок приемки. Второй крупной областью является проектирование и разработка системы. На основе технического задания формируется функциональная архитектура, то есть состав функций, задач и функциональных подсистем. Функциональная архитектура отвечает на вопрос, какие виды деятельности должна поддерживать система. Например, в складской системе выделяются приемка, размещение, хранение, комплектование, отгрузка, инвентаризация и отчетность. После функциональной архитектуры разрабатывается системная архитектура. Она определяет состав программных, информационных, технических и организационных компонентов, а также связи между ними. На этом уровне устанавливается, какие функции реализуются программными модулями, какие данные хранятся в базе, какие устройства применяются, как осуществляется сетевое взаимодействие и какие обязанности выполняет персонал. Затем выполняется физическое проектирование и конструирование: разрабатываются программы, базы данных, инструкции, средства взаимодействия и другие компоненты. Результатом становится программное изделие или программный комплекс, подготовленный для испытаний и внедрения. Третья область включает опытное внедрение и ввод в промышленную эксплуатацию. В ходе опытного внедрения проверяется работоспособность отдельных элементов и связей, выявляются локальные ошибки и уточняются технические решения. Если обнаруживается ошибка в конкретном программном компоненте, выполняется возврат к его разработке и исправлению. После устранения дефектов опытное внедрение повторяется. На следующем уровне проверяется система в целом. Оценивается соответствие функций требованиям заказчика, правильность взаимодействия подсистем, качество обработки данных и готовность к реальной эксплуатации. Если выясняется, что состав функций системы не соответствует деятельности организации, локального исправления программы недостаточно. Требуется возврат к функциональной архитектуре и повторное прохождение части проектных работ. После приемки начинается промышленная эксплуатация. Система используется по назначению, а разработчики и сопровождающая организация получают сведения о ее поведении в реальной среде. Эксплуатация является источником фактической информации о нагрузке, удобстве, надежности, ошибках и соответствии системы потребностям. Некоторые проблемы невозможно полностью выявить в лабораторных испытаниях, поскольку они проявляются только при длительной работе, большом объеме данных или участии множества пользователей. Четвертой областью является сопровождение. В процессе сопровождения анализируются сообщения пользователей, устраняются дефекты, адаптируется программное обеспечение, расширяются функции и совершенствуются характеристики. Если требуется небольшое изменение, оно выполняется на уровне программного компонента. Если изменяются функции, выполняется возврат к функциональному проектированию. Если изменяется техническая платформа или общий способ организации системы, пересматривается системная архитектура. В схеме выделяется несколько характерных циклов обратной связи. Первый охватывает весь путь от системного анализа до сопровождения и представляет собой цикл первоначального создания системы. Второй цикл возникает после опытного внедрения, когда выявляются частные ошибки элементов проекта. Исправление выполняется на уровне реализации, после чего опытное внедрение повторяется. Третий цикл возникает при выявлении после приемки ошибок функциональной архитектуры. В этом случае необходимо вернуться к определению состава подсистем, задач и связей между ними. Четвертый цикл возникает, когда новые условия требуют изменения системной архитектуры. Например, система должна быть перенесена на новую техническую платформу, объединена с другими системами или переведена на распределенное выполнение. Пятый, наиболее глубокий цикл возникает при моральном устаревании системы или полном несоответствии новым потребностям. Тогда требуется возвращение к постановке задачи и выполнение нового системного анализа. В учебных изложениях схема Липаева представляется как последовательность двенадцати взаимосвязанных блоков, объединяющих анализ объекта, обоснование автоматизации, техническое задание, функциональную и системную архитектуру, реализацию, опытное внедрение, исправление ошибок, промышленное внедрение, эксплуатацию и сопровождение. Главной особенностью схемы является не количество блоков, а наличие обратных связей разной глубины. Принципиально важной характеристикой является повторяемость последовательности «системный анализ — разработка — сопровождение — новый системный анализ». Информационная система рассматривается как динамический объект, который должен изменяться вместе с организацией и внешней средой. Например, первоначально информационная система банка может обслуживать только отделения. Затем появляется необходимость мобильного обслуживания. Если архитектура допускает развитие, создаются новые компоненты и интерфейсы. Если старая архитектура принципиально не поддерживает требуемый масштаб и безопасность, начинается новый цикл системного анализа и проектирования. Схема Липаева занимает промежуточное положение между строгой каскадной моделью и современными эволюционными подходами. В ней сохраняется последовательность основных фаз, но признается неизбежность возвратов и длительного развития системы.
2.6 Спиральная модель жизненного цикла информационных систем
Спиральная модель представляет собой итерационную модель жизненного цикла, в которой разработка организуется в виде последовательных циклов, а выбор содержания каждого цикла определяется анализом целей, альтернатив и рисков. Классическая спиральная модель была сформулирована Барри Боэмом. Ее принципиальным отличием является ориентация на риски. Каждому витку спирали соответствует очередное уточнение системы, а перед выполнением значительных работ анализируются неопределенности и возможные потери. Графически развитие изображается как движение от центра по расширяющейся спирали. Начальные витки связаны с концепцией, требованиями и проверкой принципиальной реализуемости. Последующие витки приводят к созданию архитектуры, прототипов, компонентов, версий и готовой системы. Расстояние от центра условно может отражать накопленные затраты или степень завершенности проекта. Угловое положение соответствует прохождению определенных видов деятельности внутри итерации. Каждый виток обычно включает четыре взаимосвязанные области: определение целей, альтернатив и ограничений; анализ и снижение рисков; разработку и проверку очередного результата; планирование следующего витка. В первой области определяются цели итерации. Например, целью может быть проверка возможности обработки десяти тысяч запросов в секунду, уточнение требований пользователей или создание базовой архитектуры. Одновременно рассматриваются альтернативы. Для хранения данных можно использовать централизованную реляционную базу, распределенное хранилище или сочетание нескольких технологий. Для каждой альтернативы определяются ограничения по стоимости, срокам, безопасности и квалификации команды. Во второй области выполняется анализ рисков. Риск представляет собой неопределенное событие или условие, способное отрицательно повлиять на проект или систему. К техническим рискам относятся недостаточная производительность, сложность интеграции, отсутствие совместимости, ошибки безопасности и неподтвержденная масштабируемость. К организационным рискам относятся недостаточная квалификация участников, слабое взаимодействие с заказчиком, изменение руководства и отсутствие владельца требований. К экономическим рискам относятся превышение бюджета, изменение стоимости лицензий, недостаточная эффективность и потеря финансирования. К рискам требований относятся неполнота, противоречивость, нестабильность и различное понимание потребностей участниками. После выявления риска выбирается способ его снижения. Это может быть создание прототипа, проведение эксперимента, моделирование, дополнительное обследование, приобретение экспертной консультации или разработка альтернативного решения. Например, если существует риск, что новая база данных не обеспечит требуемую производительность, создается экспериментальный стенд и проводится нагрузочное тестирование. Не требуется сначала разрабатывать всю систему. Если пользователи не могут определить требования к интерфейсу, создается интерактивный прототип. Пользователи оценивают его и уточняют свои ожидания. Если существует риск интеграции с внешней платежной системой, в ранней итерации разрабатывается пробный интеграционный компонент и проверяется взаимодействие. В третьей области создается результат итерации. В зависимости от стадии это может быть концепция, модель, прототип, архитектура, программный компонент или готовая версия системы. Затем результат проверяется. Выполняются техническая оценка, тестирование, демонстрация заинтересованным сторонам и анализ достигнутых целей. В четвертой области планируется следующий виток. Уточняются требования, определяется содержание работ, оцениваются ресурсы, сроки и новые риски. Заказчик или руководство принимает решение о продолжении, изменении направления или прекращении проекта. Таким образом, спиральная модель включает регулярные точки принятия решений. Проект может быть остановлен после раннего витка, если выясняется, что система технически невозможна, экономически нецелесообразна или не нужна пользователям. Это является преимуществом по сравнению с моделью, в которой значительные ресурсы расходуются до получения информации о критических рисках. Спиральная модель не означает простого многократного повторения программирования. Итерация начинается с целей и анализа риска. Если проект не содержит значительного риска в определенной области, соответствующие работы могут быть сокращены. Главным достоинством модели является раннее выявление критических проблем. Наиболее опасные вопросы рассматриваются до вложения основной части ресурсов. Другим преимуществом является постепенное уточнение требований. Пользователи могут оценивать прототипы и промежуточные версии, поэтому требования формируются на основе практического опыта. Спиральная модель поддерживает эволюционное развитие архитектуры. Архитектурные решения проверяются экспериментально и уточняются на следующих витках. Модель допускает использование разных способов разработки на разных витках. Для хорошо определенной части системы может применяться каскадная последовательность, а для неопределенной части — прототипирование. Например, в проекте медицинской системы правила хранения документов могут быть строго определены нормативными требованиями и проектироваться последовательно. Пользовательский интерфейс врача может уточняться через прототипы, а алгоритм интеллектуальной поддержки решений — через эксперименты. К недостаткам спиральной модели относится сложность управления. Необходимо уметь выявлять, оценивать и контролировать риски. Если риск-анализ выполняется формально, модель теряет свое основное преимущество. Другим недостатком является сложность первоначального планирования окончательных сроков и стоимости. Поскольку содержание последующих витков зависит от результатов предыдущих, точный план всего проекта может быть неизвестен. Спиральная модель требует участия квалифицированных архитекторов, аналитиков и специалистов по управлению рисками. Небольшая команда может не располагать такими ресурсами. Существует опасность бесконечного совершенствования, когда каждый виток порождает новые требования, а критерии завершения системы остаются неопределенными. Поэтому необходимо устанавливать цели продукта, границы проекта и условия приемки. Модель может быть избыточной для небольших, хорошо понятных проектов с низким риском. Разработка простой внутренней формы учета не требует полноценного риск-ориентированного спирального процесса. Особенно оправдано применение спиральной модели при создании крупных, дорогостоящих, инновационных и технически сложных систем, где неудачное архитектурное решение может привести к значительным потерям. Примером может служить разработка распределенной системы управления транспортом. На первом витке уточняется концепция и проверяется возможность получения данных от транспортных средств. На втором создается прототип сбора и отображения данных. На третьем проверяется масштабирование. На четвертом разрабатываются функции управления маршрутами. На последующих витках повышаются безопасность, надежность и полнота функций. В результате каждого витка существует проверяемый результат и новая информация, снижающая неопределенность.
2.7 Сравнение каскадной, поэтапной и спиральной моделей
Каскадная модель ориентирована на последовательное выполнение заранее определенных стадий. Основным механизмом управления является план и утверждение результатов. Поэтапная модель с промежуточным контролем также сохраняет стадийность, но вводит обратные связи, экспертизы и корректировки. Основным механизмом повышения качества является ранняя проверка промежуточных результатов. Спиральная модель строится вокруг повторяющихся циклов и управления рисками. Основным механизмом выбора работ является анализ неопределенности и возможных потерь. В каскадной модели требования предполагаются относительно стабильными. В поэтапной модели допускается их уточнение при обнаружении несоответствий. В спиральной модели постепенное уточнение требований является естественной частью процесса. В каскадной модели работающая система появляется преимущественно в конце. В модели с промежуточным контролем могут создаваться проверочные макеты, но конечный продукт также обычно передается после завершения основных стадий. В спиральной модели прототипы и версии появляются на отдельных витках. Каскадная модель удобнее для жесткого договорного планирования. Спиральная лучше работает при высокой неопределенности, но требует более гибкого управления бюджетом и содержанием проекта. Ни одна модель не является универсально лучшей. Выбор зависит от устойчивости требований, масштаба системы, критичности, технологической новизны, договорных отношений, квалификации команды и необходимости ранней поставки результата.
2.8 Эволюция моделей жизненного цикла информационных систем
Эволюция моделей жизненного цикла отражает развитие программной инженерии и постепенное изменение представлений о создании информационных систем. Основными причинами эволюции стали рост сложности программных комплексов, нестабильность требований, увеличение стоимости ошибок, необходимость быстрого выпуска продуктов и тесного взаимодействия с пользователями. На раннем этапе программирования широко использовался подход, который условно называется «кодирование и исправление». Разработчик начинал писать программу после общего понимания задачи, затем проверял ее, исправлял ошибки и добавлял функции. Для небольших программ такой способ мог быть приемлем. Однако при увеличении размера системы возникали проблемы: отсутствовала общая архитектура, изменения нарушали ранее созданные функции, сроки невозможно было оценить, а сопровождение становилось крайне сложным. Рост крупных программных проектов привел к формированию последовательных инженерных моделей. Программирование начали разделять на анализ требований, проектирование, реализацию, испытания и эксплуатацию. Так сложилась каскадная модель. Каскадная модель перенесла в программную разработку инженерные идеи предварительного проектирования, документального контроля и поэтапной приемки. Она позволила управлять крупными коллективами и договорами, но исходила из предположения о возможности заранее определить основную часть требований. Практика показала, что информационные системы отличаются от многих материальных объектов. Программное обеспечение относительно легко изменять технически, но трудно заранее определить, какие именно изменения потребуются. Пользователи лучше понимают свои потребности после взаимодействия с работающим продуктом. Для устранения чрезмерной жесткости каскада появились модифицированные каскадные модели с обратными связями. Они допустили возвраты между стадиями, промежуточные проверки и уточнение документов. Следующим направлением стала V-образная модель. В ней каждому уровню определения и проектирования соответствует определенный уровень проверки. Пользовательские требования сопоставляются с приемочными испытаниями, системные требования — с системным тестированием, архитектура — с интеграционным тестированием, детальный проект — с тестированием компонентов. V-образная модель усилила связь между разработкой и проверкой. Испытания начинают планироваться одновременно с требованиями и проектированием, а не после завершения программирования. Однако она сохраняет преимущественно последовательную структуру и также предполагает достаточно раннюю стабилизацию требований. Другим направлением развития стало прототипирование. Прототип представляет собой предварительную или упрощенную версию системы, создаваемую для уточнения требований, проверки концепции или оценки технического решения. Исследовательский прототип используется для понимания задачи и может быть отброшен после получения необходимых знаний. Эволюционный прототип постепенно совершенствуется и становится частью конечной системы. Прототипирование особенно полезно при проектировании пользовательских интерфейсов, сложных аналитических функций и новых технологий. Оно сокращает разрыв между письменным описанием и реальным представлением пользователей. Однако быстрый прототип может создать ложное впечатление высокой готовности. Пользователь видит работающий экран, но не видит отсутствия безопасности, надежности, полноценной архитектуры и обработки ошибок. Дальнейшим шагом стала инкрементная модель. Система создается и вводится в эксплуатацию частями. Каждый инкремент добавляет законченный набор функций. Например, сначала внедряется учет клиентов, затем обработка заказов, после этого склад и аналитика. Пользователь получает полезный результат раньше, а проект распределяет риски и затраты по этапам. Инкрементная разработка требует правильного определения границ приращений. Первый инкремент должен быть не случайным набором функций, а работоспособной частью, создающей ценность. Итерационная модель предполагает многократное уточнение системы. В каждой итерации анализируются требования, проектируются решения, выполняется реализация и проверка. Результат постепенно становится более полным. Итерация и инкремент не тождественны. Итерация связана с повторным уточнением, а инкремент — с добавлением функциональности. На практике они часто сочетаются: каждая итерация создает очередной инкремент. Спиральная модель объединила итерационное развитие с явным управлением рисками. Содержание очередного витка определяется не только перечнем функций, но и необходимостью устранить наиболее опасные неопределенности. В 1980—1990-е годы развивались методы быстрой разработки приложений, основанные на прототипировании, инструментальной автоматизации, повторном использовании компонентов и активном участии пользователей. Их целью было сократить длительные циклы традиционной разработки. Появились унифицированные итерационные процессы, в которых проект разделяется на фазы и итерации. Большое внимание уделяется архитектуре, вариантам использования, управлению требованиями и последовательному снижению рисков. В начале XXI века широкое распространение получили гибкие подходы к разработке. Их развитие было связано с необходимостью быстрее реагировать на изменения, чаще поставлять работающий продукт и усиливать взаимодействие с заказчиком. Гибкая разработка не отменяет требования, проектирование, тестирование и документирование. Она изменяет их организацию. Эти работы выполняются небольшими порциями на протяжении всего проекта, а не только в одной выделенной стадии. Например, требования формируются в виде упорядоченного перечня задач и уточняются перед реализацией. Проектирование выполняется перед каждой значимой функцией и одновременно поддерживается общая архитектура. Тестирование включается в каждую итерацию. Гибкие подходы используют короткие циклы, регулярную демонстрацию результата и обратную связь. Это позволяет быстрее обнаруживать неправильное понимание требований. Однако гибкость не означает отсутствие планирования и документации. Недостаток архитектурного управления может привести к накоплению технического долга. Для ответственных систем требуется сочетание коротких итераций с формальными проверками, документацией и управлением безопасностью. Следующим этапом эволюции стало развитие непрерывной интеграции, непрерывной поставки и культуры совместной работы разработки и эксплуатации, часто обозначаемой термином DevOps. Ранее разработка и эксплуатация могли существовать как отдельные последовательные стадии. Разработчики создавали систему, а затем передавали ее администраторам. В современной практике эксплуатационные требования учитываются с начала проекта, а развертывание, тестирование и контроль инфраструктуры автоматизируются. Изменение программного кода может автоматически запускать сборку, тесты, анализ безопасности и подготовку версии. Небольшие изменения передаются пользователям значительно чаще. Жизненный цикл становится не цепочкой редких крупных выпусков, а непрерывным потоком изменений. При этом процессы эксплуатации и разработки сближаются. Современная модель жизненного цикла все чаще является продуктовой, а не проектной. Команда отвечает не только за создание системы к установленной дате, но и за ее длительную результативность, развитие, надежность и ценность для пользователей. В проектном мышлении основной вопрос заключается в том, завершены ли работы в рамках срока и бюджета. В продуктовом мышлении дополнительно оценивается, достигает ли система полезного результата, используется ли она, насколько удовлетворены пользователи и как изменяются показатели деятельности. Развитие облачных технологий и микросервисной архитектуры усилило непрерывный характер жизненного цикла. Отдельные компоненты могут обновляться независимо, а инфраструктура создается и изменяется с помощью программно описанных конфигураций. Одновременно возрастает роль безопасной разработки. Безопасность должна учитываться в требованиях, архитектуре, программировании, тестировании, развертывании и эксплуатации. Такой подход часто называется интеграцией безопасности в жизненный цикл. Проверка зависимостей, анализ программного кода, моделирование угроз, управление уязвимостями и обновление компонентов становятся постоянными процессами. Для информационных систем, использующих данные и искусственный интеллект, жизненный цикл дополнительно включает сбор и подготовку данных, обучение моделей, оценку качества, контроль изменений данных, наблюдение за поведением модели и ее переобучение. Такая система может формально не изменять программный код, но изменять результаты из-за появления новых данных. Поэтому управление жизненным циклом должно охватывать не только программные версии, но и наборы данных, модели, параметры и критерии качества. Современная эволюция не означает полного исчезновения каскадных подходов. В реальных организациях применяются гибридные модели. Общая программа может управляться по стадийной схеме, а программные компоненты разрабатываться итерационно. Например, государственный проект может иметь формальные стадии технического задания, проектирования и приемки. Внутри стадии реализации команда может работать короткими итерациями, регулярно демонстрировать результат и автоматизировать тестирование. При создании медицинского оборудования аппаратная часть может разрабатываться по последовательной модели, программный интерфейс — итерационно, а экспериментальный аналитический модуль — по спиральной модели. Таким образом, эволюция моделей жизненного цикла представляет собой не простую замену старых моделей новыми, а накопление способов организации работ. Каждая модель решает определенный класс проблем. Каскадная модель обеспечивает планируемость и документальную управляемость. Модель с промежуточным контролем усиливает раннюю проверку и обратные связи. V-образная модель связывает уровни разработки с уровнями испытаний. Прототипирование помогает уточнять требования. Инкрементная модель ускоряет получение полезного результата. Итерационная модель обеспечивает постепенное уточнение. Спиральная модель управляет рисками. Гибкие подходы повышают способность реагировать на изменения. Непрерывная поставка объединяет разработку и эксплуатацию.