CC BY
22
Сеансы тестирования встраиваемых ОС выполняются в два этапа. На первом этапе осуществляется сборка исходных текстов тестов с библиотечными файлами, реализующими функции тестируемой ОС, генерация загрузочных (исполняемых) файлов. На этом этапе проверяются предоставляемые ОС возможности статического порождения множества прикладных задач и обработчиков прерываний, настройки основных параметров прикладных задач, возможности статического распределения ресурсов между задачами. Результаты первого этапа тестирования фиксируются в соответствующих файлах-протоколах статического тестирования. Отметим, что для сокращения времени статического этапа тестирования следует стремиться к сокращению числа исполняемых файлов.
На втором этапе осуществляется загрузка исполняемых файлов в целевую систему и исполнение тестов с использованием коммуникационных и отладочных программ.
Основное время (5-10 секунд) тратится на загрузку теста в память целевого устройства. Это справедливо для небольших тестов, поскольку загрузочный файл включает не только тело теста, но и тело самой ОС. Использование операции реинициализации целевого устройства и ОС позволяет размещать серию элементарных тестов в одном загрузочном файле. Такое решение позволяет сократить время выполнения как статического, так и динамического этапа сеанса тестирования.
При построении тестов в виде процессов, управляемых данными, плотность тестов на килобайт исполняемого файла увеличивается, что позволяет сократить продолжительность обоих этапов сеанса тестирования.
Пути повышения мобильности тестов для ОС
Как отмечалось выше, существенное повышение мобильности тестового комплекта достигается за счет представления логики тестов в виде интерпретируемых структур данных. При непосредственной реализации этого подхода тесты представляются с использованием синтаксических форм, имеющихся в той системе программирования, на которую ориентируется тестируемая ОС, например: при использовании системы программирования на основе языка ассемблера логика тестов мо-
жет представляться последовательностью макросов, разворачиваемых компилятором в массивы данных (при программировании на языке Си для этой цели удобнее всего использовать массивы структур).
Дополнительное повышение мобильности тестового комплекта может быть достигнуто за счет представления логики тестов в универсальной форме, не зависящей от особенностей системы программирования. Для адаптации такой универсальной формы к конкретной системе программирования достаточно сделать несложный фильтр, приводящий универсальное представление тестов к нужной синтаксической форме.
Еще один круг вопросов, связанных с проблемой повышения мобильности тестовых комплектов касается адаптации тестов к особенностям тестируемой ОС, в частности к набору ее функциональных возможностей. Сюда относятся вопросы параметрической настройки тестового комплекта, например способов представления приоритетов задач и величины временных интервалов; вопросы моделирования одних механизмов взаимодействия задач через другие, например механизма рандеву через механизм передачи сообщений или механизма мониторов через семафоры.
Для упрощения адаптации первого типа требуется соответствующее внимание к организации тестового комплекта, обособление параметров, требующих перенастройки. Для решения вопросов адаптации второго типа необходимо располагать соответствующими методами моделирования.
Разработка тестовых комплектов для встраиваемых ОС является трудоемкой задачей. Использование плоских схем для построения тестов с целью проверки базовых функций ОС позволяет существенно снизить эту трудоемкость при одновременном повышении качества тестирования и в конечном счете - качества разрабатываемых встраиваемых ОС и прикладных программных комплексов.
Список литературы
1. Beizer В. Software Testing Technique. NY, International Thomson Computer Press, 1990, 550 p.
2. QA Partner. User's Guide. Newton Center, MA, Segue Software, Inc. 1995,250 p.
АВТОМАТИЗАЦИЯ ПРОЦЕССА УПРАВЛЕНИЯ ПРОЕКТОМ ПРОГРАММНЫХ ИЗДЕЛИЙ
С.Н. Баранов, А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Как показывает опыт, внедрение стандартного процесса, соответствующего модели СММ [1], в повседневную работу организации требует значительных усилий и времени. В ИДУ эта работа началась с интенсивного обучения всех сотрудников, которое включало несколько курсов по модели СММ и способам практического использования новой методологии. По окончании обучения в ИДУ была организована специальная группа процесса, которая взяла на себя труд по приспособлению методологии модели СММ к конкретным условиям работы ИДУ, то есть по разработке и внедрению стандартного процесса.
Даже в этом случае среди сотрудников не было единого понимания того, как следует выполнять те или иные требования стандартного процесса. Различия взглядов на требования стандартного процесса особенно наблюдались у руководителей проектов, поскольку большинство из них воспринимало эти требования как ограничение их творческой инициативы. Поэтому требования стандартного процесса приходилось представлять в убедительной и простой форме, чтобы сотрудники сами могли осознать правильность избранного администрацией метода работы.
Наиболее важной задачей стало определение и внедрение единого подхода к управлению проектами разработки программных изделий (ПИ) для различных предметных областей. Путь внедрения единого метода управления проектами, соответствующего стандартному процессу, заключался в создании и внедрении процедур, регламентирующих методику работы при управлении проектом. Требовалась добиться того, чтобы эти процедуры были понятны руководителям не только с точки зрения того, что надо делать, но и как это следует делать.
По мере внедрения стандартного процесса в ИДУ росло число процедур, правил и ограничений, которым следовало придерживаться в повседневной работе. Па определенном этапе внедрения стандартного процесса количество процедур увеличилась настолько, что даже создание хорошо структурированного справочника процедур не обеспечила надлежащих условий для эффективного их применения. При этом наблюдалось значительное снижение темпов прироста положительного эффекта от внедрения стандартного процесса. В ИДУ это случилось на этапе введения в стандартный процесс требований четвертого уровня и некоторых требований пятого уровня зрелости модели СММ.
Наиболее эффективным выходом из такой ситуации является автоматизация процесса применения процедур, и в первую очередь процедур управления проектами. В настоящей статье приводится описание автоматизированной системы управления проектом программного изделия, разработанной в ИДУ и получившей название "Система-советчик руководителя проектом" (система РЬА).
Система РЬА предназначена для оказания помощи руководителю проекта в процессе управления проектом по разработке ПИ. Она обеспечивает автоматизированные модельные расчеты численности исполнителей при заданных сроках выполнения проекта и качестве ПИ; составление и редактирование проектных планов различной степени детализации (недельных, месячных, квартальных, годовых и на весь проект) и ведение исторической базы данных проекта; сбор установленных стандартным процессом метрик и ведение метрической базы данных проекта; автоматическую генерацию форм и данных для принятых метрических отчетов и отчетов о ходе выполнения проекта, обеспечивающих возможность своевременного обнаружения отклонений в проекте от плановых показателей и принятия необходимых мер для предотвращения возможных проблем.
Система PLA реализована на программных пакетах Excel 5.0 и MS Project 4.0 с использованием языка программирования Visual Basic for Application в среде Windows-95. Исходный объем дискового пространства, занимаемого системой на жестком диске, составляет 3,5 Мб. Для нормальной работы системы PLA необходима иметь процессор не ниже 486, оперативную память не менее 16 Мб, графическую карту и монитор, обеспечивающие разрешение 1024x768 пикселей и высокую цветность (16 бит).
На рисунке представлено главное меню системы PLA, которое является отображением на высоком уровне абстракции того, что может делать система.
Работа руководителя проектом ПИ в системе PLA начинается с заполнения характеристик проекта, являющихся основой его исторической базы данных. Перечень характеристик проекта сведен в таблицу. Переход в этот режим осуществляется путем выбора соответствующей строки главного меню системы PLA.
Далее руководитель проекта должен составить штатное расписание своей проектной группы, что возможно осуществить после нажатия кнопки "Переход к штатному расписанию".
Штатное расписание проектной группы записывается и хранится в исторической базе данных проекта. Штатное расписание при необходимости можно корректировать. В повседневной работе над проектом автоматически учитываются только работающие в данный момент сотрудники проектной группы, а уволенные сотрудники и связанные с ними выполненные работы остаются навсегда в исторической базе данных. Это создает возможность проведения исчерпывающего ретроспективного обзора проекта ПИ, накопления опыта по найму сотрудников необходимой квалификации и успешного планирования выполняемых работ в соответствии со знаниями нанятых работников.
Если у руководителя проекта возникают затруднения в определении численности штата проектной группы для нового проекта, то он может воспользоваться модельными расчетами численности штата (см. рис.). В основу модельных расчетов положена модель возникновения и устранения ошибок и дефектов при разработке ПИ заданного качества. Эта модель разработана в ИДУ на базе реальных метрик, полученных в результате более чем трехлетней работы над 12 проектами ПИ для различных предметных областей [2-3]. В [2] приведено подробное описание работы первой версии системы PLA в режиме модельных расчетов, а в [3] рассмотрена уточненная в результате опытной эксплуатации первой версии системы PLA модель возникновения и устранения ошибок и дефектов при разработке ПИ заданного качества.
После того как составлено и заполнено штатное расписание проектной группы, заполнены (внесены в историческую базу данных) характеристики нового проекта, руководитель проекта может приступить к планированию работ по проекту. Планирование осуществляется средствами MS Project с некоторыми добавлениями, обеспечивающими дополнительные удобства по представлению планов различной степени детализации (недельных, месячных, квартальных, годовых, на весь проект) и по контролю уровня допустимой трудоемкости по каждому сотруднику проектной группы.
ГЛАВНОЕ МЕНЮ
ХАРАКТЕРИСТИКИ ПРОЕКТА |
РАСЧЕТ ЧИСЛЕННОСТИ ШТАТА |
1 ПЛАНИРОВАНИЕ |
ОТСЛЕЖИВАНИЕ
'ЗАВЕРШЕНИЕ РАБОТЫ
Главное меню системы PLA
Для обеспечения автоматической генерации отчетов о ходе выполнения проекта, которые генерируются по данным исторической базы проекта, в таблицу проектного плана введены дополнительные два столбца. В первый помещаются коды ключевых работ, а в третий -результаты, которыми заканчиваются планируемые работы.
Даты начала и окончания планируемых работ в таблицу проектного плана заносит руководитель проекта, а даты фактического окончания заносятся автоматически при определении момента окончания работ в режиме "Отслеживание".
В экранной форме MS Project помещены дополнительные кнопки, позволяющие перейти в главное меню или вызвать на экран монитора формы недельного, месячного, квартального или годового проектных планов. При этом изменяется и диаграмма загрузки сотрудников, которая автоматически приводится в соответствие с вызванной формой проектного плана, что позволяет контролировать и добиваться сбалансированной загрузки сотрудников по месяцам, кварталам и году.
Процесс создания проектного плана является циклическим. Обычно создание годового проектного плана занимает от трех до пяти циклов. Длительность цикла планирования в высокой степени зависит от способностей и опыта руководителя проекта. Хорошим результатом можно считать создание подробного проектного плана не более чем за один месяц. Наличие в системе PLA возможности многократного возвращения к планам различной степени детализации и удобного контроля планируемой трудоемкости работ каждого сотрудника проектной группы создает дополнительные удобства для сокращения срока создания проектных планов.
Важной деятельностью стандартного процесса является отслеживание хода выполнения проекта ПИ. Автоматизация этой деятельности в системе PLA осуществляется при помощи режима "Отслеживание".
В соответствии со стандартным процессом отслеживание хода выполнения проекта ПИ строится на ежедневных метриках каждого сотрудника проектной группы, которые хранятся в метрической базе данных проекта. Существует правило: "Нет метрик, нет продвижения вперед". Поэтому очень важно добиться сбора достоверных метрик в проектной группе. Как это делать описано на с. 24-29 настоящего номера журнала.
В левую таблицу экранной формы "Учет выполненных работ" после ее вызова на экран монитора компьютера руководителем проекта ПИ из исторической базы данных проекта автоматически переписываются все плановые работы, а в правую - фамилия и инициалы исполнителей работ. Необходимая для анализа работа выделяется путем передвижения подсвеченной строки в левой части таблицы до требуемого места. Руководитель проекта должен определить объем выполнения выделенной плановой работы в процентах и занести это значение в соответствующий выделенный фрагмент экранной формы.
Указанный руководителем проекта объем выполнения выделенной работы после нажатия кнопки "занести данные в базу данных проекта" записывается в базу данных и отмечается специальным образом в таблице проектного плана. При вызове на экран монитора проектного плана (в режиме уточнения плана любой возможной в системе PLA степени детализации) в таблице
проектного плана, в ее части, предназначенной для линейного отображения трудоемкостей плановых работ, величина фактической трудоемкости, затраченная на выполнение этой плановой работы, подсвечивается цветом, отличным от подсветки плановых работ. Это создает дополнительную возможность для руководителя проекта каждый раз визуально определять степень выполнения плана, при необходимости более детально изучать критические участки плана и принимать соответствующие меры для предотвращения возможных проблем.
При указании руководителем проекта 100 % выполнения выделенная работа автоматически связывается с текущим календарным днем, который записывается в историческую базу данных проекта и является фактическим днем окончания работы. Даты фактического окончания плановых работ и затраченная на их выполнение трудоемкость используются для генерации метрических отчетов по проекту и отчетов о ходе выполнения проекта. Это еще раз показывает, насколько важно руководителю проекта обеспечивать сбор достоверных метрик в проектной группе, уделять должное внимание вопросам управления проектом и самому стремиться к объективной оценке объема каждой выполняемой работы.
Из исторической базы данных проекта и его метрической базы данных генерируются все отчеты в режиме "Отчеты о ходе выполнения проекта".
Режим "Отслеживание" является последним в главном меню системы PLA. Этим режимом руководитель проекта должен пользоваться наиболее часто (правильное решение - ежедневное использование режима "Отслеживание"), для того чтобы постоянно иметь объективное представление о текущем состоянии дел в проекте.
Целесообразно регулярно, чаще, чем раз в две недели (правильное решение - не реже двух раз в неделю), пользоваться метрическими отчетами. Это даст возможность руководителю проекта иметь достоверное, основанное на ежедневных метриках исполнителей работ, представление о характеристиках ПИ (размеры созданного кода, нового кода, удаленного кода, другие важные характеристики ПИ и группы разработчиков), о точности планирования работ по трудоемкостям, об ожидаемом качестве создаваемого ПИ и о многом другом, что необходимо для эффективного управления проектом.
В заключение отметим, внедрение стандартного процесса требует времени и терпения. Однако соблюдение всеми сотрудниками в своей работе методики труда, определенной стандартным процессом и принятой в организации в качестве единственной, сторицей окупает затраченные усилия. В этом случае каждый проект выполняется слаженно, строго поддерживается запланированная последовательность в появлении отдельных продуктов, проектов и в целом программных изделий, повышается производительность труда, сокращается длительность жизненного цикла разработок. Кроме того, все проекты ПИ завершаются в срок и без превышения выделенного бюджета.
Список литературы
1. Paulk, М.С., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993). 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. Software.
2. Baranoff S., Domaratsky A., Lastochkin N., Morozov V. An automated system for software project planning International Conference on Informatics and Control (ICI&C97 June 9-13, 1997
St.Petersburg). Proceedings. Volume 2 of 3. St.Petersburg. SPIIRAS, 1997 - P.785-795 (1353c.).
3. Баранов C.H., Домарацкий A.H., Ласточкин H.K., Морозов В.П. Предотвращение дефектов при разработке ПИ. // Программные продукты и системы. - 1998. - №2. -С.2-6
