Процесс создания новой функциональности или устранения ошибок путем революционного изменения

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

Федеральное агентство по образованию

Государственное образовательное
учреждение высшего профессионального образования

«Казанский государственный
технологический университет»

Реферат на тему:

Выполнил:Нагимова Д.И.

Нижнекамск 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. Общие сведения»). С его помощью можно быстрее и точнее определить
состав актеров наследуемой системы и основные ВИ. Эксперт заказчика может
словесно описать, кто использует систему и что она должна делать для пользователей
каждого типа. Он может также информировать, с какими другими системами
взаимодействует наследуемая ПС, какие работы осуществляются периодически. Все
эти сведения будут способствовать более точному пониманию функциональности
системы разработчиками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·
неочевидны,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роли

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

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

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

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

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

Артефакты

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

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

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

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

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

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

Процесс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роли

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

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

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

Артефакты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

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

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

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

Роли

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

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

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

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

Артефакты

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

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

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

Процесс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роли

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

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

Артефакты

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

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

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

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

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

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

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

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

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

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

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

Процесс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.codenet.ru/progr/other/reengineering.php]

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

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

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

Связанные понятия

Управле́ние разрабо́ткой програ́ммного обеспе́чения (англ. Software project management) — особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по разработке программного обеспечения является правильный выбор метода разработки.

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование…

Програ́ммное обеспе́чение (допустимо также произношение обеспече́ние) (ПО) — программа или множество программ, используемых для управления компьютером (ISO/IEC 26514:2008).

Управление требованиями к программному обеспечению (англ. software requirements management) — процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритизацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.

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

Открытое проектирование (англ. open design) — способ разработки и сопровождения эксплуатации физических изделий, а также машин и систем, путём использования публичной совместно используемой информации о конструкции. Процесс, как правило, идёт с использованием глобальной сети Интернет, лицензий Creative Commons и часто выполняется без монетизации вознаграждения. Цели и философия идентичны политике открытого кода, но применимо к разработке физических изделий, а не программного обеспечения.

Бизнес-анализ (англ. business analysis) — деятельность, которая делает возможным проведение Изменений в организации, приносящих пользу Заинтересованным Сторонам, путём выявления Потребностей и обоснования Решений, описывающих возможные пути реализации Изменений.

Открытое программное обеспечение (англ. open-source software) — программное обеспечение с открытым исходным кодом. Исходный код таких программ доступен для просмотра, изучения и изменения, что позволяет убедиться в отсутствии уязвимостей и неприемлемого для пользователя функционала (к примеру, скрытого слежения за пользователем программы), принять участие в доработке самой открытой программы, использовать код для создания новых программ и исправления в них ошибок — через заимствование исходного кода…

Непрерывная интеграция (CI, англ. Continuous Integration) — практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо…

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

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

Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает…

Компью́теры пя́того поколе́ния (яп. 第五世代コンピュータ) — в соответствии с идеологией развития компьютерных технологий, после четвёртого поколения, построенного на сверхбольших интегральных схемах, ожидалось создание следующего поколения, ориентированного на распределенные вычисления, одновременно считалось, что пятое поколение станет базой для создания устройств, способных к имитации мышления.

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

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

Операцио́нная систе́ма, сокр. ОС (англ. operating system, OS) — комплекс взаимосвязанных программ, предназначенных для управления ресурсами компьютера и организации взаимодействия с пользователем.

Интегри́рованная среда́ разрабо́тки, ИСP (англ. Integrated development environment — IDE), также единая среда разработки, ЕСР — комплекс программных средств, используемый программистами для разработки программного обеспечения (ПО).

Консорциум по перспективным вычислительным средам (Advanced Computing Environment consortium, ACE consortium, Консорциум «Передовая вычислительная среда») — существовавшее в начале 1990-х годов объединение предприятий, заинтересованных в следующем поколении компьютеров, которое, как предполагалось, должно было прийти на смену персональным компьютерам, основывавшимся на 32-разрядной архитектуре процессоров Intel. Эти усилия нашли мало поддержки на рынке, и консорциум был распущен из-за отсутствия…

Прототипи́рование (англ. prototyping от др.-греч. πρῶτος — первый и τύπος — отпечаток, оттиск; первообраз) — быстрая «черновая» реализация базовой функциональности для анализа работы системы в целом.

Свободное программное обеспе́чение (СПО, англ. free software, также software libre или libre software), свободный софт — программное обеспечение, пользователи которого имеют права («свободы») на его неограниченную установку, запуск, свободное использование, изучение, распространение и изменение (совершенствование), а также распространение копий и результатов изменения. Если на программное обеспечение есть исключительные права, то свободы объявляются при помощи свободных лицензий.

Сопровождение программного обеспечения стандартизовано, имеются национальные стандарты Российской Федерации, идентичные международным (ISO/IEC 12207:2008 System and software engineering — Software life cycle processes, ГОСТ Р ИСО/МЭК 12207-2010 «Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; ISO/IEC 14764:99 Information tehnology — Software maintenance, ГОСТ Р ИСО/МЭК 14764-2002 «Государственный…

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование. Является частью общеинженерной дисциплины «инженерия требований» (англ. Requirements Engineering).

«Серебряной пули нет» (англ. «No Silver Bullet») — широко обсуждавшаяся статья Фредерика Брукса об инженерии программного обеспечения, написанная им в 1986 году. Брукс утверждает, что «ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту». Он также утверждает, что «мы не можем ожидать увеличения прибыли в два раза каждые два года» при разработке программного обеспечения, как это происходит с разработкой…

Общие критерии оценки защищённости информационных технологий, Общие критерии, ОК (англ. Common Criteria for Information Technology Security Evaluation, Common Criteria, CC) — принятый в России международный стандарт по компьютерной безопасности. В отличие от стандарта FIPS 140, Common Criteria не приводит списка требований по безопасности или списка особенностей, которые должен содержать продукт. Вместо этого он описывает инфраструктуру (framework), в которой потребители компьютерной системы могут…

Управление проектами — область деятельности, в ходе которой определяются и достигаются чёткие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и другими), временем, качеством и рисками (PMBoK) .

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

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

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

Дизайн-система — набор компонентов, правил, предписаний и инструментов для повышения качества и скорости разработки продуктов, а также эффективной поддержки существующих. В английском языке для обозначения дизайн-систем чаще всего используют понятие «design language», определяя также его главное отличие от дизайн-системы – возможность использования вне сферы цифровых продуктов. Одним из примеров такого «визуального языка» может служить узнаваемое оформление автомобилей компании BMW (фары, решетка…

Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.

Лисп (LISP, от англ. LISt Processing language — «язык обработки списков»; современное написание: Lisp) — семейство языков программирования, программы и данные в которых представляются системами линейных списков символов. Лисп был создан Джоном Маккарти для работ по искусственному интеллекту и до сих пор остаётся одним из основных инструментальных средств в данной области. Применяется он и как средство обычного промышленного программирования, от встроенных скриптов до веб-приложений массового использования…

Транзакционная память (англ. Transactional memory, TM) — технология синхронизации общей памяти для конкурирующих потоков, позволяющая им выполнять операции сохранения, которые воспринимаются другими потоками как атомарные. Эта технология упрощает параллельное программирование, выделяя целые группы различных инструкций в атомарные транзакции. Конкурирующие потоки работают параллельно, пока не начинают модифицировать одну и ту же область памяти.

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

Проприета́рное програ́ммное обеспе́чение, несвобо́дное программное обеспечение (англ. proprietary software; от proprietary «частное, патентованное, в составе собственности» + software «программное обеспечение») — программное обеспечение, являющееся частной собственностью авторов или правообладателей и не удовлетворяющее критериям свободного ПО (наличия открытого программного кода недостаточно). Правообладатель проприетарного ПО сохраняет за собой монополию на его использование, копирование и модификацию…

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

Программное обеспечение совместной работы (англ. collaborative software, groupware, workgroup support systems, group support systems) — программное обеспечение, созданное с целью поддержки взаимодействия между людьми, совместно работающими над решением общих задач. Так как устоявшегося русскоязычного термина пока нет, часто используется один из англоязычных без перевода.

Разграничение доступа на основе атрибутов (англ. Attribute-Based Access Control, ABAC) — модель контроля доступа к объектам, основанная на анализе правил для атрибутов объектов или субъектов, возможных операций с ними и окружения, соответствующего запросу. Системы управления доступом на основе атрибутов обеспечивают мандатное и избирательное управление доступом. Рассматриваемый вид разграничения доступа дает возможность создать огромное количество комбинаций условий для выражения различных политик…

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

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

А́да (Ada) — язык программирования, созданный в 1979—1980 годах в ходе проекта Министерством обороны США с целью разработать единый язык программирования для встроенных систем (то есть систем управления автоматизированными комплексами, функционирующими в реальном времени). Имелись в виду прежде всего бортовые системы управления военными объектами (кораблями, самолётами, танками, ракетами, снарядами и т. п.). Перед разработчиками не стояло задачи создать универсальный язык, поэтому решения, принятые…

Распределительная вычислительная среда (англ. Distributed Computing Environment, сокр. DCE) — система программного обеспечения, разработанная в начале 1990-х годов в Open Software Foundation, который представлял собой ассоциацию нескольких компаний: Apollo Computer, IBM, Digital Equipment Corporation и других. DCE предоставляет фреймворк и средства разработки клиент-серверных приложений.

Патенты на программное обеспечение (или программные патенты; англ. software patents), также патенты на вычислительные идеи (англ. computational idea patents) — патенты на математические и алгоритмические методы, содержащиеся в программном обеспечении; или (по определению, предложенному Фондом за свободную информационную инфраструктуру) «патент на что‐либо, выполняемое компьютером посредством программного обеспечения».Аргументы защитников программных патентов таковы…

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

Технологическая дорожная карта (англ. Technology Roadmap) — краткосрочный или долгосрочный план выпуска производителем какого-либо продукта. Чаще всего это новая версия или развитие уже известного продукта, изменений в котором ждут потребители. Технологическая дорожная карта может содержать средства, подходы или пути, необходимые для достижения поставленных вех. Как правило, понятие «Технологическая дорожная карта» применяется к новому продукту, процессу или разрабатываемой технологии. Созданная…

Программная инженерия (англ. software engineering) — приложение систематического, дисциплинированного, измеримого подхода к разработке, функционированию и сопровождению программного обеспечения, а также исследованию этих подходов; то есть, приложение дисциплины инженерии к программному обеспечению (ISO/IEC/IEEE 24765-2010).

Проекти́рование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части (ISO 24765). Результатом проектирования является прое́кт — целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы.:272Проектирование, наряду с анализом требований, является частью большой стадии жизненного цикла системы, называемой определением системы (англ. system definition). Результаты этой стадии являются входной информацией…

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

Офис управления портфелем проектов (Project Management Office — PMO) — ОУП — это подразделение, которое занимается координацией, обобщением информации и централизацией прикрепленных к нему проектов, ведет сводный мониторинг бюджетов и графиков портфеля проектов, обеспечивает коммуникации между различными портфелями группы, обеспечивает скоординированную работу менеджеров проектов портфеля по вопросам стандартизации качества проектов.

У этого термина существуют и другие значения, см. Реинжиниринг.

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

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

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

1. обычному программисту сложно разобраться в чужом исходном коде;
2. реинжиниринг, чаще всего, дороже разработки нового программного обеспечения, так как требуется убрать ограничения предыдущих версий, но при этом оставить совместимость с предыдущими версиями;
3. реинжиниринг не может сделать программист низкой и средней квалификации — даже профессионалы, часто не могут качественно реализовать его, поэтому требуется работа программистов с большим опытом переделки программ и знанием различных технологий^{[уточнить]}.

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

См. также

• Рефакторинг

Примечания

Ссылки

• The Program Transformation Wiki  (англ.)  (Проверено 26 октября 2009)
• The Architecture-Driven Modernization website at OMG  (англ.)  (Проверено 26 октября 2009)

Макетирование.

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

Генерация документации.

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

Автоматическая генерация объектного кода.

Генерация
программ в машинном коде осуществляется
на основе репозитория и позволяет
автоматически построить до 85-90% объектного
кода или текстов на языках высокого
уровня. 

Сопровождение и реинжиниринг.

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

№ 13.
Понятие «алгоритм». Его свойства.

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

Основные
свойства алгоритмов:

1. дискретность
   – отдельные операции реализуются в
   дискретном времени (для выполнения
   каждого шага алгоритма требуется
   конечный отрезок времени);

2. массовость
   – определение пригодности алгоритма
   для решения любой задачи с различными
   исходными данными;

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

4. результативность
   – получение результата решения задачи
   за конечно число шагов;

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

№14.
Способы описания алгоритмов.

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

• обеспечивать
  компактную и наглядную запись алгоритма;

• быть общепонятны и
  удобным для использования в публикациях;

• содержать строгие
  правила для исключений неоднозначностей
  в понимании сделанной записи;

• допускать простой
  и формальный перевод алгоритма на ЯП.

Словесное описание.

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

Достоинства:

• простота представления
  алгоритма;

• отсутствие строгих
  правил;

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

Недостатки:

• произвольное словесное
  описание может привести к неоднозначному
  пониманию записи;

• для сложных алгоритмов
  описание становится слишком громоздким
  и теряет свою наглядность.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

Реинжиниринг, как радикальное переосмысление и перепроектирование деловых процессов, в ИТ-индустрии реализуется по следующим направлениям:

• Реинжиниринг программного обеспечения (как ее разновидность — Обра́тная разрабо́тка (обратный инжиниринг, реверс-инжиниринг; англ. reverse engineering));
• Реинжиниринг бизнес-процессов

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

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

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

Реинжиниринг бизнес-процессов (англ. Business process reengineering)— фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимального эффекта производственно — хозяйственной и финансово — экономической деятельности, оформленное соответствующими организационно -распорядительными и нормативными документами. Реинжиниринг использует специфические средства представления и обработки проблемной информации, понятные как менеджерам, так и разработчикам информационных систем.

Применительно к разработке информационных систем в области систем управления предприятиями, на которых специализируется НПОДО «Профит», реинжиниринг бизнес-процессов реализуется через реинжиниринг систем управления бизнес-процессами: учета, планирования, контроля, анализа, отчетности.