Архив рубрики 'Аналитика'

Трассировка требований разных уровней

Пятница, Февраль 26th, 2016

Пояснение.
Материал готовился к докладу “Документ спецификации требований к ПО, а нужен ли он?” на аналитическом онлайн-марафоне “Проектный истории”. Материал в доклад “не вписался”. Оказался чересчур велик и сложен. Это нормально. Обычно на доклад я стараюсь набрать объем материала, с расчетом выбросить две трети. Тем не менее после доклада возник вопрос о трассировке требований разного уровня друг на друга. И тут такая удача - есть рабочий материал.

Дисклеймер.
1. Это рабочий, не конечный материал.
2. Очевидно, в нем есть ошибки. Один из тезисов моего доклада: “Если вы не нашли в формальном документе SRS ошибки, то зачем вы его писали?” Так что, если вы найдете ошибки в моей матрице трассировки, присылайте. Это будет значить, что я его не зря проделал работу.
3. Матрица не полна. Полная матрица в формат доклада никак не лезла. Там было бы очень много элементов. С полной диаграммой хорошо работать на мониторе 60″, с разрешением 4k. Но никак не через “смотровую щель” ноутбука.
4. Это пример, как такие матрицы можно строить. Просто иллюстрация подхода.

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

odhannedhiaea-odhaaiaaiee-aey-iao.jpg

Что лежит за забором?

Вторник, Май 31st, 2011

Если оно выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть.

(c) Капитан Очевидность. http://lurkmore.ru/Капитан_Очевидность

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

В какой-то момент при анализе предметной области выяснилось, что в спецификации требований пропущено описание очень важного функционала. Функционал был весьма нетривиальным, и без подробного анализа и описания пытаться реализовать его было бы э-э-э… нерационально. Если кому интересно, то это был функционал перевода объекта в состояние дубликат с передачей дочерних элементов дублируемому объекту. Ведущий аналитик, который отвечал за этот модуль, написать этот юзкейс оказался не в состоянии. справедливости ради, надо отметить, что с ходу написать этот юзкейс не смогла и группа аналитиков, собравшихся на ЛАФ-2010 (посмотреть можно в материалах с конференции ЛАФ-2010). Да, юзкейск хитрый и требует времени на обдумывание. Вполне себе юзкейс на полдня-день. Не на пятнадцать минут. Ну, или надо быть ведущим аналитиком.
Впрочем, мы отвлеклись. Ведущий аналитик передал эту задачу техническому писателю. Технический писатель не смог решить ее самостоятельно и обратился за помощью к тестировщику. Тестировщик объяснил, синтаксис юзкейсов и как писать именно этот юзкейс. Технический писатель сделал описание. Задача выполнена. Но кто же здесь аналитик, невзирая на то, что написано в трудовой книжке?

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

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

- Теперь я понимаю! - радостно сказал он.

Мы вперили в него взоры, полные ожидания.

- Я понимаю… Ясно, что эта калоша резиновая!

Изумленные, мы вскочили с кресел..

Три причины не писать документацию

Вторник, Декабрь 8th, 2009

Первая. Документация не больно то и нужна.

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

Я предлагаю три метрики:

  • Средний опыт разработчиков. В данном случае это 19+ лет.
  • Средний опыт работы вместе. (21+16+16+12+12+12)/6= 15 лет
  • Средний опыт работы в предметной области

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

Причина вторая. Некому писать.

Действительно, грамотно описать функциональные требования или глоссарий (я уж не говорю про нефункциональные или, тем более, концепцию), это гораздо сложнее, чем закодировать. В результате, вместо требований, которыми можно пользоваться получается скучнейшие “материалы 35 съезда” изложенные косноязычным тинейдрером, знающего только олбОнский, и то с пятого на десятое. Читать это невозможно. Документация становится Write Only. И, в конце концов,  от написания документации отказываются.

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

Причина третья. Команда не умеет читать.

А вот эта проблема по настоящему серьезная.

Типичный пример того, что никто не умеет читать документацию это фразы вида: «Цель проекта внедрения BTS Jira является автоматизация учета багов.»

Я понимаю, у аналитика писавшего ЭТО был неудачный день. Может зубы у ребенка резались и была бессонная ночь. Может быть гриппом болел и голова не соображала. Но то, что из всей команды никто не сказал “Булшит!”, это показатель неумения читать. Писать документацию в этом случае бесполезно.

Проблему усугубляет странная российская система подбора персонала, когда на место разработчика ищется инженер со скилами кодера. Вот типичнейший пример:

Разработчик Java
Требования:

* Обязательные:
Опыт разработки на Java, знание ООП;
Знание  HTML;
Знание и опыт работы с JSP;
* Желательные:
Опыт работы с каким-либо web-framework’ом (JSF, Struts, GWT, Wicked и т.д.);
Опыт работы с какой-либо AJAX-библиотекой (jQuery, Ext-JS, Prototype);
Опыт работы со Spring framework;
Опыт работы с  JDBC, JPA, Hibernate и подобными средствами (взаимодействие с БД);
Опыт работы с WebShpereAS;
Опыт работы с СУБД Oracle;
Опыт работы с EJB;
Опыт работы с Web-сервисами.

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

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

Здесь мерилом успеха считают усталость

Суббота, Ноябрь 21st, 2009
То, что ценим мы и любим, чем гордится коллектив.

- Мы крупная фирма, - произносится это с гордостью.
- У нас работает … сотен / тысяч сотрудников, – и нам есть чем годиться.

Я вот по своему, видимо, невежеству полагал, что крупность фирмы должна измеряться по среднегодовому проходу (продажи минус стоимость материалов), а не по числу занятых стульев. Не будем брать тех, кто занимается продажей техники или сидит на пилораме бюджета. Рассмотрим софтверные фирмы. От коллег я слышал и согласен с ними, что 100 миллионов долларов – это не крупная, а средняя фирма. Хотя таким оборотом действительно можно гордиться.

Чего я ни разу не слышал и это для меня удивительно, так это высказываний следующего типа:
Мы первая и пока единственная российская фирма, достигшая рубежа в $100 млн годового прохода при численности привлеченного персонала всего 150 человек. Таким образом, мы обогнали нашего ближайшего конкурента более, чем в три раза. У него было 700 человек при $150 миллионах.

Коллеги, я ошибаюсь или действительно в РФ не принято хвастать эффективностью фирмы?

Требования к ПИ и их отсутствие.

Вторник, Октябрь 28th, 2008

Интуитивно понятная система — это система, в которой умом нельзя понять что происходит, поможет только интуиция (если вам ее хватит)
(e) …

В конце семинара Базовые инструменты и методы аналитика разобрали практический кейс.

(more…)

Нет ножек - нет варенья.

Вторник, Октябрь 14th, 2008

Мне в детстве мама выколола глазки,
Чтоб я в шкафу варенье не нашел.
Я не хожу в кино и не читаю сказки,
Зато я нюхаю и слышу хорошо!

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

Пусть мы не ходим в кино и не читаем сказки, в смысле потратим немного времени на переделывание, но зато мы нюхаем и слышим хорошо, то бишь сэкономили кучу времени на написание ТЗ.

Что есть тестирование? Это процесс проверки ПО на соответствие спецификации. Нет ножек, т.е спецификации - нет варенья, т.е тестирования.
И более того. Нет ножек - нет разработки.

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

Фантастика, господа, на втором этаже.

Нужно четко формулировать задачу

Вторник, Июль 29th, 2008

1. Пошёл старик к синему морю. Стал он кликать золотую рыбку. А какую рыбку - не уточнил. Приплыла к нему золотая акула. Ну… и всё..

(more…)

TrainingLabs с разных точек зрения.

Четверг, Июль 10th, 2008

Взгляд посетителей
Проблема с информацией. Невинный вопрос на секции тестирования: «Кто был на SQADays?» выявил грустную картину. Там был один человек. Но еще хуже то, что сказала одна из участниц: «Я узнала об этом событии на следующий день после того, как конференция прошла». И что делать? Как донести до потребителей информацию, которую они жаждут получить? Кстати, тем, кто ищет идею для проекта: «В Росси нет нормального, не забитого рекламой канала информации о событиях».

Столько всего вкусного! Выбор первого тренинга многих поставил перед неразрешимой проблемой. Хотелось и туда и туда и туда.

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

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

Взгляд тренера
Я выбрал в качестве темы «базовые методы создания тестовых сценариев». Никаких высоких теорий о преимуществах и недостатках классических или гибких подходов или о регламентах работы. Вот такой вот примитив. Тема, которая мало обсуждается и, насколько мне известно, слабо освещена в литературе на русском языке. С другой стороны это базовые знания тест-аналитика. Очень приятно, что поднятые на тренинге вопросы вызвали живой интерес. По просьбе участников я выкладываю одно из заданий с тренинга [1].

Взгляд организатора
Как это ни грустно, но приходится признать, что сейчас в Москве проблема найти полноценный центр подготовки персонала по программной инженерии. Несмотря на внешне внушительный список в 50 учебных центров, при ближайшем рассмотрении выяснилось, что в массе своей они дают курсы по инструментам вендоров. Есть несколько УЦ, состоящих из объединившихся тренеров, которые дают интересные тренинги, но, как правило, они ограничены одной - двумя областями программной инженерии. Это могут быть модные сейчас методологии, тренинги по управлению проектами,… Но полного спектра нет. Текама предлагает достаточно много тренингов по различной тематике, но не так много готовит внутри. УЦ Люксофт разрабатывает тренинги и закрывает все или почти все области программной инженерии. Сейчас УЦ Люксофт – уникальное явление, и, думаю, в ближайшее время он станет лидером рынка не только по полноте охвата, но и по количеству отчитанных часов (если еще не стал). Никто не хочет составить конкуренцию?

[1] Напомню, о чем идет речь. Есть задание на расчетный модуль. По этому заданию написано несколько (6) алгоритмов. Один правильный, остальные с теми или иными ошибками. Требуется составить тестовый набор, проверяющий эти алгоритмы.

Порядок работы. Тестовые набор поместить в голубую область. Фреймворк покажет достаточен ли этот тестовый набор.
Файл: calc_days.zip

Пример требований к системе. Часть 5.

Четверг, Апрель 10th, 2008

(more…)

Пример требований к системе. Часть 4.

Четверг, Апрель 10th, 2008

Объекты системы

(more…)