В продолжении этого топика ...\r
\r
Качество имеет точку зрения (т.з). С т.з пользователей, к-рые покупают Office - он возможно некачественный (неудобный) продукт, но с т.з менеджеров Майкрософт, отвечающих за Office и к-рые определяли требования (разработчикам Майкрософт, к-рые этот Office создавали) - Office качественный, т.е удовлетворяет их требованиямю. На всякий случай: \r
\r
Качество ПО (Вендров, Липаев) \r
совокупность свойств ПО, к-рые характеризуют способность ПО \r
удовлетворять заданным требованиям. \r
\r
или еще более общее определение: \r
\r
Качество (Розова, "Упрвление качеством") \r
совокупность характеристик объекта, относящихся к его способности \r
удовлетворять обусловленные или предполагаемые потребности. \r
\r
...Каждая потребность выражается рядом требований, которые \r
участвуют в формировании отношений пригодности объекта \r
для целей потребителя, служат для оценки соответствия \r
объекта его назначению... \r
\r
Давно хотел поймать Репликанта за его собственные слова. (хотя, он как всегда извернется - я ни я, и лошадь не моя, и вообще я лишь приводил чужие слова:) ) \r
В постоянном талдыченье "требования, потребности", почему-то не звучит определение самих этих расплывчатых терминов. Заметьте отличие в оттенках, которое при ближайшем рассмотрении оборачивается отличием смысла:\r
... совокупность характеристик объекта, относящихся к его способности \r
удовлетворять обусловленные или предполагаемые потребности ...\r
\r
... пригодности объекта для целей потребителя, служат для оценки соответствия объекта его назначению ... \r
Итак, что это: "обусловленные или предполагаемые потребности"?\r
или "соответствие объекта его назначению"?\r
И какая связь? :)) (я конечно, понимаю, какая связь, но как специалист смело предположу - весьма отдаленная)\r
Мне очень нравяться новые сотовики с цифровой камерой. Это что, некачественный продукт? \r
\r
все это шутка, не берите в голову,\r
а теперь берите:\r
\r
Практически любой программный продукт можно принять как качественный , пример с менеджерами Майкрософт весьма удачен. "Жонглируя" такими весьма субъективными понятиями как "требования" (а я настаиваю, что это именно субъективное понятие, даже тогда, когда оно с пасофом и серьезностью произносится как "объективные требования", ниже поясню свою точку зрения) можно "подогнать" под понятие "качественный" практически любой программный продукт, который ХОТЬ КАК-ТО выполняет заложенный при проектировании список операций (т.е. соответствует требованиям ). Такой взгляд на эти вещи ВЕСЬМА НА РУКУ менеджерам IT, потому что позволяет решать споры с заказчиком путем "прикрытия задницы" бумажками и документами. Здесь и проявляется вовсю (я не побоюсь этого слова) подлость самого подхода менеджеров от IT к потенциальным клиентам. Кто из вас не сталкивался с ситуацией, когда в процессе разработки было очевидно, что некоторые моменты (да почти ВСЕ), можно сделать КАЧЕСТВЕННЕЕ (с точки зрения кода, потребляемых ресурсов и быстродействия, УДОБСТВА и функциональности интерфейса пользователя)? И как при этом реагировали менеджеры? ПРАКТИЧЕСКИ ВСЕГДА ВСЯЧЕСКИ ПРЕПЯТСТВУЮТ "ИЗЛИШЕСТВАМ". Под излишеством понимается все, что при дополнительных трудозатратах не прибавит и копейки в бюджет проекта. Я еще не рехнулся, и бесплатно работать не собираюсь. Речь идет о том, что в стадии выявления этих самых "требований", когда должностные лица, общающиеся с потенциальным заказчиком, сладко "напевают" им об опыте фирмы и высококвалифицированных программистах, на самом деле выполняется совсем другая задача - постараться "забить" в проект необходимый МИНИМУМ, который при должном красноречии можно втюхать заказчику как "отвечающий требованиям". И что самое интересное - ведь будет отвечать, потому как сквозь весь процесс производства ПО будет красной чертой проходить контроль "соответствия требованиям".\r
\r
Позвольте рассказать о нескольких маленьких моментах, которые я "вложил сверх положенного" в один из своих проектов в 2000-м году.\r
\r
Есть фирма. Торгует оптом и в розницу бытовой химией и парфюмерией. Суммарный ассортимент - бешенный. Клиенты - всякие торговые ларьки и магазинчики, берут накладную в 300 строк по 1-2 шт товара на строку (такова специфика). Подавляющее большинство наименований не разбито на подвиды, что составляет некоторое неудобство менеджерам при составлении заказов на закупку, т.к. заказы, как раз-таки, необходимо делать по подвидам. \r
Далее, сама набивка средней накладной в 1С отнимает массу времени. Еще больше времени занимает потом расписывание вместе с клиентом карандашиком на накладной подвидов, чтобы правильно выдали со склада. Накладные с розничных точек (раз в неделю) - бесконечные по объему. Им наоборот, не требуется для пересчета разбивка на подвиды (у подвидов, как правило, одна цена), но приличная часть товара все же разбита на эти пресловутые подвиды, а подвидов одного мыла или шампуня может быть 15-20. \r
Т.е., с одной стороны, есть необходимость разбиения товаров на подвиды, с другой стороны, это может на порядок увеличить учетный ассортимент, и им станет просто невозможно управлять.\r
Я получил этот заказ потому, что потребовалясь сделать самую обычную "двойную" бухгалтерию, и НОРМАЛЬНЫЙ валютный учет (не так тупо как в 1С). Это-то я все сделал. Но в ходе разработки и наблюдения за работниками фирмы добавил (просто так) следующее:\r
1. В таблицу объектов учета добавил поле длиной в байт - номер подвида. Это же поле добавил во все строки таблиц, где фигурирует объект учета. Добавил признак "учитывать по подвидам" на все места хранения. Для каждого шаблона отчета по движениям составил по 2 запроса - по подвидам и суммарный (copy&paste с небольшой коррекцией, не жалко). \r
В результате - оптовые склады стали учитывать по подвидам, розничные - свернуто. Менеджеры стали видеть, какие у них остатки на складах по подвидам, появилась возможность автоматизировать процесс составления заказов. Общий ассортимент уменьшился вчетверо, т.к. треть наименований все же была "разбита", - прайс стал читабельнее, розничные точки - довольны.\r
\r
2. Всвязи с тем, что резко выросло число строк в тех накладных, в который фигурирует товар, разбитый на подвиды, потребовались методы оптимизации работы "девочек" за набивкой накладных. К традиционному способу ввода наименований (pop-up иерархический справочник товаров), я добавил еще 2:\r
1. набор прямо в строке накладной букв наименования, в фоновом режиме происходит фильтрация всех закешированных наименований и выпадает отфильтрованный по первым символам список (как URL-строка в IE, только поживее :)) ). Обычно достаточно 2-3 символа и пару нажатий на стрелочку, чтобы вбить требуемую позицию.\r
2. формирование пустой накладной по ВСЕМУ АССОРТИМЕНТУ. Разумеется накладная не формируется, это все "виртуально", но выглядит именно так. Перед оператором раскрыт иерархический справочник, где в правой части - строки накладных по выбранному прайсу без проставленного количества. Достаточно встать на колонку и "включить скорость", цифра - стрелочка вниз, цифра - стрелочка вниз. Когда "девочка" набивает заказ от клиента по прайсу фирмы, то скорость набора иногда достигает 4 строк/сек, а в среднем - 2 строки/сек. (Для сравнения - опытный оператор 1С набивает 1 строку за 5 сек, т.е. на порядок медленнее).\r
\r
3. Быстродействие. На 1С те же розничные накладные по 1500 строк перепроводились на том же железе 2-10 мин. Я потратил некоторое время (аж 2 ночи), на эксперименты с кешированием и поддержанием актуальности, тюнингом. и т.д. Добился 10-20 сек. Затем переделал тип поля ID у ВСЕХ СПРАВОЧНИКОВ на 16 бит, и ввел систему ручного контроля всех ID из всех справочников, чтобы не терять значения из диапазона 0-65535. (Вряд ли у кого нибудь более 65535 контрагентов, или более такого количества наименований). Этот шаг сам по себе увеличил быстродействие в среднем еще в 4 раза (стало 2-5 сек) и уменьшил примерно в 2 раза объем базы.\r
\r
В общих трудозатратах проекта - 6 мес, все эти дополнительные фишки обошлись примерно на неделю доп. труда, что, согласитесь, "тонет" в общей трудоемкости. Но после этого я услышал: "До чего не качественная это 1С". :) Для меня это была лучшая похвала, ведь я точно знаю, что по приведенным определениям 1С гораздо качественнее моей проги (позволяет более полно охватить все аспекты учетной деятельности предприятия, это все, конечно, решаемо, но требует элементарных трудозатрат).\r
\r
Не могут быть слова некоей Розовой и остальных из того же списка использованы как характеристика КАЧЕСТВА ПО. Потому как в ПО существуют еще понятия: качество архитектуры и качество кода . И не надо отрицать эти понятия, не прививайте дурной тон, эти понятия культивировались десятилетиями. Учитывая, что любую задачу можно решить ( УДОВЛЕТВОРИТЬ ) многими способами, такая трактовка якобы допускает применение НЕКАЧЕСТВЕННЫХ решений для достижения КАЧЕСТВЕННОГО результата. Нас на АСУ учили любую задачу сводить к нахождению минимумов/максимумов таких параметров, как эффективность, потребляемые ресурсы аппаратуры, надежность и т.д. А современные понахватавшиеся манагеры из соседних или даже очень отдаленных специальностей зачастую решают подобные задачи с нахождением только одного минимума - потраченного ВРЕМЕНИ на производство ПО. Это и есть тот самый "деловой" подход, который отличает делового человека от неделового. На простом русском языке - это циничность.\r
Разумеется, что мне как "честному" программисту, уважающему свою профессию, обидно, что за последние 4-5 лет появились такие понятия как "кодер", "программЁр" и т.д., все произноситься с оттенком пренебрежения.\r
Кто-нибудь из "успешно" сдавших проект слышал, что за спиной говорят пользователи их программ? И ведь все это обобщается на всех представителей отрасли.\r
\r
RUP - ну вы ребята малость насмешили, я скажу.\r
Чуть-чуть подразгрубусь на работе и "отгребете" еще по этому вопросу.\r
\r
Мы в свое время изучали МНОЖЕСТВО подходов к проектированию - восходящий, нисходящий, и тот и другой с итерациями, даже расходящийся от "середины" или "сплошной". Была задача не научиться пользоваться какой-то одной группой подходов, а научиться классифицировать и распознавать ситуации, в который тот или иной подход окажется наиболее эффективным. Нисходящий итерационный подход наиболее популярен сейчас, не спорю. Но все что могу о нем сказать - этот способ определенно подходящ для многих ситуаций (но далеко не всех). Это, в основном, из-за того, что сейчас проектированием занимаются не конструкторские бюро, а весьма ограниченный круг людей даже в очень больших фирмах. И использовать другой подход эти люди ФИЗИЧЕСКИ НЕ В СОСТОЯНИИ, т.к. иначе размерность задачи перекрывает суммарные мыслительные возможности выделенных для проектирования людей. Поэтому мы и имеем зачастую спроектированный на уровне "квадратиков и кружечков" (пусть даже где-то немного подробных квадратиков) проект, который при детальном рассмотрении на других уровнях оказывается зачастую весьма слабым. \r
Нисходящий и итерактивный подход подразумевает ВОЗВРАТЫ, и корректировки на каждом уровне в зависимости от результатов , достигнутых на нижлежащих уровнях. Т.е. самый нижний уровень при "чистом" итерактивном подходе должен так же влиять на самый верхний уровень, как и второй сверху :) Мне тут несколько умников-манагеров-проектировщиков почти хором как-то задали нелепый (с моей точки зрения) вопрос: "А как может потоковая библиотека влиять на структуру системы". Если учесть, что было сказано, что она драматически облегчает сериализацию объектов, то даже мало-мальски грамотному проектировщику это многое сказало бы. Напр., что можно было бы закладываться на это в проектировании на самом верхнем уровне, т.к. имеется возможность не напрягаясь перемещать объекты, (CORBA-ой мне не тыкать, там только-только приняли стандарт на перемещение объектов по значению, и я еще не видел ни одной не бета версии, его реализующей), следовательно имеет смысл распараллеливать вычисления, балансировать нагрузку, т.е. менять архитектуру, перерасчитывать те же нагрузки и траффик, а это, как раз, делается на том самом высоком уровне. Господа манагеры, любители давать советы, кто-нибудь из вас при проектировании расчитывает траффик, нагрузку, надежность, среднее время наработки на отказ? :) Я даже ответ знаю, потому что спрашивал реальных проектировщиков неоднократно. На этот вопросы господин проектировщик не в состоянии дать ответ хотя бы потому, что не всегда до конца представляет, КАКИМ ИМЕННО ОБРАЗОМ будет закодирована (запрограммированна) разработанная им система. Ситуацию усугубляет тот факт, что "абстрагироваться" от подробностей реализации нынче стало модно, об этом пишут в модных журналах рекламные статьи от фирм, продающих сумашедшие по стоимости средства проектирования (а какого беса они так стоят?). Очевидное стремительное падение цен на эти самые средства проектирования в недалеком будущем может весьма неожиданным способом повлиять на современные модные течения, которые "вяряться" пока что в довольно-таки узком кругу.\r
\r
Просматривая прошлые "выпуски" я наткнулся как-то на спор tygra и Репликант по подобным вопросам. В принципе, позиция tygra мне вполне понятна. Остутствие четкому следованию RUP восполняется в его случае настоящим нисходящим истинно итерактивным подходом, где уровни проектирования связаны м/у гораздо четче, чем при проектировании в больших командах. Именно поэтому, зачастую небольшие команды или даже отдельные личности выдают продукты, которые под силу разве что немаленьким коллективам при САМОМ ГРАМОТНОМ ТЕХНИЧЕСКОМ РУКОВОДСТВЕ. Качество руководства самим собой самомотивируемого специалиста широкого профиля, имеющего фундаментальную подготовку по дисциплинам проектирования и разработки ПО, не сравнится ни с каким другим руководством. \r
\r
Отчуждению уровней проектирования сильно способствовало ООП и тем более компонентный подход. Отделение интерфейсов от реализации, как бесценный способ борьбы со сложностью, однако, загубил в людях саму возможность представлять более-менее полно всю систему. Под этим (полное понимание) многие ошибочно понимают владение информацией о самых верхних уровнях системы. Даже самый последний программист-стажер ОБЯЗАН обладать такой информацией со всеми подробностями - не бог весь что, в институте и посложнее специальности проходил. Однако, это редко где практикуется, что не может не приводить к плохому качеству кода (не представляю себе бесцельное и при этом качественное кодирование). К тому же, такая постановка вопроса, усиливая субординацию, лишает фирму "коллективного разума" - генератора идей. Да они и не на руку этим манагерам, эти идеи. Выше уже высказался по этому поводу. Более того, мне уже дважды доводилось наблюдать подобную картину в разных фирмах по гораздо более банальной причине - боязнь всякого рода leader-ов конкуренции со стороны некоторых весьма смышленных подчиненных. Наблюдал ситуацию, когда инфомацию любопытствующим ПРОСТО НЕ ДАВАЛИ. (не говоря уже о том, чтобы проводить совместные мозговые штурмы и обмен опытом)\r
\r
Собрав все, очевидно, что в современной мало-мальски крупной конторе, при разработке проекта разными его участниками производится попытка достичь неких целей, зачастую весьма далеких от такого понятия как "по-настоящему качественное ПО". При этом, следуя критериям качества, предложенным в самом начале, мы "честно" отрабатываем свою зарплату и взятые перед заказчиком обязательства. \r
\r
Не знаю, может мои взгляды сформировались под влиянием того, что мне приходилось очень много самому работать на своих продуктах, и я просто с ужасом думаю, каково бы мне пришлось, если бы я был не в состоянии разработать продукт самостоятельно в ситуации когда ничего подходящего на рынке нет. Когда со мной это началось, был 1996-й, была 1С 6.x, был Парус, был R-base. Все они вели склад по принципу учетных карточек (старожилы помнят, что это). Очень грамотные аналитики, но явно плохие программисты, как сговорившись, во всех программных продуктах для учета материалов и товаров использовали точно такой способ, какой использовался при ручном учете склада. В период скачков цен я стал "загибаться" на 1С 6.x уже на второй месяц, и придумал партионный FIFO и LIFO учет (только не смейтесь, :) я около года считал, что это ноу-хау, пока не вышла 7-ка)\r
Разрабатывая программы под себя, невозможно "халтурить", иначе сам же начнешь тратить лишние клики или материться лишние секунды на задержках (а техника тогда была весьма постепенная...) \r
Да и качественный отчетик самому в свои руки взять приятно... (гораздо приятнее, чем пачкатня от 1С)\r
\r
Понятие качество - это непреходящая ценность, которую подменять понятием " степени соответствия требованиям " элементарно цинично. Называйте, товарищи манагеры и аналитики, пожалуйста, вещи своими именами:\r
- Это удобная программа? - это программа, позволяющая работать...\r
- Это эффективная система? - эфективность системы достаточна для выполнения поставленных задач... (а где она, достаточная степень эффективности, а?)\r
- Это качественная программа? - это программа, отвечающая согласованным и утвержденным требованиям...\r
и т.д.\r
не надо путать понятия.

Если это даже только одна из твоих целей - "поймать кого-то за его собственные слова", то печально

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

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

Опять же, мне не вериться, что Репликант не понимает, что именно мне не нравится в такой постановке вопроса.

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

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

Тоже самое с ПО. Берем гипотетическую задачу на разработку ПО.
Поручаем 2-м коллективам.
Для "чистоты" эксперимента - 2 команды обладают абсолютно одинаковым ТЗ, и реализуют абсолютно одинаковую функциональность.
Но один экземпляр программы выполняет все операции в 4 раза быстрее другого, никогда не падает, на порядок меньше грузит сеть, имеет удобные подсказки, "живые" контролы, резайз всех форм, удобные и ясные контекстные меню на всех полях и таблицах, лигичную и целостную систему помощи, сбалансированные и приятные глазу тона GUI. Даже контролы под "пальчиками" ведут себя гораздо приятнее (для примера - стандартный Windows EditBox и его аналог в MS Access, после второго первым просто невозможно пользоваться).
Дело в том, что в ТЗ и выдвигаемых требованиях на разработку ПО практически никогда не оговаривается такие мелочи, как полный список "горячих клавиш", поведенческие особенности дата-контролов, организация меню, удобство ввода информации (см. мой первый пост в топе - там я добавил еще пару способов ввода накладных, что повысило эффективность работы оператора в несколько раз).

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

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

2 Репликант

Само определение "качественный" в реальной работе нам будут давать наши заказчики. А в понятие "качество" обычно не вкладывают понятие "соответствие требованиям". ...

Кто не вкладывает? Ты?

Ну зачем же вторую часть отрезал? Вот он, весь абзац:

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

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

С другой стороны - он ведь и не обязан разбираться. Основной рынок (по-идее) - это небольшие предприятия от 10-15 рабочих операторских мест. Ну кто там будет во всем этом "шарить"? :)

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

2 PL99

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

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

Насчет аналитики - несомненно это тоже ОДНА ИЗ важнейших задач.
Но тут как раз-таки приличную часть всех требуемых отчетов даже заказчик заранее не знает. Очень многие расчеты я добавлял уже позже, по взаимной договоренности, ибо заказчики и сами были не в состоянии предвидеть все, что может понадобиться. Но это никак не влияло на всю систему. Если некоторые отчеты или даже типы документов я добавлял позже, после осознания заказчиком их необходимости, то это совершенно не значит, что до этого момента моя система была некачественной.

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

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

Естественно обусловленные или предполагаемые потребности различаются по своей сути. Наверное, можно сказать так (нет под рукой сейчас точного определения): обусловленные должны соответствовать или обуславливаться классом/типом/видом продукции, а предполагаемые потребности - это возможные потребности, не обязательно соответствующие классу/типу/виду продукции. Что касается производителя продукции (продукция - это может быть либо изделие, либо услуга. Будем для простоты говорить об изделиях), то по идее он должен объяснять, например, в инструкции к своему изделию, что его изделие удовлетворяет как обусловленным потребностям, так и предполагаемым потребностям. Например, электрический чайник (тип = кухонно бытовая техника для дома):
Весь прикол в том, что ПО по своей сути на несколько порядков гибче любого материального продукта (того же чайника).

удовлетворяет группе требований Б (предполагаемые потребности):
- имеет элегантный внешний дизайн,
(т.е приятен среднестатистическому потребителю)
- окрашен в приятные цвета,
(т.е не раздражает среднестатистического потребителя)
- при закипании воды проигрывает русскиенародные мелодии (10 штук),
(т.е порадует домохозяек и детей, любящих "умные" примочки)
- и т.д
Дык, это все слишком просто. В случае с ПО мы имеем более интересные требования:
- ручка чайника холодная даже во время кипения.
- вода из чайника самонепроизвольно не выливается.
- во время использования чайник не заползает на другие чайники.
- после кипячения в чайнике остается столько же воды, сколько было до кипячения, за минусом естественного выпаривания (no leaks).
- чайник способен хранить воду непрерывно в течении 3-х месяцев без опрокидывания.
- чайник способен давать поток воды при использовании достаточный для наполнения чашки в течении 3-х секунд.
и т.д.

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

Смысл или предназначение любого четко определенного технического термина (вместе со всей его семантикой) в условиях меркантильной бытовухи можно извратить до неузноваемости для прекрытия своей/чужой задницы. И что? От этого он не станет субъективнее. Так что можно настаивать, конечно, но толку-то от этого, ведь мы в форуме, а не на овощном рынке.
Это крупный самообман. Мы на овощном рынке. Покупатели давно выбирают наши продукты точно так же как и овощи. И не всегда только лишь заявленный набор витаминов играет решающую роль. Гораздо чаще выбирают по внешнему виду, но в подавляющем большинстве случаев - по вкусу . (если это не зарубить себе на носу - то можно "пролететь")
Возможность несоответствие санитарным (или еще каким) требованиям даже не учитывается - изначально предполагается, что продукт им соответствует, потому что в ином случае даже нет разговора.

Если продукт соответствует санитарным требованиям и содержит заявленный набор витаминов - то по определению качества - он качественный. Может быть. Однако понятие качество обычно применяется в сравнительной степени, т.е. редко говорится - этот продукт абсолютно качественный/некачественный, обычно рассуждают так - этот продукт качественнее. Неплохо бы обратить внимание на этот момент.

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

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

Кстати, Office - ИМХО продукт высоко качества (по многим параметрам), особенно последней доступной версии - XP. Наряду с выполнением несчетного количества требований к процессу подготовки документов он предоставляет массу субъективных удобств (комфорта), вполне объективно повышая производительность труда клерка. Аналогичные по функциональности, но уступающие по комфорту пакеты где? Правильно, в Караганде.

...можно "подогнать" под понятие "качественный" практически любой программный продукт, который ХОТЬ КАК-ТО выполняет заложенный при проектировании список операций (т.е. соответствует требованиям).

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

Кстати, как называется каждое принятое требование к ПО? Правильно! Ограничение. (или забыли программу ВУЗА?)

Мне как разработчику гораздо удобнее, чтобы заказчик сформулировал именно только голую функциональность, и не лез глубже. Здесь он разбирается на несколько порядков хуже меня. И ждать адекватных требований или адекватной проверки просто глупо. Для этого заказчику необходимо нанимать сторонних экспертов, т.е. увеличивать издержки вдвое. Смысл?

.. Такой взгляд на эти вещи ВЕСЬМА НА РУКУ менеджерам IT, потому что позволяет решать споры с заказчиком путем "прикрытия
задницы" бумажками и документами. ....
Это вообще уже проблема морали этих менеджеров, а не проблема качества ПО :о\
Разумеется, весь этот топ скорее о морали, и том что именно существующее трактование понятий способно провоцировать подобные преценденты. Хотелось бы детерминированности взамен полаганий на мораль. Думаю, что принятие ОБЯЗАТЕЛЬНЫХ стандартов на минимум реализуемой функциональности с точки зрения того же GUI сильно облегчило бы жизнь заказчику, избавив от утомительных подробностей. Microsoft неоднократно предлагала миру и принимала подобные стандарты у себя, но весь мир пока как-то не чешется. (Сюда же можно добавить минимальные граничные требования по генерируемогу траффику на единицу полезной информации,
загрузке ЦП на единицу той же самой полезной информации и еще кучу моментов, которые пока на "совести" разработчика).
Не проходишь санитарный контроль - на фиг с овощного рынка!

Их слова не противоречат высказываниям и знаниям официальной мировой ИТ-науки - они повторяют эти высказывания по смыслу один в один.
Ну и где уже 3-й год мировая IT-экономика? А та же Microsoft чуствует себя превосходно, потому как идет "своим" курсом, и ориентируется именно на потребителя.

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

[i].. Учитывая, что любую задачу можно решить (УДОВЛЕТВОРИТЬ) многими способами, такая трактовка якобы допускает применение НЕКАЧЕСТВЕННЫХ решений для достижения КАЧЕСТВЕННОГО результата. ..
Очень расплывчатая фраза. ЧТО именно подразумевается под "НЕКАЧЕСТВЕННЫХ решений" и "КАЧЕСТВЕННОГО результата"?
Некачественное решение - не отвечающее (или отвечающее не в полной мере) современным наработкам в области разработки ПО (уже говорил). "КАЧЕСТВЕННЫЙ результат" - твое определение.

.. Разумеется, что мне как "честному" программисту, уважающему свою профессию, обидно, что за последние 4-5 лет появились такие понятия как "кодер", "программЁр" и т.д., все произноситься с оттенком пренебрежения. ...
Ну, а при чем здесь качество? Борись с теми, кто используется слова "кодер", "программЁр" (с оттенком пренебрежения), убеждая их в том, что они неправы.
Их используют потребители, получая "качественный" продукт. Предлагаешь бороться с потребителем? В этой ситуации как рах гораздо более ответственнен "манагер" от IT.

Вообще это (расчет производительности, надежность и т.д) - задача не для менеджера. По ИТ-науке или если система сложная, то это задача для отдельного специалиста(ов) - performance & fault-tolerance engineer. Если же не очень сложная (можно обойтись простыми моделями выполнения/работы системы и контрсхемами), то это задача, с к-рой грамотный проектировщик (еще лучше аналитик-проектировщик) может справится, осмысленно прочитав пару книжек по ТОВК ПО/SPE.
А что, в ВУЗЕ не проходили? Или менеджеры от IT на бухучете образование получали? Задача менеджера, ко всему прочему "прикинуть хрен к носу" - что во что может обойтись и во что вылиться. До 10-знака после запятой расчитывать и не требуется, да и невозможно это. А вот основные расчеты должны уметь делать, иначе как принимать решения? И что это будут тогда за решения?

Странно, ты выше говорил, что тебе не нравятся слова "кодер" и "программЁр", а сам используешь российскую ИТ-вульгарщину - "манагер"
Каюсь, сегодня был последний раз. :) Я уж напоследок...

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

А что имеется в виду под "качество руководства"? Просто для того, чтобы говорить об одних и тех же вещах. Не знаю пока о каком руководстве идет речь, но руководство (управление) - это задача менеджера/руководителя
Руководство - это просто задача. И руководить приходяится не только менеджерам, гораздо чаще и непосредственней тим-лидерам.
А когда делаешь сложные вещи малым числом людей или в одиночку, то еще приходится нехило руководить собой.

"непреходящая ценность", "цинично" - это субъективно и эмоции. Если это адресовано также и мне, то я такое понятие как "степень соответствия требованиям" вообще не употреблял. Пожалуйста, приведи цитату, в к-рой по-твоему я пытался делать подобную подмену
легко:
Качество ПО (Вендров, Липаев)
совокупность свойств ПО, к-рые характеризуют способность ПО
удовлетворять заданным требованиям.
или от того что я применил "степень соответствия требованиям" поменялся смысл? Что же тогда есть "способность удовлетворять заданным требованиям" как не степень соответствия им? Или мы разговариваем не на русском?

Вот с этого и начнем, что качество можно определять для множества требований, к-рые были определены заказчиком. Все остальное это уже не качество (для существующих требований) даже если введение дополнительной эргономичности, функциональности,
производительности и т.д того же ПО будет одобрено заказчиком. Можно сказать, что это новое качество с учетом новых требований, к-рые были реализованы дополнительно
Новое качество, говоришь? Это термин такой? А если это не термин, то что со старым качеством? Это одно и тоже качество одного и того же продукта! Я могу сколь угодно глубоко уважать чего-либо достигших людей, но так же имею право на свою точку зрения, тем более, что своим опытом
успел захватить и их время и время нынешнего ПО (взять тот же MS Office или ErWin - продукты изначально нацеленные на создания субъективного комфорта при выполнении вполне объективных задач - подготовка документов или проектирование схем БД)

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

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

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

Прошу прощения, но какой конкретно из законов физики это запрещает? :)

Вообще-то я над требованиями к ПО стебался. :) Чайник - метафора.
Разумеется, что все эти требования к чайнику никто не предъявляет, так же как и к разработчику ПО. Только если производитель чайника и так ПО-УМОЛЧАНИЮ учел эти требования, то производитель ПО - далеко не всегда.

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

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

2 Репликант.
И не надо рассматривать мои топы как черезчур эмоциональные. :)
Читай их про себя спокойно-равнодушным тоном, примерно так они пишуться. :)

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

Хм...
Не знал, что в России все так запущено на овощных рынках. :)

У нас в Севастополе, страх на рыночников наводят не лица кавказской национальности, а налоговая, комитет по защите прав потребителей и сан-контроль. Все весьма строго. А любое лицо любой национальности, если попробует "хамить", просто будет немедленно "удалено".

Так же как и рассуждения о контроле нитратов на рынке - это слишком радужные представления.
Для наших городских рынков - это нормальное явление. Зело удивительно, что у вас там не так.