Управление проектом разработки web-приложения с использованием методологии RUP

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

В данной курсовой работе будут рассмотрены оссобености разработки и использования web приложений, в частности применение технологии RUP(Rational Unified Process) - Рациональный унифицированный процесс -- спиральная методология разработки программного обеспечения. Будут рассмотрена оссобености и основные достоинства технологии, указаны сферы в которых она применима. На конкретном примере будет рассмотрена эффективность от применения этого метода, представлены основные этапы разработки приложения, произведен расчет экономических и технических показателей и оценка эффективности применения данной методологии.

1. Описание методологии RUP.

Методология создана и поддерживается фирмой Rational Software, два раза в год выпускаются обновления продукта. Для моделирования в общей базе знаний применяется язык Unified Modelling Language (UML).

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

Главные принципы методологии рационального унифицированный процесса:

1. Выявление и постоянное устранение основных рисков.

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

3. Готовность к тому что изменятся в требования, проектные решения и и другие вводные данные в процессе разработки.

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

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

6. Главную роль в команде разработчиков выполняют архитекторы.

Этапы разработки методологии RUP:

1. Начальная стадия или исследование (Inception)

2. Уточнение (Elaboration)

3. Построение (Construction)

4. Развертывание (Transition).

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

2. Цель работы

Компания "MIR" разработала WEB-приложение, предназначенный для автоматического выполнения действий на Web-серверах. Продукт не смог получить большую популярность и число пользователей начало неуклонно снижаться.

За последние пол года количество посещений пользователями Web-приложения «MIR» снизилось, а рост расходов на поддержку проекта составил 30%. На настоящий момент число пользователей менее чем 50 тысяч человек при этом тенденция сокращения числа пользователей сохраняется на уровне примерно 7% в месяц. Компании пришлось искать новые пути и технологии для привлечения пользователей интернет к своим продуктам.

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

Компания заказчик изложила следующие требования в техническом задании:

* интерактивная разработка Web-приложения;

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

* применение модульных архитектур;

* применение визуального моделирования;

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

* отслеживание изменений приложения.

Срок выполнения проекта - 18 месяцев, дата завершения - начало ноября 2017 года. Объем затрат, выделенный компанией на реализацию проекта, составляет 1000 000 евро .

Реализация проекта поручена стороннему исполнителю - системному интегратору фирме «Scada».

3. Обоснование проекта

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

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

2) изложила несоответствие потребностей и ожиданий пользователей;

3) большие операционные и временные издержи;

4) недостатков в бизнес-процессах программы.

Воздействие участников на проект показано в таблице 3.1

Таблица 3.1. Роль и ответственность участников проекта

1) формирование общего плана проекта и стратегии по разработке и внедрению системы менеджмента качества;

2) Цикл центральной службы консультаций рабочих групп;

Информация по проекту сводится в таблицу 3.2

Таблица 3.2. Сводная начальная информация по проекту.

4. Содержание проекта

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

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

2. Проектирование (Elaboration).

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

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

4. Тестирование проекта - проверка взаимодействия между объектами;

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

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

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

Иерархическая структура работ приведена на рис. 4.1.

Рис. 4.1. Иерархическая структура работ

Таблица 4.1. Словарь ИСР

5. Организационная структура проекта

Основным документом регулирующем выполнение проекта в компании «MIR», является оно штатное расписание проекта, в котором отражается структура, состав и численность.

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

Для описания организационной структуры построим матрицу задании RACI в которой:

По вертикали в матрице отражаются основные задачи проекта (не ниже характеристик уровня 2-3 ИСР).

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

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

программный унифицированный интерфейс веб

Таблица 5.1. Матрица RACI

Таблица 5.2 Коды полей матрицы ответственности

Таблица 5.3. Матрица ответственности

Таблица 5.4 Смета проекта

6. Календарный ролями план проекта

Календарный план проекта приведен на рисунке 6.1.

Рис. 6.1

7. План управления рисками

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

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

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

Таблица 7.1. Оценка вероятности возникновения риска

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

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

Таблица 7.3. Оценка последствий риска

Таблица 7.4. Оценка вероятности возникновения риска

Таблица 7.5. Определение влияния рисков на достижение целей

8. План управления изменениями

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

Процедура управления изменениями:

1. Запрос на изменение. Инициатор запроса выдает требование, которое выходит за рамки проекта и является изменением.

2. Регистрация запроса в специальном реестре изменений. Любые запросы на изменение нужно фиксировать в специальном документе «Реестр запросов на изменение» (или Реестр изменений), в котором хранится список всех запросов на изменения.

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

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

5. Решение. По результатам обсуждения предлагаемого изменения должно быть принято одно из трех решений:

1) Принять

2) Отклонить

3) Отложить

6. Внесение изменений в план:

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

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

7. Выполнение работ. Так как изменение внесено в план, то оно является частью проекта.

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

9. Управленческая отчетность по проекту

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

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

Заключение

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

Литература

1. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Методические основы управления ИТ-проектами.

2. Светлов, Н.М. Информационные технологии управления проектами: учебное пособие / Н.М. Светлов, Г.Н. Светлова .-- 2-е изд., перераб. И доп. -- М.: Инфра-М, 2012 .-- 232 с.

3. Просветов Г.И. Управление рисками: задачи и решения: Учебно-практическое пособие / Г.И. Просветов .-- М. : Альфа-Пресс, 2008; 416 с.

4. Арчибальд Р.Д. Управление высокотехнологичными программами и проектами. Москва: ДМК Пресс, 2010.- 464 с.

Размещено на Allbest.ru