Конфигурационная база программного продукта должна быть зарегистрирована официально в определенный момент времени и использоваться в качестве отправной точки для контроля за состоянием конфигурации и утвержденными изменениями (п + 1)-й версии. После утверждения конфигурационной базы уполномоченным лицом (и, возможно, заказчиком) оформляются документация и физические носители подлинника (п + 1)-й версии, которые передаются на тиражирование и внедрение у пользователей, а также в архив базовых версий данного проекта программного продукта. Подлинник снабжается техническими условиями и тестами для проверки сохранности и функциональной работоспособности в базе данных отчетов тиражирования и обеспечения хранения версий ПС. Кроме того, в отчетах должны быть сведения о составе всей документации на версию ПС, основные результаты испытаний и сведения о должностных лицах, утвердивших базовую версию программного продукта.
Пользователям может поставляться копия (п + 1)-й базовой версии для самостоятельной адаптации к характеристикам внешней среды и особенностям конкретного применения. В этом случае адаптация должна проводиться строго по инструкциям разработчика этой версии и должны быть запрещены любые дополнительные изменения за пределами, предписанными документацией. Подобные изменения автоматически снимают гарантии разработчика, и ответственность за корректность адаптации возлагается на пользователя. Однако возможны ситуации, когда для адаптации требуется особенно высокая квалификация специалистов и ее следует проводить в рамках работ по конфигурационному управлению непосредственными разработчиками базовой версии. Тогда они входят в группу работ коллектива по сопровождению и конфигурационному управлению. В этом случае пользователь должен представить разработчику формализованные исходные данные и характеристики внешней среды, в соответствии с которыми следует проводить адаптацию. Результаты выполненной адаптации и особенности версий пользователей в крупных, критических информационных системах при относительно небольшом тираже целесообразно регистрировать в архиве у разработчиков соответствующей базовой версии. Ответственность за корректность адаптации в этом случае несет разработчик базовой версии программного продукта.
Для независимого удостоверения достигнутого качества проведенных модификаций в испытанной и утвержденной разработчиком версии программного продукта, по заявке разработчика, заказчика или пользователей, она может подвергаться обязательной или добровольной сертификации (см. лекцию 18). Комплект поставки, состоящий из копии физических носителей и эксплуатационной документации, а также применявшиеся разработчиками квалификационные тесты и методики испытаний передаются сертификационной лаборатории. При сертификационных испытаниях допускается расширение набора и параметров тестов, однако в пределах, ограниченных технической документацией на конкретную версию ПС. Успешно проведенные испытания и полученный сертификат качества подтверждают соответствие комплекса программ документации, надежность и безопасность применения (и + 1)-й версии до тех пор, пока в нее не будут внесены какие-либо изменения. Сертификат может быть аннулирован при любых, даже внешне незначительных, корректировках версии программного продукта.
Приведенную схему организации жесткого конфигурационного управления версиями ПС не всегда можно и целесообразно реализовать полностью. Наличие срочных исправлений ошибок и запросов пользователей на частичные изменения в эксплуатируемых версиях, а также ряд других причин могут приводить к появлению между и-й и (и + 1)-й базовыми версиями ПС ряда промежуточных пользовательских версий. Для этого, наряду с выпуском очередных, базовых версий, приходится выпускать временные извещения на исправления выявленных ошибок и на корректировки, а также извещения об основных изменениях функций, которые проведены в (п + 1)-й версии по сравнению с л?-й. В результате у пользователя могут создаваться промежуточные версии, каждая из которых кроме адаптации к характеристикам среды эксплуатации содержит специфический набор изменений из состава вводимых в очередную базовую версию ПС.
Появление промежуточных версий у пользователей может сопровождаться ошибками, обусловленными опасным разрушением концептуальной целостности взаимосвязей компонентов ПС, вследствие некоторых противоречивых изменений. Такие ошибки являются следствием того, что корректировки программ для исправления ранее выявленных ошибок и для развития функциональных возможностей (п + 1)-й базовой версии могут быть взаимозависимы и частично альтернативны как непосредственно, так и через некоторые промежуточные программы и данные, что трудно обнаруживать. При подготовке (п + 1)-й версии эти связи между корректировками могут не проявляться, однако они должны проверяться в процессе комплексного тестирования. В то же время корректность каждого отдельного изменения может автономно не полностью испытываться при подготовке версии для конкретного пользователя. В результате предлагаемые пользователями отдельные изменения оказываются между собой не полностью согласованными, что может приводить к ошибкам функционирования версии ди-го пользователя. Особое значение синхронизация выполнения изменений ПС приобретает в распределенных системах типа клиент-сервер при наличии центра системы и множества удаленных, взаимодействующих клиентов с различными функциями, которые в одно и то же время эксплуатируют различные версии некоторого ПС.
На совет конфигурационного управления дополнительно возлагаются функции выявления связанных изменений и учета эксплуатации промежуточных версий с частичными изменениями у пользователей. Вследствие этого для сложных ПС может появляться необходимость конфигурационного учета и управления не только базовыми — эталонными версиями, но и рядом промежуточных версий пользователей с частичными изменениями. Сложность сопровождения и управления конфигурацией при этом резко возрастает. Поэтому в большинстве случаев целесообразно принимать организационные меры по ограничению числа частных распространяемых изменений между и-й и (п + 1)-й базовыми версиями в пределах только простейших локальных корректировок ошибок, существенно влияющих на качество конкретных версий ПС. Для предотвращения развала взаимодействия версий клиентских программ в распределенной системе следует запрещать несанкционированные изменения пользовательских версий ПС, минуя совет конфигурационного управления.
Для эффективной реализации перечисленных процессов представленная схема организации конфигурационного управления должна быть поддержана службой и базой данных тиражирования, архивирования и гарантированного хранения всей необходимой информации об объектах, их корректировках, версиях, авторах и их правах на изменения. Эта служба должна обеспечивать поставку пользователям только утвержденных копий версий ПС и/или их компонентов с полным, адекватным комплектом эксплуатационных документов, а также извещений на частные изменения конкретных, ранее приобретенных версий. Для гарантированного сохранения состояния и результатов модификаций программ и обеспечения возможности их анализа на любой стадии проекта, а также отката по истории выполненных корректировок, следует организовать четкую систему хранения и копирования подлинников, дубликатов и копий одного и того же программного продукта и документов. Эта система должна иметь соответствующих руководителей и специалистов, ответственных за полную сохранность всех результатов истории сопровождения и изменений конфигурации конкретного программного продукта в течение заданного интервала времени.
Для гарантированного сохранения от случайного или преднамеренного разрушения базовой версии ПС в составе коллектива конфигурационного управления должны быть выделены специалисты, ответственные за сохранность подлинников физических носителей и документации испытанных и утвержденных версий программного продукта. Целесообразно выделять специальный архив с резко ограниченным доступом, в котором накапливать подлинники базовых версий и дополнительные данные, необходимые для гарантии их сохранности и возможности восстановления. Для повышения надежности независимо сохраняются все изменения, внесенные в п-ю версию при подготовке (п + 1)-й базовой версии ПС. Благодаря этому в аварийном случае разрушения подлинника, дубликата и всех копий (п + 1)-й версии ПС должна обеспечиваться возможность их восстановление на базе предыдущей версии и зарегистрированных изменений. Кроме того, сохранение изменений в некоторых случаях облегчает обнаружение и локализацию ошибок, которые проявились в (п + 1)-й версии и отсутствовали в предыдущих версиях.
Do'stlaringiz bilan baham: |