Контрольная работа по курсу «Современные технологии обработки экономической информации (часть 2)»

Министерство образования Республики Беларусь Учреждение образования

«Белорусский государственный университет информатики и радиоэлектроники»

Кафедра экономической информатики

Контрольная работа по курсу:

«Современные технологии обработки экономической информации (часть 2)» Тема: «Модели производственных процессов»

Проверил: Салапура Марина Николаевна

Выполнил: студент группы 602321с (дистанционная форма обучения) Wasja

Минск 2011

1 Задание

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

1)Определение проекта.

2)Основные понятия (цель проекта – Project Metaphor) и фазы выполнения проекта по каждой методике.

3)Основные аспекты выполнения проектов (календарные сроки и трудозатраты, людские ресурсы, производимые артефакты).

2 Выполнение работы

2.1 Описание проекта

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

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

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

−Подсистема управления движущимся составом, предназначенная для отслеживания и управления интервалами движения поездов и т.п.

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

−Подсистема управления персоналом, предназначенная для отслеживания занятости персонала метрополитена, фиксирования рабочего времени и т.п.

−Дополнительные специализированные подсистемы, предназначенные для поддержания работоспособности метрополитена.

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

2.2 Методология Rational Unified Process (RUP)

Rational Unified Process (RUP) – это модель создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой. RUP обеспечивает строгий подход к распределению

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

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

Модель жизненного цикла RUP является детально проработанной итера- тивно-инкрементной моделью с элементами каскадной модели. В модели RUP выделяются 4 основные фазы и 9 видов деятельности (процессов):

Рисунок 1 – Жизненный цикл RUP

Основными фазами RUP являются (каждая фаза может содержать несколько итераций в зависимости от сложности проекта):

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

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

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

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

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

Деятельности (основные процессы) RUP делятся на 5 рабочих и 4 поддерживающие. К рабочим деятельностям относятся:

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

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

иоценок ресурсозатрат в нем. Требования принято фиксировать в виде модели вариантов использования. Непосредственные исполнители: представитель заказчика и бизнес-аналитик.

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

4)Реализация (Implementation). Разработка исходного кода, компонент системы, тестирование и интегрирование компонент. Производимый результат: готовое приложение. Непосредственные исполнители: системный архитектор и программисты.

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

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

Поддерживающими деятельностями являются:

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

2)Управление конфигурациями (Configuration and Change Management).

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

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

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

2.3 Методология XP

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

Рисунок 2 – Жизненный цикл XP

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

Основными фазами модели можно считать:

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

2)Истории использования (User Story) – этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. Истории являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки.

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

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

5)Тестирование проводится с участием заказчика, который участвует в составлении тестов.

6)Выпуск релиза – разработанная версия передается заказчику для использования или бета-тестирования.

По завершению цикла делается переход на следующую итерацию разра-

ботки.

ВXP есть несколько правил (техник), характеризующих особенности модели его жизненного цикла:

1)Живое планирование (planning game) – как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе бизнес-приоритетов заказчика и технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика.

2)Частая смена версий (small releases) - первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.

3)Простые проектные решения (simple design) – в каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Новые функции добавляются только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.

4)Разработка на основе тестирования (test-driven development) – сначала пишутся тесты, потом реализуются модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.

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

6)Программирование парами (pair programming) – код пишется двумя программистами на одном компьютере, что повышает его качество (отсутствие ошибок, понятность, читаемость).

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

8)40-часовая рабочая неделя – сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд – это угнетает программистов и делает их работу значительно менее продуктивной.

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

3 Заключение

Основные особенности RUP и XP можно свести в таблицу 1. По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании IBM. Сопровождение разработки системы и самой системы регламентируется самой методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.

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

Таблица 1 – Технологии RUP и XP

	Технология	Оптимальная	Соответствие	Допустимые техноло-	Удобство модификации и сопро-
		команда	стандартам	гии и инструменты	вождения
	Rational Unified	10 – 40 чел.	стандарты Ra-	UML и продукты Ra-	Удобно
	Process		tional/IBM	tional/IBM
	XP	2 – 10 чел.	стандарты от-	любые	Сложно (зависимость от конкрет-
			сутствуют		ных участников коллектива)

На практике были установлены определённые условия, при которых достигается максимальная эффективность использования XP: группа разработчиков от двух до десяти человек, проект на срок до полугода и присутствие заказчика на месте разработки. Поскольку рассматриваемый проект разработки программного обеспечения для метрополитена не соответствует данным требованиям, то в данном случае оптимальной методикой разработки программного обеспечения будет являться методология RUP.