Жизненный цикл программного средства

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

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

 

2.5 Программная документация

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

 

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

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

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

 

3 Определение ЖЦПО по Леману

 

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

 

3.1 Определение системы

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

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

 

3.2 Реализация

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

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

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

 

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

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

 

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

 

4 Фазы и работы ЖЦПО по Боэму

 

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

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

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

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

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

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

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

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

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

 

Рис.2. Каскадная модель ЖЦПО.

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

4.3 Усовершенствование каскадной модели

Рассмотрим  одно из усовершенствований идеальной  каскадной модели – пошаговую разработку.

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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