книги / Проектирование систем управления технологическими процессами и производствами
..pdfДетальное планирование испытаний
Детальное планирование предусматривает уточнение и коррек тировку общего плана тестовых испытаний. Наряду с вопросами по подготовке тестовых данных, рассматриваются вопросы исполь зования специальных программных средств проведения испытаний (регистрации объемно-временных характеристик, вспомогательные средства тестирования и другие). В процессе детального проек тирования тестовых испытаний необходимо рассматривать тести руемую систему как систему “черных ящиков”, для которой известны все входные и выходные данные.
Планирование проверки внешних функций системы
При планировании проверки внешних функций необходимо выявить те внешние условия, реакция на которые отражает функцио нирование системы с точки зрения пользователей и которые должны проверяться в ходе тестовых испытаний. Для каждого типа входных и выходных данных просматривается путь в системе, и записываются все условия (допустимые и недопустимые), реакция на которые под лежит обязательной проверке. Проверки документируются и объ единяются в единый том документов.
Планирование проверки интерфейсов
Планирование проверки интерфейсов с другими автоматизи рованными системами выполняется по завершении проектирования системы. Определяются и составляются списки условий, которые могут иметь место при взаимодействии проектируемой системы с существующими системами. Определяются интерфейсные файлы и данные, необходимые для проведения совместных тестовых испыта ний спроектированной и существующей автоматизированной системы.
Планирование проверки работоспособности
На основе спроектированных профилей транзакций определя ются условия, подлежащие обязательной проверке при тестовых испытаниях работоспособности информационной системы. Для всех специальных функций СУ (инициализация, завершение обработки, защита данных, обработка сбоев и других) необходимо определить и составить список контрольных проверок. Все условия, проверяемые
в ходе тестовых испытаний, подлежат обязательному документиро ванию. Целесообразно осуществить документирование проверяемых условий в бланк описания проверки работоспособности процесса, представленный на рис. 10.3.
Наименование процесса: |
|
|
|
|
№ |
Условия проверки |
№ |
№ |
Файл / |
|
и ожидаемый результат |
проверки |
контрольного |
запись |
i |
|
|
примера |
|
|
|
|
|
2
Рис. 10.3. Бланк описания проверки работоспособности процесса
Систематизация проверок
Систематизация различных видов проверок, определенных на предыдущих стадиях проектирования, проводится для того, чтобы максимально приблизиться к реальной обстановке тестовых испыта ний. Во время тестовых испытаний контрольные примеры объеди няются в задания для проверки работоспособности автоматизирован ной системы. Благодаря систематизации проверок появляется реаль ная возможность проведения критического анализа контрольных при меров и заданий с целью выявления всех возможных условий обра ботки данных СУ. Обычно краткое описание проверяемых условий зано-сится в специальные бланки, представленные на рис. 10.4.
№ |
Ц ель |
Ф ай л |
П о с л е д о в а т е л ь н о с т ь |
С р о к |
|
п р о вер ки |
|
в ы п о л н ен и я |
в ы п о л н е н и я |
1 |
|
|
|
|
2 |
|
|
|
|
Рис. 10.4. Бланк описания проверяемых условий в тестовых испытаниях
Формирование плана выполнения контрольных примеров
На основе систематизации проверок формируется план выпол нения контрольных примеров, предусматривающий проверки внеш них функций, интерфейсов и работоспособности автоматизированной системы с учетом оценки затрат памяти, машинного времени и трудоемкости обработки данных.
Для каждого конкретного случая указываются цели проверки, используемые файлы, последовательность выполнения и сроки выполнения контрольных примеров, а также результат выполнения теста. Учитывается комплекс технических средств, на котором будет тестироваться система управления, а также подготовка, обслуживание и печать файлов тестовых данных.
Необходимо учитывать взаимодействие между отдельными контрольными примерами с целью планирования ресурсов тестовых испытаний (требуемое время, кадровое обеспечение, число необхо димых терминалов, периферийных устройств и т.п.).
Формирование плана выполнения контрольных примеров ведет ся разработчиками автоматизированной системы совместно с группой подготовки тестовых данных и подразделением эксплуатации СУ.
Подготовка тестовых данных
Подготовка тестовых данных проводится с привлечением пользо вателей, которые и должны сформулировать входные и выходные формы документов, являющихся входной информацией для обра ботки СУ и выходной информацией как результата обработки.
Для сокращения времени подготовки тестовых данных необ ходимо использовать следующий подход:
-подготовить тестовые данные силами проектной группы;
-привлечь пользователей к подготовке тестовых данных;
-взять данные, использованные для тестирования аналогичной автоматизированной системы;
-выделить тестовые данные из имеющихся файлов данных, используемых для локальной обработки данных в старой СУ;
-выделить тестовые данные из внемашинных носителей (ис пользование существующего документооборота в организации).
Для каждого тестового примера составляется общая схема тесто вых данных. Эти данные анализируются с целью исключения дубли рования, хотя избыточность тестовых данных допускается.
Как показывает практика, наилучшим вариантом тестовых дан ных является их подготовка непосредственно пользователем с исполь зованием существующего в организации документооборота. Однако данный способ является наиболее трудоемким.
Использование тестовых данных
Использование тестовых данных осуществляется путем ввода данных непосредственно пользователем с терминала с исполь зованием электронных образов (форм) входных документов.
Прогнозирование результатов проверок
Прогнозирование результатов проверок является трудоемкой задачей. Для каждого проверяемого условия формулируются ожида емые результаты. Прогнозирование результатов проверок позволяет значительно ускорить анализ результатов тестирования системы.
Разработка заданий на выполнение контрольных примеров
В процессе разработки программного обеспечения обычно раз рабатываются задания для выполнения контрольных примеров. Эти задания должны быть составлены таким образом, чтобы их можно было легко понять и осуществить восстановление и рестарт. Разработка заданий на выполнение контрольных примеров должна быть согласована со службой эксплуатации автоматизированной системы.
Составление календарного плана испытаний
Календарный план является основой проведения тестовых испы таний. Календарный план включает набор действий, имеющих непосредственное отношение к тестированию системы. Календарный план испытаний жестко устанавливает и регламентирует время и сроки выполнения контрольных примеров. В процессе составления календарного плана производится оценка трудоемкости выполнения каждого теста и выявляются взаимосвязи между контрольными примерами. С целью учета, выделения и сопровождения необходимых ресурсов для успешного проведения тестовых испытаний в разра ботке календарного плана испытаний должна принимать участие служба эксплуатации СУ. Для оперативного проведения испытаний и повышения достоверности выполнения контрольных примеров к планированию тестовых испытаний привлекаются все подразделения,
использующие в своей работе информационную систему. Составлен ный календарный план испытаний утверждается у заказчика и согласовывается с исполнителем.
Выполнение контрольных примеров
Выполнение контрольных примеров является первой задачей, связанной с непосредственным тестированием автоматизированной системы. Контрольный пример должен выполняться в соответствии с утвержденным планом тестовых испытаний. Целесообразно выпол нение контрольных примеров поручить службе эксплуатации СУ сов местно с персоналом заинтересованных подразделений. При тести ровании автоматизированной системы оператор должен фиксировать все результаты диалога с СУ и представлять результаты разработчику на проверку. Однако предварительное тестирование системы целе сообразно проводить в пакетном режиме, то есть без участия опе ратора выявить все возможные мелкие недостатки в спроектиро ванной СУ (ошибки в транзакциях, хранилищах данных и т.д.).
Анализ результатов испытаний
В процессе анализа результатов испытаний сопоставляются фак тические и ожидаемые результаты выполнения контрольных при меров. Если обнаруживается расхождение, то выясняются возможные причины (сбой оборудования или дефект программы). Составляется ведомость результатов испытаний (дефектная ведомость), в которой описываются ошибка и обстоятельства, при которых она была най дена, приводится детальное описание контрольного примера и тесто вых данных, указываются ссылки на файлы и выходные отчеты. Если обнаруженную ошибку можно локализовать, то в систему вносится соответствующее изменение и повторно производится тестовое испытание. Если причина возникновения ошибки непонятна, то исправление откладывается до тех пор, пока не будет точно уста новлена причина.
Анализ объемно-временных характеристик системы
В процессе постановки задачи на проектирование автома тизированной системы заказчик обычно накладывает серьезные объемно-временные ограничения на систему. В основном они затрагивают:
-время выполнения задания;
-загрузку процессора;
-время обработки данных;
-доступ к информации на жестких магнитных дисках;
-передачу информационных сообщений в системах телекоммуникаций;
-время реакции системы на ответ при диалоге и т.д. Наиболее распространенным способом определения этих харак
теристик является использование специальных средств регистрации объемно-временных характеристик системы. Полученные результаты сопоставляются с заданными в техническом задании. Однако не всегда имеется возможность применять специальные средства регистрации (недостаток финансирования). Имеется апробированный на практике способ, который дает довольно точный результат. Он базируется на определении времени доступа к данным на жестком магнитном диске, который является наиболее критичным устрой ством, влияющим на быстродействие информационной системы:
T=S + / + tj + t2,
где Т - время доступа к информации;
S - время перемещения магнитной головки; / - время ожидания требуемой записи;
t j - время передачи данных при считывании или записи (зависит от числа блоков);
t2- время повторной передачи данных (операция перезаписи).
Анализ ошибок, обнаруженных в ходе испытаний
После каждого сеанса выполнения контрольных примеров дол жны быть определены источники всех найденных ошибок:
-машинный сбой;
-нечеткая работа персонала;
-неточности в тестовых программах;
-неточности в тестовых данных;
-логические ошибки в системе или в программном обес печении.
Исправление ошибок процесс трудоемкий и обычно приводит к изменению графика испытаний автоматизированной системы.
Во избежание пустой траты времени на тестовые испытания следует придерживаться жесткого порядка исправления ошибок и повторного запуска контрольных примеров.
10.3. Организация хранения тестовых данных испытаний
В процессе проведения тестовых испытаний необходимо орга низовать централизованный учет и хранение документации по подго товке и проведению тестовых испытаний СУ, а также по полученным результатам тестирования. В проектной группе следует определить “библиотекаря”, который и будет выполнять функции по ведению библиотеки тестовых испытаний системы.
10.4. Подготовка документации по вводу систем управления в эксплуатацию
Подготовка СУ к вводу в эксплуатацию начинается с утверждения результатов тестовых испытаний.
Окончание тестовых испытаний разработанной системы управ ления необходимо согласовать с непосредственными пользователями системы, службой эксплуатации и технической группой заказчика. После получения всех согласований утверждается акт о завершении испытаний, проводится окончательная прогонка всех контрольных примеров в присутствии пользователей и после их успешного завершения подписывается акт о приемо-сдаточных испытаниях.
Необходимо иметь в виду, что раннее планирование и хорошее документирование процессов разработки автоматизированной системы способствуют уменьшению нагрузки на проектную группу при проведении тестовых испытаний.
После подписания акта приемо-сдаточных работ система управ ления вводится в опытную эксплуатацию.
Заключение
Современные информационные технологии дают неограни ченную возможность для проектирования систем управления в любых отраслях хозяйственной деятельности, производствах и техно логических процессах.
Рассмотренные основные подходы (концепции) проектирования систем управления с позиций системного и структурного подхода приобретают в современных условиях не только теоретико-научный, но и практический интерес.
В методологическом отношении проектирование СУ с позиций структурного (системного) подхода дает, прежде всего, целостное представление об объекте автоматизации с точки зрения информаци онного взаимодействия объекта автоматизации с внутренней и внешней средой, влияющей на производство.
Проектирование систем - это сложный реалистичный научноисследовательский процесс, основанный на детальном изучении не только внутренней сущности объекта, но и его внешней среды функционирования.
Проектирование представляет собой целостный процесс, в кото ром, кроме разработчиков СУ, участвуют все специалисты органи зации-заказчика, так как только они обладают всей полнотой знаний, являющихся основой создаваемой системы. Разработчики лишь помогают систематизировать эти данные и на их основе построить организационно-техническую систему с использованием совре менных информационных технологий.
Особое внимание при оценке эффективности СУ уделяется программно-техническим средствам. При их эксплуатации имеют место поломки, сбои, отказы, вследствие чего не обеспечивается требуемая надежность системы управления в целом.
Как известно, основная задача СУ - оперативно доставить досто верную информацию от источника до потребителя и произвести над доставленной информацией определенные действия. Отсюда вытека
ет задача обеспечения надлежащей надежности проектирования программно-технической системы.
Предложенный системный теоретико-технологический подход построения систем управления позволит специалистам в области автоматизации и информатизации рассматривать объект исследования как совокупность правовых, нормативных, экономических, организа ционных и программно-технических норм. Полученные знания помогут специалистам структурировать изучаемый объект в зави симости от поставленных пользователем задач, проектировать автома тизированные системы управления, начиная с АСУТП, АСУП и заканчивая автоматизацией управления социально-экономическими системами.
Литература
1.Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 1983. - 320 с.
2.Баронов В.В., Сазонов А.В., Позин Б.А., Титовский И.Н. Особен ности использования и внедрения ERP-систем в России. - /АйТи/ //
www.int.kiev.ua/citforum/seminars/cis99/epr.shtml.
3.Бойко B.B., Савинков В.М. Проектирование баз данных информаци онных систем. - М.: Финансы и статистика, 1989. - 351 с.
4.Дейт К. Руководство по реляционной СУБД DB2. - М.: Финансы и статистика, 1988. - 320 с.
5.Джексон Г. Проектирование реляционных баз данных для исполь зования с микроЭВМ. -М .: Мир, 1991.-252 с.
6.Калянов Г.Н. CASE: структурный системный анализ (автоматизация
иприменение). - М.: ЛОРИ, 1996. - 154 с.
7.Кириллов В.В. Структуризованный язык запросов (SQL). - СПб.: ИТМО, 1994. - 80 с.
8.Кричинин И.А., Аверин В.И., Лев В.Н. Экономическая эффективность автоматизированных систем управления промышленным пред приятием. - М.: Энергия, 1971. - 215 с.
9.Мартин Дж. Планирование развития автоматизированных систем. - М.: Финансы и статистика, 1984. - 196 с.
10.ТиориТ.,Фрай Дж. Проектирование структур баз данных.-М., 1985. -248 с.
11.Трусов А.В. Концепция построения интегрированной телекомму никационной системы акционерного коммерческого банка // Сборник научных трудов / ГосНИИУМС. - Пермь, 1996. - С. 104 - 113.
12.Трусов А.В. Введение в проектирование программно-технических комплексов для решения задач автоматизации информационных процессов / Пермский ЦНТИ. - Пермь, 2001. - 66 с.
13.Трусов А.В., Бордюже В.В., Березовик ЮЛ. Интегрированная систе ма управления акционерного коммерческого банка / Пермский ЦНТИ. - Пермь, 2001. - 90 с.