Уровень качества софта

velkin velkin

Уровень качества софта


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

Пользователю нужно.
1) решить свою задачу
2) потратив наименьшее количество усилий.

И то и другое играет важное значение.

Решить свою задачу


Если пользователь не может решить свою задачу используя данную программу или используя только данную программу, то есть ему будут нужны другие программы чтобы выполнить поставленную задачу, очевидно он будет не удовлетворён.

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

Потратить наименьшее количество усилий


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

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

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

Конкуренты в нише софта


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

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

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

Графический интерфейс программ


В некоторых задачах пользователям необходимо лишь запустить программу для работы в автоматическом режиме. Для этого достаточно двух кнопок, или одна совмещённая, или вовсе их отсутствие, когда работа начинается после запуска самой программы. Команды остановить может и вовсе не быть, тогда программа будет решать задачу пока не доделает её до конца.

полная автоматика при запуске программы
*
*
*

запуск решения задачи до полного завершения
**************
* запустить  *
**************

решение задачи с возможностью остановки
**************  **************
* запустить  *  * остановить *
**************  **************

Пресеты настроек


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

заранее заготовленные пресеты
**************  **************
* запустить  *  * остановить *
**************  **************

******************************
* выбор пресетов настроек \/ *
******************************

******************************
* свойство     * значение    *
******************************
* выбор        * да          *
* число        * 123         *
* текст        * йцукен      *
*              *             *
******************************

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

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

Макросы действий


В упрощённом случае макросы можно воспринимать как последовательность различных действий. Действие так же может содержать пресет настроек.

список действий
**************  **************  *********************
* запустить  *  * остановить *  * выбор действия \/ *
**************  **************  *********************
**************  **************  *********************
* запустить  *  * остановить *  * выбор действия \/ *
**************  **************  *********************
**************  **************  *********************
* запустить  *  * остановить *  * выбор действия \/ *
**************  **************  *********************

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

Возникает дилемма.

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

Далее следует целая пачка вопросов.

1) Много ли людей дописывали для чужих программ плагины?
2) Были ли эти плагины так же эффективны как решения разработчиков софта?
3) Легко ли устанавливать плагины из сторонних источников?

По сути полезные сторонние плагины для программ показывают некомпетентность разработчиков софта. На мой взгляд правильнее делать такой функционал основным.

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

Выбор пользователей


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

В свою очередь уровень качества софта стаёт непреодолимым барьером на пути распространения программ разработчики которых этого не понимают. Рекламные бюджеты могут "заставить" пользователей посмотреть программу, но что толку, если уровень удержания будет крайне низок.

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

К сожалению большинство программ в том числе очень раскрученных написаны крайне плохо, что в конечном счёте заставляет пользователей их покидать теряя все наработки.
Ikemefula
Ikemefula
18.02.2022 03:09
Здравствуйте, velkin, Вы писали:

V>

Уровень качества софта


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


V>
Пользователю нужно.
V>1) решить свою задачу
V>2) потратив наименьшее количество усилий.

Качество не проверяется метриками. Качество это степень соответствия требованиям. Такие вещи, как п1 и п2 неверифецируемы. Для того, чтобы с этим можно было работать, нужно сформулировать внятные требования,
т.е. раскрыть п1и п2. Тогда все части приложения можно проверять практически на всех этапах разработки (дизайн, прототип, архитектура и тд и тд)
Такая "метрика" может использоваться при выработке требований для того же UI, когда есть конкретные юзкейсы, например "а давайте пусть основные юзкейсы будут выполняться не более чем в два клика" Тогда можно сформулировать внятное требование под этот юзкейс и предложит внятный дизайн UI который это покрывает.