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

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

 

 

Реализация

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

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

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

Обслуживание

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

Фазы и работы жизненного цикла ПО по Боэму.

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

Каскадная модель была введена в 70 – 80 гг. Она удобна для однородных ПП, когда каждое приложение представляло собой единое целое.

Основные характеристики модели:

- Жизненный цикл разбивается  на этапы (фазы);

- Переход с этапа  на этап – только после полного  завершения текущего этапа;

- Этап завершается  выпуском полного комплекта документации, достаточной для того, чтобы работа  могла быть выполнена другой  командой разработчиков.

Главные характерные  черты каскадной модели следующие:

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

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

 

 

Рис.2. Каскадная модель жизненного цикла ПО.

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

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

Кодируемость – получение  полного, верифицированного набора компонентов программы.

Основные достоинства:

Формирование полного  набора проектной документации в  конце работы над этапом. Документация отвечает критериям полноты и  завершенности;

Возможность планирования сроков и затрат. Для целого ряда ПП эта модель реализуема – это  для систем, для которых на этапе анализа можно точно и полно сформировать все требования. Например, сложные вычислительные программы.

Основные недостатки:

- Большие сроки от  анализа до завершения;

- Требования к ПО  «заморожены» в виде ТЗ до  конца разработки.

Экономическое обоснование каскадной модели

Не углубляясь в экономический  анализ, которому Б.У. Боэм уделяет большое  внимание в книге «Инженерное  проектирование программного обеспечения», скажем лишь, что экономическое обоснование  каскадной модели, ориентированной  на последовательное достижение целей, базируется на двух главных предпосылках:

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

Любое другое упорядочение подцелей приводит к созданию менее  качественного программного изделия.

Определение фаз жизненного цикла

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

Начать фазу планирования и анализа требований. (Завершение концептуального обзора жизненного цикла ПО.)

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

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

Завершить фазу планирования и анализа требований. Начать фазу проектирования изделия. (Завершение обзора требований к ПО).

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

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

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

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

Одобренный (формально  или неформально) договор на разработку, основанный на приведенных выше пунктах.

Закончить фазу проектирования изделия. Начать фазу детального проектирования. (Завершение анализа результатов  проектирования изделия.)

Разработка верифицированной спецификации проекта программного изделия:

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

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

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

верификация полноты, непротиворечивости, осуществимости и обоснованности требований.

Установление и разрешение всех противоречий разработки, которые  повышают степень риска.

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

Закончить фазу детального проектирования. Начать фазу кодирования  и автономной отладки. (Завершение сквозного  контроля проекта или критического поблочного анализа проекта.)

Верифицированная детальная  спецификация каждого блока:

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

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

верификация полноты, непротиворечивости и соответствия требованиям проектных  спецификаций системы и планам распределения  ресурсов.

Одобренный план приемных испытаний.

Руководства пользователю, а также завершенный предварительный  план комплексирования и отладки.

Закончить фазу копирования  и отладки. Начать фазу комплексирования и отладки. (Удовлетворение критериев  автономной отладки.)

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

Проверка всех вариантов  ввода и вывода, включая сообщения  об ошибках.

Выполнение всех операторов и всех ветвей передачи управления.

Проверка выполнения стандартов программирования.

Завершение поблочного документирования внутренней структуры.

Закончить фазу комплексирования и испытаний. Начать фазу внедрения. (Завершение анализа результатов приемных испытаний.)

Проверка удовлетворения тесту приемных испытаний программ:

проверка удовлетворения требованиям к ПО;

демонстрация приемлемости указанных в спецификациях характеристик работы в нештатных условиях.

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

Закончить фазу внедрения. Начать фазу эксплуатации и сопровождения. (Завершение анализа приемки системы.)

Проверка удовлетворительности результатов приемных испытаний  системы.

Проверка удовлетворительности системных требований.

Проверка производственной готовности ПО, аппаратуры, средств  обслуживания и персонала.

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

Завершение всех специфицированных  работ и ввод системы в действие.

Закончить фазу эксплуатации и сопровождения (путем снятия с  производства).

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

Вывод

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

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

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

Важно так же, при составлении  программы, учитывать то, что программа  должна быть точной; полной по своему содержанию и пригодной для работы как с маленькими, так и с большими проблемами в соответствии со своим предназначением; ясной - для того чтобы пользователь мог спокойно, без затруднений работать с ней. А так же чтобы программу в любой момент можно было бы легко исправить или дополнить в соответствии с изменившимися требованиями в современном мире.

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

Практическое задание.

Краткое словесное описание метода решения поставленной задачи:

Задача: «Элементы вещественного массива размером  N содержат результаты забега на 100 м N спортсменов, измеренные в сек. Составить команду из четырёх лучших бегунов для участия в эстафете 4х100 (указать номера четырёх спортсменов).»

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

const int N = 10;,

 так же, как и  показатели N-ного числа спортсменов о времени преодоления расстояния в сто метров

double a[N] = {7.42, 6.11, 5.22, 5.19, 8.00, 5.43, 4.99, 6.55, 7.23, 8.76};,

используя тип данных для массива а[N] double для обозначения в нём чисел с двумя знаками после запятой( как это принято у спортсменов для обозначении времени преодоления дистанции).