Модели жизненного цикла проекта по разработке информационных систем

Модели жизненного цикла проекта по разработке информационных систем

Основные понятия

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

Жизненный цикл автоматизированной системы (АС) – совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990].

Модель жизненного цикла – структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999].

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

Структура жизненного цикла программного обеспечения по стандарту ISO/IEC 12207

базируется на трех группах процессов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эксплуатация системы (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании системы, исправление ошибок и недоработок, оформление требований к модернизации системы и ее выполнение.

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

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

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

концепция (инициация, идентификация, отбор);

определение (анализ);

выполнение (практическая реализация или внедрение, производство и развертывание, проектирование или конструирование, сдача в эксплуатацию, инсталляция, тестирование и т.п.);

закрытие (завершение, включая оценивание после завершения).

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

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

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

Каскадная (водопадная) модель

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

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

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

Этапы приведены на рисунке 1.

Принципы каскадной модели:

строго последовательное выполнение стадий;

технические задания являются основой модели;

каждая стадия полностью документируется;

в качестве критерия качества выбирается точность выполнения спецификаций ТЗ;

переход от одной фазы проекта к другой предполагает полную корректность результата

(выхода) предыдущей фазы.

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

четкое планирование сроков и затрат, наличие временного графика выполнения проекта;

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

каждая стадия может выполняться отдельной командой. Недостатки модели:

в некоторых случаях составить ТЗ не удается;

запаздывание с получением результатов;

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

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

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

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

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

составление плана действий по разработке системы;

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

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

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

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

План Спецификация

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

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

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

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

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

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

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

Достоинствами эволюционного подхода на основе организации итераций является:

снижение неопределенности с завершением каждой итерации;

уменьшение рисков проекта;

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

дополнительные сложности при управлении проектом и отслеживании его хода;

сложность (сравнительно с каскадной моделью) адекватной оценки текущего состояния проекта и долгосрочного планирования;

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

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

Рис. 1.2. Итеративная модель разработки

2. 2. 1. Спиральная модель

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

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

Основной отличительной особенностью этой модели является общая структура действий на каждой итерации. Выделяют четыре квадранта спирали:

планирование – определение (уточнение) целей, задач, вариантов решения и ограничений, сбор требований, в том числе на основе рекомендаций заказчика;

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

конструирование и выполнение основных работ итерации;

оценивание заказчиком текущих результатов конструирования.

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

Ниже приведем особенности спиральной модели, описанные Боэмом:

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

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

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

дефицит специалистов;

нереалистичные сроки и бюджет;

реализация несоответствующей функциональности;

разработка неправильного пользовательского интерфейса;

“Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей;

непрекращающийся поток изменений;

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

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

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

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

Существует 6 ключевых характеристик или практик, обеспечивающих успешное применение спиральной модели:

параллельное, а не последовательное определение артефактов (активов) проекта;

согласие в том, что на каждом цикле уделяется внимание:

oцелям и ограничениям, важным для заказчика;

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

o идентификации и разрешению рисков;

o оценки со стороны заинтересованных лиц (в первую очередь заказчика);

oдостижению согласия в том, что можно и необходимо двигаться дальше;

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

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

управление жизненным циклом в контексте обязательств всех заинтересованных лиц;

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

Следующие особенности модели являются причиной ее широкого применения.

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

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

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

лах” спирали разработки. Например, ограничения по безопасности могут рассматри- ваться как риски на этапе специфицирования требований.

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

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

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

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

Преимущества спиральной модели:

уточнение требований на каждой итерации;

участие заказчика в разработке;

возможность планирования и управления рисками;

обоснованность выбранного варианта;

необязательное завершение стадий;

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

Недостатки спиральной модели:

сложность

o выбора времени перехода на следующую итерацию;

oустановки границ итераций;

oподдержки версий (хранение, возврат, комбинация);

o оценки рисков и сроков;

бесконечность;

переход на каскадную модель.

Данную модель необходимо применять в следующих случаях:

большой объем проектных работ;

пользователь не уверен в требованиях либо требования слишком сложные;

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

нужна мотивация роста затрат на проект;

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

присутствует высокая степень риска проекта.

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

Характеристики методологии RAD:

небольшая команда программистов (от 2 до 10 человек);

короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

фаза анализа и планирования требований;

фаза проектирования;

фаза построения;

фаза внедрения.

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

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

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

общая информационная модель системы;

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

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

построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств,

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

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

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

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

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

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

производится анализ использования данных;

производится физическое проектирование базы данных;

определяются требования к аппаратным ресурсам;

определяются способы увеличения производительности;

завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

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

централизованное сопровождение;

адаптируемость к программно-техническим платформам, СУБД, средствам телекоммуникации;

организационно - экономические особенности объектов внедрения;

интегрируемость с существующими разработками.

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

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

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

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

К основным принципам методологии RAD относятся:

разработка приложений итерациями;

необязательность полного завершения работ на каждом из этапов жизненного цикла;

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

необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

необходимое использование генераторов кода;

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

тестирование и развитие проекта, осуществляемые одновременно с разработкой;

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

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

Унифицированный процесс Rational

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

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

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

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

Фаза передачи (Transition). Цель этой фазы – сделать систему полностью доступной ко- нечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей.

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

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

Определение требований (Requirements). Цели – понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок ресурсозат- рат в нем. Требования принято фиксировать в виде модели вариантов использования (use cases).

Анализ и проектирование (Analysis and Design). Цели – выработать архитектуру систе- мы на основе требований, убедиться, что данная архитектура может быть основой рабо- тающей системы в контексте ее будущего использования. В результате проектирования должна появиться проектная модель, включающая диаграммы классов системы, диа- граммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализа- ции вариантов использования, диаграммы состояний для отдельных объектов, и диа- граммы развертывания.

Реализация (Implementation). Цели – определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в рабо- тающее целое

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

Развертывание (Deployment). Цели – развернуть систему в ее рабочем окружении и оце- нить ее работоспособность

Управление конфигурациями и изменениями (Configuration and Change Management). Цели – определение элементов, подлежащих хранению и правил построения из них со- гласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений

Управление проектом (Project Management). Цели – планирование, управление персона- лом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта

Управление средой проекта (Environment). Цели – подстройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте

Первые пять деятельностей считаются рабочими, остальные — поддерживающими.

Распределение объемов работ в ходе проекта выглядит примерно так.

Основные техники, используемые в RUP таковы

выработка концепции проекта (project vision) в самом его начале для четкой постановки задач;

управление по плану;

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

тщательное экономическое обоснование всех действий, делается только то, что нужно заказчику;

выявление требований и их фиксация в виде вариантов использования (use cases);

формирование базовой архитектуры как можно раньше;

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

прототипирование, инкрементная разработка и тестирование;

регулярные оценки текущего состояния;

управление изменениями, постоянная отработка изменений извне проекта;

создание продукта, работоспособного в реальном окружении;

нацеленность на качество;

адаптация процесса под нужды проекта.

Современные подходы к разработке информационных систем

Методология объектно-ориентированного проектирования UML

Язык UML (Unified Modeling Language) представляет собой унифицированный язык визуального моделирования, который разработан для специфицирования (создания спецификации), конструирования, визуализации, и документирования артефактов программных систем – компонентов программного обеспечения, бизнес-процессов и т.д. Артефактами, в контексте проектирования на UML, можно называть принятые в процессе анализа и проектирования решения, которые определенным образом визуализированы с помощью различных диаграмм, условных обозначений на диаграммах и различных связей между этими обозначениями. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. При этом UML и поддерживающие его инструменты – это не самоцель; UML предполагает, но не обязывает использование определенных методологий при объектно-ориентированном анализе и процессов при объектно-ориентированном проектировании.

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

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

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

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

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

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

вариантов использования (use case);

классов (class);

поведения (behavior):

состояний (statechart);

деятельности (activity);

взаимодействия (interaction):

последовательности (sequence);

кооперации (collaboration);

реализации (implementation):

компонентов (component);

развертывания (deployment).

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

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

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

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

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

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

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

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

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

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

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

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

Описание автоматизированной системы ведения проекта по методологии UML

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

75

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

Рис. 4.12 Диаграмма вариантов использования

Подготовил Тонких Артём Петрович