Жизненный цикл автоматизированных информационных систем. Каскадная модель

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Министерство образования и науки Российской Федерации

Федеральное государственное автономное образовательное учреждение

высшего профессионального образования

«Национальный исследовательский ядерный университет «МИФИ»

Уральский технологический колледж - филиал НИЯУ МИФИ

РЕФЕРАТ

на тему:

Жизненный цикл автоматизированных информационных систем. Каскадная модель

Выполнил:

Подкина Вероника Олеговна

Рецензент:

Бушмелева Елена Алексеевна

г. Заречный

2014 г



Введение

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

Основным нормативным документом, регламентирующим жизненный цикл, является международный стандарт ISO/IEC 12207 (ISO - InternationalOrganizationofStandardization - Международная организация по стандартизации, IEC - InternationalElectrotechnicalCommission - Международная комиссия по электротехнике). Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы.

Структура жизненного цикла по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные, вспомогательные, организационные.

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

К основным относятся процессы приобретения, поставки, разработки, эксплуатации и сопровождения.

Вспомогательные процессы жизненного цикла АИС.

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

Процесс документирования предусматривает формализованное описание информации, созданной в течении ЖЦ ПП.

Процесс управления конфигурацией предполагает применение административных и технических процедур на всем протяжении ЖЦ ПП.

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

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

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

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

Процесс аттестации предусматривает определение полноты соответствия заданных требований к создаваемой системе или ПП.

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

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

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

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

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

Организационные процессы жизненного цикла АИС.

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

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

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

Процесс усовершенствования предусматривает оценку, измерение, контроль, усовершенствование процессов ЖЦ ПП.

Усовершенствование процессов ЖЦ ПП направлено на повышение производительности труда всех участвующих в них специалистов за счет совершенствования используемой технологии, методов управления, выбора инструментальных средств и обучения персонала.

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

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

Модели жизненного цикла АИС.

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

Наибольшее распространение получили две основные модели ЖЦ:

каскадная модель (70-85 гг.);

спиральная модель (86-90 гг.).



Каскадная модель

Каскадный способ - разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит, только после того, как будет полностью завершена работа на текущем (Рисунок 1).

Рисунок 1(Схема каскадного подхода)

Положительные стороны применения каскадного подхода

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

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

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

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

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

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

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

она отличается стабильностью требований;

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

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

она способствует осуществлению строгого контроля менеджмента проекта;

при правильном использовании модели дефекты можно обнаружить на более ранних этапах, когда их устранение еще не требует относительно больших затрат;

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

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

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

стадии модели довольно хорошо определены и понятны;

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

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

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

Рисунок 2 (Реальный процесс создания ИС на базе каскадной модели)



Одно из использовавшихся в западной литературе названий такой схемы организации работ: "водопадная модель" (waterfallmodel).

Основные недостатки каскадного подхода

существенное запаздывание с получением результатов;

модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением;

такое проектирование информационной системы ведет к примитивной автоматизации (по сути - "механизации") существующих производственных действий работников;

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

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

она не отображает основное свойство разработки ПО, направленное на разрешение задач. Отдельные фазы строго связаны с определенными действиями, что отличается от реальной работы персонала или коллективов;

она может создать ошибочное впечатление о работе над проектом. Выражение типа "35 процентов выполнено" -- не несет никакого смысла и не является показателем для менеджера проекта;

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

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

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

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

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

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

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

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

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

модель основана на документации, а значит, количество документов может быть избыточным;

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

отсутствует возможность учесть переделку и итерации за рамками проекта.

Классическая каскадная модель

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

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

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

Рисунок 3(Модель процесса "делать, пока, не будет сделано”)

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



Рисунок 4. (Классическая каскадная модель с обратной связью)

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

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

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

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

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

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

Краткое описание фаз каскадной модели

Приведенная ниже характеристика представляет собой краткое описание каждой фазы каскадной модели (включая фазы интеграции):

исследование концепции -- происходит исследование требований на системном уровне с целью определения возможности реализации концепции;

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

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

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

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

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

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

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

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

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

Область применения каскадной модели

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

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

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

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

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



Заключение

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

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

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

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

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

Размещено на Allbest.ru

...