Файл: Информационный менеджмент.pdf

5.4.Модели жизненного цикла ПО

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

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

фазы:

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

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

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

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

Рис. 5.1. Общепринятая модель жизненного цикла ПО

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

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

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

65

проектной стадии. Но это уже отход от схемы общепринятой модели, который мы выполним в дальнейшем.

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

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

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

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

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

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

66

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

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

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

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

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

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

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

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

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

67

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

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

Распределение технических ресурсов и задание сроков их предоставления

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

68

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

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

5.4.3. Спиральная модель ЖЦ

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

Для преодоления этих недостатков используются инкрементная и эволюционная стратегии разработки ПО.

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

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

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

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

Модель расширения охвата прикладной области совсем не претендует на инструментальность. Поэтому обсуждать эти свойства для данной модели мы не будем.

69

Рис. 5.2. Классическая спиральная модель ЖЦ

5.5. Средства разработки сегодня

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

Средства управления требованиями

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

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

Из наиболее часто применяющихся в мире средств управления требова-

ниями следует отметить Rational Requisite Pro (IBM, www.ibm.com), Borland CaliberRM (Borland, www.borland.com) и Telelogic DOORS (Telelogic, www.telelogic.com). Эти продукты обладают теми или иными средствами интеграции с другими инструментами поддержки жизненного цикла приложений и позволяют генерировать различные документы, содержащие требования к продукту (например, техническое задание или его аналоги). Отметим, что указанные категории инструментов применяются, как правило, в компанияхразработчиках или в отделах разработки, хотя иногда заказчикам предоставляется упрощенный интерфейс для доступа к хранилищу требований (например, с помощью Web-интерфейса).

Средства моделирования бизнес-процессов, приложений и данных

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

70