«В.В. Липаев ПРОЕКТИРОВАНИЕ И ПРОИЗВОДСТВО СЛОЖНЫХ ЗАКАЗНЫХ ПРОГРАММНЫХ ПРОДУКТОВ СИНТЕГ Москва - 2011 2 УДК 004.41(075.8) ББК 32.973.26-018я73 Л61 Липаев В.В. Проектирование и производство сложных заказных программных ...»

Институт системного программирования

Российской академии наук

В.В. Липаев

ПРОЕКТИРОВАНИЕ

И ПРОИЗВОДСТВО

СЛОЖНЫХ ЗАКАЗНЫХ

ПРОГРАММНЫХ

ПРОДУКТОВ

СИНТЕГ

Москва - 2011

2

УДК 004.41(075.8)

ББК 32.973.26-018я73 Л61 Липаев В.В.

Проектирование и производство сложных заказных программных продуктов. – М.: СИНТЕГ, 2011. – 408 с.

ISBN 978-5-89638-119-8 Монография состоит из двух частей, в которых изложены методы и процессы проектирования и производства сложных заказных программных продуктов для технических систем реального времени. Все компоненты и комплексы программ должны соответствовать требованиям заказчика, высокому качеству и минимальным рискам посредством верификации, тестирования, испытаний и сертификации, обеспечиваемыми коллективами квалифицированных специалистов. При изложении активно используются современные международные и отечественные стандарты, планирование производственных процессов с учетом ограниченных экономических ресурсов крупных проектов.

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

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

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

В.В. Липаев, автор, В.П. Мисник, предисловие, Институт системного программирования РАН ООО «НПО СИНТЕГ», издательство,

ОГЛАВЛЕНИЕ

Предисловие ………….…………………………………………….

Введение …………………………………………………………….

Часть 1 Проектирование заказных программных продуктов Глава 1.1. Системное проектирование комплексов программ Принципы системного проектирования комплексов программ. Структурное проектирование сложных программных комплексов. Системная и программная инженерия, процессы жизненного цикла систем и программных комплексов. Управление проектами программныхкомплексов в системе СMMI. Стандарты менеджмента (административного управления) качеством систем.

Глава 1.2. Подготовка коллектива специалистов для проектирования и производства заказных программных продуктов ………………………………………………………......

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

Глава 1.3. Проектирование требований к компонентам и комплексам программ ………………………………………..

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

Глава 1.4. Требования к характеристикам качества и допустимым рискам при проектировании процессов производства программных комплексов ………………….

Общие требования к качеству сложных программных комплексов.

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

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

Глава 1.6. Прогнозирование экономических характеристик процессов производства заказных программных продуктов ……………………………………………………………….

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

Часть 2. Производство заказных программных продуктов … Глава 2.1. Основные производственные процессы сложных заказных комплексов программ …………………………...

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

Глава 2.2. Организация верификации и тестирования компонентов и комплексов программ ………………………….

Процессы верификации компонентов и комплексов программ. Трассирование взаимодействия требований к компонентам в комплексах программ. Организация процессов тестирования компонентов и комплексов программ. Процессы и методы тестирования программных модулей и компонентов.

Глава 2.3. Тестирование потоков управления и потоков данных заказных программных модулей и компонентов …….

Стратегии выбора тестов потоков управления для программных модулей. Сложность тестирования потоков управления программных модулей. Корректность тестирования потоков управления программных модулей. Тестирование потоков данных программных модулей.

Тестирование модулей программ с учетом значений переменных и констант.

Глава 2.4. Планирование производства и тестирования заказных компонентов и комплексов программ ………… Планирование производства компонентов для комплексов программ.

Графики для планирования производства программных продуктов.

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

Глава 2.5. Тестирование при производстве сложных заказных динамических программных продуктов ……………..

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

Глава 2.6. Сопровождение сложных заказных программных комплексов …………………………………………………….

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

Глава 2.7. Управление конфигурацией и документирование сложных заказных программных комплексов …………...

Процессы управления конфигурацией программных комплексов.

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

Глава 2.8. Испытания, удостоверение качества и сертификация сложных заказных программных продуктов ………….

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

Приложение. Международные и государственные стандарты, регламентирующие проектирование и производство сложных заказных программных продуктов ……………………… Литература …………………………………………………………

ПРЕДИСЛОВИЕ

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

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

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

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

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

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

Генеральный директор - генеральный конструктор ФГУП «ЦНИИ «Комета», доктор технических наук,

ВВЕДЕНИЕ

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

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

Приступая к созданию сложных технических систем и продуктов, заказчики и разработчики, прежде всего, должны понять целесообразна ли их разработка и оценить возможную эффективность применения готового продукта, оправдаются ли затраты на его производство и использование. Поэтому сложные технические проекты традиционно начинаются с анализа и технико-экономического обоснования предстоящего проектирования, производства и применения предполагаемого продукта или системы. Заказчику и возможным потребителям результатов производства необходимо оценивать реальную потребность в его создании и конкурентоспособность, а потенциальному производителю предполагаемого продукта, проводить оценку реализуемости проекта при выделенных условиях и ресурсах, предлагаемых заказчиком [1, 26, 37].

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

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

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

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

Задачи целевого управления такими работами сводить воедино усилия руководителей, исполнителей специалистов разной квалификации, подрядчиков и субподрядчиков, добиваясь, чтобы они выступали как целевая «команда», а не как разрозненная группа функциональных специалистов с индивидуальными целями. Они характеризуются производственно-техническим, организационным и социальным единством [11, 26], которое определяется комплексом средств производства, обладающих технологической взаимосвязью отдельных этапов производственных процессов, в результате которых используемые на предприятии объекты и процессы превращаются в готовую продукцию. В результате должна обеспечиваться концептуальная целостность создания технических систем и высокое качество решения главных задач заказчиков при сбалансированном использовании ресурсов на все функциональные задачи. Рациональная организация предполагает такой способ экономически эффективного соединения всех производственных компонентов в единую взаимосвязанную систему, при которой используется наименьшее количество трудовых ресурсов, предметов труда и средств производства для изготовления требующегося продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРОЕКТИРОВАНИЕ ЗАКАЗНЫХ

ПРОГРАММНЫХ ПРОДУКТОВ

СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ

КОМПЛЕКСОВ ПРОГРАММ

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

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

Системное проектирование комплексов программ включает:

- принципы системного проектирования комплексов программ;

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

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

• адекватно описаны цели и объект проектирования ПК;

• предварительные спецификации требований к комплексу программ, его программным и информационным компонентам;

• стратегическое планирование проектирования ПК:

• рациональное использование ресурсов в процессе создания сложных ПК гарантированного качества;

• предварительное технико-экономическое обоснование проекта, приближенные значения трудоемкости и длительности всей разработки ПК;

- структурное проектирование программного комплекса;

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

• многоуровневое, иерархическое построение программного комплекса;

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

• унифицированные правила структурного построения и оформления спецификаций требований компонентов.

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

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

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

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

В системном проекте должны быть обобщены и отражены следующие основные результаты выполненных системных исследований и разработок (см.рис. 1.1):

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

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

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

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

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

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

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

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

• предварительный план организации работ, требования к составу и квалификации специалистов для выполнения проекта и всего жизненного цикла ПК;

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

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

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

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

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

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

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

Стратегическое планирование проекта должно содержать долгосрочные цели развития ПК определенного функционального назначения. На базе требований к ПК и первичных планов появляется возможность оценить объем подлежащих разработке компонентов программ и баз данных, а также некоторые дополнительные характеристики возможного объекта и среды разработки. По этим данным руководителем разработки и заказчиком принимается решение о целесообразности продолжения проектирования и осуществляется стратегическое планирование проекта, которое формализуется в техническом задании на ПК. Эти данные позволяют принимать решения по корректировке требований к ПК, по изменению среды разработки или состава коллектива специалистов. Таким образом, последовательное прогнозирование, планирование и системное управление проектом обеспечивают рациональное использование ресурсов в процессе создания сложных ПК гарантированного качества [4, 35].

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

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

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

Структурное проектирование сложных программных Основные принципы и правила структурирования ПК можно объединить в группы, которые отражают (см. рис. 1.1):

• стандартизированную структуру целостного построения ПК и/или БД определенного класса;

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

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

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

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

• унифицированные правила внешнего интерфейса и взаимодействия компонентов ПК и БД с внешней средой, с операционной системой и другими типовыми средствами организации вычислительного процесса, защиты и контроля системы [8, 19].

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

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

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

• соответствие функций и структуры ПК аппаратной и операционной среде, их ресурсам и интерфейсам;

• совместимость ПК с другими системами по источникам и потребителям информации;

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

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

• состав, структура и способы обмена данными между функциональными компонентами и внешней средой;

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

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

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

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

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

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

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

• взаимозависимость действий компонентов верхних уровней от реакций на воздействия и от функционирования компонентов нижних уровней, информация о которых передается верхним уровням.

В результате в иерархических структурах ПК образуются два потока взаимодействий между компонентами разных уровней:

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

Менее наглядными являются иерархия данных, обрабатываемых ПК, и их взаимодействие с программными компонентами.

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

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

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

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

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

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

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

• при работе с элементами каждого модуля отдельно (игнорируя элементы других модулей);

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

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

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

• программных модулей, оформляемых как законченные компоненты текста программ;

• функциональных групп (компонентов) или пакетов программ;

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

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

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

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

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

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

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

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

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

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

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

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

• возможность расширения ПК, а также переноса (мобильность) программных компонентов и систем, разработанных должным образом, с минимальными изменениями на широкий диапазон аппаратных и операционных платформ;

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

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

Проектирование и производство заказных технических систем и программных продуктов регламентируют четыре крупные комплексы международных стандартов:

• Стандарт ГОСТ Р ИСО/МЭК 12207.2007 – Системная и программная инженерия, процессы жизненного цикла систем и программных комплексов;

• CMMI – Система и модель оценки зрелости, управление проектами программных средств;

• ГОСТ Р ИСО/МЭК 9000:2000 – Стандарты менеджмента (административного управления) качеством систем;

• Стандарт ISO 19759:2005 – SWEBOK, Совокупность знаний о разработке программных средств. Руководство.

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

Системная и программная инженерия, процессы жизненного цикла систем и программных комплексов Стандарт ГОСТ Р ИСО/МЭК 12207.2007 – предоставляет широкую совокупность процессов, облегчающих связи между заказчиками, производителями, приобретающими сторонами, поставщиками и другими правообладателями в течение жизненного цикла систем и программных продуктов – рис. 1.2. Он разработан для организаций, проектирующих, разрабатывающих, приобретающих системы и программные продукты, а также для менеджеров (в том числе, менеджеров по качеству) и пользователей программных продуктов. Стандарт предназначен для использования при двусторонних отношениях заказчик – поставщик и может применяться также в случае, когда обе стороны принадлежат одной и той же организации. Такие отношения могут варьироваться от неформального соглашения вплоть до официального контракта.

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

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

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

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

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

В стандарте устанавливается общая структура работ для жизненного цикла систем и для программных комплексов. Процессы в контексте системы делятся на три группы: процессы соглашений, проекта системы и технические процессы (всего 23 процесса). Раздел процессов комплексов программ включает две группы из 18 процессов: процессы реализации и процессы поддержки комплексов. По названиям они в значительной степени подобны процессам в стандарте ISO 12207:1995, но различаются по содержанию. Жизненный цикл начинается от замысла или потребности, которая может быть удовлетворена полностью или частично системой или программным комплексом, и завершается прекращением его применения. Такая архитектура создается совокупностью процессов и взаимосвязями между этими процессами. Определение процессов жизненного цикла основываются на двух базовых принципах: связности и ответственности. Связность: процессы жизненного цикла являются связными и соединяются оптимальным образом, считающимся практичным и выполнимым. Ответственность: процесс может передаваться под ответственность какойлибо организации в жизненном цикле системы или программного комплекса.

Каждый процесс настоящего стандарта описывается в терминах следующих атрибутов:

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

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

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

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

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

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

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

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

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

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

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

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

Описание процессов ЖЦ ПК в CMMI сфокусировано на поэтапном определении, реально достигаемых результатов и на оценивании качества их выполнения. Качество процессов зависит от технологической среды, в которой они выполняются. Зрелость процессов это степень их управляемости, возможность поэтапной количественной оценки качества, контролируемости и эффективности результатов – рис.1.3.

Два варианта модели CMMI – созданы для обеспечения непрерывного оценивания комплекса процессов в определенной области создания программных средств или для поэтапного оценивания и совершенствования зрелости предприятия, а также для организации ЖЦ комплексов программ в целом.

Рис. 1.3.

Модели CMMI представляют помощь специалистам при организации технологии и совершенствовании их продуктов, а также для упорядочения и обслуживания процессов разработки и сопровождения ПК. Концепция этих моделей покрывает управление и оценивание зрелости сложных систем, инженерии программных средств, а также процессов cоздания интегрированных программных продуктов и совершенствования их разработки. Компоненты непрерывной и поэтапной моделей в значительной степени подобны, могут выбираться и применяться в разном составе и последовательности использования в зависимости от свойств и характеристик конкретных проектов [29, 47].

Варианты описания моделей построены по единой схеме, которая содержит общие разделы: предисловие; 1. введение; 2. модель компонентов; 3. терминология; 4. содержание уровней и главные компоненты каждого варианта модели (разработка целей и процедур); 5 раздел – структура взаимодействия процессов. Аннотированы четыре категории процессов раздела 7, их общий обзор и схемы взаимодействия CMMI процессов:

• менеджмент процессов;

• менеджмент – управление проектом;

• инжиниринг (технология);

6 раздел – использование модели CMMI – краткие рекомендации для пользователей по применению модели и обучению; отмечается совместимость и соответствие процессов модели. Последний, седьмой раздел самый большой в каждом стандарте, он занимает около 500 страниц из полного объема документа, который составляет свыше 700 страниц.

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

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

Планирование проекта в первой модели, так же, как и во второй модели, включает:

• оценку возможного размера – масштаба программного продукта;

• оценку сложности функций и характеристик проекта ПК;

• определение модели и этапов жизненного цикла комплекса программ;

• технико-экономическое обоснование проекта – определение стоимости, трудоемкости и длительности ЖЦ ПК;

• разработка поэтапного графика работ и бюджета проекта;

• анализ, идентификация и оценка проектных рисков;

• планирование и управление документированием процессов и продуктов в ЖЦ проекта ПК;

• планирование и распределение технических и людских ресурсов по этапам ЖЦ ПС;

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

• обобщение и анализ совокупности планов проекта ПК;

• согласование работ и ресурсов по этапам ЖЦ разработчиком с заказчиком проекта ПК;

• документирование плана работ и утверждение его менеджером разработчиков проекта.

Процессы разработки требований к программному продукту аналогичны процессам в обеих моделях и включают:

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

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

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

• декомпозицию базовых исходных требований к функциям ПС в набор требований к компонентам и тестам комплекса программ;

• формализацию требований к интерфейсам между компонентами, с операционной и внешней средой;

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

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

Управление требованиями в обеих моделях включает:

• достижение однозначного понимания требований к проекту ПК заказчиком и разработчиками;

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

• согласованное между заказчиком и разработчиком управление изменениями требований к проекту ПК;

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

• выявление и идентификация несоответствий между процессами разработки проекта и требованиями заказчика.

Второй вариант модели CMMI – поэтапное представление.

Первый уровень отличается значительной неопределенностью состава и содержания процессов в различных относительно простых проектах, поэтому он в документе не описан и не комментируется. Рекомендуется ограничиваться четырьмя (2-й – 5-й) основными уровнями – (см. рис. 1.3):

- второй уровень – формализует базовое управление проектами:

• управление требованиями;

• планирование проекта;

• мониторинг и контроль проекта;

• управление соглашениями с поставщиками;

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

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

• управление конфигурацией;

- третий уровень – содержит стандартизацию основных процессов:

• разработка требований;

• технические решения;

• интеграция продукта;

• верификация;

• валидация (аттестация);

• определение организационных процессов;

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

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

• интегрированное управление поставщиками;

• анализ и разрешение проблем (устранение дефектов);

• организация окружения для интеграции;

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

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

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

- пятый уровень – оптимизационный, непрерывное совершенствование:

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

• анализ причин дефектов, совершенствование качества и управления процессами и продуктами.

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

• общие цели процесса, которые должны быть достигнуты;

• вводные замечания и общее описание функций процесса;

• специфические цели процесса;

• менеджмент процесса;

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

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

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

• планирование действий в определенном процессе;

• анализ и валидация (утверждение) результатов реализации процесса;

• мониторинг и контроль выполнения процесса.

Особое внимание в моделях CMMI уделяется процессам менеджмента проекта ПК. Эти требования и процессы моделей практически соответствуют, регламентированным и детализированным рекомендациям в стандартах ISO 9001:2000, ISO. Требованиям к процессам в функциональных разделах 4 – 8 стандартов ISO 9001, ISO 9004, ISO 90003 может быть сопоставлен адекватный по содержанию ряд разделов в моделях CMMI.

Для определения, представленных выше уровней зрелости процессов обеспечения жизненного цикла КП, разработан обширный технический отчет ISO 15504:1-5:2003-2006 – Оценка и аттестация зрелости процессов создания и сопровождения ПК и систем в составе пяти частей. Стандарт регламентирует оценку и аттестацию зрелости процессов создания, сопровождения и совершенствования программных средств и систем, выполняемых предприятиями.

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

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

• ISO 9000:2000 – представляет введение в системы управления качеством продукции и услуг и словарь качества;

• ISO 9001:2000 – устанавливает детальные требования для систем управления качеством, достаточные в случае необходимости продемонстрировать способность предприятия, обеспечить соответствие качества продукции и услуг требованиям заказчика;

• ISO 9004:2000 – содержит руководство по внедрению и применению широко развитой системы управления качеством, чтобы достичь постоянного улучшения деловой деятельности и результатов предприятия.

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

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

• обязанности и ответственность администрации управления качеством (раздел 5);

• административное управление ресурсами (раздел 6);

• процессы жизненного цикла продукции и управления ее качеством (раздел 7);

• измерения, анализ и совершенствование продукции (раздел 8).

Стандарт ISO 9001:2000 – Система менеджмента (административного управления) качества. Требования – является базой для Руководства по их реализации в стандарте ISO 9004:2000 – Общие требования к системе менеджмента качества. Организация – разработчик должна установить и управлять процессами, необходимыми для обеспечения уверенности в том, что продукция и/или услуга соответствуют требованиям заказчика. В качестве способа внедрения и демонстрации, установленных процессов, организация должна создать систему менеджмента качества, основываясь на требованиях настоящего международного стандарта.

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

• создания и поддержания важности удовлетворения требований заказчика;

• разработки политики качества и целей в области качества, а также планирования качества;

• создания системы менеджмента качества;

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

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

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

• соответствует потребностям организации и её заказчиков;

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

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

• распространена, понята и внедрена во всей организации;

• анализируется с целью постоянного поддержания ее пригодности.

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

• обеспечения уверенности в том, что система менеджмента качества внедрена и поддерживается в рабочем состоянии в соответствии с требованиями настоящего международного стандарта;

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

• обеспечения уверенности в осознании во всей организации требований заказчика.

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

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

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

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

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

• ведению соответствующих отчетов об образовании кадров, их подготовке, уровне мастерства и опыта.

Организация должна создать процесс идентификации требований заказчика:

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

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

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

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

Входные данные для проектирования и разработки должны включать:

• эксплуатационные требования заказчика или рынка;

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

• применяемые требования по охране окружающей среды;

• любые другие требования, существенные для проектирования и разработки.

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

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

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

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

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

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

• взаимодействие между элементами проекта и/или разработки:

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

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

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

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

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

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

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

• подходящих методов для выпуска, поставки и/или монтажа продукции.

Стандарт ISO 90003:2004 – Рекомендации по применению стандарта ISO 9001:2000 для программных продуктов – предназначены для регламентирования менеджмента при приобретении, поставке, разработке, применении, сопровождении сложных программных продуктов и при их обслуживании. Стандарт предлагается при установлении соответствия требованиям комплексов программ:

• как части коммерческого контракта с другими организациями;

• при представлении полезного продукта для рынка;

• для использования при поддержке процессов организации проектов ПК;

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

• при организации сервиса программных продуктов.