Организация испытаний программного изделия [c.161]
Эту книгу можно прочитать от начала до конца и тем самым полностью ознакомиться с методологией организации проектирования программных изделий. Если же читателя интересуют не все аспекты управления, то можно прочитать лишь отдельные главы (часть II построена по функциональному принципу) и изучить только требуемые функции управления планирование, разработку, обслуживание, выпуск документации, испытания, организацию поддержки или сопровождение. В книге очень широко используется специальная терминология, однако ключевые термины выделяются курсивом и включены в предметный указатель. В каждой главе можно также найти ссылки на литературу для более глубокого обсуждения сложных вопросов, что повышает возможность использования книги в качестве справочного пособия. [c.17]
Наконец, при организации разработки программного изделия следует учесть еще один инструмент, хорошо вписывающийся в индивидуальные рабочие планы, — использование стандартов. Каждый, кто занимался программированием, по достоинству оценивает пользу стандартизации в кодировании и документировании программ. В равной мере важны стандарты управления, помогающие проводить планирование, анализ результатов и оценку эффективности осуществляемых проектов. Для того чтобы иметь возможность проверять полноту планирования и проводить декомпозицию проекта на любом этапе, необходимы системные и процедурные руководства, описывающие как методику проведения разработки, так и методики выполнения связанных друг с другом функций поддержки, выпуска документации и испытаний. [c.89]
Имеются весьма основательные доводы в пользу отделения друг от друга некоторых из функций, правильное выполнение которых способствует успешному выпуску изделия. К тому времени, когда почерпнутые из этой книги методы и средства будут введены в действие, такое разграничение функций наверняка можно будет реализовать. И тогда следует удовлетвориться, что группа испытаний работает независимо от группы разработки и потому не подчинена и не может ей подчиняться. Затем следует обособить функцию обслуживания, которая должна в равной степени охватывать обеспечение нормальной деятельности всех остальных групп. При этом, однако, нельзя забывать о планировании, организации поддержки, документирования и сопровождения программных изделий в целях лучшего удовлетворения потребностей пользователя. Если потребности пользователя изменяются, следует без колебаний преобразовывать и эти функции. Приняв такую стратегию, можно-смело приступать к более полной реализации принципов проектирования программного обеспечения и применять методы управления этим процессом точно так же, как их применяют в целом или по частям преуспевающие. руководители. [c.20]
Управление проектированием программного изделия включает семь функций планирование, разработку, обслуживание, выпуск документации, испытания, поддержку и сопровождение. На рис. 5.1 показан возможный вариант иерархической декомпозиции этих функций. Такая идеализированная организация вряд ли может существовать, поскольку она предполагает полную обособленность процессов, связанных с проектированием программных изделий, от других видов деятельности и изолирование всех функций друг от друга. Однако эта идеализация облегчает последующее рассмотрение. Необходимость в том или ином организационном подразделении [c.49]
По окончании фазы исследований группа планирования первым делом рассматривает и утверждает планы организации поддержки для каждого изделия или совокупности изделий. В течение всей фазы конструирования группа выпуска документации и группа испытаний готовятся к рассмотрению плана изданий документов и плана испытаний. Группа планирования (обычно под руководством администратора планирования) анализирует эти планы главным образом на их соответствие предписываемым формам и совместимость с соглашением о требованиях, конфигуратором и планом выпуска программного изделия. В течение фазы программирования группа поддержки готовит свой план, а группа планирования рассматривает его в том же порядке, в каком до этого рассматривались план изданий и план испытаний. [c.79]
Правильному формированию оценок помогает следующее важное соображение соотношение трудозатрат для групп разработки, испытаний и выпуска документации является достаточно постоянным, если следовать предлагаемой здесь методологии создания программного изделия. При централизованном распределении трудовых ресурсов по нескольким разным проектам, как и в случае распределения персонала внутри организации по функциональным группам в течение года, правильным является соотношение 10 3 2 (соответственно между группами разработки, испытаний и выпуска документации). Данное соотношение придает группе разработки больший вес, чем следовало бы в случае индивидуального проектирования каждого программного изделия это объясняется тем, что многие из трудовых затрат, выделенных для реализации функции разработки, либо вообще <не ориентированы на создание программного изделия, либо уходят на проекты, которые умирают раньше, чем попадают в сферу действия других функций. Для индивидуального проектирования программных изделий типичным является соотношение 10 5 3. [c.95]
Для того чтобы высшее руководство проектной организации могло решить, следует ли выделять средства на создание того или иного программного изделия, все статьи расходов шифруются и объединяются в одном документе, называемом распределением бюджета. Обычно этот документ составляет кто-либо из сотрудников группы разработки на основе данных, поступивших от группы испытаний и ряда других групп. Фактическое утверждение средств может быть отложено на более поздний период проектирования, однако обязанность группы испытаний — дать как можно более точные оценки, даже если о проекте мало что известно. Для [c.160]
Вопрос, какими силами осуществляется сопровождение, разрешается по-разному, в зависимости от таких факторов, как размер проектной организации, стабильность уровня трудовых затрат, соотношение видов изменений (корректирующих или расширяющих) в общем процессе усовершенствования изделия, длительность срока гарантийных обязательств, взятых производителем, и, наконец, качество испытаний, которое играет далеко не последнюю роль в этом списке. Размеры проектной организации определяют, представляется ли возможным создать автономное подразделение, специализирующееся на сопровождении изделий. Если такая возможность есть, ее необходимо использовать. Создание самостоятельной группы обеспечивает четкое взаимодействие между группами разработки и сопровождения, ускоряет подготовку полных спецификаций сопровождения, гарантирует надзор за соответствующими выпущенными программными изделиями, создает основу для обучения программистов, способствует выполнению гарантийных обязательств, дает возможность легко подсчитывать затраты на сопровождение. Если выделение автономной группы сопровождения невозможно, тогда в обязанность каждой группы разработчиков входит сопровождение своего изделия. Такое решение позволяет снизить накладные расходы, привлечь к сопровождению квалифицированных специалистов, способных быстро отыскать ошибку, и равномерно распределить работу между разработчиками. Однако оно имеет и недостатки сопровождение может со временем приобрести небрежный характер когда кто-ни будь из разработчиков увольняется, возможности сопровождения сокращаются исправление ошибок часто становится второстепенной работой и, наконец, иногда недостаточно тщательно анализируется целесообразность внесения тех или иных изменений. Если в работе над усовершенствованием изделия проводится много расширяющих изменений, то появляется естественное желание привлечь к этой деятельности опытных разработчиков вполне возможно, что наиболее эффективным решением будет исправление дефектов программ этими специалистами. Если сотрудники, работающие над проектами, часто переключаются с одного вида деятельности на другой, потери от этих переключений могли бы быть сведены к минимуму путем создания автономной группы сопровождения, располагающей хорошей методикой работы и исчерпывающей документацией. Если гарантийные обязательства по проекту кратковременны или вообще отсутствуют, сопровождение изделия можно обеспечить за счет незначительной дополнительной нагрузки на его разработчиков. Наконец, если группа разработки хорошо справляется со своей работой, число дефектов изделия будет небольшим и можно соответствующим образом уменьшить численность группы сопровождения. [c.192]
Фаза оценки в жизненном цикле изделия является буферной зоной между началом системных испытаний и началом практического использования изделия. В фазе оценки изделие подвергается строгому испытанию со стороны группы лиц, не являющихся разработчиками. Это делается для того, чтобы гарантировать, что изделие удовлетворяет требованиям и спецификациям, может быть использовано в среде пользователя, содержит необходимую документацию, которая точно и полно описывает программное обеспечение, может быть установлено при использовании соответствующих инструкций по вводу в действие свободно от каких-либо дефектов. Фаза оценки начинается, как только все компоненты собраны вместе и испытаны. Она заканчивается, когда организация, проводящая испытания, подтвердит, что изделие прошло все испытания и готово к эксплуатации. Фаза оценки обычно продолжается так же долго, как и фаза программирования, но методы структурного программирования могут сократить ее до одной трети фазы программирования (рис. 2.2). [c.27]
Общее правило организации деятельности по обеспечению качества изделий, заключающееся в установлении подотчетности соответствующих процедур как можно более высокому уровню руководства фирмы и отделении их от функции разработки, в полной мере применимо и к функции испытаний программного изделия. Группа испытаний в этом смысле должна быть органом, контролирующим деятельность других функциональных групп, особенно групп разработки и выпуска документации, и поэтому следует принять меры, предотвращающие возникновение причин для разногласий между ними. В фирме AB omputers (рис. 10.3) группа испытаний входит в сектор компоновки и выпуска, организационно не связанного с сектором программных изделий. [c.156]