Стоимость качества в разработке программного обеспечения



    1. Что такое качество в разработке ПО?
    2. Во сколько нам обходится некачественное ПО?
    3. Кто отвечает за качество?

    Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

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

    Что такое качество в разработке ПО?


    На вопрос что такое качество в разработке ПО можно ответить с разных точек зрения. Свои ответы буду формулировать с точки зрения Пользователя-Заказчика и Руководителя компании.

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

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

    Средний уровень качества — всё что выше + отсутствие ошибок, которые существенно влияют на опыт использования ПО (Обязательные к устранению), при этом присутствуют ошибки, которые никак не влияют на решение бизнес-задачи: орфография, разные шрифты там где должен быть один и т.д. (Желательные к устранению).

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

    Во сколько обходится нам некачественное ПО?


    Часть 1: Подтверждение Дефекта


    Когда Пользователь находит дефект он обращается к инженеру службы поддержки. Инженер СП пытается его воспроизвести и подтвердить что это дефект производства. Здесь возникают первые затраты из которых начинается складываться стоимость качества:
    • Затраты времени Пользователя — 1 ед.
    • Затраты времени Инженера СП — 1 ед.

    Если ошибка системная, то всё очевидно, а если она связана с работой функционала по определенной логике?

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

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

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

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

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

    Если им повезло найти ответ на свой вопрос, то всё заканчивается следующими затратами:
    • Владельца Продукта — 1 ед.
    • Инженер-Разработчик — 1 ед.
    • Заказчик — 1 ед.
    • Затраты времени Инженера СП — 1 ед.

    Если не повезло, то их ожидает торг по поводу того считать ли это дефектом, который будет устраняться за собственный счёт, или новым требованием, которое будет оплачивать Заказчик. Допустим, что сторговаться не удалось, Заказчик продавил, считаем это дефектом и устраняем за собственный счёт.
    • Ухудшение репутации — 1 ед. (за счёт того, что Дефект и что пришлось привлечь Заказчика к расследованию)
    • Пока затраты на устранение дефекта здесь не учитываю, так как они добавятся чуть позже.

     Промежуточный итог:
    1. Затраты времени Пользователя — 1 ед.
    2. Затраты времени Инженера СП — 2 ед.
    3. Затраты времени Владельца Продукта — 1 ед.
    4. Затраты времени Инженера-Разработчика — 1 ед.
    5. Затраты времени Заказчика — 1 ед.
    6. Ухудшение репутации — 1 ед.
    Стоимость качества — 7 единиц

    Можно оптимизировать затраты в этой части заранее потратившись на подготовку пользовательской документации Тех.Писателем-Аналитиком, тогда это будет выглядеть вот так:
    1. Затраты времени Пользователя — 1 ед.
    2. Затраты времени Инженера СП — 1 ед.
    3. Затраты времени Тех.Писателя-Аналитика — 1 ед.
    4. Ухудшение репутации — 0,5 ед. (Потому что Дефект)
    Стоимость качества — 3,5 единицы

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

    Часть №2: Устранение Дефектов


    Каждая «Блокирующая ошибка» порождает выпуск отдельного устраняющего патча-обновления. Это обновление проходит через стандартные процедуры тестирования, дабы не породить новых ошибок. Передаётся Инженеру СП для распространения среди Клиентов, которые пользуются версией ПО, в которой была найдена эта ошибка, и закрытия «тикета» дефекта. Затраты:
    • Инженер-Разработчик — 1 ед.
    • Инженер-Тестировщик — 1 ед.
    • Инженер СП — 1 ед.

    «Обязательная к устранению ошибка» устраняется в следующим плановом релизе (версии), поэтому затраты на устранение ниже, так как затраты на сборку релиза и регрессионное тестирование ложатся на новые функции и не попадают в стоимость устранения ошибки. Дополнительных затрат на работу Инженера СП также нет кроме закрытия «тикета». Затраты:
    • Инженер-Разработчик — 0,5 ед.
    • Инженер-Тестировщик — 0,5 ед.

    Затраты в обоих случаях оплачиваются из прибыли компании.
    Стоимость качества — 4 единицы.

    Часть №3: Недопущение Дефектов (Качество основанное на контроле)


    Чтобы Пользователи не находили Дефекты для этого есть собственные Инженеры по тестированию. Для них критерий эффективности 100% ошибок — 0% дефектов.

    Информация о найденном дефекте передается Инженеру по тестированию для анализа причин пропуска дефекта при тестировании и внесения изменений в методики и инструменты тестирования. Затраты:
    • Инженера-Тестировщик — 1 ед.

    Эффективная работа здесь сводит на нет следующие затраты времени
    Части 1:
    1. Пользователя — 1 ед.
    2. Инженера СП — 1 ед.
    3. Ухудшение репутации — 0,5 ед.
    Части 2:
    1. Инженер-Разработчика — 1,5 ед.
    2. Инженер-Тестировщика — 1,5 ед.
    3. Инженер СП — 1 ед.
    Стоимость — 6,5 ед. Вложения — 1 ед. Экономия — 5,5 единиц.

    Часть №4: Устранение Ошибок


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

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

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

    Затраты здесь:
    1. Ухудшение репутации — 1 ед.
    2. Инженер-Разработчик — 1 ед.
    3. Инженер-Тестировщик — 1 ед.
    4. Потерянный доход — 2 ед. (п.2 + п.3)
    Стоимость качества — 5 единиц.  

    Часть №5: Недопущение Ошибок (Качество основанное на развитии производственного процесса)


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

    Допущенные ошибки передаются на анализ Руководителю Разработки (Тим-Лиду) для выявления причин, сотрудников, которые их чаще допускают, и чаще «болеющих» продуктов. Эта работа выливается в ряд мероприятий по код-ревью, дополнительному обучению Инженеров-Разработчиков по темам где недостаёт квалификации и т.д.
    • Затраты Руководителя-Разработки — 1 ед.
    • Затраты Инженера-Разработчика — 1 ед.

    Эффективная работа здесь сводит на нет следующие затраты Части 4:
    1. Инженер-Разработчик — 1 ед.
    2. Инженер-Тестировщик — 1 ед.
    3. Потерянный доход — 2 ед.
    4. Ухудшение репутации — 1 ед.
    Стоимость — 5 ед. Вложения — 2 ед. Экономия — 3 единицы.

    Общий расчёт стоимости качества


    Обычно ситуация выглядит так: Мы ведем разработку, допускаем ошибки, порой их устранение требует более двух итераций и несмотря на эту работу Пользователи всё равно находят дефекты в ПО, которые нам приходится исправлять путем выпуска дополнительных обновлений.
    Вид затрат Часть 1 Часть 2 Часть 4 Итого
    Затраты времени Пользователя 1 - - 1
    Затраты времени Инженера СП 2 1 - 3
    Затраты времени Владельца Продукта 1 - - 1
    Затраты времени Инженера-Разработчика 1 1,5 1 3,5
    Затраты времени Заказчика 1 - - 1
    Затраты времени Инженера-Тестировщика - 1,5 1 2,5
    Ухудшение репутации 1 - 1 2
    Потерянный доход - - 2 2
    Итого 7 4 5 16
    Если будем готовить документацию по факту выполненной разработки, вложив 1 единицу ресурса Технического Писателя, то это сэкономит 3,5 единицы и стоимость качества снизится с 16 до 12,5. (Структура затрат: Документирование + Подтверждение Дефекта + Устранение Дефекта + Устранение Ошибок)

    Обеспечив недопущение дефектов, вложив в это дополнительные затраты времени Инженера-Тестировщика в размере 1 единицы, стоимость качества снизится с 12,5 до 7 единиц. (Структура затрат: Документирование + Недопущение Дефектов + Устранение Ошибок)

    Недопущение ошибок потребует вложения 2 единиц, по одной от Инженера-Разработчика и Руководителя-Разработки, и снизит стоимость качества с 7 до 4 единиц. (Структура затрат: Документирование + Недопущение Дефектов + Недопущение ошибок)

    Если вложимся в то, что Технический Писатель — Аналитик начнёт писать пользовательскую документацию про то как система должна решать бизнес-задачу Пользователя ещё до разработки, то, возможно, не придется:
    1. Не только спорить с Заказчиком дефект это или нет, но и вообще общаться с ним по поводу дефектов.
    2. Анализировать причины по которым ошибки в выполнении целевых задач ПО проскочили к Пользователям через этап Тестирования.
    3. Анализировать причины по которым Разработчик сделал так, что программа работает не так как должна и отдал это в Тестирование.
    4. Тратится на дополнительные мероприятия по недопущению ошибок и дефектов, когда проектная документация отсутствует и нужно что-то придумывать чтобы компенсировать её отсутствие.
    И на это нужна всего 1 единица затрат. (Качество основанное на развитии процесса проектирования продукта)



    Кто отвечает за качество?


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

    У нас Software Quality Assurance (Обеспечение качества ПО) утрировано до восприятия как Тестирование, а Quality Assurance Engineer до Инженер-Тестировщик. Но Инженер-Тестировщик максимум что может сделать это найти все ошибки и вернуть их Software Engineer (Инженеру-Разработчику), но он никак не влияет на их появление.

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

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

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

    Есть ещё Product Owner (Владелец Продукта), который как владелец подходит на роль Отвечающего за Качество Продукта. По этой причине их порой делят на две позиции Marketing Product Manager (Менеджер по продукту) и Software Delivery Manager (Менеджер по выпуску ПО). Первый отвечает за развитие продукта с точки зрения рынка (работа с Заказчиками и требованиями), а второй за развитие производственного процесса выпуска продукта.

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

    Поделить ответственность по этапам Software Development Life Cycle (Жизненного цикла разработки ПО) не получается. Как только это деление начинается, неэффективная работа по середине сразу делает бессмысленной работу сделанную в начале и нагружает дополнительной работой как тех кто стоит в конце, так и всю производственную цепочку заводя на её вход ошибку для устранения.

    Заключение


    Это классический подход к работе с качеством из промышленности, который основан на трёх методах:
    1. Качество через проверку готового продукта (тестирование: отлавливание ошибок и дефектов)
    2. Качество через развитие производственного процесса (предотвращение ошибок в ходе производства)
    3. Качество через развитие процесса проектирования продукта (предотвращение ошибок закладываемых в скелет-основу продукта при проектировании)
    И основным посылом: необходимо больше внимания уделять работе с причинами, а не работе с последствиями.

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

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

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

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

    Что с этим делать? — мне нравятся ответы данные в статье «Будущее гибкой разработки».

    Что ещё почитать по теме:


    1. Будущее гибкой разработки
    2. Что такое качество программного обеспечения?
    3. Управление качеством проекта
    4. Карьера в IT: должность QA engineer
    5. Гуру менеджмента качества и их концепции: Э.Деминг, Дж.Джуран, Ф.Кросби, К.Исикава, А.Фейгенбаум, Т.Тагути


    Уделите пару минут ответу на три вопроса, так вы поможете провести диагностику средней температуры отношения и внимания к качеству ПО в ИТ-отрасли нашей страны на 1 августа 2017 года. +1 вам в карму за это доброе дело.

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

    Кто отвечает в вашей компании за качество?

    • 10.8%Инженер QA18
    • 3.6%Инженер по тестированию6
    • 8.4%Инженер по разработке14
    • 9%Руководитель команды разработки15
    • 4.8%Владелец продукта8
    • 2.4%Директор ИТ4
    • 19.8%Вся команда33
    • 1.8%Другая выделенная роль3
    • 39.1%Никто65

    Какой стратегии (ям) по обеспечению качества следует ваша компания?

    • 76.6%Качество через проверку готового продукта95
    • 25%Качество через развитие производственного процесса31
    • 23.3%Качество через развитие процесса проектирования продукта29
    • 16.9%Другая / Другое21

    Как много ошибок приходится устранять в новом релизе?

    • 23.1%Не делим ошибки и доработки существующих функций31
    • 24.6%В среднем не более 3-х (софт высокого качества)33
    • 52.2%Более 3-х70
    Поделиться публикацией

    Похожие публикации

    Комментарии 25

      +2
      а где самый популярный ответ «никто» в первом пункте опроса?
        +1
        Готово. Можете воспользоваться.
        +2
        То есть, вы утверждаете, что баг, пропущенный при разработке по водопаду, после релиза, гораздо дешевле бага, который нашли во время тестирования? Вам не кажется, что эта статья клином сошлась на команде, которая пишет ПО 9 месяцев, а фиксит баги — 3?
          0
          То есть, вы утверждаете, что баг, пропущенный при разработке по водопаду, после релиза, гораздо дешевле бага, который нашли во время тестирования?


          Не утверждаю, а можете на материале статьи пояснить как у вас сформировался этот вывод?! Свою логику.

          «Водопад» предполагает и включает в себя этап «тестирования». Поэтому когда вы сравниваете ошибку сделанную в разработке ПО по «водопадной» модели, с «нашли во время тестирования» не понимаю о чем вы.

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

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

          Вот статья которая это иллюстрирует — Пьеса «Технический долг».
          Как это лечить описано в статье «будущее гибкой разработки».

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

            image

            То есть поддержка системы после релиза занимает в разы больше ресурсов

            Спасибо за развернутый ответ

            Опять же, если релиз версии происходит каждый спринт, технический долг активно копится, но есть варианты решения этой проблемы. Навскидку:
            1. Технический спринт — трудно продавить через заказчика, но технический долг уменьшается. Пример — мобильное приложение Альфа-банка — несколько раз видел релизы «Исправлены баги», и никаких новых фич.
            2. Если размер команды позволяет — часть членов команды занимаются фиксом технического долга, каждый спринт, люди могут меняться, но позволяет контролировать его размер

            Да и водопад нужен для проектов с конечной целью — построить мост, сделать ПО для спутника, которое невозможно обновить, и тп
          +1
          Да заказчикам нужно быстро и дешево, о каком качестве может идти речь)
            +1
            Оно подразумевается) Мы же профессионалы.

              0
              Да заказчикам нужно быстро и дешево, о каком качестве может идти речь)

              Видите ли, конечно быстро и дешево. Ведь это такие понятные слова. А если сайт будет подтормаживать, иметь дыры в безопасности, будет сложно добавить новые фичи, а старые будут работать некорректно — это уже вопрос не к менеджерам, а к низкой квалификации разработчиков.
                +2
                Это и имел ввиду под «Мы же профессионалы».

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

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

                «Чтобы мы были теми переменами которых ищем».
                  0
                  А кто набрал на проект таких разработчиков, которые не в состоянии справиться с поставленными задачами, не менеджеры-ли?

                  Кстати, в статье этот момент хорошо описан. В самом деле «накосячить» можно в любой момент. Причем если говорить о квалификации, то она влияет лишь на вероятность появления дефектов, но не на их принципиальную невозможность. Собственно из это и появляется вся эта история с задачами контроля качества и вовлечением в процесс персонала разного уровня. Отсюда и возникает мысль, что качество это командная responsibility, начиная от первых контактов с заказчиком и до закрытия проекта.
                    0
                    Ну вы что? Менеджеры (особенно топ) всегда все делают правильно.
                    А вообще да, разработчики, которые соглашаются на «дешево, быстро и некачественно» — сами виноваты в таком к ним отношении.
                +2

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

                  +2
                  но в статье всё настолько идеализировано и упрощено

                  Это даётся не просто, через постоянные тренировки.

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

                  И начинать стоит с простого и прагматичного. Затем посмотреть на историях гуру менеджмента качества как эволюционировали идеи про качество и уже отсюда двигаться в ITIL, COBIT, CMMI, SWEBOK и серию ISO.

                  Внедрять информационные системы типа Atlassian JIRA, чтобы построить учет ошибок и дефектов в разрезе версий выпущенного ПО, планировать их устранения по будущим версиям, автоматически собирать данные о затратах на их устранение, типизировать, по правилу «20 на 80» устранять самые тяжелые.

                  Осваивать технологии Test Driven Development, Behavior Driven Development, Continuos Integration, Интерактивного прототипирования без разработки.

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

                  В итоге все выглядят как папуасы на острове, увешанные бусами и всякими другими модными штуками, где микроскопом колют кокосы.
                  +1
                  Вообще, в ISO 9000 описаны небесполезные вещи для понимания управления качеством. Удивлён, что в опросе нет даже варианта управления качеством по ISO 9000 (через службу качества).
                    0
                    Ну почему не написано? Идеологий ISO 9000 построена на контроле качества через контроль производственного процесса. Так что пункт 2 в первом опросе как раз о том, о чем вы говорите.
                      0

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

                        0
                        Ну программное обеспечение такой же продукт, как любой другой. Так что данный стандарт распространяется и на процесс создания программного обеспечения в полной мере.
                          +1
                          Разумеется. Я просто уточнил, что программирование — это не производственный процесс, а процесс разработки.
                    +2
                    Есть мнение что в it-индустрии отсутствие контроля качества (хм, или отсутствие самого качества) является одним из способов (или причин) создания дополнительных рабочих мест. Это «грустно» и «весело» одновременно.
                      +1

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

                        +1
                        Жаль что многие пользователи и заказчики хотят получить качество не платя за это ни чего. Больше всего проблем возникает со всякого рода кастомизацией, допиливанием. Проектные проработки и документирование обходятся дороже, чем написание кода «на живую, по месту».
                          +2
                          В общем расчёте не раскрыта цена времени у разных участников процесса.
                            0
                            Это как раз не проблема коэффициентики прикрутить. Правда, результаты могут не такие гладкие получиться, если время тестировщика стоит условно 2 ед, а время планктона заказчика с точки зрения исполнителя стоит внезапно 0 =)
                            Хуже, что не учтено другое: затраты этого времени есть штука вероятностная; какой-то баг фиксится за 15 минут, а какой-то может и на пару недель потянуть, если скрывает существенный рефакторинг (например, если баг не устраним без смены нижележащей либы).
                              0
                              Вот и дефекты. Максим, когда ждать исправленную версию статьи?)
                                +1
                                Хуже, что не учтено другое: затраты этого времени есть штука вероятностная; какой-то баг фиксится за 15 минут, а какой-то может и на пару недель потянуть, если скрывает существенный рефакторинг (например, если баг не устраним без смены нижележащей либы).

                                ИМХО затраты времени на каждом этапе разработки тем более предсказуемы, чем ближе продукт к финальной стадии. На самом деле, если какой-то баг найден в момент, когда продукт уже зарелизен, то основное время потратится не на его фикс программистом, а на бюрократию — принять баг от пользователя службой поддержки, воспроизведение, документирование и передача разработчикам, фикс(15минут- неделя), пререлиз, тестирование всего продукта по новой, релиз.
                                Также следует учесть, что такие серьезные баги, как смена либы, должны отсеиваться и фикситься на ранних стадиях разработки, а не в конце. Что опять же ведет к тому, что затраты времени на фикс одного бага ближе к концу проекта составляют примерно константу.

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

                            Самое читаемое