Стандарт ИСО-МЭК 90003 - 2004. Техника программного обеспечения, страница 2

Совместный анализ сучастием организации и потребителей может проводиться на регулярной основеили на важных этапах проектирования и охватывать информацию о продукции ивопросы прохождение запросов, контрактов и изменений.Организации следует добиться того, чтобы программные продуктыразрабатывались в соответствии с установленными требованиями, а также всоответствии с планированием проектирования и разработки или планированиемкачества. Это позволяет уменьшить зависимость от верификации или валидации,как единственных методов идентификации проблем.При планировании проектирования и разработки рекомендуется рассмотретьследующие вопросы:a)анализтребований,проектированиеиразработка,кодирование,интеграция, проведение испытаний, установка и поддержка при приемкепрограммных продуктов;b) планирование управления продукцией и предоставлением услуг;10c) организацию проектных ресурсов, включая структуру коллектива,ответственность, использование поставщиков и используемые материальныересурсы;d) организационное и техническое взаимодействие разных людей или групп,например,коллективов,занимающихсяподпроектом,поставщиков,партнеров, представителей потребителей, представителей, занимающихсяподдержкой качества;e) анализ возможных рисков, предположений, зависимостей и проблем,связанных с проектированием и разработкой;f)план, включающий стадии проектирования, декомпозицию элементовработ, ресурсы, этапы работ и другие аспекты;g) идентификацию стандартов и норм, оборудования и программноаппаратных средств, практических действий по управлению конфигурацией идругих средств и методов;h) идентификацию планируемой системы и уровня качества, менеджментрисков, управление конфигурацией,интеграцию, испытания и другиеаспекты и действия;i) управление документацией, в том числе архивами документов/записей ираспределением.Входные данные для проектирования и разработки могут быть определеныиз функциональных и эксплуатационных требований, требований к качеству и кобеспечению безопасности и защите информации, а также из ограничений напроектирование системы или установлены из технологий, например, путемсоздания прототипов.

Входные данные для проектирования и разработки такжемогут быть определены из запросов об изменениях, внесенных в итерационнуюмодель разработки (цикл) при проектировании на более ранних этапах,установленных проблем или требований, касающихся критериев приемки. Входныеданные также могут определяться на основе анализа контракта.При анализе документов, содержащих входные данные для проектирования и11разработки, их следует проверить в отношенииa) двусмысленности и противоречий,b)несоответствующих,неполныхилималовероятныхданныхилитребований,c) нереальных эксплуатационных спецификаций,d) требований, которые не могут быть проверены или обоснованы,e) неустановленных или искусственных требований,f) неточного описания среды и действий пользователя,g) отсутствия решений по проектированию и разработке в документе стребованиями, иh) отсутствия основных критериев качества.Выходные данные проектирования и разработки могут выражаться в видетекста, диаграмм или с использованием нотации символьного моделирования имогут включатьa) технические условия на проектирование, разработку и проведениеиспытаний,b) модели данных,c) символический код или исходный код,d)руководствапользователя,документациюоператора,обучающийматериал, документацию по сопровождению,e) разработанный продукт, иf) формальные методы.При проведении анализа проекта и разработки рекомендуется учитыватьтакие критерии, как осуществимость проекта, защита, обеспечение безопасности,правила программирования и возможности его оценки.Дальнейшие действия по проектированию и разработке должны проводитьсятолько тогда, когда установлены последствия всех известных недостатков или все12риски известны и обсуждены.В.

Верификация, валидация и испытанияЦель верификации программного обеспечения состоит в том, чтобыобеспечить соответствиевыходныхданных проектированияи разработкитребованиям, предъявляемым к входным данным.Верификация должна проводиться, если это целесообразно, в процессепроектирования и разработки.

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

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

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

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

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

Если программное обеспечение,разработанное по субподряду, должно быть интегрировано с программнымобеспечением, разработанным самой организацией, могут использоваться другиеметоды и инструментальные средства, используемые при разработке. Можетпотребоватьсяпроверка,осуществляемаясамойорганизацией,атакжепотребителем.У организации может возникнуть необходимость приобрести и использоватьпрограммные продукты, включая данные или услуги, например, данные посотрудникам,выполняющимконтракт,назначаемымтретьейстороной.Организация должна верифицировать продукт и услуги по их получении с учетомтребований контракта. Методы верификации продукта могут быть определены какчастьтребованийкзакупкам(например,приемочныеиспытания).Функциональные требования и требования к характеристикам продукта должныпроверятьсяпередегоиспользованием,чтобыпродуктнормальнофункционировал.