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

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

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


==
Заказчик обращается к разработчику ПО с просьбой разработать софт. В ходе интервью выяснилось что:

  • Много лет эксплуатировалась система, написанная на чем то канувшем в лету. Но, но, но. Развивать систему стало почти невозможно. Где вы найдете разработчика под турбобейсик или вторую лисичку [1]?! Как интегрировать с другими системами? Ну и т.д.
  • Была приглашена студия, реализовавшая требуемый функционал, но опытно промышленная эксплуатация выявила полную непригодность системы.
  • Это система учета платежей за электроэнергию для областного центра. 200 тыс. платежей в месяц, 5 операторов вводят по 2 000 платежей в день.

Далее в ходе интервью использовалась диаграмма Исикавы.

Первая ветвь:
- Что не устраивает в системе?
- Да с этой системой нам нужно увеличить число операторов в десяток раз
- А почему?
- Так очень медленно все. Раньше по десять-пятнадцать платежек в минуту вводили, а сейчас за три в минуту впору премию давать. Да и ругаются операторы и нервничают. Опять же каждые полчаса чай уходят пить для успокоения нервов. Опять же время.
- А почему так медленно?
- Раньше как было: одной рукой держишь платежку, а другой по дополнительной клавиатуре колотишь. Там только цифры и Enter нужны. Шесть цифр (номер), Enter, сумма Enter - на одну платежку три-пять секунд надо. А новой системе модный оконный интерфейс появился. Три секунды окно открывается, номер, потом мышкой на другое поле щелкнуть, …
- Почему получился такой интерфейс?
- Потому что в спецификации требований не было прописано такое требование к интерфейсу, как: “Ввод пачки из ста платежек не более 10 мин, оператором владеющим навыком набора на уровне ..-го разряда”

Вторая ветвь:
- Что еще не устраивает в системе?
- Ошибок много допускают.
- А почему?
- Раньше как было: номер ввел - сразу напротив ФИО появляется. А поскольку правая рука только по дополнительной клавиатуре отстукивает, смотреть на клавиатуру не надо, то оператор сразу ошибку заметить может.
- А в новой системе?
- А в новой системе ничего не появляется. HTML говорят. Нельзя говорят [2]. Нужно всю пачку вбить, потом заново открыть и опять все платежки по одной перебрать.
- Почему получился такой интерфейс?
- Потому что в спецификации требований не было прописано такое требование к интерфейсу, как: “Число ошибок в наборе номера лицевого счета не должно быть больше трех на 10 000 платежек”.

Третья ветвь:
- А …
- ***
- Потому что в спецификации требований не было прописано такое требование к интерфейсу, как: “Время обучения работе с программой сотрудника с квалификацией опытный пользователь ПК не более 16 часов”.
=======
Честно говоря, за фразу в спецификации требований “Интуитивно понятный интерфейс” команду разработки нужно посылать в сад. Потому как это не требование, а детский сад, штаны в горошек.

[1] Лисичка – это foxpro, а не firefox.
[2] По поводу Ajax, Java и прочих флешей. Да, Ajax может подтягивать данные. Только вот использование Ajax ухудшает такую метрику качества ПО, как “расширяемость”. Не говоря уже о том, что бы реализовать обход грида по Enter, с автоматическим добавлением строк. Не, можно конечно сделать. Но глядеть на этот код без валерьянки будет тяжело.

Комментариев: 3

  1. Dart написал:

    Для того, чтобы выделенные жирным фразы попали в подписанный контракт нужен невероятный уровень доверия между заказчиком и исполнителем. 99% руководителей вам скажут, что это просто “попадалово”.
    Либо нужно очень четко прописать методику тестирования. Особенно про три ошибки :) . Я бы на месте заказчика с помощью этой фразы нашел бы способ не заплатить исполнителю. Посадил бы “своего” человека, который будет специально делать 4 ошибки в 10′000 платежек и выторговал бы себе скидку в NN% за доп. соглашение в котором этот пункт договора будет отменен :) .
    Сама идея то понятная - просто доведена до крайности.
    Лучшим вариантом, на мой взгляд, является утверждение прототипа пользовательского интерфейса.

  2. SALar написал:

    > 99% руководителей вам скажут, что это просто “попадалово”.
    Более того, так обычно и бывает.

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

    Еще момент. Лучше работать не с ограничениями, а с функцией потерь Тагути, но до этого нам пока как до луны.

  3. serguei_tarassov написал:

    Уважаемый тёзка, случайно набрел на ваш журнал. Много интересных материалов, они тематически перекликаются с тем, что я и мои коллеги пишем на арбинаде.
    Предлагаю каким-нибудь образом давать перекрестные ссылки :)
    Например, могу вставить ваш RSS в агрегатор новостей.

    По поводу требований к ПИ. Вам не кажется, что сейчас повсеместно формальные методы пытаются заменить т.н. “кейсами” ? Не только в ИТ, а вообще везде.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.