Содержание:
Введение
Rational Unified Process (RUP)– это процесс разработки программного обеспечения. Его цель состоит в том, чтобы гарантировать высокое качество программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого графика и бюджета выполнения. RUP обеспечивает строгий подход к решению задач проектирования и ответственности разработчиков.
Rational Unified Process – это итеративный процесс (так называемая спиральная модель жизненного цикла разработки). Каждая итерация может приводить к созданию фрагмента разрабатываемой системы или новой версии и включает этапы выработки требований, анализа, проектирования, реализации и тестирования. Поскольку тестирование проводится на каждой итерации, риск снижается уже на начальных этапах жизненного цикла разработки.
Итеративный подход позволяет увеличивать понимание проблемы через последовательные усовершенствования и повышать эффективность проектных решений. Этот подход обеспечивает лучшую гибкость в учете новых требований или тактических изменений в деловых целях, и позволяет проектировщику заранее идентифицировать и разрешать риски.
Rational Unified Process – это управляемый процесс. Итеративный подход предполагает управление требованиями и управление изменениями, чтобы своевременно и по всем пунктам обеспечивать общее понимание ожидаемых функциональных возможностей, ожидаемый уровень качества, и гарантировать наилучшее управление связанными затратами и графиками выполнения.
Rational Unified Process заключается в создании и обслуживании моделей. RUP фокусирует внимание не на создании большого количества бумажных документов, а на развитии и эксплуатациb моделей – семантически богатых представлений программной системы при ее разработке.
Rational Unified Process концентрирует внимание на первоначальной разработке и компоновке устойчивой архитектуры программы, которая облегчает параллельную разработку, минимизирует переделки, увеличивает возможность многократного использования и надежность эксплуатации. Эта архитектура используется для планирования использования и управления развитием программных компонентов.
Действия при выполнении Rational Unified Process управляются прецедентами. Определение прецедентов и сценария управляет технологическим маршрутом от делового моделирования и требований до испытаний, и обеспечивают связанные и доступные для анализа маршруты разработки и поставки системы.
Rational Unified Process поддерживает объектно-ориентированную технологию. Объектно-ориентированные модели базируются на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), используют унифицированный язык моделирования (UML) как общую систему обозначений.
Rational Unified Process поддерживает компонентно-ориентированное программирование. Компоненты – это нетривиальные модули или подсистемы, которые выполняют конкретную функцию и могут быть смонтированы в строго очерченной архитектуре, специальной или некоторой общедоступной инфраструктуре компонентов, типа Internet, CORBA, COM/DCOM, для которых появляется индустрия многократно используемых компонентов.
Rational Unified Process – это процесс с перестраиваемой конфигурацией. Rational Unified Process удовлетворяет и маленькие группы разработчиков, и большие организации. Rational Unified Process основан на простой и корректной архитектуре, которая обеспечивает общность для семейства процессов, и все же может быть адаптирована к конкретным ситуациям. RUP содержит рекомендации о том, как сконфигурировать процесс, чтобы удовлетворить потребности данной организации.
Rational Unified Process поощряет объективно осуществляемое управление качеством. Оценка качества всех действий и их участников, формируемая в процессе, использует объективные измерения и критерии.
Rational Unified Process поддерживается инструментальными средствами, которые автоматизируют большинство действий процесса. Инструментальные средства используются для создания и обслуживания различных артефактов – моделей в частности – процесса разработки программного обеспечения: визуального моделирования, программирования, испытаний и так далее. Инструментальные средства осуществляют информационную поддержку управления изменениями, которыми сопровождается каждая итерация.
Рассмотрим, как понимается в RUP процесс разработки программы. Процесс – частично упорядоченный набор шагов, которые нужно проделать для достижения цели; при разработке программного обеспечения цель состоит в формировании или расширении существующего программного изделия; при разработке процессов цель состоит в том, чтобы разработать или расширить процесс. Таким образом, процесс программирования – деловой процесс. Rational Unified Process представляет собой универсальный деловой процесс объектно-ориентированной разработки программного обеспечения. Он описывает семейство связанных процессов разработки программного обеспечения, совместно использующих общую структуру и имеющих общую архитектуру.
Структура жизненного цикла
Когда мы рассматриваем динамическую организацию процесса во времени, жизненный цикл программы разбивается на циклы, каждый из которых работает над новым поколением изделия. Rational Unified Process делит один цикл развития на четыре последовательных стадии:
- Начало
- Уточнение
- Конструирование
- Переход
Каждая стадия заканчивается четко определенной вехой – временной точкой, в которой должны быть принятыми некоторые проблемные решения, а поэтому ключевые цели должны быть достигнуты.
Стадии и главные вехи процесса.
Первый цикл выполнения этих четырёх стадий для данного изделия называют начальным циклом разработки. Если жизненный цикл изделия на этом не завершается, существующее изделие разовьётся в своём следующем поколении, повторив ту же последовательность стадий начала, уточнения, конструирования и перехода. Этот период называется “эволюцией”. Циклы развития, которые следуют за начальным циклом развития, называются “эволюционными циклами”.
Начальная стадия
На начальной стадии разработчик устанавливает деловые применения системы и определяет рамки проекта. Чтобы сделать это, нужно идентифицировать все внешние объекты, с которыми взаимодействует система (субъекты), и определить характер этого взаимодействия на высоком уровне. Эта работа включает идентификацию всех прецедентов и описание нескольких наиболее существенных. Деловое применение включает критерии успеха, оценку риска, оценку необходимых ресурсов и укрупненный план с указанием дат завершения главных этапов.
В конце начальной стадии разработчик исследует требования жизненного цикла проекта и решает, следует ли продолжать разработку.
Стадия уточнения
Цели стадии уточнения состоят в том, чтобы проанализировать прикладную область, создать нормальную архитектурную основу, разработать план проекта и устранить самые высокие элементы риска проекта. Архитектурные решения должны приниматься с пониманием целостной системы. Это подразумевает описание большинства прецедентов и рассмотрение дополнительных требований. Чтобы проверить архитектуру, нужно разработать систему, которая демонстрирует архитектурные решения и выполняет существенный прецедент.
В конце стадии уточнения разработчик детально исследует цели и контекст системы, архитектурные решения и способы разрешения главных рисков.
Стадия конструирования
В ходе стадии конструирования происходит итеративная разработка законченного изделия, которое готово к передаче его пользователям. Это подразумевает описание оставшихся прецедентов, изложение деталей конструкции, завершение выполнения и проверку программного обеспечения.
В конце стадии конструирования разработчик решает, все ли программное обеспечение, рабочие места и пользователи готовы и работоспособны.
Переходная стадия
В процессе переходной стадии разработчик передает программное обеспечение его пользователям. Как только изделие попадает в руки пользователей, часто возникают новые проблемы, которые требуют дополнительной разработки для корректировки системы, исправлению не обнаруженных ранее проблем или завершению реализации некоторых возможностей, которые, возможно, были отложены. Эта стадия обычно начинается с выпуска “бета-версии” системы.
В конце переходной стадии разработчик решает, были ли достигнуты цели жизненного цикла, и возможно, запускает другой цикл разработки. Это также та точка, в которой разработчик может проанализировать результаты и сделать выводы из некоторых уроков, полученных в процессе разработки проекта.
Решения, которые предлагает RUP для разработки программного обеспечения:
- Выпускать программное обеспечение, пользуясь принципом промышленного подхода. То есть так, как поступают любые заводы и фабрики: определяя стадии, потоки, уточняя обязанности каждого участника проекта. Именно промышленный подход позволит достаточно оперативно выпускать новые версии ПО, которые при этом будут надежными и качественными.
- Расширять кругозор специалистов для снятия барьеров. Ведь в подавляющем большинстве случаев специалисты из разных отделов просто говорят на разных языках. Соответственно, снятие языкового барьера должно вести к ускорению работы над программным обеспечением.
- Использовать итеративную разработку вместо каскадной, существующей в настоящее время. Принцип итерации заключается в повторяемости определённой последовательности процессов с целью доведения элемента до безошибочного состояния.
- Обязательное управление требованиями. Всем известно, что по ходу разработки в систему вносятся изменения (самой группой разработчиков или заказчиком – неважно). RUP предлагает мощную систему контроля управления требованиями: их обнаружение и документирование, поддержку соглашений между разработчиками и заказчиками.
- Полный контроль всего происходящего в проекте посредством создания специальных архивов.
- Унифицированный документооборот, приведенный в соответствие со всеми известными стандартами. Это значит, что каждый этап в разработке (начало, работа и завершение) сопровождаются унифицированными документами, которыми должен пользоваться каждый участник проекта.
- Использование визуального моделирования.
- Применение не только механизмов объектно-ориентированного программирования, но и объектно-ориентированного мышления.
RUP представлен в виде “on-line” документации, оформленной как web-страницы, что позволяет размещать его описание на сервере внутренней сети предприятия с целью приобщения всех сотрудников к объектно-ориентированной методологии.
Использованная литература:
- https://assistentus.ru/vedenie-biznesa/zhiznennyj-cikl-proekta/
- http://ocnova.ru/metodologii-sravnitelnyj-analiz-aris/
- https://studme.org/174152/informatika/metodologiya_rational_unified_process
- Назначение, сферы применения и принципы устройства мейнфреймов
- Контроль за исполнением документов
- ЭТИКА ДЕЛОВОГО ОБЩЕНИЯ (MBA-Стратегический менеджмент)
- Современные системные программные средства.
- History of Sambo
- Основные характеристики ЕСМ-систем
- Внимание
- Роль руководителя в конфликтной ситуации
- Менеджмент персонала предприятия
- Технологии соблюдение конфиденциальности информации ограниченного доступа
- Технологии соблюдение конфиденциальности информации ограниченного доступа
- Функциональная технология электронного документооборота
Методологии разработки программного обеспечения
Введение
Структура RUP
Продукты, поддерживающие RUP
Артефакты и роли
Business modeling
Requirements
Analysis and design
Implementation
Test
Deployment
Введение
ациональный
унифицированный процесс (Rational Unified Process, RUP) — одна из спиральных
методологий разработки программного обеспечения. Методология поддерживается
компанией Rational Software, обновление продукта происходит примерно дважды
в год. В качестве языка моделирования в общей базе знаний используется язык
Unified Modelling Language (UML).
Итерационная разработка программного обеспечения в RUP предполагает разделение
проекта на несколько мелких проектов, которые выполняются последовательно, и
каждая итерация разработки четко определена набором целей, которые должны быть
достигнуты в конце итерации. Конечная итерация предполагает, что набор целей
итерации должен в точности совпадать с набором целей, указанных заказчиком продукта,
то есть все требования должны быть выполнены.
RUP достаточно хорошо формализован, и наибольшее внимание уделяется начальным
стадиям разработки проекта — анализу и моделированию. Таким образом, эта методология
направлена на снижение коммерческих рисков (risk mitigating) посредством обнаружения
ошибок на ранних стадиях разработки. Технические риски (assesses) оцениваются
и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а
затем пересматриваются с течением времени и с развитием проекта в течение последующих
итераций. Новые цели появляются в зависимости от приоритетов данных рисков.
Релизы версий распределяются таким образом, что наиболее приоритетные риски
устраняются первыми.
Процесс предполагает эволюционирование моделей; итерация цикла разработки однозначно
соответствует определенной версии модели программного обеспечения. Каждая из
итераций (workflow) содержит элементы управления жизненным циклом программного
обеспечения: анализ и дизайн (моделирование), реализация, интегрирование, тестирование,
внедрение. В этом смысле RUP является реализацией спиральной модели, хотя довольно
часто изображается в виде графика-таблицы. Ниже мы приведем основные компоненты
процесса.
Для успешного процесса разработки необходимы три составляющие (рис. 1): процесс
(process), нотация (notation) и набор утилит (tools). Процесс описывает, что
мы делаем, в каком порядке и каким образом; нотация является средством общения;
набор утилит помогает автоматизировать процесс и управлять им.
Рис. 1. Треугольник успеха
В RUP представлены все три компонента. Сначала рассмотрим функции нотации, которые
производят следующие действия:
• осуществляет «склеивание» процесса в единое целое;
• является языковым средством принятия решений, которые не очевидны из исходного
кода;
• предоставляет семантику для отображения важных стратегических и тактических
решений;
• предлагает форму, достаточную для того, чтобы размышлять, а потом принимать
решения и средства автоматизации процесса для того, чтобы манипулировать формализованными
данными.
Фактически нотация охватывает разработку программного обеспечения, начиная
с анализа и заканчивая внедрением продукта. Нотация в случае RUP–UML — формальное
языковое средство описания процесса (об UML речь пойдет ниже). Далее рассмотрим
структуру процесса, а также приведем набор утилит, используемых в процессе управления
разработкой проекта согласно RUP.
Структура RUP
UP
предоставляет структурированный подход к итерационной разработке программного
обеспечения, подразделяя процесс на четыре основные фазы во времени (milestones):
Inception (исследование, начало), Elaboration (уточнение плана), Construction
(конструирование, построение) и Transition (переход, развертывание). К сожалению,
в русском языке нет установившейся терминологии, поэтому в дальнейшем мы будем
использовать английские термины, сопровождая их переводом на русский язык. На
рис. 2 представлено широко распространенное изображение фаз RUP. Целями каждой
из данных фаз являются:
• Inception — понимание, что мы создаем. Фаза сбора информации и анализа требований,
определение образа проекта в целом;
• Elaboration — понимание, как мы это создаем. Фаза анализа требований и проектирования
системы, планирование необходимых действий и ресурсов, спецификация функций
и особенностей дизайна;
• Construction — создание бета-версии продукта. Основная фаза разработки и кодирования,
построение продукта как восходящей последовательности итераций (версий кода);
• Transition — создание конечной версии продукта. Фаза внедрения продукта,
поставка продукта конкретному пользователю.
Рис. 2. Фазы RUP
Это фазы управления эволюцией продукта — итерациями жизненного цикла. RUP предполагает
приближение к конечной цели, но, в отличие от классического стандарта ISO (методология
«водопад»), где transition является конечной фазой, каждая из фаз может повторяться
несколько раз, отражая изменение требований заказчика продукта.
Методология RUP основана на девяти основных потоках (workflow), являющихся элементами
итерации жизненного цикла ПО:
• Business modeling (бизнес-анализ) — предполагает анализ требований на данной
итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей;
• Requirements (требования) — формализация образа системы. Предполагает сбор
требований и управление требованиями, перевод требований в функциональные спецификации.
Здесь начинается анализ прецедентов и построение use cases (пользовательских
историй) — формальное отображение требований пользователя в UML. Результатом
являются документы уровня менеджмента;
• Analysis and design (анализ и моделирование) — предполагает перевод собранных
требований в формализованную программную модель. Результатом является описание
системы на фазе реализации (технический проект) — это документы уровня разработчиков
системы. Язык формализации — Unified Modelling Language (UML), о котором речь
пойдет ниже. В процессе итеративной разработки эволюционировать будет продукт
именно этого потока — модель проекта. Все изменения привязываются в RUP непосредственно
к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют
управлять данным процессом более или менее безболезненно в плане затрат времени
и ресурсов. Здесь имеется в виду тот факт, что результатом разработки является
не модель, а исполняемый код, поэтому заказчик обычно не очень любит платить
за моделирование, так как модели не являются продуктом, который ему нужен);
• Implementation (реализация, кодирование) — предполагает собственно написание
кода. Элементы кода в RUP уже созданы на этапе анализа и дизайна, так как средство
реализации UML — Rational Rose — позволяет создавать элементы кода на нескольких
языках программирования. Методология — объектно-ориентированное программирование;
• Test (тестирование) — предполагает тестирование продукта на данной итерации.
Стоит специально отметить, что regression testing (возвратное тестирование,
тестирование «неухудшения» продукта) в данном случае должно содержать все актуальные
тесты от предыдущей итерации и приемосдаточные тесты от предыдущей transition-фазы;
• Deployment (внедрение) — предполагает установку продукта на полигоне заказчика,
подготовку персонала, запуск системы плюс приемо-сдаточные испытания, подготовка
стандартов упаковки и распространения продукта, передача материалов отделу продаж
(действия опциональны в зависимости от специфики продукта).
Приведенные выше элементы не являются новыми в плане жизненного цикла разработки
ПО, поскольку имеют место практически в любой методологии — возможно, за исключением
XP (где они, тем не менее, представлены в весьма оригинальном виде). Особенностью
реализации RUP являются временные акценты, а именно — на каких итерациях будут
доминировать те или иные потоки, а также наличие универсального языка и набора
утилит, позволяющего описывать процесс разработки. Как мы видим на рис. 2, на
начальных этапах эволюции продукта основное внимание уделяется формализации
проекта (анализ, моделирование), что направлено на сокращение коммерческих рисков
и снижение стоимости ошибок дизайна. Когда картина более или менее ясна, начинаются
собственно разработка, тестирование и, наконец, внедрение продукта.
Preliminary interna — это фактически документы, выпускаемые техническим советом
для менеджеров предприятия. Основная цель начальных этапов — заключение контракта
или соглашения о намерениях. Дальнейшие итерации — собственно начало работы
коллектива разработчиков, который имеет время и ресурсы для построения формальных
моделей. UML в данном случае имеет средства, позволяющие отображать модель на
элементы кода. Например, дерево объектов отображается непосредственно, вариации
зависят от мощности реализации выбранного разработчиками языка программирования,
а также от совпадения взглядов Г.Буча и разработчиков данного языка на объектную
модель. То же самое относится к методам.
Теперь рассмотрим элементы, касающиеся поддержки продукта, — core supporting
workflows:
• Configuration management (управление конфигурацией и изменениями) — мощный
слой административных действий, направленных на управление версиями продукта,
что предполагает контроль исходного кода (модели, исполняемых модулей, тестов,
документации), контроль версий продукта, корпоративные стандарты разработки
кода и документации, отслеживание изменений и ошибок (bug tracking); тесно связан
с тестированием и поддержкой пользователей (customers support);
• Management (управление проектом) — предполагает набор административных действий
управления проектом согласно идеологии RUP, используются средства управления
проектом (см. ниже список продуктов Rational);
• Environment (окружение) — предполагает создание и поддержку средств анализа,
проектирования, разработки, тестирования (как программное, так и аппаратное
обеспечение).
В RUP рекомендовано следовать шести практикам, позволяющим успешно разрабатывать
проект:
• итеративная разработка;
• управление требованиями;
• использование модульных архитектур;
• визуальное моделирование;
• проверка качества;
• отслеживание изменений.
Практики не являются непосредственно частью процесса RUP, но настоятельно рекомендованы
к использованию. Часть практик прямо вытекает из идеологии RUP. Так, итеративная
разработка заложена в структуру RUP, поскольку этот процесс является одной из
реализаций «спирали». Управление требованиями в RUP появляется на самых ранних
стадиях анализа. Теоретически модульная архитектура позволяет повторно использовать
код, и система получается более гибкой. В силу того что UML является объектным
языком, игнорировать модульность можно, но… несколько затруднительно. Визуальное
моделирование позволяет эффективно бороться с возрастающей сложностью систем.
Кроме того, модели являются средствами коммуникации между разработчиками, но
для этого разработчики должны говорить на UML, что предполагает определенный
тренинг. Визуальное моделирование часто осуществляется с помощью инструмента
Rational Rose, что позволяет получать набор весьма полезных документов для менеджеров,
системных администраторов, разработчиков, тестировщики, генерировать элементы
кода. Данное средство не является единственной реализацией UML — доступны как
коммерческие альтернативы (например, Microsoft Visio), так и бесплатные. Следует
отметить, что диалекты UML, реализованные в средствах моделирования, не всегда
совпадают: диалект Rational имеет некоторые серьезные различия, описанные как
в документации, так и в книгах по UML.
Продукты, поддерживающие RUP
иже
перечислены самые известные продукты, поддерживающие Rational Unified Process:
• Rational Rose — CASE-средство визуального моделирования информационных систем,
имеющее возможности генерирования элементов кода. Специальная редакция продукта
— Rational Rose RealTime — позволяет на выходе получить исполняемый модуль;
• Rational Requisite Pro — средство управления требованиями, позволяющее создавать,
структурировать, устанавливать приоритеты, отслеживать, контролировать изменения
требований, возникающие на любом этапе разработки компонентов приложения;
• Rational ClearQuest — продукт для управления изменениями и отслеживания дефектов
в проекте (bug tracking), тесно интегрирующийся со средствами тестирования и
управления требованиями и представляющий собой единую среду для связывания всех
ошибок и документов между собой;
• Rational SoDA — продукт для автоматического генерирования проектной документации,
позволяющий установить корпоративный стандарт на внутрифирменные документы.
Возможно также приведение документации к уже существующим стандартам (ISO, CMM);
• Rational Purify, Rational Quantify Rational PureCoverage, — средства тестирования
и отладки:
– Rational Purify — весьма мощное средство поиска ошибок на run-time для разработчиков
приложений и компонентов, программирующих на C/C++,
– Rational Visual Quantify — средство измерения характеристик для разработчиков
приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает
определять и устранять узкие места в производительности ПО,
– Rational Visual PureCoverage — автоматически определяет области кода, которые
не подвергаются тестированию;
• Rational ClearCase — продукт для управления конфигурацией программ (Rational’s
Software Configuration Management, SCM), позволяющий производить версионный
контроль всех документов проекта. С его помощью можно поддерживать несколько
версий проектов одновременно, быстро переключаясь между ними. Rational Requisite
Pro поддерживает обновления и отслеживает изменения в требованиях для группы
разработчиков;
• SQA TeamTest — средство автоматизации тестирования;
• Rational TestManager — система управления тестированием, которая объединяет
все связанные с тестированием инструментальные средства, артефакты, сценарии
и данные;
• Rational Robot — инструмент для создания, модификации и автоматического запуска
тестов;
• SiteLoad, SiteCheck — средства тестирования Web-сайтов на производительность
и наличие неработающих ссылок;
• Rational PerformanceStudio — измерение и предсказание характеристик производительности
систем.
Артефакты и роли
еотъемлемую
часть RUP составляют артефакты (artefact), прецеденты (precedent) и роли (role).
Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем
при работе над окончательным продуктом. Прецеденты — это последовательности
действий, выполняемых системой для получения наблюдаемого результата. Фактически
любой результат работы индивидуума или группы является артефактом, будь то документ
анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т.п.
За создание того или иного вида артефактов отвечают определенные специалисты.
Таким образом, RUP четко определяет обязанности каждого члена группы разработки
на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт.
Весь процесс разработки программной системы рассматривается в RUP как процесс
создания артефактов — начиная с первоначальных документов анализа и заканчивая
исполняемыми модулями, руководствами пользователя и т.п. Ниже приведен набор
артефактов (моделей, документов и т.п.) для каждого из потоков.
Business modeling
Артефакты-модели — используется Rational Rose:
• модель бизнес-процессов — определение бизнес-требований к разрабатываемой
системе;
• модель структуры предприятия — артефакт для разработки функциональной модели
системы;
• модели документов, бизнес-сущностей, модели сценариев бизнес-функций, модели
состояний бизнес-сущностей — для проектирования пользовательского интерфейса,
БД системы; представляют собой описание статического и динамического состояний
системы с различных точек зрения;
• модели бизнес-правил — артефакт используется для моделирования правил в ПО.
Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры,
Microsoft Project:
• оценка организации заказчика, структура бизнеса;
• словарь терминов предметной области;
• набор бизнес-правил;
• коммерческое предложение;
• спецификации бизнес-функций;
• план работ на этапе бизнес-моделирования;
• рекомендации по проведению бизнес-моделирования;
• запросы на изменение.
Requirements
Артефакты-модели — используется Rational Rose:
• модель функции системы;
• модель сценариев функций системы;
• модель интерфейсов пользователя;
• модель сценариев работы пользователя системы;
• модель выходных форм;
• модель правил системы.
Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры,
MS Project:
• план управления требованиями;
• словарь терминов системы;
• спецификация на программную систему;
• спецификация на функции системы;
• правила системы;
• запросы заинтересованных лиц;
• план работ на этапе определения требований к системе;
• рекомендации по моделированию на этапе определения требований;
• запросы на изменение.
Analysis and design
Артефакты-модели — используется Rational Rose:
• логическая модель данных;
• физическая модель данных;
• модель спецификаций компонентов системы;
• сценарии взаимодействия классов, реализующих компоненты системы.
Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры,
MS Project:
• архитектура программного обеспечения;
• спецификации программных компонентов;
• рекомендации на этапе анализа и проектирования;
• план работ на этапе анализа и проектирования;
• запросы на изменение.
Implementation
Артефакты-модели — используется Rational Rose:
• компонентная модель приложения.
Артефакты-код — используются Rational Rose, средства программирования, текстовые
процессоры:
• элементы генерации кода, полученные в Rational Rose;
• собственно код приложения;
• документация.
Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры,
MS Project:
• план сборки приложения;
• план работ на этапе реализации.
Test
Артефакты-модели — используется Rational Rose:
• модель тестовых примеров;
• функциональная модель тестовой программы;
• модель спецификации компонентов тестовой программы;
• сценарии взаимодействия классов, реализующих взаимодействие компонентов тестовой
программы.
Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:
• описание тестовых примеров;
• план тестирования;
• план работ на этапе тестирования;
• запросы на изменение.
Реализация тестирования — Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.
Deployment
Артефакты-модели — используется Rational Rose:
• модель размещения — описание размещения компонентов по узлам обработки.
Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:
• обучающие материалы;
• документы по инсталляции;
• описание версий системы;
• план внедрения.
Следующая статья данного цикла будет посвящена языку Unified Modelling
Language (UML).
КомпьютерПресс 1’2004
Подборка по базе: Вальченко Реферат по МИ на основе ргр по СППР.docx, Требования к презентации и реферату (1).docx, Темы рефератов и презентаций для самостоятельной подготовки(1)(1, Психология реферат.doc, ПОЛОЖЕНИЕ ДЛЯ ОФОРМЛЕНИЯ РЕФЕРАТА.pdf, Бектұрсын Ділмұрат реферат.docx, 2 РЕФЕРАТ Формы существования языка диалекты, общенародный (прос, География реферат на понедельник.docx, Латыпов Айрат Реферат на тему Роль центрального банка в регулиро, Тимошенко Реферат.rtf
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ОБРАЗОВАНИЯ
«Российский экономический университет имени Г.В. Плеханова»
Институт Цифровой экономики и информационных технологий
Направление
Бизнес-информатика
Кафедра
Информатики
Реферат
по дисциплине: «Методология и технология проектирования информационных систем»
на тему: «Методология RUP. Сравнительный анализ с методологией MSF»
Выполнил:
студент группы 15.11Д-БИ06/19М
очной формы обучения
Кривенцов Антон Андреевич
Преподаватель:
Кафедра информатики
д.т.н., профессор Калянов Георгий Николаевич
Москва – 2020
СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
Методология RUP 4
Методология MSF 6
Сравнительный анализ методологии RUP и MSF 8
Заключение 11
ВВЕДЕНИЕ
На современном этапе развития экономики Российской Федерации отмечается укрупнение коммерческих организаций, рост предприятий крупного бизнеса, автоматизация которых требует разработки сложных корпоративных информационных систем (КИС). КИС – это большие сложные программные системы, состоящие из многих взаимодействующих компонент и обеспечивающие основные (производственные) и вспомогательные бизнес-процессы. При разработке такого рода систем возникает целый ряд существенных проблем, связанных с высокой их сложностью. Это, прежде всего, ограниченность ресурсов и часто изменяющиеся требования. У заказчика тоже достаточно много ролей, каждая из которых выдвигает свои требования, смотрит на процесс разработки корпоративных программных систем со своей точки зрения, имеет собственное мнение, приоритеты и ожидания. Остроту этих проблем призваны сгладить методологии разработки программного обеспечения, которые превращают создание программного продукта в упорядоченный процесс, с помощью которого можно сделать работу программиста более прогнозируемой и эффективной.
Методология разработки – подход к созданию и сопровождению информационных систем в виде жизненного цикла ИС, представляющий его в виде последовательности стадий, каждая из которых разбита на этапы, и выполняемых на них процессов.
Методология RUP
В 2001 году выходит методология разработки от компании IBM, называющаяся Rational Unified Process (RUP), которая описывает как эффективно использовать коммерчески проверенные подходы к разработке прикладного программного обеспечения (ППО). RUP обеспечивает членов команды руководящими принципами, шаблонами и инструментальными наставлениями, необходимыми для всей команды, чтобы в полной мере воспользоваться следующими практиками:
- Разрабатывайте программное обеспечение итеративно;
- Управляйте требованиями;
- Используйте компонентную архитектуру;
- Визуализируйте модель программы;
- Проверяйте качество программы;
- Контролируйте изменения программы.
Рис 1. Рабочие процессы RUP
Ядро RUP составляют следующие рабочие процессы, пересечение которых показано на рисунке 1., среди которых 6 процессов инжиниринга и 3 вспомогательных процесса:
Основные:
- бизнес моделирование;
- управление требованиями;
- проектирование;
- реализация;
- тестирование;
- развертывание.
Вспомогательные:
- конфигурационное управление и управление изменениями;
- управление проектом;
- поддержка среды разработки.
Плюсы:
+ Сравнительная легкость описания и наглядность моделей
+ Возможность адаптирования методологии UML собственным элементам и видам диаграмм
+ Возможность автоматической генерации кода на основе построенных моделей при проектировании с использованием case средств, поддерживающих методологию
Минусы:
– Невозможность проведения детального анализа процессов
– Неполнота и незавершенность некоторых видов диаграмм, возможность их неверной интерпретации
Методология MSF
Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.
MSF включает четыре фазы: анализ, проектирование, разработку, стабилизацию. Она является итерационной, предполагает использование объектно – ориентированного моделирования. MSF по сравнению с RUP в большей степени ориентирована на разработку бизнес – приложений.
MSF – это гибкая и достаточно легковесная методология, построенная на итеративной модели разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нетрадиционные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.
Как и в случае с RUP, в MSF очевидно стремление к универсальности, которое неизбежно приводит к огрублению ситуации в конкретных случаях и к необходимости словесного дополнения схемы. Недостатки моделей, основанных на раскручивающейся спирали, присущи ей в полной мере: невозможность отслеживания временных соотношений между сроками выполнения работ, трудности дополнения специфичных этапов. К тому же ориентация на всеобщность лишает модель и тех преимуществ, которые демонстрирует модель, снабженная конкретным механизмом интерпретации.
Плюсы:
+ снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;
+ непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
+ раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;
Минусы:
– целостное понимание возможностей и ограничений проекта очень долгое время отсутствует.
– при итерациях приходится отбрасывать часть сделанной ранее работы.
Сравнительный анализ методологии RUP и MSF
Сравним две крупные методологии, предназначенные специально для создания корпоративных систем – Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF).
MSF и RUP характеризуются достаточно жесткими процессами, большим количеством артефактов, большим количеством документации, которая создается на каждом этапе, а также достаточно сложным командным взаимодействием, в ряде случаев это масштабирование команды команд. «Тяжелые» методологии достаточно хорошо подходят для создания КИС, поскольку они продуцируют большое количество артефактов.
| Технология | Оптимальная команда | Соответствие стандартам | Допустимые технологии и инструменты | Удобство модификации и сопровождения |
| RUP | 10-40 чел | Стандарты Rational | UML и продукты Rational | Удобно |
| MSF | 3-20 чел | Адаптируемая | Любые | Удобно |
RUP. В основе методологии RUP лежат процессы, причем следует отметить такие особенности методологии, такие особенности подхода, как архитектурную центричность, а также основу на Use Cases – сценариях использования, и итеративность.
Существуют фазы разработки – четыре крупных периода (начало, исследование, конструирование и передача). Внутри каждой из этих фаз может существовать некоторое количество итераций по инкрементальной подготовке, последовательному доведению решений и артефактов до того вида, когда они могут быть приняты, в том числе и заказчиками.
При этом на первом этапе дела есть высокоуровневые требования и общая концепция программного продукта, но еще нет детальных спецификаций. На втором этапе происходит архитектурное проектирование. На третьей стадии – конструирование или разработка, где и происходит кодирование, тестирование и сборка, разработка всей необходимой документации, для того чтобы релиз в начальном варианте мог быть передан заказчику. На четвертой стадии происходит последовательное уточнение, доработка, переработка, сведение и фиксация всей необходимой документации и кода, для того чтобы продукт был полнофункциональным и был готов к передаче заказчику. Так происходит базовый процесс разработки.
Поскольку RUP – методология строгая, существуют вполне определенные критерии выхода, как из каждой фазы, так и из каждой итерации. Существуют вполне определенные артефакты и вполне определенные метрики, которые описывают степень их готовности. На первой стадии — это основные высокоуровневые требования к системе. На втором этапе – архитектурный проект и, соответственно, диаграммы, которые описывают программный продукт, если на первом этапе это были Use-Сase. На третьем этапе – программное решение в виде кода и документации. И на четвертом этапе – полный релиз, готовый к передаче заказчику.
MSF. Методология MSF основана на гибкой процессной модели и включает в себя командную разработку. Масштабирование, команды команд – это достаточно важные составляющие MSF. Нужно сказать, что MSF поддерживает полный жизненный цикл разработки, т.е. он включает в себя как MSF (Microsoft Solutions Framework), так и MOF (Microsoft Operations Framework), которые объединяют процессы концептуализации, создания, внедрения, сопровождения, расширения, развития программных продуктов.
Прежде всего, важнейшим фокусом этой методологии является ориентация именно на бизнес, требования заказчика. Поэтому первое, что требуется – это партнерство с клиентом. При этом клиент понимается достаточно широко. Это может быть не обязательно конечный заказчик, но это может быть целый ряд людей, которые называются стейкхолдерами, или людей, которые вносят свой капитал в создание и развитие программного продукта. Одной из ценностей методологии является открытая коммуникация. Суть её состоит в том, что на самом деле представление о продукте, особенно на уровне первоначальной идеи, первоначальной концепции с точки зрения разработчика и с точки зрения заказчика, могут весьма существенно отличаться. При этом на стороне разработчика существует порядка 15 и даже более ролей, каждая из которых на самом деле имеет свое видение и свой взгляд на продукт и на программный проект.
Поэтому для того, чтобы разработка продукта, необходимого заказчику, была предсказуема и надежна, нужна открытая коммуникация, нужно постоянное взаимодействие и нужно строить общее видение – vision. Совместное видение – это, таким образом, третий принцип. Четвертый принцип – качество как работа каждого, как ежедневная необходимость создавать некую ценность, т.е. документацию, программный код и т.д., которые будут положены в основу будущего продукта. Еще один важный принцип – быть адаптивным и приспосабливаться к изменениям, за счет чего происходит постоянный мониторинг рисков, общение с заказчиком, и, таким образом, создается ценность, а внедрение делается привычкой. Microsoft основывает свою методологию не просто на разработке продукта и передаче заказчику, но и на внедрении, доводке и сопровождении.
Ниже представлена сравнительная характеристика строгих методологий разработки корпоративных систем
| RUP | MSF |
| Подходит для больших и очень больших проектов | Подходит для больших и очень больших проектов |
| Поддерживает разные модели ЖЦ | Гибкая и масштабируемая методология, построена на итеративной модели разработки |
| Базируется на широком использовании UML | Важный аспект подхода – синхронизация и стабилизация |
| На всех стадиях используются программные метрики | Четко определяются результаты по каждой контрольной точки |
Заключение
Главная цель процесса проектирования и разработки ИС состоит в создании программного продукта, обладающего высоким качеством, в приемлемые сроки в рамках прогнозируемого бюджета. Это означает, что качество и сроки разработки ИС должны удовлетворять заказчика. Достичь этого можно только при правильной организации работ по созданию ИС.
В заключение стоит отметить, что залогом успеха любого проекта, в том числе и корпоративного, является не только сплоченность команды, но и строгое следование стандартам и использование специализированных инструментальных средств. Не существует универсальной методологии, которая сможет решить все проблемы любого заказчика раз и навсегда. Выбор методологии существенным образом определяется характером и масштабом проекта, теми задачами, которые ставит заказчик.
Приведен обзор предсказуемых методологий на примере Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF). Были обсуждены характерные черты этих методологий. Наряду с общими деталями были выявлены также и некоторые сложные моменты процесса разработки, связанные с управлением командой, планированием, стратегией менеджмента, взаимодействием с заказчиком, жизненным циклом программного продукта, внедрением и реализацией выбранной методологии.
В результате, можно сделать вывод о том, что идеальной и универсальной методологии для разработки ПО не существует. При разработке определенного ПО должен быть учтен ряд факторов, влияющих на разработку. Безусловно, некоторые модели явно превосходят другие по одним признакам, но уступают по остальным, поэтому необходимо определить, что является первостепенным по важности в данной разработке.
Список источников
1. Fazar W., Program Evaluation and Review Technique // The American Statistician, Vol. 13 (№ 2), 1959, С. 10.
2. A.A. Ермолаев, В. М. Дёмкин. Управление проектами по разработке программных продуктов.
3. Microsoft Solutions Framework. Методология создания программных решений. (http://www.microsoft.com/Rus/Msdn/msf/Default.mspx)
4. Уокер Ройс. Управление проектами по созданию программного обеспечения. Издательство “Лори”, 2002 г. 424 с.
5. Андрей Колесов. Введение в методологию Microsoft Solutions Framework http://www.bytemag.ru/Article.asp?ID=2866
6. Rational Unified Process. Методология и технология. Материалы компании Interface Ltd. (http://www.interface.ru/home.a sp?artId=779)
Методология разработки прикладного программного обеспечения RUP
(Rational Unified Process)
ПРИЛОЖЕНИЕ
К МЕТОДИКЕ CETIN
Разработчики:
АО «НИТ»
ТОО «Компания системных исследований «Фактор»»
ОЮЛ «Казахстанская Ассоциация IT-Компаний»
Согласовано:
АО «Национальный инфокоммуникационный холдинг «Зерде»»
Астана, 2011
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
3
1
^ ОСНОВНЫЕ ПРОЦЕССЫ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
4
1.1
Процесс «Бизнес-моделирование»
4
1.2
Процесс «Управление требованиями»
4
1.3
Процесс «Проектирование»
6
1.4
Процесс «Реализация»
7
1.5
Процесс «Тестирование»
7
1.6
Процесс «Развертывание»
8
2
^ ВСПОМОГАТЕЛЬНЫЕ ПРОЦЕССЫ
10
2.1
Конфигурационное управление и управление изменениями
10
2.2
Управение проектом
10
2.3
Поддержка среды разработки
11
ВВЕДЕНИЕ
RUP – методология разработки прикладного программного обеспечения, созданная компанией Rational Software. RUP описывает процессы разработки прикладного программного обеспечения (ППО).
Методология RUP содержит 6 основных процессов и 3 вспомогательных:
Основные:
бизнес моделирование;
управление требованиями;
проектирование;
реализация;
тестирование;
развертывание.
Вспомогательные:
конфигурационное управление и управление изменениями;
управление проектом;
поддержка среды разработки.
Назначением процессов разработки является преобразование набора требований в прикладное программное обеспечение. В результате успешной реализации процессов:
– должно быть разработано прикладное программное обеспечение;
– должны быть разработаны промежуточные программные продукты, демонстрирующие то, что конечный продукт базируется на требованиях;
– должно быть установлено соответствие между требованиями и инженерными решениями;
– должны быть приведены (например, путем испытаний) доказательства того, что конечный продукт соответствует требованиям;
– конечный продукт будет установлен в целевой операционной среде и принят заказчиком.
1. ОСНОВНЫЕ ПРОЦЕССЫ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
^ 1.1. Процесс «Бизнес моделирование»
Основными целями процесса являются:
понять структуру и динамику предметной области, в которой должна быть развернута создаваемая информационная система;
понять текущие проблемы предметной области и определить потенциальные возможности ее усовершенствования;
обеспечить общее понимание предметной области заказчиками, конечными пользователями и разработчиками;
выявить системные требования, необходимые для поддержки автоматизации предметной области;
Для достижения этих целей Разработчику необходимо описать предметную область, а затем на основании этого описания определить с помощью моделирования роли и обязанности, существующие в ней.
В процессе Бизнес-моделирование разработчику необходимо выполнить следующие работы:
оценка текущего состояния предметной области;
идентификация бизнес процессов;
описание бизнес процессов;
проектирование бизнес процессов;
детализация ролей и обязанностей;
описание предметной области;
построение объектных моделей предметной области.
В результате работ должны быть получены следующие артефакты:
бизнес правила;
модель бизнес-объектов;
модель бизнес процессов.
1.2. Процесс «Управление требованиями»
Основными целями процесса «Управление требованиями» являются:
установление и поддержание соглашения с клиентами и другими заинтересованными лицами на том, что система должна делать;
выявление и формализация разработчиком системы требований к разработке ППО;
определение функциональных границ создаваемой информационной системы;
обеспечение базиса для планирования технического содержания фаз разработки;
обеспечение базиса для оценки стоимости и времени на разработку информационной системы;
определение графического интерфейса пользователей с учетом их потребностей и целей.
Процесс состоит из сдедующих работ:
анализ проблемы;
анализ потребностей заказчика;
определение системы;
детализация описания системы;
управление меняющимися требованиями.
В результате процесса должны быть разработаны (доработаны) следующие артефакты:
глоссарий;
концепция системы;
модель анализа;
модель сценариев использования;
план управления требованиями;
техническое задание;
требования заказчика.
Функциональный размер процесса управления требованиями измеряется в количестве вариантов использования и количестве типов объектов, участвующих в вариантах использования.
.
Примечание: Чтобы достичь указанных целей, прежде всего, важно определить функциональные границы тех задач, которые должны быть решены при использовании создаваемой системы. В ходе процесса идентифицируются заинтересованные лица в успешном выполнении проекта и выявляются их запросы к системе, которые затем анализируются. Для полного описания системы разрабатываются артефакты, которые описывают, что система должна делать с точки зрения всех заинтересованные лиц, включая заказчиков и потенциальных пользователей системы, как важных источников информации (в дополнение к системным требованиям).
Запросы заинтересованных лиц собираются из всевозможных источников для получения т.н. «списка пожеланий». Этот общий список, с одной стороны, содержит все ожидания заинтересованных лиц, а с другой – позволяет единообразно зафиксировать все требования к системе.
В ходе процесса создается полное описание концепции разрабатываемой программной системы, что служит для поддержки контракта между инвесторами и разрабатывающей организацией. Концептуальное видение создается, как видение системы со стороны клиентов и сосредотачивает основное внимание на существенных свойствах системы и допустимом уровне ее качества. Концептуальное видение включает описание основных свойств, которыми должна обладать система. Следует также определить эксплуатационные мощности системы (объемы рабочих данных, времена отклика, точность обработки и т.д.), профили пользователей (кто будет основным пользователем системы) и межсистемные интерфейсы с объектами вне границ системы.
Создаваемые модели служат в качестве средства взаимодействия между участниками проекта и могут выступать в роли контракта между заказчиками, пользователями и разработчиками системы. Эти модели описывают функциональные возможности системы. Модели позволяют:
клиентам и пользователям подтвердить достоверность того, что система станет делать то, что они ожидают;
разработчикам системы создать то, что требуется.
Полное определение системных требований, описанное в смоделированных сценариях, позволяет определить спецификацию программных требований для конкретного свойства программы или отдельной подсистемы.
^ При этом в процессе определяется общая терминологию, которая будет использоваться в ходе проекта при создании различных документов к системе.
Приведенное выше описание оценки размера результатов управления требованиями, может быть использовано для оценки трудозатрат как заказчиком, хорошо представляющим поведение будущей системы, так и разработчиком. Количество вариантов использования и количество объектов, участвующих в вариантах использования можно рассчитать путем построением диаграмм вариантов использования, диаграмм классов в нотации языка UML.
^ 1.3. Процесс «Проектирование»
Основными целями процесса проектирования являются:
трансформирование артефактов, созданных в процессе управления требованиями в артефакты данного процесса;
определение архитектуры системы;
подготовка и создание условий для осуществления соответствующей поддержки среды разработки и реализации системы в виде конечного продукта.
В результате реализации процесса будут реализованы следующие работы:
определение архитектуры проекта;
анализ требуемого поведения системы;
проектирование модулей;
проектирование баз данных;
В результате получены следующие артефакты:
архитектура системы;
модель компонентов;
модель проектирования;
модель развертывания;
прототип системы
Примечание: Размер результатов работы на данном процессе было бы вполне логично измерять подсчетом количества описанных программных компонентов или модулей. Однако, учитывая, что для заказчика, который не обязан ясно представлять технологию физической реализации системы, рекомендуется в целях измерения функционального размера использовать: количество узлов количество типов объектов участвующих в вариантах использования, количество свойств объектов, количество отношений между типами объектов.
ППО может считаться реализованным в том случае, когда оно будет способно выполнять функции своего целевого предназначения. Это возможно, только если программный код системы будет реализован в форме исполняемых модулей, библиотек классов и процедур, стандартных графических интерфейсов, файлах баз данных. Именно эти компоненты являются необходимыми элементами физического представления системы.
В данном процессе участвуют как архитекторы, так и кодировщики. Результаты процесса обеспечивают согласованный переход от логического представления к конкретной реализации проекта в форме программного кода.
^ 1.4. Процесс «Реализация»
Цели процесса «Реализация»:
определение структуры классов, функций, процедур, интерфейсов, скриптов на основе реализуемых подсистем, организованных по уровням;
реализация классов, объектов, интерфейсов в виде модулей (исходных, двоичных, исполняемых файлов и др.);
тестирование разработанных модулей;
интеграция результатов работы отдельных программистов (или групп) в рабочую систему.
В рамках процесса «Реализация» реализуются следующие работы:
структурирование модели компонентов;
планирование интеграции системы;
программирование модулей;
интегрирование подсистем;
интегрирование системы.
В результате проекта разрабатываются (дорабатываются) следующие артефакты:
архитектура систем;
модель компонентов;
план сборки;
релиз;
программный модуль.
^ 1.5. Процесс «Тестирование»
Целями процесса тестирование являются:
проверка взаимодействия между объектами;
проверка корректной интеграции всех модулей системы;
проверка, что все требования были корректно реализованы;
идентификация дефектов и подтверждение, что они максимально выявлены еще до развертывания системы.
В процессе тестирование реализуются следующие работы:
планирование тестирования;
подготовка тестового репозитория;
сборочное тестирование;
системное тестирование.
В результате реализации процесса будут получены следующие артефакты:
план тестирования;
скрипт тестирования;
отчет по результатам тестирования.
Примечание: Во многих организациях тестирование программного обеспечения (ПО) занимает от 30 до 50 процентов от всей стоимости разработки. Однако большинство людей полагают, что ПО не может быть хорошо протестировано до момента поставки. Это заблуждение основано на двух ясных фактах. Во-первых, тестирование ПО является чрезвычайно сложным. Выполнение любой программы может иметь несчитанное количество различных путей. Во-вторых, тестирование очень часто проводится без четкой методологии и без требуемой автоматизации с помощью соответствующих инструментальных средств. Сложность создаваемого ПО делает невозможным проведением 100-% тестирования, но хорошо продуманная методология и использование современных инструментальных средств, могут значительно улучшить производительность и эффективность тестирования ПО.
Для систем «с особыми требованиями к безопасности», когда отказ в работе может причинить вред людям (таких, как системы управления воздушными полетами, управления ракетами или медицинскими поставками), высокие требования к качеству ПО являются необходимыми для успеха разрабатываемой системы. Для обычной информационной административной системы такие требования не являются настолько критичными, но воздействие от наличия всего лишь одного дефекта может быть, тем не менее, достаточно дорогостоящим.
Хорошо выполненные тесты, запуск которых осуществляется еще на ранней стадии жизненного цикла, могут значительно снизить стоимость завершения проекта и поддержки ПО. Это может также значительно снизить риски или задолженности, связанные с поставкой ПО плохого качества, и предохранить заказчика от плохой производительности конечных пользователей, неудобства в вводе данных, наличия вычислительных ошибок и неприемлемое функционального поведения системы. В настоящее время многие информационные административные системы являются ответственными системами (требующими безотказного функционирования в течение всего времени выполнения целевой задачи), т.е. компании не могут корректно выполнять свои функции и несут огромные потери в случае появления неисправностей. Пример могут быть такие организации, как банки или транспортные компании. Системы, требующие безотказного функционирования в течение всего времени выполнения целевой задачи, должны быть протестированы с использованием строгих принципов для систем с особыми требованиями к безопасности.
^ 1.6 Процесс «Развертывание»
Целью процесса «Развертывание» является поставка разрабатываемой информационной системы конечным пользователям.
Для реализации процесса выполняются следующие работы:
планирование развертывания системы;
разработка документов поддержки;
проведение бета-тестирования;
создание коробочного варианта продукта.
Результатом процесса «Развертывание» являются следующие артефакты:
описание инсталляции;
описание продукта;
план развертывания;
продукт;
руководство пользователя.
Примечание: Процесс развертывания описывает три основных варианта поставки:
инсталляция представителем разработчика;
«коробочный» (продукт поставляется в упаковке);
доступ к Web-сайту разработчика и самостоятельное получение.
При любом варианте делается акцент на тестирование продукта, которое выполняется вслед за beta-тестированием, но непосредственно перед поставкой.
Основная часть деятельностей данного процесса выполняется в заключительной фазе жизненного цикла проекта.
2. ВСПОМОГАТЕЛЬНЫЕ ПРОЦЕССЫ
^ 2.1. Конфигурационное управление и управление изменениями
Целями процесса конфигурационного управления и управления изменениями являются:
контроль многочисленных артефактор, создаваемых участниками разработки ппо;
гарантия того, что изменения в проекте производятся организованно и все заинтересованные лица информированы о текущем состоянии продукта, сделанных в нем изменениях, их стоимости и влиянии на ход проекта.
В процессе выполняются следующие работы:
разработка плана конфигурационного управления и управления изменениями;
создание среды для конфигурационного управления проектом;
управление базовыми версиями и релизами;
управление запросами на изменение.
В результате процесса реализуются следующие артефакты:
запрос на изменение;
план управления изменениями;
план конфигурационного управления.
^ 2.2. Управление проектом
Целями процесса управления проектом являются:
организация процесса управления проектом;
соблюдение основных принципов планирования, управления персоналом, выполнения работ и мониторинга проекта;
эффективное управление рисками.
В ходе реализации процесса выполняются следующие работы:
инициирование проекта;
оценка функциональных границ и рисков проекта;
планирование проекта;
планирование итерации;
проведение интерации;
закрытие фазы;
закрытие договора;
мониторинг и контроль проекта.
В результате проекта получаются следующие артефакты:
оценка итерации;
оценка состояния системы;
план метрик проекта;
план приемки продукта;
план разработки продукта;
список рисков;
экономическое обоснование проекта;
концепция системы.
^ 2.3. Поддержка среды разработки
Целью процесса поддержка среды разработки явлется обеспечение организации, ведущей разработку прикладного программного обеспечения, необходимыми правилами формирования среды процесса разработки, включающими в себя требования к составу технологических процессов и инструментальных средств.
В результате выполнения процесса должны быть выполнены следующие работы:
подготовка среды проекта;
подготовка среды итерации;
поддержка среды в ходе итерации.
В результате процесса будут получены следующие артефакты:
инструментальные средства;
инфраструктура проекта;
репозиторий проекта.
Технология RUP
RUP – это процесс , направленный на поддержку коллективной разработки ПС. Все участники проекта используют единую базу знаний, единый процесс, единый взгляд на разработку, единый язык моделирования. RUP разрабатывался одновременно с UML – промышленным стандартом ОО моделирования – тем же коллективом авторов. Все модели в RUP представляются в нотации UML. RUP – это технологический процесс по созданию ПС, позволяющий улучшить производительность коллективной разработки путем предоставления для всех этапов жизненного цикла методик выполнения основных видов деятельности, шаблонов документов, инструкций по работе с инструментальными средствами.
RUP постоянно развивается на основе единой базы знаний, пополняемой через интернет. Это – полезный инструмент, применимый к широкому спектру разрабатываемых приложений.
Отличительные черты RUP
- RUP – это итеративный процесс (Controlled Interactive);
- Предполагает сквозное применение аппарата Use Cases (Use Case Driven);
- Особое внимание уделяется разработке архитектуры (Architecture Centric);
- Включает управление требованиями и изменениями (Requirements Configuration and Change Management);
- Опирается на КБ концепцию разработки ПС (Component Based Development).
- Базируется на визуальном моделировании (Visual Modeling Techniques);
RUP предлагает итерационный подход к проектированию и разработке ПС, основанный на спиральном жизненном цикле . Весь жизненный цикл включает четыре фазы – вхождение в проект (исследование), развитие (уточнение плана), конструирование и развертывание.
Каждая фаза складывается из последовательности итераций, число которых может быть любым. В каждой итерации перечисленные выше технологические процессы последовательно применяются к разработке небольшой части ПС. При этом допустимо предъявление результата заказчику. Он имеет возможность оценить выполненную реализацию, выдать свои замечания, которые могут привести к изменению и уточнению требований к ПС. Следующая итерация предполагает расширение уже разработанной части путем реализации и интеграции очередной порции требований и учета изменения требований в соответствии с замечаниями заказчика. Такая организация процесса имеет целый ряд преимуществ.
Преимущества
- Изменения и уточнения требований выявляются уже в ранний период разработки, когда объем программного кода сравнительно небольшой, поэтому трудоемкость внесения изменений существенно ниже.
- Уже на ранней стадии процесса разработки имеется возможность привлечения специалистов заказчика для оценки промежуточных версий (прототипов) ПС. Как результат – значительно более высокая вероятность того, что конечный продукт будет делать именно то, чего ждет от него заказчик, то есть, гарантируется высокое качество ПС.
- Снижаются архитектурные и интеграционные риски. При итеративном подходе создается устойчивая архитектура, которая прорабатывается на стадиях исследования, а затем проверяется и уточняется в нескольких начальных итерациях. Каждая итерация предполагает интеграцию новых элементов в систему, то есть, количество интегрируемых элементов в каждой итерации невелико и легче прослеживается, чем при глобальной интеграции всех разработанных элементов ПС.
- Итеративный подход способствует более полному повторному использованию программных элементов. Анализ результатов каждой итерации позволяет архитекторам ПС выделить фрагменты, потенциально подлежащие повторному использованию, а в следующей итерации оформить их как повторно используемые коды. Это свойство очень хорошо сочетается с идеями ОО и КБ проектирования.
RUP – процесс, направляемый вариантами использования
- Понятие use case, введенное в языке UML, является основой для выполнения всех этапов жизненного цикла, рассматриваемых в RUP. Понятие «business use case» (вид деятельности) является ключевым при бизнес-анализе .
На этапах анализа требований, проектирования и реализации use cases выступают в качестве вариантов использования системы (ВИ), При анализе требований, выделив ВИ, тем самым определяется требование или уровень иерархии требований к ПС. При детализации ВИ определяются объекты, и способы их взаимодействия, которые должны быть реализованы в программном коде.
Особую роль ВИ играют в планировании итераций. Чтобы определить, какая функциональность должна быть реализована в очередной итерациииспользуют диаграммы ВИ. Каждому ВИ можно приписать приоритет, определяющий, в какой итерации его следует реализовать. Можно показать все ВИ, реализуемые в очередной итерации, на отдельной диаграмме (или нескольких диаграммах).
RUP – процесс, основанный на архитектуре
Разработка архитектуры ПС в RUP преследует следующие цели:
- Описание организации ПС;
- Определение компонентов и их интерфейсов;
- Определение подсистем и объединение компонентов в подсистемы;
- Создание основы для повторного использования компонентов;
- Создание базиса для разработки;
- Контроль над проектом и поддержка целостности системы.
Архитектура ПС находит отражение в различных архитектурных представлениях .
Логическое представление отражает функциональные требования к системе. Оно определяет основные (архитектурно значимые) пакеты, подсистемы и классы проекта.
Реализационное представление описывает организацию статических программных модулей (компонентов, файлов данных, исходного кода и др.) в терминах пакетов и уровней
Процедурное представление отражает аспекты параллельности задач, потоков и процессов во время работы системы и их взаимодействия.
Представление развертывания показывает, как компоненты отображаются на базовые платформы и вычислительные узлы.
Use case представление содержит ключевые ВИ и сценарии.
Архитектурные представления акцентируют внимание только на таких элементах, которые имеют существенное влияние на структуру ПС, ее производительность, масштабируемость, устойчивость, сопровождаемость, возможность развития. К числу таких элементов относятся:
- Классы, моделирующие основные объекты деятельности;
- Механизмы, определяющие поведение этих классов;
- Уровни и подсистемы;
- Интерфейсы;
Основные процессы и управляющие потоки.
В RUP предусмотрено создание отдельного документа, содержащего описание архитектуры ПС.
Технологические процессы в RUP
В RUP определено 9 технологических процессов , для каждого из которых предложена методика выполнения. Технологические процессы делятся на две категории – основные процессы и процессы поддержки. К основным относятся:
- Бизнес-анализ,
- Управление требованиями,
- Анализ и проектирование,
- Реализация,
- Тестирование,
- Развертывание.
Вспомогательные процессы включают: управление проектом, управление конфигурацией, управление средой.
Для каждого технологического процесса предусмотрены роли , определяющие поведение и обязанности отдельных лиц и групп, работающих в одной команде (например, системный аналитик, тестировщик), виды деятельности , определяющие работы, выполняемые исполнителями (например, проектирование класса, проектирование ВИ) и артефакты – документы, используемые, порождаемые или модифицируемые процессом. Основные артефакты в RUP – модель, элемент модели, документ, исходный код, исполняемая программа.
RUP. Обследование организации (бизнес-анализ)
Цели
Цели бизнес-анализа заключаются в следующем:
- понять структуру и динамику работы организации;
- определить проблемы, возникающие в работе организации, и возможности их решения, направленного на повышение эффективности работы;
- гарантировать, что заказчики, конечные пользователи и разработчики будут иметь одинаковое понимание деятельности организации;
- вывести требования к программным системам, автоматизирующим работу организации.
Организация описывается как с внешней точки зрения – какие результаты предоставляются ее клиентам, так и с внутренней – роли, и их связи с деятельностью организации. Эта информация служит системным аналитикам в качестве связующей при определении требований к ПС.
Бизнес-анализ вовсе не является обязательным для каждого проекта разработки ПС. Если заказчик имеет хорошо отлаженный производственный цикл, использует программные средства автоматизации, точно представляет себе, какие производственные задачи должна решать новая ПС в дополнение к уже автоматизированным, то проведение бизнес-анализа может не потребоваться.
Основным результатом бизнес-анализа является бизнес-модель , которая представляется на языке UML. Здесь UML позволяет строить модели любой системы, не обязательно программной, поэтому для описания работы организации используются те же логические и функциональные модели, что и для ПС.
Единственное дополнение состоит в том, что в модели бизнеса должны присутствовать бизнес-исполнители – специалисты обследуемой организации, отвечающие за выполнение тех или иных работ.
Роли
В моделировании бизнеса участвуют:
- бизнес-аналитик – специалист организации-разработчика, который возглавляет и координирует работы по моделированию бизнеса;
- бизнес-разработчик – специалист организации-разработчика, который детализирует и уточняет бизнес модели, определяет бизнес-исполнителей их обязанности и действия;
- заинтересованные лица – люди, предоставляющие информацию. Это могут быть бизнес-исполнители или клиенты организации, а также прочие люди, заинтересованные как в собственно результатах моделирования, так и в будущей ПС.
эксперт – представитель обследуемой организации, участвующий в разработке модели (консультации, организация встреч с заинтересованными лицами, оценка результатов). Эксперт, в частности, может быть одним из бизне-исполнителей.
Артефакты
При моделировании создаются следующие артефакты в виде текстовых документов и моделей, описанных на UML:
- Документ «Видение бизнеса» – определяет цели проведение бизнес-анализа.
- Структура организации – статическое описание подразделений организации и отношений подчиненности в виде диаграмм пакетов и/или классов.
- Модель видов деятельности включает бизнес-актеров и виды деятельности организации.
- К числу бизнес-актеров относятся: заказчики, партнеры, поставщики, власти (представители закона, инспекция и др.), дочерние организации, собственники и инвесторы, внешние информационные системы
- Бизнес-актеры помогают определить границы организации, которую требуется описать. Виды деятельности представляют собой бизнес-процессы. Модель видов деятельности представляется с помощью use case диаграмм.
- Объектная модель включает бизнес-актеров, бизнес-исполнителей и бизнес-сущности, а также содержит описание их взаимодействий при реализации видов деятельности. Модель представляется на UML с помощью диаграмм классов и взаимодействий (последовательностей, коопераций, деятельностей), которые иногда называют технологическими сценариями.
- Модель предметной области является подмножеством объектной модели. Она описывает основные бизнес-сущности и связи между ними. Эта модель представляется в виде диаграмм классов.
- Глоссарий – текстовый документ, содержащий определения основных понятий, используемых в данном бизнесе.
- Оценка деятельности организации – текстовый документ, описывающий текущее состояние организации, в которой будет использоваться ПС.
- Бизнес-правила – текстовый документ, определяющий условия и ограничения, которым должен удовлетворять бизнес.
- Дополнительные спецификации – текстовый документ, содержащий описание свойств бизнеса, не включенных в бизнес-модель.
Процесс
Процесс бизнес-анализа показан на рис.1. Построение всех предписываемых проекций модели бизнеса выполняется параллельно. Не всегда требуется создавать все проекции. В частности, иногда достаточно просто построить модель предметной области. Решение о составе модели принимает бизнес-аналитик. Все проекции модели разрабатываются параллельно. Например, при выявлении очередного бизнес-актера его включают в модель видов деятельности и в объектную модель, где показывается его взаимодействие с бизнес-исполнителями.
При построении бизнес-модели используют нормативные документы организации (устав, штатное расписание и др.), а также информацию, предоставляемую заинтересованными лицами, для чего проводятся интервью и совещания, заполняются анкеты и опросные листы.
Созданная в итоге бизнес-модель является основой для последующего моделирования ПС. Например, модель видов деятельности преобразовывается в модель ВИ. Такое преобразование может быть формализовано. Необходимо выделить те виды деятельности, которые подлежат автоматизации, и объявить их вариантами использования ПС, а также преобразовать бизнес-исполнителей в актеров, поскольку они являются внутренними сущностями организации, но внешними по отношению к системе. Модель предметной области включается как составная часть в логическую модель ПС, а технологические сценарии являются источником для определения потоков событий в ВИ.
Созданная в итоге бизнес-модель является основой для последующего моделирования ПС.
Например, модель видов деятельности преобразуется в модель ВИ. Такое преобразование может быть формализовано. Необходимо выделить те виды деятельности, которые подлежат автоматизации, и объявить их вариантами использования ПС, а также преобразовать бизнес-исполнителей в актеров, поскольку они являются внутренними сущностями организации, но внешними по отношению к системе. Модель предметной области включается как составная часть в логическую модель ПС, а технологические сценарии являются источником для определения потоков событий в ВИ.
Откуда берутся требования к системе?
Один источник требований – это бизнес-анализ, проводимый в начальной фазе проекта. Вторым таким источником являются ПС, эксплуатируемые в организации. Разработка современных ПС редко когда начинается “с нуля”. Чаще всего у заказчика имеется работающая (наследуемая) система, для которой требуется расширить состав выполняемых функций, перевести ее на другую, более современную платформу, обеспечить доступ через интернет, повысить производительность и т. д. При этом типичной является ситуация, когда наследуемая система плохо документирована (нет моделей и описания, частично или полностью отсутствуют исходные коды программ, устарела пользовательская документация и др.). В этом случае прежде чем браться за разработку новой системы, необходимо документировать наследуемую. В терминах RUP это означает, что необходимо построение модели, описывающей ПС с различных точек зрения.
Моделирование наследуемой системы основывается на проведении реинжиниринга, в процессе которого выполняется восстановление описывающих систему моделей на основе анализа имеющейся информации. При этом функциональность, реализованная в наследуемой системе, определяет часть требований к проектируемой ПС (в большинстве случаев достаточно значительную).