Реферат: Реинжиниринг программного обеспечения

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

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

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

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

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

Столкнувшись с данной проблемой, предприятие начинает искать нового программиста или компанию, которая способна привести данную программу к удовлетворяющему предприятие виду. Однако, как оказывается не все так просто... Оказывается, большое количество программистов, которые хоть что-нибудь умеют сделать уехало за рубеж. А на рынке остались те, кто уехать не смог или кому не было в этом потребности. Предприятию очень повезет, если оно сразу найдет грамотного и ответственного программиста. Как правило, придется перебрать 2-3 человека, прежде, чем они найдут достойную кандидатуру. Однако, грамотные программисты дешево не стоят и постоянно хотят перспектив. Поэтому, если вы не быстро развивающееся программное предприятие, да еще не так уж и много платите, то придет момент, что данный программист уйдет тоже. И опять начинается все снова: 2-3 безответственных программиста, потом один профессиональный и ответственный, который 2-3 месяца будет вникать в курс дела и через 2-3 года уйдет...

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

Определение и этапы реинжиниринга

Реинжиниринг программного обеспечения — процесс создания новой функциональности или устранения ошибок, путём революционного изменения, но используя уже имеющееся в эксплуатации программное обеспечение. Процесс реинжиниринга описан Chikofsky и Кроссом в их труде 1990 года, как «The examination and alteration of a system to reconstitute it in a new form». Выражаясь менее формально, реинжиниринг является изменением системы программного обеспечения после проведения обратного инжиниринга.

Реинжиниринг программного обеспечения, можно разделить на несколько этапов:

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

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

Автоматический реинжиниринг. Автоматический реинжиниринг осуществляется с помощью инструментальных средств визуального моделирования. Его выполнение позволяет построить модели, которые могут быть приняты как исходные. Автоматическому реинжинирингу подвергается как бизнес логика (если есть исходные коды на объектно-ориентированном или объектно-базированном языке), так и БД.

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

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

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

Если диаграмма содержит слишком много элементов, то анализировать ее сложно. Попробуйте проанализировать диаграмму, содержащую более 100 классов! Поэтому целесообразно разбить такую диаграмму на несколько отдельных диаграмм, оставляя в каждой примерно по 7 – 10 элементов.

Метод повышения наглядности диаграмм хорошо известен. Это иерархическая реструктуризация. Средством ее осуществления в UML являются пакеты. Сложные ПС обычно включают несколько подсистем, имеющих разное целевое назначение и функциональность. Поэтому на верхнем уровне иерархии можно показать пакеты – подсистемы. Каждый из таких пакетов должен получить имя, отражающее суть соответствующей подсистемы. На этом уровне можно также показать пакеты классов, являющиеся общими для всей системы и используемые подсистемами. На начальной стадии реструктуризации логической модели можно ввести пакет верхнего уровня, куда помещаются классы, которые трудно отнести к какому-либо другому пакету. В любой ПС есть пользовательский интерфейс, связь с БД, управление, обработка, классы данных. Такого типа пакеты можно ввести в каждой подсистеме на следующем уровне иерархии.

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

Определение актеров. Для нахождения актеров следует искать ответы на следующие вопросы:

Кто является непосредственными пользователями системы? Необходимо при ответе на данный вопрос указывать роли, а не конкретных людей, исполняющих эти роли.

С каким внешним оборудованием или программами осуществляет взаимодействие система?

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

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

Актерам следует присвоить имена, отражающие их роли в работе с системой.

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

Далее выполняется детализация построенных пакетов ВИ на основе анализа экранных форм. Рекомендуемые правила:

если экран содержит меню, то это пакет ВИ. При этом каждая строка меню – это либо подпакет, либо отдельный ВИ;

если основной экран – форма, то это отдельный ВИ.

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

Распределение по пакетам. Если число актеров или ВИ слишком велико, то для упрощения поддержки модели ВИ целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Можно использовать следующие критерии упаковки ВИ в один пакет:

если они взаимодействуют с одним актером;

имеют друг с другом отношения включения или расширения (см. статью «Варианты использования системы. Use case диаграммы»).

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

Построение навигации экранов. Одновременно с выделением ВИ строится навигация экранов наследуемой системы в виде диаграммы классов UML. Каждый экран показывается в модели как отдельный класс, в котором полям соответствуют атрибуты, функциональным кнопкам – операции, а кнопкам меню – одноименные отношения.

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

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

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

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

Цели и задачи реинжиниринга

Цели реинжиниринга

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

получение представления о составе существующей системы;

моделирование существующей системы;

определение фрагментов программного кода, которые могут быть использованы в разрабатываемой новой системе;

определение наследуемых данных.

Задачи реинжиниринга

Задачи, решаемые при реинжиниринге, включают:

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

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

определение функциональности существующей системы;

определение логической структуры системы;

восстановление реляционной модели данных.

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

Проблемы при реинжиниринге

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

Обычному программисту сложно разобраться в чужом исходном коде

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

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

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

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

Требования к ПС

Требование – это характеристика или условие, которому должна удовлетворять ПС.

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

таких требований к системе обычно много,

заказчик не всегда способен четко сформулировать, чего он хочет от системы,

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

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

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

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

Управление требованиями – это достаточно сложный и растянутый во времени процесс. Он продолжается в течение большей части жизненного цикла, поскольку изменения могут вноситься как во время разработки, так и после сдачи системы на этапе опытной эксплуатации и при сопровождении. Причины этого заключаются в том, что требования:

неочевидны,

исходят из многих источников,

трудно формулируются (язык неоднозначен),

состоят из множества различных деталей,

неравнозначны,

связаны друг с другом,

лежат не только в функциональной области.

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

Цели анализа и моделирования требований

Целями анализа и моделирования требований являются:

достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать ПС;

достижение лучшего понимания разработчиками того, что должна делать система;

ограничение системной функциональности;

создание базиса для планирования разработки проекта;

определение пользовательского интерфейса;

составление спецификации требований.

Роли

Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований.

Разработчик ВИ – специалист организации-разработчика, который детализирует и уточняет модели требований.

Заинтересованные лица – люди, предоставляющие информацию.

Эксперт – представитель заказчика, участвующий в разработке модели требований.

Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС.

Артефакты

Для достижения поставленных целей предусматривается создание следующих документов:

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

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

Спецификация требований (Software Requirements Specification) – основной документ, используемый при проектировании и разработке ПС. Она включает модель требований и дополнительные спецификации, которые представляют собой текстовое описание требований к конечному продукту, но не к процессу его разработки и не содержат деталей реализации требований.

Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса пользователя с ПС.

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

Процесс

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

Реинжиниринг программного обеспечения

Рис.1 Технологический процесс управления требованиями.

Начало анализа.

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

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

Построение модели требований

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

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

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

Детализация модели требований

Цели данной деятельности:

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

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

реструктуризация модели требований;

детальное описание потоков событий для ВИ;

задание приоритетов ВИ.

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

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

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

Составление дополнительных спецификаций

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

Проектирование пользовательского интерфейса

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

программная реализация, воспроизводящая точный вид экранных окон;

альбом экранных форм;

модель навигации экранов в виде диаграмм классов с указанием атрибутов – полей и операций – кнопок.

Создание спецификации требований

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

Анализ и проектирование

Цель и задачи анализа и проектирования

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

К числу решаемых задач при этом относятся:

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

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

адаптация проекта системы к среде реализации с целью повышения производительности разработки;

выбор механизмов реализации и определение ограничений на реализацию;

разработка компонентной структуры;

распределение компонентов по узлам.

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

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

Роли

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

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

Разработчик БД – отвечает за проектирование базы данных ПС.

Артефакты

В процессе анализа и проектирования создаются следующие документы:

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

Документ «Архитектура ПС», в котором собраны различные архитектурные представления ПС.

Модель данных – это описание структуры данных, хранимых в БД (например, реляционная модель данных).

Технологический процесс

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

Реинжиниринг программного обеспечения

Рис.2 Диаграмма деятельностей, описывающая процесс анализа и проектирования

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

Уточнение архитектуры. Деятельность включает определение механизмов проектирования, элементов проекта, объединения существующих элементов проекта, описание архитектуры реального времени (если проектируемая ПС относится к этому классу). В результате выполнения этих работ достигаются следующие цели:

Обеспечивается переход от анализа к проектированию путем определения из элементов и механизмов анализа элементов и механизмов проектирования;

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

Осуществляется плавный переход от проектирования к реализации;

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

Проектирование компонентов. Цели данной деятельности состоят в:

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

Определении и уточнении реализации ВИ на основе новых элементов проекта.

Контроле и рецензировании проекта по мере его развития.

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

Проектирование БД. Данная деятельность выполняется для проектов, использующих базы данных. Она включает:

Определение персистентных (постоянно хранимых) классов;

Проектирование структуры БД для хранения таких классов;

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

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

Реализация

Цели процесса реализации

Основные цели процесса можно сформулировать следующим образом:

Определить структуру кода в виде уровней;

Реализовать компоненты, классы и объекты;

Провести блочное тестирование компонент;

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

В процесс реализации не включено тестирование всей ПС, для которого в RUP предусмотрен отдельный процесс (см. следующую статью).

Особенности процесса реализации

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

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

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

Роли

Конструктор (кодировщик) разрабатывает компоненты и классы, выполняет блочное тестирование.

Системный интегратор выполняет интеграцию элементов в программные конструкции (систему и подсистемы).

Архитектор определяет структуру реализации (организацию уровней и подсистем).

Рецензент кода проверяет качество программного кода и его соответствие стандартам проекта.

Артефакты

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

Компонент часть программного кода (см. статью «Компонентно-базированная разработка»).

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

Процесс

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

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

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

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

Интеграция системы. Выполняется интеграция системы путем последовательного добавления в нее новых подсистем, созданных в рамках текущей итерации. Интеграция подсистемы завершается созданием набора программных конструкций подсистемы, каждая из которых тестируется по отдельности. Для тестирования системы в RUP предусмотрен отдельный процесс.

Тестирование

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

Цели процесса тестирования

Целью тестирования является оценка качества программного продукта путем

Проверки взаимодействия компонентов;

Проверки правильности интеграции компонентов;

Проверки точности реализации всех требований и выявления дефектов.

Особенности процесса тестирования в RUP

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

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

Роли

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

Тестировщик (испытатель) отвечает за выполнение системного тестирования. В его обязанности входит настройка и выполнение тестов, оценки выполнения теста, восстановление после ошибок, регистрация выявленных дефектов.

Артефакты

В процессе тестирования создаются следующие документы:

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

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

Контрольная задача – набор тестовых данных, условий выполнения тестов и ожидаемых результатов.

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

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

Тестовый скрипт является программой, выполняемой при автоматическом тестировании с помощью инструментальных средств тестирования.

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

Результаты тестирования и данные, полученные в процессе выполнения тестов.

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

Дефекты – это описания обнаруженных при проведении тестирования фактов несоответствия системы предъявляемым требованиям. Они представляют собой вид запросов на внесение изменений.

Процесс

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

Фаза вхождения в проект. В этой фазе выполняется подготовка к тестированию. Она включает:

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

Анализ объема тестирования.

Формулирование критериев качества и завершения тестирования.

Установку и подготовки к работе инструментальных средств тестирования.

Формулирование требований к проекту разработки ПС, определяемых потребностями тестирования.

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

Создание плана тестирования для каждой итерации.

Разработка сценариев тестирования.

Создание заготовок тестовых скриптов.

Разработка контрольных задач.

Разработка методики испытаний.

Разработка модели рабочей нагрузки.

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

Создание плана тестирования для каждой итерации.

Уточнение и дополнение модели тестирования.

Выполнение тестов.

Описание обнаруженных дефектов.

Описание результатов тестирования.

Оценка результатов тестирования.

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

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

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

Инструментальная поддержка

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

Процессы поддержки

RUP предусматривает три процесса поддержки:

Управление проектом;

Управление конфигурацией;

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

Управление проектом. Цели

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

Планирование предполагает созданий двух видов планов:

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

План итераций создается для каждой итерации и предназначается для определения и распределения задач между участниками проекта.

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

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

Управление проектом. Деятельности

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

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

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

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

Сформулировть объективные критерии успеха итерации. Они будут использоваться при ее оценке;

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

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

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

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

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

Завершение фазы. Выполняются работы, завершающие выполнение фазы. Даются ответы на следующие основные вопросы:

Решены ли все основные проблемы предыдущей итерации?

Известно ли состояние всех основных артефактов (см. ниже управление конфигурацией)?

Рассмотрены ли все проблемы развертывания?

При удовлетворительном состоянии проекта выдается разрешение на переход к следующей фазе.

Завершение проекта. Руководитель проекта подготавливает проект к завершению. Готовится заключительная оценка состояния. При успешной сдаче проекта заказчик получает программный продукт в пользование. Высвобождающие ресурсы могут быть перераспределены (использованы в других проектах).

Управление конфигурацией и изменениями. Цели

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

Управление конфигурацией (Configuration management).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не много компаний реально занимается реинжинирингом программ. Если Вы закажете реинжиниринг, то вероятней всего Вам скажут: <легче разработать новый программный продукт> и пойдут именно этим путем. В результате Вы получите другую программу, которая может, решит те проблемы, которые были, но которая уже, возможно, будет обладать новыми проблемами... И не обязательно программного решения...

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

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

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

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

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

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

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

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

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

Рассмотрим два примера реинжиниринга из жизни.

1-й пример: На одном крупном предприятии с большим количеством филиалов работала программа, разработанная штатным программистом. На некотором этапе, данный программист не смог продолжать работу. В результате, на предприятии было 2 версии программы: одна старая версия, работающая на BDE и одна новая, но не до конца работающая и доступ к данным в которой был совершенно другой: компоненты прямого доступа. Старую версию пытались установить на филиалах, но без успешно, а в центральном офисе она работала с большими ошибками. Из-за чего, возникали большие очереди из заказчиков и в результате, компания терпела большие убытки. Программа была разработана на Delphi, с использованием сервера базы данных Interbase 6. Таблиц в программе было 10-11 штук, а хранимых процедур и триггеров практически не использовалось.

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

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

В данном проекте реинжиниринг прошел полностью успешно. И программа пошла на дальнейшее развитие.

2-й пример: Один институт более 10 лет разрабатывал программу расчета, CAD-систему. Программа была написана одним инженером, который сам изучил Delphi и написал программу, взяв алгоритмы из программы на Fortran. В качестве базы данных использовались dbf-файлы. Исходный текст программы написан очень плохо, без форматирования, без наименования компонент человеческими названиями (названия, часто вообще не изменялись и оставлялись такими, как назначал Delphi). Кроме того, система состояла из ряда dll (на каждую форму), исходный текст которых находился в различных каталогах, а файлы юнитов назывались одинаково. Проекты чертежей хранились в отдельных каталогах отдельных баз данных.

Задача: Привести программу к коммерческому виду. Организовать систему защиты от копирования. Организовать систему безопасности на современном уровне. Переделать базу данных на Firebird. Организовать возможность импорта/экспорта информации. Увеличить возможности графического редактора (например, откат изменений). А так же многое другое такого же типа.

Решение: Исходный текст пришлось полностью переформатировать. Проекты объединять в один exe-файл, а одинаковые юниты удалять. Пришлось построить схему базы данных. В результате оказалось, что база данных избыточная, а структура безграмотно составлена. Систему от копирования организовали. Но перевод в Firebird оказался практически не возможным, экономически не выгодным. Программа постоянно сбоила. Надежность ее была очень низкая.

В результате получился примерно такой график рентабельности обслуживания+разработки программы (по вертикали - в тысячах $, по горизонтали - в количестве компьютеров, реально работающих с программой):

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

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

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

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

1. []

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

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

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

Реферат: Реинжиниринг программного обеспечения

Похожие работы: