Жизненный цикл программного обеспечения

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

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

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

Старейшая парадигма, разработал Уинстон Ройс, 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.7.

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

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

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

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


Дата добавления: 2017-06-02; просмотров: 656;


ПОСМОТРЕТЬ ЕЩЕ:

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

Основатели теории управления разработкой программного обеспечения, в том числе Уинстон Ройс (Winston Royce) и Барри Боэм (Barry Boehm), изначально понимали, какая проблема кроется в классическом каскадном процессе. Для преодоления этих проблем в середине 80-х годов была предложена спиральная модель жизненного цикла, обеспечивающая большую степень взаимосвязи с потребителем. Спиральная модель базируется на лучших свойствах водопадного процесса и метода прототипирования (макетирования), к которым добавляется новый элемент – анализ рисков.

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

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

Как показано на рис. 1.8, в каждый квадрант модели входят целевые и вспомогательные действия. Ниже перечислены эти квадранты.

· Определение целей, альтернативных вариантов и ограничений.

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

· Оценка альтернативных вариантов, идентификация и разрешение рисков.

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

 

 

Рис. 1.8. Спиральная модель жизненного цикла

 

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

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

Жизненный цикл программного обеспечения, модели жц

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

· Планирование следующей фазы.

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

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

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

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

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

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

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

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

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

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

В то же время спиральная модель не лишена недостатков, которые особенно ярко проявляются при ее использовании в проектах, для которых она не слишком подходит:

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

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

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

· сложность оценки точки перехода на следующий цикл;

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

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

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

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

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

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

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

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

1234

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

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

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

Старейшая парадигма, разработал Уинстон Ройс, 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.7.

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

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

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

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


Дата добавления: 2017-06-02; просмотров: 655;


ПОСМОТРЕТЬ ЕЩЕ:

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ИСО/МЭК 12207 – 95 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

– каскадная модель (70–85 г.г.);

– спиральная модель (86–90 г.г.).

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

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

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

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

Каскадная модель ЖЦ:

Рис. 1.1. Каскадная схема разработки ПО

Трудозатраты:

Оценка трудозатрат по Бруксу:

1/3 – планирование

1/6 – написание программ

1/4 – тестирование компонент

1/4 – системное тестирование

В настоящее время трудозатраты составляют:

на стадиях разработки – 20%

и на сопровождение – 80%

Примерное распределение трудозатрат:

 
 

 
 

Рис. 1.2. Распределение трудозатрат при построении ИС

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

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

1.3.):

Рис. 1.3. Реальный процесс разработки ПО согласно каскадной схеме

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

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

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

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

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

Рис. 1.4. Спиральная модель ЖЦ


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


Дата публикования: 2014-10-25; Прочитано: 223 | Нарушение авторского права страницы



studopedia.org — Студопедия.Орг — 2014-2018 год.(0.002 с)…

Жизненный цикл разработки систем (Systems Development Life Cycle)

Опубликовано Вячеслав Аксёнов Июн 3, 2012

Разработка программного обеспечения (ПО) – это проект. Как в любом проекте при разработке ПО необходимо использовать формальную структуру управления проектами.
Software Engineering Institute (SEI) в 1991 году выпустил Capability Maturity Model (модель зрелости) для ПО (CMM или SW-CMM). CMM фокусируется на процессах менеджмента качества и имеет пять уровней зрелости, которые содержат несколько ключевых практик внутри каждого уровня зрелости. Пять уровней описывают эволюционный путь от хаотических процессов к зрелым, дисциплинированным процессам разработки ПО. CMM является основой для оценки надежности среды разработки.

3.1.1. Понятие и процессы жизненного цикла программного обеспечения

CMM может использоваться различных областях, включая обеспечение безопасности и системную интеграцию.
CMM предоставляет средства определения текущей зрелости организации, в сфере разработки ПО, и основные методы, для достижения целей по стоимости, времени, функциональности и качеству ПО. Модель устанавливает критерий, по которому можно судить о зрелости процесса разработки ПО в организации.Systems Development Life Cycle (SDLC) — инструмент управления проектами, который может использоваться для планирования, реализации и контроля проекта разработки ПО. Организация может использовать различные модели SDLC. Независимо от используемой модели, SDLC определяет основные фазы проекта разработки систем. Выбор модели должен основываться на проекте. Например, некоторые модели работают лучше с долгосрочными, комплексными проектами, в то время как другие больше подходят для краткосрочных проектов. Ключевым элементом является использование формализованной модели SDLC.
Число фаз (этапов) SDLC может отличаться от трех основных фаз (концепция, проектирование и реализация) и более.
Основные этапы SDLC (по материалам (ISC)2):

  • Инициирование проекта и планирование
  • Определение функциональных требований
  • Разработка технического задания
  • Разработка и реализация
  • Документирование и стандартные элементы управления программы
  • Тестирование и контроль, сертификация и аккредитация
  • Ввод в эксплуатацию

Жизненный цикл системы (system life cycle ) включает два дополнительных этапа:

  • Эксплуатация и техническое обслуживание (после установки)
  • Изменение, замена и/или удаление системы

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

Закрыть меню