Файл: История развития программирования в России.pdf

Список можно продолжить, главное, что все эти компании считают свои проекты успешными [4]. Ключевыми преимуществами российских центров разработки являются большие технические способности и творческий подход российских профессионалов.

Центры программирования

В стране исторически сложилось три основных центра программирования: Москва, Петербург и Новосибирск. Среди прочих городов с развитой индустрией программирования следует отметить Нижний Новгород, Екатеринбург, Пермь и Саров.

В Москве сосредоточены основные денежные потоки, а также менеджмент страны и практически всех крупных российских компаний, поэтому многие здешние компьютерные компании ориентированы на внутренний рынок (хотя есть и исключения, например, Luxoft, VDI и Auriga).

Петербург расположен в непосредственной близости от североевропейских стран, что превратило его в один из многообещающих центров глобального программирования. Здесь расположены десятки аутсорсинговых компаний, насчитывающих от 50 до 250 человек.

Новосибирск был с самого начала спланирован как город, ориентированный на науку — предполагалось, что ему удастся стать достойным противовесом научным центрам в европейской части России. К сожалению, российская наука испытывает сейчас не лучшие времена, поэтому происходит постепенная переориентация исследователей на разработку бизнес-приложений. Однако географическая удаленность и проблемы с телекоммуникациями в Сибири являются серьезными барьерами на этом пути.

Проблемы и перспективы развития

Развитие российской индустрии программирования затруднено целым рядом проблем. Самая большая трудность — это компьютерное пиратство. 88% используемых в России программ являются нелицензионными (в среднем по миру — 36%). Только Вьетнам, Китай и ряд стран бывшего СССР имеют еще худшие показатели по этой проблеме. Некоторые компании пытаются избежать столкновения с этой проблемой путем ориентации создаваемых продуктов на западный рынок. Этот подход (известный также как «скандинавская» или «израильская» модель) представляется очень многообещающей, так как из-за разницы в уровне цен на исходном и целевом рынке финансовый результат может многократно превышать затраты. Единственная проблема заключается в том, что требуются значительные начальные финансовые вложения, отсутствующие у большинства российских компаний. Финансовый рынок в России также недостаточно развит для того, чтобы поддерживать подобные проекты. Поэтому, несмотря на целый ряд примеров успешной реализации подобной модели (например, антивирусная система AVP или графические средства, разработанные компанией ParaGraph и приобретенные впоследствии Silicon Graphics), все еще неясно, станет ли эта модель массовой в России.

Еще одна проблема, затрагивающая все отрасли России, — неразвитая инфраструктура. Почта, транспорт, муниципальные услуги либо ненадежны, либо просто плохи в большинстве регионов, может быть, за исключением отдельных крупных городов. Естественно, это затрудняет работу всех предприятий, зависящих от инфраструктуры.

Наконец, российская индустрия глобального программирования страдает от неадекватного имиджа России за рубежом. В погоне за сенсациями ряд статьей в западной прессе освещает такие «неаппетитные» темы: отмывание денег, природные и техногенные катастрофы или русская мафия. В результате, российские компании вынуждены начинать свой маркетинг с нейтрализации бытовых мифов.

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

Существуют также законодательные проблемы, мешающие развитию отрасли. Многие законы, в частности, законы об интеллектуальной собственности, экспорте программного обеспечения и налогообложении, требуют постоянного внимания. Увы, даже современные законы, теоретически адекватно регулирующие отношения в той или иной области, зачастую очень плохо работают на практике. Скажем, очень трудно добиться соблюдения существующих законов об охране авторских прав и компьютерном пиратстве.

Опыт Индии и Ирландии показывает, что режим наибольшего благоприятствования для индустрии программирования может привести к скачку в развитии индустрии и увеличению доходов в этой области. Вместе с тем, среди руководителей российских программных компаний широко распространено мнение о том, что индустрия в целом не нуждается в освобождении от налогов или каких-то других формах прямой поддержки. Что действительно нужно от государства на данном этапе — это решение общих инфраструктурных проблем.

И все же отношение к программированию постепенно меняется. Например, в июле 2000 года Россия подписала так называемую «окинавскую хартию», в которой подчеркивается особая значимость компьютерных технологий для развития современного информационного общества. Этот вопрос также отражен в федеральной программе «Электронная Россия»; развитие компьютерной индустрии названо в ней одним из наиболее приоритетных направлений страны на ближайшее десятилетие. Будем надеяться, что эти планы действительно будут претворены в жизнь.

Становление дисциплины программирования

Технология программирования в СССР и России как отдельная дисциплина начала складываться уже к середине 60-х годов. Первоначально вопросы технологического подхода к созданию программ и программных продуктов рассматривались исключительно в аспекте «автоматизации программирования» и создания «программирующих программ», прежде всего компиляторов с основных языков программирования того времени – автокод, Фортран, Алгол-60, Лисп. Параллельно с этим развивался структурный подход, связанный с изучением схем программ и формальным доказательством их свойств.

Важными практическими результатами в этом направлении стали работы А.Л. Фуксмана [10], В.В. Липаева [11] и И.В. Вельбицкого [12] и созданных ими школ, специально рассматривавших процесс создания программных продуктов. Однако их подходы базировались на модели крупных вычислительных центров, впоследствии выросших в центры коллективного пользования с системой разделения времени на одной или нескольких больших ЭВМ.

Всеобщая миниатюризация вычислительной техники, появление персональных компьютеров, сетевых технологий, распространение Интернета создали новые вызовы, ответом на которые стали модели самого процесса разработки программ. Первые изменения стали заметными уже в классической монографии Дж. Вайнберга «Психология программирования» [13], ставшей в 1971 г. заметным явлением, дополняющим знаменитый труд Д. Кнута «Искусство программирования» [14], первый том которого вышел в 1968 г.

В 1984 г. в США был создан Институт технологии программирования (SEI – Software Engineering Institute) как научно-исследовательский центр с государственным финансированием из бюджета США при университете Карнеги-Меллон (г. Питтсбург, США), ориентированный на нужды Минобороны США. Он объединил ученых и практиков в области разработки программного обеспечения, задачей которых было дать обоснованную модель для предсказуемого процесса разработки программных продуктов для улучшения качества систем, зависящих от программного обеспечения. Основным достижением первой законченной модели CMM (1986) с последующим ее уточнением CMM for Software V1.1, (1993) можно считать определение 18 ключевых областей процесса – взаимосвязанных групп деятельностей, которые должны исполняться при создании программного продукта. Многие из этих деятельностей выполнялись и ранее на интуитивном уровне; модель CMM их точно определила и, что особенно важно, дала единую «мета-модель» для всех этих областей. Каждая ключевая область процесса характеризуется своими 3–4 целями, которые должны достигаться в процессе выполнения ее деятельностей, рекомендуемым перечнем самих этих деятельностей (4–8), обязательствами и возможностями по их исполнению, измерением, анализом и постоянным контролем хода и результата их исполнения (Рис. 1, а).

Последовавшее крупномасштабное внедрение этой модели в промышленном программировании при создании программных продуктов подтвердили ее высокую практическую значимость и реальное повышение качества конечного продукта при снижении затрат на его разработку и сопровождение, а главное – высокую предсказуемость самого процесса производства программного продукта. Настольной книгой разработчиков стала монография тогдашнего директора SEI У.С. Хэмфри «Управление процессом разработки программного обеспечения» [15].

В России первые применения модели CMM состоялись в Санкт-Петербурге, затем в Москве, Нижнем Новгороде, Великом Новгороде и других городах. Одной из первых в постановке процесса стала компания ИДУ, созданная в 1993 г. на базе СПИИРАН для выполнения программных разработок по заказам компаний IBM и затем Motorola. Благодаря помощи специалистов Моторолы, процесс по модели CMM был поставлен в течение 1 года и уже в 1995 г. был официально сертифицирован на 3-й уровень зрелости, а накопленный опыт был впоследствии отражен в [16] – первой отечественной монографии по данному вопросу.

Процесс сертификации или оценивания уровня зрелости состоял в том, что сертифицированные специалисты в течение 4-х дней изучали предоставленную им документацию по уже выполненным проектам и проектам, находящимся в разработке. Кроме того, проводились собеседования с группами разработчиков и руководством компании, на которых участники рассказывали о том, как именно ведется работа в проектах, подтверждая сказанное документами из архива проекта. Важным аспектом было то, что оценщики вопросов, как правило, не задавали, а основывали свои выводы исключительно на той информации, которая им предоставлялась. В четвертый день оценивания были оглашены предварительные результаты, которые могли быть изменены, если разработчики представят новые документы, меняющие восприятие сложившейся у оценщиков картины, после чего в течение дня готовилось окончательное заключение, оглашенное на 5-й день оценивания. Наряду с вердиктом об установленном уровне зрелости, комиссия экспертов предлагала ряд рекомендаций по улучшению отдельный аспектов проектной деятельности.

а) Метамодель CMM

б) Ключевые области процесса в CMM

Рис. 1. Модель зрелости способностей CMM

Выделившаяся из компании ИДУ группа разработчиков впоследствии составила ядро Санкт-Петербургской лаборатории компании Моторола, которая в 1999 г. была оценена на 4-й уровень зрелости, а в 2000 – на высший 5-й уровень.

Рис. 2. Спутанный клубок разных моделей зрелости

Успех модели CMM стимулировал создание других конкурирующих моделей (Рис. 2), так что к концу 90-х годов разработчикам стало уже трудно их сравнивать и делать осознанный выбор в пользу той или иной модели. Кроме того, обнаружилось, что для делового успеха организации-разработчика в модели производства программного продукта необходимо учитывать, наряду с чисто технологическими, еще бизнес-факторы и ряд других. Ответом на эти вызовы стала модель CMMI (2000) с последующими ее уточнениями (CMMI for Development V1.3, 2010), в которой обобщен накопленный опыт и заложены средства для учета этих дополнительных факторов.

Модель CMMI (Рис. 3) определяет теперь уже 22 процессные области, каждая из которых характеризуется своими специфическими целями и специфическими практиками, рекомендуемыми для их достижения. Кроме того, для всех процессных областей определены 3 общие цели и 14 общих практик. Поддержание модели, ее дальнейшее совершенствование и распространение ведет организация CMMI Institute на базе Института технологии программирования и университета Карнеги-Меллон.

а) Метамодель CMMI

б) Процессные области в CMMI

Рис. 3. Модель зрелости способностей CMMI

В 2006 г. Санкт-Петербургская лаборатория компании Моторола прошла официальную сертификацию на 5-й, высший уровень зрелости по модели CMMI, еще раз подтвердив свой высочайший профессиональный уровень.

а) Уровень 3 CMM

б) Уровень 5 CMM

в) Уровень 5 CMMI

Рис. 4. Памятные значки о достижении высоких уровней зрелости CMM/CMMI

В промышленном производстве ПО актуальным является вопрос о государственной сертификации создаваемого программного продукта, что обуславливается необходимостью отвечать международным стандартам. Например, для бортового ПО в авиации – это стандарты DO-178C и ED-12C и соответствующий им отечественный стандарт КТ178В «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники». Процесс создания сертифицируемого ПО, определяемый этими стандартами, имеет много общего с моделью CMM/CMMI (Рис. 5).

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