Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления icon

Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления




НазваниеРешить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления
страница1/3
Дата20.11.2012
Размер0.52 Mb.
ТипДокументы
источник
  1   2   3
1. /все ответы 1 часть.doc
2. /все ответы 2 часть.doc
3. /термины.doc
1 Состав и структура информационных систем
Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления
Association Francaise de Normalisation французская ассоциация по стандартизации, аналогичная по назначению ansi

6-7

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

1. Обследование объекта автоматизации (анализ) и формулирование требований пользователей к системе управления.

2. Постановка целей. Анализ существующих методов и средств автоматизации аналогичных объектов и формулирование на основании требований пользователя достижимых целей функционирования системы управления. Цели должны быть четкими, явными и измеримыми. Цели должны определять: общее назначение системы, определение разных групп пользователей и их роли, подробное перечисление функций системы, виды необходимой документации, параметры эффективности (производительности), совместимость с другими продуктами и стандартами, конфигурации аппаратуры, средства обеспечения безопасности, методы и средства настройки и обслуживания, методы обеспечения надежности системы. Цели не должны конфликтовать между собой, так как ими необходимо руководствоваться для выработки компромисных решений на следующих этапах проектирования.

3. Разработка архитектуры системы (декомпозиция функциональной структуры и определение связей между ее элементами). Выделение уровней управления, подсистем, комплексов задач, задач и функций управления.

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

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

6. Разработка информационной модели системы (проектирование структур баз данных и их связей).

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

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

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

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

11. Интеграция (сборка) системы в соответствии с выбранным методом и ее тестирование. Этапы тестирования: автономное тестирование - контроль отдельного программного модуля изолированно от других модулей, тестирование сопряжений - контроль сопряжений между частями системы, тестирование функций - контроль выполнения системой автоматизируемых функций управления, комплексное тестирование - испытание поведения системы по отношению к исходным целям, тестирование приемлемости - проверка соответствия системы требованиям пользователей. Тестирование - процесс выполнения программы с целью найти в ней ошибки. Существует два подхода к проектированию тестов - тестирование по отношению к спецификациям (не заботясь о тексте программы) и тестирование по отношению к тексту программы (не заботясь о спецификациях). Разумный компромис лежит где-то посередине, смещаясь в ту или другую сторону в зависимости от функций, выполняемых конкретным модулем. Также отметим, что стоимость этапа тестирования составляет до 25% от общей стоимости затрат на разработку системы.

12. Разработка методического обеспечения. Руководства пользователей, инструкции по эксплуатации, технологические инструкции.

13. Внедрение системы на объекте.

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


8-9

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

К настоящему времени наибольшее распространение получили следующие основные модели жизненного цикла:

Задачная модель;

каскадная модель (или системная) (70-85 г.г.);

спиральная модель (настоящее время).

Задачная модель

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

Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново);

Эксперимент и адаптация заказчика (не ясны алгоритмы, решения нащупываются методом проб и ошибок).

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

Каскадная модель

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

Положительные стороны применения каскадного подхода заключаются в следующем:

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

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




Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к информационным системам "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания программного обеспечения, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Сущность системного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Таким образом, данная модель основным достоинством имеет системность разработки, а основные недостатки - медленно и дорого.


Спиральная модель

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

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

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


11

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

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

поддерживать полный жизненный цикл информационной системы;

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

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

технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек);

обеспечивать минимальное время получения работоспособной системы;

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

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

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

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

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


39

Формализации показателей качества программных средств посвящена группа нормативных документов. В международном стандарте ISO 9126:1991 при отборе минимума стандартизируемых показателей выдвигались и учитывались следующие принципы: ясность и измеряемость значений, отсутствие перекрытия между используемыми показателями, соответствие установившимся понятиям и терминологии, возможность последующего уточнения и детализации. Выделены характеристики, которые позволяют оценивать ПС с позиции пользователя, разработчика и управляющего проектом. Рекомендуются 6 основных характеристик качества ПС, каждая из которых детализируется несколькими (всего 21) субхарактеристиками.

Функциональная пригодность детализируется пригодностью для применения, точностью, защищенностью, способностью к взаимодействию и согласованностью со стандартами и правилами проектирования.

Надежность рекомендуется характеризовать уровнем завершенности (отсутствия ошибок), устойчивостью к ошибкам и перезапускаемостью.

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

Эффективность рекомендуется характеризовать ресурсной и временной экономичностью.

Сопровождаемость характеризуется удобством для анализа, изменяемостью, стабильностью и тестируемостью.

Переносимость предлагается отражать адаптируемостью, структурированностью, замещаемостью и внедряемостью.

Характеристики и субхарактеристики в стандарте определены очень кратко, без комментариев и рекомендаций по их применению к конкретным системам и проектам.

Близким к описанному стандарту по идеологии, структуре и содержанию является ГОСТ 28195-89. На верхнем, первом, уровне выделено 6 показателей — факторов качества: надежность, корректность, удобство применения, эффективность, универсальность и сопровождаемость. Эти факторы детализируются в совокупности 19 критериями качества на втором уровне. Дальнейшая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240. Каждый из них рекомендуется экспертно оценивать в пределах от 0 до 1. Состав используемых факторов, критериев и метрик предлагается выбирать в зависимости от назначения, функций и этапов жизненного цикла ПС.

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

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

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

16

При использовании сетевых информационных технологий становится возможной реализация территориального распределения производства. Для администрации фирмы становится безразлично, где именно находится производство: в этом здании, за 100 м или за 10 000 км. Появляются совсем другие проблемы, такие как межконтинентальное снабжение, поясное время и т.д., поскольку становится возможным планетарное распределение промышленного производства. Могут создаваться транснациональные компании, реализующие мировой товарный экспорт внутри фирмы. При этом метрополия, вложив 5–7% от суммы оборота в экономику другой страны, получает возможность контролировать 50–60% ее экономики. Объясняется это тем, что за счет вложения наукоемких технологий страна-метрополия получает возможность оказывать влияние и даже осуществлять контроль за экономическим и политическим развитием другой страны. Например, 80% всех международных кредитных операций совершают банки США. Инвалютные резервы центральных банков западных стран на 75% состоят из американских долларов, а 55% расчетов по международной торговле реализуется американскими долларами, т.е. США расплачиваются воспроизводимыми ресурсами: информационными технологиями, научно-техническими знаниями, долларами. Это становится возможным благодаря новейшим сетевым технологиям и развитию коммуникаций.

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

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

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

В системе распределенной обработки клиент может послать запрос к собственной локальной базе или удаленной. Удаленный запрос – это единичный запрос к одному серверу. Несколько удаленных запросов к одному серверу объединяются в удаленную транзакцию. Если отдельные запросы транзакции обрабатываются различными серверами, то транзакция называется распределенной. При этом один запрос транзакции обрабатывается одним сервером. Распределенная СУБД позволяет обрабатывать один запрос несколькими серверами. Такой запрос называется распределенным. Только обработка распределенного запроса поддерживает концепцию распределенной базы данных.

База данных – это автоматизированные хранилища оперативно обновляемой информации. Если в 70-е гг. шла торговля «сырой» информацией, т.е. данными, то в наше время созданы автоматизированные аналитические комплексы, торгующие результатами анализа «сырой» информации. Такие базы называют «серой» нефтью (мозгом). Например, в США фирмы объединились в Ассоциацию информационной индустрии, что позволило обеспечить реализацию 80% мировых информационных услуг.

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

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

17

Централизованный, или метод извлечения данных вручную, является самым простым для реализации способом. На одном сервере находится единственная копия базы данных. Все операции с базой данных обеспечиваются этим сервером. Доступ к данным выполняется с помощью удаленного запроса или удаленной транзакции. Достоинством такого способа является легкая поддержка базы данных в актуальном состоянии. Недостатком является то, что размер базы ограничен размером внешней памяти, все запросы направляются к единственному серверу с соответствующими затратами на стоимость связи и временную задержку. Отсюда – ограничение на параллельную обработку. База может быть недоступной для удаленных пользователей при появлении ошибок связи и полностью выходит из строя при отказе центрального сервера.

При распределении данных на основе расчленения база данных размещается на нескольких серверах. Существование копий отдельных частей недопустимо. Достоинства: увеличивается объем базы данных; большинство запросов удовлетворяется локальными базами; что сокращает время ответа; увеличивается доступность и надежность; стоимость запросов на выборку и обновление снижается по сравнению с централизованным распределением: если выйдет из строя один сервер, система останется частично работоспособной. Недостатки: часть удаленных запросов или транзакций могут потребовать доступ ко всем серверам, что увеличивает время ожидания и цену; необходимо иметь сведения о размещении данных в БД. Однако доступность и надежность увеличиваются. Расчлененные базы данных наиболее подходят к случаю совместного использования локальных и глобальных сетей ЭВМ.

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

В методе смешанного распределения объединены два способа распределения данных: дублирование и расчленение. При этом приобретены как преимущества, так и недостатки обоих способов. Появилась необходимость хранить информацию о том, где находятся данные в сети. Главное преимущество – гибкость этой системы, так как можно установить компромисс между объемом памяти под базу в целом и под базу в каждом сервере, чтобы обеспечить надежность и эффективность работы. В этой стратегии легко реализуется параллельная обработка, т.е. обслуживание распределенного запроса или транзакции. Недостатки: остается проблема взаимозависимости факторов, влияющих на производительность системы, ее надежность, повышаются требования к памяти. Смешанную стратегию используют при наличии сетевой СУБД, которая обеспечивает реализацию распределенной базы данных. Первые три метода поддерживают распределенную обработку данных.

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

40

При любом виде деятельности людям свойственно непредумышленно ошибаться, результаты чего проявляются в процессе создания или применения изделий или систем. В общем случае под ошибкой подразумевается дефект, погрешность или неумышленное искажение объекта или процесса. При этом предполагается, что известно правильное, эталонное состояние объекта, по отношению к которому может быть определено наличие отклонения — дефекта или ошибки. Для систематической, координированной борьбы с ними необходимы исследования факторов, влияющих на надежность ПС со стороны случайных, существующих и потенциально возможных дефектов в конкретных программах. Это позволит целенаправленно разрабатывать комплексы методов и средств обеспечения надежности сложных ПС различного назначения при реально достижимом снижении уровня дефектов проектирования.

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

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

Объектами уязвимости, влияющими на надежность ПС, являются:

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

• информация, накопленная в базах данных, отражающая объекты внешней среды, и процессы ее обработки;

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

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

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

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

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

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

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


41

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

• создавать программные модули и функциональные компоненты высокого, гарантированного качества;

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

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

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

• оперативно выявлять последствия дефектов программ и данных и восстанавливать нормальное, надежное функционирование

комплексов программ.

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

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

50

Многие организации, занимающиеся созданием программного обеспечения, до 50% средств, выделенных на разработку программ, тратят на тестирование, что составляет миллиарды долларов по всему миру в целом. И все же, несмотря на громадные капиталовложения, знаний о сути тестирования явно не хватает, и большинство программных продуктов неприемлемо, ненадежно даже после «основательного тестирования».

О состоянии дел лучше всего свидетельствует тот факт, что большинство людей, работающих в области обработки данных, даже не могут правильно определить понятие «тестирование», и это на самом деле главная причина неудач. Если попросить любого профессионала определить понятие «тестирование» либо открыть (как правило, слишком краткую) главу о тестировании любого учебника программирования, то скорее всего можно встретить такое определение:

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

Тестирование — процесс выполнения программы с намерением найти ошибки.

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

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

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


51

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

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

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

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

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

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

Избегайте невоспроизводимых тестов, не тестируйте «слету». Использование диалоговых систем иногда мешает хорошему тестированию. Для того чтобы тестировать программу в пакетной системе, программист обычно должен оформить тест в виде специальной ведущей программы или в виде файла тестовых данных. В условиях диалога программист слишком часто выполняет тестирование «с лету», т. е. сидя за терминалом, задает конкретные значения и выполняет программу, чтобы «посмотреть, что получится». Это неряшливая и по многим причинам нежелательная форма тестирования. Основной ее недостаток в том, что такие тесты мимолетны; они исчезают по окончании их выполнения. Всякий раз, когда программу понадобится тестировать повторно (например, после исправления ошибок или после модификации), придется придумывать тесты заново.

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

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

  1   2   3



Похожие:

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

Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления iconМетодический семинар «Использование современных информационных и коммуникационных технологий в условиях введения фгос»

Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления icon1. Понятие информационных технологий
Понятие информационных технологий включают в себя многообразие методов и способов управления концепции её формирования, а так же...
Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления iconСеместровый учебный план для студентов факультета специальной педагогики (4курс лого-ов) по курсу «использование современных информационных и коммуникационных технологий в учебном процессе»
По курсу «использование современных информационных и коммуникационных технологий в учебном процессе»
Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления iconСеместровый учебный план для студентов факультета специальной педагогики (5курс лого-ов) по курсу «использование современных информационных и коммуникационных технологий в учебном процессе»
По курсу «использование современных информационных и коммуникационных технологий в учебном процессе»
Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления iconОрганизация межведомственного взаимодействия для повышения качества оказания услуг населению
Информационных технологий Главного управления информационных технологий Смоленской области
Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления iconВосточный институт экономики, гуманитарных наук, управления и права Факультет информационных технологий и управления Кафедра «Государственное и муниципальное управление»
Система кадрового обеспечения обеспечивает непрерывное совершенствование методов работы с кадрами и использованием достижений отечественной...
Решить проблему повышения эффективности управления производством в современных условиях невозможно без внедрения новейших информационных технологий и современных методов управления iconПриходько Юлия Алексеевна Приложение №2 Белгородский региональный институт повышения квалификации и профессиональной переподготовки специалистов Особенности использования информационных технологий на уроках математики. (реферат)
Необходимость внедрения новых информационных технологий в процесс обучения математики
Разместите кнопку на своём сайте:
Документы


База данных защищена авторским правом ©lib3.podelise.ru 2000-2013
При копировании материала обязательно указание активной ссылки открытой для индексации.
обратиться к администрации
Лекции
Доклады
Справочники
Сценарии
Рефераты
Курсовые работы
Программы
Методички
Документы

опубликовать

Документы