Жизненный цикл программного обеспечения (стр. 3 из 4)
В ходе процесса реализации необходимо устанавливать правильность программы. Современные процедуры большей частью основаны на тестировании, хотя в последние годы расширилось использование методов сквозного структурного контроля и аттестации программ.
В любом случае, тестирование посредством исполнения программы обычно осуществляется снизу вверх, в начале на блочном (модульном или процедурном уровне), затем функционально, компонент за компонентом. По мере проверки отдельных компонентов они объединяются в систему в процессе ее компоновки, после чего начинаются системные испытания. В конечном итоге, после того как независимо будет удостоверено качество функционирования системы и оценены ее параметры, она считается готовой к выпуску.
1.2.3 Обслуживание
Процесс обслуживания начинается сразу после выпуска системы. Ошибки подлежат выявлению и исправлению. Если нормальной работе пользователя препятствует ошибка, то ошибочную программу можно временно исключить из системы или же внести временные или постоянные исправления в некоторые или во все используемые системы. Постоянное исправление или изменение можно затем внести в новый выпуск системы. Для того чтобы учесть все изменения и их комбинации, создаются многочисленные версии системных элементов. Главной задачей становится управление системной конфигурацией. Решающая роль в управлении программирования принадлежит вспомогательным службам, которые автоматически собирают и регулируют все изменения в системе.
Вывод к п.1.2.
Метасистема, в рамках которой развивается программа, содержит существенно большее количество контуров обратной связи, чем указано выше. Многие виды деятельности перекрываются, сложным образом переплетаются и систематически повторяются. Поэтому достаточно обоснована модель ЖЦПО представленная Боэмом.
1.3 Фазы и работы ЖЦПО по Боэму
Каскадная модель была введена в 70 – 80 гг. Она удобна для однородных ПП, когда каждое приложение представляло собой единое целое.
Основные характеристики модели:
- Жизненный цикл разбивается на этапы (фазы);
- Переход с этапа на этап – только после полного завершения текущего этапа;
- Этап завершается выпуском полного комплекта документации, достаточной для того, чтобы работа могла быть выполнена другой командой разработчиков.
Главные характерные черты каскадной модели следующие:
завершение каждой фазы верификацией и подтверждением, цель которых – устранить возможно большее число проблем, связанных с разработкой изделия;
циклические повторения реализованных фаз с возможно более ранней фазы.
Рис.2. Каскадная модель ЖЦПО.
В каскадной модели успешное окончание одной из фаз ЖЦПО означает достижение соответствующей цели инженерного программирования (см. п. 2.4.). К этим подцелям необходимо добавить еще две:
Детальная проектируемость – получение полных верифицированных спецификаций и структур управления и данных, интерфейсных связей, характеристик, основных алгоритмов и определение условий работы каждого программного компонента.
Кодируемость – получение полного, верифицированного набора компонентов программы.
Основные достоинства:
Формирование полного набора проектной документации в конце работы над этапом. Документация отвечает критериям полноты и завершенности;
Возможность планирования сроков и затрат. Для целого ряда ПП эта модель реализуема – это для систем, для которых на этапе анализа можно точно и полно сформировать все требования. Например, сложные вычислительные программы.
Основные недостатки:
- Большие сроки от анализа до завершения;
- Требования к ПО «заморожены» в виде ТЗ до конца разработки.
1.3.2 Экономическое обоснование каскадной модели
Не углубляясь в экономический анализ, которому Б.У. Боэм уделяет большое внимание в книге «Инженерное проектирование программного обеспечения», скажем лишь, что экономическое обоснование каскадной модели, ориентированной на последовательное достижение целей, базируется на двух главных предпосылках:
Для получения качественного программного изделия (т.е. такого, которое в полной мере удовлетворяет всем целям требуемого программного изделия) необходимо в любом случае осуществить все подцели на каждом этапе.
Любое другое упорядочение подцелей приводит к созданию менее качественного программного изделия.
1.3.3 Усовершенствование каскадной модели
Рассмотрим одно из усовершенствований идеальной каскадной модели – пошаговую разработку.
Пошаговая разработка является усовершенствованием метода повторной разработки с созданием прототипа и поуровневой разработкой сверху – вниз. Этот метод предполагает пошаговое увеличение функциональных возможностей ПО в процессе разработки.
В качестве усовершенствованной каскадной модели пошаговая разработка успешно применялась при создании как очень больших, так и небольших программных изделий.
Главными преимуществами пошаговой разработки перед абсолютно повторной разработкой и поуровневой разработкой сверху – вниз являются следующие:
использование последовательных расширений программы обеспечивает гораздо менее дорогой способ учета в усовершенствованном изделии опыта пользователей, чем при повторной разработке;
расширение функциональных возможностей намного упрощает проверку и полезнее, чем промежуточные изделия при поуровневой разработке.
Значение пошаговой разработки заключается главным образом в изменении распределения затрат труда на проект. Вариант каскадной модели при пошаговой разработке показан на рисунке 3.
1.3.4 Определение фаз жизненного цикла
Ниже будут даны формулировки конечных целей каждой фазы для перехода к следующей фазе. Для пошаговой разработки приводимые формулировки относятся к границам фаз каждого шага расширения.
Начать фазу планирования и анализа требований. (Завершение концептуального обзора ЖЦПО.)
Получение одобренной и подтвержденной архитектуры системы с включением основных соглашений о распределении функций между аппаратурой и программами. Получение одобренного и подтвержденного общего представления об функционировании ПО с включением основных соглашений о распределении функций между человеком и системой.
Формирование общего плана ЖЦПО с определением основных этапов, ресурсов, обязанностей, сроков и главных работ.
Завершить фазу планирования и анализа требований. Начать фазу проектирования изделия. (Завершение обзора требований к ПО).
Формирование детального плана разработки: детальных показателей завершения этапов разработки, планов распределения ресурсов, схем организационной структуры, обязанностей, сроков, работ, методов и изделий.
Формирование детального плана использования: пунктов плана разработки, содержание которых ориентировано на обучение, перенос программ, внедрение, эксплуатацию и поддержание.
Формирование детального плана отладки изделия – план управления конфигурацией технического обеспечения, план контроля качества, общий план верификации и подтверждения.
Одобренная и подтвержденная спецификация требований к ПО: функциональные, технические и интерфейсные спецификации, для которых подтверждены их полнота, непротиворечивость, проверяемость и осуществимость.
Одобренный (формально или неформально) договор на разработку, основанный на приведенных выше пунктах.
Закончить фазу проектирования изделия. Начать фазу детального проектирования. (Завершение анализа результатов проектирования изделия.)
Разработка верифицированной спецификации проекта программного изделия:
формирование иерархии программных компонентов, межблочных интерфейсов по данным и управлению;
формирование физической и логической структур данных до уровня отдельных полей;
разработка плана распределения вычислительных ресурсов (времени, памяти, точности);
верификация полноты, непротиворечивости, осуществимости и обоснованности требований.
Установление и разрешение всех противоречий разработки, которые повышают степень риска.
Разработка предварительного этапа комплексирования и отладки, плана руководства для пользователей и приемных испытаний.
Закончить фазу детального проектирования. Начать фазу кодирования и автономной отладки. (Завершение сквозного контроля проекта или критического поблочного анализа проекта.)
Верифицированная детальная спецификация каждого блока:
спецификация каждой подпрограммы, имени, назначения, предположений, размеров, последовательности вызовов, ошибочных выходов, входных и выходных данных, алгоритмов и логической схемы;
описание базы данных до уровня отдельных параметров, символов и битов;
верификация полноты, непротиворечивости и соответствия требованиям проектных спецификаций системы и планам распределения ресурсов.
Одобренный план приемных испытаний.
Руководства пользователю, а также завершенный предварительный план комплексирования и отладки.
Закончить фазу копирования и отладки. Начать фазу комплексирования и отладки. (Удовлетворение критериев автономной отладки.)
Проверка работы всех блоков не только для номинальных, но также для исключительных и предельных значений.
Проверка всех вариантов ввода и вывода, включая сообщения об ошибках.