Группа испытаний

Другая группа испытаний направлена на оценку таких личных качеств претендента, как эмоциональная устойчивость, умственные способности, уверенность в себе, волевые качества и др.  [c.43]


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


Группа планирования определяет необходимость в программном изделии, устанавливает возможность его реализации и осуществляет слежение за ним вплоть до конца его использования. Группа разработки составляет спецификации, конструирует, документирует, создает, отлаживает и собирает изделия. Группа обслуживания предоставляет средства вычислительной техники для обеспечения всех названных функций, для осуществления конфигурационного управления, распространения и разнообразной административной поддержки. Группа выпуска документации обеспечивает пользователей руководствами и другими справочными материалами. Группа испытаний дает независимую оценку как программному обеспечению, так и документации до их передачи пользователю. Группа поддержки обеспечивает распространение изделия и обучение пользователей, установку изделия на месте его использования и постоянную связь между отдельными группами и пользователями. Последняя, но не менее важная, чем остальные группы, — группа сопровождения — обеспечивает исправление ошибок и некоторые улучшения в фазе использования.  [c.29]

Деятельность, связанная с разработкой изделия, достигает своего пика в фазе программирования, когда планы испытаний дополняются спецификациями испытаний. Внутренняя структура изделия полностью описывается внутренней спецификацией, которая содержит сведения о том, как строится изделие, как формируется план обеспечения функционирования программного обеспечения и становятся доступными аппаратные ресурсы. В то время как группа разработки преобразует внешний и внутренний проекты в основное тело программ, т. е. в начальное воплощение изделия, группа испытаний трансформирует их с помощью спецификации испытаний в контрольные примеры группа выпуска документации создает справочные материалы группа поддержки программного обеспечения создает рекламные материалы и материал для обучения персонала. Эти последние действия начинаются с середины фазы программирования и продолжаются почти до конца фазы оценки. В самом конце фазы оценки группа обслуживания подготавливает руководство по вводу программного обеспечения в действие, называемое информационным листком выпуска, и вместе с группой сопровождения заносит в сопроводительную документацию все, что потребуется в будущем. Фаза использования начинается тогда, когда изделие объявлено готовым к передаче пользователям. Все, что остается после этого на рис. 2.3, — это периодическое создание корректирующих программ, предназначенных для исправления ошибок, обнаруженных пользователями, и обеспечения функционирования изделия в реальных условиях эксплуатации.  [c.34]


Теперь рассмотрим возможность решения проблемы обеспечения условий для продвижения по службе. Целесообразно учредить несколько должностных инстанций, таких, как ассистент инженера по программному обеспечению, инженер, старший инженер, ведущий инженер, с альтернативными назначениями для инженера, такими, как эксперт (в группе испытаний), редактор (в группе выпуска документации), аналитик (в группе поддержки). Необходимо составить формальные должностные инструкции, определяющие соответствующее повышение ответственности и устанавливающие одинаковый уровень квалификации для должностей одного уровня. Например, если должность старшего инспектора по программному обеспечению требует 10-летнего стажа работы на ответственных постах, то аналогичные требования должны быть установлены и для должности старшего редактора.  [c.58]

Окончательный план разработки изделия может быть выработан только в результате довольно серьезного изучения и обсуждения проблемы. Первая задача, которая обычно решается после распределения бюджета, состоит в формировании такого плана. Документ, в котором фиксируется план создания изделия, представляет собой технические условия, или соглашение о требованиях. В этом документе устанавливаются договорные отношения между разработчиком и пользователем, а также теми, кто должен заниматься продажей изделия. Помимо разработчика, который обычно готовит этот документ, в его составлении принимают участие многие функциональные подразделения, в том числе группы испытаний, выпуска документации, персонал, занятый внедрением, распространением, сопровождением, сбытом, обучением и поддержкой. Рассмотрение, утверждение и корректировка соглашения о требованиях являются, вероятно, наиболее важными моментами во всем процессе разработки именно благодаря соглашению о требованиях все заинтересованные стороны знают, какие ожидания можно связывать с создаваемым изделием что оно собой представляет, каковы его возможности и для чего оно нужно. Иными  [c.72]

Если программное изделие предназначено для многих пользователей, целесообразно выбрать одного или двух из них для поставки им бесплатно и с полной поддержкой опытного образца изделия при этом пользователи будут настолько польщены подобным выбором, что обеспечат отдачу, значительно превышающую стоимость поставки опытного образца изделия. К рабочим испытаниям опытного образца изделия полезно привлечь группу испытаний. Персонал этой группы получит возможность усовершенствовать свои тестовые программы и процедуры, основываясь на экспериментальных данных. Это касается также и группы выпуска документации, сотрудники которой смогут намного улучшить качество документации пользователя после проверки в действии своих первых решений.  [c.74]

По окончании фазы исследований группа планирования первым делом рассматривает и утверждает планы организации поддержки для каждого изделия или совокупности изделий. В течение всей фазы конструирования группа выпуска документации и группа испытаний готовятся к рассмотрению плана изданий документов и плана испытаний. Группа планирования (обычно под руководством администратора планирования) анализирует эти планы главным образом на их соответствие предписываемым формам и совместимость с соглашением о требованиях, конфигуратором и планом выпуска программного изделия. В течение фазы программирования группа поддержки готовит свой план, а группа планирования рассматривает его в том же порядке, в каком до этого рассматривались план изданий и план испытаний.  [c.79]

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

Обозначения Р — группа разработки О — группа обслуживания И — группа испытаний.  [c.92]

Следует иметь в виду один серьезный недостаток волнового эффекта задержка с утверждением внешних спецификаций может неблагоприятно отразиться на выполнении многих функций. Например, на рис. 7.4 штриховыми линиями показано, что, до тех пор пока не будут утверждены внешние спецификации, нельзя утверждать спецификации испытаний для группы испытаний, в рамках функции поддержки невозможно будет закончить рекламные материалы, а в рамках функции выпуска документации не удастся составить справочные материалы.  [c.112]

В фазе программирования группа выпуска документации представляет на рассмотрение ряд вариантов справочных материалов. В середине фазы программирования группой испытаний представляются для рассмотрения спецификации испытаний. Группа разработки тщательно изучает варианты документации и спецификации испытаний с тем, чтобы в них не было ошибок, порожденных неверными исходными предположениями. Если группа разработки в свое время подготовила корректные внешние спецификации, то их анализ не вызовет больших затруднений, хотя и займет немало времени. Если же некоторые положения внешних спецификаций пропущены или изложены недостаточно полно, то их проверка не только отнимет много времени, но и вызовет большие трудности. В этом случае придется изменять внешние спецификации, что может свести на нет запас времени, имеющийся в календарном плане проектирования.  [c.113]

Проводя испытания класса А, группа разработки прогоняет как можно больше контрольных примеров из числа предложенных группой испытаний. Эта ускоряет фактическое завершение независимых испытаний, которые проводит группа испытаний, и помогает устранить ошибки в самих тестах, являющиеся часто причиной разногласий между этими двумя группами.  [c.114]

В конце испытаний класса А группа разработки подготавливает спецификацию выпуска — документ, который связывает воедино составные части программного изделия в соответствии с их шифрами, требованиями ко вводу в действие и другими, ранее разрозненными данными, такими, как перечень замеченных дефектов и недоработок. Форма спецификации описана в разд. 15.4. После того как число ошибок, обнаруживаемых во время испытаний класса А, станет незначительным, группа разработки начинает приемочные испытания по программе, составленной группой испытаний. Приемочные испытания основываются на наборе тестов, выбранных из общей программы испытаний и предназначенных для выявления недостатков плохо продуманного программного изделия. К сожалению, под впечатлением результатов испытаний группа разработки склонна к проведению поспешных изменений в модулях, которые могут разрушить целостность программного изделия проведение приемочных испытаний убеждает всех, в том числе и руководство группы разработки, что для внесения дополнительных изменений в модули нет оснований.  [c.114]

Группа испытаний гордится своим профессиональным умением давать программному изделию всестороннюю оценку, и для достижения этой цели она создает целый арсенал тестов. Испытания на основе этих тестов обычно проводятся циклами, начиная с повторного проведения приемочных испытаний, на этот раз сотрудниками группы испытаний (разумеется, уверения группы разработки в успехе этих испытаний не принимаются в расчет). Цикл испытаний предполагает прогон как можно большего числа тестов в максимально сжатые сроки и завершается отчетом о результатах, который направляется в группу разработки. Если после цикла испытаний в программном изделии будут обнаружены недостатки,  [c.114]

В то время как группа испытаний проводит испытания класса В, группа выпуска документации представляет на рассмотрение справочные материалы. Группа разработки имеет последнюю возможность исправить ошибки в этих материалах, и поэтому их рассмотрение должно проводиться особенно тщательно. Группа выпуска документации учитывает замечания разработчиков и проводит последний просмотр материалов перед сдачей их в печать. Во время последнего просмотра группа разработки может исправить только типографские опечатки любые другие изменения задержат выпуск справочных материалов.  [c.115]

Фаза оценки заканчивается, когда группа испытаний излагает свои замечания в отчете об испытаниях класса В. Отчет составляется после того, как эта группа придет к выводу, что программное изделие удовлетворяет или, наоборот, не может удовлетворить критериям испытаний, которые описаны в разд. 10.8 и носят несколько субъективный характер. Группа разработки, естественно, надеется, что группа испытаний будет рекомендовать программное изделие к выпуску без замечаний. Однако чаще всего выявляется ряд нерешенных проблем, к рассмотрению которых привлекаются разработчики. Решение о выпуске программного изделия для широкого использования принимается на основе отчета группы испытаний и пояснительной записки группы разработки, которая обычно предлагает план устранения обнаруженных недостатков. Поэтому группа разработки тщательно изучает отчет об испытаниях класса В и рекомендует меры для устранения всех замеченных дефектов. При этом группа разработки может вступить во взаимодействие с группой сопровождения, если существующие дефекты могут быть компенсированы какими-то средствами во время эксплуатации.  [c.115]

Вскоре после утверждения соглашения о требованиях группа испытаний передает на рассмотрение свой план испытаний. Этот план прежде всего направляется в группу обслуживания, которая убеждается, что для проведения испытаний классов В и С имеются соответствующие программные и технические средства. Для приобретения и установки этих средств заключаются окончательные договоры, что также оправдывается твердым намерением руководства завершить проект.  [c.125]

Вскоре после начала испытаний класса В группа обслуживания начинает готовиться к распространению программного изделия. Основной задачей на этом этапе является подготовка информационного листка выпуска, который составляется для пользователей и указывает, какие компоненты программного изделия подлежат передаче и как их внедрить. Информационный листок выпуска подготавливается на основе материалов группы разработки и передается в группу испытаний, где используется в качестве одного из руководящих материалов приемных испытаний класса В. Спецификация выпуска, описанная в разд. 15.4, служит документом, на основе которого организуются испытания.  [c.127]

Информационный листок выпуска принимает законченный вид после того, как группа испытаний составит отчет об испытаниях класса В, рекомендующий выпуск изделия. Информационный листок выпуска нельзя закончить раньше этого момента, так как в нем должны быть описаны все дефекты программного изделия, которые были обнаружены во время проведения испытаний класса В, но не настолько серьезные, чтобы оправдать задержку выпуска изделия. Эти дефекты могут быть обнаружены, как в программных средствах, так и в документации.  [c.127]

После завершения работ по данной заявке группа сопровождения сообщает о результатах группам испытаний и обслуживания. Группа обслуживания уведомляет о результатах рассмотрения заявки пользователя, а также группу поддержки, осуществ-  [c.131]

В процессе контролирования выполнения заявки группа обслуживания регулярно напоминает группам испытаний и сопровождения о необходимости принять соответствующие меры по удовлетворению запроса и сообщает руководству о продвижении работ в этом направлении. Информация в адрес руководства представляется в форме периодических отчетов, подобных сводке заявок на техническое обслуживание, описанной в разд. 16.7.  [c.132]

В самом начале фазы оценки группа выпуска документации заканчивает составление окончательных вариантов всей документации вместе с иллюстрациями. Рукописи направляются на рассмотрение другим группам. В изучении рукописей принимают обязательное участие группы разработки, испытаний и поддержки. В частности, группа испытаний проверяет эти рукописи таким же образом, как и программное изделие она сверяет содержание документов со спецификациями и проверяет их на соответствие. Группа испытаний подготавливает перечень дефектов, замеченных как в документации, так и в программном изделии (см. разд. 10.8). Группа выпуска документации должна принять решение либо устранить обнаруженные -недостатки, либо привести доводы в пользу существующей редакции материалов.  [c.147]

Если группа испытаний удовлетворена содержанием рукописей, последние сдаются в печать и готовая документация поступает на распространение. Решение об издании материалов обычно принимается раньше, чем будет рекомендован выпуск программного изделия. Поэтому группа выпуска документации имеет большой запас времени для обеспечения высокого качества печатной продукции.  [c.147]

В фазовом обзоре IV все внимание участников проекта сосредоточено на передаче программ в распоряжение группы испытаний. Группа выпуска документации участвует в этом обзоре лишь в том случае, когда для составления материалов нужны дополнительные источники или если план выпуска документации нуждается в корректировке. В фазовом обзоре V группа выпуска документации участвует только в том случае, когда необходимы ее рекомендации относительно выпуска изделия с недоработками. При этом всестороннему обсуждению подвергаются все аргументы за и против соблюдения календарных сроков и оценивается ущерб, наносимый качеству программного изделия. В фазовом обзоре VI основное внимание сосредоточено на проблеме ослабления поддержки программного изделия или ее полной отмены. К этому времени изменения в документации настолько незначительны, что становятся частью деятельности группы сопровождения, и поэтому группа выпуска документации в фазовом обзоре VI не участвует,  [c.149]

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

Насколько можно считать достоверными результаты анализа качества программного изделия, который осуществляется в рамках функции испытаний Очевидно, что группа испытаний оказывает значительное влияние на качественную сторону проектирования, используя такие средства воздействия на ход проектирования, как технические ревизионные комиссии (гл. 18), соглашение о требованиях (гл. 13), спецификации (гл. 15) и обзоры состояния проекта в различных фазах. Однако группа испытаний не может нести ответственность за обеспечение качества изделия, так как она не управляет процессом создания отдельных компонентов програм-  [c.150]

В данной книге предполагается, что в задачи группы испытаний входя 1. проведение испытаний в юм смысле, который был разъяснен выше выработка оценок, понимаемая как измерение свойств изделия (надежности, удобства использования и т. д.) участие в фазовых обзорах с целью влияния на ход разработки. В некоторых фирмах в порядке эксперимента к участию в проекте привлекаются специалисты по обеспечению качества, однако эффективность таких мероприятий еще предстоит доказать, поскольку выбор правильного соотношения ответственности за разработку и испытание изделия является достаточно тонким делом и в задачи управления входит четкое регулирование взаимоотношений между разработчиками и испытателями в процессе проектирования.  [c.151]

Третья — последняя стадия испытаний (испытания класса С) осуществляется после того, как группа испытаний рекомендует выпуск изделия и его распространение. Испытания класса С похожи на выборочный контроль производства, поскольку с полки случайным образом выбирают -экземпляр программного изделия и выполняют прогон программ, бегло анализируя результаты.  [c.153]

Режим I испытаний подразумевает полный цикл деятельности группы испытаний, включая планирование испытаний, разработку тестов, их прогон и анализ результатов. Обычно эта процедура является высшей и наиболее строгой формой контроля и используется для проверки большинства универсальных программных изделий.  [c.153]

Режим II позволяет проводить ускоренные испытания изделия, поскольку в этом случае группа испытаний несет ответственность только за анализ результатов испытаний, а составление плана и спецификаций испытаний, построение тестов и их прогон поручаются разработчикам.  [c.153]

Режим III реализуется без участия группы испытаний. Этот режим следует использовать только в случаях крайней необходимости, например при сильном нарушении сроков проектирования опытного образца, когда отсутствие независимых испытаний изделия или по крайней мере текущего контроля за испытаниями допускается. Для гарантии успеха даже в этом неблагоприятном случае следует предусмотреть ввод в действие и поддержку такого изделия силами группы разработки нельзя рассчитывать на то, что это сможет сделать кто-нибудь другой, поскольку нет полной уверенности в том, что качество программного изделия достаточно высоко для передачи его в руки пользователя без сопровождения.  [c.153]

Из таблицы видно, что все категории испытаний претендуют на их включение в состав испытаний класса А в класс В могут войти все тесты, за исключением двух категорий, а в класс С включены только два вида испытаний. Группа разработки обычно участвует на всех стадиях испытаний, группа испытаний — на второй и третьей стадиях, а группа обслуживания проводит последнюю стадию испытаний.  [c.156]

Организационная структура группы испытаний  [c.156]

Организуя испытания программного изделия, необходимо иметь четкий ответ на вопрос Где кончается процесс оценки и начинается процесс отладки программного обеспечения Прежде всего важно ограничить деятельность испытателей, возложив на них только обязанность фиксировать факт наличия ошибки им не следует разрешать диагностировать причины ошибок и, более того, указывать точное место их возникновения. Если не проводить в жизнь такое разделение труда, то никогда не удастся отделить задачи разработки от обязанностей испытателей и разработчики будут уповать на то, что группа испытаний сама завершит отладку программ. Надо также тщательно продумать вопрос о том, на кого следует возложить ответственность за компоновку программных средств в систему или за обеспечение единства программных, микропрограммных и аппаратных средств ЭВМ. В условиях, когда в большом проекте участвуют несколько фирм-подрядчиков,  [c.156]

Режимы испытаний I — проводятся группой испытаний ( X ) II — контролируются группой испытаний ( ) III — группа испытаний не участвует ( ) Подразделения, проводящие испытания Р — группа разработки О — группа обслуживания И — группа испытаний  [c.157]

Пользователи присылают много замечаний, указывающих на обилие ошибок, в результате чего в организации выделяется автономная группа испытаний, которая не оказывает влияния на проектирование.  [c.159]

Деятельность группы испытаний становится столь активной, что руководитель группы разработки протестует, заявляя Как я могу уложиться в плановые сроки, если группа испытаний придирается к любой мелочи и не соглашается рекомендовать выпуск программного изделия Тогда группа испытаний становится частью группы разработки, и их совместная деятельность продолжается успешнее, так как испытатели утвердили независимый стиль работы и не склонны допускать нарушения этой традиции.  [c.159]

Руководители проекта и руководство фирмы осознают, что проблема испытаний требует действительно профессионального подхода и что сотрудники группы испытаний могут играть важную роль в процессах планирования и проектирования изделия. Эта группа начинает постоянно участвовать в составлении планов и спецификаций в результате вновь возникают трения, так как руководитель группы разработки часто нейтрализует предложения испытателей, утверждая Если мы будем делать все, что требует группа испытаний, мы не выполним календарный план и нам не хватит отпущенных средств . После этого группа испытаний выделяется из группы разработки и становится самостоятельной организационной единицей.  [c.159]

Независимо от места, которое занимает группа испытаний в проектной организации, следует не упускать из виду необходимость стимулирования работы ее сотрудников. Группу испытаний  [c.159]

В фазе исследований деятельность группы испытаний должна предусматривать интенсивное общение с другими группами для решения вопросов о том, какие режимы испытаний следует установить, когда начать испытания класса В, какие новые методы или средства должны быть привлечены для проведения испытаний. Необходимо также провести достаточно глубокий анализ, чтобы установить, какие ресурсы потребуются на каждой стадии испытаний, и дать оценку календарных сроков и предполагаемых затрат.  [c.160]

Для того чтобы высшее руководство проектной организации могло решить, следует ли выделять средства на создание того или иного программного изделия, все статьи расходов шифруются и объединяются в одном документе, называемом распределением бюджета. Обычно этот документ составляет кто-либо из сотрудников группы разработки на основе данных, поступивших от группы испытаний и ряда других групп. Фактическое утверждение средств может быть отложено на более поздний период проектирования, однако обязанность группы испытаний — дать как можно более точные оценки, даже если о проекте мало что известно. Для  [c.160]

Во время фазы анализа осуществимости проекта группа разработки формулирует и фиксирует в документах требования и цели создания изделия. В этот период группа испытаний имеет первую возможность повлиять на качество изделия, представляя свои материалы для выработки соглашения о требованиях. В процессе поиска компромиссных решений, сопутствующих разработке, пересмотру и утверждению этого документа, определяются и регистрируются необходимые уровни испытании (рис. 10.2), а также формулируются определенные положения, касающиеся свойств изделия. Функция испытаний при этом играет роль самой активной движущей силы, которая побуждает разработчиков соглашаться на введение количественных характеристик требований и целей, чтобы в дальнейшем имелась основа для проведения испытаний.. Соглашение о требованиях является одновременно и планом разработки. Поэтому оно содержит не только описание того, что должно быть сделано, но и довольно много сведений о путях реализации проекта, с тем чтобы его участники могли убедиться в обоснованности планов. В соглашении о требованиях предусмотрен и специальный раздел, в котором группа испытаний описывает свой план проверок выдержка из этого раздела соглашения о требованиях к изделию ASK приведена ниже  [c.161]

На протяжении всей фазы анализа осуществимости проекта группа испытаний изучает проект соглашения о требованиях и на основе этого анализа и других исходных материалов формулирует цели очередных плановых этапов проектирования. Важными этапами считаются следующие передача плана испытаний и специ фикаций испытаний на анализ утверждение этих документов, передача программы приемочных испытаний группе разработки установление начальных дат испытаний класса В и каждого их цикла. Некоторые из этих этапов включаются в раздел соглашения о требованиях, касающийся планирования (см. рис. 14.8).  [c.163]

Общее правило организации деятельности по обеспечению качества изделий, заключающееся в установлении подотчетности соответствующих процедур как можно более высокому уровню руководства фирмы и отделении их от функции разработки, в полной мере применимо и к функции испытаний программного изделия. Группа испытаний в этом смысле должна быть органом, контролирующим деятельность других функциональных групп, особенно групп разработки и выпуска документации, и поэтому следует принять меры, предотвращающие возникновение причин для разногласий между ними. В фирме AB omputers (рис. 10.3) группа испытаний входит в сектор компоновки и выпуска, организационно не связанного с сектором программных изделий.  [c.156]

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

Смотреть страницы где упоминается термин Группа испытаний

: [c.312]    [c.43]    [c.132]    [c.151]    [c.160]   
Методы управления проектированием программного обеспечения (1981) -- [ c.29 , c.114 , c.153 , c.156 , c.173 ]