OberonCore
https://forum.oberoncore.ru/

Формирование требований к качеству вьюшек ПО
https://forum.oberoncore.ru/viewtopic.php?f=121&t=4272
Страница 1 из 1

Автор:  Владислав Жаринов [ Вторник, 26 Февраль, 2013 09:58 ]
Заголовок сообщения:  Формирование требований к качеству вьюшек ПО

Дабы не откладывать в "долгий ящик" вновь обозначившийся вопрос - пущай будет и такая тема... :)
Предполагается, что сюда, как и в "Терминологию..." кидаем свои формулировки, даём замечания и предложения и обкатываем. По тем же правилам, надо думать... А всё обкатанное будем сводить в отдельную ветку.

Автор:  Владислав Жаринов [ Вторник, 26 Февраль, 2013 10:03 ]
Заголовок сообщения:  Критерий 1 от А. Донского

Вот как было понято:
Владислав Жаринов в viewtopic.php?p=74070#p74070 писал(а):
...
Вот одно правило Вы сформулировали - марш схемы, как он "развершинен в цепочку" сочинителем, нужно показывать так только в определённом масштабе (диапазоне плавного масштабирования), а при изменении масштаба менять и правила отображения.
...
- с последующим уточнением:
Alexey_Donskoy в viewtopic.php?p=74071#p74071 писал(а):
...
Человек очень легко, автоматически, решает задачи на экстраполяцию движения.
Поэтому, раз приняв принцип движения сверху вниз (обоснованный принцип!), человек легко (подсознательно) решит задачу "схватывания маршрута", и ему для этого не потребуются никакие "ритмические полосы". Нет их - и не надо, и так всё прекрасно понятно. ...

Кто следующий? :)

Автор:  Ярослав Романченко [ Вторник, 26 Февраль, 2013 11:52 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Плюшки ПО тоже в эту ветку? :lol:

Автор:  Владислав Жаринов [ Среда, 27 Февраль, 2013 05:36 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Да всё, что служит цели. :) От разработки/юзания "являющего вьюшки" ПО ли определилось, или от создания вьюшек при помощи карандаша и ластика... :wink: Или как в этой теме - топикстартер взялся делать офисными средствами, проверять на аудитории, и у него стали образовываться, наряду с содержательными, также критерии качества формы...

Тут должны получаться высказывания вида: "Из <такого-то> опыта исследований/практики/обучения считаю, что наличие/отсутствие/значение <такого-то> свойства вьюшки лучше/хуже для восприятия/осмысления[ в <таком-то> выделяемом мной показателе эффективности/надёжности применения вьюшек человеком]".
    В данном случае неважно, специалист ли по вьюшкам (т.е. инженерный психолог) говорит. Важно, чтобы был материал для профессиональных исследований/"прямого постижения"... Отсюда и шкалы для значений (качественные/количественные), и формулировки свойств и показателей говорящий вводит по своему разумению. Потом заинтересованные участники разбираться будут... в т.ч. специалисты, если таковых удастся кому-то заинтересовать... :)

В итоге должна получиться структура вроде этой (отсюда):
Вложение:
Губинский-НадИКачФункЭС-извл(Рис1-ЭффКачНадЭС).jpeg
Губинский-НадИКачФункЭС-извл(Рис1-ЭффКачНадЭС).jpeg [ 1.91 МБ | Просмотров: 11050 ]
или этой (отсюда):
Вложение:
Рябов-ГуманиТехнОргПроектИРазв-извл(Рис5_6).jpeg
Рябов-ГуманиТехнОргПроектИРазв-извл(Рис5_6).jpeg [ 1.8 МБ | Просмотров: 11050 ]
- т.е. структура критериев, для каждого из которых установлены "попугаи" - размерность и шкала. :)
Замечу, что искомая структура так или иначе будет частью любой из представленных схем...

Автор:  Ярослав Романченко [ Среда, 27 Февраль, 2013 06:27 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

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

Автор:  Владислав Жаринов [ Среда, 27 Февраль, 2013 07:28 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

О! Уже дело. :) Прежде всего имел в виду сами модели как "интерфейс к смыслу представляемого", но и "интерфейс к интерфейсу" важен...
А Вы можете сказать, по субъективным ощущениям например, почему дерево удобнее (принимая терминологию Рябова, требует меньших энергозатрат на управление, наверное... может, и времени)?
Вы вообще имеете в виду такие, например, формы:
Вложение:
Окно - DesignIDEF - СтрДерУзлов (Задача ПрД).jpg
Окно - DesignIDEF - СтрДерУзлов (Задача ПрД).jpg [ 76.58 КБ | Просмотров: 11044 ]
- или такие:
Вложение:
Окно - DesignIDEF - СтрСтраниц (Задача ПрД).jpg
Окно - DesignIDEF - СтрСтраниц (Задача ПрД).jpg [ 34.04 КБ | Просмотров: 11044 ]

- это отсюда: viewtopic.php?p=78168#p78168?..

Кстати, согласен - мне в ДизайнИДЕФе эти страницы здорово помогали...

Автор:  Владислав Жаринов [ Среда, 27 Февраль, 2013 07:34 ]
Заголовок сообщения:  Критерий 1 от меня

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

Автор:  Ярослав Романченко [ Среда, 27 Февраль, 2013 10:58 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Я эти контролы имел в виду.

Вложения:
Tabs.png
Tabs.png [ 1.96 КБ | Просмотров: 11033 ]
Tree.png
Tree.png [ 6.01 КБ | Просмотров: 11032 ]

Автор:  Владислав Жаринов [ Четверг, 28 Февраль, 2013 05:20 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

А, путь к текущему месту на модели как частный случай - "вариант использования" дерева модели... Да, тоже надо...

Автор:  Ильченко Эдуард [ Четверг, 28 Февраль, 2013 08:47 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Ярослав Романченко писал(а):
Мой шеф ненавидит TreeView (деревья) и Tab (закладки) диалоги.

А что любит шеф в качестве альтернативы указанным сущностям?

Автор:  adva [ Четверг, 28 Февраль, 2013 08:50 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

По моему и деревья, и закладки помогают упорядочить информацию (в этом плане нравится onenote). Возможно есть им альтернатива в виде "каши" (все в одном месте) и в компе, и в голове (сам этим страдаю)

Автор:  Владислав Жаринов [ Суббота, 02 Март, 2013 10:06 ]
Заголовок сообщения:  Критерий 2 от А. Донского

Вот ещё на сходную тему:
Alexey_Donskoy в viewtopic.php?p=74056#p74056 писал(а):
...
Текст схватывается быстро (привычка), но есть эффект "смотришь в книгу - видишь фигу". Чтобы понять увиденный текст, необходимо заново его прочитать. Причём внимательно прочитать, а то та же фига и выйдет. Но тут возникает проблема - фокус зрения давно убежал, уведённый в неизвестную сторону гомогенной средой (произошла потеря визуального контекста). Теперь, прежде чем внимательно прочитать текст, его ещё нужно найти.
Найти нужный элемент легко, когда вся среда состоит из разнокалиберных объектов, за взаимное расположение которых мозгу очень легко зацепиться (привык он с младенчества к такой работе, да и нейронная сеть по сути так работает).
Если же среда гомогенная (состоит из ровных линеек одинаковых объектов), то зацепиться мозгу не за что, нейросеть при любой точке фокуса выдаёт практически одинаковые сигналы, и получается поиск иголки в стоге сена.

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

Почему - потому что по ассоциации вспомнилось, как ищется нужное в книге. Бывает, вспомнишь что-то нужное есть там-то - но помнишь не точное место, а... примерно как на странице (развороте) это расположено... :) И начинаешь искать, фокусируясь на этой части формата... Иногда ещё примерно помнится, в какоой части документа.

Похоже, как-то связано с утверждаемым... в подтверждение или опровержение... Скорее подтверждает - ибо похоже, что и здесь можно сказать, строится образ документа "нетекстовый, многомерный какой-то" ((С) И. Ермаков)... :) тока уже с "тегированием" фрагментов по целям, существенным на момент прочтения...
Наверное, интуитивное понимание этого привело и к такой вьюшке документа, как представлена здесь: viewtopic.php?p=78188#p78188. Ибо так можно строить и "пейзаж", более комфортный для восприятия... правда, снова встаёт вопрос о критериях комфортности, их возможных индивидуальных/групповых вариациях...

Автор:  Дмитрий_ВБ [ Четверг, 28 Март, 2013 09:09 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

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

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

из ГОСТ Р 61508-3 (ГОСТы Р 61508 - аналог европейских стандартов МЭК 61508):

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

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

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


Кстати, по поводу соотношения алгоритма и программы.

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

Автор:  Madzi [ Четверг, 28 Март, 2013 23:18 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Ярослав Романченко писал(а):
Мой шеф ненавидит TreeView (деревья) и Tab (закладки) диалоги. TreeView контролы по причине, что их якобы не любят пользователи - не пойму на основе каких исследований и пожалуй таких исследований просто нет. И во всех массовых продуктах деревя как-раз массово заменяют эти неудобные закладки (пожалуй они действительно не удобны).

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

Ещё его никак не убедить в необходимости соблюдения правила 7+/-2 (о количестве элементов на вьюшке). Именно такое число оптимально для восприятия. У нас же стараются запихнуть как можно больше, в результате не воспринимаемая каша.

Ну и классика жанра - расположение кнопок (Ok) (Cancel) вместо (Cancel) (Ok).

Автор:  Илья Ермаков [ Пятница, 29 Март, 2013 01:58 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Madzi писал(а):
Ну и классика жанра - расположение кнопок (Ok) (Cancel) вместо (Cancel) (Ok).


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

Я, например, для операций удаления в ИСах практикую текстовое поле, в которое надо вручную вписать имя удаляемого объекта....

Автор:  Александр Ильин [ Пятница, 29 Март, 2013 02:09 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Madzi писал(а):
Ну и классика жанра - расположение кнопок (Ok) (Cancel) вместо (Cancel) (Ok).

А какая ОСь? Винда? В Винде прописано в гайдлайнах, как должны быть расположены кнопки.

Кстати, я вас умоляю! OK пишется двумя заглавными буквами.

Автор:  Владислав Жаринов [ Пятница, 29 Март, 2013 10:26 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Дмитрий_ВБ в viewtopic.php?p=78912#p78912 писал(а):
Представляется интересным формирование требований к просмотрщикам
исходного кода ПО для использования их в целях верификации ПО

...

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

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

Автор:  Madzi [ Пятница, 29 Март, 2013 22:41 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Александр Ильин писал(а):
Madzi писал(а):
Ну и классика жанра - расположение кнопок (Ok) (Cancel) вместо (Cancel) (Ok).

А какая ОСь? Винда? В Винде прописано в гайдлайнах, как должны быть расположены кнопки.

Кстати, я вас умоляю! OK пишется двумя заглавными буквами.

Web приложение - так что оно теоретически может быть запущено под любой ОС.

Есть забавные исследования по поводу порядка кнопок. Например, что глядя на форму - мы пробегаем глазами всю форму. И если последовательность сначала (Ok) а потом (Cancel), то мы вынуждены вернуться к (Ok). В то время когда используется последовательность (Cancel) (Ok) - дойдя до (Ok) мы уже видели все кнопки и точно знаем что нам нужно (без возврата).

Александр Ильин писал(а):
Кстати, я вас умоляю! OK пишется двумя заглавными буквами.

Я в курсе, просто CamelCase привычка. + это не название кнопки, а скорее смысловое наполнение. Названия у нас русские "Добавить"/"Отменить" и т.п.

Автор:  Владислав Жаринов [ Воскресенье, 12 Май, 2013 20:44 ]
Заголовок сообщения:  Re: Формирование требований к качеству вьюшек ПО

Нашёл ряд требований от Донского, тоже сюда:
в viewtopic.php?p=74302#p74302 писал(а):
...
Но ряд предложений в смежных темах и здесь озвучил ведь:
    - плавные линии, закруглённые контуры (вместо острых прямоугольников и изломов);
    - масштабирование (тут где-то упомянули термин drill down/up), где при наведении мыши, клике и т.п. разворачивается/сворачивается детализация внутри элементов;
    - обозначение масштабирования, где фокус внимания изображён чётко, а контекст (например, структура) размыто и сильно приглушённым контрастом (вместо одинаковых чёрных линий, от которых чертёж хочется повесить на стену... обратной стороной...); сюда же предложение на некоторых масштабах вообще отказаться от контуров элементов, оставив равномерно закрашенные фигуры;
    - чётко (в том числе визуально) разделить маршрутные линии от потоков данных (да, потоки данных ещё и ввести надо ;) );
    - оптимизировать базовые алгоритмические элементы (особенно развилку и переключатель - который вообще состоит из раздельных, визуально слабо связанных элементов);
    - чётко отделять структурную метаинформацию (в т.ч. декларативную) от алгоритмической (так, идея методов объектов на ветках "силуэта" вроде хороша, но сам силуэт никуда не годится. Алгоритмический "силуэт" - можно оставить как есть, а декларативный (с методами, например) изобразить вообще не линиями, а, скажем, вертикальными градиентными полосами);
    - да, и вообще запретить "силуэт", как создающий ненужные и вредные разрывы :lol:

Автор:  Владислав Жаринов [ Воскресенье, 19 Май, 2013 08:02 ]
Заголовок сообщения:  О требовании 3 от Донского

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

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/