Тема 6. Проектирование и обеспечение качества программных средств по стандарту iso 12207

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

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

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

• - организация и управление жизненным циклом ПС.

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

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

6.1. Процессы жизненного цикла

5.3. Процесс разработки

5.3.1. Реализация процесса.

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

цикла.

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

5.3.1.2. Разработчик должен:

а) документировать выходные данные согласно Процессу Документирования (6.1);

б) разместить выходные данные в Процессе Управления Конфигурацией (6.2) и выполнять контроль изменений согласно этому пункту;

в) документировать и решать проблемы (выявлять дефекты) и несоответствия, найденные в программных продуктах и задачах согласно Процессу Разрешения Проблем (6.8);

г) выполнить вспомогательные процессы (п.6), как определено в контракте.

5.3.1.3. Разработчик должен выбрать, настроить и использовать стандарты, методы, инструментарии, языки программирования (если конкретно не оговорено в контракте), которые задокументированы, соответствуют требованиям и установлены организацией для выполнения действий Процесса Разработки и вспомогательных процессов (п.6).

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

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

5.3.2. Анализ требований.

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

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

5.3.2.2. Требования системы должны быть определены при рассмотрении критериев перечисленных ниже. Результаты оценок должны быть документированы:

а) трассируемость к потребностям приобретения;

б) согласованность с нуждами приобретения;

в) контролируемость;

г) выполнимость архитектуры системы;

д) возможности функционирования и сопровождения.

5.3.3. Проектирование архитектуры системы.

Эти действия состоят из решения следующих задач, которые разработчик должен выполнить или поддержать, как требуется контрактом:

5.3.3.1. Должна быть установлена архитектура верхнего уровня системы. Архитектура должна идентифицировать компоненты аппаратных средств, программного обеспечения и ручного управления. Должно быть гарантировано, что все требования системы распределены среди компонент. Компоненты конфигурации аппаратных средств и программного обеспечения и ручные действия должны быть впоследствии идентифицированы от этих компонент (изделий). Архитектура системы и требования системы, распределенные по компонентам должны быть документированы.

5.3.3.2. Архитектура системы и требования для компонент должны быть оценены, рассматривая критерии, опубликованные ниже. Результаты оценок должны быть документированы:

а) трассируемость к требованиям системы;

б) согласованность с требованиями системы;

в) соответствие стандартам проектирования и используемым методам;

г) реализуемость компонент программного обеспечения, выполняющих распределенные требования;

д) возможность функционирования и сопровождения.

5.3.5. Анализ требований программного обеспечения.

Для каждой компоненты программного обеспечения (или компоненты конфигурации программного обеспечения, если определено) эта деятельность состоит из следующих задач:

5.3.5.1. Разработчик должен установить и документировать требования программного обеспечения, включая спецификации характеристик качества, описанные ниже. Руководство по определению характеристик качества можно найти в ISO/IEC 9126.

а) функциональные и возможные спецификации, включая функционирование, физические характеристики и условия среды эксплуатации при которых компонента программного обеспечения должна быть реализована;

б) внешние связи (интерфейсы) с компонентой программного обеспечения;

в) требования квалификации;

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

д) спецификации защищенности, включая спецификации связанные с искажениями точности информации;

е) человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и к обучению;

ж) определение данных и требований базы данных;

з) установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);

и) документация пользователя;

к) работа пользователя и требования при применении;

л) требования сервиса пользователя.

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

а) трассируемость к требованиям системы и проектированию системы;

б) внешняя согласованность с требованиями системы;

в) внутренняя согласованность;

г)контролируемость;

д) выполнимость проекта программного обеспечения;

е) возможность функционирования и сопровождения.

5.3.5.3. Разработчик должен проводить совместные оценки согласно п.6.6. После успешного завершения оценок должна быть определена базовая концепция на требования единицы программного обеспечения.

5.3.5. Архитектура программного обеспечения.

Для каждой компоненты программного обеспечения (или компоненты конфигурации программного обеспечения, если она идентифицирована) эта деятельность состоит из следующих задач:

5.3.5.1. Разработчик должен трансформировать требования для компоненты программного обеспечения в архитектуру, которая описывает ее верхне - уровневую структуру и идентифицирует компоненты программного обеспечения. Должно быть гарантировано, что все требования для комплекса программного обеспечения распределены по их компонентам программного обеспечения и далее совершенствуются, чтобы облегчить детальное проектирование. Архитектура компоненты программного обеспечения должна быть документирована.

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

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

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

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

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

а) трассируемость к требованиям компонент программного обеспечения;

б) внешняя согласованность с требованиями компонент программного обеспечения;

в) внутренняя согласованность между компонентами программного обеспечения;

г) соответствие методов проектирования и используемых стандартов;

д) возможность детального проектирования;

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

В стандарте ISO 12207 в п.5.3.6 регламентируется детальное проектирование и далее в разделах 5.3 - 5.5 остальные процессы жизненного цикла ПС. В отдельный раздел стандарта 6.3 выделены требования по обеспечению гарантий качества. Эти требования представлены ниже и излагаются с рядом ссылок на другие разделы стандарта.