Почему важно думать о качестве для программного обеспечения

Обновлено: 16.06.2024

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

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

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

На качество конечного продукта влияют все фазы и виды деятельности проекта, и от того, насколько хорошо и качественно мы работаем на каждой фазе проекта (а не только, например, на фазе тестирования), зависит, насколько качественным получится разрабатываемый продукт. Другими словами, качество процесса разработки определяет качество продукта [1, 2].

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

Дефекты можно классифицировать по следующим параметрам:

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

Управление качеством программного продукта

Можно нарисовать график изменения количества дефектов в проекте с течением времени. На рис. 1 приведен график для случая водопадной модели жизненного цикла проекта и традиционного подхода к качеству программного продукта, где основной упор делается на тщательное тестирование.

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

Эффективность поиска дефектов

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

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

Эффективность поиска дефектов можно рассматривать как для отдельных фаз, так и для всего жизненного цикла разработки. При этом эффективности отдельных фаз определяют эффективность для всего жизненного цикла. Каждую фазу поиска дефектов можно рассматривать как своего рода фильтр, который удерживает некую часть дефектов, а весь жизненный цикл— как систему фильтров [2]. Если на ранних этапах жизненного цикла стоят плохие фильтры, которые пропускают много дефектов, то эти дефекты накапливаются, и, чтобы их хорошо отфильтровать, в конце жизненного цикла (фаза тестирования) будет необходим очень хороший фильтр.

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

Комплексный подход к управлению качеством

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

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

Методы поиска и предотвращения дефектов

Известно немало методов поиска дефектов.

Ручной анализ, или обзор разрабатываемых артефактов. Персональные проверки (personal review) [2], формальные инспекции [2, 3], групповые обзоры (walkthrough), парное программирование [4], групповое проектирование и т.п.

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

Автоматизированное тестирование. Модульное или блочное тестирование (unit testing) [4, 5], функциональное (комплексное) тестирование, тестирование графического интерфейса пользователя, тестирование производительности, стресс-тестирование, использование утверждений (asserts) [6] и т.д.

Эффективная стратегия поиска дефектов состоит в применении комбинации нескольких методов, каждый из которых будет иметь свой собственный уровень эффективности, выраженный в процентах. Согласно данным [1], тестирование имеет сравнительно низкую эффективность поиска дефектов (30-40%), а для того, чтобы сделать ее высокой, необходимо увеличить стоимость процесса тестирования в разы (эффективность бета-тестирования при количестве тестировщиков более 1000 составляет около 75%).

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

Прототипирование. Создание и опробование модели разрабатываемой системы с целью проверить ее характеристики и выявить неверные предположения и решения, которые могли бы привести к серьезным дефектам (и переделкам) при разработке [6].

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

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

Предварительная разработка тест-кейсов (до этапа кодирования) позволяет глубже понять требования к разрабатываемой системе и лучше спроектировать ее. Частный случай этого подхода— Test-Driven Development, при котором модульные тесты разрабатываются не после, а до кодирования.

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

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

Итерационный жизненный цикл

Рассмотрим итерационный жизненный цикл, состоящий из пяти итераций, каждую из которых можно рассматривать как маленький, но полный водопадный жизненный цикл (рис. 5).

Предположим, эффективность поиска дефектов каждого из водопадных циклов составляет 50%, и на каждой итерации вносится одинаковое количество дефектов. Чему будет равна эффективность поиска дефектов итерационного цикла, состоящего из пяти последовательных итераций? После первой итерации эффективность будет равна 50%; после второй— 62,5%; после третьей— 70,8%; после четвертой— 76,6%; после пятой эффективность поиска дефектов всех пяти итераций будет равна 80,6%.

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

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

Цена качества

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

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

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

Процесс управления качеством

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

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

Литература

Humphrey, Watts S., A discipline for software engineering, ISBN 0-201-54610-8. Addison-Wesley Longman, 1995.

Humphrey, Watts S., Introduction to Team Software Process, ISBN 0-201-47719-X. Addison Wesley Longman, 2005.

Пример управления качеством ПО

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

Обязательные формальные инспекции всех артефактов (требования, архитектура, проектные модели, тест-планы, код).

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

Контроль качества процесса и проектов осуществляется регулярно с помощью следующих метрик.

Плотности дефектов на 1000 строк кода, найденных на разных стадиях, таких как инспекции кода, интеграционное, системное, релиз-тестирование.

Эффективность инспекций (плотность найденных замечаний, скорость проверки, процент найденных дефектов, покрытие кода инспекциями).

Процент переделок (размер кода для исправления дефектов по отношению к общему числу разработанного кода).

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

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

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

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

7.1. Подходы к качеству программного обеспечения

  • Первое измерение ориентировано либо на продукт, либо на процесс. Для повышения качества программного обеспечения можно сосредоточиться на качестве самого продукта, например, делая его более дружественным пользователю. Альтернативный подход заключается в совершенствовании процесса разработки, предполагая при этом, что чем лучше процесс, тем лучше качество программного обеспечения.
  • Второе измерение связано либо с соответствием, либо с усовершенствованием. Под соответствием будем понимать соответствие какому-либо стандарту. Усовершенствование имеет своей целью переход на более совершенные методы и лучшую практику для повышения качества.
  • ISO 9126 является стандартом на качество продукта, определяющим атрибуты и характеристики качества, включая измерения количественной оценки этих характеристик;
  • "усовершенствованием практики" например, является усовершенствование управления конфигурацией программного обеспечения, инспекций, тестирования и т. п.;
  • ISO 9000 [ISO 9000 1992] - это совокупность стандартов, декларирующих требования для качественных систем. С точки зрения разработки программного обеспечения наиболее полезны "Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения" [ISO 9001 1992];
  • методы усовершенствования процесса разработки программного обеспечения предлагают некоторую шкалу уровней и требования соответствия, согласно которым можно определить место компьютерной компании на этой шкале. Наиболее известны и популярны два метода:
    • модель зрелости процесса разработки программного обеспечения - Capability Maturity Model for Software (CMM), предложенная Software Engineering Institute (SEI);
    • определение возможностей и улучшение процесса создания программного обеспечения. ISO/IEC 15504 Software Process Improvement and Capability determination (SPICE).

    Таблица 3.2. Подходы к качеству

    Объект качества Соответствие Усовершенствование
    Продукт ISO 9126 "Усовершенствование практики"
    Процесс ISO 9000, процесс обеспечения качества CMM, SPICE, .

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

    Подходы к достижению качества таковы:

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

    7.2. Характеристики качества программного обеспечения

    В настоящее время не существует общепринятых критериев качества программного обеспечения.
    Стандарт ISO 9000-3, п. 6.4.1

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

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

    Две наиболее интересные характеристики рассмотрим подробнее.

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

    • предупреждение ошибок;
    • самообнаружение ошибок;
    • самоисправление ошибок;
    • обеспечение устойчивости к ошибкам.
    • Количественные критерии, связанные с различными способами оценки (метриками) сложности программ. Укажем примеры численных характеристик. *
      • Меры Холстеда [Холстед 1981], включающие ряд формул, оценивающих длину, объем, уровень и интеллектуальное содержание программ.
      • Оценка сложности управляющего графа программы. Фрагмент программы может быть оценен цикломатическим числом ее управляющего графа, которое равно m - n + 2, где m - число дуг, an - число вершин управляющего графа. Считается, что цикломатическое число не должно превышать 10.
      • Оценка модульного разбиения программы. Такая оценка должна состоять из множества критериев. Например, сложность модуля оценивается совокупностью сложности определяемых в нем процедур и сложности связей модуля с другими модулями по импорту и экспорту определяемых сущностей.

      7.3. Оценка качества процесса разработки

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

      • Оценить качество конечного продукта.
      • Оценить качество процесса разработки.

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

      7.3.1. Модель зрелости процесса разработки программного обеспечения

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

      7.3.2. Определение возможностей и улучшение процесса создания программного обеспечения

      • Уровень 0. Процесс не выполняется.
      • Уровень 1. Выполняемый процесс.
      • Уровень 2. Управляемый процесс.
      • Уровень 3. Установленный процесс.
      • Уровень 4. Предсказуемый процесс.
      • Уровень 5. Оптимизирующий процесс.
      • Сравнение процесса разработки программного обеспечения, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов дает возможность определить сильные и слабые стороны процесса, его внутренние риски.
      • Оценка возможности улучшения данного процесса на основе определения текущих возможностей.
      • Техническая реализация поставленных задач на основе сформулированных целей совершенствования процесса. После этого весь цикл работ начинается сначала.

      7.4. "Достаточно хорошее" программное обеспечение

      Вчера в Сиэтле после упоминания Биллом Гейтсом о выходе бета-версии
      новой программы компании Microsoft произошло землетрясение.
      Пользователи с ужасом ждут объявления о выходе финальной версии продукта.
      Анекдот по мотивам землетрясения и выступления Б. Гейтса 23-го февраля 2001 г.

      Пропагандистом "достаточно хорошего" программного обеспечения является Эдвард Йордон [Йордон 2001]. Подчеркнем, что он применяет это понятие к "безнадежным проектам", которые связаны жесткими ограничениями на время, бюджет и людские ресурсы (см. разд. 1.6). В большинстве безнадежных проектов заказчик может быть удовлетворен системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро. Фактически, эти характеристики можно считать определением "достаточно хорошего" программного обеспечения.

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

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

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

      7.5. Стандартизация информационных технологий

      Стандарт - общепринятое определение компонента технических или программных средств, являющихся результатом соглашения. Профиль - набор юридических и/или фактических стандартов, ориентированных на выполнение конкретной задачи [Козлов 1999].

      • по типу установления требований:
        • устанавливающие требования к объекту;
        • устанавливающие требования к процессу;
        • международные;
        • государственные;
        • отраслевые;
        • предприятий;
        • принятые юридически;
        • действующие фактически.
        • Международные организации, входящие в структуру ООН.
          • International Organization for Standardization (ISO) - международная организация по стандартизации.
          • International Electrotechnical Commision (IEC) - международная электротехническая комиссия.
          • International Telecommunication Union-Telecommunications (ITU-T) - международный союз по телекоммуникации - телекоммуникация. До 1993 года эта организация называлась International Telegraph and Telephone Consultative Committee - международный консультативный комитет по телефонии и телеграфии.
          • Institute of Electrical and Electronic Engineers (IEEE) - институт инженеров по электротехнике и электронике.
          • Internet Activity Board (IAB) - совет управления деятельностью Интернета.
          • Object Management Group (OMG) - группа управления объектами.
          • Х/Open - консорциум, организованный группой поставщиков компьютерной техники.
          • Open Software Foundation (OSF) - фонд открытого программного обеспечения.

          В 1987 году ISO и IEC объединили свою деятельность в области стандартизации информационных технологий и создали единый орган - Joint Technical Committee 1 (JTC1) - объединенный технический комитет 1. Этот комитет предназначен для формирования системы базовых стандартов з области информационных технологий. Об абсолютной стандартизации
          Идеальный подход мог бы состоять в разработке исчерпывающего набора стандартов. Однако для некоторых современных направлений в области информационных технологий это нереально, учитывая скорость (а также стоимость) происходящих изменений. Ко времени внесений очередной порции изменений может появиться новая версия, или программистское сообщество может вообще начать двигаться в другом направлении. Абсолютная стандартизация - это мираж.

          Лекция 1. Цели и задачи курса. Понятие программной инженерии. Список литературы

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

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


          • обоснование и широкое внедрение нисходящей разработки и структурного программирования,

          • развитие абстрактных типов данных и модульного программирования,

          • исследование проблем обеспечения надежности и мобильности программных средств (ПС),

          • создание методики управления коллективной разработкой ПС,

          • появление инструментальных систем поддержки программирования (программных инструментов).

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

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

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

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

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

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


          Программа
          (Завершенный продукт, пригодный для запуска своим автором на системе, на которой она была разработана)

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

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

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

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

          Ну и, наконец, последняя горесть – продукт, на который было положено столько труда, оказывается устаревшим в момент своего завершения (или даже раньше). Коллеги и конкуренты уже работают над новыми идеями.

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

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

          Программная инженерия (Software Engineering) является отраслью компьютерной науки 4 (Computer science) и изучает вопросы построения компьютерных программ, обобщает опыт программирования в виде комплекса общих знаний и правил регламентации инженерной деятельности разработчиков программного обеспечения.

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

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


            • менеджеры, которые планируют и управляют проектом, отслеживают сроки и затраты;

            • технологи, которые определяют инженерные методы и стандарты, регламентирующие и регулирующие процесс разработки программных средств и систем;

            • тестировщики, которые проверяют правильность выполнения процессов, сбор данных при тестировании и оценку качества компонентов и системы в целом;

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

            • и др.

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

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

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

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

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

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

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

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

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


            Почему это важно

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

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

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

            Отличия тестирования и обеспечения качества


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

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

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

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

              Что делает QA-специалист:

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

                Что могут сделать тестировщики для улучшения качества продукта

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


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

                Например, если есть жалобы на пропускаемые дефекты, то мы начинаем их фиксировать для анализа причин пропуска. Допустим, после пары итераций станет понятно, что причина в недостаточном покрытии функционала тестами. Отлично! Начинаем фиксировать процент покрытия. Ага, у нас недостаточно тестов. Почему? Да потому, что сроки на подготовку и тестирование слишком сжатые, и мы не успеваем писать тесты в требуемом для полного покрытия объеме. Оценка сроков адекватная, только вот передача версии в тестирование происходит позже запланированной даты, а сроки релиза отодвигать нельзя. В чем проблема? Разработчики не успевают – их оценка на разработку всегда оказывается на 2-3 дня меньше фактического времени на реализацию. Почему? Допустим, менеджер подбрасывает незапланированные задачи в середине итерации. Зачем? Заказчик требует – он не видит разницы между разработкой сайта-каталога и сайта-магазина.

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

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

                Влияние процесса тестирования на качество ПО


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

                Читайте также: