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

реклама
Anexa nr. __________
la Ordinul nr. __________
din ____ __________ 2009
Технический Регламент
Определение стоимости разработки и внедрения автоматизированных
информационных систем. Нормативы и оценкa трудовых затрат
1
1 Область применения
Настоящий регламент устанавливает общие принципы для
определения стоимости разработки и внедрения автоматизированных
информационных систем (далее – информационных систем (ИС)). В
настоящем регламенте определены процессы, работы и задачи, которые
используются при определении стоимости разработки и внедрения ИС, но не
определены детали реализации или выполнения работ и задач.
Настоящий регламент устанавливает методологию формирования
стоимости ИС, основные компоненты стоимости ИС и метод определения
стоимости компонентов ИС, в том числе разработки и внедрения ИС.
Настоящий регламент применяется для формирования или оценки
стоимости ИС. Регламент предназначен для: заказчиков ИС, программных
продуктов и услуг; поставщиков, разработчиков и администраторов ИС;
менеджеров проектов; менеджеров, отвечающих за качество, и пользователей
программных продуктов.
Настоящим регламентом установлен набор процессов, работ и задач,
предназначенных для адаптации к условиям конкретных проектов в области
внедрения ИС.
2 Нормативно-правовая база
Настоящий
регламент
разработан
на
основе
следующих
законодательных актов Республики Молдова:
1) Закон Республики Молдова «О доступе к информации» № 982XIV от 11.05.2000;
2) Закон
Республики
Молдова
«Об
информатизации
и
государственных информационных ресурсах» № 467–XV от 21.11.2003;
3) Закон Республики Молдова «Об электронном документе и
цифровой подписи» № 264-XV от 15.07.2004;
4) Закон Республики Молдова «Об электронной торговле» № 284XV от 22.07.2004;
5) Закон Республики Молдова «О техническом регулировании»
№ 420 от 22.12.2006;
6) Закон Республики Молдова «О защите персональных данных»
№ 17-XVI от 15.02.2007;
7) Закон Республики Молдова «О регистрах» № 71-XVI от
22.03.2007;
8) Закон Республики Молдова «О государственных закупках» № 96
от 13.04.2007.
2
3 Терминология
Компонент программного продукта - идентифицируемая и
содержательная часть программного продукта, например, программная
процедура, раздел или параграф документа, полный документ.
Структурное разбиение работ - иерархическая структуризация работ
проекта, ориентированная на основные результаты проекта, определяющие
его предметную область. Каждый нижестоящий уровень структуры
представляет собой детализацию элемента высшего уровня проекта.
Элементом проекта может быть как продукт, услуга, так и пакет работ или
работа.
Аппаратное обеспечение - оборудование, используемое для ввода,
обработки и вывода данных в информационных системах.
Модель жизненного цикла - структура, состоящая из процессов,
работ и задач, вовлеченных в разработку, эксплуатацию и сопровождение
программного продукта, охватывающая жизнь программной системы от
установления требований к ней до прекращения ее использования.
Мониторинг - процесс сбора, анализа данных, представления отчетов
по выполнению работ.
Техническое задание - документ, используемый заказчиком в
качестве средства для описания и определения задач, выполняемых при
реализации договора.
Коммуникационная технология - аппаратные устройства и
программное обеспечение, служащие для связи между отдельными
элементами информационных систем и «физической» передачи данных.
4 Состав информационной системы
ИС
является
организационно–упорядоченная
совокупность
информационных ресурсов, информационных технологий, аппаратных и
коммуникационных средств, позволяющая осуществлять сбор, хранение,
поиск, обработку и пользование информацией.
ИС состоит из следующих основных компонентов:
1) программное обеспечение (ПО) – совокупность всей информации,
данных и программ, которые обрабатываются компьютерными системами;
2) информационное обеспечение – обеспечение фактическими
данными управленческих структур, использование информационных данных
для автоматизированных систем управления, использование информации для
обеспечения деятельности различных потребителей;
3) технические средства – комплекс электронных, электрических и
механических устройств, входящих в состав системы или сети;
4) обслуживающий персонал.
3
4.1 Программное обеспечение
ПО представляет собой совокупность программ систем обработки
информации и программных документов, необходимых для эксплуатации
этих программ, и подразделяется на:
1) системное ПО – набор программ, которые управляют
компонентами ИС, такими как процессор, коммуникационные и
периферийные устройства, а также программы, предназначенные для
обеспечения функционирования и работоспособности всей системы:
- операционные системы общего назначения, реального времени,
сетевые, встраиваемые;
- загрузчик операционной системы;
- драйверы устройств;
- программы, способные выполнять преобразование потока
данных или сигнала;
- утилиты;
2) программные средства защиты - программы для идентификации
пользователей, контроля доступа, шифрования информации, удаления
остаточной (рабочей) информации типа временных файлов, тестового
контроля системы защиты. К программным средствам защиты относятся:
- криптошлюзы;
- средства аутентификации;
- средства мониторинга и аудита;
- сканеры защищенности;
- средства разграничения доступа;
- системы криптографической защиты, шифрования и электронно–
цифровой подписи;
- антивирусные и антиспамовые программы;
- межсетевые экраны;
3) инструментальное ПО – программы, предназначенные для
использования в ходе проектирования, разработки и сопровождения ИС.
Включает в себя средства разработки ПО, системы управления базами
данных, компиляторы, трансляторы, генераторы;
4) Прикладное ПО включает:
- офисные приложения: текстовые редакторы, текстовые
процессоры, табличные процессоры, редакторы презентаций;
- корпоративные ИС: бухгалтерские программы, системы MRP
(Material Requirement Planning), системы MRP II, системы ERP (Enterprise
Resource Planning System), системы CRM (Customer relationship management),
системы SCM (Supply Chain Management), системы управления проектами,
системы автоматизации документооборота, системы управления архивами
документов, корпоративный портал;
системы
проектирования
и
производства:
системы
автоматизированного проектирования (CAD–системы Computer-Aided
4
Design), CAE–системы (Computer-aided engineering), CAM–системы
(Computer-aided manufacturing), PDM–системы (Product Data Management),
PLM–системы (Product Lifecycle Management), автоматизированные системы
управления технологическим процессом;
- системы логистической поддержки изделий: системы анализа
логистической поддержки и организационно–технические системы;
- системы обработки и хранения медицинской информации;
- научное ПО;
- геоинформационные системы;
- системы поддержки принятия решений;
- клиенты для доступа к интернет–сервисам: электронная почта,
веб–ресурсы, мгновенная передача сообщений, чат–каналы, IP–телефония,
P2P обмен файлами, потоковое вещание, клиент–банк;
- мультимедиа.
4.2 Информационное обеспечение
Инфраструктура ИС включает в себя организационные и
технологические подсистемы, а также комплекс обеспечивающих ресурсов, с
помощью которых решаются как внутренние, так и внешние управленческие
и организационные задачи, в соответствии с функциями, определенными
законодательством.
ИС обеспечивает связность подсистем в рамках единой логики,
стандартов, «интерфейсов» и совместного использования информационных
ресурсов.
К информационным ресурсам относятся:
1) базы данных и банк данных;
2) системная документация;
3) руководства пользователя;
4) учебные материалы;
5) операционные процедуры и процедуры поддержки;
6) планы обеспечения бесперебойной работы организации;
7) процедуры перехода на аварийный режим.
Государственные информационные ресурсы в зависимости от
использования подразделяются на:
1) базовые государственные информационные ресурсы;
2) ведомственные государственные информационные ресурсы;
3) территориальные государственные информационные ресурсы.
Базовыми государственными информационными ресурсами являются
информационные ресурсы, предназначенные для общего использования
всеми органами публичной власти, юридическими и физическими лицами в
пределах предоставленных им полномочий.
Ведомственные
информационные
ресурсы
формируются
и
используются отраслевыми органами публичного управления, являющимися
5
владельцами этих ресурсов. Ведомственные информационные ресурсы
содержат информацию, необходимую для выполнения указанными органами
своих функций, за исключением данных, предназначенных для включения в
базовые информационные ресурсы.
Территориальные информационные ресурсы формируются и
используются органами местного публичного управления, являющимися
владельцами этих ресурсов. Территориальные информационные ресурсы
содержат данные обо всех видах природных и искусственных
географических объектов, включая ресурсный потенциал на управляемых
территориях.
4.3 Технические средства
Технические средства используются для установки, поддержки и
разъединения связи, а также для обеспечения преобразования сигналов
между oконечным оборудованием данных и каналом общего пользования, и
включают:
1) компьютеры и логические устройства;
2) внешние устройства и диагностическую аппаратуру;
3) коммуникационное обеспечение;
4) энергетическое оборудование;
5) батареи;
6) аккумуляторы.
Коммуникационное обеспечение предназначено для управления
процессами передачи информации между другими системами и включает в
себя:
1) коммутаторы;
2) концентраторы;
3) маршрутизаторы;
4) межсетевые экраны;
5) адаптеры;
6) кабельные системы;
7) повторители, мосты.
Коммуникационное оборудование представляет собой сложный
специализированный мультипроцессор, который нужно конфигурировать,
оптимизировать и администрировать.
5 Методика определения стоимости информационных систем
В основу методики определения стоимости ИС легла конструктивная
модель стоимости (Constructive Cost Model - COCOMO), которая разработана
Барри Боэмом (Barry Boehm) и применяется для определения стоимости
коммерческих и государственных ИС. COCOMO II адаптирована к
современным методологиям разработки ПО и пригодна для всех моделей
6
жизненного цикла ПО.
Представленная модель является одной из самых популярных,
открытых и хорошо документированных математических моделей оценки
стоимости и трудоемкости разработки ПО. Для обработки статистических
данных используется Байесовский анализ, который дает лучшие результаты
для
программных
проектов,
характеризующихся
неполнотой
и
неоднозначностью.
Байесовский анализ – подход, который учитывает распределение
вероятностей, основанное либо на субъективном мнении, либо на таких
объективных данных, как результаты предыдущего исследования; может
использоваться для единичных исследований и для мета–анализа.
Байесовский анализ использует теорему Байеса и позволяет провести
переоценку распределения с учетом результатов исследования, давая
представленное распределение, на котором основаны статистические выводы
(точечные оценки, доверительные интервалы).
Модель базируется на реально измеряемых показателях. Для оценки
трудоемкости и стоимости проекта эти исходные данные должны быть
детализированы. При расчете показателей модель учитывает уровень
зрелости процесса разработки.
В настоящем документе представлен подход к формированию
стоимости ИС на каждом этапе жизненного цикла. Подход представлен в
виде поэтапного выполнения работ и соблюдения перечня требований,
представленных далее.
6 Этапы определения стоимости информационных систем
Перед началом этапов определения стоимости разработки и внедрения
ИС осуществляется этап предпроектных работ. Этап предпроектных работ
начинается с первоначального осознания потребности создания новой или
модификации существующей ИС.
Данный этап является периодом начального изучения, сбора фактов и
анализа, изучения действующего законодательства и существующей
организационной структуры, обзора аналогичных существующих ИС.
Выходными элементами этапа предпроектных работ являются концепция
системы и бизнес-предложение, которые позволяют принять решение продолжать или прекратить реализацию ИС.
При необходимости внесения дополнительных задач, необходимо
оценить целесообразность их выполнения.
Для определения стоимости разработки и внедрения ИС необходимо
последовательно выполнять этапы:
1) анализ и спецификации
требований к ИС - анализ
функциональных и нефункциональных требований, требований к
внешним интерфейсам ИС, к аппаратному обеспечению, по
обеспечению
информационной
безопасности,
определение
7
архитектуры аппаратного обеспечения, проектирование ПО,
идентификация объектов и их иерархия;
2) определение структурных единиц и стоимости поставок
программного и аппаратного обеспечения - определение поставок и
аренды аппаратного и программного обеспечения;
3) оценка размера программной части ИС - определение размера
программной части ИС и составление документации по оценке размера
программной части;
4) оценка объема работ - идентификация рисков, Структурного
разбиения работ, расчет и корректировка объема работ и трудозатрат
по разработке ПО;
5) трудозатраты на кодирование и тестирование - расчет объема
работ и трудозатрат на кодирование и тестирование, расчет
длительности кодирования и тестирования, составление плана работ по
разработке ИС и сценариев тестирования;
6) определение характеристик качества ИС - определение
количественных, качественных, внутренних и внешних характеристик
качества и оценка качества ИС;
7) вычисление стоимости ИС - оценка общей стоимости проекта;
8) определение влияния рисков - оценка влияния рисков, ее
регулирование, а также регулирование затрат, основанных на оценке
рисков;
9) подтверждение и корректировка оценки стоимости рисков оценка
рисков
независимой
экспертной
группой,
анализ
статистических данных, сравнение оценок рисков и их корректировка;
10) внедрение ИС - разработка плана и задач внедрения, реализация
полномасштабного внедрения ИС.
6.1 Анализ и спецификации требований к информационной
системе
Цель анализа требований к ИС заключается в разработке и
подтверждении
функциональных,
нефункциональных
требований,
требований к внешним интерфейсам и безопасности системы,
идентификации технических и программных ограничений, которые позволят
наиболее точно произвести оценку стоимости ИС.
Процесс сбора и анализа требований состоит из:
1) анализа и детального моделирования программных требований;
2) определения архитектуры ИС;
3) определения ограничений реализации ИС;
4) анализа архитектуры аппаратного обеспечения, коммуникаций.
8
6.1.1 Анализ и детальное моделирование программных
требований
6.1.1.1 Функциональные требования
Функциональные требования описывают действия, для выполнения
которых приложение предназначено, и могут выражаться в виде услуг,
заданий или функций, которые надлежит выполнять приложению.
Модель требований определяет целенаправленный комплекс
взаимодействий между внешними участниками и рассматриваемой системой.
Внешние участники - это стороны вне системы, которые взаимодействуют с
системой. Внешним участником может быть класс пользователей, роли,
исполняемые пользователями или другие системы.
Главной целью моделирования функциональных требований является
установка границ работы приложения и полного комплекса функциональных
возможностей, предоставляемых конечному пользователю.
Функциональные требования, как минимум должны включать:
1) требования,
согласованные
всеми
заинтересованными
представителями бизнес-подразделений:
- характеристику ИС;
- основные цели создания и назначение;
- планируемое развитие;
- требования к ИС в целом;
- требования к структуре данных ИС;
- требования к функциональности ИС;
- требования к интерфейсу пользователя и отчетам;
- требования к средствам администрирования;
- требования к средствам разработки;
- требования к взаимодействию с другими программными
продуктами;
- требования к документированию;
- требования к программному и аппаратному обеспечению.
- описание спецификации ИС, в которых применяется данное
приложение;
- документирование форматов входных и выходных данных;
- методы реализации контролей подготовки, ввода данных и
обработки ошибок ввода данных, позволяющих реализовать обнаружение,
индикацию и корректировку ошибок;
- методы реализации контролей проверки данных транзакций,
введенных для обработки (вручную или системой) на точность, полноту и
достоверность;
- методы обнаружения и исключения ошибочных транзакций по
ходу их обработки;
- средства, поддерживающие неотказуемость транзакций;
9
2) формализованные
требования,
согласованные
всеми
заинтересованными представителями бизнес-подразделений :
описание
детальных
спецификаций
ПО
в
части
функциональности системы;
- требования к разработке и документированию интерфейсов с
внутренними системами;
- требования к разработке и документированию алгоритмов
обработки данных;
- требования обеспечения безопасности, целостности и
доступности (в том числе при чрезвычайных ситуациях).
6.1.1.2 Требования к внешним интерфейсам
Требования к внешним интерфейсам ИС, в зависимости от
необходимости, должны включать:
1) приоритет, который ИС должна присвоить интерфейсу;
2) требования к типу интерфейса (функционирование в режиме
реального времени, передача данных, хранение и извлечение данных),
которые необходимо обеспечить;
3) требуемые характеристики индивидуальных элементов данных,
которые должна предоставлять ИС для обеспечения хранения, передачи,
доступа, приема данных:
- имя/идентификаторы;
- тип данных (цифробуквенный, целый);
- размер и формат (длина и пунктуация ряда символов);
- единицы измерения (объема, стоимости, времени);
- интервал или перечисление возможных значений (например, 0–
99);
- аккуратность (насколько верно) и точность (число значащих
разрядов);
- приоритет, хронометраж, частота, объем, порядок и другие
ограничения для актуализации элемента данных и применяемые правила
бизнеса;
- ограничения по безопасности;
- источники (объекты, которые создают/посылают данные) и
получатели (объекты, которые используют/принимают данные);
4) требуемые характеристики совокупностей элементов данных
(записи, сообщения, файлы, матрицы, отчеты), которые ИС должна
предоставлять, хранить, передавать, принимать и обеспечивать к ним доступ:
- имя/идентификаторы;
- элементы данных, которые входят в их структуру (номер,
порядок, группировка);
- среды (например, диски) и структуры данных/элементов в среде;
- аудиовизуальные характеристики сообщений и других выходов;
10
- отношения между группами, характеристики сортировки/доступа;
- приоритет, хронометраж, частота, объем, порядок и другие
ограничения;
- время реагирования на запрос;
- ограничения безопасности;
- источники и получатели;
5) требуемые характеристики для методов коммуникаций, которые
ИС должна использовать для интерфейса:
- уникальные проектные идентификаторы;
- коммуникации, связи/полосы пропускания/частоты/среды и их
характеристики;
- формат сообщений;
- контроль потоков;
- скорости передачи, периодичность, интервал между передачами;
- маршрутизация, адресация и пространства имен;
- услуги передачи, включая приоритеты и оценки;
- соображения безопасности/конфиденциальности, такие как
шифрование, аутентификация пользователей, проведение аудита;
6) требования к характеристикам, которыми должны обладать
протоколы ИС для взаимодействия:
- уникальный идентификатор проекта;
- приоритет/уровень протокола;
- разбиение на пакеты, включая фрагментацию, повторную сборку,
маршрутизацию и адресацию;
- проверки легальности, контроль над ошибками и процедуры
восстановления;
- синхронизация, включая установку соединения, поддержание,
прекращение;
- состояние, идентификация и любые возможности отчетов;
7) другие требуемые характеристики, физическая совместимость
взаимодействующих объектов информационных ресурсов (размеры,
интервалы, загрузки).
5.1.1.3 Нефункциональные требования
Нефункциональные требования должны быть использованы для
определения требований и ограничений ИС. Требования должны быть
использованы в качестве основы для ранней системы измерения и оценки
жизнеспособности разрабатываемой ИС.
Нефункциональные требования включают:
1) ограничения среды и реализации;
2) производительность (скорость, пропускная способность, время
отклика, используемая память);
3) зависимость от платформы;
11
4) расширяемость;
5) надежность (пригодность, точность, средняя наработка на отказ,
число ошибок на тысячу строк программы, число ошибок на класс).
При
определении
нефункциональных
требований
должны
применяться следующие категории атрибутов качества:
1) управляемость;
2) рентабельность;
3) эффективность;
4) возможность взаимодействия с другими приложениями и
службами;
5) доступность и надежность;
6) мощность и производительность;
7) возможность внесения исправлений;
8) возможность инсталлирования;
9) контролируемость;
10) поддерживаемость;
11) удобство использования;
12) безопасность.
Нефункциональные требования должны использоваться для
предписания качественных атрибутов разрабатываемого приложения.
Данные качественные атрибуты должны применяться для составления
планов тестирования приложений в соответствии с нефункциональными
требованиями (см. 6.5).
6.1.1.4 Основные требования к информационным системам
органов публичной власти
ИС органов публичной власти должны обеспечивать:
1) гарантированный и безопасный доступ к общедоступным
государственным информационным ресурсам;
2) возможность
поиска,
сбора,
обработки
и
хранения
государственных информационных ресурсов;
3) возможность предоставления органам публичной власти доступа
к локальным и глобальным информационным ресурсам;
4) надежность функционирования и устойчивость к программно–
аппаратным сбоям, включая случаи некорректной работы пользователей;
5) оперативный
и
безопасный
обмен
данными
между
пользователями;
6) возможность дальнейшего расширения путем модернизации
аппаратных и программных средств, наращивания системы новыми
компонентами;
7) другие функции, связанные с основным направлением
деятельности органов публичной власти.
Требования к ИС органов публичной власти должны быть
12
документированы и необходимо проверять соответствие работ по
следующим категориям систем:
1) транзакционные и учетные системы, обеспечивающие поддержку
выполнения органами публичной власти своих основных задач и функций;
2) системы межведомственного информационного взаимодействия
между ИС органов публичной власти;
3) системы управления ресурсами, обеспечивающими поддержку
деловых процессов и административных регламентов в деятельности органов
публичной власти;
4) информационно–аналитические системы, обеспечивающие сбор,
обработку, хранение и анализ данных о результатах выполнения органами
публичной власти своих основных задач и функций;
5) системы электронного документооборота;
6) системы управления электронными архивами документов;
7) системы управления эксплуатацией (включая системы
управления инфраструктурными компонентами);
8) системы взаимодействия с физическими и юридическими лицами,
обеспечивающими предоставление органами публичной власти через
Интернет или другие каналы связи справочной информации и услуг, включая
порталы и центры телефонного обслуживания;
9) системы обеспечения информационной безопасности;
10) офисные системы, используемые сотрудниками государственных
органов в своей повседневной деятельности для подготовки документов и
обмена информацией.
ИС органов публичной власти должны создаваться на основании
следующих принципов:
1) доступность, достоверность, полнота и своевременность
предоставления информации;
2) конфиденциальность - обеспечение разграничения доступа к
информационным ресурсам ИС в пределах предоставленных пользователям
полномочий;
3) открытость - возможность интегрирования с другими ИС и
национальной ИС;
4) масштабируемость - возможность дальнейшего расширения
функциональных возможностей ИС путем добавления в их состав
программно–аппаратных средств, модернизации;
5) защищенность - обеспечение сохранности и целостности
информационных ресурсов, входящих в состав ИС;
6) надежность функционирования и устойчивость ИС.
6.1.1.5
Требования
по
обеспечению
информационной
безопасности информационных систем органов публичной власти
Информационная безопасность в ИС органов публичной власти
13
должна обеспечиваться системой, включающей в себя комплекс
организационно–технических мер и программно–аппаратных средств защиты
информации.
Программно–аппаратные средства защиты информации, применяемые
в ИС органов публичной власти, должны быть лицензионными,
сертифицированными и обеспечивать:
1) идентификацию защищаемых информационных ресурсов;
2) аутентификацию пользователей ИС;
3) конфиденциальность информации, циркулирующей в системе;
4) аутентифицированный обмен данными;
5) целостность данных при формировании, передаче, использовании,
обработке и хранении информации;
6) авторизированную доступность всех ресурсов системы в
условиях нормальной эксплуатации;
7) разграничение доступа пользователей к ресурсам ИС;
8) администрирование (обозначение прав доступа к ресурсам ИС,
обработка информации из регистрационных журналов, установка и снятие
системы защиты);
9) регистрацию действий по входу и выходу пользователей, а также
нарушений прав доступа к ресурсам ИС;
10) контроль целостности и работоспособности системы обеспечения
информационной безопасности;
11) безопасность и бесперебойное функционирование системы в
чрезвычайных ситуациях.
6.1.2 Определение архитектуры информационной системы
На данном этапе необходимо провести анализ и уточнение
результирующей иерархии физической архитектуры ИС, программных
сегментов и реализации построения сегментов. Исходными данными для
этого этапа служит пакет бизнес-требований, включающий функциональные,
нефункциональные и требования по обеспечению безопасности ИС.
На этапе определения архитектуры ИС должны быть разработаны
детализированные модели того, что было подготовлено на этапе разработки
бизнес-требований. Разрабатываемые модели включают архитектурные
модели, в которых необходимо определить способ преобразования
различных функциональных компонентов в физические компоненты (т.е.
рабочий стол, сервер, база данных, сеть).
На данном этапе должны быть разработаны планы тестирования для
различных уровней тестирования (смотри раздел 6.5):
1) тестирование блочное;
2) тестирование модуля;
3) тестирование системы (возможности интегрирования систем);
4) тестирование интерфейсов между системами;
14
5)
6)
7)
8)
тестирование файлов загрузки;
нагрузочное тестирование;
тестирование безопасности;
тестирование резервного копирования.
6.1.3 Определение ограничений реализации ИС
На данном этапе необходимо провести анализ проекта и плана
разработки ИС. Идентифицировать программные ограничения и требования,
включая вспомогательные ресурсы, спецификации, определение решений о
покупке или внутренней разработке требуемых компонент приложения.
Определяется
полный
набор
технически
и
коммерчески
жизнеспособных системных элементов, из которых конфигурируется ИС.
Необходимо рассмотреть архитектуру ИС и ее структурную схему с
ассоциациями между элементами, определить внешние интерфейсы по
отношению к системе и между компонентами самой системы.
Описывается программное окружение разрабатываемой ИС. Если
разрабатываемая ИС является расширением уже существующей, то
описываются главным образом ее дополнительные характеристики.
Приводится перечень аппаратного и программного обеспечения,
необходимого для работы ИС.
Необходимо рассматривать несколько аспектов совместимости:
неоднородность программной среды, языки программирования, форматы
данных и сообщений, форматы отчетов, форматы листингов. Специально
должна оговариваться совместимость с различным ПО.
6.1.4
Анализ
коммуникаций
архитектуры
аппаратного
обеспечения,
На данном этапе необходимо проверить и удостовериться в
способности аппаратного обеспечения ИС отвечать новым и меняющимся
требованиям ведения бизнеса со стороны таких компонентов
инфраструктуры как сети, телекоммуникации и другие программные
приложения.
На этапе проектирования определяются как архитектура аппаратного
обеспечения, так и требования низкого уровня. Разработка архитектуры
заключается в принятии ряда последовательных и взаимосвязанных решений
о структуре аппаратного обеспечения ИС. Разработка требований низкого
уровня к ИС – формирование требований к отдельным программным
модулям.
Архитектура ИС включает описание:
1) физических сущностей, из которых состоит система (узлов сети,
сетей);
2) информационных потоков между физическими сущностями в
15
системе;
3) спецификаций каналов передачи информации в системе;
4) выбора платформы (платформ) и операционной системы
(операционных систем);
5) выбора архитектуры «файл–сервер» или «клиент–сервер»;
6) выбора 3–уровневой архитектуры со следующими слоями: сервер,
ПО промежуточного слоя (сервер приложений), клиентское ПО;
7) выборa базы данных централизованной или распределенной.
Подтверждение требований по мощности, производительности и
доступности ИС относятся к основным действиям, производимым на данном
этапе.
Результаты этапа включают:
1) определение аппаратных и программных требований и
ограничений;
2) определение функциональных, нефункциональных и требований
по безопасности ИС;
3) создание программной архитектурной иерархии сегментов и
связанных функций;
4) создание аппаратной архитектуры.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в Таблице 1.
№
п\п
1
2
3
4
5
Таблица 1. Стоимость информационной системы на этапе «Сбор и анализ
требований к информационной системе»
Компоненты затрат
Стоимость
Стоимость
Стоимость
работ
работ
учебных
сторонних
собственного курсов
и
организаций персонала
сертификации
Разработка
документации
по
функциональным
требованиям
Разработка
документации
по
требованиям к внешним
интерфейсам
Разработка
документации
по
нефункциональным
требованиям
Разработка
спецификации
требований к ИС
Разработка
16
№ Компоненты затрат
п\п
Стоимость
работ
сторонних
организаций
Стоимость
работ
собственного
персонала
Стоимость
учебных
курсов
и
сертификации
документации
по
требованиям к ПО
6 Проверка и валидация,
определение
ограничений к ИС
7 Определение
архитектуры ИС
8 Разработка ограничений
реализации ИС
9 Планирование
управления
конфигурацией ПО
10 Контроль конфигурации
11 Составление отчетности
по конфигурации
12 Определение
архитектуры
аппаратного
обеспечения
13 Определение требований
к
аппаратному
обеспечению
14 Разработка критической
модели ИС
15 Определение требований
по
обеспечению
информационной
безопасности
16 Проектирование ПО
17 Административные
расходы, связанные со
сбором
и
анализом
требований к ИС
Итого:
Итого по этапу:
17
6.2 Определение структурных единиц и стоимости поставок
программного и аппаратного обеспечения
Цель данного этапа заключается в определении структурных единиц и
стоимости поставок программного и аппаратного обеспечения, которые
будут включены в стоимость ИС.
При планировании структурных единиц проекта, для которого
требуется оценка стоимости, необходимо применять принцип Структурного
разбиения работ.
Структурные единицы и поставки программного и аппаратного
обеспечения, которые необходимо проанализировать на данном этапе
включают:
1) управление ПО – предполагает решение широкого спектра задач:
отслеживание
сбоев
в
управляемых
компьютерах,
автоматическое устранение их причин, исправление их последствий и
действия по их предотвращению;
- управление производительностью компьютеров и приложений;
- автоматическое конфигурирование компьютеров и сетевых
устройств;
- конфигурирование и обновление ПО.
2) проектирование ИС – определяется как итерационный процесс
получения логической модели ИС вместе со строго сформулированными
целями, поставленными перед ней, а также написания спецификаций
физической системы, удовлетворяющей этим требованиям;
3) разработка ПО – достаточно подробное уточнение требований
заказчика и проектного решения и преобразование их в один или несколько
жизнеспособных ПО;
4) тестирование ПО – один из важнейших этапов проверки качества
разработанного ПО;
5) среда разработки ПО – система программных средств,
используемая программистами для разработки ПО. Среда разработки
включает:
- текстовый редактор;
- компилятор и/или интерпретатор;
- средства автоматизации сборки и отладчик;
- систему управления версиями;
- инструменты для упрощения конструирования графического
интерфейса пользователя;
- браузер классов, инспектор объектов и диаграмму иерархии
классов;
6) системный уровень поддержки тестирования включает
испытание разрабатываемого ПО, испытание системного уровня ПО,
18
поддержку сборки, тестирования и процедуры сдачи ПО в эксплуатацию;
7) сборка, тестирование и процедура сдачи ПО в эксплуатацию –
готовое ПО передается заказчику, производятся приемо–сдаточные
испытания, осуществляется обучение пользователей и опытная эксплуатация,
после чего ПО ставится на сопровождение и начинается производственная
эксплуатация ПО;
8) система обеспечения качества направлена на обеспечение
необходимого уровня объективности и достоверности результатов
разработки и внедрения ПО, а также на обеспечение надлежащего качества
производимой продукции и/или предоставляемых услуг;
9) независимая проверка и подтверждение адекватности ИС.
Эти категории Структурного разбиения работ включают в себя
процессы жизненного цикла разработки ИС.
Результаты этапа включают:
1) определение поставок программного и аппаратного обеспечения;
2) определение структурных единиц ИС.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в Таблице 2.
Таблица 2. Стоимость информационной системы на этапе «Определение
структурных единиц и стоимости поставок программного и аппаратного
обеспечения»
№ Компоненты затрат
Стоимость Стоимость Стоимость
п\п
приобрете- организадополнительных
ния
ции
работ
для
тендеров
введения
в
эксплуатацию
1 Определение
компонентов
программного
и
аппаратного
обеспечения
2 Среда разработки ПО
3 Инструменты
управления БД
4 Инструменты
системного мониторинга
5 Инструменты системной
отчетности
6 Инструменты
генерирования отчетов
7 Затраты на системный
19
№ Компоненты затрат
п\п
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Стоимость
приобретения
Стоимость
организации
тендеров
Стоимость
дополнительных
работ
для
введения
в
эксплуатацию
мониторинг
Инструменты
диагностики
аппаратного
и
программного
обеспечения
Инструменты анализа и
проектирования
Инструменты
тестирования
Рабочие
станции
и
комплектующие
Принтеры,
сканеры,
ксероксы
Устройства
хранения
данных
Сервера
Оборудование
для
серверного помещения
Инструменты
обеспечения
информационной
безопасности
Стоимость
аренды
аппаратного
и
программного
обеспечения
Сетевое оборудование
Поддержка
сопровождения
Операционные системы
Обновление ПО
Лицензии
Коммуникационные
20
№ Компоненты затрат
п\п
Стоимость
приобретения
Стоимость
организации
тендеров
Стоимость
дополнительных
работ
для
введения
в
эксплуатацию
услуги
24 Программы
для
коммуникаций
25 Обучение,
переподготовка,
инструктаж персонала
26 Административные
расходы, связанные с
определением
структурных единиц и
поставками
программного
и
аппаратного
обеспечения
Итого:
Итого по этапу:
6.3
системы
Оценка
размера
программной
части
информационной
Целью данного этапа является определение размера программной
части ИС.
Промышленной мерой оценки размера ПО является количество
исходных строк кода - Source Lines of Code (SLOC). Под строками кода SLOC
понимаются логические строки кода, а именно строки в понимании
используемого языка программирования, без учета комментариев.
Оценка размера ПО происходит следующим образом:
1) разделение и группировка программных функциональных
требований и требований к ИС органов публичной власти в категории
программного наследования.
Категории программного наследования включают:
- новый проект и новый код;
- аналогичный проект и новый код;
- аналогичный проект и многократно используемый код;
- аналогичный проект и расширенный код, используемый
многократно.
21
Нефункциональные требования и требования к интерфейсам
используются для составления планов тестирования ПО и приложений.
Впоследствии категории программного наследования будут
использованы в качестве множителей для корректировки объема работ для
программного наследования (смотри пункт 6.4.2.2, формула (3), таблица 6);
2) оценка размера каждой программной функции - в соответствии с
коэффициентами, приведенными в таблице 3.
Таблица 3. Оценка KSLOC базовых размеров ПО для модели COCOMO II
Размер ИС
KSLOC
Ед. измерения
Маленькая
2
тыс. строк кода
Небольшая
8
тыс. строк кода
Средняя
32
тыс. строк кода
Большая
128
тыс. строк кода
Очень большая
512
тыс. строк кода
Количество тысяч строк кода (KSLOC) рассчитывается по формуле:
( SLOCP  K p  SLOCI  K i  SLOCR  K r )
KSLOC 
1000
,
(1)
где:
- KSLOC - количество тысяч строк кода;
- SLOCP - код, обеспечивающий определенную логику работы
системы. Обычно, это классы, описывающие свойства объектов системы,
взаимосвязь между бизнес–функциями;
- SLOCI - код, обрабатывающий элементы интерфейса и
связывающий его с другими частями системы. Обычно это классы обработки
ошибок ввода данных, записи данных в базу данных и т.п.;
- SLOCR - код, описывающий интерфейс системы. Обычно это код,
описывающий сам интерфейс. Для компонент, работающих в среде Интернет
- это HTML код;
- Kp - фактор изменения логики работы системы;
- Ki - фактор изменения обработки интерфейсных элементов системы;
- Kr - фактор изменения интерфейса системы.
Факторы K подбираются опытным путем и измеряются от 0,01 - 0,6 и
свыше 0,6 при создании новой системы. Для определения факторов K
используется статистический подход, помогающий изменять априорные
оценки с учетом данных новых исследований;
3) расчет общего размера программной части ИС в KSLOC,
просуммировав данные, полученные в пункте 2 по каждой программной
функции.
Альтернативные методы оценки программной части ИС представлены
в Приложении 1.
Результаты этапа включают:
22
1) размер ПО, оцененный для каждой функциональной категории
наследования KSLOC;
2) общая программная оценка размера KSLOC.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в таблице 4.
Таблица 4. Стоимость информационной системы на этапе «Оценка размера
программной части информационной системы»
№ Компоненты затрат
Стоимость
Стоимость
Стоимость
п\п
работ
работ
учебных
сторонних
собственного курсов
и
организаций персонала
сертификации
1 Составление
документации по оценке
размера
программной
части ИС
2 Определение
размера
программной части ИС
3 Анализ статистических
данных
в
данной
области
4 Административные
расходы, связанные с
оценкой
размера
программной части ИС
Итого:
Итого по этапу:
6.4 Оценка объема работ
Для оценки людских ресурсов (человек – в месяц),
продолжительности (в календарных днях) и стоимости (в денежных
единицах) необходимо основываться на статистике из прошлого опыта. В
случае отсутствия исторических данных или если ведется работа над новым
проектом необходимо применение специальных методик, позволяющих
предварительно оценить затраты на планируемый проект.
6.4.1 Идентификация категорий Структурного разбиения работ,
атрибуты которых будут влиять на размер и объем работ
Необходимо идентифицировать категории Структурного разбиения
работ, атрибуты которых будут влиять на размер и объем работ согласно
23
смете проекта, с точки зрения наследования и риска. Основными
категориями рисков могут быть следующие:
1) новые технологии: код, язык программирования или метод
проектирования. Выбор языка программирования также может оказать
существенное влияние на безопасность ИС. Лучшими языками
программирования являются те, в которых все действия определены и
обоснованы, поддерживаются функции, уменьшающие число ошибок,
осуществляется контроль над распределением памяти и использованием
указателей. Эта группа рисков объединяет риски, связанные с
используемыми технологиями, несовместимостью языков программирования,
несоответствием методов проектирования;
2) низкий уровень готовности технологий – истечение срока
действия лицензий, моральное устаревание технологий, появление
принципиально новых технологий, которые сразу делают определенные
продукты и услуги неактуальными;
3) оптимистические предположения, связанные с наследованием
элементов ИС;
4) возможность многократного использования кода - увеличение
количества ошибок в связи с неправильно составленным многократно
использующимся программным кодом;
5) риск, связанный с поставщиками программного и аппаратного
обеспечения - необходимо создание формальных процедур по управлению
рисками, связанными с поставщиками. К этой категории рисков также
относятся риски ценообразования, связанные с неопределенностью
экономических показателей проектов, и валютные риски;
6) риск недостаточной защиты интеллектуальной собственности:
возможность нарушения патентов и хищения интеллектуальной
собственности на развивающихся рынках;
7) риски, связанные с сервисным и техническим обслуживанием:
отсутствие специализированных инженерных служб, квалифицированной
рабочей силы и подменного оборудования;
8) параллельная разработка аппаратных средств;
9) количество
интерфейсов
между
многочисленными
подразделениями разработчиков;
10) инфраструктурные риски – проблемы подключения к сети и
отсутствие доступа к передающим и распределительным системам;
11) географическое распределение многочисленных подразделений
разработчиков;
12) высокая сложность элементов ИС;
13) профессиональные навыки и опыт персонала – данной категории
рисков необходимо уделить особое внимание. Руководитель проекта должен
оценить риски и организовать обучение еще до начала проекта, чтобы не
терять время на ошибки в будущем;
14) неопределенные или неполные требования – процесс разработки
24
ИС начинается с определения требований и вариантов использования
системы. Основная проблема заключается в том, что некоторые ключевые
требования могут быть пропущены, другие требования не так понятны
разработчиками. Еще одна категория рисков, связанная с требованиями – это
реализация второстепенных требований и откладывание основных
требований;
15) риски, связанные с аутсорсингом;
16) политические риски - связаны с корпоративной политикой
взаимодействующих сторон, а также особенностями организаций и
деятельностью составляющих подразделений.
Для каждой категории рисков средневзвешенный коэффициент
влияния на размер и объем работ определяется согласно статистическому
подходу, помогающему изменять априорные оценки с учетом данных новых
исследований.
6.4.2 Преобразование размера программного обеспечения в объем
работ
Целью является преобразование размера ПО, полученного в
соответствии с подразделом 6.3 (формула (1)), в объем работ. Разработка ПО
охватывает программных инженеров, системотехников, тестировщиков,
программистов, а также включает в себя: разработку и анализ требований по
интегрированию и тестированию ПО. Вычисление объема работ и стоимости
других категорий Структурного разбиения работ приведено ниже, с
использованием других методов.
Вычисление объема работ производится в рабочих месяцах (РМ) для
следующих категорий Структурного разбиения работ: «Проектирование ИС»,
«Разработка ПО» и «Тестирование ПО».
6.4.2.1 Оценка трудозатрат и объема работ по проектированию
информационной системы
Анализ и проектирование ИС являются определяющими при
построении ИС. Выделяют три фазы анализа и проектирования ИС:
1) обследование и системный анализ существующей ИС, и
выявление ее недостатков;
2) обобщение результатов системного анализа и создание
предварительной концепции новой или модернизированной ИС;
3) разработка системного проекта комплекса программ и баз данных,
определяющих методы и средства дальнейшего детального проектирования и
всего жизненного цикла ИС и базы данных.
Системный анализ является важным для успешного проектирования
ИС, поэтому может рассматриваться как один из факторов риска. Для
выполнения работ по проектированию ИС могут привлекаться
25
специализированные
организации,
имеющие
опыт
подобного
проектирования, либо собственные аналитические структуры, знающие
бизнес–процессы организации. Работы по проектированию ИС выполняются
наиболее эффективно комбинированной проектной группой.
При реализации системного анализа достигаются следующие
результаты:
1) описание бизнес и информационных процессов, сложившихся в
организации;
2) узкие места в бизнес–процессах и пути их ликвидации;
3) информационная и функциональная модель ИС;
4) список требований к новой или модернизированной ИС;
5) методы и средства проектирования и реализации ИС;
6) предварительный укрупненный план проектирования ИС;
7) технико–экономическое обоснование.
Трудозатраты по проектированию ИС включают оплату работ
специалистов сторонних организаций, в соответствии с условиями
заключенного контракта, а также оплату работ собственных аналитических
структур.
Объем работ по проектированию ИС определяется согласно контракту,
заключенному со специалистами сторонних организаций, в котором
указывается объем выполняемых работ и сроки их выполнения, а также
согласно должностным инструкциям собственного персонала.
Объем работ по проектированию ИС в разрезе декомпозиции
основных категорий Структурного разбиения работ в процентном
соотношении определяется согласно методике и статистическому анализу
SEER–SEM (смотри пункт 6.4.3(2), таблица 11) или согласно
статистическому методу (Приложение 1).
Проектирование ИС охватывает три основные области:
1) проектирование объектов данных, которые будут реализованы в
базе данных;
2) проектирование программ, экранных форм, отчетов, которые
будут обеспечивать выполнение запросов к данным;
3) учет конкретной среды или технологии, а именно: топологии сети,
конфигурации аппаратных средств, параллельной обработки, распределенной
обработки данных.
6.4.2.2 Преобразование размера каждой программной функции в
объем работ по разработке программного обеспечения
Преобразование размера каждой программной функции в объем работ
по разработке ПО вычисляется следующим образом:
1) расчет объема работ по разработке выполняется по формуле (2).
26
Объем _ работ _ по _ разработке _ ПО 
Полученный _ размер
Программная _ производительность
(2),
где
- Объем работ по разработке ПО - определяется в рабочих месяцах
(РМ);
- Программная производительность - определяется в SLOC/РМ;
- Полученный размер - определяется в SLOC.
Для определения программной производительности, используются
данные из аналогичного программного проекта. Если данные аналогичного
проекта недоступны, можно использовать таблицу 5. Показатели
производительности, представленные в таблице 5, отражают процесс
разработки ПО.
Таблица 5. Производительность программной разработки для средних
промышленных проектов
Производительность программной
Характеристика
разработки (SLOC/РМ)
Классические показатели
130–195
Развивающиеся методы
244–325
Новое встроенное ПО
17–105
2) корректировка объема работ по оценке каждой категории
Структурного разбиения работ выполняется по формуле (3), с
использованием множителей объема работ для программного наследования,
приведенных в таблице 6.
Скорректированный _ Объем _ работ  Объем _ работ * Множитель _ объема _ работ
(3)
где
- Скорректированный_Объем_работ - определяется в рабочих
месяцах (РМ);
- Объем_работ - определяется в рабочих месяцах (РМ);
- Множитель_объема_работ – определяется по данным Таблицы 6.
Таблица 6. Множители объема работ для программного наследования
Категория программного наследования
Множитель объема работ
Новый проект и новый код
1,2
Аналогичный проект и новый код
1,0
Аналогичный проект и код, используемый
0,8
многократно
Аналогичный проект и расширенный код,
0,6
используемый многократно
27
3) скорректированный объем работ каждой функциональной и
программной категории наследования суммируется, чтобы определить
общий объем работ.
6.4.2.3
обеспечения
Оценка
трудозатрат
на
разработку
программного
Трудозатраты на разработку ПО могут включать оплату работ
специалистов сторонних организаций, в соответствии с условиями
заключенного контракта, а также оплату работ собственного персонала.
6.4.2.3.1 Трудозатраты на аутсорсинг по разработке программного
обеспечения
Аутсорсинг определяется как отказ от разработки ПО собственным
персоналом и приобретение услуг по разработке ПО у сторонних
организаций.
Аутсорсинг по разработке ПО может включать следующие виды услуг:
1) разработка ПО;
2) поддержка ПО;
3) рефакторинг и реинжиниринг приложений;
4) внедрение разрабатываемого ПО;
5) документирование ПО;
6) обучение персонала заказчика;
7) консалтинг в области ИТ.
При принятии решения об использовании аутсорсинга по разработке
ПО необходимо учитывать следующие факторы:
1) стоимость собственных разработок в соотношении со
стоимостью услуг аутсорсинга;
2) риски нарушения режима информационной безопасности;
3) риски разрыва отношений с аутсорсинговой компанией и
дальнейшее развитие созданного приложения;
4) особенности организации и управления процессами разработки
внутри компании;
5) степень доверия сторонней организации определенной доли
своих секретов.
Аутсорсинг позволяет использовать опыт профессионалов, сократить
риски и снизить затраты, увеличивая отдачу вложенных средств.
К трудозатратам на разработку ПО специалистами сторонних
организаций относится оплата работ по оказанию услуг по разработке ПО в
соответствии с условиями заключенного контракта.
28
6.4.2.3.2 Трудозатраты на разработку программного обеспечения
собственным персоналом
Оценка трудозатрат на разработку ПО определяется по количеству
строк кода. Базовая формула оценки трудозатрат с использованием модели
COCOMO II:
E  a  KSLOC b  EAF ,
(4)
где
- E - трудозатраты, выраженные в рабочих месяцах;
- a, b - коэффициенты, которые зависят от режима использования
модели (смотри таблицы 6, 7);
- KSLOC - количество тысяч строк кода;
- EAF - фактор корректировки трудозатрат.
Режимы использования модели COCOMO II в зависимости от
размеров численности команды и размера проекта приведены в таблице 7.
Таблица 7. Режимы использования модели COCOMO II
Название
Размер
Описание
режима
проекта
Органичный
До
50 Некрупный
проект
разрабатывается
KSLOC
небольшой командой, для которой не
характерны нововведения и среда остается
стабильной
Сблокированный 50–300
Относительно
небольшая
команда
KSLOC
занимается проектом среднего размера, в
процессе
разработки
необходимы
определенные
инновации,
среда
характеризуется
незначительной
нестабильностью
Внедренный
Более
300 Большая команда разработчиков трудится
KSLOC
над
крупным
проектом,
необходим
значительный объем инноваций, среда
состоит из множества элементов, которые не
характеризуются стабильностью
Базовые значения коэффициентов модели СОСОМО II в зависимости
от режима представлены в таблице 8.
Таблица 8. Базовые значения коэффициентов модели COCOMO II в
зависимости от режима
Название режима
Значение
Значение
коэффициента a
коэффициента b
Органичный
2,4
1,05
29
Сблокированный
Внедренный
3,0
3,6
1,12
1,20
Фактор корректировки трудозатрат EAF увеличивает или уменьшает
трудозатраты в зависимости от факторов среды разработки. Расчет фактора
корректировки трудозатрат выполняется по формуле (5):
n
EAF   Ci
i 0
,
(5)
где
- Ci – один из факторов среды разработки.
Определение факторов корректировки трудозатрат EAF:
1) Фактор Учета Технологии Разработки (ФУТР). Под этим
фактором учитывается увеличение количества трудозатрат в результате
вовлечения разного количества сотрудников.
В этом процессе задействованы следующие категории сотрудников:
- категория «А»: менеджер проекта; менеджер разработки
программной системы; менеджер внедрения ПО; менеджер эксплуатации;
менеджер сопровождения ПО; аналитик бизнес-процессов; бизнеспроектировщик; системный аналитик; технолог бизнес–процессов;
- категория «В»: программист; проектировщик программной
системы; проектировщик пользовательского интерфейса; интегратор;
технический писатель; системный администратор; администратор баз данных;
специалист управления конфигурацией;
- категория «С»: тестировщик; тестировщик службы сопровождения;
разработчик тестов; аналитик службы сопровождения.
Время тестирования является величиной зависимой от времени
кодирования и определяется коэффициентом Ktest, который рассчитывается
по формуле (6):
ltest
 Ktest
l
,
(6)
где
- l - продолжительность процесса кодирования, выраженная в
рабочих месяцах.
- ltest - продолжительность процесса тестирования, выраженная в
рабочих месяцах.
Расчет Фактора учета технологии разработки выполняется по формуле
(7), выражается в рабочих месяцах:
ФУТР 
A  (1  Ktest )  C  Ktest
 1  Ktest
B
,
(7)
где
А, В, С - количество сотрудников соответствующих категорий.
Расчет длительности разработки выполняется по формуле (8),
30
выражается в рабочих месяцах:
L  l  (1  Ktest ) ,
(8)
2) Фактор учета сложности и опыта разработки (ФУСОР)
определяется эмпирически и состоит из значений, приведенных в таблице 9.
Таблица 9. Базовые значения коэффициентов Фактора учета сложности и
опыта разработки
Фактор учета сложности и опыта разработки
Значение
Надо поправить то, что есть
1,00
Уже делали раньше, есть опыт
1,10
Есть опыт и не видно трудностей
1,30
Опыта нет, но есть помощь
2,00
Нет ни опыта, ни помощи
4,00
Этот способ оценки используется на начальной стадии проекта для
оценки всего проекта в целом. Для небольших проектов и небольших по
объему работ его использование затруднительно.
6.4.3 Завершение оценки объема работ
Цель данного шага состоит в расширении оценки для охвата всех
категорий Структурного разбиения работ. До этого шага, оценивались
следующие категории Структурного разбиения работ: «Проектирование ИС»,
«Разработка ПО» и «Тестирование ПО». Объем работ, например, таких как,
«Управление программным объемом работ» и «Система обеспечения
качества», является дополнительным по отношению к объему работ по
разработке ПО.
1) Для получения стоимостной оценки работ по всем
перечисленным категориям необходимо к рассчитанному раннее объему
работ прибавить дополнительный объем работ по разработке ПО.
Дополнительный объем работ по разработке ПО – это отношение объема
работ по разработке ПО для дополнительной деятельности к общему объему
работ для всех рабочих элементов Структурного разбиения работ,
выраженное в процентах. Дополнительный объем работ по разработке ПО
приведен в таблице 10.
Таблица 10. Дополнительный объем работ по разработке ПО
Категория Структурного разбиения
Дополнительный объем работ
работ
по разработке ПО, %
Управление ПО
Прибавить 6–27%
Системный
уровень
поддержки Прибавить 34–112%
тестирования
Система обеспечения качества
Прибавить 6–11%
31
Категория Структурного разбиения
работ
Независимая проверка
Дополнительная деятельность:
управление конфигурацией проектов
управление проектами
управление поставками программного и
аппаратного обеспечения
доработка
Эксплуатация, первые пять лет
Дополнительный объем работ
по разработке ПО, %
Прибавить 9–45%
Прибавить 3–6%
Прибавить 8–11%
Прибавить 11–22%
Прибавить 17–22%
Прибавить 22% объёма работ по
разработке
ПО
за
год
эксплуатации
2) Суммируйте объем работ для каждой категории Структурного
разбиения работ, не относящейся к разработке ПО, чтобы получить общий
объем работ. Декомпозиция объема работ основных категорий Структурного
разбиения работ согласно методике и статистическому анализу SEER–SEM
представлена в таблице 11.
Таблица 11. Декомпозиция разработки ПО
Категория Структурного
% от объёма работ по разработке
разбиения работ
ПО
Разработка ПО:
100%
Анализ требований ПО
12%
Разработка ПО
55%
Внедрение ПО
13%
Программное интегрирование и
20%
тестирование ПО
SEER–SEM является широко используемой системой определения и
оценки ресурсов ПО, созданной на основе комбинирования математики и
статистики.
Декомпозиция объема работ может проводиться согласно
статистическому методу (Приложение 1).
Результаты этапа включают:
1) объем работ по разработке ПО для всех категорий Структурного
разбиения работ (в рабочих месяцах);
2) общий объем работ по разработке ПО.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в таблице 12.
Таблица 12. Стоимость информационной системы на этапе «Оценка объема
работ»
32
№ Компоненты затрат
п\п
Стоимость
работ
сторонних
организаций
Стоимость
работ
собственного
персонала
Стоимость
учебных
курсов
и
сертификации
Идентификация
Структурного разбиения
работ
2 Идентификация рисков
3 Расчет объема работ по
разработке ПО
4 Корректировка объема
работ по разработке ПО
5 Оценка трудозатрат на
разработку ПО
6 Расчет
фактора
корректировки
трудозатрат
7 Определение
дополнительных работ
по разработке ПО
8 Определение
объема
дополнительных работ
по разработке ПО
9 Декомпозиция
разработки ПО
10 Административные
расходы, связанные с
оценкой объема работ
Итого:
Итого по этапу:
1
6.5 Трудозатраты на кодирование и тестирование
Целью данного этапа является определение периода времени и расчет
трудозатрат на кодирование и тестирование, которые необходимы для
завершения программного проекта, и сроков выполнения рабочих элементов
Структурного разбиения работ.
33
6.5.1 Объем работ по кодированию и тестированию
За основу оценки трудозатрат по разработке программной
компоненты берется оценка трудозатрат по количеству строчек кода по
формулам (4) и (5). Оценка каждого функционального требования
выполняется отдельно, при этом значение константы b принимается равной 1,
так как функциональное требование является составной частью проекта.
Объем работ, зависит от вида работы, а время его выполнения зависит от
программной производительности. Программная производительность это
величина, равная отношению объема проделанной работы ко времени, за
которое она была совершена. Формула (4) преобразуется к виду, указанному
в формуле (9):
E   (
i
j
KSLOC ( i , j )
Wj
 EAF )
,
(9)
где
- Wj - программная производительность, необходимая для
выполнения j–ого вида работы;
- KSLOC(i,j) - количество тысяч строк кода j–го вида работ для
реализации i–го требования.
Производительность W определяется опытным путем, исходя из
опыта работы над предыдущими компонентами.
6.5.2 Определение длительности кодирования и тестирования
Кодирование – написание уже спроектированной программы на
некотором формальном языке программирования. В процессе кодирования
проверяются отдельные требования к ИС. Затем начинается интегральное
тестирование системы как единого целого, которое начинается еще в
процессе кодирования. Тестирование сопровождается проверкой исходного
кода, поиском ошибок по их проявлениям в процессе выполнения программы.
Длительность кодирования и тестирования, выраженная в рабочих
месяцах, вычисляется по формуле (10):
T   (
i
j
KSLOC ( i , j )
Wi
 ФУСОР( i )) 
1
 (1  Ktest)
P
,
(10)
Распределить время для каждой категории Структурного разбиения
работ и определить допустимую рабочую нагрузку. После составления плана
работ, проверить распределение работ в соответствии с аналогичным опытом,
используя таблицу 13 и таблицу 14. Числа в таблице 13 и таблице 14
представляют среднее, базовое расписание. Значимые отклонения от этих
данных приведут к увеличению риска и повышению стоимости.
34
Таблица 13. Распределение времени по фазам разработки ПО, основанное на
промышленных данных
Фаза
Промышленные данные (средства)
Анализ требований
18%
Разработка ПО
22%
Внедрение
36%
Программное интегрирование
24%
и тестирование
Таблица 14. Распределение объема работ для нового, модифицированного
или преобразованного ПО, основанного на промышленных данных
Фаза
Новое ПО
Существующее
Преобразованное
модифицированное ПО
ПО
Анализ
20%
15%
5%
требований
проекта
Рабочий проект,
57%
10%
5%
код и тест
Интеграция
и
23%
40%
30%
тестирование ПО
Относительный
100%
65%
40%
объём работ
6.5.3 Трудозатраты по кодированию и тестированию
Трудозатраты для определения стоимостной оценки кодирования и
тестирования, выраженные в рабочих месяцах, вычисляются по формуле (11).
E   (
KSLOC ( i , j )
Wj
 ФУСОР( i ))  ФУТР
,
(11).
При определении трудозатрат на тестирование важно учитывать
трудозатраты персонала категории «С» (см. пункт 6.4.2.3) на составление
планов тестирования (см. пункт 6.1.2).
Один из ключевых элементов обеспечения качества - это
тестирование. Процесс тестирования осуществляется в несколько этапов,
которые отличаются видами выполняемых работ и привлекаемыми
ресурсами.
Первым этапом тестирования является внутреннее тестирование, на
котором выполняется проверка функциональной полноты ИС, соответствие
проектной документации, корректность проектных решений, а также
контролируется соответствие законодательству.
i
j
35
Следующим этапом является внешнее тестирование, на котором
происходит концентрация усилий опытных экспертов, использующих
различную методологию и разнообразные подходы к работе с ИС.
Как на внутреннем, так и на внешнем тестировании постоянно
проводится статистический анализ количества обнаруженных и
исправленных ошибок, на основе результатов которого принимается решение
о переходе к следующему этапу.
На заключительном тестировании проводится проверка реализации
максимального количества бизнес–процессов и исправление ошибок на
предшествующих этапах.
Для этого этапа тестирования необходимо выделить больше времени
и трудовых ресурсов, чтобы гарантировать высокую надежность ИС.
Высокий уровень методического, технического, организационного
обеспечения тестирования на всех этапах предопределяет высокое качество
ИС. Далее осуществляется опытная эксплуатация, которая позволяет выявить
все нюансы, которые не были обнаружены на предыдущих этапах
тестирования.
Тестирование довольно высокотехнологичный и трудозатратный
процесс, требующий у организации наличия в своем распоряжении широкого
разнообразия аппаратных, программных и людских ресурсов. В некоторых
случаях целесообразно использование аутсорсинга по тестированию.
Аутсорсинг по тестированию - передача функций оценки качества ИС
третьей стороне, профессионально занимающейся тестированием. Для
обеспечения должного уровня проводимого тестирования, необходимо
обеспечить достаточную квалификацию тестировщиков, современные
инструменты автоматизации тестирования, наличие оборудования,
позволяющего имитировать ситуации реальной эксплуатации ИС.
Доверяя тестирование ИС третьей стороне, необходимо обеспечить
гарантию проверки и оценки именно тех аспектов, которые в этом
нуждаются. Для этого разрабатываются план и сценарии тестирования,
подробно описывающие, что, в какой последовательности, с какими
приоритетами, с какой тщательностью, каким образом, с помощью каких
инструментов и в какой среде будет тестироваться.
Процесс тестирования в обязательном порядке должен быть
документирован, а именно должны быть оформлены отчеты и протоколы
тестирования, наглядно показывающие результаты и динамику проводимой
оценки.
Результаты этапа включают:
1) определение трудозатрат на кодирование и тестирование;
2) распределение сроков выполнения работ категорий Структурного
разбиения работ.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в таблице 15.
36
Таблица 15.Стоимость информационной системы на этапе «Трудозатраты на
кодирование и тестирование»
№ Компоненты затрат
Стоимость
Стоимость
Стоимость
п\п
работ
работ
учебных
сторонних
собственного курсов
и
организаций персонала
сертификации
1
Определение
объема
работ по кодированию
2
Определение
объема
работ по тестированию
3
Определение
фактора
среды EAF
4
Расчет Фактора Учета
Технологии Разработки
5
Расчет Фактора Учета
Сложности и Опыта
Разработки
6
Расчет
длительности
кодирования
и
тестирования
7
Расчет трудозатрат на
кодирование
и
тестирование
8
Распределение времени
по фазам разработки ПО
9
Составление плана работ
по разработке ИС
10 Составление планов и
сценариев тестирования
11 Административные
расходы, связанные с
оценкой трудозатрат на
кодирование
и
тестирование
Итого:
Итого по этапу:
37
6.6
системы
Определение
характеристик
качества
информационной
Целью данного этапа является определение внутренних и внешних
характеристик качества, методологии анализа качества, показателей качества,
а также определение и оценка необходимых работ по улучшению качества
ИС, которые требуют организационного, технического и методологического
обеспечения.
Для описания характеристик качества ИС выделяют следующие
процессы:
1) выбор и обоснование набора исходных данных, отражающих
общие особенности и этапы жизненного цикла ИС, которые влияют на
определенные характеристики качества ИС;
2) выбор, установление и утверждение конкретных метрик и шкал
измерения характеристик и атрибутов качества ИС для их последующей
оценки и сопоставления с требованиями спецификаций в процессе
квалификационных испытаний или сертификации на определенных этапах
жизненного цикла ИС.
6.6.1 Параметры качества
На начальных этапах жизненного цикла детально определяются
требования к ИС (см. пункт 6.1.1). Детализированные требования,
необходимые для работы ИС, определяются характеристиками качества,
которые уточняют и конкретизируют данные требования к их содержанию и
реализации.
При выборе параметров качества главными показателями являются:
их адекватность целям качества, прозрачность и четкость интерпретации и
экономическая эффективность получения результата.
Параметрами качества являются:
1) адаптируемость - мера гибкости системы, оценивает способность
ИС адаптироваться к изменениям требований либо перепроектированием ИС,
либо интеграцией приложений;
2) сложность интерфейсов и интеграции - параметр, измеряющий
степень сложности интерфейса или дополнительного объема работ по
программированию, требуемого для интеграции компонент в ИС, которые
требуются для тестирования, отладки и сопровождения;
3) тестовое покрытие указывает степень полноты различных типов
тестирования;
4) надежность - параметр, оценивающий вероятность работы ИС без
отказов;
5) профили ошибок - параметр, измеряющаий кумулятивное число
обнаруженных ошибок.
38
Характеристики, субхарактеристики и атрибуты качества ИС с
позиции возможности и точности их измерения разделяются на типы:
1) категорийный – описательный, отражающий набор свойств и
общие характеристики объекта. К данному типу относятся свойства ПО и
наборов данных, которые охватывают назначения и функции ИС.
Функциональная пригодность является самой важной и доминирующей
характеристикой ИС;
2) количественный - представляемый множеством упорядоченных,
числовых точек, которые можно объективно измерить и численно
сопоставить с требованиями. Значения таких характеристик влияют на
функциональные возможности ИС. Такими характеристиками являются
надежность и эффективность ПО. Надежность характеризуется временем
наработки на отказ, средним временем восстановления, а также
коэффициентом готовности. Количественные характеристики качества ИС
приведены в таблице 12;
3) качественный - содержащий несколько упорядоченных или
отдельных значений, которые характеризуются порядковой или точечной
шкалой, устанавливаются, выбираются и оцениваются субъективно и
экспертно. Качественные характеристики ИС приведены в таблице 17.
Таблица 16. Количественные характеристики качества ИС
Единица
Характеристики качества
измерения
Надежность
Завершенность:
наработка на отказ при отсутствии
час
рестарта
Устойчивость:
наработка на отказ при наличии
час
автоматического рестарта
относительные
ресурсы
на
%
обеспечение надежности и рестарта
Восстанавливаемость:
длительность восстановления
минута
Доступность–готовность:
относительное
время
работоспособного
вероятность
функционирования ИС
Эффективность
Временная эффективность:
время отклика — получения
секунда
результатов на типовое задание
пропускная
способность
— количество
в
количество
типовых
заданий, минуту
Интервал
значений
10–1000
10–1000
10–90
10–2 – 10
0,7–0,99
1–1000
1–1000
39
Характеристики качества
Единица
измерения
Интервал
значений
исполняемых в единицу времени
Используемость ресурсов:
относительная
величина
использования
ресурсов
при вероятность
нормальном функционировании ПО
0,7–0,99
Таблица 17. Качественные характеристики качества ИС
Единица
Характеристики качества
Интервал значений
измерения
Практичность
Понятность:
четкость концепции ИС
Отличная; хорошая;
демонстрационные возможности
удовлетворительная;
наглядность
и
полнота
неудовлетворительная
документации
Простота использования:
простота управления функциями
Отличная; хорошая;
удовлетворительная;
комфортность эксплуатации
неудовлетворительная
среднее время ввода заданий
секунда
1 – 1000
среднее время отклика на задание
Изучаемость
трудоемкость
изучения
применения ИС
продолжительность изучения
объем
эксплуатационной
документации
объем электронных учебников
Привлекательность:
субъективные или экспертные
оценки
человеко–час
1 – 1000
час
страница
1 – 1000
1 – 1000
килобайт
1 – 1000
-
Сопровождаемость
Анализируемость:
стройность
архитектуры человеко–час
программ
унифицированность интерфейсов час
полнота
и
корректность
-
Отличная; хорошая;
удовлетворительная;
неудовлетворительная
Отличная; хорошая;
удовлетворительная;
неудовлетворительная
1–1000
1–1000
Отличная; хорошая;
40
Единица
измерения
Характеристики качества
Интервал значений
документации
удовлетворительная;
неудовлетворительная
Изменяемость:
трудоемкость
подготовки
человеко–час
изменений
длительность
подготовки
час
изменений
Стабильность:
устойчивость
к
негативным
проявлениям при изменениях
Тестируемость:
трудоемкость
тестирования
изменений
длительность
тестирования
изменений
Мобильность
Адаптируемость:
трудоемкость адаптации
длительность адаптации
Простота установки:
трудоемкость инсталляции
длительность инсталляции
Сосуществование – соответствие:
стандартизация интерфейсов с
аппаратной и операционной
средой
Замещаемость:
трудоемкость
замены
компонентов
длительность
замены
компонентов
6.6.2 Внутренние
информационной системы
и
1–1000
1–1000
Отличная; хорошая;
удовлетворительная;
неудовлетворительная
человеко–час
1–1000
час
1–1000
человеко–час
час
1–100
1–100
человеко–час
час
1–100
1–100
Отличная; хорошая;
удовлетворительная;
неудовлетворительная
-
человеко–час
1–100
час
1–100
внешние
характеристики
качества
Качество ИС должны соответствовать внутренним и внешним
характеристикам, состоящим из шести групп базовых показателей, каждая из
которых детализирована несколькими нормативными субхарактеристиками:
1) функциональная пригодность ИС:
- пригодность для применения;
41
- корректность (правильность, точность);
- способность к взаимодействию;
- защищенность;
2) надежность ИС:
- уровень завершенности (отсутствие ошибок);
- устойчивость к дефектам;
- восстанавливаемость;
- доступность — готовность;
3) эффективность ИС:
- временная эффективность;
- используемость ресурсов;
4) применимость (практичность) ИС:
- понятность;
- простота использования;
- изучаемость;
- привлекательность;
5) сопровождаемость ИС:
- удобство для анализа;
- изменяемость;
- стабильность;
- тестируемость;
6) переносимость (мобильность) ИС:
- адаптируемость;
- простота установки — инсталляции;
- сосуществование — соответствие;
-замещаемость.
Дополнительно каждая характеристика должна сопровождаться
субхарактеристикой «согласованность», которая отражает отсутствие
противоречий с нормативными документами.
6.6.3 Характеристики качества программного обеспечения в
использовании
Внутренние и внешние характеристики качества относятся
непосредственно к самой ИС, а характеристики качества в использовании
проявляются в эффекте от ее применения и зависят от внешней среды.
Между характеристиками качества существует взаимовлияние сверху вниз и
зависимость снизу вверх, то есть повышение одной характеристики может
привести к снижению другой, и наоборот.
Основными характеристиками качества ПО в использовании должны
являться:
1) системная эффективность применения ПО по назначению;
2) продуктивность - производительность при решении основных
задач ИС, достигаемая при ограниченных ресурсах в конкретной внешней
42
среде применения;
3) безопасность - надежность функционирования комплекса ПО и
возможный риск от его применения для людей, бизнеса и внешней среды;
4) удовлетворение требований и затрат пользователей в
соответствии с целями применения ИС.
6.6.4 Методология оценки качества информационной системы
Для обеспечения полноты измерения качества ИС на ранних стадиях
жизненного цикла ИС требуется разработать структурные параметры
качества.
Измерение качества ИС состоит в вычислении отклонения
фактических характеристик ИС от нормативов.
Методология создания параметров качества ИС состоит из
следующих шагов:
1) определение нетехнического уровня, предназначенного для
менеджеров, пользователей, заказчика:
- формирование требований качества;
- выбор свойств качества, установка приоритетов и связи с
требованиями;
- определение допустимых коридоров для величин качества;
2) определение технического уровня, предназначенного для
аналитиков, конструкторов, разработчиков:
- осуществление декомпозиции факторов качества в измеряемые
характеристики ПО;
3) определение нижнего уровня иерархии – уровень разработанных
правил и норм, которым должна удовлетворять ИС для того, чтобы
выполнялись факторы качества.
Тщательно проведенная методологическая оценка качества ИС в
соответствии с целями разработки ИС создает основу для корректного
планирования и контроля затрат на качество для достижения требуемых
показателей и эффективности работы ИС. Затраты на оценку качества ИС
включают оплату труда специалистов собственной организации.
Результаты этапа включают:
1) определение характеристик качества;
2) стоимость затрат на оценку качества ИС.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в таблице 18.
Таблица 18. Стоимость информационной системы на этапе «Определение
характеристик качества информационной системы»
№ Компоненты затрат
Стоимость
Стоимость
Стоимость
п\п
работ
работ
учебных
сторонних
собственного курсов
и
43
организаций персонала
сертификации
Определение
количественных
характеристик качества
ИС
2
Определение
качественных
характеристик качества
ИС
3
Определение
внутренних и внешних
характеристик качества
ИС
4
Оценка качества ИС
Итого:
Итого по этапу:
1
6.7 Вычисление стоимости информационной системы
Цель - оценка общей стоимости проекта по разработке ИС, охват
поставок программного и аппаратного обеспечения и Структурного
разбиения работ.
В общую стоимость ИС входят:
1) капитальные затраты;
2) операционные расходы.
6.7.1 Капитальные затраты
Капитальные затраты - расходы на приобретение новых и замещение
старых долгосрочных материальных и нематериальных активов,
используемых в процессе создания ИС.
К капитальным затратам относится стоимость поставок:
1) аппаратного обеспечения:
- стоимость оборудования (полная стоимость оборудования без
учета амортизации);
- амортизационные расходы (амортизационный срок берется в
зависимости от типа техники);
- апгрейд (включает все обновления и изменения в аппаратной
конфигурации, такие как: замена жестких дисков, установка дополнительных
устройств. В отдельную подкатегорию сведены процессорные апгрейды);
- память (расходы на увеличение объема памяти как клиентских
мест, так и остальных устройств, содержащих модули памяти);
44
- устройства хранения информации (дисководы, жесткие диски,
карты памяти, носители, оптические приводы, системы хранения, стримеры,
устройства хранения данных, флеш–накопители);
- периферия (принтеры, сканеры, плоттеры и т. д.);
- сетевое оборудование (концентраторы, коммутаторы, сетевые
карты (кроме встроенных в клиентские компьютеры), маршрутизаторы,
мосты и т. д.);
2) ПО:
- операционные системы;
- стоимость лицензий;
- приложения (включает в себя кроме стандартных офисных
приложений еще и специализированное ПО, как разработанное самой
компанией, так и произведенное третьими организациями);
- обслуживающие программы (диагностические, отладочные,
программы–дефрагментаторы, криптографические, антивирусные и прочие);
- программы для коммуникаций: различные браузеры, протоколы
передачи файлов FTP, почтовые программы, средства удаленного доступа и
пр.
- определение стоимости транспортных расходов, имеющих
отношение к ИС.
6.7.2 Операционные расходы
Операционные расходы - затраты и платежи, связанные с
проведением
за
определенный
период
времени
финансовых,
производственных, хозяйственных операций, связанных с процессом
поддержки ИС. Операционные расходы включают затраты на производство и
реализацию продукции и/или предоставление услуг, административные и
финансовые расходы.
К операционным расходам относятся:
1) платежи - оплата арендованного аппаратного и программного
обеспечения и прочие расходы на компьютерное оборудование, не
подпадающие ни под одну из перечисленных категорий;
2) управление:
- управление сетью;
- диагностирование и ремонт;
- управление и планирование трафика;
- оптимизация производительности (выполняется системным
администратором и включает в себя выявление узких мест в сети и принятие
соответствующих мер);
- администрирование пользователей (добавление, удаление,
изменение прав);
- поддержка операционных систем;
- текущие регламентные работы (профилактика);
45
- прочие работы по управлению сетью;
3) управление системой:
- изучение и планирование развития системы;
- определение стоимости и закупка оборудования;
- лицензирование и дистрибуция программного обеспечения;
- управление имуществом (оборудованием);
- управление приложениями;
- контроль за секретностью и защита от вирусов;
- конфигурирование и перенастройка оборудования;
- установка оборудования;
- прочие вопросы управления системой;
- управление устройствами хранения данных;
- управление дисками и файлами;
- планирование емкости устройств хранения данных;
- управление доступом к данным;
- архивирование и резервное копирование;
- прогнозирование неисправностей и восстановление;
- управление репозиторием;
- остальные виды управления;
4) поддержка:
- оперативная работа;
- помощь административного персонала;
- нерегулярное обучение (административный состав);
- поддержка производителя;
- поддержка, осуществляемая сторонними организациями
(аутсорсинг);
- обучение административного персонала;
- обучение конечного пользователя;
- затраты на передвижения;
- закупки;
- прочие расходы на оперативную работу;
- контракты на поставку;
- контракты на поддержку;
- учебные курсы и сертификация;
5) определение профессионального уровня и заработной платы
персонала.
Результаты этапа включают:
1) стоимость поставок программного и аппаратного обеспечения;
2) определение стоимости категорий Структурного разбиения работ;
3) общая оценочная стоимость ИС.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в таблице 19.
Таблица 19. Стоимость информационной системы на этапе «Вычисление
46
стоимости информационной системы»
№ Компоненты затрат
Стоимость
Стоимость
п\п
работ
работ
сторонних
собственного
организаций персонала
1
Оценка
общей
стоимости проекта по
разработке ИС
2
Выполнение
текущих
регламентных работ
3
Изучение
и
планирование развития
ИС
4
Административные
расходы, связанные с
вычислением стоимости
ИС
Итого:
Итого по этапу:
Стоимость
учебных
курсов
и
сертификации
6.8 Определение влияния рисков
Целью данного этапа является определение рисков проекта, для
оценки их влияния на стоимость разработки.
6.8.1 Оценка влияния рисков на стоимость информационной
системы
Риски оцениваются следующим образом:
1) основываясь на начальном списке рисков (см. пункт 6.4.1)
идентифицировать основной риск, который оказывает наибольшее влияние
на оценку ИС;
2) оценить общее влияние рисков (см. таблицы 20 и 21). Общее
влияние рисков получается путем умножения величин оценки влияния
рисков на стоимость всех причин риска. Оценка влияния рисков на
стоимость приведена в таблице 21;
Таблица 20. Оценка причин рисков
Виды рисков
Оценка причин рисков
Уменьшает риск
Увеличивает риск
Опыт и навыки Опыт
участия
в Отсутствие
опыта
работы в команде разработке ПО;
разработке ПО;
Опыт планирования и Отсутствие
опыта
в
в
47
Виды рисков
Планирование
Проектирование
Кадровое
обеспечение
Оценка причин рисков
Уменьшает риск
Увеличивает риск
опыт принятия решений; планировании;
Интегрирование
Аппаратное и программное
аппаратного
и обеспечение группы не
программного
интегрированы
обеспечения групп
Детализированный
и Недостатки планирования;
пересмотренный план;
В планировании проекта
Достаточно времени для принимали участие не все
разработки
всех заинтересованные стороны;
ключевых
модулей Упрощенный подход к
проекта;
распределению резервов;
Соответствующее
Оптимистические,
назначение резервов;
непроверенные
Наследование ПО явно предположения,
основано на анализе
касающиеся наследования
ПО
Цельная системная и Системная и программная
программная
архитектура с неясным
архитектуры, а так же описанием
основ
ясные
правила, функционального
разделяющие систему на разделения аппаратного и
модули;
программного обеспечения;
Интегрированные
Системные
решения
системные
решения приняты без учёта влияния
основываются как на на ПО;
аппаратном
Предположение,
что
обеспечении, так и на изменение и развитие ПО
ПО;
не
потребуются
до
Процесс разработки ПО окончания
жизненного
спроектирован с учётом цикла
дальнейшего
расширения
функциональности
Низкая
текучесть Высокая текучесть кадров;
кадров;
Плохая
комплектация
Своевременный набор персонала;
персонала
для Планирование
роспуска
48
Виды рисков
Оценка причин рисков
Уменьшает риск
Увеличивает риск
разработки ПО;
группы
разработчиков
Сохранение
перед
сборкой,
программной группы до тестированием
и
выпуска продукта
процедурой сдачи ПО в
эксплуатацию
Тестирование
Испытательные стенды Недостаточно
готовы
до
начала испытательных стендов или
разработки;
их отсутствие;
Отдельная
группа Планируется преобразовать
тестировщиков;
группу разработчиков в
Своевременная
группу тестировщиков по
разработка
плана окончании разработки;
тестирования
Отсутствие
плана
тестирования
Инструментальные Система
управления Отсутствующая
либо
средства
соответствует средствам ограниченная
тестирования
и совместимость
системы
требованиям проекта;
управления
и
Испытанные
средства инструментальных средств
проектирования
анализа тестирования;
Неподходящие
средства
проектирования
Таблица 21. Оценка влияния рисков на стоимость
Причины риска
Оценка влияния на стоимость
Высокое
Очень высокое
Наивысшее
Опыт и навыки
1,02
1.05
1.08
работы в команде
Планирование
1,10
1,17
1,25
Проектирование
1,05
1,13
1,2
Кадровое
1,02
1,05
1,13
обеспечение
Тестирование
1,05
1,08
1,15
Инструментальные
1,02
1,03
1,1
средства
Максимум
1,3
1,6
2,32
ожидаемое влияние
49
3) определить влияние рисков на стоимость ИС по формуле (12):
Влияние _ риска _ на _ стоимость  Стоимость _ ИС * Общее _ влияние _ рисков (12)
Вычисление стоимости ИС приведено в подразделе 6.7;
4) регулировать оценку риска путем добавления общего фактора
риска к стоимости по формуле (13):
n
Общее _ влияние _ рисков   Влияние i   Вероятност ь _ случаяi 
(13),
i 1
где
- Влияние – влияние рисков на стоимость ИС.
- Вероятность случая определяется опытным путем, для этого
используется статистический подход, помогающий изменять априорные
оценки с учетом данных новых исследований.
6.8.2
Влияние
информационной
функционирование информационной системы
безопасности
на
Для минимизации влияния рисков функционирования ИС необходимо
соблюдение и контроль требований по обеспечению информационной
безопасности ИС.
К требованиям по обеспечению информационной безопасности ИС
относятся:
1) планирование обеспечения информационной безопасности - план
обеспечения безопасности и правила поведения сотрудников;
2) реагирование на инциденты нарушения информационной
безопасности;
3) действия по обеспечению информационной безопасности в
непредвиденных ситуациях – план действий в непредвиденных ситуациях,
резервирование телекоммуникационных сервисов, резервное копирование и
хранение информации, восстановление данных;
4) требования к оцениванию рисков и уязвимостей;
5) требования к защите носителей информации - маркировка,
хранение, транспортировка, очистка, передача и уничтожение носителей
информации;
6) требования к обеспечению целостности информации;
7) требования к физической защите ИС;
8) требования к безопасности эксплуатирующего персонала, а также
к его информированию и обучению вопросам безопасности;
9) требования идентификации и аутентификации;
10) требования к управлению доступом.
Обеспечение информационной безопасности включает затраты на
аппаратные и программные средства защиты, затраты на оплату труда
50
специалистов информационной безопасности как сторонних организаций, так
и собственного персонала.
Результаты этапа включают:
1) подробный список рисков ИС;
2) определение требований по обеспечению информационной
безопасности;
3) переоцененные характеристики: размер, объем, план работ,
проектная стоимость с учетом рисков.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в таблице 22.
Таблица 22. Стоимость информационной системы на этапе «Определение
влияния рисков»
№ Компоненты затрат
Стоимость
Стоимость
Стоимость
п\п
работ
работ
учебных
сторонних
собственного курсов
и
организаций персонала
сертификации
1
Оценка влияния рисков
на стоимость
2
Регулирование оценки
риска
3
Регулирование
затрат,
основанных на оценке
риска
4
Административные
расходы, связанные с
определением влияния
риска на стоимость
5
Обеспечение
информационной
безопасности
Итого:
Итого по этапу:
6.9 Подтверждение и корректировка оценки стоимости рисков
Целью этапа является подтверждение и корректировка оценки
стоимости рисков.
Первоначальный список рисков (см. пункт 6.4.1) дополняется списком
рисков, используя:
1) альтернативную оценку: привлечение человека или группы с
соответствующим опытом для независимой экспертной оценки;
2) исторические аналогии: используя предыдущий опыт, следует
сравнить оценку по следующим параметрам:
51
- размер, объем работ и стоимость аналогичного ПО;
- отношение размера к назначению ПО;
- отношение размера к объёму работ, и стоимости (продуктивность
разработки);
- отношения технологии примененной при разработке к объему
работ и цене.
Для выполнения данной задачи необходимо сравнить первоначальный
список рисков (см. пункт 6.4.1) с дополнительными рисками, полученными в
предыдущем пункте, определить разницу, и составить новый список рисков
для получения более точных показателей.
В дальнейшем необходимы управление и корректировка полученного
списка рисков.
Реализация процесса управления рисками включает:
1) оценку рисков в течение всего жизненного цикла ИС;
2) определение и классификацию рисков;
3) количественное определение неблагоприятных воздействий
рисков;
4) определение мер по предотвращению рисков;
5) определение стратегии управления каждым выявленным риском;
6) составление отчетности о рисках и их состоянии.
Результаты этапа:
1) подтверждение правильности оценки;
2) подтвержденные и скорректированные: объем работ, сроки
выполнения, сметные затраты полученные с повышенной точностью.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в таблице 23.
Таблица 23. Стоимость информационной системы на этапе «Подтверждение
и корректировка оценки стоимости рисков»
№ Компоненты затрат Стоимость
Стоимость
Стоимость
п\п
работ
работ
учебных
сторонних
собственного курсов
и
организаций
персонала
сертификации
1
Оценка
рисков
независимой
экспертной группой
2
Анализ
статистических
данных в данной
области
3
Сравнение
оценок
рисков
4
Регулирование оценки
рисков
52
Административные
расходы, связанные с
подтверждением
и
корректировкой
оценки
стоимости
рисков
Итого:
Итого по этапу:
5
6.10 Внедрение информационной системы
Цель этапа состоит в:
1) повышении производительности труда персонала;
2) снижении трудоемкости конкретных процессов за счет единого
информационного пространства;
3) уменьшении ошибок за счет расширения возможностей анализа и
проверок информации в ИС.
Этап внедрения начинается со следующего:
1) получение разрешения на установку ИС в местах ее
функционирования;
2) подготовка инфраструктуры пользователя и оборудования
помещений, в которых будет осуществляться функционирование ИС;
3) проверка работоспособности ИС в реальных условиях
эксплуатации;
4) организация обучения персонала работе с ИС или ее
компонентами.
Задачи внедрения ИС являются комплексными, так как их решение
предполагает проведение целого ряда мероприятий, к числу которых
относятся следующие:
1) концентрация людских и финансовых ресурсов для решения
задачи внедрения ИС;
2) разработка концепции создания единой ИС;
3) обучение пользователей;
4) обучение администраторов и узконаправленных специалистов;
5) адаптация ИС к специфике процессов в организации;
6) реализация пилотного проекта ИС;
7) разработка нормативной базы для работы в новых технологиях;
8) полномасштабное внедрение ИС в практику работы организации.
Для выполнения задач внедрения ИС необходимо составление плана
внедрения ИС.
Стандартный план внедрения ИС включает в себя следующие этапы:
1) планирование внедрения – назначение менеджера проекта,
обеспечение информированности сотрудников, подбор сотрудников в группу
внедрения ИС;
53
2) установка системы - установка, тестирование и проверка
корректности настройки ИС;
3) запуск пилотного проекта – обучение пользователей, перевод
пользователей на новую ИС, сбор отзывов пользователей и доработка ИС в
случае необходимости, назначение группы лиц, ответственных за
сопровождение ИС (менеджер процесса внедрения);
4) полномасштабное внедрение ИС в работу организации.
Результаты этапа включают:
1) обучение пользователей;
2) разработка документации по внедрению;
3) реализация пилотного проекта ИС, а затем полномасштабное
внедрение ИС.
На данном этапе в стоимость ИС будут включены компоненты затрат,
указанные в таблице 24.
Таблица 24. Стоимость информационной системы на этапе «Внедрения
информационной системы»
№ Компоненты затрат
Стоимость
Стоимость работ
п\п
работ
собственного
сторонних
персонала
организаций
1
Разработка плана внедрения
2
Обучение пользователей
Установка ИС
Адаптация ИС к специфике
процессов организации
5
Реализация пилотного проекта
ИС
6
Реализация полномасштабного
внедрения ИС
Итого:
Итого по этапу:
3
4
Общая стоимость информационной
представлена в таблице 25.
системы
на
всех
этапах
Таблица 25. Общая стоимость информационной системы
Название этапа
Стоимость
№
этапа
1
Сбор и анализ требований к ИС
2
Определение структурных единиц и стоимости
54
поставок программного и аппаратного обеспечения
3
Оценка размера программной части ИС
4
Оценка объема работ
5
Трудозатраты на кодирование и тестирование
6
Определение характеристик качества ИС
7
Вычисление стоимости ИС
8
Определение влияния рисков
9
Подтверждение и корректировка оценки стоимости
рисков
10
Внедрение ИС
Итоговая стоимость ИС:
7 Методология анализа стоимости, бюджета и сроков выполнения
работ в ходе долгосрочного проекта
7.1 Пересмотр стоимости, бюджета и сроков выполнения работ в
ходе долгосрочного проекта
Цель - проверка согласованной стоимости, бюджета проекта и сроков
выполнения работ для определения различий.
Необходимо выполнение следующих действий:
1) определяются границы бюджета ИС в процентном соотношении
по формуле (14):
Границы _ бюджета 
Сметные _ затраты  Проектная _ стоимость _ ИС
*100%
Сметные _ затраты
(14)
Аналогично рассчитываются границы сроков выполнения работ;
2) сравниваются проектная стоимость, сроки выполнения работ и
границы бюджета проекта для определения их согласованности;
3) если оценка существенно превышает запланированные величины,
то следует определить и устранить различия. Для этого следует:
максимально
детализировать
требуемые
границы
и
функциональность, анализируя и определяя приоритеты функций, для того,
что идентифицировать функции, которые могут быть устранены. Следует
принимать во внимание зависимость между функциями;
- прекратить поставки, в которых нет необходимости;
- проверить сроки выполнения работ, сметную стоимость и риски,
влияющие на базовую стоимость. Уменьшить риск и издержки за счет
уменьшения функциональности или объема поставок;
- повторить данный процесс, пока функциональность и поставки
не войдут в допустимые пределы, по отношению к бюджету и срокам
55
выполнения работ;
- согласовать уменьшение функциональности, снижение объема
поставок и соответственно пересмотренные затраты для достижения
соглашения. Скорректировать Структурное разбиение работ согласно
пересмотренной функциональности.
7.2 Документация и отчетность произведенной оценки стоимости
информационной системы
Цель - проверить точность оценки стоимости ИС и обеспечить
аналогичное оценивание для будущих программных проектов.
В процессе жизненного цикла ИС с каждым бизнес–процессом
связана документация, которая либо подается на вход, либо получается на
выходе данного процесса.
Следует проанализировать оценку для определения сроков и причин,
по которым проект может выйти за границы запланированных затрат,
вследствие чего необходимо:
1) изменить документацию в процессе определения стоимости ИС.
Документация - это результат записи информации, полученной в ходе
действий или процессов жизненного цикла программной системы;
2) для улучшения показателей оценки и планирования
скорректировать оценку на каждом этапе.
Необходимо задокументировать следующую информацию:
1) опорную информацию о проекте:
- название проекта;
- организация разработчик;
- платформа;
- язык программирования;
- метод оценок;
- дата утверждения стоимости проекта;
2) оцененный и фактический размер, объем работ, стоимость
аппаратного и программного обеспечения;
3) запланированные и фактические даты основных этапов;
4) идентифицировать риски и их предполагаемое и фактическое
влияние.
В процессе проектирования, разработки и внедрения ИС составляется
следующая документация в соответствии с RT 38370656-002:2006:
1) план руководства проектом;
2) календарный план реализации проекта;
3) концепция ИС;
4) бизнес — предложение;
5) техническое задание;
6) технический проект;
7) инструкция по эксплуатации ИС;
56
8) руководство администратора;
9) план тестирования;
10) протокол тестирования;
11) акт передачи в опытную эксплуатацию;
12) акт о завершении разработки;
13) календарный план процесса перехода;
14) акт передачи в эксплуатацию;
15) акт ввода в эксплуатацию;
16) предложение о модификации;
17) сообщение о проблеме;
18) журнал регистрации обращений.
Документация содержит справочные сведения о проекте ИС и
контрактов, заключенных в процессе проектирования, разработки и
внедрения.
57
Приложение 1
Альтернативные методы оценки программной части
информационной системы
В качестве методов оценки программной части ИС можно применять:
Метод Аналогии - применяется при многократном использовании
или для модифицируемых функций. Метод аналогии широко используется
как модель – аналог объекта, изучаемого посредством моделирования.
Применяется аналогия экспертного решения или аналогия исторических
данных. Экспертное решение основано на опыте с аналогичной функцией,
тогда как аналогия исторических данных на прошлых проектах, сходстве и
различиях в функциональных требованиях.
Статистический Метод (PERT). Применяется для аналогичных или
новых функций, где опыт и исторические данные ограничены, или для
проектов с неопределенными или неполными требованиями. Оценка
программной части ИС происходит следующим образом:
1) первый независимый эксперт определяет минимально возможный
размер программной части ИС (Least);
2) второй независимый эксперт определяет максимальный возможный
размер программной части ИС (Most);
3) третий независимый эксперт, используя, в том числе и исторические
данные, определяет наиболее вероятный размер программной части ИС
(Likely);
4) вычисляется размер программной части ИС (Mean):
Mean = (Least + 4*Likely + Most)/6.
Этот метод компенсируется тем, что оценивание устремляется к более
низкому пределу, чем к верхнему пределу.
Если размер оценивания основан на исторических базах данных,
использовавших физические строки кода или аналогии в проектах, следует
преобразовать физические строки кодовой оценки размера в логические
строки, используя Таблицу 1.1.
Таблица 1.1. Преобразование размера оценивания
Язык программирования
Логические SLOC
Assembler и Fortran
Физические SLOC = Логические
SLOC
Языки программирования третьего Уменьшение физических SLOC на
поколения
25%
(C, Cobol, Pascal, Ada 83)
Языки программирования четвертого Уменьшение физических SLOC на
поколения
40%
(SQL, Perl, Oracle)
58
Язык программирования
Логические SLOC
Объектно–ориентированные
языки Уменьшение физических SLOC на
программирования
30%
(Ada 95, C++, Java, Python)
Производительность разработки автогенерированного кода намного
выше, чем производительность разработки другого кода, и это должно
учитываться при преобразовании. Для преобразования автогенерированного
кода в логические SLOC необходимо использовать таблицу 1.2.
Таблица 1.2. Таблица преобразования автогенерированного кода в
логические SLOC
Язык
Преобразование автогенерированного кода в
программирования
логические SLOC по:
Least
Likely
Most
Второго поколения
1
Третьего поколения
0,22
0,25
0,4
Четвертого
0,04
0,06
0,13
поколения
Объектно–
0,09
0,17
ориентированные
59
Скачать