PosobieASOIU0_5

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

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

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

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

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

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

представление, в котором все составляющие компоненты согласованы.

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

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

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

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

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

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

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

2МоделижизненногооццииккллааппррооееккттааппооррааззррааббооттккееААССООИИУУ

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

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

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

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

Основным нормативным документом, регламентирующим жизненный цикл программного обеспечения, является международный стандарт ISO/IEC 12207 (ISO - International

Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission -

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

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

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

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

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

самого жизненного цикла, обучение).

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

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

Управление проектом [12, 41, 47] связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта

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

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

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

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

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

Можно выделить следующие типовые стадии жизненного цикла АСОИУ:

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

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

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

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

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

Каждый этап сопровождается разработкой соответствующей

отчетной документации, например, различного рода спецификаций. В

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

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

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

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

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

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

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

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

Эффективная организация жизненного цикла АСОИУ помогает успешно координировать проект и обеспечить требуемое качество

системы. Ниже кратко описаны наиболее популярные модели (парадигмы) организации разработки АСОИУ.

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

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

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

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

Этапы приведены на рисунке 1. Принципы каскадной модели:

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

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

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

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

•переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы.

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

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

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

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

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

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

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

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

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

•низкая адаптивность проекта к изменениям требований в процессе разработки системы.

Марри Кантор отмечает ряд важных аспектов, характерных для

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

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

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

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

Фредерик Брукс во втором издании своего классического труда

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

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

Планирование

План Формирование требований

Спецификация

Анализ

Техническое решение Проектирование

Продукт Эксплуатация

Рис. 1.1. Каскадная модель проекта

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

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

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

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

•существующая автоматизированная системы, характеристики

которой позднее должны быть улучшены.

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

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

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

2.3 Итеративная (эволюционная) модель

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатками модели являются:

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

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

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

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

Версия N

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

2.4 Спиральная модель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• различие в квалификации специалистов разных областей знаний. Существует 6 ключевых характеристик или практик,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•сложность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.Генерация приложения. Предполагается использование методов, ориентированных на языки 4-го поколения.

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

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

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

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

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

взаимодействии с заказчиком.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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