CC BY
13
Д. С. Пащенко, кандидат технических наук, руководитель офиса процессного развития в ЗАО «БСЦ Мск» e-mail: denpas@rambler.ru
АНАЛИЗ ЗАРУБЕЖНОГО ОПЫТА В СТАНДАРТИЗАЦИИ ПРОЦЕССОВ ПРОИЗВОДСТВА ПРИКЛАДНОГО ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Стандартизация процессов производства прикладного программного обеспечения продолжается уже более 40 лет. Процесс стандартизации очень тесно связан с развитием рынка программных продуктов и ожиданий заказчиков от поставщиков. В статье приведен обзор и анализ подходов к стандартизации производственной деятельности поставщиков программного обеспечения в США и Западной Европе.
Ключевые слова: стандартизация, производство программного обеспечения, практика изменений.
Производство прикладного программного обеспечения (ПО) для коммерческих предприятий, как промышленная отрасль и конкурентный вид бизнеса, в Западной Европе и США сформировались около 40 лет назад. В основе такого процесса лежали не только убыстрение бизнес-процессов и усложнение конкурентной борьбы, но и стремительный прогресс в области разработки аппаратного обеспечения и удешевление ЭВМ. В течение 70-х годов XX века ЭВМ начали свое глобальное наступление в различные сектора экономики и частного бизнеса — финансовое обслуживание, транспортные услуги, медицину, управление предприятиями и т.п.
Естественно, что промышленное производство программного обеспечение должно было быть стандартизировано в соответствии с лучшими практиками области или критериями необходимого качества для потребителей. К сожалению, даже к середине 70-х сообщество разработчиков ведущих компаний США не обладало достаточной внутренней самоорганизацией для создания промышленных стандартов собственной деятельности. Данный период мы можем отметить как период созерцания собственной деятельности: появляется понятие каскадной модели (конференция NATO, 1968), далее термин и модель waterfall в разработке дорабатывается и получает обоснование обратимости этапов в процессе (W. W. Royce, 1970), выделяются специализации членов команды разработки. Некоторые лидеры рынка разработки крупных информационных систем вроде IBM [4] создают практические инструкции по управлению проектами разработки, однако «первые пробы» не выдерживают испытаний при практическом применении и постоянно корректируются. Таким образом, данный период - это не попытки стандартизации, а период осмысления практик производства в очень молодой отрасли.
Анализируя современный российский рынок, отмечу, что методы разработки, близкие к waterfall, еще не изжили себя и по-прежнему применяются в самых неподходящих для этого проектах. Вместе с тем, действительно, остаются отрасли и комплексные проекты (например, в области самолетостроения или космических полетов), где модифицированные методы waterfall из 70-х годов прошлого века остаются актуальными. Причины, на мой взгляд, две и они очень простые: ментальные привычки разработчиков «старшего поколения» и очень слабые изменения требований к программному продукту в течение всего проекта.
Возвращаясь к более распространенным и высоко конкурентным секторам рыночной экономики, сделаем следующую отсечку в подходах к стандартизации производственных процессов производства программного обеспечения — 80-е годы 20-го века. Потребители программных продуктов были вынуждены сами стандартизировать если не коренные процессы разработки, то хотя бы качественные параметры продуктов, процессы их проектирования и поставки потребителям. Здесь следует выделить работы Б. Боэма [1, 2] и стандарты описания жизненного цикла программных систем (ISO/IEC, АNSI/IЕЕЕ, DOD/ NIST). Данные стандарты регулировали скорее взаимоотношения между потребителями и производителями и описывали жизненный цикл товара, нежели были производственными процессными моделями. В рамках текущей действительности СНГ данные стандарты были переняты более современными практиками и в редакции первоисточников практически не применяются. Однако отметим основные аспекты данных стандартов, оказавшие существенное влияние на развитие отрасли:
• стандарты поддерживались крупными заказчиками (реальными или потенциальными) конеч-
ных продуктов производства ПО и институтами стандартизации;
• основное внимание уделялось определению потребительских свойств программных продуктов и проектов по их реализации, а не производственным процессам.
Несмотря на серьезность организаций, поддерживавших развитие и внедрение данных стандартов, их широкое распространение было достигнуто лишь в долгосрочных программах проектов в области государственных заказов. Практически каждый участник рынка в соответствии со своими бизнес-реалиями достигал соответствия декларируемым стандартам в области, например, безопасности или документирования систем ISO/EC, не подчиняясь каким-то строгим производственным моделям. Тем не менее другие лидеры рынка, в меньшей степени стесненные государственными заказами, продолжали наращивать существенные различия в области производственных подходов или ведения проектов разработки ПО.
Резюмируя описание данного этапа, отмечу, что первые стандарты описывали не производственные модели, а, скорее, ожидания по качеству продуктов или сервисов в области разработки программного обеспечения и были продиктованы крупными потребителями, а не производителями или профессионалами рынка.
К началу 90-х годов прошлого века сразу несколько компаний пытались на практическом уровне вырваться из тисков «привычного водопада» в области производственных моделей. Опыт и достижения в области многолетнего развития программных продуктов и стремление к стабильному качеству (в т.ч. соответствие требованиям заказчика) получаемого продукта создали предпосылки к развитию новых парадигм и производственных процессных моделей создания прикладного программного обеспечения. Одним из наиболее ярких явлений данной эпохи стало использование итеративных моделей разработки. В то же время такие компании, как Telelogic и Rational Software, вдохновленные усиливающимся влиянием ПО на самые различные области экономики, начали создание (и сборку из купленных компаний) линеек программных продуктов [5], автоматизирующих процессы планирования, создания и поддержки ПО. Позднее данные инструменты стали основой инструментального обеспечения некоторых итеративных моделей разработки.
Стандартизированные и специфицированные итеративные модели разработки были предложены лидерами индустрии разработки прикладного ПО в виде собственных методологий (Rational — RUP, Microsoft — MSF, Borland — ALM) и легли в основу процессных моделей, которые к концу 90-х были автоматизированы соответствующими инструментами. По своей сути итеративные мо-
дели разработки программных продуктов впитали основные прогрессивные наработки предыдущих проектов и моделей:
• возможности прототипирования и моделирования - из разработок Б. Боэма и Г. Буча;
• дробление продукта на модули и автоматизируемые функции - из инкрементной модели;
• выпуски работоспособных версий в течение всего проекта;
• проактивная работа с рисками, в т.ч. в области производства;
• разделение проекта на фазы, а фазы - на итерации.
Однако методологии ведущих компаний и отдельные теоретические работы экспертов области [3, 4] не могли стать стандартом отраслевого уровня без соответствующей обработки. С середины 80-х годов прошлого века и до сего дня существует, как минимум, два общепринятых мировых стандарта, построенных на итеративных моделях разработки ПО - это стандарты СММ (позже - СММ1) и стандарты КО (например, КОЛЕС 12207). В данных стандартах подробно описаны все процессные области и процессы, связанные с разработкой программного обеспечения по итерационным моделям. Итеративные методологии производства (в данном временном промежутке -производные от RUP, MSF, ALM) являются практическими реализациями данных стандартов на конкретном предприятии. В основе успеха именно данных стандартов лежала поддержка крупных заказчиков конечных программных продуктов -так СММ поддерживало оборонное ведомство США, КО-образные сертификации - британские институты и учреждения. Популяризация и следование стандартам отрасли с середины 90-х годов становится не только модным трендом, но и важным конкурентным преимуществом на рынке программного обеспечения. Таким образом, условно первым из актуальных на сегодняшний день в Мире и России столпом стандартизации именно процессов производства становятся именно итерационные модели, описанные в СММ (СММ1) и приближенные к методологиям ЯиР и МБК
В течение 90-х годов рынок услуг в области программного обеспечения становится глобальным, а 1Т-аутсорсинг интернациональным. Разработка как продуктов, так и уникальных решений по требованиям корпоративных заказчиков теперь требует стандартизации процессов производства для обеспечения необходимого уровня качества, а сертификация компаний разработчиков становится конкурентным преимуществом на международном рынке. К середине первого десятилетия текущего века десятки (если не сотни) компаний, сертифицированных по 4-му и 5-му (самым высоким) уровням зрелости СММ, участвовали в глобальном рынке. Безусловно,
почти каждая такая компания имела собственный стандарт разработки, органично вбиравший в себя методы ЯиР и МББ, процессы и области процессов из КО и СММ1. Однако у заказчиков по-прежнему находились веские аргументы в споре о несовершенстве текущих подходов к разработке программного обеспечения и компетентности вендоров [7] ввиду возрастания требований к параметрам конечных продуктов качеству, стоимости, срокам создания. Добавлю, что по материалам тех лет [6] заказчикам было довольно сложно проверить реальность сертификации компании по какому-либо стандарту.
Таким образом, данный этап эволюции рынка сопровождается созданием общепризнанных производственных стандартов в области разработки программного обеспечения. Сертификация на соответствие данным стандартам (КО, СММ1) становится конкурентным преимуществом в борьбе за заказчика.
Однако общий рынок программного обеспечения продолжал свой лавинообразный рост, все новые ранее ручные или механизированные функции людей получали сложное и чаще всего централизованное управление на уровне информационных технологий. В мире развивались новые классы устройств, работа которых принципиально была невозможна без программного обеспечения. Такое разнообразие задач автоматизации (и количество конечных заказчиков и потребителей) вызвало значительные изменения в структуре рынка и значимости различных показателей в воспринимаемом качестве получаемых продуктов среди различных потребителей. Традиционные треугольники соотношения цены, качества и сроков проекта встретили противоречивые ожидания со стороны различных групп заказчиков. В то же время сообщества программистов с течением лет и сменой поколений не только стали более организованными, но и приняли глобализованный характер иногда в отрыве от реальных проектов и компаний-вендоров. Именно так с начала текущего века последовательно набирали моду, а впоследствии - сторонников и реальные воплощения в отрасли модели «легковесных» технологий разработки программного обеспечения. В настоящий момент «легковесные» модели создания программного обеспечения уже изменили как саму отрасль, так и ранее созданные итеративные модели производственных процессов. Основные причины активного продвижения таких технологий и моделей:
• смена поколений разработчиков, а значит, сдвиг стереотипов и профессиональных ценностей;
• значительное расширение спектра прикладного программного обеспечения, в т.ч. появление полноценного Web программирования;
• возрастание требований бизнеса и ожидания потребителей по срокам реализации программных продуктов в ущерб конечному качеству в долгосрочной перспективе.
Так, группа экспертов по различным легковесным методологиям провела семинар (2001), на котором были сформулированы основные принципы гибкой разработки ПО (так называемый Agile Manifesto). На том же семинаре было предложено новое название легковесных методологий — гибкая разработка (agile software development). По своей сути гибкие технологии разработки относятся к итеративным моделям, однако конкретные методики применения Agile сделали последние 10 лет современной истории полем для экспериментов и споров — от полного противостояния RUP-образных моделей и Agile до их скрещивания в некоторых гибридных формах.
Основные попытки применения и стандартизации гибких подходов — это осмысление отдельных практик в рамках «улучшения» определенной слабости более старых итеративных и инкрементных моделей на базе RUP и CMMI. Данный процесс далек от завершения, но основные закономерности можно выделить уже сейчас:
• Почти каждая Agile-практика создавалась на основе реального проектного опыта, «отягощенного» специальными рисками и ограничениями по ключевым параметрам бюджета.
• Каждая практика описана в книге ее автора или манифесте последователей. Затруднительно построить ретроспективную модель развития той или иной методики, однако следование ей в географическом масштабе носит широкий, но хаотический характер.
• Крупные софтверные компании и институты активно изучают и используют данные техники и методики, но не выступают с попытками их стандартизации, предпочитая сразу работать над стандартизацией и автоматизацией неких «гибридных» производственных моделей [8, 9].
Мы видим, как стандартизация производственных процессов принимает все более нечеткие формы в применении к отдельным типам компаний и сообществам программистов. При этом общемировой бенчмаркинг еще более востребован, а комбинация различных подходов из итерационных практик дает многообразие конкурентноспособных сочетаний в отдельных предприятиях.
В реальных компаниях, использующих гибкие технологии, почти всегда происходит смешение гибких и традиционных итеративных практик в каких-то пропорциях. Очевидно, что такие методики, как экстремальное программирование (EP) или бережливая разработка в чистом виде применимы в весьма небольшом количестве компаний на рынке. Однако интерес софтверных гигантов к гибким технологиям заставляет задуматься о
следующем прогнозе: гибридные модели разра- держанные авторитетом и практикой крупных ботки программного обеспечения на основе тра- мировых компаний, в ближайшем времени будут диционных и гибких итеративных моделей, под- брендированы и стандартизированы.
Литература
1. Боэм, Б. Инженерное проектирование программного обеспечения / Б. Боэм. — М. : Радио и связь, 1985.
2. Боэм, Б. Характеристики качества программного обеспечения : пер. с англ. / Б. Боэм, Д. Браун, Х. и. Каспар. — М. : Мир, 1981.
3. Boem, B. A Spiral Model of Software Development and Enhancement, ACM SIGSOFT Software Engineering Notes / B. Boem. — ACM. — 11(4):14—24. — August, 1986.
4. Фокс, Дж. Программное обеспечение и его разработка / пер. с англ. Дж. Фокс. — М. : Мир, 1985.
5. Лесин, Д. А. Что такое Jazz от IBM — утопия или будущее? / Д. А. Лесин. — 2011.
6. Кох, К. Взрывная волна CMM / К. Кох // Директор информационной службы. — № 04. — 2004.
7. J.A.L. Siegel, et al. National Software Capacity: Near-Term Study, Software Engineering Institute. CMU/SEI-90-TR-12. ADA226694. — May 1990.
8. Microsoft patterns & practice [Электронный ресурс]. — URL: http://msdn.microsoft.com/ru-ru/ practices — Дата доступа: 17.09.20012
9. Platform IBM JAZZ [Электронный ресурс]. — URL: http://www-01.ibm.com/software/rational/jazz — Дата доступа: 17.09.20012.
