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