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

Рекомендации ЦБР от 14 апреля 1999 г.
по решению проблемы 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, предполагает 19хх, а год со значением, меньшим или равным 50, предполагает 20хх).

Правило 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 году, разработанную Департаментом информатизации ЦБР 6 января 1999 г.

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

Избегайте изменения форматов даты, когда достигнуто соответствие 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 года, возможно, необходимо будет создать и правильно именовать хранилища, библиотеки, файлы, базы данных и т.д. Используя стандарты именования, которым легко следовать, проектировщики системы могут производить продукты, которые не приведут к неоднозначному или неправильному пониманию.

Проблемы

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

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

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

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

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

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

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

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

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

                   ASOF         BEGIN         CURR

                   CURRENT      DATE          DAT

                   DTE          DT            DAY

                   DA           DD            DOB

                   DOH          EXPIRE        JULIAN

                   MONTH        MON           START

                   TERM         TIME          TIMESTAMP

                   TIMEDATE     THISDATE      WEEK

                   YEAR         YR            YY

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

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

- Используемые 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. Перечень ПЭВМ

Поставщик	Модель	Серийный номер	BIOS/программа

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

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

Персональный компьютер	Действие
286 и ниже	Заменить; эти машины не будут хранить или об- рабатывать какие-либо даты после 1999-12-31
386	Заменить, если этого требуют решаемые задачи Устанавливать дату каждый раз, когда система включается Принять тот факт, что система не соответствует 2000 году, и использовать ее для задач, не яв- ляющихся чувствительными ко времени
Не соответствующие 2000 году 486 и Pentium	Заменить, если этого требуют решаемые задачи Улучшить BIOS программным путем (flash), если машина должна продолжать работать во время смены 1999 года на 2000-й Если не годится ни один из вышеуказанных вари- антов, предпочтительна ручная установка даты 2000-01-01 или позднее
Соответствующие 2000 году 486 и Pentium	Ничего не делать: они перейдут к 2000 году ав- томатически

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

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

Таблица 4. Сценарий готовности к 2000 году для персонального компьютера

Шаг	Тест	Нормальное выполнение	Отказ
1	Измените дату на 1999-12-31	Система принимает дату. Следующий шаг	При этой операции не может быть отказа. Ошиб- ка пользователя. Повто- рите
2	Измените время на 11:59:50РМ	Система принимает время. Следующий шаг	Ошибка пользователя. Повторите
3	Подождите 20 секунд; отоб- разите дату и время	Дата отображается как 2000-01-01. Следующий шаг	Без паники. Идите на тест включения питания
4	Отключите пи- тание и ждите 10 секунд; включите пита- ние. Проверьте дату	Дата отображается как 2000-01-01. Следующий шаг	СТОП! Идите на процедуры обновления для превраще- ния ПЭВМ в соответству- ющую 2000 году
5	Тест високос- ного года Измените дату на 2000-02-29	Система принимает 2000 год как високосный	СТОП! Идите на процедуры обновления для превраще- ния ПЭВМ в соответству- ющую 2000 году

Таблица 5. Сценарий готовности к 2000 году для рабочей станции

Шаг	Тест	Нормальное выполнение	Отказ
1	Измените дату и время на 1999-12-31 и 11:58РМ	Система принимает изме- нение даты/времени. Сле- дующий шаг	Ошибка пользователя. Повторите
2	Проверьте изме- нение даты вре- мени	Дата - 1999-12-31. Время между 11:58РМ и 12:00АМ. Следующий шаг	Ошибка пользователя. Повторите шаг 1
3	Отключите пита- ние и ждите 10 секунд; включите питание. Про- верьте дату	Дата отображается как 2000-01-01. Поздравляем! Ваша система готова к 2000 году	Установите дату/время на 2000-01-01 и 12:01:00АМ. Следующий шаг
4	Проверьте дату и время	Дата отображается как 2000-01-01. Следующий шаг	СТОП! Идите на процедуры обновления для превраще- ния ПЭВМ в соответству- ющую 2000 году
5	Отключите пита- ние с датой 2000-01-01. Пе- резагрузите ПЭВМ	При загрузке дата отоб- ражается как 2000-01-01. ПЭВМ будет нормально работать, если часы ус- танавливаются вручную после Нового года	СТОП! Идите на процедуры обновления для превраще- ния ПЭВМ в соответству- ющую 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   году   версия/выпуск  будет

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

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

           - придется ли покупать новое улучшение (upgrade)?

- Как поставщик определяет соответствие 2000 году для своего продукта?

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

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

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

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

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

Советы

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

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

Более тщательно оценивайте поставщиков, участвующих в слияниях и поглощениях.

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

Заключение

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

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