Модельная задача для

Типовое решение: «корпоративная почта для СМБ»
Модельная задача
Участникам предлагается представить проект создания корпоративной почтовой системы
для холдинга, специализирующегося на предоставлении консультационных услуг.
Общее количество пользователей в компании составляет 500. Для удобства
моделирования предполагается, что количество почтовых ящиков совпадает с
количеством пользователей. На центральный офис приходится 300, на каждый из 3
филиалов по 50, 50 адресов используется внешними сотрудниками (фрилансерами).
Модельная компания имеет центральный офис, представительства в 3 других городах и
разветвленную сеть фрилансеров, работающих удаленно. В общем, описываемая
структура свойственна большинству сервисных компаний, которые могут оказывать
услуги в самых разнообразных областях: реклама, маркетинг, бухгалтерия, недвижимость,
ИТ-аутсорсинг и др.
Бизнес компании существенно зависит от средств коммуникации и коллективной работы,
прежде всего -- электронной почты и систем организации групповой работы (groupware).
Корпоративный стандартом общения внутри и вне организации -- электронная почта. 70%
рабочего времени большинство сотрудников проводит в командировках, однако, несмотря
на это, им необходим постоянный доступ к почте и groupware-серверу. Задержка с
ответом на запрос может стоить многомиллионного контракта и значительного ущерба
репутации. Эта особенность также определяет повышенные требования к доступности,
безопасности и отказоустойчивости почтовой системы.
Базовый набор задач проекта:
 обмен электронной почтой и организация рассылок;
 возможность организации защиты (от вредоносных программ и спама);
 глобальная адресная книга (с разграничением прав доступа);
 функции резервного копирования.
Желательные возможности:
 возможность дистанционного подключения к серверу с мобильных ПК и смартфонов;
 средства организации коллективной работы (календари, планировщики задач,
оповещения);
 функции централизованного администрирования;
 поддержка гетерогенной ИТ-инфраструктуры (разнообразие операционных систем как
внутри отдельных офисов, так и между ними);
 минимизация ресурсов, выделяемых на административное управление почтовой
системой.
ИТ-инфраструктура модельной компании
400 из 500 пользователей используют операционную систему Windows XP, 50 – Windows
Vista, 50 – MacOS X, 50 -- Linux. 50 пользователей постоянно пользуются смартфонами
под управлением Windows Mobile и Symbian -- причем, для них желательно предоставить
возможность как работы с электронной почтой, так и системами групповой работы. На
компьютерах и смартфонах отсутствует дополнительное ПО для организации электронной
почты.
Конфигурация офисных ПК: Процессор 1,5 GHz/256Mb RAM/50Gb HDD
 Серверная платформа: Windows 2000 или Windows Server 2003, Данные об учетных
записях пользователей хранятся в службе каталогов Microsoft Active Directory.
 Количество серверов: 1 -- основной почтовый, 1 -- вспомогательный (файловый,
Интернет, печать и др.).
 Конфигурация почтового сервера: P4/2 ГГц, 1 Гбайт памяти, 300 Гбайт свободно на
диске.
 Конфигурация вспомогательного сервера: P4/2 ГГц, 512 Гбайт памяти, 80 Гбайт
свободно на диске.
 Конфигурация офисных ПК: Celeron/2 ГГц, 256 Мбайт памяти, 3 Гбайт свободного
места на диске
Компания готова выделить средства для обеспечения почтового сервиса (программное и
аппаратное обеспечение для клиентской и серверной части), необходимые для безопасной
и отказоустойчивой работы. Вместе с тем, заказчик ценит соотношение цена/качество и
предпочитает тратить средства эффективно. Таким образом, участникам предлагается
предоставить стоимость и описание не только собственно почтовой системы, но также и
оценку трудозатрат на интеграцию с учетом «системного ландшафта».
Персонал
Для администрирования почтовой системы выделен системный инженер средней
квалификации. Большинство сотрудников имеют только общие знания о работе с
компьютером и мобильными устройствами.
Примерный план
В описании проекта рекомендуется акцентировать внимание на конкретных деталях
решения и процесса внедрения системы. В рамках данной задачи мы не рассматриваем
вопрос выбора конкретной системы, принимая как аксиому, что покупатель заинтересован
и проблема перешла в практическую плоскость: подгонка решения под специфику
компании, интеграция, внедрение и др. Важно не то, _какие_ задачи решаются, а в том
_как_ именно выглядит это решение.
В частности, желательно осветить следующие вопросы (это некий ориентировочный
минимум информации, необходимый для подготовки материалы, если возникнет
необходимость раскрыть нечто дополнительно -- можно добавить):
1. Описание модельной задачи, если вы внесли в нее изменения
2. Задачи и схема работы
2.1.
Принципы организации и подходы к решению базового набора задач, их
обоснование (почему именно такие решения -- не технические, а архитектурные
-- были заложены в вашу систему)
2.2.
Дополнительные (в смысле, выходящие за пределы базового) возможности и
задачи, решаемые системой
2.3.
Особенности и отличия от аналогов
3. Техническая реализация
Архитектура системы (монолитная, модульная, со встроенным языком
программирования и конфигурациями, etc.).
3.2.
Системные требования к серверу (аппаратные и программные)
3.3.
Системные требования к рабочим местам (аппаратные и программные)
3.4.
Прочие требования (если есть)
3.5.
Технические ограничения (в части количества информации, числа
пользователей, лицензионные, и др.)
3.6.
Ориентировочная производительность системы на заданной в условиях
модельной задачи конфигурации (в том числе в пиковых ситуациях, например,
активной работе всех пользователей)
3.7.
Другие технические особенности
3.8.
Основные рекомендации по оптимизации ИТ-инфраструктуры и системного
ландшафта (если таковые есть; под «оптимизацией» понимается обеспечение
нормальной работы системы, а не всей ИТ-инфраструктуры компании в целом,
как пример можно привести рекомендацию увеличения количества серверов,
мощности рабочих мест, покупке дополнительного ПО и др.).
Схема внедрения (пошаговый алгоритм) с конкретизацией каждого действия
4.1. Предпроектное обследование (какие вопросы следует изучить, на что обратить
особой внимание, что и как отразить в ТЗ, и др.)
4.2. Порядок оформления договора и работ (основные этапы)
4.3. Первоначальная установка и настройка (как система должна быть интегрирована с
существующей ИТ-инфраструктурой, пусть даже та сводится к паре серверов,
какие могут возникнуть проблемы при импорте и синхронизации баз данных и
справочников и как они решаются, разграничение прав и безопасность, в том
числе от инсайдеров.)
4.4. Описание интерфейса системы и основных операций (рекомендуется отметить
уникальные интерфейсные решения, если таковые имеются)
4.5. Человеческий фактор (чему надо будет учить пользователей, насколько по опыту
проста система в пользовании, др.).
Эксплуатация и администрирование системы
5.1. Описание типичных операций при решении повседневных задач
5.2. Техобслуживание (список регулярных операций, которые должен будет выполнять
администратор, рекомендации администратору и др.)
5.3. Решение проблем (как организованы процедуры исправления ошибок, обновления
системы при выходе новых версий и др.).
5.4. Возможности наращивания и масштабируемость при росте организации (как
организованы процедуры покупки новых лицензий, насколько потребуется
нарастить серверные мощности, скажем, при росте компании в два раза, при
слиянии с другой компанией и др.).
Экономическая часть (обязательна)
6.1. Оценочная стоимость реализации модельной задачи в целом
6.2. Схема лицензирования программных компонентов системы и стоимость лицензий
6.3. Примерная смета и перечень работ (в виде таблицы)
6.4. Прогнозируемые результаты внедрения и экономическая эффективность (в
проекции на ранее описанную структуру)
Приложения (желательные)
7.1. Схема
7.1. Снимки экранов (рекомендуется 3--5 наиболее показательных, с пояснениями)
7.2. Список реализованных проектов сходного типа (3-5 с кратким, до 500 символов,
описанием каждого)
Контактная информация
8.1. Название компании
3.1.
4.
5.
6.
7.
8.
8.2.
8.3.
8.4.
8.5.
Сайт компании
Контактное лицо
Телефоны для связи
Email для связи
Объем материала
Общий объем итогового описания -- до 30 Кбайт, включая таблицы (если таковые
планируются), но не менее 10 Кбайт. Техническое описание, подготовленное участником,
полностью публикуется в разделе «Техническая библиотека» сайта PC Magazine/RE
(www.pcmag.ru), на его основе также формируется вариант статьи для журнала
(сокращенный, до 5 Кбайт). Журнальный вариант утверждается участником перед
публикацией.
Последовательность этапов проекта:
1. Подтверждение готовности участвовать в проекте: до 9 июля 2007 г. (понедельник)
2. Подготовка решения и передача материалов в редакцию: 12 июля 2007 г. (четверг)
3. Вычитка материалов (своих разделов) участниками и отправка из в редакцию: 16
июля 2007 г. (понедельник, включительно)
4. 4. Публикация материала: номер поступает из типографии в розничные сети и
подписчикам до 10 августа
5. Публикация технических описаний решений в «Технической библиотеке» сайта PC
Magazine/RE: 10--15 августа