Виды испытаний программного изделия

Управление проектированием программного изделия включает семь функций планирование, разработку, обслуживание, выпуск документации, испытания, поддержку и сопровождение. На рис. 5.1 показан возможный вариант иерархической декомпозиции этих функций. Такая идеализированная организация вряд ли может существовать, поскольку она предполагает полную обособленность процессов, связанных с проектированием программных изделий, от других видов деятельности и изолирование всех функций друг от друга. Однако эта идеализация облегчает последующее рассмотрение. Необходимость в том или ином организационном подразделении  [c.49]


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

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


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


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

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

Технологический процесс создания САПР осуществляется на нескольких предметно-специализированных технологических линиях и сборочном участке с полигоном для испытаний готовой системы. Предметная специализация технологических линий определяется составом и содержанием компонентов САПР (видов ее обеспечения — методического и математического, технического, программного, информационного, организационно-экономического и кадрового). На каждой из технологических линий системное изделие проходит определенные стандартами стадии обработки.  [c.42]

Безусловно, не к любому программному обеспечению необходимо применять строгие методы планирования, проектирования и испытаний, обычно используемые для других видов изделий. Как быть, например, со специалистом по бухгалтерскому учету, который разрабатывает программу для составления единственного в своем роде отчета на основе ежемесячных сведений по счетам дебиторов, содержащихся в базе данных Или как быть со специалистом по статистике, который пишет программу поиска скрытых повторяющихся последовательностей в потоке данных или во временных рядах Следует ли такие программные средства рассматривать как изделия Ясно, что не следует.  [c.21]

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

: [c.152]    [c.115]    [c.171]