МЕТОДОЛОГИИ
Трудно назвать компанию, превосходящую Microsoft по массовости распространения коммерческих продуктов. Огромные тиражи программ, выпускаемых этой корпорацией, придают определенную специфику и технологиям их разработки. Microsoft не применяет классические методологии создания ПО наподобие CMM - прежде всего потому, что в них необходимо максимально подробно формулировать требования к проекту на самых ранних его стадиях. Определить же эти требования при разработке ОС или продуктов, выпускаемых десятками и сотнями миллионов копий, и угадать пожелания большинства пользователей, предварительно не пообщавшись с ними, очень сложно. Поэтому оригинальная методология Microsoft предусматривает как можно более раннюю организацию обратной связи с потребителями будущего продукта. Сначала он наделяется ограниченным базовым набором функциональных возможностей, и такая версия отдается на тестирование большому числу пользователей, чтобы определить их мнение о правильности ее идеологического построения.
Кроме того, весьма непросто предсказать, как будет выглядеть окончательная конфигурация будущей системы, поэтому ее очень тяжело тестировать целиком: неизвестен конкретный состав отдельных компонентов, а их возможные сочетания, возникающие в процессе эксплуатации системы миллионами клиентов, невозможно проверить физически. Все это заставляет Microsoft особое внимание уделять тестированию отдельных модулей и отладке средств их взаимодействия - недаром все версии Windows основываются на интеграционных технологиях DDE, OLE, COM, DCOM, XML. Но тут появляется другая проблема: как на этапе проектирования разбить продукт на одинаково важные подсистемы, не допуская перекоса в их функциональных возможностях, и как правильно определить для них внутренние интерфейсы, чтобы потом из компонентов можно было собрать хорошо работающий готовый продукт.
Вместе с тем стремиться при развертывании крупных проектов к единому операционному окружению, например только на базе Windows, - не лучший выход. Пауль Мариц, вице-президент Microsoft Developer Group, считает, что интенсивное развитие ИТ может потребовать в будущем проведения серьезной и дорогостоящей адаптации новых версий коммерческого ПО к текущему эксплуатируемому окружению. Поэтому гораздо правильнее, с его точки зрения, создавать свои системы на основе общепринятых стандартов (например, XML, DCOM, CORBA) и строго их придерживаться. Г-н Мариц довольно скептически отзывается о сегодняшней ситуации с Linux: хотя она распространяется в исходных текстах, пока не существует независимой организации, которая разрабатывала бы стандарты и интерфейсы программирования для Linux и следила за их соблюдением.
Особняком стоит проблема предсказания производительности распределенной системы, собранной из компонентов, - при неукоснительном следовании требованиям стандартизованных интерфейсов быстродействие системы может существенно снижаться. Microsoft требует от команд разработчиков конкретных оценок качества и производительности создаваемых ими продуктов и модулей. Точность подобных оценок служит одним из важнейших показателей квалификации этих работников.
Заботясь о сохранении высокопрофессионального состава служащих, Microsoft считает необходимым придерживаться трех наиболее важных, с ее точки зрения, принципов:
- сотрудники должны знать, что именно от них во многом зависит успешное завершение проекта;
- сотрудники должны работать над интересными для них задачами;
- сотрудников надо материально стимулировать. По материалам Microsoft Developer Group
