Сергей Бобровский
В 1987 г. после 20 лет активного использования компьютерных технологий Министерство обороны США пришло к выводу, что главная причина слишком частых неудач при разработке крупных информационных проектов заключается прежде всего в отсутствии менеджеров управления процессом создания качественного ПО. Менеджеры постоянно работали в режиме аврала, сроки откладывались все дальше, бюджет проекта разбухал, а качество продукта можно было предсказать только в сторону ухудшения. Тестирование не спасало - обнаруживались ошибки, для ликвидации которых требовалось переписывать всю систему с нуля. В организациях, где царил хаос (американцы употребляют термин undisciplined), не помогали ни CASE-системы, ни дорогие средства программирования, ни самые опытные руководители и консультанты. Если иногда все же удавалось реализовать проект среднего размера с удовлетворительным качеством, то это была заслуга исключительно отдельных высококлассных специалистов. При получении следующего заказа вновь возникала проблема подбора персонала. Точно так же сегодня многие (если не все) российские компании, разрабатывающие ПО, жалуются на отсутствие грамотных менеджеров проектов, хотя корень неудач лежит в методологии разработки программ (точнее, в ее отсутствии). Есть прекрасные программисты, есть специалисты по проектированию ПО, по постановке задачи, есть бизнес-консультанты, но простое объединение всех их в команду во главе с самым лучшим менеджером проекта не дает никаких гарантий, что эта команда создаст качественный продукт. Нет в России ни одной организации, способной научить программистскую фирму, как своими силами организовать выпуск качественного ПО. Огромная ниша между бизнес-консалтингом и аутсорсингом в нашей стране совершенно пуста.
Но можно ли вообще гарантировать реализацию проекта в заданный срок с заданным бюджетом и высоким качеством? Практика показала, что можно. Имеется специальная методика, которой сегодня успешно пользуются многие крупнейшие зарубежные компании, выполняющие большие информационные заказы. В ее основе лежит управление процессами создания качественного ПО (ПСПО). Такой процесс может быть определен как набор организационных процедур, действий и методов, используемых менеджерами для управления разработкой, тестированием и сопровождением качественного ПО. Совершенствуя ПСПО, фирма может неограниченно повышать качество своих продуктов при среднем уровне квалификации менеджеров и программистов.
Пойди туда - не знаю куда
В конце 1987 г. Институт программной инженерии США (Software Engineering Institute, SEI) в сотрудничестве с корпорацией Mitre выпустил небольшую инструкцию, посвященную способам управления ПСПО. Тогда эта работа была воспринята скорее как очередная технология проектирования (вроде формальных методик IDEF), чем как средство улучшения качества ПО. Но SEI продолжил свои исследования, проанализировал процессы разработки множества больших КИС в разных компаниях и госструктурах и за четыре года создал модель зрелости Capability Maturity Model for Software (CMM, последняя версия - 1.1), с помощью которой удается обеспечить эффективное управление ПСПО. Соответствие уровням CMM означает, что компания созрела для новых свершений в программной индустрии.
CMM - не технология, не стандарт, для нее нет никаких формальных описаний, и SEI не рекомендует использовать ориентированные на CMM CASE-системы. Более того, при создании CMM не проводилось никаких аналогий и не делалось никаких заимствований из других методик проектирования ПО. В ней нет жестких предписаний, она не привязана к конкретным информационным технологиям, не подсказывает, как улучшить работу компании, и не объясняет, как работать с персоналом. Для этого есть консалтинговые фирмы. Ведь всегда существуют нюансы функционирования компании и ее корпоративная культура. Нет готовых руководств и по применению CMM - SEI советует каждой компании самой написать руководство для своего бизнеса на основе CMM. Или пригласить CMM-консультантов, которых готовит SEI.
Здесь уместно спросить - а зачем вообще нужна CMM? Предназначена она для организации эффективного управления разработкой ПО. CMM определяет ключевые действия, которые указывают, что надо сделать для достижения требуемого качества ПО (но не указывают, как). CMM также содержит способы контроля за правильностью выполнения ключевых действий и методы их корректировки. Ключевые действия достаточно детально описаны в руководстве на абстрактном уровне, а в процессе использования CMM компания может выбрать произвольную степень их формализации.
CMM позволяет также точно оценить ПСПО и на этой основе сравнить производительность различных компаний. В CMM включен набор критериев для определения зрелости ПСПО. Эти критерии используются крупными заказчиками для оценки риска при заключении контрактов на разработку ПО.
Международная организация по стандартизации ISO применяет CMM для создания международных стандартов оценки ПСПО. Но сама CMM - не стандарт и не может им быть. Например, фирма, стоящая на нижней ступени иерархии CMM, способна выпускать ПО в соответствии с ISO 9001, но достигается это благодаря титаническим усилиям нескольких талантливых менеджеров и программистов. В таких случаях говорят: “У фирмы Х сильная команда”. В идеале эта фраза должна звучать так: “Х - сильная фирма!”.
CMM имеет мало общего с практическими методиками управления качеством (во всем мире их насчитывается около 150 тыс.), хотя и базируется на разработанных в последние 60 лет пяти стадиях контроля за качеством. Эти методики обычно жестко регламентированы и основаны на статистическом контроле за продуктом в соответствии с требованиями множества различных нормативов, а CMM не содержит никаких численных критериев и рекомендаций и не указывает, как оценить продукт, а только рекомендует, что надо сделать, чтобы он обладал необходимым качеством.
Наиболее близко CMM стоит к общефирменной системе управления качеством TQM Ф. Кросби, которая считается целой философией (как и CMM), настолько она сложна. Однако принципиальное отличие TQM от CMM в том, что TQM ориентирована на области, не связанные с программированием, поэтому компьютерным фирмам не удается эффективно использовать TQM из-за слишком специфического понятия “качество ПО”. Кроме того, TQM большое значение придает человеческому фактору, бизнес-планированию и другим вещам, которые CMM не рассматривает.
И это все работает?
CMM иногда подвергается критике за то, что она сложна и для понимания, и для практического использования. Как выразился один из пользователей CMM, она слишком “неформально формальна”. Однако пока ничеголучшего в области управления ПСПО не придумано, а практика показала, что внедрение CMM дает очень большой эффект.
CMM чаще всего применяется при реализации крупных проектов, когда заказчиками выступают организации, требующие от исполнителя особо высокой надежности и качества ПО (как правило, военные и государственные структуры), поэтому работы по развитию CMM спонсируются Пентагоном. Американская компания не получит от правительства серьезный заказ, если она не прошла в SEI тестирование на соответствие как минимум третьему (из пяти) уровню CMM: программистская фирма, сертифицированная по третьему уровню, считается фирмой мирового класса. Пятому же уровню к осени 1997 г. соответствовало только пять компаний (программное отделение Boeing в Сиэтле, индийское отделение Motorola в Бангладеш и еще три другие). Интересно, что Microsoft неоднократно опровергала предположения, что она использует CMM. В оправдание Microsoft надо заметить, что применение CMM наиболее эффективно в компаниях с высоким уровнем бюрократии, когда многие процессы управления жестко формализованы.
(Окончание следует).
Компьютерная музыка. Интересные Web-узлы
www.auction-web.com/amisg. Похоже, что здесь собрана одна из самых больших коллекций ссылок на производителей аппаратуры и ПО, исследовательские, учебные, концертные и другие организации, так или иначе связанные с музыкой.
www.arachnaut.org/music/. Здесь можно просто утонуть в море музыкальной информации.
www.hitsquard.com/smm/, www.synthzone.com/, www. harmony-central.com. Прекрасно выполненные Web-узлы с хорошей подборкой музыкального ПО.
www.netrover.com/~dangerz/. Базовая страница MIDI-композиторов. Можно зарегистрироваться и разместить собственную композицию.
www.mindspring.com/~s-allen/. Один из старейших Web-узлов, где размещена оригинальная музыка.
www.midiweb.com/. Базовая страница, поддерживаемая MIDI-сообществом.
www.megatrade.ru/russian/. MIDI-композиции, выполненные с использованием расширенного набора инструментов.
www.ru.com/ntonyx/. Здесь можно ознакомиться с ПО Style Enhancer, которое способно улучшить стиль исполнения композиции.
Можно также заглянуть на Web-узел PC Week/RE по адресу: www.pcweek.ru и получить музыкальный привет от создателей компьютерной музыки.
Между прочим...
Встречаясь в начале 1997 г. с Габриэлем Сильберманом, одним из руководителей нашумевшего шахматного проекта IBM, я говорил с ним о машинном интеллекте и творчестве. Из уважения к собеседнику я не стал заострять внимание на очевидных различиях в исследуемых нами предметах. А они весьма существенны. Например в шахматах нельзя ставить фигуру между двумя клетками. Уже несколько веков партии шахматистов фиксируются в записях. Как бы ни было велико число комбинаций, оно все-таки конечно. К сожалению или к счастью, в музыке можно играть, невзирая на частотную сетку, и иногда именно такая игра бывает особенно выразительной. В музыкальном исполнении нет строгих правил, есть только направление движения с бесконечным числом нигде не зафиксированных нюансов. даже выдающийся музыкант, десять раз исполняя одно и то же произведение, сыграет его по-разному. Но все варианты будут выразительными, т. е. правильными...
