Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Технологии создания программного обеспечения 391

рении

ТС

ПО.

большинстве случаев такая интеграция

процес-

се пилотного проектирования не осуществляется, однако накоп-

ленная при этом информация может помочь

разработке планов

интеграции. Для планирования интеграции необходима следую-

щая информация:

• наименования и версии существующих средств, с которыми

должны интегрироваться новые средства;

• описания данных, которые должны совместно использо-

ваться новыми

существующими средствами,

также пред-

варительная информация об источниках этих данных;

• описания других взаимосвязей между новыми и существу-

ющими средствами (таких, как связи по передаче управле-

ния и порядку использования), а также предварительная

информация о механизмах поддержки этих взаимосвязей;

• оценки затрат, сроков

рисков, связанных

интефацией (и,

возможно, с переходом от существующих средств

данных);

• способы внедрения данных средств

деятельность

по

совер-

шенствованию существующих процессов;

• ожидаемые изменения в существующих процессах и про-

дуктах, являющиеся следствием использования новых

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

Риск, связанный с интеграцией новых средств с существую-

щими средствами и процессами, снижается, если потребности в

интеграции учитываются в процессе оценки и выбора

ТС

ПО.

Обучение и ресурсы, используемые в течение и после заверше-

ния

процесса перехода

Данная информация должна охватывать:

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

интег-

раторов), нуждающийся

обучении использованию ТС ПО;

• вид обучения, необходимого для каждой категории пользо-

вателей и обслуживающего персонала,

учетом особой важ-

ности обучения совместному использованию различных

средств, а также методам и процессам, связанным с данны-

ми средствами;

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

(например, для группы тестирования и независимой служ-

бы сертификации);

• частоту обучения;

• виды

доступность поддержки.

392 Глава 5

Определение стандартных

процедур

использования средств

План перехода должен определять начальную практику при-

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

нение любой ТС ПО в конкретной организации и конкретном

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

лашений), которые должны соблюдаться всеми участниками

проекта (это особенно актуально при коллективной разработке

ПО большим количеством групп специалистов). К таким стан-

дартам относятся следующие:

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

• соглашения по присвоению имен;

• процедуры контроля качества и процессов приемки, вклю-

чая расписание экспертиз и используемые методологии;

• процедуры резервного копирования, защиты мастер-копий

и конфигурирования базы данных проекта;

• процедуры интефации с существующими средствами и ба-

зами данных;

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

целостности базы данных;

• стандарты и процедуры обеспечения секретности;

• стандарты документирования;

• стандарт проектирования;

• стандарт оформления проектной документации;

• стандарт интерфейса пользователя.

Стандарт проектирования должен устанавливать:

• набор необходимых моделей (диаграмм) на каждой стадии

проектирования и степень

их

детализации;

• правила фиксации проектных решений на диафаммах, в

том числе правила именования объектов (включая соглаше-

ния по терминологии), набор атрибутов для всех объектов и

правила их заполнения на каждой стадии, правила оформ-

ления диафамм (включая требования к форме и размерам

объектов) и

т.

д.;

• требования к конфигурации рабочих мест разработчиков,

включая настройки операционной системы, настройки

CASE-средств и

т.

д.;

• механизм обеспечения совместной работы над проектом, в

том числе правила интефации подсистем проекта, правила

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

состоянии (регламент обмена проектной информацией, ме-

Технологии создания программного обеспечения 393

ханизм фиксации общих объектов и т.д.), правила анализа

проектных решений на непротиворечивость и

т.

д.

Стандарт оформления проектной документации должен уста-

навливать:

• комплектность, состав

структуру документации на каждой

стадии проектирования (в соответствии со стандартом

ГОСТ Р ИСО 9127-94 «Системы обработки информации.

Документация пользователя и информация на упаковке

потребительских программных пакетов»);

• требования к оформлению документации (включая требо-

вания к содержанию разделов, подразделов, пунктов, таб-

лиц и т.д.);

• правила подготовки, рассмотрения, согласования и утверж-

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

каждой стадии;

• требования к настройке издательской системы, используе-

мой

качестве встроенного средства подготовки документа-

ции;

• требования к настройке CASE-средств для обеспечения

подготовки документации

соответствии

установленными

правилами.

Стандарт интерфейса пользователя должен регламентиро-

вать:

• правила оформления экранов (шрифты и цветовая палит-

ра),

состав и расположение окон и элементов управления;

• правила использования клавиатуры и мыши;

• правила оформления текстов помощи;

• перечень стандартных сообщений;

• правила обработки реакции пользователя.

Стандарты использования ТС ПО, выработанные во время

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

ной точки для разработки более полного набора стандартов ис-

пользования средств в данной организации. При этом должен

учитываться опыт участников пилотного проекта.

Реализация плана перехода

Реализация плана перехода требует постоянного мониторин-

га использования ТС ПО, обеспечения текущей поддержки, соп-

ровождения и обновления ее средств по мере необходимости.

394 Глава 5

Периодические экспертизы

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

экспертизе в соответствии с графиком. План перехода должен

при необходимости корректироваться. Постоянное внимание

должно уделяться степени удовлетворения потребностей органи-

зации и критериев успешного внедрения ТС ПО.

Периодические экспертизы должны продолжаться и после

завершения процесса внедрения. Такие экспертизы могут анали-

зировать метрики и другую информацию, получаемую в процес-

се работы с ТС ПО, чтобы определять, насколько хорошо она

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

также указать на необходимость дополнительной модификации

процессов.

Текущая поддержка

Необходимо определить источники для текущей поддержки

ТС ПО. Такая поддержка должна обеспечивать:

• получение ответов на вопросы, связанные с использовани-

ем ТС ПО;

• передачу информации о достигнутых успехах и полученных

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

• модификацию и совершенствование стандартов, соглаше-

ний и процедур, связанных с использованием ТС ПО;

• интефацию новых средств с существующими и сопровож-

дение интегрированных средств по мере появления новых

версий;

• помощь новым сотрудникам в освоении ТС ПО и связанных

с ней процедур;

• планирование и контроль обновления версий;

• планирование внедрения новых возможностей ТС ПО в ор-

ганизационные процессы.

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

Для поддержки процесса перехода к практическому исполь-

зованию ТС ПО желательно выполнение следующих действий:

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

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

версий ТС ПО или вовлечения в проект новых сотрудников;

• поддержка ролевых функций, связанных с процессом внед-

рения. Поскольку внедрение ТС ПО приводит к изменени-

Технологии создания программного обеспечения 395

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

ния вьщелить ряд ключевых ролей (руководство высшего

уровня, проектная фуппа и целевые группы);

• управление обновлением версий. Управление может быть

связано с такими вопросами, как обновление версий, про-

цедуры установки и ответственные за установку, процедуры

контроля качества

для

оценки новых версий, процедуры об-

новления базы данных, конфигурация версий и среда под-

держки (другие средства, операционная система и т.д.);

• свободный доступ к информации. Должны быть определе-

ны механизмы, обеспечивающие свободный доступ к ин-

формации об опыте внедрения и извлеченных из этого уро-

ках, включая доски объявлений, информационные бюлле-

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

• налаживание тесного рабочего взаимодействия с поставщи-

ком, позволяющего организации быть в курсе планов пос-

тавщика

обеспечивать нормальную обратную связь

соот-

ветствии со своими требованиями.

Для успешного внедрения ТС ПО в организации существен-

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

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

определить характер будущего использования ТС ПО как отдель-

ными разработчиками, так

фуппами. Использование стандарт-

ных процедур позволит обеспечить плавный переход между от-

дельными стадиями ЖЦ ПО.

Как правило, все понимают, что обучение является цент-

ральным звеном, обеспечивающим нормальное использование

ТС ПО в организации. Тем не менее, довольно распространен-

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

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

все ограничивается минимальным текущим обучением. Участ-

ники пилотного проекта, получившие начальное обучение, мо-

гут быть высококвалифицированными энтузиастами новой ТС

ПО,

стремящимися использовать ее во что бы то ни стало. С

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

в проекте в дальнейшем, могут потребоваться более интенсив-

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

зовании ТС ПО.

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

персонала (например, администраторы средств, служба поддерж-

396 Глава 5

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

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

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

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

деятельность которых оказывает влияние использование ТС ПО.

В процессе дальнейшего использования ТС ПО в организа-

ции обучение должно стать частью процесса ориентации при

найме новых сотрудников и привлечении сотрудников к проек-

там. Обучение должно стать неотъемлемой составной частью

нормативных материалов, касающихся деятельности организа-

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

Одна общая ошибка, которая делается в процессе перехода,

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

постоянного использования сложных ТС ПО. Рост необходимых

ресурсов вызывается тремя причинами:

• сложностью ТС ПО;

• частотой появления новых версий;

• взаимодействием между ТС ПО и внешней средой.

Сложность ТС ПО приводит к возрастанию потребностей в

тщательном и продуманном обучении. Кроме того, многие ТС ПО

нуждаются в опытных специалистах, умеющих сопровождать про-

ектные базы данных и оперативно реагировать на возникающие

проблемы. Частота обновления версий ТС ПО может привести к

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

каются из виду. Такие обновления обычно пагубно отражаются на

жестких планах и фафиках работы. Взаимодействие между сред-

ствами и внешней по отношению к ним средой также может иног-

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

достигли уровня минимальной несовместимости данных между

отдельными версиями, проблемы обеспечения совместимости с

другими элементами внешней среды остаются в силе.

Оценка результатов перехода

Программа постоянной оценки качества и продуктивности

ПО преследует следующие цели:

• определение степени совершенствования процессов;

• упреждение возможных стратегических просчетов;

• своевременный отказ от использования устаревшей ТС ПО.

Чтобы определить, насколько эффективно новая ТС ПО по-

вышает продуктивность и (или) качество, организация должна

Технологии создания программного обеспечения 397

опираться на некоторые базовые данные. К сожалению, лишь

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

для реализации профаммы текущей количественной оценки и

усовершенствования процессов. Для доказательства эффектив-

ности ТС ПО и ее возможностей улучшать продуктивность необ-

ходимы следующие базовые метрические данные:

• использованное время;

• время, выделенное персонально для конкретных специа-

листов;

• размер, сложность и качество ПО;

• удобство сопровождения.

Метрическая оценка должна начинаться с реальной оценки

текущего состояния среды

до

начала внедрения ТС ПО и поддер-

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

Период времени, в течение которого выполняется количест-

венная оценка воздействия, оказываемого внедрением ТС ПО,

является весьма значимой величиной относительно определения

степени успешности перехода. Некоторые организации, успешно

внедрившие в конечном счете ТС ПО, столкнулись с кратковре-

менными негативными эффектами в начале процесса. Другие,

успешно начав, недооценили долговременные затраты на сопро-

вождение и обучение. Вследствие этого наиболее приемлемый

временной интервал для оценки степени успешности внедрения

должен быть достаточно большим, чтобы преодолеть любые не-

гативные эффекты на начальном этапе, а также смоделировать

будущие долговременные затраты. С другой стороны, данный

интервал должен соответствовать целям организации и ожидае-

мым результатам.

В конечном счете опыт, полученный при внедрении ТС ПО,

может отчасти изменить цели организации и ожидания, возлага-

емые на ТС ПО. Например, организация может сделать вывод,

что средства целесообразно использовать для большего или

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

сопровождения ПО. Такие изменения в ожиданиях зачастую мо-

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

внесению соответствующих корректив

определение степени ус-

пешного внедрения ТС ПО

данной организации.

Результатом данного этапа является внедрение ТС ПО в пов-

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

какого-либо специального планирования. Кроме того, поддерж-

398 Глава 5

ка ТС ПО включается в план текущей поддержки ПО в данной

организации.

Дополнительную информацию по материалу данного подраз-

дела можно найти в американских стандартах IEEE Std

1348-1995.

IEEE Recommended Practice for the Adoption of

Computer-Aided Software Engineering (CASE) Tools и IEEE Std

1209-1992. IEEE Recommended Practice for the Evaluation and

Selection of CASE Tools (IEEE

—

Institute of Electrical and Electronics

Engineers

—

Институт инженеров по электротехнике и электрони-

ке).

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

года (первый стандарт был утвержден в декабре 1996 г, а второй

—

в декабре 1992 г), однако они достаточно тесно взаимосвязаны,

поскольку первый стандарт содержит целый ряд ссылок на второй

(помимо упомянутых стандартов, существует также упомянутый

выше международный стандарт ISO/IEC 14102:1995(E).

Information technology - Guideline for the evaluation and selection of

CASE Tools, основные положения которого во многом совпадают

с положениями IEEE Std 1209-1992). Цель приведенных в стан-

дартах рекомендаций

—

предоставить руководство, позволяющее

повысить вероятность успешного внедрения ТС ПО. Эти реко-

мендации достаточно актуальны и ценны, поскольку отражают

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

разработчиками в течение длительного периода.

5.4.

ПРИМЕРЫ ТС ПО

Многие организации-разработчики программных продуктов

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

ТС ПО, которые материализовались в виде практических реко-

мендаций, документации, обучающих программ и книг Пос-

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

эти технологии стали приобретать электронную форму, превра-

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

поставляются вместе с CASE-средствами и включают библиоте-

ки процессов, шаблонов, методов, моделей и других компонен-

тов,

предназначенных для построения ПО того класса систем, на

который ориентирована технология. Электронные технологии

включают также средства, которые должны обеспечивать их

адаптацию для конкретных пользователей и развитие по резуль-

татам выполнения конкретных проектов.

Технологии создания программного обеспечения 399

На сегодняшний день практически все ведущие компании

—

разработчики технологий и программных продуктов (IBM,

Microsoft, Oracle, Borland, Computer Associates, Sybase

и др.)

распо-

лагают развитыми технологиями создания ПО, которые создава-

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

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

ными компаниями. Выбор в качестве примера четырех перечис-

ленных ниже технологий объясняется

их

ведущими позициями на

мировом рынке ТС ПО и присутствием на российском рынке.

5.4.1.

ТЕХНОЛОГИЯ RUP (RATIONAL UNIFIED PROCESS)

Одна из наиболее совершенных технологий, претендующих

на роль мирового корпоративного стандарта

—

Rational Unified

Process. RUP представляет собой программный продукт, разрабо-

танный компанией Rational Software (www.rational.com), которая

в настоящее время входит в состав IBM. RUP является результа-

том объединения подходов Rational Approach и Objectory Process,

происшедшего после слияния в 1995 году компаний Rational

Software и Objectory

АВ

(созданной Иваром Якобсоном).

RUP

значительной степени соответствует стандартам и нор-

мативным документам, связанным с процессами ЖЦ ПО

оцен-

кой технологической зрелости организаций-разработчиков (ISO

12207,

ISO 9000, СММ и др.). Ее основными принципами явля-

ются:

Итерационный и инкрементный (наращиваемый) подход к

созданию ПО.

Планирование и управление проектом на основе функцио-

нальных требований к системе

—

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

Построение системы на базе архитектуры ПО.

Первый принцип является определяющим. В соответствии с

ним разработка системы выполняется в виде нескольких крат-

косрочных мини-проектов фиксированной длительности (от

до

6 недель), называемых итерациями. Каждая итерация включает

свои собственные этапы анализа требований, проектирования,

реализации, тестирования, интефации и завершается созданием

работающей системы.

Итерационный цикл основывается на постоянном расшире-

нии

дополнении системы

процессе нескольких итераций

пе-

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

400

Глава

лей

существующему ядру системы. Система постоянно разрас-

тается шаг за шагом, поэтому такой подход называют

итерацион-

ным

инкрементным.

При таком подходе исключено

слишком быстрое написание

кода (без детальной проработки)

чрезмерно длительный этап

детального проектирования

построения моделей без обратной

связи.

На рис. 5.6 показано общее представление RUP в двух изме-

рениях:

• горизонтальное измерение представляет время, отражает

динамические аспекты процессов

оперирует

такими

поня-

тиями, как стадии, итерации и контрольные точки;

• вертикальное измерение отражает статические аспекты

процессов

оперирует такими понятиями,

как

виды дея-

тельности (технологические операции), рабочие продукты,

исполнители

дисциплины (технологические процессы).

Основные

процессы

Построение

бизнес-моделей

Определение

требований

Анализ

проектирование

Реализация

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

Развертывание

Поддерживающие

процессы

Управление

конфигурацией

Управление

проектом

Создание

инфра-

структуры

Стг1дии

ч'

ч\^ ' \^V

'Л^^' S4'

' Ч'чЧ

Ч\'ч v\\ s^ \-^^

Начальная :Pii:tba6oTKa

ч^

Итерации

•^>'v

Рис. 5.6. Общее представление RUP