Инкрементная модель, спиральная модель разработки ПО: жизненный цикл, достоинства и недостатки. — КиберПедия 

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

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

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

2017-07-01 656
Инкрементная модель, спиральная модель разработки ПО: жизненный цикл, достоинства и недостатки. 0.00 из 5.00 0 оценок
Заказать работу

Инкрементная модель объединяет в себе достоинства двух подходов: классического подхода и макетирования.

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

Для каждого инкремента выполняется:

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

– Проектирование, на котором происходит проектирование архитектуры, допроектирование тех вещей, которые не были сделаны на предыдущем инкременте;

– Разработка,

– Тестирование.

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

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

Риск программного проекта – это те причины, из-за которых проект может быть неуспешным. Это могут быть технические риски, проектные риски, экономические риски. Это понятие такой науки как «Управление рисками».

 

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

Сама по себе спиральная модель не простая в реализации.

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

Поэтому реально в проектах не так часто используют спиральную модель

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

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

  • небольшую команду программистов (от 2 до 10 человек);
  • короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
  • повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

  • фаза анализа и планирования требований;
  • фаза проектирования;
  • фаза построения;
  • фаза внедрения.

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

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

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

производится физическое проектирование базы данных;

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

определяются способы увеличения производительности;

завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.


Поделиться с друзьями:

Состав сооружений: решетки и песколовки: Решетки – это первое устройство в схеме очистных сооружений. Они представляют...

Таксономические единицы (категории) растений: Каждая система классификации состоит из определённых соподчиненных друг другу...

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

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



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.007 с.