Определение понятия ЖЦ разработки по

 

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

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

 

 

Рис. 1.3. Обобщенная фаза процесса

 

 

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

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

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

Стандарт ISO/IEC 12207

Институт программного инжиниринга (SEI) - не единственная организация, которая занимается вопросами обеспечения качества или стандартов и изучением процессов разработки ПО и жизненных циклов. Еще в 1989 году было признано, что стандарт, предложенный военным и другим правительственным подрядчикам, и называемый стандартом Министерства обороны США (Department of Defense Standard — 2167A) не подходил в достаточной мере для использования в проектах, в которых были задействованы методы объектно-ориентированного проектирования (Object-oriented design, OOD) или быстрой разработки приложений (Rapid Application Development, RAD).

Создание нового военного стандарта 498 (Military Standard, MIL STD) было направлено на обеспечение качества разработки проектов. Международная организация по стандартизации (I nternational O rganization for S tandardization, ISO/IEC) разработала стандарт12207. IEC - International Electromechanical Commission - Международная комиссия по электротехнике. При использовании этого стандарта описываются основные процессы, составляющие полный жизненный цикл разработки ПО, связующие звенья между ними, а также отношения на высшем уровне, управляющие их взаимосвязи.

В стандарте ISO/IEC 12207 перечислены 12 действий по инжинирингу, следующих за реализацией процесса, которые аналогичны фазам, составляющим типичную модель жизненного цикла:

1) анализ системных требований;

2) проектирование архитектуры системы;

3) анализ программных требований;

4) разработка проекта программной архитектуры;

5) рабочий план разработки ПО;

6) кодирование ПО;

7) интеграция ПО;

8) тестирование ПО;

9) интеграция системы;

10) тестирование системы;

11) установка ПО;

12) тестирование и приемка ПО.

Приведенный выше метод ISO/IEC 12207 описан как реализация цикла, построенного по принципу "планирование-реализация-проверка-действие".

Суть описанного выше метода заключается в том, что инженер сначала проверяет данные, полученные в результате выполнения инженерной задачи, прежде чем использовать их в качестве исходных для выполнения следующей задачи. Действия, составляющие процесс разработки ПО стандарта ISO/IEC 12207, не зависят друг от друга, они не упорядочены по принципу каскадной модели, и в международном стандарте отсутствуют требования, которые диктуют последова-тельность их выполнения. На самом деле, в стандарте ISO/IEC 12207 четко указано, что "эти действия и задачи могут перекрываться или взаимодействовать, а также могут выполняться многократно или рекурсивно". Далее "этот международный стандарт не предписывает какую-либо определенную модель жизненного цикла или метод разработки ПО". Также указывается, что если используемая модель не оговорена в контракте в качестве особого условия, "разработчику предстоит определить или выбрать модель жизненного цикла разработки, которая соответствует размеру и сложности данного проекта. Действия и задачи процесса разработки предстоит выбрать, а затем сопоставить с моделью жизненного цикла". Жизненный цикл ПО – непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации. Назначение и цель языка, используемого в международном стандарте, заключается в том, чтобы обеспечить гибкость при установке очередности действий, а также в выборе моделей разработки во избежание каскадного смещения других стандартов.

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

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

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

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

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

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

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

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

Первая редакция стандарта ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1 "Информационные технологии, подкомитет SC7, проектирование программного обеспечения". ISO 12207:1995 - базовый стандарт процессов жизненного цикла программного обеспечения, ориентированный на различные (любые!) виды ПО и типы проектов автоматизированных систем (АС) или информационных систем, в которые ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО. Он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

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

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

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

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

В стандарте описаны 5 основных процессов ЖЦ ПО:

1. Процесс приобретения определяет действия предприятия покупателя, которое приобретает АС, программный продукт или сервис ПО.

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

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

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

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

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

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

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

Примеры:

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

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

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

Такой характер позволяет реализовывать любую модель ЖЦ.

Степень адаптивности стандарта - максимальная. Множество процессов и задач сконструиро-вано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения этапов, видов деятельности и задач, не применимых в конкретном проекте.

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

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

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

- была рассмотрена область применения системы;

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

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

При этом разработчик должен установить и документировать в качестве требований к программному обеспечению:

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

б) внешние связи (интерфейсы) с единицей программного обеспечения;

в) требования квалификации;

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

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

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

ж) типы данных и требования к базе данных;

з) требования установки и приемки поставляемого программного продукта в местах его функционирования и сопровождения (эксплуатации);

и) требования к документация пользователя;

к) требования к работе пользователя и требования к выполнению ПО;

л) требования к сервису пользователя.

(Интересно и важно то, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ 34 по видам обеспечения системы).

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

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

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

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

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

Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать БД вовсе.

 

 

Модели ЖЦ разработки ПО

 

Как правило, менеджмент качества программных проектов основывается на знаниях из трех источников: программный инжиниринг, менеджмент проекта и качество. Институт программного инжиниринга (SEI, Software Engineering Institute) в Университете Карнеги Мэллон объединяет все эти три источника. Модель зрелости функциональных возможностей (Capability Maturity Model, СММ), служит "каркасом" процесса разработки ПО.

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

Уровни модели СММ:

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

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

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

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

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

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

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

 

 

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

 

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

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

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

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

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

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

При этом персонал должен владеть необходимыми умениями и опытом в работе с данной технологией. Ставшее классикой произведение Фреда Брукса (Fred Brooks) под названием "Мифический человек-месяц" (The Mythical Man-Month) сегодня столь же актуально, как и в 1975 году. Технологии радикально изменили мир, но многие недостатки менеджмента программных проектов по-прежнему те же. Десятки лет тому назад Брукс сказал: "В большинстве проектов первая построенная система едва ли пригодна к употреблению. Она может быть слишком медленной, слишком объемной, неудобной в использовании или обладать всеми тремя перечисленными недостатками. Нет другого выбора, кроме как начать с самого начала, приложив все усилия, и построить модернизированную версию, в которой решались бы все три проблемы... В случае, когда в проекте используется новая системная концепция или новая технология, разработчик вынужден построить систему, которой впоследствии не воспользуется, поскольку даже при наилучшем планировании невозможно предвидеть достижение нужного результата. Следовательно, вопрос менеджмента заключается не в том, создавать или нет экспериментальную систему, которой затем не воспользуются. Вы в любом случае так и сделаете. Единственный вопрос в том, нужно ли планировать создание продукта одноразового использования заранее или обещать поставить его заказчикам...". Именно эта концепция построения экспериментальной, или прототипной системы привела к возникновению "структурной", "эволюционной" модели быстрого прототипирования (RAD), и спиральной модели.

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

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

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

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

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

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

· требования не известны заранее;

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

· следует уточнить требования;

· существует потребность в разработке пользовательских интерфейсов;

· нужна проверк