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

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

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

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

Тверь 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