Общепринятая модель

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

• разработка;

• сопровождение.

Фазы разбиваются на ряд этапов (см рис. 5.1).

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

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

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

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

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

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

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

Фаза разработки заканчивается этапом тестирования (автономного и комплексного) и передачей системы в эксплуатацию - следующие два этапа.

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

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

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

Календарный план как модель жизненного цикла программного обеспечения

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

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

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

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

Распределение времени и контроль над ним - назначение столбцов 2 и 3. В них указываются календарные даты планируемого (столбец 2) и фактического (столбец 3) сроков выполнения работы, задачи или задания.

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

Столбец 4 «Ответственный исполнитель и исполнители, роли» задает информацию о том, кто работает над данным заданием и какая квалификация от исполнителей требуется. Возможно дополнение этого столбца сведениями о том, на какой период выделен тот или иной исполнитель для выполнения задания, предполагается ли замена исполнителей и т. п.

Распределение технических ресурсов и задание сроков их предоставления - содержание столбца 5. Здесь указывается необходимая для выполнения задания техническая, а в ряде случаев и программная база. Иногда этот раздел дополняется сведениями о лицах, отвечающих за выполнение указываемых требований. Это удобно как для менеджера, так и для ответственных исполнителей: наглядно видны нарушения поставок (несоответствия между плановыми и фактическими сроками). Полезным расширением состава сведений столбца 5 является включение в него информации о зависимости работ внутри проекта, т. е. перечисление заданий (в том числе, ссылки на другие строки данного календарного плана), без выполнения которых осуществимость планируемых работ нарушается. Отслеживание зависимостей работ - это более содержательная задача выполнения проекта по сравнению с тем, что можно получить через только что указанное расширение календарного плана, и ей в дальнейшем будет уделено внимание. Схема календарного плана пытается охватить все аспекты, которые нужно учитывать при выделении работ и отслеживании сроков их выполнения. Однако абсолютной точности здесь добиться не удается. Рассмотренные и другие подобные расширения схемы призваны компенсировать недостающие элементы технологии управления. В частности, они иллюстрируют возможность вынесения на уровень работы с календарным планом элементов сетевого планирования и оперативного использования их в управленческой деятельности. Но предусмотреть расширения схемы так, чтобы полностью удовлетворить все потребности управления в статической картине календарного плана, просто невозможно. Поэтому таблица плана предусматривает столбец примечаний, который заполняется по мере необходимости в свободной форме.

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