понедельник, 26 сентября 2011 г.

Ложка дегтя

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

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

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












суббота, 24 сентября 2011 г.

Моделирование использования (краткая аннотация книги)

Читаю книгу Use Case Modeling by Bittner K., Spence I.. Начал читать, чтобы найти информацию о правилах наименования вариантов использования. Помимо этого захотелось потренироваться в чтении англоязычной литературы без мысленного перевода. Получилось.

Книга в действительности написано очень простым английским языком. Иногда я даже умилялся его примитивизму. Причем этот примитивизм проявляется, если пытаешься перевести дословно. А если читаешь без перевода, на постосмысление. Вдруг понимаешь, что все понятно и точно :)

Книга очень подробная и полезная для начинающего аналитика и аналитика со стажем и опытом. Есть весьма оригинальные рассуждения по поводу уровня и детальности (granularity)  вариантов использования.

вторник, 13 сентября 2011 г.

Вторая технологическая конференция Яндекса — Yet another Conference 2011


Вторая технологическая конференция Яндекса — Yet another Conference 2011 — пройдет 19 сентября в Центре международной торговли. На конференции будет рассказано о математике в компьютерных науках, техниках программирования, безопасности, мобильных технологиях, клиентской разработке, администрировании, тестировании, распределенных системах хранения и вычисления.

В YaC-2011 примут участие как сотрудники Яндекса, так и представители других компаний международного уровня: Google, Facebook, Opera Software, Kaspersky Lab, Cloudera, Nigma, Sturmann, Cloud9 IDE, а также исследователи из университета Тель-Авива и ИСП РАН.

Программа конференции YaC-2011.

Тезисы докладов.

Конференция пройдёт в три потока, доклады будут и на русском, и на английском.

Мы приглашаем на YaC-2011 разработчиков, технических специалистов и студентов-старшекурсников технических специальностей.

Участие в YaC-2011 бесплатное, необходима предварительная регистрация.

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

English version

суббота, 10 сентября 2011 г.

Перемен требуют наши сердца

Если бы Putcha (Venkata) Narasimham, владелец и профессор, знал бы слова популярной песни, гимна 80-х, Виктора Цоя, он тоже назвал свою тему примерно так же. Но он не знает, а потому и назвал тему Time to rename Use Case and Use Case Description? К сожалению не могу расшарить дискуссию в группе. Она доступна только членам USE CASE PROFESSIONALS.

Уважаемого мною Пушту сподвигло на это, то, что название термина "use case" малопонятно начинающим, не несет в себе нужной семантической ясности. Потому пришла пора подумать о замене этого термина более приличествующим случаю. Господин Нарасимхам предлагает заменить термин Use Case на BizGoal и ApGoal (что-то в вольном переводе бизнес-цели и системная цель?), а Use Case Description на GoalDialog или DialogGoal.

В дискуссию вступил John Watson, человек лично знакомый с Ивором Якобсоном. Он подверг критики начинание Пушты, но согласился, что лучше бы термин Use Case остался в своем первоначальном виде Usage Case. Хотя так же он заметил, что важнее не сам термин, как стандартизация определения, что есть этот термин:
While I support a name change from Use Case to Usage Case I think it is very much more important to lobby OMG to provide a standardised definition of what a Usage Case is.
Профессор Нарасимхам, как истинный благородный муж, стоит на своем и призывает придумать более понятный термин. Он аргументирует, защищая позицию не ИТ-специалиста: термин use case понятен айтишнику, потому как он изучал UML, но UML сложен и непонятен простым смертным. В то же время это такой богатый язык и инструмент моделирования, что грех не использовать его в других областях, не только в ИТ. Просто, по мнению Пушты, язык UML и в частности UC и UCD не достаточно стандартизированы. Было бы правильным осуществить и упрощение и стандартизацию UML, приближая ее к таким стандартам как ИСО9000.

Мое мнение я выразил в дискуссии примерно следующим образом: ребята , у нас тоже есть своя заморочка с определением. Правда, нам все равно, будет ли это называться Use Case, или Usage Case, или еще как, все равно наши переводчики его переведут по-своему, а мы, народ привычный, будем смотреть не на термин, а в корень - т.е. каково разъяснение этого термина.

Например BABOK его объясняет так:
An analysis model that describes the tasks that the system will perform for actors and the goals that the system achieves for those actors along the way
На мой взгляд совершенно не понятно о чем идет речь :) А вы как полагает?

Обратная диффузия

Диффузия (лат. diffusio — распространение, растекание, рассеивание) — процесс взаимного проникновения молекул одного вещества между молекулами другого, приводящий к самопроизвольному выравниванию их концентраций по всему занимаемому объёму. В некоторых ситуациях одно из веществ уже имеет выравненную концентрацию и говорят о диффузии одного вещества в другом. При этом перенос вещества происходит из области с высокой концентрацией в область с низкой концентрацией (против градиента концентрации).

Так происходит в неживой природе. Если же рассмотреть живую природу и, в частности, человеческую среду, то мы, главным образом, будем сталкиваться с "обратной диффузией". Единственное, что ее объединяет с классической - наличие градиента. Градиент - это главная движущая сила прогресса :) Шютка.

Представьте, существуют две компании. Каждая из них занимает некоторую нишу, имеет штат сотрудников и испытывает недостаток в квалифицированных профессионально подготовленных кадрах. При этом одна компания более старая, другая более молодая. Одна уже со сложившейся корпоративной культурой, этакий ЗУБР, почти семья (может быть). Другая молодая амбициозная энергичная АКУЛА бизнеса. Каждая компания готова платить и платит значительно выше средней по региону зарплату. Однако молодая компания может платить значительно больше (разница может составлять до 4 и более раз). С другой стороны у молодой компании гораздо выше требования к сотруднику, его исходным умениям и навыкам. Имеем два градиента. Первый зарплатный, он положительный относительно АКУЛЫ, другой (требования к начальному уровню) тоже положительный относительно АКУЛЫ. Парадокс ситуации в том, что первый градиент притягивающий - ГП - (вопреки классической диффузии), а второй как потенциальный барьер наоборот отпугивающий - ГО. Получаем некую формулу ГП/ГО и ряд следствий:
ГП/ГО > 1 (или много больше единицы) - вероятность утока сотрудников от ЗУБРА к АКУЛЕ очень высокая
ГП/ГО = 1 или около того, тут возможно будут играть какие-то факторы дополнительного характера, типа получить новый опыт, интереснее и т.п.
ГП/ГО < 1 возможен переток от АКУЛЫ к ЗУБРУ, правда тут еще следует смотреть отношение ЗП одной компании к другой.
В эту нехитрую формулу стоит добавить дополнительных факторов и учесть иные влияния.

Или лучше присмотреться к закону Фика?

суббота, 3 сентября 2011 г.

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

Оригинал статьи: How to Write Good Use Case Names – 7 Tips

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

Цели именования вариантов использования
При определении имени или названия для варианта использования перед вами стоят следующие цели:

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

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

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

Вот несколько наилучших рекомендации, собранных по всему Интернету:

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