Раздел 15. Технология разработки программного обеспечения

80. Жизненный цикл программного обеспечения, процессы жизненного цикла, связь между процессами: основные, вспомогательные, организационные процессы, модели и стадии жизненного цикла, взаимосвязь между стадиями и процессами, матрица фазы-функции.

ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

- основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

- вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);

- организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).

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

Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО. Верификация - это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.

МОДЕЛИ

Каскадная модель. Она предполагает, что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии.

Достоинствами такой схемы являются:

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

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

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

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

необходимости пересмотра уже принятых решений;

• изменение требований заказчика непосредственно в процессе разработки;

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

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

Модель с промежуточным контролем. Контроль, который выполняется по данной схеме после завершения каждого этапа, позволяет при необходимости вернуться на любой уровень и внести необходимые изменения. Основная опасность использования такой схемы связана с тем, что разработка никогда не будет завершена, постоянно находясь в состоянии уточнения и усовершенствования.

Спиральная модель. В соответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов.

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

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

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

• заинтересовать большое количество пользователей, обеспечивая быстрое продвижение следующих версий продукта на рынке;

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

• уменьшить вероятность морального устаревания системы за время разработки.

Основной проблемой использования спиральной схемы является определение моментов перехода на следующие стадии. Для ее решения обычно ограничивают сроки прохождения каждой стадии, основываясь на экспертных оценках.

81. Метод и технология проектирования программного обеспечения: требования к технологии, формализация и автоматизация стадий и этапов жизненного цикла, стандартизация процесса проектирования и разработки - стандарт проектирования, стандарт оформления проектной документации, стандарт интерфейса пользователя, государственные стандарты, стандарты предприятия; эффективность технологии проектирования программного обеспечения: критерии оценки технологии проектирования – функциональные, конструктивные; основные затраты в жизненном цикле, распределение затрат на разработку, длительность разработки программного обеспечения.

Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.

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

-пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1);

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

-нотаций (графических и текстовых средств), используемых для описания проектируемой системы.

РИСунок: в центре прямоугольник - в нем текст "технологическая операция"

к нему 4 стрелки

слева: исходные данные

сверху: методол материала, инструкции

справа: результаты

снизу: исполнители

Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.

Технология проектирования, разработки и сопровождения ПО должна удовлетворять следующим общим требованям:

- технология должна поддерживать полный ЖЦ ПО;

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

- технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей);

- технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

- технология должна обеспечивать минимальное время получения работоспособного ПО. Речь идет не о сроках готовности всего ПО, а о сроках реализации отдельных подсистем;

- технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;

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

- технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ..

Стандартизация

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

- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

- правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;

- требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;

- механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.

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

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

- требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

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

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

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

- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

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

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

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

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

3 Стандарты и методики разработки программ. Виды стандартов.

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

- стандарты на продукты и услуги

- стандарты на процессы и технологии

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

Существующие на сегодняшний день стандарты можно несколько условно разделить на несколько групп по следующим признакам:

- по предмету стандартизации. К этой группе можно отнести функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию жизненного цикла создания и использования ИС и ПО.

- По утверждению организации. Здесь можно выделить официальные национальные или национальные ведомственные стандарты (например6 ГОСТ-ы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (например6 консорциума OMG), стандарты «де-факто»-официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с рел. БД SQL и язык программирования С), фирменные стандарты (например, Microsoft ODBC).

- По методическому источнику. К этой группе относятся различного рода методические материалы ведущих фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации.

Ниже мы рассмотрим след. Стандарты и методики, касающиеся организации жизненного цикла ИС и ПО:

- методика ORAcle CDM (custom development method) по разработке прикладных ИС под заказ.

- Международный стандарт ISO/IEC 12207:1995-08-01 на организацию жизненного цикла продуктов прогр. Обесп.

82. Оценка качества процессов создания программного обеспечения: международные стандарты серии ISO 9000, CMM, SPICE; качество программного обеспечения, управление качеством, общие характеристики качества программного обеспечения: функциональность, надежность, удобство использования, эффективность, сопровождаемость, мобильность; критерии качества, ранжированные по фазам жизненного цикла, метрики характеристик программного обеспечения.

На настоящий момент существует несколько стандартов, связанных с оценкой качества. К наиболее известным относят:

• международные стандарты серии ISO 9000 (ISO 9000 - ISO 9004);

• СММ - Capability Maturity Model - модель зрелости (совершенствования) процессов создания программного обеспечения, предложенная SEI (Software Engineering Institute – институт программирования при университете Карнеги-Меллон);

• рабочая версия международного стандарта ISO/IEC 15504: Information Technology – Software Process Assessment; эта версия более известна под названием SPICE - (Software Process Improvement and Capability dEtermination - определение возможностей и улучшение процесса создания программного обеспечения).

Серия стандартов ISO 9000. В серии ISO 9000 сформулированы необходимые условия для достижения некоторого минимального уровня организации процесса, но не дается никаких рекомендаций по дальнейшему совершенствованию процессов.

СММ. СММ представляет собой совокупность критериев оценки зрелости организации-разработчика и рецептов улучшения существующих процессов.

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

1. Начальный уровень (initial level)- описан в стандарте в качестве основы для сравнения со

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

2. Повторяемый уровень (repeatable level) - на предприятии внедрены технологии управления

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

3. Определенный уровень (defined level) - характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения полностью документирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа.

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

4. Управляемый уровень (managed level) - в организации устанавливаются количественные показатели качества, как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.

5. Оптимизирующий уровень (optimizing level) - характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например с помощью создания и повторного использования компонентов.

Сертификационная оценка соответствия всех ключевых областей проводится по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области осуществляется по следующим показателям:

• заинтересованность руководства в данной области, например, планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т. д.;

• насколько широко данная область применяется в организации, например, оценке в 4 балла соответствует фрагментарное применение;

• успешность использования данной области на практике, например, оценке в 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется при наличии систематического и измеримого положительного результата практически во всей организации.

SPICE. Стандарт SPICE унаследовал многие черты более ранних стандартов, в том числе и уже упоминавшихся ISO 9001 и СММ. Больше всего SPICE напоминает СММ. Точно так же, как и в СММ, основной задачей организации является постоянное улучшение процесса разработки программного обеспечения. Кроме того, в SPICE тоже используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам.

В основе стандарта лежит оценка процессов. Эта оценка выполняется путем сравнения процесса разработки программного обеспечения, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов, полученных на этом этапе, помогает определить сильные и слабые стороны процесса, а также внутренние риски, присущие данному процессу. Это помогает оценить эффективность процессов, определить причины ухудшения качества и связанные с этим издержки во времени или стоимости.

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

Безусловно, совершенствование процессов жизненного цикла программного обеспечения абсолютно необходимо. Однако следует иметь в виду, что построение «более зрелого» процесса разработки не обязательно обеспечивает создание более качественного программного обеспечения. Это хотя и связанные, но совершенно различные процессы.

Использование формальных моделей и методов позволяет создавать понятные, непротиворечивые спецификации на разрабатываемое программное обеспечение. Конечно, внедрение таких методов имеет смысл, хотя оно весьма дорого и трудоемко, а возможности их применения весьма ограничены. Основная же проблема - проблема сложности разрабатываемого программного обеспечения с совершенствованием процессов разработки пока не разрешена.

Создание программного обеспечения по-прежнему предъявляет повышенные требования к квалификации тех, кто этим занимается: проектировщикам программного обеспечения и непосредственно программистам.

83. Понятийный аппарат метрической теории программ – принципы количественного анализа качества объектов с расплывчатыми свойствами: модели и метрики оценки сложности Боэма, Холстэда, Мак-Кейба (основанные на потоковых графах), модель и метрики, основанные на информационных потоках; методы оценки качества программного обеспечения: анкетирование, рабочие списки, контрольные задачи, метрики; государственные стандарты в области оценки качества программного обеспечения.

Модели и метрики оценки качества ПО

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

Тем не менее, анализ технологического опыта лидеров производства ПО показывает, насколько дорого обходится несовершенство ненаучного прогноза разрешимости и трудозатрат, сложности программ, негибкость контроля и управления их разработкой и многое другое, указывающее на отсутствие сквозной методической поддержки и приводящее в конечном итоге к его несоответствию требованиям пользователя, требуемому стандарту и к последующей болезненной и трудоемкой его переделке. Эти обстоятельства, требуют тщательного отбора методик, моделей, методов оценки качества ПО, учета ограничений их пригодности для различных жизненных циклах и в пределах жизненного цикла, установления порядка их совместного использования, применения избыточного разномодельного исследования одних и тех же показателей для повышения достоверности текущих оценок, накопления и интеграции разнородной метрической информации для принятия своевременных производственных решений и заключительной сертификации продукции. Ниже, в таблице 1.3., приведены модели и метрики, хорошо зарекомендовавшие себя при оценке качества ПО, пригодные для прогнозирования и констатации различных показателей сложности и надежности программ.

Таблица 1.

Название модели	Формула, обозначение
МЕТРИКИ СЛОЖНОСТИ
Метрики Холстеда -длина программы; - объем программы - оценка ее реализации; - трудность ее понимания; - трудоемкость кодирования; - уровень языка выражения; - информационное содержание; - оптимальная модульность;	N = n1 log1 n1 + n2 log2 n2 V = N log2 n L*= (2 n2 )/ (n1 N2) Ec = V/ L* D = (n1N2) (2n2) = 1/ L*  * = V/ D2 = V/ L* 2 I = V / D M = n2*/6
Метрики Джилба - количество операторов цикла; - количество операторов условия; - число модулей или подсистем; - отношение числа связей между модулями к числу модулей; - отношение числа ненормальных выходов из множества операторов к общему числу операторов;	L1oop L IF L mod f = N4SV / L mod f * = N*SV / L
Метрики Мак-Кейба- цикломатическое число; - цикломатическая сложность;	(G) = m - n + p  (G) =   (G) +1 = m - n + 2
Метрика Чепена - мера трудности понимания программ на основе входных и выходных данных;	H = 0.5T+P+2M+3C
Метрика Шнадевида - число путей в управляющем графе	S =  Pi Ci
Метрика Майерса - интервальная мера;	[ 1  2]
Метрика Хансена - пара (цикломатическое число, число операторов)	{ , N}
Метрика Чена - топологическая мера Чена;	M(G) = ( (G), N, Q0)
Метрика Вудворда - узловая мера (число узлов передач управления);	 
Метрика Кулика - нормальное число (число простейших циклов в нормальной схеме программы);	Norm (P)
Метрика Хура - цикломатическое число сети Петри, отражающей управляющую структуру программы;	(G*р)
Метрики Витворфа, Зулевского -мера сложности потока управления -мера сложности потока данных;	(Р) (Р)
Метрика Петерсона - число многовходовых циклов;	Nm 1 0 0 p
Метрики Харрисона, Мэйджела - функциональное число (сумма приведенных сложностей всех вершин управляющего графа); - функциональное отношение (отношение числа вершин графа к функциональному числу); - регулярные выражения (число операндов, операторов и скобок в регулярном выражении управляющего графа программы);	f1 =   1 f* = N  1/ f1 p(G) = N+L+Sk
Метрика Пивоварского - модифицированная цикломатическая мера сложности;	N(G) = n*(G) +  Pi
Метрика Пратта - тестирующая мера;	Test (Pr)
Метрика Кантоне - характеристические числа полиномов, описывающих управляющий граф программы;	PCN*
Метрика Мак-Клура - мера сложности, основанная на числе возможных путей выполнения программы, числе управляющих конструкций и переменных;	C(V) = D(V) J(V) / N
Метрика Кафура - мера на основе концепции информационных потоков;	I(G)
Метрика Схуттса, Моханти - энтропийные меры;	 (G)
Метрика Коллофело - мера логической стабильности программ;	h (G)
Метрика Зольновского, Симмонса, Тейера Взвешенная сумма различных индикаторов: - (структура, взаимодействие, объем, данные); - (сложность интерфейса, вычислительная сложность, сложность ввода/вывода, читабельность);	 ( ,  ,  ,  )    ( ,  ,  ,  )
Метрика Берлингера - информационная мера;	I(R) = m (F* (R)  F-(R))2
Метрика Шумана - сложность с позиции статистической теории языка;	 ()
Метрика Янгера - логическая сложность с учетом истории вычислений; Сложность проектирования Насыщенность комментариями Число внешних обращений Число операторов	 ( ) Cc =  log2 (i + 1) [ n Cxy (n)] X = K/C Ci L1
ПРОГНОЗ МОДЕЛИ
Модели Холстеда - прогноз системных ресурсов; - прогноз числа ошибок. Модель фирмы IBM Модель общей сложности Модели связности Сплайн-модель	P=3/8 (Ra - 1)  2Ra B = Nlog2 n / 3000 B = 23M1 + M1 0 B = 21.1 + 0.1 V + COMP (S) Pij = 0.15 (Si + Sj) + 0.7 Cij Pij = ½   i ( Zij2 +  Nij2 ) ln ( Zij2 +  Nij2 ) +  +  Zi +  N1
ОЦЕНОЧНЫЕ МОДЕЛИ
Джелински - Моранды	R(t) = e - (Т - 1 + 1) t
Вейса-Байеса	R1 (t) =   e - l - (i -1)  )t (, F/t1, ... , ti-1) d dФ
Шика-Волвертона	R1 (t) = e - F( N - 1 + 1) ti2 / 2
Литтлвуда	R1 (t) = (b+/b++)- (N - i + 1) a
Нельсона	Rj (t) = exp { ln (1 - Pj)}
Халецкого	Rj (t) = P- a(1-  nj ) / nj
Модель отлаженности	Rj (t) =P-  fj (, ,)
Мозаичная модель	Rj (t) = 1 - (  - j - 1)

В таблице представлены разнообразные метрики сложности ПО для различных форм их представления, модели прогнозирующие ход развития процессов разработки ПО и вероятностные модели по оценке надежности. Кратко рассмотрим метрики сложности. Одной из основных целей научно-технической поддержки является уменьшение сложности ПО. Именно это позволяет снизить трудоемкость проектирования, разработки, испытаний и сопровождения, обеспечить простоту и надежность производимого ПО. Целенаправленное снижение сложности ПО представляет собой многошаговую процедуру и требует предварительного исследования существующих показателей сложности, проведения их классификации и соотнесения с типами программ и их местоположением в жизненном цикле.

Теория сложности программ ориентирована на управление качеством ПО и контроль ее эталонной сложности в период эксплуатации. В настоящее время многообразие показателей (в той или иной степени описывающих сложность программ) столь велико, что для их употребления требуется предварительное упорядочение. В ряде случаев удовлетворяются тремя категориями метрик сложности. Первая категория определяется как словарная метрика, основанная на метрических соотношениях Холстеда, цикломатических мерах Мак-Кейба и измерениях Тейера. Вторая категория ориентирована на метрики связей, отражающих сложность отношений между компонентами системы - это метрики Уина и Винчестера. Третья категория включает семантические метрики, связанные с архитектурным построением программ и их оформлением.

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

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

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

Именно топологические меры сложности наиболее часто применяются в фазе исследований, формирующей решения по управлению производством (в процессах проектирования, разработки и испытаний) и составляют доступный и чувствительный эталон готовой продукции, контроль которого необходимо регулярно осуществлять в период ее эксплуатации.

Первой топологической мерой сложности является цикломатическая мера Мак-Кейба. В ее основе лежит идея оценки сложности ПО по числу базисных путей в ее управляющем графе, т.е. таких путей, компонуя которые можно получить всевозможные пути из входа графа в выходы. Цикломатическое число  (G) орграфа G с n-вершинами, m-дугами и p-компонентами связности есть величина  (G) = m - n + p.

Имеет место теорема о том, что число базисных путей в орграфе равно его цикломатическому числу, увеличенному на единицу. При этом, цикломатической сложностью ПО Р с управляющим графом G называется величина  (G) =  (G) +1 = m - n + 2. Практически цикломатическая сложность ПО равна числу предикатов плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом предикатов. Данная мера отражает психологическую сложность ПО.

К достоинствам меры относят простоту ее вычисления и повторяемость результата, а также наглядность и содержательность интерпретации. В качестве недостатков можно отметить: нечувствительность к размеру ПО, нечувствительность к изменению структуры ПО, отсутствие корреляции со структурированностью ПО, отсутствие различия между конструкциями Развилка и Цикл, отсутствие чувствительности к вложенности циклов. Недостатки цикломатической меры привело к появлению ее модификаций, а также принципиально иных мер сложности.

Дж. Майерс предложил в качестве меры сложности интервал [ _1  ₂], где  ₁- цикломатическая мера, а  ₂ - число отдельных условий плюс единица. При этом, оператор DO считается за одно условие, а CASE c n - исходами за n - 1- условий. Введенная мера получила название интервальной мерой.

У. Хансену принадлежит идея брать в качестве меры сложности ПО пару {цикломатической число, число операторов}. Известна топологическая мера Z(G), чувствительная к структурированности ПО. При этом, она Z(G) = V(G) (равна цикломатической сложности) для структурированных программ и Z(G)  V(G) для неструктурированных. К вариантам цикломатической меры сложности относят также меру М(G) = (V(G),C,Q), где С - количество условий, необходимых для покрытия управляющего графа минимальным числом маршрутов, а Q - степень связности структуры графа программы и ее протяженность.

К мерам сложности, учитывающим вложенность управляющих конструкций, относят тестирующую меру М и меру Харрисона-Мейджела, учитывающих уровень вложенности и протяженности ПО, меру Пивоварского - цикломатическую сложность и глубину вложенности, и меру Мак-Клура - сложность схемы разбиения ПО на модули с учетом вложенности модулей и их внутренней сложности.

Функциональная мера сложности Харрисона-Мейджела предусматривает приписывание каждой вершине графа своей собственной сложности (первичной) и разбиение графа на сферы влияния предикатных вершин. Сложность сферы называют приведенной и слагают ее из первичных сложностей вершин, входящих в сферу ее влияния, плюс первичную сложность самой предикатной вершины. Первичные сложности вычисляются всеми возможными способами. Отсюда функциональная мера сложности ПО есть сумма приведенных сложностей всех вершин управляющего графа.

Мера Пивоварского ставит целью учесть в оценке сложности ПО различия не только между последовательными и вложенными управляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) =  ^*(G) +  P_i , где  ^*(G) - модифицированная цикломатическая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n- выходами рассматривается как один логический оператор, а не как n - 1 операторов. Р_i - глубина вложенности i - той предикатной вершины.

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

Мера Мак-Клура предназначена для управления сложностью структурированных программ в процессе проектирования. Она применяется к иерархическим схемам разбиения программ на модули, что позволяет выбрать схему разбиения с меньшей сложностью задолго до написания программы. Метрикой выступает зависимость сложности программы от числа возможных путей исполнения, числа управляющих конструкций и числа переменных (от которых зависит выбор пути). Методика расчета сложности по Мак-Клуру четко ориентирована на хорошо структурированные программы.

Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям: 1. Мера сложности простого оператора равна 1; 2. М ({F1; F2; ┘;Fn}) = е_iⁿ M(Fi); 3. М (IF P THEN F1 ELSE F2) = 2 MAX (M (F1), M (F2)); 4. М (WHILE P DO F) = 2 M(F).

Мера возрастает с глубиной вложенности и учитывает протяженность программы. К тестирующей мере близко примыкает мера на основе регулярных вложений. Идея этой меры сложности программ состоит в подсчете суммарного числа символов (операндов, операторов, скобок) в регулярном выражении с минимально необходимым числом скобок, описывающим управляющий граф программы. Все меры этой группы чувствительны к вложенности управляющих конструкций и к протяженности программы. Однако возрастает уровень трудоемкости вычислений.

Рассмотрим меры сложности, учитывающие характер разветвлений. В основе узловой меры Вудворда, Хедли лежит идея подсчета топологических характеристик потока управления. При этом, под узловой сложностью понимается число узлов передач управления. Данная мера отслеживает сложность линеаризации программы и чувствительна к структуризации (сложность уменьшается). Она применима для сравнения эквивалентных программ, предпочтительнее меры Холстеда, но по общности уступает мере Мак-Кейба.

Топологическая мера Чена выражает сложность программы числа пересечений границ между областями, образуемыми блок - схемой программы. Этот подход применим только к структурированным программам, допускающим лишь последовательное соединение управляющих конструкций. Для неструктурированных программ мера Чена существенно зависит от условных и безусловных переходов. В этом случае можно указать верхнюю и нижнюю границы меры. Верхняя - есть m+1, где m - число логических операторов при их гнездовой вложенности. Нижняя - равна 2. Когда управляющий граф программы имеет только одну компоненту связности, мера Чена совпадает с цикломатической мерой Мак-Кейба.

Метрики Джилба оценивают сложность графоориентированных модулей программ отношением числа переходов по условию к общему числу исполняемых операторов. Хорошо зарекомендовала себя метрика, относящаяся число межмодульных связей к общему числу модулей. Названные метрики использовались для оценки сложности эквивалентных схем программ, в особенности схем Янова.

Используются также меры сложности, учитывающие историю вычислений, характер взаимодействия модулей и комплексные меры.

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

Международный стадарт ИСО 9000-3