"Рекомендации по решению проблемы 2000 года в информационных системах Банка России"

РЕКОМЕНДАЦИИ

ПО РЕШЕНИЮ ПРОБЛЕМЫ 2000 ГОДА В ИНФОРМАЦИОННЫХ

СИСТЕМАХ БАНКА РОССИИ

Введение

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

Проблема возникает по двум причинам. Первой причиной является то, что многие системы хранят даты в шестизначном формате (YYMMDD, DDMMYY или MMDDYY) с представлением года только двумя цифрами, а не четырьмя. Так, дата 15 февраля 1998 года будет представлена в формате YYMMDD как 980215. А дата 15 февраля 2000 года в этом же формате будет храниться как 000215, и по умолчанию в качестве столетия ей будет приписываться значение 19. Это приводит к неразличимости столетий.

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

1) делимость на 4, но не на 100;

2) делимость на 400. Например, годы 1800 и 1900 не являются високосными, а 2000 год является.

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

Арифметические:

- вычисление длительности промежутка времени между двумя датами;

- вычисление даты, основываясь на начальной дате и длительности промежутка времени;

- вычисление дня недели, дня в году, недели в году и т.п.

Переходы:

- сравнение двух дат.

Форматы:

- преобразование даты из одного представления в другое (YYMMDD, юлианская и т.д.);

- извлечение из поля даты ее различных частей и значений.

Хранение данных:

- хранение и поиск;

- сортировка и слияние;

- использование даты в ключах и индексах дисковых файлов и таблиц баз данных;

- использование даты в именах файлов.

Расширенная семантика:

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

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

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

1. Определения соответствия 2000 году

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

Определение Британского института стандартов

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

В частности, должны соблюдаться следующие правила.

Правило 1. Никакое значение для текущей даты не должно вызвать прерывания в работе.

Это правило известно как правило общей целостности.

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

Правило 2. Функциональные возможности ИС, связанные с датой, должны вести себя одинаково для дат до, во время и после наступления 2000 года.

Это правило известно как правило целостности даты.

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

Функциональная возможность означает как процессы, так и результаты этих процессов.

Никакое оборудование или продукт не будет использовать конкретные значения даты для особых обозначений (например, "99" - для обозначения "нет конечного значения" или "конец файла", "00" - для обозначения "неприменимо" или "начало файла").

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

Это правило называется иногда правилом явного / неявного столетия.

Оно включает два подхода:

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

- использование правил вывода (например, двузначный год со значением, большим 50, предполагает 19xx, а год со значением, меньшим или равным 50, предполагает 20xx).

Правило 4. 2000 год должен распознаваться как високосный.

Определение штата Миннесота (США)

Соответствие 2000 году означает, что:

- структуры даты обеспечивают распознавание столетия четырехзначной даты;

- хранимые данные содержат распознавание столетия даты;

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

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

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

Определение штата Орегон (США)

Соответствие 2000 году определяют следующие стандарты.

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

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

Никакое значение для текущей даты не вызовет прерывания в работе.

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

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

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

Определение Университета Флориды (США)

Каждый компонент информационной системы должен удовлетворять следующим минимальным стандартам.

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

Все манипуляции или сравнения связанных с датой данных должны давать желаемые результаты для всех допустимых значений даты в приложении.

Не должно быть двусмысленности столетия. Неявное столетие может использоваться только там, где все операции с датой и ее отображение могут выполняться без двусмысленности. Во всех других случаях в элементе даты должно храниться явное столетие. Даты с явным столетием должны храниться в 8 смежных байтах в формате YYYYMMDD стандарта ISO. Даты должны отображаться в обычном американском формате MM - DD - YYYY.

Где минимальная и / или максимальная дата требуется для целей редактирования или отображения, стандартное значение 01-01-1900 (хранимое как 19000101) должно использоваться как минимум, а 12-31-9999 (хранимое как 99991231) должно использоваться как максимум.

2000 год должен распознаваться как високосный.

Определение компании Year2000 Ltd (Новая Зеландия)

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

Все поля даты, хранимые в электронном виде в системах, эксплуатируемых нами, должны содержаться в виде 8 цифр в формате YYYYMMDD стандарта ISO-8601. Это относится ко всем системам, работающим в нашей компании, независимо от того, разработаны они нами или являются пакетами, поставленными нам внешними поставщиками / производителями программного обеспечения.

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

Все поля даты, передаваемые нами третьим сторонам, будут также в полном 8-значном формате ISO-8601.

В любых печатных отчетах из этих систем будут печататься 4-значные годы; 2-значные годы будут печататься только в тех случаях, где по контексту предполагаемое значение столетия не вызывает сомнений.

Любой ввод дат человеком через экраны и т.д. должен быть недвусмысленным. Так, ввод 2-значного года является приемлемым тогда и только тогда, когда контекст приложения делает предположение о столетии полностью очевидным. Любые такие даты должны храниться в полном 8-значном стандарте ISO. Во всех случаях, если этому не препятствуют проблемы размещения, ввод 2-значного года будет сопровождаться отображением интерпретируемого 4-значного года. На случай пожелания оператора изменить столетие должна быть предусмотрена возможность вводить 4-значный год.

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

Никакое значение для сегодняшней даты не вызовет какого-либо прерывания в нашей работе.

Любая обработка, включающая даты, будет вести себя одинаково и в соответствии с ожиданиями до, во время и после наступления 2000 года.

2000 год распознается как високосный.

2. Организация работ

Работы по решению проблемы 2000 года в информационных системах ЦБ РФ следует разделить на пять перекрывающих друг друга этапов.

1. Осведомленность (июнь - июль 1998 года):

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

- определить потенциальное влияние проблемы 2000 года;

- провести мероприятия по осведомлению о проблеме 2000 года;

- разработать стратегию 2000 года;

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

2. Оценивание (июль - ноябрь 1998 года):

- определить соответствие 2000 году;

- оценить серьезность влияния отказов, связанных с 2000 годом;

- провести инвентаризацию информационных систем;

- установить приоритеты систем и компонентов для преобразования или замены;

- определить необходимые ресурсы, установить их приоритеты;

- разработать стратегии проверки, планы тестирования и сценарии;

- определить и приобрести инструментальные средства 2000 года;

- рассмотреть график внедрения ИС;

- рассмотреть вопросы интерфейсов и обмена данными;

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

3. Обновление (октябрь 1998 года - май 1999 года):

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

- разработать мосты и фильтры данных;

- заменить выбранные приложения и соответствующие системные компоненты;

- задокументировать изменения в программном коде и системах;

- спланировать автономное, интеграционное и системное тестирование;

- списать выбранные приложения и соответствующие системные компоненты;

- сообщить об изменениях в информационных системах внутренним и внешним пользователям.

4. Проверка (январь - сентябрь 1999 года):

- разработать планы и графики тестирования ИС;

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

- выполнить автономное, интеграционное и системное тестирование;

- начать приемо - сдаточные испытания.

5. Внедрение (июнь - ноябрь 1999 года):

- определить среду и процедуры перехода;

- разработать график внедрения;

- решить вопросы обмена данными и межведомственные проблемы;

- выполнить преобразование баз данных и архива;

- завершить приемо - сдаточные испытания;

- обновить или разработать планы восстановления после катастроф;

- внедрить преобразованные или замененные системы.

В связи с централизованными поставками в подразделения и учреждения ЦБ РФ технических и программных средств и наличием у них собственных разработок следует обеспечить соответствующее распределение работ с целью минимизации их дублирования.

Для ускорения обмена информацией по проблеме 2000 года необходимо использовать разнообразные средства связи ("горячие" телефонные линии, факсимильное оборудование, электронную почту, сайты Internet и т.п.).

3. Варианты преобразования

3.1. Обновление

Назначение данного раздела - очертить преимущества и недостатки каждого приема и помочь организаторам проектов в определении самой лучшей стратегии обновления.

Обновление является процессом, с помощью которого в проекте 2000 года решаются проблемы структуры даты. Существует в основном четыре типа приемов обновления: расширение, работа с окнами, кодирование или сжатие и последовательная дата (serial date).

Проблемы

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

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

- Приложения разбиваются на обновляемые модули. Неиспользуемый исходный текст ("мертвый" код) не обновляется.

Приемы

Внутри приложения наилучшие результаты может дать один прием или их комбинация.

- Приемы расширения:

- Приемы работы с окнами:

- Приемы кодирования или сжатия.

- Прием последовательной даты.

Приемы расширения

Когда следует использовать приемы расширения

Когда даты переходят границу 100-летнего окна и столетие не может быть получено недвусмысленно (например, в дате рождения).

Для элемента даты, который является частью ключа или индекса.

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

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

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

Когда технологией является база данных, контролируемая системой управления базами данных (СУБД); структуры таблицы / записи изменяются однажды, а ссылка на них содержится в многочисленных приложениях.

Когда следует избегать приемов расширения

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

Когда имеется ограниченное устройство хранения прямого доступа (DASD) / дополнительная память, чтобы сохранить столетия.

Когда приложение имеет короткий жизненный цикл и расширение поля является дорогостоящей альтернативой.

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

Четырехзначный формат

Преимущества

Обеспечивает четырехзначный формат года; рассматривается как полное, постоянное и очевидное решение.

Использует формат ISO (YYYY - MM - DD) по умолчанию.

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

Недостатки

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

Смежные поля в макете поля даты переопределяются, и размеры записей увеличиваются.

Требуется увеличение используемой DASD / памяти.

Односимвольный код столетия

Внешний код столетия

Преимущества

Формат базы данных может быть преобразован, а программы модифицированы позже.

Обеспечивает простое решение для преобразования данных в новый формат.

Недостатки

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

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

Размеры записей должны увеличиться.

Требуется увеличение используемой DASD / памяти.

Встроенный код столетия

Преимущества

Сохраняется правильное упорядочение данных.

Не требуется дополнительного дискового пространства.

Недостатки

Данные года должны быть преобразованы из двузначного в трехзначный формат.

Требуется преобразование данных формата YY в формат CYY.

Приемы работы с окнами

Когда следует использовать прием окон

Когда расширение поля будет слишком дорогостоящим, если даты, как ожидается, останутся в пределах 100-летнего периода.

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

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

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

Когда не следует использовать прием окон

При обработке дат со значениями, выходящими за пределы 100-летнего периода.

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

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

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

Фиксированное окно и скользящее окно

Преимущества

Нет необходимости расширять формат года с двузначного до четырехзначного.

Обеспечивает формат года с четырьмя знаками для обращения к данным.

Различает годы разных столетий, используя двузначный формат (исходя из предположения, что обрабатываемые годы находятся в 100-летнем диапазоне).

Полезно в том случае, если отдельная программа выводится из использования поэтапно; временное решение.

Недостатки

Потенциальные риски существуют, когда / если функционирование программного приложения требует обрабатывать годы вне 100-летнего диапазона.

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

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

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

Приемы кодирования или сжатия

Преимущества

Нет необходимости преобразовывать год из двузначного в четырехзначный формат данных.

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

Юлианский формат с флагом (CYYDDD) использует С как признак столетия.

Недостатки

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

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

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

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

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

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

Прием последовательной даты

Преимущества

Во многих случаях форматы записи не должны изменяться.

Недостатки

Он сложен; должен быть хорошо задокументирован.

Может влиять на производительность при преобразовании дат из последовательного значения или в него.

3.2. Списание (отказ от использования)

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

Проблемы

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

Архивирование данных и приложения для будущего обращения.

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

Рекомендуемый подход

Определите деловое значение приложения на этапе оценивания проекта 2000 года.

Следующие условия должны быть выполнены, чтобы списать приложение:

- приложение не обслуживает никакую текущую деловую функцию;

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

- слишком дорого преобразовывать приложение в соответствующее 2000 году;

- приложение не будет использоваться в будущем.

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

Если списание приложений производится поэтапно, то готовится план поэтапного вывода приложений из использования.

Советы

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

3.3. Замена

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

Техническое обеспечение, программное обеспечение и / или программно - аппаратное обеспечение могут не соответствовать 2000 году и, следовательно, могут потребовать замены. Замена включает покупку пакетного решения или разработку нового решения, основанного на проекте существующей системы. Если не соответствующие 2000 году техническое обеспечение, программное обеспечение и / или программно - аппаратное обеспечение, выбранные для замены, не будут заменены до критических сроков 2000 года, то должен существовать план чрезвычайных обстоятельств.

Проблемы

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

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

Обучение новой системе потребует времени и ресурсов; они могут быть ограничены.

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

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

Разработанные по заказу приложения могут иметь неадекватные программы обработки даты. Изменение или обновление исходного кода может быть дорогостоящим и требующим много времени.

Пакеты программ должны быть заменены соответствующими 2000 году версиями (upgrades) или другими продуктами.

Во время преобразования данные могут быть потеряны из-за модификации полей.

Могут потребоваться новые инструментальные средства для штата программистов, включая:

- системы анализа влияния;

- инструментальные средства управления изменениями или контроля версий;

- утилиты быстрого изменения и замены;

- инструментальные средства тестирования.

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

Зависимость от интерфейсов создает сложности при интегрировании новой системы в существующую среду.

Рекомендуемый подход

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

Преимущества

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

Добавление долгосрочной гибкости.

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

Недостатки

Это рискованный метод, учитывая короткое время для реализации.

Новая система требует дополнительных ресурсов.

Не все новые покупные программы соответствуют 2000 году.

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

"ДЕЛАТЬ", если:

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

- пакетные системы плохо интегрируются в финансовые системы;

- пакетные системы не являются гибкими и / или сбалансированными для роста;

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

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

- пакетные системы не отвечают всем требованиям пользователей.

"ПОКУПАТЬ", если:

- затраты на то, чтобы "сделать", больше затрат на то, чтобы "купить";

- требуются стандартные методы обработки, такие, как стандартные финансовые действия, стандартные подпрограммы закупки и т.д.;

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

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

Разработайте и выполните план преобразования. Он должен основываться на критичности систем, сроках отказа и приоритетах.

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

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

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

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

Советы

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

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

Используйте следующий контрольный список при выборе пакета прикладных программ:

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

- гибкость - легко модифицировать или настраивать;

- дружелюбие по отношению к пользователю - прост в использовании и обеспечивает управление;

- аппаратные и программные ресурсы - способен поддерживать существующие ресурсы;

- характеристики базы данных - поддерживает текущие требования обработки и поиска;

- установка - процесс не требует много усилий и времени;

- сопровождение - поставщик предоставляет продолжающееся сопровождение и поддержку;

- документация - ясная и полная;

- качество поставщика - приложение разработано опытными разработчиками;

- затраты - учесть любые дополнительные затраты (плата за сопровождение, расширение возможностей, модернизация и т.д.);

- соответствие 2000 году - продукт уже соответствует 2000 году.

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

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

3.4. Поддержание соответствия 2000 году

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

Проблемы

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

Порча соответствующих 2000 году систем путем введения систем, которые не соответствуют 2000 году.

Трудности с разработкой и соблюдением во всех учреждениях стандартов соответствия 2000 году.

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

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

Обеспечение того, чтобы рутинное сопровождение не вносило новых проблем 2000 года.

Рекомендуемый подход

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

- проверка соответствия поставщика перед подписанием заказов на покупку;

- доведение до сведения поставщика требований о необходимости абсолютного соответствия продукта;

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

- использование соответствующих положений во всех договорах.

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

Должен выполняться сквозной просмотр кода, который проверяет соблюдение стандартов разработки.

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

Документируйте изменения, производимые в среде.

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

Советы

Установите стандарты учреждения по проекту 2000 года относительно типов данных даты / времени во всех системах. Эти стандарты должны соблюдать все пользователи.

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

Учреждения должны учесть следующее:

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

- разработка новых систем должна следовать стандарту учреждения;

- должен вестись точный постоянный учет всех систем до 1 января 2000 года и далее;

- необходимо проверять соответствие 2000 году любой системы, вводимой в среду.

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

4. Проектирование

4.1. Управление проектом

Управление проектом - приложение знаний, умений, инструментальных средств и методик для планирования действий, чтобы удовлетворить потребности и ожидания проектировщиков или превысить их. Соответствие потребностям и ожиданиям или их превышение включает уравновешивание конкурирующих требований (таких, как охват, время, затраты и качество), объектов с различными потребностями и ожиданиями, а также определенных потребностей и неопределенных ожиданий.

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

Проблемы

Опытные программисты могут быть недоступны.

Документация для существующих систем может быть недоступна.

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

Предположения

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

Будут проведены исследования инструментальных средств всех платформ.

Больше времени будет отведено на замену, чем на обновление, если это будет оправданно.

Устаревшие программы не будут обновляться.

Будет уделено внимание основным проблемам библиотеки программ.

Рекомендуемый подход

Полная опись системы должна быть подготовлена на этапе оценивания (может потребоваться ее обновление).

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

Определите опись для обновления.

Определите сложности обновления.

Установите приоритеты обновляемых приложений, основываясь на их критичности.

Разработайте процессы преобразования.

Определите инструментальные средства и приемы, которые будут использоваться.

Определите необходимость обучения для процессов и инструментальных средств.

Сгруппируйте и определите последовательность реализации модулей и отметьте зависимости.

Оцените время для каждого модуля.

Разработайте план ресурсов этапа преобразования, включая требуемую квалификацию.

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

Обзор процесса управления проектом

Организация проекта

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

План работ проекта

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

Управление изменениями проекта

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

Обеспечение качества систем

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

Контроль за изменениями исходных кодов

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

Рабочие документы

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

План работ проекта

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

Проблемы / решения

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

Состояние проекта

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

План чрезвычайных обстоятельств

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

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

- проверьте каждый модуль тщательно, насколько возможно;

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

В случае отказа

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

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

Советы

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

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

4.2. Файлы и базы данных

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

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

Проблемы

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

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

Документация существующих систем и подсистем может быть недоступна.

Рекомендуемый подход

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

Файлы

Категории файлов могут включать следующее, но не ограничиваться им:

- ссылки на поле;

- физический, логический и коммуникационный;

- программный;

- дисплейный;

- принтерный.

Базы данных

Примеры объектов базы данных:

- таблицы;

- запросы;

- формы;

- отчеты;

- функции;

- хранимые процедуры;

- триггеры базы данных;

- представления.

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

- схема данных;

- макеты файлов;

- программы (например, коды доступа, процедуры, функции, триггеры и т.д.);

- CopyLib.

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

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

Сильное влияние

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

Представление года двумя цифрами, имеющее внутренние появления.

Связанные с датой данные и переменные имеют ссылки, вычисляются, сравниваются, сортируются, вводятся и выводятся.

Слабое влияние

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

Представление года двумя цифрами внутри приложения не имеет внутренних или внешних появлений.

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

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

4.3. Интерфейсы

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

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

Проблемы

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

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

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

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

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

Некоторые интерфейсы могут быть не учтены или пропущены.

Типы интерфейсов

Интерфейсы могут содержать:

- прикладные интерфейсы,

- EDI (стандарт электронного обмена данными),

- Internet,

- электронную почту,

- распространение лент, дисков и т.д.,

- ручной ввод,

- FTP (протокол передачи файлов).

Рекомендуемый подход

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

платформу,

систему,

имена наборов данных / файлов,

описание,

отправку или прием,

тип носителя,

предлагаемый формат,

плановую дату соответствия,

действительную дату соответствия,

внутренний контакт и телефон,

описание внешней организации,

внешний контакт и телефон,

частоту,

текущий формат,

примечания.

Интерфейсы должны быть включены в планы оценивания, обновления и тестирования проекта 2000 года. Все интерфейсы должны быть протестированы на соответствие 2000 году.

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

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

Советы

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

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

Интерфейсы, которые должны быть протестированы:

- информация от системы к учреждению;

- информация в систему из учреждения;

- интерфейсы с деловыми партнерами;

- интерфейсы с внешними поставщиками услуг.

4.4. Мосты

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

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

Проблемы

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

Программы - мосты увеличивают нагрузку на систему.

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

Уровни обработки трансакций большого объема могут подвергаться влиянию обращений ввода / вывода к программе - мосту.

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

Рекомендуемый подход

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

Создайте план обновления, основанный на приоритетности и критичности.

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

Определите метод создания мостов. Имеется четыре типа мостов: разработанные на заказ, пакетные, он - лайновые и изменение программы.

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

Установите мост. Мосты должны оставаться в производстве, пока не будут заменены или обновлены внутренним или внешним образом все взаимосвязанные приложения.

Советы

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

Мосты должны иметь значимые имена. Это поможет в отслеживании мостов и упростит процесс их удаления.

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

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

Мост должен:

- быть динамическим; требовать минимального количества логики ввода / вывода;

- удовлетворять требованиям производительности; минимизировать внешние и внутренние обращения;

- поддерживать достаточную целостность данных;

- содержать достаточно много проверок;

- основываться на спецификациях преобразования, выработанных в процессе модификации.

4.5. Функции даты

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

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

Проблемы

До проектирования или приобретения функции даты должны рассматриваться следующие проблемы.

Эффекты инверсии вызываются программами, которые интерпретируют "00" скорее как "1900", чем "2000", и по ошибке выполнят вычисления, скорее, на 99 лет в прошлое, чем на 1 год в будущее.

Нестандартная логика включает следующее:

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

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

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

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

Прочие проблемы

- Когда дата является частью ключа, существует риск, что даты со значениями года "00" будут отыскиваться перед датами со значениями года "99", хотя "2000" идет после "1900".

- Даты и логика даты могут находиться в макрокомандах, Wylbur Execs, CMS Execs, Rexx Execs, запросах, отчетах, триггерах, процедурах, функциях и т.д.

- Даты, которые встроены в имена наборов данных или внутри структур данных.

Логика високосного года состоит из трех правил високосного года, как определено в 1582 году римским папой Григорием XIII:

- если год делится без остатка на 4, то он является високосным;

- если год делится без остатка на 100, то он не является високосным;

- если год делится без остатка на 400, то он является високосным.

Год 2000-й - високосный год.

Рекомендуемый подход

Установите стандарт для нотации даты.

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

- имитаторы системной даты;

- анализаторы кода;

- дополнительная функция даты;

- улучшения (upgrades) языка;

- преобразователи (конверторы) баз данных.

Советы

Рекомендуемым стандартом даты является нотация даты стандарта ISO 8601. Международной стандартной нотацией даты является YYYY - MM - DD.

Преимущества нотации даты стандарта ISO 8601 по сравнению с другими обычно используемыми вариантами:

- легко читается и записывается программным обеспечением;

- легко сравнивается и сортируется с помощью обычного сравнения строк;

- не зависит от языка;

- не может быть спутана с другими популярными нотациями даты;

- короткая и имеет постоянную длину;

- представление года четырьмя цифрами позволяет избежать проблем переполнения после 1999-12-31.

4.6. Архивные данные

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

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

Проблемы

Архивные данные могут не включаться в проект 2000 года.

Архивные данные содержат обычно двузначный формат года, что может повредить соответствующим 2000 году системам.

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

Рекомендуемый подход

Рассмотрите график сохранения записей.

Определите все файлы архивных данных, которые должны вестись.

Определите, содержат ли эти файлы даты и в каком формате эти даты хранятся.

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

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

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

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

Ничего не делайте, если 2000 год не влияет на процесс поиска данных.

4.7. Управление изменениями

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

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

Проблемы

Контроль изменений исходных кодов, производимых вне проекта 2000 года.

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

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

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

Обновленные приложения сбоят после развертывания или являются причиной сбоев зависимых приложений.

Возможное влияние на план внедрения.

Изменения могут увеличить затраты. Финансирование затрат на изменение может быть ограниченным и доступным только в определенные промежутки времени.

Рекомендуемый подход

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

Осознание изменения

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

Представление заявки на изменение

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

- план обновления;

- размер изменения;

- вопросы регрессионного тестирования.

Оценивание разработчиками

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

Оценивание управления изменениями

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

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

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

- убедиться, что все необходимые внешние утверждения были получены;

- предпринять соответствующее действие утверждения, основанное на этих проверках.

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

В случае утверждения изменения производятся модификация, тестирование и внедрение, а в противном случае оформляется отклонение заявки на изменение.

Отклонение заявки на изменение

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

Модификация

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

Тестирование

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

Внедрение

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

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

Советы

Механизм управления изменениями должен обеспечивать следующее:

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

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

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

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

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

Используйте самую высокую степень экономически эффективной автоматизации. Автоматизированные инструментальные средства управления изменениями облегчают этот процесс.

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

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

- участие руководства;

- управление проектом;

- контроль исходного кода;

- механизмы тестирования / разработки;

- доставка объектов;

- управление готовностью;

- координация / планирование эксплуатации;

- отслеживание проблем;

- исторический анализ;

- распределенные и интегрированные пакеты управления изменениями;

- объектно - ориентированные пакеты управления изменениями.

4.8. Соглашения по именованию

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

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

Проблемы

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

Во время разработки никакие соглашения по именованию не использовались или использовались неоднородные соглашения.

Аббревиатуры имен или усеченные имена данных использовались без официальных стандартов.

Имена данных не указывают на использование данных; данные те же самые, а имена различные.

Использовались омонимы или синонимы.

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

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

Рекомендуемый подход

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

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

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

- Используемые Copybooks, JCL и общие программы могут существовать как в обновленном, так и в необновленном виде. Необходимо или переименовать эти объекты, или разработать альтернативные библиотеки и компилировать процедуры.

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

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

Логическая модель

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

Физическая модель

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

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

Автоматизированное обновление

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

Ручное обновление

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

Советы

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

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

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

4.9. Планирование для чрезвычайных обстоятельств

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

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

Проблемы

Критические приложения могут быть не приведены в соответствие 2000 году вовремя.

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

Могут потребоваться дополнительные ресурсы и утверждение финансирования.

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

Программно - аппаратное обеспечение (то есть лифты, системы безопасности, телефонные системы, кондиционирование воздуха, отопление и т.д.) могут отказать или функционировать неправильно.

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

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

Рекомендуемый подход

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

Еще раз проверьте приоритеты критических систем.

Оцените состояние текущих планов чрезвычайных обстоятельств:

- задокументированы ли планы, актуальны ли и содержат ли даты запуска;

- был ли персонал обучен процессам;

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

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

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

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

Определите, какие операции, продукты и услуги могут быть прерваны и на какое время.

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

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

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

Тщательно проверяйте все планы перед их реализацией.

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

Советы

Планы чрезвычайных обстоятельств должны разрабатываться заблаговременно.

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

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

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

- критерии для задействования плана (например, несоблюдение сроков обновления, достижение даты прогнозируемого отказа, связанного с 2000 годом, серьезные системные сбои и т.д.);

- ожидаемый период жизни плана (как долго можно продолжать работать в аварийном режиме);

- роли и обязанности;

- процедуры для перехода на аварийный режим;

- процедуры для работы в аварийном режиме;

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

- критерии для возврата в режим нормальной работы;

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

- процедуры для восстановления утраченных или искаженных данных.

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

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

5. Обеспечение качества

5.1. Тестирование

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

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

Проблемы

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

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

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

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

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

Рекомендуемый подход

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

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

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

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

Установите приоритеты тестов, ориентируясь на критические приложения и функциональные возможности. Применяйте правила 80 / 20, которые раскроют 80 процентов проблем, сосредоточиваясь на 20 процентах тестирования.

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

Выполняйте регрессионное тестирование; тесты, выполненные ранее, должны выполняться повторно, когда в приложение вносится изменение. По мере решения проблем может потребоваться повторение тестов.

Приемы тестирования

Тестирование 2000 года может выполняться в следующие четыре этапа.

Таблица 1. Тестирование 2000 года

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

Автономное тестирование 2000 года

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

Назначение автономного тестирования состоит в том, чтобы:

- выполнялось адекватное покрытие операторов, условий, решений и путей;

- обеспечивалась динамическая проверка спецификаций;

- реализация на уровне модуля была свободна от недостатков;

- процедуры восстановления при ошибках работали правильно на уровне модуля;

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

- проверялось успешное выполнение всех новых, измененных или зависимых путей;

- велся протокол выполненных тестовых случаев модуля;

- решались проблемы и осуществлялось повторное тестирование;

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

- по мере необходимости корректировалась документация тестов.

Интеграционное тестирование 2000 года

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

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

Цели интеграционного тестирования:

- выполнить новые, измененные и зависимые функции приложения и проверить, являются ли они приемлемыми в эксплуатационном отношении и соответствуют ли внутреннему проекту;

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

- проверить выполнение всех случаев интеграционного теста по плану интеграционного тестирования;

- если обнаружены проблемы, исправить модуль и повторно проверить его в среде автономного тестирования;

- выполнить регрессионные тесты в интегрированной среде;

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

- при необходимости скорректировать документацию.

Системное тестирование 2000 года

Проверяет, соответствует ли 2000 году все программное приложение.

Цели системного тестирования:

- проверить все программное приложение как полную систему в целевой среде;

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

- проверить успешное выполнение всех случаев системного теста согласно плану системного тестирования;

- если обнаружены проблемы, исправить модуль и повторно проверить его в среде автономного и интеграционного тестирования;

- выполнить регрессионные тесты в системной среде;

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

- при необходимости скорректировать документацию.

Приемо - сдаточное тестирование 2000 года

Проверяет, соответствует ли система 2000 году и готова ли она для производства.

Цели приемо - сдаточного тестирования:

- гарантировать, что система соответствует 2000 году и готова для производства;

- проверить, что система удовлетворяет критериям приемки пользователя;

- продемонстрировать интерфейс пользователя в обстановке, имитирующей производственную среду;

- создать у пользователей уверенность в том, что система работает правильно и управляема ими;

- проверить систему с реальными данными;

- подтвердить корректность и применимость документации пользователя;

- разработать план приемо - сдаточного тестирования;

- создать сценарии тестирования, основанные на типах, перечисленных ранее;

- выполнить сценарии тестирования;

- при необходимости разработать отчеты о проблемах тестирования;

- принять полностью проверенную систему.

Советы

Тестирование соответствия 2000 году включает следующие три основных этапа.

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

Выполнение тестов, основанных на стратегии соответствия 2000 году, используемой для обновления приложения:

- прием расширения;

- прием работы с окнами;

- прием кодирования или сжатия:

- прием последовательной даты.

Конфигурирование отдельной системы с готовой к 2000 году версией приложения и выполнение общего теста с преобразованным загруженным кодом приложения и системной датой со значением после 2000 года.

Основные сценарии тестирования

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

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

Тестирование неправильного истечения срока. Тест для проверки того, что сроки полисов, дел, записей, файлов и т.д. не будут автоматически истекать на:

-1999-09-09;

-1999-12-31;

- 2000-01-01 (некоторые сроки кодируются как 99-99-99).

Тестирование дней недели (если необходимо):

- 2000-01-01 - суббота (не понедельник, как было 1900-01-01);

- 2000-01-03 - понедельник.

Другие интересные даты для включения (при необходимости): 1997, 1998, 1999, 2000, 2001, 2006, 2000-01-01, 2000-01-31, 1899-12-31 и 1999-12-31.

Тестирование старения. Если система вычисляет любой вид старения (например, 30 дней сверх положенного срока, 45 дней сверх положенного срока и т.д.), определите эти периоды старения - и получите правильные календарные даты для проверки.

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

Тестирование високосного года. Удостоверьтесь, что в тестирование високосного года включены следующие даты:

- високосный год - 1996-02-28 и 1996-02-29;

- невисокосный год - 1999-02-29 (должен отклоняться);

- високосный год - 2000-02-28, 2000-02-29, 2000-03-01;

- невисокосный год - 2001-02-29 (должен отклоняться).

5.2. Процесс проверки персональных компьютеров

Связанные с 2000 годом вопросы технического обеспечения персональных компьютеров включают проблему перехода, которая возникает, когда компьютер не может определить правильную дату при переходе даты с 31 декабря 1999 года на 1 января 2000 года. Для отслеживания текущей даты и времени в персональных компьютерах используется аппаратный таймер с резервной батареей, называемый "часами реального времени" (RTC). В соответствии с первоначальными спецификациями стандартный таймер был спроектирован для хранения только последних двух цифр года.

Для преодоления этого ограничения информация столетия программировалась в памяти операционной системы компьютера как "19". Когда ПЭВМ включается, BIOS соединяет информацию столетия с информацией года из RTC для получения четырехзначного года. К сожалению, когда таймер переходит от 23.59 31 декабря 1999 года к 00.00 1 января 2000 года, информация десятилетий ("99") перерастает в "00", но информация столетия остается "19".

Предупреждение

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

Единственной причиной для выполнения сценария готовности к 2000 году персонального компьютера и рабочей станции вне крупного проекта тестирования является подтверждение результатов улучшения (upgrade) BIOS. Сценарии готовности к 2000 году рекомендуются для тестирования только тех ПЭВМ, которые не планируется заменить до 2000 года. В целях тестирования соответствия 2000 году ПЭВМ разделяются на две категории: автономные и сетевые.

Автономный персональный компьютер - любой микрокомпьютер, работающий под управлением DOS / Windows, который обычно используется одним человеком изолированно.

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

Замечание. Дата / время сетевого персонального компьютера синхронизируется с датой / временем сервера сети при входной регистрации пользователя. Таким образом, когда сервер сети соответствует 2000 году, то он автоматически установит время для сетевого персонального компьютера, если сетевой персональный компьютер соответствует 2000 году. Чтобы проверить, соответствует ли 2000 году сетевой персональный компьютер, он должен быть временно преобразован в автономный персональный компьютер. Эта процедура должна быть выполнена до осуществления сценария тестирования соответствия персонального компьютера 2000 году.

Проблемы

Допущение, что персональные компьютеры будут заменены до 2000 года.

Допущение, что недавно замененные персональные компьютеры соответствуют 2000 году.

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

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

Предосторожности до проверки

Преобразуйте сетевой персональный компьютер в автономный персональный компьютер.

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

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

Избегайте "загрязнения" производственных систем и баз данных при выполнении разнообразных сценариев тестирования.

Не производите установки или тестирования с экрана установки BIOS, они выполняются только из DOS или Windows.

Рекомендуемый подход

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

Таблица 2. Перечень ПЭВМ

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

Таблица 3. План обновления персональных компьютеров

Не выполняйте этот тест на персональных компьютерах, подключенных к сети. Примите необходимые предосторожности для перевода системы в автономное состояние до проверки ПЭВМ.

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

Таблица 4. Сценарий готовности

к 2000 году для персонального компьютера

Таблица 5. Сценарий готовности

к 2000 году для рабочей станции

Процедуры обновления для превращения ПЭВМ

в соответствующую 2000 году

Эта процедура применяется к ПЭВМ, которые не выдержали одного или более из ранее приведенных тестов:

- тест, могут ли часы системы устанавливаться после 2000 года (таблица 5, шаг 4);

- тест функции автоматической корректировки системных часов (таблица 4, шаг 4);

- тест високосного года (таблица 4, шаг 5).

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

Если поставщик имеет программное улучшение BIOS для конкретной модели ПЭВМ, то получите его из одного из общих источников, таких, как сайт поставщика в Internet или сайт FTP, и выполните инструкции по установке.

Если программное улучшение BIOS недоступно, рассмотрите следующие варианты.

- Приобретите у третьей стороны резидентную программу, которая устраняет ошибку перехода от 1999-го к 2000 году часов реального времени (RTC) CMOS.

- Устанавливайте часы ПЭВМ вручную. Разработайте пошаговые инструкции и обучите этим процедурам соответствующий персонал.

- Подключите ПЭВМ к сети, синхронизируя таким образом дату / время ПЭВМ с датой / временем сервера сети. Убедитесь, что система будет хранить скорректированные дату / время.

Замечание. Использование второго и третьего вариантов зависит от способности ПЭВМ обрабатывать даты XXI столетия. Предполагается, что сервер соответствует 2000 году и будет в рабочем состоянии 1 января 2000 года.

Советы

Причины, чтобы не выполнять сценарии готовности к 2000 году для персонального компьютера и для рабочей станции на каждой ПЭВМ, могут быть следующими:

- нужно много времени: 15 - 30 минут на одну ПЭВМ;

- возможное прерывание работы;

- могут существенно увеличиться затраты проекта. Более эффективно положиться на поставщика и проверять каждую подозрительную ПЭВМ 1 января 2000 года или позднее;

- вместо тестирования ПЭВМ до 2000 года пользователи могут проверить дату на любой ПЭВМ при ее первом включении в новом году.

5.3. Процесс проверки систем

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

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

Предупреждение

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

Таблица 6. Потенциальные проблемы

установки будущих дат системы

Рекомендуемый подход

Определите и задокументируйте все тестовые данные.

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

Создайте тестовые случаи, специально предназначенные для проверки функций даты, таких как:

- исторические даты;

- настоящие даты;

- будущие даты;

- периоды времени;

- расчетные даты.

Исключите тестовые случаи, не связанные с датами; это уменьшит объем тестовых данных.

Установите средства сбора и воспроизведения данных в режиме он - лайн.

Стратегия проверки

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

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

Сравните этот вывод с базой, чтобы проверить, что результаты эквивалентны и точны.

Когда результаты проверены, система готова для производства.

Советы

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

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

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

При тестировании рабочей станции сначала убедитесь, что система отключена от всех серверов файлов.

При тестировании сервера файлов сначала убедитесь, что отключены все рабочие станции и другие серверы файлов.

Для подтверждения правильности обработки будущих дат протестируйте следующие серверы:

- серверы печати;

- серверы факсов;

- серверы файлов;

- серверы баз данных;

- серверы связи;

- серверы Internet / Intranet / Web.

Выполните тестирование 2000 года как тестирование восстановления после катастроф:

- зарезервируйте все серверы;

- зарезервируйте все подключенные рабочие станции;

- восстановите на аналогичные серверы;

- восстановите на аналогичные рабочие станции;

- перенаправьте / подключите все рабочие станции и терминалы на восстановленные серверы;

- проверьте правильность восстановления серверов и рабочих станций;

- выполните тестирование 2000 года рабочих станций и серверов.

Все критические приложения должны быть проверены на соответствие 2000 году.

6. Инструментальные средства

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

Продукты для инвентаризации

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

Продукты для сканирования / синтаксического анализа

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

Автоматические преобразователи кода

Являются интеллектуальными продуктами, основанными на правилах.

Календарные подпрограммы

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

Преобразователи (конверторы) файлов

Расширяют записи данных или язык описания данных (DDL) базы данных автоматически и выполняют разгрузку / перезагрузку.

Имитаторы даты

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

Компараторы файлов / администраторы версий

Сравнивают файлы и показывают различия.

Инструментальные средства написания сценариев

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

Инструментальные средства переноса (migration)

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

Инструментальные средства реинжиниринга

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

Автоматизированные рабочие места

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

Прочие инструментальные средства

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

Выбор инструментальных средств

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

- сглаживает переход между группами разработки / сопровождения и эксплуатацией;

- упрощает инициализацию изменения, заранее убирая бюрократические препятствия;

- гарантирует, что никакая часть не теряется и что все части защищены;

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

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

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

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

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

- является достаточно гибким, чтобы обрабатывать сложные типы компонентов, такие как CASE - технология, связи DB2, DDL, CICS, IMS и MFS;

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

7. Программно - аппаратное обеспечение

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

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

Проблемы

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

Сопровождение программно - аппаратного обеспечения может не охватываться гарантией или срок гарантии может истечь до 31 декабря 1999 года.

Большая часть программно - аппаратного обеспечения была написана на ассемблере по причинам производительности и объема.

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

Операции с годом часто встроены в микрокод на основе программно - аппаратного обеспечения.

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

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

Факсы и принтеры могут использовать штампы времени в верхней или нижней части листа.

Может быть отказано во входе в здания вследствие несоответствия 2000 году системы безопасности.

Регистрирующие устройства могут иметь неправильные форматы даты.

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

Рекомендуемый подход

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

- Телефоны.

- Факсимильные машины.

- Регистрирующие устройства.

- Сейфы.

- Модемы.

- Системы среды.

- Видеомагнитофоны.

- Видеокамеры.

- Системы голосовой почты.

- Принтеры.

- Лифты.

- Оборудование для телеконференций.

- Пейджеры.

- Часы.

- Сканирующие устройства.

- Автоматизированная сигнализация (системы пожарной тревоги).

- Оборудование управления и слежения за процессами. Сетевое оборудование.

- Копировальное оборудование.

- Программируемые термостаты.

- Телевизионное оборудование.

- Машины штемпелевания даты / времени.

- Частная учрежденческая телефонная станция.

- Электронные пишущие машинки или процессоры слов.

- Системы безопасности (считыватели значков / камеры слежения).

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

Определите стратегии соответствия для не соответствующих 2000 году ресурсов. Обычными решениями являются следующие.

- Замена.

- Списание.

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

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

Советы

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

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

Не ждите! О программно - аппаратном обеспечении часто забывают, а оно является критическим для повседневной работы.

8. Работа с поставщиками

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

Проблемы

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

Необоснованные заявления поставщика о соответствии 2000 году его продуктов.

Нежелание поставщика подтвердить соответствие 2000 году его продуктов.

Отсутствие юридической поддержки.

Рекомендуемый подход

Составьте полный перечень всех средств, полученных от поставщиков.

Определите взаимозависимости с другими поставляемыми средствами.

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

- Полагается ли поставляемый продукт на дату для лицензирования?

- Соответствует ли продукт 2000 году? Если да, то каков номер выпуска?

- Как поставщик определяет соответствие 2000 году для своего продукта?

- Потребуется ли при использовании соответствующего 2000 году выпуска вносить какие-либо изменения в процессы, использующие поставляемый продукт?

Определите приоритеты продуктов по их критичности для функционирования учреждения.

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

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

Разработайте планы чрезвычайных обстоятельств.

Советы

Включите в договоры с поставщиками положения о соответствии продуктов 2000 году и о разрешении споров.

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

Более тщательно оценивайте поставщиков, участвующих в слияниях и поглощениях.

Определите возможные сценарии судебных процессов.

Заключение

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

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

Материал подготовлен Департаментом информатизации ЦБ РФ

Приложение 1

КРАТКОЕ ИЗЛОЖЕНИЕ

МЕЖДУНАРОДНОЙ СТАНДАРТНОЙ НОТАЦИИ ДАТЫ И ВРЕМЕНИ

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

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

Дата

Нотацией даты международного стандарта является

Например, четвертый день февраля в 1995 году записывается в стандартной нотации как

1995-02-04.

Другими обычно используемыми нотациями являются, например, 2/4/95, 4/2/95, 95/2/4, 4.2.1995, 04-FEB-1995, 4-February-1995 и многие другие. Особенно опасными являются первые два примера, поскольку оба используются довольно часто в США и Великобритании и оба не могут быть различены, так как остается неясным, означает ли 2/4/95 дату 1995-04-02 или 1995-02-04. Обозначение даты 2/4/5 имеет по меньшей мере шесть разумных интерпретаций (с учетом того, что в нашей жизни только двадцатое и двадцать первое столетия являются разумными кандидатами).

Преимущества нотации даты стандарта ISO 8601 по сравнению с другими обычно используемыми вариантами:

- легко читается и пишется программным обеспечением (нет необходимости в таблице 'JAN', 'FEB',...);

- легко сравнивается и сортируется с обычным сравнением строк;

- не зависит от языка;

- не может быть спутана с другими популярными нотациями даты;

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

- строки, содержащие дату, за которой следует время, также легко сравниваются и сортируются (например, "1995-02-04 22:45:00");

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

- идентична китайской нотации даты, так что крупнейшая на планете культурная группа (> 25%) уже знакома с ней;

- нотация даты с порядком "год, месяц, день" широко используются в Японии, Корее, Венгрии, Швеции, Финляндии, Дании и некоторых других странах, а в США уже привыкли к порядку "месяц, день";

- представление года четырьмя цифрами позволяет избежать проблем переполнения после 1999-12-31.

Так как даты начиная с 2000-01-01 будут выглядеть немного странно (например, 1/1/0), наступление 2000 года дает возможность перейти на стандартную нотацию даты.

Помимо рекомендованной основной стандартной нотации YYYY-MM-DD в ISO 8601 обозначен также ряд альтернативных форматов для использования в приложениях с особыми требованиями. Все эти форматы могут легко и автоматически различаться.

Черточки могут быть опущены, если компактность представления является более важной, чем читаемость для человека, например:

19950204.

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

95-02-04 или 950204.

Если интерес представляет только месяц или даже только год:

1995-02 или 1995.

В коммерческих или промышленных приложениях (время доставки, производственные планы и т.д.), особенно в Европе, часто требуется ссылка на неделю года. Неделей 01 года является по определению первая неделя, которая имеет четверг в этом году, что эквивалентно неделе, которая содержит четвертый день января. Другими словами, первой неделей нового года является неделя, которая имеет большинство своих дней в новом году. Неделя 01 может также содержать дни из предыдущего года, и неделя перед неделей 01 года является последней неделей (52 или 53) предыдущего года, даже если она содержит дни из нового года. Неделя начинается с понедельника (день 1) и заканчивается воскресеньем (день 7). Например, первая неделя 1997 года длится с 1996-12-30 по 1997-01-05 и может быть записана в стандартной нотации как

1997-W01 или 1997W01.

Нотация недели может также расширяться номером, указывающим день недели. Например, день 1996-12-31, который является вторником (день 2) первой недели 1997 года, может быть записан как

1997-W01-2 или 1997W012.

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

Сокращенная версия года и номера недели такая, как

Стандарт ISO избегает явного указания возможного диапазона номеров недели, но его можно легко вывести из определения.

Теорема. Возможные номера недель по ISO находятся в диапазоне от 01 до 53. Год всегда имеет неделю 52. (Имеется одно историческое исключение: год, в который был введен григорианский календарь, имел менее 365 дней и менее 52 недель.)

Доказательство. По определению первой неделей года является W01, и, следовательно, дни перед неделей W01 принадлежат предыдущему году, и, таким образом, не существует недели с меньшим номером. При рассмотрении максимального возможного номера наихудшим случаем является високосный год, подобный 1976 году, который начинается четвергом, поскольку это удерживает в предыдущем году наибольшее возможное число дней недели W01 - 3 дня. В этом случае воскресенье недели W52 года, являющегося наихудшим случаем, имеет номер дня 4 + 51 x 7 = 361, и 361 - 366 = 5 дней недели W53 принадлежат еще этому году. Это гарантирует, что в году, являющемся наихудшим случаем, день 4 (четверг) недели W53 не относится еще к следующему году, поэтому возможен номер недели 53. Например, 53-я неделя являющегося наихудшим случаем 1976 года началась с 1975-12-29 = 1976-W01-1 и закончилась 1977-01-02 = 1976-W53-7. С другой стороны, при рассмотрении самого низкого номера последней недели года наихудшим случаем является невисокосный год, подобный 1999 году, который начинается с пятницы. Это гарантирует, что первые три дня года принадлежат последней неделе предыдущего года. В этом случае воскресенье недели 52 будет номером дня 3 + 52 x 7 = 367, то есть только последние 367 - 365 = 2 дня недели W52 переходят в следующий год, и, следовательно, даже являющийся наихудшим случаем год, подобный 1999 году, имеет неделю W52, включающую дни с 1999-12-27 по 2000-01-02. Что и требовалось доказать.

День и год являются полезными единицами структурирования времени вследствие того, что ими описывается положение Солнца на небе, которое влияет на жизнь человека. Однако деление года на 12 месяцев имеет таинственное происхождение, и в настоящее время у него нет никакого реального назначения, за исключением того, что люди к нему привыкли (оно даже не описывает текущего положения Луны). В некоторых приложениях предпочтительной является нотация, которая использует только год и день года между 001 и 365 (366 в високосных годах). Стандартная нотация для такого варианта, представляющего день 1995-02-04 (который является 035 днем 1995 года), -

1995-035 или 1995035.

Високосными годами являются годы с дополнительным днем YYYY-02-29, где номер года кратен четырем, за следующим исключением. Если год кратен 100, то он является високосным, если он кратен также 400. Например, 1900 год не был високосным годом, а 2000 год является високосным годом.

Время дня

Международной стандартной нотацией для времени дня является

Примером времени является нотация

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

23:59 (2359) или 23.

Можно также добавлять доли секунды после десятичной точки или запятой, например, время полночь без 5.8 ms может быть записано как

23:59:59.9942 или 235959.9942.

Так как день начинается и заканчивается в полночь, то доступны два обозначения - 00:00 и 24:00 - для различения полуночей, которые могут быть связаны с одной датой. Это означает, что следующие два обозначения относятся к одной и той же точке во времени:

1995-02-04 24:00 = 1995-02-05 00:00.

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

ISO 8601 не указывает, обозначают ли его нотации точку во времени или период времени. Это значит, например, что ISO 8601 не определяет, относится ли 09:00 к точному концу девятого часа дня, к периоду от 09:00 до 09:01 или к чему-то другому. Пользователи стандарта должны каким-то образом прийти к согласию относительно точной интерпретации обозначения времени, если это будет иметь какое-либо значение.

Если дата и время отображаются в одной и той же строке, то дату всегда пишут впереди времени. Если дата и значение времени хранятся вместе в одном поле данных, то ISO 8601 предлагает, чтобы они разделялись латинской заглавной буквой Т, как в 19951231Т235959.

Замечания о стандартах, принятых в США

24-часовая нотация времени, приведенная здесь, стала стандартом де-факто во всем мире в письменном языке уже десятилетия. Исключением являются некоторые англоговорящие страны, где еще широко используются обозначения часов от 1 до 12, и такие дополнения, как "a.m." и "p.m.". Общепринятая 24-часовая международная нотация начала в настоящее время широко использоваться даже в Англии. Большинство других языков не имеют сокращений, подобных "a.m." и "p.m.", и 12-часовая нотация едва ли когда-либо использовалась в континентальной Европе для записи или отображения времени. В США военные и программисты используют 24-часовую нотацию уже длительное время.

Старая английская 12-часовая нотация имеет много недостатков:

- она длиннее 24-часовой нотации;

- людям требуется намного больше времени для сравнения двух времен в 12-часовой нотации;

- неясно, как представляются 00:00, 12:00 и 24:00 (даже энциклопедии и руководства по стилю содержат противоречащие друг другу описания и обычно советуют избегать "12 a.m. / p.m." и писать вместо этого "полдень", "полночь" или "12:01 a.m. / p.m.", хотя слово "полночь" не различает 00:00 и 24:00);

- она часто заставляет людей верить, что следующий день начинается при переходе от "12:59 a.m." к "1:00 p.m.", что является обычной проблемой, не только когда люди пытаются программировать таймер видеомагнитофона вскоре после полуночи;

- она не является легко сравнимой с помощью операции сравнения строк;

- для непосвященных неясно, начинается ли время между "12 a.m. / p.m." и "1 a.m. / p.m." в 00:00 или в 12:00, то есть английскую 12-часовую нотацию понять трудней.

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

Замечания о стандартах, принятых в немецкоязычных странах

В мае 1996 года был обновлен германский стандарт DIN 5008, определяющий типографские правила для текстов на немецком языке. Старые немецкие нотации для обозначения даты цифрами DD.MM.YYYY и DD.MM.YY были заменены нотациями даты YYYY-MM-DD и YY-MM-DD стандарта ISO. Подобным же образом старые немецкие нотации времени hh.mm и hh.mm.ss были заменены нотациями hh:mm и hh:mm:ss стандарта ISO. Сохраняется немецкая алфавитно - цифровая нотация, например, "3. August 1994" или "3.Aug. 1994". Соответствующий австрийский стандарт использует нотации даты и времени ISO 8601.

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

Временная зона

Без каких-либо дальнейших пояснений дата и время, записанные вышеприведенными способами, считаются относящимися к какой-то локальной временной зоне. Чтобы указать, что речь идет об универсальном времени (UTC), вы можете добавить ко времени заглавную букву Z, как в

Например, центральное европейское время (СЕТ) есть +0100, а канадское восточное стандартное время (EST) есть -0500. Все следующие нотации указывают на одну и ту же точку времени:

12:00Z = 13:00 + 01:00 = 0700 - 0500.

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

Приложение 2

Сентябрь 1997 года

Главное бюджетно - контрольное управление США

КОМПЬЮТЕРНЫЙ КРИЗИС 2000 ГОДА:

РУКОВОДСТВО ПО ОЦЕНИВАНИЮ GAO/AIMD-10.1.14

Модель преобразования 2000 года:

структурный подход и жесткое управление программой

могут уменьшить риски

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

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

Руководство описывает пять этапов осуществления программы или проекта с представлением для каждого этапа основного действия или сегмента программы 2000 года.

1.0. Осведомленность

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

Основные процессы

1.1. Определить проблему 2000 года и ее потенциальное влияние на организацию.

1.2. Провести кампанию осведомления о проблеме 2000 года.

1.3. Оценить возможности организации по управлению программой.

1.4. Разработать и задокументировать стратегию 2000 года.

1.5. Получить поддержку руководства.

1.6. Учредить совет исполнительных руководителей.

1.7. Назначить руководителя программы 2000 года и учредить офис программы 2000 года.

1.8. Определить контакты с техническим персоналом и руководством в основных деловых областях.

1.1. Определить проблему 2000 года и ее потенциальное влияние на организацию.

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

1.2. Провести кампанию осведомления о проблеме 2000 года.

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

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

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

- уровни кадрового обеспечения и требования к квалификации кадров.

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

1.4. Разработать и задокументировать стратегию 2000 года.

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

1.5. Получить поддержку руководства и придать ей официальный статус путем выпуска:

- программного заявления по 2000 году;

- концепции программы 2000 года.

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

1.6. Учредить совет исполнительных руководителей.

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

1.7. Назначить руководителя программы 2000 года и учредить офис программы 2000 года.

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

1.8. Определить контакты с техническим персоналом и руководством в основных деловых областях.

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

2.0. Оценивание

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

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

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

Основные процессы

2.1. Определить соответствие 2000 году.

2.2. Сконцентрироваться на основных деловых областях и процессах и разработать документ оценивания 2000 года.

2.3. Оценить серьезность влияния отказов, связанных с 2000 годом.

2.4. Провести в масштабе организации инвентаризацию информационных систем для каждой деловой области.

2.5. Разработать всеобъемлющий портфель автоматизированных систем.

2.6. Проанализировать портфель систем.

2.7. Установить приоритеты систем и компонентов для преобразования или замены.

2.8. Учредить проектные группы 2000 года для деловых областей и основных систем.

2.9. Разработать план программы 2000 года.

2.10. Определить необходимые ресурсы, установить их приоритеты и мобилизовать их.

2.11. Разработать стратегии проверки, планы тестирования и сценарии.

2.12. Определить требования к стенду (facility) тестирования 2000 года.

2.13. Определить и приобрести инструментальные средства 2000 года.

2.14. Рассмотреть вопросы графика внедрения.

2.15. Рассмотреть вопросы интерфейсов и обмена данными.

2.16. Начать разработку планов чрезвычайных обстоятельств для критических систем.

2.17. Определить подверженные 2000 году системы и процессы, функционирующие вне сферы управления информационными ресурсами.

2.1. Определить соответствие 2000 году.

2.2. Сконцентрироваться на основных деловых областях и процессах и разработать документ оценивания 2000 года.

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

2.3. Оценить серьезность влияния отказов, связанных с 2000 годом.

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

2.4. Провести в масштабе организации инвентаризацию информационных систем для каждой деловой области.

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

2.5. Разработать всеобъемлющий портфель автоматизированных систем и определить для каждой системы:

- связи с основными деловыми областями или процессами;

- платформы, языки и системы управления базами данных;

- программное обеспечение операционных систем и утилиты;

- телекоммуникации;

- внутренние и внешние интерфейсы;

- владельцев;

- доступность и адекватность исходного кода и соответствующей документации.

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

- невосстанавливаемые элементы (отсутствие исходного кода или документации);

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

2.7. Установить приоритеты систем и компонентов для преобразования или замены.

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

2.8. Учредить проектные группы 2000 года для деловых областей и основных систем.

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

2.9. Разработать план программы 2000 года, включая:

- графики для всех задач и этапов программы 2000 года;

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

- оценивание и выбор вариантов передачи третьей стороне;

- назначение проектов преобразования или замены проектным группам 2000 года;

- оценивание рисков;

- планы чрезвычайных обстоятельств для всех систем.

2.10. Определить необходимые ресурсы, установить их приоритеты и мобилизовать их.

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

2.11. Разработать стратегии проверки и планы тестирования для всех преобразованных или замененных систем и их компонентов. Определить и приобрести автоматизированные инструментальные средства тестирования и разработать сценарии тестирования.

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

Этап I - автономное тестирование. Ориентировано на тестирование функциональности и соответствия одного приложения или программного модуля.

Этап II - интеграционное тестирование. Тестирует объединение связанных программных модулей и приложений.

Этап III - системное тестирование. Тестирует все объединенные компоненты информационной системы.

Этап IV - приемо - сдаточное тестирование. Тестирует информационную систему с "живыми" операционными данными.

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

2.12. Определить требования к стенду (facility) тестирования 2000 года.

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

2.13. Определить и приобрести инструментальные средства 2000 года.

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

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

- определение и выбор средств преобразования;

- время, необходимое для ввода преобразованных систем в производство;

- преобразование резервных и архивных данных.

2.15. Рассмотреть вопросы интерфейсов и обмена данными, включая:

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

- уведомление всех внешних объектов обмена данными;

- потребность в мостах и фильтрах данных;

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

- процесс проверки для исходящих внешних данных;

- планы чрезвычайных обстоятельств для неправильных данных.

2.16. Начать разработку планов чрезвычайных обстоятельств для критических систем.

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

2.17. Определить подверженные 2000 году системы и процессы, функционирующие вне сферы управления информационными ресурсами.

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

3.0. Обновление

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

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

Основные процессы

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

3.2. Разработать мосты и фильтры данных.

3.3. Заменить выбранные приложения и соответствующие системные компоненты.

3.4. Задокументировать изменения в программном коде и системах.

3.5. Спланировать автономное, интеграционное и системное тестирование.

3.6. Списать выбранные приложения и соответствующие системные компоненты.

3.7. Сообщить об изменениях в информационных системах внутренним и внешним пользователям.

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

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

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

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

3.2. Разработать мосты и фильтры данных.

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

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

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

3.4. Задокументировать изменения в программном коде и системах.

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

3.5. Спланировать автономное, интеграционное и системное тестирование.

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

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

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

3.7. Сообщить об изменениях в информационных системах внутренним и внешним пользователям.

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

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

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

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

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

4.0. Проверка

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

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

Основные процессы

4.1. Разработать и задокументировать планы и графики тестирования и соответствия.

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

4.3. Реализовать стенд тестирования 2000 года.

4.4. Внедрять автоматизированные инструментальные средства тестирования и сценарии тестирования.

4.5. Выполнить автономное, интеграционное и системное тестирование.

4.6. Определять, собирать и использовать данные тестирования для управления процессом тестирования и проверки.

4.7. Начать приемо - сдаточное тестирование.

4.1. Разработать и задокументировать планы и графики тестирования и соответствия для каждого преобразованного или замененного приложения или системного компонента.

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

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

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

4.3. Реализовать стенд тестирования 2000 года.

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

4.4. Внедрять автоматизированные инструментальные средства тестирования и сценарии тестирования.

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

4.5. Выполнить автономное, интеграционное и системное тестирование.

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

4.6. Определять, собирать и использовать данные тестирования для управления процессом тестирования и проверки.

4.7. Начать приемо - сдаточное тестирование.

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

5.0. Внедрение

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

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

Основные процессы

5.1. Определить среду и процедуры перехода.

5.2. Разработать график внедрения.

5.3. Разрешить вопросы обмена данными и межведомственные проблемы.

5.4. Выполнить преобразование баз данных и архива.

5.5. Завершить приемо - сдаточное тестирование.

5.6. Реализовать планы чрезвычайных обстоятельств.

5.7. Обновить или разработать планы восстановления после катастроф.

5.8. Внедрить преобразованные или замененные системы.

5.1. Определить среду и процедуры перехода.

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

5.2. Разработать график внедрения.

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

5.3. Разрешить вопросы обмена данными и межведомственные проблемы, включая обеспечение того, что:

- все внешние объекты обмена данными уведомлены;

- мосты и фильтры данных готовы для обработки не соответствующих 2000 году данных;

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

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

- процесс проверки готов для входящих внешних данных.

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

5.4. Выполнить преобразование баз данных и архива.

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

5.5. Завершить приемо - сдаточное тестирование.

Обычно формальное тестирование обнаруживает 80 - 90% программных ошибок, а остальные 10 - 20% ошибок раскрываются во время эксплуатации. Приемо - сдаточное тестирование должно быть завершено не позднее осени 1999 года, чтобы оставить достаточно времени для исправления программных ошибок, обнаруженных после внедрения.

5.6. Реализовать планы чрезвычайных обстоятельств.

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

5.7. Обновить или разработать планы восстановления после катастроф.

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

5.8. Внедрить преобразованные или замененные системы.

Интегрировать преобразованные или замененные системы и соответствующие базы данных в производственную среду.

Управление программой и проектом

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

Основные процессы

A. Создать структуру управления программой 2000 года.

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

C. Внедрить процессы и инструментальные средства управления программой.

A. Создать структуру управления программой 2000 года:

- назначить руководителя программы 2000 года и учредить группу программы 2000 года;

- определить технических и управленческих представителей от каждой основной деловой области.

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

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

Основываясь на выполненной во время осведомления о проблеме 2000 года оценке способности ведомства управлять программой, обеспечить готовность стратегий и процедур управления программой на уровне ведомства, включая:

- управление конфигурацией,

- обеспечение качества,

- управление рисками,

- планирование проекта и слежение,

- измерение характеристик,

- финансирование.

C. Внедрить процессы и инструментальные средства управления программой.

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

Приложение 3

ОЦЕНКА СООТВЕТСТВИЯ СИСТЕМЫ 2000 ГОДУ <*>

--------------------------------

<*> Вопросник штата Миннесота (США).

Наименование системы __________ ______________________________

Определите стратегию согласования

Программное обеспечение

- Отказ от использования.

- Обновление.

- Замена.

- Неприменимо.

- Было ли соответствие 2000 году проверено для новых улучшений и замен? (Да / Нет)

- Будет ли соответствующий 2000 году продукт поставщика доступен до сентября 1998 года? (Да / Нет)

Техническое обеспечение

- Отказ от использования.

- Обновление.

- Замена.

- Неприменимо.

- Было ли соответствие 2000 году проверено для новых улучшений и замен? (Да / Нет)

- Будет ли соответствующий 2000 году продукт поставщика доступен до сентября 1998 года? (Да / Нет)

Разработанные на заказ приложения

- Использует ли продукт какие-либо поля даты? (Да / Нет)

- Сколько цифр в полях года?

Две цифры.

Четыре цифры.

- Вводится ли дата непосредственно пользователем? (Да / Нет)

- Как пользователь определяет год?

- Как программа вычисляет високосные годы? Какие правила применяются?

- Являются ли даты, хранящиеся внутри, специфическим типом данных "дата"? (Да / Нет)

- Определяются ли даты с использованием смещения числа секунд / минут / часов / дней / недель начиная с базового года? (Да / Нет)

- Если так, то какого размера тип данных используется, чтобы сохранить смещение?

- Каков диапазон достоверных дат?

- Допускается / используется определение года двумя цифрами для любого из перечисленного?

- Если так, то как ими управляют / используют?

- Выполняются ли какие-либо проверки правильности даты при сравнении? (Да / Нет)

- Как обрабатываются разрывы во времени? ______________

- Что происходит, если текущее время меньше предыдущего? _____

- Игнорируются ли данные? (Да / Нет)

- Как для вычислений обрабатываются временные рамки больше 100 лет? ____________________

- Используются ли специальные значения в полях даты? (Например, 99 может интерпретироваться логикой системы, чтобы указать, что не имеется никакой даты истечения срока.) (Да / Нет)

- Получает ли или передает ли программа даты непосредственно любым другим программам и / или системам? (Да / Нет)

- Если да, то могут ли эти приложения и / или системы правильно обрабатывать следующее:

- Использует ли продукт дату в проверке правильности лицензии (например, данные, используемые в алгоритме кодирования)? (Да / Нет)

- Зависит ли исправление вычисления даты от изменения любых аппаратных средств (например, BIOS)? (ДА / Нет)

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

- Определена ли стратегия соответствия?

- Определена ли и задокументирована ли стратегия исправления?

Приложение 4

КРИТЕРИИ ТЕСТИРОВАНИЯ СООТВЕТСТВИЯ СТОЛЕТИЮ

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

Четырьмя критериями, определяющими соответствие столетию, являются общая целостность, целостность даты, явное столетие и неявное столетие.

Критерии

Общая целостность

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

Целостность даты

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

Явное столетие

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

Неявное столетие

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

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

Инструкции по тестированию

Операционная система

Общая целостность

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

1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29.

Повторная инициализация с холодного старта по датам с повышенным риском:

1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29.

Системная дата правильно переходит к датам с повышенным риском:

1998-12-31 -> 1999-01-01

1998-12-31 -> 2000-01-01

2000-02-28 -> 2000-02-29

2000-02-29 -> 2000-03-01.

Правильно ли происходит переход даты как в выключенном, так и во включенном состоянии?

Целостность даты

Ведут ли себя корректно в 19xx и 20xx годах чувствительные к датам функции для системных дат?

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

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

Каково наибольшее возможное значение, которое переключатель может представлять для системной даты?

Системная дата правильно появляется при использовании в штампах времени для дат с повышенным риском:

1999-01-01, 1999-12-31, 2000-01-01, 2000-02-28,

2000-02-29, 2000-03-01.

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

Явное столетие

Может ли столетие явно вводиться или отображаться в чувствительных ко времени функциях?

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

Неявное столетие

Может ли столетие в любом значении даты в любой чувствительной ко времени функции неправильно интерпретироваться для дат между 1985-01-01 и 2050-12-01?

Компилятор, ассемблер или интерпретатор

Общая целостность

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

Возвращает ли эта функция правильное значение для системной даты для дат с повышенным риском:

1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29?

Возвращает ли эта функция правильное значение для системной даты после перехода системной датой дат с повышенным риском:

1998-12-31 -> 1999-01-01

1999-12-31 -> 2000-01-01

2000-02-28 -> 2000-02-29

2000-02-29 -> 2000-03-01?

Целостность даты

Поддерживает ли язык тип данных для значений даты в диапазоне от 1900-01-01 до 2050-12-31?

- Обрабатывают ли подпрограммы языка 2000 год как високосный, а 1900 год как невисокосный?

- Правильно ли арифметика дат определяет разности между датами, складывает даты и длительности, а также вычисляет день недели?

- Правильно ли подпрограммы языка выполняют преобразование представлений даты (YYMMDD в юлианскую и в базу со смещением)?

Работает ли язык с библиотекой подпрограмм даты? Если да, то правильно ли библиотека функционирует для вопросов в предыдущем пункте?

Включает ли система утилиту сортировки / слияния? Если да, то дает ли сортировка или слияние по полю даты правильную последовательность для дат в 19xx и 20xx годах?

Явное столетие

Предусматривает ли тип данных "дата" явные значения для столетия?

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

Неявное столетие

Поддерживает ли тип данных "дата" форматы без явного столетия?

Если значение для столетия не устанавливается явно, то какое значение предполагается при сравнении дат, арифметических операциях, постоянном хранении и т.д.?

Правильно ли столетие определяется во всех случаях, где столетие не является явным?

Система управления базами данных (СУБД)

Общая целостность

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

Возвращает ли эта функция правильное значение для системной даты для дат с повышенным риском:

1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29?

Возвращает ли эта функция правильное значение для системной даты после перехода системной датой дат с повышенным риском:

1998-12-31 -> 1999-01-01

1999-12-31 -> 2000-01-01

2000-02-28 -> 2000-02-29

2000-02-29 -> 2000-03-01?

Целостность даты

Поддерживает ли язык тип данных для значений даты в диапазоне от 1900-01-01 до 2050-12-31?

- Обрабатывают ли подпрограммы языка 2000 год как високосный, а 1900 год как невисокосный?

- Правильно ли арифметика дат определяет разности между датами, складывает даты и длительности, а также вычисляет день недели?

- Правильно ли подпрограммы языка выполняют преобразование представлений даты (YYMMDD в юлианскую и в базу со смещением)?

- Правильно ли язык сравнивает даты?

Производит ли ключевой индекс, включающий поле даты, правильную последовательность для дат в 19xx и 20xx годах?

Точно ли СУБД находит даты для значений в диапазоне от 1900-01-01 до 2050-12-31?

Явное столетие

Позволяет ли тип данных "дата" устанавливать явные значения для столетия?

Допускают ли функции поиска форматирование дат с явным столетием?

Точно ли СУБД находит даты для значений в диапазоне от 1900-01-01 до 2050-12-31?

Неявное столетие

Предусматривает ли тип данных "дата" типы данных без явного столетия?

Если значение для столетия не устанавливается явно, то какое значение предполагается при установке поля даты, сравнении дат, арифметических операциях и т.д.?

Локальная сеть

Общая целостность

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

1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29?

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

1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29?

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

1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29?

Возвращает ли эта функция правильное значение для системной даты после перехода системной датой дат с повышенным риском:

1998-12-31 -> 1999-01-01

1999-12-31 -> 2000-01-01

2000-02-28 -> 2000-02-29

2000-02-29 -> 2000-03-01?

Правильно ли принимает и устанавливает штампы времени в диапазоне от 1985-01-01 до 2035-12-31 программное обеспечение локальной сети?

Целостность даты

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

- Обрабатывает ли календарная логика 2000 год как високосный, а 1900 год как невисокосный?

- Правильно ли арифметика дат определяет разности между датами, складывает даты и длительности, а также вычисляет день недели?

- Правильно ли подпрограммы языка выполняют преобразование представлений даты (YYMMDD в юлианскую и в базу со смещением)?

- Правильно ли язык сравнивает даты?

Точно ли программное обеспечение администрации сети и прикладной интерфейс (API) к сетевому программному обеспечению принимают и ищут все поля даты для значений в диапазоне от 1900-01-01 до 2050-12-31?

Явное столетие

Предусматривают ли штампы времени явные значения столетия?

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

Допускает ли прикладной интерфейс к сетевому программному обеспечению явный ввод и поиск столетия во всех полях даты?

Неявное столетие

Правильно ли определяется значение столетия для всех операций над штампами времени для штампов времени без явного столетия?

Какое значение столетия предполагается для полей даты в пользовательском интерфейсе программного обеспечения администрации, если оно не вводится?

Какое предполагается значение столетия для полей даты в API, если приложение его не устанавливает?

Заказное приложение

Общая целостность

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

Возвращает ли эта функция правильное значение для системной даты для дат с повышенным риском:

1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29?

Возвращает ли эта функция правильное значение для системной даты после перехода системной датой дат с повышенным риском:

1998-12-31 -> 1999-01-01

1999-12-31 -> 2000-01-01

2000-02-28 -> 2000-02-29

2000-02-29 -> 2000-03-01?

Встроены ли в приложение продукты третьей стороны? Соответствуют ли столетию все эти продукты?

Игнорирует ли код приложения значения для явного столетия в системной дате в любой точке программы?

Целостность даты

Поддерживает ли язык тип данных для значений даты в диапазоне от 1900-01-01 до 2050-12-31?

Выполняет ли приложение вычисление високосного кода? Обращаются ли эти вычисления с 2000 годом как с високосным, а с 1900 годом как с невисокосным?

Правильно ли арифметика дат определяет разности между датами, складывает даты и длительности, а также вычисляет день недели?

Правильно ли приложение выполняет преобразование значений даты из одного представления даты в другое (например, YYMMDD в юлианскую и в базу со смещением)?

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

Включает ли приложение поиск, сортировку, слияние или индексирование по внутренним таблицам, цепным спискам и другим структурам данных, основанным на переменных даты? Правильно ли эти операции выполняются для всех возможных значений даты в ключевых переменных? Производит ли правильную последовательность для дат в 19xx и 20xx годах ключевой индекс, включающий поле даты?

Представляет ли приложение дату в любой переменной как смещение от базовых даты / времени? Каково максимальное значение даты для этого представления? Каково минимальное значение даты для этого представления (обычно базовая дата)? Попадает ли ожидаемый диапазон значений для каждой переменной, использующей это представление даты, в эти пределы?

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

Использует ли приложение языковые средства, связывающие адрес даты с несколькими переменными (такие, как REDEFINE в языке COBOL или COMMON в языке FORTRAN)? Игнорирует или отсекает значение для явного столетия в значении даты какая-либо переменная среди всех псевдонимов для одной и той же области данных? Используется ли усеченное значение даты в операции, которая предполагает, что все значения даты используют то же самое столетие?

Используются ли константы для значений даты (включая день, месяц или год) в какой-либо операции? Относится ли константа к функциональным требованиям или особое значение используется в типе данных "дата" для удобства?

Осуществляет ли приложение точное хранение и поиск дат для значений в диапазоне от 1900-01-01 до 2050-12-31?

Использует ли приложение утилиты сортировки / слияния для упорядочивания содержимого файлов по полям даты или индексированные файловые структуры с ключами по полям даты? Правильна ли упорядоченность для всех значений даты в диапазоне от 1900-01-01 до 2050-12-31?

Полагается ли приложение на первичные или альтернативные индексы структурированной базы данных для поиска, вставки, обновления или удаления, когда какой-либо ключ содержит поле даты? Будет ли правильной упорядоченность индекса для всех значений даты в диапазоне от 1900-01-01 до 2050-12-31?

Инициализируются ли все переменные типа "дата" в соответствии с каким-либо соглашением относительно пустого значения?

Явное столетие

Использует ли приложение язык, инструментальные средства и / или генератор приложений, допускающие явное столетие в типах данных "дата"? Если да, то поступают ли значения для столетия в переменных этих типов путем ввода извне или формируются программным обеспечением?

Использует ли приложение СУБД или другой программный продукт для хранения и поиска данных типа "дата"? Если да, то могут ли эти продукты поддерживать явные значения для столетия в любой хранимой и участвующей в поиске переменной типа "дата"?

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

Удовлетворяют ли критериям соответствия столетию все представления даты с явным столетием как внутри приложения, так и во всех интерфейсах?

Неявное столетие

Использует ли приложение язык, инструментальные средства и / или генератор приложений (включая средства построения GUI), допускающие представление даты без явного столетия в типах данных "дата"? Если да, то формируется ли столетие для любых операций или передачи значения даты через любой интерфейс или для постоянного хранения? Если да, то является ли значение для столетия правильным для всех возможных значений дат, которые может содержать каждая переменная?

Использует ли приложение константы для даты или частей даты (например, дня, месяца или года)? Если да, то является ли столетие неявным в значении любой константы полной даты или года? Все ли операции, использующие каждую константу прямо или косвенно (то есть переносимую через переменные в другие операции в программе), производят правильные результаты для всех возможных значений для таких переменных даты?

Использует ли приложение какой-либо прикладной интерфейс (API), такой как SQL, который передает переменные типа "дата"? Если да, то предоставляет ли принимающее программное обеспечение значение столетия, производное или по умолчанию, для любого значения даты, передаваемого через этот интерфейс?