Заметки консультанта

Шамрай Александр Владимирович

Archive for the ‘Полезное’ Category

Добавим немного автоматизации для планирования в TFS

Posted by Шамрай Александр на Сентябрь 2, 2013

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

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

Рисунок 1. Список требований на итерацию

Первым делом добавим новые задачи в план. У задач в TFS есть отдельное поле Действие, которое имеет ввиду тип работ необходимых для выполнения. Собственно, набор этих действий и будет нам определять шаблон создаваемых задач. Кроме этого выберем те требования, для которых нам интересно добавить дочерние задачи и выполним генерирование.

Рисунок 2. Выбор требований для планирования

В результате будет создан шаблон, в который нам необходимо добавить из списка исполнителей по задачам. Напротив задач, которые нам не нужны в плане, убираем чек-бокс. Результат публикуем.

Рисунок 3. Создание новых задач и назначение исполнителей

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

Рисунок 4. Результат создания задач

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

Рисунок 5. Выбор требований для создания тестов

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

Рисунок 6. Выбор плана тестирования

Для новых тестов устанавливаем ответственных и публикуем в TFS.

Рисунок 7. Указание ответственных за тесты

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

Рисунок 8. Сгенерированные задачи и тесты

Кроме этого тесты будут отражаться в плане тестирования в нужной иерархии и с назначенными исполнителями.

Рисунок 9. Новый план тестирования в Test Manager

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

Рисунок 10. Отслеживание выполнения

Posted in Полезное, Разное, Разработка, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

Правильные требования: Топ 10 ловушек

Posted by Шамрай Александр на Август 15, 2013

Перевод: Шамрай А.В.

Источник: Getting requirements right: avoiding the top 10 traps

Содержание

Не попадайтесь

Ловушка 1: расползание границ

Ловушка 2: спрашивать заказчиков, чего они хотят

Ловушка 3: неспособность адаптироваться к изменениям

Ловушка 4: неспособность эффективно общаться

Ловушка 5: нечастое общение

Ловушка 6: громоздкие документы и слишком много информации

Ловушка 7: скрытые артефакты проекта

Ловушка 8: неоднозначные требования

Ловушка 9: неспособность измерить и оценить процесс требований

Ловушка 10: изоляция ваших требований

Заключение

Не попадайтесь

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

К сожалению, ловушки требований являются общими и их влияние является значительным. В исследованиях State of the IT Union Survey изучали методы управления разработкой, которые команды применяют во избежание неприятностей или используют для решения проблемы после их обнаружения. Онлайн-опрос респондентов показывает, как часто команды разработчиков предвидят, что они могут попасть в ловушки. Они дополняют бюджеты и планы. Они изменяют первоначальную смету, чтобы соответствовать фактическим результатам. И они запрашивают дополнительные ресурсы. Рисунок 1 показывает, как команды и руководители групп будут бороться с этими ловушками…

Основные моменты

Слабое Управление требованиями приводит к несогласованным результатам проекта.

Рисунок 1. Команды разработчиков ожидают ловушки управления требованиями и преднамеренно избегают создание точных бюджетов и планов.

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

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

Основные моменты

Фиксирование бизнес-требований может контролировать расползание границ.

Ловушка 1: расползание границ

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Уводите обсуждение подальше от возможностей.

Спрашивайте заказчиков, какие результаты они ожидают, это поможет вам определить требования.

Ловушка 2: спрашивать заказчиков, чего они хотят

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

Избегание ловушки

  • Спросите заказчиков, почему они нуждаются в конкретном решении. Это может привести к лучшему пониманию их ожиданий и улучшить дискуссию об определенных требованиях.
  • Уводите обсуждение подальше от возможностей — спрашивайте заказчиков, что они хотят, чтобы делало программное обеспечение. Создайте отдельное обсуждение от том, как конечный продукт будет использоваться.
  • Определите правильные заинтересованные лица. Целевая аудитория или конечный пользователь могут быть не теми, кто несет ответственность за проект или инвестирует в результат. Найдите — и выслушайте — правильных пользователей, заказчиков, руководителей, которые финансируют проект, представителей правления, которые накладывают правила, проектных команд, групп поддержки и др.

Выигрыш

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

Основные моменты

Неопределенности и внешние факторы могут повлиять на требования.

Планируйте изменений для уменьшения риска.

Ловушка 3: неспособность адаптироваться к изменениям

Установка каменных требований в начале разработки может стать хорошим рецептом для катастрофы, которая приведет к огромным расходам ресурсов и неспособность соблюдать график. Как показывают недавние изменения в мировой экономике, внешние влияния могут быстро изменить требования проекта. Организации быстро изменили свой фокус на сделать больше с меньшими затратами. Спекулятивные или экспериментальные домашние проекты покинули стол, заменены на проекты с сильным потенциальным ROI. Тем не менее в любой экономике, всегда есть новые требования как действовать, когда изменяются бизнес-приоритеты, вводятся новые управленческие правила и определяются новые заинтересованные стороны. Проектным командам необходимо учесть эти изменения.

Избегание ловушки

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

Выигрыш

Приспосабливание и планирование изменений в требованиях проекта помогает снизить риск и снижает дорогостоящие переделки.

Основные моменты

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

Эффективная коммуникация помогает оптимизировать время и трудозатраты.

Ловушка 4: неспособность эффективно общаться

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

Избегание ловушки

  • Знайте вашу аудиторию и связывайтесь методами, которые помогут ей понять информацию. Используйте диаграммы, описания функциональности пользователей, зарисовки и раскадровки.
  • Создавайте глоссарии, шаблоны документов и формы обратной связи, которые являются четкими, краткими и просты в использовании.
  • Используйте прототипы, чтобы помочь заинтересованным сторонам визуализировать решение. Они могут дополнить текст или полностью заменить его в зависимости от необходимой степени детализации.
  • Получайте обратную связь от всех представителей заинтересованных сторон и помните, что один или два человека, как правило, наиболее активны. Не делайте ошибку, упуская обратную связь от других.
  • Всегда отвечайте на обратною связь, желательно с некоторым четким заявлением о состоянии, например, «Будет включено», «Добавить это в список пожеланий» или «Не удается выполнить это сейчас». Если вы просите мнение, признавайте его.

Выигрыш

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

Основные моменты

Заинтересованные лица часто имеют разные приоритеты.

Регулярные общение помогает поставить ценный продукт.

Ловушка 5: нечастое общение

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Когда речь заходит о документации, думайте качественно, а не количественно.

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

Сфокусированная документация и обратная связь помогает повысить эффективность и точность.

Ловушка 6: громоздкие документы и слишком много информации

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Создайте центральное хранилище для артефактов проекта.

Централизованное управление информацией может способствовать сотрудничеству.

Ловушка 7: скрытые артефакты проекта

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Неопределенность создает риски на следующем этапе проекта.

Отложите первый черновик и вернитесь к нему позже со свежим взглядом.

Ловушка 8: неоднозначные требования

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

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

Что вызывает неопределенность? Бедное описание, неточная информация и предположение, что аудитория понимает так же, как вы и делаете.

Избегание ловушки

  • Используйте руководство по написанию, например, Элементы Стиля Вильяма Странка Младшего и Е.Б. Уайта, которое уже давно считается авторитетным справочным материалом для четкого, понятного текста — до и во время создания требований.
  • Создайте глоссарий и убедитесь, что включен каждый акроним и технический термин.
  • Представьте, что вы пишете для студента, который только что закончил колледж, или для тех, кто недавно присоединился к компании. Не ожидайте, что аудитория будет знать каждый термин и понимать каждое понятие.
  • Дополняйте текст визуальными эффектами. Это отличный способ выразить и простую, и сложную концепцию.
  • Шагните назад. После написания любого проектного документа, закройте его на некоторое время и прочитайте позже. Свежий взгляд может выявить неоднозначности.

Выигрыш

Четкие, понятные требования являются основой вашего программного проекта.

Основные моменты

Измерения результатов позволяют непрерывно улучшать процесс.

Ловушка 9: неспособность измерить и оценить процесс требований

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

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

Избегание ловушки

  • Проводите сессии обратной связи «извлеченные уроки» в конце каждой итерации разработки или выпуска как часть процесса.
  • Также выполняйте сессии «запомненных уроков» до начала нового проекта. Поощряйте непрерывное совершенствование, вам нужно не только обобщать накопленный опыт в конце итерации или выпуска, но также усиливать эти уроки перед движением вперед.
  • Определяйте и собирайте метрики, что гарантирует ваш успех. Например, измеряйте влияние изменений на требования, покрытие тестового сценария, приоритет, стоимость и трудозатраты бизнес и требований к продукту. По мере совершенствования опыта в измерениях, вы сможете найти нужное сочетание метрик, которые позволят постоянно улучшать ваш процесс требований.

Выигрыш

Постоянные измерения выполнения проекта покажут небольшие проблемы, прежде чем они станут большими проблемами.

Основные моменты

Изменения в одном требовании могут иметь значительное влияние на артефакты ниже.

Определение и управление связями между требованиями помогает снизить риск.

Ловушка 10: изоляция ваших требований

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Решения IBM Rational для требований могут помочь вам избежать общих ловушек в разработке программного обеспечения.

Заключение

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

Программное обеспечение для требований IBM Rational ® включает многие лучшие практики, которые помогут вам избежать этих общих ловушек и насладиться выгодами.

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

Программное обеспечение IBM Rational RequisitePro ® в сфере ИТ и программное обеспечение IBM Rational Doors ® в системной сфере обеспечивают трассировку и анализ влияния, который держит аналитиков, архитекторов, разработчиков и тестировщиков в соответствии потребностям бизнеса и требованиям на протяжении всего жизненного цикла поставки программного обеспечения.

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

Дополнительная информация

Чтобы узнать больше о решениях для требований IBM Rational для разработки программного обеспечения, обратитесь к представителю IBM или бизнес-партнеру IBM или посетите:

ibm.com/software/rational/offerings/irm

Rational Requirements Composer software:

ibm.com/software/awdtools/rrc/

Бесплатная загрузка Rational Requirements Composer:

https://jazz.net/projects/rational-requirements-composer/

Электронный пакет лучший практик поставки программного обеспечения: Сделать больше с меньшими затратами:

ibm.com/services/forms/preLogin.do?lang=en_US&source=swg-rtl_sdekit

Топ 10 секретов поставки программного обеспечения выполняя больше с меньшими затратами:

ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14139usen/RAW14139USEN.PDF

Калькулятор ROI:

ibm.com/software/rational/offerings/testing/roi/

Читайте наш блог RDM:

rationalrdm.wordpress.com

Следуйте за нами на Twitter: @RationalRDM

Стань фаном Rational Requirements Composer на Facebook:

http://www.facebook.com/home.php?#/pages/Rational-Requirements-Composer/47378244431?ref=ts

Posted in Полезное, Разное, Требования | Отмечено: , | Leave a Comment »

Советы для написания хороших сценариев использования

Posted by Шамрай Александр на Март 2, 2011

James Heumann, Requirements Evangelist,

IBM Rational Software

Оригинал: Tips for writing good use cases

Перевод Шамрай А.В.

Содержание
Введение
 

Что такое сценарий использования (и что не является им)

Сценарии использования – это программные требования, которые определяют функциональность

Ссылки позволяют пользователям восстановить всю историю

Заключение

Введение

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

Ивар Якобсон ввел сценарии использования. Мария Эриксон работала с Якобсоном и была соавтором одной из его книг. Курт Биттнер и Ян Спенс также написали популярную книгу по использованию сценариев использования. Эти пионеры и многие другие люди в IBM, которые имеют многолетний опыт работы с заказчиками в разработке хороших сценариев использования, внесли свой вклад в технологии, описанные в этой статье. Дать хороший сценарий использования не легко, но, к счастью, наш опыт может быть Вашим руководством. Концепций и принципы, собранные здесь, представляют опыт многих людей в IBM, и они образуют основу проверенных передовых методов. Многие советы, приведенные в данном документе, являются частью методологии IBM Rational® Unified Process® (RUP®), другие являются новыми и не представлены в RUP.

Что такое сценарий использования (и что не является им)

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

Сценарий использования – это история о том, как бизнес или система и пользователи взаимодействуют. Варианты использования являются частью стандарта Object Management Group (OMG) Unified Modeling Language (UML). Этот стандарт говорит нам, что части сценария использования выражается диаграммами – рисованные фигуры, овалы и линии – и это дает нам определение сценария использования. Но это не говорит нам, как структурировать или писать. Поэтому нам остается читать книги или статьи (подобной этой), чтобы попытаться выяснить правильные методы.Итак, какой правильный путь? Лучший способ – это способ, который работает на Вас, не отходя слишком далеко от определения, что такое вариант использования: 

Вариант использования – это спецификации набора действий, выполняемых системой, который дает заметный результат, который, как правило, значим для одного или нескольких субъектов или других заинтересованных сторон системы (UML 2).

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

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

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

Сценарии использования преобразуют выражения «должен» на группы, которые обеспечивают наблюдаемое значение и контекст, организованные с точки зрения пользователя.

Сценарии использования – это программные требования, которые определяют функциональность

Люди часто говорят о требованиях и сценариях использования, подразумевая, что это разные вещи. Прецеденты просто другой способ для организации функциональных требований; они по-прежнему требованиям. Традиционно требования описывают функциональность системы, используя длинный список с выражением «должен», иногда их тысячи. Целью создания сценариев использования является преобразование этих многих выражений на более мелкие группы, которые обеспечивают наблюдаемое значение и контекст, организованные с точки зрения пользователя.

Сценарии использования описывают поведение (по крайней мере, выходы), которое является видимым для пользователя. Существуют и другие типы требований кроме функциональных, их, как правило, называют нефункциональными или вспомогательными требованиями. Эти требования, как правило, также указываются выражением «должен», но они содержат отличную от сценариев использования информацию. Они описывают необходимые качественные показатели системы: насколько быстра она должна быть, как надежна, как безопасна и другие качественные атрибуты. Сценарии использования должны описывать, что система должна делать. Они должны выражать интерактивные шаги, которые пользователь должен предпринять для достижения значимого результата.

Сценарии использования описывают и функциональность и результаты. Сценарий использования описывает функциональные возможности, но он также должен описывать результат. Это важно, и это отражается в первом определении, которое говорит, что прецеденты обеспечивают «значимый результат для одного или нескольких субъектов или других заинтересованных сторон системы». Одна из общих проблем, наблюдаемых в организациях, которые только начали использовать сценарии использования, является то, что они не понимают этот фокус на значимости. И в результате они делают много небольших сценариев использования, которые не дотягивают до полной истории. Они не нацелены на взаимодействие, определяющие значимость и интересы для субъектов, участвующих в сценарии использования.
Распространенной ошибкой является путать требования со спецификациями проектирования. Этот подход часто можно увидеть в его воздействии на этапе тестирования проекта. Если тесты, основанные на сценариях использования, отражают юнит-тесты, а не приемочные испытания пользователя, их может быть, возможно, слишком много и они на слишком низком уровне.Как, например, один клиент IBM взаимодействовал с около 10 людьми, работающими над проектом, который должен был длиться около года. Первоначально в организации было около 150 сценариев использования, потому что было непонимания их цели. После глубокой экспертизы, было установлено, что многие из их вариантов использования были действительно спецификациями проектирования, а не требованиями, и другие были слишком сосредоточены на настолько незначительных взаимодействиях, что они не показывали никакой значимости для субъекта или заинтересованных сторон. 

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

Диаграммы обеспечивают визуальный вспомогательный материал для сценария использования.

Совет: Не забывайте о диаграммах

Сценарии использования представлены графически в виде овалов на диаграммах сценариев использования, и они также выражаются как текстовые спецификации (см. рисунки 1 и 2). Текст, безусловно, суть модели сценария использования, и Вы можете, конечно, извлечь пользу от текстового описания без рисования диаграмм. Однако схема может помочь представить требования на высоком уровне. Это также помогает заинтересованным сторонам увидеть, что находится в границах и что выходит за границы. Субъекты вне разрабатываемой системы и сценарии использования внутри. Это особенно важно для обзорных диаграмм сценариев использования, которые показывают всех участников и варианты использования на одной диаграмме.

Люди являются наиболее важным элементом сценария использования

Совет: Люди-субъекты являются наиболее важным элементом

Рисованные фигуры, применяемые в диаграммах сценариев использования, называются субъектами. Они показывают, любое лицо (или роль), другие системы или, возможно, даже устройство, которое находятся за пределами разрабатываемой системы, но взаимодействуют с ней. Люди-субъекты представляют наиболее интересные и сложные взаимодействия для большинства систем, а также взаимодействие человека и системы, где реальная значимость сценария использования вступает в перспективе. Функциональность, вложенная в сценарий использования, поможет субъектам делать свою работу или задачу существенно лучше.

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

Создание стиля для сценария использования позволяет писать и читать их быстрее и проще.

Совет: Идите за потоком

Хорошие сценарии использования не только абзацы понятного и краткого текста. Они имеют структуру, которая определяет, как части сценариев использования сочетаются друг с другом. И они могут быть структурированы разными способами, которые называются стилем сценария использования.

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

Сценарии использования должны иметь один основной поток и несколько альтернативных потоков. Сценарий использования должен иметь один основной поток и несколько альтернативных потоков. Основной поток (см. рисунок 1) объясняет, что происходит, когда все идет правильно и сценарий использования достигает свою цель. Иногда его называют сценарий «верного пути» и он происходит чаще всего. Иногда авторы сценария использования пытаются описать несколько основных потоков, но это может уменьшить понятность сценария использования, поскольку потребителю сложнее понять истинные цели. Поэтому наиболее общий сценарий должен быть основным в процессе, выступающим в качестве одного основного потока. 

Рисунок 1. Хорошо написанный сценарий использования, который рассказывает, как студент регистрируется на курсы.

Альтернативные потоки объясняют отклонение от основного потока. Альтернативные потоки (см. рисунок 2) объясняют, что происходит, когда по каким-то причинам происходит отклонение от основного потока. Эти отклонения могут или не могут быть помечены как исключения или ошибки. В любом случае, они не встречаются так часто, или не так важны, как основной поток. В документе сценария использования каждый тип потока описывается в своем собственном разделе. Иногда альтернативные потоки разбиты на более подробные категории такие, как пользовательские ошибки и исключения. Отметим, что низкоуровневые коды ошибок выходят за рамки альтернативных потоков. 

Рисунок 2. Альтернативные потоки описывают возможные результаты, когда они начинаются и когда они заканчиваются.

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

Ссылки позволяют пользователям восстановить всю историю

Хорошая практика разбивать на модули сценарий использования, разделив его на несколько потоков. Но чтобы быть в состоянии рассказать всю историю, Вы также должны иметь какой-то способ сложить кусочки снова вместе, чтобы проиллюстрировать конкретные непрерывные сценарии. Это достигается с помощью ссылок, которые по существу определяют начало и конец альтернативного потока, ссылаясь на конкретный шаг в основной поток или иной альтернативный поток (см. рисунок 3). Создание легко понимаемого сценария использования требует последовательной техники с использованием ссылок.

Совет: Помещайте ссылки в альтернативных потоках, а не основных потоках

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

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

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

Совет: Сценарии описывают полную историю

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

Удобочитаемость может пострадать, если присутствует оператор «если» в потоке, потому что это обычно означает множественные требования.

Совет: Будьте осторожны с операторами «если»

ИТ-специалисты, в частности, с опытом программирования знакомы с оператором «если», и Вы будете часто видеть использование таких операторов в сценариях использования. «Если» в языке программирования указывает условное поведение, и это правило справедливо в сценариях использовании. Проблемы возникают, когда есть один или больше операторов «если» в потоке, потому что это обычно означает, что вы устанавливаете несколько требований. Это может быть отрицательным для удобства чтения, т.к. может быть сложно отследить поток после нескольких операторов «если» в тексте. Это также отрицательно для проектирования и тестирования системы. Лучше и для читателя, и для проекта, если Вы прервете каждый «если» в его собственный поток. Это сделает больше потоков, но такой компромисс стоит того.

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

Совет: Укажите выбор для субъекта

Субъекты часто делают выбор в сценарии использовании. Рассмотрим пример системы регистрации университета определенного в сценарии использования «Регистрация на курсы». В этом примере шаг главного потока может спросить субъекта: 1) создать график, 2) изменить график и 3) удалить график. Часто авторы сценария использования пытаются использовать оператор «если», чтобы показать, субъект делает выбор, но по причинам, указанным выше, это может быть не лучшая идея. Лучшей альтернативой для того, чтобы все возможности выборы субъекта были перечислены в соответствующем месте и был один выбранный вариант, направляющий в текущий поток, а другие рассматривались в альтернативных потоках. Этот метод сохраняет каждый поток простым и снижает ветвления.

Совет: Убирайте СЧОУ

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

Вместо этого, попробуйте сосредоточиться на вещах, которые субъект действительно хочет сделать, что, как правило, не в действиях создание, чтение, обновление и удаление (СЧОУ).

В нашем примере системы регистрации университета, есть варианты для 1) создания графика, 2) изменения графика и 3) удаления графика. Все они находятся в сценарии использования «Регистрация на курсы», поскольку студент не заботится о создании и изменении графиков; студент хочет только зарегистрироваться. Выбор легкого пути и составление списка всех деятельностей СЧОУ в результате даст в три или в четыре раза больше сценариев использования, чем необходимо и может быстро сделать процесс сложным и трудно управляемым.

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

Плохо написанный сценарий использования имеет слишком много действий создания, чтения, обновления и удаления, уменьшая ясность. Рисунок 3. У плохо описанного варианта использования есть слишком много включенных действий типа СЧОУ.
Удаление деятельностей СЧОУ упрощает документ. Рисунок 4. Хорошо написанный сценарий использования четко указывает на пути и значимость.
Упорядочивание событий в потоке не всегда необходимо для достижения ясности.

Совет: Последовательность событий может быть опциональной

Мы говорим, что шаги в сценарии использования, как правило, упорядочены по времени, но следует учитывать, является ли порядок шагов требованием. Например, субъект должен пройти четыре шага до завершения пятого шага? Обычно ответ будет да, но не всегда. Это очень просто, при разработке текстового описания для сценария использования, уточнить любые временные ограничения и добавить в предложение комментарии такие как «Этот шаг может выполняться в любом порядке» или «Этот шаг может выполняться в любое время перед этим шагом». Дело в том, Вы не хотите ограничивать разработчиков системы наличием неявных временных требований, когда они не являются необходимыми.

Не забывайте, что Вы пишете сценарии использования для конечного пользователя.

Совет: Используйте правильный уровень детализации

Один из наиболее часто задаваемых вопросов: «На сколько детально описывать сценарий использования?» Помните, что сценарий использования – это требования. Это не документация по проектированию, и они, конечно, не проект пользовательского интерфейса. Сценарии использования никогда не должны ссылаться на элементы пользовательского интерфейса, такие как домашние страницы, экраны входа или нажатие кнопки.

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

Совет: Поставьте себя на место субъекта

Сценарии использования отличаются использованием выражения «должен». Так как они указывают упорядоченные по времени шаги, они создают больше контекста, чем автономные выражения «должен», которые не являются зависимыми от времени. Поэтому они в большей степени соответствуют предназначению для пользователей. Имейте это в виду. Если сценарии использования это требования (а они и есть), проектировщики и разработчики будут ограничены тем, что они говорят. Помните об этом, пожалейте субъектов и пишите сценарии использования с помощью методов, которые сделают систему максимально удобной для пользователя.

Соглашение по структуре сценария использования и процессов важно для достижения качества и последовательности.

Заключение

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

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

Дополнительная информация

Чтобы узнать больше о том, как писать эффективные сценарии использования и как IBM Rational Software может помочь, пожалуйста, обращайтесь к представителю компании или бизнес-партнеру IBM или посетите:

ibm.com/software/rational/offerings/irm

Posted in Полезное, Разное, Требования | Отмечено: , , , | 2 комментария »

Как защитить авторские права разработчикам ПО? Или как мы получали копирайт в Библиотеке Конгресса США?

Posted by Шамрай Александр на Сентябрь 19, 2010

Из блога Новичкова Александра:

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

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

Традиционная благодарность Галине Карабановой за помощь в написании статьи.

В статье, в примерах регистрации в Библиотеке Конгресса США фигурирует соавтор решения ProjectTracker, на примере регистрации которого и построен данный материал, –  Александр Шамрай.

Читать далее—>

Posted in Полезное, Разное, Разработка | 1 Comment »

Конвертирование образа Hyper-V в VmWare

Posted by Шамрай Александр на Сентябрь 15, 2010

Недавно посетила идея покрутить виртуалку от Microsoft с настроенными TFS 2010, Project Server 2010 и настроенной между ними интеграцией. Сам образ находится здесь: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f221c660-161b-43ca-95f3-e0e4aad8d43e&displaylang=en

Учитывая, что под XP вряд ли получиться поднять Hyper-V, то я воспользовался утилитой Starwind Image Converter, которую можно скачать здесь после непродолжительной регистрации: http://www.starwindsoftware.com/download-starwind-converter. Далее все просто:

  • Запускаем мастер конвертирования

  • Выбираем образ диска, который нужно конвертировать

  • Выбираем формат, в который нужно конвертировать

  • Выбираем необходимый тип диска

  • … и каталог, куда сохранить результирующий образ

  • И далее дожидаемся окончания процесса

  • В VmWare запускаем мастер создания новой виртуальной машины

  • Устанавливаем необходимый тип виртуальной машины

  • Указываем, что пока устанавливать ОС на новую виртуальную машину не будем

  • Выбираем тип ОС для виртуальной машины

  • Указываем путь, где будет находится виртуальная машина

  • Устанавливаем количество процессоров

  • Необходимое количество памяти

  • Нужный тип сетевого подключения

  • Тип контроллера жестких дисков

  • На этом шаге говорим, что будем использовать существующий жесткий диск

  • Указываем диск, который был создан ранее при конвертировании

  • При необходимости можем довести формат диска под тип виртуальной машины

  • Теперь как бы все

  • Результат должен быть где-то таким

Posted in Полезное, Разное | Отмечено: , | 2 комментария »

Тестирование памяти с помощью Windows Memory Diagnostic

Posted by Шамрай Александр на Июль 19, 2010

Если компьютер начинает себя вести неестественно (подвисать, притормаживать, выдавать синий экран), то конечно стоит задуматься, правильно ли функционирует железо. Утилита Windows Memory Diagnostic позволяет определить неисправность или исключить из списка подозреваемых оперативную память ПК. Скачать утилиту можно по этому адресу: http://oca.microsoft.com/en/windiag.asp. Процесс установки простой:

  1. Качаем и запускаем файл mtinst.exe
  2. После запуска появиться окно лицензионного соглашения, в котором нужно нажать Accept|
  3. Далее появится окно предлагающее выбрать метод установки утилиты

    • Первый пункт Create Sturtup Disk должен создать установочную дискету (лет 10 не использовал предлагаемое)
    • Второй пункт Save CD Image to Disk сохраняет образ CD по выбранному в дальнейшем пути. Сохраненный образ можно записать на CD или DVD, который нужно в дальнейшем использовать как загрузочный.

Далее необходимо перезагрузить ПК и вставить созданный на предыдущем шаге floppy, CD или DVD (предварительно выставив загрузку с этих устройств). После загрузки появится следующий экран, в котором сразу начнется процесс тестирования памяти:

По умолчанию запускается стандартный процесс тестирования, который включает в себя 6 тестов и проходит довольно быстро (около 20-ти минут). Кроме этого доступен расширенный тест, который включает в себя 11 тестов и длится уже намного дольше (до 2-х часов). Переключиться на простой или расширенный режим можно с помощью клавиши T. Запущенные тесты будут длиться (повторяться) до тех пор, пока не будет перезагружен компьютер или не будет выполнен выход с помощью клавиши E. Правда у утилиты есть ограничение (на момент публикации заметки) по объему оперативной памяти в размере 4 GB. Все, что выше этого объема, просто не тестируется.
Более подробно, включая полную инструкцию по использованию, можно посмотреть здесь: http://oca.microsoft.com/en/windiag.asp.

Posted in Полезное, Разное, Техника | Отмечено: | 2 комментария »

Подключение блога на WordPress.com к Facebook, Twitter, Yahoo!

Posted by Шамрай Александр на Март 27, 2010

Сервис WordPress.com может отсылать информацию о публикации записей на блоге на различные сервисы (на момент публикации этой записи поддерживались следующие сервисы: Facebook, Twitter, Yahoo!). В этом случае при публикации новой записи на блоге, информация о новой записи будет автоматически добавлена на выбранные сервисы. Кроме этого, когда активны соединения между WordPress.com и сервисами Facebook, Twitter, Yahoo!, при публикации записи появляется возможность задать сообщение, которое будет отсылаться на эти сервисы. По умолчанию это будет в формате «Заголовок записи : короткий адрес записи публикуемой записи». Но если необходимо задать что-то другое, то можно нажать кнопку «Изменить» и ввести нужное сообщение.

Результат будет приблизительно следующий:

Facebook

Twitter

Yahoo!

Активация возможности

Для того, чтоб включить такую возможность, нужно на консоли управления блогами перейти в пункт «Консоль»->»Мои блоги»

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

Facebook

При активации публикации на сервис Facebook появиться следующее окно, в котором нужно выбрать «Authorize connection with Facebook»

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

Далее необходимо просто подтвердить свои намерения для подключения WordPress.com к Facebook.

Twitter

При активации публикации на сервис Twitter появиться следующее окно, в котором нужно выбрать «Authorize connection with Twitter»

В следующем окне нужно ввести информацию о профиле Twitter, если это необходимо, и подтвердить необходимость соединения Twitter и WordPress.com

Yahoo!

При активации публикации на сервис Yahoo! появиться следующее окно, в котором нужно выбрать «Authorize connection with Yahoo!»

В следующем окне нужно ввести информацию о профиле Yahoo! для активации соединения Yahoo! и WordPress.com

Posted in Полезное, Разное | Отмечено: , , , , | 4 комментария »

Публикация записей на WordPress.com с помощью MS Word 2007

Posted by Шамрай Александр на Сентябрь 21, 2009

Можно конечно и пользоваться стандартными возможностями движка wordpress.com для создания записей, но использование MS Word 2007 удобнее на мой взгляд по следующим причинам:

  • Все происходит в привычном виде в документе, т.е. можно выполнять форматирование текста, использовать различные шрифты и работать с таблицами
  • Проще работать с изображениями, т.е. простой копи-паст и нет надобности переходить в раздел загрузки изображений, делать им аплоад, вставлять, потом их подгонять и т.д. При публикации MS Word сам уже загружает все вставленные в документ изображения и размещает их в так же как они были размещены в документе.
  • Ну и, наверно, одно из немаловажных – это привычная проверка орфографии

Для того чтоб использовать MS Word для публикации записей сделать нужно немного:

  • Перевести MS Word в режим редактирования записей блога. Если используется готовый документ, то на его основе в этом случае будет создан новый документ MS Word, структура которого будет адаптирована под запись блога.

  • Настроить учетную запись. Для этого нужно выбрать меню «Запись блога»-«Учетные записи» и в появившемся окне создать учетную запись блога. При создании учетной записи используются следующие данные:
    1. URL блога, который формируется для worpresss.com в следующем виде: полный_веб_адрес_блога/xmlrpc.php
    2. Имя пользователя, который используется для создания и редактирования записей на блоге, в общем случае, это логин, который использовался при регистрации блога
    3. Пароль пользователя

  • Если запись необходимо опубликовать под одной или более категорией, то для каждой категории в документе нужно выбрать меню «Запись блога»-«Вставить категорию»

  • Для публикации записи нужно нажать «Запись блога»-«Опубликовать» или «Запись блога»-«Опубликовать как черновик». Я обычно публикую как черновик и уже на блоге добавляю метки к записи, т.к. MS Word не поддерживает выбор меток.

  • Ну и как результат публикации в документе появится соответствующая надпись в документе записи блога:

Posted in Полезное, Разное | Отмечено: , | 26 комментариев »

Использование элементов ActiveX для Eclipse Plug-in

Posted by Шамрай Александр на Сентябрь 9, 2009

Если кому необходимо использовать ActiveX элементы для плагинов Eclipse, то для этого нужно использовать библиотеки SWT, которые содержат функции для работы с OLE объектами. Вот и меня постигла такая потребность, поэтому пришлось немного поэкспериментировать. Если что указал ниже некорректно, то прошу шибко не судить, т.к. java я использовал первый раз, что уж говорить про разработку плагинов к Eclipse.

Для начала своих опытов я скачал Eclipse, который содержит все, что нужно для создания плагинов: http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/R/eclipse-rcp-galileo-win32.zip

Далее создал проект «Plug-in project» и при создании в мастере выбрал шаблон плагина «Plug-in with a view». И уже в новый проект добавил импорт необходимых классов:

import org.eclipse.swt.ole.win32.OleAutomation;
import org.eclipse.swt.ole.win32.OleControlSite;
import org.eclipse.swt.ole.win32.OleFrame;
import org.eclipse.swt.ole.win32.Variant;

Далее в классе представления плагина определил переменные необходимые для работы с OLE объектом:

private OleControlSite olesite;
private OleAutomation oleauto;

И в функцию createPartControl, предварительно убрав лишнее, внес изменения, т.е. добавление элемента на страницу представления:

public void createPartControl(Composite parent) {
        OleFrame frame = new OleFrame(parent, SWT.NONE);
        olesite = new OleControlSite(frame, SWT.NONE, «Word.Document»);
        oleauto = new OleAutomation(olesite);
}

 

Если же необходимо использовать методы и свойства встроенного элемента, то можно использовать следующие функции класса OleAutomation:

  • setProperty – установить значение для свойства
  • getProperty – получить значение для свойства
  • invoke – выполнить метод

Небольшой пример для присваивания значения свойству:

        Variant valueq = new Variant((String) «New value»); // определяем новое значение
        int[] rgdispid = oleauto.getIDsOfNames(new String[]{«CtlName»});    // получаем номер свойства по его наименованию
        oleauto.setProperty(rgdispid[0], valueq); // устанавливаем новое значение

Ресурсы:

Posted in Разное, Разработка | Отмечено: , , | Leave a Comment »

 
%d такие блоггеры, как: