67324

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

Лекция

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

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

Русский

2014-09-07

287.5 KB

38 чел.

PAGE  1

Лекция 15. Сопровождение и мониторинг программных средств

   15.1.  Организация и методы сопровождения программных средств   

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

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

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

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

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

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

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

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

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

Основной процесс эксплуатации в жизненном цикле может инициировать процесс сопровождения ПС путем представления предложений о модификации (изменении) или отчетов о дефектах. Процесс сопровождения программного средства в соответствии со стандартом ISO 12207 (п. 5.5) и детализацией этого раздела в стандарте ISO 14764,  использует основной стандартизированный процесс разработки комплексов программ и вспомогательные процессы документирования, управления конфигурацией, обеспечения качества, верификации, аттестации, совместного анализа, аудита и устранения дефектов. Организационные процессы управления, создания инфраструктуры и обучения  должны определяться сопроводителем в начале каждого проекта сопровождения.

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

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

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

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

требования к передаче технических и программных средств, данных и знаний (опыта) от разработчика к сопроводителю;

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

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

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

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

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

основные требования и правила, используемые для определения того, когда ПС может быть локально откорректировано, а когда необходима новая базовая версия программного продукта с использованием для ее подготовки и инсталляции процесса разработки;

описания типов редакций версий, в зависимости от частоты их появления или влияния на эксплуатацию программного продукта (например, экстренные редакции, периодические редакции);

способы информирования заказчика о состояниях текущих или намечаемых изменений;

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

классификацию типа изменения, его очередности (приоритетности) и взаимосвязи с другими предложенными изменениями.

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

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

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

определение и описание новых функций;

точность и логическая организация данных;

интерфейсы (системные, компонентов и пользователей), особенно новые и перспективные интерфейсы;

требования к функциям и рабочим характеристикам, включая влияния корректировок и дополнений;

требования, налагаемые запланированной внешней средой;

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

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

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

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

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

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

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

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

область сопровождения и изменений программного продукта;

практическое применение (адаптацию) данного процесса;

определение предприятия и лиц, ответственных за сопровождение;

оценку стоимости и длительности сопровождения.

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

типы допустимых изменений и  процедур сопровождения;

уровень качества сопровождаемых  документов;

реакцию (чувствительность) пользователей на сопровождение;

обеспечиваемый уровень обучения персонала сопровождения;

обеспечение поставки  модифицированных версий программного продукта;

возможность организации справочной службы  «горячей линии».

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

срок службы программного средства;

размер первичных и долгосрочных затрат на сопровождение;

квалификация сопровождающего персонала;

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

программа (график) модификаций и сопровождения;

знание сопроводителем предметной области применения программного продукта.

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

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

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

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

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

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

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

15.2. Этапы и процедуры при сопровождении программных средств

      

       В соответствии с требованиями стандарта ISO 12207 по развитию и модификации программного продукта в жизненном цикле должен быть организован процесс его сопровождения (см. п. 5.5). Работы,  обеспечивающие  сопровождение  ПС, включают:

  •  подготовку процесса;
  •  анализ проблем и изменений;
  •  внесение изменений;
  •  проверку и приемку при сопровождении;
  •  перенос;
  •  снятие с эксплуатации.    

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

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

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

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

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

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

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

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

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

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

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

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

Анализ дефектов и модификаций в стандарте ISO 14764 рекомендуется реализовать в следующем порядке:

анализируются предложения о модификации  и отчеты о дефектах;

дублируется или проверяется реальность каждого дефекта;

разрабатываются варианты реализации изменения;

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

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

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

Для обеспечения реализации представленного предложения на изменение сопроводитель должен определить:

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

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

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

       Контроль за рассматриваемыми работами следует проводить посредством процесса совместного анализа.  В конце работ должен быть проведен анализ риска. На основании выходных результатов анализа может быть пересмотрена предварительная оценка требуемых ресурсов и с привлечением пользователей или заказчика принято решение о целесообразности перехода к работе по внесению изменений в базовую версию программного продукта. Результатами этой работы являются: анализ влияния изменений; рекомендуемый вариант и согласованные изменения; обновленные  и исправленные документы.

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

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

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

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

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

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

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

Сопроводитель должен  документально оформить и представить заказчику:

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

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

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

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

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

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

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

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

      15.3. Задачи и процессы переноса программ и данных                    на иные платформы

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

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

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

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

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

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

      Задачи повторного использования и переноса программ  и данных охватывают:

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

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

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

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

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

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

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

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

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

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

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

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

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

    Задачи и объекты, связанные с мобильностью ПС и БД  в системах, и подлежащие рассмотрению при выборе методов и средств  обеспечения переносимости, включают:

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

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

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

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

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

      Процессы переноса программных средств и баз данных регламентируются рядом процедур и документов, стандартизированных в ISO 14764  (п. 8.5),  который детализирует требования к процессам переноса, определенным в базовом стандарте на жизненный цикл ПС (см. ISO 12207 п. 5.5.5).  Специалисты, которые проводят перенос по рекомендациям этих стандартов, должны разработать план переноса, известить пользователей, обучить персонала, выдать предупреждения о завершении переноса, оценить влияние новой версии и  внешней среды и архивировать соответствующие данные. Если систему или программный продукт (включая данные) переносят из  старой в новую эксплуатационную среду, следует обеспечить, чтобы программный продукт и данные были корректно изменены при переносе. Для этого необходимо решить следующие  основные задачи: определить все добавляемые или изменяемые программные компоненты, продукты или данные; проверить соответствие реализации конкретных задач, спецификациям требований заказчика на перенесенную версию ПС и БД.

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

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

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

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

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

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

  •  определить требования по обучению для реализации переноса;
  •  запланировать реализацию требований по обучению переноса;
  •  выполнить проверку результатов обучения после выполнения переноса;
  •  обновить и откорректировать планы обучения.

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

Отчетными результатами работ по переносу ПС и БД являются:

перенесенный программный продукт на новой платформе;

план реализации переноса;

инструментальные средства для переноса;

извещения о намерениях по переносу;

уведомление о завершении переноса;

-    архивные данные процессов и результатов переноса.

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

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

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

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

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

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

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

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

    

15.4. Ресурсы, для обеспечения сопровождения и мониторинга                   программных средств

      

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

     При анализе затрат на сопровождение и мониторинга программных средств целесообразно рассматривать следующие сценарии:

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

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

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

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

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

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

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

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

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

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

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

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

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

     При системном анализе затраты на сопровождение можно считать аддитивными и включающими составляющие:

  •  затраты на обнаружение и устранение ошибок и дефектов в каждой версии ПС;
  •  затраты на доработку и совершенствование программ, формирование и испытание новых модернизированных версий ПС;
  •  затраты на тиражирование каждой новой версии и её внедрение в эксплуатируемых и новых системах.

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

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

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

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

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

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

     На основе анализа и оценивания рассчитанных характеристик ресурсов для сопровождения следует выполнять заключительное технико-экономическое обоснование необходимости сопровождения конкретного программного продукта и определять:

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


 

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

67007. Подорож картою України 52 KB
  Мета: продовжити формувати уявлення учнів про географічне розміщення України її кордони сусідство з іншими країнами; ознайомити з найбільшими містами України горами водоймами тваринами рослинами; детальніше познайомити із столицею України містом Києвом; викликати позитивні емоції виховувати почуття любові...
67008. Правила поведения в экстремальной ситуации 63.5 KB
  Вводная часть: актуализация опорных знаний. - Что на свете всего дороже. - Как понимаете это слово. Что с ним связано? Что влияет на наше здоровье? (Питание, спорт, профилактика вредных привычек соблюдение правил безопасности, правильный отдых) - Что такое опасная ситуация? - Какое отношение имеют эти слова к здоровью?
67009. Текст. Признаки текста. Виды связи в тексте. Цепная связь. Способы передачи цепной связи. Параллельная связь. Присоединительная связь 102.5 KB
  Текст можно определить как объединенную смысловой и грамматической связью последовательность речевых единиц: высказываний, сложных синтаксических целых, фрагментов, разделов и.т.д. Основными признаками текста являются: 1) завершённость, смысловая законченность, которая проявляется в полном...
67010. Тема текста. Содержание текста. Коммуникативная задача текста. Части текста. Микротемы текста 38.5 KB
  Цели: 1. Углубить понятие о смысловом делении текста. 2. Продолжить работу над синтаксическими конструкциями для выражения характера, образа действия. 3. Добиться осознания студентами тесной взаимосвязи языка и общества, основных функций языка в обществе, которые будут способствовать правильному стилистическому использованию изученных конструкций в речи.
67011. Функционально-смысловые типы монологической речи. Описание 47 KB
  Цели: 1. Углубить понятие о типах монологической речи. 2. Продолжить работу над пунктуационными, синтаксическими, орфографическими и иными ошибками изложений (над наиболее типичными коллективно, над остальными – индивидуально. 3. Добиться осознания студентами тесной взаимосвязи языка и общества...
67012. Описание как функционально-смысловой тип речи 39.5 KB
  В текстах данного типа всегда представлена статичная картина, складывающаяся из указаний на предметы (или части предметов) и их признаки; главным, во имя чего создаются предложения, является указание на признаки; называющие их слова, как правило, помещается в конце предложения...
67013. Функционально-смысловые типы монологической речи. Повествование 43.5 KB
  Повествование раскрывает тесно связанные между собой события явления действия. Чаще всего это действия происходившие в прошлом. Предложения в повествовательных текстах не описывают действия а повествуют о них. Повествование это сообщение о каких-либо событиях и действиях.
67014. Функционально-смысловые типы монологической речи. Рассуждение 78 KB
  Рассуждение это тип речи целью которого является выяснение какого-либо понятия доказательство или опровержение какой-нибудь мысли. С логической точки зрения рассуждение это цепь умозаключений на какую-либо тему изложенная в последовательной форме. Рассуждение как тип речи широко встречается в научном стиле.
67015. Функциональные стили русского языка (общая характеристика) 90.5 KB
  Современный русский язык состоит из 5 стилей: Разговорный стиль Научный стиль Официально-деловой стиль Публицистический стиль Художественный стиль Функционально-стилевая типология охватывает практически все тексты рассматривая их во всем многообразии содержательных и языковых стилевых признаков. Любой текст можно отнести к тому или иному стилю...