– сотрудничество с заказчиками ценится выше формальных договоров;
– реагирование на изменения ценится выше строгого следования плану.
При таком подходе технология занимает в процессе создания ПО вполне определенное место и повышает эффективность деятельности разработчиков при наличии следующих условий:
– технология позволяет людям легче выразить свои мысли;
– технология выполняет задачи, невыполнимые вручную;
– технология автоматизирует утомительные и подверженные ошибкам действия;
– технология облегчает общение между людьми.
Технология не должна действовать против характера культурных ценностей и познавательной способности человека.
Однако при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра – критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в ПО. Ее уровень может иметь одно из четырех значений:
– C – дефекты вызывают потерю удобства;
– D – дефекты вызывают потерю возместимых средств (материальных или финансовых);
– E – дефекты вызывают потерю невозместимых средств;
– L – дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участвующих в проекте:
– от 1 до 6 человек – малый масштаб;
– от 6 до 20 человек – средний масштаб;
– свыше 20 человек – большой масштаб.
По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью (C или D). Общие принципы оценки технологий в таких проектах заключаются в следующем:
– интерактивное общение лицом к лицу – это самый дешевый и быстрый способ обмена информацией;
– избыточная «тяжесть» технологии стоит дорого;
– более многочисленные команды требуют более «тяжелых» и формальных технологий;
– большая формальность подходит для проектов с большей критичностью;
– возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;
– дисциплина, умение и понимание противостоят процессу, формальности и документированию;
– потеря эффективности в некритических видах деятельности вполне допустима.
Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является «Экстремальное программирование» (Extreme Programming – XP). Этот метод предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, что достигается посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению, навыкам, дисциплине, пониманию.
Однако задача поиска повторяемого, предсказуемого процесса или методологии, которые бы улучшили продуктивность, качество и надёжность разработки до сих пор не решена. Одни подходы делают акцент на систематизации и формализации процессов. Другие ставят во главу угла методы управления проектами и методы программной инженерии. Третьи исходят из необходимости постоянного контроля со стороны заказчика.
При выборе методологии разработки программного обеспечения следует руководствоваться тем, что сложность методологии сравнима со сложностью структуры программного продукта, и неоправданная для продукта данной сложности сложность методологии только неоправданно увеличит стоимость разработки.
