индустрии, то за этим может скрываться банальное желание заставить нас в очередной раз сменить технику и программное обеспечение.
 |
Поэтому говорить на эту тему желательно чаще, но по существу, рассматривая технические и организационные аспекты решения проблемы 2000 года, привлекая внимание руководителей и специалистов.
Этапы решения проблемы 2000 года
Решение проблемы 2000 года в организационном плане распадается на несколько достаточно хорошо определенных этапов. Предварительный этап, называемый "осведомленность о проблеме", имеет целью обратить на нее внимание, однако вряд ли сейчас уже стоит надолго останавливаться на нем.
Следующим этапом является оценивание всех компонентов. Цель его - четко определить все имеющиеся у организации программные, аппаратные средства, информационные ресурсы и интерфейсы обмена и установить степень влияния проблемы 2000 года на те или иные компоненты информационных систем. При этом используются самые разные приемы: инвентаризация, инспектирование кодов, интервью разработчиков и тестирование. В ходе инвентаризации и других процедур оценивания компоненты ранжируют по степени влияния (риска) и формируют перечень, так сказать, "подозреваемых" компонентов. При предварительном тестировании системы, вошедшие в полученный перечень, проверяются по критериям соответствия - удовлетворяют ли они проблеме 2000 года или нет. Для тестирования нужно разработать правила, вывести критерии, соответствующие правилам, и на основе этих критериев построить тесты как для системного и прикладного программного обеспечения, так и для вычислительной техники, коммуникационных узлов и других компонентов. На основе тестов подразделения, отвечающие за те или иные направления, производят оценивание своих компонентов. В результате выявляются участки, на которые проблема действительно оказывает влияние, и уже после этого проводится так называемое обновление. При обновлении вносятся те или иные изменения, например докупаются отдельные аппаратные компоненты или дорабатываются и переписываются программные коды.
| Глобальная катастрофа? Отраслевые эксперты утверждают, что решение проблемы 2000 года обойдется в сумму 600 млрд. долл., учитывая возможные сбои, простой сетей и затраты на их устранение. Некоторые трагедии и их цена | |
| Вторая мировая война | 4,2 трлн. долл. |
| 2000 год | 600 млрд.долл. |
| Война во Вьетнаме | 500 млрд.долл. |
| Землятресение в Кобе (Япони) | 100 млрд.долл. |
| Землятресение в Лос-Анджелесе | 60 млрд.долл. |
Наконец, после этой работы тестирование повторяется на тех же тестах, то есть производится проверка результативности внесенных изменений. Стоит отметить, что на первоначальных этапах предполагается, конечно, автономное тестирование, когда связи между компонентами разрываются и они существуют независимо. Но большинство современных систем отличаются распределенным характером и многоуровневой структурой. Поэтому работу завершает комплексное и системное тестирование, при котором все узлы и системы проверяются во взаимодействии.
Конечно, все особо важные компоненты должны быть протестированы с созданием специальной комиссии, которая принимает результаты работы, а не "верит на слово" подразделениям, отвечающим за их работоспособность.
Таковы организационные аспекты, а если говорить подробнее о технической стороне дела, то здесь требуется принять правила и критерии соответствия 2000 году, которые важны для построения самого тестирования.
Правила и критерии соответствия 2000 году
Существует несколько подходов к определению соответствия 2000 году компонентов информационных систем. Так, например, новозеландская компания Year2000 стоит на максималистских позициях, требуя привести внутреннее и внешнее представление даты в соответствие со стандартом ISO-8061, который регламентирует формат YYYYMMDD. Однако при всех положительных сторонах - удобстве сравнения и сортировки, однозначной интерпретации - приходится учитывать большой объем модификаций и устойчивые национальные традиции при задании даты. Разумнее принять стратегию, при которой внутреннее представление даты имеет формат ISO, а внешнее представление - длинный формат DDMMYYYY или короткий, но однозначно интерпретируемый формат DDMMYY.
Более реалистичный подход демонстрирует Британский институт стандартов, который дает четыре правила соответствия 2000 году, на основе которых можно построить критерии соответствия.
Правило и критерии общей целостности
Первое правило, так называемое правило общей целостности, определяет, что никакое значение текущей даты не вызовет прерывания в работе. Этот аспект касается того, как мы получаем время, откуда мы его получаем, в частности сегодняшнюю дату и время. Эти вопросы "адресованы" прежде всего аппаратному уровню и системному уровню. Необходимо установить, как реализована поддержка текущей даты. На программном уровне рассматривается работа функции "сегодня", на аппаратном - смена дат, то есть контроль смены дат. В частности, придется проверять, как выполняется переход через столетие, как в 2000 году происходит смена февраля на март и т. п. Это в большей степени затрагивает, конечно, нижний уровень системно-технического обеспечения. В данном случае можно проводить его автономное тестирование отдельно от приложений, но в комплексных и системных испытаниях необходимо воспроизвести основную часть тестов на смену дат.
Дополнительным аргументом, свидетельствующим о масштабе проблемы, служит, например, объем перечня критических дат для Соединенных Штатов, в которой внесены финансовые годы для каждого штата (в США они отличаются по штатам). Планируется проверять такие даты для каждого штата. Проверка должна учитывать начало финансового года, полный день в финансовом году.
Правило и критерии целостности дат
Второе правило, называемое целостностью дат, говорит о том, что функциональные возможности, связанные с датами, должны себя вести одинаково до, во время и после 2000 года. Все календарные операции (в основном это касается приложений, хотя даты есть и в аппаратуре): разность между датами, увеличение даты на какое-либо число, определение дня недели, месяца и года - все должно работать корректно. Дополнительно необходимо тестировать операции сравнения дат, форматные преобразования и извлечения частей из поля даты.
Следует заметить, что в этих правилах нет конкретной информации для проведения тестирования, в частности не определен диапазон допустимых дат. Нужно поставить четкие границы, в которых будет проверяться значение даты, например 2049 год. Это значение связано с определением неявного столетия методом фиксированного окна; для метода скользящего окна в качестве предела нужно взять по крайней мере 2050 год. При любой выбранной границе может оказаться, что часть компонентов при этом значении ведет себя неправильно. Тогда придется опытным путем установить другую границу, но знать ее четко. Ею может стать 37-й, 19-й год следующего столетия. И в каждом конкретном случае надо принимать решение, соответствует ли данный продукт 2000 году.
Правило високосного года
Четвертое правило (для удобства изложения речь о нем пойдет перед третьим) говорит о том, что 2000 год должен распознаваться как високосный. Это отмечается отдельно, поскольку многие программисты неправильно определяли алгоритм выявления високосных годов и 2000 год не попал в их число. Правило надо проверять, даже если в приложениях нет явных функций проверки високосного года. Необходимо обеспечить, чтобы 29 февраля было допустимо, чтобы после 28 февраля не шло сразу первое марта.
Эта ошибка вызывает некорректное определение порядкового номера дня в году, интервалов между двумя датами и дней недели.
Правило и критерии исчерпывающего представления даты
Наконец, третье правило гласит о том, что во всех интерфейсах и при хранении даты столетие должно определяться либо явно, либо недвусмысленными алгоритмами или правилами логического вывода.
Явное определение даты связано с представлением событий и процессов, перекрывающих 50-летний диапазон. Явное определение, то есть указание даты с четырьмя цифрами года, абсолютно необходимо при хранении информации в БД и файлах. И в действительности в базах данных Oracle и Informix даты так и реализованы. Их внутренний формат хранит столетие в явном виде. А вот, например, масса файл-серверных приложений в малых или средних организациях, которые рассчитаны на работу с файлами DBF, представляют в этом смысле известную опасность. В них дата может храниться в символьном виде, и нужно дополнительно уточнить, представлена ли она явно с четырьмя цифрами года.
Если брать банковскую и финансово-хозяйственную деятельность, то можно указать несколько редких примеров, где безусловно необходимо явное определение даты. Например, при кредитовании, где срок погашения может составлять 75 лет. С другой стороны, при указании года рождения в персоналиях явная запись должна использоваться всегда, потому что стаж работы, возраст человека и срок архивного хранения информации могут превышать 50 лет.
Явное указание даты может потребоваться для дат образования или истечения срока действия чего-либо. При этом все time stamp - метки времени (даты отчетов) могут представляться внешне в коротком формате. Поэтому нужно провести анализ и понять, достаточно ли использовать короткий формат с неявным определением столетия или все-таки нужны четыре цифры. Это позволит существенно сократить обновление программ.
В интерфейсах ввода/вывода явное определение даты необязательно, здесь нужно ориентироваться на возможность однозначной интерпретации короткого формата и требования заказчика и пользователя системы.
| Две последние цифры текущего года | Две цифры рассматриваемого года | Результат интерпретации |
| 00-49 | 00-49 | Текущее столетие |
| 50-99 | 00-49 | Следующее столетие |
| 00-49 | 50-99 | Предыдущее столетие |
| 50-99 | 50-99 | Следующее столетие |
Вторая часть правила говорит о том, что можно использовать традиционную запись (неявное определение) в виде двух последних цифр года, но при этом четко подразумевать действующий алгоритм интерпретации даты. Есть так называемые алгоритмы неявного определения столетия методом окна. Простой алгоритм фиксированного окна действует в диапазоне 1950-2049 гг. Если две цифры года имеют значения 0-49, то приписывают 19, иначе - 20. Можно рассмотреть более сложный алгоритм скользящего окна, который учитывает текущий год (см. таблицу).
Если даты, которыми манипулирует бизнес-процесс, никогда не выходят за пределы 50 лет, проблем не возникнет, то есть они всегда интерпретируются однозначно по отношению к сегодняшнему дню. Возможны алгоритмы окна для диапазона от 50 до 100 лет, но они менее тривиальны и не нашли всеобщего признания.
Для СУБД Oracle и Informix, например, уже существуют специальные форматы, которые поддерживают алгоритм неявного определения столетия. То есть достаточно будет установить соответствующий флажок или параметр - и при некоторых условиях приложение даже на потребует обновления.
Список потенциальных источников опасности этим, безусловно, не заканчивается. В одном из следующих выпусков будут рассмотрены вопросы неявного использования даты, взаимодействия с внешними системами и различные аспекты применения методик и средств тестирования.
Валерий Иванович Артемьев - начальник аналитического отдела Главного центра информатизации Банка России. Ему можно написать по адресу art@gci.cbr.ru.