Рекомендации IEEE по разработке требований к программному обеспечению.

[Dimka]

Более аргументирующий. А?

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

Если совсем кратко, то позиции сторон выглядят так:
Dale: стандарт правильный, кто им не пользуется - неправильные разработчики, несерьёзные;
Dimka: разработчики правильные, и пользуются стандартом лишь те, чьим задачам он адекватен, не пользуются те, чьим задачам он неадекватен.

Это антагонизм мировоззрений.

Все остальные лирические отступления про Дейкстру, науку и т.д. - это лишь упаковка.

[Sla]

Можно я только самйл оставлю, по выбору для каждого ||

[Вад]

Если совсем кратко, то позиции сторон выглядят так:
Dale: стандарт правильный, кто им не пользуется - неправильные разработчики, несерьёзные;
Dimka: разработчики правильные, и пользуются стандартом лишь те, чьим задачам он адекватен, не пользуются те, чьим задачам он неадекватен.

Что ещё хуже, стандартами любят пользоваться люди, от разработки далёкие. В результате, услышав про стандарт, бюрократы применяют его там, где он неадекватен. И это самая распространённая и самая дурная, на мой вкус, практика в индустрии разработки ПО: пользоваться инструментами, пригодность которых необоснованна. Чтобы далеко не лезть за примером, про Waterfall все, наверное, слышали. А кто-то, наверное, и ролик Дорофеева на ютубе видел

Впрочем, программирование здесь не исключение, - такое сплошь и рядом встречается в окружающем мире.

[Dale]

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

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

[Михалыч]

Странно, что по ходу дискуссии стороны плавно переходят ко все более и более непримиримым позициям и более резким выражениям. Впрочем, видимо это "запал" такой...

категории "социальных", которым закон стандарт не писан

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

[RXL]

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

[Dale]

Так что зря спорите. Действительно: нужен стандарт - используем, нет - дело хозяйское.

Михалыч, я именно эту мысль и пытался пробить с самого начала:

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

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

Почему-то не сработало. Видимо, сложно так много писАть и читать одновременно.

Но видеть при этом какое-то "уничижение" тех, кто стандарт не приемлет - странно...

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

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

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

Бред, скажете? Охотно соглашусь - бред. И вместе с тем реальность, увы.

[RXL]

Dale, будет уже... Ведь действительно трудно читать эти посты-простыни и при этом поддерживать в уме все нити рассуждений. Главное, вовремя остановиться.

[Вад]

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

А какая может быть альтернатива следованию стандарту? Только не-следование стандарту. Но это объявляется несерьёзным подходом, поэтому Димка и завёлся

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

Вообще, имхо, любой отраслевой стандарт служит двум целям (которые, может быть, являются ипостасями одного и того же):
- позволяет унифицировать процессы (по сути, сводя их к "стандартным", что облегчает взаимодействие между организациями, обучение и подбор кадров, и проч.)
- и упрощает экспертизу заказчиком (это относится что к CMMI level X, что к сертификациям сотрудников по всяким MCSD или, если про Agile, сертификаты SCRUM-мастеров, и т.п.). То есть, заказчик, пребывая в неопределённости, предпочтёт того, кто блюдёт какой-нибудь RUP, ISO-xxxx, и проч, просто потому что это снижает ряд его рисков, возлагая часть ответственности за экспертизу на сторонние уважаемые организации.

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

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

[Dale]

Я вот не использую подобные стандарты.
...
Можно поставить на мне клеймо "неправильного программиста"?
Я не отрицаю полезность подобных стандартов.

Зачем? По-моему, позиция вполне адекватного человека: прочитал, ознакомился, принял к сведению. Если не кинулся применять со всех ног - ничего страшного. Главное, что в голове отложилось: если задача разрастется настолько, что сложно будет помнить все требования, то есть способ упорядочить их письменно. Все, ничего другого в данном Стандарте нет. Кто прочитал, те в курсе.

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

[Dale]

А какая может быть альтернатива следованию стандарту? Только не-следование стандарту. Но это объявляется несерьёзным подходом, поэтому Димка и завёлся

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

[Вад]

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

Что значит, не нравится? Не подходит, и всё тут.

Потому что потребует многократно превосходящих трудозатрат, при том, что заказчик на это пойтить не может (неважно, по какой причине). Но ещё и потому, что в "моём" процессе это не принесёт качества, зато крайне отсрочит дату получения результата. И, наконец, потому что заказчику (о, ужас) нужен результат в ущерб качеству (по части поддержки, сопровождения, безотказности, и т.п.).

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

[Dimka]

Михалыч, ты затрагиваешь сложную тему.

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

С другой стороны, (как тот же Дейкстра отмечал) корректность ПО вовсе не означает:
- в технических аспектах - надёжность, живучесть и т.п. характеристики всей технической системы, в которую это ПО встроено;
- в гуманитарных аспектах - общественную удовлетворённость от использования технической системы.

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

При решении социальных задач это требует уменя прогнозировать в общем-то совсем уж эфемерные вещи: настроения, моду, увлечения и т.п. Во-первых, на данный момент не существует надёжных средств такого прогнозирования - это, как говорится, медицинский факт. Во-вторых, сама концепция, сама идея такого прогнозирования - это научная традиция XIX века, это убеждение в том, что мир предсказуем и упорядочен, а если мы чего-то не можем предсказать - это недоработка учёных. Во второй половине XX века это убеждение сменилось новым: в мире есть вещи и явления, которые принципиально непредсказуемы. Жить с этим можно лишь одним способом - отказаться от бессмысленных попыток контроля неконтролируемого, и сосредоточиться на развитии адаптационных возможностей.

В технических системах последнее означает систематическую работу по расширению допусков, диапазонов, объёма параметрического пространства систем, в котором функционирование системы считается функционированием в штатном режиме.

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

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

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

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

Если некая организация требует применения стандарта своими подрядчиками в 100% случаев и вне зависимости от профиля - ну дай бог, чтобы 100% её проектов действительно имели указанные в стандарте управленческие цели. Гораздо более вероятно, что эта организация поражена бюрократической заразой, её процесс разработки окостенел, не адаптируется от проекта к проекту, он максимально упорядочен только из одной любви руководства к порядку. Назвать такую организацию "серьёзной" я могу лишь с большой улыбкой.


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


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

[Dale]

...И, наконец, потому что заказчику (о, ужас) нужен результат в ущерб качеству (по части поддержки, сопровождения, безотказности, и т.п.).

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

...вечное переписывание подробных функциональных спецификаций закончилось полным крахом ...  Делали бы по Agile - вполне возможно, исход был бы другим.

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

[Вад]

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

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

[Sla]

Есть понятие стандартов, а есть понятие рекомендаций.

Это рекомендации (так по крайней мере написано в Заголовке)

Тоже самое творится и в вэбе.
Большая часть верстальщиков не придерживается рекомендаций, она их даже, возможно, не читала. А оставшиеся - стремятся донести в массы о необходимости стандартизации.

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

Приложение выполнило недопустимую операцию и будет закрыто...

А че? Вполне адекватное поведение приложения на неадекватные данные.

А так было бы хорошо. Написал парсер html - браузер готов - руби бабло

[Dale]

Есть понятие стандартов, а есть понятие рекомендаций.

Это рекомендации (так по крайней мере написано в Заголовке)

Они тут два в одном соединили - рекомендация, имеющая статус стандарта организации, причем организации добровольной (IEEE STD). Это и правильно, наверное. Если в твоей конструкции нужен винт именно с левой резьбой и нестандартным шагом, то его нестандартность - это не повод отказаться от реализации идеи в принципе. А вот если ты используешь такие винты в качестве простого крепежа, то это уже по меньшей мере странно.

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

[Dimka]

http://lenta.ru/articles/2011/05/31/wasted/

Не помогают стандарты "серьёзным организациям"...

[Dale]

Все закономерно:

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

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

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

[Dimka]

Т.е. порядок, дисциплина и репутация - залог успеха проекта? Что ж всё рай не наступает-то...

[Dale]

Скорее, пожалуй, отсутствие вышеперечисленного - практически полная гарантия, что бюджет будет проёпотрачен впустую, если не считать удовольствие от самого процесса, а проект закончится ничем. 32 миллиарда и 15 лет - дороговатая цена за это довольно очевидное знание. Я бы им этот секрет выдал и за половину суммы, причем сразу.

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