CC BY-NC-ND
228
ПРОБЛЕМЫ РАЗВИТИЯ ПРОГРАММНОЙ ИНЖЕНЕРИИ И НЕКОТОРЫЕ ФРАГМЕНТЫ
ИХ РЕШЕНИЯ
В.В. Липаев, главный научный сотрудник Института системного программирования РАН, профессор ГУ-ВШЭ.
Еще в 70-е гг. стало ясно, что неформальный подход к созданию программных продуктов не эффективен при разработке больших программных систем. Стоимость таких проектов многократно возрастала по сравнению с первоначальными оценками, программные системы получались ненадежными, сложными в эксплуатации и сопровождении. Стоимость аппаратных средств относительно быстро снижалась, тогда как стоимость программных продуктов стремительно возрастала.
Новая вычислительная техника позволяла воплощать в жизнь не реализуемые ранее крупные программные продукты. В результате программные комплексы в 80-е гг. достигли размеров и уровня сложности, намного превышающих аналогичные показатели у программных систем, реализованных на вычислительной технике предыдущих поколений. Массовое создание сложных программных продуктов промышленными методами и большими коллективами специалистов потребовало их четкую организацию, планирование работ по требуемым ресурсам, этапам и срокам реализации. Возникла необходимость в новых технологиях, методах создания и управления сложными проектами больших программных систем.
Благодаря развитию операционных систем и инструментальных средств универсальных персональ-
ных ЭВМ и серверов накапливались готовые программные компоненты, и сокращалась необходимость их программирования. Это приводило к увеличению роли интеграции таких компонентов, соответствующих методов и инструментария программной инженерии. Однако вследствие их принципиальной новизны и сложности, они трудно воспринимались традиционными программистами компонентов и множеством преподавателей отечественной высшей школы. Коренные отличия между методами и инструментарием индивидуального, «художественного» программирования небольших программ, и технологией планомерной, регламентированной, инженерной разработки крупных программных продуктов приводили к тому, что последние медленно осваивались и входили в практику работы больших коллективов специалистов. Эти обстоятельства стали причиной существенного отставания от мирового уровня по конкурентоспособности, количеству и качеству отечественных программных продуктов.
Сохраняется и обостряется ряд практических проблем в процессе разработки программных систем, на решение которых затрачивается много времени и средств. Реализация крупных программных проектов встречается с подобными проблемами, что дает право некоторым специалистам утверждать, что современная технология создания программных
продуктов находится в состоянии хронического кризиса. Тем не менее, быстро возрастает как общий объём производства программных продуктов, так и сложность отдельных проектов. Необходимость взаимодействия вычислительной и коммуникационной техники предъявляет новые системотехнические требования к специалистам по программным комплексам. Это одна из причин возникновения проблем при разработке крупных программных продуктов. Многие компании, занимающиеся производством программных средств (ПС), не уделяют должного внимания эффективному применению современных методов автоматизации и обеспечения всего их жизненного цикла.
Ниже проанализированы основные современные проблемы развития и применения методологии программной инженерии. Эти проблемы и их компоненты в разной степени могут отражаться на экономике, качестве и конкурентоспособности отечественных программных продуктов. На них целесообразно обращать внимание и по возможности решать заказчикам, руководителям и разработчикам крупных программных проектов.
Крупные комплексы программ являются компонентами систем, реализующими обычно их основные, функциональные свойства и создающими предпосылки для последующих изменений их жизненного цикла (ЖЦ). Реализация ЖЦ, методология управления и изменения ПС зависит от квалификации специалистов, технических, организационных и договорных требований и сложности проекта. Множество текущих состояний и модификаций компонентов в ЖЦ сложных ПС менеджерам необходимо упорядочивать, контролировать их развитие и реализацию участниками проекта. Организованное, контролируемое и методичное отслеживание динамики изменений в ЖЦ программ и данных, их разработка при строгом учете и контроле каждого изменения, является базовой проблемой эффективного, поступательного развития каждой крупной системы методами программной инженерии.
Проблема освоения знаний программной инженерии
Накопление знаний, опыта разработки и применения огромного количества различных сложных программ для ЭВМ способствовало систематизации и обобщению методов и технологий их разработки, сокращению дефектов и неопределенностей в характеристиках и качестве поставляемых и применяемых программных продуктов. В результате в 90-е гг. сформировалась современная методология и дисциплина обеспечения процессов ЖЦ
сложных программных продуктов — программная инженерия для различных областей применения.
Программная инженерия — область компьютерной науки и технологии; занимается построением программных систем, настолько больших и сложных, что для этого требуется участие крупных команд разработчиков различных специальностей и квалификаций. Такие системы существуют и применяются долгие годы, развиваясь от версии к версии, претерпевая на своем жизненном пути множество изменений, улучшение существующих функций, добавление новых или удаление устаревших возможностей, адаптацию для работы в новой среде, устранение дефектов и ошибок. Суть методологии программной инженерии состоит в применении систематизированного, научного и предсказуемого процесса планирования, проектирования, разработки и сопровождения сложных программных продуктов.
Исследования и опыт разработки проектов методами программной инженерии, позволили в 90-е гг. накопить большой материал для обобщения и создания методологической концепции комплекса знаний в этой новой области. Необходимая селекция и концентрация основных проблем, методов и публикаций, проводилась под руководством специалистов организации IEEE Computer Society Professional Practices Committee, завершившаяся в 2004 г. опубликованием соответствующего документа, в 2005 г. получившего статус международного стандарта ISO.
Программные средства все больше встраиваются в различные сложные системы. Работа с такими проектами требует от программного инженера широкого взгляда на общие проблемы проектирования систем. Инженеру необходимо участвовать в выработке требований для всей системы, пытаться понять прикладную область применения ПС еще до начала обдумывания абстрактных компонентов и их интерфейсов, требованиям которых должен будет отвечать программный продукт. Важен поиск компромисса задач и функций проекта.
Целевое управление проектами — рациональное использование и предупреждение потери ресурсов путем сбалансированного распределения их по частным работам на протяжении всего ЖЦ объекта с заданным качеством. Управление проектом — особый вид деятельности, включающий постановку задач, подготовку решений, планирование, организацию и стимулирование специалистов, контроль хода работ и использования ресурсов при создании сложных систем. Целевое управление проектами возникло в середине прошлого века из необходимости разрабатывать и реализовывать сложные
системы с заданными функциями в максимально короткие сроки при ограниченных ресурсах. Критическим параметром планирования и управления проектами обычно является время. Основная проблема целевого управления работами — сводить воедино усилия исполнителей, специалистов разной квалификации, подрядчиков и субподрядчиков, чтобы они выступали как команда, а не как разрозненная группа функциональных специалистов при создании компонентов систем. В результате должны обеспечиваться концептуальная целостность системы и высокое качество решения главных целей при сбалансированном использовании ресурсов на все функциональные задачи.
Рациональное сочетание целей, стратегий действий, конкретных процедур и доступных ресурсов необходимо для достижения поставленной основной цели получения программного продукта с заданным качеством. Базой эффективного управления проектом программного средства является план. Задачи исполнителей частных работ должны быть согласованы с выделяемыми для них ресурсами, а также между собой по результатам и срокам их достижения. Планирование проектов ПС должно обеспечивать компромисс между требующимися характеристиками создаваемой системы и ограниченными ресурсами, необходимыми на её разработку и применение.
Проблемы развития и освоения экономики
программной инженерии
Приступая к разработке крупных проектов, руководители должны понять, целесообразно ли их создание и оценить эффективность применения готового продукта, оправдаются ли затраты на его разработку и использование. Поэтому такие проекты традиционно начинаются с анализа и разработки технико-экономического обоснования (ТЭО) предстоящего ЖЦ и эксплуатации предполагаемого продукта. Заказчику проекта надо оценивать реальную потребность в его создании и возможную конкурентоспособность, а потенциальному разработчику — оценивать реализуемость проекта в условиях и ресурсах, предлагаемых заказчиком. Обоснование проектов на начальном этапе их развития должно содержать оценки экономических рисков реализации поставленных целей, обеспечивать возможность планирования и выполнения ЖЦ продукта или указывать на недопустимо высокий риск его реализации и целесообразность прекращения разработки.
Проблемы в том, что руководители и разработчики комплексов программ, как правило, не знают
основ экономики разработки и производства сложной продукции, а экономисты не представляют сущность объектов разработки ПС, а также особенностей их создания, технологического процесса и применения. Объективно положение осложнено трудностью измерения характеристик таких объектов. Широкий спектр количественных и качественных показателей, которые с различных сторон характеризуют содержание этих объектов, и невысокая достоверность оценки их значений определяют значительную дисперсию при попытке описать и измерить свойства создаваемых или используемых программных продуктов.
Развитие и применение методов ТЭО проектов ПС осложнены в ряде случаев, неопределенностью характеристик предполагаемого продукта, технологических этапов и процессов разработки, производства и применения программ для ЭВМ. При разработке комплексов программ сложно переплетаются содержание, этапы и распределение работ. Возможен ряд возвратов на более ранние технологические этапы в процессе создания компонентов ПС. Они имеют не совсем определенные границы начала и завершения. Специалисты в коллективе могут на некотором интервале времени решать несколько производственных задач и заменять друг друга. Положение усугубляется трудностью поэтапного определения качества компонентов и его прогнозирования в процессе разработки. Это непосредственно отражается на технико-экономических показателях (ТЭП) проекта в целом.
Результатом становятся большие ошибки при планировании сроков, трудоемкости и стоимости создания ПС. Стихийность экономических характеристик при создании крупных комплексов программ приводит к запаздыванию разработок и превышению предполагавшихся затрат. Практика последних лет показывает, что из-за пренебрежения тщательным ТЭО до 15% проектов сложных программных комплексов не доходит до завершения, а почти половина проектов не укладывается в выделенные бюджет и сроки, не обеспечивает требуемые характеристики качества. Типичны ситуации, когда отставание сроков внедрения промышленных систем управления и обработки информации полностью зависит от неготовности программных продуктов (ЕГАИС).
Недостатки или отсутствие ТЭО проектов новых ПС вызывают острые конфликты между заказчиками и разработчиками. Часто разработчики ПС не в состоянии привести заказчику или руководителю проекта обоснованные доказательства нереальности выполнения выдвигаемых требований при
предложенных ограниченных значениях бюджета и сроков. Это может приводить к оптимистической переоценке выгод новой программной разработки, к недооценке роли других конкурирующих предложений при заключении контрактов на разработку, и к неизбежным перерасходам средств и к снижению качества ПС. Руководители конкретных проектов ПС зачастую не в состоянии обоснованно определить, сколько времени и затрат труда потребуется на каждый этап программной части проекта системы; не могут оценить, насколько успешно выполняется план разработки ПС. Это означает, что программная часть проекта системы с самого начала выходит из-под экономического контроля и возможна катастрофа с реализацией и завершением проекта всей системы в требуемый срок с заданным качеством.
Проблема экономического прогнозирования развития проектов в программной инженерии заключается в освоении и использовании методик и пакетов прикладных программ для расчета ТЭП реальных крупных проектов. Цель ТЭО проектов комплексов программ определять:
^ целесообразно ли продолжать работы над конкретным проектом ПС в направлении детализации требований, функций и технико-экономических характеристик или следует его прекратить, по причине недостаточных ресурсов специалистов, времени или возможной стоимости и трудоемкости разработки; ^ при наличии достаточных ресурсов, следует ли провести маркетинговые исследования для определения рентабельности полного выполнения проекта ПС и создания программного продукта для поставки на рынок; ^ достаточно ли полно и корректно формализованы требования к проекту ПС, на основе которых проводились расчеты ТЭП, или их следует откорректировать и выполнить повторный анализ с уточненными исходными данными; ^ есть ли возможность применить готовые повторно используемые компоненты ПС, в каком относительном размере от всего комплекса программ, и рентабельно ли их применять в конкретном проекте ПС, или весь проект целесообразно разрабатывать как полностью новый.
Проблема определения требований и характеристик качества комплексов программ
Эта проблема присуща крупным, наукоемким проектам комплексов программ. Однако многочисленные спекуляции разработчиков на их значении
приучила заказчиков не доверять рекламируемым достоинствам и качеству программных продуктов. Во многих случаях контракты и предварительные планы на создание сложных ПС и баз данных подготавливаются и оцениваются на основе неформализованных представлений заказчиков и разработчиков о требуемых функциях и характеристиках качества систем. Многочисленные провалы проектов ПС выявили необходимость формализации методов взаимодействия и обеспечения взаимопонимания разработчиков с заказчиком или потенциальными пользователями создаваемого ПС с самого начала проекта с целью конкретизации его функций и уточнения требований к качеству. Ошибки, обусловленные неопределенностью или некорректностью технических заданий и спецификаций требований, могут и должны быть выявлены на ранних стадиях проектирования. Это способствует его ускорению и повышению качества.
Возрастание сложности и ответственности современных задач, решаемых крупными системами, а также возможного ущерба от недостаточного качества комплексов программ, значительно повысило актуальность проблемы освоения методов стандартизированного описания требований, и оценивания характеристик качества на различных этапах разработки ПС. Выявилась необходимость систематизации реальных характеристик качества ПС, применения стандартов для выбора из них необходимой номенклатуры и требуемых значений для конкретных проектов комплексов программ. Обещания разработчиков в контрактах с заказчиками создать высококачественные ПС в согласованные сроки во многих случаях не выполняются из-за различий в понимании требуемого качества, неумения оценить ресурсы для достижения требуемого качества программ. Стратегической проблемой в ЖЦ современных систем стало обеспечение и совершенствование качества крупных программных продуктов при реальных ограничениях на использование ресурсов разработки.
Удостоверение достигнутого качества функционирования крупных программных продуктов и методов обеспечения их ЖЦ должно базироваться на сертификации проблемно-ориентированными испытательными лабораториями. Применение сертифицированных систем качества на предприятиях-разработчиках должно гарантировать высокое, устойчивое качество процессов обеспечения ЖЦ конечного программного продукта. Основа сертификации — детальные и эффективные методики испытаний конкретных ПС, специально разработанные тестовые задачи и генераторы для их формирования,
а также квалификация и авторитет испытателей. Для этого заказчики должны выбирать подрядчиков-исполнителей своих проектов, имеющих системы обеспечения качества ПС и сертификаты, удостоверяющие реализацию и применение системы качества предприятием-разработчиком.
Неопределенности концепции и характеристик безопасности конкретных систем, включающих программные продукты, должны учитываться заказчиками, пользователями и разработчиками в течение всего их ЖЦ. Чем сложнее системы и чем выше к ним требования безопасности, тем неопределеннее функции и характеристики их безопасности. Неопределенности начинаются с требований заказчиков. При формулировке технического задания и спецификаций они не полностью формализуют и принципиально не могут обеспечить достоверное содержание всего адекватного набора характеристик и значений безопасности, которые должны быть при завершении проекта и предъявлении конечного продукта заказчику. Эти требования итерационно формируются, детализируются и уточняются по согласованию между всеми участниками проекта и обусловлены ограниченностью первичных исходных данных и изменением их под влиянием объективных и субъективных воздействий со стороны различных процессов на последовательных этапах ЖЦ.
В требованиях технических заданий и реализованных проектах сложных систем систематически умалчиваются и/или недостаточно формализуются понятия и метрики безопасности программного продукта и выдаваемой информации, какими характеристиками они должны описываться, как их следует измерять и сравнивать с требованиями, отраженными в контракте, техническом задании или спецификациях. Некоторые характеристики безопасности часто вообще отсутствуют в требованиях заказчика и согласованных документах на систему и/или ПС. Это приводит к произвольному их учёту или к пропуску при испытаниях. Тщательное специфицирование, оценивание и повышение безопасности систем, программного продукта и обработанной для потребителей информации — ключевая проблема обеспечения их адекватного и эффективного применения.
Выделились области анализа и обеспечения информационной безопасности (связанные, с защитой от предумышленных, негативных воздействий на информационные ресурсы систем) и функциональной безопасности (обусловленной отказовыми ситуациями и потерей работоспособности систем и ПС вследствие проявления непредумышленных, случайных дефектов и отказов программ, данных, аппаратуры или внешней среды).
Обеспечение функциональной безопасности при случайных, дестабилизирующих воздействиях и отсутствии злоумышленного влияния на системы, ПС или информацию баз данных существенно отличается от задач информационной безопасности. Функциональная безопасность объектов и систем зависит от отказовых ситуаций, негативно отражающихся на работоспособности и реализации их основных функций. Причинами могут быть дефекты и аномалии в аппаратуре, программах, данных или вычислительных процессах. При этом катастрофически, критически или существенно искажается процесс функционирования систем, что наносит значительный ущерб при их применении. Основные источники отказовых ситуаций: некорректные исходные требования; сбои и отказы в аппаратуре; дефекты или ошибки в программах и данных функциональных задач, проявляющиеся при их исполнении в соответствии с назначением. В реальных сложных системах, связанных с безопасностью, возможны катастрофические последствия и отказы функционирования с большим ущербом при отсутствии воздействия лиц, заинтересованных в нарушениях работоспособности систем и ПС. Вредные и катастрофические последствия таких отказов в ряде областей применения систем могут превышать по результатам последствия злоумышленных воздействий, имеют свою природу, особенности и характеристики.
Проблема выделения факторов, определяющих
риски программных продуктов
Оценки качества программных средств в ЖЦ могут проводиться с позиции положительной эффективности и непосредственной адекватности их характеристик назначению, целям создания и применения, а также с негативной позиции возможного при этом ущерба — риска при создании или использовании программного продукта или системы. Характеристики качества и риски объектов и процессов обычно тесно связаны. На них влияют подобные факторы, которые с разных сторон отражаются в свойствах систем или комплексов программ. Риски проявляются как негативные последствия разработки, функционирования и применения ПС, способные вызвать ущерб системе, внешней среде или пользователю, в результате отклонения характеристик объектов или процессов от заданных требований заказчика, согласованных с разработчиками. Риски ПС могут проявляться в процессе проектирования, разработки и сопровождения при изменении и развитии комплексов программ и при применении готового программного продукта по прямому назначению.
Риски при случайных, дестабилизирующих воздействиях дефектов при реализации проекта и отсутствии предумышленного негативного влияния на систему, ПС или информацию баз данных зависят от отказовых ситуаций, отрицательно отражающихся на работоспособности и оперативном выполнении их основных функций. Причинами могут быть дефекты и аномалии в аппаратуре, программах, данных или вычислительных процессах. Ос-новныме источниками отказовых ситуаций: некорректные исходные требования; сбои и отказы в аппаратуре; дефекты или ошибки в программах и данных функциональных задач, проявляющиеся при их исполнении в соответствии с назначением.
Анализ рисков должен начинаться с исследования понятий, требований и функций, способствующих разработке, одобрению и применению заказчиком и пользователями конкретного программного продукта. Должны быть определены требования к характеристикам ПС и оценки возможного ущерба при их нарушении. Эти потери — ущерб проектов — могут быть значительно сокращены своевременным анализом, прогнозированием и корректированием рисков возможного нарушения требований контрактов, технических заданий и спецификаций на характеристики, выделяемые ресурсы и технологию создания комплексов программ.
Управление рисками предполагает понимание и оценку внутренних и внешних причин и реальных источников угроз, влияющих на качество проекта ПС, которые могут привести к его провалу или большому ущербу. Главная цель управления рисками — обнаружение, идентификация, контроль за ситуациями и факторами, которые приводят к негативным — рисковым результатам проекта. Это должно отражаться на применении регламентированных процессов, в которых факторы и угрозы рисков систематически идентифицируются, оцениваются и корректируются. В ЖЦ программных средств ущерб может проявляться:
^ в искажениях или неполной реализации требуемого назначения, функций или взаимодействия ПС с компонентами системы или внешней среды — недостатками и дефектами функциональной пригодности комплексов программ;
^ в недостаточных требованиям к конструктивным характеристикам качества ПС при его функционировании и применении по прямому назначению; ^ в нарушениях ограничений на использование экономических, временных или технических ресурсов при создании и применении ПС.
Риски проектов могут быть обусловлены нарушениями технологий или ограничениями при использовании ресурсов — бюджета, планов, коллектива специалистов, инструментальных средств, выделенных на разработку ПС. Результирующий ущерб в совокупности зависит от величины и вероятности проявления каждого негативного воздействия. Одним из косвенных методов определения величины риска может быть оценка совокупных затрат для ликвидации негативных последствий в программном продукте, системе или внешней среде, в результате конкретного рискового события.
Проблемы выбора и применения стандартов программной инженерии
В середине 70-х гг. начал разрабатываться комплекс отечественных стандартов Единой системы программной документации (ЕСПД) по аналогии со стандартами конструкторской документации. Эти стандарты ориентированы на программирование относительно простых программ универсальных ЭВМ, создаваемых и применяемых в основном в пакетном режиме. Они не регламентировали процессы ЖЦ сложных ПС реального времени и имели ограниченную сферу применения. Для регламентирования процессов программной инженерии в начале 80-х гг. разработаны комплексы стандартов на ряде отечественных оборонных предприятий для внутреннего использования в собственных проектах. Эти нормативные документы отражали специфику разработок конкретных программных продуктов для военных систем реального времени и не утверждались как государственные. С середины 90-х гг. в области стандартизации программной инженерии принята стратегия перевода на русский язык международных стандартов, их адаптация и утверждение в качестве Государственных стандартов. В представленных ниже международных стандартах многие имеют статус ГОСТ Р.
Основные концепции программной инженерии в 90-е гг. сконцентрировались, детализировались и формализовались в целостном комплексе систематизированных международных стандартов, охватывающих и регламентирующих практически все процессы ЖЦ сложных ПС. Эти стандарты сконцентрировали и формализовали опыт, технологии разработки и сопровождения крупных программных продуктов высокого качества в различных отраслях народного хозяйства и оборонной техники. Несколько десятков стандартов этого комплекса допускают целеустремленный отбор необходимых унифицированных процессов в зависимости от характеристик и особенностей конкретного проекта,
а также формирование на их базе проблемно-ориентированных профилей стандартов для определенных типов проектов и/или предприятий.
Практическое применение стандартов, сосредоточивших мировой опыт создания различных типов крупных комплексов программ, способствует значительному снижение стоимости, трудоемкости, длительности и улучшение других ТЭП проектов крупных программных продуктов, повышению производительности труда специалистов и качества создаваемых продуктов. ЖЦ крупных ПС отражается в стандартах набором процессов, этапов, частных работ и операций в последовательности их выполнения и взаимосвязи, регламентирующим ведение разработки, сопровождение и эксплуатацию — от анализа и подготовки требований до завершения испытаний ряда версий программного продукта и прекращения их использования. Стандарты включают описания исходной информации, способов и методов выполнения операций и работ, устанавливают требования к результатам и правилам их контроля, определяют содержание технологических и эксплуатационных документов, организационную структуру коллектива специалистов, регламентируют распределение и планирование работ, а также контроль за ходом разработки, определяют модификацию, мобильность и возможность повторного применения программных компонентов и комплексов, их расширяемость и переносимость на различные аппаратные и операционные платформы, что непосредственно отражается на росте экономической эффективности технологий и создании различных программных продуктов и систем.
Комплексное, скоординированное применение стандартов в процессе создания, развития и применения ПС позволяет исключать многие виды дефектов или значительно ослаблять их влияние. Тем самым уровень достигаемого качества ПС становится предсказуемым и управляемым, непосредственно зависящим от ресурсов, выделяемых на его достижение, а главное, от системы качества и эффективности технологии, используемых на всех этапах жизненного цикла ПС.
Важная проблема внедрения стандартизации программной инженерии — психологическая. Стандарты регламентируют определенную дисциплину трудового процесса коллективов специалистов при создании и применении крупных программных продуктов требуемого качества при ограниченных ресурсах. Для этого необходимо изучение и освоение соответствующих стандартов, корректное применение их требований и рекомендаций всеми участниками
крупных проектов ПС. По мере возрастания размеров проектов и ответственности за качество и безопасность применения программных продуктов совершенствуются технологии их создания, повышаются требования к полноте и корректности применения стандартов. Это должно обеспечивать повышение экономической эффективности и конкурентоспособности ЖЦ крупных программных продуктов. Накопленный капитал международных стандартов программной инженерии в значительной степени обеспечивает современный, регламентированный ЖЦ комплексов программ и продолжает успешно развиваться и совершенствоваться. Это требует от коллективов разработчиков программных продуктов дополнительных усилий для мониторинга номенклатуры, текущего состояния и адаптации стандартов.
Проблема оценивания и выбора квалифицированных и надежных специалистов-подрядчиков
Подрядчики-разработчики должны быть способны создавать сложные программные продукты и базы данных, требуемого качества в разумные сроки, с учетом ограничений на используемые ресурсы. Для её решения поставщикам комплексов программ, кроме программистов-кодировщиков, необходимо иметь: системных аналитиков, архитекторов и топ-менеджеров проектов ПС, специалистов по ком-плексированию, испытаниям и обеспечению качества современных сложных программных продуктов. Они должны знать передовые, индустриальные методы, технологии и международные стандарты, поддерживающие и регламентирующие жизненный цикл ПС, инструментальные системы обеспечения качества, верификации, тестирования и сертификации программных средств. Для этого требуется системотехническая квалификация предприятий и специалистов, берущихся за создание крупных ПС высокого качества.
Проблемы организации структуры и состава
коллектива специалистов для проектов крупных
программных продуктов.
Накопленный к 90-м гг. опыт создания крупных комплексов программ и острый дефицит соответствующих специалистов отразились на необходимости принципиального изменения методов и программ их обучения. Быстрый рост сложности и повышение ответственности за качество комплексов программ привели к появлению новых требований к обучению и к дифференциации специалистов по программной инженерии, обеспечивающих основные этапы ЖЦ ПС. Стало ясно, что специалистам
недостаточно навыков процедурного программирования небольших компонентов; необходимы глубокие знания системотехники, технологии и стандартов проектирования, методов обеспечения и контроля качества сложных комплексов программ в определенной области их применения. Эти специалисты должны владеть новой интеллектуальной профессией, обеспечивающей высокое качество программных продуктов и контроль, испытания и удостоверение реального достигнутого качества на каждом этапе разработки и совершенствования программ. Крупномасштабное проектирование ПС различных классов, разделение труда специалистов по квалификации при разработке программ и данных, структура и организация коллективов, а также экономика таких разработок стали важнейшей составляющей выбора и обучения специалистов для обеспечения всего ЖЦ сложных программных продуктов.
В ЖЦ сложных комплексов программ участвуют специалисты различной квалификации и степени ответственности за результаты своей деятельности:
^ заказчики определяют и несут ответственность за финансирование, требования к функциям и качеству программного продукта и за доступные, адекватные ресурсы для обеспечения его ЖЦ;
^ разработчики должны гарантировать и отвечать за выполнение требований заказчиков программного продукта с учетом выделенных ресурсов;
^ пользователи имеют право применять программный продукт и адаптировать его к особенностям использования и внешней среды только в пределах, определенных эксплуатационной документацией, созданной разработчиками.
Для организации эффективной структуры коллектива разработчиков ПС следует учитывать согласованность конкретных целей специалистов, участвующих в проекте, их психологическую совместимость, способность к дружной коллективной работе, наличие опыта взаимодействия в составе определенного коллектива, объективные и субъективные свойства участников проекта. Большое значение имеет личная мотивация и психологические особенности поведения разных специалистов при комплексной работе над сложным проектом. Эти характеристики могут быть обобщены в качественный показатель влияния сложности взаимодействия специалистов в коллективе, которому могут быть сопоставлены оценки возможного изменения
эффективности разработки ПС. Наилучшим считается непрерывное корректное взаимодействие организованных специалистов с большим опытом работы в конкретном коллективе при согласованности их целей, планов и методов работы. В остальных случаях в той или иной степени (даже в 3—5 раз) может возрастать трудоёмкость разработки ПС, что нельзя не учитывать при обосновании крупных проектов.
Уровень квалификации заказчика и определенность технического задания на разработку ПС может сильно влиять на суммарные затраты и длительность создания комплекса программ. Первоначальное техническое задание зачастую оказывается недостаточно квалифицированным и подвергается в дальнейшем многократным изменениям. Изменения технического задания заказчиком объем переделок непосред-ственно отражаются на производительности труда специалистов. Достоверность технического задания может влиять на попытки заказчика форсировать сроки разработки. Этому же может способствовать различие между заказчиком и разработчиком в квалификации, уровне понимания целей разработки и необходимых затрат на реализацию возникающих дополнительных требований. Даже при испытаниях заказчик зачастую обнаруживает, что решаются не тезадачи и не совсем так, как ему нужно, поэтому необходима большая переработка готовых программ. Даже квалифицированные заказчики вынуждены иногда корректировать техническое задание на любых этапах разработки, что снижает производительность на 10—20%. Представители заказчика, участвующие в проекте, должны обучаться формализации автоматизируемых функций систем и технологических процессов, для которых предназначены соответствующие программные продукты, и иметь представление об эффективных путях их реализации.
При разработке сложных программ большими коллективами значительно повышается роль квалификации руководителей проекта, что непосредственно отражается на производительности труда всего коллектива. Известны случаи, когда только вследствие квалификации руководителей крупных проектов суммарные затраты на разработку изменялись в несколько раз как в лучшую, так и в худшую сторону. Некоторые методы организации структуры коллектива и процессов разработки, позволяют сокращать негативное влияние человеческого фактора. Однако формализовать и учесть влияние особенностей конкретного руководителя разработки и ведущих специалистов на реализацию комплекса программ трудно.
Разработчики должны иметь в своем составе квалифицированных менеджеров, проблемно-
ориентированных системных архитекторов, способных переводить не всегда полные и корректные функциональные требования заказчиков в конкретные спецификации и технические требования к комплексам программ и к их компонентам. Специалисты по проектированию сложных ПС (системные архитекторы) должны иметь хорошую подготовку по системному анализу алгоритмов и комплексов программ в определенной проблемной области, по методам оценки эффективности проектов, организации и планированию крупных разработок компонентов программ и баз данных. Им необходима высокая квалификация по архитектурному построению, комплексной отладке и испытаниям ПС определенных классов, умение организовать коллектив для решения общей целевой задачи системы. Это позволит на ранних этапах исключать или сокращать дефекты, обусловленные различием представления ими целей и задач проектов, а также их показателей качества.
Для создания высококачественных комплексов программ, прежде всего, необходимо обучение специалистов, процессам организации взаимодействия представителей заказчика и разработчиков проекта. Взгляды и требования заказчика, в основном, отражаются на функциональных и потребительских характеристиках ПС. Устремления разработчиков направлены на способы их реализации с требуемым качеством. Эти различия исходных интересов и точек зрения на проект приводят к тому, что некоторые неформализованные представления тех и других имеют зоны неоднозначности и взаимного непонимания, что может приводить к конфликтам. Организация четкого взаимодействия и сокращение этих зон требует определенных мероприятий и контактов по обмену знаниями в процессе проведения совещаний, взаимному повышению квалификации и обучению.
Принципиальный путь улучшения экономических характеристик при разработке сложных ПС — исключение творчества на тех этапах, где возможны типовые, стандартные решения и использование апробированных заготовок программных компонентов, не требующие при их применении высококвалифицированного творческого труда. Основа такого подхода — применение унифицированной технологии, готовых, испытанных программных компонентов и стандартизированной архитектуры определенных классов ПС. Использование готовых апробированных модулей и компонентов может почти исключать творческий труд по их программированию, автономной отладке и документированию. На этих этапах творческие усилия необходимы для отбора и контроля готовых компонентов,
а также для разработки новых, отсутствующих среди апробированных. Однако практически полностью сохраняется творческий труд при системном анализе, при комплексировании компонентов и их отладке, а также во время испытания программного продукта в целом.
Проблемы организации коллективов специалистов
для проектов крупных программных продуктов
Для реализации крупных проектов наиболее часто применяются две схемы организации коллективов, которые должны осваиваться при обучении специалистами:
^ формирование для выполнения каждого крупного проекта жесткой организационной структуры целостного коллектива с полным составом необходимых специалистов под единым, централизованным руководством лидера проекта;
^ выделение руководителя (главного конструктора) и небольшой группы интеграторов, по заданиям которых выполняются частные работы узкими специалистами по компонентам, не входящими организационно в единый коллектив для реализации каждого конкретного крупного проекта.
Первая схема предпочтительна, когда предприятие реализует небольшое число особенно крупных проектов-заказов и имеет возможность для каждого из них комплектовать полноценную, организационно замкнутую, «команду». Она полностью реализует проект и несет ответственность за его качество. Однако при этом возможны простои отдельных специалистов из-за несинхронного ожидания заданий или результатов на последовательных этапах разработки компонентов другими специалистами.
Вторая схема имеет преимущества для предприятия при большом числе относительно небольших проектов, близких по содержанию и функциональному назначению компонентов. В этом случае большинство специалистов одновременно участвуют в нескольких заказах по локальным заданиям лидеров и интеграторов различных проектов, и может использоваться полнее. Однако задачи интеграторов при этом усложняются и требуют более высокой квалификации. Хотя за качество проекта в целом также несут ответственность руководитель — лидер и группа интеграторов, однако усложняется взаимодействие с поставщиками компонентов, руководство и контроль их качества.
В обеих схемах для реализации мероприятий по планированию и управлению ЖЦ концептуально
целостных, крупных ПС и обеспечения их качества необходимы организационные действия системных архитекторов, направленные на подбор и обучение коллектива специалистов разных категорий и специализаций. Практически в каждом успешном проекте должен быть лидер. Лидером продукта может быть: менеджер продукта, менеджер проектирования, руководитель проекта. Лидер должен иметь талант, квалификацию и обучен:
^ руководить процессом выявления, конкретизации и формирования требований заказчика проекта;
^ осуществлять проверку спецификаций программного средства, чтобы удостовериться, что они соответствуют реальной концепции, представленной детальными функциями;
^ вести переговоры с заказчиком, руководством, пользователями и разработчиками, определять и поддерживать равновесие между тем, чего хочет заказчик, и тем, что может создать команда разработчиков за ресурсы и время, выделенные заказчиком для реализации проекта;
^ рассматривать конфликтующие пожелания от различных участников проекта и находить компромиссы, необходимые для определения набора функций, представляющих наибольшую ценность для максимального числа участников и проекта в целом.
Крупные проекты требуют координированной работы больших коллективов или даже ряда команд. Возрастание сложности проекта снижает способность человека решать задачи интуитивно по мере их возникновения. Чтобы добиться успеха в большом проекте, необходима четкая координация действий членов команды, которая должна работать по общей утвержденной методологии, чтобы решить проблему реализации комплекса требований и качества программного продукта эффективно организованной командой разработчиков.
Один из наиболее важных факторов — члены команды имеют различные талант, профессиональные навыки и квалификацию. Поэтому при обучении специалистов важно учитывать возможную структуру большой команды. Успех и качество при разработке сложных программных комплексов зависит от слаженности работы, квалификации и профессионализма коллектива и перечисленных категорий специалистов на всех этапах и уровнях создания крупных проектов. При выборе заказчиком надежного поставщика-разработчика проекта необходима оценка тематической и технологической квалификации возможно-
го коллектива специалистов, его способности реализовать проект с заданными требованиями и качеством. Тематическую квалификацию специалистов в области создания ПС определенного функционального назначения приближенно можно характеризовать средней продолжительностью работы в данной проблемной области основной части команды, непосредственно участвующей в разработке алгоритмов, спецификаций требований, программ и баз данных. Технологическая квалификация коллектива характеризуется опытом и длительностью работы с регламентированными технологиями, инструментальными комплексами автоматизации программной инженерии, языками проектирования, программирования и тестирования ПС. Важнейшую роль при этом играет квалификация руководителей — лидеров разработки и системных аналитиков функциональных компонентов и в меньшей степени непосредственных разработчиков программных компонентов в конкретной прикладной области. Особенно важны, не столько индивидуальные характеристики каждого специалиста, сколько интегральный показатель квалификации команды, реализующей некоторую, достаточно крупную функциональную задачу или весь проект.
Интегральные затраты на создание и сопровождение новых версий сложных программных продуктов могут значительно превосходить затраты на разработку их первой версии. Это приводит к тому, что по мере накопления эксплуатируемых ПС и их компонентов все большее число специалистов переходит из области непосредственного программирования новых программ в область системного проектирования, управления конфигурацией и создания новых версий программного продукта на базе повторно используемых компонентов. По некоторым оценкам, непосредственным программированием новых компонентов в мире занято только около 15—20% специалистов, участвующих в создании программных продуктов.
Проблемы обучения методологии программной
инженерии
Специализация и квалификация персонала, участвующего в крупных проектах программных продуктов, требуют соответствующей их подготовки, отбора и обучения. Это — самостоятельная, важная проблема развития программной инженерии. Обучение — сложный процесс и требует организации и сопровождения обучаемого персонала. Должны быть разработаны и документированы планы, требования и цели обучения, разработаны учебники и руководства, включая материалы,
используемые для обучения. Персонал, ответственный за выполнение конкретных задач, если это необходимо, должен быть аттестован на основе соответствующего образования, подготовки и/или опыта работы. Может стать необходимым включение в подготовку, ознакомление со специфической (проблемно-ориентированной) областью, в которой будет применяться программный продукт, и повышение квалификации в этой области.
Крупные программные продукты — наиболее сложные объекты, создаваемые человеком. Творчество специалистов, поиск новых методов, альтернативных решений и способов осуществления заданных требований, формирование и декомпозиция этих требований составляют значительную часть всех трудозатрат. Индустриализация разработки ПС позволяет автоматизировать нетворческие, технические и рутинные операции и этапы, облегчает творческий процесс за счет селекции, обработки и отображения информации, необходимой для принятия решений. Следствием этого должно являться значительное сокращение доли затрат на творческий труд в непосредственных затратах на разработку комплексов программ. Как в любой инженерной отрасли, программный инженер должен развивать умения, позволяющие построить набор моделей и оценить эти модели, управляя выбором компромиссов. Он должен обладать навыками общения и межличностных отношений, уметь планировать не только свою работу, но и координировать ее с работой других специалистов.
По мере повышения квалификации коллектива и автоматизации творческой части труда следует ожидать асимптотического приближения проектов к предельным значениям относительных экономических характеристик новых разработок. Эти значения определяются интеллектуальными возможностями человека по интенсивности принятия творческих решений. Им соответствуют наличие предельных значений производительности труда и длительности разработки сложных комплексов программ. Для их оценки необходимо изучение и экстраполяция прецедентов и экспериментальных данных реальных разработок ПС с наилучшими экономическими характеристиками, с учетом возрастания квалификации специалистов и уровня автоматизации разработок. Вряд ли можно ожидать в ближайшие годы радикального повышения производительности труда при создании полностью новых, крупных программных продуктов. Еще более консервативна длительность таких разработок.
Специалисты по программной инженерии должны быть обучены и хорошо знать системотехнику
вычислительных систем, поскольку в них программный продукт играет определяющую роль. Технологии программной инженерии — критический фактор при разработке сложных вычислительных систем. Высокие темпы роста основных доступных ресурсов аппаратных средств (приблизительно на порядок каждые пять лет) и сохраняющаяся потребность в увеличении их использования со стороны различных пользователей и сфер применения требуют адекватного совершенствования технологий создания ПС и баз данных.
Методы и опыт отечественных специалистов успешного создания сложных комплексов программ высокого качества, в 60-80-е гг. были сосредоточены в основном на предприятиях оборонной промышленности. Этот опыт сегодня в значительной степени утрачен и частично устарел. Современное поколение специалистов должно вновь (почти «с нуля») создавать и осваивать методологию промышленной программной инженерии крупных программных продуктов с требуемым качеством. Для многих заказчиков и пользователей систем обострилась проблема выбора квалифицированных и надежных специалистов-подрядчиков, способных создавать сложные ПС и базы данных необходимого качества в разумные сроки, с учетом ограничений на затраты труда и другие ресурсы.
Большинство вузов этому не учит, и ограничивается обучением студентов элементам программирования только небольших простейших программ. Они не готовят системных аналитиков, архитекторов и менеджеров проектов ПС, специалистов по комплексированию, испытаниям и обеспечению качества крупных комплексов программ реального времени. Выпускники вузов не знают современных промышленных методов, технологий и международных стандартов программной инженерии, поддерживающих и регламентирующих ЖЦ ПС, инструментальных систем обеспечения качества, верификацию, тестирование и сертификацию сложных программных продуктов. Это определяет низкую системотехническую квалификацию ряда отечественных предприятий, берущихся за создание крупных ПС. В результате, многие проекты сложных ПС оказываются неконкурентоспособными, недостаточного качества, требуют длительной доработки для устранения системных и технических дефектов и ошибок.
Пробелы в обучении студентов методам программной инженерии и обеспечения требуемого качества комплексов программ при их практической деятельности оставляют широкое поле для произвола при оценивании качества программных
продуктов и к проявлению многочисленных дефектов и ошибок. Возрастание сложности и ответственности современных задач, решаемых комплексами программ реального времени, а также возможного ущерба от недостаточного качества их результатов значительно повысило актуальность освоения учащимися методов полного, стандартизированного описания требований к характеристикам качества на различных этапах ЖЦ этих ПС. Требуется освоение студентами и специалистами понятий, определений и способов оценивания реальных характеристик качества программных продуктов; систематизация реальных характеристик качества ПС; обучение студентов применению стандартов выбора из них и адаптации необходимой номенклатуры и требуемых значений характеристик для конкретных проектов комплексов программ.
Студенты, аспиранты и специалисты должны освоить современный комплекс задач, методов и стандартов промышленного создания и развития сложных, многоверсионных, тиражируемых ПС и баз данных требуемого высокого качества. Обучение должно ориентироваться на коллективную, групповую работу команд специалистов над средними и крупными программными проектами. Внимание следует акцентировать на комплексе индустриальных методов и международных стандартов программной инженерии, которые непосредственно обеспечивают эффективный ЖЦ сложных высококачественных ПС и баз данных. Необходимо обучение специалистов современной культуре промышленного создания крупных высококачественных проектов ПС. Они должны уметь формализовать требования и достигать конкретных значений характеристик функционирования и применения сложных комплексов программ с учетом тех ресурсов, которые доступны для обеспечения и совершенствования качества. Для этого надо разрабатывать и включать в учебные программы вузов по специальности «Информационные системы» учебный курс «Программная инженерия» и совокупность поддерживающих его курсов.
В последние годы в отечественных вузах появился интерес к программной инженерии; делаются попытки ввести такой курс в планы обучения студентов. В качестве основы для разработки учебных планов рассматриваются: международный стандарт «Свод знаний по программной инженерии» - ISO 19759:2005 - ТО. - SWEBOK; Рекомендации по преподаванию программной инженерии и информатики в университетах — SE2004 — www.in-tuit.ru. Эти документы близки по структуре и содержанию. Однако первый документ предусматривает для учащихся и специалистов более глубокие знания. Второй документ ориентирован на планирование обучения студентов и разработку учебных планов по программной инженерии в составе полной вузовской программы по информатике или информационным системам разных классов.
Основой базового курса может быть учебник В.В. Липаева «Программная инженерия. Методологические основы», изданный в 2006 г. Для освоения и расширения знаний, а также при подготовке преподавателями лекций в этой области, можно рекомендовать монографии В.В. Липаева по программной инженерии, аннотированные на сайте: www.ispras.ru/lipaev/index.htm. Предлагаемый курс основ методологии программной инженерии предназначен для заказчиков, менеджеров крупных проектов, для аналитиков и ведущих специалистов, обеспечивающих все этапы ЖЦ крупных ПС и систем. Курс полезен исполнителям научных проектов и опытно-конструкторских работ, к которым предъявляются высокие требования к качеству функционирования и ограничены доступные ресурсы разработки программных продуктов. Материалы лекций могут стать базой при подготовке и внедрении систем качества предприятий, создающих сложные конкурентоспособные программные продукты, для их сертификации на соответствие международным стандартам. ■
Литература
1. Боэм Б.У. Инженерное проектирование программного обеспечения. Пер. с англ. /Под ред. А.А. Красилова. - М.: Радио и связь, 1985.
2. Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения. Пер. с англ. - СПб.: БХВ-Петербург. 2005.
3. Кантор М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения. Пер. с англ. - М.: Вильямс. 2002.
4. Соммервилл И. Инженерия программного обеспечения. 6-е издание. Пер. с англ. - М.: Вильямс. 2002.
5. Фатрелл Р. Т., Шафер Д. Ф., Шафер Л. И. Управление программными проектами: достижение оптимального качества при минимальных затратах. Пер. с англ. - М.: Вильямс. 2003.
