Delphi

Разработка сайтов

Наши проекты

Главная » Новости » Продукты Microsoft » Управляя проектом Windows 7

Дата: 08.09.2008

Управляя проектом Windows 7

Стивен уже упоминал об организации инжиниринговой команды Windows, от которой зависит успешность будущей работы. Но не менее важна и организация самого проекта по разработке.

Хотелось бы сразу сделать пару замечаний. Во-первых, Стивен читает и пишет примерно в 10 раз быстрее меня, поэтому не удивляйтесь соотношению количества наших публикаций. Только знайте, из нас двоих я более глубокомысленный :-). Хоть, быть может, я просто завидую. Во-вторых, мы стараемся делиться с вами информацией о том, как мы разрабатываем Windows 7, поскольку это позволит нам быть курсе при обсуждение конкретных вопросов на конференциях PDC и WinHEC. Мы хотим поделиться с вами тем, как мы проектируем Windows 7 основываясь на опыте, полученном при разработке Longhorn/Vista. Именно этот опыт привел нас к решению открыть блог Engineering Windows 7.

Стивен порекомендовал мне книгу Microsoft Secrets, в которой проведен отличный анализ того, что лично я называю второй версией инжиниринговой системы Microsoft (первая версия была построена на базе индексных карт и “floppy-сетей”, которые вам, скорее всего, попросту неинтересны). Вторая версия служила Microsoft хорошую службу гораздо дольше, чем многие предполагали, но опыт Windows XP и Longhorn/Vista показал, что пришло время для изменения подхода к проектированию наших продуктов.

Изменения в XP были вызваны меняющейся обстановкой в сфере безопасности во всей компьютерной индустрии. Увидеть, каким образом полученный нами опыт был воплощен в реальные действия, можно ознакомившись с техникой Security Development Lifecycle, являющейся набор инженерных практик, рекомендованных компанией Microsoft для разработки более безопасного программного обеспечения. Именно эти практики были использованы для разработки Windows.

Комментарии к блогу показывают, что качество конечного продукта всегда зависит от многих атрибутов, каждый из которых имеет разную значимость для разных пользователей, при этом у этих пользователей мнения об общем качестве Vista очень сильно разнятся. Я потратил немало времени на базовую надежность ОС и изучение данных телеметрии, собранных с компьютеров реальных пользователей (пожелавших принять участие в программе Customer Experience Improvement Program). Я знаю, что в целом Vista SP1 столь же надежна, как XP, а в некоторых областях даже более. Именно телеметрия подсказала нам, что требуется исправить в SP1. Мы были рады увидеть, что первое, о чем говорили пользователи Vista SP1, - это сокращение времени входа/выхода из режима сна и гибернации. Телеметрия в перспективе позволит сделать Vista самой надежной из когда-либо выпущенных Windows. К списку несомненных преимуществ Vista следует отнести и двойное сокращение секьюрити-уязвимостей по сравнению с Windows XP. Этот блог о Windows 7, но вы должны знать, что над Windows 7 мы работаем глубоко понимая различные аспекты производительности Windows Vista в реальном мире.

Пользователи, комментирующие наши статьи, натолкнули нас на некоторые идеи относительно дальнейшего улучшения инжиниринговой системы Windows. Производительность, надежность, совместимость и новые технологии – основные темы их комментариев. Достичь этого можно улучшением ежедневного управления разработкой кодовой базы Windows 7 — иначе говоря, улучшением качества ежедневных сборок. Мы уже предприняли немало шагов для того, чтобы улучшить качество управления проектом, поэтому в этом направлении нам удалось достигнуть определенных результатов.

Вы, наверное, читаете и думаете: “Тоже мне новость!”, но мой опыт с проектами по созданию программного обеспечения различных масштабов в различных организациях показывает, что это не настолько очевидно и не так легко достижимо, как бы нам хотелось.

Качество ежедневных сборок

Качество ежедневных сборок имеет ключевое значение для любого проекта по созданию программного обеспечения, поскольку от него зависит, сколько еще работы осталось, и соответственно, влияет на ежедневно принимаемые решения. Когда ежедневные сборки обладают низким качеством, невозможно определить, сколько работы осталось до завершения проекта, и в итоге менеджеры проекта могут принимать немало неверных инженерных решений. В связи с тем, что количество наших инженеров растет (в частности потому, что мы хотим сделать больше), важность качества ежедневных сборок принимает особую важность, особенно потому, что возрастает вероятность ошибки программистов. Эта проблема выходит за рамки осознания количества ошибок в продукте. Если бы в этом заключалась вся проблема, то судьба каждого разработчика была бы в его собственных руках. Гораздо более коварный побочный эффект, заключается в том что у разработчиков исчезает уверенность в необходимости интеграции всех изменений, сделанных в течение дня, в свою личную работу. Когда такое происходит, появляется огромное количество багов, несовместимостей и других проблем, которые сложно предвидеть, поскольку изменения в коде никогда не сводились в одну сборку на одной машине.

Я подготовил график, на котором проиллюстрирована вероятность сбоя в сборке в зависимости от числа сотрудников, работающих над проектом , вызванная однопроцентной вероятностью появления ошибки в работе отдельно взятого программиста (синий график). Однако, если использовать типичную частоту появления ошибки, то ситуация изменится в худшую сторону. Для информации я включил два дополнительных графика, на которых показано вероятность сбоя в сборке в случае, если сократить вероятность появления ошибки в работе отдельного программиста вдвое (красный график) и в десять раз (зеленый график). Можно видеть, что механизмы, используемые для улучшения ежедневного качества работы каждого инженера, достаточно сильно влияют на общее качество ежедневных сборок.

Для такой огромной команды как Windows выпуск надежных ежедневных сборок является подвигом.

Изменения в Windows 7 были вызваны значительными изменениями в инжиниринговой системе Vista, в частности нашими инвестициями в инфраструктуру автоматизации тестирования среди всех команд Windows (в будущем вы поймете, что между процессом разработки самим по себе и организацией команды есть постоянная связь, которую многие, к сожалению, не осознают). Используя эту инфраструктуру, мы можем отследить и проверить изменения в коде, внесенные каждой командой, до того, как они будут интегрированы в ежедневную сборку. Внутри каждой из команд эта инфраструктура может быть ежедневно использована для выверки изменений в коде от каждого программиста. На графике можно видеть, каким образом сбалансирована вероятность ошибки в сборке в среднем от 40 программистов, работающих в командах Windows 7. И как видите, вероятность сбоя сборки достаточно мала.

При разработке Windows 7 нам удалось добиться, что каждый отдельно собранный билд обладает достаточно высоким качеством. То есть, несмотря на то, что в сборку интегрируется труд всех разработчиков, автоматизация процесса позволяет нам отыскивать и исправлять любые проблемы и, как следствие, обеспечивать высочайшее качество практически каждой сборки. Поверьте мне, я использую Windows 7 в моей обыденной жизни с самого начала проекта и за это время практически не сталкивался с проблемами в ее работе (знаю, что многие энтузиасты хотели бы, как и я, тестировать различные сборки Windows 7, но еще чуточку терпения!)

Ради интереса приведу парочку фотографий из наших лабораторий, где проводятся различного рода тесты сборок серверных и клиентских версий Windows в режиме 24 часа/7 дней в неделю:

Данная статья – всего лишь капля в море информации о разработке программного обеспечения, на которую я потратил немало своего времени, но надеюсь, что в итоге вам было интересно. Надеюсь, что благодаря приведенному мною примеру вы уловили идею, какими способами мы улучшаем качество разработки Windows. Однако, наиболее достоверным тестом нашему мышлению будет качество конечного продукта. А что думаете вы по поводу этой инженерной проблемы?

Джон ДеВаан

Источник: E7Blog

Просмотров: 1356