Текст книги "Журнал PC Magazine/RE №06/2008"

Office
Встречи назначаются автоматически

Дэвид Кардинал

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

Нужно лишь внести соответствующие данные в именованный диапазон таблицы Excel, после чего их можно импортировать как расписание встреч. Если данные хранятся в электронной таблице, достаточно выделить все необходимые ячейки, щелкнуть правой клавишей мыши, выбрать вариант Name a Range (Имя диапазона) и задать имя. Если данные, которые предстоит импортировать, представлены в виде таблицы на Web-странице, их следует выделить, скопировать и вставить в таблицу Excel, а затем импортировать в Outlook.

Одно важное замечание. Как ни странно, Outlook 2007 не позволяет импортировать файлы Excel 2007 (XLSX). Если вы работаете с Office 2007, сохраните свою таблицу в формате 97-2003.

1. Подготовка данных. Импортировать расписание встреч будет очень легко, если данные хорошо отформатированы. Во-первых, над данными надо расположить наименования столбцов, чтобы было понятно, какие данные на какие поля Outlook отображаются. Если имена столбцов совпадают с именами собственных полей Outlook (например, Место и Тема), поля будут отображаться автоматически и надлежащим образом. Во-вторых, если тема события в явном виде не указана, вводим дополнительный столбец с общим названием, которое вам знакомо. К примеру, в Станфордском теннисном календаре, который я импортирую, перечислены только соперники и даты. Поэтому, прежде чем импортировать, я добавляю в качестве темы столбец «Станфордский теннис». Наконец, я добавляю столбец с названием, который импортирую как категорию Outlook. Таким образом, при обновлении времени и даты событий достаточно выбрать пункт View by Category (Просмотр по категориям) и перед повторным импортом информации удалить все встречи данной категории.

2. Импорт электронной таблицы. Импорт расписаний встреч выполняется довольно просто. Выведите свой календарь в окне Outlook и обратитесь к команде File | Import and Export (Файл | Импорт и экспорт), выбрав в качестве типа файла таблицу Excel. После выбора таблицы получаем список именованных диапазонов файла. Выбираем из них один (или несколько) для импорта. Затем столбцы данных можно отобразить на собственные поля Appointment (Встречи) Outlook для настройки. Для завершения процедуры нужно щелкнуть на кнопке Finish (Готово).

Совет редактора.

Напоминания в полях Outlook

Чтобы подготовить напоминания о событиях, столбцу присваивается заголовок «Напоминание включено/выключено», а для выдачи предупреждения используется код TRUE (ИСТИНА). Для выбора момента напоминания используются заголовки «Дата напоминания» и «Время напоминания»; задать дату или время напоминания в определенном интервале, предшествующем дате или времени начала события, можно даже с помощью формул.

3. Проверка календаря. После импорта событий в Outlook они выводятся на экран точно так же, как и любые другие встречи. Чтобы время в Outlook правильно воспроизводилось, нужно выбрать для времени и даты верный формат. К примеру, Outlook опознает как время запись «3:00», но не «3».

Новости. С 15 по 15

Программы

Компания «ИВК» (www.ivk.ru) объявила о разработке комплекса «ДатаМаркет», позволяющего организовать защищенную систему распределенного хранения неоднородных информационных ресурсов АИС с применением средств интеграционной платформы «ИВК Юпитер».

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

При этом системы сбора информации об объектах АИС формировались хаотично (как с технической точки зрения, так и с нормативной), что вызывало ряд проблем, характерных для так называемой «лоскутной» автоматизации. Это и невысокий общий уровень информатизации (как самих предприятий и организаций, так и федеральных органов исполнительной власти), проблемы совместимости различных автоматизированных систем и др.

В основе пакета «ДатаМаркет» лежит концепция «единого информационного пространства». Информация размещается на так называемых «витринах данных», позволяющих организовать систематизированное представление материалов (файлов, сообщений и пр.) в виде вложенного списка, навигация по которому производится стандартными средствами Web-браузера. Система функционирует на базе ПО промежуточного слоя «ИВК Юпитер», хранилище представляет собой каталог ссылок на разнородные информационные объекты, хранящиеся в специализированных хранилищах на узлах информационной системы.

Извлечение данных из «ДатаМаркет» сопровождается генерацией унифицированного запроса на выборку заданного информационного объекта в соответствии с параметрами ссылки и профилем клиента системы.

При этом работа с данными хранилища контролируется как встроенными механизмами защиты самих объектов хранения, так и средствами защиты информации платформы «ИВК Юпитер». Работа с распределенным хранилищем АИС «ДатаМаркет» строится как система управления знаниями, в основе которой лежит информационно-поисковая система со средствами лингвистического поиска.

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

Системы хранения

Корпорация Teradata (www.teradata.com) объявила о выпуске новой серии систем хранения данных, построенной на базе Teradata 12.0.

В частности, объявлены симметричная многопроцессорная система Teradata 550 SMP (позиционируемая как хранилище данных уровня департамента), система Teradata 2500 (хранилище данных начального уровня для компаний), Teradata 5550 («активное хранилище»). Система Teradata 550 оптимизирована для использования аналитических систем, проста в настройке и может работать под управлением Windows или 64-разрядной версии Novell SUSE Linux.

Teradata 2500 – интегрированная система начального уровня, в состав которой входят двухъядерный сервер, ПО и ряд дополнительных компонентов.

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

Основа систем – база данных Teradata 12. Она создавалась для использования в составе сложных аналитических систем и систем класса «поддержка бизнеса», оптимизирована для решения таких задач, как генерация сложных отчетов и анализ данных по требованию.

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

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

«1С: Предприятие»

«1С: Предприятие 8»: сопровождение сложных конфигураций

Никита Зайцев

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

В предыдущей статье цикла была приведена классификация тиражных решений на платформе «1С: Предприятие 8»: типовые и отраслевые конфигурации (на базе типовых либо созданные с нуля), отраслевые и универсальные надстройки над конфигурациями. Ситуация, когда информационная база предприятия построена на базе двух и более тиражных решений, предоставленных разными разработчиками, – вполне обыденна. Разнообразие «форм жизни» в экономике и бизнесе ставит перед специалистами по автоматизации самые разные учетные и управленческие задачи, которые необходимо решать в рамках единого информационного пространства предприятия, а конфигурация «Управление Вселенной», к сожалению, на рынке не представлена.

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

Поддержка интегрированных конфигураций

Совместить несколько разнородных конфигураций «1С: Предприятия 8» в единое информационное пространство можно двумя способами:

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

• объединить конфигурации в рамках одной информационной базы.

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

Совсем другое дело, когда от элементов интегрированной информационной системы требуется постоянное и оперативное взаимодействие. Простой пример: интеграция системы управления торгово-закупочной деятельностью («1С: Управление торговлей») с конфигурациями, в которых реализованы функции складской логистики, управления взаимоотношениями с клиентами, управления цепочками поставок и т. д. В этом случае от всех функциональных блоков требуется полная синхронность действий; информация, внесенная или модифицированная в одной подсистеме, должна сразу же становиться доступной во всех остальных, а иногда и порождать в других подсистемах соответствующие события. Единственное решение такой задачи – объединение всех необходимых конфигураций (обычно – двух, но бывает, что и большего количества) в единую и неделимую информационную базу.

Технология поддержки

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

Сценарий «вертикальной поддержки»

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

Вертикальная поддержка

• Поставщик «А» формирует и выпускает поставку тиражной конфигурации «А».

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

• Поставщик «Б» формирует поставку конфигурации «Б» и передает конечному пользователю.

• Конечный пользователь разворачивает на основе конфигурации «Б» информационную базу и ставит конфигурацию на поддержку.

• Поставщик «А» формирует и выпускает обновление конфигурации «А».

• Поставщик «Б» получает обновление от поставщика «А», обновляет свою конфигурацию, формирует обновление конфигурации «Б» и передает конечному пользователю.

• Конечный пользователь обновляет свою информационную базу в режиме «Полная поддержка».

Сценарий «вертикальной поддержки» применяется, как правило, в двух случаях:

• При разработке тиражных отраслевых конфигураций, построенных на базе типовых конфигураций «1С». В роли поставщика «А» выступает фирма «1С», а поставщика «Б» – партнер-разработчик.

• При доработке тиражной конфигурации под нужды конкретного предприятия в рамках проекта внедрения. В роли поставщика «А» выступает разработчик тиражного решения (фирма «1С» или партнер-разработчик), а поставщика «Б» – партнер-внедренец и (или) внутренний отдел ИТ предприятия-пользователя.

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

Но у сценария есть и недостаток, который является прямым следствием из преимущества. Представим такую ситуацию: партнер-разработчик («Б-1») создал свое тиражное решение на базе типовой конфигурации «1С», партнер-внедренец («Б-2») на базе этого же решения разработал конфигурацию для конечного пользователя. Далее фирма «1С» выпускает обновление своей типовой конфигурации. Тогда передача обновлений происходит по «вертикали», т. е. последовательно. Партнер «Б-1» должен обновить свою конфигурацию и выпустить свое обновление. Партнер «Б-2» должен дождаться этого обновления и проделать аналогичную операцию со своей конфигурацией, и только потом обновление дойдет до конечного пользователя. И чем значительнее изменения, внесенные в исходные конфигурации обоими поставщиками (заметим, что поставщиков в такой схеме может быть и больше двух), тем больше времени займет передача обновлений по всей цепочке. Фактор времени может оказаться важным и даже критичным для конечного пользователя, например, когда обновление исходной типовой конфигурации содержит поддержку изменений в законодательстве и (или) исправление серьезных ошибок.

Сценарий «горизонтальной поддержки»

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

Сценарий действий поставщиков и пользователя строится следующим образом:

Горизонтальная поддержка

• Поставщик «А» формирует и выпускает поставку тиражной конфигурации «А».

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

• На стороне конечного пользователя (либо его собственными силами, либо с помощью специалистов поставщика «Б») разворачивается информационная база на основе конфигурации «А». Далее, в этой информационной базе включается режим «поддержка с возможностью изменения» и производится последовательное объединение с конфигурациями «В» (если она использовалась на предыдущем шаге) и «Б». В процессе объединения каждая из конфигураций ставится на поддержку своего поставщика.

• Любой из поставщиков («А», «Б» или «В») в любое время может сформировать и выпустить обновление своей конфигурации. Конечный пользователь получает обновление от любого из поставщиков и тут же устанавливает его на свою информационную базу.

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

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

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

Использование буферной информационной базы

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

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

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

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

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

Зачем вводить в цепочку поддержки лишний элемент? В этом «лишнем элементе» есть определенный смысл. Использование буферной информационной базы позволяет:

• избежать редкой, но крайне неприятной проблемы – «установка обновления привела к частичной или полной неработоспособности информационной базы». Конечно, рабочую базу можно точно так же восстановить из резервной копии, как и буферную (хотя на это уйдет, возможно, на порядок больше времени), но в случае буферной базы неудачная попытка обновления будет абсолютно прозрачна для пользователей и не приведет к прерыванию рабочих процессов;

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

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

При этом трудозатраты на операции «сформировать обновление в буферной базе» и «установить обновление на рабочую базу» можно свести практически к нулю – эти операции поддаются автоматизации штатными средствами платформы «1С: Предприятие 8». Для указанных операций необходимо использовать пакетный режим работы Конфигуратора (запуск из командной строки или командного файла Windows с передачей параметров через набор ключей). Например, так может выглядеть строка запуска Конфигуратора с командой «сформировать файл обновления» в самом простом случае:

1cv8.exe CONFIG /Smyservermybase /WA+ /CreateDistributeFiles – cfufile – v2.0.4

А так в самом простом случае может выглядеть строка запуска с командой «установить обновление на рабочую базу»:

1cv8.exe CONFIG /Smyservermybase /WA+ /UpdateCfg\srvcfu2.0.51Cv8.cfu /UpdateDBCfg

Перечень параметров командной строки, используемых для управления Конфигуратором в пакетном режиме, содержится в документации к «1С: Предприятию 8», этот перечень также легко найти в Интернете.

Функциональное тестирование обновлений

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

Тест-центр, результаты тестирования

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

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

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

Первый способ подкупает своей простотой – фактически делать ничего не нужно; даже если в конфигурацию и были внесены ошибки, пользователи легко могут их не заметить, а если и заметят, всегда можно свалить вину на поставщика тиражной конфигурации. Но привлекательность простых решений в ИТ обманчива. Во-первых, когда ошибка все-таки замечена, придется затратить значительное количество самых ценных и невосполнимых ресурсов – нервов и времени. К сожалению, самая серьезная ошибка выявляется именно в тот момент, когда она является критичной в высшей степени, а задача на исправление ставится в виде «нужно было еще позавчера». Во-вторых, оба способа представляют собой итерационный процесс, но при первом способе число ошибок после каждой итерации практически не уменьшается. Исправления, которые вносятся в систему на ходу, без предварительного анализа и последующей комплексной проверки, по статистике в ~80 % случаев приводят к возникновению новых ошибок.

Собственно, вопрос, требуется ли функциональное тестирование при обновлении сложных интегрированных конфигураций «1С: Предприятия 8», даже и не стоит. Тестирование требуется, это ясно. Вопрос стоит другой: существуют ли средства, которые помогут упростить, ускорить и, по возможности, автоматизировать тестирование?

Такое средство есть, и называется оно «1С: Корпоративный инструментальный пакет». Этот программный продукт разработан фирмой «1С» и представляет собой набор инструментальных средств для повышения производительности, стабильности и масштабируемости информационных систем на платформе «1С: Предприятие 8». На данный момент пакет содержит две конфигурации:

• «Центр управления производительностью». Этот инструмент мы рассмотрим в следующей статье нашего цикла;

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

Что представляет собой конфигурация «Тест-центр»? Это готовая инфраструктура для хранения, настройки и выполнения тестовых сценариев, а также для сбора и анализа результатов тестирования. Конфигурация легко встраивается в любую информационную базу «1С: Предприятия 8». Тестовый сценарий представляет собой заданную специалистом-тестировщиком последовательность действий, выполняемых «виртуальными пользователями». «Действие» в терминах «Тест-центра» – созданная на основании шаблона обработка, в модуле которой запрограммированы выполняемые «виртуальным пользователем» операции с объектами информационной базы. Действие может быть довольно простым (создать и записать элемент справочника), сложным (выполнить запрос, на основании результатов запроса создать, заполнить и провести ряд взаимосвязанных документов) или вообще каким угодно. Важно, что у программиста, создающего тестовый сценарий, есть возможность управлять записью результатов каждого действия, он произвольно может определить, при каких условиях считать тест пройденным успешно, а при каких – с ошибкой.

Тест-центр, конструктор сценариев

Каким образом «Тест-центр» может помочь в решении нашей задачи автоматизации функционального тестирования? Методика следующая:

• на основе буферной информационной базы создается еще одна – тестовая информационная база. В конфигурацию тестовой информационной базы встраивается «Тест-центр»;

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

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

Все эти операции, так же как и процесс передачи обновлений из буферной информационной базы в рабочую базу, можно почти полностью автоматизировать средствами «1С: Предприятия 8». Для этого надо дополнить «Тест-центр» некоторым количеством собственного кода, но это делается один раз, и затем используется всю оставшуюся жизнь.

Известную трудность представляет конструирование тестовых сценариев – понятно, что запрограммировать в них действия для проверки абсолютно всех функций информационной системы невозможно. В случае сложной конфигурации, например «1С: Управление производственным предприятием», трудозатраты на создание полного и всеобъемлющего комплекта тестовых сценариев будут, как минимум, сопоставимы с трудозатратами на создание самой конфигурации. Определить минимально необходимый набор тестовых сценариев – задача в принципе творческая, и рекомендации по ее решению можно дать только самые общие:

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

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

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

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

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

Новости. С 15 по 15

Программы

Компания «Лаборатория Касперского» (www.kaspersky.ru) объявила о выпуске пакета Kaspersky Mobile Security 7.0. Система предназначена для защиты смартфонов на базе Windows Mobile и Symbian OS от всех типов информационных угроз, а также от утечки конфиденциальных данных при утере устройства. В пакете реализован антивирусный сканер автоматически, который проверяет все входящие и модифицируемые объекты (есть также режим проверки по требованию). Опасные объекты могут быть по желанию пользователя удалены или помещены в зону карантина. Предусматривается возможность обновления антивирусных баз по различным каналам связи, включая синхронизацию с ПК.

Модуль защиты от спама отфильтровывает нежелательные SMS, защищая пользователя как от фишинга, так и от навязчивой рекламы, сетевой экран блокирует хакерские атаки и эпидемии мобильных червей, распространяющихся при помощи Bluetooth и Wi-Fi-соединений. Кроме того, в Kaspersky Mobile Security 7.0 имеется модуль «Антивор», владелец смартфона имеет возможность в случае его пропажи дистанционно заблокировать доступ к устройству или полностью очистить его память, отправив кодовое SMS-сообщение на свой номер.