Опубликован: 24.09.2008 | Уровень: специалист | Доступ: платный | ВУЗ: Московский физико-технический институт
Лекция 3:

Модели жизненного цикла для разработки программных систем

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >

Описание семантики задач и шагов процесса тестирования представлено в табл. 2.1.

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

Таблица 2.1. Состав задач процесса тестирования
Шаг процесса Задачи процесса тестирования
1. Создание группы тестирования 1.1. Определение участников процесса тестирования
1.2. Распределение обязанностей в группе и формирование плана тестирования
2. Анализ риска 2.1. Идентификация рисков
2.2. Упорядочение рисков
2.3. Распределение ресурсов
3. Определения целей тестирования 3.1. Идентификация целей тестирования
3.2. Определения критериев прохождения тестов
3.3. Приведения в порядок целей тестирования по оценкам риска
4. Разработка планов тестирования 4.1. Разработка плана тестирования ПС
4.2. Разработка плана интеграционного тестирования
4.3. Разработка плана автономного тестирования
4.4. Разработка плана комплексного тестирования
5. Разработка тестов 5.1. Проектирование и разработка тестов
5.2. Подготовка тестовых данных
5.3. Проверка тестовых документов
6. Автономное и интеграционное тестирование 6.1. Автономное тестирование модулей и анализ результатов
6.2. Интеграционное тестирование
6.3. Повторное тестирование после устранения дефектов
6.4. Анализ результатов интеграционного тестирования
7. Тестирования ПС 7.1. Утверждение среды и ресурсов тестирования
7.2. Тестирование ПС
7.3. Повторное тестирование ПС после устранения дефектов
7.4. Анализ результатов завершения тестирования ПС
7.5. Тестирование инсталляции ПС
8. Составление документа по тестированию ПС и подготовка отчета 8.1. Сбор и анализ данных о результатах тестирования
8.2. Подготовка решений и рекомендаций по использованию ПС
8.3. Подготовка итогового документа о результатах тестирования
8.4. Проверка решений и подготовка документа отчета

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

2.2. Типы моделей ЖЦ

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

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

Одной из первых стала применяться каскадная модель, в которой каждая работа выполняется один раз и в том порядке, как это представлено в модели (рис. 2.4).

Каскадная модель ЖЦ программных систем

увеличить изображение
Рис. 2.4. Каскадная модель ЖЦ программных систем

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

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

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

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

Недостатки этой модели:

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

При применении каскадной модели могут иметь место следующие факторы риска:

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

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

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

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

2.2.2. Инкрементная модель ЖЦ

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

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

увеличить изображение
Рис. 2.5. Инкрементная модель ЖЦ

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

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

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

При применении данной модели необходимо учитывать следующие факторы риска:

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

Данную модель ЖЦ целесообразно использовать, в случаях когда:

  • желательно реализовать некоторые возможности системы быстро за счет создания промежуточной версии продукта;
  • система декомпозируется на отдельные составные части, которые можно реализовывать как некоторые самостоятельные промежуточные или готовые продукты;
  • возможно увеличение финансирования на разработку отдельных частей системы.
< Лекция 2 || Лекция 3: 1234 || Лекция 4 >
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Александр Медов
Александр Медов

Здравствуйте, прошел курс МБА Управление ИТ-проектами и направил документы на получение диплома почтой. Подскажите, сроки получения оного в бумажной форме?

:

Татьяна Невокшонова
Татьяна Невокшонова
Россия
Кристина Языкова
Кристина Языкова
Россия, Москва, 1171, 2012