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

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО. Стандарт описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ любого конкретного ПО ЭИС определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Под стадией создания ПО понимается часть процесса создания ПО, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных компонентов, документации), определяемого заданными для данной стадии требованиями. Стадии создания ПО выделяются по соображениям рационального планирования и организации работ, заканчивающихся заданными результатами. В состав жизненного цикла ПО обычно включаются следующие стадии:

• 1. Формирование требований к ПО.
• 2. Проектирование.
• 3. Реализация.
• 4. Тестирование.
• 5. Ввод в действие.
• 6. Эксплуатация и сопровождение.
• 7. Снятие с эксплуатации.

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

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

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

построение моделей деятельности организации, предусматривающее обработку материалов обследования и построение двух видов моделей:

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

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

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

Переход от модели "AS-IS" к модели "ТО-ВЕ" может выполняться двумя способами:

• 1. Совершенствованием существующих технологий на основе оценки их эффективности.
• 2. Радикальным изменением технологий и перепроектированием бизнес-процессов (реинжиниринг бизнес-процессов).

Построенные модели имеют самостоятельное практическое значение. Например, модель "AS-IS" позволяет выявлять узкие места в существующих технологиях и предлагать рекомендации по решению проблем независимо от того, предполагается на данном этапе дальнейшая разработка ЭИС или нет. Кроме того, модель облегчает обучение сотрудников конкретным направлениям деятельности организации за счет использования наглядных диаграмм (известно, что "одна картинка стоит тысячи слов").

Стадия проектирования. Она, как правило, включает следующие этапы:

• * разработка системного проекта. На этом этапе дается ответ на вопрос: "Что должна делать будущая система?", а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели проектируемой ЭИС, которые строятся на основе модели "ТО-ВЕ". Документальным результатом этапа является техническое задание;
• * разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня.

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ISO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных стадиях.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ ПО: каскадная модель (1970-1985 гг.) и спиральная модель (1986-1990 гг.).

В однородных ЭИС 70-х и 80-х гг. прикладное ПО представляло собой единое целое. Для разработки такого типа ПО применялся каскадный подход (другое название - водопад (waterfall)) (рис. 1.3). Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания.

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

Преимущества применения каскадного способа заключаются в следующем:

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

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

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

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

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

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

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

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

Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 1.5). Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

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

И. Н. Скопин

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

Введение

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

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

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

Рис. 1. Разработка, использование и сопровождение программного обеспечения

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

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

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

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

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

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

1. Модели традиционного представления
о жизненном цикле

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

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

• разработка,
• сопровождение.

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

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

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

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

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

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

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

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

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

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

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

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

1.2. Классическая итерационная модель

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

Таковы мотивы классической итерационной модели жизненного цикла (рис. 3).

Рис. 3. Классическая итерационная модель

Стрелки, ведущие вверх, обозначают возвраты к предыдущим этапам, квалифицируемые как требование повторить этап для исправления обнаруженной ошибки. В этой связи может показаться странным переход от этапа « Эксплуатация и сопровождение» к этапу «Тестирование и отладка». Дело в том, что рекламации, предъявляемые в ходе эксплуатации системы, часто даются в такой форме, которая нуждается в их перепроверке. Чтобы понять, о каких ошибках идет речь в рекламации, разработчикам полезно предварительно воспроизвести пользовательскую ситуацию у себя, т.е. выполнить действия, которые обычно относят к тестированию.

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

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

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

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

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

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

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

Рис. 4. Каскадная модель

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

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

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

В ходе эксплуатации и сопровождения изделия устанавливается, насколько хорошо система соответствует пользовательским запросам, т.е. осуществляется переаттестация .

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

Рис. 5. Строгая каскадная модель

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

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

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

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

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

1.4. Модель фазы-функции

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

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

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

В модели Гантера отражено то, что выполнение функции на одном этапе может продолжаться и на следующем. На рис. 6 представлено фазовое измерение модели. Жирной чертой (с разрывом и стрелкой, обозначающей временное направление) изображен процесс разработки . Контрольные точки и наименования событий указаны под этой чертой. Они пронумерованы. Все развитие проекта в модели привязывается к этим контрольным точкам и событиям.

Рис. 6. Фазовое измерение модели фазы-функции

В данной модели жизненный цикл распадается на следующие перекрывающие друг друга фазы (этапы):
• исследования - этап начинается, когда необходимость разработки признана руководством проекта (контрольная точка 0), и заключается в том, что для проекта обосновываются требуемые ресурсы (контрольная точка 1) и формулируются требования к разрабатываемому изделию (контрольная точка 2);
• анализ осуществимости - начинается на фазе исследования, когда определены исполнители проекта (контрольная точка 1), и завершается утверждением требований (контрольная точка 3). Цель этапа - определить возможность конструирования изделия с технической точки зрения (достаточно ли ресурсов, квалификации и т.п.), будет ли изделие удобно для практического использования, ответить на вопросы экономической и коммерческой эффективности;
• конструирование - этап начинается обычно на фазе анализа осуществимости, как только документально зафиксированы предварительные цели проекта (контрольная точка 2), и заканчивается утверждением проектных решений в виде официальной спецификации на разработку (контрольная точка 5);
• программирование - начинается на фазе конструирования, когда становятся доступными основные спецификации на отдельные компоненты изделия (контрольная точка 4), но не ранее утверждения соглашения о требованиях (контрольная точка 3). Совмещение данной фазы с заключительным этапом конструирования обеспечивает оперативную проверку проектных решений и некоторых ключевых вопросов разработки. Цель этапа - реализация программ компонентов с последующей сборкой изделия. Он завершается, когда разработчики заканчивают документирование, отладку и компоновку и передают изделие службе, выполняющей независимую оценку результатов работы (независимые испытания начались - контрольная точка 7);
• оценка - фаза является буферной зоной между началом испытаний и практическим использованием изделия. Она начинается, как только проведены внутренние (силами разработчиков) испытания изделия (контрольная точка 6) и заканчивается, когда подтверждается готовность изделия к эксплуатации (контрольная точка 9);
• использование - начинается в ходе передачи изделия на распространение и продолжается, пока изделие находится в действии и интенсивно эксплуатируется. Этап связан с внедрением, обучением, настройкой и сопровождением, возможно, с модернизацией изделия. Он заканчивается, когда разработчики прекращают систематическую деятельность по сопровождению и поддержке данного программного изделия (контрольная точка 10).

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

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

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

Модель учитывает соотношение технологических функций и фаз жизненного цикла, чем она выгодно отличается от простых (или ограниченных?) ранее рассмотренных «идеальных» моделей. По-видимому, простота-ограни­ченность «идеальных» моделей есть следствие отождествления выделяемых этапов с технологической операцией, преобладающей при их выполнении. В то же время, задача отражения итеративности в модели Гантера в явном виде не предусматривается. Хотя само по себе перекрытие смежных фаз проекта и выпуск соответствующей событиям документации - путь к минимизации возвратов к выполненным этапам, более содержательные средства описания итераций в модель не закладываются.

Рис. 7. Матрица фазы-функции модели Гантера

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

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

Рис. 8. Учет итеративности в модели фазы-функции (фазовое измерение, показаны лишь некоторые возвраты)

2. Объектно-ориентированные модели
жизненного цикла

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

2.1. Принципы объектно-ориентированного проектирования

Принципиальные моменты, в которых объектно-ориентированный подход к развитию проектов стоит сопоставить с традиционными последовательными методологиями, сводятся к следующему:

• Итеративность развития.

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

• Наращивание функциональности в соответствии со сценариями.

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

• Ничто не делается однократно.

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

• Оперирование на размножающихся фазах подобно.

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

При объектно-ориентированном проектировании в ходе итеративного наращивания обыкновенно выполняются вполне традиционные этапы:

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

2.2. Модификация модели фазы-функции

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

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

• Распределение реализуемых требований по итерациям.

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

• Особый стиль наращивания возможностей системы и ее развития.

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

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

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

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

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

Рис. 9. Фазовое измерение модели жизненного цикла при объектно-ориентированном развитии проекта

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

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

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

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

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

• выделение общих (т.е. непривязанных к проекту) переиспользуемых компонентов (обычно эти работы связываются с событием передачи системы на распространение - контрольная точка 10).

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

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

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

Рис. 10. Модель фазы-функции, модифицирования для объектно-ориентированного развития проекта

2.3. Параллельное выполнение итераций

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

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

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

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

Одновременность выполнения разных итераций можно представить в виде схем, показанных на рис. 11.

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

Рис. 11 б) демонстрирует три одновременно выполняемые итерации: вторая начинается в ходе выполнения программирования первой итерации с таким расчетом, чтобы ее этап программирования начался после окончания тестирования первой итерации. Планирование третьей итерации начинается одновременно с этапом программирования второй итерации.

Рис. 11. Распараллеливание выполнения итераций проекта

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

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

2.4. Моделирование итеративного наращивания
возможностей системы

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

Рис. 12. Спираль развития объектно-ориентированного проекта

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

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

Рис. 13. Модель расширения охвата прикладной области объектно-ориентированной системой

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

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

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

Из сборника "Новосибирская школа программирования. Перекличка времен" . Новосибирск, 2004 г.
Перепечатываются с разрешения редакции.

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

Одним из базовых понятий методологии проектирования ПО является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ним документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

· вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

1. Каскадная модель (до 70-х годов XX в) определяет последовательный переход на следующий этап после завершения предыдущего.

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

Достоинство : хорошие показатели по срокам разработки и надежности при решении отдельных задач.

Недостаток : неприменимость к большим и сложным проектам из-за изменчивости требований к системе в течение длительного проектирования.

2. Итерационная модель (70-80-е годы XX в.) соответствует технологии проектирования «снизу - вверх». Допускает итерационные возвраты на предыдущие этапы после выполнения очередного этапа;

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

Достоинство: возможность оперативно вносить коррективы в проект.

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

3. Спиральная модель (80-90-е годы XX в.) соответствует технологии проектирования «сверху - вниз». Предполагает использование программного прототипа, допускающего программное расширение. Проект системы циклически повторяет путь от детализации требований к детализации программного кода.

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

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

Достоинства:

1. сокращение число итераций и, следовательно, число ошибок и несоответствий, которые необходимо исправлять;

2. сокращение сроков проектирования;

3. упрощение создания проектной документации.

Недостаток: высокие требования к качеству общесистемного репозитория (общей базы проектных данных).

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

· Анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области.

· Проектирование. Пользователи под руководством разработчиков принимают участие в техническом проектировании.

· Конструирование. Разработчики проектируют рабочую версию ПО с использованием языков 4-го поколения;

· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.

Лекция 2.

Понятие жизненного цикла и модели жизненного цикла. Каскадная модель ЖЦ. Поэтапная модель с промежуточным контролем. Спиральная модель ЖЦ . Процессы ЖЦ ПО . Rapid Application Development(RAD). Extreme Programming (XP). Rational Unified Process (RUP). Microsoft Solution Framework (MSF). Custom Development Method (методика Oracle).

2.1. Понятие жизненного цикла и модели жизненного цикла

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

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

Модель ЖЦ ПО включает в себя (слайд 3) :стадии, результаты выполнения работ на каждой стадии, ключевые события - точки завершения работ и принятия решений.

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

Крайним случаем модели ЖЦ можно считать так называемую модель «черного ящика» (black box) или «code and fix» (кодиро­вание и исправление), что фактически означает отсутствие ка­кой-либо модели. В этом случае выделить какие-либо рациональные стадии в процессе разработки ПО не представля­ется возможным, поскольку отсутствует планирование и органи­зации работ.

В настоящее время известны и используются следующие модели жизненного цикла:

Каскадная модель (характерна для периода 1970-1980 гг.);

Поэтапная модель с промежуточным контролем (характерна для периода 1980-1985 гг.);

Спиральная модель (характерна для периода после 1986 г.)

2.2. Каскадная модель жц

В1970 г. эксперт в области ПО Уинстон Ройс опубликовал по­лучившую широкую известность статью, в которой он излагал свое мнение о методике, которая позднее получила название «модель водопада» (waterfall model), или «каскадная модель» (слайд 4) .

Впосле­дствии эта модель была регламентирована множеством норма­тивных документов, в частности, широко известным стандартом Министерства обороны США Dod-STD-2167A и российскими стандартами серии ГОСТ 34.

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

Принципиальными свойствами так называемой «чистой» каскадной модели являются следующие:

Фиксация требований к системе до ее сдачи заказчику;

Последовательное выполнение этапов.

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

Отсутствие временного перекрытия этапов

Отсутствие возврата к предыдущим этапам

Наличие результата только в конце разработки.

Преимущества применения каскадной модели заключаются в следующем:

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

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

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

Другими недостатками каскадного подхода являются:

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

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

избыточное количество документации;

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

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

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

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

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

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

1. Инженерный подход
2. С учетом специфики задачи
3. Современные технологии быстрой разработки

Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.

Модель кодирования и устранения ошибок

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.
Данная модель имеет следующий алгоритм:

1. Постановка задачи
2. Выполнение
3. Проверка результата
4. При необходимости переход к первому пункту

Модель также ужасно устаревшая. Характерна для 1960-1970 гг., по-этому преимуществ перед следующими моделями в нашем обзоре практически не имеет, а недостатки на лицо. Относится к первой группе моделей.

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

Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.

Преимущества:

• Последовательное выполнение этапов проекта в строгом фиксированном порядке
• Позволяет оценивать качество продукта на каждом этапе

Недостатки:

• Отсутствие обратных связей между этапами
• Не соответствует реальным условиям разработки программного продукта

Относится к первой группе моделей.

Каскадная модель с промежуточным контролем (водоворот)

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

V модель (разработка через тестирование)

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

Модель на основе разработки прототипа

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

1. Прояснить не ясные требования (прототип UI)
2. Выбрать одно из ряда концептуальных решений (реализация сцинариев)
3. Проанализировать осуществимость проекта

Классификация протопипов:

1. Горизонтальные и вертикальные
2. Одноразовые и эволюционные
3. бумажные и раскадровки

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

Модель принадлежит второй группе.

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

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

Преимущества:

• Быстрое получение результата
• Повышение конкурентоспособности
• Изменяющиеся требования - не проблема

Недостатки:

• Отсутствие регламентации стадий

Третьей группе принадлежат такие модели как экстремальное программирование (XP), SCRUM , инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике.

Большое спасибо за внимание!