Monday, November 20th, 2017

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

Published on Февраль 25, 2009 by   ·   Комментариев нет

Добрый день. С вами Джон ДеВаан. Стивен уже упоминал о том, каким образом организована инжиниринговая команда 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) Я знаю, что в целом Vista SP1 столь же надежен, как XP, а в некоторых областях и более надежен. Именно телеметрия подсказала нам, что требуется исправить в SP1. Мы были рады увидеть, что первое, о чем говорили пользователи Vista SP1, — это сокращение времени входа/выхода из режима сна и гибернации. Телеметрия в перспективе позволит сделать Vista самой надежной из когда-либо выпущенных Windows. К списку несомненных преимуществ Vista следует отнести и двойное сокращение секьюрити-уязвимостей по сравнению с Windows XP. Этот блог о Windows 7, но вы должны знать, что над Windows 7 мы работаем с глубоким пониманием производительности Windows Vista в реальном мире. Пользователи, комментирующие наши статьи, натолкнули нас на некоторые идеи относительно дальнейшего улучшения инжиниринговой системы Windows.

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

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

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

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

Проэкт Windows 7

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

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

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

Управление проектами windous

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

Джон ДеВаан (Jon DeVann)
старший вице-президент Windows Core Operating System Division

Источник: http://blogs.msdn.com/e7ru





Смотрите также:

Tags: , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]