Приложение 9Б: Пример целей Управления релизами для распределенных систем

Приложение 9Б: Пример целей Управления релизами для распределенных систем

■ В идеале Пользователи должны иметь полную организационную гибкость: функции зависят от людей, а не от их местоположения. Это значит, что все рабочие станции должны иметь доступ ко всем функциям. Однако «меню» каждого Пользователя должно составляться Пользователем и генерироваться во время регистрации пользователя при входе в систему.
■ Чтобы разрешить замену неисправных рабочих станций, все они должны обладать идентичной конфигурацией, и данные не должны храниться локально. Это подразумевает одинаковое ограниченное число приложений на всех рабочих станциях и доступ к большей части ПО на сервере.
■ Должна иметься возможность распространять небольшие программные изменения в сети за одну ночь, например, в случаях необходимости внедрения срочного решения. Возможно, это также приведет к тому, что все прикладное ПО должно будет храниться только на серверах.
■ Должна иметься возможность распространять синхронизированные обновления всех компонентов приложения по сети (например, координация изменений в ПК или в мейнфрейм-системах). Это легче всего проделать при единой системе распространения и контроля.
■ У Пользователей должен быть единый логин для всех систем и оборудования, и все их права доступа и функции должны быть основаны на этом логине.
■ Контроль за функциями, доступными Пользователю, должен быть скрыт от локальных Пользователей, чтобы им не было известно о существующих программных механизмах.
■ Контроль и распространение ПО после первоначальной установки Релиза должны быть автоматизированы и требовать минимальных затрат.
■ Должен быть гарантированный механизм доставки/уведомления о получении вместе с защищенными ключами на всех неисправных рабочих станциях, чтобы невозможно было использовать старый код.
■ Должен быть возможен быстрый откат после внесения Изменений вместе с возможностью «заморозить» использование неисправных приложений.