Учебное пособие санктПетербург 2015
 Скачать 3.34 Mb.
|
|
План сертификации в части ПО План сертификации в части ПО, в первую оче- редь, предназначен для использования сертифицирую- щей организацией с целью определить, что предлага- емый соискателем жизненный цикл ПО соответствует требованиям для разработки ПО указанного уровня. Этот план должен иметь следующие разделы: а) Обзор системы. Этот раздел представляет обзор системы, включающий в себя описание ее фун- кций и их распределения между аппаратным и про- граммным обеспечением, архитектуру, используемые процессоры, аппаратно-программные интерфейсы и особенности обеспечения безопасности. б) Обзор ПО. Этот раздел кратко описывает функции ПО, уделяя особое внимание предлагаемым концепциям обеспечения безопасности и разбиения структуры, например совместное использование ре- сурсов, резервирование, многоверсионное программи- рование, обеспечение отказоустойчивости, стратегия синхронизации и планирования выполнения ПО. в) Вопросы сертификации. Этот раздел описы- вает сертификационный базис, включая средства дока- зательства соответствия разработки ПО требованиям сертификации ПО; раздел также устанавливает пред- лагаемые уровни ПО (уровни критичности) и сумми- 236 Методы оценки и измерения характеристик информационных систем рует пояснения, обеспечивающие процесс оценки бе- зопасности системы, включая потенциальный вклад ПО в создание отказных ситуаций. г) Жизненный цикл ПО. Этот раздел определяет используемую модель жизненного цикла ПО, которая должна быть выполнена и которую контролируют про- цессы жизненного цикла ПО, детализируемая инфор- мация для последних определена в соответствующих планах ПО. Данный раздел поясняет то, каким образом должны быть удовлетворены цели каждого процесса жизненного цикла, и точно определяет организации, участвующие в разработке, организационную ответс- твенность, а также ответственность за процессы жиз- ненного цикла системы и процесс сертификационного взаимодействия. д) Документы жизненного цикла ПО. Этот раз- дел точно специфицирует документы жизненного цик- ла ПО, которые должны быть разработаны и должны контролироваться процессами жизненного цикла ПО. Данный раздел также описывает отношения между этими документами или другими документами, опре- деляющими систему, документами жизненного цикла, представляемыми на рассмотрение сертифицирующей организации, форму документов и способ, посредс- твом которого документы жизненного цикла становят- ся доступными для сертифицирующей организации. е) План-график. Этот раздел описывает средс- тва соискателя, которые должны обеспечивать про- зрачность работ процессов жизненного цикла ПО для сертифицирующей организации (в целях планирова- ния просмотров). ж) Дополнительные вопросы. Этот раздел опи- сывает специфические особенности, которые могут влиять на процесс сертификации, например: 237 Стандартизация и сертификация программного обеспечения 1) альтернативные методы согласования; 2) аттестация инструментальных средств; 3) использование ранее разработанного ПО; 4) использование ПО, разработанного в необяза- тельном порядке; 5) использование модифицируемого пользовате- лем ПО; 6) использование коммерчески доступного ПО; 7) использование ПО, загружаемого в полевых условиях; 8) использование многоверсионного неидентич- ного ПО. План разработки ПО План разработки ПО содержит описание целей, стандартов и модели жизненного цикла ПО, которые должны быть использованы в процессах разработки ПО. Этот план может быть включен в План сертифи- кации в части ПО. План разработки ПО должен вклю- чать в себя следующие разделы: а) Стандарты: идентификация стандартов на разработ- ку требований к ПО, стандартов на процесс проекти- рования ПО, стандартов кодирования ПО для данного проекта, а также ссылки на стандарты для ранее разра- ботанного ПО, включая коммерчески доступное ПО, если эти стандарты различаются. б) Жизненный цикл ПО: описание процессов жиз- ненного цикла ПО, которые должны быть исполь- зованы для формирования конкретного жизненно- го цикла данного проекта, включая критерии пе- рехода между процессами ПО. Это описание от- личается от резюме в Плане сертификации в части ПО тем, что оно содержит подробности, необхо- димые для гарантии соответствующей реализации процессов жизненного цикла ПО. 238 Методы оценки и измерения характеристик информационных систем в) Среда разработки ПО: обоснование выбора исполь- зуемой среды разработки ПО в аппаратной и програм- мной частях, включая: 1) выбор методов и средств разработки требований; 2) выбор методов и средств проектирования ПО; 3) выбор языков программирования, средств коди- рования, компиляторов, редакторов связей и загрузчиков; 4) аппаратную поддержку для инструменталь- ных средств. ГОСТ Р ИСО-МЭК ТО 9294-93 Руководство по управлению документированием программного обеспечения Данный стандарт представляет собой руководство по документированию программного обеспечения для тех руководителей, которые отвечают за производство программного обеспечения или программной продук- ции. Руководство предназначено для помощи руково- дителям в обеспечении эффективного проведения до- кументирования в их организациях. Стандарт направ- лен на определение стратегий, стандартов, процедур, ресурсов и планов, которыми должны заниматься сами руководители для того, чтобы эффективно управлять документированием программного обеспечения. Руководство предназначено для применения ко всем типам программного обеспечения - от простейших программ до наиболее сложного программного набора или системы программного обеспечения. Охвачены все типы программной документации, относящиеся ко всем стадиям жизненного цикла программного обеспечения. Руководители принимают на себя организацию работ по документированию и осуществляют подде- ржку этих работ в стратегиях, стандартах, процеду- рах, распределении ресурсов и планах, которыми они 239 Стандартизация и сертификация программного обеспечения определяются. Эффективность выполнения руково- дящей роли можно рассматривать как основанную на трех элементах: 1) Руководящая обязанность по документирова- нию. Данная обязанность требует признания того, что программная документация важна и что ее следует планировать, описывать, проверять, утверждать, вы- пускать, распространять и сопровождать. 2) Руководящая поддержка обязанностей персо- нала по документированию. Для этого требуется руко- водство и стимулирование персонала при проведении требуемого документирования и обеспечение его ре- сурсами для содействия в данной работе. 3) Признаки руководящих обязанностей и подде- ржки. Для этого требуется обеспечить: а) опубликованные официальные отчеты о стратегии документирования; б) стандарты и руководства, определяющие все аспекты документирования программного обеспечения; в) опубликованные процедуры документирования; г) выделение соответствующих ресурсов для докумен- тирования; д) планирование документирования, осуществляемое как неотъемлемая часть процесса разработки програм- много обеспечения; е) постоянную проверку, осуществляемую для обеспе- чения соответствия со стратегией, стандартами, про- цедурами и планами по документированию. Функции программной документации Для эффективного управления документирова- нием программного обеспечения важно осознавать различные функции, выполняемые документацией. Программную документацию можно рассматривать как имеющую шесть основных функций: 240 Методы оценки и измерения характеристик информационных систем 1) информация для управления; 2) связь между задачами; 3) обеспечение качества; 4) инструкции и справки; 5) сопровождение программного обеспечения; 6) исторические справки. Во время разработки программного обеспечения администрации необходимо оценивать ход работы, возникающие проблемы и вероятности развития про- цесса. Периодические отчеты, согласно которым про- веряют ход работ по графику и представляют планы на следующий период, обеспечивают контрольные меха- низмы и обзор проекта. Связь между задачами Большинство проектов разработки програм- много обеспечения разделяется на задачи, зачас- тую выполняемые различными группами. В типо- вом варианте: - специалисты в предметной области начина- ют проект; - аналитики формулируют требования к системе; - проектировщики разрабатывают системный и программный проекты; - специалисты по изданиям создают пользова- тельскую документацию в соответствии со стратегией и стандартами по документированию; - специалисты по обеспечению качества и ре- визоры оценивают общую полноту и качество функ- ционирования программного обеспечения; - сопровождающие программисты улучшают эксплуатируемое программное обеспечение и разраба- тывают его изменения или расширения. Этим людям необходимы средства общения друг с другом, обеспечивающие информацию, которую 241 Стандартизация и сертификация программного обеспечения можно, при необходимости, воспроизводить, распро- странять и на которую можно ссылаться. Большинство методологий разработки програм- много обеспечения устанавливают официальные до- кументы для связи между задачами. Например, ана- литики представляют официальные спецификации требований для проектировщиков, а проектировщики выдают официальные проектные спецификации для программистов. Установление стратегии документирования Стратегии документирования, подготовленные и отслеживаемые главной администрацией, обеспечива- ют руководства для ответственных лиц, принимающих решения на всех нижних уровнях. Стратегия обеспе- чивает главное направление, но не дает рекомендаций, что делать или как это делать. Из-за существенной роли, которую играет докумен- тация на всех стадиях жизненного цикла программного обеспечения, должна быть подготовлена официально ут- вержденная стратегия. Каждый затронутый стратегией должен быть информирован о ней и должен ее понимать. Официальная, описанная, разрекламированная страте- гия устанавливает дисциплину, требуемую для эффек- тивного документирования программного обеспечения. Стратегия должна поддерживать основные элементы эф- фективного документирования: 1) Требования документации охватывают весь жизненный цикл программного обеспечения. Докумен- тация требуется на ранних стадиях проекта и должна быть доступна и сопровождаться на всем протяжении процесса разработки программного обеспечения. После заверше- ния процесса разработки документация необходима для использования, сопровождения, модернизации, преобра- зования или передачи программного обеспечения; 242 Методы оценки и измерения характеристик информационных систем 2) Документирование должно быть управля- емым. Управление и контроль требуются для полу- чения и сопровождения документации. Руководите- ли и специалисты по изданиям должны подготовить подробные планы, охватывающие документирование продукции, графиков, обязанностей, ресурсов, обеспе- чения качества и процедур проверок; 3) Документация должна соответствовать ее читательской аудитории. Читателями могут быть руководители, аналитики, специалисты по экспертным системам, сопровождающие програм- мисты, канцелярский персонал и т.д. В зависимос- ти от выполняемых задач им требуются различные степени детализации и различное представление материала. Специалисты по изданиям должны быть готовы соответствующим образом спроектировать различные типы документации, предназначенные для различных читателей; 4) Работы по документированию должны быть объединены в общий процесс разработки програм- много обеспечения. Процесс разработки должен быть определен; 5) Должны быть определены и использова- ны стандарты по документированию. По возмож- ности, должны быть приняты существующие стан- дарты. Когда подходящие стандарты отсутствуют, должны быть разработаны требуемые стандарты и руководства; 6) Должны быть определены средства подде- ржки. Должны быть использованы там, где это эко- номически целесообразно, средства, помогающие раз- работке и сопровождению программной продукции, включая документацию. 243 Стандартизация и сертификация программного обеспечения Определение стандартов и руководств по документированию Внутри организации должны быть приняты стан- дарты и руководства для: - модели жизненного цикла программного обеспече- ния; - типов и взаимосвязей документов; - содержания документа; - качества документа; - форматов документа; - обозначения документа. Данные стандарты и руководства будут опреде- лять, как следует выполнять задачи документирова- ния, и будут обеспечивать критерии для оценки полно- ты, полезности и соответствия программной докумен- тации, создаваемой в организации. По возможности, должны быть приняты действующие международные и национальные стандарты. Если подходящие стан- дарты отсутствуют, то организация должна разрабо- тать собственные. Большинство стандартов и руководств выдают ре- комендации, которые применимы на общем уровне. За- частую будут требоваться управленческие решения для адаптации общих рекомендаций к конкретным проек- там. Применение стандартов, распространяющихся на организацию документирования, облегчит руководите- лям проекта определение следующих вопросов: - какие типы документов требуются? - каков объем представляемой документации? - что документы содержат? - какой уровень качества будет достигнут? - где документы будут созданы? - как документы будут храниться, сопровождаться и обращаться? 244 Методы оценки и измерения характеристик информационных систем Если возможен контракт на программное обеспе- чение, контракт должен требовать, чтобы документация удовлетворяла принятым стандартам. Он должен опре- делять типы поставляемых документов, уровень качест- ва каждого и процедуры их проверки и утверждения. Установление процедур документирования Должны быть установлены процедуры для при- меняемых в организациях стратегий документирова- ния. Процедуры определяют последовательность до- кументирования: - планирование; - подготовка; - конфигурационное управление; - проверка; - утверждение; - производство; - хранение; - дублирование; - распространение и модернизация; - продажа. Процедуры также должны определять контроль- ные пункты и методы обеспечения качества. Планирование документирования План документирования определяет, что долж- но быть сделано, как это должно быть сделано, ког- да это должно быть сделано и кто это должен де- лать. План документирования может быть частью общего плана проектирования или отдельным до- кументом. Для небольших, неофициальных проек- тов план может быть всего на одной странице. Для больших проектов это может быть объемный доку- мент, который следует установленным стандартам и является предметом для официальной проверки и процедуры утверждения. 245 Стандартизация и сертификация программного обеспечения План документирования должен быть доведен до всех участников разрабатывающего коллектива и до всех, кого он касается. Должны быть четко уста- новлены обязанности всех вовлеченных в работу, свя- занную с документированием. План должен включать в себя изложение: - общей структуры документации; - типов и содержания документов; - качества и форматов документов; - обозначения документов; - комплектности и хранения документов; - обращения документов; - графика документирования. График документирования должен распределять время для: - планирования документов; - проверки плана документирования и принци- пов документирования; - подготовки проектов и проверки их на техни- ческую точность, полноту и соответствие; - редактирования при внесении комментариев, появившихся при проверке; - проведения согласования; - перевода (например, с японского на французс- кий); - распространения. Планирование следует начинать заранее, и план необходимо проверять на всем протяжении проек- та. Подобно любому плану план документирования отражает намечаемые действия и является объектом для необходимых изменений. В проекте должны быть предусмотрены регулярные проверки результатив- ности изменений в плане. 246 Методы оценки и измерения характеристик информационных систем 7.2 Основы сертификации программной продукции Сертификация – комплекс действий, в резуль- тате которых посредством специального документа – сертификата или знака соответствия – подтверждается соответствие продукции требованиям международ- ных или национальных стандартов. Является важной мерой повышения конкурентоспособности. Сертификация – Деятельность по подтвержде- нию соответствия продукции, процессов или услуг ус- тановленным требованиям. Сертификация в переводе с латыни означает «сделано верно». Добровольная сертификация проводится по ини- циативе самого предприятия – изготовителя продукции с целью повышения конкурентоспособности продукции или по требованию продавца, а также потребителя. Обязательная сертификация является прерога- тивой государства и направлена на обеспечение качес- тва и безопасности продукции. Цели подтверждения соответствия Подтверждение соответствия осуществляется в целях: - удостоверения соответствия продукции, процес- сов проектирования (включая изыскания), производс- тва, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации и утилизации, работ, услуг или иных объектов техническим регламентам, стандартам, сводам правил, условиям договоров; - содействия приобретателям, в том числе потреби- телям, в компетентном выборе продукции, работ, услуг; - повышения конкурентоспособности продукции, работ, услуг на российском и международном рынках; - создания условий для обеспечения свободного перемещения товаров по территории Российской Фе- |