67245

Основные ресурсы для обеспечения жизненного цикла сложных программных средств

Лекция

Информатика, кибернетика и программирование

Общее понятие доступные ресурсы обеспечения жизненного цикла ПС включает реальные финансовые временные кадровые и аппаратурные ограничения затрат в условиях которых происходит создание и совершенствование комплексов программ. Эти факторы проявляются как дополнительные характеристики процессов ЖЦ и программных...

Русский

2014-09-06

200.5 KB

21 чел.

26

PAGE  11

Лекция 9. Управление ресурсами в жизненном цикле   программных средств

9.1.  Основные ресурсы  для обеспечения  жизненного цикла                              сложных программных средств

 

         Общее  понятие  доступные ресурсы обеспечения жизненного цикла ПС включает реальные финансовые, временные, кадровые и аппаратурные ограничения затрат, в условиях которых происходит создание и совершенствование комплексов программ. В зависимости от характеристик объекта разработки на её выполнение выделяются ресурсы различных видов и размеров. Эти факторы проявляются как дополнительные характеристики процессов ЖЦ и программных продуктов, а также их рентабельности, которые следует учитывать и оптимизировать. В результате доступные ресурсы становятся косвенными критериями или факторами, влияющими на выбор методов разработки, на достигаемые качество и эффективность применения программных продуктов. Многие проекты систем терпели и терпят неудачу из-за отсутствия у разработчиков и заказчиков при подготовке контракта четкого представления о реальных финансовых, трудовых, временных и иных ресурсах, необходимых для их реализации.  Поэтому одной из основных задач при проектировании ПС является экономический анализ и определение необходимых ресурсов для  создания и обеспечения всего ЖЦ ПС в соответствии с требованиями контракта и технического задания.

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

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

В соответствии с этапами жизненного цикла ПС основные за-
траты С  , снижающие идеальную эффективность за цикл жизни t ж
, можно пред-ставить следующими составляющими ис.9.1):

    С Р   совокупные затраты на разработку программ и обеспече-
ние решения заданных функциональных задач, в том числе на тех-
нологическое обеспечение и аппаратуру ЭВМ при разработке ПС, 
в течение времени t Р ; 

   С С   затраты на сопровождение ПС за время t с , включающие
затраты на хранение и контроль их состояния, проведение модер-
низаций и исправление ошибок, тиражирование версий;

   С Э  затраты на эксплуатацию программ и аппаратные средст-
ва ЭВМ, реализующих ПС, а также совокупные потери эффектив-
ности за время t Э , вследствие ограниченных характеристик ЭВМ и н
е идеальности программ.

   В результате совокупные затраты ресурсов на программное средство - за весь жизненный цикл длительностью  t ж можно
представить в виде суммы: С Р + С С + С Э . В зависимости от назначения и области использования про-
грамм экономическую эффективность целесообразно анализиро-
вать интегрально за весь период жизни, либо дифференциально за
единицу времени (месяц, год). Для совместного анализа составля-
ющих, определяющих эффективность,  необходимо унифицировать
методы временного анализа и единицы измерения составляющих
затрат. При последующем изложении затраты рассматриваются
на длительности цикла жизни или на соответствующих интервалах
времени:  разработки,  эксплуатации и сопровождения .

   Разработка сложного ПС требует во мно-
го раз больших затрат, чем производство каждого экземпляра при
массовом тиражировании. Поэтому далее производство базового
образца программ не выделяется в  самосто-ятельный этап, а рас-
сматривается совместно с процессом разработки ПС. Производство
серийных образцов программного продукта включается в этап эксплуатации.  Экономическая-
 эффективность разработки и распре-деление ресурсов на ее
выполнение могут значительно изменяться в зави-симости от того,
является ПС уникальным или будет изготовлен в сотнях экземпля-
ров. Это обстоятельство привело к целесообразности оценки затрат
на разработку ПС не только в абсолютных значениях для опытно-
го или базового образца, но и в относительных величинах доли затрат на про-
граммы в каждом экземпляре реализующей (целевой) ЭВМ при серийном
производстве систем.

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

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

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

         Обобщенными ресурсами ЖЦ проекта ПС являются доступные стоимость или совокупные трудовые, временные  и материальные затраты, необходимые для приобретения, создания, модификации и эксплуатации компонентов и всего комплекса программ. Эти характеристики непосредственно влияют практически на все показатели качества и определяют рентабельность покупки или создания заново конкретного программного продукта. Это означает, что качество является относительным понятием, которое зависит от ресурсов и субъектов, осуществляющих его оценку с позиции эффективности использования,  а также от состояния рынка соответствующей продукции, её производителей и технологий.  Ориентация на потребителей подразумевает анализ их нужд и определение возможностей рынка удовлетворить эти потребности. При этом следует учитывать рыночную конкуренцию двух видов: между поставщиками готовых к применению программных средств с фиксированным качеством и между разработчиками, способными обеспечить жизненный цикл ПС или его существенную часть, с характеристиками качества, требующимися конкретному заказчику. В последнем случае на требуемое качество  могут оказывать влияние не только заказчик и непосредственные пользователи, но и различные посредники, организационные и торговые структуры, а также исполнители проекта.

     В начале проектирования ПС всегда возникает задача оценивания ресурсов, которые необходимы и доступны для создания и обеспечения всего ЖЦ ПС, а также возможной экономической эффективности последующего применения комплекса программ по назначению при условии реализации требуемых характеристик качества. Экономическая эффективность и затраты имеют самостоятельное значение и методологию при анализе ЖЦ ПС. При планировании проектов программных средств, часто инициатором разработки является разработчик-поставщик, который самостоятельно принимает все решения о  проектировании за счет собственных ресурсов и предполагает возместить затраты при реализации программного продукта на рынке. В других случаях имеется определенный заказчик-потребитель, который способен задать основные цели, характеристики качества и обеспечить ресурсы для реализации проекта. Таким образом,  при экономическом анализе ресурсов  проектов ПС возможны два сценария (см. лекцию 5):  

  •  создание и весь жизненный цикл комплекса программ и/или базы данных ориентируется разработчиком на массовое тиражирование и распространение на рынке, для заранее не известных покупателей-пользователей в различных сферах применения, при этом отсутствует приоритетный внешний потребитель-заказчик, который определяет и диктует основные требования, а также финансирует проект;
  •  разработка проекта ПС и/или БД предполагается поставщиком-разра-ботчиком для конкретного потребителя-заказчика, задающего требования, который его финансирует, с определенным, необходимым ему тиражом  и известной, ограниченной областью применения результатов разработки.

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

На рис. 9.1 отражены затраты на технологию, инструментальные средства автоматизации разработки и ЖЦ ПС, а также затраты на аппаратуру вычислительных систем, необходимую при обеспечении жизненного цикла комплексов программ.  Эти затраты только обозначены в данной лекции, а их  описания и оценки отнесены к лекции 16.   

9.2.  Ресурсы  специалистов для обеспечения  жизненного цикла                              сложных программных средств

Важнейшим ресурсом при создании программных средств являются люди –  специалисты, с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Быстрый рост сложности и повышение ответственности за качество комплексов программ привели к появлению новых требований к специалистам программной инженерии, обеспечивающим все этапы жизненного цикла ПС. Эти требования отражены, в частности, в восьми современных принципах управления качеством продукции и технологии (см. лекцию 1). Теперь недостаточно навыков процедурного программирования небольших компонентов, а необходимы глубокие знания системотехники, технологии проектирования, методов обеспечения и контроля качества сложных комплексов программ в определенной области применения. Эти специалисты должны владеть новой интеллектуальной профессией, обеспечивающей высокое качество ЖЦ программных средств, а также контроль, испытания и удостоверение реального достигнутого качества на каждом этапе разработки и совершенствования программ. Крупномасштабное проектирование ПС различных классов, разделение труда специалистов по квалификации при разработке программ и данных, организация коллективов и экономика таких разработок стали важнейшей частью выбора, обучения и подготовки специалистов  для обеспечения всего ЖЦ ПС.

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

 Представители заказчика, участвующие в проектировании, должны обучаться формализации автоматизируемых технологических процессов, для которых предназначены соответствующие ПС, и иметь представление об эффективных путях их реализации. С другой стороны, разработчики должны иметь в своем составе квалифицированных менеджеров, проблемно-ориентированных системных архитекторов (рис. 9.2), способных переводить функциональные требования заказчика в конкретные спецификации и технические требования к комплексу программ и его компонентам. Специалисты по проектированию сложных ПС (системные архитекторы) должны иметь, прежде всего, хорошую подготовку по системному анализу алгоритмов и пакетов прикладных программ, по методам оценки эффективности проектов, организации и планированию крупномасштабных разработок программ и баз данных. Им необходима высокая квалификация по архитектурному построению, комплексной отладке и испытаниям ПС определенных классов, умение организовать коллектив для решения общей целевой задачи системы. Это позволит на ранних этапах исключать или сокращать дефекты, обусловленные различием представления ими целей и задач проектов, а также их показателей качества.

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

         Однако в программной инженерии неуклонно повышается сложность создаваемых ПС, что вызывает возрастание затрат творческого труда на единицу размера программ. В перспективе,  не смотря на автоматизацию и повышение инструментальной оснащенности технологии разработки программ,  доля творческого труда при создании полностью новых крупномасштабных ПС возрастает. Даже при сокращении суммарных затрат на разработку программных компонентов за счет автоматизации нетворческого труда, все более определяющей для технико-экономических показателей (ТЭП) создания ПС становится доля затрат на творческий труд и возрастают требования к творческим способностям специалистов.

         Необходимость всегда выполнять значительную долю творческих работ,  которые даже для высококвалифицированных коллективов требуют определенных затрат, приводит к пониманию наличия потенциальных предельных значений ТЭП для новых разработок. По мере повышения квалификации коллектива и автоматизации творческой части труда следует ожидать асимптотического приближения к предельным значениям ТЭП. Эти предельные значения определяются интеллектуальными возможностями человека по интенсивности принятия творческих решений. Они позволили выявить предельные значения производительности труда и длительности разработки сложных комплексов программ (см. лекцию 5). Реальным путем их оценки,  является изучение и экстраполяция прецедентов и экспериментальных данных реальных разработок ПС с наилучшими ТЭП,  с учетом возрастания квалификации специалистов и уровня автоматизации разработок.  Эти факторы способствуют эволюционному, относительно медленному приближению к предельным значений ТЭП для новых ПС. Вряд ли можно ожидать в ближайшие годы повышения производительности труда на порядок при создании полностью новых, сложных программных продуктов. Еще более консервативна длительность таких разработок.

      Принципиальным путем улучшения ТЭП при разработке сложных ПС является исключение творчества на тех этапах, где возможны типовые, стандартные решения и апробированные заготовки, не требующие при их применении высококвалифицированного творческого труда. Основой такого подхода является применение унифицированной технологии, готовых испытанных компонентов и стандартизированной архитектуры определенных классов ПС. Использование готовых апробированных модулей почти исключает творческий труд по их программированию, автономной отладке и документированию. На этих этапах творческие усилия необходимы только для отбора готовых компонентов и разработки новых, отсутствующих среди апробированных. Однако практически полностью сохраняется творческий труд при системном анализе, при комплексировании компонентов и их комплексной отладке, а также во время испытания ПС в целом (см. лекцию 14).

Для реализации сложных проектов ПС наиболее часто применяются две схемы организации коллективов  специалистов:

  •  формирование для выполнения каждого проекта жесткой организационной структуры целостного коллектива с полным составом необходимых специалистов под единым, централизованным руководством лидера проекта;
  •  выделение руководителя (главного конструктора) и небольшой группы интеграторов, по заданиям которых выполняются частные работы узкими специалистами по компонентам, не входящими организационно в единый коллектив для реализации каждого конкретного крупного проекта.

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

Для реализации мероприятий по планированию и управлению жизненным циклом  концептуально целостных, крупных ПС и обеспечения их качества, необходимы организационные действия системных архитекторов, направленные на подбор и обучение коллектива специалистов разных категорий и специализаций (см. рис. 9.2). Концепция – ключевой, исходный документ сложного жизненного цикла ПС. Он непосредственно ориентирован на решение проблемы комплексной реализации требований и является документом, к которому можно обратиться в любой момент, чтобы увидеть, что продукт или система должны делать.

Практически в каждом успешном проекте должен быть или был лидер. Лидером продукта может быть: менеджер продукта, менеджер проектирования, руководитель проекта. Лидер должен:

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

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

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

Руководство крупным проектом ПС должны осуществлять один или два лидера – менеджера (см. рис. 9.2):

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

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

Специалисты первой категории непосредственно создают компоненты и ПС в целом с заданными показателями качества. В процессе разработки их функции заключаются в тщательном соблюдении принятой в фирме технологии  и в формировании всех предписанных руководствами исходных и отчетных документов. При этом  предполагается, что выбранная технология способна обеспечить необходимые значения конструктивных показателей качества, а достижение заданных функциональных характеристик гарантируется тематической квалификацией соответствующих специалистов и регулярным контролем этих характеристик в процессе разработки. Система стандартизированного документирования частных работ должна обеспечить объективное отражение качества компонентов и процессов их создания на всех этапах ЖЦ ПС (см. лекцию 17).  

Разделение труда специалистов этой категории в крупных проектных коллективах приводит к необходимости их дифференциации по квалификации и областям деятельности:

  •  спецификаторы подготавливают описания функций соответствующих компонентов с уровнем детализации,  достаточным для корректной разработки текстов программ программистами и их интерфейсов;
  •  разработчики программных компонентов  программисты создают  компоненты, удовлетворяющие спецификациям,   реализуют возможности продукта,  отслеживают и исправляют ошибки, при разработке сложных систем это требует детального знания высокоуровневых языков программирования, визуального программирования, сетевых технологий и проектирования баз данных;
  •  системные интеграторы сложных проблемно-ориентированных ПС работают над проектами в значительной степени отличными от программистов методами, на разных языках проектирования, используют различные средства автоматизации и имеют на выходе различные результаты крупных компонентов и комплексов программ;
  •  тестировщики обеспечивают проверку функциональных спецификации, систем обеспечения производительности, пользовательских интерфейсов, разрабатывают стратегию, планы и выполняют тестирование для каждой из фаз и компонента проекта, должны быть административно независимыми от программистов и спецификаторов;
  •  управляющие сопровождением и конфигурацией, инструкторы интерфейсов отвечают за снижение затрат на модификацию и сопровождение продукта, обеспечение максимальной эффективности работы разработчиков по взаимодействию компонентов и реализации версий ПС, принимают участие в обсуждениях пользовательского интерфейса и архитектуры продукта;
  •  документаторы процессов и объектов ЖЦ ПС обеспечивают подготовку и издание сводных технологических и эксплуатационных документов в соответствие с требованиями стандартов.

Успех и качество при разработке сложных программных комплексов все больше зависит от слаженности работы и профессионализма коллектива этой категории специалистов на всех этапах и уровнях создания таких проектов. При выборе заказчиком надежного поставщика-разработчика проекта необходима оценка тематической и технологической квалификации возможного коллектива специалистов, а также его способности реализовать проект с заданными требованиями и качеством. Тематическую квалификацию специалистов в области создания ПС определенного функционального назначения приближенно можно характеризовать средней продолжительностью работы в данной проблемной области основной части команды, непосредственно участвующей в разработке алгоритмов, спецификаций, программ и баз данных. Важнейшую роль при этом играет квалификация руководителей – лидеров  разработки и системных аналитиков функциональных компонентов и в меньшей степени непосредственных разработчиков программ в конкретной прикладной области. Особенно важна не индивидуальная характеристика каждого специалиста, а, прежде всего, интегральный показатель квалификации “команды”, реализующей некоторую, достаточно крупную функциональную задачу или весь проект. При низкой тематической квалификации допускаются наиболее грубые системные ошибки, требующие больших затрат при доработке программ или даже делающие проект практически не реализуемым.

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

        В детальной  модели СОСОМО (см. лекцию 5)значительное внима-ние уделено влиянию организации и взаимодействия коллектива разра-ботчиков на трудоемкость создания сложных программных средств – таблица 9.1. В составе организационных характеристик коллектива реко-мендуется учитывать согласованность целей специалистов, участвующих в проекте, их психологическую совместимость и способность к дружной коллективной работе, наличие опыта работы в данном коллективе и другие объективные и субъективные свойства участников проекта. При этом большое значение может иметь личная мотивация и психологические особенности поведения разных специалистов при комплексной работе над сложным проектом. Эти характеристики могут быть обобщены в качес-твенный показатель влияния сложности взаимодействия специалистов в коллективе, которому сопоставлены коэффициенты изменения  трудоем-кости разработки ПС (последняя строка в таблице 9.1). Наилучшим счита-ется непрерывное корректное взаимодействие организованных специали-стов с  большим опытом работы в данном коллективе при полной согласо-ванности их целей, планов и методов работы. В остальных случаях в той или иной степени (даже в 3 – 5 раз) может возрастать трудоемкость разра-ботки ПС, что нельзя не учитывать при прогнозировании ТЭП и обоснова-нии разработки крупных проектов.

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

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

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

   Инспекторы-испытатели по проверке систем качества предприятия и качества программных продуктов должны пройти обучение, дающее им знания и квалификацию, необходимые для проведения испытаний, оценки их результатов и эффективности применения систем качества. Для них (см. ISO 10011-2) необходимыми считаются  знание и понимание стандартов и нормативных документов, в соответствии, с которыми должны осуществляться оценки применения систем качества, а также обследование, анкетирование и составление отчетов по испытаниям. Инспектор-эксперт, в соответствии со стандартом, должен быть непредубежденным; обладать здравым смыслом; иметь аналитический склад ума и твердость воли; обладать способностью реально оценивать сложные действия с точки зрения их дальнейшей перспективы в рамках общей организационной структуры:

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

Перечисленные выше специализации и квалификации персонала, участвующего в крупных проектах ПС, требуют соответствующей их подготовки, отбора и непрерывного обучения,  которые являются самостоятельной, важной проблемой проектирования и всего ЖЦ комплексов программ. Обучение представляет собой процесс и требует организации и сопровождения обучаемого персонала. Должны быть разработаны и документированы планы, требования и цели  обучения, а также разработаны руководства, включая материалы, используемые для обучения  (см. шестую часть стандарта ISO 15504). Персонал, ответственный за выполнение конкретных задач, если это необходимо, должен быть аттестован на основе соответствующего образования, подготовки и/или опыта работы. Может также стать необходимым включение в подготовку, ознакомление со специфической (проблемно-ориентированной) областью, в которой будет работать данное программное средство, и повышение квалификации в этой области. Требования к квалификации, обучению персонала и их реализации должны быть документально оформлены в системном проекте.

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

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

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

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

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

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

     

9.3.  Ресурсы  для обеспечения функциональной  пригодности  при разработке  сложных программных средств 

При проектировании ПС необходимо учитывать, что экономические, временные, вычислительные и другие  ресурсы на разработку и весь ЖЦ программ всегда ограниченны и используемые затраты для улучшения каждой характеристики должны учитывать эти ограничения. Для рационального распределения этих ресурсов необходимо знать как отражается изменение затрат на улучшении каждой характеристики качества ПС. Эта взаимосвязь затрат ресурсов и значений каждой характеристики зависит от назначения, а также от ряда свойств и других особенностей комплекса программ, что усложняет учет влияния таких связей. Тем не менее,  выявлены основные тенденции такого взаимодействия, которые могут служить ориентирами при выборе и установлении требований к определенным характеристикам качества в конкретных проектах ПС.

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

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

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

Кроме того, следует учитывать совокупность затрат ресурсов на технологию, инструментарий автоматизации разработки и систему качества, обеспечивающие жизненный цикл ПС. Эта составляющая затрат зависит не только от характеристик проектируемого ПС, но и от интенсивности применения технологических средств (см. рис. 9.1).  

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

   Для учета классов крупномасштабных ПС с позиции затрат на их разработку проведено ранжирование экспериментальных данных и выделены классы (см. ISO 12182), наиболее сильно отличающиеся затратами на функциональную пригодность, при одном и том же общем размере полностью новых программ и информации баз данных, которые характеризуются (см. лекцию 5):

  •  максимальной трудоемкостью ПС  систем управления динамическими объектами или процессами в реальном  времени (СРВ);
  •  средней трудоемкостью ПС  административных, организационных  и  информационно-поисковых систем (ИПС);
  •  минимальной трудоемкостью  создания пакеты автономных расчетных прикладных программ (ППП).

Все остальные типы ПС могут быть упорядочены между выделенными классами  и для них получены оценки изменения трудоемкости (стоимости) относительно максимальной для ПС реального времени. Малые проекты, создаваемые небольшими коллективами специалистов характеризуются большим коэффициентом вариации – разбросом  значений предполагаемой трудоемкости,  вследствие высокой роли индивидуальных способностей отдельных специалистов. Трудоемкость разработки крупномасштабных ПС объемом свыше 100 тыс. строк отражается более определенными закономерностями и стабильными значениями,  что обусловлено усреднением творческих возможностей специалистов и условий  их  труда в больших коллективах, а также возрастанием доли затрат и роли руководящего и вспомогательного персонала в ЖЦ ПС.

   Основные составляющие дополнительных затрат, обеспечивающие требуемые характеристики качества ПС целесообразно структурировать в соответствии с их номенклатурой в стандарте ISO 9126 (см. лекцию 11). Однако желательно эти затраты связать с процессами ЖЦ ПС. Важнейшее значение имеет установление и формализация исходных требований к характеристикам  ПС. Поэтому целесообразно выделять значительные ресурсы на системный анализ и проектирование требований ко всему комплексу характеристик и их атрибуты на начальных этапах проекта ПС (см. рис. 9.1).  На этих этапах неопределенность оценки влияния факторов наибольшая, тем не менее даже приблизительный их учет позволяет избегать грубых ошибок (в несколько раз) при оценке затрат на разработку, которые делаются экспертами без детального анализа влияния различных факторов на требуемое качество ПС. Подобный анализ может быть базой для рационального, первичного распределения ограниченных ресурсов разработки и для управления их использованием по мере развития проекта. Учет возможного изменения затрат в зависимости от основных параметров проекта способствует упорядочению процесса разработки ПС и концентрации усилий на тех факторах и затратах, которые могут дать максимальный эффект в повышении качества, при конкретных условиях создания программ и реальных ограничениях ресурсов.

     После проведения системного проектирования, а также предварительного распределения ресурсов, возможна ошибка в оценке совокупных затрат на разработку ПС с требуемым качеством, приблизительно в полтора-два раза. Разработка архитектуры комплекса программ на основе прототипов и подготовка к  программированию готовых апробированных алгоритмов позволяет ее уменьшить до 20-30%. Такую достоверность можно получить, конечно, только при подробном анализе и оценке влияния важнейших факторов и требований к качеству конкретного ПС (см. лекцию 5).

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

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

Затраты на обеспечение безопасности и надежности функционирования ПС определяются требуемым уровнем защищенности и сложностью (размером) программ для ее реализации (см. лекцию 11).  При наличии особенно высоких требований к безопасности критических ПС эти затраты могут даже в 2 – 4 раза превышать затраты на решение базовых, функциональных задач. Для типовых административных систем трудоемкость создания программных средств защиты обычно составляет 20 – 40% затрат на решение основных, функциональных задач.  В  более простых случаях,  доля таких затрат может снижаться до  5 – 10%.   Затраты на обеспечение высокой надежности в  составе разработки ПС  могут достигать 2 – 3 кратного увеличения общих затрат,  при  высоких требованиях наработки на отказ. Для минимального обеспечения автоматического рестарта в ординарных системах они составляют порядка 10 – 20%.  Однако практически, в любых системах должен присутствовать минимум программных компонентов, обеспечивающих надежность и защиту от преднамеренных  и случайных угроз.

 Затраты на создание достаточно полного комплекта докумен-
тации  практически пропорциональны размеру комплекса программ.
Удельные затраты на документацию зависят от класса, назначения
и широты применения программ, что трудно учесть в достаточно
общем виде. Эти затраты сопутствуют в некоторой степени всем
этапам разработки, однако, оформление эксплуатационных доку-
ментов обычно локализуется в специ-альном этапе работ. Затраты
на разработку комплекта эксплуатационной документации для сложных программных продуктов
,
подлежащих дли-тельному сопровождению, обычно определяются
затратами ориентир-овочно 5  10 страниц на тысячу строк
текста программы.

Достаточно определенно могут быть выделены и оценены затраты на обеспечение и реализацию требований к характеристикам: защищенности, сопровождаемости, мобильности и практичности (последние в части документирования) ПС. Эти затраты состоят из двух связанных частей: затрат на реализацию соответствующих характеристик качества в программных продуктах и затрат при использовании этих характеристик в процессе эксплуатации комплекса программ. Обычно совершенствование качества и повышение затрат на реализацию характеристик способствует снижению затрат при их эксплуатации. Последние трудно оценить априори,  так как они зависят от внешней среды и активности применения конкретного ПС, а не от его свойств и требуемого качества. Поэтому далее основное внимание акцентировано на затратах, которые необходимы для достижения  требуемых характеристик качества.

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

         Наиболее активно в качестве простейшего показателя сложности используется размер – масштаб комплекса программ, выраженный числом операторов (команд) или строк текста на языке программирования (с учетом коэффициента, зависящего от класса ПС и специфики языка) (см. лекцию 5).  Размер программ без комментариев является одной из наиболее достоверно измеряемых характеристик сложности ПС и достаточно адекватен экономическим затратам на его разработку. Реальное изменение создаваемых в настоящее время новых сложных ПС объемом от 103 до 106  строк определяет диапазон трудоемкости разработки таких программ от человеко-года до тысяч человеко-лет.  С другой стороны, отсутствуют какие-либо данные о значительном преимуществе других достаточно простых мер сложности при прогнозировании ресурсов на разработку крупномасштабных ПС.

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

При современных технологиях полностью новые, крупномасштабные комплексы программ, реализуемые в допустимое  время 2 – 4 года, ограничены  объемом 106   10 7 строк текста.  Выше отмечалось (см. лекцию 5), что диапазону размеров современных ПС в три-четыре порядка (до 10 млн. строк) соответствуют приблизительно такие же диапазоны изменения трудоемкости и стоимости их разработок. Очевидна принципиальная нерентабельность разработки очень сложных ПС  за  5 10 лет. С другой стороны, даже относительно небольшие программы высокого качества в несколько тысяч строк по полному технологическому циклу с сертификационными испытаниями  продукции редко создаются за время, меньшее, чем полгода год. Таким образом, диапазон вариации длительностей разработок ПС много меньше, чем вариация их трудоемкости, а эти длительности ограничены сверху и снизу, и объем новых программ является одним из основных факторов, определяющим эти границы.

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

           

         9.4.  Ресурсы  на  реализацию конструктивных характеристик                     качества программных средств

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

         Анализ затрат на обеспечение корректности зависит от полноты прослеживания реализации требований к ПС сверху вниз, в требованиях к компонентам вплоть до объектного кода программ и от степени их покрытия тестами. Эти затраты входят непосредственно в процесс разработки и зависят от объема и детальности процессов верификации и тестирования. Для сложных ПС при требовании их высокой корректности они могут составлять до 30%  от затрат на обеспечение первичной, функциональной пригодности. Для относительно простых комплексов программ эта величина в среднем не превышает 20%.

         Затраты на взаимодействие программных средств и их компонентов с внутренней и внешней средой определяются сложностью (объемом) программ и затратами производительности ЭВМ, реализующими эти функции. Они включают затраты на визуализацию информации, обеспечивающей функциональную пригодность, телекоммуникацию с внешними абонентами системы и с операционной системой и могут составлять 10 – 20%  затрат на обеспечение основных функций ПС.

        Особенности затрат на реализацию остальных требований к конструктивным характеристикам качества отмечаются при представлении соответствующих характеристик  (см. лекцию 11) и сводятся к следующему:

  •  дополнительные затраты на обеспечение высокой надежности ПС  могут достигать 2 – 3 кратного увеличения затрат относительно функциональной пригодности при требованиях наработки на отказ в десятки тысяч часов, а для минимального обеспечения автоматического рестарта в ординарных системах составляют порядка 10 – 20%;
  •  для повышения эффективности использования ресурсов ЭВМ затраты могут быть относительно невелики  (несколько процентов) и их трудно выделить из затрат на решение основных, функциональных задач;
  •  затраты на обеспечение практичности зависят в основном от сложности применения ПС, от качества и количества эксплуатационной документации и электронных учебников и могут составлять до 20% затрат на решение основных, функциональных задач.

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

       Сопровождаемость ПС можно оценивать потребностью трудовых и временных ресурсов для ее обеспечения и для реализации. Возможные затраты ресурсов на развитие и совершенствование качества комплекса программ зависят не только от внутренних свойств программ, но также от  запросов и потребностей пользователей на новые функции и от готовности заказчика и разработчика удовлетворить эти потребности (см. лекцию 15).  

В современных проектах ПС большую или меньшую долю составляют готовые апробированные компоненты из других подобных разработок – прототипы и/или покупные пакеты прикладных программ. Это позволяет значительно ускорять работы и сокращать затраты на создание сложных комплексов программ.  Перед  разработчиками проекта ПС зачастую возникает дилемма: разрабатывать ли весь комплекс программ полностью из новых компонентов или использовать, адаптировать и приспосабливать готовые компоненты, какие и в каком количестве. В результате при первичном экономическом анализе ресурсов на создание ПС с требуемыми характеристиками качества, целесообразно рассматривать два альтернативных варианта определения затрат на разработку:

  •  полностью нового ПС, для которого отсутствуют или недоступны подходящие готовые компоненты – прототипы  и/или их заведомо нерентабельно использовать;
  •  программного продукта на базе комплексирования набора готовых программных компонентов и информации баз данных, для которого почти не  требуется создания новых компонентов.

           Мобильность и затраты конкретных ресурсов для переноса программ и данных на иные аппаратные и операционные платформы при проектировании могут быть учтены, только очень приблизительно. Эти субхарактеристики включают адаптируемость, простоту установки и замещаемость программ, которые целесообразно оценивать количественно: совокупными затратами, стоимостью, трудоемкостью и длительностью на реализацию процедур переноса  программ и данных. Оценки мобильности зависят не только от внутренних субхарактеристик ПС, но также от организации, технологии и документирования реализации жизненного цикла и процессов переноса комплексов программ и их компонентов (см. лекцию 15).

     При переносе программ и данных свойства систем практически всегда изменяются, что следует учитывать при системном анализе целесообразности и эффективности переноса,  а также могут быть необходимы тестирование, испытания и сертификация получаемых ПС в новой среде. Кроме того, любой перенос связан с затратами. При создании мобильных ПС трудно предусмотреть все возможные особенности и различия платформ и внешней среды, для которых декларируется мобильность конкретных программных средств. Эти особенности и возможное расширение свойств окружающих прикладных программ и данных могут преподносить неприятные сюрпризы нестыковки, для ликвидации которых потребуются дополнительные ресурсы. Требования мобильности компонентов ПС приводят к необходимости их  проектирования как автономных комплектующих изделий. Это реализуется за счет стандартизации их построения и организации интерфейсов, унификации структуры базы данных и гарантии качества функционирования. В результате подготавливается возможность создание новых ПС из набора готовых программных модулей или функциональных групп программ, ранее использованных и испытанных в другом сочетании при решении несколько иных функциональных задач. Однако в любом комплексе программ вряд ли возможно и нужно повторно использовать все 100% готовых программных модулей.  При сборке нового ПС из комплектующих компонентов,  может  потребоваться  доработка  некоторых из них,  или создание специальных программ,   для их взаимодействия.

        В ряде случаев целесообразна настройка  адаптация готовых компонентов на новые условия применения. При больших изменениях условий применения, эффективной может оказаться сборка нового ПС с частичным использованием апробированных компонентов и с разработкой небольшой части программных модулей, обеспечивающих новые функции, интерфейсы и условия применения ПС.  При этом относительное снижение затрат пропорционально доле использования готовых комплектующих компонентов и степени их пригодности для использования в новом ПС. В пределе при построении  нового ПС на 80 90% из готовых компонентов суммарные затраты могут сокращаться в 3 5 раз. В этом случае, кроме 10 20% затрат на создание новых программных компонентов, необходимы ресурсы на комплексирование нового ПС, его квалификационное тестирования, испытания и документирование.

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

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

9.5. Ресурсы на имитацию внешней среды для обеспечения           тестирования и испытаний программных средств

         

        При создании крупных ПС, одной из больших составляющих могут быть необходимые  ресурсы на генерацию тестов. В ряде случаев они соизмеримы с затратами на создание основных функций комплексов программ, что определяется принципиальным соответствием сложности необходимых наборов тестов и тестового покрытия программ, и сложности функций, реализуемых испытываемым ПС. Создание представительных совокупностей тестов возможно путем использования реальных объектов внешней среды или с помощью программных имитаторов, адекватных этим объектам по результатам функционирования и генерируемой информации. При этом возникает проблема какой метод и когда выгодней по затратам на генерацию тестов и по обеспечению необходимой степени покрытия тестами  испытываемых ПС (см. лекцию 14).

         Имитаторы тестов необходимы не только для оценивания достигнутых характеристик качества комплексов программ, но также для их комплексной отладки, квалификационного тестирования, испытаний и при создания версий. Поэтому затраты на программные имитаторы и их экономическую эффективность целесообразно рассматривать в проекте с учетом всего комплекса задач, которые они способны и должны решать в ЖЦ ПС. Анализ эффективности программной имитации внешней среды при разработке и определении качества ПС целесообразно разделить на две части:  оценка факторов, определяющих эффективность средств имитации тестов, и оценка экономического выигрыша при моделировании внешней среды на ЭВМ по сравнению с натурными экспериментами в реальных системах.

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

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

Экономическую эффективность программной имитации внешней среды на ЭВМ по сравнению с натурными экспериментами целесообразно оценивать при одинаковых объемах тестовых данных для испытаний и определения качества ПС.  Показателем экономической эффективности имитации может служить соотношение затрат ресурсов на проведение натурных экспериментов и затрат на программную имитацию той же совокупности тестовых и эталонных данных.

    Затраты ресурсов на натурные эксперименты для генерации тестов при проведении разработки, испытаний и определения качества пропорциональны реальному времени функционирования проверяемого ПС  и затратам на применение привлекаемых средств реальной внешней среды. Они включают стоимость эксплуатации реального объекта, создающего тесты в единицу времени  (например, затраты на функционирование административной системы, прокатного стана или системы управления воздушным движением и всех управляемых ею объектов). Таким образом, затраты на натурные эксперименты для оценивания характеристик ПС определяются использованием всей реальной внешней среды, в которой предстоит в дальнейшем функционировать программам,  а также затратами на средства измерения характеристик этой среды и проверяемого ПС в процессе разработки, испытаний и определения качества.

   Затраты на программную имитацию тестовых данных определяются  ресурсами необходимыми на проектирование и эксплуатацию сложных комплексов программ для этих целей и  следующими составляющими:

  •  затратами на разработку комплекса программ для  имитации информации внешних объектов и среды их функционирования;
  •  затратами на эксплуатацию программ имитации за время проведения тестирования, испытаний и/или определения характеристик качества тестируемого ПС;
  •  затратами на первичную установку и эксплуатацию моделирующей ЭВМ и вспомогательного оборудования, используемого в имитационном стенде.

   Имитационные стенды практически всегда являются уникальными и достаточно полно используют ресурсы моделирующей ЭВМ. В ряде случаев эти комплексы программ могут иметь объем порядка 104  106 строк текста и должны создаваться с применением современных технологических систем. Затраты на эксплуатацию программ имитации в основном определяются длительностью проведения тестирования, испытаний и/или измерения характеристик качества ПС. Значения этого времени соответствуют реальному времени генерации тестовых данных и тестирования программ. Затраты на эксплуатацию ЭВМ, используемую в моделирующем имитационном стенде (МИС), включают: первичные затраты на закупку и установку оборудования, необходимого для имитации тестовых данных, стоимость имитирующей ЭВМ и устройств сопряжения имитационного стенда с ЭВМ, на которой функционируют тестируемые программы.

         Обычно МИС используется для тестирования нескольких ПС разного, но близкого целевого назначения. Следовательно, затраты на имитационный стенд и на часть его программ распределяются на число проектов ПС, тестируемых с его использованием. В результате удельные затраты на создание и эксплуатацию стендов быстро убывают при унификации имитаторов и расширении области их применения для тестирования и оценивания качества большого числа ПС, имеющих близкое функциональное назначение. Даже приближенные оценки при системном анализе соотношения этих затрат в большинстве случаев показывают высокую рентабельность программных имитаторов внешней среды, особенно для квалификационного тестирования и оценивания характеристик качества крупномасштабных ПС реального времени. Например, при тестировании ПС для управления воздушным движением, применение имитационных стендов, по крайней мере, на порядок снижает затраты по сравнению с натурными экспериментами и использованием реальных объектов (самолетов), а для управления космическими аппаратами или атомными электростанциями это соотношение может быть значительно больше (~ 10 100). При создании и определении качества административных систем с полной загрузкой, имитация способна заменить сложную организацию функционирования по определенной программе большого коллектива операторов банка, налоговой инспекции или таможенного органа.

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


 

А также другие работы, которые могут Вас заинтересовать

68081. Методична розробка «З Перемогою!» 89 KB
  Цілі: Знайомство з героїчними сторінками історії нашої країни. Формування уявлень про військовий обов,язок і вірність Батьківщині, формування досвіду моральної поведінки особистості, спонукання інтересу до історії своєї країни. Підвищення інформаційної культури учнів
68083. Планування дій. Алгоритм 473.5 KB
  Навчальна: Розкрити зміст поняття алгоритм. Формувати в учнів уміння складати алгоритм здійснення того чи іншого процесу. Формувати в учнів уміння передбачати певний результат. Розвивальна: Розвивати вміння узагальнювати. Розвивати вміння працювати колективно.
68085. Прогулянка до лісу. Диференціація звуків л-р-л’-р’ 35.5 KB
  Мета: вчити дітей розрізняти звуки (л-р-л′-р′), автоматизувати ці звуки у зв’язному мовленні; розвивати у дітей слухову увагу, пам'ять; розвивати дрібну моторику; розвивати міміку дітей; удосконалювати мовну моторику, фонематичний слух, фонематичне сприймання, фонематичний аналіз та синтез.
68087. Дослідження творчого спадку М.В. Ломоносова в області природознавчих наук 10.63 MB
  У пропонованій роботі наведено результати дослідження й аналізу творчого спадку М.В.Ломоносова в області геології, ґрунтознавства, біології, екології. Головну увагу приділено впливу праць М.В.Ломоносова на сучасний стан цих наук. На конкретних прикладах показано пріоритетну роль М.В.Ломоносова...
68088. Визначні місця Лондона. Урок для 4 класу 49.5 KB
  Мета: закріпити знання лексики з теми «Споруди»; практикувати у вживанні спеціальних питань, вчити правильно на них відповідати; вдосконалювати навички аудіювання, читання та письма; розвивати навички усного мовлення; сприяти розвитку пам’яті, логічного мислення учнів...
68089. Подорож історією Лондона 181.5 KB
  В процесі викладання іноземної мови дуже важливе місце займають позакласні заходи. Вони є дієвим методом підтримки зацікавленості учнів у вивченні англійської мови. Важливу роль відіграє підготовчий етап до заходів. Вчитель повинен підготовити сценарій і ознайомити учнів з ним, розподілити...