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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

План и поддерживающее его Руководство по документированию сопровождения и конфигурационного управления конк­ретного крупного проекта ПС (рис. 16.5) должны отражать:

- общую структуру комплекта документов на конфигурацию ПС;

- номенклатуру и структуру содержания каждого документа;

- требования к качеству, оформлению и обозначению документов;

- регламент комплектования, корректировки и хранения документов;

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

- графики подготовки, проверки, редактирования, согласования, утверждения и распространения документов.

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

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

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

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

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

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

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

- подробное описание сценария тестирования и исходных данных, при кото­рых выявлен дефект;

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

- предположение о возможной причине, вызвавшей проявление дефекта;

- предложение о возможной модификации ПС и его компонентов для устранения дефекта или совершенствования качества функ­ционирования комплекса программ.

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

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

- оценки сложности, трудоемкости, эффективности и срочности модифи-каций программ;

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

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

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

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

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

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

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

- решение по распространению пользователям проведенной модификации или версии программного продукта;

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

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

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

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

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

Дата добавления: 2014-01-13