Оценка методологий разработки программных средств

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

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

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

Программная инженерия

В конце 1960-х годов, когда тогдашним инженерным гениям удалось высадить человека на Луну, располагая при этом меньшими вычислительными мощностями, чем любой современный калькулятор[110], в обиход вошел термин «программная инженерия». Эта концепция зиждется на представлении, согласно которому программное обеспечение можно разрабатывать средствами традиционных инженерных дисциплин. Применительно к сверхкрупным программным проектам, которые, как правило, заказывались правительством или крупными подрядчиками министерства обороны, эта методика несколько раз показала достойные результаты, но в остальных случаях потерпела фиаско[111]. Метод программной инженерии зачастую применялся в условиях одновременной разработки программного и аппаратного обеспечения. Кроме того, с его помощью удалось создать несколько коммерческих продуктов. IEEE определяет этот метод следующим образом:

«Программная инженерия – это систематический, структурированный, количественный подход к разработке, функционированию и сопровождению программных средств; иначе говоря, способ применения инженерных методов в разработке программных продуктов»[112].

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

Это не в меру сжатое определение, по-моему, можно расширить.

• Систематически – все аспекты разработки можно контролировать в едином процессе.

• Структурно – последовательное употребление должных методов с целью производства качественного программного продукта.

• Количественно – все требования известны и допускают отображение на методы реализации.

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

«Существует распространенное мнение, согласно которому несколько высококлассных специалистов, собранных вместе, способны сделать больше, чем стандартная группа разработчиков. Имеется в виду, что их знания о способах достижения высоких результатов интуитивны, а значит, потребность в систематизации процесса отпадает. Будь это действительно так, можно было бы предположить, что компании, у которых в штате числятся наиболее квалифицированные специалисты, не должны испытывать типичных проблем с качеством разрабатываемых программных средств и продуктивностью. Опыт же подсказывает нам, что это совершенно не так»[113].

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

Мнения на этот счет расходятся. Предположим, перед вами стоит задача конструирования системы управления воздушным движением. На первый взгляд, программная инженерия прекрасно подходит для ее решения. Но… стоит подумать еще раз. К провалу проекта комплексной системы автоматизации (Advanced Automation System, AAS) Федерального управления гражданской авиации США (Federal Aviation Administration, FAA), с помощью которого в 1980-х годах предполагалось модернизировать систему управления воздушным движением, методика программной инженерии имеет непосредственное отношение. Несмотря на миллионные затраты, проект так и не оправдал ожиданий[114].

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

MSF

Хотите – возмущайтесь, но в одном вы меня не переубедите: компании Microsoft удалось разработать крайне продуманный метод и успешно его разрекламировать. Несколько компаний[115]даже решили в приказном порядке отправить своих сотрудников на недельные курсы обучения предлагаемому Microsoft методу. Не сомневаюсь, что компании уровня Microsoft, специализирующейся на разработке коммерческих программных продуктов, есть что сказать на заданную тему.

Концептуальная основа метода MSF (Microsoft Solutions Framework – каркас решений Microsoft) предполагает координацию групп, тем или иным способом ответственных за процесс разработки. Вместо того чтобы воспроизводить яркие рекламные лозунги, я сосредоточу ваше внимание на отдельных деталях метода – по-моему, они лучше любых сообщений информационных служб и даже лучше научного изложения концепции отражают позицию Microsoft. Согласно выпущенному компанией руководству[116], предлагаемая методика основывается на «трех китах».

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

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

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

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

Что касается этапов MSF, то здесь группа разработчиков должна принять на вооружение ряд принципов.

1. Видение/рамки. Основное внимание уделяется не требованиям, а рамкам работ.

2. План проекта. Заказчики и участники группы должны договориться о поставках, приоритетах и ожиданиях.

3. Закрытые рамки/Первое применение. Первая бета-версия готового продукта.

4. Выпуск. Продукт или услуга предоставляется рабочей группе и группе поддержки.

Роли в MSF распределяются следующим образом.

1. Руководство продуктом. Особое внимание уделяется оценке продукта с коммерческой точки зрения.

2. Управление программой. Разработка функциональных спецификаций, утверждение и корректировка графика.

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

4. Тестирование. Выявление всех проблем перед выпуском программы.

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

6. Логистика. Обеспечение беспрепятственных выпуска, установки и миграции.

Все очень складно, не правда ли? На самом деле максимальной продуктивности, вооружившись методикой MSF, можно достичь лишь при наличии достаточно многочисленного персонала, который позволит сформировать группы и исполнять процессы согласно рекомендациям. Преподаватели на курсах утверждают, что метод MSF применяется в самой компании Microsoft. Учитывая характер литературы, выпущенной Microsoft Press за последние 10 лет, полагаю, что это действительно так[117].

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