Иногда вместо расширенных испытаний класса В проводится эксплуатационная проверка, подразумевающая участие пользователей в прогоне соответствующих контрольных примеров из программы испытаний класса В. Такая проверка может принести большую пользу, хотя и заключает, в себе определенную долю риска. Ее полезность состоит в запуске контрольных примеров в реальных условиях эксплуатации опасность же заключается в том, что пользователю могут стать очевидными любые дефекты программного изделия и применяемой методологии проектирования. Для уменьшения степени риска эксплуатационная проверка начинается только после проведения хотя бы одного цикла испытаний класса В, когда становится возможным в определенной мере оценить качество изделия и вероятность обнаружения крупных дефектов. Группа поддержки всегда подбирает участников испытаний из числа пользователей и оказывает им помощь в работе. [c.185]
В течение всей фазы использования основная задача группы поддержки состоит в обнаружении дефектов программного изделия и нейтрализации соответствующих отрицательных последствий. Каждый действительно существующий дефект является либо ошибкой, связанной с отклонением от требований внешних спецификаций, либо неожиданно ценным приобретением для пользователя. Оба вида дефектов требуют использования соответствующих процедур нейтрализации отрицательных последствий. [c.187]
В фазе оценки группа испытаний может формировать рапорты о дефектах программного изделия, которые не были устранены к моменту его выпуска из-за решения руководства оценивать готовность изделия, без согласования с группой испытаний. Перечень рапортов о неисправленных дефектах включается в спецификации версии и в СС. По каждому такому рапорту составляется заявка на внесение исправлений и передается в систему координации обслуживания. [c.294]
ДЕФЕКТЫ ПРОГРАММНОГО ИЗДЕЛИЯ [c.297]
Дефект программного изделия 187 Диаграмма тенденций 303, 309 Документация внешняя 23 [c.381]
Группа планирования осуществляет текущий контроль за изделием в фазе использования, непрерывно наблюдая за уведомлениями о дефектах и запросами на расширение. При этом кто-то должен определять истинную необходимость внесения изменений, связанных с устранением ошибок и дефектов, или целесообразность создания новой версии с целью реализации требуемого расширения возможностей. Следует также пересматривать и постепенно снижать уровень поддержки, в результате чего должна быть выработана рекомендация о снятии программного изделия с производства. Таким лицом может быть администратор планирования, который способен оценить целесообразность того или иного предложения, поэтому именно он рассматривает все рекомендации, касающиеся текущего контроля за изделием в фазе использования. [c.80]
В конце испытаний класса А группа разработки подготавливает спецификацию выпуска — документ, который связывает воедино составные части программного изделия в соответствии с их шифрами, требованиями ко вводу в действие и другими, ранее разрозненными данными, такими, как перечень замеченных дефектов и недоработок. Форма спецификации описана в разд. 15.4. После того как число ошибок, обнаруживаемых во время испытаний класса А, станет незначительным, группа разработки начинает приемочные испытания по программе, составленной группой испытаний. Приемочные испытания основываются на наборе тестов, выбранных из общей программы испытаний и предназначенных для выявления недостатков плохо продуманного программного изделия. К сожалению, под впечатлением результатов испытаний группа разработки склонна к проведению поспешных изменений в модулях, которые могут разрушить целостность программного изделия проведение приемочных испытаний убеждает всех, в том числе и руководство группы разработки, что для внесения дополнительных изменений в модули нет оснований. [c.114]
Фаза оценки заканчивается, когда группа испытаний излагает свои замечания в отчете об испытаниях класса В. Отчет составляется после того, как эта группа придет к выводу, что программное изделие удовлетворяет или, наоборот, не может удовлетворить критериям испытаний, которые описаны в разд. 10.8 и носят несколько субъективный характер. Группа разработки, естественно, надеется, что группа испытаний будет рекомендовать программное изделие к выпуску без замечаний. Однако чаще всего выявляется ряд нерешенных проблем, к рассмотрению которых привлекаются разработчики. Решение о выпуске программного изделия для широкого использования принимается на основе отчета группы испытаний и пояснительной записки группы разработки, которая обычно предлагает план устранения обнаруженных недостатков. Поэтому группа разработки тщательно изучает отчет об испытаниях класса В и рекомендует меры для устранения всех замеченных дефектов. При этом группа разработки может вступить во взаимодействие с группой сопровождения, если существующие дефекты могут быть компенсированы какими-то средствами во время эксплуатации. [c.115]
После принятия решения о выпуске программного изделия группа обслуживания печатает информационный листок выпуска в таком количестве экземпляров, которое достаточно для обеспечения начального распространения программного изделия и выполнения всех заказов, поступивших до принятия решения о модернизации программного изделия (модификация программного изделия приводит к пересмотру информационного листка выпуска, если только для этого нет других причин, таких, как указание исправленных дефектов или перечисление вновь замеченных дефектов). Затем группа обслуживания подготавливает достаточное количество экземпляров программного изделия, чтобы начать распространение, имея при этом некоторое количество копий в запасе комплектует и упаковывает отдельные экземпляры программных средств, информационный листок выпуска и соответствующую техническую документацию. Далее она завершает испытания класса С, выбирая в качестве объекта испытаний (случайным образом), один или несколько комплектов программного изделия, проверяя соответствие содержимого комплекта сопроводительному листку и проводя некоторые простые операции, например по проверке годности машинных носителей для чтения. [c.129]
В самом начале фазы оценки группа выпуска документации заканчивает составление окончательных вариантов всей документации вместе с иллюстрациями. Рукописи направляются на рассмотрение другим группам. В изучении рукописей принимают обязательное участие группы разработки, испытаний и поддержки. В частности, группа испытаний проверяет эти рукописи таким же образом, как и программное изделие она сверяет содержание документов со спецификациями и проверяет их на соответствие. Группа испытаний подготавливает перечень дефектов, замеченных как в документации, так и в программном изделии (см. разд. 10.8). Группа выпуска документации должна принять решение либо устранить обнаруженные -недостатки, либо привести доводы в пользу существующей редакции материалов. [c.147]
В фазе оценки группа обслуживания подготавливает руководство по вводу программного изделия в действие — информационный листок выпуска. Этот листок создается в соответствии со стандартами группы выпуска документации, которая и обеспечивает его выход в свет. Группа выпуска документации привлекается к обсуждению решения руководства фирмы о выпуске изделия, если предложены рекомендации оставить без исправления замеченные в документах дефекты. Такая рекомендация может быть сделана только в том случае, если бы устранение дефектов при- [c.147]
В этой главе рассматриваются задачи, решаемые группой испытаний программного изделия. Под испытаниями мы подразумеваем не отладку программ, признанную определять, почему в программе возникает та или иная ошибка, и устранять ее причины, а процесс установления самого факта наличия дефектов и расхождений между истинными свойствами программного изделия и его спецификациями. [c.150]
Обнаруживая тот или иной дефект, испытатели доказывают факт его наличия с помощью различных материалов, например посредством консольного протокола, распечатки текущего состояния системы, выдачи листингов, отметок времени и дампов памяти. Проводя эту работу, испытатели должны воздержаться от искушения самостоятельно исправить дефекты испытываемого изделия, Эта работа входит в обязанности разработчиков, и если ее проводить в рамках функции испытаний, то группа разработки вообще окажется вне ее. Если разработчики не будут участвовать в отладке, то конструирование и компоновка изделия будут проводиться не так тщательно, как следует фаза оценки затянется из-за неэффективного использования ресурсов по вине обеих групп мало того, к пользователям могут попасть программы, наспех залатанные группой испытаний. Такие программные средства наверняка введут в заблуждение группу сопровождения и могут привести к [c.168]
После того как группа обслуживания отправила программное изделие потребителям, фаза оценки заканчивается и группа испытаний выполняет новые обязанности. Ввод в действие и эксплуатация программного изделия пользователями позволяют выявлять новые дефекты. По мере поступления сообщений о каждом обнаруженном дефекте, например в форме заявок на техническое обслуживание, группа испытаний его регистрирует и разрабатывает контрольные примеры, позволяющие проверить правильность изменений, которые должны быть внесены группой сопровождения. Прежде чем приступить к распространению исправленного изделия, группа испытаний проводит возвратную проверку, призванную гарантировать, что не только устранен прежний дефект, но и не появилось новых. [c.172]
Механизм устранения ошибок обеспечивается системой заявок на техническое обслуживание, которая охватывает такие группы, как группа обслуживания (гл. 8, разд. 8.7), группа испытаний (гл. 10, разд. 10.9), группа сопровождения (гл. 12, разд. 12.5). Работа по каждому конкретному дефекту начинается с того момента, когда периферийные специалисты группы поддержки убедятся в существовании ошибки и вышлют соответствующее уведомление. Это уведомление поступает в центральную группу поддержки вместе с дополнительными материалами, такими, как тексты программ и описание процедур, в которых была обнаружена ошибка, дампы оперативной памяти и диагностические сообщения программ. Центральная группа поддержки устанавливает, не возникла ли ошибка в результате неправильного понимания и не требует ли она действий в рамках функции сопровождения. Если центральная группа найдет способ временного исправления ошибки или способ работы с ошибкой в течение времени, требуемого на анализ дефекта, она высылает пользователям соответствующее пояснение, как действовать в создавшейся ситуации. Если для устранения дефекта необходимо участие группы сопровождения, центральная группа направляет все имеющиеся материалы по данной проблеме в группу обслуживания. Начиная с этого времени группа поддержки ожидает ответа от группы обслуживания, которая обеспечивает прохождение заявки через группы разработки, испытаний и сопровождения. Если группа сопровождения предлагает средства временного исправления ошибок, центральная группа направляет их периферийному персоналу поддержки для реализации. Тогда и только тогда, когда исправления, утвержденные группой испытаний, порождают новую редакцию программного изделия, периферийный персонал внедряет от- [c.187]
Группа сопровождения выполняет обязанности, связанные с исправлением дефектов изготовленных программных изделий (корректирующее сопровождение) или незначительными изменениями (адаптивное сопровождение). Эти виды усовершенствований изделия строго разграничены, так как они по-разному отражаются на конфигурационном управлении. Например, простое исправление ошибки предполагает приведение в соответствие с ним спецификаций, текстов программ и документов. В то же время реализация какого-либо нового свойства изделия, пусть даже незначительного, по существу, требует пересмотра спецификаций, текстов программ и справочных материалов. Введение новых свойств может отразиться и на совместимости программных средств. Кроме того, для их проверки необходимо создавать специальные контрольные примеры. [c.191]
Вопрос, какими силами осуществляется сопровождение, разрешается по-разному, в зависимости от таких факторов, как размер проектной организации, стабильность уровня трудовых затрат, соотношение видов изменений (корректирующих или расширяющих) в общем процессе усовершенствования изделия, длительность срока гарантийных обязательств, взятых производителем, и, наконец, качество испытаний, которое играет далеко не последнюю роль в этом списке. Размеры проектной организации определяют, представляется ли возможным создать автономное подразделение, специализирующееся на сопровождении изделий. Если такая возможность есть, ее необходимо использовать. Создание самостоятельной группы обеспечивает четкое взаимодействие между группами разработки и сопровождения, ускоряет подготовку полных спецификаций сопровождения, гарантирует надзор за соответствующими выпущенными программными изделиями, создает основу для обучения программистов, способствует выполнению гарантийных обязательств, дает возможность легко подсчитывать затраты на сопровождение. Если выделение автономной группы сопровождения невозможно, тогда в обязанность каждой группы разработчиков входит сопровождение своего изделия. Такое решение позволяет снизить накладные расходы, привлечь к сопровождению квалифицированных специалистов, способных быстро отыскать ошибку, и равномерно распределить работу между разработчиками. Однако оно имеет и недостатки сопровождение может со временем приобрести небрежный характер когда кто-ни будь из разработчиков увольняется, возможности сопровождения сокращаются исправление ошибок часто становится второстепенной работой и, наконец, иногда недостаточно тщательно анализируется целесообразность внесения тех или иных изменений. Если в работе над усовершенствованием изделия проводится много расширяющих изменений, то появляется естественное желание привлечь к этой деятельности опытных разработчиков вполне возможно, что наиболее эффективным решением будет исправление дефектов программ этими специалистами. Если сотрудники, работающие над проектами, часто переключаются с одного вида деятельности на другой, потери от этих переключений могли бы быть сведены к минимуму путем создания автономной группы сопровождения, располагающей хорошей методикой работы и исчерпывающей документацией. Если гарантийные обязательства по проекту кратковременны или вообще отсутствуют, сопровождение изделия можно обеспечить за счет незначительной дополнительной нагрузки на его разработчиков. Наконец, если группа разработки хорошо справляется со своей работой, число дефектов изделия будет небольшим и можно соответствующим образом уменьшить численность группы сопровождения. [c.192]
В конце фазы программирования группа сопровождения активно включается в работу над проектом, начиная подготовку спецификации сопровождения. Основным условием успешного завершения этой работы является наличие готовой внутренней спецификации. Спецификация сопровождения содержит внутреннюю спецификацию, дополненную техническим описанием и листингами программ (гл. 15, разд. 15.5). Как видно из рис. 12.2, другим необходимым условием завершения спецификации сопровождения является утверждение внешней спецификации в этом случае существует гарантия того, что внутренний и внешний проекты программного изделия приобрели стабильный характер. Рис. 12.2 показывает также, что ко времени составления спецификации сопровождения должен быть закончен документ, регламентирующий ввод программного изделия в действие,— так называемый информационный листок выпуска (разд. 8.6), что позволяет группе сопровождения учесть в спецификации сопровождения принятые и отклоненные заявки, замеченные, но неустраненные дефекты и гарантировать соблюдение требований к выполнению процедуры ввода программного изделия в действие. [c.196]
Уровень поддержки 2 Не планируется новых версий или программных изделий-заменителей, поэтому заявки на расширение рассматриваться не должны все еще ожидается значительное количество заявок на исправление дефектов,- поэтому должны выпускаться уведомления об изменениях. [c.252]
Когда программное изделие передается из группы разработки в группу испытаний, а затем в группу обслуживания, оно сопровождается документом, который называется спецификацией версии. Спецификация версии содержит следующую информацию точный идентификатор изделия, включая полную структурную диаграмму,. охватывающую все модули требования к оборудованию, включая допустимые замены имеющуюся по данному изделию документацию и перечень наиболее существенных дефектов. Группа обслуживания составляет информационный листок выпуска изделия на основе спецификаций версий входящих в него других программных изделий. Группа сопровождения дополняет каждую спецификацию сопровождения информацией из соответствующих спецификаций версий. [c.296]
Составляется список заявок, не учтенных к моменту поступления программного изделия в группу испытаний. Если все заявки удовлетворены, делается пометка Отсутствует , но чаще всего бывает так, что требование ускорения темпов работы заставляет разработчиков оставлять неисправленными некоторые незначительные дефекты. Сюда же включаются рапорты о дефектах, составляемые в ходе испытаний класса А. [c.298]
Разд. 3. (2,3) л. 1.3 и 3. (2,3). л. 1.4 внутренней спецификации изделия определяют программное обеспечение и оборудование, которые необходимы для обеспечения функционирования программного изделия, а разд. 5.2 внешней спецификации указывает программное обеспечение и оборудование, необходимые для ввода его в действие. В разд. 3.1 спецификации версии уточняется потребность в машинных ресурсах для внесения изменений по требованию заказчиков, или для проведения испытаний класса В. В будущем из-за скрытых дефектов могут возникать ошибки, и запись, обеспечивающая условия для нормальной эксплуатации программного изделия, будет способствовать устранению обнаруживаемых дефектов. [c.300]
Как указано в предыдущем разделе, лицензии или контракты могут оказаться лучшим средством установления прав собственности на программные изделия. Лицензии и контракты используются для указания гарантийных обязательств, а также помощи, которая будет оказана заказчику, например ввод в действие, освоение, модификация, консультация по использованию. В лицензиях и контрактах определяются необходимые виды и сроки платежей, а также уточняется степень ответственности за дефекты программных средств или неправильное их использование. [c.350]
Комиссия по расширению возможностей рассматривает заявки на проверку или расширение, но не устранение дефектов и решает судьбу каждой из них. Эта комиссия является разновидностью постоянной технической ревизионной комиссии. Последняя может быть созвана для рассмотрения заявок на проверку и расширение в любое время до выпуска изделия. После его выпуска заявки на проверку и расширение направляются уже в комиссию по расширению. Заявки на проверку обычно выполняются быстро, так как они представляют реальную необходимость. Например, если вводятся в действие требования федерального законодательства, касающегося обеспечения секретности, многие программные изделия подлежат изменению для обеспечения более строгой защиты данных заказчика. Отношение к заявкам на расширение совсем иное. Их выполнение необязательно, поэтому здесь проводится серьезный технический и экономический анализ целесообразности удовлетворения заявки. Поскольку тот, кто подает заявку на расширение, естественно, поддерживает его, а группа сопровождения обычно не склонна проводить никаких, даже наиболее полезных расширений, комиссия уполномочена решать этот вопрос самостоятельно. Многие заявки на расширение остаются открытыми в течение длительного времени. Они рассматриваются при каждом [c.356]
К автоматизированным относятся процессы, в которых основная работа механизирована полностью, а вспомогательная — частично (полуавтоматы) или полностью (автоматы). При этом управление работой механизмов происходит автоматически. Функции рабочих сводятся к наладке машин, наблюдению за их работой и устранению дефектов, а на полуавтоматах, кроме того, к периодической подаче сырья (заготовок) и снятию готовых изделий, напр, токарная обработка деталей на станках с программным управлением, изготовление продукции на автоматических линиях и др. К аппаратурным относятся процессы, осуществляемые на специальном оборудовании (аппаратах) путем воздействия [c.100]
Фаза оценки в жизненном цикле изделия является буферной зоной между началом системных испытаний и началом практического использования изделия. В фазе оценки изделие подвергается строгому испытанию со стороны группы лиц, не являющихся разработчиками. Это делается для того, чтобы гарантировать, что изделие удовлетворяет требованиям и спецификациям, может быть использовано в среде пользователя, содержит необходимую документацию, которая точно и полно описывает программное обеспечение, может быть установлено при использовании соответствующих инструкций по вводу в действие свободно от каких-либо дефектов. Фаза оценки начинается, как только все компоненты собраны вместе и испытаны. Она заканчивается, когда организация, проводящая испытания, подтвердит, что изделие прошло все испытания и готово к эксплуатации. Фаза оценки обычно продолжается так же долго, как и фаза программирования, но методы структурного программирования могут сократить ее до одной трети фазы программирования (рис. 2.2). [c.27]
В робототехнике распознавание образов осуществляется системами технического зрения. Они используются в системах технического контроля для обнаружения дефектов в заготовках и изделиях, в станках с программным управлением - при управлении позиционированием деталей, сборкой, сваркой и т.п. В широко разрабатывающихся сейчас алгоритмах по распознаванию и "пониманию" сложных сцен, включающих несколько произвольно расположенных в пространстве трехмерных объектов, используется информация о расположении и конфигурации теней, полутонов, об особенностях отражения света материалами различных текстур (металл, дерево, ткань и пр.) и т.п. [c.64]
Уровни поддержки назначаются программным изделиям для того, чтобы текущие и потенциальные пользователи могли узнать, какая помощь им гарантируется при исправлении дефектов и расширении возможностей программных средств. В фирме AB omputers возможно назначение одного из трех уровней [c.252]