6. Жизненный цикл кис. Каскадная модель. Инкрементная модель. Спиральная модель.

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

за этот период на предприятии могут произойти структурные и организационные изменения, требующие серьезной корректировки структуры и алгоритмов работы КИС;

сама система «обрастает» многочисленными доработками, дела­ю­щими ее неэффективной и слишком запутанной;

происходит полная смена аппаратной и программной платформы, появляются новые информационные технологии.

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

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

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

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

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

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

в процессе проектирования КИС неоднократно подвергается модификации, отражающую развитие объекта автоматизации;

снижение объемов и трудоемкости каждого этапа позволяет уменьшить риск и издержки в процессе проектирования.

Однако применение таких методов наряду с быстрым эффектом дает снижение управляемости проектом в целом и стыкуемости различных фрагментов КИС.

7. Общая характеристика case средств разработки по. Критерии выбора case средств. Понятие пилотного проекта. Его роль при выборе case средств.

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

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

Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:

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

интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

средства разработки приложений;

средства конфигурационного управления;

средства документирования;

средства тестирования;

средства управления проектом;

средства реинжиниринга.

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

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

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

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

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

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

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

После того, как CASE-средство выбрано, оно должно быть приобретено, интегрировано в проектную среду и настроено в соответствии с требованиями пилотного проекта.

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

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

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

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

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

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