Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - bas

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
331
Народ,

Среди нас есть любители спорта? А в частности футбола??

Я сам наш футбол не очень люблю, но этот матч смотреть буду. ИМХО у наших мало шансов.

332
Вот только-что прислали документ из одной немало известной компании документ под названием: "Vision по созданию ...."

Содержание такое:
1   Введение   3
1.1   Цель   3
1.2   Описание бизнес проблем   3
1.3   Ограничения задачи   4
1.4   Нормативные документы   4
1.5   Список согласователей   4
1.6   Глоссарий   4
2   Бизнес-требования   5
2.1   Область применения   5
2.2   Требования к процессам   7
2.3   Требования к экранным формам   7

Параграф Цель начинается так:
"Документ содержит требования к формированию ...."
Хотя в этом разделе есть цели, но воды больше :)

В общем уж не называли бы так документы если писать не могут ...

333
Сообщество Аналитиков / Визитки
« : 12 Сентября 2007, 12:49:14 »
Народ,

В преддверии очередного семинара м.б. сделаем визитки с логотипом сайта. А то на семинаре происходит иногда обмен оными, а у меня вообще никакой визитки нет (к своему стыду).
Это должно быть не очень дорого. Если надо, то я провентилирую вопрос где можно сделать и сколько будет стоить (должно быть не дорого)

Простенький дизайн может моя жена сделать, с указанием:
1. Логотипа сайта
2. Адрес сайта
3. ФИО
4. Контактной инфы (тел, мыло)
5. Ссылку на профиль в моем круге.

334
Последние обновления этого раздела см. здесь: http://www.uml2.ru/index.php?option=com_content&task=category&sectionid=3&id=29&Itemid=53


1. Что такое требования?
IEEE Standard Glossary of Software Engineering Terminology определяет требования как:
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
3. документированное представление условий или возможностей для п. 1 и 2

2. Какие бывают требования?
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.
- Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.
- Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
- Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
- Системные требования (system requirements) - это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.
- Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
- Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта
- Характеристика продукта (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта.

3. Каких требований не должно быть?
Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании. Для проекта, как правило, создаются требования других типов: документ, где описана среда разработки, ограничения бюджета, руководство
пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду. Все это относится к требованиям к проекту, но не к продукту.

4. Какими характеристиками должны обладать хорошие требования?
Характеристики качества превосходных требований:
- Полнота Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.
- Корректность Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.
- Осуществимость Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды. Чтобы не придумывать недостижимые положения, обеспечьте взаимодействие разработчиков с маркетологами и аналитиками требований на период всего извлечения требований. Разработчики реально оценят, что можно выполнить технически, а что нет, или что сделать можно, но при дополнительном финансировании. Инкрементальная разработка и подтверждающие концепцию прототипы позволяют проверить осуществимость требования.
- Необходимость Каждое требование должно отражать возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения. Отследите каждое требование вплоть до стадии сбора мнений пользователей, когда выявлялись варианты использовании,
бизнес-правила или другие источники.
- Назначение приоритетов Назначьте приоритеты каждому функциональному требованию, характеристике или варианту использования, чтобы определить, что необходимо для каждой версии продукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки,
Дополнительная информация В главе 14 назначение приоритетов обсуждается в деталях.
- Однозначность Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.
- Проверяемость Попробуйте разработать несколько тестов или примените другие приемы для проверки, например экспертизу или демонстрации, чтобы установить, действительно ли в продукте реализовано каждое требование. Если требование не проверяется, вопрос его корректной реализации становится предметом заключения, а не целью анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются

5. Какими характеристиками должны обладать спецификации требований?
Набор требований, составляющий спецификацию должен отвечать характеристикам:
- Полнота Никакие требования или необходимые данные не должны быть пропущены.
- Согласованность Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Несогласованность документов следует устранить до начала процесса разработки. Вы не всегда знаете, какое именно положение некорректно (если какое-то некорректно), пока не выполните исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен.
- Способность к модификации Необходимо обеспечить возможность переработки требований, если
понадобится, и поддерживать историю изменений для каждого положения. Для этого все они должны быть уникально помечены и обозначены, чтобы вы могли ссылаться на них однозначно. Каждое требование должно быть записано в спецификации только единожды. Иначе вылегко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные утверждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и указатель. Сохранение спецификации в базе данных коммерческого инструмента управления требованиями сделает их пригодными для повторного использования.
- Трассируемость Трассируемость, или возможность для анализа, можно реализовать как в направлении назад, к первоисточникам, так и вперед, к элементам дизайна и исходному коду, который его реализует, а также к вариантам использования, которые позволяют проверить корректность, реализации. Трассируемые требования помечены соответствующими идентификаторами. Они записаны в структурированной, детализированной форме, в противоположность параграфам в длинной повествовательной форме. Избегайте слипания множества требований в один ком, отдельные требования можно трассировать к различным элементам дизайна и кода.

6. Что в себя включает дисциплина по управлению требований?
К действиям по управлению требованиями относятся:
- определение основной версии требований (моментальный срез требований для конкретной версии продукта);
- просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
- включение одобренных изменений требований в проект установленным способом;
- согласование плана проекта с требованиями;
- обсуждение новых обязательств, основанных на оценке влияния изменения требований;
- отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;
- отслеживание статуса требований и действий по изменению на протяжении всего проекта.

7. Какие есть программные средства управления требовниями?
Наиболее известные - это Rational RequisitePro, Borland CaliberRM, Telelogic DOORS.
Все средства и их сравнительные характиристики указаны здесь:
http://www.uml2.ru/forum/index.php?topic=208.0

8. Какие есть права и обязанности у Клиента во время работы с требованиями?
- Перед началом проекта ознакомьте Клиента с его обязанностями:
1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса
2. Потратить столько времени, сколько необходимо, на объяснение требований
3. Точно и конкретно описать требования к системе
4. Принимать своевременные решения
5. Уважать определённую разработчиком оценку стоимости и возможность реализации ваших
требований
6. Определять приоритеты требований
7. Просматривать документы с требованиями и оценивать прототипы
8. Своевременно сообщать об изменениях требований
9. Поддерживать принятый в организации-разработчике порядок контроля изменений
10.Уважительно относиться к методам, с помощью которых аналитики создают требования

- Перед началом проекта ознакомьте Клиента с его правами:
1. Иметь дело с аналитиком, который разговаривает на вашем языке
2. Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается
система
3. Потребовать, чтобы аналитик преобразовал требования, предоставленные вами устно,
в письменную спецификацию требований к программному продукту
4. Получить от аналитика подробный отчет обо всех рабочих продуктах, созданных
в процессе формулирования требований
5. На уважительное и профессиональное отношение к вам со стороны аналитиков
и разработчиков
6. Знать о вариантах и альтернативах требований и их реализации
7. Описать характеристики, упрощающие работу с продуктом
8. Изменить требования или разрешить использование имеющихся программных компо-
нентов
9. Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых
компромиссах, которые возникают в связи с изменениями в ПО
10. Потребовать, чтобы система функциональностью и качеством удовлетворяла требования
заказчика

9. Что такое антитребования?
Антитребование - это некое утверждение, что не должна делать программа. Например: "Программа не должна иметь внешнего загрузчика файлов". Хорошая спецификация должна иметь антитребования, чтобы явно описать, что программа не должна делать.

335
О Сайте и Форуме / Обновление сайта
« : 16 Июля 2007, 16:48:46 »
Переезд сайта на новый хостинг запланирован на сентябрь. В связи с этим надо выработать четкое техническое решение для обновления сайта.

Пойдем по всей строгости.

1. Цели.
1.1. Предоставление качественной бесплатной информации в области анализа, проектирования и методологий/нотаций разработки ПО
1.2. Предоставление бесплатной экспертизы в этой области
1.3. Привлечение спонсоров
1.4. Реклама наших платных услуг: консалтинга и семинаров в данной области

2. Проблемы.
2.1. Не корректная работа форума и сайта
Решение: переезд на другой хостинг
2.2. Сайт перегружен не нужной информацией
Решение: оставить только нужный функционал:
- материалы
- новости
- ссылки
- блоги
- форум
- регестрация только на форуме (на сайте убрать)
2.3. Плохая структурированность  информации и как следствие сложный поиск
Решение: Реструктуризация материала
2.4. Редкая пополняемость сайта статьями/ссылками/книгами
Решение: Привлечь спонсоров и за условное вознаграждение (скажем 100 дол/месяц) заинересовать людей для выполнения этой задачи
2.5. Не привлекательность дизайна
Решение: Привлечь спонсоров и заказать дизайн на стороне
2.6. Хранение пиратской копии книг
Решение: Указывать ссылки на внешние источники

3. Основной Функционал
3.1. Сайт без регистрации для всех пользователей, а только для выделенных пользователей
3.2. Форум с регистрацией, не меняется
3.3. Хранилище документов/файлов на сайте с возможностью указывать не только внутренние файлы, но и ссылки
3.4. Новости
3.5. Ссылки
3.6. Блог

336
Просьба проголосовать, кто был на семинаре.
Чтобы проголосовать, надо зарегистрироваться.
Если регистрироваться совсем лень, оставьте здесь хотя бы коммент.
Спасибо.

337
О Сайте и Форуме / Новый хостинг
« : 09 Июля 2007, 12:28:18 »
Народ!

Пришла очередная дата оплаты за хостинг (он должен быть оплачен через 14 дней).
Но я не к деньгам :)

Многим не нравится существующий хостинг из-за глюком и ошибок. Поэтому предлагайте куда можно перехать, бум думать.
Требования:
1 гб простарнства
PHP
MySql
не более 15 дол./ месяц


338
IDEF ARIS BPMN и пр. / BPMN - Материалы по BPMN
« : 06 Июля 2007, 22:59:39 »
Нашел очень интересный Tutorial по BPMN:
http://www.omg.org/bpmn/Documents/OMG_BPMN_Tutorial.pdf

339
Впервые 30 августе в одном из ночных клубов состоИТся праздник- тусовка "мИТинг". Приглашаются все, кто имеет отношение к сфере ИТ.

ВХОД БЕСПЛАТНЫЙ ПО
ПРЕДВАРИТЕЛЬНОЙ
РЕГИСТРАЦИИ

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

Здесь Вы можете встретИТь потенциального инвестора, работодателя, сотрудника и партнера.

ВыходИТе из виртуальности в реальность! Всем будет весело! Программа мИТинга будет опубликована в ближайшее время.

Зарегистрироваться и узнать более подробную информацию можно здесь.

340
12 июля, в четверг, UML2.ru и компания Luxoft проведут семинар на тему

«Концепция системы и варианты использования (use-cases)»

Докладчики - сотрудники компаний CSoft, Afisha Digital, Egar Technology, Luxoft

Программа семинара:
# Целеполагание как разработка модели целей, проблем и решений
# Увязывание модели целей с моделями процессов и сущностей
# Образец модели концептуального документа
# Диаграммы UC для согласования интересов
# Отношения include и extend на практике
# Особенности UC, типовые ошибки и проблемы
# Границы применимости UC - когда нужны бизнес-UC
# Трансформация моделей UC в ходе проекта по RUP: бизнес-UC, системные UC и модель классов
# UC уровня реализации как наиболее точные спецификации

Начало в 19:00, длительность ~2 часа.

Узнать, как добраться и записаться можно по ссылке. Посещение бесплатное, но обязательна регистрация. При регистрации пожалуйста указывайте свои настоящие ФИО.

341
Sparx / FAQ - Sparx Enterprise Architect
« : 28 Июня 2007, 14:44:49 »
Общие вопросы

Что такое Enterprise Architect?
EA – CASE-инструмент для проектирования и конструирования программного обеспечения. EA поддерживает спецификацию UML2.0, описывающую визуальный язык, которым могут быть определены модели проекта.
Некоторые из ключевых функций ЕА:
- создание элементов UML-моделей широкого круга назначения;
- размещение этих элементов в диаграммах и пакетах;
- создание коннекторов между элементами;
- документирование созданных элементов;
- генерация кода для конструируемого ПО;
- реверс-инжиниринг имеющегося кода на некоторых языках.
Используя EA, можно выполнять форвард и реверс-инжиниринг ActionScript, C++, C#, Delphi, Java, Python, PHP, VB.NET and Visual Basic классов, синхронизировать код и элементы моделей, проектировать и генерировать элементы баз данных. Из моделей может быть быстро создана документация в стандартном rtf-формате и импортирована в Word для финального редактирования, так же доступна генерация HTML-документов.
EA поддерживает все модели/диаграммы UML 2.0. С его помощью можно моделировать бизнес-процессы, веб-сайты, пользовательские интерфейсы, сети, конфигурации аппаратного обеспечения, сообщения и т.д., оценивать размер трудозатрат проектных работ в часах, фиксировать и трассировать требования, ресурсы, тест-планы, дефекты и запросы на изменения.
Т.о. EA – современный инструмент, который поддерживает все аспекты цикла разработки, обеспечивая полную трассировку от начала проектирования до размещения и поддержки. Также он обеспечивает поддержку тестирования, управления сопровождением и изменениями.

Какова архитектура EA?
Архитектурно Enterprise Architect представляет собой программу – рабочее место EA, из которого осуществляется соединение через собственный драйвер БД с проектным репозитарием, организованным в виде базы данных. В качестве базы данных по умолчанию используется Microsoft Jet. Так же  в качестве сервера БД могут использоваться SQL Server, MySQL, Oracle 9i и 10g, PostgreSQL, Adaptive Server Anywhere, MSDE Server, Progress OpenEdge.
На рабочем месте хранятся пользовательские настройки этого рабочего места, такие как настройки отображения панелей инструментов, набор горячих клавиш и т.д.
В проектном репозитарии хранятся следующие элементы моделирования:
- объекты модели, такие как UML-элементы и пакеты;
- коннекторы, которые связывают взаимодействующие объекты;
- диаграммы, отображающие объекты, коннекторы и ссылки на другие диаграммы.
При этом один элемент может быть отображен на нескольких диаграммах, но физически как объект базы данных он хранится только в одном экземпляре. Т.о. удаление элемента на диаграмме не вызывает удаление объекта из репозитория.
Также в проектном репозитарии хранится дополнительная и служебная информация:
- дополнительные справочники, такие как глоссарий, авторов моделей, задач, проблем, дефектов и пр.;
- настроечные справочники, такие как типы стереотипов, пользовательских тегов, шаблонов отчетов и т.п.
- шаблоны проектирования, такие как UML-паттерны и UML-профили, позволяющие сохранять и быстро воспроизводить типовые решения, смоделированные ранее.
- базовые линии, т.е. моментальные снимки состояния пакетов в XML-формате.
Для обмена информацией между репозитариями используется экспорт/импорт файлов XML-формата.

Существует ли в природе русскоязычный help (или документация) по EA?
Нет, не существует.

Особенности и недостатки
Инструмент конечно удобный, но не без недостатков. Многое приходится делать через контекстное меню, что порой раздражает. Есть проблемы с портированием элементов. Особенно достали плавающие дорожки, как их портировать?Не совсем удобен перенос фигур - стрелками нельзя.
Почему-то нельзя менять шрифт тегов ограничений наименований ассоциаций - что довольно странно. Но в целом инструмент нравится.

Глюки
Обнаружена некоторая проблема с редактированием шрифтов, например, ставлю жирный шрифт, а ставится все равно не жирный, но это не так страшно. Просто попробуйте - сделайте сначала некую диаграмму, выделите все и измените шрифт, скажем 12 жирный Arial. Затем присоедините любую картинку (фотку нечто еще) и увидите: размер не изменился, а жирность исчезла.

Лицензирование

Какие преимущества дает корпоративный режим EA?
Корпоративный режим EA позволяет создавать базы данных репозитариев на MySQL, SQL Server, PostgreSQL, Sybase Adaptive Server Anywhere  и Oracle9i. Также в корпоративном режиме включена поддержка MDG-технологий и MDG-связок (MDG Link). Еще этот режим поддерживает систему безопасности с правами пользователей, групп пользователей и блокировкой на уровне элементов и диаграмм. Возможны 2 режима работы системы безопасности: в первом режиме все элементы доступны для изменения до момента блокировки их пользователем или группой, во втором режиме все элементы заблокированы до экспорта и блокировки пользователем.

Можно ли каким-нибудь образом "переключить" EA в "корпоративный режим" (т.е. сделать его corporate edition)?
Можно, для триального EA с сайта нужно взять ключик по ссылке http://www.sparxsystems.com.au/resources/corporate/index.html
Но это удовольствие будет работать 30 дней.

Источники информации для ответов на вопросы
Help к EA, входящий в поставку, информация с сайта производителя http://www.sparxsystems.com.au/ , личный опыт участников форума UML2.ru

Об авторе
FAQ оформлен участником форума Irr

343
Обязанности модератора раздела:

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

- следить, чтобы добавлялись только корректные высказывания, как личные так и общие
- следить, чтобы ответы сильно не отклонялись от темы дискуссии (удалять оффтоп)
- переносить темы в соответствующий раздел, если они не соответствуют тематике текущего раздела

- при редактировании, удалении или переноса темы/ответа обязательно писать причину красным наклонным шрифтом либо в текущем сообщении, либо в дополнительном

344
Вот рассказали тут анекдот про консультантов, долго смеялся :

Цитировать
Завсегдатай ресторана спрашивает официанта:
- Слушай, что такое - почему все официанты ходят теперь с ложечкой в кармашке?
- Видите ли, хозяин пригласил консультантов, они обследовали наш бизнес и выдали заключение, что официанты тратят очень много времени когда клиент роняет ложечку и мы идём на кухню за другой. Предложили оптимизацию - мы теперь носим ложечку с собой.
- Аааа, какие молодцы!
В следующий раз снова спрашивает:
- Слушай, что такое, почему теперь у всех официантов из ширинки торчит верёвочка?
- Опять были консультанты. Провели обследование, выдали заключение - мы тратим очень много времени когда идём в туалет, достаём, потом моем руки, вытираем, ... Предложили оптимизацию - привязали верёвочку, чтобы руками не доставать.
- Аааа, какие молодцы!
- Хм, слушай, ну доставать - понятно, а убирать-то как?
- Не знаю кто как, а я ложечкой ....

345
Вот что написала Агава (наш хостер):

Цитировать
Добрый день.

Сообщаем, что 2 июня в субботу в Дата-Центре будут производиться
работы по модернизации сети электропитания. В связи с этим
будет произведено кратковременное отключения каждого сервера от
электропитания. Каждый сервер будет недоступен около часа.

Во время проведения работ возможнадеградация качества связи.

Приносим извинения за доставленные неудобства.

---
Служба поддержки хостинга Agava.Ru, support@agava.com

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »