Каталог статей
| Главная » Статьи » Мои статьи | [ Добавить статью ] |
Современные тенденции в программной инженерии (принципы "быстрой разработки ПО")
| В конце 60-х годов прошлого века в США было отмечено явление под названием "software crisis" (кризис ПО). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей. Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, результаты исследований, выполненных в 1995 году компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, выглядели следующим образом: • только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; • 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; • 31,1% проектов были аннулированы до завершения; • для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%. В 1998 году процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно). В последние годы процентное соотношение трех перечисленных категорий проектов также незначительно изменяется в лучшую сторону, однако, по оценкам ведущих аналитиков, это происходит в основном за счет снижения масштаба выполняемых проектов, а не за счет повышения управляемости и качества проектирования. В числе причин возможных неудач, по мнению разработчиков, фигурируют: • нечеткая и неполная формулировка требований к ПО; • недостаточное вовлечение пользователей в работу над проектом; • отсутствие необходимых ресурсов; • неудовлетворительное планирование и отсутствие грамотного управления проектом; • частое изменение требований и спецификаций; • новизна и несовершенство используемой технологии; • недостаточная поддержка со стороны высшего руководства; • недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта. Объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием "программная инженерия" (software engineering). В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволяет повысить его качество, обеспечить управляемость процесса проектирования ПО и увеличить срок его жизни. В то же время, попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания ПО, возлагаемых на новые методы и технологии, специалисты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области - неспособность эффективного управления проектами создания ПО. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме "тушения пожара". Бессистемное применение технологий создания ПО (ТС ПО), в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания ПО, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков). Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Постоянное повышение качества создаваемого ПО и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки ПО, так и в управлении проектами. В соответствии с моделью SEI СММ (Capability Maturity Model), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания ПО на протяжении всего жизненного цикла ПО и на уровне всей организации. Одна из причин распространенности "хаотического" процесса создания ПО - стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процесса создания ПО. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам (в частности, Gartner Group), более $100 тыс. и около трех лет на внедрение развитой ТС ПО, охватывающей большинство процессов жизненного цикла ПО, в многочисленной команде разработчиков (до 100 чел.). Причина - в "тяжести" технологических процессов. "Тяжелый" процесс обладает следующими особенностями: • необходимость документировать каждое действие разработчиков; • множество рабочих продуктов (в первую очередь - документов), создаваемых в бюрократической атмосфере; • отсутствие гибкости; • детерминированность (долгосрочное детальное планирование и предсказуемость всех видов деятельности, а также распределение человеческих ресурсов на длительный срок, охватывающий большую часть проекта. Альтернативой "тяжелому" процессу является адаптивный (гибкий) процесс, основанный на принципах "быстрой разработки ПО", интенсивно развиваемых в последнее десятилетие. В начале 2001 года века ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием "Быстрая разработка ПО" (Agile software development) [10] базируется на четырех идеях, сформулированных ими в документе "Манифест быстрой разработки ПО" (Agile Alliance's Manifesto) и заключающихся в следующем: • индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов; • работающее ПО ценится выше всеобъемлющей документации; • сотрудничество с заказчиками ценится выше формальных договоров; • реагирование на изменения ценится выше строгого следования плану. При таком подходе технология занимает в процессе создания ПО вполне определенное место. Она повышает эффективность деятельности разработчиков при наличии любых из следующих четырех условий: • когда она позволяет людям легче выразить свои мысли; • когда она выполняет задачи, невыполнимые вручную; • когда она автоматизирует утомительные и подверженные ошибкам действия.; • когда она облегчает общение между людьми; Технология не должна действовать против характера культурных ценностей и познавательной способности человека. При этом следует четко понимать: при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра - критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в ПО, ее уровень может иметь одно из четырех значений: • C - дефекты вызывают потерю удобства; • D - дефекты вызывают потерю возместимых средств (материальных или финансовых); • E - дефекты вызывают потерю невозместимых средств; • L - дефекты создают угрозу человеческой жизни. Масштаб определяется количеством разработчиков, участвующих в проекте: • от 1 до 6 человек - малый масштаб; • от 6 до 20 человек - средний масштаб; • свыше 20 человек - большой масштаб. По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью (C или D). Общие принципы оценки технологий в таких проектах заключаются в следующем: • интерактивное общение лицом к лицу - это самый дешевый и быстрый способ обмена информацией; • избыточная "тяжесть" технологии стоит дорого; • более многочисленные команды требуют более "тяжелых" и формальных технологий; • большая формальность подходит для проектов с большей критичностью; • возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах; • дисциплина, умение и понимание противостоят процессу, формальности и документированию; • потеря эффективности в некритических видах деятельности вполне допустима. Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является "Экстремальное программирование" (Extreme Programming - XP). Этот метод предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, и достигает этого посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты. | |
| Просмотров: 1868 | |
| Всего комментариев: 0 | |