Качество ПО: восемь мифов Джеффри Воас
    Складывается впечатление, что компьютерное сообщество вполне удовлетворено нынешним состоянием дел c качеством ПО: мало не то, что новых идей, да и просто энтузиазма. Нам остается лишь вспоминать о тех далеких временах, когда специализироваться в области управления качеством ПО было весьма престижно, и на визитке зачастую встречались надписи типа: "software safety evangelist".
    Неужели уже можно почивать на лаврах? В конце концов, ни одна из основных проблем создания качественного ПО так и не решена! Сегодня перед нами стоят все те же проблемы, что и десять лет назад. Я хочу обратить внимание коллег на некоторые общепринятые решения, чтобы не сказать панацеи (silver bullets, как после знаменитой книги Брукса стало принято это обозначать в профессиональной литературе), которые, собственно, и создают иллюзию движения вперед. Мне кажется, что на самом деле эти решения носят мифологический характер. Не претендуя на полноту, я выделил восемь таких мифов. Совершенствование процесса и модели зрелости разработки ПО
    Миф, связанный с этой тенденцией современной программной инженерии, состоит в следующем: измерение зрелости процесса разработки в некоторой организации эквивалентно измерению качества ПО, которое эта организация производит. Отсюда неявно следует, что построение более зрелого процесса разработки обеспечивает создание более зрелого ( более качественного) ПО.
    Само по себе усовершенствование процесса разработки, так же как и ранжирование коллективов по уровню профессионализма (особенно по стандартизованной методике типа CMM) безусловно похвально. Однако практика доказывает, что предположение об однозначной связи между официально засвидетельствованными рейтингами зрелости процессов и качеством производимого ПО ошибочно. К сожалению, в компьютерной индустрии этот миф получил чрезвычайно широкое распространение. Формальные методы
    Этот миф можно считать в некоторой степени частным случаем предыдущего. Он гласит, что именно формальные методы способны стать движущей силой "усовершенствования процессов", в частности, облегчить решение проблем безопасности и надежности ПО. На деле формальные методы - это не более чем математически строгая демонстрация наличия у разрабатываемого ПО некоторых желаемых свойств абстрактной природы. Формальные методы позволяют делать заключения об отсутствии логически некорректного, плохо определенного и рассогласованного поведения, которое в принципе может присутствовать в спецификации.
    Конечно, внедрение формальных методов имеет смысл, однако необходимо четко понимать, что возможности их применения весьма ограничены. Не говоря уже о том, что использовать формальные методы сложнее, и обходится это недешево. Языки и объектно- ориентированное проектирование
    Этот миф устанавливает, что, изменив языковую или проектную парадигму, можно решить те проблемы разработки, с которыми мы не могли справиться, используя существующие языки или стратегии проектирования. Однако замена одного языка программирования другим, более современным, вряд ли поможет решить проблемы, не связанные напрямую с особенностями применяемого языка. А именно с такой задачей обычно и приходится сталкиваться. ............