Уважаемые пользователи сервиса SeoRate.ru!

Мы рады сообщить о запуске новой версии нашего сервиса. Переключение на новую версию сервиса будет произведено 18-19 октября 2007 года. Работа сервиса на время переключения будет временно приостановлена.
Мы постараемся минимизировать время простоя сервиса и заранее благодарим наших пользователей за понимание. Ниже содержится информация о важных изменениях в работе сервиса SeoRate.ru.Пожалуйста, ознакомьтесь с ней.

О НОВОЙ ВЕРСИИ СЕРВИСА
В новой версии сервиса сохранены все возможности бета-версии и снято главное ограничение: пользователи теперь не ограничены по числу сайтов и запросов, которые требуется контролировать. Вы можете задать любое количество запросов и любое количество сайтов, позиции по которым необходимо отслеживать.
По просьбам пользователей сервис SeoRate.ru дополнен четырьмя новыми отчетами:

• Отчет о количестве страниц, проиндексированных поисковыми системами;
• Отчет о количестве ссылок на сайт по данным Google;
• Cервис мониторинга Google PR и Яндекс тИЦ;
• Cервис мониторинга размещенных ссылок.

Кроме того существенно упрощена логика работы сервиса. Чтобы облегчить использование данных, подготовленных SeoRate.ru, существенно переработана система экспорта результатов. В дальнейшем мы планируем продолжить работу по развитию сервиса и подключению к нему новых возможностей.

Изменения коснулись также правил использования сервиса. Теперь сервис стал платным. Вы можете выбрать один из трех платных тарифных планов, подходящий Вам по числу контролируемых сайтов и запросов. Для пользователей, которые хотели бы попробовать сервис в тестовом режиме, сохранен бесплатный режим использования.

СТАРЫМ ПОЛЬЗОВАТЕЛЯМ SEORATE.RU

Регистрации пользователей, которые зарегистрировались на SeoRate.ru в течение бета-тестирования, сохраняются со всеми сделанными настройками. Это касается также данных и сформированных отчетов. Мы автоматически переводим всех старых пользователей на тарифный план “Начальный”, который позволит Вам
отслеживать позиции 5 сайтов по 25 запросам.
На лицевой счет старым пользователям зачислены средства, позволяющие использовать сервис в течение одного месяца. В течение этого срока Вы можете пользоваться всеми преимуществами платного тарифного плана, а затем решить, оставаться ли на каком-то платном тарифе или перейти на бесплатный режим
работы.
Мы надеемся, что сервис SeoRate.ru оказался полезен при продвижении Вашего сайта и рассчитываем на продолжение нашего сотрудничества.

С уважением, Администрация сервиса SeoRate.ru

Проектная матрица – простое представление планирующего и организационного фрейма, обеспечиваемого подсистемами и ООА (Объектно-ориентированный анализ). В проектной матрице каждая строка – этап в методе ООА и каждый столбец – подсистема. Ячейки, которые образуются пересечением строк и столбцов, представляют собой отдельные модули работы,которую необходимо выполнить. В результате Вы можете связать некоторые информационные сведения с каждой данной рамкой:

• сотрудники, определённые для выполнения работы, представленной ячейкой;
• рабочие продукты, которые должны быть созданы как результат выполнения работы;
• предполагаемые трудозатраты, требуемые для выполнения работы;
• текущее состояние работы: завершена, выполняется, будет проделана;
• ожидаемые даты начала и конца работы;
• трудозатраты, которые действительно потребовались для выполнения работы.

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

Деятельность при анализе

ООА (объектно ориентированный анализ) является процессом, состоящим из анализационной деятельности, которая требуется для обеспечения формализованных моделей. Процесс описывается во фрейме, данном проектной матрицей.

Строка информационной модели. Работа, связанная с рамкой в строке информационной модели, подразделяется на несколько отчётливых видов деятельности:

• исследование;
• разработка модели;
• интеграция;
• просмотр.

Исследование. Первая задача, перед необходимостью решения которой поставлен аналитик, – собрать и усвоить подходящую информацию о реальном (или гипотетическом) мире для анализа. Многое из такой информации может быть доступно в документах как в общих работах, имеющихся в библиотеках, так и в специализированных, созданных организацией заказчика: в руководстве по производству и в руководящих принципах, инженерных чертежах и документах, бланках данных, фотографиях, обучающих материалах и т.п. Возможно, что дополнительную информацию необходимо будет получить прямо от представителей организации заказчика, людей, которые, как ожидается, будут операторами системы, и различных экспертов предметной области.

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

Разработка модели. Как только вы хорошо разобрались с предметной областью, может начинаться работа над созданием формализованных моделей.Начните с эскизной зарисовки первого проекта графической информационной модели. Заполниет её атрибутами и связями, предложенными техническими замечаниями.

Как только у вас будет довольно законченный проект графической информационной модели, начните подготовку описаний атрибутов и объектов. Эта деятельность может потребовать решений дополнительных вопросов. Продолжите совершенствование модели и исследование вопросов по мере их возникновения до тех пор, пока не выясните все подробности.

Часто бывает так, что некоторые фундаментальные вопросы не могут быть рассмотрены достаточно быстро, поскольку зависят от решений, которые ещё предстоит принять заказчику или другому отделу в вашей организации. В этом случае у вас есть возможность приостанавливать работу над частной подсистемой до тех пор, пока не будут получены ответы. Альтернативно наилучший выход может быть в том, чтобы продолжать, готовя техническое замечание, документирующее опции. В дальнейшем выберите одну из опций, зафиксируйте ваш выбор как предположение в документе, озаглавленном “Контекст для просмотра подсистемы” и продолжите анализ. Несмотря на то, что эта стратегия несёт с собой риск, связанный с возможной необходимостью переработки части анализа, она, вероятно, облегчит процесс принятия решений, так как законченный анализ обнаружит любые вовлечения опций, которые вы выбрали для исследования, и может пролить некоторый свет на другие опции.

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

Просмотр. Вследствии того, что информационная модель – основа для всего анализа и проектирования – ещё создаётся, мы проводим детализированный технический просмотр работы в этой точке. При этом мы преследуем две цели: проверить, что существенные аспекты реального мира были точно сохранены в формальных моделях, и проконтролировать соответствие модели правилам ООА, которые состоят в том, что каждый объект имеет идентификатор, все связи формализованы и описаны и т.д. Команда для просмотра должна, следовательно, включать как экспертов предметной области (для обеспечения первой цели), так и экспертов по моделированию (для второй). Если вы не можете предоставить экспертов предметной области для просмотра, замените их аналитиками, не работавшими над этой частной моделью. Снабдите аналитиков-рецензентов техническими замечаниями, которые могут в дальнейшем использоваться как описание действительности, с которой сверяется модель.

Строка моделей состояний. Деятельность, связанная с рамкой в строке моделей состояний, – это разработка модели, вериикация взаимных действий, интеграция и просмотр.

Разработка модели. Начните работу с моделью состояний эскизной зарисовкой грубой модели взаимодействия объектов для установления иерархического представления объектов. Затем формируйте одну за другой модели состояний и накапливайте в процессе работы список событий. Может быть, будет необходимо провести некоторые дополнительные исследования, чтобы определить тонкости поведения различных объектов.В таком случае запишите полученные сведения в технические замечания.

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

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

Верификация взаимных действий. Если взаимные действия между моделями состояний нелегко понять из ДПС и единственной модели взаимодействия объектов, проиграйте взаимные действия, используя автоматизированный имитатор или ручную процедуру. Альтернативно опишите взаимные действия на схеме каналов управления. В любом случае подготовьтесь для объяснения взаимных действий различных моделей состояний в просмотре для этой ячейки.

Интеграция. Как только модели состояний и модель взаимодействия объектов завершены, сформируйте (или модифицируйте) модель взаимодействия подсистем для этого домена.

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

Строка моделей процессов. Работа, связанная с рамкой в строке моделей процессов, требует трёх видов деятельности: разработки модели с последующей интеграцией и обзором. Эта работа вполне простая и обычно выполняется очень быстро.

Разработка модели и интеграция. Разделите работу так, чтобы каждый аналитик отвечал за создания ДПДД* для некоторого количества моделей состояний. Во время этой работы каждый аналитик может поддерживать отдельную таблицу процессов состояний. Когда ДПДД* закончены, объедените отдельные таблицы процессов состояний и устраните все расхождения в именах и идентификаторах процессов. Затем создайте модель доступа к объектам для подсистемы и модифицируйте модель доступа к подсистемам для всего домена.

Просмотр. Просмотрдля рамки моделей процессов даёт возможность убедиться в том, что действия моделей состояний точно отображены на ДПДД*. Поскольку никакой новой информации по предметной области на этом этапе не поступает, верификация лучше всего выполняется аналитиками.

—
* ДПДД – Action data flow diagram – диаграмма потоков данных действий.

—
Источник: Объектно-ориентированный анализ: моделирование мира в состояниях.
Авторы: Салли Шлеер, Стефан Меллор
Книга издана в 1993-м году, на счёт переизданий – не в курсе; посвяцена изложению самых первых этапов процесса разработки сложных (программных, технических и других) систем.

В общем случае строится модель “проблемной” системы для анализа и дальше – система декомпилируется на составляющие её объекты и связи между ними, изыскиваются исходные данные [от общего (от уже полученного результата) к частному (к причинам)], сопоставляются и пересопоставляются n-е количество раз и в результате – либо подготавливается очёт, как система в целом докатилась до такой жизни, либо даже строится /теоретическая/ модель той же системы, но уже оптимизированной. Вот это “либо”/”либо” – достаточно ли в качестве результата работы предоставить “мы попали в *C*, потому что складывали *A*+*B*” или результатом работы аналитика должно быть не только “как мы попали в *С*”, но и “если мы хотим попасть не в *С*, а в *Z*, мы должны брать не *А* и *В*, а *X* и *Y*”, да ещё и предоставить все доказательства, почему?

Неправильности часто встречающиеся:

1. Для анализа системы в целом берутся не все данные, а только часть – наиболее видимая часть данных или доступная. Могут быть данные, о которых мы знаем, что они есть, но не знаем их значений, тогда можно закладываться с некоторой погрешностью на то, что “вот здесь, вероятнее всего, так” – и принимая предполагаемое значение за реальность, включаем данные в анализ. Но могут быть данные, о которых вообще не известно, вообще не известно о том, что они – тоже часть системы.

1.а) Или не правильно обозначен период времени для сбора данных. На малом интервале получилось найти исходные значения – делаются выводы – только они не работают.

2. Не правильно построены, не построены, проигнорированы связи между группами данных, связи внутренние и внешние. Проверяем первую цепочку, строящую подсистему *А* – работает, вторую цепочку, которая отвечает за работоспособность подсистемы *B* – работает. А система в целом – не работает, потому что *А* и *В* между собой не договорились.

3. Цифры – это не аналитика, цифры – это статистика. Числовые данные могут быть основой для анализа. Собрать из всех доступных числовых данных те, которые нужны для анализа, и те, которые нужны для оценки погрешностей (вторичные, незначительные или малозначительные для анализа конкретной системы, но в совокупности таки влияющие на результат), за нужный период времени – это колоссальный труд, но без построения на основе этих данных закономерностей и подготовки выводов это не аналитика.

4. Аналитика – это не только цифры. Для того, чтобы сделать яишницу, нужно взять 1 сковородку, 2 яйца, 10 грамм соли и 30 грамм масла, жарить при температуре 100­°С, для того, чтобы порадовать этой яишницей подругу с утра, нужна чистая салфетка, красивая тарелка, зелень и оливки для украшения блюда (а как украсить – интуиция подскажет) и УЛЫБКА! (одна штука). Ладно, это не супер пример. Но тем не менее по п.4. – аналитика – это не только числовые данные.

Для анализа системы из *А*, *Б* и *сникерса* разумно привлекать сторонних аналитиков (они вне системы, поэтому снижается риск влияния на результат анализа “человеческого фактора”, нет необходимости в процессе оценки “защищать себя” – и значит “искать того, кто виновен”). Поэтому как раз в системе из *А*, *Б* и *сникерса* редко возникает необходимость в стороннем объективном анализе, потому что для *Б* – это угроза его стабильности, у *А* на это нет времени, потому что ему нужно сегодня ещё “выкопать-две-траншеи/слепить-три-сникерса”, думать некогда, и такая система может оставаться неоптимизированной годами. А потом в одночасьё – рухнуть.

Можно обойтись и без стороннего беспристрастного аналитика. Включается здравый смысл и заложенная у всех без исключения способность видеть ситуацию (и себя в ситуации) со стороны, и этого достаточно. Но это делать так же не хочется (хотя и надо), как и вызывать стороннего аналитика. Это первое.
Второе. При анализе важно участие значимых объектов системы. В бизнесе – это обе стороны (к примеру, конфликт между подрядчиком и нанимателем), в семье – это искреннее желание и мужа, и жены изменить ситуацию (на самом деле как правило минимум один из ситуацию менять не хочет, только играет во “всё плохо”), в политике – то же самое.
Если объективную оценку жаждет кто-то один, второй же игрок от объективной – прячется – обесценивается сам факт анализа, и происходит то же самое – система рушится.