CC BY
40
риалов (в том числе ПИ на машинном носителе) и подлежащих разработке программных документов с указанием фаз жизненного цикла ПИ, на которых разработка должна выполняться, а также требования к качеству изготовления текстовых документов и тип машинных носителей ПИ.
Порядок контроля и приемки. В этом разделе устанавливаются общие требования к контролю работ по разработке ПИ и приемке выполненных работ на различных фазах жизненного цикла ПИ. Определяются критерии определения качества ПИ, представитель заказчика (или другие персоны, указанные заказчиком), который будет осуществлять опытную эксплуатацию готового ПИ.
В заключение отметим, что при определении набора рубрик шаблона и их содержания мы руководствовались принципом разумной достаточности и исходили из обеспечения возможности составления однозначных, хорошо понятных и тестируемых требований к ПИ. При этом не ставилась задача доказательства полноты и достаточности набора требований к ПИ, включенного в шаблон (это очень сложная задача). Успешное выполнение с высоким качеством более 10 проектов ПИ для различных предметных областей подтвердило разумность такого подхода к составлению требований.
Описания конкретных процедур и стандартов технологии разработки ПИ представляют собой интеллектуальную собственность предприятия и, как правило, не подлежат огласке. Однако в первой части статьи есть все указания на то, что должно быть сделано для получения эффективной технологии разработки ПИ. А вот как это должно быть сделано, выносится на суд конкретного предприятия. Заметим, что большую пользу при этом приносит изучение предшествующего опыта работы и включение в новую технологию лучшего, что было достигнуто в разработке ПИ.
Список литературы
1. Paulk M.C., Curtis B., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. - Pittsburgh: Software Engineering Institute, 1993. - 533 p.
2. Humphrey G. Managing the Software Process - Reading: Addison-Wesley, 1989. - 494 p.
3. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504): - Изд-во: Компания "АйТи", Книга и бизнес. - 2001. - 348 с.
4. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий. - М.: Наука, Физматлит. - 2000. - 176 с.
АВТОМАТИЗАЦИЯ ИНТЕГРИРОВАННОГО УПРАВЛЕНИЯ
ПРОЕКТАМИ
А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Как показывает опыт, трудность внедрения процесса [1] заключается в том, что при разработке программного изделия (ПИ) главным действующим лицом является человек, который, как известно, обладает и достоинствами, и недостатками. Однако при внедрении процесса приходится сталкиваться больше с недостатками человека, чем с его достоинствами. Причем проявляются прежде всего те недостатки, которые порождены природой человека, - сопротивление всему, что ограничивает его свободу в каком-либо смысле. Этот недостаток проявляется даже тогда, когда некоторое ограничение свободы выбора организационной культуры при проведении работ по созданию ПИ дает положительный результат и приводит к удачному выполнению программного проекта.
Поскольку процесс - это систематизированный набор механизмов, формальных процедур и стандартов, обусловливающий успешное выполнение проекта, то всю деятельность по проекту он ограничивает определенными рамками. Эти рамки воспринимаются многими программистами (особенно программистами со стажем успешной работы) как ограничение свободы в их труде, хотя процесс не несет никаких ущемлений свободы в их творческой деятельности.
В таких условиях требуются значительные усилия и терпение со стороны руководства предприяти-
ем, чтобы наладить работу программистов по установленному процессу. С ростом совершенства процесса растет набор механизмов, процедур и стандартов, которые необходимо выполнять или соблюдать, что еще в большей степени вызывает сопротивление внедрению процесса со стороны программистов. В этой ситуации для сокращения этапа внедрения процесса необходимо использование автоматизированных средств выполнения механизмов, процедур и соблюдения стандартов. Таким автоматизированным средством является система, описанию которой посвящена настоящая статья. Эта система разработана и применяется в АОЗТ ИДУ с 1998 года; она получила название "Автоматизированная система интегрированного управления проектами (АСС)". С использованием системы АСС происходит объединение деятельности по управлению проектом и технической разработкой ПИ в единый интегрированный проектный процесс.
АСС состоит из трех согласованных автоматизированных рабочих мест (АРМ), предназначенных для руководства предприятия, руководителей проектов и разработчиков ПИ. Наибольшими функциональными возможностями из перечисленных АРМов обладает АРМ руководителя проекта. С его помощью можно осуществлять автоматизированное составление и редактирование проектных планов раз-
13
личной степени детализации (годовых, квартальных, месячных, недельных), ведение базы данных проектных планов; персонифицированный сбор и анализ установленных стандартным процессом метрик, ведение метрической базы данных проекта, а также выполнять автоматизированный анализ ошибок и дефектов, допущенных в проекте ПИ, и т.д. С помощью этого АРМа руководитель проекта может легко выявлять надвигающиеся проблемы и вырабатывать действия по их предотвращению.
Наиболее простым является АРМ разработчика, в задачи которого входит, в основном, облегчение выполнения разработчиками ПИ часто встречающихся формальных процедур, таких как процедуры ежедневного занесения в метрическую базу данных метрик, определенных метрической программой, а также процедуры заполнения ведомости предъявленных, открытых и закрытых отклонений, выявляемых в проекте.
АРМ для руководства предприятия позволяет выполнять функцию контроля за соблюдением участниками проекта многих процедур, некоторых механизмов и стандартов, установленных процессом. Функция контроля может осуществляться руководством предприятия самостоятельно в любое время в течение рабочего дня незаметно для участников проверяемого проекта.
Архитектура системы АСС, изображенная на рисунке 1, представляет возможности системы АСС. Из рисунка видно, что в локальной сети реализованы и система АСС, и сервер коллективного пользования, в дисковом пространстве которого для каждого проекта выделена достаточная область для реализации системы управления конфигурацией. В этой же области отведено место для создания резервных копий и ведения библиотеки базовых версий создаваемых продуктов. Кроме того, в дисковом пространстве
14
сервера коллективного пользования расположен архив проектов и установлена библиотека процесса, в которой собраны все формальные процедуры и стандарты, а также представлена документация механизмов, введенных стандартным процессом. Библиотека процесса и архив проектов являются ресурсами коллективного пользования.
База данных проекта и его метрическая база данных расположена в АРМе руководителя проекта. Эти базы защищены от несанкционированного доступа и являются основой для формирования всех предусмотренных процессом отчетов и графиков. Они доступны только для чтения и формирования необходимых контрольных данных со стороны АРМа руководства предприятием, для чтения планов и записи ежедневных метрик со стороны АРМов разработчиков. Руководитель проекта имеет полный доступ к базам данных своего АРМа. Он использует данные из них для текущего планирования в ритме выполнения проекта, балансировки почасовой ежедневной загрузки разработчиков, создания технических отчетов и исполнения других установок стандартного процесса.
Для каждого проекта в локальной сети организуется свой сектор, в который включается один АРМ руководителя проекта и несколько (по числу разработчиков) АРМов разработчиков. Архитектура системы АСС на локальной сети позволяет организовать автономное автоматизированное выполнение стандартов и процедур стандартного процесса одновременно в произвольном количестве проектов. Число проектов ограничивается лишь числом секторов, которое можно организовать в конкретной локальной сети. При этом для контроля над соблюдением стандартного процесса будет использоваться единственный АРМ руководства предприятием. Кроме того, такая архитектура обусловливает возможность автономной модификации каждого АРМа системы.
Рис. 2. Учетная карточка проекта
Создание резервных ко] I Управление конфигурацией 1 Библиотека базовых вер| Библиотека процесса
База данных проекта Метрическая база данных проекта Оценка объема I Планирование Отслеживание хода I Прогнозные расчеты Предотвращение дефектов Учетная карточка проекта Шаблоны документов Подготовка операционных обзоро Другие плановые работы
У
АРМ руководителя проекта (Win98, Ms Office, Ms Project)
АРМ разработчика
№98,
I Плановые работы I Заполнение ведомости
Запись метрик Получение план
П
АРМ руководства
предприятием (Win98, Ms Project, Ms Office)
процесса в
Рис. 1. Архитектура системы АСС
АРМ руководителя проекта. Учетная карточка проекта показана на рисунке 2, из которого видно, что в учетную карточку, кроме полного и сокращенного названия проекта, входят ключевые характеристики проекта, установленные документом "Положение о работе", и другие важные характеристики, а также штатное расписание проектной группы, составляемое руководителем проекта в интерактивном режиме. Набор представленных на рисунке 2 характеристик превращают учетную карточку в паспорт проекта, который сопровождает проект в течение всего его жизненного цикла.
После запоминания учетной карточки в базе данных проекта инициалы каждого сотрудника из составленного штатного расписания используются во всех базах данных проекта. К ним привязываются метрики и другая информация, необходимая для управления проектом. Инициалы персон штатного расписания, например, используются при распределении ответственности в процессе планирования. По окончании планирования инициалы персон в базе данных проекта оказываются связанными с соответствующими плановыми работами. Все плановые работы сохраняются в базе данных даже для уволенных в ходе выполнения проекта сотрудников. Это сделано для возможности воссоздания неискаженной истории выполнения проекта.
Автоматизированные прогнозные расчеты. Система АСС обеспечивает выполнение автоматизированных прогнозных расчетов численности проектной группы и сроков выполнения проекта. Умение правильно прогнозировать характеристики будущих проектов является одним из требований ключевой области второго уровня зрелости "Планирование проекта". Правильно выполненный прогноз характеристик нового проекта позволяет так сбалансировать его ресурсы, чтобы он был завершен в срок, с заданным качеством и без превышения выделенного бюджета.
Прогнозные расчеты чрезвычайно полезны при обсуждении с заказчиком ресурсов нового проекта. Прогнозные оценки длительности проекта и численности проектной группы выполняются в системе АСС с использованием метрик стандартного процесса. Это обеспечивает руководителю проекта возможность обоснованной аргументации своих предложений по потребным финансовым ресурсам для нового проекта.
В основу реализации расчетов положены реальные метрики стандартного процесса, представленные в графическом виде [2]. На рисунке 3 справа по оси абсцисс отложена метрика стандартного процесса, определяющая длительность фазы системного тестирования (27% от
общей трудоемкости проекта), и метрика заключительной фазы (2% от общей трудоемкости проекта).
Для осуществления прогнозных расчетов руководитель проекта, исходя из своего предшествующего опыта, должен определить предполагаемый объем ПИ в КЛЕЬОС и коэффициент риска нового проекта. При затруднениях в определении объема ПИ рекомендуется привлечь независимых экспертов (как правило, не менее трех) и получить их персональные оценки, которые следует усреднить и использовать в дальнейших расчетах полученным средним значением объема ПИ в КЛЕЬОС.
После установления предполагаемого объема нового ПИ необходимо определить метрику повторного использования результатов предыдущих разработок в новом проекте и определить долю повторного использования для каждой фазы жизненного цикла нового проекта в отдельности.
Затем необходимо записать рекомендуемый заказчиком срок разработки, ожидаемый размер ПИ, доли повторного использования в фазах жизненного цикла разработки ПИ в таблицу исходных данных и выполнить расчет требуемой численности. Полученная численность разработчиков будет гарантировать выполнение проекта в срок, если каждый член проектной группы имеет метрику трудоемкости создания ПИ не ниже, чем значение соответствующей метрики стандартного процесса.
Если же численность разработчиков окажется неприемлемо большой, можно по удовлетворительному размеру проектной группы определить оценку новой длительности разработки с уменьшенным числом разработчиков.
Изменяя величину долей повторного использования во всех фазах жизненного цикла разработки ПИ, производительности или других метрик стандартного процесса, можно найти приемлемые значения срока разработки и численности разработчиков. По окончании расчетов значения метрик, установленные в таблице исходных данных системы АСС,
Рис. 3. Метрики стандартного процесса и прогнозируемые характеристики нового проекта
15
следует принять в качестве значений метрик проектного процесса для нового проекта. Разумеется, в ходе выполнения проекта необходимо постоянно следить за соответствием метрик проектного процесса, положенных в основу плана, фактическим и при необходимости вносить корректирующие воздействия в ход выполнения проекта.
Любые изменения в таблице входных переменных, показанной на рисунке 3, приводят к соответствующим изменениям таблицы прогнозируемых показателей и вида графика. Нужный результат в этом случае достигается путем итеративной процедуры, заключающейся в последовательном изменении значений входных переменных.
В системе АСС предусмотрен и графический способ изменения входных переменных. Для использования этого режима необходимо активизировать диаграмму рисунка 3, установить визир в положение, соответствующее требуемому сроку завершения проекта, и произвести вычисления прогнозируемого значения численности проектной группы или трудоемкости.
Нажатие кнопки "ОТМЕНИТЬ ПЕРЕСЧЕТ ГРАФИКА" позволяет вернуться в состояние, имевшее место до активизации диаграммы, не производя при этом никаких изменений.
Нажатие кнопки "РАСЧЕТ ЧИСЛЕННОСТИ" или "РАСЧЕТ ПРОИЗВОДИТЕЛЬНОСТИ" дает возможность автоматически получить новые значения прогнозируемых данных, соответствующих выбранному сроку окончания проекта.
Система АСС отслеживает допустимые значения входных переменных, выдавая при неправильном вводе данных предупреждающие сообщения.
В окне графического режима (рис. 3) представлено 17 переменных (14 в таблице входных переменных и 3 в таблице расчетных показателей). Всего в модели насчитывается более 100 переменных. Для обеспечения возможности более тонкого управления моделью и получения дополнительной информации о ходе расчета в системе АСС предусмотрен табличный режим работы. Вход в режим обеспечивается нажатием кнопки "ПЕРЕХОД К ТАБЛИЧНОЙ ФОРМЕ".
Планирование. АРМ руководителя проекта обеспечивает автоматизированное создание проектных планов разной степени подробности (годовых, квартальных, месячных, недельных) [3]. Наличие иерархии проектных планов позволяет руководителю проекта ежедневно оценивать объем выполненных работ каждым исполнителем. Кроме того, он имеет возможность ежедневного оценивания реальной трудоемкости выполненных работ и сравнения их с плановой трудоемкостью. В результате этого у руководителя проекта появляется возможность еженедельной (ежедневной) корректировки загрузки каждого разработчика, уточнения месячных и квартальных планов, предвидения приближения критических ситуаций и своевременного принятия необходимых действий по их предотвращению. Иными словами, у руководителя проекта появляется в руках эффективный инструмент для управления проектом.
Отслеживание и анализ хода выполнения проекта. В АРМе установлены наглядные формы и способы отображения состояния проекта ПИ, определенные процессом [4]. Все формы отчетов генерируются автоматически. Наличие наглядных отчетов о статусе проекта обеспечивает всем заинтересованным лицам, в том числе заказчику, возможность своевременного принятия эффективных мер всякий раз, когда выполнение проекта отклоняется от плановых показателей. В АРМе также выполняется автоматическая генерация ретроспективных метрических отчетов за выбранный период времени. Генерация отчетов может осуществляться в течение жизненного цикла разработки или по завершении проекта. Ретроспективные отчеты являются объективным средством для сохранения и использования накопленного опыта и знаний в прошлом, для увеличения эффективности выполнения текущего проекта или проектов в будущем.
Метрическая база данных проекта. Для сбора метрических данных осуществляется ежедневный автоматизированный персонифицированный сбор метрик, определенных стандартным процессом. С целью повышения достоверности, строгого соблюдении правил сбора и хранения метрик в системе АСС используется электронная форма заполнения метрик [5]. Для обеспечения сохранности уровня достоверности собираемых метрик, определенных исполнителем работы, введена защита метрической базы данных от несанкционированного доступа после записи в нее очередных данных, то есть запрещена корректировка метрик в базе данных сразу после их записи и в последующие моменты времени. По метрическим данным осуществляется автоматическая генерация всех метрических отчетов, обусловленных стандартным процессом, отчетов по предотвращению дефектов в проектах и на предприятии в целом, отчетов, которые используются при отслеживании хода выполнения проектов на еженедельных и ежемесячных научно-организационных семинарах.
Оценка объема выполнения. Руководитель проекта имеет возможность с использованием специальной экранной формы ежедневно определять объем выполнения плановых работ в процентах и заносить значения в базу данных проекта, после чего эти работы отмечаются специальным образом в таблице проектного плана.
Даты фактического окончания плановых работ и затраченная на их выполнение трудоемкость используются для генерации метрических отчетов по проекту и отчетов отслеживания хода выполнения проектов.
Предотвращение дефектов. Автоматизация деятельности по предотвращению дефектов подробно описана в [6]. Отметим, что деятельность по предотвращению дефектов в проекте является основой для повышения качества создаваемых продуктов. Поскольку эта деятельность требует определенных затрат личного времени каждого программиста, то деятельность по предотвращению дефектов многими программистами (особенно программистами со ста-
16
Рис. 4. Меню шаблонов
жем успешной работы, которые ошибочно считают, что они в процессе разработки ПИ не допускают отклонений) воспринимается как обуза.
Важно, чтобы каждый программист в проектной группе воспринимал деятельность по предотвращению дефектов (впрочем, как и любую деятельность по процессу) необходимой составной частью общего успеха проектной группы. Руководитель проекта
ОТСЛЕЖИВАНИЕ ХОДА ВЫПОЛНЕНИЯ ПРОЕКТОВ
АНАЛШ ХОДА ВЫПОЛНЕНИЯ ПРОЕКТОВ
| УПРАВЛЕНИЕ ХОДОМ ВЫПОЛНЕНИЯ ПРОЕКТОВ
НАСТРОЙКА СИСТЕМЫ
Рис. 5. Главное меню АРМа руководителя предприятия
должен создать в проектной группе такую творческую атмосферу, чтобы каждый разработчик считал, что он занимается не только конкретным плановым делом, но и строит вместе со всеми новое ПИ. Только наличие чувства причастности к общему успеху у каждого программиста создаст атмосферу, в которой может результативно выполняться любая деятельность по процессу, в том числе и по предотвращению дефектов. Руководитель проекта должен отдавать себе отчет в том, что силовым способом невозможно насадить организационную культуру, установленную процессом. Наш опыт показал, что правильная политика администрации предприятия и руководителя проекта, активная позиция каждого сотрудника проектной группы и использование автоматизированных средств приводит к положительному результату при внедрении и совершенствовании процесса.
Шаблоны документов. В
АРМе руководителя проекта предусмотрено специальное меню
установленных стандартным процессом шаблонов, которыми руководитель проекта должен пользоваться при создании поставляемых документов (рис. 4). Каждый шаблон, кроме формы, имеет текстовое содержание, которым следует пользоваться при составлении того или иного документа. Этим достигается не только одинаковая форма всех документов, выходящих из проекта, но и обусловливается смысловое содержание общих разделов в каждом документе.
Следует отметить, что достичь полного устного взаимопонимания в вопросах оформления документов со всеми руководителями проектов не удается. Даже тогда, когда содержание каждого документа согласовано с каждым руководителем проекта, все равно найдется кто-либо, который что-то или все сделает не так. Надо признаться, что и использование руководителями проектов шаблонов иногда приводит к подобным результатам. Для исправления таких ошибок в каждом проекте должен быть сотрудник (или группа), которому поручена роль по контролю качества. Этот сотрудник должен обозревать каждый документ, выходящий из проектной группы. Целью таких обзоров является обнаружение отклонений и последующее их устранение.
АРМ разработчика. Как отмечалось, АРМ разработчика является самым простым в системе АСС. Однако именно с его помощью осуществляется сбор ежедневных метрик (объективных данных о свойствах проекта, продуктов и процесса). Поэтому очень важно обеспечить сохранность достоверности внесенных данных в метрическую базу. Для этого в АРМе разработчика предусмотрены специальные меры [5]. Заметим, что достоверность метрик определяется добросовестностью и прилежанием разработчика, который вносит метрики в базу данных. Руководитель проекта обязан личным примером показывать важность и необходимость достоверной работы по сбору метрик, так как их накопление в метрической базе является фундаментом, на котором строится управление проектом.
АРМ администрации предприятия. Одной из основополагающих установок СММ является постоянный контроль над выполнением проектного плана и соблюдением всех предписаний процесса. Такой
Рис. 6. Меню отслеживания хода выполнения проектов
17
контроль должен осуществляться во время проведения формальных и неформальных обзоров персоной (или группой), ответственной за качество в проекте, руководителем проекта. Все проектные группы должны проверяться группой процесса и группой обеспечения качества, а последней инстанцией контроля должна стать администрация предприятия.
Для повышения действенности исполнения контроля за соблюдением проектного плана и предписаний процесса администрацией предприятия в системе АСС предусмотрен специальный АРМ. Этот АРМ значительно сокращает время, необходимое для получения данных, подлежащих контролю, за счет автоматической генерации и заполнения данными проверочных форм. При этом руководителю предприятия достаточно только выбрать в меню необходи-
мую строчку и щелкнуть по ней клавишей мыши. Главное меню АРМа руководителя предприятия показано на рисунке 5, а некоторые подменю - на рисунках 6-8.
Из рисунков 5-8 видно, что АРМ руководителя предприятия обеспечивает контроль за соблюдением всех установок стандартного процесса. С помощью этого АРМа руководитель предприятия может генерировать все метрические отчеты и отчеты отслеживания (еженедельный, двухнедельный, месячный, ретроспективный), а также все отчеты по качеству. Это дает возможность руководству предприятия постоянно иметь объективную картину хода выполнения каждого проекта и представление о качестве выпускаемых продуктов, а также оценивать уровень соблюдения процесса в каждом проекте.
На рисунке 9 показана форма, по которой контролируется наличие плана и почасовая ежедневная загрузка каждого сотрудника проектной группы в любой выбранный отрезок времени жизненного цикла проекта.
Такой контроль над планом и почасовой загрузкой сотрудников, а также другие метрические данные создают объективные предпосылки для оценки руководством предприятия значимости в проекте того или иного сотрудника. Оценку значимости сотрудников целесообразно проводить не реже раза в квартал. Полученные оценки следует использовать при принятии решения о возможности повышения сотруднику должностного оклада или о продвижении его вверх по служебной лестнице.
Система АСС охватывает автоматизацией деятельность не из всех ключевых областей СММ. В таблице представлены ключевые области модели
Рис. 9. Форма для контроля ежедневных планов и почасовой загрузки сотрудников
Таблица
Ключевые области модели СММ, накрываемые системой АСС
Уровень Характеристика Ключевые области Результат
Оптимизационный 5-й Осуществляется управление сов фшенсты:в анием процесса по обратной связи Предотврздение дефектов Управление изменениями Управление изменениям процесса Производи-
Управляемый 4-й Процесс измеряется и управляется Количественное упржление процессом Управление качеством
Определенный 3-й Процесс определен, внедрен и постоянно поддерживается Нацележость процесса Определение процесса Повышение квалификации Интегрированное убавление Технология разработки Межруттаж ая координация Обзоры с коллегами
Псвтсряемьй 2-й Определены и поддерживаются фундаментальные компоненты процес са Управление требованиями Планирование проекта Отслсживжие щоекта Управление субподрядчиками Обеспечение качества Управление конфигурацией
Начальный 1-й Процесс неустойчивый, Нет Ржк
18
Рис. 7. Меню подготовки отчетов по качеству
Рис. 8. Меню анализа хода выполнения проектов
СММ по уровням зрелости ключевые области, деятельность которых подвергнута автоматизации в полном объеме, отмечена в таблице жирным шрифтом, а частичная автоматизация отмечена курсивом. Такой выбор ключевых областей и автоматизация деятельности в них обусловлены особенностями нашего предприятия, то есть конкретной реализацией стандартного процесса.
Система АСС реализована на программных пакетах MS Office 2000 и MS Project 98 с использованием языка программирования Visual Basic for Applications в среде Windows 98, включает 33 модуля, содержащих 235 KAELOC программного кода. После инсталляции "пустая" система занимает на винчестере 2,6 Mb.
Список литературы
1. Домарацкий А.Н. Управление улучшением стандартного процесса и качеством программных изделий. //Программные продукты и системы. - 1998. - №4, - С.20-24.
2. Домарацкий А.Н., Домарацкий Я.А. Вероятность обнаружения дефектов во время тестирования программных изделий. //Там же. -1999. -№4. - С.12-15.
3. Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Автоматизация планирования разработки программных изделий. // Там же. - 1999. -№4. - С.2-8.
4. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Отслеживание хода выполнения проектов программных изделий. //Там же. - 1998. - №4. - С.29-30.
5. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Сбор и анализ метрик при выполнении проектов программных изделий. //Там же. - 1998. - №4. - С.24-29.
6. Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Автоматизация деятельности по предотвращению дефектов в программном проекте. //Там же. - 2000. - №4. - С.2-7.
АДАПТАЦИЯ ОС LINUX К ТРЕБОВАНИЯМ ПОДДЕРЖКИ ПРОГРАММНЫХ ПРИЛОЖЕНИЙ ВО ВСТРОЕННЫХ СИСТЕМАХ
В.В. Никифоров, В.А. Павлов, М.В. Данилов, А.В. Глазков, Н.В. Гуцалов
Сложившаяся практика построения, распространения и использования встроенных компьютерных систем приводит к требованиям существенного снижения их стоимости при одновременном расширении функциональных возможностей, выражающихся, в частности, в наличии графического пользовательского интерфейса и доступа к глобальной компьютерной сети. Вместе с тем выполнение части функций встроенных систем должно отвечать требованиям жесткого реального времени [1]. Совмещение этих требований приводит к необходимости применения во встроенных системах мощных операционных систем реального времени (ОС РВ). При использовании для этих целей коммерческих ОС РВ стоимость лицензии может составить существенную долю стоимости всей встроенной системы. Этим вызвано повышенное внимание разработчиков встроенных программных приложений к изучению возможностей использования в своих продуктах свободно распространяемых ОС РВ с открытым исходным кодом. В частности, проявляется интерес к свободно распространяемой ОС РВ eCos [2]. Не меньшее внимание уделяется разработке таких специализированных версий свободно распространяемой ОС Linux [3], которые были бы приспособлены к работе во встроенных системах (встроенные версии Linux) и/или к работе в системах реального времени (РВ-версии Linux). В исходном виде ОС Linux ориентирована на поддержку настольных приложений, а не на работу во встроенных системах или в системах реального времени (СРВ). Особое внимание к этой ОС обусловлено потенциальной возможностью использования большого числа библиотек, разработанных мировым сообществом в рамках Ассоциации свободно распространяемого программного обеспечения (Free Software Foundation Inc.). Следует также отметить, что эти библиотеки, как и сама ОС Linux, были разработаны программистами высокого уровня и про-
шли тестирование огромной армией бета-тестиров-щиков [4].
Авторами исследовались характеристики эффективности адаптации сокращенной версии ОС Linux к поддержке приложений РВ во встроенных системах, построенных на базе микроконтроллеров серии M-Core фирмы "Моторола" [5]. В данной статье рассматриваются результаты исследования функциональных возможностей и параметров быстродействия встроенных ОС и ОС РВ, представляющих собой модификацию исходных версий ОС Linux [6-11].
Требования ко встроенным и РВ-версиям Linux. В ряду требований к версиям ОС Linux, обеспечивающим поддержку встроенных приложений и приложений РВ, следует отметить реактивность, производительность, точность, функциональность, корректность и устойчивость, а также совместимость, преемственность, масштабируемость, меру готовности, оснащенность, мобильность.
В применении к предмету настоящей статьи часть этих терминов требует пояснений, а некоторые из них трактуются специфически.
Под реактивностью СРВ в самом общем смысле понимается способность системы быстро откликаться на возникновение обстоятельств, требующих незамедлительной реакции. ОС РВ как базовая составная часть СРВ должна строиться таким образом, чтобы в максимальной мере способствовать построению приложений с высокой реактивностью. Количественную характеристику пригодности ОС РВ к использованию в СРВ с высокой реактивностью определяют два параметра:
— задержка обработки прерываний - продолжительность интервала времени между возникновением маскируемого сигнала прерывания и передачей управления обработчику этого прерывания;
— задержка обработки внутрисистемных событий - продолжительность интервала времени ме-
19
