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

2. Становление и развитие программирования как дисциплины в России

2.1 Программирование в СССР

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

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

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

В 1984 г. в США был создан Институт технологии программирования (SEI – Software Engineering Institute) как научно-исследовательский центр с государственным финансированием из бюджета США при университете Карнеги-Меллон (г. Питтсбург, США), ориентированный на нужды Минобороны США.

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

Основным достижением первой законченной модели CMM (1986) с последующим ее уточнением CMM for Software V1.1, (1993) можно считать определение 18 ключевых областей процесса – взаимосвязанных групп деятельностей, которые должны исполняться при создании программного продукта.

---

Многие из этих деятельностей выполнялись и ранее на интуитивном уровне; модель CMM их точно определила и, что особенно важно, дала единую «мета-модель» для всех этих областей.

Каждая ключевая область процесса характеризуется своими 3–4 целями, которые должны достигаться в процессе выполнения ее деятельностей, рекомендуемым перечнем самих этих деятельностей (4–8), обязательствами и возможностями по их исполнению, измерением, анализом и постоянным контролем хода и результата их исполнения (Рис. 1, а).

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

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

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

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

2.2 Программирование в России

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

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

---

Выделившаяся из компании ИДУ группа разработчиков впоследствии составила ядро Санкт-Петербургской лаборатории компании Моторола, которая в 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).

---

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

В полном соответствии с моделью CMMI, стандарт DO-178C определяет набор целей для всех деятельностей по созданию ПО, перечисляет обязательные типы рабочих продуктов (документов), создаваемых на каждом этапе в процессе разработки, и дает рекомендации по достижению заданных целей. В зависимости от уровня создаваемого ПО (от A – наиболее требовательного к аспектам безопасности, до D – наименее требовательного), меняется состав целей и способ проверки их достижения (Рис. 6).

Рис. 5. Связь процессов жизненного цикла системы и ее программного обеспечения

Рис. 6. Цели и деятельности жизненного цикла по разработке сертифицируемого ПО

Процесс жизненного цикла	Целей				Деятельностей	Документов
	A	B	C	D
Планирование	7	7	7	2	27	9
Разработка в целом	7	7	7	4	35	6
Требования	7	7	6	3	1	1
Проектирование	13	13	9	1	2	1
Кодировка и сборка	9	9	8	1	3	2
Тестирование сборки	5	5	5	3	7	3
Верификация	9	7	6	1	9	1
Управление конфигурацией	6	6	6	6	9	4
Обеспечение качества	3	3	2	2	9	1
Контакт с органом сертификации	3	3	3	3	3	2
Итого:	69	67	59	26	105	30
Из них независимо повторяемых	30	18	5	2

---

Таким образом, успешность сертификации во многом зависит от устойчивости и определенности установленного процесса разработки, сравнимого с уровнями 3 и 4 модели CMMI, что делает вопросы дисциплины программирования и правильной постановки процесса разработки ПО особенно важными. Для успешной сертификации необходимы современные средства автоматизации процесса разработки – единый каркас для разработки ПО, настроенный на данную предметную область и разработчика [8].

Заключение

Российское программирование имеет богатую историю, ведущую свой отчет от 50-х годов, когда программирование в основном предназначалось для решения военных и промышленных задач, например, для точного расчета места приземления космического корабля Юрия Гагарина. Ранние успехи советского программирования во многом связаны с тем, что советская экономика всегда была сильно индустриализованной и технически ориентированной. Растущая потребность в программистах была разрешена путем переориентации части математиков и физиков на информатику. В те времена количество программистов (да и самих компьютеров) было очень небольшим, так как область применения программирования была достаточно ограниченной. Так, за все 20 лет производства БЭСМ-6, одного из самых успешных компьютеров тех времен (было выпущено всего около 300 штук). Тем не менее, к концу 60-х советская школа программирования находилась на мировом уровне и в промышленной разработке программ, и в научных исследованиях.

Компьютерный рынок быстро увеличивался вплоть до кризиса 1998 года. Отечественная компьютерная индустрия была одной из наиболее пострадавших из-за своей зависимости от западного рынка; лишь совсем недавно Россия снова вышла на уровень 1997 года по количеству продаваемых компьютеров.

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

---