Geum.ru

Вопросы для экзамена по курсу "Проектирование асоиу"

Вид материалаВопросы для экзамена

Содержание


Модели жизненного цикла программного обеспечения АСОИУ. Подход RAD.
1. Каскадная модель
2. Спиральная модель
3. Методология RAD
Основные принципы методологии RAD
Подобный материал:
1   2   3   4   5   6   7   8   9   ...   19

Модели жизненного цикла программного обеспечения АСОИУ. Подход RAD.


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

Рассмотрим каскадную и спиральную модели подробнее:

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

Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе. [4]

Каскадная модель разбивает процесс ЖЦ на пять этапов, выполняемых последовательно, один за другим:



Рисунок 5. Каскадная схема разработки ПО

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



Рисунок 6. Каскадная схема с промежуточным контролем
  • существенное запаздывание с получением результатов,
  • требования к ИС "заморожены" в виде технического задания на все время ее создания, и, в случае неточного изложения требований или их изменения за время создания ПО, модель автоматизируемого объекта устаревает к моменту реализации.

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

Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Делает упор на начальные этапы ЖЦ - анализ и проектирование. Реализуемость технических решений проверяется на этих этапах путем создания прототипов.



Рисунок 7. Спиральная модель жизненного цикла ПО

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

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

Сам Барри Боэм так характеризует спиральную модель разработки (используется с разрешения автора):

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

Спиральная модель обладает рядом преимуществ:
  • Модель уделяет специальное внимание раннему анализу возможностей повторного использования. Это обеспечивается, в первую очередь, в процессе идентификации и оценки альтернатив.
  • Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта. Главные источники изменений заключены в целях, для достижения которых создается продукт. Подход, предусматривающий скрытие информации о деталях на определенном уровне дизайна, позволяет рассматривать различные архитектурные альтернативы так, как если бы мы говорили о единственном проектном решении, что уменьшает риск невозможности согласования функционала продукта и изменяющихся целей (требований).
  • Модель предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта. Эти механизмы строятся на основе идентификации всех типов целей (требований) и ограничений на всех “циклах” спирали разработки. Например, ограничения по безопасности могут рассматриваться как риски на этапе специфицирования требований.
  • Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Это достигается явно определенными работами по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки.
  • Модель позволяет контролировать источники проектных работ и соответствующих затрат. По-сути речь идет об ответе на вопрос – как много усилий необходимо затратить на анализ требований, планирование, конфигурационное управление, обеспечение качества, тестирование, формальную верификацию и т.д. Модель, ориентированная на риски, позволяет в контексте конкретного проекта решить задачу приложения адекватного уровня усилий, определяемого уровнем рисков, связанных с недостаточным выполнением тех или иных работ.
  • Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего. Этот аспект позволяет избежать часто встречающегося отношения к поддержке и сопровождению как ко второсортной” деятельности. Такой подход предупреждает большого количество проблем, возникающих в результате одинакового уделения внимания как обычному сопровождению, так и критичным вопросам, связанным с расширением функциональности продукта, всегда ассоциированным с повышенными рисками.
  • Модель позволяет решать интегрированный задачи системной разработки, охватывающей и программную и аппаратную составляющие создаваемого продукта. Подход, основанный на управлении рисками и возможности своевременного отбрасывания непривлекательных альтернатив (на ранних стадиях проекта) сокращает расходы и одинаково применим и к аппаратной части, и к программному обеспечению.



Рисунок 8. Оригинальная спиральная модель жизненного цикла разработки по Боэму

Недостатки:

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

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

3. Методология RAD

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений - RAD (Rapid Application Development).

Методология RAD предполагает:
  • маленький коллектив 2 – 10 чел.
  • короткий график от 2 до 6 мес.
  • повторяющийся цикл

Основные принципы методологии RAD

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

Методология RAD дает хорошие результаты при выполнении относительно небольших проектов для конкретного заказчика.

Однако, ее нельзя использовать:
  • при разработке типовых систем, которые затем адаптируются к особенностям объектов внедрения;
  • для построения сложных расчетных программ, операционных систем, программ управления сложными объектами (системы АСУ ТП);
  • к приложениям, у которых интерфейсная часть не определяет логику работы системы;
  • к разработке систем, от которых зависит безопасность людей (например: управление самолетом или АЭС).

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