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

Стандарт ИСО/МЭК 90003:2004. Техника программногообеспечения. Рекомендации по применению ИСО 9001:2000 ккомпьютерному программному обеспечениюНастоящий международный стандарт содержит руководящие указания дляорганизацийпокасающиесяприобретения,сопровожденияопределяетприменениюмеждународногопоставки,компьютерногонезависящиеотразработки,программноготехнологиистандарта9001:2000,функционированияобеспечения.проблемы,ИСОЭтоткоторыеистандартнеобходиморассматривать, а также модели жизненного цикла, процессы разработки,последовательности действий и организационную структура, которые могут бытьиспользованы организацией.МеждународныйстандартИСО/МЭК90003:2004применяетсякпрограммному обеспечению, которое− является частью торгового контракта с другой организацией;− является продукцией, доступной на рынке;− используется для сопровождения процессов организации;− встроено в аппаратное оборудование или− связано с услугами по программному обеспечению.Организации, использующие системы менеджмента качества для разработки,функционирования или сопровождения программного обеспечения, основанные нанастоящем международном стандарте, могут выбрать процессы, установленные вмеждународных стандартах ИСО /МЭК 12207 и ИСО/МЭК 12207:1995/Amd.1:2002, для поддержки или дополнения модели процессов международногостандарта ИСО 9001:2000.

Международный стандарт ИСО/МЭК 12207:1995содержит подробные положения для семнадцати процессов жизненного циклапрограммного обеспечения. Международный стандарт ИСО/МЭК 12207:1995/Amd.1:2002 включает положения высокого уровня для многих дополнительныхпроцессов. Этот международный стандарт содержит ссылки на термины,установленные в обоих стандартах.Дальнейшие руководящие указания поприменению международного стандарта ИСО /МЭК 12207 можно найти вмеждународном стандарте ИСО/МЭК ТО 15271.

Что касается дополнительныхруководящих указаний, то часто ссылки даются на международные стандартыИСО /МЭК 9126-1, ИСО/МЭК ТО 9126 (части 2-4), ИСО/МЭК 15939 и ИСО/МЭК15504 (все части).Информацию по различным аспектам процессов программного обеспеченияможно найти в международном стандарте ИСО/МЭК 15504-1. Международныйстандарт ИСО/МЭК 15504 (все его части) может использоваться для оцениваниявозможностей процессов и для определения целей по расширению возможностейпроцессов.

В области менеджмента ресурсов и проектов может быть полезнойдополнительная информация, представленная вмеждународных стандартахИСО/МЭК 14598-2 и 14598-3, ИСО/МЭК 14102, ИСО/МЭК 9126-1, ИСО/МЭК ТО15846:1998, ИСО/МЭК ТО 16326:1999. При оценке жизненного цикла продукциимогут быть полезными стандарты ИСО/МЭК 15026:1998 и ИСО/МЭК 12119:1994,а в областисопровождения программного обеспечениястандарт ИСО/МЭК14764:1999.Также целесообразно использовать международный стандарт ИСО/МЭК12119:1994, являющийся руководством по программному обеспечению контрольно– измерительной установки (COTS), ИСО|МЭК 6592:2000, представляющийруководство по документации проектирования и разработки, стандарты ИСО/МЭК19761, ИСО/МЭК 20926[и ИСО/МЭК 20968, дающие руководящие указания пооценке методов измерения функционального размера, стандарт ИСО|МЭК ТО14759, дающий руководящие указания по категоризации прототипов и примеры ихиспользования,истандартИСО/МЭК15910попроцессудокументациипрограммного обеспечения пользователей.2Процессы, действия и задачи следует планировать и выполнять сиспользованием моделей жизненного цикла с учетом объема, сложности,безопасности, рисков и целостности предпринимаемых действий и выполняемыхработ.Ниже рассматриваются наиболее значимые с точки зрения автораположения стандартаИСО/МЭК 90003:2004 в отношении основных фазпроцессного подхода стандарта ИСО 9001:2000, касающиесяответственностируководства, менеджмента ресурсов, процессы жизненного цикла, измерения,анализа и улучшения.Ответственность руководстваПланирование может осуществляться на организационном уровне и науровнях проектирования/выпуска продукции.Планирование системы менеджмента качества на организационном уровнеможет включать следующие позиции:a) определение подходящих моделей жизненного цикла программногообеспечения;b) определение рабочих продуктов разработок программного обеспечения;c)определениесодержанияплановпоуправлениюпрограммнымобеспечениемd) определение того, как технические методы программного обеспеченияадаптируются к проектам организации в рамках жизненного цикла;e) идентификация инструментов и среды для разработки программногообеспечения, функционирования или сопровождения;f) соглашения по использованию языков программирования, по правиламкодирования, библиотекам программных средств и оболочкам;g) идентификация многократного использования программного обеспечения.3Для организаций, занимающихся разработкой программного обеспечения,желательно, чтобы представитель руководства имел опыт работы в областиразработки программного обеспечения.Одним из способов измерения функционирования процесса являетсяоценивание процесса создания программного обеспечения.

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

ИнфраструктураК инфраструктуре следует отнести аппаратные средства, программныесредства, инструментальные средства и средства труда, необходимые для4разработки, функционирования или обслуживания программного обеспечения.Инфраструктура может включать инструментальные программные средства,поддерживающие процесс проектирования и разработки, в том числе:a) инструментальные средства, например, для анализа, проектирования иразработки, управления конфигурацией, проведения испытаний, управленияпроектами, документации, создания и генерации кодов;b) среды разработки и поддержки приложений;c) инструментальные средства внутренних и внешних сетей для управлениязнаниями;d) сетевые инструментальные средства, включая средства обеспечениябезопасности, резервирования, защиты от вирусов, брандмауэр;e) "справочный" стол и инструментальные средства сопровождения;f) средства управления доступом;g) библиотеки программного обеспечения;h) инструментальные средства для управления операциями, включая сетевоймониторинг, управление системами и памятью.Процессы жизненного цикла продукцииПроектирование и разработка могут являться эволюционным процессом ипоэтому процедуры могут нуждаться в корректировке или актуализации по мерепродвиженияпроектапослерассмотренияизменений,вносимыхвсоответствующие действия и задачи.А.

Планирование качества и проектированиеПланирование качества дает возможность адаптации применения системыменеджмента качества к конкретному проекту, продукту или контракту.Планирование качества может включать или ссылаться на общие процедуры и/илипроцедуры, распространяемые на конкретный проект/продукт/контракт, если это5целесообразно.Планированиекачестваследуетпересматриватьпомереусовершенствования проектирования; разработки и вопросы, рассматриваемые накаждом этапе, следует полностью определить перед тем, как приступить квыполнению этого этапа. Планирование качества может быть пересмотрено исогласовано со всеми организациями, заинтересованными в этом, если этоцелесообразно.При планировании качества программного обеспечения на уровне проектарекомендуется рассмотривать следующие вопросы:a) включение планов разработки или ссылку ни них;b) требования к качеству, связанные с планами и/или процессами;c) адаптирование системы менеджмента качества и/или идентификацияспецифических процедур и инструкций;d) процедуры и инструкции для конкретного проекта;e) методы, модель (модели) жизненного цикла, инструментальные средства,соглашения по языку программирования, оболочки и другие средства,многократно используемые в проекте;f) критерии, определяющие начало и завершение каждого этапа проекта;g) типы анализа и другие выполняемые действия по верификации ивалидации;h) выполняемые процедуры управления конфигурацией;i) выполняемые действия по мониторингу и измерению;j) лицо (лица), ответственные за утверждение выходных данных процессовдля их последующего использования;k) обучение, необходимое для использования инструментальных средств итехнологии, а также составление расписания обучения для приобретениятребуемых навыков;l) сохраняемые записи;m) управление внесением изменений, например, касающееся ресурсов,6временных рамок и контракта.Программное обеспечение может разрабатываться как часть контракта, какпродукт, доступный в рыночном секторе, как программное обеспечение,встроенное в систему, или для бизнес – процессов организации.

Для всех этихслучаев должны быть определены соответствующие требования и действия.Конкретные действия могут включать:а) разработку методов определения рассматриваемых требований, к которымотносятся1) методы согласования требований и санкционирования и прослеживаниявносимых изменений, особенно в случае итерационных разработок;2)методыоцениванияпрототиповилидемонстраций,еслионииспользуются;3) методы записи и анализа дискуссионных результатов с участием всехзаинтересованных сторон;b) разработку требований в тесном сотрудничестве с потребителями илипользователями и усилия по предотвращению неверного толкования,например, положений определения терминов, обоснование этих требований;с) получение одобрения требований потребителем;d) разработку метода прослеживаемости выполнения требований вплоть доконечногопродукта(например,матрицыслежениязавыполнениемтехнических требований).Требования могут устанавливаться потребителем, могут разрабатыватьсяорганизацией или разрабатываться совместно.

Может возникнуть необходимостьучета требований операционной среды. Требования могут включать следующиехарактеристики (но не ограничиваться ими): функциональность, надежность,практичность, эффективность, удобство сопровождения и портативность. Могуттакже устанавливаться другие характеристики, например, защита, безопасность иустановленныезакономобязательства.Некоторыеизперечисленных7характеристик могут иметь целевое назначение и/или являться критическими сточки зрения безопасности.Еслипрограммныйпрограммнымиилипродуктнуждаетсясистемнымивсогласованиипродуктами,сдругимиинтерфейсымеждуразрабатываемыми программными продуктами и другие программные илисистемные продукты следует по мере возможности определить в требованиях либонепосредственно, либо путем ссылки.Требования следует формулировать четко и однозначно, что позволяетоблегчитьвалидациюприприемкепродукта.Выполнениетребованийрекомендуется отслеживать в течение жизненного цикла разработки.Проблемы, которые могут оказаться значимыми при анализе организациейтендеров, контрактов или заказов по программному обеспечению, включаютследующие позиции (но не ограничиваются ими):a) выполнимость и валидация требований и характеристик продукции,включаяидентификациюобеспечения(например,требуемыхтакихкакхарактеристикфункциональность,программногонадежность,практичность, удобство сопровождения, портативность и эффективность);b) используемые стандарты и процедуры по проектированию и разработкепрограммного обеспечения;c) идентификация аппаратуры, инструментальных средств, элементовпрограммного обеспечения и данных, предоставляемых потребителем;определение и документальное оформление методов оценки их пригодности;d) операционная система или базовые аппаратные средства;e) соглашение по управлению интерфейсами внешних устройств спрограммным продуктом;f) требованию к копирования и распределению;g) проблемы, относящиеся к потребителю:1) процессы жизненного цикла, установленные потребителем;82) сроки выполнения обязательств организации по поставке копий ипроизводительность считывания оригиналов;h) проблемы менеджмента:1) рекомендуется рассмотреть проблему менеджмента рисков;2) ответственность организации за субподрядные работы;3) планирование проведения работ, технического анализа и выпускапродукции;4) требования к установке, сопровождению и поддержке;5) своевременная доступность технических, человеческих и финансовыхресурсов;i) юридические вопросы, а также вопросы, связанные с обеспечениембезопасности и конфиденциальностью:1) информация, рассматриваемая по контракту, может затрагиватьинтересы,связанныелицензионнымисправамисоглашениями,интеллектуальнойобязательнымиисобственности,законодательнымитребования, конфиденциальностью и защитой информации, включаяпатенты и авторские права;2) защита оригинала продукта и прав потребителя на доступ или проверкуоригинала;3) уровень предоставления информации потребителю, необходимостьвзаимного согласия сторон;4) установление гарантий;5) обязанности/штрафные санкции, связанные с выполнением контракта.При анализе требований к продукции могут быть рассмотрены вопросы,связанные со следующими рисками:a) вопросы критичности, обеспечения безопасности и защиты;b) возможности и опыт организации или её поставщиков;c) надежность оценок ресурсов и время, необходимое для осуществлениякаждого процесса;9d) важные различия между временем, необходимым для поставки продукцииили услуг, и временем, установленным в соответствующих планах путемоптимизации затрат и целей в области качества;e)важныевопросы,связанныесместонахождениеморганизации,потребителей, пользователей и поставщиков;f)высокотехнологическиенововведения,включаяновейшиеметоды,инструментальные средства, технологии и поставляемое программноеобеспечение;g)низкоекачествоилидоступностьпоставляемогопрограммногообеспечения и инструментов;h)точность,соответствиеистабильностьопределениятребованийпотребителя и внешних интерфейсов.Анализ требований может проводиться внутренними или внешнимиорганизациями и может включать рассмотрение требований, относящихся кконтракту, проектированию, сопровождению или качеству.