Главная страница

Системная инженерия ЛЕКЦИЯ 2. Лекция 2 Из рабочей учебной программы Тема Стандарты и нормативные руководства по системной и программной инженерии


Скачать 0.87 Mb.
НазваниеЛекция 2 Из рабочей учебной программы Тема Стандарты и нормативные руководства по системной и программной инженерии
АнкорСистемная инженерия ЛЕКЦИЯ 2.doc
Дата20.10.2017
Размер0.87 Mb.
Формат файлаdoc
Имя файлаСистемная инженерия ЛЕКЦИЯ 2.doc
ТипЛекция
#9614
страница4 из 5
1   2   3   4   5

Инкрементная модель жизненного цикла разработки ПО



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

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

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

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

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

Фазы инкрементной модели ЖЦ разработки ПО



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

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

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

Преимущества инкрементной модели



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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



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

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

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

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

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

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

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

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

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



Область применения инкрементной модели



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

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

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

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

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

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

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

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

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

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



    1. 1   2   3   4   5


написать администратору сайта