Если бы «Проблемы 2000» не было, ее бы следовало выдумать

Мелкие противные «насекомые» (bugs), выглядывающие из всех компьютерных щелей, порядком поднадоели пользователям. Проблема 2000 года — определенный вызов не столько профессионализму программистов, сколько ответственности и организованности их самих и их руководителей. А пока еще можно слышать: «И кто придумал эту проблему 2000 года?».

Хочу обратиться к своему полугодовому опыту работы в этом направлении. За это время в нашем Центре были проведены анализ условий и классификация вариантов несоответствия 2000 году, неформальная инвентаризация с выяснением «датазависимости» компонентов, спланировано и запущено первоначальное их тестирование и обновление.

Заведомо «непроходные» варианты

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

Даты дальних событий отстоят от сегодня более чем на 50 лет, например: даты рождения, даты погашения долгосрочных кредитов и т. п. Даты ближних событий имеют диапазон изменения менее 50 лет — дата отчета, дата проведения операции и т. п.

Проблема 2000 года связана с хранением и внешним представлением дат дальних событий. Рассмотрим таблицу возможных вариантов использования и представления дат. Как мы видим, в первых трех вариантах происходит усечение и потеря информации, поэтому такое информационно-программное обеспечение (ИПО) необходимо безусловно обновлять. Не верьте в мифы разработчиков о том, что «смещенные» окна могут помочь представить даты дальних событий. В общем случае это неверно. Недопустимы хранение, ввод и вывод дат дальних событий в коротком формате. Наличие календарных операций может только усугубить проблему.

Даты ближних событий допустимо вводить и выводить в коротком формате при условии правильной их интерпретации. Для правильной интерпретации дат, вводимых в коротком формате, предлагается включить поддержку доступного механизма окон для всего приложения. Хранение же таких дат должно быть в длинном формате с четырьмя цифрами года (типы DATE или символьный в ISO-совместимом формате), исключение могут составить поля для короткого представления года, по которым не производится сортировка и вычисление будущих дат. Даты ближних событий в коротком формате должны интерпретироваться правильно в определенном окне с учетом наложения действий окон разных компонентов, например, для Oracle вместе с пакетами MS Office оно имеет диапазон от 1950 до 2029 (2019).

А есть ли заведомо «проходные» варианты? Только датанезависимые приложения, другие нужно тестировать.

Проведенный анализ позволяет рекомендовать:

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

Эта скучная инвентаризация

В связи с тем что времени для проведения необходимых работ по проблеме 2000 года чрезвычайно мало, предлагается ограничить круг обновляемых (и тестируемых) приложений только критическими, чтобы не допустить остановок или сбоев в производственных задачах. Критические компоненты необходимо привести в соответствие 2000 году, и они должны нормально функционировать в период 1999-2000 годов — при их неправильной работе у учреждения могут возникнуть серьезные проблемы. Остальные приложения можно протестировать и обновить позже.

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

• технические средства (вычислительная техника, интеллектуальное сетевое и телекоммуникационное оборудование);
• системное и общее ПО (ОС, СУБД, сетевое ПО, утилиты, офисные пакеты, инструментальные средства);
• прикладное ПО (комплексы, задачи, АРМ и программы);
• информационные ресурсы (базы данных, файлы и архивы);
• макеты обмена файлами (структура входных и выходных файлов).

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

Одновременнр мы выясняли зависимость от даты, ориентируясь на следующие характеристики:

• наличие дат дальних событий;
• наличие дат в символьном формате (символьные даты);
• представление даты (разрядность года) при хранении данных, в макетах обмена данными, при диалоговом вводе, при выводе и при именовании файлов (необязательно);
• использование календарных операций;
• cоответствие 2000 году техники, ОС, СУБД и инструментов, с которыми связано данное приложение (согласно информации фирм-производителей).

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

Тестируйте, тестируйте...

Я столкнулся с ситуацией, когда тестировать не хотят, а подчас просто не умеют. Вот цели, которые мы ставили для первоначального тестирования:

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

Тестирование ИПО основано на проведении по крайней мере двух серий испытаний при установке системной даты на 1999 год и на любой год начиная с 2000 (не позже 2030). Результаты тестов внутри одной серии должны удовлетворять правилам Британского института стандартов по соответствию 2000 году. Повторение испытаний с теми же тестовыми наборами при установке будущего времени не должно изменить результатов тестирования. Но не всегда это возможно. Тесты должны естественным образом вписываться в технологию работы приложения, но включать помимо правильных и неправильные даты. Тестирование является целенаправленным разрушительным процессом, ориентированным на нарушение работы системы или снижение ее устойчивости.

При тестировании прикладного ИПО проверке подлежат:

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

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

Описание тестов для каждого испытания включает в себя две части: сценарий тестирования и тестовые наборы.

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

Вот некоторые общие рекомендации.

• При вводе обязательна проверка високосного года (29-02-2000 или 29-02-00) и желательно наличие дат 1999 и 2000 годов. Ввод в короткое поле даты в длинном формате и, наоборот, в длинное поле даты в коротком формате (последнее вызывает массу проблем). Рекомендуется тестирование выполнять при включенной поддержке механизма окна для коротких дат.
• Анализ выходных форм на наличие дат в длинном формате, которые были введены или импортированы в коротком формате. Анализ по выходным формам вычисляемых календарных периодов, вычисляемых дат, дней недели и других календарных мер.
• Контроль правильности интерпретации путем выборки из БД. Сканирование рабочей БД по полям дат, вводимых в коротком формате, для поиска неверных дат в диапазоне лет 1900-1919. Тестирование вариантов обновления или нейтрализации неверных дат в БД.
• Поиск данных по коротким датам на совпадение всей или части даты (месяцу, году). Поиск данных по вычисляемой дате, заданной относительным смещением от текущей даты (назад или вперед); текущая и искомая даты должны находиться в разных столетиях.
• Фильтрация данных по коротким датам (на равно, на меньше/больше или по части даты) или диапазону коротких дат. Фильтрация данных по периоду (относительному смещению); даты начала и конца периода должны находится в разных столетиях.
• Сортировка данных по короткому символьному полю даты (без расширения) с контролем нарушения последовательности. Должны присутствовать даты 1999 и 2000 годов.
• Тестирование динамического расширения (заданного в операторе SELECT) для короткого символьного поля даты при сортировке с контролем нарушения последовательности. Должны присутствовать даты 1999 года и 2000-х годов.
• Автономное тестирование используемых календарных функций. В ряде случаев это позволяет сократить объемы тестирования приложений.

Синхронизация клиентов и серверов

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

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

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

А напоследок я скажу...

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

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

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

Возможные варианты использования и представления дат

Рекомендуемый тестовый набор дат для проверки диалогового ввода и импорта