Наш перевод статьи:
Двадцать пять целей индустрии программного обеспечения на 2015–2019г.г.
С разрешения автора: Каперс Джонс
Каперс Джонс, VP and CTO Namcook Analytics LLC
Версия 5.0 28 февраля 2015 г.
Краткий обзор
Развитие индустрии программного обеспечения имеет сходство с походкой алкоголика, при которой движение одновременно и выравнивается и дает задний ход. Например, гибкая методология разработки – это выравнивание малых проектов, а парное программирование — это движение назад, слишком дорогостоящее для роли двигателя.
Одна из причин отсутствия неуклонного движения вперед – это тягостное отсутствие эффективной системы измерений. Две старейшие и наиболее распространенные метрики, стоимость дефектов и строк программы, не свидетельствуют о прогрессе и фактически искажают реальность. С подсчетом затрат за дефект страдает качество, а за строку программы – бракуются языки программирования высокого уровня.
В этой небольшой статье представлены 25 реальных целей, которые могут быть достигнуты в течение 5 лет, принимая за точку отсчета 2015 год. Некоторые цели выражены в показателях метрики функциональных баллов (Function Points — FPs), которая является единственной широко используемой метрикой, допустимой для освещения экономической результативности и качества без серьезных погрешностей.
Другой пригодной метрикой является «эффективность устранения дефектов» (defect removal efficiency — DRE), которая показывает процентное отношение найденных и устраненных ошибок во время разработки по сравнению с количеством ошибок, о которых сообщают пользователи на протяжении первых 90 дней использования программы. Если разработчики нашли 95 ошибок, а пользователи сообщили о 5 ошибках за три месяца, то DRE равняется 95%. В настоящее время средний показатель DRE в США представлен только на уровне примерно 90%, но технически возможно для каждого проекта по разработке программного обеспечения достичь 95%, а для многих – достичь и 99%.
Web: www.Namcook.com
Blog: Namcookanalytics.com
Email: Capers.Jones3@gmail.com
© Каперс Джонс, 2014 – 2015. Все права защищены.
Двадцать пять задач индустрии программного обеспечения на 2015 – 2019 гг.
Введение
Нижеследующее представляет собой подборку 25 целей или задач для развития программирования, разработанную Namcook Analytics LLC для реализации в течение пяти лет с 2015 по 2019 гг. Некоторые из этих целей достижимы уже в 2015 году, но далеко не всем компаниям удалось достичь их. Незначительное число избранных ведущих компаний достигло некоторых из отмеченных целей.
К сожалению, менее 5% компаний США и транснациональных компаний достигли какой-либо из представленных целей и менее 1% достигли большинства целей. Ни одному из клиентов автора не удалось достичь всех целей.
Автор предлагает, чтобы каждая крупная компания по разработке программного обеспечения и правительственная организация создали свою подборку целей на пятилетний период, используя предложенный список как отправной пункт.
1. Поднять эффективность устранения дефектов (DRE) с < 90.0% до > 99.5%. Эта цель является наиболее важной для индустрии. Она не может быть достигнута только тестированием, но требует применения предтестового контроля и статического анализа. DRE измеряется сравнением всех дефектов, найденных во время разработки, с теми, о которых сообщают потребители на протяжении первых 90 дней. Текущий средний показатель DRE в США равен примерно 90%. Динамика равна приблизительно 92%. Лишь немногие компании-лидеры, используя полный комплект предупреждения дефектов, предтестовое устранение дефектов и формальное рецензирование с математически спроектированными контрольными примерами и привлекая дипломированных специалистов по тестированию, могут достичь 99% DRE.
2. Снизить показатель возможности дефектов программного обеспечения с > 4.0 на функциональный балл до < 2.0 на функциональный балл. Показатель возможности дефектов – это сумма ошибок, найденных в технических требованиях, конфигурации, проектировании, коде, документах пользователя и некачественно исправленных патчах. Ошибки технических требований и проектирования часто численно превосходят ошибки кода. В настоящее время показатель возможностей дефектов может достичь 6.0 на функциональный балл в больших системах с 10.000 функциональных баллов в типоразмерном ряду. Достижение этой цели требует эффективного предупреждения дефектов, к которому относятся, например, совместная разработка прикладных программ (joint application design — JAD), структурирование функции качества (quality function deployment — QFD), официально одобренные компоненты многократного применения и др. Для этого также требуется программа полного контроля качества программного обеспечения. Для достижения этой цели также необходимо улучшить профессиональную подготовку по общим источникам дефектов, обнаруживаемых в технических требованиях, проектировании и исходном тексте. Наиболее эффективный способ снижения возможностей дефектов – переключиться с проектирования по техническим требованиям заказчика и кодирования вручную, которые по своей сути предрасположены к ошибкам. Проектирование с целью создания официально одобренных компонентов многократного применения может способствовать весьма значительному снижению возможностей дефектов программного обеспечения.
3. Снизить затраты на обеспечение качества (cost of quality — COQ) с > 45.0% стоимости разработки до < 15.0% стоимости разработки. Обнаружение и устранение неисправностей на протяжении более 50 лет и до сих пор было наиболее дорогостоящим заданием в программировании. Для достижения этой цели необходимо синергетическое сочетание предотвращения дефектов, предтестового контроля и статического анализа. Вероятным итогом могло бы стать повышение эффективности устранения дефектов с сегодняшнего среднего показателя ниже 90% до 99%. Одновременно возможности дефектов могут быть сокращены с сегодняшнего среднего показателя 4.0 на функциональный балл до менее 2.0 на функциональный балл. Это сочетание будет оказывать сильное синергетическое влияние на расходы по техническому обслуживанию и технической поддержке. Между прочим, снижение затрат на качество также уменьшит технический долг. Однако по итогам 2014 года технический долг не является стандартной метрикой и так значительно отличается в различных местах, что его трудно подсчитать.
4. Снизить среднюю цикломатическую сложность с > 25.0 до < 10.0. Достижение этой цели требует тщательного анализа структур программного обеспечения и, конечно, измерения цикломатической сложности для всех модулей. Так как цикломатические инструменты являются общепринятыми и некоторые из них являются открытыми исходными текстами, каждое приложение должно использовать их без исключения.
5. Увеличить тестовое покрытие относительно рисков, маршрутов и технических требований с < 75.0% до > 98.5%. Достижение этой цели требует использования математических методов проектирования для создания контрольных примеров; таким методом является, например, планирование экспериментов. Также требуется измерение тестового покрытия. Необходимыми являются и средства прогностической диагностики, которые могут прогнозировать количество контрольных примеров, основанных на функциональных баллах, кодовых томах и цикломатической сложности. Авторская сервисная программа по диагностике рисков программного обеспечения (SRM) прогнозирует контрольные примеры для 18 видов тестирования и, следовательно, может также прогнозировать вероятное тестовое покрытие.
6. Устранить подверженные ошибкам модули (error-prone modules — EPM) в больших системах. Неисправности не распределяются беспорядочно. Достижение этой цели требует тщательных измерений дефектов кода во время разработки и после выпуска с помощью инструментальных программных средств, которые могут отслеживать ошибки до конкретных модулей. Некоторые компании, как, например, IBM, делают это уже на протяжении многих лет. Подверженные ошибкам модули (EPM) обычно составляют менее 5% общего количества модулей, но на них приходится более 50% всех ошибок. Предотвращение – это наилучшее решение. Существующие подверженные ошибкам модули в унаследованных приложениях могут нуждаться в хирургическом удалении и замене. Тем не менее, статический анализ должен применяться ко всем распознанным EPM. В одном исследовании главное приложение насчитывало 425 модулей. 57% всех ошибок было найдено во всего лишь 31 модуле, собранном одним отделом. Более 300 модулей были бездефектными. EPM легко предотвратить, но трудно исправить, если они уже были созданы. Обычно хирургическое удаление неизбежно. EPM – наиболее дорогостоящие артефакты в истории программирования. EPM имеют сходство с заболеванием оспой; то есть оно не может быть полностью устранено с помощью «вакцинации» и эффективных контрольных методов. Подверженные ошибкам модули часто достигают показателя 3.0 ошибок на функцию и удаляются в количестве менее 80% до выпуска программного обеспечения. Они также стремятся войти в число топ-50 по показателям цикломатической сложности. Устранение дефектов на более высоком уровне посредством тестирования представляет сложность из-за высоких уровней цикломатической сложности.
7. Устранить дефекты безопасности во всех приложениях программного обеспечения. По мере того как киберпреступность все более распространяется, возникает все большая необходимость в совершенствовании средств обеспечения безопасности. Достижение этой цели требует контроля состояния безопасности, тестирования систем безопасности и автоматизированного инструментария по обнаружению дефектов безопасности. Для работы с главными системами, которые содержат ценные финансовые или конфиденциальные данные, могут также понадобиться этичные хакеры.
8. Снизить вероятность кибератак с > 10.0% до < 0.1%. Достижение этой цели требует синергетического сочетания усовершенствованных межсетевых экранов, непрерывного антивирусного контроля и постоянных обновлений вирусных сигнатур; а также нужно работать над повышением иммунитета самого программного обеспечения посредством изменений основной конфигурации и стратегий прав доступа. Возможно, потребуется пересмотр конфигурации оборудования и программного обеспечения для повышения уровня защищенности того и другого.
9. Сократить инжекции некачественного устранения ошибок с > 7.0% до < 1.0%. Немногие люди знают, что около 7% попыток устранения ошибок программного обеспечения вносят новые ошибки в непосредственно исправленные участки, которые обычно называются «некачественно исправленными участками». Когда цикломатическая сложность достигает 50, показатель инжекции некачественного устранения ошибок может воспарить до 25% и более. Для сокращения инжекций некачественного устранения ошибок необходимо контролировать цикломатическую сложность, использовать статический анализ для всех участков устранения дефектов, тестировать все исправления и проверять все участки значительных исправлений до их сборки.
10. Уменьшить дрейф технических требований с > 1.5% на календарный месяц до < 0.25% на календарный месяц. Дрейф технических требований является эндемической проблемой индустрии программного обеспечения на протяжении уже более 50 лет. До тех пор, пока пригодны прототипы, динамичные встроенные пользователи и совместные разработки прикладных программ (JAD), технически возможно использовать автоматизированные модели технических требований для улучшения полноты технических требований. Лучшим методом было бы использование сопоставления с образцом для опознавания функциональных возможностей приложений, схожих с теми, которые находятся в разработке. Технология предшествования была бы полезной таксономией функциональных возможностей приложения программного обеспечения, что фактически еще не существует в 2015 году, но могло бы быть разработано в течение нескольких месяцев сосредоточенного исследования.
11. Снизить риск провала проекта или отмены на больших проектах в 10.000 функциональных баллов с > 35.0% до < 5.0%. Отмена больших систем из-за низкого качества, низкого уровня контроля изменений и перерасхода средств, что по своей сути поворачивает направление показателя возврата инвестиций (ROI) от позитивного к негативному, является эндемической проблемой индустрии программного обеспечения, без которой вполне можно было бы обойтись. Синергетическое сочетание эффективного предотвращения дефектов, предтестового контроля и статического анализа может приблизить к устранению этой слишком распространенной проблемы. Параметрические инструменты оценивания, которые могут прогнозировать риски, затраты и календарный план с большей точностью, чем подсчеты вручную, также рекомендованы к использованию.
12. Уменьшить вероятности запаздывания календарного плана с > 50.0% до < 5%. В связи с тем, что причинами запаздывания календарного плана являются низкое качество и чрезмерный дрейф технических требований, решение некоторых из указанных выше проблем этого списка также послужит решением проблемы запаздывания календарного плана. Большинство проектов кажутся выполняемыми в срок до тех пор, пока не начинается тестирование, когда громадное количество ошибок не начинает растягивать календарный план тестирования до бесконечности. Предотвращение дефектов в сочетании с предтестовым статическим анализом может сократить или устранить случаи запаздывания календарного плана. Это излечимое состояние и может быть исключено в течение пяти лет.
13. Сократить возможности перерасхода средств с > 40.0% до < 3.0%. Перерасход затрат на программное обеспечение и запаздывание календарного плана имеют схожие основные причины; то есть низкий контроль качества и низкий контроль изменений в сочетании с чрезмерным дрейфом технических требований. Лучшее предотвращение дефектов в сочетании с предтестовым устранением дефектов может способствовать излечению обеих этих эндемических проблем программного обеспечения. Применение точных параметрических инструментов оценивания, а не оптимистических подсчетов вручную, также полезно для сокращения перерасхода средств.
14. Сократить случаи судебных процессов по аутсорсинговым контрактам с > 5.0% до < 1.0%. Автор статьи был свидетелем-экспертом в 12 судебных процессах по нарушению контрактов. Похоже на то, что все эти дела имеют схожие основные причины, к которым относятся низкий контроль качества, низкий контроль изменений и очень низкое отслеживание состояния. Синергетическое сочетание ранней оценки размеров и анализа рисков перед подписанием контракта плюс эффективное предотвращение дефектов и предтестовое устранение дефектов могут сократить случаи судебных процессов по нарушению контрактов в индустрии программного обеспечения.
15. Снизить затраты на техническое обслуживание и ремонт до > 75.0% по сравнению со значениями 2015 года. Начиная примерно с 2000 года, число программистов по техническому обслуживанию в США начало превышать число программистов-разработчиков. IBM обнаружила, что эффективное предотвращение и предтестовое устранение дефектов поспособствовали сокращению количества окончательных дефектов до такого низкого уровня, что затраты на техническое обслуживание были сокращены самое меньшее до 45%, а иногда даже и до 75%. Эффективная разработка программного обеспечения и эффективный контроль качества оказывают большее влияние на затраты на техническое обслуживание, чем на разработку. Технически возможно сократить техническое обслуживание новых приложений более чем до 60% по сравнению с текущими средними величинами. Анализ унаследованных приложений и устранение подверженных ошибкам модулей, а также небольшая реорганизация исходного кода, также могут поспособствовать снижению затрат на техническое обслуживание на каждое унаследованное приложение примерно до 25%. Технический долг также будет уменьшен, но технический долг не является стандартной метрикой и различается так значительно, что его трудно подсчитать. Инструменты статического анализа должны регулярно запускаться по отношению ко всем активным унаследованным приложениям.
16. Увеличить объем официально одобренных материалов многократного применения с < 15.0% до > 75.0%. Проектирование по техническим требованиям заказчика и кодирование вручную по существу подвержено ошибкам и неэффективно, какая бы методика ни использовалась. Наилучшим способом превращения программирования из ремесла в современную профессию могло бы стать конструирование приложений из библиотек официально одобренных материалов многократного применения; то есть посредством использования технических требований, проектов, кодов и тестовых материалов многократного применения. Все предполагаемые для использования материалы многократного применения должны быть пересмотрены, кодовые сегменты – проверены, а серии статического анализа запущены. Так точно, код многократного применения должен сопровождаться тестовыми материалами многократного применения и сопутствующей информацией, каковыми являются цикломатическая сложность и пользовательская информация.
17. Улучшить среднюю результативность разработки с < 8.0 функциональных баллов в месяц до > 16.0 функциональных баллов в месяц. Коэффициенты результативности различаются по признаку размера, сложности, опыта команды, методик и по нескольким другим факторам. Тем не менее, когда все проекты рассматриваются в совокупности, средняя результативность ниже 8.0 функциональных баллов на штатный месяц. Для того чтобы удвоить этот коэффициент, нужно сочетать лучший контроль качества с намного большими объемами официально одобренных материалов многократного применения; вероятно, на 50% и более.
18. Сократить рабочее время на функциональный балл с > 16.5 до < 8.25. Цель номер 17 и эта цель по существу одинаковы, но используют различные метрики. Тем не менее, есть одно важное отличие. Рабочие часы в месяц не будут равняться одному и тому же числу в каждой стране. Например, проект в Нидерландах со 116 рабочими часами в месяц будет равняться тому же рабочему времени, что и проект в Китае со 186 рабочими часами в месяц. Но для китайского проекта потребуется меньшее число календарных месяцев, чем для нидерландского проекта.
19. Улучшить максимальную результативность до > 100 функциональных баллов на штатный месяц в 1000 функциональных баллов. В настоящее время, по состоянию на начало 2015 года, коэффициент результативности на 1000 функциональных баллов находится в диапазоне примерно от 5 до 12 баллов на штатный месяц. По сути, невозможно достичь 100 функциональных баллов на штатный месяц, используя проектирование по техническим условиям заказчика и кодирование вручную. Только конструирование из библиотек стандартных компонентов многократного применения может позволить такому высокому коэффициенту результативности стать реальностью. Тем не менее, было бы возможным увеличить объем материалов многократного применения. Предшествующий продукт нуждается в хорошей таксономии функциональных возможностей программного обеспечения, каталогах материалов многократного применения и процессе сертификации для добавления новых материалов многократного применения. Также необходимо применять метод отзыва, в случае, если материалы многократного применения содержат ошибки или нуждаются в изменениях.
20. Сократить средний календарный план разработки программного обеспечения до > 35% по сравнению со средними показателями 2015 года. Наиболее распространенной жалобой клиентов сферы программного обеспечения и управляющих корпорациями на уровне директора по информатизации (CIO) и финансового директора (CFO) является то, что проекты программного обеспечения занимают много времени. Удивительно то, что сократить это время не представляет труда. Синергетическое сочетание лучшего предотвращения дефектов, предтестового статического анализа и контроля, а также больший объем официально одобренных материалов многократного применения, могут способствовать существенным сокращениям интервалов календарного плана. В современном мире увеличение размера приложений программного обеспечения в функциональных баллах со степенью 0.4 обеспечивает удобное приближение к длительности плана в календарных месяцах. Но действующие технологии способны снизить показатель степени до 0.37. Увеличение 1000 функциональных баллов со степенью 0.4 указывает на график в 15.8 календарных месяцев. Увеличение 1000 функциональных баллов со степенью 0.37 указывает на график во всего лишь 12.9 календарных месяцев. Такой более короткий календарный план становится возможным благодаря использованию эффективного предотвращения дефектов, усиленного предтестовым контролем и статическим анализом. Компоненты программного обеспечения многократного использования могли бы снизить показатель степени до 0.3 или 7.9 календарных месяцев. Запаздывание календарного плана сегодня безудержно растет, но поддается лечению и может быть устранено.
21. Увеличение объемов задания технического обслуживания с < 1500 функциональных баллов до > 5000 функциональных баллов. Метрика «объем задания технического обслуживания» относится к числу функциональных баллов, которое один программист по техническому обслуживанию может поддерживать и сохранять в режиме функционирования на протяжении календарного года. Диапазон представлен от < 300 функциональных баллов для дефектов и сложного программного обеспечения до > 5000 функциональных баллов для современного программного обеспечения, выпущенного под эффективным контролем качества. Текущий средний показатель составляет примерно 1500 функциональных баллов. Это ключевая метрика для прогнозирования кадрового обеспечения технического обслуживания как проектов по техническим условиям заказчика, так и корпоративных портфолио. Достижение этой цели требует эффективного предотвращения дефектов, эффективного предтестового устранения дефектов и эффективного тестирования с использованием современных методик проектирования контрольных примеров на основе математических расчетов. Для достижения этой цели также необходим низкий уровень цикломатической сложности. Статический анализ должен быть запущен во всех приложениях во время разработки, а также и в унаследованных приложениях.
22. Заменить сегодняшние статические и жесткие технические требования, конфигурацию и методы проектирования на комплект анимационных средств проектирования в сочетании с сопоставлением с образцом. Во время своей работы приложения программного обеспечения являются самыми быстрыми объектами, которые были когда-либо созданы человеческим родом. В ходе своего развития приложения программного обеспечения растут и изменяются каждый день. Вряд ли какой-либо метод проектирования является статичным и состоит из такого текста, как баллы текстовых блоков, или таких очень примитивных и ограниченных диаграмм, как блок-схемы или диаграммы на унифицированном языке моделирования (UML). Технология создания нового метода анимационного проектирования графическими средствами в полном цвете и трех измерениях существует уже сегодня, с 2014 года. Остается только разработать набор символов и начать анимировать процесс проектирования.
23. Разработать средство интерактивного обучения для программирования на основе широкомасштабно интерактивных технологий создания игр. Новые концепции в программировании появляются почти каждый день. Новые языки программирования выпускаются еженедельно. Программное обеспечение приговаривает медицину, закон и другие формы инженерии к постоянному обучению. Но обучение вживую является дорогостоящим и неудобным. Появляется необходимость в инструментальном средстве интерактивного обучения с функцией встроенного планирования программы обучения. В настоящее время возможно разработать такое инструментальное средство. С помощью лицензирования игрового движка появляется возможность создания модели университета программирования, в котором аватары смогли бы посещать занятия и контактировать друг с другом.
24. Разработать комплект динамических анимационных инструментов планирования и оценивания проекта, которые будут показывать развитие приложений программного обеспечения. В наше время выходные данные всех инструментов оценивания программного обеспечения подаются в виде статических таблиц, подкрепленных несколькими графиками. Но приложения программного обеспечения развиваются при разработке более чем на 1% в календарный месяц и продолжают развиваться после выпуска более чем на 8% в календарный месяц. Очевидно, что инструменты планирования и оценивания программного обеспечения нуждаются в возможностях динамического моделирования, которое сможет показать рост функциональности со временем. Они также должны показывать прибытие (и обнаружение) ошибок или дефектов, поступающих из технических требований, проектирования, конфигурации, кода и других источников дефектов. Конечной целью, которая технически достижима сегодня, может стать графическая модель, которая показывает рост приложения с первых дней технических требований и до 25-летия его использования.
25. Внедрить лицензирование и профессиональную аттестацию разработчиков программного обеспечения и специалистов. Настоятельно рекомендуется, чтобы каждый читатель этой статьи также прочел книгу Пола Старра «Социальная трансформация американской медицины» (The Social Transformation of American Medicine). Эта книга была награждена Пулитцеровской премией в 1982 г. В книге Старра показано, как Американская медицинская ассоциация сумела усовершенствовать академическое обучение, снизить профессиональную небрежность и достичь более высокого уровня профессионализма, чем другие технические сферы. Медицинские лицензии и профессиональная аттестация специалистов были ключевыми факторами в прогрессе медицины. Медицине понадобилось более 75 лет для достижения существующего профессионального статуса, но с книгой Старра в качестве руководства программирование смогло бы достичь того же самого в течение 10 лет. Это за пределами 5-летнего окна этой статьи, однако процесс должен начаться в 2015 г.
Обратите внимание, что метрика функциональных баллов, использованная в этой статье, относится к функциональным баллам в определении Международной группы пользователей метрик на основе функциональных баллов (IFPUG). Другие определения функциональных баллов, к которым, кроме прочего, относятся COSMIC, FISMA, NESMA, неурегулированные и др., могут также использоваться, но будут иметь другие количественные результаты.
Множества технологий, доступных в 2015 г., уже вполне достаточно для достижения каждой из этих 25 целей, несмотря на то, что немногие компании их достигли. Некоторые технологии, ассоциированные с достижением этих 25 целей, включают среди прочего:
Полезные технологии для реализации целевых установок программирования
Мы на пороге времени, предшествующего превращению программирования из ремесла в современную профессию. Это также время, предшествующее переключению с частичного и неточного анализа результатов программного обеспечения на результаты высокой точности как для прогнозирования перед началом проектов, так и для измерений после их завершения.
Представленные выше 25 целей являются позитивными целевыми установками, к достижению которых нужно стремиться компаниям и правительственным организациям. Однако «инженерия разработки программного обеспечения» также имеет и некоторое количество вредоносных методов, которых следует избегать или исключать из применения. Некоторые их них настолько вредоносны, что не могут рассматриваться как профессиональная небрежность. Ниже указаны шесть опасных методов проектирования программных средств, некоторые из которых непрерывно использовались на протяжении более 50 лет без осознания их вредоносности в полной мере:
Шесть опасных методов проектирования программных средств, которых следует избегать
1. Прекратите попытки измерить экономику качества посредством «расходов на дефект». Эта метрика всегда показывает самую низкую величину для самого полного неисправностей программного обеспечения, таким образом ставя под удар качество. Метрика также преуменьшает истинную экономическую ценность программного обеспечения на несколько сотен процентов. Эта метрика нарушает стандартные экономические допущения и может рассматриваться как профессиональная небрежность при измерении экономики качества. Лучшим средством измерения стоимости качества является подсчет «расходов на устранение дефектов на функциональный балл». Расходы на дефект не берут во внимание фиксированные расходы на написание и прогон контрольных случаев. Это известный принцип производственной экономики, согласно которому, если в процессе имеет место высокая пропорция фиксированных расходов, расходы на единицу поднимаются. Городская байка о том, что потребуется в 100 раз больше затрат на исправление ошибки после выпуска программного обеспечения, чем до него, безосновательна; расходы почти равнозначны, если просчитаны должным образом.
2. Прекратите попытки измерить результативность программного обеспечения с помощью метрики «строк кода» (lines of code — LOC). Эта метрика бракует языки программирования высокого уровня. Это средство измерения также не отражает в подсчетах работу вне кодирования, каковой являются, например, технические требования и проектирование. Эта метрика может рассматриваться как профессиональная небрежность при экономическом анализе, включающем многочисленные языки программирования. Лучшим средством измерения результативности программного обеспечения является подсчет рабочего времени на функциональный балл и функциональных баллов на штатный месяц. Измерения этих обеих величин могут быть использованы на уровнях активности, а также для проектов в целом. Эта метрика может быть использована и для измерения работ вне кода, каковыми являются, например, технические требования и проектирование. Метрика LOC имеет ограниченную функциональность относительно самого кода, но представляет опасность для более крупных экономических исследований целых проектов. Метрика LOC не принимает во внимание затраты на технические требования, проектирование и документацию, которые обычно превосходят затраты на код как таковой.
3. Прекратите измерение «проектирования, кода и блочного тестирования» или (design, code, and unit test — DCUT). Измеряйте целые проекты, включая руководство, технические требования, проектирование, кодирование, сборку, документацию, все формы тестирования и т. п. Измерения DCUT охватывают менее 30% общих затрат на проекты по разработке программного обеспечения. Измерение затрат всего лишь части проекта по разработке программного обеспечения приводит к состоянию профессионального замешательства.
4. Будьте осторожны с «техническим долгом». Это полезная метафора, которая вместе с тем не является полноценной метрикой для понимания экономики качества. Технический долг пренебрегает высокими затратами отмененных проектов, которые включают как побочные убытки клиентов, так и затраты на судебные процессы, а также возможное назначенное возмещение убытков истцам. Технический долг учитывает только 17% истинных затрат на низкое качество. Измерение затрат на качество (COQ) является лучшей метрикой для экономики качества.
5. Избегайте «парного программирования». Парное программирование дорогостоящее и менее эффективное, чем сочетание контроля и статического анализа. Ознакомьтесь с литературой по парному программированию и, в особенности, с докладами программистов, которые специально увольняются с работы, чтобы избежать парного программирования. Литература, одобряющая парное программирование, также иллюстрирует общую слабость исследования по программированию, в котором не сравнивается парное программирование с методами с доказанным качеством результатов, каковыми являются контроль и статический анализ. Сравнению подвергаются только пары и единичные программисты без обсуждения инструментария, методов, контроля и т. п.
6. Прекратите полагаться только на тестирование без использования эффективных методов предотвращения и предтестового устранения дефектов, каковыми являются контроль и статический анализ. Тестирование само по себе без предтестового устранения дефектов является дорогостоящим и редко достигает 85% по уровню эффективности устранения дефектов. Синергетическое сочетание предотвращения и предтестового устранения дефектов, к которым относятся, например, статический анализ и контроль, может повысить DRE до > 99%, в то же самое время сокращая затраты и укорачивая календарные планы.
Инженерия разработки программного обеспечения всегда очень сильно отличалась от более старых и зрелых форм инженерии. Одним из наиболее значимых отличий сферы инженерии разработки программного обеспечения от традиционной инженерии является то, что инженерия разработки программного обеспечения имеет очень скудный опыт измерений и обладает слишком субъективной информацией вместо веских эмпирических данных.
В этой небольшой статье предлагается подборка 25 количественных целей, достижение которых поспособствует значительному продвижению как в качестве программного обеспечения, так и в его результативности. Однако, важнейшее послание заключается в том, что низкое качество программного обеспечения является критическим фактором, который нуждается в улучшении, для того чтобы, в свою очередь, усовершенствовать результативность, календарные планы, затраты и экономику.
References
Abrain, Alain; Software Estimating Models; Wiley-IEEE Computer Society; 2015
Abrain, Alain; Software Metrics and Metrology; Wiley-IEEE Computer Society; 2010
Abrain, Alain; Software Maintenance Management: Evolution and Continuous Improvement; Wiley-IEEE Computer Society, 2008.Beck, Kent; Test-Driven Development; Addison Wesley, Boston, MA; 2002; ISBN 10: 0321146530; 240 pages.
Black, Rex; Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing; Wiley; 2009; ISBN-10 0470404159; 672 pages.
Chess, Brian and West, Jacob; Secure Programming with Static Analysis; Addison Wesley, Boston, MA; 20007; ISBN 13: 978-0321424778; 624 pages.
Cohen, Lou; Quality Function Deployment – How to Make QFD Work for You; Prentice Hall, Upper Saddle River, NJ; 1995; ISBN 10: 0201633302; 368 pages.
Crosby, Philip B.; Quality is Free; New American Library, Mentor Books, New York, NY; 1979; 270 pages.
Everett, Gerald D. And McLeod, Raymond; Software Testing; John Wiley & Sons, Hoboken, NJ; 2007; ISBN 978-0-471-79371-7; 261 pages.
Gack, Gary; Managing the Black Hole: The Executives Guide to Software Project Risk; Business Expert Publishing, Thomson, GA; 2010; ISBN10: 1-935602-01-9.
Gack, Gary; Applying Six Sigma to Software Implementation Projects; software.isixsigma.com/library/content/c040915b.asp.
Gilb, Tom and Graham, Dorothy; Software Inspections; Addison Wesley, Reading, MA; 1993; ISBN 10: 0201631814.
Hallowell, David L.; Six Sigma Software Metrics, Part 1.; software.isixsigma.com/library/content/03910a.asp.
IFPUG (52 authors); The IFPUG Guide to IT and Software Measurement; Auerbach publishers; 2012.
International Organization for Standards; ISO 9000 / ISO 14000; www.iso.org/iso/en/iso9000-14000/index.html.
Jacobsen, Ivar; Ng Pan-Wei; McMahon, Paul; Spence, Ian; Lidman, Svente; The Essence of Software Engineering: Applying the SEMAT Kernel; Addison Wesley, 2013.
Jones, Capers; The Technical and Social History of Software Engineering; Addison Wesley, 20124.
Jones, Capers; “A Short History of Lines of Code Metrics”; Namcook Analytics LLC, Narragansett, RI 2014.Jones, Capers; “A Short History of the Cost per Defect Metric”; Namcook Analytics LLC, Narragansett RI 2014.
Jones, Capers; The Technical and Social History of Software Engineering; Addison Wesley Longman, Boston, Boston, MA; 2014.
Jones, Capers and Bonsignour, Olivier; The Economics of Software Quality; Addison Wesley, Boston, MA; 2011; ISBN 978-0-13-258220-9; 587 pages.
Jones, Capers; Software Engineering Best Practices; McGraw Hill, New York; 2010; ISBN 978- 0-07-162161-8;660 pages.
Jones, Capers; “Measuring Programming Quality and Productivity”; IBM Systems Journal; Vol. 17, No. 1; 1978; pp. 39-63.
Jones, Capers; Programming Productivity — Issues for the Eighties; IEEE Computer Society Press, Los Alamitos, CA; First edition 1981; Second edition 1986; ISBN 0-8186—0681-9; IEEE Computer Society Catalog 681; 489 pages.
Jones, Capers; “A Ten-Year Retrospective of the ITT Programming Technology Center”; Software Productivity Research, Burlington, MA; 1988.
Jones, Capers; Applied Software Measurement; McGraw Hill, 3rd edition 2008; ISBN 978=0- 07-150244-3; 662 pages.
Jones, Capers; Critical Problems in Software Measurement; Information Systems Management Group, 1993; ISBN 1-56909-000-9; 195 pages.
Jones, Capers; Software Productivity and Quality Today — The Worldwide Perspective; Information Systems Management Group, 1993; ISBN -156909-001-7; 200 pages.
Jones, Capers; Assessment and Control of Software Risks; Prentice Hall, 1994; ISBN 0-13- 741406-4; 711 pages.
Jones, Capers; New Directions in Software Management; Information Systems Management Group; ISBN 1-56909-009-2; 150 pages.
Jones, Capers; Patterns of Software System Failure and Success; International Thomson Computer Press, Boston, MA; December 1995; 250 pages; ISBN 1-850-32804-8; 292 pages.
Jones, Capers; Software Quality – Analysis and Guidelines for Success; International Thomson Computer Press, Boston, MA; ISBN 1-85032-876-6; 1997; 492 pages.
Jones, Capers; Estimating Software Costs; 2nd edition; McGraw Hill, New York; 2007; 700 pages..Jones, Capers; “The Economics of Object-Oriented Software”; Namcook Analytics; Narragansett, RI; 2014.
Jones, Capers; “Software Project Management Practices: Failure Versus Success”; Crosstalk, October 2004.
Jones, Capers; “Software Estimating Methods for Large Projects”; Crosstalk, April 2005.
Kan, Stephen H.; Metrics and Models in Software Quality Engineering, 2nd edition; Addison
Wesley Longman, Boston, MA; ISBN 0-201-72915-6; 2003; 528 pages.
Land, Susan K; Smith, Douglas B; Walz, John Z; Practical Support for Lean Six Sigma Software Process Definition: Using IEEE Software Engineering Standards; WileyBlackwell; 2008; ISBN 10: 0470170808; 312 pages.
Mosley, Daniel J.; The Handbook of MIS Application Software Testing; Yourdon Press, Prentice Hall; Englewood Cliffs, NJ; 1993; ISBN 0-13-907007-9; 354 pages.
Myers, Glenford; The Art of Software Testing; John Wiley & Sons, New York; 1979; ISBN 0- 471-04328-1; 177 pages.
Nandyal; Raghav; Making Sense of Software Quality Assurance; Tata McGraw Hill Publishing, New Delhi, India; 2007; ISBN 0-07-063378-9; 350 pages.
Radice, Ronald A.; High Quality Low Cost Software Inspections; Paradoxicon Publishingl Andover, MA; ISBN 0-9645913-1-6; 2002; 479 pages.
Royce, Walker E.; Software Project Management: A Unified Framework; Addison Wesley Longman, Reading, MA; 1998; ISBN 0-201-30958-0.
Starr, Paul; The Social Transformation of American Medicine; (Pulitzer Prize in 1982); Basic Books, 1982;
Strassman, Paul; The Squandered Computer; The Information Economics Press, New Canaan, CT; 1997; 426 pages.
Wiegers, Karl E.; Peer Reviews in Software – A Practical Guide; Addison Wesley Longman, Boston, MA; ISBN 0-201-73485-0; 2002; 232 pages.
Двадцать пять целей индустрии программного обеспечения на 2015–2019г.г.
С разрешения автора: Каперс Джонс
Каперс Джонс, VP and CTO Namcook Analytics LLC
Версия 5.0 28 февраля 2015 г.
Краткий обзор
Развитие индустрии программного обеспечения имеет сходство с походкой алкоголика, при которой движение одновременно и выравнивается и дает задний ход. Например, гибкая методология разработки – это выравнивание малых проектов, а парное программирование — это движение назад, слишком дорогостоящее для роли двигателя.
Одна из причин отсутствия неуклонного движения вперед – это тягостное отсутствие эффективной системы измерений. Две старейшие и наиболее распространенные метрики, стоимость дефектов и строк программы, не свидетельствуют о прогрессе и фактически искажают реальность. С подсчетом затрат за дефект страдает качество, а за строку программы – бракуются языки программирования высокого уровня.
В этой небольшой статье представлены 25 реальных целей, которые могут быть достигнуты в течение 5 лет, принимая за точку отсчета 2015 год. Некоторые цели выражены в показателях метрики функциональных баллов (Function Points — FPs), которая является единственной широко используемой метрикой, допустимой для освещения экономической результативности и качества без серьезных погрешностей.
Другой пригодной метрикой является «эффективность устранения дефектов» (defect removal efficiency — DRE), которая показывает процентное отношение найденных и устраненных ошибок во время разработки по сравнению с количеством ошибок, о которых сообщают пользователи на протяжении первых 90 дней использования программы. Если разработчики нашли 95 ошибок, а пользователи сообщили о 5 ошибках за три месяца, то DRE равняется 95%. В настоящее время средний показатель DRE в США представлен только на уровне примерно 90%, но технически возможно для каждого проекта по разработке программного обеспечения достичь 95%, а для многих – достичь и 99%.
Web: www.Namcook.com
Blog: Namcookanalytics.com
Email: Capers.Jones3@gmail.com
© Каперс Джонс, 2014 – 2015. Все права защищены.
Двадцать пять задач индустрии программного обеспечения на 2015 – 2019 гг.
Введение
Нижеследующее представляет собой подборку 25 целей или задач для развития программирования, разработанную Namcook Analytics LLC для реализации в течение пяти лет с 2015 по 2019 гг. Некоторые из этих целей достижимы уже в 2015 году, но далеко не всем компаниям удалось достичь их. Незначительное число избранных ведущих компаний достигло некоторых из отмеченных целей.
К сожалению, менее 5% компаний США и транснациональных компаний достигли какой-либо из представленных целей и менее 1% достигли большинства целей. Ни одному из клиентов автора не удалось достичь всех целей.
Автор предлагает, чтобы каждая крупная компания по разработке программного обеспечения и правительственная организация создали свою подборку целей на пятилетний период, используя предложенный список как отправной пункт.
1. Поднять эффективность устранения дефектов (DRE) с < 90.0% до > 99.5%. Эта цель является наиболее важной для индустрии. Она не может быть достигнута только тестированием, но требует применения предтестового контроля и статического анализа. DRE измеряется сравнением всех дефектов, найденных во время разработки, с теми, о которых сообщают потребители на протяжении первых 90 дней. Текущий средний показатель DRE в США равен примерно 90%. Динамика равна приблизительно 92%. Лишь немногие компании-лидеры, используя полный комплект предупреждения дефектов, предтестовое устранение дефектов и формальное рецензирование с математически спроектированными контрольными примерами и привлекая дипломированных специалистов по тестированию, могут достичь 99% DRE.
2. Снизить показатель возможности дефектов программного обеспечения с > 4.0 на функциональный балл до < 2.0 на функциональный балл. Показатель возможности дефектов – это сумма ошибок, найденных в технических требованиях, конфигурации, проектировании, коде, документах пользователя и некачественно исправленных патчах. Ошибки технических требований и проектирования часто численно превосходят ошибки кода. В настоящее время показатель возможностей дефектов может достичь 6.0 на функциональный балл в больших системах с 10.000 функциональных баллов в типоразмерном ряду. Достижение этой цели требует эффективного предупреждения дефектов, к которому относятся, например, совместная разработка прикладных программ (joint application design — JAD), структурирование функции качества (quality function deployment — QFD), официально одобренные компоненты многократного применения и др. Для этого также требуется программа полного контроля качества программного обеспечения. Для достижения этой цели также необходимо улучшить профессиональную подготовку по общим источникам дефектов, обнаруживаемых в технических требованиях, проектировании и исходном тексте. Наиболее эффективный способ снижения возможностей дефектов – переключиться с проектирования по техническим требованиям заказчика и кодирования вручную, которые по своей сути предрасположены к ошибкам. Проектирование с целью создания официально одобренных компонентов многократного применения может способствовать весьма значительному снижению возможностей дефектов программного обеспечения.
3. Снизить затраты на обеспечение качества (cost of quality — COQ) с > 45.0% стоимости разработки до < 15.0% стоимости разработки. Обнаружение и устранение неисправностей на протяжении более 50 лет и до сих пор было наиболее дорогостоящим заданием в программировании. Для достижения этой цели необходимо синергетическое сочетание предотвращения дефектов, предтестового контроля и статического анализа. Вероятным итогом могло бы стать повышение эффективности устранения дефектов с сегодняшнего среднего показателя ниже 90% до 99%. Одновременно возможности дефектов могут быть сокращены с сегодняшнего среднего показателя 4.0 на функциональный балл до менее 2.0 на функциональный балл. Это сочетание будет оказывать сильное синергетическое влияние на расходы по техническому обслуживанию и технической поддержке. Между прочим, снижение затрат на качество также уменьшит технический долг. Однако по итогам 2014 года технический долг не является стандартной метрикой и так значительно отличается в различных местах, что его трудно подсчитать.
4. Снизить среднюю цикломатическую сложность с > 25.0 до < 10.0. Достижение этой цели требует тщательного анализа структур программного обеспечения и, конечно, измерения цикломатической сложности для всех модулей. Так как цикломатические инструменты являются общепринятыми и некоторые из них являются открытыми исходными текстами, каждое приложение должно использовать их без исключения.
5. Увеличить тестовое покрытие относительно рисков, маршрутов и технических требований с < 75.0% до > 98.5%. Достижение этой цели требует использования математических методов проектирования для создания контрольных примеров; таким методом является, например, планирование экспериментов. Также требуется измерение тестового покрытия. Необходимыми являются и средства прогностической диагностики, которые могут прогнозировать количество контрольных примеров, основанных на функциональных баллах, кодовых томах и цикломатической сложности. Авторская сервисная программа по диагностике рисков программного обеспечения (SRM) прогнозирует контрольные примеры для 18 видов тестирования и, следовательно, может также прогнозировать вероятное тестовое покрытие.
6. Устранить подверженные ошибкам модули (error-prone modules — EPM) в больших системах. Неисправности не распределяются беспорядочно. Достижение этой цели требует тщательных измерений дефектов кода во время разработки и после выпуска с помощью инструментальных программных средств, которые могут отслеживать ошибки до конкретных модулей. Некоторые компании, как, например, IBM, делают это уже на протяжении многих лет. Подверженные ошибкам модули (EPM) обычно составляют менее 5% общего количества модулей, но на них приходится более 50% всех ошибок. Предотвращение – это наилучшее решение. Существующие подверженные ошибкам модули в унаследованных приложениях могут нуждаться в хирургическом удалении и замене. Тем не менее, статический анализ должен применяться ко всем распознанным EPM. В одном исследовании главное приложение насчитывало 425 модулей. 57% всех ошибок было найдено во всего лишь 31 модуле, собранном одним отделом. Более 300 модулей были бездефектными. EPM легко предотвратить, но трудно исправить, если они уже были созданы. Обычно хирургическое удаление неизбежно. EPM – наиболее дорогостоящие артефакты в истории программирования. EPM имеют сходство с заболеванием оспой; то есть оно не может быть полностью устранено с помощью «вакцинации» и эффективных контрольных методов. Подверженные ошибкам модули часто достигают показателя 3.0 ошибок на функцию и удаляются в количестве менее 80% до выпуска программного обеспечения. Они также стремятся войти в число топ-50 по показателям цикломатической сложности. Устранение дефектов на более высоком уровне посредством тестирования представляет сложность из-за высоких уровней цикломатической сложности.
7. Устранить дефекты безопасности во всех приложениях программного обеспечения. По мере того как киберпреступность все более распространяется, возникает все большая необходимость в совершенствовании средств обеспечения безопасности. Достижение этой цели требует контроля состояния безопасности, тестирования систем безопасности и автоматизированного инструментария по обнаружению дефектов безопасности. Для работы с главными системами, которые содержат ценные финансовые или конфиденциальные данные, могут также понадобиться этичные хакеры.
8. Снизить вероятность кибератак с > 10.0% до < 0.1%. Достижение этой цели требует синергетического сочетания усовершенствованных межсетевых экранов, непрерывного антивирусного контроля и постоянных обновлений вирусных сигнатур; а также нужно работать над повышением иммунитета самого программного обеспечения посредством изменений основной конфигурации и стратегий прав доступа. Возможно, потребуется пересмотр конфигурации оборудования и программного обеспечения для повышения уровня защищенности того и другого.
9. Сократить инжекции некачественного устранения ошибок с > 7.0% до < 1.0%. Немногие люди знают, что около 7% попыток устранения ошибок программного обеспечения вносят новые ошибки в непосредственно исправленные участки, которые обычно называются «некачественно исправленными участками». Когда цикломатическая сложность достигает 50, показатель инжекции некачественного устранения ошибок может воспарить до 25% и более. Для сокращения инжекций некачественного устранения ошибок необходимо контролировать цикломатическую сложность, использовать статический анализ для всех участков устранения дефектов, тестировать все исправления и проверять все участки значительных исправлений до их сборки.
10. Уменьшить дрейф технических требований с > 1.5% на календарный месяц до < 0.25% на календарный месяц. Дрейф технических требований является эндемической проблемой индустрии программного обеспечения на протяжении уже более 50 лет. До тех пор, пока пригодны прототипы, динамичные встроенные пользователи и совместные разработки прикладных программ (JAD), технически возможно использовать автоматизированные модели технических требований для улучшения полноты технических требований. Лучшим методом было бы использование сопоставления с образцом для опознавания функциональных возможностей приложений, схожих с теми, которые находятся в разработке. Технология предшествования была бы полезной таксономией функциональных возможностей приложения программного обеспечения, что фактически еще не существует в 2015 году, но могло бы быть разработано в течение нескольких месяцев сосредоточенного исследования.
11. Снизить риск провала проекта или отмены на больших проектах в 10.000 функциональных баллов с > 35.0% до < 5.0%. Отмена больших систем из-за низкого качества, низкого уровня контроля изменений и перерасхода средств, что по своей сути поворачивает направление показателя возврата инвестиций (ROI) от позитивного к негативному, является эндемической проблемой индустрии программного обеспечения, без которой вполне можно было бы обойтись. Синергетическое сочетание эффективного предотвращения дефектов, предтестового контроля и статического анализа может приблизить к устранению этой слишком распространенной проблемы. Параметрические инструменты оценивания, которые могут прогнозировать риски, затраты и календарный план с большей точностью, чем подсчеты вручную, также рекомендованы к использованию.
12. Уменьшить вероятности запаздывания календарного плана с > 50.0% до < 5%. В связи с тем, что причинами запаздывания календарного плана являются низкое качество и чрезмерный дрейф технических требований, решение некоторых из указанных выше проблем этого списка также послужит решением проблемы запаздывания календарного плана. Большинство проектов кажутся выполняемыми в срок до тех пор, пока не начинается тестирование, когда громадное количество ошибок не начинает растягивать календарный план тестирования до бесконечности. Предотвращение дефектов в сочетании с предтестовым статическим анализом может сократить или устранить случаи запаздывания календарного плана. Это излечимое состояние и может быть исключено в течение пяти лет.
13. Сократить возможности перерасхода средств с > 40.0% до < 3.0%. Перерасход затрат на программное обеспечение и запаздывание календарного плана имеют схожие основные причины; то есть низкий контроль качества и низкий контроль изменений в сочетании с чрезмерным дрейфом технических требований. Лучшее предотвращение дефектов в сочетании с предтестовым устранением дефектов может способствовать излечению обеих этих эндемических проблем программного обеспечения. Применение точных параметрических инструментов оценивания, а не оптимистических подсчетов вручную, также полезно для сокращения перерасхода средств.
14. Сократить случаи судебных процессов по аутсорсинговым контрактам с > 5.0% до < 1.0%. Автор статьи был свидетелем-экспертом в 12 судебных процессах по нарушению контрактов. Похоже на то, что все эти дела имеют схожие основные причины, к которым относятся низкий контроль качества, низкий контроль изменений и очень низкое отслеживание состояния. Синергетическое сочетание ранней оценки размеров и анализа рисков перед подписанием контракта плюс эффективное предотвращение дефектов и предтестовое устранение дефектов могут сократить случаи судебных процессов по нарушению контрактов в индустрии программного обеспечения.
15. Снизить затраты на техническое обслуживание и ремонт до > 75.0% по сравнению со значениями 2015 года. Начиная примерно с 2000 года, число программистов по техническому обслуживанию в США начало превышать число программистов-разработчиков. IBM обнаружила, что эффективное предотвращение и предтестовое устранение дефектов поспособствовали сокращению количества окончательных дефектов до такого низкого уровня, что затраты на техническое обслуживание были сокращены самое меньшее до 45%, а иногда даже и до 75%. Эффективная разработка программного обеспечения и эффективный контроль качества оказывают большее влияние на затраты на техническое обслуживание, чем на разработку. Технически возможно сократить техническое обслуживание новых приложений более чем до 60% по сравнению с текущими средними величинами. Анализ унаследованных приложений и устранение подверженных ошибкам модулей, а также небольшая реорганизация исходного кода, также могут поспособствовать снижению затрат на техническое обслуживание на каждое унаследованное приложение примерно до 25%. Технический долг также будет уменьшен, но технический долг не является стандартной метрикой и различается так значительно, что его трудно подсчитать. Инструменты статического анализа должны регулярно запускаться по отношению ко всем активным унаследованным приложениям.
16. Увеличить объем официально одобренных материалов многократного применения с < 15.0% до > 75.0%. Проектирование по техническим требованиям заказчика и кодирование вручную по существу подвержено ошибкам и неэффективно, какая бы методика ни использовалась. Наилучшим способом превращения программирования из ремесла в современную профессию могло бы стать конструирование приложений из библиотек официально одобренных материалов многократного применения; то есть посредством использования технических требований, проектов, кодов и тестовых материалов многократного применения. Все предполагаемые для использования материалы многократного применения должны быть пересмотрены, кодовые сегменты – проверены, а серии статического анализа запущены. Так точно, код многократного применения должен сопровождаться тестовыми материалами многократного применения и сопутствующей информацией, каковыми являются цикломатическая сложность и пользовательская информация.
17. Улучшить среднюю результативность разработки с < 8.0 функциональных баллов в месяц до > 16.0 функциональных баллов в месяц. Коэффициенты результативности различаются по признаку размера, сложности, опыта команды, методик и по нескольким другим факторам. Тем не менее, когда все проекты рассматриваются в совокупности, средняя результативность ниже 8.0 функциональных баллов на штатный месяц. Для того чтобы удвоить этот коэффициент, нужно сочетать лучший контроль качества с намного большими объемами официально одобренных материалов многократного применения; вероятно, на 50% и более.
18. Сократить рабочее время на функциональный балл с > 16.5 до < 8.25. Цель номер 17 и эта цель по существу одинаковы, но используют различные метрики. Тем не менее, есть одно важное отличие. Рабочие часы в месяц не будут равняться одному и тому же числу в каждой стране. Например, проект в Нидерландах со 116 рабочими часами в месяц будет равняться тому же рабочему времени, что и проект в Китае со 186 рабочими часами в месяц. Но для китайского проекта потребуется меньшее число календарных месяцев, чем для нидерландского проекта.
19. Улучшить максимальную результативность до > 100 функциональных баллов на штатный месяц в 1000 функциональных баллов. В настоящее время, по состоянию на начало 2015 года, коэффициент результативности на 1000 функциональных баллов находится в диапазоне примерно от 5 до 12 баллов на штатный месяц. По сути, невозможно достичь 100 функциональных баллов на штатный месяц, используя проектирование по техническим условиям заказчика и кодирование вручную. Только конструирование из библиотек стандартных компонентов многократного применения может позволить такому высокому коэффициенту результативности стать реальностью. Тем не менее, было бы возможным увеличить объем материалов многократного применения. Предшествующий продукт нуждается в хорошей таксономии функциональных возможностей программного обеспечения, каталогах материалов многократного применения и процессе сертификации для добавления новых материалов многократного применения. Также необходимо применять метод отзыва, в случае, если материалы многократного применения содержат ошибки или нуждаются в изменениях.
20. Сократить средний календарный план разработки программного обеспечения до > 35% по сравнению со средними показателями 2015 года. Наиболее распространенной жалобой клиентов сферы программного обеспечения и управляющих корпорациями на уровне директора по информатизации (CIO) и финансового директора (CFO) является то, что проекты программного обеспечения занимают много времени. Удивительно то, что сократить это время не представляет труда. Синергетическое сочетание лучшего предотвращения дефектов, предтестового статического анализа и контроля, а также больший объем официально одобренных материалов многократного применения, могут способствовать существенным сокращениям интервалов календарного плана. В современном мире увеличение размера приложений программного обеспечения в функциональных баллах со степенью 0.4 обеспечивает удобное приближение к длительности плана в календарных месяцах. Но действующие технологии способны снизить показатель степени до 0.37. Увеличение 1000 функциональных баллов со степенью 0.4 указывает на график в 15.8 календарных месяцев. Увеличение 1000 функциональных баллов со степенью 0.37 указывает на график во всего лишь 12.9 календарных месяцев. Такой более короткий календарный план становится возможным благодаря использованию эффективного предотвращения дефектов, усиленного предтестовым контролем и статическим анализом. Компоненты программного обеспечения многократного использования могли бы снизить показатель степени до 0.3 или 7.9 календарных месяцев. Запаздывание календарного плана сегодня безудержно растет, но поддается лечению и может быть устранено.
21. Увеличение объемов задания технического обслуживания с < 1500 функциональных баллов до > 5000 функциональных баллов. Метрика «объем задания технического обслуживания» относится к числу функциональных баллов, которое один программист по техническому обслуживанию может поддерживать и сохранять в режиме функционирования на протяжении календарного года. Диапазон представлен от < 300 функциональных баллов для дефектов и сложного программного обеспечения до > 5000 функциональных баллов для современного программного обеспечения, выпущенного под эффективным контролем качества. Текущий средний показатель составляет примерно 1500 функциональных баллов. Это ключевая метрика для прогнозирования кадрового обеспечения технического обслуживания как проектов по техническим условиям заказчика, так и корпоративных портфолио. Достижение этой цели требует эффективного предотвращения дефектов, эффективного предтестового устранения дефектов и эффективного тестирования с использованием современных методик проектирования контрольных примеров на основе математических расчетов. Для достижения этой цели также необходим низкий уровень цикломатической сложности. Статический анализ должен быть запущен во всех приложениях во время разработки, а также и в унаследованных приложениях.
22. Заменить сегодняшние статические и жесткие технические требования, конфигурацию и методы проектирования на комплект анимационных средств проектирования в сочетании с сопоставлением с образцом. Во время своей работы приложения программного обеспечения являются самыми быстрыми объектами, которые были когда-либо созданы человеческим родом. В ходе своего развития приложения программного обеспечения растут и изменяются каждый день. Вряд ли какой-либо метод проектирования является статичным и состоит из такого текста, как баллы текстовых блоков, или таких очень примитивных и ограниченных диаграмм, как блок-схемы или диаграммы на унифицированном языке моделирования (UML). Технология создания нового метода анимационного проектирования графическими средствами в полном цвете и трех измерениях существует уже сегодня, с 2014 года. Остается только разработать набор символов и начать анимировать процесс проектирования.
23. Разработать средство интерактивного обучения для программирования на основе широкомасштабно интерактивных технологий создания игр. Новые концепции в программировании появляются почти каждый день. Новые языки программирования выпускаются еженедельно. Программное обеспечение приговаривает медицину, закон и другие формы инженерии к постоянному обучению. Но обучение вживую является дорогостоящим и неудобным. Появляется необходимость в инструментальном средстве интерактивного обучения с функцией встроенного планирования программы обучения. В настоящее время возможно разработать такое инструментальное средство. С помощью лицензирования игрового движка появляется возможность создания модели университета программирования, в котором аватары смогли бы посещать занятия и контактировать друг с другом.
24. Разработать комплект динамических анимационных инструментов планирования и оценивания проекта, которые будут показывать развитие приложений программного обеспечения. В наше время выходные данные всех инструментов оценивания программного обеспечения подаются в виде статических таблиц, подкрепленных несколькими графиками. Но приложения программного обеспечения развиваются при разработке более чем на 1% в календарный месяц и продолжают развиваться после выпуска более чем на 8% в календарный месяц. Очевидно, что инструменты планирования и оценивания программного обеспечения нуждаются в возможностях динамического моделирования, которое сможет показать рост функциональности со временем. Они также должны показывать прибытие (и обнаружение) ошибок или дефектов, поступающих из технических требований, проектирования, конфигурации, кода и других источников дефектов. Конечной целью, которая технически достижима сегодня, может стать графическая модель, которая показывает рост приложения с первых дней технических требований и до 25-летия его использования.
25. Внедрить лицензирование и профессиональную аттестацию разработчиков программного обеспечения и специалистов. Настоятельно рекомендуется, чтобы каждый читатель этой статьи также прочел книгу Пола Старра «Социальная трансформация американской медицины» (The Social Transformation of American Medicine). Эта книга была награждена Пулитцеровской премией в 1982 г. В книге Старра показано, как Американская медицинская ассоциация сумела усовершенствовать академическое обучение, снизить профессиональную небрежность и достичь более высокого уровня профессионализма, чем другие технические сферы. Медицинские лицензии и профессиональная аттестация специалистов были ключевыми факторами в прогрессе медицины. Медицине понадобилось более 75 лет для достижения существующего профессионального статуса, но с книгой Старра в качестве руководства программирование смогло бы достичь того же самого в течение 10 лет. Это за пределами 5-летнего окна этой статьи, однако процесс должен начаться в 2015 г.
Обратите внимание, что метрика функциональных баллов, использованная в этой статье, относится к функциональным баллам в определении Международной группы пользователей метрик на основе функциональных баллов (IFPUG). Другие определения функциональных баллов, к которым, кроме прочего, относятся COSMIC, FISMA, NESMA, неурегулированные и др., могут также использоваться, но будут иметь другие количественные результаты.
Множества технологий, доступных в 2015 г., уже вполне достаточно для достижения каждой из этих 25 целей, несмотря на то, что немногие компании их достигли. Некоторые технологии, ассоциированные с достижением этих 25 целей, включают среди прочего:
Полезные технологии для реализации целевых установок программирования
- Применяйте на ранней стадии средства анализа рисков, оценки размеров, а также оценки затрат на качество и календарный план перед началом главных проектов, каковым является, например, сервисная программа Namcook по диагностике рисков программного обеспечения (SRM).
- Используйте параметрические инструменты оценивания, нежели оптимистические подсчеты вручную. Все параметрические инструменты (COCOMO, CostExpert, ExcelerPlan, KnowledgePlan, SEER, SLIM, Software Risk Master (SRM) и True Price) произведут лучшие результаты для больших приложений, чем подсчеты вручную, оптимизм которых прогрессирует с ростом размера приложения.
- Используйте средства эффективного предотвращения дефектов, каковыми являются, например, совместная разработка прикладных программ (JAD) и структурирование функции качества (QFD).
- Применяйте предтестовый контроль главных комплектующих узлов, как, например, технических требований, конфигурации, проектирования, кода и т. п.
- Используйте как статический анализ текста, так и статический анализ исходного текста всего программного обеспечения. Это включает новые приложения и 100% активных унаследованных приложений.
- Используйте список распространенных ошибок программирования института SANS и избегайте их всех.
- Используйте инструменты удобочитаемости FOG и FLESCH в технических требованиях, проектировании и т. д.
- Применяйте математическое проектирование контрольных случаев, как, например, проектирование экспериментов.
- Пользуйтесь услугами аттестованного персонала по тестированию и обеспечению качества.
- Используйте метрики функциональных баллов для контрольных задач и нормализации данных.
- Используйте эффективные методики, как например, гибкая методология разработки и XP для малых проектов, а также RUP и TSP для больших систем. Гибридные методы также эффективны, каковым является, например, гибкая методология разработки в сочетании с TSP.
- Используйте автоматизированные инструментальные средства тестового покрытия.
- Используйте автоматизированные инструментальные средства цикломатической сложности.
- Используйте параметрические измерительные средства, которые могут прогнозировать качество, календарный план и затраты. Подсчеты вручную могут быть чрезмерно оптимистичными.
- Используйте точные измерительные инструментальные средства и методы с наименьшей точностью 3.0%.
- Примите во внимание применение автоматизированных моделей технических требований, которые могут быть эффективны для минимизации проблем, связанных с техническими требованиями.
- Примите во внимание применение нового метода SEMAT (Методы и теоретические основы программирования), который оправдывает данные им гарантии усовершенствования проектирования и качества кода. SEMAT поступает с кривой обучения, поэтому прочтение опубликованной книги необходимо перед применением метода.
Мы на пороге времени, предшествующего превращению программирования из ремесла в современную профессию. Это также время, предшествующее переключению с частичного и неточного анализа результатов программного обеспечения на результаты высокой точности как для прогнозирования перед началом проектов, так и для измерений после их завершения.
Представленные выше 25 целей являются позитивными целевыми установками, к достижению которых нужно стремиться компаниям и правительственным организациям. Однако «инженерия разработки программного обеспечения» также имеет и некоторое количество вредоносных методов, которых следует избегать или исключать из применения. Некоторые их них настолько вредоносны, что не могут рассматриваться как профессиональная небрежность. Ниже указаны шесть опасных методов проектирования программных средств, некоторые из которых непрерывно использовались на протяжении более 50 лет без осознания их вредоносности в полной мере:
Шесть опасных методов проектирования программных средств, которых следует избегать
1. Прекратите попытки измерить экономику качества посредством «расходов на дефект». Эта метрика всегда показывает самую низкую величину для самого полного неисправностей программного обеспечения, таким образом ставя под удар качество. Метрика также преуменьшает истинную экономическую ценность программного обеспечения на несколько сотен процентов. Эта метрика нарушает стандартные экономические допущения и может рассматриваться как профессиональная небрежность при измерении экономики качества. Лучшим средством измерения стоимости качества является подсчет «расходов на устранение дефектов на функциональный балл». Расходы на дефект не берут во внимание фиксированные расходы на написание и прогон контрольных случаев. Это известный принцип производственной экономики, согласно которому, если в процессе имеет место высокая пропорция фиксированных расходов, расходы на единицу поднимаются. Городская байка о том, что потребуется в 100 раз больше затрат на исправление ошибки после выпуска программного обеспечения, чем до него, безосновательна; расходы почти равнозначны, если просчитаны должным образом.
2. Прекратите попытки измерить результативность программного обеспечения с помощью метрики «строк кода» (lines of code — LOC). Эта метрика бракует языки программирования высокого уровня. Это средство измерения также не отражает в подсчетах работу вне кодирования, каковой являются, например, технические требования и проектирование. Эта метрика может рассматриваться как профессиональная небрежность при экономическом анализе, включающем многочисленные языки программирования. Лучшим средством измерения результативности программного обеспечения является подсчет рабочего времени на функциональный балл и функциональных баллов на штатный месяц. Измерения этих обеих величин могут быть использованы на уровнях активности, а также для проектов в целом. Эта метрика может быть использована и для измерения работ вне кода, каковыми являются, например, технические требования и проектирование. Метрика LOC имеет ограниченную функциональность относительно самого кода, но представляет опасность для более крупных экономических исследований целых проектов. Метрика LOC не принимает во внимание затраты на технические требования, проектирование и документацию, которые обычно превосходят затраты на код как таковой.
3. Прекратите измерение «проектирования, кода и блочного тестирования» или (design, code, and unit test — DCUT). Измеряйте целые проекты, включая руководство, технические требования, проектирование, кодирование, сборку, документацию, все формы тестирования и т. п. Измерения DCUT охватывают менее 30% общих затрат на проекты по разработке программного обеспечения. Измерение затрат всего лишь части проекта по разработке программного обеспечения приводит к состоянию профессионального замешательства.
4. Будьте осторожны с «техническим долгом». Это полезная метафора, которая вместе с тем не является полноценной метрикой для понимания экономики качества. Технический долг пренебрегает высокими затратами отмененных проектов, которые включают как побочные убытки клиентов, так и затраты на судебные процессы, а также возможное назначенное возмещение убытков истцам. Технический долг учитывает только 17% истинных затрат на низкое качество. Измерение затрат на качество (COQ) является лучшей метрикой для экономики качества.
5. Избегайте «парного программирования». Парное программирование дорогостоящее и менее эффективное, чем сочетание контроля и статического анализа. Ознакомьтесь с литературой по парному программированию и, в особенности, с докладами программистов, которые специально увольняются с работы, чтобы избежать парного программирования. Литература, одобряющая парное программирование, также иллюстрирует общую слабость исследования по программированию, в котором не сравнивается парное программирование с методами с доказанным качеством результатов, каковыми являются контроль и статический анализ. Сравнению подвергаются только пары и единичные программисты без обсуждения инструментария, методов, контроля и т. п.
6. Прекратите полагаться только на тестирование без использования эффективных методов предотвращения и предтестового устранения дефектов, каковыми являются контроль и статический анализ. Тестирование само по себе без предтестового устранения дефектов является дорогостоящим и редко достигает 85% по уровню эффективности устранения дефектов. Синергетическое сочетание предотвращения и предтестового устранения дефектов, к которым относятся, например, статический анализ и контроль, может повысить DRE до > 99%, в то же самое время сокращая затраты и укорачивая календарные планы.
Инженерия разработки программного обеспечения всегда очень сильно отличалась от более старых и зрелых форм инженерии. Одним из наиболее значимых отличий сферы инженерии разработки программного обеспечения от традиционной инженерии является то, что инженерия разработки программного обеспечения имеет очень скудный опыт измерений и обладает слишком субъективной информацией вместо веских эмпирических данных.
В этой небольшой статье предлагается подборка 25 количественных целей, достижение которых поспособствует значительному продвижению как в качестве программного обеспечения, так и в его результативности. Однако, важнейшее послание заключается в том, что низкое качество программного обеспечения является критическим фактором, который нуждается в улучшении, для того чтобы, в свою очередь, усовершенствовать результативность, календарные планы, затраты и экономику.
References
Abrain, Alain; Software Estimating Models; Wiley-IEEE Computer Society; 2015
Abrain, Alain; Software Metrics and Metrology; Wiley-IEEE Computer Society; 2010
Abrain, Alain; Software Maintenance Management: Evolution and Continuous Improvement; Wiley-IEEE Computer Society, 2008.Beck, Kent; Test-Driven Development; Addison Wesley, Boston, MA; 2002; ISBN 10: 0321146530; 240 pages.
Black, Rex; Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing; Wiley; 2009; ISBN-10 0470404159; 672 pages.
Chess, Brian and West, Jacob; Secure Programming with Static Analysis; Addison Wesley, Boston, MA; 20007; ISBN 13: 978-0321424778; 624 pages.
Cohen, Lou; Quality Function Deployment – How to Make QFD Work for You; Prentice Hall, Upper Saddle River, NJ; 1995; ISBN 10: 0201633302; 368 pages.
Crosby, Philip B.; Quality is Free; New American Library, Mentor Books, New York, NY; 1979; 270 pages.
Everett, Gerald D. And McLeod, Raymond; Software Testing; John Wiley & Sons, Hoboken, NJ; 2007; ISBN 978-0-471-79371-7; 261 pages.
Gack, Gary; Managing the Black Hole: The Executives Guide to Software Project Risk; Business Expert Publishing, Thomson, GA; 2010; ISBN10: 1-935602-01-9.
Gack, Gary; Applying Six Sigma to Software Implementation Projects; software.isixsigma.com/library/content/c040915b.asp.
Gilb, Tom and Graham, Dorothy; Software Inspections; Addison Wesley, Reading, MA; 1993; ISBN 10: 0201631814.
Hallowell, David L.; Six Sigma Software Metrics, Part 1.; software.isixsigma.com/library/content/03910a.asp.
IFPUG (52 authors); The IFPUG Guide to IT and Software Measurement; Auerbach publishers; 2012.
International Organization for Standards; ISO 9000 / ISO 14000; www.iso.org/iso/en/iso9000-14000/index.html.
Jacobsen, Ivar; Ng Pan-Wei; McMahon, Paul; Spence, Ian; Lidman, Svente; The Essence of Software Engineering: Applying the SEMAT Kernel; Addison Wesley, 2013.
Jones, Capers; The Technical and Social History of Software Engineering; Addison Wesley, 20124.
Jones, Capers; “A Short History of Lines of Code Metrics”; Namcook Analytics LLC, Narragansett, RI 2014.Jones, Capers; “A Short History of the Cost per Defect Metric”; Namcook Analytics LLC, Narragansett RI 2014.
Jones, Capers; The Technical and Social History of Software Engineering; Addison Wesley Longman, Boston, Boston, MA; 2014.
Jones, Capers and Bonsignour, Olivier; The Economics of Software Quality; Addison Wesley, Boston, MA; 2011; ISBN 978-0-13-258220-9; 587 pages.
Jones, Capers; Software Engineering Best Practices; McGraw Hill, New York; 2010; ISBN 978- 0-07-162161-8;660 pages.
Jones, Capers; “Measuring Programming Quality and Productivity”; IBM Systems Journal; Vol. 17, No. 1; 1978; pp. 39-63.
Jones, Capers; Programming Productivity — Issues for the Eighties; IEEE Computer Society Press, Los Alamitos, CA; First edition 1981; Second edition 1986; ISBN 0-8186—0681-9; IEEE Computer Society Catalog 681; 489 pages.
Jones, Capers; “A Ten-Year Retrospective of the ITT Programming Technology Center”; Software Productivity Research, Burlington, MA; 1988.
Jones, Capers; Applied Software Measurement; McGraw Hill, 3rd edition 2008; ISBN 978=0- 07-150244-3; 662 pages.
Jones, Capers; Critical Problems in Software Measurement; Information Systems Management Group, 1993; ISBN 1-56909-000-9; 195 pages.
Jones, Capers; Software Productivity and Quality Today — The Worldwide Perspective; Information Systems Management Group, 1993; ISBN -156909-001-7; 200 pages.
Jones, Capers; Assessment and Control of Software Risks; Prentice Hall, 1994; ISBN 0-13- 741406-4; 711 pages.
Jones, Capers; New Directions in Software Management; Information Systems Management Group; ISBN 1-56909-009-2; 150 pages.
Jones, Capers; Patterns of Software System Failure and Success; International Thomson Computer Press, Boston, MA; December 1995; 250 pages; ISBN 1-850-32804-8; 292 pages.
Jones, Capers; Software Quality – Analysis and Guidelines for Success; International Thomson Computer Press, Boston, MA; ISBN 1-85032-876-6; 1997; 492 pages.
Jones, Capers; Estimating Software Costs; 2nd edition; McGraw Hill, New York; 2007; 700 pages..Jones, Capers; “The Economics of Object-Oriented Software”; Namcook Analytics; Narragansett, RI; 2014.
Jones, Capers; “Software Project Management Practices: Failure Versus Success”; Crosstalk, October 2004.
Jones, Capers; “Software Estimating Methods for Large Projects”; Crosstalk, April 2005.
Kan, Stephen H.; Metrics and Models in Software Quality Engineering, 2nd edition; Addison
Wesley Longman, Boston, MA; ISBN 0-201-72915-6; 2003; 528 pages.
Land, Susan K; Smith, Douglas B; Walz, John Z; Practical Support for Lean Six Sigma Software Process Definition: Using IEEE Software Engineering Standards; WileyBlackwell; 2008; ISBN 10: 0470170808; 312 pages.
Mosley, Daniel J.; The Handbook of MIS Application Software Testing; Yourdon Press, Prentice Hall; Englewood Cliffs, NJ; 1993; ISBN 0-13-907007-9; 354 pages.
Myers, Glenford; The Art of Software Testing; John Wiley & Sons, New York; 1979; ISBN 0- 471-04328-1; 177 pages.
Nandyal; Raghav; Making Sense of Software Quality Assurance; Tata McGraw Hill Publishing, New Delhi, India; 2007; ISBN 0-07-063378-9; 350 pages.
Radice, Ronald A.; High Quality Low Cost Software Inspections; Paradoxicon Publishingl Andover, MA; ISBN 0-9645913-1-6; 2002; 479 pages.
Royce, Walker E.; Software Project Management: A Unified Framework; Addison Wesley Longman, Reading, MA; 1998; ISBN 0-201-30958-0.
Starr, Paul; The Social Transformation of American Medicine; (Pulitzer Prize in 1982); Basic Books, 1982;
Strassman, Paul; The Squandered Computer; The Information Economics Press, New Canaan, CT; 1997; 426 pages.
Wiegers, Karl E.; Peer Reviews in Software – A Practical Guide; Addison Wesley Longman, Boston, MA; ISBN 0-201-73485-0; 2002; 232 pages.
