Документирование системы качества

Все элементы, требования и положения системы качества должны быть четко документально оформлены с соблюдением требований систематичности и аккуратности.

Программа качества

Поставщик должен подготовить и документально оформить программу качества для осуществления деятельности в области обеспечения качества при каждой разработке программного обеспечения на основе стандартизованной системы качества. Он должен также обеспечить, чтобы программа качества была понятна и соблюдалась заинтересованными организациями.

Внутренние проверки системы качества

Поставщик должен осуществлять обширную систему плановых и документированных внутренних проверок системы качества с целью контроля соответствия деятельности в области качества запланированным мероприятиям и определения эффективности системы качества.

Проверки должны планироваться на основе оценки состояния и важности различных видов деятельности.Проверки и последующие мероприятия должны проводиться в соответствии с документированными методиками.

Результаты проверок должны оформляться документально и доводиться до сведения персонала, ответственного за проверяемый участок работы.

Корректирующие действия

Поставщик должен разработать, документально оформить и поддерживать в рабочем состоянии процедуры, обеспечивающие:

a) Выявление причин несоответствий продукции и корректирующие воздействия, предупреждающие повторение дефектов.

b) Анализ всех процессов, рабочих операций, отклонений, протоколов качества, отчетов об использовании продукции и рекламаций потребителя с целью выявления и устранения возможных причин несоответствия продукции требованиям.

c) Проведение предупреждающих действий для решения проблем на том уровне, который соответствует реальному риску.

d) Проведение тестирования и контроля с тем, чтобы убедиться в том, что корректирующие действия действительно реализуются и носят эффективный характер.

e) Применение и регистрацию изменений в процедурах, вызванных корректирующими действиями.

Контроль качества, надежности и безопасности создаваемых и модифицируемых программ должен сопровождать весь жизненный цикл ПО. Это достигается путем применения специальной, достаточно эффективной технологической системы тестирования программ и обеспечения их качества.

 

Вопросы

1) Основы тестирования (понятия, ключевые вопросы).

2) Уровни тестирования (объекты, цели тестирования).

3) Какие существуют техники тестирования?

4) Измерение результатов тестирования.

5) Управление процессом тестирования.

 

Дополнительная информация

1) http://www.protesting.ru/testing/

 

Лекция №10. Стандарты, регламентирующие разработку ПО

План лекции

- Качество программной системы как совокупность ее свойств, которые обуславливают пригодность удовлетворять заданные или подразумеваемые потребности в соответствии с назначением системы.

- Критерии оценки качества программных систем, характеристики качества и показатели качества. Общие характеристики качества программных систем: функциональность, надежность, удобство использования, эффективность, сопровождаемость, мобильность.

- Оценка качества программных систем. ГОСТ 28195. Методика оценки качества ПС. Факторы качества, критерии качества, метрики и оценочные элементы. Методы оценки: расчетный, экспертный. Общая оценка качества ПС. Взаимосвязь факторов, критериев и метрик с фазами жизненного цикла ПС. Выбор оценочных элементов для программных систем различного назначения.

- Методы управления качеством, используемые в современных технологиях программирования. Аттестация программных систем. Инструментальные системы оценки качества программных систем. Серии стандартов ГОСТ 19.ХХХ и ГОСТ 34.ХХХ. Стандарт ISO 12207. Стандарт SPICE (ISO/IEC 15504)

 

Введение

Полно и подробно ЖЦ, технология разработки и обеспечения качества сложных программных средств отражены в двух представленных ниже международных стандартах ISO.

 

Стандарт ISO 12207:1995

Стандарт ISO 12207:1995 - Процессы жизненного цикла программных средств - определяет архитектуру, процессы, разделы и подразделы ЖЦ ПО, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПО в стандарте базируется на трех крупных компонентах:

1) основы жизненного цикла ПО и определяющие работы;

2) процессы и работы, поддерживающие жизненный цикл ПО;

3) организация и управление жизненным циклом ПО.

Стандарт состоит из семи разделов и четырех приложений. Разделы 1-4 являются вводными. В первом разделе сформулированы цели стандарта, области его применения, подчеркнуты его гибкость и ограничения при использовании. В разделе 2 приведены нормативные ссылки на некоторые общие стандарты, поддерживающие разработку и качество ПО и их компонент, а также терминологию. В 3-м разделе аннотированы основные термины, используемые в дальнейшем. Общая структура основных (5-7) разделов и их краткое содержание изложено в разделе 4. Последующие - 5,6,7 разделы стандарта состоят из ряда подразделов, в которых подробно раскрывается содержание каждой работы и комментируются особенности их выполнения. Такие комментарии каждого подраздела состоят в среднем из 3-6 процессов - работ. Общее число работ и комментариев к ним в стандарте свыше 220.

Основные работы по подготовке, разработке эксплуатации и сопровождению программных средств изложены в разделе 5. Процесс приобретения или подготовки к созданию ПО (5.1) отражается 23 работами и начинается с инициализации проекта, анализа концепции, анализа рынка продуктов, выработки требований и состава поддерживающих документов, создания предварительного плана действий. Далее анализируются предложения возможных исполнителей на разработку и подготавливается проект контракта. Организуется отслеживание разработки, ее приемки и завершения. В подразделе 5.2. детализируются 23 процесса организации последующей подготовки к поставке ПО. Оцениваются отклики фирм на предложение по созданию проекта, заключается контракт, планируется жизненный цикл, организуются поддержка разработки отчетами и обеспечение развития, а также процессы сдачи и завершения проекта.

Основные 55 работ по созданию сложного комплекса программ представлены в подразделе 5.3. Подготовка проекта начинается с создания состава сопровождающих документов, выбора средств конфигурационного управления и обеспечения качества, а также выбора методов и средств технологического обеспечения разработки всей информационной системы. Анализируются и формализуются системные требования и критерии качества ПО: функциональные, коммерческие, пользовательские, защищенности, интерфейсов с внешней средой, сопровождаемости и т.д. На этой базе проектируется архитектура всей ИС, выделяются и анализируются требования к программным средствам. Рекомендуется при формировании характеристик качества ПО руководствоваться стандартом ISO 9126 и предложенной в нем номенклатурой показателей. Все эти работы отражаются совокупностью документов на каждую компоненту проекта, их взаимодействие и связи с внешней средой в ИС. Кодирование и тестирование каждой компоненты ПО должно быть оформлено совокупностью документов, удостоверяющих соответствие первичной спецификации, содержащих тесты и результаты тестирования.

Для интеграции компонент рекомендуется разрабатывать план работ, включающий их комплексирование, тестирование по всем разделам требований и показателям качества, а также документирование плана, результатов интеграции, использованных тестов, критериев оценки и полученных результатов. Далее ПО рекомендуется подвергать квалификационному (аттестационному) тестированию по всем разделам требований, при широком варьировании тестов, изменениях значений критериев, а также тестировать адекватность и полноту технической и пользовательской документации. Проверенный таким образом комплекс программ интегрируется в вычислительные средства информационной системы, средства визуализации и телекоммуникации. После объединения всех средств ИС система подвергается квалификационному тестированию и испытаниям на всю совокупность требований к системе, а также производится оформление и проверка полного комплекта документации. При этом рекомендуется использовать методы и средства поддержки жизненного цикла ПО, изложенные в разделе 6. Далее разработчику рекомендуется создать план инсталляции программного продукта в соответствии с контрактом и производить инсталляции, результаты которых документируются. Должна быть обеспечена поддержка разработчиком ПО.

Подраздел 5.4. из 9 работ посвящен поддержке эксплуатации. Подготовленный оператор должен освоить все процедуры применения ИС и в том числе тестирования ПО при функционировании на соответствие критериям оперативного использования в соответствии с документацией. Работы по поддержке пользователей состоят в помощи и консультации их при обнаружении дефектов или ошибок при применении ПО в составе информационной системы.

Эти работы взаимодействуют с работами подраздела 5.5, обеспечивающими сопровождение ПО (24 работы). Предполагается, что работы по сопровождению могут выполняться специалистами, которые не вели разработку ПО на предыдущих этапах. Специалисты анализируют сообщения об ошибках и предложения на модификацию ПО, селектируют их на соответствие требованиям контракта и оценивают целесообразность проведения изменений. Подготовленные изменения тестируются и проверяются по критериям, определенным в документации. При подтверждении корректности изменения в программах, производится корректировка документации. Далее планируется распространение проведенных изменений или новой версии пользователям, которым была поставлена предшествующая версия. Рекомендуется учитывать возможность одновременного использования у пользователей версий ПО с разным составом проведенных модификаций. Некоторые версии с определенной совокупностью изменений планируются для ликвидации и прекращения сопровождения.

В разделе 6 представлены около 70 технологических работ, поддерживающих жизненный цикл ПО. Процессы документирования ПО (6.1) охватывают планирование и обеспечение документирования, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комплекта документации на ПО. Конфигурационное управление (6.2) включает план, как часть общего плана управления проектом, рекомендации по конфигурационной идентификации, контролю, учету, отчетности и развитию конфигурации.

Обеспечение гарантий качества (6.3) включает использование планирования, методологии, процедур и стандартов обеспечения качества в соответствии с контрактом с учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией, путем планирования и выполнения специальных работ в процессе всего жизненного цикла ПО, а также на основе положений стандарта ISO 9001. Верификация ПО (6.4) включает организацию, планирование и техническое обеспечение верификации. Представлена структура контракта на верификацию, содержание процесса, состав требований, проектирование процесса верификации, обобщение и документирование результатов. Валидация (6.5) - удостоверение правильности (аттестация) должно гарантировать полное соответствие спецификациям, требованиям и документации наПО и возможность его безопасного и надежного применения пользователем. Рекомендуется ее выполнять путем тестирования во всех возможных ситуациях исходных данных и проводить независимыми специалистами. По существу, этот процесс аналогичен сертификации, которая в стандарте не упоминается.

Управление проектом (6.6) сосредоточено, в основном, в подготовке и обеспечении планирования и управления ресурсами, персоналом, аппаратурой, программными средствами и инструментарием. Общий контроль проекта должен учитывать состояние доступных ресурсов и возможность изменения плана проектирования, а также систематические технические отчеты. Процессы ревизии - аудит (6.7) служат для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Ревизоры не должны иметь прямой зависимости от проектировщиков ПО, они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования. В процессе устранения дефектов и ошибок (6.8) решаются проблемы обеспечения последующего применения программных средств и их функционирования. Каждый дефект или ошибка должны быть определены, идентифицированы, описаны, проанализированы, и разрешены в процессе сопровождения в соответствии с контрактом.

Раздел 7 посвящен процессам организации жизненного цикла ПО, которые отражены 25-ю работами. Процессы управления (7.1) включают основные работы по управлению проектом, производством и средствами для обеспечения прикладных процессов по разработке, эксплуатации, сопровождению и поддерживающим процессам. Они охватывают разработку концепции управления, планирования, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение.

Процессы образования инфраструктуры (7.2) включают выбор и установление аппаратных и программных средств, технологии, стандартов и обслуживания, используемых для разработки, сопровождения и обеспечения эксплуатации ПО. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к разработке и подлежит конфигурационному управлению. Процессы совершенствования жизненного цикла ПО (7.3) состоят в установлении, оценивании, измерении, контроле и корректировке процессов жизненного цикла. Совершенствование ЖЦ ПО должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходимые ресурсы, управление и технические средства. Должны быть разработаны и представлены пользователю материалы, облегчающие обучение по соответствующему плану.

В приложении А (нормативное) изложены основы преобразования и обобщения базовой структуры этого международного стандарта для конкретного проекта. Следует подчеркнуть необходимость реализации двух важнейших вариантов адаптации положений и рекомендаций стандарта: на особенности ЖЦ создания потенциально мобильных ПО и на особенности ЖЦ ПО с использованием мобильных компонентов.

Приложение В (информационное) содержит руководство по процессам адаптации и преобразования ЖЦ ПО для конкретного проекта, а также конкретные рекомендации по возможным изменениям ряда работ из разделов 5 и 6 стандарта в зависимости от характеристик объекта разработки.

 

ISO 15504 SPICE

ISO/IEC TR 15504 SPICE создан с целью обеспечить руководство компаний- разработчиков программного обеспечения концептуальной основой и механизмом для оценки корпоративных бизнес- процессов. Подобный механизм может использоваться организациями, так или иначе вовлеченными в планирование, управление, мониторинг, контроль и улучшение процессов приобретения, поставки, разработки, использования, оценки и поддержки программного обеспечения (SW- процессы) [35].

Рисунок 27 – Структура процессов ISO/IEC TR 15504 SPICE

 

ISO/IEC TR 15504 SPICE предлагает структурированный подход к оценке или аттестации (assessment) SW- процессов:

· самим предприятием или по его поручению, для определения текущего состояния внутренних процессов с целью их последующего улучшения;

· самим предприятием или по его поручению, для определения соответствия внутренних процессов некоторым критериям;

· самим предприятием или по его поручению, для определения соответствия другой организации требованиям конкретного контракта или типа разработки.

Рисунок 28 – Состав и соотношение процессов SPICE

 

Предлагаемая ISO/IEC TR 15504 SPICE основа:

· поощряет и во многом ориентирована на внутренние проверки;

· направлена на определение соответствия уровня управления оцениваемого процесса;

· учитывает контекст, в котором проистекает исследуемый процесс;

· предлагает систему рейтингов (a processprofile) вамен стандартной для ИСО 9000 системы выполнено/не выполнено;

· одинаково применим для предприятий любого размера и области деятельности.

Использование предлагаемой в ISO/IEC TR 15504 SPICE модели аттестации процессов приводит к:

· переходу к непрерывному улучшению процессов и внедрению корректных механизмов для поддержки подобных программ;

· проектированию процессов в соответствии с реальными бизнес- требованиями;

· оптимизации использования ресурсов.

В свою очередь, организации, приобретающие ПО, получают ряд преимуществ:

· снижение рисков при выборе поставщиков ПО, связанных с возможностью определения потенциала подрядчиков до момента оплаты работ;

· организацию на месте соответствующего управления для снижения возможных последствий рисков;

· создание численных методик для выбора и классификации потребностей бизнеса, требований и предварительных оценок стоимости ИТ- проектов в соответствии с определенными возможностями подрядчиков.