УК позволяет:

· исключить возможность потери артефактов,

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

· гарантировать точное повторение действий над группой связанных артефактов в итерациях,

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

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

Управление внесением изменений

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

Управление состоянием и измерениями

Этот процесс связан с управлением проектом и направлен на предоставление информации, полезной для оценки:

· Состояния, прогресса, общих тенденций и качества продукта;

· Издержек и расходов;

· Проблемных областей, требующих внимания;

· Того, что сделано и что необходимо сделать.

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

Деятельности

Планирование конфигурации проекта и управления изменениями. Описываются все виды деятельности, связанные с УК, которые надо выполнить. Описывается процесс контроля над изменениями.

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

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

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

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

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

Управление средой. Цели

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

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

· Выбор и приобретение инструментальных средств;

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

· Конфигурирование процесса;

· Усовершенствование процесса;

· Создание технических служб поддержки.

Роли и артефакты

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

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

Деятельности

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

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

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

Преимущества и недостатки компании-разработчика перед отдельным разработчиком

· Компания может "тянуть" большие и очень большие проекты. Отдельный же разработчик крупный проект может не осилить физически.

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

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

· Технически, компании выше оснащены, чем один разработчик.

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

· У компании значительно выше опыт работы с различными проектами, чем у отдельного человека.

· В компаниях больше направлений развития программных средств.

· Компания может предоставить комплексный подход при наличии специалистов различных направлений.

· Все, что тратится по договору с компанией идет в затраты. В то время, как отдельный программист чаще всего работает на зарплату.

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

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

· Компания не уволится.

· Компания не умрет и ее не переедет автобус.

· Компания не заболеет и по этой причине не приостановит поддержку.

· В компании всегда будут люди, которые смогут продолжить дело.

· Компания берет на себя головную боль по поиску высоко-квалифицированных и ответственных программистов.

· Компания следит за технологиями и тенденциями развития программного обеспечения.

Недостатки компании-разработчика перед отдельным разработчиком:

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

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

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

Почему компании-разработчики не любят реинжиниринг

Почему же так не охотно компании берутся за реинжиниринг?

Вот они причины:

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

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

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

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

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

Рентабельность реинжиниринга

Список использованной литературы

1. [http://www.informicus.ru /default.aspx?SECTION=6&id=73 &subdivisionid=17]

2.[ http://www.newlinestudio.ru/ArticleReengirinPO.php]

3.[ http://www.codenet.ru/progr/other/reengineering.php]

4.[http://ru.wikipedia.org]