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

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

От пользователя могут поступать также предложения по внесению изменений в (n+1)-ю версию для улучшения эксплуатационных характеристик и расширения функциональных возможностей ПС. Аналогичные предложения могут поступать от разработчиков комплекса. Изменения могут быть направлены на коренное улучшение функциональных возможностей программ или некоторые косметические улучшения реализуемых функций. Ва­рианты небольших корректировок программ целесообразно на­капливать отдельно от предложений по существенному совершен­ствованию системы. Таким образом создается документ — исход­ные данные для планирования доработок и тестирования ПС в процессе сопровождения [9].

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

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

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

2. изменения, которые целесообразно внести в (n+1)-ю версию с учетом затрат на их реализацию и улучшения эффективности ПС;

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

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

Для принятых к внедрению изменений разрабатывается план доработок программ и определяется ответственный за каждую корректировку программ. Изменения программ могут потребо­вать либо полной замены модуля или группы программ, либо небольшого изменения текста программного модуля, описания данных или констант. Если изменения в программе или данных невелики, то тестирование стремятся ограничить компонентами, непосредственно связанными с выполненной корректировкой. Од­нако следует учитывать, что корректировки программ в 10 .30 % случаев сами содержат ошибки и требуют тестирования не только техчастей программы. Где внесен изменения. Наличие в программах глубоких межмодульных связей по управлению и по информации вызывают необходимость тестирования и тех компонент, где по первому впечатлению корректировки не оказывают влияния. Такие связи зачастую приводят к появлению вторичных ошибок вследствие проведенных изменений и нарушения функциональной целостности взаимодействующих программ и данных.

Тиражирование и использование версий программ.

Все корректировки предварительно выполняются и проверяются на версиях программ разработчиков, которые формируются на основе фрагментов подлинника n-й версии ПС. Откорректированные версии компонент подвергаются автономному тестированию, после чего объединяются в группы программ и тестируются в нескольких скомплексированных группах. Проверенные таким образом изменения регистрируются в журнале проведен­ных корректировок для (n+1)-й версии ПС.

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