что такое жизненный цикл по ис модели жизненного цикла

Что такое жизненный цикл по ис модели жизненного цикла

3. МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

3.1. Классификация моделей жизненного цикла

К настоящему времени наибольшее распространение получили следующие модели (стратегии) жизненного цикла [4, 7].

Рис.3.1. Классификация моделей жизненного цикла

Дальнейшее рассмотрение моделей жизненного цикла ведется с использованием терминологии классического жизненного цикла.

3.2. Каскадная стратегия

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

Рис.3.2. Каскадная стратегия

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

— на каждой стадии формируется законченный набор документации, программного и аппаратного обеспечения, отвечающий критериям полноты и согласованности;

— выполняемые в четкой последовательности стадии позволяют уверенно планировать сроки выполнения работ и соответствующие ресурсы (денежные, материальные и людские).

— реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем;

— основана на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично;

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

3.3. Инкрементная стратегия

Инкрементная стратегия (англ. increment – увеличение, приращение) подразумевает разработку информационной системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта.

Рис.3.3. Инкрементная стратегия

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

Данная модель жизненного цикла характерна при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат (информационная система). Разработка версиями ведется в силу разного рода причин:

— отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;

— отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;

— требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у ее пользователей неприятие и только «затормозить» процесс перехода на новые технологии. Образно говоря, они могут просто «не переварить большой кусок, поэтому его надо измельчить и давать по частям».

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

3.4. Спиральная стратегия

Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1986-88 гг.) [44] подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.

Рис. 3.4. Спиральная стратегия

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

— позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;

— допускает изменение требований при разработке информационной системы, что характерно для большинства разработок, в том числе и типовых;

— обеспечивает большую гибкость в управлении проектом;

— позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации;

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

— уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.

— увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;

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

3.5. Сравнительный анализ моделей

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

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

Таблица 3.1. Сравнение моделей жизненного цикла

В табл. 3.1 не стоит рассматривать значения «Да» и «Нет» как жесткие требования. Например, незначительное изменение требований по мере развития проекта при использовании каскадной модели (например, добавление некоторых непредусмотренных сервисных функций) встречается не так уж редко и в случае их реализации способствует улучшению взаимоотношений между сторонами. Аналогично распространение промежуточного программного обеспечения при спиральной модели необязательно, а иногда даже вредно отражается на процессах внедрения и опытной эксплуатации системы.

При разработке системы под итоговым продуктом и промежуточным программным обеспечением следует понимать:

— ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД, необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;

— модификацию – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ТЗ), а также изменения, связанные с устранением ошибок, усовершенствованием;

— версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;

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

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

3.6. Методологии, поддерживающие спиральную модель

В настоящее время имеется несколько методологий 1 разработки программного обеспечения, которые можно рекомендовать при использовании спиральной модели жизненного цикла. Наиболее известными из них являются методология быстрой разработки приложений (Rapid Application Development, RAD) и экстремальное программирование (eXtreme Programming, XP – автор Кент Бек, 1999).

Методология RAD [4]. На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования и подразумевала, как правило, ручной набор текстов программ. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке разработки программного обеспечения средств автоматизации практически всех стадий жизненного цикла.

Под RAD-разработкой обычно понимается процесс разработки, содержащий 3 элемента:

— небольшую команду программистов (до 10 человек);

— короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);

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

Помимо особенностей, характерных для спиральной модели жизненного цикла, методология RAD подразумевает использование на каждой итерации:

— инструментальных средств, обеспечивающих визуальную разработку (программирование) системы. Среда разработки приложений позволяет без написания кода программы создавать («рисовать») сложные графические интерфейсы пользователя, состав и структуру БД, запросы к БД, а также связывать данные с элементами интерфейса (переключателями, полями ввода, таблицами и т. д.);

— инструментальных средств, поддерживающих объектно-ориентированный подход. Эти средства позволяют создать описание предметной области в виде совокупности объектов – сущностей реального мира, характеризуемых свойствами (атрибутами) и поведением (методами);

— инструментальных средств, обеспечивающих событийное программирование. Каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами;

— шаблонов и библиотек готовых решений как собственной разработки, так и сторонних производителей.

Условия применения методологии RAD:

— применима для относительно небольших проектов, разрабатываемых под конкретного заказчика;

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

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

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

Методология XP [7]. Данный подход ориентирован на разработку информационных систем группами малого и среднего размера в условиях неопределенных или быстро изменяющихся требований.

Отличительными особенностями XP-разработки являются:

— частая смена версий и модификаций (длительность итераций вплоть до часов и минут, а обычно – 2 недели; в RAD – минимум 2 месяца);

— непрерывная связь с заказчиком – в группе все время находится квалифицированный представитель заказчика. Это самое сокровенное желание любого разработчика. Как правило, очень трудно убедить заказчика выделить такого представителя, чтобы он целыми днями (неделями) не выполнял своих прямых обязанностей на работе. Но еще труднее бывает найти именно квалифицированного специалиста, который может оперативно ответить на все увеличивающее количество вопросов со стороны команды разработчиков;

— простое проектирование – при разработке всегда выбирается наиболее простое решение. «Лучше сделать простую вещь сегодня и завтра заплатить еще немного за внесение небольших изменений, чем делать сегодня сложную вещь, которая завтра может не понадобиться» [7]. Спорное утверждение, на которое можно возразить, что «скупой платит дважды». Нередко опытному разработчику, особенно неплохо разбирающемуся в поставленной задаче, видно, что если применить более сложную схему реализации некоторой функции или расширить структуру данных, то это увеличит круг решаемых задач, позволит с меньшими затратами адаптировать систему под изменяющиеся или новые требования заказчика и т. д.;

— простой дизайн – система должна быть спроектирована настолько просто, насколько это возможно на каждый момент времени. Чем интерфейс проще, тем быстрее и качественнее идет освоение системы пользователями. Это не означает, что интерфейс «командной строки» самый предпочтительный. Как раз наоборот, «дружественный» и простой интерфейс должен быть интуитивно-понятным для пользователя; в нем должны отсутствовать бесполезные элементы, основная цель которых – произвести визуальное впечатление на пользователя; дополнительные диалоговые окна по вводу данных в строку таблицы, когда это можно сделать непосредственно в строке этой таблицы и т. д.;

— коллективное владение кодом – любой, кто видит возможность улучшить какую-то часть кода, может сделать это в любой момент времени. Это подразумевает применение одинаковых стандартов и правил оформления кода с исчерпывающими комментариями, а также и ведение общедоступной истории развития системы;

— программирование в парах – на пару программистов приходится один компьютер. Пока один из них непосредственно программирует, другой обдумывает вопросы реализации требований (функций, БД и т.п.). Смысл положения заключается не в экономии на материально-техническом обеспечении команды разработчиков, а в более разумном сочетании разных видов деятельности каждого из них. Как показывает опыт, при непосредственном программировании, исправлении ошибок и т.п. программист начинает думать односторонне и все более узкими категориями. Именно поэтому во время «отдыха от компьютера» приходят наиболее удачные решения;

— непрерывное и пересекающееся проектирование, разработка, интеграция и тестирование системы.

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

1 Методология – последовательность выполнения работ, правил выбора методов и решений на разных этапах разработки.

2 CASE – Computer Aided Software Engineering (автоматизированная разработка ПО).

Вопросы для самопроверки

3. Дайте краткую характеристику методологий RAD и XP.

Источник

Понятие жизненного цикла ИС И ПО

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

Наиболее часто ключевые стороны, задействованные в создании и эксплуатации информационной системы, ассоциируют ее с программным обеспечением, лежащем в основе этой ИС. Тогда в чем основное отличие жизненного цикла информационной системы от жизненного цикла программного обеспечения? Ответ начинается с самого определения информационной системы, охватывающего большее количество аспектов, нежели просто ПО. Программное обеспечение может быть модернизировано, обновлено до новых версий несколько раз в рамках одного жизненного цикла информационной системы. Однако это будет все та же информационная система, возможно, с теми же инфраструктурными и организационными ресурсами. Могут приходить и уходить сотрудники, обновляться системы хранения данных, но это лишь части информационной системы, которая все равно будет выполнять свои основные функции до момента вывода из эксплуатации. Интересная для рассмотрения концепция уровней жизненного цикла была предложена в 2005 году Скоттом Амблером, автором практик гибкого моделирования Agile Modeling и концепции Enterprise Unified Process.

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

Жизненный цикл организации / бизнеса

Жизненный цикл информационных технологий

Жизненный цикл системы

Жизненный цикл ПО (разработки)

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

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

Следует различать два типа ЖЦ ИС

Типы жизненного цикла ИС

ЖЦ адаптируемой ИС.

Внедрение тиражируемой модели ИС

ЖЦ включает стандартные этапы:

ЖЦ ориентированный на адаптацию:

ЖЦ включает стандартные этапы:

Анализ и разработка требований:

· Анализ бизнес процессов

· Разработка функциональных требований и комплекса требований к программному, информационному и другим видам обеспечения ИС

· Проектирование архитектурных систем

· Разработка архитектуры ИС

· Разработка обеспечивающих частей ИС

Отладка и тестирование

Внедрение и сопровождение

ЖЦ ориентированный на адаптацию:

Анализ и разработка требований:

· Разработка функциональных требований к ИС

· ИТ-маркетинг, приобретение, постановка ИС

· Проектирование требуемой архитектуры ИС

· Анализ требуемой архитектуры и архитектуры тиражируемой ИС

· Выявление и реализация доработок

· Соотношение требований к тиражируемой ИС с ее функционалом

Адаптация тиражируемой ИС

Отладка и тестирование

Внедрение и сопровождение

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

Модель ЖЦ ИС – комбинация последовательности этапов жизненного цикла и переходов между ними, необходимых для гарантированного достижения поставленной для реализации проекта цели.

Сами фазы жизненного цикла фиксированы и для различных отраслей человеческой деятельности, по сути, одинаковы: ‒ Замысел (планирование проекта). ‒ Анализ и постановка задачи. ‒ Проектирование. ‒ Разработка. ‒ Развертывание и внедрение. ‒ Эксплуатация. ‒ Поддержка. ‒ Модернизация. ‒ Утилизация. Можно говорить о том, что средняя продолжительность подобного цикла составляет порядка 15 лет, однако следует учитывать что в зависимости от огромного числа различных факторов, обусловленных спецификой предприятия, отрасли, самой информационной системы сроки физического и морального старения техники и ПО будут значительно отличаться. А значит, еще при проектировании ИС необходимо четко представлять себе возможности ее дальнейшей модернизации, в том числе факторы, которые могут вызвать эту необходимость.

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

2. Каскадная модель ЖЦ ИС

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

Каскадная модель ЖЦ ИС

2.1. Каскадная модель с промежуточным контролем

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

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

Описание этапов ЖЦ каскадной модели.

3. Спиральная модель

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

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

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

Определенным прообразом спиральной модели ЖЦ стал классический цикл управления Деминга (PDCA-цикл).

PDCA (Plan – Do – Check – Act) – Цикл качества, еще называемый циклом Деминга. Этот алгоритм управления предполагает четыре основных шага «Планирование – Действие – Проверка – Корректировка» и помимо стандартной области применения в менеджменте предприятия возможно использовать его в управлении внедрением и развитием информационной системы. Таким образом, этап планирования может начинаться как при первичном проектировании системы, так и при старте ее модернизации, когда, как мы говорили, снова необходимо пройти все этапы жизненного цикла системы.

Графически цикл Деминга может быть представлен следующим образом:

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

4. Модель разработки через тестирование (V-модель)

Приближенная по своей сути к практикам PRINCE2, V-модель разработки через тестирование была разработана еще в конце 1980-х годов ведомствами Германии и США, и до сих пор является стандартом немецких правительственных и оборонных проектов. Основной ее принцип состоит в постепенном возрастании степени детализации проекта с течением времени и одновременном проведении «горизонтальных» итераций. Таким образом, результаты каждой из фаз левой стороны буквы V влияют на тестирование и компоновку проекта с правой стороны буквы V: приемо-сдаточные испытания основываются на проведенном анализе требований, интеграционное тестирование – на высокоуровневом описании архитектуры, модульное тестирование – на архитектуре, интерфейсах, алгоритмах и прочих элементах детализированных требованиях к системе.

5. Модель быстрой разработки программных приложений ( RAD )

Модель RAD включает следующие фазы:

· Планирование требований – структурный анализ и обсуждение с заказчиком реализуемых коммерческих задач;

· Пользовательское описание – выполняется сбор опльзовательской информации и построение моделей процессов предметной области с использованием автоматизированных инструментальных средств при активном участии заказчика;

· Конструирование – выполняется детализованное проектирование, включающее разработку (кодирование и тестирование) системы, а также поставку программного продукта заказчику;

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

Преимущества модели RAD

· Применение мощной инструментальных сред позволяет сократить время цикла разработки всего проекта;

· Создание системы выполняется коллективом, знающим процессы предметной области;

· Уменьшаются затраты благодаря сокращенному времени цикла, а также меньшему количеству задействованных разработчиков;

· Уменьшается риск, связанный с соблюдением графика работ, за чсет сокращения времени цикла;

· Сведение к минимуму риска того, что система не будет удовлетворять требованиям предметной области;

· Использование различных стандартных методологий моделирования: моделирование потоков данных; моделирование данных; моделирование бизнес процессов; генерирование приложения;

· Повторное использование компонентов уже существующих программ.

Недостатки модели RAD

· Низкое качество программного продукта, если заказчики не могут принимать активное участие в процессе создания системы на протяжении всего ЖЦ;

· Необходимость достаточного количества высококвалифицированных разработчиков, умеющих пользоваться выбранными инструментальными средствами разработки

· Необходимость наличия готовых компонентов проектируемой системы до начала проекта.

Источник