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

[Dale]

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

[RXL]

Вопрос: а есть конкретный пример применения? Название софта или фирмы, которая по данным рекомендациям работает? Просто интересно.

[Dale]

Я полагаю, сегодня гораздо труднее найти более-менее приличную фирму, которая по данным рекомендациям НЕ работает.

В частности, насколько мне известно, в США департамент FDA, который помимо прочих задач контролирует разработку медицинского оборудования, принципиально не заключает контрактов с фирмами, которые не владеют процессами и инструментами управления требованиями. Не менее строгими являются требования NASA, DARPA и подобных серьезных заказчиков. Конечно, сегодня можно зарабатывать большие деньги на всяких гуглах/одноклассниках/вконтактах/жывыхжурналах и прочих модных и IMHO не слишком полезных игрушках, но, к счастью, не все исчерпывается попсой, в том числе в информатике.

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

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

[Dimka]

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

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

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

Такая вот попса...

[Dale]

Добавь требование высокой изменчивости всех требований, и всё поплывёт.

Далеко не уплывет.  Для работы с изменчивыми требованиями в Стандарте имеется пункт 4.3.8 (не только для этого, конечно, но в том числе).

С этой точки зрения "ВКонтакте" как техническая система гораздо интереснее межпланетного зонда NASA - с одной стороны, гораздо проще, с другой стороны, гораздо непредсказуемее.

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

[Dimka]

Для работы с изменчивыми требованиями в Стандарте имеется пункт 4.3.8 (не только для этого, конечно, но в том числе).

Ты не понял. Изменение требований - это информационный поток. Пункт 4.3.8 предлагает справляться с ним усилением бюрократии. Конечным результатом будет полная неповоротливость проекта и неадекватная скорость адаптации к изменениям. Кто будет читать бесконечные логи изменений? Чем-то это похоже на отечественное законодательство во всей его красе. При этом в результате изменений конечная ценность каждого требования будет становится всё менее определённой. Исправить положение может только полная ревизия и "реструктуризация" всего массива требований, свежий взгляд на всю картину целиком. Такая ревизия по сложности и объёму работ может быть сопоставимой со стратегией "всё выкинуть и начать с нуля".

Именно как реакция на такое положение дел рождаются всякие "экстремальные программирования" и т.п. методики. Когда ценность результата становится меньше стоимости неповоротливого процесса.

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

[Dale]

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

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

Конечным результатом будет полная неповоротливость проекта и неадекватная скорость адаптации к изменениям.

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

Кто будет читать бесконечные логи изменений?

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

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

Эти все ужасы неизбежно вытекают из необходимости трассировки требований? Или этот абзац попал сюда по ошибке?

Именно как реакция на такое положение дел рождаются всякие "экстремальные программирования" и т.п. методики. Когда ценность результата становится меньше стоимости неповоротливого процесса.

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

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

После прочтения семейства стандартов IEEE, относящихся к процессу производства ПО, у меня возникло мнение, что сия организация не стремится регулировать вечно длящиеся, незаканчивающиеся, постоянно меняющиеся проекты. Лично меня подобное ограничение вполне устраивает, ибо "ВКонтакте" - один из многочисленных ресурсов, в отношении которых справедлива поговорка: "семь лет мак не родил, а голода не было". И их успехи, и их провалы - лишь забавный курьез, не более.

[Dimka]

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

После прочтения семейства стандартов IEEE, относящихся к процессу производства ПО, у меня возникло мнение, что сия организация не стремится регулировать вечно длящиеся, незаканчивающиеся, постоянно меняющиеся проекты. Лично меня подобное ограничение вполне устраивает, ибо "ВКонтакте" - один из многочисленных ресурсов, в отношении которых справедлива поговорка: "семь лет мак не родил, а голода не было". И их успехи, и их провалы - лишь забавный курьез, не более.

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

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

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

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

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

[Dale]

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

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

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

Это хорошо.

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

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

Назначение хорошего стандарта - не связывать разработчику руки, а помогать ему. Для разработчиков firmware, интересы которых я на нашем форуме некоторым образом лоббирую, ценность данного Стандарта неоспорима - он позволяет зафиксировать требования в удобной форме, причем достаточно качественные требования, с которыми удобно работать. Если вышеупомянутого Пупкина поутру вдруг осенит, что вместо большой красной кнопки лучше бы иметь пять маленьких зеленых, ему придется смириться с тем, что поезд ушел - на складе уже стоит контейнер с заказанными на всю партию приборов большими красными кнопками, в готовых корпусах не предусмотрены крепления для маленьких зеленых, да и на печатной плате для них нет контактов.

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

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

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

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

[Dimka]

Для разработчиков firmware, интересы которых я на нашем форуме некоторым образом лоббирую, ценность данного Стандарта неоспорима

Тогда вместо "программа" (вообще) лучше говорить firmware - конкретизировать класс программ. Сразу отпадут лишние вопросы.

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

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

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

никто не мешает разработать более подходящие для данной области стандарты. Если, конечно, хаос подлежит стандартизации.

Не подлежит - и это хорошо.

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

Потому что IEEE справедливо не стремится вогнать в один стандарт всю вселенную. У стандарта есть чёткая область применения. И это не "ПО вообще". Активно ссылающаяся на стандарт литература охватывает все области разработки ПО, или же это тематическая литература?

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

Я тоже не припомню такого у Дейкстры (который не другой, не однофамилец). О чём речь?

[Dale]

Тогда вместо "программа" (вообще) лучше говорить firmware - конкретизировать класс программ. Сразу отпадут лишние вопросы.

Кому лучше говорить, у кого отпадут? В реферате к Стандарту недвусмысленно сказано:

Описаны содержание и характеристики качественной спецификации требований к программному обеспечению (software requirements specification, SRS), приведены несколько примеров плана SRS. Эти рекомендации ориентированы на составление спецификаций требований к разрабатываемому программному обеспечению, но также могут помочь при выборе коммерческих и разработанных самостоятельно программных продуктов. Также приведены указания по согласованию со стандартом IEEE/EIA 12207.1-1997.

Никаких лишних вопросов при внимательном чтении возникать не должно.

Тот факт, что лично я считаю Стандарт подходящим для разработки firmware, не является достаточным основанием к корректировке Стандарта.

Потому что IEEE справедливо не стремится вогнать в один стандарт всю вселенную. У стандарта есть чёткая область применения. И это не "ПО вообще".

Смотрим во Введении:

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

Вполне четко и недвусмысленно сказано: те, кто не нуждается в непротиворечивой и полной спецификации требований, могут не утруждать себя дальнейшим чтением документа. Соответственно, и область его применения не "ПО вообще", а ПО, разрабатываемое на основе IEEE/EIA 12207.1-1997.

Активно ссылающаяся на стандарт литература охватывает все области разработки ПО, или же это тематическая литература?

Из того, что сейчас под рукой: Леффингуэлл, Уидрит. "Принципы работы с требованиями к программному обеспечению. Унифицированный подход", с реверансами в предисловии от Йордона и явным тяготением к Унифицированному процессу Буча и компании. Собственно, эта книга и подвигла к данной публикации, очень часто ссылается на данный Стандарт. Особой тематической направленности в книге я не заметил, хотя разработка требований для встроенных систем в ней оговаривается отдельно.

Я тоже не припомню такого у Дейкстры (который не другой, не однофамилец). О чём речь?

Там большой пространный абзац, завершающийся словами

Всё это Дейкстра называл самым большим вызовом для науки и индустрии.

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

[Dale]

Вот еще из подручной литературы, которая активно ссылается на Стандарт: SWEBOK (у меня распечатана версия от 2004 года).

[Dimka]

Кому лучше говорить, у кого отпадут?

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

Из того, что сейчас под рукой: Леффингуэлл, Уидрит. "Принципы работы с требованиями к программному обеспечению. Унифицированный подход", с реверансами в предисловии от Йордона и явным тяготением к Унифицированному процессу Буча и компании.

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

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

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

[Dale]

Тебе лучше говорить, если ты презентуешь здесь текст данного стандарта.

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

Я же с тобой разговариваю и объясняю, с чем я не согласен.

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

Да, таких книжек много. Только на практике пользы от них не очень много. Особенно тех, к которым Буч руку приложил...

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

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

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

Тогда можно пруфлинк? Я перечитал бОльшую часть архива Дейкстры (за исключением статей на голландском и описаний древних компьютерных архитектур), но ничего подобного припомнить не смог. Будет любопытно, если упустил что-то существенное.

[Dimka]

С самой идеей необходимости сбора требований?

Нет, не с этим.

Или с необходимостью документировать результат в виде спецификации?

И не с этим.

Или с конкретным вариантом оформления, предложенным в Стандарте?

Да с этим.

Или, наконец, с механизмами трассировки требований?

Нет, не с этим.

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

Они все ценные и дельные. Но, увы, не все практичные.

Тогда можно пруфлинк?

Да у нас они и лежат - статьи эти.

https://club.shelek.ru/viewart.php?id=217

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

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

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

Роль формальной функциональной спецификации – просто служить логическим барьером между двумя совершенно разными проблемами, известными как «проблема удовлетворенности» и «проблема корректности». Проблема удовлетворенности касается вопроса, соответствует ли система, отвечающая таким-то и таким-то формальным спецификациям, вашим ожиданиям и надеждам. Проблема корректности касается вопроса, соответствует ли данная разработка таким-то и таким-то формальным функциональным спецификациям.

  Логический барьер был необходим, чтобы поставить проблему корректности перед информатикой: он изолирует уютную нишу информатики от проблемы удовлетворенности, решению которой наука мало чем способна помочь. Заметьте, пожалуйста, что я не утверждаю, что одна из проблем важнее другой; в конце концов, цепь не прочнее самого слабого звена. Однако я утверждаю, что проблема корректности представляет ту самую часть, которую нам удалось втиснуть в «тонкий пограничный слой» Бонди, где разумное применение научной мысли может принести пользу, тогда как неформализованная проблема удовлетворенности в действительности лежит на пределами компетенции науки.

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

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

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

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

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

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

  Выдающийся пример этого явления недавно продемонстрировала Ada. Если Ada собирается выдать стандарт, желательно, чтобы он был недвусмысленно документирован. По меньшей мере две группы попытались сделать это; в результате обе выдали около 600 страниц формального текста. Это гораздо больше, чем необходимо, чтобы удостовериться в невозможности хотя бы твердо установить, что оба документа определяют один и тот же язык. Ошибка очевидной неуправляемости этих двух документов кроется ни в двух группах, составивших их, ни в принятом ими формализме, а лишь в самом языке: сами не обеспечив формального определения, могут ли его разработчики скрыть, что они предлагают неуправляемого монстра. То, что Ada уменьшит проблемы программирования и увеличит надежность наших разработок до приемлемых границ, – это лишь одна из тех сказок, в которые могут поверить только люди с военным образованием. Самое лучшее, что я могу сказать об этом, – это упорные слухи, что даже военного образования недостаточно, чтобы поддерживать веру в этот Философский Камень. Я упомянул про Ada, поскольку это замечательный пример того, на что я указывал в начале доклада: ее принятие – это политический процесс, в котором информатике, предостережения которой рассматривались как досадная помеха, не было дозволено оказывать никакого влияния. Следовательно, даже простое согласие с чьим-то обоснованным сомнением на этот счет, даже без вмешательства в контроль и намерения, становится действием с политическим душком.

К вопросу о стандартах.

https://club.shelek.ru/viewart.php?id=194

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

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

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

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

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

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

Я описал эту сцену столь подробно, поскольку хорошо помню ее и потому что считаю ее достаточно типичной. Постепенно вы достигаете весьма формального и хорошо определенного результата, но этому постепенному зарождению предшествует период созревания, в течение которого новые идеи опробуются и либо отбрасываются, либо развиваются. Это единственный известный мне способ, которым разум может справиться с подобными концептуальными проблемами. Из опыта я уяснил, что в этот период созревания, когда должен быть создан новый жаргон, блестящее владение родным языком является абсолютным требованием для всех участников. Программист, изъясняющийся неряшливым языком, - это просто бедствие. Блестящее владение родным языком  это мой первый критерий отбора будущих программистов; хороший математический вкус  второй важный критерий. (К счастью, они часто сопутствуют друг другу).

У меня есть и третья причина столь подробно описывать рождение понятия святости. Через несколько лет я узнал, что это не просто романтика, не просто приятные воспоминания о проекте, который всем нам нравился: наш эксперимент попал в самую точку. Я понял это, когда пожелал в качестве упражнения для себя самого дать полную формальную разработку рекурсивного парсера для простого языка программирования, заданного в терминах пяти или шести синтаксических категорий. Единственным способом, которым я смог достичь корректного формального подхода, было введение новых синтаксических категорий! Эти новые синтаксические категории описывали последовательности символов, которые были бессмысленными с точки зрения разбираемого языка, но необходимыми для понимания и проверки алгоритма разбора при разработке. Мое формальное упражнение многое прояснило не потому, что привело к созданию хорошего парсера, а потому, что в краткой, компактной форме продемонстрировало необходимость изобретений, которые требуются при разработке программного обеспечения: новые синтаксические категории были образцом понятий, которые постоянно приходится изобретать, понятий, которые не имеют смысла с точки зрения начальной постановки задачи, но необходимы для понимания решения.

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

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

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

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

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

Когда C.A.R. Hoare писал в начале этого года: порог моей терпимости к сложности намного ниже, чем обычно, он имел в виду развитие по двум направлениям: осознание больших опасностей сложности, а также растущие стандарты элегантности. Осознание опасностей сложности делает большую простоту желаемой целью, но поначалу вопрос о том, достижима ли эта цель, оставался открытым. Некоторые проблемы бросают вызов элегантным решениям, но очевидно, что большая часть из того, что сделано в программировании (и в компьютерной науке в целом) может быть существенно упрощено. (Известны многочисленные истории о 30-строчых решениях, состряпанных так называемыми профессиональными программистами  или даже учителями программирования!  которые могли быть уменьшены до 4-5 строк).

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

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

А это к вопросу о практичности.

https://club.shelek.ru/viewart.php?id=155

в то время часто встречались наивные предположения, что как только более мощные машины станут доступны, программирование перестанет быть проблемой, ибо закончится борьба с тесными рамками оборудования, а ведь именно в этом и заключается суть программирования, не так ли? Но в следующие десятилетия произошло кое-что совершенно иное: стали доступны более мощные машины, не на один, а на несколько порядков величины мощнее прежних. Но вместо того, чтобы оказаться в состоянии бесконечного блаженства от того, что все проблемы программирования решены, мы оказались по самое горло в кризисе программирования! Как же это случилось?
Вот второстепенная причина: в одном-двух аспектах современные компьютеры значительно сложнее содержать, чем старые. Во-первых, мы получили прерывания ввода/вывода, происходящие в непредсказуемые и невоспроизводимые моменты времени; в сравнении со старыми последовательными машинами, которые прикидывались полностью детерминированными автоматами, это разительное изменение, и преждевременная седина многих системных программистов служит свидетельством тому, что нам не стоит легкомысленно отзываться о логических проблемах, порожденных этой возможностью. Во-вторых, мы получили машины, оборудованные многоуровневыми запоминающими устройствами, что ставит перед нами проблемы стратегии управления ею, которые, несмотря на обилие литературы по этому предмету, остаются весьма скользкими. Слишком дорогая плата за возрастание сложности, обусловленное изменениями в структуре современных машин.
Но я назвал это второстепенной причиной; первостепенная же кроется в том, что... машины стали на несколько порядков мощнее! Говоря прямолинейно: пока машин не было вовсе, не существовало проблемы программирования; когда появились немногочисленные слабые компьютеры, программирование стало малозаметной проблемой; а теперь, когда у нас есть гигантские компьютеры, программирование само превратилось в гигантскую проблему. В этом смысле электронная промышленность не решила ни единой проблемы, она только породила их, создав проблему использования своей продукции. Другими словами, по мере того как мощность доступных машин выросла более чем в тысячу раз, стремление общества найти им применение выросло пропорционально, и бедный программист вынужден метаться буквально по минному полю. Возросшая мощь оборудования совместно с, возможно, еще более возросшей надежностью, сделали возможными решения, о которых программист даже не отваживался мечтать несколько лет назад. А теперь, спустя несколько лет, он должен мечтать о них и, более того, он обязан воплощать эти мечты в реальность! Удивительно ли, что мы оказались в кризисе программирования? Конечно же, нет, и как вы можете догадаться, это даже было предсказано заранее; но трагедия пророков, предсказывающих неприятности, состоит в том, что только лет через пять вы действительно осознаете, что они были правы.

[Dale]

Как я и ожидал, цитаты утверждают прямо противоположное.

С одной стороны:

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

С другой:

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

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

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

....существуют проекты, для которых очевидно, что ниша информатики не подходит; если это тот самый случай, информатика не в состоянии ничем им помочь, и лучше ей не вмешиваться.

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

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

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

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

[Dimka]

Dale, и как это противоречит тому, что я сказал?

[Dale]

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

- с формализацией совершенно не вяжется. А у Дейкстры формализация сквозит из каждой фразы. Да у физика-теоретика и не может быть иначе.

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

[Dimka]

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

Совершенно верно, о том я и говорю.

- с формализацией совершенно не вяжется. А у Дейкстры формализация сквозит из каждой фразы.

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

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

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

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

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

[Dale]

...Дейкстра говорит о том же. Всё, что он подчёркивает, так это отсутствие науки там, где нет формализации.

Солидарен.

И это нисколько не умаляет ценность для общества таких вненаучных сфер.

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

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

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

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

За меня уже ответил Дейкстра:

Задача Университета  не предлагать то, что просит общество, а давать то, что обществу необходимо. [Те вещи, что общество просит, в основном хорошо понятны, и для них не нужен Университет; Университет же должен предлагать то, что никто больше предоставить не в состоянии.]

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

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

Это исключительно проблема слабого инструментария, а не слабого стандарта. У того же Леффингуэлла масса примеров, как громоздко такие задачи решаются вручную и как легко при помощи современных инструментальных средств.

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

Не следует путать непрактичность Стандарта с непрактичностью методик его использования.

[Dimka]

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

Не согласен. Это твоя личная оценка, а говоришь от имени общества. На самом деле ты говоришь о таком обществе, в котором лично тебе более комфортно жить. Конечно, твоё дело - воздействовать на общество в желаемом для тебя направлении. В том числе и речами. А моё дело - не соглашаться с такой категоричностью.

Не следует путать непрактичность Стандарта с непрактичностью методик его использования.

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

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

[Dale]

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

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

Для ЯВУ это была теория компиляции.

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

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

Банковская платежка формализована (определен формат до миллиметра, недопустимы вольности при заполнении); возможно, даже стандартизована, не знаю этих тонкостей. По-вашему, это наука?

На теорию относительности вряд ли есть стандарт. Следовательно, она ненаучна?

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

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

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

[Dimka]

Для связи между уровнями с головой достаточно банальной двусторонней трассируемости.

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

Просто технология. Кабы речь шла о теории формальных языков, я бы согласился.

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

Банковская платежка формализована (определен формат до миллиметра, недопустимы вольности при заполнении); возможно, даже стандартизована, не знаю этих тонкостей. По-вашему, это наука?

На теорию относительности вряд ли есть стандарт. Следовательно, она ненаучна?

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

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

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

Да, вот так просто. И не более того. И это не даёт никакого повода осуждать социальные сети и практики разработки обслуживающего их ПО фразами вида:

Я полагаю, сегодня гораздо труднее найти более-менее приличную фирму, которая по данным рекомендациям НЕ работает.

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

[Dale]

И опять по кругу. "С головой" означает "без средства автоматизации".

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

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

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

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

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

Т.е. ты согласен с моим утверждением, что обсуждаемый стандарт не имеет научного фундамента.

Согласен. Даже более того. Не берусь утверждать, но сильно подозреваю, что 99% стандартов не имеют научного фундамента (допускаю, что 100%). Это просто документы, оговаривающие, какой должна быть некоторая сущность. Вроде правил движения, которые обязуются соблюдать все участники, но которые не доказываются при помощи теорем.

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

Так ведь не я приплел Дейкстру к данной теме. Наоборот, упоминание его в данном контексте вызвало у меня недоумение. Это уже какой-то сбой самоидентификации: сам сказал, сам же гневно возразил... В истории сообщений ведь все видно.

Да, вот так просто. И не более того. И это не даёт никакого повода осуждать социальные сети и практики разработки обслуживающего их ПО фразами вида:

Я полагаю, сегодня гораздо труднее найти более-менее приличную фирму, которая по данным рекомендациям НЕ работает.

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

Собственно, любая крупная софтверная корпорация НЕ работает по этим правилам.

Хорошо, на том и порешим. Никакая корпорация не работает по этим правилам. Надеюсь, эта экстренная мера спасет тему от превращения в какое-то вязкое бесконечное болото.

Кстати, только честно: это все на полном серьезе или просто упражнение в троллинге? Если второе - снимаю шляпу, технично.

[Михалыч]

Три дня слежу за дискуссией с нарастающим интересом. Чес-слово. Давно такого не читал.
И ведь оба правы, если рассматривать по отдельности "социальную" и "несоциальную" стороны... Разному по назначению ПО - разные метОды. Что ж тут такого? Все разумно. Оба правы...
Дык... ведь давно уже было деление на "физиков" и "лириков" Не совсем то, конечно, но близко по духу
Жаль, дисскуссия дошла до вежливого перехода "на личности". Что говорит о том, что ее пора прекратить. Хотя бы на время. Пока не "поссорились И.И. с И.Н."
Но, мне правда, по моей специализации гораздо ближе "несоциальная" позиция Dale. И тоже непонятны сентенции по поводу "осуждать социальные сети и практики разработки обслуживающего их ПО фразами вида..."
Я тоже там осуждения не рассмотрел.

[Dimka]

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

Взаимно.

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

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

Не берусь утверждать, но сильно подозреваю, что 99% стандартов не имеют научного фундамента (допускаю, что 100%). Это просто документы, оговаривающие, какой должна быть некоторая сущность.

Именно. Это документы конвенционального характера; в них не идёт речь об истине, о подлинном знании и т.п. вещах - это лишь договорённость. И поэтому присоединение к конвенции не является основанием испытывать чувство превосходства перед неприсоединившимися.

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

Именно ты и приплёл. Потому что

Наоборот, он всегда настаивал на математически строгих формализмах. То, наверное, был другой Дейкстра, однофамилец.

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

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

это все на полном серьезе или просто упражнение в троллинге?

Это на полном серьёзе. Потому что "театр" раздражает жутко хотя бы тем, что дискредитирует стандарт в глазах, к примеру, веб-разработчиков, которых походя, с лёгкой руки всех под одну гребёнку свели к быдлу и детской неожиданности - они ведь не NASA, DARPA и прочие "серьёзные".

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

[Dale]

И ведь оба правы, если рассматривать по отдельности "социальную" и "несоциальную" стороны... Разному по назначению ПО - разные метОды. Что ж тут такого? Все разумно. Оба правы...

Ох, Михалыч, нарываетесь, рисковый человек... Было недвусмысленно сказано:

Собственно, любая крупная софтверная корпорация НЕ работает по этим правилам.

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

Жаль, дисскуссия дошла до вежливого перехода "на личности"... И тоже непонятны сентенции по поводу "осуждать социальные сети и практики разработки обслуживающего их ПО фразами вида..."
Я тоже там осуждения не рассмотрел.

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

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

Но при таком подходе никак не получится многодневного феерического шоу.

[Sla]

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

[Sla]

выживает один - сильнейший говорливейший.

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

[Dale]

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

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

Ладно, не будем о грустном. Еще каким-то чудом до традиционного "Декарта Картезия" дело не дошло, тогда вообще хоть святых выноси и тему закрывай.

Но у Dale усть стандарты=рекомендации,  у Dimka горький опыт сопровождения-разработки больших проектов.

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