Методология разработки прикладного программного обеспечения rup

Вид материала

Реферат

Содержание Основные процессы разработки прикладного программного обеспечения Вспомогательные процессы 1.1. Процесс «Бизнес моделирование» При этом в процессе определяется общая терминологию, которая будет использоваться в ходе проекта при создании различных документ 1.3. Процесс «Проектирование» 1.4. Процесс «Реализация» 1.5. Процесс «Тестирование» 1.6 Процесс «Развертывание» 2.1. Конфигурационное управление и управление изменениями 2.2. Управление проектом 2.3. Поддержка среды разработки

Подобный материал:

• Анализ прикладного программного обеспечения, используемого для разработки бизнес–плана, 137.41kb.
• И. Ф. Бабалова московский инженерно-физический институт (государственный университет), 39.62kb.
• 010500. 62 Математическое обеспечение и администрирование информационных систем (квалификация, 19.59kb.
• Интегрированная) среда разработки программного обеспечения (англ, 76.47kb.
• § Модели угроз безопасности программного обеспечения, 158.47kb.
• Программа вступительного экзамена вмагистратуру по специальности «6M070300-информационные, 73.49kb.
• Примерная программа наименование дисциплины Проектирование и архитектура программных, 182.2kb.
• Открытый конкурс «Сопровождение и развитие прикладного программного обеспечения, эксплуатируемого, 1878.91kb.
• Пк программный комплекс; по программное обеспечение; ппо прикладное программное обеспечение, 208.41kb.
• Программа элективного курса «Компьютерная графика в операционной системе Linux», 162.47kb.

Методология разработки прикладного программного обеспечения 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. Поддержка среды разработки

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

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

• подготовка среды проекта;
  
• подготовка среды итерации;
  
• поддержка среды в ходе итерации.
  

В результате процесса будут получены следующие артефакты:

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