Разработка, стандартизация и сертификация программных средств и информационных технологий и систем: Учебное пособие

Федеральное агентство по образованию Тверской государственный технический университет

С.Л. Котов, Б.В. Палюх, С.Л. Федченко

РАЗРАБОТКА, СТАНДАРТИЗАЦИЯ И СЕРТИФИКАЦИЯ ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И СИСТЕМ Учебное пособие Издание первое Допущено Учебно-методическим объединением по образованию в области прикладной информатики в качестве учебного пособия для студентов высших учебных заведений, обучающихся по специальности «Прикладная информатика (по областям)» и другим экономическим специальностям

Тверь 2006

УКД 681.3: 658.1 (075.8) ББК 32.965.7 Я7 Котов С.Л., Палюх Б.В., Федченко С.Л. Разработка, стандартизация и сертификация программных средств и информационных технологий и систем: Учеб. пособие. 1-е изд. Тверь: ТГТУ, 2006. 104 с. Содержится основной материал по дисциплинам «Разработка и стандартизация программных средств и информационных технологий» и «Сертификация информационных систем» для специальностей «Прикладная информатика (в экономике)» и «Информационные системы и технологии». Поскольку первая дисциплина изучается вначале, учебное пособие начинается с краткой характеристики программных средств как объекта разработки и стандартизации. Затем излагаются основные понятия и положения технологии разработки программных средств, позволяющие систематизированно представить вопросы нормирования и стандартизации жизненного цикла программной продукции, оценки техникоэкономических показателей её разработки и эффективности соответствующих технологий проектирования. Вопросам сертификации информационных систем посвящена отдельная глава, в которой рассматриваются основные положения закона «О техническом регулировании» № 184 от 18.12.02 и особенности сертификации программных средств. В отдельную главу выделены также методики оценки технико-экономических показателей, учитываемых при разработке и сертификации программных средств и информационных систем. Завершается учебное пособие методическими указаниями к лабораторному практикуму по решению задач оценки и прогнозирования наиболее важных технико-экономических показателей. Предназначено для студентов, магистрантов и аспирантов, обучающихся по соответствующим дисциплинам и специальностям. Рецензенты: заместитель директора ФГУП «Государственный испытательный сертификационный центр программных средств и вычислительной техники», кандидат технических наук, доцент Ю.В. Гибин; заместитель директора ФГУП «Межотраслевой центр эргономических исследований и разработок», кандидат технических наук, старший научный сотрудник, эксперт по сертификации систем качества Г.Н. Фролов.

ISBN 5-7995-0317-1

© Тверской государственный технический университет, 2006

3 ВВЕДЕНИЕ Быстрое развитие информационных технологий (ИТ) и расширение сферы их применения в последние годы привели к резкому росту разработок программного обеспечения (ПО). В стоимостном исчислении ПО и информационные услуги составляют более половины объёма рынка всех продуктов информационных технологий. На российском рынке программных средств (ПС) заметно определённое завоевание отечественными производителями таких направлений, как бухгалтерские системы, системы распознавания текстов, различные корпоративные и управленческие программы, а также системы распределённой обработки данных [2, 3]. Характеризуя общие тенденции в области информатизации, следует отметить высокую динамичность изменений технических и потребительских свойств ИТ и средств их реализации. В настоящее время срок смены поколений аппаратных и программных средств составляет 3 – 4 года, что предъявляет высокие требования к срокам и качеству их разработки, особенно ПС. Опыт организации работ на всех фазах жизненного цикла ПС показывает, что это сложная, трудоёмкая и длительная работа, требующая высокой квалификации специалистов и новых подходов к проектированию на основе широкого использования методов программной индустрии, стандартизации и сертификации [4, 5, 6]. Чрезвычайно важными показателями для разработчиков и пользователей программной продукции являются трудоёмкость изготовления и сопровождения ПС, а также стоимостные показатели и уровень качества программной продукции. Поэтому этим вопросам в учебном пособии уделено особенное внимание. 1. КРАТКАЯ ХАРАКТЕРИСТИКА ПРОГРАММНЫХ СРЕДСТВ КАК ОБЪЕКТА РАЗРАБОТКИ И СТАНДАРТИЗАЦИИ 1.1. Технические особенности разработки программных средств. Принципы модульности и адаптируемости Рост объёмов и сложности ПС и баз данных (БД) информационных систем (ИС), а также требований к их качеству привели к созданию программной индустрии с большими коллективами специалистов и применению технологий автоматизированного проектирования и сопровождения, базирующихся на стандартах и нормативных документах. Комплекс таких документов должен регламентировать технологические процессы и объекты проектирования комплексов программ на всех этапах их жизненного цикла (ЖЦ). Жизненный цикл ПС – это непрерывный процесс с момента принятия решения о необходимости использования ПС до его полного изъятия из

4 эксплуатации. Модель ЖЦ ПС представляет собой структуру, состоящую из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение, то есть всю жизнь ПС: от установления требований к нему до снятия с эксплуатации [2]. Структура ЖЦ ПС базируется на трёх группах процессов: 1) основные (приобретение, поставка, разработка, эксплуатация, сопровождение); 2) вспомогательные, обеспечивающие выполнение основных (документирование, конфигурационное управление, обеспечение качества, верификация, аттестация, оценка, аудит); 3) организационные (управление проектами, создание инфраструктуры проекта, определение, оценка и совершенствование ЖЦ ПС, обучение). При этом особое внимание уделяется качеству документации, которое во многом определяет конкурентоспособность программ и БД [1, 4]. При создании сложных ПС и обеспечении их ЖЦ надо сделать выборку нужных стандартов, то есть сформировать весь комплект документов (профиль), обеспечивающий регламентирование всех этапов и работ. Это позволяет строить комплексы ПС из крупных функциональных модулей, отвечающих требованиям стандартов профиля, и применять отработанные проектные решения и методы, обеспечивающие повторное использование компонентов ПС и БД на иных аппаратных и операционных платформах, то есть эффективно решать проблему мобильности и адаптируемости ПС и БД на основе CASE-технологий. Для этого применяют стандартизацию структуры ПС и их интерфейсов с операционной и внешней средой и фиксируют показатели качества ПС, которые не должны снижаться при переносе программ на другие платформы [2, 6, 9]. 1.2. Экономические особенности разработки программных средств Высокая стоимость и большие ресурсы, используемые при создании сложных ПС и БД, привели к необходимости детального техникоэкономического анализа и обоснования проектов ИС до начала их осуществления [2, 12, 15]. Поэтому в данной дисциплине большое внимание уделено анализу ПС и методикам оценки трудоёмкости их разработки и сопровождения. Создание ПС и БД не завершается после первичных испытаний и сертификации 1-й версии, и длительное время они развиваются и модифицируются в серию версий в ходе сопровождения разработки и эксплуатации ПС. Программы и данные в ИС являются наиболее гибкими компонентами, подверженными изменению в течение всего их жизненного

5 цикла. Поэтому они должны контролироваться и упорядочиваться участниками проекта. Для координации их действий применяют специальные методы, методики и средства автоматизации конфигурационного управления [4]. Они позволяют на основе отслеживания динамики изменения ПС и БД представить специалистам и руководителям состояние проекта и его компонентов в любой момент времени и не допускать хаоса при модификации программ и данных. Процессы документирования и конфигурационного управления играют стабилизирующую роль во всём ЖЦ ПС [1, 4]. Поэтому они располагаются на первых позициях в стандартах и обеспечивают отражение состояния и динамики проектов. Их строгое выполнение определяет техникоэкономические показатели (ТЭП) проекта, его качество, длительность применения и конкурентоспособность ПС и ИС в целом. Освоение основ экономики создания и применения ИС и их компонентов позволяет рационализировать капиталовложения в средства автоматизации, прогнозировать затраты и длительность разработки систем, научно планировать создание крупных ПС и БД. Так как их разработка требует больших затрат и происходит в условиях ограниченных ресурсов, надо осуществлять баланс между достигаемым их качеством и ресурсами для их реализации, поддерживая его на всём ЖЦ. При этом особенно остро стоит задача борьбы с ростом ошибок в сложных ПС и БД, угрожающим безопасности и надёжности ИС [10]. Для их сокращения применяют типизацию проектов ИС в определённых проблемно ориентированных областях, сборочное программирование, процессы, средства и стандарты управления конфигурацией и качеством ПС и БД. 1.3. Вопросы оценки трудоёмкости разработки программных средств в свете требований стандартизации Современный подход к оценке трудоёмкости разработки ПС состоит в учёте особенностей ЖЦ ПС на различных этапах и влияния технологических факторов не только на трудозатраты, но и на уровень качества, надёжность и экономические показатели ПС [2, 7, 10]. Разработка ПС является важнейшим элементом основных процессов ЖЦ и состоит из следующих работ и задач, сгруппированных в 5 групп (этапов) [7]: 1. Анализ разработки: а) подготовка процесса: определение или выбор модели жизненного цикла ПС; документальное оформление выходных результатов в соответствии с процессом документирования; выполнение вспомогательных процессов в соответствии с условиями договора;

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

7 разработка технического проекта базы данных; уточнение документации пользователя; определение и документальное оформление требований к испытаниям и программе испытаний программных модулей; оценка технического проекта и требований к тестированию, документальное оформление оценки. 3. Программирование: а) программирование и тестирование компонентов ПС: разработка и документальное оформление каждого программного модуля и базы данных; разработка и документальное оформление процедур испытаний и данных для тестирования каждого программного модуля и базы данных; тестирование каждого программного модуля и базы данных; уточнение документации пользователя; уточнение программы сборки ПС; оценка запрограммированных элементов программного объекта и документальное оформление оценки; б) сборка ПС: разработка плана сборки и тестирования, документальное оформление плана; сборка и тестирование программных модулей и компонентов, документальное оформление результатов; подготовка к квалификационным испытаниям: разработка и документальное оформление наборов тестов, контрольных примеров, процедур испытаний; оценка и документальное оформление оценки плана сборки, проекта, запрограммированного программного объекта, проведенных испытаний, результатов тестирования, документации пользователя. 4. Квалификационные испытания (тестирование) ПС: проведение квалификационных испытаний на соответствие квалификационным требованиям к программному объекту; уточнение документации пользователя (при необходимости); проведение аудиторской проверки и документальное оформление результатов; доработка программного продукта по результатам аудиторской проверки (при необходимости); подготовка ПС к вводу в действие. 5. Внедрение ПС: а) ввод в действие ПС: разработка и документальное оформление плана ввода в действие программного продукта в среде эксплуатации, определенной в договоре; ввод в действие программного продукта в соответствии с планом и условиями договора; документальное оформление работ;

8 б) обеспечение приемки ПС: обеспечение проведения заказчиком оценки готовности к приемке и приемочным испытаниям; документальное оформление результатов оценки готовности; поставка программного продукта заказчику; первоначальное и непрерывное обучение и поддержка персонала заказчика в соответствии с условиями договора. Вспомогательные процессы 1) Документирование – процесс формализованного описания информации, созданной в процессе или работе жизненного цикла. Данный процесс состоит из набора работ, при помощи которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают те документы, в которых нуждаются все заинтересованные лица. Данный процесс состоит из работ: подготовка процесса; проектирование и разработка; выпуск. 2) Обеспечение качества – процесс обеспечения соответствующих гарантий того, что программные продукты и процессы в жизненном цикле проекта соответствуют установленным требованиям и утвержденным планам. Обеспечение качества должно быть организационно и полномочно независимым от субъектов, непосредственно связанных с разработкой программного продукта. Данный процесс состоит из подготовки процесса; обеспечения продукта; обеспечения процесса; обеспечения систем качества. Организационные процессы 1) Управление – процесс, состоящий из общих работ и задач, которые могут быть использованы любой стороной, управляющей соответствующим процессом. Администратор отвечает за управление продуктом, проектом, работами и задачами соответствующего процесса, который состоит из подготовки и определения области управления; планирования; выполнения и контроля; проверки и оценки; завершения. 2) Создание инфраструктуры – процесс установления и обеспечения инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки. Этот процесс состоит из подготовки процесса; создания инфраструктуры; сопровождения инфраструктуры. 3) Усовершенствование – процесс установления, оценки, измерения, контроля и улучшения любого процесса жизненного цикла ПС. Процесс состоит из создания процесса; оценки процесса; усовершенствования процесса. 4) Обучение – процесс обеспечения первоначального и продолженного обучения персонала. Должно быть запланировано и заранее выполнено обучение персонала с целью готовности его к работам

9 по разработке программного проекта. Данный процесс состоит из подготовки процесса; разработки учебных материалов; реализация плана обучения. Методика оценки трудоёмкости должна охватывать все указанные выше работы процесса разработки ПС, а также вспомогательные и организационные процессы. 2. ОСНОВНЫЕ ПОНЯТИЯ И ПОЛОЖЕНИЯ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ 2.1. Проблемы и задачи проектирования программных средств ПС современных ИС являются типичными сложными системами со всеми их особенностями (наличие общей задачи и единой цели функционирования, иерархическая система связей, сложность поведения системы и др.), обуславливающими проблемы их проектирования. К ним относятся [2, 5]: 1) проблемы рационального структурного построения ПС, включающие: – оптимизацию структуры ПС по критерию максимального использования ресурсов ЭВМ; – контроль вычислительного процесса и обеспечение надёжности ПС; – обеспечение простой корректировки ПС и др.; 2) проблемы технологии разработки ПС, включающие: – разработку моделей алгоритмов и др. компонентов ИС; – автоматизацию программирования на основе унификации типовых компонент программ; – обеспечение отладки и испытаний программ; – автоматизацию изготовления документации и др.; 3) проблемы стандартизации и унификации ПС, включающие: – стандартизацию структуры и правил сопряжения программ по передаче управления и по обменной информации; – унификацию правил и методов построения ПС, общих правил иерархии и взаимодействия программ и методов организации вычислительного процесса; – стандартизацию методов и требований к обеспечению и измерению качества ПС; – стандартизацию языков программирования. 2.2. Этапы жизненного цикла программных средств По длительности ЖЦ ПС можно разделить на 2 класса [5]: а) с малым, б) большим временем жизни.

10 ПС с малым временем ЖЦ (до 3 лет) и объёмом 1 – 10 тысяч команд разрабатываются обычно в НИИ и вузах одним специалистом. ПС с большим временем ЖЦ (10 – 20 лет, из которых 70 – 90 % приходится на эксплуатацию и сопровождение), с объёмом 10 – 1000 команд разрабатываются большими коллективами специалистов и создаются на основе промышленного регламентированного проектирования. ЖЦ таких программ включает в себя этапы [2]: системный анализ, проектирование, эксплуатацию, сопровождение. Наиболее специфическим, трудноформализуемым и тесно связанным с функциональным назначением является этап системного анализа, на котором формируются назначение и основные показатели качества ПС. Этапы проектирования, эксплуатации и сопровождения сильно различаются целями, задачами, методами и средствами. Процесс эксплуатации идёт параллельно и независимо от этапа сопровождения и сводится к исполнению программ на ЭВМ и обеспечению достоверности и надёжности результатов. Этап сопровождения состоит в эксплуатационном обслуживании, развитии функциональных возможностей и характеристик ПС, а также в тиражировании ПС и переносе их на различные типы ЭВМ. Наиболее трудоёмким является этап проектирования, требующий методической, технологической, инструментальной и организационной поддержки [2, 5]. 2.3. Виды поддержки и стадии этапа проектирования Методическая поддержка включает в себя комплекс стандартов, инструкций и методик, определяющих правила создания программ и конкретизирующих языки проектирования, правила использования символов, структурного построения и другие методические основы процесса создания программ. Технологическая поддержка является детализацией документов методической поддержки, регламентирующей конкретную технологию обеспечения ЖЦ программ. Эти документы определяют допустимую трудоёмкость и длительность каждого этапа и обеспечивают нужное качество при допустимых затратах ресурсов. Инструментальная поддержка состоит из ПС и средств вычислительной техники, обеспечивающих автоматизацию создания ПС и определяющих её программную и аппаратную оснащённость. Процесс разработки ПС делится на стадии [5]: техническое проектирование и рабочее проектирование. Первая стадия включает этапы: структурное проектирование, подготовка технических средств, разработка программ. Вторая стадия включает этапы: завершение разработки программ,

11 отладка программ в статике, комплексная динамическая отладка программ, выпуск машинных носителей, испытания ПС. Все виды работ и задач, выполняемых на этих этапах, сгруппированы для оценки трудоёмкости разработки ПС в 5 групп [2]: анализ разработки, проектирование, программирование, тестирование, внедрение. Подробное рассмотрение состава и содержания работ в каждой группе приведено в соответствующей литературе [7], использованной при подготовке методических указаний к проведению лабораторных работ (подразделы 6.1, 6.2). Важное значение для успешного их проведения имеют результаты статического анализа. 2.4. Основные понятия и определения статического анализа программных средств Статический анализ (СА) – это процесс анализа исходного текста программы без её выполнения на ЭВМ [12]. СА программ проводится: – для проверки модульной структуры программного средства, а также логической структуры отдельных модулей и сравнения этих структур с приведенными в программной документации; – подготовки исходных данных для проведения динамического анализа ПС и разработки плана тестирования ПС; – оценки конструктивных характеристик программы, степени простоты модификации и сопровождения программы; – определения наличия несовершенства в программе, неиспользуемых участков программы, лишних переменных; – оценки текстовой сложности программы, затрат на ее разработку и освоение; – экспертизы идентичности программ при установлении авторства и разрешении правовых споров; – определения количественных характеристик при оценке уровня качества программы. Статический анализ начинается со стадии проектирования программы (укрупненный анализ) и продолжается на всех последующих фазах жизненного цикла программного средства. Статический анализ программного средства предусматривает получение следующих характеристик (графических и метрических): модульная структура ПС; логическая структура отдельного программного модуля; характеристика текста программы. Модульная структура анализируемого ПС представляется в виде графа вызовов; списка путей вызовов; матрицы вызовов и достижимости; точек вызовов; метрик иерархии вызовов.

12 Логическая структура отдельного программного модуля представляется в виде графа управления; путей тестирования; метрик структуры управления. Характеристики текста программ включают в себя: статистические данные о комментированности программы и текстовые метрики Холстеда. Граф вызовов – это ориентированный граф, в котором вершины – модули ПС, а рёбра ориентированы от вызывающего модуля к вызываемому. Граф управления −это ориентированный граф, вершинами которого являются логические блоки, а направленные ребра ориентированы в направлении передачи управления между блоками. Логический блок программы – это участок программы, состоящий из одного или нескольких операторов и не имеющий разветвлений. Матрица вызовов и достижимости – это матрица, характеризующая отношение вызова и достижимости между произвольными парами программных компонент (модулей). Путь вызовов – это последовательность соприкасающихся ребер из графа вызовов, где начальная вершина есть корень графа, а конечная − лист дерева. Путь тестирования – это маршрут в графе управления программного модуля, начальная вершина которого является входной вершиной графа, а конечная вершина − выходной вершиной графа. Точка вызовов – это местоположение вызова программной компоненты (модуля), задаваемое номером строки и столбца расположения оператора вызова. Кроме этого СА предусматривает определение ряда количественных характеристик, таких как иерархическая и структурная сложность, тестируемость и др. Иерархическая сложность: I = N / L, где N – количество вершин в графе вызовов модулей; L – количество уровней. Иерархическая сложность характеризует среднюю ширину уровня в графе вызовов, т.е. количество проектных решений, принимаемых на отдельном шаге разработки программы. Структурная сложность: S = D / N, где D – количество ребер в графе вызовов модулей; N – количество вершин. Тестируемость – это свойство ПС, заключающееся в их приспособленности к эффективному применению контрольных тестов, зависящей от степени разветвления вычислительного процесса и доступности модулей. Доступность узла (модуля) характеризует структурную вероятность вызова этого модуля, зависящую от разветвленности дерева вызовов. Если показатель тестируемости имеет малое значение, то затрудняется тестирование модулей нижних уровней иерархии, особенно при применении автоматизированных методов тестирования.

13 3. ЭФФЕКТИВНОСТЬ ТЕХНОЛОГИЙ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ 3.1. Критерии оценки технологий проектирования программных средств Эффективность (полезность) технологий характеризуется в основном трудоёмкостью и длительностью создания ПС, а также достигаемым качеством. Критерии оценки качества ПС и ТЭП позволяют осуществлять целевое управление их разработкой при применении конкретных технологий. В процессе разработки ТЗ выявляются основные показатели, устанавливается относительная важность каждого из них и строится обобщённая целевая функция требуемого качества, а также устанавливаются допустимые затраты и длительность разработки ПС, которые должны обеспечить соответствующие технологии. После завершения отладки и испытаний эти показатели и обобщённая функция уточняются на предмет их соответствия ТЗ. Различают функциональные и конструктивные критерии качества ПС. Первые отражают специфику применения и степень соответствия ПС их целевому назначению (номенклатуру исходных данных, достоверность результатов, разнообразие функций редактирования и т.д.). В ряде случаев их можно свести к показателям обобщённой экономической эффективности применения ПС в ЖЦ, характеризуемой величиной экономии труда, энергии, материалов и т.п. Вторые критерии оценивают сложность программ, надёжность функционирования, ресурсы ЭВМ, корректность программ и др. Особо следует выделить временные показатели ЖЦ программ (длительность проектирования, продолжительность эксплуатации и время проведения модификаций), которые в ряде случаев могут быть более важными, чем трудоёмкость. Поэтому для каждой разработки целесообразно проводить ранжирование критериев и влияющих характеристик на всех этапах ЖЦ. 3.2. Суть управления качеством программных средств Для управления качеством необходима формализация технологии проектирования, а также независимое измерение, контроль и анализ критериев качества ПС и влияющих на них факторов. Управление качеством ПС включает: анализ системных требований к ПС и ранжирование критериев качества, разработку методик и стандартов контроля выполнения правил модульно-иерархического построения ПС, создание методов и технологии поэтапного контроля выполнения заданных требований к качеству ПС,

14 применение средств инструментальной, технологической поддержки автоматизации программирования, отладки и испытаний, обеспечивающих создание ПС с заданными значениями критериев качества. Важнейшим для качества ПС является этап системного анализа и формирования ТЗ. При этом необходимо учитывать 2 типа ограничений: 1) ограничения знаний о методах решения задач, 2) ограничения ресурсов, доступных для реализации ПС. 3.3. Составляющие затрат в жизненном цикле программных средств Почти всегда критерии качества связаны с экономическим эффектом от применения ПС [10, 14, 15]. Его можно выразить доходом, повышением производительности труда или прибыли, снижением затрат, энергопотребления и др. экономическими показателями. Во многих случаях наиболее просто и обобщённо экономический эффект можно описать доходом Э от использования ПС в течение ЖЦ продолжительностью t: Э = Эид – C сум, где Эид – идеальная эффективность применения программ; C сум – суммарные потери и затраты, снижающие предельный доход. Это снижение происходит вследствие затрат на разработку Cр, сопровождение Cс, эксплуатацию Сэ и из-за потерь в результате недостаточной надёжности Сн. Тогда Э = Эид – Ср – Сс – Сэ – Сн. Динамику совершенствования программ характеризует величина экономической эффективности, отнесенная к общим затратам, при которых она достигнута, что позволяет ограничивать качество при больших затратах. 3.4. Основные факторы, влияющие на трудоёмкость разработки программных средств Качество и эффективность технологии определяется прежде всего затратами на разработку: Ср = С1р + С2р + С3р + С4р + С5р, где С1р – затраты, связанные с непосредственной разработкой ПС; С2р – затраты на изготовление опытного образца (5 – 10 %), часто не учитываемые из-за малости; С3р – затраты на программные средства автоматизации технологии; С4р – затраты на аппаратные средства автоматизации технологии (машинное время работы ЭВМ); С5р – затраты на повышение квалификации специалистов (часто не учитываются из-за малого значения и трудностей формализации, но рассматриваются как один из важных факторов, влияющих на величину С1р).

15 В результате можно считать, что для практических целей проведения анализа можно пользоваться формулой Cр = С1р + С3р + С4р. В этой сумме при создании средних и крупных ПС все три составляющие примерно равны, но основное внимание при анализе следует обращать на С1р, так как на неё наиболее сильно влияет объём разработки ПС. Приближённо можно считать, что затраты на разработку должны быть прямо пропорциональны объёму создаваемых ПС (Пк) при одной и той же производительности труда разработчиков, измеряемой числом созданных команд за один человеко-день труда. При этом учитывается труд не только программистов, но и разработчиков алгоритмов, системных аналитиков и обслуживающего персонала. 3.5. Длительность разработки программных средств Диапазон приемлемых длительностей разработок Tр ограничен сверху 10 годами (рациональными сроками создания самых сложных ИС), а снизу – 1 – 3,5 года (сроками естественного технологического процесса). Среднюю длительность разработки можно аппроксимировать зависимостью Тр = 0,8 Пк1/3, или Тр = 1,4 Пк¼ лет, где Пк – объём ПС в тысячах команд. 3.6. Распределение затрат по этапам разработки По опыту эксплуатации трудоёмкость отдельных этапов разработки различается в 2 – 4 раза, а загрузка отдельных категорий специалистов на них – в 3 – 5 раз. Это надо учитывать при планировании и организации проектирования ПС, а также при прогнозировании затрат на непосредственную разработку программ. Так же неравномерно в зависимости от этапов изменяется и потребность в машинном времени С4р, причём для разных ЭВМ (моделирующих, технологических, реализующих) эта потребность находится в широком диапазоне и является максимальной для этапа динамической отладки. Такие оценки затрат машинного времени позволяют рационально планировать и прогнозировать необходимую аппаратную оснащённость разработок по этапам и в целом на весь ЖЦ. Упорядоченный подход к организации проектирования сложных ПС с учётом вышеизложенного позволяет создавать ПС с высоким качеством и допустимыми затратами, если использовать современные технологии, методы и системы автоматизации проектирования, выбирая их на основе системного и техникоэкономического анализа достигаемого эффекта и ресурсов на весь ЖЦ.

16 4. ОБЩИЕ СВЕДЕНИЯ О СЕРТИФИКАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ И ИХ ПРОГРАММНЫХ СРЕДСТВ 4.1. Основные понятия и определения Сертификация – это деятельность определённого органа (организации), независимого (ой) от изготовителя (продавца) и потребителя продукции, по подтверждению её соответствия установленным требованиям технических регламентов, положениям стандартов или условиям договоров. Сертификация ИС предполагает удостоверение достигнутого качества и надёжность функционирования созданных ИС [11, 13]. С технической точки зрения, качество – это совокупность свойств продукции, обуславливающих её способность удовлетворять определённые потребности в соответствии с её назначением. Одним из важнейших компонентов ИС, определяющих ее качество, является программная продукция. Весь объём признаков и характеристик программной продукции, относящийся к её способности удовлетворять потребностям пользователей ИС, определяет качество программного обеспечения (ПО) ИС. Такие признаки и характеристики определяют свойства ПО, по которым его качество описывается и оценивается. К ним относятся: функциональные возможности, надёжность, практичность, эффективность, сопровождаемость, мобильность. Каждая из этих характеристик может быть уточнена на множестве уровней комплексных показателей (подхарактеристик), определяемых с учётом разрабатываемых для этих целей метрик качества. Метрика качества – это количественный масштаб (мера) и метод, которые могут быть использованы для определения значений признаков или характеристик конкретного ПО и последующей оценки уровня качества ИС. Уровень качества – это относительная характеристика, основанная на сравнении совокупности характеристик качества продукции с соответствующей совокупностью базовых характеристик, принимаемых за исходные (эталонные). Для осуществления такого сравнения используют ранжирование (действие по отнесению измеренного значения характеристики к соответствующему уровню ранжирования). Уровень ранжирования – это диапазон значений характеристики в масштабе, позволяющем классифицировать (ранжировать) ПО в соответствии с потребностями пользователей и принятыми критериями оценки качества ПО. Критерии оценки качества ПО – это набор определённых и задокументированных правил и условий, которые используются для решения о приемлемости общего качества конкретного ПО, принимаемого

17 в результате сертификации. При таком положительном решении выдаётся сертификат соответствия установленным требованиям. Кроме этого сертифицированная продукция маркируется знаком соответствия, зарегистрированным в установленном порядке по правилам соответствующей системы сертификации, относящейся к данной группе продукции. Орган, возглавляющий систему сертификации однородной продукции, называется центральным органом системы сертификации или центром по сертификации. В его подчинении находятся органы, проводящие сертификацию соответствия, и испытательные лаборатории, проводящие испытания определённой продукции. При объединении этих функций в одном юридическом лице используется термин «сертификационный центр». Эти органы подвергаются периодически аккредитации – процедуре официального признания (соответствующим уполномоченным органом) компетентности и возможности выполнения конкретных работ в заданной области. Взаимоотношения между участниками – разработчиками (продавцами), пользователями (покупателями) и органами сертификации и аккредитации, а также их права и обязанности регулируются Законом № 184-ФЗ от 27.12.02 «О техническом регулировании». Ниже рассматриваются отдельные главы, статьи и пункты данного закона, дающие наиболее полное представление об устанавливаемых этим законом нововведениях. 4.2. Основные положения закона «О техническом регулировании» (ТР) 4.2.1. Структура закона Закон состоит из 9 глав, которые включают в себя 48 статей: 1. Общие положения. 2.Технические регламенты (ТРегл). 3. Стандартизация. 4. Подтверждение соответствия. 5. Аккредитация органов по аккредитации. 6. Государственный контроль за соблюдением требований ТРегл. 7. Информация о нарушениях требований ТРегл и отзыв продукции. 8. Информация о ТРегл и документах по стандартизации. 9. Финансирование в области ТР. 4.2.2. Содержание закона ГЛАВА 1 Статья 1. Сфера применения Пункт 1. Закон регулирует отношения, возникающие при разработке, принятии, применении и исполнении:

18 а) обязательных требований к продукции, процессам производства, эксплуатации, хранения, перевозки, реализации и утилизации; б) требований на добровольной основе к продукции, процессам и другим объектам ТР, а также при оценке соответствия. Пункт 3. Действие закона не распространяется на государственные общеобразовательные стандарты, положения о бухучёте и правила (стандарты) аудиторской деятельности, стандарты эмиссии ценных бумаг и проспектов их эмиссии. Статья 2. Основные понятия Декларация о соответствии – документ, удостоверяющий соответствие продукции требованиям ТРегл. ТРегл – документ, принятый международным ратифицированным договором РФ или указом президента РФ (постановлением правительства РФ) и устанавливающий обязательные для применения и исполнения требования к объектам ТР. Статья 3. Принципы ТР: применение единых правил установления требований к объектам ТР; соответствие ТР уровню национальной экономики и научнотехнического развития; независимость органов по аккредитации и сертификации от субъектов – изготовителей, продавцов, исполнителей и приобретателей; недопустимость совмещения полномочий органа госконтроля (надзора) и органа сертификации, а также полномочий на сертификацию и аккредитацию. Статья 4. Законодательство РФ о ТР Федеральные органы исполнительной власти вправе создавать в сфере ТР акты только рекомендательного характера, за исключением случаев, определённых в статье 5. Статья 5. Особенности ТР в отношении оборонной продукции и продукции, сведения о которой составляют государственную тайну. В отношении такой продукции вышеуказанные акты могут носить обязательный характер. ГЛАВА 2 Статья 6. Цели принятия ТР: защита жизни или здоровья граждан; охрана окружающей среды, жизни животных и растений; предупреждение действий, вводящих в заблуждение приобретателей. Статья 7. Содержание и применение ТРегл Они должны содержать требования к характеристикам объектов ТР, но не должны содержать требования к конструкции и исполнению, если их отсутствие не противоречит целям принятия регламентов, изложенным в статье 6.

19 Регламент не может содержать требования к продукции, причиняющей вред жизни и здоровью граждан при длительном её использовании, а может только содержать требования к информированию приобретателя о вреде и факторах, от которых вред зависит. Статья 8. Виды ТРегл В РФ действуют общие ТРегл и специальные ТРегл. Требования общих регламентов обязательны для применения ко всем объектам ТР, а требованиями специальных регламентов учитываются технологические и иные особенности отдельных объектов ТР. Статья 9. Порядок разработки, принятия, изменения и отмены ТРегл Регламент принимается федеральным законом в установленном порядке с обязательной публикацией уведомления о разработке его проекта. Разработчик должен дорабатывать проект регламентов с учётом полученных замечаний заинтересованных лиц, проводить публичное обсуждение проекта и сохранять замечания до дня вступления в силу регламентов. Статья 10. Особый порядок разработки и принятия ТР В исключительных случаях, приводящих к непосредственной угрозе жизни, здоровью и т.п., президент РФ вправе издать регламент без его публичного обсуждения. ГЛАВА 3 Статья 11. Цели стандартизации: повышение уровня безопасности жизни или здоровья; повышение уровня безопасности объектов; обеспечение научно-технического прогресса; повышение конкурентоспособности продукции; рациональное использование ресурсов; техническая и информационная совместимость; сопоставимость результатов испытаний и статистических данных; взаимозаменяемость продукции. Статья 12. Принципы стандартизации: добровольное применение стандартов; максимальный учёт законных интересов заинтересованных лиц при разработке стандартов; применение международных стандартов как основы разработки национальных стандартов; недопустимость таких стандартов, которые противоречат ТРегл; обеспечение условий для единообразного применения стандартов. Статья 13. Документы в области стандартизации: национальные стандарты; правила стандартизации, нормы и рекомендации;

20 классификации, общероссийские классификаторы социальной и технико-экономической информации; стандарты организаций. ГЛАВА 4 Статья 18. Цели подтверждения соответствия: удостоверение соответствия продукции ТРегл, стандартам и условиям договоров; содействие приобретателям в выборе продукции и других объектов ТР; повышение конкурентоспособности на международном и российском рынках; создание условий для свободного перемещения товаров по РФ, а также для международного сотрудничества и торговли. Статья 19. Принципы подтверждения соответствия: доступность для заинтересованных лиц информации о порядке подтверждения соответствия; недопустимость применения обязательного подтверждения соответствия к объектам, для которых не установлены требования ТРегл; установление перечня форм и схем обязательного подтверждения соответствия определённых видов продукции ТРегл; недопустимость принуждения к добровольному подтверждению соответствия, в том числе в системе добровольной сертификации; недопустимость подмены обязательного подтверждения соответствия добровольной сертификацией. Статья 20. Формы подтверждения соответствия: подтверждение соответствия на территории РФ может носить добровольный или обязательный характер; добровольное подтверждение соответствия осуществляется в форме добровольной сертификации; обязательное подтверждение соответствия осуществляется в формах принятия декларации о соответствии и обязательной сертификации. Статья 21. Добровольное подтверждение соответствия: может осуществляться для установления соответствия национальным стандартам, стандартам организаций, системам добровольной сертификации и условиям договоров; объектами добровольного подтверждения соответствия являются объекты ТР, для которых стандартами, системами добровольной сертификации и договорами устанавливаются соответствующие требования. Орган по сертификации подтверждает соответствие объектов ТР; выдаёт сертификат соответствия; приостанавливает или прекращает действие выданных им сертификатов соответствия.

21 Статья 22. Знаки соответствия Маркировка осуществляется знаком соответствия системы добровольной сертификации в соответствии с порядком применения знака, установленным правилами системы добровольной сертификации. Статья 23. Обязательное подтверждение соответствия Оно проводится только в случаях, установленных соответствующим ТРегл, и исключительно на соответствие требованиям регламента. Объектом обязательного подтверждения соответствия может быть только продукция, выпускаемая на территории РФ. Декларация о соответствии и сертификат соответствия имеют равную юридическую силу. Статья 24. Декларирование соответствия Оно осуществляется по одной из схем: а) принятие декларации на основе собственных доказательств; б) принятие декларации на основе доказательств, полученных с участием органов по сертификации и (или) аккредитованной испытательной лаборатории (центра). В первом случае заявитель самостоятельно формирует доказательные материалы, а во втором – заявитель включает протоколы испытаний в испытательном центре и предоставляет сертификат качества, в отношении которого предусмотрен контроль (надзор) органа сертификации, выдавшего данный сертификат. Статья 25. Обязательная сертификация Она осуществляется на основании договора с заявителем. Соответствие продукции требованиям регламентов подтверждается сертификатом соответствия, включающим в себя: наименование и местонахождение заявителя, изготовителя продукции и органа, выдавшего сертификат; информацию об объекте сертификации, позволяющую идентифицировать объект; наименование ТРегл, на соответствие требованиям которого проводилась сертификация; информацию о проведенных испытаниях и документах заявителя, представленных в орган сертификации в качестве доказательств соответствия требованиям регламентов; срок действия сертификата. Статья 26. Организация обязательной сертификации Орган по сертификации: привлекает на договорной основе аккредитованные испытательные центры (лаборатории); осуществляет контроль объектов сертификации; ведёт реестр выданных им сертификатов;

22 информирует органы госконтроля за соблюдением требований ТРегл о продукции, поступившей на сертификацию, но не прошедшей её; приостанавливает или прекращает действие выданного им ранее сертификата. Статья 27. Знак обращения на рынке Используется для маркировки продукции, прошедшей подтверждение соответствия (в информационных целях) и осуществляется заявителем самостоятельно любым удобным для него способом. ГЛАВА 7 Статья 37. Информация о несоответствии продукции требованиям ТРегл Изготовитель (продавец), которому стало известно о несоответствии продукции, обязан сообщить об этом в орган госнадзора в течение 10 дней. Продавец, получивший такую информацию, обязан довести её в течение 10 дней до изготовителя. При получении такой информации органом госконтроля от других лиц последний должен известить об этом изготовителя (продавца) в течение 5 дней. ГЛАВА 9 Статья 46. Переходные положения До вступления в силу новых регламентов (в течение 7 лет) требования к объектам ТР устанавливаются нормативно-правовыми актами РФ и подлежат обязательному исполнению только в части, соответствующей целям: защиты жизни и здоровья граждан; охраны окружающей среды; предупреждения действий, вводящих в заблуждение приобретателя. Обязательное подтверждение соответствия осуществляется только в отношении отечественной продукции. Правительством РФ до вступления в силу ТРегл ежегодно дополняется перечень объектов ТР, в отношении которых обязательная сертификация заменяется добровольной. Обязательные требования к объектамТР, в отношении которых ТРегл в течение 7 лет не будут приняты, прекращают своё действие. Выданные сертификаты и документы об аккредитации до данного закона считаются действительными до окончания срока, указанного в них. 4.3. Особенности сертификации программного обеспечения Рекомендованные в [9] шесть характеристик качества ПО представляют основу для оценки и сертификации программ различных классов. При этом необходимо предварительно решить вопросы установления метрик, важности каждой характеристики, уровней ранжирования, критериев оценки и разработки моделей оценивания

23 применительно к конкретным условиям применения ПО в определённой организации. Важность каждой характеристики качества меняется в зависимости от класса ПО, а также от различных точек зрения на их важность со стороны пользователя, разработчика и руководителя. В соответствии с этим разработчиками могут использоваться различные метрики для одних и тех же характеристик ПО, потому что одни и те же метрики не применимы для всех фаз ЖЦ ПО. Так, если пользователя интересует только качество конечной продукции, то разработчики заинтересованы и в качестве промежуточных результатов на всех фазах ЖЦ, так как без этого конечный результат может быть не оптимальным или вовсе не отвечать заданным требованиям. Руководители более заинтересованы в общем качестве ПО, чем в конкретных характеристиках, и поэтому для них важнее вопросы сопоставления повышения качества с критериями управляемости, такими как плановая задержка или перерасход стоимости, так как для них основная задача состоит в оптимизации качества в пределах ограниченной стоимости, трудовых ресурсов и установленного времени [9]. Для шести вышеназванных характеристик качества ПО используют несколько достаточно апробированных метрик, но стандартами предусматривается возможность разработки организациями дополнительной номенклатуры характеристик и показателей, своих собственных моделей процесса оценивания и методов формирования метрик, связанных с этими характеристиками. Это делается для более широкого охвата различных областей применения ПО с определённой спецификой решаемых задач. Считается общепринятым, что наиболее объективным путём определения важности характеристик является путь проведения экспертных оценок на предмет выявления свойств, определяющих качество ПО конкретного применения, включая и те, которые не вошли в шесть обязательных характеристик [9], и упорядочение их по предпочтительности. Руководствуясь этим, в интересах оценки и сертификации ИС специального назначения одним из авторов при выполнении соответствующей НИР был проведен опрос, в основу которого была положена анкета с включённой в неё совокупностью характеристик (свойств), полученной в результате анализа требований к ПО данной ИС. Объективность опроса достигалась участием в нём 35 ведущих специалистов из 10 организаций заказчиков и разработчиков ИС, а также проверкой согласованности ответов экспертов и исключением крайне противоположных оценок. Результаты обработки такой информации с учётом некоторой корректировки названий свойств, в соответствии с рекомендациями [9] приведены в табл. 4.1.

24 Таблица 4.1 Характеристики свойств ПО Наименование свойств Коэффициент важности 0,35 Функциональные возможности 0,25 Надёжность 0,20 Сопровождаемость 0,15 Эффективность 0,03 Мобильность 0,02 Практичность

Ранг свойства 1 2 3 4 5 6

С учётом полученных данных применительно к рассмотренному классу ПО можно выделить: а) основные свойства – функциональные возможности, надёжность, сопровождаемость, эффективность; б) дополнительные свойства – мобильность, практичность. Большинство из приведенных свойств присуще ПО и других классов. Однако степень их важности будет отличаться, и не исключено выявление новых свойств. Так, для ИС военного назначения наиболее важным свойством может быть надёжность, для систем управления технологическими процессами – эффективность, а для ПО универсальных ИС широкого применения – мобильность и функциональные возможности. Следует отметить, что цель проведения таких экспертных оценок состоит не столько в обеспечении «свёртки» комплексных показателей качества в обобщённый, сколько в выделении основных и дополнительных свойств и их показателей, в возможном дополнении их новыми, что допускается требованиями ГОСТов, ОСТов и других регламентирующих документов. Для таких сложных систем, как ПО ИС, нет возможности описать все свойства количественными показателями. Поэтому при разработке, испытаниях, сертификации и эксплуатации ПО приходится использовать две группы показателей качества (ПК): 1) объективные (количественные) ПК, характеризуемые реально измеряемыми физическими величинами; 2) субъективные (качественные) ПК, характеризуемые, как правило, фактом практического наличия или отсутствия того или иного свойства у ПО и оцениваемые соответственно 1 или 0. Использование качественных показателей хотя и вносит элемент субъективизма в оценку ПО, но позволяет с определённой достоверностью, зависящей от опыта и квалификации разработчика, заказчика или пользователя, учесть степень влияния таких свойств на качество всей ИС. Степень субъективизма может быть значительно снижена при использовании метода групповых экспертных оценок. Поскольку

25 стандартом [9] определено, что предложенные в нём характеристики – не истина в последней инстанции, а только образуют основу для дальнейшего уточнения и описания качества ПО, допустимо расширять состав соответствующих свойств и номенклатуры показателей их оценки, устанавливать свои собственные модели процесса оценивания и методы формирования и проверки метрик, связанных с этими показателями, для охвата различных областей применения и стадий ЖЦ. С учётом этого в качестве примера совокупности показателей качества ПО для одной из ИС может служить следующая совокупность: 1) количественные ПК: а) функциональные ПК решения задач, определяемые назначением ИС, – среднее время решения задачи, пропускная способность, время ответа и другие; б) среднее время наработки на программный отказ; в) среднее время восстановления после программного отказа; г) коэффициент загрузки оперативной памяти; д) коэффициент загрузки производительности; е) ёмкость программ; ж) время изменения логической структуры базы данных и выходных форм; 2) качественные ПК: а) информативность текстов; б) соответствие программной документации требованиям стандартов; в) защищённость от НСД; г) степень «дружественности» пользовательского интерфейса и ряд других. Модель процесса оценивания качества и сертификации ПО должна отражать основные этапы, требуемые для оценивания по характеристикам, рекомендуемым стандартом [9], в соответствии с которым процесс состоит из трёх стадий: 1) установление (определение) требований к качеству, 2) подготовка к оцениванию, 3) процедура оценивания. Требования должны формулироваться в установленных ГОСТом терминах характеристик качества и комплексных показателей. Подготовка к оцениванию включает в себя: а) выбор метрик (показателей), сводящийся к установлению количественного масштаба и метода для определения значения того или иного признака свойств ПО; б) определение уровней ранжирования, представляющее собой разделение всей шкалы выбранных метрик на диапазоны, соответ-

26 ствующие различным степеням удовлетворения требований по конкретным показателям; в) определение критериев оценки, позволяющих подытоживать результаты оценивания различных характеристик с помощью специальных таблиц решений, среднего взвешивания или других приёмов, для получения вывода о приемлемости результатов оценки отдельных признаков свойств и качества ПО в целом, о приёмке или отбраковке программной продукции. Процедура оценивания включает: а) измерение, результатом которого является получение измеренного признака свойств в масштабе выбранной метрики; б) ранжирование, устанавливающее отнесение измеренного признака к тому или иному уровню; в) оценка, являющаяся последним этапом процесса оценивания ПО, на котором обобщается множество установленных уровней и результатом которого является заключение о качестве ПО, по которому после сравнения с другими факторами, такими как время и стоимость, принимается решение о выпуске (или невыпуске) программной продукции и её сертификации. 5. МЕТОДЫ ОЦЕНКИ ТЕХНИКОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ ПРОГРАММНЫХ СРЕДСТВ НА РАЗЛИЧНЫХ ЭТАПАХ ИХ ЖИЗНЕННОГО ЦИКЛА 5.1. Порядок и методология проведения статического анализа программных средств Статический анализ проводится в соответствии со стандартом [12], все положения которого подлежат обязательному применению в испытательных центрах (лабораториях), аккредитованных в системе РОСИНФОСЕРТ. Данный стандарт распространяется на все программные средства независимо от их назначения и области применения. Проведение СА начинается обычно с построения графа вызовов, который отражает модульную структуру ПС. Вершины графа изображаются в виде прямоугольников, содержащих имена компонент (модулей), ребра – в виде стрелок. Затем формируется список путей вызовов. Путь вызова представляет собой последовательность соприкасающихся ребер из графа вызовов (конечная вершина ребра является начальной вершиной следующего ребра), где начальная вершина первого ребра есть корень графа, а конечная вершина всегда представляет собой компоненту, которая не содержит последующих вызовов, т.е. если иерархия вызовов является древовидной структурой, то это лист дерева.

27 Обычно в списке путей вызовов представлены все пути, которые подлежат тестированию. Кроме того, этот список содержит полезную информацию для сопровождения программы: на основании последовательности вызовов компонент можно непосредственно указать возможные результаты некоторой модификации; можно немедленно узнать длину пути вызовов, а также местонахождение и частоту появления компонент, что важно при определении компонент, которые могут быть модифицированы; список дает возможность составления перечня тестовых примеров. Более наглядное и удобное представление о логической структуре даёт матрица вызовов и достижимости, которая содержит информацию о двух основных типах структур вызова между произвольными парами компонент. Элементы в иерархии вызовов могут находиться в одной из взаимосвязей: одна из них непосредственно вызывает другую; в графе вызовов существует путь, начинающийся на одном из элементов данной пары и заканчивающийся на другом, т.е. элементы рассматриваемой пары не могут быть вызваны друг из друга непосредственно, а лишь через цепочку последовательных вызовов. Матрица вызовов и достижимости позволяет ответить на вопросы: Если изменить модуль А, то может ли это как-то повлиять на модуль В (так называемый волновой эффект)? Каково число модулей, вызываемых модулем А, и что это за модули? Каково число модулей, достижимых модулем А, но не вызываемых из него, и что это за модули? Какие модули являются недостижимыми (никогда не вызываемыми)? Какие вершины графа являются конечными (не содержащими вызова)? Какие вызовы являются рекурсивными? Строки и столбцы матрицы содержат имена компонент в иерархии вызовов и упорядочены по иерархическим уровням сверху вниз. Крестик обозначает, что компонента, соответствующая строке, непосредственно вызывает компоненту, специфицированную столбцом. Точкой обозначен факт косвенного вызова (достижение реализуется через цепочку вызовов). Диагональные элементы обозначены дефисами за исключением случая рекурсивного вызова, при котором в качестве соответствующего диагонального элемента матрицы будет стоять крестик или точка. Эта информация используется при тестировании и сопровождении, в частности при построении путей тестирования. Так как операторы программы могут исполняться в различном порядке в зависимости от выбранного набора входных данных, то существует много способов достижения точки выхода из точки входа программы. Путь тестирования

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

Т = [(1 / Nв) · (∑1 / Pi)]-1, i=1 где NВ – количество путей вызовов в графе вызовов модулей; Pi – тестируемость i-го пути вызовов, равная k Pj = [∑1 / A(Mj)]-1, j=1 где k – количество модулей в пути вызовов; А (Мj) – доступность модуля Мj, принадлежащего пути Рi, определяется следующим образом: n А (Мj) = ∑ А (Мx) / C (Мx), x=1 где А (Мx) – доступность x-го модуля, вызывающего Мj; C (Мx) – количество всех модулей, которые вызывает Мx; n – количество модулей, которые вызывают Mj; А(М) = 1, если модуль М является самым верхним (головным) модулем. Рассмотренный выше ручной метод статического анализа, заключающийся в детальном просмотре исходного текста программ специальным экспертом, имеет следующие недостатки: приводит к большим затратам времени и человеческих ресурсов; требует привлечения эксперта высокой квалификации (как программиста и как эксперта качества); точность результатов не всегда удовлетворительна из-за больших объемов и сложности программ (в ряде случаев человеческие возможности не позволяют применить ручной анализ). Автоматизированные средства способны вычислить или помочь в определении самых трудоемких характеристик, позволяя таким образом эксперту сосредоточить внимание на интерпретации полученных характеристик и уровне качества программы. Независимо от способа проведения СА (автоматизированного или ручного) следует учитывать особенности СА на различных этапах.

29 1) Анализ и проектирование Применение статического анализа на этих этапах требует прежде всего наличия инструментального средства формальной спецификации, обеспечивающего хранение результатов в машинообрабатываемой форме. Статический анализ на этих этапах применяется прежде всего для выявления ошибок и аномалий, т.е. является средством управления качеством в отличие от этапа программирования, где имеет оценочный характер. Применение статического анализа на этапах анализа и проектирования, несмотря на ограниченность измеряемых характеристик, способствует раннему обнаружению ошибок, трудноисправимых на последующих этапах. 2) Программирование На этом этапе статический анализ используется для оценки качества программы, а также для документирования (при разработке документов сопровождения). 3) Тестирование и отладка На этом этапе статический анализ применяется для получения исходной информации при подготовке и оценки полноты тестов. Пример оценки тестируемости Пусть граф вызовов имеет вид Mx=1 A(

i=1

i=1,2,3 Mx=0

Mx=4

i=2 Mx=2

i=4,5

i=4

Mx=5

i=5

i=6

Mj, j = 0,1

i=3 Mx=3

i=6

Mx=6

Для данного графа NВ = 6, C(Mx=0) = 3, C(Mx=1) = 3, C(Mx=2) = 2, C(Mx=3) = 1, n = 3. n=0 Тогда A(M0) = 1, A(M1) = A(M2) = A(M3) = ∑ A(Mx=0) / C(Mx=0) = 1/3 x=0 n=3 A(M4) = ∑ A(Mx) / C(Mx) = 1/3:3 + 1/3:2 + 1/3:1 = 11/18 x=1

30 n=2 A(M5) = ∑ A(Mx) / C(Mx) = 1/3:3 + 1/3:2 = 5/18 x=1 n=1 A(M6) = ∑ A(Mx) / C(Mx) = 1/3:3 = 1/9 x=1 3 Pi=1 = [ ∑1/ A(Mj)]-1 = [1/ A(M0) + 1/ A(M1) + 1/A(M4)]-1 = j=1 = [1/1+1:1/3 + 1:11/18]-1 = 11/62 Pi=2 = [1/ A(M0) + 1/ A(M1) + 1/A(M5)]-1 = [1/1 + 1:1/3 + 1:5/18]-1 = 5/38 Pi=3 = [1/ A(M0) + 1/ A(M1) + 1/A(M6)]-1 = [1/1 + 1:1/3 + 1:1/9]-1 = 1/13 Pi=4 = [1/ A(M0) + 1/ A(M2) + 1/A(M4)]-1 = [1/1 +1:1/3+1:18/11]-1=11/62 Pi=5 = [1/ A(M0) + 1/ A(M2) + 1/A(M5)]-1 = [1/1 + 1:1/3 + 1:18/5]-1 = 5/38 Pi=6 = [1/ A(M0) + 1/ A(M2) + 1/A(M4)]-1 = [1/1 +1:1/3+1:18/11]-1 =11/62 Nв 6 -1 T = [1/Nв·∑1/PI] = [1/6 ·∑1/PI]-1 = [7,52]-1 = 0,133. i=1 i=1 5.2. Методика оценки трудоёмкости разработки программных средств Трудоемкость разработки ПС рассчитывается с учетом объективных и субъективных факторов [7]: количество строк исходного текста, написанных разработчиком (без учета текста, сгенерированного автоматически, использованного из библиотек и т.д.); сложность разрабатываемого ПС; степень новизны разрабатываемого ПС; уровень требований к показателям качества ПС; условия и средства разработки ПС; опыт и квалификация разработчика. 5.2.1. Нормы времени и порядок расчета трудоемкости разработки ПС Базовая трудоемкость разработки ПС (Тб) определяется по формуле Тб = Норм · Ксложн , где Норм – норма времени на разработку, определяемая в соответствии с п. 5.2.2; Ксложн – коэффициент сложности ПС, определяемый в соответствии с п. 5.2.4. 5.2.2. Норма времени на разработку ПС (Норм) определяется по табл. 5.1 в зависимости от исходного объема ПС (Vo), определяемого в соответствии с п. 5.2.3. Нормы времени, указанные в табл. 5.1, рассчитаны на количество строк исходного текста, написанных разработчиком

31 вручную (без учета текста, сгенерированного автоматически, использованного из библиотек и т.д.) на языке С++. Таблица 5.1 Нормы времени на разработку ПС средней сложности в зависимости от его исходного объема* Объем ПС –V0, Нормы времени тыс. строк на разработку, № нормы исходного текста чел.-дн. 1 2 3 0,1 7 1 0,2 11 2 0,3 17 3 0,4 23 4 0,5 32 5 0,6 38 6 0,8 53 7 1,0 65 8 1,2 86 9 1,4 97 10 1,6 111 11 1,8 126 12 2,0 141 13 2,5 181 14 3,0 221 15 3,5 263 16 4,0 302 17 4,5 344 18 5,0 389 19 6,0 443 20 7,0 525 21 8,0 607 22 9,0 704 23 10,0 777 24 15,0 1213 25 20,0 1665 26 25,0 2128 27 30,0 2600 28 35,0 3080 29 40,0 3567 30 45,0 4061 31 50,0 4560 32

32 1 55,0 60,0 65,0 70,0 75,0 80,0 85,0 90,0 95,0 100,0 110,0 120,0 130,0 140,0 150,0 160,0 170,0 180,0 190,0 200,0

Продолжение табл. 5.1 2 3 5063 33 5572 34 6085 35 6601 36 7122 37 7645 38 8172 39 8703 40 9236 41 9772 42 10851 43 11941 44 13040 45 14147 46 15263 47 16385 48 17514 49 18650 50 19793 51 20942 52

*

Если исходный объем ПС выражается таким числом строк исходного текста, которое не приведено непосредственно в табл. 5.1, то норма времени вычисляется методом линейной интерполяции: в графе 1 табл. 5.1 следует выбрать два значения Vо, которые по отношению к фактическому значению Vо являются ближайшим меньшим и ближайшим большим значениями, и для каждого из этих двух значений Vо определить значение нормы времени (графа 2 в табл. 5.1), а затем по этим двум значениям норм времени вычислить среднее значение пропорционально положению фактического значения Vо между его ближайшим меньшим и ближайшим большим значениями. 5.2.3. Исходный объем разрабатываемого ПС (Vо) определяется по формуле n V0 =∑VImiki , i=1

где Vi – объем i-й функции ПС; n – общее число функций ПС; mi – число реализаций i-й функции;

33 ki – коэффициент повторного использования i-й функции, может принимать значения от 0 до 1 (ki = 0 – i-я функция полностью дублируется, ki = 1 – i-я функция полностью разрабатывается). Объем каждой отдельной функции разрабатываемого ПС (Vi), выраженный числом строк исходного текста, написанных непосредственно разработчиком на языке С++, определяется по Каталогу функций программных средств № 1 (табл. 5.2) на основании имеющейся в техническом задании информации о составе функций разрабатываемого ПС. Исходный объем ПС в существенной степени влияет на точность результатов расчета трудоемкости, поэтому точность определения его отдельных составляющих (объемов функций) имеет важное значение. Чем глубже проработана функциональная архитектура, тем точнее результаты расчетов. Технические задания могут существенно различаться по степени детализации функций. Если в техническом задании функции ПС достаточно глубоко детализированы, то для повышения точности расчетов рекомендуется использовать Каталог функций программных средств № 2 (табл. 5.3). Таблица 5.2 Каталог функций программных средств № 1 Объем функции ПС Наименование (содержание) функции (строк исходного текста) 1 2 1. Функции, обеспечивающие реализацию пользовательского интерфейса и машинной графики Реализация стандартного графического пользовательского интерфейса (однооконное приложение) 2000 Реализация стандартного графического пользовательского интерфейса (диалоговое приложение)

1000

Реализация стандартного графического пользовательского интерфейса (многооконное приложение)

5000

Реализация машинной графики отображения состояния системы в статике

1000

для

Реализация машинной графики для отображения состояния системы в динамике

2000

34 Продолжение табл. 5.2 1 2 2. Функции, обеспечивающие взаимодействие с системами управления базами данных Создание и изменение схемы базы данных 200 Контроль и восстановление целостности 700 базы данных 3. Функции, обеспечивающие реализацию взаимосвязей систем и компонентов Сетевая передача команд и сообщений 90 Контроль состояния распределенной 200 системы 4. Функции, обеспечивающие управление безопасностью Реализация криптографических алго1000 ритмов Обеспечение безопасности передачи 700 сообщений и обмена данными Контроль и журнализация доступа к 2000 защищенным ресурсам 5. Функции, обеспечивающие распределенную обработку данных Реализация связи между распределенными приложениями с использованием стандартных 70 транспортных средств Реализация связи между распределенными приложениями на основе сетевых 140 интерфейсов низкого уровня 6. Функции, обеспечивающие ввод / вывод и обработку данных Прием данных (в заданных форматах) от 1500 приложений нижестоящего уровня Логический, синтаксический и номенкла1000 турный контроль данных Разработка выходных печатных форм 500 Расчет алгебраических выражений 30 7. Функции, обеспечивающие реализацию прикладных задач Статистическая обработка данных 100 Расчет экономических показателей 30 Составление сводных балансов 500 Обработка экономических данных 500 Экономический анализ и прогнозирование 5000

35 Таблица 5.3 Каталог функций программных средств № 2 Объем функции Наименование (содержание) функции ПС (строк исходного текста) 1. Функции, обеспечивающие реализацию пользовательского интерфейса и машинной графики Реализация стандартного графического пользовательского интерфейса (однооконное приложение): API (Application Programming Interface – интерфейс прикладного программирования) MFC/OWL (Microsoft Foundation Classes/Object Windows Library – библиотеки классов Microsoft) VCL (Visual Classes Library – библиотека визуальных классов) Реализация стандартного графического пользовательского интерфейса (диалоговое приложение): API MFC/OWL VCL

1000 – 2000 600 – 900 300 – 700

500 – 1000 40 – 100 20 – 100

Реализация стандартного графического пользовательского интерфейса (многооконное приложение): 2000 – 5000 API 600 – 1500 MFC/OWL 500 – 1500 VCL 2. Функции, обеспечивающие взаимодействие с системами управления базами данных Создание и изменение схемы базы данных 200 Контроль и восстановление целостности базы 700 данных Ведение базы данных (выполнение единичного 15 запроса на модификацию) Ведение базы данных (выполнение единичного 10 запроса на чтение данных)

36 Продолжение табл. 5.3 1 2 3. Функции, обеспечивающие реализацию взаимосвязей систем и компонентов Удаленная доставка информации с подтверждением получения 40 Вызов удаленных процедур 10 Управление файлами, доступом к файлам и 50 передачей файлов между удаленными и разнородными файловыми системами Обработка сообщений 10 – 20 Обработка распределенных транзакций 60 Средства контроля состояния распределенной 100 – 200 сети однородных компонент Доступ к общей памяти: в рамках одной машины 20 в рамках вычислительной сети 90 Ведение журнала обращений к распределенной 30 системе 4. Функции, обеспечивающие управление безопасностью Реализация криптографических алгоритмов 200 – 1000 Обеспечение безопасности передачи сообщений 200 – 700 и обмена данными Контроль и журнализация доступа к защищен400 – 2000 ным ресурсам 5. Функции, обеспечивающие распределенную обработку данных Создание одного объекта на базе технологии CORBA (Common Object Requests Broker Architecture 50 – универсальная открытая технология для создания распределенных систем вне зависимости от языка программирования и платформы) 60 Создание одного объекта на базе технологии COM (Component Object Model – объектноориентированная технология создания распределенных систем на базе платформы Microsoft Windows) 2 Вызов метода CORBA-объекта 1 Вызов метода COM-объекта 40 Реализация сетевого взаимодействия на базе средств Sockets API (серверная сторона) 20 Реализация сетевого взаимодействия на базе средств Sockets API (клиентская сторона)

37 Окончание табл. 5.3 1 2 6. Функции, обеспечивающие ввод / вывод и обработку данных Прием данных (в заданных форматах) от 50 – 1500 приложений нижестоящего уровня Логический, синтаксический и номенклатур500 – 1000 ный контроль данных Разработка выходных печатных форм 300 – 500 Расчет алгебраических выражений 10 – 50 7. Функции, обеспечивающие реализацию прикладных задач Статистическая обработка данных 100 Расчет экономических показателей 20 Экономический анализ и прогнозирование 500 – 5000 Составление сводных балансов 500 Экономическая обработка данных 100 – 500 5.2.4. Коэффициент сложности ПС определяется по табл. 5.4 в зависимости от наличия или отсутствия у разрабатываемого ПС соответствующих характеристик. Таблица 5.4 Значение коэффициента сложности Ксложн в зависимости от характеристик ПС Характеристики ПС Уровень сложности ПС

Вычислительные операции

Операции, зависящие от аппаратуры

Операции управления данными

1

2

3

Очень низкий

Вычисление упрощенных выражений: например, A=B+ + C(D – E)

Упрощенные операторы чтения, записи с простыми форматами

4 Простые массивы в основной памяти. Простые запросы на обновление

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

Коэффициент сложности 6

0,73

38

Продолжение табл. 5.4 1

2

3 Не требуется никакой информации о характеристиках конкретного типа процессоров или устройств ввода / вывода

4

5

6

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

Использование простых средств построения интерфейса пользователя

0,8

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

1,0

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

1,17

Низкий

Вычисление выражений средней сложности (одномерные массивы)

Средний

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

Операции ввода и вывода включают выбор устройства, проверку его состояния и обработку ошибок

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

Базовые элементы численного анализа: многомерная интерполяция, обыкновенные дифференциальные уравнения, простые случаи усечения и округления

Операции ввода и вывода на физическом уровне (трансляция физических адресов хранения данных; операции поиска, чтения и т.д.). Оптимизированное совмещение ввода и вывода

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

Высокий

39 Окончание табл. 5.4 1

Очень высокий

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

3

4

5

6

Процедуры для определения, обработки и маскирования прерываний. Управление каналом связи. Встроенные системы с определенными требованиями к производительности

Управление распределенными базами данных. Сложные триггеры. Оптимизация поиска

2D/3D графика средней сложности, динамическая графика, мультимедиа

1,34

Примечание. Уровень сложности представляет собой субъективное средневзвешенное значение уровней сложности выбранных характеристик кода программы. 5.2.5. Общая трудоемкость разработки ПС (То) определяется по формуле То = Тб · Кн · Ккач, где Кн – поправочный коэффициент, учитывающий степень новизны ПС (п. 5.2.6); Ккач – поправочный коэффициент, учитывающий уровень требований к показателям качества ПС (п. 5.2.7); Тб – базовая трудоемкость разработки ПС (п. 5.2.1). 5.2.6. Значение поправочного коэффициента (Кн), учитывающего степень новизны ПС, определяется по табл. 5.5. Таблица 5.5 Зависимость значений поправочного коэффициента Кн от степени новизны ПС Код степени новизны

Степень новизны

1

2

А

Принципиально новое ПС, не имеющее доступных аналогов

Признак использования новых Значение ЭВМ/ОС Кн Новый Новая ОС тип ЭВМ 3 4 5 + + 1,75 – + 1,6 + – 1,2 – – 1,1

40 Продолжение табл. 5.5 1 Б

В

2 ПС, являющееся развитием определенного параметрического ряда ПС на новом типе ЭВМ/ОС ПС, являющееся развитием определенного параметрического ряда ПС на прежнем типе ЭВМ/ОС

3 + – +

4 + + –

5 1,0 0,9 0,8

–

–

0,7

5.2.7. Коэффициент, учитывающий уровень требований к показателям качества ПС, рассчитывается по формуле Ккач = КнадКпроизв·Кдокум · Кпик, где Кнад – коэффициент, учитывающий требования к надежности ПС (табл. 5.6); Кпроизв – коэффициент, учитывающий требования к производительности ПС (табл. 5.7); Кдокум – коэффициент, учитывающий требования к уровню информативности документации на фазах жизненного цикла ПС (табл. 5.8); Кпик – коэффициент повторного использования программных компонентов (табл. 5.9). Таблица 5.6 Значения коэффициента надежности Уровень требований к надежности ПС Очень низкий Низкий Средний Высокий Очень высокий

Характеристика Сбои ПС приводят к некоторым неудобствам Незначительный, легко восполнимый ущерб Средний, восполнимый ущерб Крупные финансовые потери Риск для жизни людей

Значение Кнад 0,82 0,92 1,0 1,10 1,26

Таблица 5.7 Значения коэффициента, учитывающего требования к производительности ПС Характеристика Производительность ПС не играет роли Требования к производительности ПС не установлены (однако производительность ПС должна обеспечивать приемлемое время отклика при работе пользователя в интерактивном режиме) Имеются умеренные требования к производительности Повышенные требования к производительности Исключительно высокие требования к производительности

Значение Кпроизв 0,9 1,0 1,1 1,2 1,3

41 Таблица 5.8 Значения коэффициента, учитывающего требования к уровню информативности документации Уровень требований Характеристика Значение Кдокум Не учтены многие потребности Очень низкий 0,81 жизненного цикла Не учтены некоторые Низкий 0,91 потребности жизненного цикла Соответствует потребностям Средний 1,00 жизненного цикла Повышенный объем для Высокий 1,11 жизненного цикла данного ПС Большой (избыточный) объем для Очень высокий 1,23 жизненного цикла данного ПС Примечание. Экономия трудозатрат путем установления очень низкого значения коэффициента повлечет дополнительные расходы в процессе сопровождения. Плохая документация или отсутствие ее приведут к увеличению коэффициента, связанного с параметром «Понимание ПС». Таблица 5.9 Значения коэффициента повторного использования программных компонентов Уровень требований Характеристика Значение Кпик Низкий Повторно не используются 0,95 Средний На уровне проекта 1,00 Высокий На уровне программы 1,07 Очень высокий На уровне линии продуктов 1,15 Исключительно На уровне нескольких 1,24 высокий линий продуктов Примечание. Этот параметр учитывает дополнительные трудозатраты, необходимые для создания компонентов, предназначенных для повторного использования в текущих и будущих проектах: более общей архитектуры ПС, более детализованных спецификаций и более тщательного проведения испытаний с тем, чтобы гарантировать готовность компонентов к использованию в составе других приложений. «На уровне проекта» может применяться к повторному использованию на уровне модулей, входящих в состав какого-либо проекта по разработке бизнес-приложений. «На уровне программ» подходит для повторного использования на уровне нескольких проектов по разработке бизнесприложений для одной организации. «На уровне линии программных продуктов» применяется, если повторное использование распространяется на несколько организаций. «На уровне нескольких линий» означает

42 повторное использование на уровне линий бизнес-приложений, приложений для маркетинга и коммерции. Разработка с целью повторного использования накладывает некоторые ограничения на значения коэффициентов Кнад и Кдокум. Значение Кнад выбирается из графы на один уровень ниже, чем уровень Кпик. Значение Кдокум должно быть, по меньшей мере, равно среднему при высоком значении Кпик и высокому при очень и исключительно высоком значении Кпик. 5.2.8. Трудоемкость разработки ПС с учетом конкретных условий разработки (Тур) рассчитывается по формуле Тур = То · Кср.упр.жиз · Кср.разр , где То – общая трудоемкость разработки ПС; Кср.упр.жиз – поправочный коэффициент, учитывающий использование средств управления жизненным циклом (табл. 5.10); Кср.разр – поправочный коэффициент, учитывающий конкретные условия и средства разработки ПС (табл. 5.11). Таблица 5.10 Значения поправочного коэффициента, учитывающего использование средств управления жизненным циклом Уровень

Характеристика

Значение

Средства написания, редактирования 1,17 и отладки приложений Простые клиент/серверные средства Низкий 1,09 CASE, интеграция незначительна Основные, умеренно Средний интегрированные средства 1,00 управления жизненным циклом Мощные, развитые, умеренно Высокий 0,90 интегрированные средства управления жизненным циклом Мощные, развитые, умеренно интегрированные средства прогноза и управления жизненным циклом, Очень высокий 0,78 совместно с технологическими процессами, методами разработки и повторного использования Примечание. Наименьший рейтинг присваивается в том случае, если при разработке используются только средства для написания и редактирования кода, максимальный рейтинг присваивается при использовании интегрированных средств управления жизненным циклом. Очень низкий

43 Таблица 5.11 Значения поправочного коэффициента Кср.разр в зависимости от средств разработки ПС Значения Кср.разр в разрезе типа ЭВМ и характера операционной среды Сети IBM-PC Средства разработки ПС* совместилокальные глобальмые (типа ные Windows NT) Язык С++ 1,0 1,2 1,3 Язык Java 0,73 0,88 0,95 Процедурные языки высокого 0,52 0,62 0,68 уровня (Паскаль) Языки 4GL (Visual Basic, 0,46 0,55 0,6 Delphi) Системы программирования 0,35 0,42 0,46 на основе СУБД типа FoxPro Системы программирования на основе СУБД типа Oracle, 0,4 0,48 0,52 SqlServer Объектно-ориентированные технологии (COM/DCOM, 0,65 0,78 0,85 CORBA) Средства проектирования 0,35 0,42 0,46 BPWIN, ERWIN/ERX Объектно-ориентированные 0,3 0,36 0,39 CASE-средства (Rational Rose) Прочие CASE-средства

0,40

0,48

0,52

Примечание. Указанные в таблице средства разработки обозначают группу средств подобного типа. Поэтому если имеется средство разработки, непосредственно не указанное в левом столбце, то его необходимо самостоятельно отнести к какой-либо из групп, наиболее близкой по уровню используемого языка. 5.2.9. В том случае, если имеются сведения об опыте и квалификации разработчика, рассчитывается трудоемкость разработки с учетом рейтинга разработчика Тр: Тр = Тур · Кквал · Копыт , где Тур – трудоемкость с учетом условий разработки ПС; Кквал – поправочный коэффициент, учитывающий уровень квалификации разработчика ПС (табл. 5.12); Копыт – поправочный коэффициент, учитывающий опыт разработчика ПС (табл. 5.13).

44 Таблица 5.12 Зависимость значения коэффициента Кквал от уровня квалификации разработчика Уровень квалификации разработчика Значение Кквал Крайне низкий 2,12 Очень низкий 1,62 Низкий 1,26 Средний 1,00 Высокий 0,80 Очень высокий 0,60 Исключительно высокий 0,50 Примечание. Оценка должна строиться на возможностях разработчиков как членов группы, а не на индивидуальных возможностях каждого программиста. Основными критериями оценки, которые необходимо учесть при определении рейтинга, являются: квалификация, эффективность работы, скрупулезность, коммуникабельность и способность работать в коллективе. Таблица 5.13 Зависимость значения коэффициента Копыт Уровень

Опыт разработки приложений

Крайне низкий Очень низкий Низкий Средний Высокий Очень высокий Исключительно высокий

Не более 3 месяцев 5 месяцев 9 месяцев 1 год 2 года 4 года

Значение Кквал 1,59 1,33 1,12 1,00 0,80 0,70

6 лет

0,60

5.2.10. Трудоемкость разработки ПС Т (равная Тур или Тр, если расчеты ведутся для конкретного разработчика) в человеко-днях складывается из трудоемкостей отдельных стадий разработки: n

T = ∑Ti , i=1

где

Тi – трудоемкость i-й стадии разработки ПС; n – количество стадий разработки ПС (см. п. 5.1.1).

45 5.2.11. Трудоемкость каждой отдельной стадии разработки ПС (Тi) определяется по формулам: Т1 = L1 · Т – трудоемкость стадии «Анализ разработки»; Т2 = L2 · Т – трудоемкость стадии «Проектирование»; Т3 = L3 · Т – трудоемкость стадии «Программирование»; Т4 = L4 · Т – трудоемкость стадии «Тестирование»; Т5 = L5 · Т – трудоемкость стадии «Внедрение», где Li – удельный вес трудоемкости i-й стадии разработки, причем n ∑Li = 1; i=1

Т – трудоемкость разработки ПС. 5.2.12. Значения Li зависят от вида технологии разработки ПС и определяются по табл. 5.14. Таблица 5.14 Зависимость коэффициентов удельного веса трудоемкости стадий разработки от вида технологии Значения коэффициентов удельного веса трудоемкости Вид стадий разработки ПС в разрезе видов технологии технологии L1 L2 L3 L4 L5 Традиционная технология разработки без применения 0,2 0,15 0,2 0,40 0,05 структурных методологий и средств автоматизации Разработка с использованием структурных методологий 0,3 0,3 0,15 0,20 0,05 вручную без применения средств автоматизации Разработка с применением 0,4 0,4 0,05 0,10 0,05 CASE-средств

46 5.2.13. Если при расчете трудоемкости всей разработки не учитывались квалификация и опыт разработчика, то трудоемкость различных стадий процесса разработки может быть скорректирована (уточнена) с учетом профессиональных качеств исполнителей (трудоемкость Т в этом случае также изменится). 5.2.14. Трудоемкость стадии «Анализ разработки» может быть скорректирована с учетом профессиональных качеств аналитиков: Т1* = Т1 · Кан , где Кан – коэффициент, учитывающий профессиональные качества аналитиков (табл. 5.15). Таблица 5.15 Таблица зависимости значения коэффициента Кан от профессиональных качеств аналитиков Профессиональный уровень аналитиков Значение Кан Очень низкий 1,42 Низкий 1,19 Средний 1,00 Высокий 0,85 Очень высокий 0,71 Примечание. Аналитики – часть персонала организации, занятая в разработке технических требований, высокоуровневом проектировании и составлении рабочего плана. Основными характеристиками, которые следует рассмотреть при определении категории для данного параметра, являются способность к проектированию и анализу, производительность и аккуратность, а также коммуникабельность и способность к совместной работе. 5.2.15. Трудоемкость стадии «Проектирование» может быть скорректирована с учетом профессиональных качеств проектировщиков: Т2* = Т2 · Кпр , где Кпр – коэффициент, учитывающий профессиональные качества проектировщиков (табл. 5.16). Таблица 5.16 Таблица зависимости значения коэффициента Кпр от профессиональных качеств проектировщиков Профессиональный уровень проектировщиков Значение Кпр Очень низкий 1,22 Низкий 1,10 Средний 1,00 Высокий 0,88 Очень высокий 0,81

47 5.2.16. Трудоемкость стадии «Программирование» может быть скорректирована с учетом опыта работы с языками и средствами разработки: Т3* = Т3 · Кпрог , где Кпрог – коэффициент, учитывающий опыт работы программистов с языками и средствами разработки (табл. 5.17). Таблица 5.17 Таблица зависимости значения коэффициента Кпрог от опыта работы программистов с языками и средствами разработки Опыт работы с языками Уровень Значение Кпрог и средствами разработки Очень Менее 2 месяцев 1,20 низкий Низкий 6 месяцев 1,09 Средний 1 год 1,00 Высокий 3 года 0,91 Очень 6 лет 0,84 высокий 5.2.17. Если для испытания ПС необходимо генерировать большой объем тестовых данных, то трудоемкость стадии тестирования может быть скорректирована с учетом размеров базы данных: Т4* = Т4 · КБД , где КБД – коэффициент, учитывающий размер БД (табл. 5.18); Т4 – трудоемкость стадии тестирования без учета размера БД (п. 5.2.11). Таблица 5.18 Значения коэффициента, учитывающего размер БД Отношение объема БД к объему ПС, Значение Размер БД байты / количество строк КБД исходного текста (D/P) Низкий < 10 0,90 Средний 10 <= D/P < 100 1,00 Высокий 100 <= D/P < 1000 1,14 Очень высокий D/P >= 1000 1,28 5.2.18. Исходя из трудоемкости стадий разработки ПС (Тi, см. п. 5.2.11) определяются количество специалистов или сроки, необходимые для реализации стадий разработки ПС. Данная оценка производится в условиях одного из двух ограничений: задано (ограничено) число разработчиков на каждой стадии разработки ПС; заданы сроки реализации стадий разработки ПС.

48 Срок реализации ПС (в месяцах) определяется по формуле n

t = ∑TI / (NI · Ф), i=1

где

t – время, необходимое для разработки ПС (месяцы); n – число стадий разработки ПС; Тi – трудоемкость i-й стадии разработки ПС (чел.-дн.); Ni – количество разработчиков, принимающих участие в разработке ПС на i-й стадии; Ф – фонд времени одного разработчика в течение месяца, дней/месяц. Если сроки разработки ПС заданы, то их соблюдения добиваются путем подбора нужного количества разработчиков на каждой стадии разработки ПС. В случае сокращения сроков выполнения плана работ существует тенденция к увеличению трудозатрат как на ранних этапах проекта (с тем, чтобы свести на нет дополнительные риски и улучшить архитектуру), так и на поздних этапах при параллельном проведении дополнительных испытаний и составлении документации. Увеличение сроков выполнения плана работ не приводит к изменению трудозатрат. Общая трудоемкость разработки может быть скорректирована: Тсрок = Т · Кср , где Тсрок – трудоемкость с учетом сроков разработки; Т – трудоемкость разработки; Кср – коэффициент, учитывающий влияние сроков работ на трудоемкость (табл. 5.19). Таблица 5.19 Значения коэффициента Кср, учитывающего влияние сроков работ на трудоемкость Продолжительность работ Значение Кср по сравнению с номинальной, % 75 1,43 85 1,14 100 1,00 130 1,00 160 1,00

49 5.2.19. Приведенные в настоящем документе нормы времени включают затраты времени на выполнение всех работ, сопутствующих разработке ПС. 5.2.20. В нормах времени учтено время на подготовительнозаключительные работы, обслуживание рабочего места, отдых и личные надобности в размере 10 % оперативного времени. Пример Определить трудоемкость разработки и среднюю численность разработчиков ПС «Средство тестирования». 1) Разработка ПС «Средство тестирования» предусматривает проведение всех стадий разработки: анализ; проектирование; программирование; тестирование; внедрение. 2) Исходные данные: – используется CASE-технология разработки; – все функции разрабатываются на языке С++. 3) По каталогу функций ПС (табл. 5.3) определяем объем каждой из функций разрабатываемого ПС «Средство тестирования» и сводим эти данные в таблицу:

№ функции

Наименование (содержание) функции

1

2 Реализация стандартного графического пользовательского интерфейса (диалоговое приложение): API MFC/OWL Реализация стандартного графического пользовательского интерфейса (многооконное приложение): MFC/OWL

1

2

Объем функции ПС (строк исходного текста) 3

4

Суммарный объем функции ПС (строки сходного текста) 5

500 100

15 50

7500 5000

1500

3

4500

Количество функций

50 1 3

4

5

6

7 8 9

10

11

12

2 Реализация машинной графики для отображения состояния системы в статике Реализация машинной графики для отображения состояния системы в динамике Создание и изменение схемы базы данных Ведение базы данных (выполнение единичного запроса на модификацию) Ведение базы данных (выполнение единичного запроса на чтение данных) Обработка сообщений Обработка распределенных транзакций Средства контроля состояния распределенной сети однородных компонент Доступ к общей памяти: в рамках одной машины в рамках вычислительной сети Ведение журнала обращений к распределенной системе

Продолжение табл. 5

3

4

1000

1

1000

2000

1

2000

200

1

200

15

180

2700

10

180

1800

20

20

400

60

20

1200

200

10

2000

20

2

20

90

2

180

30

20

600

51 1 13 14 15 16 17

2 Создание одного объекта на базе технологии CORBA Создание одного объекта на базе технологии COM Вызов метода CORBA-объекта Вызов метода COM-объекта Статистическая обработка данных

3

4

Окончание табл. 5

50

30

1500

60

30

1800

2

500

1000

1

500

500

100

11

1100

4) Определяем общий объем разрабатываемого ПС (Vo) как сумму объемов входящих в него функций: Vo = V1 +… + V17 = 35000 (строк исходного текста). 5) По табл. 5.1 и для объема ПС Vo = 35000 ТСИ определяем значение базовой трудоемкости разработки ПС: Норм = 3080 чел.-дн. 6) ПС «Средство тестирования» относим к высокому уровню сложности, поэтому согласно табл. 5.4: Ксложн = 1,17. Базовая трудоемкость Тб = Норм · Ксложн = 3080 · 1,17 = 4446 чел.-дн. 7) Общая трудоемкость разработки То = Тб · Кн · Ккач . Значение Кн определяем по табл. 5.5 ПС «Средство тестирования», разрабатывается на известном разработчикам типе ЭВМ (на ПЭВМ типа IBM PC) и в известной ОС (MS Windows), при наличии известных разработчикам аналогов, т.е. коэффициент новизны Кн = 0,7. Значение Ккач является произведением коэффициентов Кнад, Кпроизв, Кдокум и Кпик, значения которых выбираются из табл. 5.6 – 5.9: – коэффициент, учитывающий требования к надежности ПС, Кнад = 1,0; – коэффициент, учитывающий требования к производительности ПС, Кпроизв = 1,0; – коэффициент, учитывающий требования к уровню информативности документации на фазах жизненного цикла ПС, Кдокум = 1,0;

52 - коэффициент компонентов

повторного

использования

программных

Кпик = 1,15. Общая трудоемкость разработки будет равна То = 444,6 · 0,7 · 1,1 · 1,0 · 1,0 · 1,15 = 3937 чел.-дн. 8) Трудоемкость разработки ПС с учетом конкретных условий разработки (Тур) рассчитывается по формуле Тур = То · Кср.упр.жиз · Кср.разр . Значение поправочного коэффициента, учитывающего использование средств управления жизненным циклом, выбирается из табл. 5.10: Кср.упр.жиз = 1,0. Значение поправочного коэффициента, учитывающего конкретные условия и средства разработки ПС, выбирается из табл. 5.11: Кср.разр = 1,2. Подсчитываем Тур: Тур = 393,7 · 1,0 · 1,2 = 4724 чел.-дн. 9) Разработчик известен, поэтому в таблицах 5.12 и 5.13 находим значения коэффициентов Кквал и Копыт: поправочный коэффициент, учитывающий уровень квалификации разработчика ПС, Кквал = 0,8; поправочный коэффициент, учитывающий опыт разработчика ПС, Копыт = 0,8. Рассчитываем трудоемкость с учетом рейтинга разработчиков: Тр = 4724 · 0,8 · 0,8 = 3023 чел.-дн. 10) По табл. 5.14 определяем коэффициенты удельного веса трудоемкости стадий разработки ПС в общей трудоемкости: L1 = 0,30 (Анализ); L2'= 0,30 (Проектирование); L3'= 0,15 (Программирование); L4 = 0,20 (Тестирование); L5 = 0,05 (Внедрение). Рассчитываем трудоемкости отдельных стадий: Т1 = 907 чел.-дн. Т2 = 907 чел.-дн. Т3 = 453 чел.-дн. Т4 = 605 чел.-дн. Т5 = 151 чел.-дн. 11) Пусть на всю разработку запланировано 2 года, на отдельные стадии запланированы следующие сроки: Анализ 8 мес. Проектирование 8 мес.

53 Программирование 3 мес. Тестирование 4 мес. Внедрение 1 мес. Исходя из рассчитанной трудоемкости стадий и с учетом того, что в календарном месяце содержится примерно 22 рабочих дня, потребуется следующая численность исполнителей на каждой стадии: Анализ 5 чел. Проектирование 5 чел. Программирование 7 чел. Тестирование 7 чел. Внедрение 7 чел. 12) Если на всю разработку запланирован 1 год, на отдельные стадии запланированы следующие сроки: Анализ 4 мес. Проектирование 4 мес. Программирование 1,5 мес. Тестирование 2 мес. Внедрение 0,5 мес. Исходя из рассчитанной трудоемкости стадий и с учетом того, что в календарном месяце содержится примерно 22 рабочих дня, потребуется следующая численность исполнителей на каждой стадии: Анализ 10 чел. Проектирование 10 чел. Программирование 14 чел. Тестирование 14 чел. Внедрение 14 чел. 5.3. Методика оценки трудоёмкости сопровождения программных средств 5.3.1. Общие положения Цель методики – оценка трудоемкости сопровождения программных средств (ПС) с учетом современного состояния и тенденций развития нормативно-методического обеспечения и программно-инструментальных средств поддержки жизненного цикла ПС, а также требований к качеству ПС. 5.3.1.1. Методика охватывает работы процесса сопровождения, а также вспомогательные и организационные процессы, относящиеся к сопровождению в соответствии с ГОСТ Р ИСО/МЭК 12207-99. Процесс сопровождения состоит из работ [8]: подготовка процесса; анализ проблем и изменений; внесение изменений; проверка и приемка при сопровождении; перенос; снятие с эксплуатации.

54 5.3.1.2. Нормы времени определены с учетом факторов, влияющих на трудоемкость выполнения указанных работ: объем ПС в тыс. строк исходного текста (как написанного разработчиком вручную, так и сгенерированного автоматически); объем документации в тыс. строк (только эксплуатационная документация и документация сопровождения); сложность программ; язык программирования и другие средства разработки ПС; наличие аналогов ПС; степень участия службы сопровождения в разработке ПС; характер поставки ПС; характер внедрения ПС; объем доработок (количество строк исходного текста). 5.3.1.3. Правила расчета трудоемкости сопровождения ПС Трудоемкость каждого из видов работ по сопровождению ПС рассчитывается на основании норм времени, значения которых приведены в нормативной части документа в табл. 5.27 – 5.39 в зависимости от объема программ в тыс. строк исходного текста и объема документации в тыс. строк. Нормы времени, приведенные в указанных нормативных таблицах, разработаны для ПС, обладающего характеристиками: ПС средней сложности; аналоги данного ПС имеются; служба сопровождения в разработке ПС не участвовала, но имела информацию о ходе разработки и проводила испытания ПС. Для определения трудоемкости рассматриваемых работ для ПС с другими характеристиками следует пользоваться поправочными коэффициентами: Кан – коэффициент, учитывающий наличие в фонде программ аналогов данного ПС (табл. 5.20); Куч – коэффициент, характеризующий степень участия службы сопровождения в разработке ПС (табл. 5.21); Крз – коэффициент, учитывающий язык программирования и другие средства разработки ПС (табл. 5.22); Кхв – коэффициент, учитывающий характер внедрения ПС (табл. 5.23); Кт – коэффициент, учитывающий полноту тестирования поставленного ПС (табл. 5.24); Кхп – коэффициент, учитывающий характер поставки ПС (табл. 5.25). Ксл – коэффициент, учитывающий сложность ПС (табл. 5.26).

55 Таблица 5.20 Значения поправочного коэффициента, учитывающего наличие в фонде аналогов ПС Признак наличия аналогов Кан Есть 1,0 Нет 1,25 Таблица 5.21 Значения поправочного коэффициента, учитывающего степень участия службы сопровождения в разработке ПС Характеристика степени участия службы сопровождения Куч (ССо) в разработке ПС ССо разрабатывала ПС или значительную его часть 0,6 ССо участвовала в разработке ПС 0,8 на правах соисполнителя ССо в разработке ПС не участвовала, но имела информацию о ходе разработки 1,0 и принимала участие в испытаниях ПС ССо в разработке ПС не участвовала. Информации 1,2 о разработке до момента сдачи в фонд не имелось Таблица 5.22 Значения поправочного коэффициента, учитывающего язык программирования, технологии и средства разработки ПС* Характеристика средств разработки ПС Краз Язык С++ 1,0 Язык Java

0,9

Процедурные языки высокого уровня (Паскаль)

0,9

Языки 4GL (Visual Basic, Delphi)

0,8

Системы программирования на основе СУБД типа FoxPro Системы программирования на основе СУБД типа Oracle, SqlServer Объектно-ориентированные технологии (COM/DCOM, CORBA) Средства проектирования BPWIN, ERWIN/ERX Объектно-ориентированные CASE-средства (Rational Rose) Прочие CASE-технологии разработки ПС

0,7 0,6 0,7 0,15 0,17 0,2

56 *Примечание. При использовании нескольких средств разработки определяется средневзвешенное значение Краз, где весовой коэффициент определяет объем части ПС, разрабатываемой с помощью конкретных средств. Таблица 5.23 Значения поправочного коэффициента, учитывающего характер внедрения ПС Характер внедрения ПС Локальное внедрение ПС Внедрение ПС в составе комплекса невзаимосвязанных ПС Внедрение ПС в составе комплекса взаимосвязанных ПС Внедрение ПС как компонентов разрабатываемой или функционирующей системы обработки информации (СОИ), связанной с другими компонентами

Кхв 1,0 1,1 1,3 2,0 Таблица 5.24

Значения поправочного коэффициента, учитывающего полноту тестирования поставленного ПС Кте в разрезе видов тестирования Нагрузочное Характеристика Функциос разработкой полноты тестирования Нагрузочное нальное специальных ПС Тестирование некоторых функций ПС 1,0 – – (до 30 %) Тестирование значительной части 1,4 – – функций ПС (30 – 70 %) Тестирование всех 1,7 – – основных функций ПС Тестирование режимов – 1,5 3,5 с рабочей нагрузкой Тестирование режимов – 2,0 3,5 с пиковой нагрузкой Тестирование – 3,0 4,5 всех режимов

57 Таблица 5.25 Значения поправочного коэффициента, учитывающего характер поставки ПС Характер поставки Локальная поставка стандартного комплекта ПС или поставка в комплекте с несвязанными ПС Локальная поставка нестандартного комплекта ПС Поставка стандартного комплекта ПС в составе комплекса взаимосвязанных ПС Поставка нестандартного комплекта ПС в составе комплекса взаимосвязанных ПС Поставка комплекта ПС как компонента системы обработки информации (СОИ), не связанного с другими компонентами Поставка комплекта ПС как компонента СОИ, связанного с другими компонентами поставки Поставка комплекта ПС как компонента СОИ, связанного с другими компонентами поставки и с уже функционирующими компонентами СОИ

Кхп 1,0 1,2 1,4 1,6 1,7 1,8 1,9 Таблица 5.26

Значения поправочного коэффициента, учитывающего уровень повышения сложности ПС Показатель повышения сложности Ксл 1 2 Код без циклов, с небольшим количеством невложенных структурированных операторов: DO, CASE, IF-THEN-ELSE. Упрощенная схема взаимодействия модулей посредством вызова процедур и упрощенных сценариев Вычисление упрощенных выражений: например, A = B + C · (D – E) Упрощенные операторы чтения, записи с простыми форматами Простые массивы в основной памяти. Простые запросы на обновление Простые формы, генераторы отчетов

0,73

58 Продолжение табл. 5.26 1 2 Простое вложение структурированных операторов. Применение в основном простых предикатов Вычисление выражений средней сложности (одномерные массивы) Не требуется никакой информации о характеристиках конкретного типа процессоров или устройств ввода/вывода. Ввод/вывод осуществляется 0,8 на уровне команд GET/PUT Использование единственного файла без изменения структуры данных, без редактирования. Промежуточные файлы не используются. Запросы на обновление и запросы SQL умеренной сложности Использование простых средств построения интерфейса пользователя Применение в основном простого вложения и нескольких средств межмодульного взаимодействия, логических таблиц, простых функций обратного вызова или обмена сообщениями, включая распределенную обработку на основе промежуточного ПО Использование стандартных математических и статистических процедур. Основные операции с матрицами/векторами 1,0 Операции ввода/вывода включают выбор устройства, проверку его состояния и обработку ошибок Многофайловый ввод и однофайловый вывод. Простые структурные изменения, простые правки. Сложные запросы на обновление и запросы SQL. Использование простых (стандартных) элементов управления Многократное вложение структурированных операторов с множеством составных предикатов. Управление очередью и стеком. Однородная распределенная 1,17 обработка. Мягкие требования к режиму однопроцессорной обработки в реальном времени Базовые элементы численного анализа: многомерная интерполяция, обыкновенные дифференциальные уравнения, простые случаи усечения и округления

59 Окончание табл. 5.26 1 2 Операции ввода/вывода на физическом уровне (трансляция физических адресов хранения данных; операции поиска, чтения, и т.д.). Оптимизированное совмещение ввода/вывода Простые триггеры, активизируемые содержанием потоков данных. Сложное реструктурирование данных Разработка новых элементов управления и усовершенствование существующих. Простой голосовой ввод/вывод, мультимедиа Использование методов написания программ на основе рекурсии и многократного входа в программу. Обработка прерываний фиксированного приоритета, синхронизация задач, сложные функции обратного вызова, разнородная распределенная обработка. Жесткие требования к режиму однопроцессорной обработки в реальном времени Сложный, но структурированный численный анализ, матричные уравнения, близкие к сингулярным, дифференциальные уравнения в частных производных. Простое распараллеливание 1,34 Процедуры для определения, обработки и маскирования прерываний. Управление каналом связи. Встроенные системы с определенными требованиями к производительности Управление распределенными базами данных. Сложные триггеры. Оптимизация поиска. 2D/3D графика средней сложности, динамическая графика, мультимедиа Сложное управление ресурсами с динамически изменяющимися приоритетами. Управление на уровне микрокоманд. Жесткие требования к режиму распределенной обработки Сложный и неструктурированный численный анализ: высокоточный анализ стохастических данных. Сложное распараллеливание Написание управляющего кода, работающего синхронно 1,74 с устройством, программирование на уровне микроопераций. Встроенные системы, критичные к производительности Сильносвязанные динамические реляционные и объектные структуры. Речевое управление данными Сложная мультимедийная информация, виртуальная реальность, интерфейс речевого управления

60 5.3.2. Порядок расчета трудоемкости сопровождения ПС 5.3.2.1. Трудоемкость выполнения работы «Подготовка процесса» Содержание работы (перечень задач): 1) разработка, документальное оформление и выполнение плана и процедуры для проведения работ и задач процесса сопровождения; 2) определение процедур для получения, документирования и контроля сообщений о возникающих проблемах и заявок на внесение изменений от пользователей; обеспечение обратной связи с пользователями; 3) реализация процесса управления конфигурацией для управления изменениями существующей системы. Трудоемкость выполнения работы «Подготовка процесса» (Тпп) в чел.-дн. определяется по формуле Тпп = Ксл · Кан · Куч · Нвр.пп , где Ксл – коэффициент, учитывающий сложность ПС (табл. 5.7); Кан – коэффициент, учитывающий наличие аналогов данного ПС (табл. 5.20); Куч – коэффициент, характеризующий степень участия службы сопровождения в разработке ПС (табл. 5.21); Нвр.пп – норма времени на выполнение работы «Подготовка процесса» (табл. 5.27). 5.3.2.2. Трудоемкость выполнения работы «Анализ проблем и изменений» Содержание работы (перечень задач): 1) анализ сообщения о проблеме или заявки на внесение изменений; 2) верификация возникшей проблемы; 3) разработка вариантов реализации изменений; 4) документальное оформление сообщения о проблеме или заявки на внесение изменения; результатов их анализа и вариантов реализации изменений; 5) получение согласования выбранного варианта реализации изменения в соответствии с договором. Трудоемкость задачи «Анализ сообщения о проблеме или заявки на внесение изменений» (Тан) в чел.-дн. рассчитывают по формуле Тан = Ксл ·Кхв · Куч · Нвр.ан , где Ксл – коэффициент, учитывающий сложность ПС (табл. 5.7); Кхв – коэффициент, учитывающий характер внедрения поставленного ПС (табл. 5.23); Куч – коэффициент, характеризующий степень участия службы сопровождения в разработке ПС (табл. 5.21); Нвр.ан – норма времени на выполнение задачи «Анализ сообщения о проблеме или заявки на внесение изменений» (табл. 5.28).

61 Трудоемкость задачи «Верификация возникшей проблемы» (Твер) в чел.-дн. рассчитывают по формуле Твер = Ксл · Кте · Куч · Нвр.вер , где Ксл – коэффициент, учитывающий сложность ПС (табл. 5.26); Кте – коэффициент, учитывающий полноту тестирования (табл. 5.24); Куч – коэффициент, характеризующий степень участия службы сопровождения в разработке ПС (табл. 5.21); Нвр.вер – норма времени на выполнение задачи «Верификация возникшей проблемы» (табл. 5.29). Трудоемкость задачи «Разработка вариантов реализации изменений» (Твар) в чел.-дн. определяют по формуле Твар = Кхв · Куч ·Ксл· Нвр.вар , где Кхв – коэффициент, учитывающий характер внедрения поставленного ПС (табл. 5.23); Куч – коэффициент, характеризующий степень участия службы сопровождения в разработке ПС (табл. 5.21); Ксл – коэффициент, учитывающий сложность ПС (табл. 5.26); Нвр.вар – норма времени на выполнение задачи «Разработка вариантов реализации изменений» (табл. 5.30). Суммарная трудоемкость задач «Документальное оформление сообщения о проблеме или заявки на внесение изменения; результатов их анализа и вариантов реализации изменений» и «Получение согласования выбранного варианта реализации изменения в соответствии с договором» (Тсогл) является величиной постоянной: Тсогл = 5 чел.-дн. 5.3.2.3.Трудоемкость выполнения работы «Внесение изменений» Содержание работ (перечень задач): 1) анализ и определение перечней программ и документов, требующих изменения; документальное оформление результатов; 2) реализация процесса разработки для внесения изменений. Развитие ПС выполняется в рамках данной работы. Трудоемкость задачи «Анализ и определение перечней программ и документов, требующих изменения; документальное оформление результатов» определяют по формуле Тдр = Куч · Ксл · Нвр.ан , где Куч – коэффициент, учитывающий степень участия службы сопровождения в разработке ПС (табл. 5.21); Ксл – коэффициент, учитывающий сложность ПС (табл. 5.26); Нвр.ан – норма времени на выполнение задачи «Анализ и определение перечней программ и документов, требующих изменения; документальное оформление результатов» (табл. 5.31). Трудоемкость задачи «Реализация процесса разработки для внесения изменений» (Траз) определяют по формуле

62 Траз = Краз · Куч ·Ксл· Нвр.раз , где Краз – коэффициент, учитывающий язык программирования и другие средства разработки ПС (табл. 5.22); Куч – коэффициент, учитывающий степень участия службы сопровождения в разработке ПС (табл. 5.21); Ксл – коэффициент, учитывающий сложность ПС (табл. 5.26); Нвр.раз – норма времени на реализацию процесса разработки (табл. 5.32). Трудоемкость реализации процесса разработки зависит от объема доработок, который определяется путем экспертных оценок с привлечением специалистов службы сопровождения, участвовавших в испытаниях ПС. На объем доработок влияют такие факторы, как количество пользователей и частота изменений ПС (в случае смены требований законодательства, изменения технологии и т.п.). Как правило, объем доработок не должен превышать 20 % объема ПС. 5.3.2.4. Трудоемкость выполнения работы «Проверка и приемка при сопровождении» Содержание работ (перечень задач): 1) проверка внесенного изменения в целях подтверждения работоспособности измененного ПС; 2) получение подтверждения правильности внесенного изменения от организации-заказчика. Трудоемкость задачи «Проверка внесенного изменения в целях подтверждения работоспособности измененного ПС» (Тпи) определяют по формуле Тпи = Кте · Кхв · Ксл · Нвр.пи , где Кте – коэффициент, учитывающий полноту тестирования (табл. 5.26); Кхв – коэффициент, учитывающий характер внедрения поставленного ПС (табл. 5.23); Ксл – коэффициент, учитывающий сложность ПС (табл. 5.26); Нвр.пи – норма времени на выполнение задачи «Проверка внесенного изменения в целях подтверждения работоспособности измененного ПС» (табл. 5.33). Трудоемкость задачи «Получение подтверждения правильности внесенного изменения от организации-заказчика» (Тпод) является величиной постоянной: Тпод = 5 чел.-дн. 5.3.2.5. Трудоемкость выполнения работы «Перенос» Содержание работы: 1) проверка соответствия переносимого ПС стандарту ИСО/МЭК 12207-99; 2) разработка плана переноса; 3) уведомление пользователей о планах и работах по переносу;

63 4) обучение специалистов пользователя работе в новой среде; 5) архивация прежних программ и документации; 6) анализ влияния перехода к новой среде. Суммарная трудоемкость задач «Проверка соответствия переносимого ПС стандарту ИСО/МЭК 12207-99» и «Разработка плана переноса» (Тпп) в чел.-дн. определяют по формуле Тпп = Кхп · Нвр.п , где Кхп – коэффициент, учитывающий характер поставки ПС (табл. 5.25); Нвр.п – норма времени на выполнение задач «Проверка соответствия переносимого ПС стандарту ИСО/МЭК 12207-99» и «Разработка плана переноса» (табл. 5.34). Трудоемкость задачи «Уведомление пользователей о планах и работах по переносу» (Туп) в чел.-дн. является величиной постоянной: Туп = 1,0 чел.-дн. Трудоемкость задачи «Обучение специалистов пользователя работе в новой среде» (Тоб) в чел.-дн. рассчитывают по формуле Тоб = Ксл · Нвр.об , где Ксл – коэффициент, учитывающий сложность ПС (табл. 5.26); Нвр.об – норма времени на выполнение задачи «Обучение специалистов пользователя работе в новой среде» (табл. 5.16). Трудоемкость задачи «Архивация прежних программ и документации» определяют по формуле Тар = Нвр.ар , где Нвр.ар – норма времени на архивирование (табл. 5.17). Трудоемкость задачи «Анализ влияния перехода к новой среде» (Тап) в чел.-дн. рассчитывают по формуле Тап = Ксл · Нвр.ап , где Ксл – коэффициент, учитывающий сложность ПС (табл. 5.7); Нвр.ан – норма времени на выполнение задачи «Анализ влияния перехода к новой среде» (табл. 5.37). 5.3.2.6. Трудоемкость выполнения работы «Снятие с эксплуатации» Содержание работ (перечень задач): 1) разработка и оформление плана снятия с эксплуатации; 2) уведомление пользователя о планах и работах по снятию с эксплуатации; 3) обучение пользователей в течение периода параллельной эксплуатации прежнего и нового программных средств; 4) архивация связанной с прежним объектом документации разработки, журналов регистрации и программ. Трудоемкость задачи «Разработка и оформление плана снятия с эксплуатации» (Тпсэ) в чел.-дн. рассчитывают по формуле Тпсэ = Кхп · Нвр.псэ , где Кхп – коэффициент, учитывающий характер поставки ПС (табл. 5.25);

64 Нвр.псэ – норма времени на выполнение задачи «Разработка плана снятия с эксплуатации» (табл. 5.38). Трудоемкость задачи «Уведомление пользователя о планах и работах по снятию с эксплуатации» является величиной постоянной: Тупi = 1,0 чел.-дн. Трудоемкость задачи «Обучение пользователей в течение периода параллельной эксплуатации прежнего и нового программных средств» (Тобн) определяют по формуле Тобн = Ксл · Нвр.обн , где Ксл – коэффициент, учитывающий сложность ПС (табл. 5.26); Нвр.обн – норма времени на выполнение задачи «Обучение пользователей в течение периода параллельной эксплуатации прежнего и нового программных средств» (табл. 5.39). Трудоемкость задачи «Архивация связанной с прежним объектом документации разработки, журналов регистрации и программ» определяют по формуле Тар = Нвр.ар , где Нвр.ар – норма времени на выполнение задачи «Архивация связанной с прежним объектом документации разработки, журналов регистрации и программ» (табл. 5.36). 5.3.3. Нормативная часть Методика оценки трудоёмкости сопровождения ПС предназначена для нормирования труда специалистов, занятых сопровождением ПС, для определения их численности, а также для расчета трудоемкости сопровождения ПС. Эта часть рекомендуется для применения в тех организациях (независимо от их ведомственной подчиненности и формы собственности), которые ведут фонды ПС, осуществляют поставки ПС и оказывают другим организациям научно-технические услуги по внедрению и сопровождению ПС. Методика базируется на стандартных процессах жизненного цикла ПС в соответствии со стандартами ГОСТ Р ИСО/МЭК 12207-99 и ИСО 9000-3-91. Методика охватывает следующие ПС (по Общероссийскому классификатору продукции): 501000 – Системные программные средства. 502000 – Программные средства общего назначения. 503000 – Прикладные программные средства для научных исследований. 506000 – Прикладные программные средства для решения организационно-экономических задач. 507000 – Прикладные программные средства учебного назначения. 509000 – Программные средства прочие*. * По данной группе применимость методики определяется индивидуально на основе каталога функций.

65 Нормы времени, введенные в настоящей методике, рассчитаны на одно программное средство и указаны в человеко-днях при пятидневной рабочей неделе с продолжительностью рабочего дня 8 часов. В случае изменения продолжительности рабочего дня нормы времени должны быть соответственно пересчитаны. 5.3.3.1. Нормы времени выполнения работы «Подготовка процесса» приведены в табл. 5.27. Таблица 5.27 Зависимость норм времени на выполнение работы «Подготовка процесса» от объемов документации и программ Норма времени на работу «Подготовка процесса», чел.-дн., в разрезе объемов программ, выраженных в ТСИ*

Объем документации, тыс. строк

До 10**

10 – 30

30 – 50

50 – 70

70 – 90

90 – 110

110 – 130

130 – 150

150 – 170

До 1 Св. 1 до 2 Св. 2 до 4 Св. 4 до 6 Св. 6 до 8 Св. 8 до 10 Св.10 до 12 Св.12 до 14 Св.14 до 16 Св.16 до 18 Св.18 до 20 Св.20 до 22 Св.22 до 24 Св.24 до 26 Св.26 до 28 Св.28 до 30 Св.30 до 32 Свыше 32

8 9 12 15 20 23 27 33 35 40 42 47 51 55 59 63 67 70

8 10 13 16 21 24 28 34 36 41 43 48 52 57 61 65 70 75

9 13 14 18 22 25 29 35 37 42 44 50 54 60 65 69 73 78

9 14 15 19 23 26 30 36 38 43 45 52 56 62 70 73 78 87

10 14 16 20 24 27 32 37 40 44 47 54 59 65 73 78 82 90

10 15 17 21 25 29 34 38 42 45 49 56 62 69 77 82 86 93

11 16 18 22 26 30 36 39 44 47 52 60 66 73 81 89 90 96

11 16 19 23 27 32 37 41 46 50 55 63 69 76 84 91 96 98

12 17 20 24 29 34 39 43 48 52 59 66 72 80 87 95 100 105

Свы -ше 170 13 15 21 25 31 35 41 45 50 55 62 69 76 82 90 98 105 110

* ТСИ – тысячи строк исходного текста. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно». 5.3.3.2. Нормы времени на выполнение работы «Анализ проблем и изменений» Нормы времени на выполнение задачи «Анализ сообщения о проблеме или заявки на внесение изменений» Нвр.ан приведены в табл. 5.28.

66 Таблица 5.28 Зависимость норм времени на выполнение задачи «Анализ сообщения о проблеме или заявки на внесение изменений» (Нвр.ан)от объемов документации и программ Объем документации, тыс. строк До 1 Св. 1 до 2 Св. 2 до 4 Св. 4 до 6 Св. 6 до 8 Св. 8 до 10 Св. 10 до 12 Св. 12 до14 Св. 14 до 16 Св.16 до 18 Св.18 до 20 Св. 20 до 22 Св. 22 до 24 Св. 24 до 26 Св. 26 до 28 Св. 28 до 30 Св. 30 до 32

6,0

Норма времени, чел.-дн., в разрезе объемов программ, выраженных в ТСИ* 130 150 10 – 30 – 50 – 70 – 90 – 110 – – – 30 50 70 90 110 130 150 170 4,8 5,0 5,2 5,4 5.6 5.8 6.0 6.2

4,8

5,1

5,3

5,5

5,7

5.9

6.1

6.3

6.5

6.5

5,2

5,8

6,0

6,4

6,8

7.0

7.4

7.6

7.8

7.2

5,9

6,4

6,6

7,0

7,4

7.6

8.0

8.2

8.5

8.3

6,5

7,1

7,3

7,5

8,0

8.1

8.6

8.8

9.1

9.4

7,2

7,5

8,0

8,4

8,8

9.0

9.3

9.6

9.8

10.1

8,0

8,4

8,6

8,9

9,1

9.4

9.7

10.0

10.2

10.7

8,9

9,1

9,3

9,5

10,0

10.3

10.6

10.8

11.1

11.4

9,6

9,8

10,0

10,4

10,7

11.0

11.3

11.5

11.8

12.1

10,3

10,4

10,5

11,0

11,3

11.6

11.9

12.1

12.4

12.7

11,0

11,1

11,3

11,7

12,1

12.3

12.5

12.7

13.0

13.3

11,7

11,8

12,0

12,4

12,8

13.0

13.2

13.5

13.7

14.1

12,3

12,4

12,6

12,8

13,0

13.2

13.6

13.9

14.1

14.5

13,0

13,1

13,3

13,5

13,8

14.0

14.3

14.6

15.0

15.2

13,5

13,6

13,7

13,8

14,0

14.4

14.8

15.1

15.5

16.0

14,0

14,1

14,2

14,4

14,6

15.0

15.4

15.8

16.1

16.6

14,7

15,0

15,3

15,5

15,7

15.9

16.1

16.5

16.8

17.2

До 10**

Свыше 170 9.0

* ТСИ – тысячи строк исходного текста. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

67 5.3.3.3. Нормы времени на выполнение задачи «Верификация возникшей проблемы» (Нвр.вер) приведены в табл. 5.29 Таблица 5.29 Таблица зависимости норм времени на выполнение задачи «Верификация возникшей проблемы» от объема программ Объем документации, тыс. строк

Норма времени, чел.-дн., в разрезе объемов программ, выраженных в ТСИ* До 10 – 30 – 50 – 70 – 90 – 110 – 130 – 150 – Свыше 10** 30 50 70 90 110 130 150 170 170

До 1

9.0

9.6

10.0 10.4 10.8 11.2

11.6

12.0

12.4

12.8

Св. 1 до 2

9.6

10.1 10.5 11.0 11.4 11.8

12.2

12.6

13.0

13.5

Св. 2 до 4

10.4

11.6 12.0 12.7 13.6 14.0

14.8

15.2

15.6

16.0

Св. 4 до 6

11.8

12.7 13.2 14.0 14.8 15.2

16.0

16.5

17.0

17.5

Св. 6 до 8

13.0

14.2 14.7 15.0 16.0 16.2

17.2

17.6

18.2

18.8

Св. 8 до 10

14.4

15.0 16.0 16.8 17.6 18.0

18.6

19.3

19.8

20.2

Св. 10 до 12

16.0

16.8 17.2 17.8 18.2 18.4

19.4

20.0

20.4

21.4

Св. 12 до 14

17.8

18.2 18.6 19.0 20.0 20.6

21.2

21.8

22.2

22.8

Св. 14 до 16

19.2

19.6 20.0 20.8 21.4 22.0

22.6

23.0

23.6

24.2

Св. 16 до 18

20.6

20.8 21.0 22.0 21.6 23.1

23.8

24.2

25.0

25.5

Св. 18 до 20

22.1

22.5 22.9 23.4 24.1 24.6

25.0

25.5

26.0

26.7

Св. 20 до 22

23.3

23.6 24.1 24.8 25.5 26.0

26.5

27.0

27.7

28.2

Св. 22 до 24

24.6

24.9 25.2 25.8 26.0 26.4

27.1

27.8

28.3

29.0

Св. 24 до 26

26.0

26.2 26.7 27.0 27.5 28.0

28.5

29.1

30.0

30.4

Св. 26 до 28

27.0

27.3 27.5 27.7 28.0 28.4

29.6

30.2

31.0

32.0

Св. 28 до 30

28.0

28.3 28.5 28.9 29.5 30.0

30.8

31.9

32.3

33.1

Св. 30 до 32

29.4

30.0 30.6 31.0 31.4 31.7

32.4

33.0

33.6

34.5

Свыше 32

30.0

30.4 30.9 31.2 31.7 32.0

32.4

33.2

34.1

35.0

*

ТСИ – тысячи условных машинных команд. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

68 5.3.3.4. Нормы времени на выполнение задачи «Разработка вариантов реализации изменений» Нвр.вар приведены в табл. 5.30 Таблица 5.30 Зависимость норм времени на выполнение задачи «Разработка вариантов реализации изменений» (Нвр.вар) от объемов документации и программ Норма времени, чел.-дн., в разрезе объемов программ, выраженных в ТСИ*

Объем документации, тыс. строк

До 10**

10 – 30

30 – 50

50 – 70

70 – 90

90 – 110

110 – 130

130 – 150

150 – 170

Свыше 170

До 1

5

5.7

6.5

7.2

8.0

8.8

9.5

10.3

11.2

12.0

Св. 1 до 2

5.2

6.0

6.7

7.5

8.2

9.0

9.7

10.5

11.4

12.4

Св. 2 до 4

5.3

6.1

6.8

7.7

8.4

9.1

10.0

10.7

11.6

12.9

Св. 4 до 6

5.7

6.4

7.2

8.0

8.7

9.4

10.2

11.0

12.0

13.3

Св. 6 до 8

6.0

6.8

7.5

8.2

9.0

9.7

10.6

11.4

12.6

13.7

Св. 8 до 10

6.2

7.0

7.7

8.6

9.4

10.1

11.0

11.9

13.0

14.1

Св. 10 до 12

6.5

7.2

8.0

8.9

9.7

10.3

11.5

12.6

13.7

14.5

Св. 12 до 14

6.7

7.5

8.2

9.1

10.0

10.5

11.7

12.8

13.9

14.9

Св. 14 до 16

7.0

7.7

8.5

9.3

10.2

11.0

11.9

13.0

14.5

15.4

Св. 16 до 18

7.2

8.0

8.8

9.5

10.4

11.3

12.2

13.2

14.7

15.9

Св. 18 до 20

7.5

8.3

9.0

9.9

10.9

11.5

12.5

13.5

14.8

16.3

Св. 20 до 22

7.7

8.5

9.3

10.2

11.1

12.0

13.0

14.1

15.5

16.8

Св. 22 до 24

8.0

8.8

9.6

10.4

11.3

12.2

13.5

14.7

16.0

17.3

Св. 24 до 26

8.2

9.0

9.8

10.6

11.6

12.6

13.6

14.9

16.5

17.7

Св. 26 до 28

8.5

9.3

10.0

10.9

11.9

13.1

14.3

15.9

17.0

18.1

Св. 28 до 30

8.7

9.5

10.3

11.5

12.7

14.0

15.4

16.7

17.1

18.5

Св. 30 до 32

9.0

9.8

10.7

11.7

12.9

14.2

15.7

16.9

17.9

19.0

Свыше 32

9.5

10.3

11.0

11.9

12.8

14.4

15.9

17.2

18.4

19.5

* ТСИ – тысячи строк исходного текста. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

69 5.3.3.5. Нормы времени для работы «Внесение изменений» Нормы времени на выполнение задачи «Анализ и определение перечней программ и документов, требующих изменения; документальное оформление результатов» (Нвр.пер) приведены в табл. 5.31. Таблица 5.31 Зависимость норм времени на выполнение задачи «Анализ и определение перечней программ и документов, требующих изменения» (Нвр.пер) от объемов документации и программ Объем документации, тыс. строк

Нормы времени на определение перечней изменяемых программ и документов (Нвр.пер), чел.-дн., в разрезе объемов программ, выраженных в ТСИ*

До 10**

10 – 30

30 – 50

50 – 70

70 – 90

90 – 110

110 – 130

130 – 150

150 – 170

Свыше 170

До 1

4.0

5.2

6.4

7.6

8.8

10.0

11.1

12.3

13.6

15.0

Св. 1 до 2

4.2

5.4

6.6

7.8

9.0

10.2

11.3

12.6

13.8

15.2

Св. 2 до 4

4.4

5.6

6.8

8.0

9.2

10.4

11.5

12.8

14.1

15.4

Св. 4 до 6

4.6

5.8

7.0

8.2

9.4

10.6

11.8

13.1

14.4

15.6

Св. 6 до 8

4.8

6.0

7.2

8.4

9.6

10.8

12.0

13.4

14.5

15.8

Св. 8 до 10

5.1

6.3

7.5

8.7

9.9

11.1

12.3

13.7

14.8

16.1

Св.10до 12

5.3

6.5

7.7

8.9

10.1

11.3

12.5

13.8

15.1

16.3

Св.12 до 14

5.5

6.7

7.9

9.1

10.3

11.5

12.7

14.0

15.3

16.5

Св.14 до 16

5.7

6.9

8.1

9.3

10.5

11.7

12.9

14.2

15.5

16.7

Св.16 до 18

5.9

7.1

8.3

9.5

10.7

11.9

13.1

14.4

15.7

16.9

Св.18 до 20

6.2

7.4

8.6

9.8

11.0

12.2

13.4

14.7

15.9

17.2

Св.20 до 22

6.4

7.7

9.1

10.4

11.7

13.0

14.3

15.6

16.9

18.0

Св.22 до 24

6.6

7.9

9.3

10.6

11.9

13.2

14.6

15.9

17.1

18.4

Св.24 до 26

6.8

8.1

9.4

10.9

12.2

13.5

14.8

16.1

17.3

18.7

Св. 26 до28

7.1

8.4

9.7

11.0

12.4

13.7

14.8

16.1

17.5

19.0

Св. 28 до30

7.4

8.7

10.0

11.3

13.6

15.3

16.6

17.9

19.2

19.6

Св. 30 до32

7.7

9.0

10.3

11.6

13.9

15.6

16.9

18.2

19.5

20.7

Свыше 32

8.2

9.4

10.7

12.0

15.1

16.4

17.7

19.0

21.0

22.0

* ТСИ – тысячи строк исходного текста. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

70 Нормы времени на выполнение задачи «Реализация процесса разработки для внесения изменений» (Нвр.раз) приведены в табл. 5.32. Таблица 5.32 Таблица зависимости норм времени на выполнение задачи «Реализация процесса разработки для внесения изменений» (Нвр.раз) от объема доработок Объем дополнительных Норма времени, № нормы разработок, СИ* чел.-дн. 100 7.0 1 200 11.0 2 300 17.0 3 400 23.0 4 500 35.0 5 600 38.0 6 800 53.0 7 1000 65.0 8 1200 86.0 9 1400 97.0 10 1600 111.0 11 1800 126.0 12 2000 141.0 13 2500 181.0 14 3000 221.0 15 3500 263.0 16 4000 302.0 17 4500 344.0 18 5000 389.0 19 6000 443.0 20 7000 525.0 21 8000 607.0 22 9000 704.0 23 10000 777.0 24 15000 1213.0 25 20000 1665.0 26 25000 2128.0 27 30000 2600.0 28 35000 3080.0 29 40000 3567.0 30 * СИ – строки исходного текста.

71 5.3.3.6. Нормы времени на выполнение работы «Проверка и приемка при сопровождении» Нормы времени на выполнение задачи «Проверка внесенного изменения в целях подтверждения работоспособности измененного ПС» (Нвр.пи) приведены в табл. 5.33. Таблица 5.33 Зависимость норм времени на выполнение задачи «Проверка внесенного изменения в целях подтверждения работоспособности измененного ПС» (Нвр.пи) от объема программ Норма времени, Объем программ, ТСИ* чел.-дн. До 10 3.5 Свыше 10 до 20 3.7 Свыше 20 до 30 3.9 Свыше 30 до 40 4.0 Свыше 40 до 50 4.1 Свыше 50 до 60 4.2 Свыше 50 до 70 4.3 Свыше 70 до 80 4.4 Свыше 80 до 90 4.5 Свыше 90 до 100 4.6 Свыше 100 до 110 4.8 Свыше 110 до 120 4.9 Свыше 120 до 130 5.0 Свыше 130 до 140 5.1 Свыше 140 до 150 5.3 Свыше 150 до 160 5.4 Свыше 160 до 170 5.6 Свыше 170 до 180 5.7 Свыше 180 до 190 5.9 Свыше 190 6.00 *ТСИ – тысячи строк исходного текста. 5.3.3.7. Нормы времени на выполнение работы «Перенос» Нормы времени на выполнение задач «Проверка соответствия переносимого ПС стандарту ИСО/МЭК 12207-99» и «Разработка плана переноса» Нвр.пп приведены в табл. 5.34.

72 Таблица 5.34 Зависимость норм времени на выполнение задач «Проверка соответствия переносимого ПС стандарту ИСО/МЭК 12207-99» и «Разработка плана переноса» Нвр.п от объемов документации и программ Норма времени, чел.-дн., в разрезе объемов программ, выраженных в ТСИ*

Объем документации, тыс. строк

До 10**

10 – 30

30 – 50

50 – 70

70 – 90

90 – 110

110 – 130

130 – 150

150 – 170

До 1

10.0

11.5

13.0

14.5

16.0

17.5

19.0

20.5

22.0

Свыше 170 24.0

Св. 1 до 2

10.4

11.9

13.4

14.9

16.4

17.9

19.4

21.0

22.5

24.5

Св. 2 до 4

10.8

12.3

13.6

15.3

16.8

18.3

19.9

21.5

23.0

25.0

Св. 4 до 6

11.2

12.4

13.8

15.4

16.9

18.5

20.0

21.7

23.5

25.5

Св. 6 до 8

11.6

13.1

14.6

16.1

17.6

19.1

21.0

22.5

24.0

26.0

Св. 8 до 10 Св. 10 до 12 Св. 12 до 14 Св. 14 до 16 Св. 16 до 18 Св. 18 до 20 Св. 20 до 22 Св. 22 до 24 Св. 24 до 26 Св. 26 до 28 Св. 28 до 30 Св. 30 до 32 Свыше 32

12.0

13.5

15.0

16.5

18.0

19.5

21.4

22.9

24.5

26.5

12.4

13.9

15.4

16.9

18.4

19.9

21.5

23.0

25.0

27.0

12.8

14.3

15.8

17.2

18.7

20.2

21.8

23.2

25.5

27.5

13.1

14.6

16.1

17.6

19.1

20.6

22.1

23.9

26.0

28.0

13.6

15.1

16.6

18.1

19.6

21.1

22.6

24.5

26.5

28.5

14.0

15.5

17.0

18.5

20.0

21.5

23.0

25.0

27.0

29.0

14.4

15.9

17.4

18.9

20.4

21.9

23.4

25.5

27.5

29.5

14.8

16.3

17.8

19.3

20.8

22.2

23.9

26.0

28.0

30.0

15.2

16.7

18.2

19.7

21.2

22.7

24.7

26.5

28.5

30.5

15.6

17.1

18.6

20.1

21.6

23.1

25.0

27.0

29.0

31.0

16.0

17.5

19.0

20.5

22.0

23.5

25.5

27.5

29.5

31.5

16.4

17.9

19.4

20.9

22.4

24.0

26.0

28.0

30.0

32.0

17.0

18.5

20.0

21.5

23.0

24.5

26.5

28.5

30.5

32.5

* ТСИ – тысячи строк исходного текста. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

73 5.3.3.8. Нормы времени на выполнение задачи «Обучение специалистов пользователя работе в новой среде» Нвр.об приведены в табл. 5.35. Таблица 5.35 Зависимость норм времени на выполнение задачи «Обучение специалистов пользователя работе в новой среде» (Нвр.об) от объемов документации и программ Объем Норма времени, чел.-дн., докув разрезе объемов программ, выраженных в ТСИ* менСвытации, До 10 – 30 – 50 – 70 – 90 – 110 – 130 – 150 – ше 10** 30 50 70 90 110 130 150 170 тыс. 170 строк До 1

15.5 15.8 16.1 16.4 16.8

17.2

17.5

17.9

18.1

18.5

Св. 1 до 2

15.8 16.2 16.6 16.9 17.2

17.5

17.9

18.3

18.5

18.6

Св. 2 до 4

16.1 16.2 16.4 16.5 16.7

17.4

18.0

18.5

18.6

18.9

Св. 4 до 6

16.5 16.5 16.7 16.9 17.3

17.7

18.1

18.3

18.6

19.0

Св. 6 до 8

16.7 17.0 17.2 17.5 17.8

18.0

18.3

18.5

18.8

19.1

Св. 8 до 10

17.1 17.3 17.7 17.9 18.2

18.4

18.7

18.9

19.0

19.3

Св. 10 до 12

17.4 17.6 17.8 18.1 18.3

18.6

18.8

19.1

19.3

19.4

Св. 12 до 14

18.7 18.8 18.9 19.0 19.1

19.2

19.3

19.4

19.5

19.6

Свыше 14

18.8 18.8 18.9 19.0 19.1

19.2

19.4

19.6

19.8

20.0

*

ТСИ – тысячи строк исходного текста . Интервалы в графах с 3-й по 10-ю следует понимать так: запись типа «10 – 30» означает «свыше 10 до 30 включительно». **

74 5.3.3.9. Нормы времени на выполнение задачи «Архивация прежних программ и документации» Нвр.ар приведены в табл. 5.36 Таблица 5.36 Зависимость норм времени на выполнение задачи «Архивация прежних программ и документации» (Нвр.ар) от объемов документации и программ Объем документации, тыс. строк

Норма времени, чел.-дн., в разрезе объемов программ, выраженных в ТСИ* До 10**

10 – 30

30 – 50

50 – 70

70 – 90

90 – 110

110 – 130

130 – 150

150 – 170

Свыше 170

До 1

8.0

9.1

10.7

12.0

13.9

15.5

17.1

18.7

20.3

21.0

Св. 1 до 2

8.4

9.2

10.8

12.4

14.0

15.6

17.2

18.8

20.4

21.7

Св. 2 до 4

8.6

9.4

11.0

12.7

14.2

15.8

17.4

19.0

20.7

21.9

Св. 4 до 6

8.7

9.5

11.1

12.7

14.3

15.9

17.5

19.1

20.7

22.1

Св. 6 до 8

9.0

9.7

11.3

13.0

14.2

16.2

17.8

19.4

21.0

22.4

9.2

10.0

11.6

13.2

14.3

16.4

18.0

19.7

21.2

22.8

9.3

10.1

11.7

13.3

14.5

16.0

18.1

19.5

21.5

22.9

9.5

10.3

11.9

13.5

14.8

16.7

18.3

19.8

21.9

23.1

9.7

10.5

12.1

13.7

15.0

16.9

18.5

19.9

22.0

23.3

9.9

10.7

12.3

13.9

15.1

17.1

18.7

20.1

22.1

23.5

10.1

10.9

12.5

14.1

15.3

17.3

18.9

20.3

22.2

23.7

10.7

11.1

12.6

14.3

15.9

17.5

19.1

20.6

22.3

23.9

11.5

11.9

13.5

15.1

16.7

18.3

20.0

21.6

23.5

24.7

12.4

12.8

14.1

15.9

17.5

19.2

20.8

22.4

24.7

25.6

13.3

13.6

15.1

16.8

18.4

20.0

21.6

23.2

25.0

26.0

14.1

14.5

15.9

17.7

19.3

20.9

22.5

24.1

25.7

26.2

14.6

15.3

16.9

18.5

20.1

21.7

23.3

24.9

26.5

26.7

15.1

16.1

17.7

19.3

20.9

22.5

24.1

25.7

27.3

27.0

Св. 8 до 10 Св. 10 до 12 Св. 12 до 14 Св. 14 до 16 Св. 16 до 18 Св. 18 до 20 Св. 20 до 22 Св. 22 до 24 Св. 24 до 26 Св. 26 до 28 Св. 28 до 30 Св. 30 до 32 Свыше 32

* ТСИ – тысячи строк исходного текста. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

75 5.3.3.10. Нормы времени на выполнение задачи «Анализ влияния перехода к новой среде» Нвр.ан приведены в табл. 5.37. Таблица 5.37 Зависимость норм времени на анализ перехода к новой среде (Нвр.ан) от объемов документации и программ Норма времени, чел.-дн., в разрезе объемов программ, выраженных в ТСИ*

Объем документации, тыс. строк

До 10**

10 – 30

30 – 50

50 – 70

70 – 90

90 – 110

110 – 130

130 – 150

150 – 170

Свыше 170

До 1

5.5

5.8

6.0

7.2

7.4

7.6

8.8

9.0

9.2

10.0

Св. 1 до 2

5.8

6.1

6.3

7.5

7.7

7.9

8.1

9.3

9.5

10.5

Св. 2 до 4

6.2

6.8

7.0

8.4

8.8

9.0

9.4

9.6

10.8

11.2

Св. 4 до 6

6.9

7.4

7.6

9.0

9.4

9.6

10.0

10.2

11.5

12.3

Св. 6 до 8

7.5

8.1

8.3

8.5

10.0

10.1

10.6

11.8

12.1

13.4

Св. 8 до 10

8.2

8.5

9.0

9.4

10.8

11.0

11.3

11.6

12.8

14.1

9.0

9.4

9.6

9.9

11.1

11.4

11.7

12.0

13.2

14.7

9.9

10.1

10.3

10.5

12.0

12.3

12.6

12.8

14.1

15.4

10.6

10.8

11.0

11.4

12.7

13.0

13.3

13.5

14.8

16.1

11.3

11.4

11.5

12.0

13.3

13.6

13.9

14.1

15.4

16.7

12.0

12.1

12.3

12.7

13.1

14.3

14.5

14.7

16.0

17.3

12.7

12.8

13.0

13.4

13.8

15.0

15.2

16.5

17.7

18.1

13.3

13.4

13.6

13.8

14.0

15.2

15.6

16.9

18.1

18.5

14.0

14.1

14.3

15.5

15.8

16.0

16.3

17.6

19.0

19.2

15.5

15.6

15.7

15.8

16.0

16.4

16.8

18.1

19.5

20.0

15.0

15.1

15.2

15.4

16.6

17.0

17.4

18.8

20.1

20.8

15.7

16.0

16.3

16.5

16.7

17.3

18.1

18.5

20.8

21.2

16.0

16.2

16.4

16.6

16.8

18.0

18.2

19.6.

21.1

22.5

Св. 10 до 12 Св. 12 до 14 Св. 14 до 16 Св. 16 до 18 Св. 18 до 20 Св. 20 до 22 Св. 22 до 24 Св. 24 до 26 Св. 26 до 28 Св. 28 до 30 Св. 30 до 32 Свыше 32

* ТСИ – тысячи строк исходного текста. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

76 5.3.3.11. Нормы времени на выполнение работы «Снятие с эксплуатации» Нормы времени на выполнение задачи «Разработка и оформление плана снятия с эксплуатации» Нвр.псэ приведены в табл. 5.38. Таблица 5.38 Зависимость норм времени на выполнение задачи «Разработка и оформление плана снятия с эксплуатации » (Нвр.псэ) от объемов документации и программ Объем документации, тыс. строк До 1 Св. 1 до 2 Св. 2 до 4 Св. 4 до 6 Св. 6 до 8 Св. 8 до 10 Св. 10 до 12 Св. 12 до 14 Св. 14 до 16 Св. 16 до 18 Св. 18 до 20 Св. 20 до 22 Св. 22 до 24 Св. 24 до 26 Св. 26 до 28 Св. 28 до 30 Св. 30 до 32 Свыше 32

Норма времени, чел.-дн., в разрезе объемов программ, выраженных в ТСИ* До 10**

10 – 30

30 – 50

50 – 70

70 – 90

90 – 110

110 – 130

130 – 150

150 – 170

10.0 10.4 10.8 11.2 11.6 12.0

11.5 11.9 12.3 12.4 13.1 13.5

13.0 13.4 13.6 13.8 14.6 15.0

14.5 14.9 15.3 15.4 16.1 16.5

16.0 16.4 16.8 16.9 17.6 18.0

17.5 17.9 18.3 18.5 19.1 19.5

19.0 19.4 19.9 20.0 21.0 21.4

20.5 21.0 21.5 21.7 22.5 22.9

22.0 22.5 23.0 23.5 24.0 24.5

Свыше 170 24.0 24.5 25.0 25.5 26.0 26.5

12.4

13.9

15.4

16.9

18.4

19.9

21.5

23.0

25.0

27.0

12.8

14.3

15.8

17.2

18.7

20.2

21.8

23.2

25.5

27.5

13.1

14.6

16.1

17.6

19.1

20.6

22.1

23.9

26.0

28.0

13.6

15.1

16.6

18.1

19.6

21.1

22.6

24.5

26.5

28.5

14.0

15.5

17.0

18.5

20.0

21.5

23.0

25.0

27.0

29.0

14.4

15.9

17.4

18.9

20.4

21.9

23.4

25.5

27.5

29.5

14.8

16.3

17.8

19.3

20.8

22.2

23.9

26.0

28.0

30.0

15.2

16.7

18.2

19.7

21.2

22.7

24.7

26.5

28.5

30.5

15.6

17.1

18.6

20.1

21.6

23.1

25.0

27.0

29.0

31.0

16.0

17.5

19.0

20.5

22.0

23.5

25.5

27.5

29.5

31.5

16.4

17.9

19.4

20.9

22.4

24.0

26.0

28.0

30.0

32.0

17.0

18.5

20.0

21.5

23.0

24.5

26.5

28.5

30.5

32.5

* ТСИ – тысячи строк исходного текста. ** Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

77 5.3.3.12. Нормы времени на выполнение задачи «Обучение пользователей в течение периода параллельной эксплуатации прежнего и нового программных средств» Нвр.обн приведены в табл. 5.39. Таблица 5.39 Зависимость норм времени на выполнение задачи «Обучение пользователей в течение периода параллельной эксплуатации прежнего и нового программных средств» (Нвр.обн) от объемов документации и программ Норма времени, чел.-дн., в разрезе объемов программ, выраженных в ТСИ*

Объем документации, тыс. строк

До 10**

10 – 30

30 – 50

50 – 70

70 – 90

90 – 110

110 – 130

130 – 150

150 – 170

Свыше 170

До 1

17.5

18.0

18.5

19.0

19.5

20.0

20.5

21.0

21,5

22.0

Св. 1 до 2

18.5

19.0

19.5

20.0

20.5

21.0

21.5

22.0

22.5

23.0

Св. 2 до 4

19.5

20.0

20.5

21.0

21.5

22.0

22.5

23.0

23.5

24.0

Св. 4 до 6

20.5

21.0

21.5

22.0

22.5

23.0

23.5

24.0

24.5

25.0

Св. 6 до 8

21.5

22.0

22.5

23.0

23.5

24.0

24.5

25.0

25.5

26.0

22.5

23.0

23.5

24.0

24.5

25.0

25.5

26.0

26.5

27.0

23.5

24.0

24.5

25.0

25.5

26.0

26.5

27.0

27.5

28.0

24.5

25.0

25.5

26.0

26.5

27.0

27.5

28.0

28.5

29.0

25.5

26.0

26.5

27.0

27.5

28.0

28.5

29.0

29.5

30.0

Св. 8 до 10 Св. 10 до 12 Св. 12 до 14 Свыше 14 *

ТСИ – тысячи строк исходного текста. Запись типа «10 – 30» означает «свыше 10 до 30 включительно».

**

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

78 5.4. Методика прогнозирования стоимостных показателей информационных систем Различают методы прогнозирования: сопоставительно-аналоговый метод; метод экспертных оценок; метод статистического прогнозирования; нормативно-калькуляционный и сметно-калькуляционный методы. Сопоставительно-аналоговый метод основан на сопоставлении основных характеристик ИС и затрат на их обеспечение в проектируемых образцах и прототипах, связанных соотношением m C = Cп∑Кјβј , ј=0 где Cп − стоимость прототипа; Кј – переводные коэффициенты, Кј = Xј / Xјп , Xјп – значение j-й характеристики прототипа; βј – весовые коэффициенты, учитывающие долю затрат Сj на обеспечение j-й характеристики Xј разрабатываемой ИС; m – число основных характеристик. При этом методе за основные характеристики принимаются те, теснота связи которых со стоимостью наибольшая. В качестве показателя тесноты связи применяют парные, а иногда и множественные коэффициенты корреляции. Сущность 2-го и 3-го методов базируется на тех же правилах. Отличие статистического прогнозирования стоимости от прогнозирования других показателей состоит в выборе видов моделей, характеризующих зависимость затрат от характеристик ИС. Исходными данными при нормативно-калькуляционном методе являются сметные калькуляции по статьям затрат на сырьё и материалы, на покупные изделия и полуфабрикаты, на заработную плату. Сметно-калькуляционный метод состоит в расчёте затрат по установленным методикам с использованием сметной калькуляции на конкретный образец. Оба этих метода часто не могут быть использованы на ранних стадиях разработки, так как они требуют знания нормативных коэффициентов и сметных калькуляций, которых к этому времени может и не быть. Поэтому чаще применяют первые три метода, в первую очередь аналого-сопоставительный метод как наиболее апробированный и дающий приемлемую точность. Более подробно ознакомиться с ним можно в подразделе 6.3, выполняя лабораторный практикум.

79 5.5. Методика оценки уровня качества программных средств информационных систем Уровень качества ИС или отдельных её компонентов можно охарактеризовать одним из трёх способов: совокупностью относительных групповых показателей качества, отношением обобщённого показателя качества к соответствующему обобщённому базовому показателю, отнесением ИС или её компонентов к определённой категории качества. Выбор того или иного из них зависит от цели оценки, которая определяет также выбор групповых и единичных показателей, принимаемых за базовые. ГОСТ устанавливает три метода оценки уровня качества любой продукции, в том числе и ИС: дифференциальный (сопоставление уровня качества по отдельным единичным показателям), комплексный (сопоставление оцениваемой и базовой ИС по одному обобщённому показателю), смешанный (сопоставление по единичным показателям совместно с групповыми). Дифференциальный метод применяют, когда надо провести анализ уровня качества оцениваемой ИС базовому образцу по отдельным показателям. Комплексный метод применяют, когда с помощью дифференциального не удаётся получить однозначный ответ, выше или ниже базового уровня качество оцениваемой ИС, и его поэтому надо характеризовать одним обобщённым показателем. Смещанный метод применяют, когда обобщённый показатель в комплексном методе не обеспечивает полный учёт всех свойств ИС, а совокупность единичных показателей в дифференциальном методе не позволяет получить обобщающих выводов об уровне качества ИС. Обобщённый показатель может быть выражен: главным показателем, отражающим основное назначение, например, производительностью; интегральным показателем качества, например, экономической эффективностью; средним взвешенным показателем качества, используемым обычно на ранних стадиях разработки, когда невозможно определить зависимость главного или интегрального показателей от первичных и групповых. Применяют средние взвешенные арифметические Q, Q' и геометрические V, V' показатели качества, вычисляемые по формулам n n 1 Q = ∑mi (Q) qi; Q = ∑mi (Q) q'i; i=1 i=1

80 n V = ∏(qi)mi(v) ; i=1

n V = ∏(q'i)mi (v') i =1 1

;

n где ∑mi = 1; i=1 mi – коэффициент весомости i-го показателя, входящего в обобщённые показатели Q и V; i = 1, n – число показателей, составляющих средний взвешенный показатель; qi = Pi / Piб ; qi1 = Piб / Pi , где Pi И Piб – значения i-го показателя качества оцениваемой и базовой системы соответственно. Для оценки обычно выбирают qi и qi1 из таких соображений, чтобы улучшению качества ЭИС соответствовало увеличение относительного показателя. Для более подробного и глубокого изучения вопросов оценки уровня качества ПС предназначен подраздел 6.4 лабораторного практикума, содержащий методические указания по выполнению соответствующей лабораторной работы и необходимые формульные зависимости для её выполнения. 6. ЛАБОРАТОРНЫЙ ПРАКТИКУМ. РЕШЕНИЕ ЗАДАЧ ОЦЕНКИ И ПРОГНОЗИРОВАНИЯ ТЕХНИКО-ЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ СИСТЕМ 6.1. Оценка трудоёмкости разработки программных средств 6.1.1. Общие сведения Работа выполняется в соответствии с методикой, изложенной в подразделе 5.2. Нормы времени, введенные в настоящей методике, рассчитаны на одно программное средство и указаны в человеко-днях при пятидневной рабочей неделе с продолжительностью рабочего дня 8 часов. В случае изменения продолжительности рабочего дня нормы времени должны быть соответственно пересчитаны. Целью работы является определение трудоемкости разработки и средней численности разработчиков ПС «Расчет экономических показателей банков» (ПС «Комбанк»).

81 Создание ПС «Комбанк» предусматривает проведение всех стадий разработки: анализ, проектирование, программирование, тестирование, внедрение. Исходные данные – состав функций, реализуемых ПС «Комбанк»: а) реализация стандартного графического интерфейса; б) обеспечение взаимодействия с системой управления базами данных; в) расчет экономических показателей. Все функции разрабатываются с использованием системы программирования на базе СУБД FoxPro. 6.1.2. Задание на выполнение работы По каталогу функций ПС (табл. 5.3) определить объем каждой из функций разрабатываемого ПС «Комбанк» и свести эти данные в таблицу, аналогичную приведенной ниже. Таблица объемов функций разрабатываемого ПС Объем Суммарный функции, объем Наименование (содержание) Количество строк функции, строк функции функций исходноисходного го текста текста Реализация стандартного графического интерфейса 5000 1 5000 (многооконное приложение) Создание и изменение схемы 900 1 900 БД, контроль и восстановление целостности Ведение базы данных: чтение 10 20 200 модификация 15 20 300 Расчет экономических 20 50 1000 показателей 6.1.3. Рекомендации по выполнению работы Определяем общий объем разрабатываемого ПС (Vo) как сумму объемов входящих в него функций: Vo = V1 + V2 + V3 + V4 = … ( строк исходного текста). По табл. 5.1 для объема ПС Vo = … строк исходного текста определяем значение базовой трудоемкости разработки ПС: Норм = … чел.-дн. Расчет показателей коммерческих банков не является особо сложным, поэтому, согласно табл. 5.4: Ксложн =…

82 Базовая трудоемкость Тб = Норм·Ксложн =… чел.-дн. Общая трудоемкость разработки То = Тб · Кн ·Ккач . По табл. 5.5 определяем значение коэффициента новизны (при условии что, ПС «Комбанк» разрабатывается на известном разработчикам типе ЭВМ и в известной ОС): Кн = …. Значение Ккач является произведением коэффициентов Кнад, Кпроизв, Кдокум и Кпик, значения которых выбираются из табл. 5.6 – 5.9: – коэффициент, учитывающий требования к надежности ПС, Кнад =… – коэффициент, учитывающий требования к производительности ПС, Кпроизв =… – коэффициент, учитывающий требования к уровню информативности документации на фазах жизненного цикла ПС, Кдокум =… – коэффициент повторного использования программных компонентов Кпик =… Общая трудоемкость разработки То =…чел.-дн. Трудоемкость разработки ПС с учетом конкретных условий разработки (Тур) рассчитывается по формуле Тур = То · Кср.упр.жиз·Кср.разр . Значение поправочного коэффициента, учитывающего использование средств управления жизненным циклом, выбирается из табл. 5.10: Кср.упр.жиз =… Значение поправочного коэффициента, учитывающего конкретные условия и средства разработки ПС, выбирается из табл. 5.11: Кср.разр =… Подсчитываем Тур: Тур = … чел.-дн. По табл. 5.14 определяем коэффициенты удельного веса трудоемкости стадий разработки ПС в общей трудоемкости: L1 = 0,2; L2 = 0,15; L3 = 0,2; L4 = 0,4; L5 = 0,05. Рассчитываем трудоемкости отдельных стадий: Т1 = …чел.-дн.; Т2= … чел.-дн.; Т3 = …чел.-дн.; Т4 = …чел.-дн.; Т5 = … чел.-дн.

83 Пусть запланированы следующие сроки реализации стадий: Анализ – 2 мес. Проектирование – 2 мес. Программирование – 2 мес. Тестирование – 2 мес. Внедрение – 0,5 мес. Тогда, исходя из рассчитанной трудоемкости стадий и с учетом того, что в календарном месяце содержится примерно 22 рабочих дня, потребуется такая численность исполнителей на каждой стадии: Анализ – … чел. Проектирование – …чел. Программирование – … чел. Тестирование –…чел. Внедрение – … чел. Отчёт: демонстрация результатов работы преподавателю и их объяснение. 6.2. Оценка трудоёмкости сопровождения программных средств 6.2.1. Общие сведения Работа выполняется в соответствии с методикой, изложенной в подразделе 5.3. Целью работы является определение трудоёмкости сопровождения ПС «Комбанк». Процесс сопровождения включает: подготовку процесса, анализ проблем и изменений, внесение изменений, проверку и приемку при сопровождении, перенос, снятие с эксплуатации. Нормы времени определены с учетом факторов, влияющих на трудоемкость выполнения указанных работ: объем ПС, тыс. строк исходного текста (как написанного разработчиком вручную, так и сгенерированного автоматически); объем документации, тыс. строк (только эксплуатационная документация и документация сопровождения); сложность программ; язык программирования и другие средства разработки ПС; наличие аналогов ПС; степень участия службы сопровождения в разработке ПС; характер поставки ПС; характер внедрения ПС; объем доработок (количество строк исходного текста).

84 6.2.2. Задание на выполнение работы Рассчитать трудоемкость каждого из видов работ по сопровождению ПС на основании норм времени, значения которых приведены в нормативной части документа в табл. 5.27 – 5.39 в зависимости от объема программ в тыс. строк исходного текста и объема документации в тыс. строк. Считать, что по данным разработчика объем ПС в строках исходного текста составляет 20000 строк, объем документации – 3000 строк. Определить значения поправочных коэффициентов, пользуясь табл. 5.20 – 5.26, и свести их в таблицу, аналогичную приведенной ниже. Объем ПС – 20000 строк текста Объем документации – 3000 строк Характеристики Условное Зна№ Вид поправочных поправочных обозначечеп/п коэффициентов коэффициентов ние ние Наличие в фонде 1 программ аналогов Аналогов в фонде нет Кан данного ПС Степень участия ССо участвовала службы в разработке ПС 2 Куч сопровождения на правах в разработке ПС соисполнителя Язык Системы программирования программирования 3 Крз и другие средства на основе СУБД типа разработки ПС FoxPro Характер Локальное внедрение 4 Кхв внедрения ПС ПС Полнота Функциональное 5 тестирования тестирование всех Кте поставленного ПС основных функций ПС Локальная поставка Характер поставки 6 стандартного Кхп ПС комплекта ПС 7 Сложность ПС ПС средней сложности Ксл

85 6.2.3. Рекомендации по выполнению работы Результаты расчетов трудоемкости выполнения каждого вида работ целесообразно представить в виде приведенной ниже таблицы. Норма времени Вид работы

№ таблиц

1

2

Подготовка процесса Анализ сообщения о проблеме или заявки на внесение изменений Верификация возникшей проблемы Разработка вариантов реализации изменений Документальное оформление сообщения о проблеме или заявки на внесение изменения; результатов их анализа и вариантов реализации изменений и получение согласования выбранного варианта реализации изменения в соответствии с договором

Значение

Формула расчета

3 4 Подготовка процесса 5.27 Тпп = Ксл · Кан · Куч · Нвр.пп Итого на работу Анализ проблем и изменений 5.28

Тан = Ксл ·Кхв · Куч ·Нвр.ан

5.29

Твер = Ксл · Кте · Куч · Нвр.вер

5.30

Твар = Кхв · Куч ·Ксл· Нвр.вар

Тсогл = 5 чел.-дн.

Итого на работу Внесение изменений Анализ и определение перечней программ и документов, требующих изменения; оформление результата Реализация процесса разработки для внесения изменений

5.31

Тдр = Куч ·Ксл· Нвр.раз

5.32

Траз = Краз · Куч ·Ксл· Нвр.раз Итого на работу

Трудоемкость, чел.дн. 5

86 Продолжение таблицы 1

2 3 4 Проверка и приёмка при сопровождении Проверка внесенного изменения в целях подтверждения 5.33 Тпи = Кте · Кхв · Ксл · Нвр.пи работоспособности измененного ПС Получение подтверждения правильности Тпод = 5 чел.-дн. внесенного изменения от организациизаказчика Итого на работу Перенос Проверка соответствия переносимого ПС стандарту ИСО/МЭК 5.34 Тпп = Кхп · Нвр.п 12207-99» и «Разработка плана переноса Уведомление пользователей о планах Туп=1,0 чел.-дн. и работах по переносу Обучение специалистов 5.35 Тоб = Ксл · Нвр.об пользователя работе в новой среде Архивация прежних программ 5.36 Тар = Нвр.ар и документации Анализ влияния 5.37 Тап = Ксл · Нвр.ап перехода к новой среде Итого на работу Снятие с экспплуатации Разработка и оформление плана 5.39 Тпсэ = Кхп · Нвр.псэ снятия с эксплуатации Уведомление пользователя о планах Туп = 1,0 чел.-дн. и работах по снятию с эксплуатации

5

87 Окончание таблицы 1 Обучение пользователей в течение периода параллельной эксплуатации прежнего и нового программных средств Архивация связанной с прежним объектом документации разработки, журналов регистрации и программ

2

3

4

5.39

Тобн = Ксл · Нвр.обн

5.17

Тар = Нвр.ар

5

Итого на работу ИТОГО

Отчёт: демонстрация результатов работы преподавателю и их объяснение. 6.3. Сопоставительно-аналоговый метод прогнозирования стоимостных показателей информационных систем 6.3.1. Общие сведения Сопоставительно-аналоговый метод основан на сопоставлении основных характеристик ИС и затрат на их обеспечение в проектируемых образцах и прототипах, связанных соотношением m

C = Cп∑Кјβј , (6.1) ј=0 где Cп − стоимость прототипа; Кј – переводные коэффициенты; βј – весовые коэффициенты, учитывающие долю затрат Сj на обеспечение j-й характеристики Xј разрабатываемой ИС; m – число основных характеристик, Кј = Xј/ Xјп , Xјп – значение j-й характеристики прототипа. На практике обычно используют линейную зависимость Сj = а +βј Xј или степенную m

Сј = ∏а Xј βј . j=0

88 За основные характеристики ИС принимаются те, что имеют наибольшую связь со стоимостью. Существует несколько разновидностей сопоставительно-аналогового метода: однофакторный или многофакторный методы переводных коэффициентов; многофакторный метод бальной оценки. В данной работе использован многофакторный метод переводных коэффициентов и линейных зависимостей, в соответствии с которыми затраты и значения соответствующих характеристик пропорциональны, то есть Сј/Сјп = Хј/Хјп. Так как Кј = Xј / Xјп, то Сј = КјСјп, где Сјп – затраты на обеспечение j-й характеристики прототипа. С учётом того что βј = Сјп / Сј (по определению), получаем Сј = Кјβј Cп . Отсюда следует формула (6.1), в которой Ко = 1, а βо характеризует затраты, которые не меняются при переходе от прототипа к разрабатываемому образцу, то есть долю затрат на неосновные параметры. Введём зависимость С = КсрСп, m где Кср = ∑ Кјβј = С / Сп– переводной коэффициент. j=o Применение данного метода для прогнозирования стоимостных показателей можно проиллюстрировать на примере использования выборки характеристик стоимости Сi, ёмкости памяти Vi и быстродействия Бi серверов ИС для получения значений весовых коэффициентов βv и βБ. Воспользовавшись соотношениями Ксрi = βо + βVКVI + βБKБi , i = 1, n, получим Сi = СiФ [(КVi – 1) βV + (КБi – 1) βБ + 1], где Сi – расчётные значения стоимости i-го образца; Сiф – фактические значения стоимости i-го образца; КVI = ХVi / XV1; КБi = XБi / ХБ1, где XVi и XБ1 – значения ёмкости памяти и быстродействия 1-го образца, принимаемого за базовый (прототип). Чтобы погрешность в среднем по всем образцам была минимальной, значения весовых коэффициентов можно подобрать с использованием метода наименьших квадратов. Тогда подлежащая минимизации функция будет иметь вид n

n _

2

2

S = ∑( С iФ – Сi) = ∑ СiФ{(KVi – 1) βV + (КБi – 1) βБ} = min. i=1 i=1

89 Дифференцируя S по βV и βБ и приравнивая к нулю, получим а − d − βБ ⋅ g р ; ð(b − 1) + g (d − a ) = ѓА , Á 2 qp − g βV =

где βо = 1 – βv – βБ, d + p βv + g βБ = a, l + g βv + q βБ = b; a, d, p, g, q, b, l – условные обозначения: n n n n 2 a = ∑(Кvi – 1) Сiф/ С1ф, d = ∑(Кvi – 1), p = ∑(Кvi – 1) , q = ∑(КБi – 1)2 , i=1 i=1 i=1 i=1 n g = ∑(Кvi – 1) (КБi – 1), i=1 n n b = ∑(КБi – 1) Сiф / С1ф, l = ∑(КБi – 1). i=1 i=1 6.3.2. Задание на выполнение работы Cоздать электронную таблицу для расчёта прогнозируемых значений стоимости серверов ИС, исходные данные для расчётов которых приведены в табл. 6.1, и провести расчёты в соответствии с табл. 6.2. Предварительно надо скопировать ячейки B17 в C17:E17, B5 в C5:E5, B6 в C6:E6. Таблица 6.1 Исходные данные для расчёта стоимости ИС A B C D E Порядковый номер 1 1 2 3 4 образца 2 Стоимость фактическая 1 2 3 6 3 Память 1024 2048 8192 16384 4 Быстродействие 150 450 1500 4500

5 6 7 8 9 10

Таблица 6.2 Макет таблицы для прогнозирования стоимости ИС A B Kvi = B3 / $B3 KБi = B4 / $B4 a = СУММ(C2 · (C5 – 1) + D2 · (D5 – 1) + E2 · (E5 – 1)) / B2 d = СУММ(C5 + D5 + E5 – 3) p = СУММ((C5 – 1)^2 + (D5 – 1)^2 + (E5 – 1)^2) = СУММ((C6 – 1) · (C5 – 1) + (D6 – 1) · (D5 – 1) + g + (E6 – 1) · (E5 – 1))

90 11 12 13 14 15 16

Продолжение табл. 6.2 = СУММ((C6 – 1)^2 + (D6 – 1)^2 + (E6 – 1)^2) = СУММ(C2 · (C6 – 1) + D2 · (D6 – 1) + E2 · (E6 – 1)) / B2 = СУММ(C6 + D6 + E6 – 3) = (B9 · (B12 – B13) + B10 · (B8 – B7)) / (B11 · B9 – B10^2) = (B7 – B8 – B14 · B10) / B9 = 1 – B14 – B15

q b l Bb Bv Bo Стоимость 17 расчетная, Сi = $B2 · СУММ($B16 + $B15 · B5 + $B14 · B6)

Отчёт: демонстрация результатов работы преподавателю и их объяснение. 6.4. Оценка уровня качества программного обеспечения и информационных систем 6.4.1. Общие сведения Уровень качества ИС или отдельных её компонентов можно охарактеризовать одним из трёх способов: совокупностью относительных групповых показателей качества, отношением обобщённого показателя качества к соответствующему обобщённому базовому показателю, отнесением ИС или её компонентов к определённой категории качества. Выбор того или иного из них зависит от цели оценки, которая определяет также выбор групповых и единичных показателей, принимаемых за базовые. ГОСТ устанавливает три метода оценки уровня качества любой продукции, в том числе и ИС: дифференциальный (сопоставление уровня качества по отдельным единичным показателям), комплексный (сопоставление оцениваемой и базовой ИС по одному обобщённому показателю, смешанный (сопоставление по единичным показателям совместно с групповыми). Обобщённый показатель может быть выражен: главным показателем, отражающим основное назначение, например, производительностью; интегральным показателем качества, например, экономической эффективностью; средним взвешенным показателем качества, используемым обычно на ранних стадиях разработки, когда

91 невозможно определить зависимость главного или интегрального показателей от первичных и групповых, как в данной работе. Применяют средние взвешенные арифметические Q, Q и геометрические V, V показатели качества, вычисляемые по формулам n n 1 Q = ∑miqi.; Q = ∑m1iqi1 ; i=1

i=1

n n m 1 V = ∏(qi) i; V = ∏(qi1)m1i, i=1

n

где

∑mi = 1; i=1 mi – коэффициент весомости i-го показателя, входящего в обобщённые показатели Q и V; i = 1, n – число показателей, составляющих средний взвешенный показатель; qi = Pi / Piб ; q1I = Piб / Pi , где Pi И Piб – значения i-го показателя качества оцениваемой и базовой системы соответственно. Для оценки обычно выбирают qi и qi1 из таких соображений, чтобы улучшению качества ЭИС соответствовало увеличение относительного показателя. При возможности установления предельных показателей качества Рiпред, определяющих нецелесообразность использования ИС по конкретному назначению, относительные показатели определяют по формуле qi = ( Pi – Рiпред) / (Piб – Рiпред). Для определения значений показателей качества оцениваемой ИС могут использоваться методы: экспериментальный, осуществляемый измерительными средствами или на основе обработки статистических данных; расчётный, осуществляемый c использованием теоретических или эмпирических зависимостей и значений параметров, найденных экспериментально или другими методами; экспертный, основанный на учёте мнений группы специалистов. Экспериментальный метод применяют при оценке единичных показателей назначения, экологичности и безопасности; расчётный – при оценке единичных показателей надёжности, технологичности, стандартизации и унификации и экономических показателей; экспертный – при оценке показателей эргономичности, защиты от НСД, а также групповых показателей и уровня качества ИС в целом.

92 Эти методы могут использоваться в ряде случаев и для определения базовых показателей, например, когда целью оценки уровня качества ИС является аттестация качества. Если же целью оценки является контроль качества ИС или выбор лучшего варианта ИС, то за базовые показатели берутся нормативные или записанные в ТЗ на систему. Наиболее сложно определять базовые показатели, когда целью оценки является выбор оптимального варианта решения, при которой эта задача превращается в задачу обоснования оптимальных требований к ИС. При этом в качестве базовых показателей выбирается эталонная ИС, обеспечивающая оптимальный уровень качества. Для оценки весомости отдельных единичных показателей назначения и надёжности и некоторых других могут быть использованы метод стоимостных регрессионных зависимостей, подобный аналогосопоставительному методу в лабораторной работе №3, и метод предельных и номинальных значений, рассматриваемый в данной лабораторной работе. Коэффициенты весомости mi для средневзвешенного арифметического и геометрического показателей определяются по формулам: 1 (p − ð iïðåä ) m i = n ií , (6.2) ∑1 (p ií − ð iïðåä ) i =1

mi =

1 lg(p ií − ð iïðåä

∑1 lg(p n

i =1

ií

)

− ð iïðåä

)

,

где Piн – номинальное (среднестатистическое) значение оцениваемых показателей. Для оценки значимости (весомости) групповых показателей, а также некоторых единичных показателей прибегают к экспертному методу. Таким образом, обобщённый средний взвешенный показатель качества ИС определяется по формуле n (6.3) К = ∑ mi Кi, i=1 где mi – коэффициент весомости i-го относительного группового n показателя, 0 < mi < 1; ∑ mi = 1; i=1 Кi – относительный групповой показатель качества.

93 Групповые показатели Кi рассчитываются по формуле l Кi = ∑mij Кij ,

(6.4)

j=1

где mij – коэффициент весомости j-го относительного единичного показателя качества в i-й группе; l

0 < mij < 1; ∑ mij = 1; Кij – относительный единичный показатель i =1

качества в i-й группе; Кij =

Pij / Pij баз, если Pij / Pij ≤ 1,

(6.5)

Pij / Pij баз, если Pij / Pij > 1, где Pij и Pij баз – абсолютные единичные показателе качества оцениваемого и базового образца. 6.4.2. Задание на выполнение работы Создать электронные таблицы для расчёта относительных единичных и групповых показателей качества, исходные данные для которых представлены в табл. 6.3 и 6.4, и провести расчёты показателя качества программного обеспечения и ИС в целом. Таблица 6.3 Макет для расчёта показателей качества программного обеспечения A 1 2 3

Наименование характеристик Метрика 1. Показатели назначения

B C Значение показателя качества Pij Pij б

D E Коэффициенты весомости показателей mij mi

–

–

–

0,35

4

пригодность ПО

5

5

0,3

–

5

правильность ПО

4

5

0,2

–

3

5

0,1

–

5

5

0,1

–

6 7

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

8

защищенность

5

5

0,3

–

9

2. Надежность

-

-

–

0,25

10

стабильность

0,002

0,007

11

устойчивость

0,02

0,04

Формула (6.2) Формула (6.2)

– –

F

G

Относительные показатели качества Kij -

Кi Формула (6.4)

Формула (6.5) Формула (6.5) Формула (6.5) Формула (6.5) Формула (6.5) – Формула (6.5) Формула (6.5)

Формула (6.4)

94 Продолжение табл. 6.3 13

3. Практичность

–

–

Формула (6.2) –

14

понятность

5

5

0,3

15

обучаемость

5

5

0,3

16

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

5

5

0,4

17

4. Эффективность

–

–

–

0,15

18

время отклика

0,005

0,002

0,8

–

19

ресурсы

2

1

0,2

–

20 5. Сопровождаемость

–

–

–

0,2

21

анализируемость

5

5

0,2

–

22

изменяемость

5

5

0,2

–

23

устойчивость

5

5

0,1

–

24

тестируемость

90

100

0,5

–

25

6. Мобильность

–

–

–

0,3

26

адаптируемость

5

5

0,25

–

27

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

5

5

0,25

–

28

соответствие стандартам

3

5

0,25

–

5

5

0,25

–

12 востанавливаемость

29 взаимозаменяемость 30

7.Обобщённый показатель качества

0,2

0,25

Формула (6.5) 0,02 – Формула – (6.5) Формула – (6.5) Формула – (6.5) –

–

Формула (6.4)

Формула (6.4)

Формула (6.4) формула (6.5) – Формула (6.5) Формула (6.5) Формула (6.5) Формула (6.5) – Формула (6.5) Формула (6.5) Формула (6.5) Формула (6.5)

Формула (6.4) – – – – Формула (6.4) – – – – Формула (6.3)

Отчёт: демонстрация результатов работы преподавателю и их объяснение.

95 Таблица 6.4 Макет для расчёта показателей качества ИС A 1

Наименование характеристик

2

Метрика

3 1. Показатели назначения

B C Значение показателя качества Pij Pij б

D E Коэффициенты весомости показателей mij mi

–

–

–

0,3

F

G

Относительные показатели качества Kij

Кi

–

Формула (6.4)

Формула (6.5) Формула (6.5)

4

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

1300

2000

0,4

–

5

ёмкость памяти

8192

16384

0,2

–

6

пропускная способность каналов

3000

3000

0,2

–

7

разрядность

32

64

0,2

–

8

2. Надежность

–

–

–

0,25

9

наработка на отказ

750

1000

0,4

–

1

2

0,4

–

0,9

0,95

0,2

–

Формула (6.5)

–

–

–

–

0,1

–

Формула (6.4)

0,6

–

0,4

–

–

0,025

10 11 12

интенсивность восстановления коэффициент технического использования 3. Технологичность

комплексный показатель 3,7 0,8 технологичности трудоёмкость 14 195000 150000 изготовления 4. Эргономические 15 – – показатели 13

16

гигиенические

17 психофизиологические

5

5

0,4

–

0,005

0,002

0,8

–

18

антропометрические

2

1

0,2

–

19

5. Эстетические показатели

–

–

–

0,025

20

композиция

5

5

0,4

–

21

цветовая гармония

5

5

0,3

–

22

общая гармония

5

5

0,3

–

– – –

Формула (6.5) – Формула (6.5) Формула (6.5)

Формула (6.5) Формула (6.5) – Формула (6.5) Формула (6.5) Формула (6.5) – Формула (6.5) Формула (6.5) Формула (6.5)

– Формула (6.4) – –

– – Формула (6.4) – – – Формула (6.4) – – –

96 Продолжение табл. 6.4 23

6. Стандартизация и унификация

–

–

–

0,05

24 коэффициент применяемости

80

85

0,7

–

25

коэффициент повторяемости

92

94

0,3

–

26

7. Патентно-правовые показатели

–

–

–

0,05

27

патентная чистота

0,6

1

28

патентная защита

0,4

29

8. Экологические показатели

30

– Формула (6.5) Формула (6.5)

Формула (6.3) – –

–

Формула (6.4)

0,6

Формула (10)

–

0,3

0,4

Формула (10)

–

–

–

–

0,05

–

Формула (6.4)

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

66

66

0,6

–

31

уровень звукового давления

75

75

0,4

–

32

9. Показатели безопасности

–

–

–

0,05

–

Формула (6.4)

33

Защита от электротока

5

5

1

–

Формула (6.5)

–

34

10. Показатели транспортабельности

–

–

–

0,05

–

Формула (6.4)

35

масса

30

30

1

–

Формула (6.5)

–

–

–

–

0,05

–

Формула (6.4)

36 11. Экономические показатели 37 38 39

себестоимость изготовления рентабельность к полной себестоимости 12.Обобщённый показатель качества

8000 8000 0,6

–

14

14

0,4

–

–

–

–

–

Формула (6.5) Формула (6.5)

Формула (6.5) Формула (6.5) –

– –

– – Формула (6.3)

Отчёт: демонстрация результатов работы преподавателю и их объяснение. 6.5. Поиск оптимальных решений надёжности средствами Excel

6.5.1. Предварительные процедуры 1) Загрузка Excel Ознакомление с задачей нахождения оптимального распределения требований к надежности изделий вида А, В, С, обеспечивающих максимум надёжности (целевой функции F(x)) при удельных значениях

97 увеличения массы, объема, потребляемой электроэнергии и стоимости изделий и ограничениях, приведенных в таблице: Массо-объемные, энергетические и стоимостные характеристики системы Масса Объем Электроэнергия Стоимость Вероятность безотказной работы Рi

Удельные значения увеличения массы, объема, потребляемой электроэнергии и стоимости изделий вида А, В, С А

В

С

2 1 7 60

4 8 4 70

5 6 5 120

0,91

0,93

0,92

2) Составление математической модели задачи: 2х1 + 4х2 + 5х3 <= 70 х1 + Зх2 + 6х3 <= 80 7х1 + 4х2 + 5х3 <= 100 60х1 + 70 х 2 + 120х3 <= 2000 0 <= х1 <= 9 0 <= x2 <= 7 0 <= x3 <= 8 F(x) = x1 + x2 + x3 3) Составление форм для ввода условий задачи.

Ограничение по массе, объему электроэнергии и стоимости 70 80 100 2000

98

4 5 6

7

А Имя Значение Нижняя граница Верхняя граница Коэффициент Ц.Ф.

В A

С B

D C

Е

0

0

0

Надёжность

0

0

0

9

7

8

1

1

1

F

=СУММПРОИЗВ(В$4:D$4;B7: D7) Левая часть

Правая часть

8 9 10 11 12 13

Характеристики системы Масса Объем Электроэнергия Стоимость

G

Знак

70 80

=СУММПРОИЗВ(В$4:D$4;B10:D10) 2 1

4 8

5 6

7

4

5

60

70

120

=СУММПРОИЗВ(B$4:D$4;B11:D11)

<=

=СУММПРОИЗВ(В$4:D$4;B12:D12)

<=<=

=СУММПРОИЗВ(В$4:D$4;B13:D13)

100 2000

6.5.2. Решение прямой задачи В меню «Сервис» выбрать пункт «Поиск решения», в появившемся диалоговом окне установить целевую ячейку $Е$7, в окне <изменяя ячейки> – В4:D4 установить переключатель на максимальное значение и ввести границы изменяемых ячеек с помощью пункта «Добавить»: В6 >= В4 >= В5; C6 => С4 >= С5; D6 >= D4 >= D5; Е10 <= G10; Е11 <= G11; Е12 <= G12; Е13 <= G13. Щёлкнуть по кнопке «Параметры» и в открывшемся диалоговом окне установить Линейную модель. Затем выполнить Поиск решения, щёлкнув по кнопке «ОК». В появившемся диалоговом окне «Результаты поиска решения» выделить все отчеты и нажать «ОК». В результате будет получено решение, согласно которому надёжность повышать надо на ... единиц в изделии А, на ... единиц в изделии В, на ... единиц в изделии С, что обеспечит ОБЩЕЕ ПОВЫШЕНИЕ надёжности на … единиц. Необходимо проанализировать все отчёты.

99 6.5.3. Решение обратной задачи Пусть при тех же условиях и ограничениях надо повысить надёжность изделий: вида А – на … условных единиц, вида В – на …, вида С – на ..., что возможно только при выделении некоторых дополнительных ресурсов (увеличения ограничений): ti (i = 1,2,3,4), t1 >= 0; t2 >= 0; t3 >= 0; t4 >= 0; (можно увеличить х1, х2 и х3 на несколько условных единиц по сравнению с тем, что получено в пункте 6.5.2, но не выходя за пределы х1 <= 9; х2 <= 7; х3 <= 8). Тогда целевая функция системы будет иметь вид F(t) = t1 + t2 + t3 + t4 → min, а сама система граничных условий и ограничений запишется в виде: 2х1 + 4х2 + 5х3 – t1 <= 70, х1 + Зх2 + бх3 – t2 <= 80, 7х1 + 4х2 + 5х3 – t3 <=100, 60х1 + 70х2 + 120х3 – t4 <= 2000. В таблице, где получено решение прямой задачи, через меню Вставка / Столбцы добавить столбцы Е, F, G, Н для переменных t1, t2, t3, t4. В ячейки Е10, F11, G12, Н13 ввести – 1. В ячейку I10 ввести формулу = СУММПРОИЗВ(В$4:Н$4;В10:Н10) и скопировать её в ячейки I11, I12, I13. В ячейку I4 ввести формулу = СУММ (Е4:Н4). Имя

A

B

C

Значение

9

3

7

0

0

7

8

1

1

Нижняя 0 граница Верхняя 9 граница Коэффи1 циент Ц.Ф. Характеристики системы Масса Объем Электроэнергия Стоимость

T1 Т2 T3 T4 Целевая функция 0

0

0

0

=СУММ(E4:H4)

Надёжность

Левая часть 2 1

4 8

5 6

7

4

5

60

70

120

min

-1 -1 -1 -1

ПраЗнак вая часть <= 70 <= 80 <=

100

<=

2000

100 Вызвать Поиск решения, установить как целевую ячейку I4, переключатель – на минимальное значение и в окне «изменяя ячейки» ввести $E$4:$Н$4, а в окне «ограничения» ввести ограничения: В4 = 8; С4 = 7; D4 = 8; Е4 > 0; F4 >= 0; G4 >= 0; H4 => 0; H10 <= J10; H11 <= J11; H12 <= J12; H13 <= J13. Затем произвести поиск решения. В диалоговом окне «Результаты поиска решения» выделить нужные отчёты и нажать «ОК». В результате получится решение, согласно которому необходимые дополнительные ресурсы, минимизирующие целевую функцию, будут t1 =… t2 =… t3 =… t4 =... . При этом надёжность будет увеличена на … условных единиц. Отчёт: демонстрация преподавателю.

результатов

работы

и

их

объяснение

101 БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Документация пользователя и информация на упаковке для потребительских программных пакетов: ГОСТ Р ИСО 9127-94. М., 1996. 2. Котов С.Л. Нормирование жизненного цикла программной продукции. М., 2002. 3. Информационные технологии (для экономиста) / Под ред. А.К. Волкова. М.: Инфра-М, 2001. 4. Липаев В.В. Документирование и управление конфигурацией программных средств. М., 1993. 5. Липаев В.В. Разработка программных средств. М., 1990. 6. Липаев В.В. Качество программных средств: Методические рекомендации / Под общей ред. А.А. Полякова. М., 2002. 7. Методика оценки трудоёмкости разработки программных средств. М.: Госстандарт России, 2000. 8. Методика оценки трудоёмкости сопровождения программных средств. М.: Госстандарт России, 2000. 9. Оценка программной продукции. Характеристики качества и руководства по их применению: ГОСТ Р ИСО/МЭК 9126-93. М., 1993. 10. Палюх Б.В., Мироненко А.С. Надёжность и эффективность экономических информационных систем: Учебное пособие. Тверь: ТГТУ, 2004. 11. Правила по проведению сертификации в Российской Федерации. М.: Госстандарт России, 1994. 12. Требования к проведению статического анализа программных средств. ОСТ 115.1.9-96. М., 1996. 13. Федеральный закон от 27.12.02 №184-ФЗ «О техническом регулировании». 14. Федченко С.Л., Кузнецов В.Н., Пашаев Ф.А. Информационные технологии в управлении финансово-хозяйственной деятельностью предприятий: Учебное пособие. Тверь: ТГТУ, 2003. 15. Федченко С.Л., Мироненко А.С. Оптимизация техникоэкономических показателей создания программного обеспечения // ММТТ17: Сб. тр. Т. 7. Секция 7. Кострома, 2004.

102 ОГЛАВЛЕНИЕ Введение……………………………………………………………………….3 1. Краткая характеристика программных средств как объекта разработки и стандартизации………..……………………………………..3 1.1. Технические особенности разработки программных средств. Принципы модульности и адаптируемости………………………...3 1.2. Экономические особенности разработки программных средств………………………………………………...4 1.3. Вопросы оценки трудоёмкости разработки программных средств в свете требований стандартизации………………………..5 2. Основные понятия и положения технологии разработки программных средств…………………………………………………….….9 2.1. Проблемы и задачи проектирования программных средств………………………………………………...9 2.2. Этапы жизненного цикла программных средств…………………..9 2.3. Виды поддержки и стадии этапа проектирования………………..10 2.4. Основные понятия и определения статического анализа программных средств………………………11 3. Эффективность технологий проектирования программных средств………………………………………………...……..13 3.1. Критерии оценки технологий проектирования программных средств……………………………………………………13 3.2. Суть управления качеством программных средств………………13 3.3. Составляющие затрат в жизненном цикле программных средств…………………………………………...…..14 3.4. Основные факторы, влияющие на трудоёмкость разработки программных средств…………………………………...…………..14 3.5. Длительность разработки программных средств…………………15 3.6. Распределение затрат по этапам разработки……………………...15 4. Общие сведения о сертификации информационных систем и их программных средств…………………………………………………16 4.1. Основные понятия и определения………………...……………….16 4.2. Основные положения закона «О техническом регулировании» (ТР)…………………………………………………………………...17 4.3. Особенности сертификации программного обеспечения………..22

103 5. Методы оценки технико-экономических показателей программных средств на различных этапах их жизненного цикла….................................................................................26 5.1. Порядок и методология проведения статического анализа программных средств……………………………………………….26 5.2. Методика оценки трудоёмкости разработки программных средств……………………………………………….30 5.3. Методика оценки трудоёмкости сопровождения программных средств……………………………………………….53 5.4. Методика прогнозирования стоимостных показателей информационных систем…………………………………………...78 5.5. Методика оценки уровня качества программных средств информационных систем…………………………………………...79 6. Лабораторный практикум. Решение задач оценки и прогнозирования технико-экономических показателей программных средств и информационных систем……………..………80 6.1. Оценка трудоёмкости разработки программных средств………..80 6.2. Оценка трудоёмкости сопровождения программных средств…...83 6.3. Сопоставительно-аналоговый метод прогнозирования стоимостных показателей информационных систем……………...87 6.4. Оценка уровня качества программного обеспечения и информационных систем…………...………………………………90 6.5. Поиск оптимальных решений надежности...……………………...97 Библиографический список………………………………………………101

104

Сергей Львович Котов Борис Васильевич Палюх Сергей Лукич Федченко Разработка, стандартизация и сертификация программных средств и информационных технологий и систем

Учебное пособие Издание первое Редактор Т.С. Синицына Корректор В.А. Румянцева Технический редактор Г.В. Комарова Подписано в печать 5.05.06 Формат 60 × 84 / 16 Бумага писчая Физ. печ. л. 6,5 Усл. печ. л. 6,05 Уч.-изд. л. 5,66 Тираж 150 экз. Заказ № 82 С – 42 Издательство Тверского государственного технического университета 170026, г. Тверь, наб. Афанасия Никитина, 22