48783 (666088), страница 5
Текст из файла (страница 5)
Управление состоянием и измерениями
Этот процесс связан с управлением проектом и направлен на предоставление информации, полезной для оценки:
-
Состояния, прогресса, общих тенденций и качества продукта;
-
Издержек и расходов;
-
Проблемных областей, требующих внимания;
-
Того, что сделано и что необходимо сделать.
Вся необходимая информация находится в базе данных и архиве проекта. Руководитель работ оценивает состояние дел путем непосредственного просмотра запросов, истории версий артефактов или на основе анализа различных отчетов, формируемых инструментальным средством УК. Анализ позволяет руководителю оценить имеющиеся ресурсы и принять необходимые управленческие решения.
Деятельности
Планирование конфигурации проекта и управления изменениями. Описываются все виды деятельности, связанные с УК, которые надо выполнить. Описывается процесс контроля над изменениями.
Создание среды УК. Целью этой деятельности является создание рабочей среды, в которой будут доступны все артефакты, будет обеспечена разработка, интеграция и архивирование продукта.
Создание рабочей среды исполнителей. В пределах своей рабочей среды исполнитель получает доступ к артефактам проекта, имеет возможность вносить в них изменения и предлагать внесение изменений в проект в целом. Изменения, сделанные отдельными исполнителями, направляются в рабочую среду интеграции.
Управление версиями. При записи артефакта в архив проекта формируется его новая версия. Управление версиями предусматривает обязательное указание причин и целей создания версии. При выборе артефакта из архива можно указать конкретную версию.
Управление запросами на внесение изменений. Целью этой деятельности является обеспечение последовательного внесения изменений в проект и информирование о состоянии продукта, его изменениях и о влиянии изменений на стоимость и сроки выполнения проекта.
Наблюдение за состоянием конфигурации. Наблюдаемость процесса разработки обеспечивается путем доступа руководства проекта к хранимым артефактам и запросам на изменения, а также путем предоставления отчетов о состоянии конфигурации. При этом инструментальные средства, поддерживающие управление конфигурацией и изменениями, могут выполнять требуемые измерения. Например, можно показать процент завершенных запросов, число открытых запросов высокого приоритета и т. д.
Управление средой. Цели
Многие виды деятельностей, предусмотренные RUP, могут быть автоматизированы посредством инструментальных средств, что позволит избежать наиболее трудоемких, напряженных и подверженных ошибкам аспектов разработки ПС.
Цель процесса управления средой – процедурная и инструментальная поддержка организации, разрабатывающей ПС. Она включает:
-
Выбор и приобретение инструментальных средств;
-
Настройку инструментальных средств под требования организации-разработчика;
-
Конфигурирование процесса;
-
Усовершенствование процесса;
-
Создание технических служб поддержки.
Роли и артефакты
Основным исполнителем процесса является технолог. В его обязанности входит конфигурирование процесса перед запуском проекта и усовершенствование процесса в ходе проектных работ. Поддержка аппаратной и программной среды разработки ложится на плечи системного администратора.
Главным создаваемым артефактом является план разработки, описывающий процесс, используемый в данном проекте. В нем указывается, какие артефакты, предусматриваемые в RUP, будут использоваться в проекте и каким образом.
Деятельности
Подготовка среды к реализации проекта. Выполняется оценка текущего состояния организации-разработчика и имеющейся инструментальной поддержки. Создается предварительный план разработки. Составляется перечень инструментальных средств, которые предполагается использовать при разработке. Составляется перечень шаблонов для производства основных артефактов.
Подготовка среды к итерации. Производится дополнение и уточнение плана разработки, выполняется подготовка и настройка инструментальных средств, которые будут использоваться в итерации. Составляется набор шаблонов для артефактов, создаваемых в итерации. Осуществляется подготовка сотрудников к использованию инструментальных средств.
Подготовка руководящих директив. Для каждого основного технологического процесса подготавливается набор директив на основе анализа проблем и дефектов предыдущих итераций.
Преимущества и недостатки компании-разработчика перед отдельным разработчиком
Теперь, перечислим преимущества и недостатки компании-разработчика перед отдельным разработчиком.
Преимущества компании-разработчика перед отдельным разработчиком:
-
Компания может "тянуть" большие и очень большие проекты. Отдельный же разработчик крупный проект может не осилить физически.
-
В компании, как правило, работает группа людей с различным образованием, тем самым дополняя и развивая знания друг-друга. В компании-разработчике переплетаются знания людей различных школ. Отдельный же разработчик варится в своем соку. Основной источник знаний у него - книги и Интернет.
-
Стандартизация исходного текста в компании значительно выше, чем у отдельного разработчика, т.к. в компании работает группа разработчиков.
-
Технически, компании выше оснащены, чем один разработчик.
-
Источников информации у компании больше, чем у отдельного разработчика. А это отражается на результате - разрабатываемой программе.
-
У компании значительно выше опыт работы с различными проектами, чем у отдельного человека.
-
В компаниях больше направлений развития программных средств.
-
Компания может предоставить комплексный подход при наличии специалистов различных направлений.
-
Все, что тратится по договору с компанией идет в затраты. В то время, как отдельный программист чаще всего работает на зарплату.
-
Скорость разработки компании выше, чем у одного человека, т.к. можно подключать к проекту нескольких человек.
-
Разрабатывая программный продукт, компания тестирует его и пишет документацию. Отдельный же разработчик часто ленится это делать. А если не ленится и пытается писать документацию или тестировать, то развитие программного продукта временно приостанавливается (на время написания документации или тестирования).
-
Компания не уволится.
-
Компания не умрет и ее не переедет автобус.
-
Компания не заболеет и по этой причине не приостановит поддержку.
-
В компании всегда будут люди, которые смогут продолжить дело.
-
Компания берет на себя головную боль по поиску высоко-квалифицированных и ответственных программистов.
-
Компания следит за технологиями и тенденциями развития программного обеспечения.
Недостатки компании-разработчика перед отдельным разработчиком:
-
отдельный разработчик обходится дешевле, т.к. у него нет необходимости арендовать повешение, платить коммунальные платежи, нет необходимости в рекламе и в других издержках, присутствующих в любом предприятии. Компании же необходимо оплачивать арендные платежи, налоги, коммунальные платежи, зарплату (а у программистов она ну очень большая) и т.д.
-
программист-одиночка легче идет на уступки предприятию, т.к. сам отвечает за свое благосостояние. Компания-разработчик не может позволить себе пойти часто на уступки в ущерб компании, так как это приведет к ее банкротству.
-
отдельный разработчик может постоянно присутствовать на заданном предприятии, работая на нем, как сотрудник, а компания не может такого позволить. Даже предоставляя человека для обслуживания предприятия, компания время от времени должна вызывать его в офис, обучать.
Почему компании-разработчики не любят реинжиниринг
Не много компаний реально занимается реинжинирингом программ. Если Вы закажете реинжиниринг, то вероятней всего Вам скажут: и пойдут именно этим путем. В результате Вы получите другую программу, которая может, решит те проблемы, которые были, но которая уже, возможно, будет обладать новыми проблемами... И не обязательно программного решения...
Почему же так не охотно компании берутся за реинжиниринг?
Вот они причины:
-
Программисты не любят разбираться в чужом исходном тексте. Это все равно, что разбираться в каракулях, написанных другим человеком (и часто левой ногой).
-
Реинжиниринг чаще всего дороже разработки нового программного обеспечения. Т.к. требуется переломить ограничения предыдущих версий, но при этом соблюдать совместимость по возрастанию версий. Т.е. Предоставить возможность конвертировать данные из старых версий в новую.
-
Реинжиниринг не может сделать программист низкой и средней квалификации. Даже профессионалы часто не могут качество реализовать его. Для грамотного реинжиниринг нужны эксперты - программисты с большим опытом переделки программ и знанием различных технологий.
-
Исправлять чужую программу - большая ответственность, т.к. можно не заметить или не понять назначение каких-то алгоритмов, реализованных предыдущим программистом.
-
Программисту может понадобиться разбираться с технологиями, с которыми он не работает, но которые используются в программе.
Рентабельность реинжиниринга
Чаще всего, реинжиниринг программ обходится дороже, чем разработка программы. Причиной этого является то, что нужно соблюдать совместимость новой версии со старой или же реализовывать конвертер старых данных в новые, а так же необходимость обходить ограничения, навязанные предыдущими версиями программ.
Рассмотрим два примера реинжиниринга из жизни.
1-й пример: На одном крупном предприятии с большим количеством филиалов работала программа, разработанная штатным программистом. На некотором этапе, данный программист не смог продолжать работу. В результате, на предприятии было 2 версии программы: одна старая версия, работающая на BDE и одна новая, но не до конца работающая и доступ к данным в которой был совершенно другой: компоненты прямого доступа. Старую версию пытались установить на филиалах, но без успешно, а в центральном офисе она работала с большими ошибками. Из-за чего, возникали большие очереди из заказчиков и в результате, компания терпела большие убытки. Программа была разработана на Delphi, с использованием сервера базы данных Interbase 6. Таблиц в программе было 10-11 штук, а хранимых процедур и триггеров практически не использовалось.
Задача: Разработать новую версию программы в которой бы были реализованы новые потребности компании, исправлены ошибки, возникающие в центральном офисе и на филиалах и которая бы смогла работать на филиалах. Так же важно, чтобы программа быстро работала и не создавалась очередь из заказчиков. Предусмотреть значительно больший сервис, чем есть в данной программе, а в дальнейшем обеспечить систему безопасности на должном уровне программы и обмен данными между филиалами.
Решение: Технология построения первичного приложения полностью удовлетворяет всем текущим и будущим потребностям, поэтому изменять ни средство разработки, ни базу данных нет необходимости. Таблиц в проекте не много, форм тоже, поэтому, можно попробовать не создавать программу заново (особенно, учитывая, что программа уже работает), а взяться за реинжиниринг программы. Исходный текст программы написан сравнительно грамотно (хотя и было много замечаний), поэтому полностью переписывать текст не пришлось.
В данном проекте реинжиниринг прошел полностью успешно. И программа пошла на дальнейшее развитие.
2-й пример: Один институт более 10 лет разрабатывал программу расчета, CAD-систему. Программа была написана одним инженером, который сам изучил Delphi и написал программу, взяв алгоритмы из программы на Fortran. В качестве базы данных использовались dbf-файлы. Исходный текст программы написан очень плохо, без форматирования, без наименования компонент человеческими названиями (названия, часто вообще не изменялись и оставлялись такими, как назначал Delphi). Кроме того, система состояла из ряда dll (на каждую форму), исходный текст которых находился в различных каталогах, а файлы юнитов назывались одинаково. Проекты чертежей хранились в отдельных каталогах отдельных баз данных.
Задача: Привести программу к коммерческому виду. Организовать систему защиты от копирования. Организовать систему безопасности на современном уровне. Переделать базу данных на Firebird. Организовать возможность импорта/экспорта информации. Увеличить возможности графического редактора (например, откат изменений). А так же многое другое такого же типа.
Решение: Исходный текст пришлось полностью переформатировать. Проекты объединять в один exe-файл, а одинаковые юниты удалять. Пришлось построить схему базы данных. В результате оказалось, что база данных избыточная, а структура безграмотно составлена. Систему от копирования организовали. Но перевод в Firebird оказался практически не возможным, экономически не выгодным. Программа постоянно сбоила. Надежность ее была очень низкая.