В первое десятилетие нового века — и так считаем не только мы — системное представление о программировании переживает очередной кризис. Это связано с тем, что технологическая поддержка написания текстов программ, на которую так уповали разработчики, позволила в рамках автоматизации отдельных процессов лишь их организовать. Правда, в целом значительное ускорение получила разработка программ на основе спецификации. Но внимание при создании программ, к сожалению, было сконцентрировано в пределах так называемого жизненного цикла, который определяется, главным образом, периодом их разработки. Настоящая статья преследует цель обратить внимание читателей журнала «Мир ПК» на более общую системную модель.
Системный взгляд на программную инженерию
Следует для начала обсудить, какой смысл в настоящее время обычно вкладывается в понятие «система», потому что отчасти именно в этом скрыта важная причина возникновения упомянутой выше проблемы. В данной работе станем исходить из того, что обсуждаемым в ней предметом будет программная инженерия, понимание которой удобно иллюстрировать ссылками на книгу, доступную для широкого круга читателей журнала. В качестве такого источника, к которому автор намерен при необходимости припадать, избрана работа профессора В. В. Липаева «Программная инженерия. Методологические основы», выпущенная издательством ГУ — Высшая школа экономики в 2006 г. Ее автор весьма известный специалист в мире программирования, имеющий более чем полувековой опыт исследовательской и практической работы.
Итак, выставим на пути рассмотрения проблемы первый понятийный репер, для чего заглянем на 10-ю страницу книги В.В. Липаева. Там сказано, что под программной инженерией (ПИ) понимается «область компьютерной науки и технологии, которая занимается построением программных систем, настолько больших и сложных, что для этого требуется участие слаженных команд разработчиков различных специальностей и квалификаций». Далее указывается, что суть методологии ПИ «состоит в применении систематизированного, научного и предсказуемого процесса проектирования, разработки и сопровождения программных средств». Таким образом, модель системы, используемую в ПИ, можно представить следующим образом. Отправляясь от печки, из кибернетического далека, под системой, используемой в ПИ, обычно понимают формальную триаду из множеств: элементов, ее составляющих, их состояний, а также из описаний переходов по состояниям.
Конкретизируем формальные понятия. В качестве элементов системы скорее всего рассматриваются группы и конкретные разработчики, участвующие в процессах разработки, проектирования, сопровождения, а также группа менеджеров, состав которой зависит от рыночного назначения системы ПИ.
Под множеством состояний системы, реализуемой в ПИ, рассматривают, в современном понимании, такие состояния элементов, которые определяются их влиянием на процессы, задаваемые целями, стоящими перед системой. Появление в толковании понятия системы термина «цель» естественно, потому что создание в реальных условиях всякой системы обусловлено той или иной целью. По сути процессы в системе — это не что иное, как группы элементов, объединяемые общностью цели, и их удобно понимать как подсистемы.
Далее, третий компонент, описание переходов по состояниям, обычно связывают с состояниями процессов или подсистем, реализуемых системой и определяющих ее функциональное назначение. Так, наиболее типичные процессы в ПИ — разработка, проектирование и сопровождение программных средств, а системные переходы из состояния в состояние есть продвижение по ним к функциональной цели процесса — его завершению.
Для дальнейшего важно обратить внимание на то, что модель системы в ПИ рассматривается в отрыве от модели той системы, для которой, собственно, создаются и в которой эксплуатируются программы. Разумеется, без спецификаций и сопровождения программ в ПИ не обходятся, но, к сожалению, даже объединяющее процессы ПИ понятие жизненного цикла программных средств не приводит к эффективной модели системы с точки зрения управления ею. Так, в частности, система в ПИ, как правило, при реализации ограничена в выборе алгоритмических методов, а качество работы программ сильно зависит от данных при решении задач в эксплуатационный период. Как об этом свидетельствует в своей книге В. В. Липаев, «программы и данные в системах и вычислительных машинах являются наиболее гибкими компонентами ПИ и подвержены изменениям в течение всего жизненного цикла программных средств». Поэтому в системах ПИ весьма популярен технологический прием настройки программ для процессов обработки информации. Чаще всего это означает, что для управления в программах используются длинные обратные процессные связи.
Жизненный цикл программных средств
Под жизненным циклом (ЖЦ) любой системы (термин заимствован из бионики — раздела кибернетики, изучающего живые системы для построения систем-аналогов, используемых в человеческой практике) понимается процесс от начала ее возникновения до конца существования. Типовая модель ЖЦ сложной программной системы с процессной точки зрения — заглянем в книгу В. В. Липаева — состоит в ПИ из формирования идеи системы или потребности в ней, охватывает проектирование, разработку, применение, сопровождение и заканчивается снятием системы с эксплуатации. В связи с тем, что программные средства служат для выполнения определенных функций в системах, назовем их для удобства основными, по отношению к которым системы ПИ и всевозможные системы аппаратных средств являются всего лишь подсистемами; они, естественно, существуют в рамках собственных ЖЦ. В таком случае ЖЦ систем ПИ целесообразно делить на стадии или этапы, чтобы согласовать с ЖЦ основной системы. Теперь можно описать на основе стадий ЖЦ процессный состав системы ПИ. Она реализует следующие процессы: определение потребностей основной системы в программных средствах, исследование и описание принципиальных концепций системы ПИ, проектирование и разработка, испытание системы ПИ, ее производство, распространение и продажа, эксплуатация, сопровождение и мониторинг, снятие с эксплуатации (утилизация).
При содержательном рассмотрении систем ПИ обычно выделяют два их крупных класса — малые и большие, что позволяет охарактеризовать свойственные им компоненты процессной модели. Например, каскадная модель ЖЦ системы ПИ использует последовательное и однократное исполнение процесса. При всей популярности в практике ПИ таких моделей их недостаток очевиден. В реальных условиях для более широкого круга основных систем необходимо не только параллельно исполнять некоторые процессы, но и обязательно использовать взаимодействие между процессами и даже организовывать соответствующие обратные связи для повышения эффективности управления в системе ПИ.
При реализации системы ПИ очень важным является обеспечение эффективности всего их ЖЦ в основной системе, что достигается главным образом благодаря использованию современных технологий, опирающихся на методологию, инструментальные средства автоматизации и технологические процессы, гарантирующие функциональные и конструктивные характеристики качества программных комплексов. Современная методология CMM (Capability Maturity Model), системная модель для оценки зрелости комплекса технологических процессов ЖЦ систем ПИ, позволяет заказчику и поставщику таких систем выстраивать отношения доверия при оценке их качества.
Принято считать, что концептуальные и организационные основы административного управления ЖЦ и качеством систем ПИ определены в CMM и CMMI:2003 и декларированы в восьми базовых принципах стандартов ISO 9000:2000 и ISO 15504:1-9. Для более подробного ознакомления с методологией и стандартами поддержания качества программ в ЖЦ систем ПИ можно воспользоваться книгой В.В. Липаева.
Итак, в сегодняшних представлениях о системе ПИ наиболее общими являются модели на основе ЖЦ, учитывающие контроль качества программных средств. Как было отмечено ранее, соотнесение моделей основной системы и системы ПИ в связи с ее процессным представлением и обычно с последовательной реализацией процессов не приводит к высокой степени соответствия прежде всего в отношении эффективности управления в основной системе. Отсюда подавляющее большинство проектов основных систем — это информационные системы, а эффективность тех, которые объявлены управляющими, невысока, т. е. организационные средства выступают как управляющие.
Кроме того, системы ПИ являются в основном объектно-ориентированными, что приемлемо для основных систем, решающих чаще всего задачи транзакционной обработки информации. В случае ЦОД, предназначенных для решения вычислительных задач, значительную роль играет методно-ориентированный подход, а жизненный цикл системы ПИ структурируется с учетом поддержки вычислительных методов и управления новым для нее процессом.
Вычислительная система
В качестве нового процесса выступает вычислительный, который проникает во многие процессы системы ПИ, так как на различных этапах ЖЦ может возникать естественная необходимость внесения изменений в любую составляющую процессов системы ПИ и при системной реализации она должна быть охвачена обратной связью, как между процессами, так и внутри процесса, причем автоматически обрабатываемой. Это отнюдь не запредельные претензии к сложным программным комплексам, а обычное требование, например ко времени счета по задаче, поскольку администратору необходимо управлять загрузкой компьютеров и других устройств.
Отсюда программная спецификация все больше детализируется в отношении методов решения задач и появляется более высокий уровень оперативного взаимодействия с постановкой задачи, что ставит перед методологами систем ПИ проблему разработки лингвистической поддержки составления спецификации для автоматизации этапов наиболее трудозатратного процесса — постановки задачи. Например, автоматизированными методами спецификации специалисты занимаются не один десяток лет (см. о подходе, изложенном в книге Деметрович Я., Кнут Е., Радо П. . Автоматизированные методы спецификации. М.: Мир, 1989).
Похоже, что транзакционная эпоха развития ИС уже требует активного осмысления информации, а для этого необходима ее количественная оценка на основе вычислительных задач. Отсюда возврат в широких кругах интереса к моделям систем, поддерживающим вычислительные процессы, следовательно, ПИ ожидает серьезное сближение с вычислительными методами.
Что же добавляет в процессное описание системы ПИ? Во-первых, при постановке задачи для системы ПИ связь с основной системой сохраняется на протяжении всего ЖЦ и управление им определяется ЖЦ основной системы. Алгоритмизация задачи выстраивается так, что зависит от управления вычислительным процессом. Появляется специфика в подготовке данных для тестирования на всех этапах ЖЦ, они должны учитывать особенность используемых вычислительных методов. Неизбежно возникающие в вычислительном процессе обратные связи приводят к тому, что процессная модель системы ПИ уже не может быть каскадной или последовательной. В модели на конечном этапе вычислительного процесса необходимо предусматривать возможность оценки качества решения, т. е. выполнения аналитической работы, которая требует от пользователя высокой квалификации и специфической программно-аппаратной поддержки.
Разумеется, более общая модель системы ПИ с вычислительным процессом появилась не сегодня, ее корни несложно усмотреть в вычислительных процессах, которые были непременным атрибутом организации работ на ВЦ в эпоху мэйнфреймов, но новые времена и технологии привносят большие возможности, которые тем не менее являются надстройками над прежними достижениями.
Программная инженерия и образование
Завершая статью, следует обратить внимание на то обстоятельство, что ПИ — это отклик программирования на требования к скорости разработок, которая устраивала бы рынок. Поэтому приходится мириться с кризисными явлениями как результатом давления рынка. Надо сказать, что последние годы постоянно дискутируются вопросы отношений бизнеса и образовательных учреждений на тему, кому под кого подстраиваться, а тут еще политики со своими «Болонскими конфетти» требуют стандартизации образовательных процессов и рушат привычные практики обучения.
Вот и на Пятой открытой всероссийской конференции «Преподавание информационных технологий в Российской Федерации» среди прочих вопросов активно обсуждалась программная инженерия. Профессор А.Н. Терехов наряду с докладом о ПИ и о том, как ей обучать студентов, представил перевод «Рекомендаций по преподаванию программной инженерии и информатики в университетах», изданный Интернет-университетом информационных технологий. Это два документа — Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering и Computing Curricula 2001: Computer Science. Они представляют собой заключительный отчет специальной объединенной комиссии ACM и IEEE Computer Science, содержащий рекомендации по преподаванию ПИ и информатики, а также типовые учебные планы по этим дисциплинам.
Если разговоры об образовательных стандартах на этой конференции уже не достигали накала высокого градуса, как в прошлые годы, то примерка к тому, как учат на Западе ПИ, а у нас тому же самому, но под названием «системное программирование», проходила спокойно, и основной отмеченный недостаток не был связан со спором о том, переходить ли на новый термин, а касался болевой точки — привязки содержимого учебных курсов к рыночным отношениям. Данная книга и, по нашему мнению, весьма представительная библиотека трудов, написанных В. В. Липаевым (их список можно найти в издании, упомянутом в начале работы, или на сайте www.sinteg.ru издателя В.Л. Гуревича), позволяют достаточно глубоко вникнуть в тему, посвященную программной инженерии.
Модель вычислительного процесса