Читайте также:
|
В конце 60-х годов прошлого века в США было отмечено явление под названием «software crisis» (кризис ПО). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.
Аналитические исследования и обзоры, выполняемые в последние годы ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Например, результаты исследований, выполненных в 1995 г. компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, выглядели следующим образом:
• только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;
• 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;
• 31,1% проектов были аннулированы до завершения;
• для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.
Интересное исследование было проведено компанией HP и исследовательским подразделением HP and the Economist Intelligence Unit (ЕIU). Они выяснили, сколько IT-проектов завершается в срок в разных странах. Согласно результатам исследования, Россия находится на последнем месте:
Швеция—44% проектов были завершены точно в срок за последние 3 года,
Швейцария — 24%,
Чехия — 20%,
Германия — 19%,
Дания — 16%,
Великобритания — 11%,
Израиль — 8%,
Финляндия — 8%,
Франция — 6%,
Бельгия — 4%,
Испания — 4%,
Италия — 4%,
Нидерланды — 4%,
Россия — 4%.
Справедливости ради стоит отметить, что на самом последнем месте Россия стоит только потому, что имеющие одинаково плохой результат страны отсортированы по алфавиту, хотя лучше от этого все равно не становится. В поддержку отечественных программистов можно сказать, причины столь низкого процента завершенных вовремя проектов кроются, скорее, не в их плохой работе, а в задержках аутсорсеров, в смене приоритетов в процессе разработки проекта и в слабой координации между менеджерами.*
___________________
* Хакер, сентябрь 2007год.
В 1998 г. процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).
В последние годы процентное соотношение трех перечисленных категорий проектов также незначительно меняется в лучшую сторону, однако, по оценкам ведущих аналитиков, это происходит в основном за счет снижения масштаба выполняемых проектов, а не за счет повышения управляемости и качества проектирования.
• В последнее время ведущие зарубежные аналитики отмечают как одну из причин многих неудач тот факт, что множество проектов выполняется в экстремальных условиях. В англоязычной литературе с легкой руки Эдварда Йордона1, одного из ведущих мировых специалистов в области ПО, утвердилось название «death march», буквально — «смертельный марш». Под ним понимается такой проект, параметры которого отклоняются от нормальных значений, по крайней мере, на 50%.
Однако основная причина всех проблем заключается в ответе на вопрос: является ли проектирование ПО ремеслом, инженерной дисциплиной или чем-то средним? Многие разработчики ПО, вероятно, заявят, что программирование хотя и не сложилось в установившуюся инженерную дисциплину, но уже близко подошло к этому.
Однако можно утверждать, что разработка ПО на сегодняшний день является почти чистым ремеслом. Все знание о способах разработки ПО основано исключительно на пробах и ошибках. Конечно, со времени зарождения программирования сообщество программистов добилось некоторых успехов. Признанные корифеи программирования изобрели в помощь разработчикам ПО успешные методы и правила. Но, подобно средневековым архитекторам, разработчики ПО изучили и испытали эти методы путем проб и ошибок. Современным разработчикам не хватает системы основных принципов, на основе которых можно было бы строить свои правила и методы. Замечено, что ключевым фактором успеха проекта является хорошая архитектура.
Метод проб и ошибок завел достаточно далеко. Но рост сложности современных программных систем подводит нас к жесткому пределу. За пределами определенного уровня сложности создание качественных архитектур методом проб и ошибок становится невозможным.
Объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия» {software engineering). Впервые термин software engineering был использован как тема исторической конференции Научного комитета NATO в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии, тогда же появилось первое издание, посвященное программной инженерии, — IEEE Transactions on Software Engineering. Программная инженерия определяется, с одной стороны, как совокупность инженерных методов и средств создания ПО а, с другой стороны, как дисциплина, изучающая применение строгого систематического количественного (т.е. инженерного) подхода к разработке, эксплуатации и сопровождению ПО.
В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволяет повысить его качество, обеспечить управляемость процесса проектирования ПО и увеличить срок его жизни.
Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме «тушения пожара». Бессистемное применение технологий создания ПО, в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания ПО, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков).
Постоянное повышение качества создаваемого ПО и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки ПО, так и в управлении проектами. В соответствии с моделью СММ (Capability Maturity Model) Института программной инженерии (Software Engineering Institute, SEI), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания ПО на протяжении всего жизненного цикла ПО и на уровне всей организации. Процессы выстраиваются таким образом, чтобы обеспечить реальные сроки создания ПО.
При решении проблемы повышения эффективности создания ПО основное внимание уделяется, как правило, процессу разработки ПО, что вызвано естественным желанием разработчиков и заказчиков экономить средства с самого начала проекта (особенно в условиях ограниченных финансовых возможностей и высокой конкуренции). Так, по оценкам компании Hewlett-Packard, в 1994 г. от 60% до 80% ее разработчиков были заняты сопровождением ПО, а в отчетах федеральных служб США ранее отмечалось, что на сопровождение уходит от 50% до 80% рабочего времени программистов. Перечисленные тенденции отражены на рис. В.З.
|
|
|
Рис. В.З. Тенденции изменения соотношения стоимости аппаратуры и ПО
Первоначально, в 1960 - 1970 гг., в понятие сопровождения ПО входило только исправление ошибок и устранение мелких замечаний пользователей. Технология сопровождения представлялась достаточно простой и сравнительно слабо влияла на методы и средства разработки ПО. При сопровождении подвергались изменениям одна — две версии ПО, и задача состояла в обеспечении и улучшении качества одной основной версии. В настоящее время сопровождение превратилось в весьма трудоемкий процесс модификации и развития множества версий крупномасштабного ПО и его компонентов, значительно различающихся функциями и качеством.
Для того чтобы проиллюстрировать насколько «тяжелыми» могут быть формальные процессы, эксперт в области использования метрик Каперс Джонс подсчитал, что процесс разработки ПО по стандарту DOD-2167A Министерства обороны США требует 400 слов в документации на английском языке для каждой строки исходного кода. Так, если создается среднее приложение размером 50 000 строк исходного кода, потребуется наличие армии технических специалистов для создания 20 миллионов слов документации с описанием того, что делает код, как он функционирует и почему это происходит именно так.
Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки ПО», интенсивно развиваемых в последнее десятилетие.
3. Современные тенденции в программной инженерии (принципы «быстрой разработки ПО»)
В начале 2001 г. ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайс-мит, Кент Бек и др.) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки ПО» (Agile Alliance's Manifesto) и заключающихся в следующем2:
· индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;
· работающее ПО ценится выше всеобъемлющей документации;
· сотрудничество с заказчиками ценится выше формальных договоров;
· реагирование на изменения ценится выше строгого следования плану.
Центральными для быстрой разработки ПО являются простые, но достаточные правила выполнения проекта, а также ориентация на людей и коммуникацию.
Быстрота предполагает маневренность, характеристику, которая в настоящее время становится более важной, чем когда-либо. Распространение ПО в Интернете еще больше усилило конкуренцию между программными продуктами. Нужно не только выпускать программы на рынок и сокращать число дефектов в них, но и постоянно следить за изменяющимися требованиями пользователей и рынка.
При таком подходе технология занимает в процессе создания ПО вполне определенное место. Она повышает эффективность деятельности разработчиков при наличии любых из следующих четырех условий:
• когда она позволяет людям легче выразить свои мысли. Языки высокого уровня дают возможность более сжато выражать идеи. Некоторые языки высокого уровня позволяют человеку мыслить в технологическом пространстве, приближенном к проблемному пространству, позволяя почти не отвлекаться на мысли об ограничениях реализации;
• когда она выполняет задачи, невыполнимые вручную. Инструменты измерения и анализа собирают данные, которые иначе собрать было бы невозможно. Программисты говорят о них, как об основных инструментах;
• когда она автоматизирует утомительные и подверженные ошибкам действия. Компиляторы, электронные таблицы и средства управления конфигурацией ПО настолько важны, что некоторые программисты даже не упоминают о них как об инструментах, а просто предполагают их присутствие;
• когда она облегчает общение между людьми. В среде распределенной разработки ПО все виды инструментов обмена информацией помогают команде работать.
Технология не должна действовать против характера культурных ценностей и познавательной способности человека.
По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью (С или D). Общие принципы оценки технологий в таких проектах заключаются в следующем:
• интерактивное общение лицом к лицу — это самый дешевый и быстрый способ обмена информацией;
• избыточная «тяжесть» технологии стоит дорого;
• более многочисленные команды требуют более «тяжелых» и формальных технологий;
• большая формальность подходит для проектов с большей критичностью;
• возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;
• дисциплина, умение и понимание противостоят процессу, формальности и документированию;
• потеря эффективности в некритических видах деятельности вполне допустима.
Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является «Экстремальное программирование» (Extreme Programming — ХР[2]). Далее приведено краткое изложение этого метода.
В команде работает от трех до десяти программистов. Один или несколько заказчиков должны быть на месте и обеспечивать текущую экспертизу. Все работают в одной комнате или в смежных комнатах, желательно вокруг установленных вместе компьютеров, которых вдвое меньше числа программистов, с мониторами, повернутыми наружу из круга.
Одно из несомненных достоинств ХР заключается в обратной связи, которая возникает достаточно быстро. Заказчики получают ее в отношении последствий реализации их требований, представленных в ходе сеанса планирования. Через несколько дней они видят работающий код и могут соответственно скорректировать свои представления о том, что в действительности следует программировать. Изменяя проект, программисты получают быструю обратную связь благодаря модульному и приемочному тестированию. Они получают реакцию на процесс разработки каждые несколько недель, благодаря итерационным циклам.
ХР использует общение - сильную сторону людей. Парная работа и быстрая ответная реакция компенсирует склонность людей к совершению ошибок.
ХР — метод с высокой дисциплиной. Он требует приверженности строгому кодированию и стандартам проектирования, многочисленным комплектам модульных тестов, которые должны регулярно выполняться, качественному приемочному тестированию, постоянной работе в парах, бдительности при поддержании простоты проектных решений и постоянной реорганизации.
В своем определении ХР включает набор приемов и методик, которые команде нужно освоить: игру планирования, ежедневное оперативное совещание, реорганизацию и опережающую разработку тестов.
ХР предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности. Метод достигает этого посредством насыщенной, неформальной коммуникации, приданием на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты.
Дата добавления: 2014-12-15; просмотров: 167 | Поможем написать вашу работу | Нарушение авторских прав |