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

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

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

• реструктуризация исходного кода (возможность модифика-

ции формата и (или) структуры существующего исходного

кода).

1.4. Документирование:

• редактирование текстов и графики;

• редактирование с помощью форм;

• возможности издательских систем;

• поддержка функций и форматов гипертекста;

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

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

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

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

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

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

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

элементов данных

для

модификации, блокировки доступа к

ним на время модификации

помещения обратно

репози-

торий);

• отслеживание модификаций (фиксация и ведение журнала

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

ботки или сопровождения);

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

версиях

системы

и всех ее

коллективно используемых компонентах);

• учет состояния объектов управления конфигурацией (воз-

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

сиях, содержимом и состоянии различных объектов конфи-

гурационного управления);

• генерация версий и модификаций (поддержка пользова-

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

мых для

формирования версий

модификаций,

автомати-

ческое выполнение этих действий);

• архивирование (возможность автоматического архивирова-

ния элементов данных

для

последующего использования).

1.6. Обеспечение качества:

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

• управление рисками.

1.7. Верификация:

• анализ трассировки спецификаций;

• анализ спецификаций (синтаксический и семантический

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

—

контроль синтаксиса

372 Глава 5

диаграмм и типов их элементов, контроль декомпозиции

функций, проверка спецификаций на полноту

непротиво-

речивость);

• анализ исходного кода (определение размера кода, вычисле-

ние показателей сложности, генерация перекрестных ссы-

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

1.8. Аттестация:

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

тестирования, требуемых результатов и т.д.);

• фиксация и повторение действий оператора (возможность

фиксировать данные, вводимые оператором с помощью

клавиатуры, мыши и т.д., редактировать их и воспроизво-

дить

тестовых примерах);

• автоматический запуск тестовых примеров;

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

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

различий в системе и (или) среде);

• статистический анализ результатов тестирования;

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

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

Проверяются, в частности, исполняемые и вызываемые

(или нет) операторы, процедуры и переменные);

• анализ производительности (возможность анализа произво-

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

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

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

ращений к определенным элементам данных и (или) сег-

ментам кода, временные характеристики и т.д.);

• анализ исключительных ситуаций;

• динамическое моделирование среды;

• интефационное тестирование.

Функциональные характеристики применения (инструмен-

тальных средств).

2.1.

Среда функционирования:

• требуемые технические средства;

• требуемое ПО.

2.2.

Совместимость:

• совместимость с различными средами функционирования;

• совместимость с другими средствами по данным, представ-

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

дру-

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

гими средствами, включая непосредственный обмен данны-

ми (примерами таких средств являются текстовые процес-

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

другие CASE-средства) и возможность преобразования ре-

позитория или

его

части

стандартный формат для обработ-

ки другими средствами).

2.3.

Аспекты применения:

• соответствие технологическим стандартам (касающимся

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

ческого.

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

ности, стандартов обмена информацией);

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

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

системы

др.);

• размер поддерживаемых приложений (определяет ограниче-

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

вложенности, размер базы данных, количество элементов

данных, количество объектов управления конфигурацией);

• поддерживаемые методы (набор методов

методик, поддер-

живаемых CASE-средством. Примерами являются струк-

турный или объектно-ориентированный анализ и проекти-

рование);

• поддерживаемые языки (все языки, используемые CASE-

средством: языки профаммирования, языки баз данных,

фафические языки, языки спецификации проектных тре-

бований и интерфейсы операционных систем);

• локализация.

Характеристики качества.

3.1.

Надежность:

• контроль и обеспечение целостности проектных данных;

• автоматическое резервирование;

• безопасность (защита от несанкционированного доступа);

• обработка ошибок (обнаружение ошибок в работе системы,

извещение пользователя, корректное завершение работы

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

• анализ отказов в критических приложениях.

3.2. Удобство использования:

• удобство пользовательского интерфейса (удобство располо-

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

рана, способов ввода данных

др.);

374 Глава 5

• простота освоения (трудовые и временные затраты на осво-

ение средств);

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

различным алфавитам, режимам текстового и графического

представления (слева направо, сверху вниз), различным

форматам

даты,

способам ввода-вывода (экранным формам

и форматам), изменениям в методологии (изменениям гра-

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

ленных объектов)

др.;

• качество документации

учебных материалов (полнота, по-

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

учебных материалов, учебных пособий, курсов);

• качество диагностики (понятность и полезность диагности-

ческих сообщений для пользователя);

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

3.3.

Эффективность:

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

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

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

• эффективность рабочей нафузки: эффективность выполне-

ния CASE-средством своих функций в зависимости от ин-

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

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

нения определенных функций);

• производительность: время, затрачиваемое CASE-сред-

ством для выполнения конкретных задач (например, время

ответа на запрос, время анализа 100 000 строк кода).

3.4. Сопровождаемость:

• уровень поддержки со стороны поставщика - скорость раз-

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

полнительных возможностей;

• трассируемость обновлений

—

простота освоения отличий

новых версий от существующих;

• совместимость обновлений

—

совместимость новых версий

с существующими, включая, например, совместимость по

входным или выходным данным;

• адаптируемость к изменениям в методах;

• сопровождаемость конечного продукта.

3.5.

Переносимость:

• совместимость с версиями операционной системы;

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

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

средств;

• соответствие стандартам переносимости, включающим до-

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

фейс,

оконный интерфейс, языки программирования, язы-

ки запросов и др.

Общие характеристики.

4.1.

Приобретение:

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

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

Следует учитывать цену для всех необходимых конфигура-

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

ную лицензию, лицензию для предприятия, сетевую ли-

цензию;

• лицензионная политика

—

доступные возможности лицен-

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

ции),

любые офаничения и (или) штрафные санкции за

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

зователем ТС ПО продуктов, в состав которых входят неко-

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

ботке продуктов);

• экспортные ограничения.

4.2.

Реализация:

• оценочный эффект от внедрения ТС ПО

—

уровень продук-

тивности, качества и т.д. Такая оценка может потребовать

экономического анализа;

• инфраструктура, требуемая для внедрения ТС ПО.

4.3.

Поддержка:

• профиль поставщика

—

общие показатели возможностей

поставщика. Профиль поставщика может включать масш-

таб его организации, стаж в бизнесе, финансовое положе-

ние,

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

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

планируемую стратегию развития;

• профиль продукта

—

общая информация о продукте, вклю-

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

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

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

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

др.;

376 Глава 5

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

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

либо

другом месте).

4.4.

Сертификация:

• сертификация поставщика

—

сертификаты, полученные от

специализированных организаций в области создания ПО

(например, SEI и ISO), удостоверяющие, что квалификация

поставщика в области создания и сопровождения ПО удов-

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

не определенным требованиям. Сертификация может быть

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

ты поставщика;

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

• поддержка поставщика

—

доступность, реактивность

каче-

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

лей

ТС

ПО.

Такие услуги могут включать телефонную «горя-

чую

линию»,

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

самой организации.

На основе данного набора параметров анализируются и клас-

сифицируются существующие ТС ПО. Общий набор критериев,

применяемых для оценки ТС ПО, приведен ниже.

Критерии, применяемые

для

оценки

ТС

ПО

Критерий Определение

Минимум времени Количество человеко-часов, затрачиваемых на

обучения обучение ТС ПО

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

обучение ные расходы, связанные с обучением

Минимум трудоем- Количество человеко-месяцев, затрачиваемых на

кости создания ПО создание ПО с использованием ТС ПО

Минимум трудоем- Количество человеко-месяцев, затрачиваемых на

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

ПО

Минимум времени Временной интервал от начала до завершения

создания ПО проекта (сдачи ПО в эксплуатацию) при исполь-

зовании данной ТС ПО

Максимум продук- Объем работы (измеряемый в количестве строк

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

на единицу трудоемкости (человеко-месяц) при

использовании данной ТС ПО

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

Продолжение

Критерий

Максимум качества

создаваемого ПО

Возврат инвестиций

Минимум затрат на

создание ПО

Минимум затрат на

сопровождение ПО

Минимум времени

внедрения ТС ПО

Минимум затрат на

внедрение ТС ПО

Минимальный срок

окупаемости затрат на

внедрение ТС ПО

Определение

Количество дефектов в рабочих продуктах при

использовании данной ТС ПО

Доход от использования ПО

—

Затраты на соз-

дание и сопровождение ПО / Затраты на созда-

ние и сопровождение ПО

Трудоемкость создания и сопровождения ПО

без использования ТС ПО

—

Трудоемкость созда-

ния и сопровождения ПО с использованием ТС

ПО / Трудоемкость создания и сопровождения

ПО с использованием ТС ПО

Стоимость выполнения проекта (до сдачи ПО в

эксплуатацию) с использованием ТС ПО

Отношение стоимости сопровождения ПО при

использовании данной ТС ПО к совокупным зат-

ратам на информационные ТС ПО в организации

Временной интервал от начала внедрения ТС ПО

до выхода на безубыточный уровень (начало

возврата инвестиций в ТС ПО)

Суммарная стоимость приобретения, обучения и

сопровождения ТС ПО

Временной интервал от начала внедрения ТС ПО

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

В результате выполненной оценки может оказаться, что ни

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

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

этом слу-

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

на их базе единую технологическую среду.

ВЫПОЛНЕНИЕ ПИЛОТНОГО ПРОЕКТА

Перед полномасштабным внедрением выбранной ТС ПО в

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

ляется экспериментальная проверка правильности решений,

принятых на предыдущих этапах, и подготовка к внедрению.

Пилотный проект представляет собой первоначальное реаль-

ное использование ТС ПО в предназначенной для этого среде и

378 Глава 5

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

ТС ПО по отношению к тому, который был достигнут во время

оценки. Пилотный проект должен обладать многими характерис-

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

средство. Он преследует следующие цели:

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

• установить, действительно ли ТС ПО годится для использо-

вания

данной организации, и если да, то определить наи-

более подходящую область ее применения;

• собрать информацию, необходимую для разработки плана

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

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

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

необходимую для оценки ТС ПО и его поддержки со стороны

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

Важной функцией пилотного проекта является принятие ре-

шения относительно приобретения или отказа от использования

ТС

ПО.

Провал пилотного проекта позволяет избежать более зна-

чительных

дорогостоящих неудач

дальнейшем, поскольку пи-

лотный проект обычно требует приобретения относительно не-

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

листов.

Первоначальное использование новой ТС ПО в пилотном

проекте должно тщательно планироваться и контролироваться.

Пилотный проект включает следующие шаги (рис. 5.5).

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

пилотного

проекта

Пилотный проект должен обладать следующими характерис-

тиками.

Типичность

предметной

области.

Чтобы облегчить окончатель-

ное определение области применения ТС ПО, предметная об-

ласть пилотного проекта должна быть типичной для обычной де-

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

делить любую дополнительную технологию, обучение или под-

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

к широкомасштабному использованию ТС ПО.

рамках этих ог-

раничений пилотный проект должен иметь небольшой, но зна-

чимый размер.

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

екте,

должны показать масштабируемость ТС ПО. Цель

—

полу-

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

379

Определение

характеристик

пилотного проекта

Планирование

пилотного проекта

Вьшолнение

пилотного проекта

Оценка пилотного

проекта

Выполнение

дополнительного

пилотного

проекта

Отказ

от внедрения

Внедрение

средства

Рис.

5.5. Шаги пилотного проекта

ЧИТЬ четкое представление о масштабах проектов, для которых

данная ТС ПО применима.

Представительность. Пилотный проект не должен быть нео-

бычным или уникальным для организации. ТС ПО должна ис-

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

ласти, хорошо понимаемой всей организацией.

Критичность. Пилотный проект должен иметь существенную

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

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

380 Глава 5

лом. Необходимо осознавать, что первоначальное внедрение но-

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

лотного проекта приходится решать следующую дилемму: успех

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

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

ную критику.

Авторитетность. Группа специалистов, участвующих в проек-

те,

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

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

ганизации.

Готовность проектной

группы.

Проектная фуппа должна обла-

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

приемлемым уровнем опыта и знаний в данной ТС ПО и пред-

метной области.

С другой

стороны, группа должна отражать

ми-

ниатюре характеристики организации в целом.

В большинстве случаев существует баланс между желанием

реализовать идеальный пилотный проект

реальными офаниче-

ниями организации. Организация должна выбрать пилотный

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

ТС ПО

нем совпадал

дальнейшими планами и, во-вторых, пе-

речисленные выше характеристики были сбалансированы с ре-

альными условиями организации.

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

ность пилотного проекта (и

целом процесса внедрения). Слиш-

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

нему со стороны руководства.

Планирование пилотного проекта

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

вписываться в обычный процесс планирования проектов в орга-

низации. План должен содержать следующую информацию:

• цели, задачи и критерии оценки;

• персонал;

• процедуры и соглашения;

• обучение;

• график и ресурсы.

Цели, задачи

критерии оценки

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

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