Учебное пособие санктПетербург 2015
 Скачать 3.34 Mb.
|
|
ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств Настоящий стандарт устанавливает, используя чет- ко определенную терминологию, общую структуру про- цессов жизненного цикла программных средств, на кото- рую можно ориентироваться в программной индустрии. Стандарт определяет процессы, работы и задачи, кото- рые используются: при приобретении системы, содержа- щей программные средства, или отдельно поставляемо- го программного продукта; при оказании программной услуги, а также при поставке, разработке, эксплуатации и сопровождении программных продуктов. Понятие программных средств также охватывает программный компонент программно-аппаратных средств. Настоящий стандарт также определяет процесс, который может быть использован при определении, контроле и модернизации процессов жизненного цик- ла программных средств. Стандарт не распространяется на готовые про- граммные продукты, если они не входят в поставляе- мый продукт. Стандарт предназначен для: - заказчиков систем, программных продуктов и услуг; - поставщиков; разработчиков; операторов; пер- сонала сопровождения; администраторов проектов; 213 Стандартизация и сертификация программного обеспечения - администраторов, отвечающих за качество, и пользователей программных продуктов. Стандарт определяет набор процессов, работ и задач, предназначенных для адаптации к условиям конкретных программных проектов. Процесс адапта- ции заключается в исключении неприменяемых в ус- ловиях конкретного проекта процессов, работ и задач. Соответствие настоящему стандарту определяется как выполнение всех процессов, работ и задач, выбранных из настоящего стандарта в процессе адаптации (при- ложение А), для конкретного программного проекта. Выполнение процесса или работы считается завер- шенным, когда выполнены все требуемые для них за- дачи в соответствии с предварительно установленны- ми в договоре критериями и требованиями. Любая организация (например, национальная, про- мышленная ассоциация, компания), применяющая на- стоящий стандарт в качестве условия обеспечения тор- говых сделок, обязана определить и опубликовать мини- мальный набор требуемых процессов, работ и задач, ко- торый обеспечивает проверку соответствия поставщика настоящему стандарту. Стандарт описывает архитектуру процессов жизненного цикла программных средств, но не определяет детали реализации или выполнения работ и задач, входящих в данные процессы. Стандарт не предназначен для определения на- именований, форматов или подробного содержания выпускаемой документации. Стандарт может требо- вать разработки документов одного класса или тип а, например различных планов, но не предусматривает, чтобы такие документы разрабатывались или комп- лектовались раздельно или совместно. Решение этих вопросов оставлено на усмотрение пользователей на- стоящего стандарта. 214 Методы оценки и измерения характеристик информационных систем Стандарт не предопределяет конкретной модели жизненного цикла или метода разработки программно- го средства. Пользователи, применяющие настоящий стандарт, должны сами выбирать модель жизненного цикла применительно к своему программному проекту и распределять процессы, работы и задачи, выбранные из настоящего стандарта, на данной модели; выбирать и применять методы разработки программных средств и выполнять работы и задачи, соответствующие конк- ретному программному проекту. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению Стандарт определяет шесть характеристик, кото- рые с минимальным дублированием описывают качест- во программного обеспечения. Данные характеристики образуют основу для дальнейшего уточнения и описа- ния качества программного обеспечения. Руководства описывают использование характеристик качества для оценки качества программного обеспечения. Стандарт не определяет подхарактеристики (ком- плексные показатели) и показатели, а также методы измерения, ранжирования и оценки. Данный стандарт придерживается определения качества по ИСО 8402. Оценка (assessment) - действие по применению конкретного задокументированного критерия оценки к конкретному программному модулю, пакету или про- дукции с целью обусловленной приемки или выпуска программного модуля, пакета или продукции. Признаки (показатели) (features) - признаки, оп- ределяющие свойства программной продукции, кото- рые могут быть отнесены к характеристикам качества. 215 Стандартизация и сертификация программного обеспечения Примечание - Примеры признаков включают длину маршрута, модульность, структуру программы и комментарии. Программно-аппаратные средства (firmware) - технические средства, содержащие компьютерную программу и данные, которые не могут изменяться средствами пользователя. Компьютерная программа и данные, входящие в программно-аппаратные средс- тва, классифицируются как программное обеспечение; схемы, содержащие компьютерную программу и дан- ные, классифицируются как технические средства. Уровень качества функционирования (level of performance) - степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества. Измерение (measurement) - действие по приме- нению показателя качества программного обеспече- ния к конкретной программной продукции. Качество (quality) - весь объем признаков и ха- рактеристик продукции или услуги, который относит- ся к их способности удовлетворять установленным или предполагаемым потребностям (ИСО 8402). Программное обеспечение(software) - про- граммы, процедуры, правила и любая соответствую- щая документация, относящиеся к работе вычисли- тельной системы. Программная продукция (sofwarе product) - программный объект, предназначенный для поставки пользователю. Качество программного обеспечения (software quality) - весь объем признаков и характеристик про- граммной продукции, который относится к ее способ- ности удовлетворять установленным или предполага- емым потребностям. 216 Методы оценки и измерения характеристик информационных систем Критерии оценки качества программного обес- печения (software quality assessment criteria) - набор оп- ределенных и задокументированных правил и условий, которые используются для решения о приемлемости общего качества конкретной программной продукции. Качество представляется набором установленных уров- ней, связанных с программной продукцией. Характеристики качества программного обеспечения (software quality characteristics) - набор свойств (атрибутов) программной продукции, по ко- торым се качество описывается и оценивается. Харак- теристики качества программного обеспечения могут быть уточнены на множестве уровней комплексных показателей (подхарактеристик). Метрика качества программного обеспечения (software quality metric) - количественный масштаб и метод, которые могут быть использованы для опреде- ления значения признака, принятого для конкретной программной продукции. Качество программного обеспечения может быть оценено следующими характеристиками: 1. Функциональные возможности (Functionality) - набор атрибутов, относящихся к сути набора функ- ций и их конкретным свойствам. Функциями являются те, которые реализуют установленные или предпола- гаемые потребности. 2. Надежность (Reliability) - набор атрибутов, относящихся к способности программного обеспече- ния сохранять свой уровень качества функционирова- ния при установленных условиях за установленный период времени. Износ или старение программного обеспечения не происходит. Ограничения надежности проявляются из-за ошибок в требованиях, проекте и реализации. Отказы из-за этих ошибок зависят от спо- 217 Стандартизация и сертификация программного обеспечения соба использования программного обеспечения и ра- нее выбранных версий программ. 3. Практичность (Usability) - набор атрибутов, от- носящихся к объему работ, требуемых для использования и индивидуальной оценки такого использования опреде- ленным или предполагаемым кругом пользователей. 4. Эффективность (Efficiences) - набор атрибу- тов, относящихся к соотношению между уровнем ка- чества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях. 5. Сопровождаемость (Maintainability) - набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций). 6. Мобильность (Portability) - набор атрибутов, относящихся к способности программного обеспечения быть перенесенным из одного окружения в другое. ГОСТ Р ИСО/МЭК 15910-2002. Процесс создания документации пользователя программного средства Настоящий стандарт по существу является стан- дартом на процесс. Стандарт не определяет компонов- ку конкретного документа, его содержание и другие аспекты комплектности документации, однако он ус- танавливает метод планирования и проведения про- цесса документирования. Процесс документирования должен быть вы- полнен в два этапа в последовательности, представ- ленной на рисунке 43. Поэтапные работы не выпол- няются одновременно. На отдельных этапах работы могут проводиться параллельно. Возможные итера- ции работ показаны пунктирными линиями. Когда минимальный состав документации определяется 218 Методы оценки и измерения характеристик информационных систем заказчиком (например, с использованием ГОСТ Р ИСО 9127 или ИСО/МЭК 6592), это должно быть учтено документатором при разработке плана доку- ментирования. Рисунок 43 - Обзор процесса документирования 219 Стандартизация и сертификация программного обеспечения Заказчик должен обеспечивать документатору доступ: a) Ко всем соответствующим спецификациям, фор- матам записей, компоновкам экранов и отчетов, вы- ходным результатам работы средств автоматизации программирования (CASE tool) и другой информации, необходимой для подготовки документации. b) К рабочей копии программного средства (при необ- ходимости). c) К аналитикам и программистам, включая своевре- менное правильное решение вопросов, возникающих у персонала разработчиков документации. d) К типичным пользователям (по возможности) для анализа аудитории и тестирования на практичность. В обязанности документатора входит обеспе- чение плодотворности контактов с разработчиками программных средств заказчика, гарантирующее как минимум понимание сути выпускаемой продукции и соответствующих ей аудиторий. Документатор не от- вечает за разработку, проверку или корректировку ис- ходных материалов, а только за их получение. Независимо от того, является ли документатор одновременно разработчиком программного средства, заказчик должен обеспечить его копиями всех приме- няемых стандартов, руководствами по стилям и фор- матам, а также соответствующими материалами (если они не являются общедоступными). Документатор должен обеспечить данными материалами соответс- твующий персонал разработчиков документации. Обязанностью разработчика является обеспе- чение полноты, правильности и актуальности всех материалов, предъявляемых разработчику на момент их поставки. Разработчик должен гарантировать, что представление документатору данных материалов не 220 Методы оценки и измерения характеристик информационных систем нарушает прав интеллектуальной собственности лю- бой третьей стороны. Документатор должен предпринять соответс- твующие шаги по сохранению материалов, представ- ленных заказчиком, обеспечить защиту информации о требованиях заказчика и возвратить все материалы заказчику по завершении проекта документирования. В ряде случаев нет необходимости возвращать все материалы; данный вопрос должен быть оговорен в договоре. В ряде случаев требуется сохранить конфи- денциальность и секретность предоставленных мате- риалов. В договоре должны быть установлены уровни (грифы) конфиденциальности или секретности мате- риалов, представляемых заказчиком документатору. ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию Настоящий стандарт распространяется на про- цессы разработки и документирования программно- го обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все дейс- твия, имеющие отношение к разработке программно- го обеспечения. Настоящий стандарт применяют полностью ко всему поставляемому программному обеспечению, включая среду разработки, если контрактом не предус- мотрено использование специальных стандартов для определенных заказчиком типов ПО. Стандарт непри- меним для аппаратных элементов программно-аппарат- ного обеспечения. В рамках конкретного проекта созда- ния ПО должны быть установлены одна или несколько моделей жизненного цикла ПО, в соответствии с кото- 221 Стандартизация и сертификация программного обеспечения рыми выбирают необходимые работы для каждого про- цесса, определяют последовательность их выполнения, назначают ответственных за выполнение работ. Для конкретного проекта последовательность процессов определяется сложностью проекта, функ- циональными возможностями разрабатываемой систе- мы, объемом и сложностью ПО, стабильностью требо- ваний, использованием ранее полученных результатов, стратегией разработки и возможностями аппаратных средств. Обычная последовательность процессов раз- работки ПО - определение требований, проектирова- ние, кодирование и интеграция. Методы разработки ПО Разработчик должен использовать для всех ра- бот по созданию ПО систематизированные, зарегист- рированные методы. План разработки ПО должен со- держать описание этих методов или включать в себя ссылки на источники, в которых они описаны. Стандарты ПО Разработчик должен разработать и использовать стандарты для представления требований, проекта, кода, тестовых вариантов, тестовых процедур и ре- зультатов тестирования. План разработки ПО должен содержать описание этой информации или ссылки на источники, в которых они описаны. Программные средства многократного использования Разработчик должен рассмотреть и оценить возможность применения ранее разработанных про- граммных средств многократного использования для выполнения требований контракта. Область исследо- вания и критерии, используемые для оценки, должны быть описаны в Плане разработки ПО. Выбранные для применения программные средства должны отвечать требованиям контракта по правам собственности. 222 Методы оценки и измерения характеристик информационных систем Разработчик должен рассмотреть возможность многократного использования программных средств, разработанных по контракту, оценить и идентифициро- вать для заказчика выгоды и издержки такого использо- вания в случае его совместимости с задачами проекта. Информационный поток от системных процессов к процессам ПО В процессе оценки безопасности системы долж- ны быть определены возможные отказные ситуации для системы и установлены их категории, определе- ны требования, связанные с безопасностью, которые специфицируют желаемую отказоустойчивость и ре- акцию системы на отказные ситуации. Требования, связанные с безопасностью, - это часть системных требований, которые являются вход- ной информацией для процессов жизненного цикла ПО. Для гарантии правильной реализации требова- ний, связанных с безопасностью, системные требова- ния должны содержать (или ссылаются на): - описание системы и определение аппаратуры; - системные требования, относящиеся непос- редственно к ПО, включая функциональные требова- ния, требования по эффективности и требования, свя- занные с безопасностью; - уровень(ни) ПО и информацию, подтверждаю- щую их определение, отказные ситуации, их катего- рии и функции, выполняемые ПО; - стратегии обеспечения безопасности и ограни- чения проекта, включая методы проектирования, та- кие как использование разбиения, многоверсионного неидентичного ПО, избыточности или мониторинга безопасности. Процессы жизненного цикла системы могут так- же определять требования к процессам жизненного 223 Стандартизация и сертификация программного обеспечения цикла ПО, которые необходимы для поддержки вери- фикации системы. Информационный поток от процессов ПО к системным процессам Процесс оценки безопасности системы должен определить влияние проектирования и реализации ПО на безопасность системы в целом, используя инфор- мацию, создаваемую процессами жизненного цикла ПО. Эта информация включает в себя идентифика- цию областей распространения отказов, требования к ПО, архитектуру ПО и источники ошибок, которые могут быть обнаружены или исключены посредством специальной организации архитектуры ПО или пу- тем использования инструментальных средств, или другими методами, используемыми в процессе про- ектирования ПО. Для процесса оценки безопаснос- ти системы должна быть обеспечена трассируемость между системными требованиями и результатами проектирования ПО. Изменения, внесенные при модификации ПО, могут воздействовать на безопасность системы и, сле- довательно, также должны быть идентифицированы для оценки безопасности системы. Определения уровня ПО по отказам Уровень ПО определяется возможностью воз- никновения потенциальных отказных ситуаций, вы- явленных процессом оценки безопасности системы, в результате сбоев в ПО. Уровень ПО означает, что тру- дозатраты, необходимые для доказательства согласо- ванности с требованиями сертификации, меняются в зависимости от категории отказной ситуации. Уровень А: ПО, аномальное поведение кото- рого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) воз- |