- •Дипломный проект
- •Реферат
- •Перечень сокращений и терминов
- •Онтологическое соглашение проекта
- •Введение
- •Глава 1. Анализ предметной области
- •Услуга Colocation
- •Общие понятия услуги colocation
- •Услуги цод (colocation)
- •История развития цод и услуг colocation
- •Происхождение вида
- •Всеобщая цоДофикация
- •Аутсорсинг.
- •В регионы за электричеством.
- •Мировая мода.
- •Проблемы «озеленения».
- •Основные задачи, решаемые системой комплексного менеджмента colocation-проектов.
- •Пример методика ценообразования услуг
- •Обзор конфигураторов услуг и сервисных калькуляторов в сфере услуг colocation и аутсорсинга, представленных в Росии.
- •Что же такое сервисный калькулятор или конфигуратор услуг?
- •Компания europrojects.
- •Резюме:
- •Выводы.
- •Глава 2. Выбор и обоснование средств разработки и технологий реализации
- •Выбор программной платформы разработки системы.
- •Выбор технологии
- •Трехуровневая архитектура “клиент-сервер”
- •Выбор субд
- •Выбор языка программирования
- •Выбор web – сервера
- •Выбор программно-аппаратной платформы разработки информационной системы.
- •Обеспечение отказоустойчивости решения.
- •Использование failover кластера (отказоустойчивого кластера).
- •Принцип функционирования кластера.
- •Персональный компьютер пользователя (Клиент)
- •Глава 3. Разработка информационной системы
- •Проверка закона распределения данных по критериям к.Пирсона (критерии согласия)
- •Разработка и реализация пользовательского интерфейса
- •История развития веб-дизайна от технической графики до современных сайтов
- •Зарождение идей о юзабилити сайтов
- •Современный этап развития веба
- •Разработка пользовательского интерфейса
- •Архитектура и структурная схема информационной системы
- •Функциональная схема информационной системы
- •Глава 4. Модель оценки результативности работы системы. Расчет технических характеристик системы
- •Расчет математического ожидания ис.
- •Расчет производительности.
- •Расчет обобщенной энтропии информационной системы
- •Расчет интегральной информационной нагруженности информационной системы
- •Расчет надежности информационной системы
- •Надежность аппаратной части
- •Надежность программной части
- •Глава 5. Менеджмент проекта
- •Введение
- •Ступень дивергенции
- •Ступень трансформации
- •Ступень конвергенции
- •Ступень релаксации
- •Ступень ликвидации
- •Глва 6. Выбор и обоснование модели жизненного цикла информационной системы
- •Введение
- •Итеративный подход
- •Подход, основанный на фазах и вехах
- •Модель проектной группы msf
- •Фаза выработки концепции
- •Фаза планирования
- •Фаза разработки
- •Фаза стабилизации
- •Фаза внедрения
- •Глава 7. Экономическая часть проекта
- •Аннотация
- •Организация работ
- •Структура организации работ
- •Система управления производством работ
- •Бизнес-план
- •Конкуренция на рынке
- •Расчет сметной стоимости (себестоимости) проекта
- •Затраты на материалы и покупные изделия
- •Основная зарплата научного и производственного персонала
- •Дополнительная заработная плата
- •Оценка экономической эффективности проекта
- •Оценка рисков и поиск путей их минимизации
- •Заключение
- •Глава 8. Экологичность и безопасность проекта
- •Введение
- •Оптимальные условия труда на рабочем месте разработчика.
- •Расчет освещения.
- •Расчет системы вентиляции.
- •Расчет влаговыделения
- •Расчет тепловыделения.
- •Определение потребного воздухообмена
- •Проектирование системы вентиляции.
- •Глава 9. Проверка на соответствие стандарту гост р исо/мэк 15288:2005
- •Глава 10. Информационно-социальная компонента
- •Цод крупным планом: Креатив и Экзистенция
- •Увидеть лес среди деревьев
- •Не до идеалов
- •Принцип деления Цодов
- •Справка
- •Системы жизнеобеспечения
- •Как со всем этим справиться?
- •Приложение 1. Техническое задание
- •1.1 Полное наименование системы и ее условное обозначение
- •1.2 Шифр темы
- •1.3 Наименование предприятий разработчика и заказчика системы и их реквизиты
- •1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы
- •1.5 Плановые сроки начала и окончания работы по созданию системы
- •1.6 Сведения об источниках и порядке финансирования работ
- •1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы, по изготовлению и наладке отдельных средств и программно-технических комплексов системы
- •2.Назначение и цели создания системы
- •2.1 Назначение системы
- •Требования к системе
- •4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы
- •4.1.1.4 Требования к режимам функционирования системы
- •4.1.1.5 Требования по диагностированию системы
- •4.1.1.6 Перспективы развития, модернизации системы
- •4.1.2 Требования к численности и квалификации персонала системы и режиму его работы
- •4.1.4.4 Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами
- •4.1.5 Требования безопасности
- •4.1.6 Требования к эргономике и технической эстетике
- •4.1.7 Требования к транспортабельности для подвижных ас
- •4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
- •4.1.8.2 Предварительные требования к допустимым площадям для размещения персонала и тс системы, к параметрам сетей энергоснабжения и т. П.
- •4.1.8.3 Требования по количеству, квалификации обслуживающего персонала и режимам его работы
- •4.1.8.4 Требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов
- •4.1.8.5 Требования к регламенту обслуживания
- •4.1.9 Требования к защите информации от несанкционированного доступа
- •4.1.10 Требования по сохранности информации при авариях
- •4.3.3 Требования к программному обеспечению
- •Требования к техническому обеспечению
- •4.3.5 Требования к лингвистическому обеспечению
- •4.3.6 Требования к метрологическому обеспечению
- •5. Состав и содержание работ по созданию системы
- •6. Порядок контроля и приемки системы
- •8. Требования к документированию
- •9. Источники разработки
- •Приложение 2. Техническое предложение
- •3. Техническая характеристика
- •4. Описание и обоснование выбранной конструкции
- •5. Расчеты, подтверждающие работоспособность и надежность конструкции
- •6. Описание организации работ с применением разрабатываемого изделия
- •7. Ожидаемые технико-экономические показатели
- •8. Уровень стандартизации и унификации
- •Приложение 3. Технические условия
- •1.1 Наименование и назначение системы
- •1.2. Условия эксплуатации
- •2. Технические требования
- •2.1 Требования назначения
- •2.2 Требования к программной совместимости
- •2.3 Требования к производительности и точности
- •2.4 Требования к надежности
- •3. Требования безопасности
- •4. Требования охраны окружающей среды
- •5. Правила приемки
- •6. Методы контроля
- •7. Указания по эксплуатации
- •Приложение 4. Инструкция для всех групп пользователей
- •Приложение 5. Листы графики
- •Приложение 6. Описание демо-версии
- •Приложение 7. Текст доклада
- •Доклад окончен. Спасибо за внимание!
Не до идеалов
Еще один постулат: идеальной платформы не существует. В доказательство можно использовать метод «от противного»: если бы такая идеальная платформа была, мы все, в 90% случаев, работали сейчас именно на ней. Существование же остальных 10% объяснялось бы присутствием в IT-среде наследованных приложений, по тем или иным причинам не поддающихся переносу в идеальную среду. Синергия двух описанных факторов неотвратимо ведет к появлению разнородных систем. Так стоит ли бояться появления «зоопарка»? И да, и нет одновременно — таков обычный ответ IT-менеджеров. С одной стороны, потребитель получает традиционную и вечную проблему с децентрализацией технической поддержки и громадную схему формата А0 с указанием алгоритма действия в случае возникновения той или иной проблемы: если то — звонить туда, а если это — сюда. Дальнейшие действия, и это хорошо известно, напоминают настольный вариант популярной игры в мяч ракетками. С другой стороны, это IT-решение наиболее полно отвечает потребностям предприятия и четко настроено под насущные задачи бизнеса. Но это как раз решение той основной задачи, которая стоит перед IT-подразделениями. Современный ЦОД — всегда парк разнородных систем. Другое дело, насколько данный парк может и должен быть гетерогенным. Вот здесь и начинается настоящее творчество для специалистов.
Любая неоднородность повышает общую энтропию системы. Для ее уменьшения существует весьма эффективный инструмент — корпоративный стандарт. Противники такого подхода говорят об ограничении конкуренции и о трудности реализации некоторых решений. Для сторонников основными аргументами служат унификация сервисного обслуживания и сокращение стоимости владения. Те и другие правы. Тогда в чем преимущество? В правильно установленной границе введения корпоративного стандарта. Этот инструмент хорошо применяется там, где существуют массовые закупки товаров одного класса или где он определяет основополагающий элемент IT-инфраструктуры. К первым относится периферийное оборудование, рабочие места пользователей, расходные материалы. Ко вторым, например, операционная среда, в которой работают основные бизнес-приложения. Введение корпоративных стандартов может оказаться полезным, поскольку сокращает число возможных вариантов отдельных видов продукции, сохраняя определенную степень свободы выбора и, что немаловажно, обеспечивая необходимую безопасность — «безсюрпризность» этого выбора.
Унификация систем с помощью инструментария корпоративного стандарта или без такового позволяет решать еще одну очень важную задачу — обеспечение обслуживания как можно большего числа пользовательских рабочих мест минимально возможным числом системных администраторов. Проблема квалифицированных IT-специалистов стоит остро не только в России, но и во всем мире. Для многих наших заказчиков один из основных вопросов — привлечение и удержание персонала. Особенно остро данная проблема ощущается в государственном секторе. Дефицит квалифицированных кадров отчасти можно компенсировать аутсорсингом. Несмотря на то что на 100% аутсорсинговые схемы крупные организации не используют, многие из них начали применять этот механизм частично. Например, известны случаи применения аутсорсинговых схем для обслуживания корпоративной сети федерального уровня или для обслуживания парка рабочих станций. Основным сдерживающим фактором для применения 100% аутсорсинговых схем является боязнь заказчиков потерять контроль над собственной IT-инфраструктурой и, самое главное, над сохранением полной безопасности конфиденциальной информации. Многие думают именно так, хотя на самом деле в первом случае контроль остается, а во втором — это не относится к аутсорсингу. Риск всегда существует, а его уровень определяется правилами подбора персонала и отношениями между наемными сотрудниками и работодателями. Аусторсинг является простейшим с организационной точки зрения, но не единственным способом обеспечения непрерывности работоспособности IT-инфраструктуры. Здесь нужно сделать важную оговорку: речь идет о бесперебойности работы именно IT-инфраструктуры, а не об обеспечении бесперебойности бизнеса в целом. События в США 11 сентября 2001 года послужили своеобразным катализатором и наглядно продемонстрировали, зачем и почему необходимо уделять особое внимание вопросам обеспечения бесперебойности бизнеса и работоспособности IT-инфраструктуры. Основы решения таких вопросов известны давно — это катастрофоустойчивые центры обработки данных, кластерные системы, резервное копирование, бесперебойное электропитание, доступная связь и квалифицированный персонал.