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

Сильный пользователь

Читая работы Ф. Новикова, обнаружил интересное наблюдение, сделанное в Microsoft и развитое Ф.А. Новиковым. Например, в книге "Microsoft Office XP в целом" читаем:
Сильный пользователь силен: если захочет, он может все (или почти все). Он может без видимого ущерба для здоровья часами работать за компьютером, прочитать от корки до корки книжку в 1000 страниц (если она ему интересна), самостоятельно научиться пользоваться новой версией любого приложения (если ему это очень нужно). 
Сильный пользователь практичен: он пользуется программами для решения конкретных задач, а не из праздного любопытства и не от нечего делать. Задачи, которые решает сильный пользователь, всегда имеют статус важных и нужных. 
Сильный пользователь смел и инициативен: он не боится браться за новые задачи и пробовать новые методы на старых задачах. Отдельные неудачи его не смущают. 
Сильный пользователь обязательно является высоким профессионалом в своей предметной области и совсем не обязательно - в области информационных технологий и программирования.
В своей диссертации "Методы алгоритмизации предметных областей" Фёдор Александрович дает такое определение сильному пользователю:
Сильный пользователь (оракул) может ответить на любые вопросы о предметной области...

воскресенье, 30 октября 2011 г.

Омут памяти. Системная инженерия

http://www.slideshare.net/ailev/ss-998595 - слайд-лекция Анатолия Левенчука
http://ru.rise-russia.org/rusec2010 - проблемы системной инженерия (российская конференция)
http://www.osp.ru/os/2002/05/181460/ - Системная инженерия программного обеспечения: введение
http://www.e-joe.ru/i-joe/i-joe_02/files/batovrin.pdf - ОБРАЗОВАНИЕ В СИСТЕМНОЙ ИНЖЕНЕРИИ – ПРОБЛЕМЫ ПОДГОТОВКИ СПЕЦИАЛИСТОВ ДЛЯ СОЗДАНИЯ КОНКУРЕНТОСПОСОБНЫХ СИСТЕМ
http://academy.ibs.ru/content/aca/624/6244-article.asp - Программа курса - 72 часа
http://www.aticourses.com/fundamentals_of_systems_engineering.htm - ATI's Fundamentals of Systems Engineering course

среда, 26 октября 2011 г.

Ticket Sale Automaton (Source)

This is task that I give to my students during course of Modeling Systems
There is simple task: make a model and simulate it
The automaton can be given by
transition function:

output function:



Then we can build the model in Matlab:Simulink

and in Stateflow
the first variant

and
the second one

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

Translated copy of MailModelioOpensource-Sept2011-russian.doc
Среда с открытым исходным кодом для моделирования на UML и BPMN
Компания Modeliosoft и сообщество modelio.org рады сообщить о рождении первой профессиональной среды моделирования с открытым исходным кодом.
В результате 20-ти лет непрерывного совершенствования и инноваций Modelio 2.0 выходит под лицензией GPL и становится первой профессиональной средой с открытым исходным кодом для моделирования на UML и BPMN - средой, по качеству сравнимой с лидерами этой области.
  1. Modelio - единственная среда моделирования c  открытым исходным кодом, поддерживающая одновременно UML и BPMN и позволяющая моделировать широкий спектр различных систем. 
  2. В магазине Modelio Store вы найдете широкий выбор расширений (модулей) с открытым исходным кодом включая:
  1. генератор (и реверс) кода на Java;
  2. систему моделирования  архитектуры предприятия на базе TOGAF;
  3. систему моделирование производственных систем  на базе SysML;
  4. и многие другие расширения.
Открытое сообщество modelio.org управляет разработкой Modelio и различных расширений (модулей) для многих областей моделирования. Пользователи Modelio могут свободно обращаться в магазин Modelio Store, где найдут широкий выбор модулей, как с открытым исходным кодом, так и коммерческих.
Modelio распространяется под лицензией GPL, но движок модулей для Modelio распространяется под лицензией Apache, а это означает, что любой разработчик может создать модуль для  Modelio и распространять его под любой лицензией включая коммерческую. Магазин Modelio Store открыт для разработчиков, вы можете свободно распространять ваши модули, используя нашу платформу.
Modeliosoft - это коммерческая структура, которая разрабатывает бизнес-решения на базе платформы Modelio. Modeliosoft обеспечивает гарантии для Modelio, поддержку и консультационные услуги, а также предлагает широкий набор бизнес-ориентированных расширений. Таким образом,  наши клиенты получают доступ к дистрибутивам платформы и бизнес-решениям, для которых Modeliosoft предоставляет гарантии и сервис, а также к разработкам сообщества modelio.org.
Само собой разумеется, что Modeliosoft продолжает обеспечивать техническое обслуживание и поддержку для всех пользователей Objecteering и более ранних версий Modelio.
  1. Скачайте Modelio c открытым исходным кодом на www.modelio.org.
  2. Скачайте и попробуйте в действии  модули для Modelio в магазине Modelio Store.
  3. Скачайте и попробуйте в действии дистрибутивы и бизнес-решения от Modeliosoft на www.modeliosoft.com.
  4. Примите участие в разработке Modelio и вступите в сообщество modelio.org.

суббота, 8 октября 2011 г.

КЛИЕНТ! ВСЕГДА! ПРАВ!

Именно так и никак иначе следует считать, если ты зарабатываешь на том. что продаешь свои или чужие товары, или оказываешь какие-то важные услуги за деньги. Ясно, что ты делаешь это для того, чтобы получать деньги, прибыль. Как ты будешь использовать другой вопрос. Здесь весьма важна твоя репутация. Если ты будешь отказывать клиенту в его правоте, это может сказаться на твоей репутации, и ты можешь остаться без клиентов. Удержание клиента в 12 раз дешевле, чем привлечение нового. И совершенно плохо, когда от тебя уходит клиент к кому-то другому.

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

История такова, понимаю, мало кто сюда забредет, и заинтересуется текстом, и уж вовсе вероятность того, что кто-то еще и даст комментарий, исчезающее мала, но прет, понимаете, нужно излить желчь мысли  на бумагу.
Клиент - некоторая организация, имеющая штаты  и пытающаяся их учитывать и управлять ими.
Рамки разговора - автоматизированная система кадрового учета.
Предмет разговора - возможность неоднократного приема сотрудника организации как внутреннего совместителя.
Действующие правила:
- 1. сотруднику может быть оформлен только один приказ на приме по основному месту работы (т.е. сотрудник работает по основному месту работы только на одной должности и в одном подразделении одновременно)
- 2. сотрудник может быть принят по совместительству несколько раз
- 3. сумма ставок по внутреннему совместительству не превышает заданного числа (обычно 0.5)
- 4. сотрудник не может быть принят по совместительству в тоже самое подразделение и на ту же саму должность (штатная единица), если он уже был принят на эту штатную единицу по совместительству
Проблема или потребность клиента - нужно чтобы была возможность неоднократного приема по внутреннему совместительству на одну и ту же штатную единицу, т.е. необходимо отменить правило 4.
С чем это связано? Рассмотрим пример:
пусть сотрудник Х был принят по совместительству на 0.25 ставки штатной единицы Y.
по какой-то причине образовалась вакансия по этой же штатной единице, которую решено дать сотруднику Х, т.е. увеличить занимаемую сотрудником Х 0.25 ставки на 0.5 ставки.
Сейчас система позволяет это делать просто, оформляется кадровое перемещение  с изменением количества занимаемых ставок (а следовательно и получаемых денег) и дополнительное соглашение к трудовому договору.
Юрист организации считает, что это неправильно, что сотрудника нужно не переводить (хотя переводом это сложно назвать) а вновь принять на туже самую должность еще раз на 0.25 ставки, заключить с сотрудником Х новый трудовой договор, оформить новую личную карточку. Продиктовано это тем, что при первом приеме был заключен договор, при котором сотруднику гарантировались определенные условия, а в случае кадрового перемещение на 0.5 эти условия типа изменяются и частично теряются. Потому и надо отдельно принять сотрудника Х еще на 0.25 ставки отдельным приказом оформить с ним ТД параллельный первому и тогда все будут счастливы.
Я не искушен в столь сложных юридических перепитиях, но мне кажется это полным бредом. Почему нельзя просто указать (описать) эту ситуацию в допсоглашении, например, что устанавливается 0.5 ставки до выхода основного сотрудника на работу. Почему это ущемляет права сотрудник работающего как ВНУТРЕННИЙ СОВМЕСТИТЕЛЬ???

Однако внимательно подумав и взвесив все за и против, пришел к выводу, да проще дать такую возможность, пускай решают сами. Таких ситуаций у меня было немало в практике взаимодействия с этим клиентом. Каждый раз все равно, мы делали им то, что им хотелось, несмотря на то, что это было похоже на бред. Главное, что клиент доволен?!


воскресенье, 2 октября 2011 г.

Автоматизация тестирования: через терни к звездам?

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

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

Я как человек науки привык сначала исследовать поле деятельности, понять перспективы, правильные и неправильные пути. И по началу автоматизация меня не привлекла. Слишком сложно, слишком долго, много требуется первичных высокопрофессиональных навыков. Кроме того, много критики в публицистике: книгах, интернет-печати, на форумах, в блогах. С другой стороны ежедневные повторения одного и того же в ручном режиме, монотонно повторяя один чек-лист за другим, бессилие перед Горой "руды", которую следует перелопатить и желательно, нет НУЖНО, было лопатить ежедневно - все это + мудрое и настойчивое наставничество руководителя проекта, его вера в чудо автоматизации, привело нас к однозначной ставке на автоматизацию тестирования.

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

Среди средств автоматизации мы выбрали TestComplete. По честности сказать, особо выбирать-то и не пришлось. Почитали обзоры, форумы, поговорили. Скачали демоверсию, месяц ее погоняли. Решили покупаем. Купили и не жалеем. Тем более, что в конце концов пришли к выводу, что вполне по зубам все-то же делать, используя, например, ту же Visual Studio.

Первые опыты были далеки от совершенства. Первая версия была 6.5. Первая проблема, с которой мы тогда столкнулись, как нам сделать наше тестируемое приложение открытым, чтобы обеспечить доступ к непосредственно к объектам и их методам. Рекомендации на форумах предлагали особую компиляцию тестируемой программы. Это в разы увеличивало ее размеры, существенно сказывалось на производительности тестового стенда и устойчивости взаимодействия ТС и тестируемого приложения.
Вторая проблема, во многом перекликалась с первой. При тестировании через графический интерфейс нам часто приходилось обрабатывать координатные клики. О, вы просто не представляете, какие эмоции у нас вызывали самые незначительные изменения в расположении элементов на формах. Другой момент - это регионы. Никогда не пользуйтесь регионами. Это зло, зло! Ну в некоторых ситуациях, конечно, иначе никак.
Первые 40 или 50 тестовых процедур, охватывающих три наиболее важных направления, увидели свет примерно через пару месяцев работы. Первый ночной полностью автоматический (без участия человека) прогон дал просто ошеломляющие результаты. Простая систематичность и скрупулезность проверки роботом показали свое преимущество. Было чертовски осознавать, что ты сумел удивить окружающих. Правда, они это не показывали. Можно было догадаться по второстепенным признакам.
Следует отметить, что сразу нами были заложены верные принципы . В данном случае это довольно универсальные процедуры, управляемые данными. Мы скармливали таким процедурам хорошо подобранными парами данные - результаты. Причем эти же процедуры использовались для начального получения результатов, которые потом анализировались. Результат анализ приводил либо к описанию дефекта, либо к получению ожидаемого результат для автотестов, либо к идеям расширения тестовых ситуаций и поиску нужных тестовых данных.

Тут я поехал в командировку на учебу в Воронеж. А когда вернулся ... Ну это будет продолжением серии :о)



Изучаем возможности редкатора

Зачеркнуто,   Подчеркнуто и т.п.

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

понедельник, 29 августа 2011 г.

Узелок на память 2

Как писать хорошие названия для вариантов использования

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

вторник, 2 августа 2011 г.

Почему "Заметки энтомолога"?

Почему "Заметки энтомолога"? Да так получилось! Как-то кто-то из ведущих программистов, наших отечественных зубров программирования, кивая на группу тестирования, бросил ".. да спросите вон у энтомологов".
Мне название понравилось, почему нет, оригинально. Пусть будут заметки энтомолога. Правда, сам блог в сети пришлось назвать иначе: заметки энтомолога - entomologistnotes - слишком длинно и сложно, назвал пока insectfinder:  finder - искатель, охотник; insect - насекомое (жучок).