Модели разработки по

Цикл разработки программного обеспечения

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

МОДЕЛИ РАЗРАБОТКИ ПО Тема 2 1 Модели

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

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

  1. Инженерный подход

  2. С учетом специфики задачи

  3. Современные технологии быстрой разработки

Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.

Давайте, более подробно рассмотрим подклассы моделей.

Модель кодирования и устранения ошибок

Самая простая из моделей очень часто применяемая студентами в учебном процессе.Алгоритм этой модели состоит из следующих шагов:

  • Шаг 1: постановка задачи

  • Шаг 2: создание программы

  • Шаг 3: тестирование

  • Шаг 4: анализ результата тестирования и возможный переход к шагу 1

Эта модель относится к первой группе и совсем не актуальна при профессиональной разработке программного обеспечения. По таким алгоритмам работали программисты 50-60 лет назад. Излишняя простота в данном случае не позволяет конкурировать с другими существующими моделями.

Недостатки

«Водопад» или каскадная модель жизненного цикла программного обеспечения

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

Алгоритм каскадной модели

Преимущества:

  • Последовательное выполнение этапов проекта в строгом фиксированном порядке

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

Недостатки:

  • Отсутствие обратных связей между этапами

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

  • Относится к первой группе моделей.

«Водоворот» или каскадная модель с промежуточным контролем

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

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

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

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

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

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

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

V модель — разработка через тестирование

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

Модель на основе разработки прототипа

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

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

  • Прояснить не ясные требования (прототип UI)

  • Выбрать одно из ряда концептуальных решений (реализация сцинариев)

  • Проанализировать осуществимость проекта

Классификация протопипов:

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

  • Вертикальные прототипы — проверка архитектурных решений.

  • Одноразовые прототипы — для быстрой разработки.

  • Эволюционные прототипы — первое приближение эволюционной системы.

Спиральная модель жизненного цикла программного обеспечения

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

Преимущества модели:

  1. Результат достигается в кратчайшие сроки.

  2. Конкурентоспособность достаточно высокая.

  3. При изменении требований, не придется начинать все с «нуля».

Но у этой модели есть один существенный недостаток: невозможность регламентирования стадий выполнения.

Отдельного рассказа заслуживают модели экстремального программирования (ХР), SCRUM, инкриментальная модель (RUP). Это все модели, относятся к третьей группе, но для их анализ будет проведен в отдельной статье.

И в заключении

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

Процесс разработки программного обеспечения

Поиск Лекций


Инкрементная модель жизненного цикла разработки программного обеспечения

 

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

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

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

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

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

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

Рис. 2. Инкрементная модель

Инкремент 3    
Инкремент 2    
Требования и планирование
Производство, эксплуатация
Инкремент 1    

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

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

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

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

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

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

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

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

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

· существует возможность поддерживать постоянный прогресс в ходе выполне­ния проекта;

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

· ускоряется начальный график поставки (что позволяет соответствовать возрос­шим требованиям рынка);

· снижается риск неудачи и изменения требований;

· заказчики могут распознавать самые важные и полезные функциональные воз­можности продукта на более ранних этапах разработки;

· риск распределяется на несколько меньших по размеру инкрементов (не сосре­доточен в одном большом проекте разработки);

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

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

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

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

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

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

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

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

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

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

· ощутимые признаки прогресса при выполнении проекта помогают поддерживать вызванное соблюдением графика "давление" на управляемом уровне.

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

· в модели не предусмотрены итерации в рамках каждого инкремента;

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

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

· заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены;

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

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

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

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

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

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

· если рыночное окно слишком "узкое" и существует потребность быстро поставить на рынок продукт, имеющий функциональные базовые свойства;

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

· при равномерном распределении свойств различной степени важности;

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

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

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

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

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

 

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

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

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

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

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

 

 

Рис. 3. Итерационная модель.

 

 

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

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

Все подобные методологии программирования направлены лишь на то, чтобы минимизировать возвраты. Но суть от этого не меняется: при возврате всегда приходится повторять построение того, что уже считалось готовым.

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

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

©2015-2018 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Нарушение авторских прав и Нарушение персональных данных

Выбор модели жизненного цикла программного продукта

Требования к web-сайту

При разработке web-сайта должны учитываться следующие параметры:

— сайт должен содержать краткую информацию по дисциплине «география»

— сайт должен содержать тесты для проверки знаний

Вывод:

1.Была изучена предметная область по дисциплине «География» были выделены основные части теоретического материала, которые будут использоваться при создании web-сайта «География для студента»

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

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

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

Стадии;

Результаты выполнения работ на каждой стадии;

Ключевые события – точки завершения работ и принятия решений.

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

2.1 Модели жизненного цикла ПО:

Водопадная модель жизненного цикла была предложена в 1970 г. Уинстоном Ройсом (рис 2.1).

Разработка ПО: этапы, модели разработки

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

Ø Этапы проекта в соответствии с каскадной моделью:

Ø Формирование требований

Ø Проектирование

Ø Реализация

Ø Тестирование

Ø Внедрение

Ø Эксплуатация и сопровождение

Ø Преимущества:

Ø Полная и согласованная документация на каждом этапе;

Ø Легко определить сроки и затраты на проект.

 

Недостатки:

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

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

⇐ Предыдущая123456789Следующая ⇒


Дата добавления: 2015-08-31; Просмотров: 144; Нарушение авторских прав?;




Добавить комментарий

Закрыть меню