17. Общая методика отладка по: изучение проявления ошибки, локализация ошибки, определение причины ошибки, исправление ошибки, повторное тестирование.

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

2 этап - локализация ошибки - определение конкретного фрагмента, при выполнении которого произошло отклонение от предполагаемого вычислительного процесса. Локализация может выполняться:

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

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

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

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

4 этап - исправление ошибки - внесение соответствующих изменений во все операторы, совместное выполнение которых привело к ошибке.

5 этап - повторное тестирование - повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

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

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

• выводить пользователю вводимые им данные для контроля и проверять их на допустимость сразу после ввода;

• предусматривать вывод основных данных во всех узловых точках алгоритма (ветвлениях, вызовах подпрограмм).

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

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

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

Организация испытаний комплексов программ. Используются для программ, создаваемых на уровне продукции производствен­но-технического назначения и отчуждаемых от разработчика. Важная осо­бенность испытаний программы состоит в наличии достаточно полных эталонов, которым должен соответствовать КП, тре­бований технического задания. Цель испытаний — определение степени соответствия созданного комплекса программ техниче­скому заданию, полученному от заказчика.

Испытания сложных КП являются наиболее формализован­ным и регламентированным видом тестирования. Для всесторон­ней проверки опытный образец КП подвергается испытаниями главного конструктора (предварительные испытания) и заказчи­ка-пользователя с участием разработчиков (совместные испыта­ния).

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

В жизненном цикле КП можно выделить следующие виды испытаний

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

-рабочей версии КП, адаптированной к условиям конкретного применения,

-версии модернизированного КП при сопровождении.

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

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

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

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

19. Испытания программ на надежность: прямые экспериментальные методы определения показателей надежности программ в условиях нормального функционирования, форсированные методы испытаний реальных систем на надежность.

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

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

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

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

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

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

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

20. Достоверность испытаний: методическая и статистическая достоверность; документирование результатов испытаний: исходных и отчетные документы при испытаниях программ – техническое задание, государственные и отраслевые стандарты, программа испытаний, методики испытаний, протоколы испытаний, акт испытаний.

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

Методическая достоверность испытаний КП оп­ределяется следующими факторами:

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

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

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

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

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

Документы:

1. ТЗ

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

2. Государственные и отраслевые стандарты

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

-объект испытаний, его назначение и перечень основных до­кументов, определивших его разработку;

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

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

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

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

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

-указание методик, в соответствии с которыми проводились испытания, обработка и оценка результатов;

-условия проведения тестирования и характеристика исходных данных;

-обобщенные результаты испытаний с оценкой их на соответ­ствие требованиям технического задания и другим руководящим документам;

-выводы о результатах испытаний и степени соответствия созданного КП определенному разделу требований технического задания.

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

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

21. Виды программной документации: проектная и эксплуатационная документация. Документирование интерактивного ПО. Государственные стандарты в области документирования ПО. Средства автоматизации документирования.

К программным относят документы, содержащие сведения, необходимые для разработки, сопровождения и эксплуатации программного обеспечения. Документирование программного обеспечения осуществляется в соответствии с Единой системой программной документации (ГОСТ 19.XXX). Так ГОСТ 19.101-77 устанавливает виды программных документов для программного обеспечения различных типов. Ниже перечислены основные программные документы по этому стандарту и указано, какую информацию они должны содержать.

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

Ведомость держателей подлинников (код вида документа — 05) должна содержать список предприятий, на которых хранятся подлинники программных документов. Необходимость этого документа определяется на этапе разработки и утверждения технического задания только для программного обеспечения со сложной архитектурой.

Текст программы (код вида документа - 12) должен содержать текст программы с необходимыми комментариями. Необходимость этого документа определяется на этапе разработки и утверждения технического задания.

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

Ведомость эксплуатационных документов (код вида документа - 20) должна содержать перечень эксплуатационных документов на программу, к которым относятся документы с кодами: 30, 31, 32, 33, 34, 35, 46. Необходимость этого документа также определяется на этапе разработки и утверждения технического задания.

Формуляр (код вида документа - 30) должен содержать основные характеристики программного обеспечения, комплектность и сведения об эксплуатации программы.

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

Руководство системного программиста (код вида документа - 32) должно содержать сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения.

Руководство программиста (код вида документа - 33) должно содержать сведения для эксплуатации программного обеспечения.

Руководство оператора (код вида документа - 34) должно содержать сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программного обеспечения.

Описание языка (код вида документа - 35) должно содержать описание синтаксиса и семантики языка.

Руководство по техническому обслуживанию (код вида документа - 46) должно содержать сведения для применения тестовых и диагностических программ при обслуживании технических средств.

Программа и методика испытаний (код вида документа - 51) должны содержать требования, подлежащие проверке при испытании программного обеспечения, а также порядок и методы их контроля.

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

Прочие документы (коды вида документа - 90-99) могут составляться на любых стадиях разработки, т. е. на стадиях эскизного, технического и рабочего проектов. Допускается объединять отдельные виды эксплуатационных документов, кроме формуляра и ведомости. Необходимость объединения указывается в техническом задании, а имя берут у одного из объединяемых документов.

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

На этапе планирования разработки ПО создаются планы и выбираются стандарты, которые направляют этап разработки и интегрированный этап. Его

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

1) определение действий на этапах разработки и интегрированном этапе, которые будут посвящены определению системных требований и уровня ПО;

2) определение ЖЦ ПО, включая взаимодействие между этапами, механизм взаимного влияния этапов, критерии оценки ПО при переходе от одного этапа к другому;

3)определение среды ЖЦ, т.е. методы и инструментальные средства, используемые на каждом этапе;

4) формирование дополнительных замечаний к ПО;

5) рассмотрение стандартов разработки ПО, соотношение их с системными целями безопасности, относящиеся к разрабатываемому ПО;

6) разработка плана создания ПО;

7) доработка и проверка плана создания ПО.

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

-на основе распределения системного анализа (алгоритмиза­ции) и разработки программ по разным коллективам;

-по принципу выделения коллективов, создающих всю совокуп­ность программных модулей, и группы специалистов, объединя­ющих программы в единый комплекс;

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

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

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

Одним из вариантов организационной структуры коллектива при создании крупных КП является иерархическая структура, базирующаяся на группах специалистов, каждая из которых сос­тавляет специализированную, так называемую «хирургическую бригаду». Такая бригада решает достаточно автономную функци­ональную задачу и должна разработать и отладить группу взаи­модействующих программ с достаточно четкой целью функциони­рования. «Хирургическая бригада» рекомендуется в составе 7...10 специалистов с различными задачами и квалификацией. Во главе бригады стоит «хирург», который разрабатывает функциональ­ные задачи программ, составляет алгоритм, пишет и отлаживает программы, готовит и проверяет документацию. Он должен обла­дать значительным системным опытом, высокой математической и программистской квалификацией и талантом разработки и от­ладки сложных КП. «Второй пилот» является дублером и может выполнить любую часть работы, но менее опытен. Он принимает участие в разработке, обсуждении и оценке компонент, создаваемых бригадой, в качестве оппонента или ответчика по альтернативным решениям, а также несет ответственность за взаимодей­ствие с другими бригадами и с разрабатываемыми ими груп­пами программ.

«Администратор» позволяет избавить «хирурга» от множества технических и административных функций как внутри бригады, так и по взаимодействию с администрацией всей организации. При этом «хирургу» принадлежит определяющее слово по важ­нейшим вопросам организации и проведения работ. «Редактор» критикует документацию, созданную «хирургом», дорабатывает ее, снабжает ссылками и наблюдает за ее публикацией. «Адвокат языка» обеспечивает «хирурга» консультациями по применению языка в трудных или запутанных ситуациях, способствует полу­чению более эффективных программ. «Инструментальщик» — опытный системный программист — является создателем специа­лизированных технологических и служебных программ, каталоги­зированных процедур, библиотек макрокоманд для расширения функций технологического обеспечения по заказу «хирурга». «Наладчик» разрабатывает системные тесты в соответствии с назначением и функциями создаваемой группы программ. Он планирует последовательность тестирования, подготавливает имитаторы исходных данных для комплексной отладки, регистри­рует процесс проведения отладки и ее результаты. Кроме того, в бригаду входят 2...3 технических работника для выполнения секретарских функций и различных вспомогательных техни­ческих работ.

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

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

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

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

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

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

• наличие ошибок в используемом программном продукте;

• изменение требований пользователя (расширение или модифи­кация);

• появление более совершенных общесистемных программных средств или технических устройств;

• изменение организационной структуры, условий и методов ра­боты пользователя.

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

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

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

Задачи службы сопровождения программного изделия

В процессе эксплуатации программного изделия пользователи взаимодействуют с организацией (группой), ответственной за со­провождение. Задачами службы сопровождения являются:

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

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

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

4. Внесение изменений в программы с целью их приспособления к условиям работы конкретного пользователя.

5. Контроль правильности всех корректировок, вносимых в из­делие, и проверка качества измененных программ.

6. Доведение до пользователя информации о внесенных измене­ниях.

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

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

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