4. Каскадные модели разработки по.
Модель водопада (waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
В оригинальной модели водопада Ройса, следующие фазы шли в таком порядке:
Определение требований
Проектирование
Конструирование (также «реализация» либо «кодирование»)
Интеграция
Тестирование и отладка (также «верификация»)
Инсталляция
Поддержка
Следуя модели водопада, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.
Тем самым, модель водопада подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.
V- образная модель является развитием каскадной (жизненный цикл) и используется тогда, когда требования к программной системе четко определены на начальных этапах.
Основным отличием данной модели является то, что для каждого этапа жизненного цикла имеется связанный этап, который позволяет проверить правильность принятых решений.
«+» данной модели является механизм контроля.
«-» : выполнять этот контроль затруднительно, поскольку документы, разработанные на начальных этапах, часто бывают неоднозначными.
5. Итеративные модели разработки по.
Разработка коммерческих продуктов – это серьезное предприятие, которое требует большого количества времени и ресурсов. Практично было бы разделить работу на небольшие куски или мини проекты. Каждый мини проект будет итерацией, а результат итерации – это приращение. Итерации относятся к шагам рабочих процессов, а приращение к выполнению проекта. Для максимальной эффективности, итерации должны быть управляемыми. На каждой итерации определяют и описывают уместные для этой итерации варианты использования. Создают проект, использующий выбранную архитектуру в качестве направляющей, а затем его реализуют. Если итерация достигает своей цели, процесс разработки переходит на следующую. Для получения максимальной экономии, команда разработчиков должна выбирать только те итерации, которые требуются для выполнения цели проекта.
Управляемый итеративный процесс имеет ряд преимуществ:
управляемая итерация ограничивает финансовые риски затратами на одно приращение
управляемая итерация снижает риск не поставки продукта в установленные договором сроки. При раннем обнаружении соответствующего риска времени можно внести этот риск в план на ранних этапах разработки
управляемая итерация ускоряет темпы процесса разработки в целом
управляемый итеративный процесс направлен на удовлетворение желаний пользователя
Спиральная модель разработки ПО
Риск: не уложиться во времени, в финансы.
Спиральная модель декомпозирует проект на риск ориентированные подпроекты. Под рисками понимаются факторы, в результате действия которых разработка ПО может закончиться неудачей. В начале каждого этапа (подпроекта) анализируются риски, затем они ранжируются (по уровню критичности) и начинается реализация того подпроекта, который имеет самый высокий уровень
«-» основная доработка на последнем этапе.
Эволюционная модель
Эволюционная модель используется для проектов малого и среднего масштаба с нечетко определенными требованиями. Само название говорит о том, что процесс создания программного продукта проходит через некоторую эволюцию, развитие за определенное количество итераций.
Преимущества данной модели:
Предполагается нечеткая формулировка требований и реагирование на их изменение.
Процесс разработки – в непрерывном общении с клиентом.
Недостатки:
Невозможно четко определить количество итераций, а соответственно рассчитать сроки и стоимость выполнения проекта.
Слабый анализ рисков.
Адаптивная модель
Адаптивная модель используется в тех случаях, когда требования к проекту полностью неизвестны и могут очень быстро меняться в процессе разработки
Это выражается в 3 компонентах данной модели
Размышляйте (как бы деятельность планирования)
Сотрудничайте (взаимодействие между всеми сторонами, вовлеченными в проект)
Учитесь – предназначен для оценки эволюционного развития продукта
Преимущества адаптивной модели:
Позволяет работать над проектами, требования для которых полностью неизвестны на начальном этапе.
Недостатки:
Основной недостаток – невозможность полноценного управления проектом.
6. Почему программные системы сложны. Привести пять признаков сложной системы.
Сложность программных систем (ПС) обусловлена следующим:
сложность реальной предметной области, из которой происходит заказ на разработку
трудность управления процессом разработки
необходимость обеспечить достаточную гибкость программы
неудовлетворительные способы описания больших дискретных систем
Пять признаков сложной системы:
сложные системы часто являются иерархическими и состоят из взаимосвязанных подсистем, которые в свою очередь также могут быть разделены на подсистемы и т.д. в плоть до низкого уровня
выбор какие компоненты в данной системе считаются элементарными относительно произволен и в большей степени остаются на усмотрение разработчика
внутрикомпонентная связь обычно сильнее, чем связь между компонентами
иерархические системы обычно состоят из немногих типов подсистем по-разному скомбинированных и организованных
любая работающая сложная система является результатом развития работающей более простой системы, сложная система, спроектированная с нуля никогда не будет работать, следует начинать с работающей простой системы