РЕЦЕНЗИИ
Microsoft Corporation. Анализ требований и создание архитектуры решений в среде Microsoft .NET. Пер. с англ. М.: ИТД "Русская Редакция", 2004. - 416 с., компакт-диск.
В последние годы мы можем видеть, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (application lifecycle management, ALM). Microsoft пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО (хотя движется именно в этом направлении) и главный акцент делает на средствах для проектирования и разработки - Visio, Visual Studio и др. Но основой реализации идеологии ALM является конечно же не набор инструментов сам по себе, а общая методологическая база. Microsoft уже более десяти лет занимается развитием собственной ALM-методологии под названием Microsoft Solutions Framework (MSF).
Это может показаться неожиданным, но MSF - по сути, платформонезависимая методология, детально описывающая отдельные процессы на уровне абстракций; инструменты самой Microsoft в ней присутствуют в минимальной степени, лишь как примеры реализации тех или иных рекомендаций. Вместе с тем хотя и в неявном виде, но концепция эта четко выражает общую нацеленность (круг задач, для решения которых они предназначены) средств разработки корпорации, что очень хорошо видно из анализа динамики ее развития. Так, если десять лет назад MFS ориентировалась на создание локальных клиентских приложений, то сегодня - на разработку и внедрение сложных систем масштаба предприятия.
Рецензируемая книга представляет собой официальный учебный курс Microsoft по подготовке к сдаче сертификационного экзамена 70-300 Analyzing Requirements and Defining Microsoft .NET Solution Architectures; она позволяет довольно детально познакомиться с современным состоянием методологии MSF в целом (его оригинальный английский вариант выпущен в конце 2003 г.), а не только с его отдельными этапами. При этом подчеркнем еще раз: слова "Microsoft .NET" не должны вводить читателей в заблуждение - речь в книге идет об общей логике разработки ПО, без особой привязки к инструментарию и операционной среде Microsoft.
Однако сказав общие слова о пользе MSF вообще и рецензируемой книги в частности, для правильного восприятия этих материалов мы должны сделать еще ряд важных замечаний относительно этой методологии и той ее части, которой посвящена данная книга. С этой точки зрения ключевое значение имеет первая глава - "Введение в проектирование бизнес-решений", сжато, но достаточно содержательно излагающая концепцию MSF.
Сравнивая различные промышленные методологии разработки ПО (IBM/Rational, Borland, Microsoft и др.), можно увидеть их тождественность в плане общей логики, принципов организации и последовательности реализации (например, все они за основу берут итерационный, спиралевидный характер разработки). И в этом нет ничего удивительного: именно этим отличаются выверенные временем технологии от кустарного производства. Но в то же время каждая методология по-своему подходит к выделению различных этапов разработки и зачастую использует собственную терминологию, что усложняет проведение необходимых параллелей. Проблема эта усугубляется также отсутствием устоявшейся русской терминологии.
Наиболее общепринятое на сегодня выделение ALM-этапов, которого, в частности, придерживаются Borland и Rational, выглядит следующим образом:
- Defining (определение требований);
- Designing (анализ и проектирование);
- Developing (разработка);
- Testing (тестирование);
- Deploying (развертывание).
Модель MSF предлагает несколько иную разбивку и наименование этапов:
- Envisioning (создание общей картины);
- Planning (планирование);
- Developing (разработка);
- Stabilizing (стабилизация);
- Deploying (развертывание).
Хотелось бы обратить внимание, что речь здесь идет не просто о разных названиях одних и тех же видов деятельности. Объективная проблема категоризации заключается в том, что выделение самостоятельных этапов в жизненном цикле приложений является весьма условным, особенно если речь идет об итерационной циклической модели разработки. Например, широкое использование визуальных методов проектирования с автоматической генерацией кода фактически стирает грань между проектированием и кодированием. А тестирование вообще пронизывает всю жизнь программы.
Имеются и субъективные факторы, которые определяются различиями стратегических бизнес-целей разных поставщиков методологий. Именно этим объясняется то, что Microsoft, основу бизнеса которой составляют не средства разработки, а платформенное ПО, больше (по сравнению с теми же Rational и Borland) внимания уделяет общим вопросам организации процесса создания приложений, а также их внедрению.
Поэтому, например, этап Envisioning включает определение не только требований ПО, но и состава команды (тут содержатся, в частности, очень интересные рекомендации по ролевой модели команды разработчиков, а также по возможным вариантам совмещения ролей). А этап Stabilizing подразумевает не только собственно тестирование, но и фактически опытную эксплуатацию ПО, на которой может производиться уточнение исходных требований заказчика. Что уж говорить об особом акценте Microsoft на задачах развертывания решений*1.
_____
*1 Например, методология Rational вообще фактически не затрагивала вопросы развертывания ПО. Но можно предположить, что Rational после вхождения в состав IBM будет уделять больше внимания этим задачам.
Сделав эти пояснения, можно перейти к содержанию остальных десяти глав книги - все они по своему содержанию привязаны к этапам MSF:
- этап Envisioning - главы 2 "Сбор и анализ информации" и 3 "Создание общей картины решения";
- этап Planning - главы с 4 по 10: "Создание концептуального дизайна", "Создание логического дизайна", "Создание физического дизайна", "Проектирование концептуального уровня", "Проектирование уровня данных", "Дизайн спецификаций безопасности", "Завершение этапа планирования";
- этапы Stabilizing и Deploying - глава 11 "Стабилизация и развертывание решения".
Я думаю, сейчас не имеет смысла детально обсуждать содержание отдельных разделов - в целом это понятно из их названий. Обратим внимание лишь на некоторые проблемы терминологии и перевода (он местами не очень удачен). Например, в оригинальном английском варианте книга называется "Analyzing requirements and defining Microsoft .NET solution architectures" - т. е. речь в ней идет не о создании архитектуры приложения, как это говорится в русском переводе, а о ее определении, проектировании. (Стоит отметить и то, что в названии книги Microsoft использует не собственную терминологию - Envisioning и Planning, а общепринятую.) Не совсем правильно термин Design переведен как "дизайн": речь в книге идет в основном о проектировании и проектах.
Что же касается остальных вопросов по форме и содержанию книги, то они решены на традиционном для подобных изданий высоком уровне: четкое разбиение по темам и занятиям, практикумы, закрепление материалов, лаконичное изложение и пр. Хотя пособие нацелено на подготовку к сдаче сертификационного экзамена, оно может быть полезно всем, кто хочет познакомиться с современными методами проектирования приложений (не только на платформе Microsoft). И в этой связи в заключение мне хочется обратить внимание еще на один важный момент.
В разговорах с руководителями софтверных компаний мне часто приходится слышать сетования по поводу студентов, которые приходят устраиваться на работу: "Никто не хочет быть просто программистом или тестировщиком, все сразу хотят стать бизнес-аналитиками или проектировщиками". Изучение данной (или подобной ей) книги - это необходимое (но еще не достаточное) условие, чтобы стать и аналитиком, и проектировщиком. Вот как выглядят минимальные требования к ее читателям:
- общее понимание жизненного цикла разработки ПО;
- практическое знание и опыт разработки в среде Microsoft .NET;
- базовые знания в области методологии объектного моделирования и моделирования данных;
- опыт работы с MS Visio Pro 2003;
- не менее чем годичный опыт работы в команде, занимающейся разработкой ПО.
