Программа по формированию навыков безопасного поведения на дорогах и улицах «Добрая дорога детства» 2
Скачать 1.39 Mb.
|
надежность - уровень завершенности (отсутствие ошибок), ус тойчивость к ошибкам и перезапускаемость;
6) переносимость - адаптируемость, структурированность, заме- щаемость и удобство внедрения. Функциональная пригодность - это набор атрибутов, определяющий назначение, наменклатуру, основные необходимые и достаточные функции прикладной программы, установленные в техническом задании. В процессе проектирования программы атрибуты функциональной пригодности конкретизируются в спецификации на компоненты. Эти атрибуты можно численно представить точностью вычислений, относительным числом поэтапно изменяемых функций, коэффициентом изменения спецификаций требований разработчиками и заказчиками и т.д. 4.3.1.1 Функциональная пригодность В наибольшей степени функциональная пригодность проявляется в корректности решения задач, в надежности и безопасности применения прикладной программы. Функциональная пригодность определяется, прежде всего, качеством системного проектирования программы. Критериями, отражающими эти свойства, могут быть: способность компонент к взаимодействию и степень стандартизации интерфейсов, мобильность программ и их защищенность от внешних воздействий. Способность программных и информационных компонент к взаимодействию можно оценивать объемом изменений в прикладной программе, которые необходимо выполнить при дополнении или исключении некоторой функции, когда отсутствуют изменения операционной или аппаратной среды. 37 4.3.1.2 Корректность Корректность программ зависит от функциональной корректности применяемых компонент и может рассматриваться в зависимости от методов ее достижения и оценивания: детерминированно, стохастически или в реальном времени. Функциональная корректность модулей определяется корректностью обработки исходных данных и получения результатов. В зависимости от функциональных задач корректность модуля может оцениваться детерминированно, по полностью определенным наборам эталонных значений, или стахостически, при задании эталонов распределениями случайной величины. Функциональная корректность обработки данных связана в основном с конкретизацией их содержания в процессе исполнения программ, а также при подготовке данных внешним абонентам. Детерминированная корректность программ определяется по частотам отклонения конкретных вычисляемых результатов от эталонных значений, заданных в техническом задании, в спецификациях или в иных исходных документах. Стохастическая корректность характеризуется величиной статистического отклонения распределений и их параметров (средних значений, среднеквадратических отклонений) результатов функционирования программ от заданных в качестве эталонов. При этом не оценивается каждый результат тестирования, а они обобщаются и оцениваются интегрально по некоторой достаточно представительной выборке. Корректность в реальном времени определяется величиной максимального или усредненного отклонения траектории изменения выходных параметров от заданной эталонной траектории обработки тестовых исходных данных. Результаты тестирования оцениваются интегрально на некотором временном интервале или по наибольшему отклонению от эталонной траектории. Корректность структуры программ определяется корректностью структуры модулей и корректностью структуры групп программ, построенных из модулей. Для оценки корректности структуры программ используется несколько частных показателей, различающихся степенью охвата тестами структурных компонент программы при тестировании. Корректность обработки данных определяется степенью отладки процесса обработки представительной выборки значений переменных в допустимых диапазонах их изменения. Для сложных программ принципиально невозможно провести исчерпывающее тестирование при всех значениях переменных, которые могут появиться при реальном функционировании программ. Поэтому устанавливается иерархия критериев и соответствующих им правил обработки данных в программе. 38 Корректность межмодульных интерфейсов определяется двумя видами связей между модулями: по управлению и по информации. Связи по управлению составляют вызовы программных модулей и возвраты в вызывавшие модули. Некорректности взаимодействия модулей по информации очень разнообразны, трудно контролируемые и носят стохастический характер. Ряд искажений переменных при взаимодействии модулей не вызывает ситуаций отказа и отражается только в искажении результирующих данных на выходе модуля. Многообразие и сложность информационных связей в больших прикладных программных системах значительно затрудняют формализацию достигнутой корректности программ. Критерии становятся стохастическими и качество программы оценивается интегрально по результатам общего функционирования. 4.3.1.3 Надежность Показатели надежности прикладной программы в значительной степени адекватны аналогичным характеристикам принятым для других промышленных изделий. В этом случае регистрируются только такие искажения в процессе функционирования и исполнения программ, которые приводят к потере работоспособности программы или их крупных компонент. С понятием надежности и отказов программ тесно связано понятие технологической безопасности применения прикладных программ. Основным принципом классификации сбоев и отказов в программах при отсутствии их физического разрушения является разделение по временному показателю длительности восстановления после любого искажения программ, данных или вычислительного процесса, регистрируемого как нарушение работоспособности. При длительности восстановления, меньшей заданного порога, аномалии при функционировании программ следует относить к сбоям, а при восстановлении превышающем по длительности пороговое значение, происходящее искажение соответствует отказу. Классификация программных сбоев и отказов по длительности восстановления приводит к необходимости анализа динамических характеристик абонентов, являющихся потребителями данных, обработанных исследуемой прикладной программой, а также временных характеристик функционирования программ. Временная зона перерыва нормальной выдачи информации и потери работоспособности, которую следует рассматривать как зону сбоя, тем шире, чем более инерционный объект находится под воз-Действием сообщений, подготовленных данной прикладной программой. Надежность функционирования прикладной программы наиболее Широко характеризуется устойчивостью или способностью к безотказному 39 функционированию и восстанавливаемостью работоспособного состояния после произошедших сбоев. Восстанавлиемость характеризуется полнотой и длительностью восстановления функционирования программ после перезапуска (рестарта). Перезапуск должен обеспечивать возобновление нормального функционирования программы, на что требуются ресурсы компьютера и время. Наиболее широко используется критерий длительности наработки на отказ. Для определения этой величины измеряется время работоспособного состояния системы между последовательными отказами или началами нормального функционирования системы после них. Обобщение характеристик отказов и восстановлений производится в критерии коэффициент готовности. Этот показатель отражает вероятность иметь восстанавливаемую систему в работоспособном состоянии в произвольный момент времени. 4.3.1.4 Уровень защищенности К показателям надежности близки критерии уровня защищенности и безопасности применения прикладаной программы, которые характеризуются эффективностью контроля за доступом к данным, степенью обеспечения их секретности и сохранности, а также некоторыми другими свойствами устойчивости к воздействиям со стороны внешней среды и дефектов программ и данных. 4.3.1.5 Удобство использования Удобство использования прикладной программы - понятие достаточно абстрактное и трудно формализуемое. Оно определяет функциональную пригодность и полезность применения прикладной программы. В эту группу показателей входят критерии с различных сторон отражающие понятность, простоту освоения и эффективность или простоту использования. Понятность прикладной программы можно описать четкостью концепции, широтой демонстрационных возможностей и точностью представления в документации возможных функций. Также этот показатель характеризуется распознаваемостью модифицируемых параметров и адаптируемостью прикладной программы к конкретной среде и условиям применения. К этим критериям примыкают критерии простоты изучения, которые могут включать длительность подготовки пользователя к полноценной эксплуатации прикладной программы. Это время зависит от возможности предварительного обучения и совершенствования в процессе эксплуатации, от возможностей оперативной помощи и подсказки (Help) при использо- j вании программы, а также от доступности и удобства использования ру- j ководств и инструкций по эксплуатации. ; 40 ; Критерии простоты и удобства использования учитывают физические и психологические характеристики пользователей и отражают уровень комфортности условий эксплуатации прикладной программы. Они характеризуют легкость управления программой и объем параметров управления, реализуемых по умолчанию, информативность сообщений пользователю и унифицированность управления экраном, степень доступности изменения функций в соответствии с квалификацией пользователя и число операций, необходимых для запуска определенного задания. Кроме того, удобство использования характеризуется рядом динамических параметров: временем ввода и отклика на задание, длительностью решения типовых задач, временем на регистрацию результатов. 4.3.1.6 Эффективность использования ресурсов Несмотря на быстрый рост ресурсов памяти и производительности компьютеров, очень часто потребности в них для решения конкретных задач обгоняют их техническое увеличение и остается актуальной задача экономного использования ресурсов. Поэтому среди критериев качества прикладной программы заметную роль, играют критерии эффективности использования ресурсов памяти и производительности компьютеров при реализации определенной программы. Временная экономичность программы определяется длительностью выполнения заданных функций. Она зависит от скорости обработки данных, влияющей непосредственно на интервал времени завершения конкретного вычислительного процесса, и от пропускной способности, то есть от числа заданий, которое можно реализовать на данном компьютере в заданном интервале времени. Эти показатели качества тесно связаны с временем реакции (отклика) программы на запросы для полного решения основных функциональных задач. Пропускная способность комплекса программ на конкретном компьютере отражает число сообщений или запросов на решение определенных задач, обрабатываемых в единицу времени, зависящую от некоторого показателя внешней среды. При этом выделяются составляющие времени центрального процессора, обмена с внешней памятью, взаимодействия с внешней средой и терминалами и т.д. Экономия ресурсов отражает количество и степень занятости ресурсов центрального процессора, оперативной, внешней и виртуальной памяти, каналов ввода-вывода, терминалов и каналов локальной сети. Этот критерий определяется структурой и функциями прикладной программы, а также архитектурными особенностями и доступными ресурсами реализующего компьютера. 41 4.3.1.7 Переносимость Сейчас важным показателем стала переносимость или мобильность программ в иную операционную среду или в иную аппаратную платформу. Это свойство может оцениваться объемом необходимых доработок программы, которые следует выполнить для обеспечения полноценного функционирования программы после переноса. Мобильность может оцениваться, на уровне исходных текстов программ или на уровне объектного кода. При анализе и оценке переносимости программ и данных в первую очередь необходимо учитывать:
4.3.2 Отечественный стандарт ГОСТ 28195-89 Близким к описанному стандарту по идеологии, структуре и содержанию является стандарт «ГОСТ 28195-89. Оценка качества программных средств. Общие положения». На верхнем, первом уровне выделено шесть показателей факторов качества:
Эти факторы детализируются в совокупности 19 критериями качества на втором уровне. Дальнейшая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240. Каждый из них рекомендуется экспертно оценивать в пределах от 0 до 1. Состав используемых факторов, критериев и метрик предлагается выбирать в зависимости от назначения, функций и этапов жизненного цикла прикладной программы. 42 В перечисленных стандартах представлены широкая номенклатура показателей и общее описание их содержания. Материалы имеют справочный характер и не содержат рекомендаций по селекции, выбору и упорядочению необходимого минимума критериев в зависимости от особенностей объекта и среды разработки. Кроме того, для большинства показателей отсутствуют и не очевидны методики их измерения и сопоставления с требованиями спецификаций, а также нет рекомендаций, на каких этапах разработки их целесообразно применять. Описания показателей качества ориентированы на квалифицированных системных аналитиков и заказчиков прикладных программ, которым предоставляется возможность при системном проектировании выбирать необходимую номенклатуру характеристик в соответствии с назначением, областью применения и конкретными особенностями применения прикладных программ. 5. Универсальный язык для моделирования программ 5.1 Общие положения UML (Universal Modeling Language - универсальный язык моделирования), способный решить любые задачи, связанные с любым проектированием и моделированием: от общей (абстрактной) модели процессов предприятия до конкретной (физической) модели класса в создаваемом программном обеспечении. Инструментальная среда для построения моделей на этом языке, разработанная фирмой Rational Software, называется Rational Rose. Работа в Rational Rose заключается в проектировании определенного вида диаграмм, задающих элементы, их свойства, отношения и взаимодействие друг с другом. При разработке любой информационной системы в первую очередь возникает проблема взаимопонимания подрядчика и заказчика еще на стадии выбора структуры системы. Имея такой инструмент, как Rational Rose, проектировщик (аналитик) всегда может показать заказчику не абстрактное словесное описание процесса, а его конкретную модель (на экране компьютера или в печатном виде). Это позволит быстрее согласовать с заказчиком все детали планируемой системы. Результатом моделирования является файл с моделью. Проектировщик передает модель следующему звену сотрудников - кодировщикам. Они дополняют полученную логическую модель системы моделями конкретных классов на языке программирования. Богатый набор средств Rational Rose предоставляет разработчикам следующие возможности:
3. Round-trip engineering - сочетание возможности первых двух подходов, когда сначала создается система, а по прохождении некоторого времени доработок она подвергается реинженирингу, дорабатывается и вновь выполняется генерация кода программы.  Рис. 5. Пример диаграммы объектов на языке UML 5.2 Концептуальные области UML Все концепции и модели языка UML можно отнести к четырем концептуальным областям. 1 . Статическая структура.
В первую очередь, любая точная модель должна определять полное множество объектов, то есть ключевые концепции программы, их внутренние свойства и отношения между собой. Эта структура и есть статическое представление системы. 45 Концепции программы моделируются как классы, каждый из которых описывает тип дискретных объектов, содержащих определенную информацию и взаимодействующих между собой для реализации некоторого поведения. Информация, которую содержат объекты, моделируется как атрибуты, поведение - как операции. Используя механизм обобщения, несколько классов могут иметь одну общую структуру. Класс-потомок изначально содержит в себе структуру и поведение, наследованные от общего класса-предка. В процессе выполнения программы одни объекты имеют связи с другими. Такие взаимоотношения между объектами моделируются как межклассовые ассоциации. Отношения между элементами, включая такие, например, как отношения для моделирования, изменения уровня абстракции, связывание фактических значений с формальными параметрами шаблона, наделение правами и использование одного элемента другим, группируются как отношения зависимости. Прочие отношения включают в себя комбинацию вариантов использования и потоков значений. Статическое представление системы изображается с помощью диаграмм классов. Его можно использовать для генерации большинства объявлений структуры данных в программе. В языке UML существует еще несколько элементов диаграмм: интерфейсы, типы данных, варианты использования и сигналы. Они носят общее название классификаторов и ведут себя в большинстве случаев как классы, но с некоторыми ограничениями для каждого типа классификатора. 5.2.2 Динамическое поведение Существует два способа моделировать поведение. Первый представляет собой отображение истории жизни объекта и его взаимодействия с остальным миром. Второй - это образцы взаимодействия зависимых объектов и их взаимоотношения при реализации определенного поведения. Поведение отдельно взятого объекта описывается конечным автоматом. При этом рассматривается реакция объекта на события на основе его текущего состояния, действий, из которых состоит эта реакция, и переход в новое состояние. Подобное поведение изображается на диаграммах состояний. Взгляд на систему как на комплекс взаимодействующих объектов называется кооперацией. Кооперация описывает контекстно зависимый взгляд на объекты и их связи друг с другом, а также поток сообщений между объектами по каналам передачи данных. В этом случае структура данных системы, управляющая логика и поток данных рассматриваются вместе. Кооперация объектов отображается на диаграм- 46 мах последовательности и диаграммах кооперации. Поведение всех объектов системы охватывается набором вариантов использования, каждый из которых описывает некую часть функционирования системы, с точки зрения действующего лица, то есть пользователя. 5.2.3 Элементы реализации Модели создаются как для логического анализа, так и для физической реализации системы. Некоторые конструкции в модели представляют собой элементы реализации. Компонент - это вещественная замещаемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает их реализацию. Компонент должен легко замещаться другими компонентами с тем же набором интерфейсов. Узел - это компьютерный ресурс, который определяет местонахождение исполняемых компонентов и объектов. Описание развертывания системы содержит информацию о конфигурации узлов действующей системы, расположение компонентов и объектов на них, включая возможную миграцию содержимого между разными узлами. 5.2.4 Организация модели Компьютеры могут работать с большими плоскими моделями, а вот люди - нет. Поэтому при работе над большими системами вся информация о модели должна быть поделена на связные понятные части, чтобы команды разработчиков могли параллельно работать над различными разделами системы. Даже при разработке небольших систем лучше разделить содержимое модели на несколько пакетов приемлемого размера. Пакетами в языке UML называются иерархически организованные блоки моделей. Их можно использовать для хранения, контроля доступа, управления конфигурацией и конструирования библиотек, содержащих фрагменты моделей многократного пользования. Отношения между пакетами объединяют отношения между содержимым пакетов и могут задаваться системной архитектурой. Таким образом, отношения содержимого пакетов должны соответствовать отношениям между пакетами и заданной архитектуре системы. 5.2.5 Механизмы расширения Как бы велики ни были возможности языка, людям рано или поздно захочется их расширить. UML обладает способностью к расширению, которой должно хватать на обычные, повседневные нужды, не требующие изменений в основных положениях языка. Стереотип (stereotype) - это новый вид элемента модели, который обладает той же структурой, что и существующий элемент, но имеет дополнительные ограничения, другую интерпретацию и пиктограмму, а также иначе обрабатывается генераторами кода и другими прикладными программами. 47 6. Управление требованиями к прикладной программе RequisitePro - это удобный инструмент для сбора и управления требованиями к информационной системе. Его могут использовать все участники программного проекта. Программа RequisitePro позволяет в наглядной форме получать, выводить, структурировать наборы вводимых требований к создаваемому программному изделию. Для каждого требования поддерживается набор атрибутов, позволяющий эффективно управлять проектом на основе иерархий требований, установки их приоритетов, сортировки, назначения требований конкретным исполнителям. Для требований предусмотрен, предопределен набор атрибутов, который может быть расширен пользователем. Это позволяет характеризовать программу в соответствии с представлениями пользователя. Развитые возможности представления требований позволяют визуально определять схожие требования в рамках одного или нескольких проектов. Это дает возможность применения готовых апробированных решений в новом проекте. Задание связей между требованиями позволяет легко проследить, какие требования следует подвергнуть анализу (и, возможно, пересмотру) при модификации некоторого конкретного требования или атрибута. Тем самым упрощается процесс внесения изменений в требования к программному изделию. Для каждого требования хранится его история, позволяющая отследить, какие изменения были внесены в требование, кем, когда и почему. Выгоды эффективного управления требованиями с помощью программы RequisitePro увеличиваются при использовании его всей командой разработчиков. При этом упрощается общение между разработчиками за счет предоставления общего доступа ко всем требованиям проекта, либо к их части. Все документы и данные, относящиеся к требованиям, централизованно организуются при помощи программы RequisitePro. Требования заказчика, дизайн подсистем, сценарии, функциональные и нефункциональные спецификации и планы тестирования распределяются и связываются таким образом, чтобы максимально облегчить управление проектом. 7. Управление запросами на изменение программы Поскольку проект постоянно -меняется, руководителям, менеджерам жизненно необходимо знать статистику того, что менялось, кем и в какое время. В большинстве случаев необходимо видеть не просто информацию о том или ином событии, а хочется иметь полный объем необходимой информации. Программа ClearQuest помогает в решении данной задачи. ClearQuest является мощным средством управления запросами на изменение (change request management - CRM), специально разработанным с учетом динамической и сложной структуры процесса разработки программного обеспечения. Программа ClearQuest отслеживает и управляет любым типом действий, приводящих к изменениям продукта в течение его жизненного цикла. Это дает возможность более предсказуемым образом создавать качественное программное обеспечение. Основные задачи, решаемые посредством программы ClearQuest:
В качестве положительных черт данного продукта можно отметить его легкую настройку к используемому процессу разработки программного обеспечения, а также масштабируемость и простоту в администрировании и использовании. В работе с Rational ClearCase каждый участник проекта может просматривать базу данных и определять собственные запросы. Запросы на изменения проходят цикл из нескольких состояний, начиная с подачи запроса и заканчивая его разрешением. Например, только что поданный запрос находится в состоянии «Подан». После передачи запроса сотруднику он переходит в состояние «Назначен». Начало работы над запросом переводит его в «Открытое» состояние, и вся команда проекта может видеть кто обрабатывает этот запрос. Наконец, при проверке и закрытии запроса, он проходит стадии «Проверка» и «Закрыт». Если же в данное время работа над запросом не актуальна или по каким-либо причинам не возможно, то этот запрос переводится в состояние «Отложен». 49 8. Улучшение качества кода Разработчик постоянно сталкивается с проблемой необходимости увеличения производительности приложения в сжатые сроки и с максимально возможной эффективностью. Из-за отсутствия необходимого инструментария, разработчику приходится вручную замерять скоростные характеристики разрабатываемых приложений. Это неточно и требует много времени. Программа Rational Quantify позволяет решить описанные выше проблемы. Это простое, но в то же время мощное и гибкое средство учета производительности приложений. Он незаменим для сбора и анализа информации о производительности созданного программного продукта. Программа Rational Quantify генерирует в табличной форме список всех вызываемых в процессе работы приложения функций, указывая временные характеристики каждой из них. Программа предоставляет полную статистическую информацию по всем вызовам (внешним и внутренним). Сбор данных осуществляется посредством технологии OCI (Object Code Insertion). Суть этого способа состоит в подсчете всех машинных циклов путем вставки счетчиков в код для каждого функционального блока тестируемой программы. Все циклы приложения просчитываются реально, а не при помощи произвольных выборок, как это делается в большинстве пакетов тестирования. Уникальность данного подхода заключается в том, что, во-первых, тестируется не только сам исходный код, но и все используемые компоненты, (например: библиотеки DLL, системные вызовы), и, во-вторых, для подобного анализа совсем необязательно иметь исходные тексты тестируемого приложения (правда, в этом случае нет возможности отслеживать внутренние вызовы). Статистическая информация по вызовам процедур в тестируемой программе может быть перенесена в Microsoft Excel, где можно построить как графики, так и сводные таблицы для разных запусков программы. Отметим, что тестируемое приложение можно изменить, затем перекомпилировать и запустить повторно, при этом программа Rational Quantify способна запомнить все предыдущие вызовы процедур и дать сравнительную оценку. Также данный продукт помогает в разрешении проблем, связанных с утечками памяти и Run-time ошибками. Не секрет, что многие программные продукты ведут себя «не слишком скромно», используя во время работы все системные ресурсы без необходимости. Возникновение подобного рода ошибок достаточно трудно отследить стандартными средствами. И дело тут 50 не только в том, что разработчик может где-то недосмотреть, а в том, что в подавляющем большинстве случаев проектные сроки вынуждают смотреть «сквозь пальцы» на «мелкие» неточности. В общих чертах работа программы Purify сводится к выводу детальнейшей статистики об использовании памяти приложением. Программа собирает данные о любых потерях в памяти и ошибках, связанных с распределением памяти. К ним можно отнести и невозвращение блока памяти, и не использование указателей, и остановку исполнения программы с выводом состояния среды при возникновении run-time ошибки. Программа Purify - это очень мощный инструмент. Но вместе с тем он обладает достаточно простым интерфейсом и осваивается специалистом за 2-3 дня. Еще один инструмент для улучшения кода разрабатываемого приложения - Rational Pure Coverage. Эта программа позволит разработчикам довести программы до совершенства. Основное и единственное назначение продукта - выявление участков кода, пропущенного при тестировании приложения. Вполне очевидно, что при тестировании программы, специалисту не удается оттестировать абсолютно все ее функции. Это связано с тем, что, во-первых, разработчик не может сделать все абсолютно правильно с учетом всех возможных нюансов, и, во-вторых, даже учитывая все возможные реакции приложения на внешние «раздражители» невозможно на 100% быть уверенным в том, что все оттестировано. Но если Вы воспользуетесь средством Rational PureCoverage, то сможете раз и навсегда забыть о мучительном поиске непроверенного кода в собственной программе. Пакет Pure Coverage собирает статистику о тех участках программы, которые во время тестирования не были выполнены (пройдены). Дополнительно программа определяет активно исполнявшиеся строки. Стало быть, разработчик может оценить не просто, сколько раз вызывалась та или иная функция, а сколько раз исполнилась каждая строка, составляющая ее. Имея подобную статистику, очень просто выявить не исполнившиеся строки и проанализировать причину, по которой они не получили управления. 51 9. Средства тестирования прикладных программ С целью повышения качества и надежности создаваемых программ | организуется их проверка или тестирование. Эта проверка может прово-j диться простым прогоном программы с использованием предварительно 1 подготовленных данных. Так делается обычно при использовании экстремальных методологий. Промышленные методологии предполагают ис-; пользование для тестирования специальных средств. Одно из таких средств ' Visual Test. Продукт позволяет производить тестирование 32-битного i Windows-приложения, компонентов ActiveX, DLL, сервера автоматизации OLE (OLE Automation server) и приложений на основе интернет. Программа ; Visual Test дает возможность создавать поддерживаемые, расширяемые и пригодные для повторного применения компоненты тестирования, которые ; можно использовать во многих версиях одного программного проекта И; даже во многих проектах. Основу гибкости и мощи программы Visual Test составляет производный от Visual Basic расширенный язык программирования TestBasic. Этот язык обладает сотнями специфических для теста функций, специальных конструкций для облегчения тестирования, имеет простой доступ к Windows API и открытую архитектуру, которая делает этот язык расширяемым. Данный продукт обеспечит надежное функциональное тестирование. Программа Rational Robot - средство функционального тестирования приложений, разработанных по объектно-ориентированной технологии. Эта программа позволяет существенно превзойти традиционные средства тестирования графического интерфейса, так как с ее помощью тестируются сотни и тысячи свойств всех объектов приложения (даже скрытых объектов), как вместе, так и каждого в отдельности. Программа Rational Robot способна работать в двух режимах: в автоматическом и в ручном. В ручном режиме пользователь сам задает на специальном языке сценарий тестирования (скрипт), а в автоматическом -пользователь тестирует приложение, a Robot автоматически генерирует необходимый скрипт для дальнейшего повторного тестирования. Скрипты, создаваемые в Rational Robot, обеспечивают поиск ошибок в приложении, оставаясь виртуально независимыми от внесенных изменений и платформы. Без дополнительных изменений скрипты могут использоваться на Microsoft Windows 98, Windows 2000 и Windows NT. Такое тестирование обеспечивает быстрое создание скриптов, которые в даль-52 нейшем можно легко изменять, создавать заново и воспроизводить. Rational Robot поддерживает широкий спектр языков программирования, позволяет редактировать, отлаживать и настраивать скрипты, допускает также тестирование сложных клиент-серверных систем на платформе Windows. Внедрение подобного универсального инструмента для всеобъемлющего тестирования графического интерфейса даст существенный прирост в эффективности проводимого тестирования. LoadTest - средство автоматизированного тестирования характеристик распределенных сетевых приложений на платформах Windows и Unix. Программа LoadTest выполняет нагрузку сервера большим количеством виртуальных пользователей. Например, вы можете измерить время выполнения запроса для одного пользователя, чтобы затем определить время выполнения запроса, когда тысячи других пользователей будут посылать запросы на тот же самый сервер одновременно. Термин «тесты производительности» включает нагрузочные, стрессовые, конкурирующие и конфигурационные тесты. Совокупность этих тестов позволяет ускорить цикл тестирования производительности и достигнуть значимых и точных результатов. Нагрузочное тестирование с использованием LoadTest выполняется тогда, когда нужно определить время отклика серверов или клиентских приложений при изменяющейся нагрузке. Нагрузочное тестирование также используется тогда, когда нужно вычислить, какое максимальное количество транзакций может выполнить сервер за определенный временной отрезок. Если клиент/серверная система использует распределенную архитектуру или средства балансировки нагрузки - нагрузочное тестирование может быть использовано для того, чтобы проверить правильность выбранных методов для балансирования или конструирования системы. Нагрузочное тестирование выполняется как с использованием режима только виртуальных пользователей, когда измеряется время отклика только серверной части или комбинации виртуальных пользователей и пользователей графического интерфейса для измерения времени отклика системы для конкретного клиентского приложения. С помощью данной программы можно проверять производительность любой системы клиент-сервер. 53 10. Управление конфигурациями и версиями прикладной программы Rational ClearCase - средство конфигурационного и версионного контроля, которое сохраняет всю историю каждого файла проекта с целью возможного сравнения изменений, включая миграцию файлов между независимыми проектами. ClearCase объединяет всех участников проекта единой средой, хранящей всю возможную информацию, относящуюся к проекту, позволяя получать последние версии редактируемых файлов. Этот инструмент выполняет контроль над версиями и управление рабочим пространством с помощью уникального инвариантного подхода. С помощью программы ClearCase команда разработчиков может ускорить разработку, повысить точность релизов, создавая новые, надежные в эксплуатации продукты, а также дорабатывать и поддерживать ранее реализованные продукты, организовывать эффективный процесс разработки - и все это достигается без изменения среды, инструментальных средств и подхода к работе. Программа ClearCase обеспечивает управление версиями исходных текстов, библиотек подпрограмм на протяжении всего жизненного цикла проекта. Это позволяет разработчику вернуться к любой версии редактируемого файла и откорректировать его, создав новую версию. Каждый участник проекта может иметь доступ либо ко всем файлам проекта, либо только к определенной его части. Для достижения подобного эффекта ClearCase использует мощную систему настраиваемых фильтров, скрывающих ненужную информацию. Система видов отличает ClearCase от продуктов конкурирующих фирм. Она позволяет осуществить параллельную разработку. Также она позволяет отдельному участнику проекта выходить из общего состава разработки, забирая работу «на дом», а после всех внесенных изменений вернуть свои версии снова в проект. При этом программа ClearCase осуществит автоматическое слияние версий. В дополнение к описанным возможностям, программа ClearCase позволяет объединять географически удаленные команды разработчиков посредством MultiSite - специального модуля, осуществляющего репликацию (передачу) текущего состояния проекта на указанный сайт. 54 11. О единой системе программной документации 11.1 Назначение единой системы программной документации Единая система программной документации (далее ЕСПД) - комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформление и обращения программ и программной документации. В стандартах ЕСПД устанавливают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ. Это обеспечивает возможность:
Сопровождение программы включает анализ функционирования, развитие и совершенствование программы, а также внесение изменений в неё с целью устранения ошибок. 11.2 Область распространения и состав ЕСПД Правила и положения, установленные в стандартах ЕСПД, распространяются на программы и программную документацию для вычислительных машин, комплексов и систем независимо от их назначения и области применения. В состав ЕСПД входят:
Разработка организационно-методической документации, определяющей и регламентирующей деятельность организаций по разработке,, сопровождению и эксплуатации программ, должна проводится на основе стандартов ЕСПД. 55 11.3 Классификация и обозначение стандартов ЕСПД Стандарты ЕСПД подразделяют на группы, приведённые в таблице:
Обозначение стандарта ЕСПД строят по классификационному признаку. Обозначение стандарта ЕСПД должно состоять из следующих частей:
Пример обозначения стандарта «Единая система программной документации. Общие положения»: ГОСТ 19.0-77 56 12. Два вида документации для прикладных программ 12.1 Документация для разработчиков прикладных программ 12.1.1 Состав документации Состав документации для разработчиков прикладной программы, применяемой для решения экономических задач, в общем случае включает следующие книги:
Ведомость документов для разработчиков содержит перечень документов на программу, необходимых при разработке и сопровождении программы во время эксплуатации коллективом разработчиков. Техническое задание на программу является основным документом, определяющим требования и порядок создания (развития или модернизации) прикладной программы, в соответствии с которым проводится разработка программы и ее приемка при вводе в действие. Технический проект разрабатывают с целью выявления окончательных технических решений, дающих полное представление об архитектуре прикладной программы. Документ «Текст программы» должен содержать исходные тексты программы с комментариями. Документ «Описание программы» содержит описание архитектуры, функционального назначения и логики программы. Программа и методика испытаний должна содержать необходимые сведения для проведения приемо-сдаточных испытаний программы. Обязательными документами являются только два документа -«Техническое задание» и «Текст программы». Допускается объединять несколько документов в один. Состав документации для конкретной компьютерной программы определяется руководителем проекта, в рамках которого разрабатывается эта программа (Site: WWW.OberonCo.da.Ru, Телефон: (096) 567-2224, E-mail: OberonCo@Mail.Ru). 57 12.1.2 Содержание документации 12.1.2.1 Книга «Ведомость документов для разработчика» Информационную часть (аннотацию и оглавление) в Ведомость документов для разработчика допускается не включать. В этом документе перечисляются все книги, входящие в состав документации для разработчика данной компьютерной программы, с указанием их краткого и полного названий, объемов и аннотаций. 12.1.2.2 Книга «Техническое задание» Техническое задание на программу является основным документом, определяющим требования и порядок создания (развития или модернизации) прикладной программы, в соответствии с которым проводится разработка программы и ее приемка при вводе в действие. Техническое задание на программу разрабатывают на программу в целом, предназначенную для работы самостоятельно или в составе другой программы. Дополнительно могут быть разработаны технические задания на части программы: на подсистемы программы, программные модули и т. п. Техническое задание на программу разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии "Предпроектные исследования". Изменения к техническому заданию на программу оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью технического задания на программу. На титульном листе технического задания на программу должна быть запись "Действует с ... ". Информационную часть (аннотацию и оглавление) в Техническс задание допускается не включать. В основную часть документа должны входить следующие разделы:
В техническое задание допускается включать приложения. 58 В зависимости от особенностей программы допускается уточнять содержание разделов, вводить новые раздели или объединять отдельные из них. 12.1.2.2.1 Содержание разделов В разделе «Введение» указывают наименование, краткую характеристику области применения программы и объекта, в котором используют программу. В разделе «Основания для разработки» должны быть указаны:
В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы. |
