Лекция. Этапы и процедуры при управлении конфигурацией программных средств

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

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

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

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

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

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

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

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

- выявленные дефекты и ошибки в программах и данных;

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

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

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

- насколько данное изменение может улучшить эксплуатационные характеристики ПС в целом;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

---

Дата добавления: 2019-09-13; просмотров: 178; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!