Функциональное назначение программы. Техническое задание

Согласно ГОСТу, настоящий стандарт (переизданный в ноябре 1987 г.) устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Надо быть предельно внимательным и осторожным, создавая его, т.к. зачастую умело (и грамотно) составленное ТЗ определяет успех всей работы. Именно ТЗ согласовывается с Заказчиком, который обычно стремится внести как можно больше противоречивых и завышенных требований. Задача же Исполнителя – наоборот, облегчить себе жизнь. Но после того, как подписи с обеих сторон поставлены, переигрывать что-либо поздно.

Общие положения

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

Раздел: Наименование и область применения

В разделе Основание для разработки должны быть указаны:

• документ (документы), на основании которых ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

Раздел: Назначение разработки

Например: Программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.

Раздел: Технические требования к программе или программному изделию

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

Раздел:Требования к функциональным характеристикам.

Например : Программа должна позволять … вычислять … строить… создавать …

Исходные данные: текстовый файл с заданной …

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

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

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

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

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

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

Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.

Здесь главное – ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой – не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.

Например: Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 600 Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа "мышь".

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

Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0.

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

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

Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.

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

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

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

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

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

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

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

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

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

Oтекст программы;

Oописание программы;

Oпрограмма и методика испытаний;

Oописание применения;

Oруководство пользователя.

Это - стандартные требования. Если Заказчик соглашается с тем, что можно представить не весь этот список, то это означает несерьезность его намерений в отношении вас и вашего продукта.

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

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

Oтехнико-экономические показатели;

Oструктура программы;

Oформат представления входных данных программы;

Oобщая схема алгоритма (2 листа);
oосновные вычислительные алгоритмы;
oпример работы программы.

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

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

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

Другие источники разработки.

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

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

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

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

гарантировать сохранность данных при сбоях в работе внешних устройств.

Для повышения надежности необходимо принять следующие меры:

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

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

регулярно проверять целостность базы данных;

поддерживать исправность сетевого оборудования.

1. Требования к составу и параметрам технических средств

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

Оперативная память 128 Мбайт и выше.

Свободного места на жестком диске не менее 150 Мб.

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

Процессор AMD Athlon 900 МГц и выше.

Оперативная память 256 Мбайт и выше.

Свободного места на жестком диске не менее 250 Мб.

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

1. Требования к информационной и программной совместимости

Для эксплуатации программного продукта необходимо наличие следующих компонентов:

Операционная система семейства Microsoft®Windows® (не ниже 2000).

Установленных и сконфигурированных программных продуктов MicrosoftSQLServer, IBExpert2004,Borland®C++Builder™ 6.0,Microsoft.NETFrameworkSDKv2.0.

1. Условия эксплуатации

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

1. Требования к программной документации

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

Руководство системного администратора.

Руководство преподавателя.

Руководство обучаемого.

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

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

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

1. Этапы разработки программной системы

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

разработка плана реализации;

разработка плана тестирования;

разработка плана внедрения.

Проектирование:

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

разработка структуры БД;

проектирование пользовательского интерфейса.

Реализация:

реализация разработанного пользовательского интерфейса;

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

Тестирование системы:

структурное тестирование;

функциональное тестирование;

исправление ошибок и доработка.

Внедрение системы:

проверка наличия необходимого оборудования;

установка системы;

обучение персонала.

Сопровождение системы.

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

Пример. ЭВМ должна работать под управлением операционной системы не ниже, чем Windows 98/NT 4.0. Требование информационной совместимости должно быть обеспечено работой с файлами геометрической информации определенной структуры в качестве входной и выходной информации.

Конец работы -

Эта тема принадлежит разделу:

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

На сайте сайт читайте: "Технология разработки программного обеспечения"...

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

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

Требования к функциональным характеристикам
В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характерист

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аппаратные ограничения
Пример. Помимо устройств, нужных для VSOS ILSAM (см. п. 2.4.1, б и в), процессору корректировок потребуются устройства, перечисленные в таблице 2.3. Таблица 2.3 - Устройств

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

Справочные документы
Отдельно указывается каждый плановый или технический документ, на который имеется ссылка в СТ. Каждый такой документ должен реально существовать (а не подразумеваться в будущем) и д

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

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

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

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

Техническая ревизионная комиссия
В каждом СТ следует рекомендовать создание технической ревизионной комиссии (ТРК) с указанием места работы каждого члена комиссии и его фамилии, если это возможно, а также назначени

Уровни испытаний
Испытания программ могут быть организованы в три этапа, проводиться в трех режимах и насчитывать десять категорий (см. раздел 5 «Тестирование»). Эта информация представляется в виде таблицы. Для ка

Эталоны для сравнения
Определяются эталонные системы, относительно которых должно выполняться сравнение. Указываются характеристики данной системы в относительных единицах. Если эталона для сравнения нет

Извещение об изменении календарных сроков
Пример. Наименование проекта: Разработка изделия ASK Шифр проекта: C013. Шифр изделия: L301A. Наименование изделия: ASK

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

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

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

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

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

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

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

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

Общие положения
1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78. 1.2. Руководство системного программиста должно содержать следующие разделы: –

Структура программы
Программа «Автоматизированное рабочее место читателя» состоит из следующих компонентов: 1) zcon - приложение, реализующее функции Z39.50-кли­ен­та; 2) zgate - CGI-

Установка программы
В настоящем документе для именования файлов используется синтаксис, определенный ISO/IEC 9945-1. В тех операционных системах, которые не поддерживают указанный способ именования файлов в приложения

Проверка программы
Проверка программы осуществляется методом ее выполнения. В связи с тем, что конкретные условия применения программы (адреса Z39.50-серверов, названия баз данных, поддерживаемые точк

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

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

По требованию заказчика данное программное обеспечение разрабатывается под платформу Windows. Программа должна работать под основными версиями этой платформы:Windows98,Windows2000,WindowsXP. Причем серверная часть программы для версийWinNTдолжна работать как сервис (работать в фоновом режиме).

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

1. Требования к транспортировке и хранению

Разрабатываемая система управления будет поставляться в комплекте при продаже RAID-контроллера. Она должна быть записана на отдельныйCD-диск, на котором будут находиться драйверы системы и необходимая документация к продаваемому контроллеру. Для этого следует учесть, чтобы объем установочных файлов был не более примерно 2/3 стандартногоCD-диска (700 Мб).

1. Специальные требования

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

1. Структурная схема работы программы

Весь программный проект основан на двух независимых модулях. Как уже упоминалось, один из них запускается отдельно на компьютере с RAID-системой, а второй на компьютере администратора. Для сокращения будем называть первый модульАгентом , а второй –Менеджером .

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

Агент в основном служит для передачи команд отМенеджера RAID-системе и обратно. ТакжеАгент будет заниматься мониторингомRAID(ведениеlog-файла) и нотификацией администратора при ошибках.

Сеть

Рис. 1.2. Основная структура работы программы GUIRAIDManager

Основная структура работы всей работы в целом представлена на рис. 1.2. На нем показаны различные варианты работы двух модулей Агент иМенеджер :

Агент (C 3 ) запущен на компьютере и анализирует работуRAID-массиваR 2 ;

Менеджер с удаленного компьютера (С2 илиС4 ) может соединяться по сети с Агентом (С3 ) для управления работойRAID-массиваR 2 ;

Менеджер иАгент запущены на одном компьютере С1 для управления работойRAID-массиваR 2 . При таком варианте подключение к сети не требуется.

1. Структура входных и выходных данных

Основной обмен данными в системе в целом происходит по двум каналам:

между Менеджером иАгентом по сети по протоколуTCP/IP(командыМенеджера и ответыАгента );

между Агентом иRAID-контроллером через интерфейсRS-232 (опрос контроллера и ответы от него).

Общая схема обмена данными в проекте проиллюстрирована на рис. 1.3.

Рис. 1.3. Обмен данными в программе GUIRAIDManager

Формат данных между Менеджером иАгентом , а также междуАгентом иRAID-контроллером описан в параграфе «Формат данных модуляАгент » данного раздела.

Моей задачей в этом проекте является разработка модуля Агент . Поэтому рассмотрим подробнее обмен данных в модулеАгент междуМенеджером иRAID-контроллером. Разбитая на модули структураАгента показана на рис. 1.4

Рис. 1.4. Обмен данными в модуле Агент

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