p align="left">Управление состоянием и измерениями Этот процесс связан с управлением проектом и направлен на предоставление информации, полезной для оценки: · Состояния, прогресса, общих тенденций и качества продукта; · Издержек и расходов; · Проблемных областей, требующих внимания; · Того, что сделано и что необходимо сделать. Вся необходимая информация находится в базе данных и архиве проекта. Руководитель работ оценивает состояние дел путем непосредственного просмотра запросов, истории версий артефактов или на основе анализа различных отчетов, формируемых инструментальным средством УК. Анализ позволяет руководителю оценить имеющиеся ресурсы и принять необходимые управленческие решения. Деятельности Планирование конфигурации проекта и управления изменениями. Описываются все виды деятельности, связанные с УК, которые надо выполнить. Описывается процесс контроля над изменениями. Создание среды УК. Целью этой деятельности является создание рабочей среды, в которой будут доступны все артефакты, будет обеспечена разработка, интеграция и архивирование продукта. Создание рабочей среды исполнителей. В пределах своей рабочей среды исполнитель получает доступ к артефактам проекта, имеет возможность вносить в них изменения и предлагать внесение изменений в проект в целом. Изменения, сделанные отдельными исполнителями, направляются в рабочую среду интеграции. Управление версиями. При записи артефакта в архив проекта формируется его новая версия. Управление версиями предусматривает обязательное указание причин и целей создания версии. При выборе артефакта из архива можно указать конкретную версию. Управление запросами на внесение изменений. Целью этой деятельности является обеспечение последовательного внесения изменений в проект и информирование о состоянии продукта, его изменениях и о влиянии изменений на стоимость и сроки выполнения проекта. Наблюдение за состоянием конфигурации. Наблюдаемость процесса разработки обеспечивается путем доступа руководства проекта к хранимым артефактам и запросам на изменения, а также путем предоставления отчетов о состоянии конфигурации. При этом инструментальные средства, поддерживающие управление конфигурацией и изменениями, могут выполнять требуемые измерения. Например, можно показать процент завершенных запросов, число открытых запросов высокого приоритета и т. д. Управление средой. Цели Многие виды деятельностей, предусмотренные RUP, могут быть автоматизированы посредством инструментальных средств, что позволит избежать наиболее трудоемких, напряженных и подверженных ошибкам аспектов разработки ПС. Цель процесса управления средой - процедурная и инструментальная поддержка организации, разрабатывающей ПС. Она включает: · Выбор и приобретение инструментальных средств; · Настройку инструментальных средств под требования организации-разработчика; · Конфигурирование процесса; · Усовершенствование процесса; · Создание технических служб поддержки. Роли и артефакты Основным исполнителем процесса является технолог. В его обязанности входит конфигурирование процесса перед запуском проекта и усовершенствование процесса в ходе проектных работ. Поддержка аппаратной и программной среды разработки ложится на плечи системного администратора. Главным создаваемым артефактом является план разработки, описывающий процесс, используемый в данном проекте. В нем указывается, какие артефакты, предусматриваемые в RUP, будут использоваться в проекте и каким образом. Деятельности Подготовка среды к реализации проекта. Выполняется оценка текущего состояния организации-разработчика и имеющейся инструментальной поддержки. Создается предварительный план разработки. Составляется перечень инструментальных средств, которые предполагается использовать при разработке. Составляется перечень шаблонов для производства основных артефактов. Подготовка среды к итерации. Производится дополнение и уточнение плана разработки, выполняется подготовка и настройка инструментальных средств, которые будут использоваться в итерации. Составляется набор шаблонов для артефактов, создаваемых в итерации. Осуществляется подготовка сотрудников к использованию инструментальных средств. Подготовка руководящих директив. Для каждого основного технологического процесса подготавливается набор директив на основе анализа проблем и дефектов предыдущих итераций. Преимущества и недостатки компании-разработчика перед отдельным разработчикомТеперь, перечислим преимущества и недостатки компании-разработчика перед отдельным разработчиком. Преимущества компании-разработчика перед отдельным разработчиком: · Компания может "тянуть" большие и очень большие проекты. Отдельный же разработчик крупный проект может не осилить физически. · В компании, как правило, работает группа людей с различным образованием, тем самым дополняя и развивая знания друг-друга. В компании-разработчике переплетаются знания людей различных школ. Отдельный же разработчик варится в своем соку. Основной источник знаний у него - книги и Интернет. · Стандартизация исходного текста в компании значительно выше, чем у отдельного разработчика, т.к. в компании работает группа разработчиков. · Технически, компании выше оснащены, чем один разработчик. · Источников информации у компании больше, чем у отдельного разработчика. А это отражается на результате - разрабатываемой программе. · У компании значительно выше опыт работы с различными проектами, чем у отдельного человека. · В компаниях больше направлений развития программных средств. · Компания может предоставить комплексный подход при наличии специалистов различных направлений. · Все, что тратится по договору с компанией идет в затраты. В то время, как отдельный программист чаще всего работает на зарплату. · Скорость разработки компании выше, чем у одного человека, т.к. можно подключать к проекту нескольких человек. · Разрабатывая программный продукт, компания тестирует его и пишет документацию. Отдельный же разработчик часто ленится это делать. А если не ленится и пытается писать документацию или тестировать, то развитие программного продукта временно приостанавливается (на время написания документации или тестирования). · Компания не уволится. · Компания не умрет и ее не переедет автобус. · Компания не заболеет и по этой причине не приостановит поддержку. · В компании всегда будут люди, которые смогут продолжить дело. · Компания берет на себя головную боль по поиску высоко-квалифицированных и ответственных программистов. · Компания следит за технологиями и тенденциями развития программного обеспечения. Недостатки компании-разработчика перед отдельным разработчиком:· отдельный разработчик обходится дешевле, т.к. у него нет необходимости арендовать повешение, платить коммунальные платежи, нет необходимости в рекламе и в других издержках, присутствующих в любом предприятии. Компании же необходимо оплачивать арендные платежи, налоги, коммунальные платежи, зарплату (а у программистов она ну очень большая) и т.д.· программист-одиночка легче идет на уступки предприятию, т.к. сам отвечает за свое благосостояние. Компания-разработчик не может позволить себе пойти часто на уступки в ущерб компании, так как это приведет к ее банкротству.· отдельный разработчик может постоянно присутствовать на заданном предприятии, работая на нем, как сотрудник, а компания не может такого позволить. Даже предоставляя человека для обслуживания предприятия, компания время от времени должна вызывать его в офис, обучать.Почему компании-разработчики не любят реинжинирингНе много компаний реально занимается реинжинирингом программ. Если Вы закажете реинжиниринг, то вероятней всего Вам скажут: <легче разработать новый программный продукт> и пойдут именно этим путем. В результате Вы получите другую программу, которая может, решит те проблемы, которые были, но которая уже, возможно, будет обладать новыми проблемами... И не обязательно программного решения... Почему же так не охотно компании берутся за реинжиниринг? Вот они причины: · Программисты не любят разбираться в чужом исходном тексте. Это все равно, что разбираться в каракулях, написанных другим человеком (и часто левой ногой). · Реинжиниринг чаще всего дороже разработки нового программного обеспечения. Т.к. требуется переломить ограничения предыдущих версий, но при этом соблюдать совместимость по возрастанию версий. Т.е. Предоставить возможность конвертировать данные из старых версий в новую. · Реинжиниринг не может сделать программист низкой и средней квалификации. Даже профессионалы часто не могут качество реализовать его. Для грамотного реинжиниринг нужны эксперты - программисты с большим опытом переделки программ и знанием различных технологий. · Исправлять чужую программу - большая ответственность, т.к. можно не заметить или не понять назначение каких-то алгоритмов, реализованных предыдущим программистом. · Программисту может понадобиться разбираться с технологиями, с которыми он не работает, но которые используются в программе. Рентабельность реинжинирингаЧаще всего, реинжиниринг программ обходится дороже, чем разработка программы. Причиной этого является то, что нужно соблюдать совместимость новой версии со старой или же реализовывать конвертер старых данных в новые, а так же необходимость обходить ограничения, навязанные предыдущими версиями программ. Рассмотрим два примера реинжиниринга из жизни. 1-й пример: На одном крупном предприятии с большим количеством филиалов работала программа, разработанная штатным программистом. На некотором этапе, данный программист не смог продолжать работу. В результате, на предприятии было 2 версии программы: одна старая версия, работающая на BDE и одна новая, но не до конца работающая и доступ к данным в которой был совершенно другой: компоненты прямого доступа. Старую версию пытались установить на филиалах, но без успешно, а в центральном офисе она работала с большими ошибками. Из-за чего, возникали большие очереди из заказчиков и в результате, компания терпела большие убытки. Программа была разработана на Delphi, с использованием сервера базы данных Interbase 6. Таблиц в программе было 10-11 штук, а хранимых процедур и триггеров практически не использовалось. Задача: Разработать новую версию программы в которой бы были реализованы новые потребности компании, исправлены ошибки, возникающие в центральном офисе и на филиалах и которая бы смогла работать на филиалах. Так же важно, чтобы программа быстро работала и не создавалась очередь из заказчиков. Предусмотреть значительно больший сервис, чем есть в данной программе, а в дальнейшем обеспечить систему безопасности на должном уровне программы и обмен данными между филиалами. Решение: Технология построения первичного приложения полностью удовлетворяет всем текущим и будущим потребностям, поэтому изменять ни средство разработки, ни базу данных нет необходимости. Таблиц в проекте не много, форм тоже, поэтому, можно попробовать не создавать программу заново (особенно, учитывая, что программа уже работает), а взяться за реинжиниринг программы. Исходный текст программы написан сравнительно грамотно (хотя и было много замечаний), поэтому полностью переписывать текст не пришлось. В данном проекте реинжиниринг прошел полностью успешно. И программа пошла на дальнейшее развитие. 2-й пример: Один институт более 10 лет разрабатывал программу расчета, CAD-систему. Программа была написана одним инженером, который сам изучил Delphi и написал программу, взяв алгоритмы из программы на Fortran. В качестве базы данных использовались dbf-файлы. Исходный текст программы написан очень плохо, без форматирования, без наименования компонент человеческими названиями (названия, часто вообще не изменялись и оставлялись такими, как назначал Delphi). Кроме того, система состояла из ряда dll (на каждую форму), исходный текст которых находился в различных каталогах, а файлы юнитов назывались одинаково. Проекты чертежей хранились в отдельных каталогах отдельных баз данных. Задача: Привести программу к коммерческому виду. Организовать систему защиты от копирования. Организовать систему безопасности на современном уровне. Переделать базу данных на Firebird. Организовать возможность импорта/экспорта информации. Увеличить возможности графического редактора (например, откат изменений). А так же многое другое такого же типа. Решение: Исходный текст пришлось полностью переформатировать. Проекты объединять в один exe-файл, а одинаковые юниты удалять. Пришлось построить схему базы данных. В результате оказалось, что база данных избыточная, а структура безграмотно составлена. Систему от копирования организовали. Но перевод в Firebird оказался практически не возможным, экономически не выгодным. Программа постоянно сбоила. Надежность ее была очень низкая. В результате получился примерно такой график рентабельности обслуживания+разработки программы (по вертикали - в тысячах $, по горизонтали - в количестве компьютеров, реально работающих с программой): Из графика видим, что на начальном этапе, реинжиниринг программы обходится дешевле. Но, в процессе эксплуатации, предприятие начало бы терять огромные деньги из-за плохой работы программы. Данная система не работала нигде. Поэтому мы посчитали, что в данном случае полная переделка программы оказалась бы более выгодной в результате, чем реинжиниринг программы. Переделка программы стоит на начальном этапе значительно больше, но в результате получается стабильно работающий программный продукт и с значительно более дешевым обслуживанием. Список использованной литературы 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]
Страницы: 1, 2, 3, 4, 5
|