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

С. Н. Баранов

Технология программирования в СССР и России как отдельная дисциплина начала складываться уже к середине 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, а).

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

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

Процесс сертификации или оценивания уровня зрелости состоял в том, что сертифицированные специалисты в течение 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).

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

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

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

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

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

Список литературы

1. Фуксман А.Л. Технологические аспекты создания программных систем. / М.: Статистика, 1979. – 184 с.
2. Липаев В.В. Управление разработкой программных средств: Методы, стандарты, технология. / М.: Финансы и статистика, 1993. – 250 с.
3. Вельбицкий И.В. Технология программирования. / К.: Техніка, 1984. – 280 с.
4. Weinberg, Gerald M. The Psychology of Computer Programming. Silver Anniversary Edition (1998). ISBN 0-932633-42-0.
5. Knuth Donald E. The Art of Computer Programming, 1: Fundamental Algorithms (3rd ed.), Addison-Wesley Professional (1997). ISBN 0-201-89683-4.
6. Humphrey Watts S. Managing the Software Process. Addison-Wesley (1989). ISBN 0-201-18095-2.
7. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий. М: Наука, 2000. – 176 с. ISBN 5-02-015564-0.
8. Баранов С.Н., Юсупов Р.М. Единый каркас для управления разработкой и сертификацией программного обеспечения // Региональная информатика (РИ-2012), 24-26 октября 2012 г.: Труды конференции, СПб, 2013. – С.51–54.

Об авторе: Санкт-Петербургский институт информатики и автоматизации РАН (СПИИРАН)
Санкт-Петербург, Россия
SNBaranov@gmail.com
Материалы международной конференции Sorucom 2014 (13-17 октября 2014)
Помещена в музей с разрешения авторов 26 ноября 2014