Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения

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

Проблема 1. Людям, занятым в проекте, совершенно неинтересно изучать нашу систему.

Проблема 2. Они вполне могут обойтись и без методологов, и при этом успешно создавать программное обеспечение. Я ушел от формальных разработок, в то время как мои коллеги выдвинули новую идею: "Вся проблема - в обучении. Все будет хорошо , если мы дадим разработчикам необходимые математические знания гораздо раньше, еще в средней школе". Однако мое знание людей подсказывало, что такое желание неосуществимо. Не то, чтобы я ставил под сомнения очевидные преимущества формальной разработки ПО, просто я сомневался в нашей способности убедить 10 миллионов человек заняться математикой. Правильно было бы поставить вопрос следующим образом: "При каких обстоятельствах и для чего нужно включать в проект специалиста по формальной разработке?"

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

Мы потратили несколько лет, чтобы разработать специальный генератор, трансформирующий диаграммы последовательности и взаимодействия в архитектуру программного продукта и систему правил [Ci]. Многие компании работали (и работают) над сходными задачами, например, выполняемыми конечными автоматами Хэрела (Harel's executable finite state machines) [Ha].

Итак, проработав над этим проектом несколько лет, мы сделали прототип, и решили показать его группе наших потенциальных пользователей. Как же мы были поражены, услышав следующее: "Нет, спасибо. Нам больше нравится рисовать на доске, да и не хочется тратить время на то, чтобы заносить все эти рисунки в компьютер. Хотя… мы бы, наверное, взяли из всего вашего набора средств графический редактор". Как оказалось, прочие разработчики подобных программ получали похожие отзывы. Обычно пользователи соглашались, в конце концов, использовать "только графический редактор". Другими словами, перед нами стояли:

Проблема 1. Людям, занятым в проекте, совершенно неинтересно изучать нашу систему.

Проблема 2. Они вполне могут обойтись и без нас, и при этом успешно создавать программное обеспечение. Такое положение дел уже начинало меня беспокоить, и я стал заниматься методологиями разработки ПО (проектировал объектно-ориентированную методологию по заказу IBM Consulting Group (1992-94)). На этот раз, чтобы не наступать на те же самые грабли, я заранее опросил более дюжины различных компаний, которые работали над ОО проектами в различных странах, и тщательно записал все, что они мне рассказали. Изучая эти заметки, я сделал несколько интересных выводов:

Те команды, которые успешно работают над своими проектами, используют инкрементные процессы разработки [Co95]

При проектировании любая техника, сложнее "CRC-карточек" [B87] считается слишком сложной и не используется [Co94].

У тех, кто занимается проектированием, всегда есть возможность отказаться от любого программного продукта или техники, которые им не нравятся. Достаточно сказать начальнику: "Это замедляет работу. Если я буду этим пользоваться, то не уложусь в срок", и он разрешит проектировщикам поступать по собственному усмотрению. В то время это наблюдение не казалось мне особенно важным, но, тем не менее, я его записал и назвал "проектным ограничением" методологии. После этого я разработал весьма привлекательную и, как мне казалось, настолько не формальную, насколько это возможно, методологию и опробовал ее на одном из проектов. Наш опыт описан в документации по проекту Winifred [Co98]. Основной идеей техники проектирования, которую я рекомендовал к --">