Часто Забываемые Основные Факты, Связанные с Разработкой Программного Обеспечения

Перевод. Автор: Роберт Л. Гласс.

Источник: IEEE Computer Society Frequently Forgotten Fundamental Facts about Software Engineering.

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

Вы конечно в праве не согласиться со всеми фактами; некоторые из них могут даже огорчить вас. Прекрасно! В таком случае мы можем начать диалог о тех фактах, которые действительно являются фактами или которые просто представляют собой фикцию моего яркого патриотического и в то же время противоречивого воображения! Итак, достаточно прелюдий. Здесь представлены наиболее часто забываемые фундаментальные факты, связанные с разработкой программного обеспечения. Некоторые из них просто жизненно необходимы — и забывать о них чревато последствиями.

Сложность

C1. Каждые прибавленные 10 процентов к степени сложности проблемы — это 100 прибавленных процентов к степени сложности решения, сформированного программным обеспечением. Не надо, конечно, пытаться изменить условие (хотя сокращение степени сложности всегда приветствуется); дело в самом методе. (В поисках объяснения, почему это так, см. RD2 в разделе «Требования и проектирование.»)

Человек

P1. Наиболее важный фактор в процессе атаки сложности — это не инструменты и методики, используемые программистами, а особенности самих программистов.

P2. Хорошие программисты в 30 раз лучше средних программистов, если рассматривать с позиции исследования «индивидуальных различий». Если учесть их зарплату, можно сказать, что программисты — это товар широкого потребления на рынке программного обеспечения.

Инструменты и технологии

T1. Зачастую, улучшения относительно инструментов и технологий составляют от 5 до 30 процентов увеличения продуктивности и качества. Но в то или иное время, многие такие улучшения требуют эффекта, называемого «десятикратный множитель» (коэффициент 10). Реклама — это эпидемия в мире программного обеспечения.

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

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

Качество

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

Q2. Понятие качества не совпадает с понятиями удовлетворенного пользователя, соответствия требованиям, цене или предметам каталога. Тем не менее, все перечисленные понятия имеют своеобразное взаимодействие: удовлетворенный пользователь = качественный продукт + соответствие требованиям + доставка по требованию + соответствующая цена.

Q3. Качество — это не простая надежность, это гораздо шире понятия дефекты программирования.

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

Надежность

RE1. Выявление и устранение ошибки составляет около 40 процентов роста цены. Так, это самая важная стадия в цикле жизненного развития.

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

RE3. По мнению типичного программиста, программное обеспечение должно быть полностью испытано. Но на самом деле, зачастую выполняется всего лишь 55 — 60 процентов логических цепочек. Автоматическая служба поддержки, в виде анализаторов обслуживания, может увеличить приведенную выше цифру на 85 — 90 процентов. Тестирование же на 100 процентов практически не возможно.

RE4. Даже если бы было возможно 100-процентное проведение тестирования (см. RE3), данного критерия все равно было бы недостаточно для полного испытания. Около 35 процентов дефектов программного обеспечения возникают из-за пропуска логических цепочек, остальные 40 процентов появляются в процессе выполнения уникальной комбинации логических цепочек. Логические цепочки не могут быть охвачены на 100 процентов (100-процентный охват потенциально способен определять всего лишь около 25 процентов ошибок!).

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

RE6. (вывод к RE5) Программное обеспечение всегда будет содержать остаточные дефекты, даже после самого тщательного устранения ошибок. Целью является минимизировать число, а особенно, степень серьезности дефектов.

Эффективность

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

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

EF3. Существуют компромиссы между оптимизацией размера и времени. Очень часто одно улучшение снижает эффективность другого.

Техническое обслуживание

M1. Качество и техническое обслуживание прямо зависят друг от друга (см. Q3 и Q4).

M2. 40 — 80 процентов (в среднем 60 процентов) затрат на программное обеспечение составляют расходы на техническое обслуживание. Тем не менее, это, наверное, самая важная стадия жизненного цикла.

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

M4. Два предыдущих факта составляют основу того, что называется правилом «60/60» программного обеспечения.

M5. Многие задачи разработки программного обеспечения совпадают с задачами технического обслуживания программного обеспечения — за исключением дополнительной задачи программного обеспечения, которая заключается в «осмыслении существующего продукта.» Данная задача представляет собой доминирующую деятельность по техническому обслуживанию, которая охватывает около 30 процентов времени, отведенного на техническое обслуживание. Итак, можно утверждать, что техническое обслуживание более сложный этап, чем разработка.

Требования и проектирование

RD1. Одной из двух общих причин отклонения в проектах являются нестабильные требования. (В
поисках подробной информации, см. ES1.)

RD2. На стадии продвижения проекта от требований к проектированию, сложность процесса решения вызывает бурный прирост «вторичных требований.» Перечень требований на стадии проектирования в 50 раз длиннее перечня оригинальных требований.

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

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

Анализ и контроль

RI1. Тщательный анализ, в общем, устраняет до 90 процентов ошибок продукта программного обеспечения еще до первого тестирования. (Многие научные данные это доказывают; конечно, чрезвычайно тяжело установить, когда же будет достигнуто 100-процентное устранение ошибок продукта программного обеспечения!)

RI2. Проведение тщательного анализа наиболее эффективно, так же в отношении цены, чем другие методики устранения ошибок, в том числе и тестирование. Но, тем не менее, они не могут и не должны заменять тестирование (см. RE5).

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

RI4. Проведение контроля после поставки признано важным, как для определения степени удовлетворенности заказчика, так и для улучшения процесса, но не все организации выполняют это. К этому моменту такого рода контроль уже должен быть выполнен (от 3 до 12 месяцев после поставки), потенциальные участники контроля в основном уже разбросаны по другим проектам.

Повторное использование

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

REU2. Повторное использование в значительных масштабах (элементы) остается еще в значительной степени нерешенной проблемой, несмотря на то, что ее считают важной и необходимой.

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

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

REU5. Модельное повторное использование является единственным решением проблем, связанных с повторным использованием кода.

Оценка

ES1. Одной из двух общих причин отклонения в проектах является оптимистическая оценка. (В поисках подробной информации, см. RD1.)

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

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

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

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

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

ES7. Общее давление добиться поставленных оценок заставляет программистов пропускать качественные программные процессы. Глупый результат является следствием глупых оснований.

Исследование

RES1. Многие программные исследование скорее поддерживаются, чем действительное исследуются. В результате, (a) некоторые защищаемые концепции на самом деле значат меньше, чем в это верят их приверженцы, и (b) из-за недостатка проведения оценочных исследований, не удается определить фактическое значение новых инструментов и технологий.

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

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

Роберт Л. Гласс — редактор эльзевировского Журнала систем и программного обеспечения, а также издатель и редактор информационного бюллетеня по Практике программного обеспечения. Контактные данные: [email protected]; рад получить информацию от вас.

Перевод выполнен агентством переводов «Апосто». Телефон: +7 (8652) 604-562, 612-666, 551-621 Сайт: www.aposto.ru E-mail: [email protected]

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU