Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
«Казанский государственный технологический университет»
Нижнекамский химико-технологический институт
Реферат на тему:
«Реинжиниринг программного обеспечения»
Выполнил:Нагимова Д.И.
Проверила:Хурматуллина С.А.
Нижнекамск 2010
Введение
Цели и задачи реинжиниринга
Проблемы при реинжиниринге
Управление требованиями
Процесс
Анализ и проектирование
Реализация
Тестирование
Процессы поддержки
Преимущества и недостатки компании-разработчика перед отдельным разработчиком
Почему компании-разработчики не любят реинжиниринг
Рентабельность реинжиниринга
Компьютер без программного обеспечения - груда металла, которую к тому же нельзя сдать на металлолом. Купив даже самый быстродействующий компьютер, предприятие не решает основной проблемы - автоматизация предприятия. Для этого нужны программы.
Разнообразие программного обеспечения куда больше, чем технических решений. Так как они решают самые различные задачи, начиная от связи с оборудованием (драйвера) и заканчивая автоматизацией бухгалтерского учета или 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. Общие сведения»). С его помощью можно быстрее и точнее определить состав актеров наследуемой системы и основные ВИ. Эксперт заказчика может словесно описать, кто использует систему и что она должна делать для пользователей каждого типа. Он может также информировать, с какими другими системами взаимодействует наследуемая ПС, какие работы осуществляются периодически. Все эти сведения будут способствовать более точному пониманию функциональности системы разработчиками.
Определение актеров. Для нахождения актеров следует искать ответы на следующие вопросы:
Ответы на поставленные вопросы можно получить либо путем опроса экспертов заказчика, либо из документации на систему, либо (если таковых не имеется) путем запуска системы и анализа экранных форм или меню.
Актерам следует присвоить имена, отражающие их роли в работе с системой.
Определение вариантов использования. Определение ВИ выполняется на основе анализа экранов работающей системы. Сначала определяются пакеты ВИ. Для этого следует найти все первичные экраны и для каждого из них в модели на головной диаграмме ВИ завести отдельный пакет. Таким образом, на этой диаграмме будет пакет актеров и несколько пакетов ВИ.
Далее выполняется детализация построенных пакетов ВИ на основе анализа экранных форм. Рекомендуемые правила:
Определение взаимодействий актеров и ВИ. Поскольку очень важно показать, как актеры соотносятся с ВИ, после нахождения ВИ определяется, какие актеры взаимодействуют с системой в этом варианте. В модель включаются ассоциации. Они имеют направления, соответствующие направлениям передачи информации между актерами и ВИ.
Распределение по пакетам. Если число актеров или ВИ слишком велико, то для упрощения поддержки модели ВИ целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Можно использовать следующие критерии упаковки ВИ в один пакет:
Могут быть и другие способы обеспечения наглядности модели, важно лишь иметь четкую стратегию разбиения на пакеты.
Построение навигации экранов. Одновременно с выделением ВИ строится навигация экранов наследуемой системы в виде диаграммы классов UML. Каждый экран показывается в модели как отдельный класс, в котором полям соответствуют атрибуты, функциональным кнопкам – операции, а кнопкам меню – одноименные отношения.
Детализация функциональности. Детализация функциональности представляет собой построение сценариев реализации ВИ, представленных в модели ВИ. Она выполняется с помощью диаграмм последовательностей и диаграмм деятельностей UML. Выбор вида диаграмм в каждом конкретном случае зависит от того, что преобладает в данном ВИ – логика выполнения или передачи данных. В первом случае предпочтительно применять диаграммы деятельностей, где легко показывать ветвления и параллельную обработку, во втором – диаграммы последовательностей.
Детализация требуется в особенности для тех вариантов использования, в которых важна последовательность действий, учитывается состояние системы, имеется разветвленная логика выполнения. Целесообразно детализировать выполнение ВИ, определяющих основную функциональность системы. Если заказчик высказывает пожелания относительно того, что из наследуемой системы должно быть сохранено в новой ПС, то именно эти ВИ должны быть детализированы.
Детализация осуществляется на основе анализа исходных кодов. По текстам программ выявляются ветвления, выражения, циклы. Это позволяет восстановить алгоритмы, представив их в виде диаграмм деятельностей или диаграмм состояний. Другой путь – это проведение экспериментов с работающей наследуемой системой. Варьирование входных данных и анализ реакции системы на эти данные делает возможным обнаружение ветвлений и ограничений. Можно также выдвигать и проверять гипотезы об алгоритмах вычислений.
Модели, построенные в результате реинжиниринга, являются основой для определения требований к проектируемой ПС, а также для построения логической и функциональной моделей новой системы.
Цели реинжиниринга
Цели проведения реинжиниринга заключаются в следующем:
Задачи реинжиниринга
Задачи, решаемые при реинжиниринге, включают:
Порядок решения этих задач принципиально отличается от порядка действий, выполняемых при разработке новых проектов. Логическая архитектура системы определена ее реализацией, в частности, структурой каталогов, размещением файлов по каталогам, распределением задач между сервером и клиентскими местами. Кроме того, часть моделей системы может быть получена автоматически с помощью инструментальных средств. Таким образом, не функциональное описание системы служит основой для выявления классов и отношений между ними, а наоборот, предварительно полученные диаграммы классов могут существенно облегчить описание поведения системы.
Как правило утверждается, что "легче разработать новый программный продукт". Это связано со следующими проблемами:
В то же время, если изначально программа обладала строгой и ясной архитектурой, то провести реинжиниринг будет на порядок проще. Поэтому при проектировании как правило анализируется, что выгоднее провести реинжиниринг или разработать программный продукт "с нуля".
Требования к ПС
Требование – это характеристика или условие, которому должна удовлетворять ПС.
Функциональные требования определяют действия, которые должна выполнять ПС, без учета физических ограничений. Тем самым они определяют поведение системы при вводе и выводе. Процесс выявления функциональных требований весьма сложный и трудоемкий. Это объясняется следующими причинами:
Для преодоления этих трудностей применяется моделирование требований. Модель требований позволяет, во-первых, установить иерархию требований, что способствует лучшему пониманию человеком, во-вторых, дает наглядное графическое представление требований и зависимостей между ними, в третьих позволяет связать графическую форму представления с текстовой, обеспечивая человека полной информацией.
Нефункциональные требования не описывают поведение программной системы, но описывают ее атрибуты или атрибуты окружения. Нефункциональные требования не требуется включать в модель требований, но они должны быть точно сформулированы. Обычно нефункциональных требований не бывает много, однако они кардинальным образом влияют на выбор архитектуры системы.
Управление требованиями – это достаточно сложный и растянутый во времени процесс. Он продолжается в течение большей части жизненного цикла, поскольку изменения могут вноситься как во время разработки, так и после сдачи системы на этапе опытной эксплуатации и при сопровождении. Причины этого заключаются в том, что требования:
Цели анализа и моделирования требований
Целями анализа и моделирования требований являются:
Роли
Артефакты
Для достижения поставленных целей предусматривается создание следующих документов:
В процессе анализа и моделирования требований можно выделить несколько основных этапов (см. рис.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 оказался практически не возможным, экономически не выгодным. Программа постоянно сбоила. Надежность ее была очень низкая.
В результате получился примерно такой график рентабельности обслуживания+разработки программы (по вертикали - в тысячах $, по горизонтали - в количестве компьютеров, реально работающих с программой):
Из графика видим, что на начальном этапе, реинжиниринг программы обходится дешевле. Но, в процессе эксплуатации, предприятие начало бы терять огромные деньги из-за плохой работы программы.
Данная система не работала нигде. Поэтому мы посчитали, что в данном случае полная переделка программы оказалась бы более выгодной в результате, чем реинжиниринг программы.
Переделка программы стоит на начальном этапе значительно больше, но в результате получается стабильно работающий программный продукт и с значительно более дешевым обслуживанием.
Список использованной литературы