СОДЕРЖАНИЕ
РЕКОМЕНДАЦИИ
ПО РЕШЕНИЮ ПРОБЛЕМЫ 2000 ГОДА В ИНФОРМАЦИОННЫХ
СИСТЕМАХ БАНКА РОССИИ
Введение
Проблема 2000 года связана с трудностями, которые могут
возникнуть при неправильном функционировании программного
обеспечения, технического обеспечения и программно - аппаратного
обеспечения в конце двадцатого столетия или при выполнении
операций с информацией, включающей даты, относящиеся к следующему
столетию.
Проблема возникает по двум причинам. Первой причиной является
то, что многие системы хранят даты в шестизначном формате (YYMMDD,
DDMMYY или MMDDYY) с представлением года только двумя цифрами, а
не четырьмя. Так, дата 15 февраля 1998 года будет представлена в
формате YYMMDD как 980215. А дата 15 февраля 2000 года в этом же
формате будет храниться как 000215, и по умолчанию в качестве
столетия ей будет приписываться значение 19. Это приводит к
неразличимости столетий.
Вторая причина - то, что 2000 год является високосным, чего не
учитывают многие программы. Правилами определения високосного года
должны быть:
1) делимость на 4, но не на 100;
2) делимость на 400. Например, годы 1800 и 1900 не являются
високосными, а 2000 год является.
По этим причинам при наступлении 2000 года могут произойти
сбои вычислительных систем и ошибки в обработке данных, связанные
с операциями следующих категорий.
Арифметические:
- вычисление длительности промежутка времени между двумя
датами;
- вычисление даты, основываясь на начальной дате и
длительности промежутка времени;
- вычисление дня недели, дня в году, недели в году и т.п.
Переходы:
- сравнение двух дат.
Форматы:
- преобразование даты из одного представления в другое
(YYMMDD, юлианская и т.д.);
- извлечение из поля даты ее различных частей и значений.
Хранение данных:
- хранение и поиск;
- сортировка и слияние;
- использование даты в ключах и индексах дисковых файлов и
таблиц баз данных;
- использование даты в именах файлов.
Расширенная семантика:
- использование в дате "99" и "00" или других значений в
качестве особого признака (конца файла, пропущенного значения,
режима хранения и т.п.).
Эти ошибки могут быть связаны с прикладным программным
обеспечением (неправильное вычисление процентов, дат платежа,
пенсий, пособий, капиталовложений, неправильный учет файлов,
поддержание и сохранение файлов), операционными системами
(нарушение работы программ ведения файлов и оптимизации
производительности), системами контроля за доступом и безопасности
(логическое отключение пользователей от автоматизированных
приложений, физическое отключение от помещений или зон
подразделений), техническим обеспечением (отказ центральных
процессоров компьютеров, коммутаторов, маршрутизаторов, мостов,
серверов, принтеров, факсимильных машин, мультиплексоров и других
устройств, а также отказ микросхем ROM, BIOS, контроллеров жестких
дисков и т.д.). Кроме того, неправильная работа с датами может
нарушить функционирование банкоматов, автоматов в торговых точках
(POS), сейфов, лифтов, систем отопления, вентиляции и
кондиционирования воздуха, противопожарных систем и т.д.
Таким образом, очевидной является необходимость замены
покупного технического и программного обеспечения версиями,
удовлетворяющими требованиям 2000 года, переделка разработанного
собственными силами программного обеспечения и преобразование
архивных баз данных для обеспечения их совместимости с новыми
структурами данных и программным обеспечением.
1. Определения соответствия 2000 году
Существуют различные определения соответствия информационных
систем (ИС) 2000 году, на основе которых можно построить свое
определение в зависимости от выбираемых стратегий, имеющихся
ресурсов, предпочтений и других факторов. Приведем некоторые из
них.
Определение Британского института стандартов
Соответствие 2000 году будет означать, что на
производительность и функциональность ИС не повлияют даты до, во
время и после наступления 2000 года.
В частности, должны соблюдаться следующие правила.
Правило 1. Никакое значение для текущей даты не должно вызвать
прерывания в работе.
Это правило известно как правило общей целостности.
Если это требование удовлетворяется, то переход через все
значимые границы времени (например, дни, месяцы, годы, столетия)
будет выполняться правильно. Текущая дата означает сегодняшнюю
дату, как она известна оборудованию или продукту.
Правило 2. Функциональные возможности ИС, связанные с датой,
должны вести себя одинаково для дат до, во время и после
наступления 2000 года.
Это правило известно как правило целостности даты.
Оно означает, что все оборудование и все продукты должны
выполнять с датами вычисления, другие операции и представление в
соответствии с определенными целями.
Функциональная возможность означает как процессы, так и
результаты этих процессов.
Никакое оборудование или продукт не будет использовать
конкретные значения даты для особых обозначений (например, "99" -
для обозначения "нет конечного значения" или "конец файла", "00" -
для обозначения "неприменимо" или "начало файла").
Правило 3. Во всех интерфейсах и при хранении данных столетие
в любой дате должно определяться либо явно, либо недвусмысленными
алгоритмами или правилами логического вывода.
Это правило называется иногда правилом явного / неявного
столетия.
Оно включает два подхода:
- явное представление года в датах (например, путем
использования четырех цифр или путем включения признака столетия);
- использование правил вывода (например, двузначный год со
значением, большим 50, предполагает 19xx, а год со значением,
меньшим или равным 50, предполагает 20xx).
Правило 4. 2000 год должен распознаваться как високосный.
Определение штата Миннесота (США)
Соответствие 2000 году означает, что:
- структуры даты обеспечивают распознавание столетия
четырехзначной даты;
- хранимые данные содержат распознавание столетия даты;
- вычисления и логика программы могут работать с формулами и
значениями дат одного и того же столетия и нескольких столетий;
- интерфейсы препятствуют входу в любую систему учреждения или
выходу из любой системы учреждения не соответствующих 2000 году
дат и данных;
- 2000 год правильно обрабатывается как високосный год во всех
вычислениях и всех операциях с календарем.
Определение штата Орегон (США)
Соответствие 2000 году определяют следующие стандарты.
Информационные системы, предназначенные для использования до,
во время и после наступления 2000 года, будут работать без ошибок,
связанных с данными дат.
Программное обеспечение и приложения не будут завершаться
аномально или давать неправильные результаты при обработке дат,
особенно между столетиями.
Никакое значение для текущей даты не вызовет прерывания в
работе.
Все операции над связанными со временем данными (датами,
длительностями, днями недели и т.д.) будут давать желаемые
результаты для всех допустимых значений в Приложениях.
Элементы даты в интерфейсах и при хранении данных позволят
указывать столетие во избежание двусмысленности.
Для любого элемента данных, представленного без столетия,
правильное столетие является недвусмысленным для всех операций,
связанным с этим элементом.
Определение Университета Флориды (США)
Каждый компонент информационной системы должен удовлетворять
следующим минимальным стандартам.
Никакое правильное значение для текущей даты не должно вызвать
ошибки или сбоя в любой желаемой операции (вводе - выводе,
модификации, ссылке, сравнении, отображении и т.д.).
Все манипуляции или сравнения связанных с датой данных должны
давать желаемые результаты для всех допустимых значений даты в
приложении.
Не должно быть двусмысленности столетия. Неявное столетие
может использоваться только там, где все операции с датой и ее
отображение могут выполняться без двусмысленности. Во всех других
случаях в элементе даты должно храниться явное столетие. Даты с
явным столетием должны храниться в 8 смежных байтах в формате
YYYYMMDD стандарта ISO. Даты должны отображаться в обычном
американском формате MM - DD - YYYY.
Где минимальная и / или максимальная дата требуется для целей
редактирования или отображения, стандартное значение 01-01-1900
(хранимое как 19000101) должно использоваться как минимум, а
12-31-9999 (хранимое как 99991231) должно использоваться как
максимум.
2000 год должен распознаваться как високосный.
Определение компании Year2000 Ltd (Новая Зеландия)
Хотя это может оказаться труднодостижимым, в качестве цели мы
рассматриваем следующее.
Все поля даты, хранимые в электронном виде в системах,
эксплуатируемых нами, должны содержаться в виде 8 цифр в формате
YYYYMMDD стандарта ISO-8601. Это относится ко всем системам,
работающим в нашей компании, независимо от того, разработаны они
нами или являются пакетами, поставленными нам внешними
поставщиками / производителями программного обеспечения.
Все поля даты, принимаемые электронным образом в наши системы
(за исключением ручного ввода), то есть файлы, передаваемые нам от
третьих сторон, будут в том же самом формате ISO-8601.
Все поля даты, передаваемые нами третьим сторонам, будут также
в полном 8-значном формате ISO-8601.
В любых печатных отчетах из этих систем будут печататься
4-значные годы; 2-значные годы будут печататься только в тех
случаях, где по контексту предполагаемое значение столетия не
вызывает сомнений.
Любой ввод дат человеком через экраны и т.д. должен быть
недвусмысленным. Так, ввод 2-значного года является приемлемым
тогда и только тогда, когда контекст приложения делает
предположение о столетии полностью очевидным. Любые такие даты
должны храниться в полном 8-значном стандарте ISO. Во всех
случаях, если этому не препятствуют проблемы размещения, ввод
2-значного года будет сопровождаться отображением
интерпретируемого 4-значного года. На случай пожелания оператора
изменить столетие должна быть предусмотрена возможность вводить
4-значный год.
Все техническое и программное обеспечение должно точно
возвращать сегодняшнюю дату по любым датам.
Никакое значение для сегодняшней даты не вызовет какого-либо
прерывания в нашей работе.
Любая обработка, включающая даты, будет вести себя одинаково и
в соответствии с ожиданиями до, во время и после наступления 2000
года.
2000 год распознается как високосный.
2. Организация работ
Работы по решению проблемы 2000 года в информационных системах
ЦБ РФ следует разделить на пять перекрывающих друг друга этапов.
1. Осведомленность (июнь - июль 1998 года):
- назначить руководителя программы 2000 года и создать рабочие
группы;
- определить потенциальное влияние проблемы 2000 года;
- провести мероприятия по осведомлению о проблеме 2000 года;
- разработать стратегию 2000 года;
- разработать схему управления ходом работ и механизм контроля
за ними.
2. Оценивание (июль - ноябрь 1998 года):
- определить соответствие 2000 году;
- оценить серьезность влияния отказов, связанных с 2000 годом;
- провести инвентаризацию информационных систем;
- установить приоритеты систем и компонентов для
преобразования или замены;
- определить необходимые ресурсы, установить их приоритеты;
- разработать стратегии проверки, планы тестирования и
сценарии;
- определить и приобрести инструментальные средства 2000 года;
- рассмотреть график внедрения ИС;
- рассмотреть вопросы интерфейсов и обмена данными;
- начать разработку планов чрезвычайных обстоятельств для
критических систем.
3. Обновление (октябрь 1998 года - май 1999 года):
- преобразовать выбранные приложения, базы данных, архивы и
соответствующие системные компоненты;
- разработать мосты и фильтры данных;
- заменить выбранные приложения и соответствующие системные
компоненты;
- задокументировать изменения в программном коде и системах;
- спланировать автономное, интеграционное и системное
тестирование;
- списать выбранные приложения и соответствующие системные
компоненты;
- сообщить об изменениях в информационных системах внутренним
и внешним пользователям.
4. Проверка (январь - сентябрь 1999 года):
- разработать планы и графики тестирования ИС;
- разработать стратегию для управления тестированием систем,
преобразуемых подрядчиками;
- выполнить автономное, интеграционное и системное
тестирование;
- начать приемо - сдаточные испытания.
5. Внедрение (июнь - ноябрь 1999 года):
- определить среду и процедуры перехода;
- разработать график внедрения;
- решить вопросы обмена данными и межведомственные проблемы;
- выполнить преобразование баз данных и архива;
- завершить приемо - сдаточные испытания;
- обновить или разработать планы восстановления после
катастроф;
- внедрить преобразованные или замененные системы.
В связи с централизованными поставками в подразделения и
учреждения ЦБ РФ технических и программных средств и наличием у
них собственных разработок следует обеспечить соответствующее
распределение работ с целью минимизации их дублирования.
Для ускорения обмена информацией по проблеме 2000 года
необходимо использовать разнообразные средства связи ("горячие"
телефонные линии, факсимильное оборудование, электронную почту,
сайты Internet и т.п.).
3. Варианты преобразования
3.1. Обновление
Назначение данного раздела - очертить преимущества и
недостатки каждого приема и помочь организаторам проектов в
определении самой лучшей стратегии обновления.
Обновление является процессом, с помощью которого в проекте
2000 года решаются проблемы структуры даты. Существует в основном
четыре типа приемов обновления: расширение, работа с окнами,
кодирование или сжатие и последовательная дата (serial date).
Проблемы
- Определение полей даты и переменных, которые должны
соответствовать 2000 году, в качестве входных для процесса
обновления.
- Процесс обновления предполагает, что исходный код доступен
для всех Приложений, требующих обновления.
- Приложения разбиваются на обновляемые модули. Неиспользуемый
исходный текст ("мертвый" код) не обновляется.
Приемы
Внутри приложения наилучшие результаты может дать один прием
или их комбинация.
- Приемы расширения:
четырехзначный формат;
односимвольный код столетия:
внешний код столетия;
вложенный код столетия.
- Приемы работы с окнами:
фиксированное окно;
скользящее окно.
- Приемы кодирования или сжатия.
- Прием последовательной даты.
Приемы расширения
Когда следует использовать приемы расширения
Когда даты переходят границу 100-летнего окна и столетие не
может быть получено недвусмысленно (например, в дате рождения).
Для элемента даты, который является частью ключа или индекса.
В относительно новой системе, которая может иметь долгую
жизнь.
В системе большого объема, где на время отклика в режиме он -
лайн может неблагоприятно влиять получение столетий программным
путем.
В приложениях с многочисленными интерфейсами к другим
приложениям, внутренним или внешним, особенно когда внешний
источник диктует использование четырехзначной даты в качестве
условия ведения бизнеса.
Когда технологией является база данных, контролируемая
системой управления базами данных (СУБД); структуры таблицы /
записи изменяются однажды, а ссылка на них содержится в
многочисленных приложениях.
Когда следует избегать приемов расширения
Когда стратегией преобразования является постоянное
сопровождение, непрактично делать изменения структур данных
специально.
Когда имеется ограниченное устройство хранения прямого доступа
(DASD) / дополнительная память, чтобы сохранить столетия.
Когда приложение имеет короткий жизненный цикл и расширение
поля является дорогостоящей альтернативой.
В случаях только отображения, когда двузначная дата не будет
интерпретироваться двусмысленно (например, дата формирования
отчета).
Четырехзначный формат
Преимущества
Обеспечивает четырехзначный формат года; рассматривается как
полное, постоянное и очевидное решение.
Использует формат ISO (YYYY - MM - DD) по умолчанию.
Обеспечивает в настоящее время усиленную защиту против
потенциально неприемлемых решений, если отображаемые даты
выборочно игнорируются.
Недостатки
Во всех случаях требуется преобразование года из двузначного
формата в формат с четырьмя цифрами.
Смежные поля в макете поля даты переопределяются, и размеры
записей увеличиваются.
Требуется увеличение используемой DASD / памяти.
Односимвольный код столетия
Внешний код столетия
Преимущества
Формат базы данных может быть преобразован, а программы
модифицированы позже.
Обеспечивает простое решение для преобразования данных в новый
формат.
Недостатки
Требуется дополнительная логика для программ, выполняющих
вычисления даты.
Последовательность подборки некорректна, если поле даты
используется как ключ, пока к ключу не добавлен код столетия.
Размеры записей должны увеличиться.
Требуется увеличение используемой DASD / памяти.
Встроенный код столетия
Преимущества
Сохраняется правильное упорядочение данных.
Не требуется дополнительного дискового пространства.
Недостатки
Данные года должны быть преобразованы из двузначного в
трехзначный формат.
Требуется преобразование данных формата YY в формат CYY.
Приемы работы с окнами
Когда следует использовать прием окон
Когда расширение поля будет слишком дорогостоящим, если даты,
как ожидается, останутся в пределах 100-летнего периода.
Когда недостаточно времени, чтобы выполнить расширение
четырехзначного поля.
При преобразовании приложения, замену которого первоначально
планировалось выполнить до критической точки, а время истекает.
Как быстрое решение, когда дефектные программы изменяются как
часть продолжающегося сопровождения.
Когда не следует использовать прием окон
При обработке дат со значениями, выходящими за пределы
100-летнего периода.
При частой обработке дат; постоянное формирование дат может
создать недопустимую дополнительную нагрузку.
При неуверенности в том, что одно и то же правило формирования
будет использоваться при формировании столетия несколькими
приложениями для одного и того же элемента даты.
Когда рассматриваемая дата является частью ключа или
используется в отсортированном наборе данных в некоторой системе
управления базами данных.
Фиксированное окно и скользящее окно
Преимущества
Нет необходимости расширять формат года с двузначного до
четырехзначного.
Обеспечивает формат года с четырьмя знаками для обращения к
данным.
Различает годы разных столетий, используя двузначный формат
(исходя из предположения, что обрабатываемые годы находятся в
100-летнем диапазоне).
Полезно в том случае, если отдельная программа выводится из
использования поэтапно; временное решение.
Недостатки
Потенциальные риски существуют, когда / если функционирование
программного приложения требует обрабатывать годы вне 100-летнего
диапазона.
Влияние на производительность прямо пропорционально количеству
обрабатываемых дат вследствие дополнительной нагрузки
преобразования года из двузначного формата в четырехзначный.
Для программ, использующих метод фиксированного окна, может
потребоваться ежегодное обновление вручную.
Все программы, принимающие выходные данные, получаемые с
помощью приема фиксированного окна, должны использовать те же
самые предположения (например, окна текущей даты, прошлой даты и
будущей даты).
Приемы кодирования или сжатия
Преимущества
Нет необходимости преобразовывать год из двузначного в
четырехзначный формат данных.
Различают годы разных столетий, используя двузначный формат
года.
Юлианский формат с флагом (CYYDDD) использует С как признак
столетия.
Недостатки
В зависимости от представления данных схема может применяться
к ограниченному диапазону.
Все программы, использующие эту схему и обращающиеся к
результату двухсимвольного преобразования, должны изменяться
одновременно.
Вследствие преобразования данных влияние на производительность
может быть прямо пропорциональным количеству дат, обрабатываемых
конкретным приложением.
В зависимости от выбора реализованного представления данных
может происходить неправильная сортировка данных, если не
расширена логика программирования.
Закодированные даты требуют преобразования всякий раз при
работе с данными; присутствие закодированных дат добавит к задачам
другой уровень сложности.
Данные должны быть преобразованы прежде, чем они смогут
отображаться в григорианском формате; некоторые закодированные
данные могут просматриваться только в шестнадцатеричном формате.
Прием последовательной даты
Преимущества
Во многих случаях форматы записи не должны изменяться.
Недостатки
Он сложен; должен быть хорошо задокументирован.
Может влиять на производительность при преобразовании дат из
последовательного значения или в него.
3.2. Списание (отказ от использования)
Изучение исходных модулей выявляет, что в хранилище
присутствует устаревший исходный код, который больше не
используется или не нужен в производственной среде. Процесс, с
помощью которого эти программы систематически удаляются из
производственной среды, называется списанием. Он обладает
преимуществом сокращения как общих трудовых затрат на проект 2000
года, так и затрат на хранение.
Проблемы
Критичность приложения и его функциональность в связи с
интерфейсами, промежуточным программным обеспечением (middleware),
другими приложениями, входными и выходными данными.
Архивирование данных и приложения для будущего обращения.
Списанное приложение должно быть задокументировано в
информационных целях и для будущего проектирования и разработки.
Рекомендуемый подход
Определите деловое значение приложения на этапе оценивания
проекта 2000 года.
Следующие условия должны быть выполнены, чтобы списать
приложение:
- приложение не обслуживает никакую текущую деловую функцию;
- не имеется никаких интерфейсов, использующих входную или
выходную информацию приложения;
- слишком дорого преобразовывать приложение в соответствующее
2000 году;
- приложение не будет использоваться в будущем.
Заморозьте приложение, заархивируйте его и задокументируйте
процесс списания. Документация должна содержать такие детали, как
дата списания, фамилия ответственного лица, краткое описание того,
как будет учтена функциональность приложения, и другую полезную
информацию (по решению ответственного лица).
Если списание приложений производится поэтапно, то готовится
план поэтапного вывода приложений из использования.
Советы
Приложения, без которых учреждение может существовать или
которые имеют альтернативное рабочее окружение, становятся
кандидатами на списание, особенно если процесс, выполняемый
приложением, больше не является необходимым или другие прикладные
программы выполняют тот же самый деловой процесс.
3.3. Замена
Назначением данного раздела является определение метода
замены, а также описание стратегий преобразования для не
соответствующих 2000 году ресурсов.
Техническое обеспечение, программное обеспечение и / или
программно - аппаратное обеспечение могут не соответствовать 2000
году и, следовательно, могут потребовать замены. Замена включает
покупку пакетного решения или разработку нового решения,
основанного на проекте существующей системы. Если не
соответствующие 2000 году техническое обеспечение, программное
обеспечение и / или программно - аппаратное обеспечение, выбранные
для замены, не будут заменены до критических сроков 2000 года, то
должен существовать план чрезвычайных обстоятельств.
Проблемы
При существующей системе, находящейся в эксплуатации, имеется
ограниченный промежуток времени для установки и сдачи в
эксплуатацию новой системы.
Текущая система может быть старой, не очень хорошо понимаемой
и / или плохо задокументированной.
Обучение новой системе потребует времени и ресурсов; они могут
быть ограничены.
Проблемы управления рисками возникают для приложений, замену
которых планируется завершить до 2000 года, но она может быть
отсрочена или даже отменена.
Деловой риск возникает из времени опережения, необходимого для
выполнения преобразования, когда не удалось соблюсти контрольные
сроки 2000 года.
Разработанные по заказу приложения могут иметь неадекватные
программы обработки даты. Изменение или обновление исходного кода
может быть дорогостоящим и требующим много времени.
Пакеты программ должны быть заменены соответствующими 2000
году версиями (upgrades) или другими продуктами.
Во время преобразования данные могут быть потеряны из-за
модификации полей.
Могут потребоваться новые инструментальные средства для штата
программистов, включая:
- системы анализа влияния;
- инструментальные средства управления изменениями или
контроля версий;
- утилиты быстрого изменения и замены;
- инструментальные средства тестирования.
Соответствующие продукты, такие, как операционные системы,
системы управления базами данных, компиляторы, интерфейсы и т.д.,
должны соответствовать 2000 году.
Зависимость от интерфейсов создает сложности при
интегрировании новой системы в существующую среду.
Рекомендуемый подход
Определите, является ли замена наилучшим решением для
вытесняемых, зависящих от даты приложений. Имеются некоторые
преимущества и недостатки выбора замены в качестве решения. Вот
некоторые из них.
Преимущества
Возможность заменять устаревшие пакеты и системы последними
разработками.
Добавление долгосрочной гибкости.
Возможность получать преимущество в конкурентной борьбе от
того, что иначе должно быть работой по сопровождению.
Недостатки
Это рискованный метод, учитывая короткое время для реализации.
Новая система требует дополнительных ресурсов.
Не все новые покупные программы соответствуют 2000 году.
Определите метод замены: "делать" или "покупать". При
управлении процессом внутренним образом или при передаче третьей
стороне каждая система должна быть проанализирована для
определения метода замены. Решение "делать" включает замену
существующей системы системой, основанной на оригинале. Решение
"покупать" влечет за собой закупку и внедрение пакета программ.
"ДЕЛАТЬ", если:
- изготовленные на заказ системы обеспечивают значительное
стратегическое преимущество над покупными пакетными системами;
- пакетные системы плохо интегрируются в финансовые системы;
- пакетные системы не являются гибкими и / или
сбалансированными для роста;
- имеются достаточные внутренние или внешние доступные
ресурсы, такие, как технический опыт и возможности тестирования,
чтобы преобразовывать системы;
- времени достаточно, чтобы разработать и внедрить
изготовленное на заказ приложение или систему;
- пакетные системы не отвечают всем требованиям пользователей.
"ПОКУПАТЬ", если:
- затраты на то, чтобы "сделать", больше затрат на то, чтобы
"купить";
- требуются стандартные методы обработки, такие, как
стандартные финансовые действия, стандартные подпрограммы закупки
и т.д.;
- существующие системы находятся в конце своего жизненного
цикла и требуют значительного сопровождения или не обладают
возможностями, необходимыми для удовлетворения сегодняшних
потребностей;
- имеются достаточные ресурсы, чтобы купить новую систему, но
не для того, чтобы сделать новую систему.
Разработайте и выполните план преобразования. Он должен
основываться на критичности систем, сроках отказа и приоритетах.
План преобразования должен также включать стратегию
преобразования. Имеются четыре типа стратегии преобразования:
параллельный, поэтапный подход, пилотный и прямой переход.
Используемая стратегия будет зависеть от заменяемой системы,
однако для большинства проектов преобразования 2000 года
рекомендуется поэтапный подход, так как он обеспечивает меньшую
степень воздействия на текущую работу, увеличивая возможность
параллельной разработки вследствие более низких требований к
ресурсам, и создает минимальный риск по сравнению с другими
стратегиями.
Проверьте все новые продукты и системы, а также существующие
системы, на которые может повлиять замена.
Внедрите, оцените и измените новую систему, основываясь на
изменяющихся требованиях пользователей и приемо - сдаточных
критериях пользователей.
Разработайте план чрезвычайных обстоятельств. Может оказаться
необходимым преобразовывать приложения, если проект замены не
удастся выполнить в контрольные сроки.
Советы
Оцените затраты для обоих альтернативных вариантов метода
замены. Обратите внимание на то, что затраты метода "делать" могут
использоваться в обосновании замены пакета.
Оба метода потребуют не только поддержки высшего руководства,
но также специальных распоряжений для сосредоточения усилий всех
служащих на проекте 2000 года.
Используйте следующий контрольный список при выборе пакета
прикладных программ:
- функциональные возможности - обеспечивает выполнение всех
необходимых Функций;
- гибкость - легко модифицировать или настраивать;
- дружелюбие по отношению к пользователю - прост в
использовании и обеспечивает управление;
- аппаратные и программные ресурсы - способен поддерживать
существующие ресурсы;
- характеристики базы данных - поддерживает текущие требования
обработки и поиска;
- установка - процесс не требует много усилий и времени;
- сопровождение - поставщик предоставляет продолжающееся
сопровождение и поддержку;
- документация - ясная и полная;
- качество поставщика - приложение разработано опытными
разработчиками;
- затраты - учесть любые дополнительные затраты (плата за
сопровождение, расширение возможностей, модернизация и т.д.);
- соответствие 2000 году - продукт уже соответствует 2000
году.
Так как аппаратные средства и их операционные системы
заменяются регулярно, новые системы должны проверяться на
соответствие 2000 году.
План чрезвычайных обстоятельств должен установить контрольные
точки и стратегии резервирования. В каждой контрольной точке
руководство должно делать обзор развития проекта замены и решать,
нужно ли обращаться к стратегии резервирования.
3.4. Поддержание соответствия 2000 году
Принятие необходимых мер для поддержания соответствия -
ответственность каждого использующего компьютер для создания
приложения, электронной таблицы, базы данных и т.д. Хотя
первоначально основное внимание уделялось техническому
обеспечению, операционные системы, приобретенное программное
обеспечение и купленные приложения не могут оставаться без
внимания. При введении не соответствующих 2000 году форматов даты
в соответствующую 2000 году систему учреждение рискует разрушить
уже достигнутое соответствие и увеличить стоимость проекта.
Проблемы
Недостаточная осведомленность о проблеме 2000 года и
потенциальной катастрофе, грозящей учреждениям; отсутствие
ощущения срочности.
Порча соответствующих 2000 году систем путем введения систем,
которые не соответствуют 2000 году.
Трудности с разработкой и соблюдением во всех учреждениях
стандартов соответствия 2000 году.
Интерфейсы; связь четырехзначных приложений с двузначными
может оказаться катастрофической.
Затруднение доступа к архивным файлам, использующим двузначный
формат даты.
Обеспечение того, чтобы рутинное сопровождение не вносило
новых проблем 2000 года.
Рекомендуемый подход
Разработайте метод управления изменениями, вносимыми в
техническую среду. Сюда включается:
- проверка соответствия поставщика перед подписанием заказов
на покупку;
- доведение до сведения поставщика требований о необходимости
абсолютного соответствия продукта;
- запрос письменной документации, поддерживающей соответствие
новых систем;
- использование соответствующих положений во всех договорах.
Ясно определите, какие системы соответствуют 2000 году, какие
приводятся в соответствие и какие являются частью новой
разработки.
Должен выполняться сквозной просмотр кода, который проверяет
соблюдение стандартов разработки.
Все компоненты системы должны тщательно тестироваться и
утверждаться как соответствующие 2000 году. По завершении приемки
система становится частью регулярного процесса сопровождения. При
внесении изменений в систему соответствие 2000 году должно
проверяться снова.
Документируйте изменения, производимые в среде.
Избегайте изменения форматов даты, когда достигнуто
соответствие 2000 году, пока такое изменение не станет для
приложения критическим.
Советы
Установите стандарты учреждения по проекту 2000 года
относительно типов данных даты / времени во всех системах. Эти
стандарты должны соблюдать все пользователи.
Создайте ощущение срочности у технического персонала путем
ознакомительных семинаров, передачи сообщений, памятных записок и
через другие формы эффективного общения.
Учреждения должны учесть следующее:
- положения о соответствии 2000 году должны быть введены во
все договоры, касающиеся закупок и услуг;
- разработка новых систем должна следовать стандарту
учреждения;
- должен вестись точный постоянный учет всех систем до
1 января 2000 года и далее;
- необходимо проверять соответствие 2000 году любой системы,
вводимой в среду.
Выполняйте периодические проверки данных для обеспечения
однородного присутствия столетия в структурах баз данных, где даты
были расширены.
4. Проектирование
4.1. Управление проектом
Управление проектом - приложение знаний, умений,
инструментальных средств и методик для планирования действий,
чтобы удовлетворить потребности и ожидания проектировщиков или
превысить их. Соответствие потребностям и ожиданиям или их
превышение включает уравновешивание конкурирующих требований
(таких, как охват, время, затраты и качество), объектов с
различными потребностями и ожиданиями, а также определенных
потребностей и неопределенных ожиданий.
В данном документе определяются и описываются основные
процессы и приемы управления проектом. Цель проекта - создать
стратегию для приведения всех систем учреждения в соответствие
2000 году. Должны быть определены руководитель проекта и,
возможно, консультант проекта. Для всех членов проектной группы
должны быть разработаны и задокументированы роли и обязанности.
Проблемы
Опытные программисты могут быть недоступны.
Документация для существующих систем может быть недоступна.
Должны учитываться проблемы многоплатформенности, например,
приложения для мейнфреймов, к которым обращаются из ПЭВМ.
Предположения
Будет издан документ проекта, включая обзор.
Будут проведены исследования инструментальных средств всех
платформ.
Больше времени будет отведено на замену, чем на обновление,
если это будет оправданно.
Устаревшие программы не будут обновляться.
Будет уделено внимание основным проблемам библиотеки программ.
Рекомендуемый подход
Полная опись системы должна быть подготовлена на этапе
оценивания (может потребоваться ее обновление).
Определите связанные с датой поля и переменные, которые
вызываются, вычисляются, сравниваются, сортируются, вводятся и
выводятся.
Определите опись для обновления.
Определите сложности обновления.
Установите приоритеты обновляемых приложений, основываясь на
их критичности.
Разработайте процессы преобразования.
Определите инструментальные средства и приемы, которые будут
использоваться.
Определите необходимость обучения для процессов и
инструментальных средств.
Сгруппируйте и определите последовательность реализации
модулей и отметьте зависимости.
Оцените время для каждого модуля.
Разработайте план ресурсов этапа преобразования, включая
требуемую квалификацию.
Добейтесь понимания от высшего руководства и лиц, принимающих
решения.
Обзор процесса управления проектом
Организация проекта
Организация проекта должна включать всех участников проекта.
Должен быть разработан документ "Роли и обязанности" для всех
членов проектной группы.
План работ проекта
План работ должен быть создан с использованием
инструментальных средств типа Microsoft Project или Project
Workbench. План должен организовать проект по этапам, действиям,
задачам и датам. Он должен также создавать критический путь. Все
ресурсы и все результаты должны быть связаны с конкретными
задачами.
Управление изменениями проекта
Роль управления изменениями проекта заключается в контроле за
осуществлением изменений в проекте. Чтобы гарантировать наличие
этого контроля, создайте документ на одной странице, в котором
отражаются типы модификаций, процедуры и роль руководства в их
решении.
Обеспечение качества систем
План обеспечения качества систем должен быть частью проекта
2000 года. Он может включать сквозной просмотр проекта, ранние
обзоры результатов (набросков) и обзор проекта. Система
обеспечения качества должна использоваться в течение всего
проектирования.
Контроль за изменениями исходных кодов
Вследствие объема программного кода, на который может быть
оказано воздействие при выполнении проекта 2000 года, очень важным
является наличие плана контроля за изменениями исходных кодов.
Должно планироваться применение автоматизированного
инструментального средства, помогающего справиться с параллельными
изменениями программ.
Рабочие документы
Следующие документы должны обновляться и издаваться по крайней
мере каждые две недели.
План работ проекта
Этот план должен постоянно обновляться, и изменения должны
регулярно передаваться членам группы.
Проблемы / решения
Каждой задаче проекта должен быть назначен ресурс и задана
целевая дата решения. Поскольку это проект 2000 года, то смещения
целевых дат не может быть.
Состояние проекта
Отчет о состоянии проекта должен включать результаты за
последний период, основные задачи на следующий период и краткое
описание состояния. Нужно обеспечить еженедельную передачу отчета
от каждого участника рабочей группы руководителю проекта.
План чрезвычайных обстоятельств
Независимо от того, насколько тщательно запланированы работы
по решению проблемы 2000 года, в последние минуты могут возникнуть
неожиданности. Задача руководителя проекта - определить
потенциальные риски и управлять ими. Вряд ли 100% проблем будет
решено вовремя, поэтому сосредоточьтесь на критических приложениях
и их зависимостях. Выполните следующие шаги:
- документируйте все изменения, сделанные в любом приложении;
- проверьте каждый модуль тщательно, насколько возможно;
- составьте список неизмененных модулей или приложений, чтобы
знать возможные области отказа.
В случае отказа
Создайте процесс для выполнения задач, которые могут
неправильно работать из-за сбоев, связанных с 2000 годом.
Производите обучение процессу основного персонала. В случае
отказа приложения деловые процессы могут стать более
продолжительными и потребовать большего количества работников;
будьте готовы к этому.
Советы
Сосредоточьтесь на критических приложениях, которые будут
обновляться; не потеряйте из виду цель.
Разработайте специальный процесс аудита для проверки того, что
улучшение / сопровождение существующих прикладных программ
соответствуют 2000 году.
4.2. Файлы и базы данных
Цель данного раздела - представить рекомендуемый подход для
обнаружения и поддержания соответствующих 2000 году файлов и баз
данных.
При преобразовании 2000 года может потребоваться изменение
файлов и баз данных, чтобы принять четырехзначный формат года.
Каждый файл или база данных может потребовать уникального решения,
основанного на функциональных возможностях базы данных или файла.
Определить влияние часто помогает связь между данными и файлом или
базой данных.
Проблемы
Отсутствие стандартных форматов даты, используемых в записях,
файлах, таблицах и базах данных. Обнаружение данных и кода,
связанных с датой, вследствие неоднородных соглашений по
именованию.
Правовые проблемы, касающиеся изменений в исторических данных,
должны исследоваться до внесения любых изменений. Во многих
случаях изменения, вносимые в архивированные файлы, могут сделать
недействительным файл или всю архивную систему.
Документация существующих систем и подсистем может быть
недоступна.
Рекомендуемый подход
Определите категории файлов и баз данных согласно
функциональным возможностям; категории выделяются по усмотрению
руководителя проекта.
Файлы
Категории файлов могут включать следующее, но не
ограничиваться им:
- ссылки на поле;
- физический, логический и коммуникационный;
- программный;
- дисплейный;
- принтерный.
Базы данных
Примеры объектов базы данных:
- таблицы;
- запросы;
- формы;
- отчеты;
- функции;
- хранимые процедуры;
- триггеры базы данных;
- представления.
Рассмотрите переменные даты, функции или подпрограммы даты,
символьные строки с датами и т.д. для прямых или косвенных ссылок
к следующим данным и форматам, связанным с датой:
- схема данных;
- макеты файлов;
- программы (например, коды доступа, процедуры, функции,
триггеры и т.д.);
- CopyLib.
Определите, какие требуются форматы ввода и отображения данных
года (двузначные или четырехзначные); убедитесь, что используются
правильные цифры, если выбран двузначный формат.
Классифицируйте использование / ссылку связанных с датой полей
данных как имеющие сильное или слабое влияние.
Сильное влияние
Представление года двумя цифрами внутри программы, которое не
имеет внутренних появлений (exposures), но превращается во внешнее
и может иметь ссылку на себя в другой программе.
Представление года двумя цифрами, имеющее внутренние
появления.
Связанные с датой данные и переменные имеют ссылки,
вычисляются, сравниваются, сортируются, вводятся и выводятся.
Слабое влияние
Только для отображения; представление года двумя цифрами в
приложении не имеет внутренних появлений, однако имеет внешние
появления, но на них нет ссылок.
Представление года двумя цифрами внутри приложения не имеет
внутренних или внешних появлений.
Оцените критичность каждого появления даты начиная с
приложений с высоким влиянием. Определите, как, когда и где
появление будет воздействовать на файлы и базы данных, основываясь
на вышеупомянутых результатах.
Определите соответствующий метод изменения, чтобы устранить
проблему перехода к новому столетию. (Более подробную информацию
см. в разделе "Обновление".)
4.3. Интерфейсы
Назначение данного раздела - представить подход, гарантирующий
соответствие 2000 году импортируемых или экспортируемых системами
учреждения данных и принятие мер для предохранения от порчи не
соответствующими 2000 году данными технической среды учреждения.
Интерфейсы позволяют осуществлять обмен данными между
приложениями. Такой обмен может происходить внутри учреждения,
между учреждениями и / или между учреждением и внешней
организацией.
Проблемы
Обмен данными между деловыми партнерами, где используется
логика обработки дат, может привести к внедрению не
соответствующих 2000 году данных в среду учреждения.
Определение и отслеживание состояния всех интерфейсов является
серьезной работой и потребует координации с деловыми партнерами и
группой проекта 2000 года учреждения.
Использование мостов и брандмауэров станет необходимым, если
деловые партнеры не смогут соблюсти контрольные сроки соответствия
или примут стандарты, отличающиеся от стандартов учреждения.
Учреждения могут кооперироваться с внешними деловыми
партнерами при экспорте данных и будут в конечном счете принимать
решения, как получать данные в свою среду.
Потребуется систематический подход, чтобы координировать и
документировать связи с деловыми партнерами, соблюдение принятых
рекомендаций и качественное управление проектом.
Некоторые интерфейсы могут быть не учтены или пропущены.
Типы интерфейсов
Интерфейсы могут содержать:
- прикладные интерфейсы,
- EDI (стандарт электронного обмена данными),
- Internet,
- электронную почту,
- распространение лент, дисков и т.д.,
- ручной ввод,
- FTP (протокол передачи файлов).
Рекомендуемый подход
Разработайте механизм (например, электронную таблицу) для
инвентаризации и отслеживания соответствия 2000 году всех
интерфейсов. Механизм отслеживания должен включать следующую
информацию:
платформу,
систему,
имена наборов данных / файлов,
описание,
отправку или прием,
тип носителя,
предлагаемый формат,
плановую дату соответствия,
действительную дату соответствия,
внутренний контакт и телефон,
описание внешней организации,
внешний контакт и телефон,
частоту,
текущий формат,
примечания.
Интерфейсы должны быть включены в планы оценивания, обновления
и тестирования проекта 2000 года. Все интерфейсы должны быть
протестированы на соответствие 2000 году.
Планы чрезвычайных обстоятельств должны включать процессы,
выполняемые в случае, если соответствие 2000 году не будет
достигнуто деловым партнером, а обмен данными должен продолжаться
после контрольного события.
Положение о разрешении споров должно использоваться при
общении с поставщиками и выполняться, когда расхождение в подходах
или планах между партнерами требует проведения переговоров и
отслеживания документов.
Советы
Постоянно рассматривайте и изменяйте при необходимости план
проекта для интерфейсов, чтобы управлять воздействием новых
приложений или изменений на существующие приложения.
Проводите периодические совещания по осуществлению проекта;
основной персонал может обмениваться опытом и информацией
относительно успешных подходов и решений и отчитываться о
состоянии работ.
Интерфейсы, которые должны быть протестированы:
- информация от системы к учреждению;
- информация в систему из учреждения;
- интерфейсы с деловыми партнерами;
- интерфейсы с внешними поставщиками услуг.
4.4. Мосты
Назначение данного раздела - помочь организаторам проекта и
техническому персоналу разработать приемы создания мостов,
делающие мосты прозрачными и оказывающие минимальное воздействие
на производительность.
Создание мостов - это прием, который используется для
организации интерфейса между двумя или более системами или
программами. Программа - мост обычно читает файл данных в одном
формате и преобразует его в формат другой программы или системы.
Применительно к проблеме 2000 года мосты могут связывать с помощью
интерфейса системы с одним форматом даты или с разными форматами
даты.
Проблемы
Системы, совместно использующие данные, не могут быть
исправлены и запущены в производство одновременно.
Программы - мосты увеличивают нагрузку на систему.
В зависимости от выбранного метода создания мостов может
потребоваться дополнительная мощность вследствие увеличения
использования центрального процессора и дополнительной памяти,
требуемой для логики моста.
Уровни обработки трансакций большого объема могут подвергаться
влиянию обращений ввода / вывода к программе - мосту.
Программы - мосты могут потребовать как расширения поля, так и
включения логики моста для ввода / вывода в программы.
Рекомендуемый подход
Определите число подверженных влиянию 2000 года приложений. В
процессе обновления система, применяющая расширение даты до
четырех цифр, часто использует данные совместно с другими,
неизмененными, системами.
Создайте план обновления, основанный на приоритетности и
критичности.
Определите места, где могут потребоваться мосты. (Существующие
и разрабатываемые приложения также должны рассматриваться.)
Определите метод создания мостов. Имеется четыре типа мостов:
разработанные на заказ, пакетные, он - лайновые и изменение
программы.
Тесты моста в реальном масштабе времени должны быть выполнены
для определения того, нормально ли мост функционирует. Мост должен
принимать двузначные и четырехзначные форматы, преобразовывать оба
формата даты и правильно сохранять даты.
Установите мост. Мосты должны оставаться в производстве, пока
не будут заменены или обновлены внутренним или внешним образом все
взаимосвязанные приложения.
Советы
Программы - мосты являются временными решениями. В начале
преобразования 2000 года для каждого моста должны быть установлены
даты истечения срока использования.
Мосты должны иметь значимые имена. Это поможет в отслеживании
мостов и упростит процесс их удаления.
Мосты не должны быть удобным местом для внесения исправлений,
не связанных с 2000 годом, поскольку это приведет к вторичным
проблемам сопровождения при удалении моста.
При реализации вариантов моста избегайте необходимости
выполнять корректировки файлов в режиме он - лайн, набирая
трансакцию дважды (один раз для допустимых в отношении 2000 года
данных и один раз для данных, не допустимых в отношении 2000
года). Пропускайте записи данных через фильтр и позвольте
производить корректировку отдельным программам корректировки.
Мост должен:
- быть динамическим; требовать минимального количества логики
ввода / вывода;
- удовлетворять требованиям производительности; минимизировать
внешние и внутренние обращения;
- поддерживать достаточную целостность данных;
- содержать достаточно много проверок;
- основываться на спецификациях преобразования, выработанных в
процессе модификации.
4.5. Функции даты
Назначением данного раздела является ознакомление с различными
методами, которыми даты представляются в приложениях, и
установление стандарта для нотации даты.
Функции даты связаны с тем, как приложение или процесс
использует и вычисляет даты. Существует много различных способов
использовать даты, например, преобразование григорианской даты в
юлианскую и обработка относительных форматов даты. Варианты
решения проблемы 2000 года часто связаны с эффектами инверсии и
логикой високосного года. При наличии стандартной функции даты
можно легко определять даты и выполнять операции с ними.
Проблемы
До проектирования или приобретения функции даты должны
рассматриваться следующие проблемы.
Эффекты инверсии вызываются программами, которые
интерпретируют "00" скорее как "1900", чем "2000", и по ошибке
выполнят вычисления, скорее, на 99 лет в прошлое, чем на 1 год в
будущее.
Нестандартная логика включает следующее:
- Общие соображения относительно логики даты могут быть
различными, сложными или простыми, но большей частью логика даты
оформляется в виде специальных подпрограмм даты.
- Поиск текущей даты определяет, отыскивается ли текущая дата
из предопределенного источника, такого, как файл, таблица или
компьютерные часы. Доморощенные методы часто реализуют "хитрое"
использование поиска даты. Их трудно понять, трудно сопровождать,
и они очень неэффективны.
- Усечение высокого порядка происходит, когда вычисления идут
полностью неправильно и промежуточные переменные слишком малы,
чтобы сохранить результаты. В таком случае могут быть потеряны
знак и / или наиболее значимые цифры.
- Значения даты по умолчанию могут использоваться
беспорядочно, без какого-либо учета 2000 года. Использование дат
по умолчанию очень трудно отслеживать, оно может преподнести
неприятные сюрпризы.
Прочие проблемы
- Когда дата является частью ключа, существует риск, что даты
со значениями года "00" будут отыскиваться перед датами со
значениями года "99", хотя "2000" идет после "1900".
- Даты и логика даты могут находиться в макрокомандах, Wylbur
Execs, CMS Execs, Rexx Execs, запросах, отчетах, триггерах,
процедурах, функциях и т.д.
- Даты, которые встроены в имена наборов данных или внутри
структур данных.
Логика високосного года состоит из трех правил високосного
года, как определено в 1582 году римским папой Григорием XIII:
- если год делится без остатка на 4, то он является
високосным;
- если год делится без остатка на 100, то он не является
високосным;
- если год делится без остатка на 400, то он является
високосным.
Год 2000-й - високосный год.
Рекомендуемый подход
Установите стандарт для нотации даты.
Проанализируйте и выберите продукт функции даты, который лучше
всего подходит для приложения. Эти продукты разделяются на
следующие пять категорий:
- имитаторы системной даты;
- анализаторы кода;
- дополнительная функция даты;
- улучшения (upgrades) языка;
- преобразователи (конверторы) баз данных.
Советы
Рекомендуемым стандартом даты является нотация даты стандарта
ISO 8601. Международной стандартной нотацией даты является
YYYY - MM - DD.
Преимущества нотации даты стандарта ISO 8601 по сравнению с
другими обычно используемыми вариантами:
- легко читается и записывается программным обеспечением;
- легко сравнивается и сортируется с помощью обычного
сравнения строк;
- не зависит от языка;
- не может быть спутана с другими популярными нотациями даты;
- короткая и имеет постоянную длину;
- представление года четырьмя цифрами позволяет избежать
проблем переполнения после 1999-12-31.
4.6. Архивные данные
Настоящий раздел касается данных, которые должны сохраняться в
исторических или правовых целях определенный промежуток времени.
Архивные данные за много лет могут стать бесполезными вследствие
их несоответствия 2000 году. Могут быть сильно затруднены или даже
стать невозможными анализ тенденций, исторические исследования,
оценка эффективности и т.п.
Многие более старые приложения используют двузначный формат
даты для ввода и хранения данных. Если к таким архивным файлам
обратится соответствующая 2000 году система, то они могут стать
причиной получения системой неточных результатов или прекращения
ее функционирования.
Проблемы
Архивные данные могут не включаться в проект 2000 года.
Архивные данные содержат обычно двузначный формат года, что
может повредить соответствующим 2000 году системам.
Приложения, обращающиеся к архивным данным, заменяются или
изменяются для соответствия 2000 году.
Рекомендуемый подход
Рассмотрите график сохранения записей.
Определите все файлы архивных данных, которые должны вестись.
Определите, содержат ли эти файлы даты и в каком формате эти
даты хранятся.
Определите приложение, используемое для поиска и обработки
этих данных, и определите его соответствие 2000 году.
Определите, какой процесс должен использоваться, чтобы
обеспечить доступность данных после 2000 года.
Расширьте связанные с датой данные путем добавления
предполагаемого двузначного столетия.
Создайте мост в приложении, который будет систематически
преобразовывать данные из двузначных дат в четырехзначные,
позволяя текущему программному обеспечению оставаться в
использовании без нарушения соответствующих 2000 году систем.
Ничего не делайте, если 2000 год не влияет на процесс поиска
данных.
4.7. Управление изменениями
Назначением данного раздела является определение процедур,
которые будут минимизировать влияние на внесение изменений, но
позволят продолжить обслуживание способом, который защищает
целостность данных и минимизирует нарушение обслуживания.
Управлением изменениями являются разрешение, выполнение и
запись изменений. Управление изменениями помогает предотвратить
введение ошибок в производственную систему и обеспечить учет (то
есть руководитель проекта должен знать, почему было сделано
изменение, каким было его влияние на стоимость, план и другие
факторы, кто был инициатором изменения и кто согласился делать
необходимые изменения).
Проблемы
Контроль изменений исходных кодов, производимых вне проекта
2000 года.
Может остаться неизвестной одновременная работа над
программами, что приводит к перезаписи кода или
несанкционированным изменениям.
Конфликты в уровнях версий могут происходить из-за ошибок,
срочных исправлений или параллельной разработки.
Неточная версия кода может использоваться из-за программистов,
вводящих элементы с тем же самым именем или использующих
предшествующую версию на секционированном (partitioned) наборе
данных.
Обновленные приложения сбоят после развертывания или являются
причиной сбоев зависимых приложений.
Возможное влияние на план внедрения.
Изменения могут увеличить затраты. Финансирование затрат на
изменение может быть ограниченным и доступным только в
определенные промежутки времени.
Рекомендуемый подход
Процесс управления изменениями, которому необходимо следовать
во время преобразования 2000 года, включает следующие этапы.
Осознание изменения
Изменения могут быть сделаны в техническом обеспечении,
программном обеспечении, сопровождении, эксплуатации, документации
и временных модификациях. Во время преобразования 2000 года
изменение часто происходит в исходном коде, файлах и базах данных,
а также интерфейсах пользователя.
Представление заявки на изменение
Все заявки на изменение представляются разработчиком -
инициатором для анализа влияния. Разработчик - инициатор должен
также рекомендовать, когда заявки на изменение должны быть
реализованы, основываясь на следующих критериях:
- план обновления;
- размер изменения;
- вопросы регрессионного тестирования.
Оценивание разработчиками
Связанные с изменением разработчики будут изучать заявку на
изменение и проводить анализ влияния с соответствующим
техническим, управленческим персоналом, персоналом обеспечения
качества и персоналом пользователей. Анализ влияния включает такие
вопросы, как срочность, риск, требования регрессионного
тестирования, управление изменениями, план обновления, затраты,
надежность и постоянство. Анализ должен быть задокументирован,
приложен к соответствующей заявке на изменение и содержать
запрошенное изменение, определяющие факторы, альтернативные
решения, потенциальное влияние на другие приложения, регрессионные
тесты для повторной проверки и изменения в документации
пользователя.
Оценивание управления изменениями
До реализации должен состояться эффективный процесс
исследования. Для этого необходимо:
- убедиться, что технические инспекции были выполнены
адекватным образом;
- убедиться, что пакет изменения полон и готов для реализации;
- убедиться, что все необходимые внешние утверждения были
получены;
- предпринять соответствующее действие утверждения, основанное
на этих проверках.
Когда согласие не может быть достигнуто, представитель
пользователя принимает решения о приоритете работ по
удовлетворению требований бизнеса / пользователя и администратор
приложения принимает решения, основываясь на технических вопросах,
касающихся затрат и приоритетных ограничений.
В случае утверждения изменения производятся модификация,
тестирование и внедрение, а в противном случае оформляется
отклонение заявки на изменение.
Отклонение заявки на изменение
Заявка на изменение может быть не принята для реализации по
одной или более из следующих причин: плана обновления, затрат или
постоянства. Разработчик - инициатор должен быть уведомлен об
отказе и осведомлен о ходе предпринимаемых действий.
Модификация
Когда изменение утверждено, разработчик, назначенный на
изменение, может проверить элемент конфигурации программного
обеспечения и выполнить корректирующее действие. Разработчик
отвечает также за ведение записей о произведенных действиях по
изменению.
Тестирование
Тестирование необходимо, чтобы определить, что изменение
работает правильно и функциональность системы не была нарушена.
Изменение не должно вводить ошибки в систему, и измененные
приложения должны работать в рамках нового и первоначального
диапазонов дат.
Внедрение
Внедряться будут только санкционированные и проверенные
изменения. При утверждении более обширных изменений разработчик
должен представить на утверждение новый анализ влияния.
После физической реализации изменений, но прежде чем
приложение запускается в производство, проводится соответствующее
приемо - сдаточное тестирование, чтобы гарантировать, что
изменение способно удовлетворить требованиям своего
проектирования.
Советы
Механизм управления изменениями должен обеспечивать следующее:
- текущую информацию о влиянии и конфигурации в режиме он -
лайн, давая разработчику возможность знать воздействие изменения в
начале процесса;
- информацию об изменении в режиме он - лайн в течение
изменения. Это поможет в процессе планирования и поможет
гарантировать, что все требуемые части включены в процесс
корректировки;
- уведомление, когда несколько разработчиков пытаются
обратиться к модулю. Это защитит от проблемы двух разработчиков,
по незнанию решающих различные задачи сопровождения в отношении
одного и того же модуля.
Обеспечьте условия для нескольких уровней сопровождения и
автоматического уведомления и управления. Это гарантирует, что все
участвующие стороны знают о модификациях программы и краткосрочные
модификации включены в долгосрочный проект. Программное
обеспечение может также содержать возможности запрета параллельной
разработки, если изменение не определено как срочное.
База данных управления изменениями может быть полезна в
накоплении и отслеживании информации об изменениях.
Используйте самую высокую степень экономически эффективной
автоматизации. Автоматизированные инструментальные средства
управления изменениями облегчают этот процесс.
Создавайте резервную копию исходного кода до выполнения
модификаций. Имейте также проверенную процедуру поиска резервной
копии кода. Она будет полезной, когда не проходит тестирование,
произошла перезапись кода или когда в исходный код внесены
несанкционированные изменения.
Разработайте формальные механизмы управления изменениями для
каждой из следующих категорий:
- участие руководства;
- управление проектом;
- контроль исходного кода;
- механизмы тестирования / разработки;
- доставка объектов;
- управление готовностью;
- координация / планирование эксплуатации;
- отслеживание проблем;
- исторический анализ;
- распределенные и интегрированные пакеты управления
изменениями;
- объектно - ориентированные пакеты управления изменениями.
4.8. Соглашения по именованию
Назначением данного раздела является определение стандартов и
соглашений, используемых при именовании объектов и атрибутов.
Во время преобразования 2000 года, возможно, необходимо будет
создать и правильно именовать хранилища, библиотеки, файлы, базы
данных и т.д. Используя стандарты именования, которым легко
следовать, проектировщики системы могут производить продукты,
которые не приведут к неоднозначному или неправильному пониманию.
Проблемы
Большинство инструментальных средств анализа влияния основано
на методах сканирования текста, построенных исключительно на
соглашениях именования полей.
Во время разработки никакие соглашения по именованию не
использовались или использовались неоднородные соглашения.
Аббревиатуры имен или усеченные имена данных использовались
без официальных стандартов.
Имена данных не указывают на использование данных; данные те
же самые, а имена различные.
Использовались омонимы или синонимы.
Синтаксический анализ данных; запутанное соглашение по
именованию либо алгоритм неизвестен, утрачен или не существует.
Приложения поставщика, "заплаты" или исправления могут
использовать соглашения по именованию, специфические для продукта.
Рекомендуемый подход
Определите существующие соглашения по именованию, используемые
для описания даты. Некоторые примеры имен даты дает следующий
список.
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 годом, серьезные системные сбои и т.д.);
- ожидаемый период жизни плана (как долго можно продолжать
работать в аварийном режиме);
- роли и обязанности;
- процедуры для перехода на аварийный режим;
- процедуры для работы в аварийном режиме;
- план ресурсов для работы в аварийном режиме (например,
обеспечение кадрами, планирование, материалы, запасы, помещения,
временное техническое и программное обеспечение, связь и т.д.);
- критерии для возврата в режим нормальной работы;
- процедуры для возврата к режиму нормальной работы;
- процедуры для восстановления утраченных или искаженных
данных.
По мере приближения дат запуска готовьтесь задействовать планы
чрезвычайных обстоятельств.
Следите за эффектом, оказываемым планами чрезвычайных
обстоятельств на другие процессы.
------------------------------------------------------------------
АИСС БКБ, www.orioncom.ru, tel (495) 783-5510