Проблема 2000 года возникает в результате использования укороченного формата представления дат. Так, число 1 января 2000 г., представленное в укороченном формате ‘01/01/00’, будет ошибочно интерпретироваться как 1 января 1900 г. Данная ошибка может повлечь за собой неправильное вычисление важнейших параметров, некорректное сохранение информации, а иногда и вовсе привести к остановке программы.

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

КЛАССИФИКАЦИЯ НЕКОРРЕКТНЫХ СИТУАЦИЙ

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

Считается, что основная масса ошибок, обусловленных использованием укороченных дат, возникнет вследствие неправильного вычисления столетия, а также несогласованного обмена данными между различными программными системами. Скорее по традиции, к Проблеме 2000 года относят ошибки, связанные с неправильным распознаванием високосного года и возникающие вследствие нецелевого использования программистами специальных значений дат, таких как 99, 9/9/99, 365/99, 12/31/99 (31/12/99) или 00/00/00.

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

1. Некорректная сортировка дат.

Неправильное вычисление столетия может приводить к неверному упорядочиванию данных. Например, дата 1 января 2000 г., представленная в виде 01/01/00, будет располагаться раньше даты 31 декабря 1999 г., представленной в виде 31/12/99. В результате, банковские платежи начала января 2000 г. в общем списке будут расположены раньше платежей за декабрь 1999 г.

2. Некорректное вычисление интервалов времени.

Неправильное вычисление столетия может приводить к ошибочному определению интервала времени между двумя датами. Например, 10 ноября 2000 г. человеку, родившемуся 10 ноября 1961 г., исполнится 39 лет. Однако, в случае использования укороченных дат его возраст может оказаться отрицательным, поскольку 00-61=-61. В тех случаях, когда программа игнорирует отрицательные значения для возраста, полученное число (т.е. -61) будет интерпретироваться как «61», следствием чего станет ошибка более неявного характера.

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

3. Некорректные расчеты важнейших показателей.

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

4. Нарушение целостности данных.

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

5. Ошибки интерфейса.

Неправильное вычисление столетия может быть предопределено ограничениями, устанавливаемыми пользовательским интерфейсом. Некоторые программные системы, например LOTUS 1-2-3, изначально ориентированы на работу с датами из диапазона 1900-1999 гг. Такие системы используют только укороченный формат для представления дат, а столетию по умолчанию присваивается значение «19», которое может быть жестко «зашито» в выходных печатных документах при вводе или редактировании дат.

6. Несогласованность семантик.

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

7. Переполнение регистра.

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

8. Распознавание високосного года.

Использование некорректной формулы для распознавания високосного года также может стать причиной неправильного определения даты. Год Y является високосным, если предикат LeapYear:

function LeapYear (Y : integer) : boolean; begin LeapYear:= (Y mod 4 = 0) and (Y mod 100 <> 0) or (Y mod 400 = 0) end;

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

function LeapYear(Y : integer) : boolean; begin LeapYear:= (Y mod 4 = 0) end;

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

9. Расширение семантики дат.

Одна из широко распространенных профессиональных уловок, применяемых программистами, заключается в том, что специальные значения дат, такие как 99, 9/9/99, 365/99 или 12/31/99 (31/12/99) используются в тех случаях, когда необходимо указать, что соответствующие данные не имеют срока давности, а значение 00/00/00 – для указания неизвестной даты. По мере приближения 2000 г. использование подобных приемов может привести к неправильной интерпретации даты. Например, лицензия на программый продукт, срок которой истекает в 1999 г. (т.е. 31/12/99), может ошибочно интерпретироваться как бессрочная.

Масштаб проблемы 2000 года

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

Несмотря на то, что устаревшее аппаратное обеспечение может приводить к некорректной обработке дат, в целом Проблема 2000 года значительно шире и сложнее. Чтобы убедиться в этом, рассмотрим, где именно хранятся и обрабатываются даты на персональном компьютере и какие причины могут привести к некорректной обработке дат (см. таблицу) [2].

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

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

Перечислим объективные обстоятельства, которые еще более осложняют складывающуюся ситуацию.

1. Большое количество согласований.

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

2. Ограниченные сроки выполнения проекта.

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

3. «Наследуемые» программные системы.

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

4. Отсутствие исходного текста программы.

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

Аналогичная ситуация связана с использованием устаревших языков программирования. Так, компания IBM объявила о «кончине» языка OS/VS COBOL более 10 лет назад. Однако, по оценкам некоторых исследователей [1] около 40% магазинов в США, оснащенных большими машинами компании IBM, по-прежнему используют этот язык.

5. Отсутствие документации.

Как правило, многие программные системы, разработанные сотрудниками предприятия, плохо документируются, а иногда документация и вовсе не составляется. Ее отсутствие является существенным препятствием для эффективного решения Проблемы 2000 года.

6. Отсутствие квалифицированного персонала.

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

7. Проблема пространства.

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

8. Проблема «серого» пользователя.

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

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

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

9. Юридические проблемы.

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

Критерии решения проблемы 2000 года

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

Y2K-конверсия программной системы

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

Перечислим основные критерии, которые необходимо принимать во внимание [3].

1. Срок годности метода конверсии.

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

2. Сложность программного продукта.

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

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

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

4. Качество технического исполнения.

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

5. Стоимость осуществления конверсии.

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

6. Срок осуществления конверсии.

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

7. Объем рисков, связанных с конверсией.

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

Этапы решения проблемы 2000 года

Традиционная схема осуществления Y2K-конверсии включает пять этапов [4]:

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

Y2K-конверсию осуществляет группа специалистов, называемая Командой 2000 года. Широкий диапазон решаемых задач требует привлечения в Команду специалистов различного профиля: cистемных аналитиков, программистов, управляющих, финансистов и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЛИТЕРАТУРА 1. P. de Jager. Biting the Silver Bullet. http://www.year2000.com.

2. R.Martin. Dealing with the Year 2000. http://www.mitre.org/research/y2k.

3. GTE Corporation. Proposed Criteria for «Century Compliance». GTE Program Office, Watham, MA, 1996.

4. Th.Royer. Evaluating Systems for Year 2000 Compliance. September, 1997. http://www.mitre.org/research/y2k.

Хранение и обработка дат на персональном компьютере ЭЛЕМЕНТ ПОТЕНЦИАЛЬНЫЙ ИСТОЧНИК ПРОБЛЕМЫ 2000 г. ПРИЧИНА НЕКОРРЕКТНОГО ОПРЕДЕЛЕНИЯ ДАТЫ Аппаратный таймер Внутренние часы, питающиеся от батарейки Аппаратное обеспечение не рассчитано на обработку дат из 21 столетия Базовая система операций ввода/вывода (BIOS)

• Память компьютера, сохраняющая информацию при выключении питания (ROM/PROM/EPROM)

• Самозагружающаяся часть операционной системы

• BIOS не в состоянии интерпретировать дату из 21 столетия, поступающую от аппаратного таймера

• BIOS не передает дату операционной системе Операционная система Команды ввода/вывода и изменения даты: • имена временных файлов; • архивирование данных; • формирование и проверка паролей; • сохранение и удаление файлов

• Операционная система не в состоянии интерпретировать дату из 21 столетия, поступающую от BIOS

• Укороченный формат используется по указанию пользователя Коммерческие программные системы • СУБД • Библиотеки стандартных функций • Компиляторы • Сети

• Дата определяется посредством обращения к функциям операционной системы

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

• Дата определяется посредством обращения к функциям операционной системы

• Система не способна обрабатывать даты из 21 столетия

• В программной системе используется укороченный формат для представления дат
Y2k-конверсия программной системы