Лекция. Технологическое обеспечение при сопровождении и управлении конфигурацией программных средств
Технологической основой сопровождения и управления конфигурацией ПС являются системы управления базами данных (СУБД), адекватные целям и функциям проектов, структурированные по целям, назначению и содержанию данных в выделенных подсистемах хранения. Они должны обеспечивать возможность управления организационной и проектной деятельностью коллективов специалистов, универсальное хранилище в них необходимых данных, с инструментами наполнения, корректировки, поиска и контроля информации, соответствующей их профессиональной деятельности. Должны быть упорядочены деловые коммуникации между специалистами разных категорий, управление динамическими процессами выполнения изменений и транспортировки корректировок между подсистемами в соответствии с целями их использования специалистами.
Первоначально должен быть разработан проект архитектуры системы технологического обеспечения управления конфигурацией, а также Руководство по её применению, настроена выбранная СУБД на управление основными взаимодействующими подсистемами базы данных, с учетом класса и масштаба предполагаемого проекта ПС. По мере развития жизненного цикла проекта комплекса программ, подсистемы базы данных сопровождения и УК должны поэтапно заполняться реальными данными от заказчика и разработчиков соответствующих квалификаций, и контролироваться менеджерами проекта. При этом следует управлять динамикой процессов реализации процедур модификации, регистрировать реальное использование ресурсов специалистов, текущее время выполнения процедур развития проекта и оформления изменений в подсистемах БД.
|
|
Эта информация в подсистемах базы данных сопровождения и УК должна быть защищены от случайных и преднамеренных искажений, путем организованного санкционирования, дублирования и контроля модификаций, истории их создания и изменения, в процессах жизненного цикла ПС. Необходимо гарантировать сохранность версий изменений, с учетом их важности для результатов всего проекта. Особенно защищенным от искажений и разрушения, следует сохранять архив базовых версий программных продуктов, прошедших успешные испытания, утвержденных заказчиком, и скрепленных его подписью. Для устранения дефектов, реализации корректировок и ошибок при развитии новых базовых версий целесообразно выделять рабочую копию предшествовавшей базовой версии и архив накопленных изменений, обеспечивающих возможность “отката” к предыдущей базовой версии в случае разрушительных некорректных изменений в процессе разработки новой базовой версии.
Такая система обеспечения информацией процессов сопровождения и управления конфигурацией может быть структурирована в соответствии с адаптированной версией жизненного цикла конкретного ПС. В соответствии с основными задачами специалистов проекта, на рис. 16.3 представлены частные подсистемы базы данных информационного обеспечения модификаций, ориентированные на определенные процессы и компоненты ЖЦ комплексов программ. Для каждой подсистемы целесообразно выделять достаточно автономную базу данных компонентов ПС с ограниченным доступом только для определенных категорий специалистов. Эти фрагменты базы данных могут быть построены на стандартизированной основе СУБД проекта, взаимодействовать с аналогичными по структуре предшествующей и последующей базами данных. Они должны накапливать и содержать основные компоненты и документы проекта на соответствующем уровне жизненного цикла ПС. Интерфейсы этого взаимодействия баз данных должны быть стандартизированы, по возможности ограничены по объему и доступности обмениваемой текущей и отчетной информации для других категорий специалистов. Для каждого сложного проекта комплекса программ целесообразно оформлять и утверждать Руководство и схему базы данных, обеспечивающей документооборот и управление сопровождением и конфигурацией ПС, а также категории ответственных лиц за их поэтапную реализацию, контроль и сохранность информации.
|
|
|
|
Выше, подчеркивалось, что проводимый анализ сопровождения программных средств в основном ориентирован на жизненный цикл сложных проектов комплексов программ высокого качества. Многие проекты ПС являются более простыми, и их процесс документооборота сопровождения может быть значительно сокращен. Для этого целесообразно проводить адаптацию и формировать практическую рабочую версию Руководства сопровождения и управления конфигурацией конкретного проекта ПС, которая должна регламентировать работы специалистов. Последовательное сокращение подсистем базы данных и компонентов обеспечения сопровождения, начинается с определения масштаба и наличия предыстории проекта. Известные функции, потенциальные пользователи и концепции существующих версий ПС позволяют прогнозировать направления совершенствования и уменьшения модификаций для нового проекта или базовой версии, имеющих прототип.
В процессе реализации проекта производится наполнение базы данных реальными требованиями и характеристиками результатов разработки модификаций, и архивация откорректированных компонентов и отчетов выполненного проекта. При этом фиксируются корректировки и исправления дефектов и ошибок, и оформляются комплекты документов базовых версий программных продуктов поставляемых заказчику. Эти процедуры целесообразно выделять в отдельную подсистему БД – сопровождения, конфигурационного управления версиями и корректировками программного продукта, для чего, формировать группу специалистов, которые могут быть организационно автономными от остальных подсистем сопровождения и даже размещаться на другом предприятии.
|
|
Документирование развития и совершенствования ПС в значительной степени влияет на достигаемое качество версий сложных комплексов программ, трудоемкость и длительность их создания. Организация документирования должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов на программы и данные систем. Для этого должны быть выделены руководители и коллективы специалистов, которые должны планировать, утверждать, выпускать, распространять и сопровождать комплекты документов. Они должны стимулировать разработчиков программных средств, компонентов и их изменений, осуществлять непрерывное, регламентированное документирование процессов и результатов своей деятельности, а также контролировать полноту и качество отчетных документов.
Структура документации и формы отдельных документов, используемых для конфигурационного управления и сопровождения программ, должны позволять точно документально описывать и идентифицировать каждую оформленную версию программных компонентов и ПС в целом в любое время на всем протяжении их жизненного цикла. Стандарт ISO 9126 регламентирует характеристики качества программного продукта, его изменений и документов. Один из шести основных показателей качества жизненного цикла ПС, важный для документирования сопровождения, характеризует практичность - применимость: свойства программного средства, его модификаций и документации, отражающие сложность их понимания, изучения и использования, для квалифицированных специалистов при применении в указанных условиях. В жизненном цикле ПС характеристика качества практичности, доступности для понимания и освоения документации, должна использоваться и учитываться специалистами с двух позиций:
- разработчиками модификаций и версий комплексов программ, для которых необходимо адекватное отражение и восприятие в документах состояния и изменений ПС и их компонентов в процессе сопровождения и управления конфигурацией;
- пользователями измененных и утвержденных документов, поставляемых базовых версий программных продуктов в процессе их применения и эксплуатации.
Требования к практичности и ее субхарактеристикам - понятности и простоте использования при сопровождении, зависят от назначения и функций модификаций ПС и могут формализоваться заказчиками набором свойств, необходимых для обеспечения удобной и комфортной модификации и улучшения версий комплекса программ. Количественно, простоту изменений при сопровождении можно характеризовать требованиями допустимой средней длительности разработки и ввода типовых корректировок при устранении дефектов и совершенствовании функций ПС.
Требования к продолжительности изучения и разработки модификаций и документов, достаточной для эффективного сопровождения ПС квалифицированными специалистами, могут составлять часы или недели. Для обеспечения полноценного изучения процессов сопровождения и возможностей применения новых версий ПС этими специалистами необходима документация, объем которой существенно зависит от назначения и дополнительных функций ПС, и может быть задан на основе анализа прецедентов подобных успешных проектов.
Понятность: свойства ПС и документации, обеспечивающие специалистам сопровождения понимание, является ли разработка модификации или новой версии комплекса программ пригодной для целей заказчика, и как ее можно использовать для конкретных задач и условий применения. Она должна обеспечиваться корректностью и полнотой описания в документах исходной и результирующей информации, а также всех деталей новых функций ПС для заказчика и потенциальных пользователей.
Простота использования: возможность специалистам сопровождения удобно и комфортно изменять и управлять конфигурацией ПС. Аспекты изменяемости, адаптируемости и легкости инсталляции корректировок могут быть предпосылками для простоты использования и сопровождения документов конкретного ПС.
Изучаемость: свойства версий и документов ПС, обеспечивающие удобное освоение его сопровождения достаточно квалифицированными пользователями. Она может определяться трудоемкостью и длительностью подготовки специалистов к полноценному управлению конфигурацией ПС.
План и поддерживающее его Руководство по документированию сопровождения и конфигурационного управления конкретного крупного проекта ПС должны отражать:
- общую структуру комплекта документов на конфигурацию ПС;
- номенклатуру и структуру содержания каждого документа;
- требования к качеству, оформлению и обозначению документов;
- регламент комплектования, корректировки и хранения документов;
- правила обращения, процессов изменения и сопровождения документов;
- графики подготовки, проверки, редактирования, согласования, утверждения и распространения документов.
Для управления конфигурацией, развитием комплекса программ и испытаний в базе данных документов должны собираться сведения, которые состоят из следующих крупных функциональных частей:
- описания данных об отказах, дефектах и ошибках, условиях их проявления и характеристиках обнаруживающих тестов, а также предложения на изменения программ, подлежащие анализу и селекции для выделения тех из них, для которых будут разрабатываться корректировки программ –описания предполагаемых изменений ПС;
- разработанные изменения программ, отобранные аналитиками сопровождения и конфигурационного управления для проведения корректировок в очередной версии ПС – описания подготовленных и утвержденных корректировок компонентов и версий комплексов программ;
- сборки компонентов, откорректированные версии и наборы изменений, выполненных в каждой из них – описания откорректированных и утвержденных базовых версий программного продукта;
- характеристики и параметры пользователей, которым переданы для использования соответствующие базовые версии и особенности внешней среды эксплуатации у них – описания параметров адаптации пользовательских версий программного продукта.
Перечисленные документы в базе данных управления конфигурацией проекта реально структурируются на более мелкие фрагменты. Они взаимосвязаны и сведения об изменениях по мере обработки должны переходить последовательно из одного состава описания в другое и, возможно, из одного сектора базы данных проекта в другой.
Методика оформления отчетов о выявленных дефектах, ошибках и предложениях по корректировке версий ПС должна содержать рекомендации испытателям и пользователям по выявлению, регистрации и формализации условий проявления и содержания дефектов и желательных модификациях испытываемых и/или эксплуатируемых версий. Эта методика должна включаться в состав эксплуатационной документации и передаваться каждому пользователю версии программного продукта. В методике следует стимулировать специалистов анализировать, подготавливать и представлять рекомендации заказчику и разработчикам по совершенствованию и развитию функций и качества поставляемой версии ПС. Результаты анализа и предложения необходимо передавать в унифицированной форме Отчетов специалистов о выявленных дефектах и предложениях по корректировке ПС, которые должны содержать:
- подробное описание сценария тестирования и исходных данных, при которых выявлен дефект;
- описание проявления дефекта и документы результатов его регистрации;
- предположение о возможной причине, вызвавшей проявление дефекта;
- предложение о возможной модификации ПС и его компонентов для устранения дефекта или совершенствования качества функционирования комплекса программ.
Изменения, отобранные аналитиками сопровождения и управления конфигурацией, переводятся из описаний предварительных изменений в другую часть базы данных. Здесь изменения конкретизируются вплоть до текстов корректировок программ или созданных новых компонентов. Кроме того, для каждой подготовленной корректировки следует регистрировать результаты ее рассмотрения, проверки и утверждения на введение в новую базовую версию ПС или для частных извещений пользователям. Отвергнутые корректировки возвращаются в состав предлагаемых изменений.
Описание выявленных дефектов и предложений по совершенствованию функций комплекса программ, а также результатов анализа предполагаемых корректировок версий ПС должен содержать отчеты пользователей о выявленных дефектах и предложениях и дополнительно:
- оценки сложности, трудоемкости, эффективности и срочности модификаций программ;
- оценки возможного влияния предлагаемых изменений на эксплуатацию версий ПС, имеющихся у пользователей.
Все корректировки, утвержденные для введения в очередную версию, следует регистрировать в отдельной подсистеме базы данных. Для каждого изменения должны документироваться содержательная аннотация, а также общие характеристики и достигнутые на предварительных испытаниях показатели качества очередной версии программного продукта. Результаты испытаний версии запоминаются вместе с условиями и параметрами, при которых они формировались, а также с набором тестов или указаниями места их хранения.
Описание подготовленных и утвержденных корректировок, а также реализованных изменений и обобщенных характеристик модифицированной базовой версии программного продукта должно содержать:
- причину изменения программ и базы данных (ошибка, дефект, совершенствование);
- содержание изменений программ и базы данных, а также документации на версию ПС или компонента;
- результаты квалификационного тестирования базовой версии программного продукта с предполагаемыми изменениями;
- результаты испытаний и обобщенные характеристики качества базовой версии программного продукта после внесения изменений;
- решение по распространению пользователям проведенной модификации или версии программного продукта;
- адрес хранения корректировок, документов и квалификационных тестов новой базовой версии программного продукта.
Учет тиражирования, адаптации, переноса на иные платформы и распространения версий программного продукта должны осуществляться с фиксированием документов в базе данных описаний пользовательских версий. В этом документе накапливаются сведения об операционных и аппаратных платформах, а также о параметрах внешней среды применения и адаптации ПС у каждого пользователя и активность его работы с версиями комплекса программ.
Накопленные документы об изменениях и история корректировок подлежат хранению в архиве в течение всего жизненного цикла ПС или значительной его части. Разрушение сведений о выполненных или предполагаемых изменениях программ, может приводить к большими затратам на их восстановление. Поэтому база данных архива изменений должна дублироваться и поддерживаться методами и средствами сопровождения, аналогичными, применяемым для основной документации, тестов и текстов программ конкретного проекта.
Особое значение при сопровождении и управлении конфигурацией имеет документация на реализованные изменения и тесты, с помощью которых проверялась корректность версий компонентов и ПС в целом. Эта документация должна позволять восстанавливать историю разработки и проверки каждого изменения любого компонента. На базе всего комплекса использованных тестов создается и документируется для каждой версии программного продукта, эталонная тестовая (контрольная) задача и контрольные результаты её решения. Эти документы оформляются в соответствии со стандартами, тиражируются и передаются пользователям вместе с программами базовой версии и остальными эксплуатационными документами.
Разработка и тестирование изменений компонентов и ПС всегда несколько опережают их документальное оформление. В течение этого времени возможны отдельные уточнения изменений в версиях. В результате документация должна непрерывно “догонять” реальное состояние программного продукта. Для упорядочения этого процесса стандартами установлена возможность оперативного выпуска предварительных, официальных извещений на частные изменения. Эти извещения регистрируются как временные и погашаются при полном оформлении документации на очередную версию программного продукта и все изменения.
Лекция. Оценка качества ПО.
Дата добавления: 2019-09-13; просмотров: 265; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!