Мифический человеко-месяц или как создаются программные системы
Шрифт:
Таким образом, всякий достаточно большой или срочный продукт, требующий усилий многих людей, сталкивается со специфической трудностью: результат должен концептуально согласовываться с разумом одиночного пользователя и в то же время проектироваться усилиями нескольких разумов. Как организовать проектирование, чтобы достичь такой концептуальной целостности? Это центральный вопрос «МЧ-М». Один из его тезисов гласит, что существуют качественные различия между управлением большими и маленькими программными проектами — лишь в силу числа работающих над ними голов. Для достижения согласованности необходимы обдуманные и даже героические действия.
Архитектор. С четвертой по шестую главу я доказываю, что самое
Отделение архитектуры от разработки и реализации. Чтобы сделать возможным осуществление архитектором своей главной задачи, необходимо отделить архитектуру, т.е. определение продукта в восприятии пользователя, от его разработки. Архитектура и разработка определяют четкую грань между разными частями задачи проектирования, и по каждую сторону этой грани лежит большая работа.
Рекурсивность архитектуры. В очень больших проектах одному человеку не справиться со всей архитектурой, даже если он избавлен от всех забот, связанных с разработкой. Поэтому главный архитектор системы должен разбить целое на подсистемы. Границы подсистем должны быть проведены так, чтобы интерфейсы между ними были минимальны и легче всего строго определяемы. Тогда у каждой части может быть свой архитектор, подчиняющийся главному архитектору системы в отношении архитектуры. Очевидно, при необходимости этот процесс может быть продолжен рекурсивно.
Сегодня я убежден более чем когда-либо. Концептуальная целостность является важнейшим условием качества продукта. Наличие системного архитектора есть важнейший шаг в направлении концептуальной целостности. Эти принципы ни в коей мере не ограничиваются разработкой программного обеспечения, а справедливы при проектировании любой сложной конструкции, будь то компьютер, самолет, стратегическая оборонная инициатива или система глобальной навигации. После преподавания в более чем 20 лабораториях разработки программного обеспечения я стал настаивать, чтобы группы учащихся, даже из четырех человек, выбирали менеджера и отдельно — архитектора. Разделение функций в таких маленьких группах может показаться несколько чрезмерным требованием, но, по моим наблюдениям, это оправдано и способствует достижению успеха.
Эффект второй системы: функциональность и угадывание частоты
Проектирование для больших групп пользователей. Одним из последствий революции, произведенной персональными компьютерами, является все возрастающее, по крайней мере в области обработки деловых данных, вытеснение заказных программ коробочными программными пакетами. Более того, стандартные программные пакеты продаются сотнями тысяч и даже миллионами экземпляров. Системные архитекторы программ, поставляемых вместе с машиной, всегда должны были создавать проект, ориентированный на большую аморфную массу пользователей, а не на отдельное определенное приложение в одной компании. Теперь такая задача встает перед очень многими архитекторами.
Парадокс состоит в том, что спроектировать инструмент общего назначения, нежели специализированный, гораздо труднее именно
В погоне за функциональностью. Архитектор инструмента общего назначения, такого, например, как электронная таблица или текстовый редактор, подвержен сильному соблазну перегрузить продукт функциями предельной полезности ценой снижения производительности и даже простоты использования. Вначале привлекательность предлагаемых возможностей кажется очевидной. Расплата производительностью становится очевидной лишь при системном тестировании. Утрата простоты использования коварно подкрадывается по мере того, как небольшими порциями добавляются новые функции, а руководства пользователя все более разбухают. [1]
Соблазн особенно велик в отношении долгоживущих массовых продуктов, развивавшихся на протяжении ряда поколений. Миллионы покупателей требуют сотен новых возможностей. Всякая просьба свидетельствует о наличии спроса на рынке. Часто архитектор первоначальной системы уже ушел в поход за новой славой, и архитектура оказалась в руках людей с меньшим опытом взвешенного представления общих интересов пользователей. В недавней рецензии на Microsoft Word 6.0 сказано: «Переполнен возможностями; обновление замедлено перегруженностью… Кроме того, Word 6.0 занимает много места и медленно работает.» С неудовольствием отмечается, что Word 6.0 занимает 4 Мбайт памяти и сообщается, что из-за богатых дополнительных функциональных возможностей «даже Macintosh IIfx едва пригоден для выполнения Word 6». [2]
Определение группы пользователей. Чем крупнее и аморфнее группа предполагаемых пользователей, тем более необходимо явно ее определить, если вы намерены достичь концептуальной целостности. У каждого члена группы проектировщиков наверняка есть неявный мысленный образ пользователя, и все образы будут отличаться друг от друга. Поскольку представление архитектора о пользователе явно или подсознательно оказывает влияние на все архитектурные решения, важно, чтобы команда проектировщиков пришла к единому общему образу. Для этого необходимо составить список признаков предполагаемых пользователей, указав в нем:
• кто они такие,
• что им нужно,
• что, по их мнению, им нужно,
• чего они хотят.
Частоты. Для любого программного продукта каждая характеристика пользователя представляет собой распределение со множеством возможных значений и соответствующими частотами. Как архитектору получить эти частоты? Изучение этой слабо очерченной популяции представляется сомнительным и дорогостоящим занятием. [3] С годами я пришел к убеждению, что архитектор должен угадать или, если вам больше нравится, постулировать полный набор признаков и значений вместе с частотами для создания полного, явного и общего для всех описания группы пользователей.
Такая непривлекательная процедура имеет ряд полезных последствий. Во-первых, при стремлении точно угадать частоты архитектор вынужден очень тщательно обдумать, какова возможная группа пользователей. Во-вторых, при фиксации частот возникает обсуждение, полезное для всех участников и выявляющее различия в образах пользователя, имеющихся у разных проектировщиков. В-третьих, явное присвоение частот содействуют пониманию того, какие решения какими свойствами группы пользователей обусловлены. Даже такой неформальный анализ чувствительности приносит пользу. Когда обнаруживается, что очень важные решения зависят от некоторых специфических предположений, оказывается уместным получить более точные численные оценки. (Разработанная Джеффом Конклином (Jeff Conklin) система позволяет формально и точно прослеживать принятие проектных решений и документировать их основания. [4] Мне не приходилось ею пользоваться, но думаю, что она должна быть очень полезна.)