Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Информационные системы и технологии на предприятиях

Модели жизненного цикла ПО

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

Модель ЖЦ ПО - это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий, задач на протяжении ЖЦ.

Модель ЖЦ конкретного ПРОГРАММНОГО обеспечения информационной системы определяет характер процесса создания ПО, что означает совокупность упорядоченных во времени, объединенных в стадии работ.

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

Наибольшее распространение получили две модели: каскадная (водопадная), созданная в 1970-1985 гг., и спиральная, созданная в 1986-1990 гг.

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

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

Основное внимание разработчиков сосредотачивается на достижении наилучших значений технических характеристик ПО, а именно: производительности, объема памяти и т.д.

Преимущества применение каскадной модели:

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

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

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

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

Рис. 3.3. Каскадная модель жизненного цикла 1С

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

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

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

Для преодоления перечисленных проблем в середине 1980-х годов была предложена спиральная модель ЖЦ ПО (рис. 3.4).

Рис. 3.4. Модель спирального процесса разработки 1С

Спиральная модель (spiral model) была разработана в середине 1980-х годов Баре Боемом. Она основывается на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ИС создается в несколько итераций (витков спирали) методом прототипирования.

Сейчас эта модель достаточно распространена. Самые известные примеры ее реализации - это RUP (Rational Unified Process фирмы Rational и MSF (Microsoft Solution Framework). Создание 1С по такой модели имеет итерационный характер и движется по спирали, проходя стадии, где на каждом витке уточняются характеристики будущего информационного продукта.

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

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

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

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

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

 
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 
Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Естествознание
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Математика, химия, физика
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Региональная экономика
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика
Прочее