выполнение программы для выявления дефектов в функциях логике и форме

Каскадная модель. Реализация стратегий разработки ПС в различных моделях проектирования

Реализация стратегий разработки ПС в различных моделях проектирования

Стратегии разработки программных средств

Классическая стратегия (называемая иногда «водопадной») характеризуется линейной последовательностью этапов конструирования.

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

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

Характеристики стратегий конструирования ПО в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в таблице 2.

Старейшей парадигмой процесса разработки ПО является классический жизненный цикл, реализованный в каскадной модели проектирования (автор Уинстон Ройс, 1970).

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

Рис.2.2. Каскадная модель разработки

Содержание основных этапов может быть охарактеризовано следующим образом.

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

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

Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Проектирование состоит в создании представлений:

· модульной структуры ПО;

· алгоритмической структуры ПО;

· входного и выходного интерфейса (входных и выходных форм данных).

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

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

Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение — это внесение изменений в эксплуатируемое ПО со следующими целями:

· адаптация к изменениям внешней для ПО среды;

· усовершенствование ПО по требованиям заказчика.

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

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

Недостатки классического подхода также существенны:

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

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

· результаты проекта доступны заказчику только в конце работы.

Источник

Выполнение программы для выявления дефектов в функциях логике и форме

1. Определение технологии конструирования

2. Методы технологии конструирования

3. Средства технологии конструирования

4. Процедуры технологии конструирования

5. Классический жизненный цикл

7. Стратегии конструирования ПО(модели ЖЦ)

Технология конструирования программного обеспечения

• Различают методы, средства и процедуры ТКПО.

Методы обеспечивают решение следующих задач:

• планирование и оценка проекта;

• анализ системных и программных требований;

• проектирование алгоритмов, структур данных и программных структур;

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

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

• формирование отчетов, форм по соответствующим требованиям;

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

• формирование «вех», по которым руководители оценивают прогресс.

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

Классический жизненный цикл

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

Охарактеризуем содержание основных этапов.

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

• Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.

• Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

• Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

• Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

• Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

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

Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение — это внесение изменений в эксплуатируемое ПО. Цели изменений:

• адаптация к изменениям внешней для ПО среды;

• усовершенствование ПО по требованиям заказчика.

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

Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.

Недостатки классического жизненного цикла:

1) реальные проекты часто требуют отклонения от стандартной последовательности шагов;

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

3) результаты проекта доступны заказчику только в конце работы.

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

• Основная цель макетирования — снять неопределенности в требованиях заказчика.

• Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.

• Модель может принимать одну из трех форм:

• 1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);

• 2) работающий макет (выполняет некоторую часть требуемых функций);

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

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

Рис. 1.3. Последовательность действий при макетировании

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

Достоинство макетирования: обеспечивает определение полных требований к ПО.

заказчик может принять макет за продукт;

разработчик может принять макет за продукт.

Стратегии конструирования ПО(Модели жизненного цикла)

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

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

Уменьшенное время цикла разработки (до 3 мес) и улучшенная производительность. Повторное использование кода и автоматизация процесса разработки

Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе разработки.

Невозможен переход от текущей реализации к новой версии в течение построения текущей частичной реализации

Охватывает каскадную модель. Расчленяет фазы на меньшие части. Позволяет гибко выполнять проектирование. Анализирует риски и управляет ими. Пользователи знакомятся с ПП на более раннем этапе благодаря прототипам

• Наибольшее распространение получили следующие модели жизненного цикла разработки ПП:

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

Разрабатываемое программное обеспечение не доступно для изменений

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

Создается «быстрая» частичная реализация сис­темы до составления окончательных требований. Обеспечивается обратная связь между пользо­вателями и разработчиками в процессе выпол­нения проекта.

Используемые требования не полные

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

Преимущества каскадного способа:

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

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

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

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

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

• Данная модель основана на систематическом подходе к проблеме, для решения которой определены четыре базовых шага: анализ, проектирование, разработка и обзор. При выполнении анализа осуществляются планирование проекта и составление требований. Проектирование разделяется на высокоуровневое и де­тальное (низкоуровневое). Разработка включает в себя кодирова­ние, а обзор — различные виды тестирования.

• Эта модель (рис. 3.3) была разработана как разновидность кас­кадной модели, в которой особое внимание уделяется верификации и аттестации ПП. Модель показывает, что тестирование продукта обсуждается, проектируется и планируется, начиная с ран­них этапов жизненного цикла разработки (на рис. 3.3 этот процесс обозначен штриховыми стрелками).

• На модели хорошо просматриваются взаимосвязи между аналитическими фазами и фазами проектирования, которые пред-

шествуют кодированию и тестированию. Штриховые стрелки показывают, что эти фазы надо рассматривать параллельно.

• Модель включает в себя следующие фазы: составление требований к проекту и планирование — определяются системные требования и выполняется планирование работ;

• составление требований к продукту и их анализ — составляется полная спецификация требований к программному продукту;

• высокоуровневое проектирование — определяются структура ПП, взаимосвязи между основными его компонентами и реализуемые ими функции;

• детальное проектирование — определяется алгоритм работы каждого компонента;

• кодирование — выполняется преобразование алгоритмов в го­товое программное обеспечение;

• модульное тестирование — выполняется проверка каждого ком­понента или модуля ПП;

• интеграционное тестирование — осуществляются интеграция ПП и его тестирование;

• системное тестирование — выполняется проверка функциони­рования ПП после помещения его в аппаратную среду в соответ­ствии со спецификацией требований;

• эксплуатация и сопровождение — запуск ПП в производство. На этой фазе в ПП могут вноситься поправки и может выполняться его модернизация.

Преимушества V-образной модели:

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

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

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

Кроме перечисленных достоинств модель обладает и рядом недостатков:

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

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

Модель прототипирования (рис. 3.4) позволяет создать прототип ПП до или в течение этапа составления

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

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

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

• Модель прототипирования обладает целым рядом преимуществ:

• взаимодействие заказчика с

• разрабатываемой системой начи­нается на раннем этапе;

• благодаря реакции заказчика на прототип сводится к миниму­му число неточностей в требованиях;

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

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

• прототип представляет собой формальную спецификацию, воп­лощенную в ПП;

• прототип позволяет очень гибко выполнять проектирование и разработку, включаянесколько итераций на всех фазах жизнен­ного цикла разработки;

• заказчик всегда видит прогресс в процессе разработки ПП; возможность возникновения противоречий между разработчи­ками и заказчиками сведена к минимуму;

• уменьшается число доработок, что снижает стоимость разра­ботки:

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

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

• Кроме указанных достоинств модели прототипирования присутсвует и целый ряд недостатков:

• решение сложных задач может отодвигаться на будущее;

• заказчик может предпочесть получить прототип, а не закон­енную полную версию ПП;

• прототипирование может неоправданно затянуться;

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

• Модель прототипирования рекомендуется применять в следующих случаях:

• требования к ПП заранее неизвестны,

• требования не постоянны или неудачно сформулированы;

• требования необходимо уточнить;

• нужна проверка концепции;

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

Источник

Жизненный цикл разработки программного обеспечения. Сравнение различных типов жизненного

цикла и вспомогательные процессы.

Классический жизненный цикл (каскадная модель или водопад)

Старейшая парадигма, разработал Уинстон Ройс, 1970.

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

Содержание основных этапов.

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

Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.

Проектирование состоит в создании представлений:

модульной структуры ПО;

алгоритмической структуры ПО;

структуры данных; • входного и выходного интерфейса (входных и выходных форм данных).

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

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

Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение — это внесение изменений в эксплуатируемое ПО с целью:

адаптация к изменениям внешней для ПО среды;

усовершенствование ПО по требованиям заказчика.

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

Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.

Недостатки классического жизненного цикла:

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

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

Макетирование (портотипирование)

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

Основная цель макетирования — снять неопределенности в требованиях заказчика.

Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.

Модель может принимать одну из трех форм:

бумажный макет или макет на основе ПК

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

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

Макет оценивается заказчиком и используется для уточнения требований к

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

обеспечивает определение полных требований к ПО.

Недостатки макетирования: заказчик может принять макет за продукт; разработчик может принять макет за продукт.

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

Инкрементная модель

Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис. 1.4). Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования.

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

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

Быстрая разработка приложений

Модель быстрой разработки приложений (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования (рис. 1.5).

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD — высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:

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

функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнеспроцессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?

моделирование данных. Информационный поток, определенный на этапе

бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержкибизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами моделирование обработки. Определяются преобразования объектов данных,

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

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

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

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

Применение RAD имеет и свои недостатки, и ограничения.

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

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

RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).

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

Спиральная модель — классический пример применения эволюционной стратегии конструирования.

Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска, отсутствующий в этих парадигмах [19].

Как показано на рис. 1.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

Планирование — определение целей, вариантов и ограничений.

Анализ риска — анализ вариантов и распознавание/выбор риска.

Конструирование — разработка продукта следующего уровня.

Оценивание — оценка заказчиком текущих результатов конструирования.

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

Достоинства спиральной модели:

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

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

включает шаг системного подхода в итерационную структуру разработки; 4) использует моделирование для уменьшения риска и совершенство вания программного изделия. Недостатки спиральной модели:

новизна (отсутствует достаточная статистика эффективности модели);

повышенные требования к заказчику; 3) трудности контроля и управления временем разработки.

Компонентно-ориентированная модель

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

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

Достоинства компонентно-ориентированной модели:

1) уменьшает на 30% время разработки программного продукта; 2) уменьшает стоимость программной разработки до 70%; 3) увеличивает в полтора раза производительность разработки.

Дата добавления: 2017-06-02 ; просмотров: 3585 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник