Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

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

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

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

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

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

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

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

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

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

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

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

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