Домашнее задание для ПО 3.11 по документирование и сертификация от 23.10.20
учебно-методический материал

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

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

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

Процессами формирования ИС — процессами информатизации — в России стали серьезно заниматься с начала 90-х годов. Вначале Комитет при Президенте РФ по политике информатизации, а в настоящее время в результате ряда структурных реорганизаций Минсвязи России возглавляет работы по организации этих процессов, координации действий научных и конструкторских организаций.

Сущность процесса информатизации и основные положения государственной политики в сфере информатизации.

Основные понятия.

Несмотря на сложности, обусловленные переходной экономикой, быстрым развитием отечественного рынка информационных, компьютерных и телекоммуникационных технологий, государственная политика информатизации приобрела в настоящее время концептуальную целостность. Созданы важные правовые, организационные и экономические условия для развития информационной и коммуникационной инфраструктуры, системы распространения и использования информационных ресурсов. Существенное внимание уделяется разработке законодательства в этой области. Так, в сентябре 1992 года принят Закон "О правовой охране программ для электронных машин и баз данных", в ноябре 1994 года - Закон "Об обязательном экземпляре документов", в феврале 1995 года - Закон "Об информации, информатизации и защите информации", в июне 1996 года - Закон "Об участии в международном информационном обмене". По проблемам информатизации выпущено большое количество указов Президента РФ, постановлений Правительства РФ, а также руководящих и организационно-методических материалов различных государственных организаций. Прежде всего дадим определение собственно термину "информатизация". В Законе "Об информации, информатизации и защите информации" это понятие определено следующим образом:

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

В этом Федеральном законе используется еще несколько понятий:

информация - сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления;

документированная информация (документ) - зафиксированная на материальном носителе информация с реквизитами, позволяющими ее идентифицировать;

информационные процессы - процессы сбора, обработки, накопления, хранения, поиска и распространения информации;

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

информационные ресурсы - отдельные документы и отдельные массивы документов, документы и массивы документов в информационных системах (библиотеках, архивах, фондах, банках данных, других информационных системах);

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

конфиденциальная информация - документированная информация, доступ к которой ограничивается в соответствии с законодательством Российской Федерации;

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

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

пользователь (потребитель) информации - субъект, обращающийся к информационной системе или посреднику за получением необходимой ему информации и пользующийся ею.

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

Основными направлениями государственной политики в сфере информатизации являются:

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

В "Концепции формирования и развития единого информационного пространства России и соответствующих государственных информационных ресурсов", отмечено, что имеющиеся проблемы информатизации России можно решить только путем формирования единого информационного пространства России. Это понятие определено в Концепции так:

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

Иными словами, единое информационное пространство складывается из следующих главных компонентов:

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

Организационные структуры и средства информационного взаимодействия образуют информационную инфраструктуру.

Целями формирования и развития единого информационного пространства России являются:

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

Основными задачами государственной политики в области индустрии информатизации являются:

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

1.2 Развитие рынка в программных средств в России. Критические информационные, компьютерные и телекоммуникационные технологии.

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

Сегодня в большинстве крупных городов России эффективно функционируют провайдеры — организации, обеспечивающие пользователям доступ в Интернет. Широко используется бесплатное (некоммерческое) обслуживание пользователей. Быстро расширяется и рынок сетевой коммерческой информации (сведения о компаниях, товарных рынках, рынке ценных бумаг, объектах инвестиций). Это означает серьезный шаг по пути к информационной экономике.

Бурному развитию процессов информатизации и, соответственно, отечественных территориальных компьютерных сетей и информационных систем различного рода в первой половине 90-х годов в значительной мере способствовало как ускорение развития инфраструктуры связи, так и определенное насыщение страны персональными компьютерами.

В настоящее время отечественные сетевые структуры (при отставании на 1-2 года) развиваются в направлениях, по которым идут США, Великобритания, Германия, Франция.

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

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

К этим технологиям прежде всего следует отнести:

многопроцессорные ЭВМ с параллельной структурой;
вычислительные системы на базе нейрокомпьютеров, транспьютеров и оптических ЭВМ;
системы распознавания и синтеза речи, текста и изображений;
системы искусственного интеллекта и виртуальной реальности;
информационно - телекоммуникационные системы;
системы математического моделирования.

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

Что касается российского информационного рынка, то его главная отличительная черта состоит в его неоднородности по регионам страны. Это связано, естественно, с географическим положением регионов, неравномерностью их социально-экономического развития, направленностью экономической деятельности и т. д.

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

Необходимо отметить развитие сферы домашнего потребления компьютеров, которая быстро растет, и в ближайшие годы количество домашних компьютеров может составить до половины всего парка ПК, что вызовет резкое повышение спроса на информационные продукты и услуги (до 60—70% в общем объеме продаж).

Российская культурная среда оказывает непосредственное воздействие на процессы информатизации. Имеется ряд благоприятных для этого развития социально-демографических характеристик, в частности высокий процент городских жителей. Другой важный индикатор — высокий процент молодых, 15—16-летних людей, активных, способных и желающих осваивать компьютерный мир. Однако сегодня работают и тормозящие факторы: неразвитые информационные потребности населения и неготовность общества жить в условиях открытого общества.

Политика информатизации должна быть ориентирована и на решение главных задач информационной политики:

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

1.3 Стандартизация

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

В документах Международной организации по стандартизации (ИСО) термин стандартизация определяется следующим образом:

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

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

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

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

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

Правовые основы стандартизации, обязательные для всех государственных органов управления, объектов хозяйственной деятельности и общественных объединений Российской Федерации, определены Законом "О стандартизации", принятым в 1993 году. Общее руководство работами по стандартизации в Российской Федерации возложено на Госстандарт России.

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

Качество средств и систем информатизации сегодня определяется:

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

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

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

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

1.4 Лицензирование

Основным отличием процесса лицензирования от процесса сертификации является состав категорий, по отношению к которым они применяются. В процессе лицензирования фигурируют такие категории, как "деятельность" (подразумеваются виды или направления деятельности) и "субъект" (физическое лицо, предприятие, организация или иное юридическое лицо).

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

Лицензия является официальным документом, который разрешает осуществление указанного в нем вида деятельности в течение установленного срока, а также определяет условия его осуществления.

Основу нормативно-правовой базы лицензирования в сфере информатизации составляют Законы "О лицензировании отдельных видов деятельности", "Об информации, информатизации и защите информации" и "Об участии в международном информационном обмене".

Общие принципы лицензирования видов деятельности в сфере информатизации России можно сформулировать следующим образом:

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

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

Право на осуществление деятельности, подлежащей лицензированию, может получить субъект, отвечающий определенным критериям, которые заранее определяются правилами проведения лицензирования и являющимися их неотъемлемой частью требованиями к предприятию-заявителю. Таким образом, субъектом лицензирования становится лишь то физическое или юридическое лицо, которое представляет все необходимые и правильно оформленные документы и удовлетворяет соответствующим требованиям.

За органом, уполномоченным на проведение лицензионной деятельности, закрепляется право на осуществление контроля за деятельностью лицензиата.

Существует несколько типов лицензий на программные продукты.

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

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

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

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

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

1.6 Жизненный цикл программного продукта.

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

Рис.1 Жизненный цикл программного продукта.

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

Проектирование структуры — алгоритмизация процесса обработки данных, детализация функций, разработка архитектурного проекта, выбор методов и средств создания программ.

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

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

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

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

Снятие программного продукта с продажи и отказ от его сопровождения происходит, как правило, в случае изменения технической политики фирмы-изготовителя, неэффективности работы программного продукта, наличия в нём неустранимых ошибок, отсутствие спроса.

Длительность жизненного цикла разных программных продуктов неодинакова. Для большинства современных программ его длительность составляет 2-3 года. Хотя часто встречаются на компьютерах и давно снятые с производства программные продукты.

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

Эти модели выражают последовательность этапов ЖЦ ПО. До 80-х годов имела место каскадная модель ЖЦ (рис.2) подразумевавшая переход на последующие этапы ЖЦ только после полного окончания работ на предыдущих этапах.

Рис.2 Каскадная модель жизненного цикла

С развитием вычислительной техники, в середине 80-х, сложность и объемы программного обеспечения существенно возросли. В связи с этим возникли проблемы с разработкой и отладкой ПО. Продумать все шаги разработки нового ПО, наметить этапы проектирования и предусмотреть все варианты поведения при отладке программного обеспечения стало не под силу одному разработчику. Каскадная модель ЖЦ стала существенно сдерживать темпы создания сложных программных систем. Процесс отладки, при этом, затягивался и не давал гарантий безошибочной работы программ.

На смену каскадной модели, жестко регламентирующей последовательность этапов и критерии переходов между ними, пришла поэтапная модель с промежуточным контролем (рис. 3).

Рис.3 Поэтапная модель с промежуточным контролем

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

Спиральная модель (рис. 4) поддерживает итерации поэтапной модели, но особое внимание уделяется начальным этапам проектирования: анализу требований, проектированию спецификаций, предварительному проектированию и детальному проектированию. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии ПО, уточняются цели и требования к ПО, оценивается качество разработанного фрагмента или версии ПО и планируются работы следующего витка. Таким образом, углубляются и конкретизируются все детали проектируемого ПО, и в результате получается вариант, который удовлетворяет всем требованиям заказчика.

Рис.4 Спиральная модель

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

Как было отмечено выше, жизненные циклы систем, процессов их разработки, эксплуатации и сопровождения регламентированы в стандартах. При этом стандарты, разрабатываемые международными организациями в той или иной области деятельности, носят рекомендательный характер и не возведены в ранг закона. Руководящие принципы, определенные в стандартах, имеют официальную силу тогда, когда приняты правительством той или иной страны. В настоящее время общепризнанными международными лидерами в области стандартизации разработки ПО стали следующие организации: Американский национальный институт по стандартизации - ANSI; Международная организация по стандартизации - ISO; Министерство обороны США - DOD, Институт инженеров по электронике и радиотехнике (IEEE).

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

В рамках поставленной цели управления нужно решить задачу оптимизации структуры ЖЦ как по продолжительности отдельных фаз цикла, так и по затратам различных видов ресурсов по фазам.

К задачам управления ЖЦ ПП относят:

планирование;
регулирование;
рациональное использование трудовых и финансовых ресурсов;
учет затрат и нормирование труда разработчиков;
снижение производственных затрат в ходе разработки ПП;
устранение непроизводительных расходов при заданном уровне качества ПП.

1.6.1 Подход к разработке прикладного ПО.

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

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

Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в проектировании, программировании и тестировании ПО, способных хорошо взаимодействовать с конечным пользователем и трансформировать их предложения в рабочие прототипы.

ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:

1. Анализ и планирование требований предусматривает действия:

определение функций, которые должна выполнять система;
выделение наиболее приоритетных функций, требующих проработки в первую очередь;
описание информационных потребностей. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков.

Кроме того, на данной стадии реализуются следующие задачи:

- ограничивается масштаб времени;

- устанавливаются временные рамки для каждой из последующих стадий. Определяется сама возможность реализации проекта в заданных рамках финансирования, на имеющихся аппаратных средствах.

Результатом стадии должны быть список расставленных по приоритету функций будущего ПО ЭИС и предварительные модели ПО.

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

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

После детального определения состава процессов оценивается количество так называемых функциональных точек разрабатываемой системы и принимается решение о разделении ЭИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое время (до 3 месяцев). Под функциональной точкой понимается любой из следующих элементов разрабатываемой системы:

входной элемент приложения (входной документ или экранная форма);
выходной элемент приложения (отчет, документ, экранная форма)
запрос (пара «вопрос/ответ»);
логический файл (совокупность записей данных, используемых внутри приложения);
интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).

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

Результатом данной стадии должно быть:

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

На стадии реализации выполняется непосредственно сама быстрая разработка приложения.

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

Пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки.

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

Осуществляется анализ использования данных и определяется необходимость их распределения.
Производится физическое проектирование базы данных
Формируются требования к аппаратным ресурсам.
Устанавливаются способы увеличения производительности.
Завершается разработка документации проекта.

Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям.

На стадии внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы продолжается эксплуатация существующей системы (до полного внедрения новой). Так как стадия реализации достаточно продолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на стадии проектирования системы. Приведенная схема разработки ЭИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка:

разрабатывается совершенно новая система;
уже было проведено обследование организации и существует модель ее деятельности.

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

Следует отметить, что подход RAD, как и любой другой подход, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникаций, то на первый план выступают такие показатели проекта как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Подход RAD не применим для построения сложных расчетных программ, операционных систем.

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

Итак, перечислим основные принципы подхода RAD.

Разработка приложений итерациями.
Необязательность полного завершения работ на каждой стадии ЖЦ ПО.
Обязательность вовлечения пользователей в процесс разработки ЭИС.
Целесообразность применения CASE – средств, обеспечивающих целостность проекта и генерацию кода приложений.
Целесообразность применения средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы.
Использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей.
Тестирование и развитие проекта, осуществляемые одновременно с разработкой.
Ведение разработки немногочисленной хорошо управляемой командой профессионалов.
Грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.

1.6.2 Модели качества процессов конструирования

В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO / IЕС 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model - СММ) Института программной инженерии при американском университете Карнеги-Меллон.

Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IЕС 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IЕС 15504 взята из модели СММ.

Базовым понятием модели СММ считается зрелость компании. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.

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

Таким образом, модель СММ фиксирует критерии для оценки зрелости компании и предлагает рецепты для улучшения существующих в ней процессов. Иными словами, в ней не только сформулированы условия, необходимые для достижения минимальной организованности процесса, но и даются рекомендации по дальнейшему совершенствованию процессов.

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

Рис. 5. Пять уровней зрелости модели СММ

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

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

Следующий, определенный уровень (уровень 3) требует, чтобы все элементы процесса были определены, стандартизованы и документированы. Основное отличие от уровня 2 заключается в том, что элементы процесса уровня 3 планируются и управляются на основе единого стандарта компании. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей.

С переходом на управляемый уровень (уровень 4) в компании принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса.

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

Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:

предотвращения дефектов;
управления изменениями технологии;
управления изменениями процесса.

Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ

К задачам управления ЖЦ ПП относят:

планирование;
регулирование;
рациональное использование трудовых и финансовых ресурсов;
учет затрат и нормирование труда разработчиков;
снижение производственных затрат в ходе разработки ПП;
устранение непроизводительных расходов при заданном уровне качества ПП.

1.6.3 Определение метода и технологии

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

Концепций и теоретических основ. В качестве таких основ могут выступать структурный или объектно-ориентированный подход.
Нотаций, используемых для построения моделей статической структуры и динамики поведения проектируемой системы. В качестве таких нотаций обычно используются графические диаграммы, поскольку они наиболее наглядны и просты в восприятии (диаграммы потоков данных, и диаграммы «сущность – связь» для структурного подхода, диаграммы вариантов использования, диаграммы классов и др. – для объектно-ориентированного подхода.
Процедур, определяющих практическое применение метода (последовательность и правила построения моделей, критерии, используемые для оценки результатов).

Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ ПО.

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

Требования к технологии

Современная технология проектирования должна обеспечивать:

Соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех процессов ЖЦ ПО).
Гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время.
Возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности (3-7 чел.), с последующей интеграцией составных частей.
Минимальное время получения работоспособного ПО ЭИС. Речь идет не о сроках готовности всей ЭИС, а о сроках реализации отдельных подсистем. Практика показывает, что даже при наличии полностью завершенного проекта внедрение ЭИС идет последовательно по отдельным подсистемам.
Независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования).
Поддержка комплексом согласованных CASE – средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ ПО.

Реальное применение любой технологии проектирования ПО ЭИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся:

Стандарт проектирования.
Стандарт оформления проектной документации.
Стандарт интерфейса конечного пользователя с системой.

Стандарт проектирования должен устанавливать:

Набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации.
Правила фиксации проектных решений на диаграммах, в том числе правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм (включая требования к форме и размерам объектов) и т.д.
Требования к конфигурации рабочих мест разработчиков, включая настройки ОС, настройки CASE – средств и т.д.
Механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила анализа проектных решений на непротиворечивость и т.д.

Стандарт оформления проектной документации. Он должен устанавливать:

комплектность, состав и структуру документации на каждой стадии проектирования (в соответствии со стандартом ГОСТ Р ИСО 9127 – 94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов»);
требования к оформлению документации (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.);
правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков на каждой стадии;
требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
требования к настройке CASE – средств для обеспечения подготовки документации в соответствии с установленными правилами.

Стандарт интерфейса конечного пользователя с системой. Он должен регламентировать:

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

1.7 Сущность структурного подхода. Принципы, на которых базируется структурный подход. Метод SADT. Метод DFD.

Проблема сложности является главной проблемой, которую приходится решать при создании больших систем любой природы, в том числе и ЭИС. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять все систему в целом. Единственно эффективный подход к решению этой проблемы заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй», иерархическая декомпозиция и др. по отношению к проектированию сложной программной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем. Понятие «правильная» по отношению к декомпозиции означает следующее:

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

Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки:

Каждая подсистема должна инкапсулировать свою содержимое (скрывать его от других подсистем). Каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

Итак, сущность структурного подхода к разработке ПО ЭИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх», от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов:

Принцип «разделяй и властвуй»;
Принцип иерархического упорядочения - принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

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

В структурном подходе в основном две группы средств, описывающих функциональную структуру системы и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди них являются:

DFD (Data Flow Diagrams) - диаграммы потоков данных;

SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы;

ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».

Практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования:

Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0).
Диаграммы, моделирующие данные и их отношения (ERD).

Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT - модели и DFD используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким образом существующую и предлагаемую структуру бизнес - процессов организации и взаимодействие между ними (использование SADT - моделей , как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД).

На стадии проектирования DFD используются для описания структуры проектируемой системы.

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

Метод функционального моделирования SADT

Разработан Дугласом Россом в 1973г. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следующих концепциях:

Графическое представление блочного моделирования. Графика блоков и дуг SADT - диаграммы отображает функцию в виде блока, а интерфейсы входа-выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются. Это:

Строгость и точность. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (3-6), связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), разделение входов и управлений (правило определения роли данных).
Отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель).

Состав функциональной модели

Результатом применения метода SADT является модель, состоящая из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно (рис.6). Управляющая информация входит в блок сверху в то время, как входная информация, которая подвергается обработке, показаны с левой стороны блока, а результаты (выход) - справа. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей снизу.

Рис. 6. Функциональный блок и интерфейсные дуги

Построение иерархии диаграмм

Построение SADT - модели начинается с представления всей системы в виде простейшего компонента – одного блока и дуг, изображающих интерфейсы с функциями вне системы (рис.7). Поскольку единственный блок отражает систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг - они также соответствуют полному набору внешних интерфейсов системы в целом.

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

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

Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков (рис.8). Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы.

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

Рис. 7. Общее представление

Ниже (рис. 8,9) приведены различные варианты выполнения функций и соединения дуг с блоками.

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

Рис. 8. Иерархия диаграмм

Рис. 9. Функции блоков А2 и А3 могут выполняться параллельно

Рис. 10. Соответствие интерфейсных дуг родительской (а) и детальной (б) диаграмм

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

Рис. 11. Пример обратной связи

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

Типы связей между функциями

Одним из важнейших моментов при моделировании бизнес-процессов организации с помощью метода SADT является точная согласованность типов связей между функциями. Различают по крайней мере связи семи типов (в порядке возрастания их относительной значимости):

случайная;
логическая;
временная;
процедурная;
коммуникационная;
последовательная;
функциональная.

Случайная связь – показывает, что конкретная связь между функциями незначительна или полностью отсутствует (рис.12).

Это относится к ситуации, когда имена данных на SADT – дугах в одной диаграмме имеют слабую связь друг с другом. Крайний вариант этого случая:

Рис. 12. Случайная связь

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

Временная связь - представляет функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

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

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

Процедурная связь

Коммуникационная связь

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

Последовательная связь

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

Функциональная связь

В математических терминах необходимое условие для простейшего типа функциональной связи имеет вид:

С=g(B)=g(f(F)).

В таблице 1 ниже представлены все типы связей. Важно отметить, что уровни 4-6 устанавливают типы связей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.

Типы связей

Таблица 1

Уровень значимости	Тип связи	Характеристика типа связи
Уровень значимости	Тип связи	Для функций	Для данных
0	случайная	случайная	Случайная
1	логическая	Функции одного и того же множества или типа (например, «редактировать все входы»)	Данные одного и того же множества или типа
2	временная	Функции одного и того же периода времени (например, «операции инициализации»)	Данные, используемые в каком либо временном интервале
3	процедурная	Функции, работающие в одной и той же фазе или итерации, например, «первый проход компилятора»	Данные используемые во время одной и той же фазы или итерации
4	коммуникационная	Функции, использующие одни и те же данные	Данные, на которые воздействует одна и та же деятельность
5	Последовательная	Функции, выполняющие последовательное преобразование одних и тех же данных	Данные, преобразуемые последовательными функциями
6	функциональная	Функции, объединяемые для выполнения одной функции	Данные, связанные с одной функцией

2. Качество программного обеспечения

2.1 Характеристики качества программного обеспечения

В условиях существования рынка программных продуктов важными характеристиками являются:

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

Но необходимо учитывать влияние на стоимость характеристик качества ПО.

Качество - совокупность характеристик объекта, относящихся к его способности удовлетворить установленные и предполагаемые потребности. [ИСО8402].

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

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

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

Основные характеристики качества программного продукта (ПП).

Мобильность. ПП обладает этим свойством, если он может легко и эффективно использоваться для работы с ЭВМ с другой программно-аппаратной платформой, чем та, для которой изначально предназначалось. Свойство мобильности также можно считать свойством автономности. Потребность в обеспечении мобильности зависит от конкретного проекта. При этом должны учитываться затраты полученной эффективности. Пример мобильной программы: библиотеки стандартных функций, минимально использующие средства ОС и не использующие специфические функции.
Надежность (завершенность, устойчивость, восстанавливаемость). Надежность – это способность программы безотказно выполнять функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью. Надежный программный продукт не исключает наличия в нем ошибок. Здесь важно, чтобы ошибки при практическом применении в заданных условиях проявлялись достаточно редко. Степень надежности характеризуется вероятностью работы программного продукта без отказа в течение определенного периода времени.
Эффективность. ПП обладает этим свойством, если выполняет требуемые функции без излишних затрат ресурсов (объем ОП, скорость выполнения, выделенная память, пропускная способность сети и т. д.). Часто эффективность получается за счет ухудшения других характеристик. Является машинно-зависимой и определяется свойствами конкретного языка программирования. Обычно противоположно свойству мобильности. Существуют специальные методы написания программ, повышающие эффективность для конкретной платформы, но с другой стороны существуют автосредства, оптимизирующие уже готовые программы автоматически.
Учет человеческого фактора. Учитывается человеческий фактор, если он способен выполнять свои функции, не требуя излишних затрат времени со стороны пользователя, неоправданных усилий по поддержанию процесса функционирования без ущерба для морального состояния пользователя.
Модифицируемость. ПП обладает свойством модифицируемости, если он имеет структуру, позволяющую легко вносить требуемые изменения (модульная структура).
Коммуникативность. ПП обладает этим свойством, если оно дает возможность легко описывать входные данные и выдает информацию, форма и содержание которой просты, содержат полезные сведения.

Программные продукты массового распространения продаются по ценам, которые учитывают спрос и конъюнктуру рынка (наличие и цены программ-конкурентов). Большое значение имеет проводимый фирмой маркетинг, который включает:

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

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

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

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

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

Вторая концепция — иерархическая структура. Каждый уровень представляет собой совокупность структурных отношений между элементами нижних уровней. Концепция уровня позволяет понять систему, скрывая несущественные уровни детализации. Например, система, которую мы называем «человек», представляется иерархией. Социолог может интересоваться взаимоотношениями людей, не заботясь об их внутреннем устройстве. Психолог работает на более низком уровне иерархии. Он может исследовать различные логические и физические процессы в мозге, не рассматривая внутреннего строения областей мозга. Еще ниже в этой иерархии находится нейролог — он имеет дело со структурой основных компонентов мозга. Однако он может изучать мозг на этом уровне, не заботясь о молекулярной структуре отдельных белков в нейроне. Химик-органик интересуется построением сложных аминокислот из таких компонентов, как атомы углерода, водорода, кислорода и хлора. Физик-ядерщик изучает систему на уровне элементарных частиц в атоме и взаимодействия между ними.

Иерархия позволяет проектировать, описывать и понимать сложные системы. Если бы нельзя было принять описанный подход к изучению человека, социологу пришлось бы рассматривать его как необъятное и сложное множество субатомных частиц. Очевидно, что такое количество деталей подавило бы его, так что невозможны были бы даже те ограниченные знания о человеке, которыми мы располагаем.

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

2.2 Цена качества

Цена качества – важная категория, поскольку фактически она отражает стоимость работ на доработку, увеличенную стоимость сопровождения. Существует два подхода, которые могут применяться для оценки качества программного продукта:

Оценить качество конечного продукта
Оценить качество процесса разработки

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

В программировании в цене качества выделяют согласованную (conformance) и несогласованную (non-conformance) цену. Согласованная цена включает все планируемые затраты на повышение качества и предупреждение появления несоответствий. Несогласованная цена — это незапланированные потери, связанные с рекламациями, переделками, переносом сроков проекта и т. д. Статистические исследования на реальных проектах показывают, что несогласованная цена качества уменьшается существенно быстрее, чем увеличивается согласованная цена. Фактически это означает, что затраты на качество, безусловно, выгодны и должны окупаться не только в перспективе через расширение рынка, но и непосредственно в каждом текущем проекте.

2.3 Основные понятия качества программных средств

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

Изучением и реализацией методов и средств количественного оценивания качества продукции занимается научная дисциплина – квалиметрия. Эффективное управление качеством возможно лишь при наличии достаточно точных и объективных методов измерения или оценивания качества продукции или процессов. Создание и развитие квалиметрии подготовило обоснованное применение: численных, количественных методов в решении задач при оценке качества технологических процессов и готовой продукции, методов выбора предпочтений при анализе альтернативных групп продуктов, методов расчета интегрального качества, определении достоверности выборок при статистических оценках качества и ряд других задач управления качеством. В основе квалиметрии лежат три базовых положения:

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

Теоретическая квалиметрия абстрагируется от конкретных объектов и изучает общие закономерности и математические модели, связанные с оцениванием качества. Ее содержанием являются общие методологические проблемы количественной оценки качества, а также методы, направленные на преодоление общих трудностей, характерных для многих конкретных методик, предназначенных для количественной оценки качества конкретных объектов разного назначения.

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

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

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

Большое место в квалиметрии занимают статистические методы исследования. Многие показатели качества продукции определяются при помощи статистических методов по опытным данным или по материалам эксплуатационной статистики. Такие обобщенные квалиметрические оценки качества часто получаются путем измерения и сравнения физических, экономических, эстетических и других характеристик с лучшими образцами, которые формально такими эталонами не являются.

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

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

Потребителя-заказчика, прежде всего, интересуют функции и качество готового конечного продукта - программного средства, и обычно не очень беспокоит, как они достигнуты. Требуемое качество при разработке проектов ПС, как и любой продукции, можно обеспечить двумя методами:

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

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

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

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

Глубокая взаимосвязь качества разработанных программ с качеством технологии их создания и с затратами на разработку становится особенно существенной при необходимости получения конечного продукта с предельно высокими значениями показателей качества. Установлено, что затраты на разработку резко возрастают, когда показатель качества приближается к пределу, достижимому при данной технологии и уровне автоматизации процесса разработки. Это привело к существенному изменению в последние годы объектов, методологии и культуры в области создания и совершенствования ПС. Непрерывный рост требований к качеству ПС стимулировали создание и активное применение международных стандартов и регламентированных технологий, автоматизирующих основные процессы их жизненного цикла, начиная с инициирования проекта.

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

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

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

Качество в использовании - это основное качество системы, содержащей ПС, которое воспринимается пользователями. Оно измеряется скорее в терминах результата функционирования и применения программ, чем внутренних свойств самого ПС. Цель такого оценивания - определение, имеет ли продукт требуемый эффект в специфическом контексте использования. Качество ПС в среде пользователей может отличаться от качества в среде разработчиков, поскольку некоторые функции могут быть невидимы пользователю или не использоваться им. Пользователь оценивает только те атрибуты ПС, которые видимы и полезны ему в процессе реального применения. Поэтому к дефектам комплексов программ следует относить не только прямые потери при их применении пользователями, но и избыточные свойства, которые не нужны пользователям и потребовали дополнительных затрат при разработке. Иногда атрибуты ПС, специфицированные пользователем на этапе анализа требований, впоследствии не удовлетворяют его надежды при применении продукта вследствие изменения взглядов и понятий, а также трудности специфицирования неявных потребностей в начале проектирования.

Качество изменяется в течение жизненного цикла ПС, то есть его требуемое и реальное значение в начале ЖЦ почти всегда отличается от фактически достигнутого при завершении проекта и качества поставляемой пользователям версии продукта. На практике важно оценивать качество программ не только в завершенном виде, но и в процессе их проектирования, разработки и сопровождения. Кроме того, оценки показателей качества могут быть субъективными и отражать различные точки зрения и потребности разных специалистов. Чтобы эффективно управлять качеством на каждом этапе ЖЦ, необходимо уметь определять и примирять эти различные представления требуемого качества и его изменения. Характеристики этого процесса в значительной степени определяются совокупными затратами, необходимыми для достижения заданного качества конечного продукта - версии программного средства.

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

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

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

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

Определение и сравнение функционального качества программ целесообразно рассматривать в пределах ограниченных классов ПС, выполняющих подобные функции. Такие классы функций могут выделяться в пределах крупных проблемно-ориентированных сфер применения (административные, банковские, медицинские, авиационные и т.п.), и для решения более мелких, специальных, функциональных задач в этих областях. Каждая из таких задач может быть описана рядом специфических свойств, характеристик и атрибутов, полная номенклатура которых содержит многие тысячи названий, мер и шкал, которые трудно или невозможно унифицировать. Функциональные характеристики и их параметры могут подвергаться значительным модификациям в течение всего ЖЦ ПС и являются обычно наиболее динамичными компонентами из всех характеристик качества.

Функциональная пригодность (стандарт ISO-9126) непосредственно определяет основное назначение и функции ПС для пользователей. В контракте и техническом задании для каждого проекта, она должна быть выделена и формализована для однозначного понимания и оценивания всеми партнерами на каждом этапе ЖЦ и при значительных модификациях задач ПС. В силу своей специфичности, при последующем изложении функциональная пригодность обозначается как основная цель и главная характеристика для всего множества типов ПС.

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

Стандарт ISO 9126:1991 - Оценка программного продукта. Основные факторы, определяющие качество сложных программных средств. Внутренние метрики. Внешние метрики. Метрики качества в использовании.

Стандарт ISO 9126:1991 - Оценка программного продукта. Характеристики качества и руководство по их применению - является основой формального регламентирования характеристик качества ПС. Развитие этого международного стандарта проводится в направлении уточнения, детализации и расширения, описаний характеристик качества комплексов программ. Для замены редакции 1991 года завершается разработка и формализован проект стандарта, состоящего из четырех частей ISO 9126:1-4. Стандарт ISO 9126:1991 предполагается заменить, на две взаимосвязанные серии стандартов: ISO 9126:1-4 (проект) - Качество программных средств - и утвержденный стандарт ISO 14598:1-6:1998-2000 - Оценивание программного продукта. Проект нового стандарта ISO 9126 состоит из следующих частей под общим заголовком - Информационная технология - Качество программных средств:

Часть 1: Модель качества.

Часть 2: Внешние метрики качества.

Часть 3: Внутренние метрики качества.

Часть 4: Метрики качества в использовании.

Часть первая стандарта ISO 9126-1 - (пересмотренная и расширенная редакция ISO 9126:1991), сохранила практически ту же номенклатуру нормативных характеристик качества программных средств. В ней приводится схема взаимосвязи частей стандарта ISO 9126 и частей стандарта ISO 14598, а также область применения, нормативные ссылки, термины и определения. Модель характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками:

Функциональная пригодность детализируется:

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

Надежность характеризуется:

уровнем завершенности (отсутствия ошибок);
устойчивостью к дефектам;
восстанавливаемостью;
доступностью-готовностью.

Эффективность рекомендуется отражать:

временной эффективностью;
используемостью ресурсов.

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

понятностью;
простотой использования;
изучаемостью;
привлекательностью.

Сопровождаемость представляется:

удобством для анализа;
изменяемостью;
стабильностью;
тестируемостью.

Переносимость (мобильность) предлагается отражать:

адаптируемостью;
простотой установки - инсталляции;
сосуществованием - соответствием;
замещаемостью.

Дополнительно каждая характеристика сопровождается субхарактеристикой согласованность, которая должна отражать отсутствие противоречий с иными стандартами и нормативными документами, а также с другими показателями в данном стандарте. Характеристики и субхарактеристики в этой части стандарта определены очень кратко (2-3 строки), без комментариев и подробных рекомендаций по их применению к конкретным системам и проектам. Материалы имеют концептуальный характер и не содержат рекомендаций по выбору и упорядочению приоритетов необходимого минимума критериев в зависимости от особенностей объекта среды разработки и применения. Кроме того, отсутствуют методики измерения характеристик и сопоставления с требованиями спецификаций, а также рекомендации, на каких этапах ЖЦ ПС их целесообразно применять.

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

Основные факторы, определяющие качество сложных программных средств

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

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

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

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

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

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

Метрики качества в использовании отражают, в какой степени продукт удовлетворяет потребности конкретных пользователей в достижения заданных целей. Эта метрика не отражена в числе шести базовых характеристик ПС, регламентируемых стандартом ISO 9126-1 вследствие ее общности, однако рекомендуется для интегральной оценки результатов функционирования и применения комплексов программ в стандарте ISO 9126-4. Качество в использовании - это объединенный эффект функциональных и конструктивных характеристик качества ПС для пользователей. Связь качества в использовании с другими характеристиками ПС зависит от задач и функций их потребителей:

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

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

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

Для выбора характеристик качества ПС и достоверного сравнения их с требованиями, а также для сопоставления их значений между различными программными продуктами необходимы оценки, измерения и использование определенных мер и шкал. Стандартами рекомендуется, чтобы было предусмотрено измерение каждой характеристики качества ПС (субхарактеристики или ее атрибута) с точностью и определенностью, достаточной для сравнений с требованиями технических заданий и спецификаций, и чтобы измерения были объективны и воспроизводимы. Следует предусматривать нормы допустимых ошибок измерения, вызванных инструментами и/или ошибками человека-эксперта. Чтобы измерения были объективными, должна быть документирована и согласована процедура для присвоения числового значения, свойства или категории каждому атрибуту программного продукта. Процедуры измерений должны давать в результате одинаковые меры с приемлемой устойчивостью, получаемые различными субъектами при выполнении одних и тех же измерений характеристик ПС в различных случаях.

Характеристики, субхарактеристики и атрибуты качества ПС с позиции возможности и точности их измерения можно разделить на три уровня детализации показателей, особенности которых следует уточнять при их выборе:

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

К первому уровню относятся показатели качества, которые характеризуются наибольшим разнообразием значений - свойств программ и наборов данных и охватывают весь спектр классов, назначений и функций современных ПС. Эти свойства можно сравнивать только в пределах однотипных ПС и трудно упорядочивать по принципу предпочтительности. Среди стандартизированных показателей качества к этой группе, прежде всего, относится Функциональная пригодность, являющаяся самой важной и доминирующей характеристикой любых ПС. Номенклатура и значения всех остальных показателей качества непосредственно определяются требуемыми функциями программного средства и, в той или иной степени, влияют на выполнение этих функций. Поэтому выбор функциональной пригодности ПС, подробное и корректное описание ее свойств являются основными исходными данными для установления при системном проектировании требуемых значений всех остальных стандартизированных показателей качества.

Ко второму уровню показателей качества относятся достаточно достоверно и объективно измеряемые численные характеристики ПС. Значения этих характеристик обычно в наибольшей степени влияют на функциональную пригодность и метрики в использовании ПС. Поэтому выбор и обоснование их требуемых значений должно проводиться наиболее аккуратно и достоверно уже при проектировании ПС. Их субхарактеристики могут быть описаны упорядоченными шкалами объективно измеряемых значений, требуемые численные величины которых могут быть установлены и выбраны заказчиками или пользователями ПС. Такими характеристиками являются надежность и эффективность комплексов программ. Надежность может отражаться временем наработки на отказ, средним временем восстановления, а также коэффициентом готовности – вероятностью застать ПС в работоспособном состоянии при нормальной эксплуатации. Эти величины могут выбираться и фиксироваться в техническом задании или спецификации требований, и сопровождаться методикой объективных, численных измерений при квалификационных испытаниях для сопоставления с требованиями.

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

Третий уровень стандартизированных показателей качества ПС трудно полностью описать измеряемыми количественными значениями и их некоторые субхарактеристики и атрибуты имеют описательный, качественный вид. В зависимости от функционального назначения ПС по согласованию с заказчиком можно определять экспертно степень необходимости (приоритет) этих свойств и бальные значения уровня реализации их атрибутов в жизненном цикле конкретного ПС. Например, не всегда может требоваться мобильность программ на иные операционные и аппаратные платформы. В других случаях мобильность можно оценивать категориями: отличная, хорошая, удовлетворительная или неудовлетворительная. Такие оценки могут проводиться экспертно на основе анализа возможной трудоемкости и длительности, реализации процессов переноса комплекса программ на новую платформу.

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

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

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

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

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

Введение строгих количественных метрик в программирование должно было способствовать решению ряда практических задач:

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

По мере роста актуальности программных метрик на рынке стали появляться различные "измерительные" программы. Одни из них исследовали характеристики проектов и ПО комплексно, другие ориентировались на вполне конкретные цели: анализ исходного кода, размеров и структуры отдельных модулей.

Документирование и сертификация.

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

3.1 Сертификация.

Сертификация — процедура, выполняемая третьей стороной, независимой от изготовителя (продавца) и потребителя продукции или услуг, по подтверждению соответствия этих продукции или услуг установленным требованиям. Результатом выполнения процедуры сертификации является так называемый сертификат соответствия. Сертификат соответствия — документ, выданный по правилам системы сертификации для подтверждения соответствия сертифицированной продукции установленным требованиям. Общие правовые основы сертификации продукции и услуг в Российской Федерации установлены Законом "О сертификации продукции и услуг", где определены права и ответственность в области сертификации органов государственного управления, а также изготовителей (продавцов, исполнителей) и других участников сертификации.

В этом Законе, в частности, указано, что сертификация проводится в целях:

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

Сертификация средств и систем информатизации является элементом общей системы сертификации продукции в Российской Федерации.

Основными целями сертификации средств информатизации, информационных технологий и услуг являются:

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

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

Говоря о сертификации, нельзя не отметить ее тесную взаимосвязь со стандартизацией в сфере информатизации.

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

Во-вторых, собственно процедура сертификации регламентируется действующими нормативными документами (стандартами).

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

нормативные документы на объекты сертификации, где устанавливаются характеристики объектов, подтверждаемые при сертификации;
нормативные документы на методы испытаний для оценки характеристик объектов сертификации;
нормативные документы, регламентирующие процедуры сертификации.

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

Основные понятия и термины в области сертификации

Система сертификации - система, располагающая собственными правилами процедуры и управления для проведения сертификации.

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

Испытательная лаборатория - лаборатория (центр), который проводит испытания в процессе сертификации.

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

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

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

В Законе "О сертификации продукции и услуг" определены два вида сертификации: обязательная и добровольная. Обязательной сертификации подлежит продукция, включенная в перечни, определяемые соответствующими нормативными документами.

Организационная структура системы сертификации в России включает: государственный (национальный) орган по сертификации, ведомственные органы по управлению сертификацией продукции определенных классов, а также испытательные центры (лаборатории). Основными функциями государственного органа по сертификации являются организация, координация, научно-методическое, информационное и нормативно-техническое обеспечение работ по испытаниям и сертификации, а также аккредитация центров сертификационных испытаний в соответствии с полномочиями национального органа по сертификации. Ведомственные органы сертификации выполняют те же функции в ограниченном объеме для конкретных видов продукции.

Национальным органом по сертификации продукции в Российской Федерации является Госстандарт России, который осуществляет следующие функции:

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

Основой сертификации продукции в Российской Федерации является Система сертификации ГОСТ Р Госстандарта России. Этой системой, в частности, определяются правила создания и регистрации ведомственных систем сертификации для конкретных классов продукции.

В соответствии с действующими законодательными и нормативными документами сертификация средств информатизации проводится в Российской Федерации в следующих основных направлениях:

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

Обязательная сертификация по требованиям электромагнитной совместимости и параметрам безопасности

В соответствии с действующими законодательными и нормативными документами выполнение работ по сертификации средств информатизации в данном направлении возложено на Госстандарт России. В 1994 году Госстандарт России ввел в действие нормативный документ "Номенклатура продукции и услуг, подлежащих обязательной сертификации в Российской Федерации". Этот документ ежегодно пересматривается и уточняется с учетом практики, условий торговли, производства и тенденций научно-технического развития.

Указанным документом к продукции, подлежащей обязательной сертификации в рассматриваемом направлении, отнесены следующие средства информатизации:

вычислительные машины и комплексы;
персональные ЭВМ;
устройства внешней памяти, ввода-вывода и отображения информации;
устройства подготовки и телеобработки данных.

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

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

Сертификация средств информатизации по требованиям электромагнитной совместимости и параметрам безопасности возложена на Госстандарт России и проводится органами (центрами) сертификации, аккредитованными Госстандартом в рамках Системы сертификации ГОСТ Р.

Вы, вероятно, не раз встречали в рекламных объявлениях по продаже компьютеров фразу "Товар сертифицирован". Иногда в рекламе указывается и регистрационный номер сертификата соответствия, например, "Сертификат соответствия № РОСС RU.ME67.B00373". Речь в этих случаях идет именно о сертификации по требованиям электромагнитной совместимости и параметрам безопасности.

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

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

Это объясняется тем, что данный сертификат соответствия практически не затрагивает функциональных характеристик объекта и соответствия их современным требованиям. Такой сертификат дает вам только определенную уверенность в том, что предлагаемое оборудование не создает недопустимого уровня помех и безопасно в эксплуатации. Сертификация средств информатизации по функциональным характеристикам будет рассмотрена нами в следующих разделах.

3.2 Обязательная сертификация средств защиты информации

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

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

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

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

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

Целями защиты информации упомянутый Закон определяет:

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

• предотвращение угроз безопасности личности, общества, государства;

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

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

Необходимость сертификации средств защиты, применяемых при обработке информации, составляющей государственную тайну, закреплены в Законе Российской Федерации "О государственной тайне". Сертификации подлежат защищенные технические, программно-технические, программные средства, системы, сети вычислительной техники и связи, средства защиты и средства контроля эффективности защиты. Обязательной сертификации подлежат средства, в том числе и иностранного производства, предназначенные для обработки информации с ограниченным доступом, и прежде всего составляющей государственную тайну, а также использующиеся в управлении экологически опасными объектами, вооружением и военной техникой и средства их защиты. Наличие у владельца информационной системы сертифицированных средств обработки информации является гарантией надежности ее защиты и дает ему преимущества при осуществлении страхования.

Порядок сертификации средств защиты информации в Российской Федерации и ее учреждениях за рубежом установлен Положением "О сертификации средств защиты информации", утвержденным Постановлением Правительства Российской Федерации от 26 июня 1995 года № 608. Это Положение определяет области деятельности и сферу компетенции различных государственных органов при сертификации средств защиты информации. Основной объем работ по сертификации средств защиты информации в пределах Российской Федерации возлагается на Гостехкомиссию России и Федеральное агентство правительственной связи и информации (ФАПСИ). Координация работ по организации сертификации этой продукции возложена на Межведомственную комиссию по защите государственной тайны.

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

Непосредственное подчинение Президенту Российской Федерации обеспечивает независимость Гостехкомиссии России от региональных, ведомственных и корпоративных влияний, гарантирует соответствие ее деятельности высшим государственным интересам. Гостехкомиссия России - коллегиальный орган. В ее состав входят министры, председатели государственных комитетов, первые заместители (заместители) этих руководителей. Решения Гостехкомиссии России являются обязательными для исполнения всеми органами государственного управления, предприятиями, организациями и учреждениями независимо от их организационно-правовой формы и формы собственности, которые по роду своей деятельности обладают информацией, составляющей государственную или служебную тайну.

Директивными документами, в частности Положением "О сертификации средств защиты информации" установлено, что:

В ведении Гостехкомиссии России находится сертификация программных и технических средств защиты информации, не использующих методы криптографии (шифрования), а в ведении ФАПСИ - сертификация средств защиты информации, использующих эти методы.

В соответствии с установленным распределением сфер деятельности Гостехкомиссии России и ФАПСИ в Российской Федерации созданы и функционируют две системы сертификации средств защиты информации:

"Система сертификации средств защиты информации по требованиям безопасности информации", разработанная Гостехкомиссией России и зарегистрированная Госстандартом за № РОСС RU.OOOI.OIBHOO;
"Система сертификации средств криптографической защиты информации (СКЗИ)", разработанная ФАПСИ и зарегистрированная Госстандартом за № РОСС RU.OOO 1.030001.

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

3.2 Добровольная сертификация по функциональным параметрам

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

Добровольная сертификация проводится для удостоверения качества средств и систем информатизации с целью повышения их конкурентоспособности, расширения сферы использования и получения дополнительных экономических преимуществ.

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

В соответствии с действующим законодательством добровольная сертификация средств информатизации может проводиться в Системе сертификации ГОСТ Р, так и в других системах сертификации, зарегистрированных Госстандартом России в установленном порядке.

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

3.4 Единая система программной документации. Содержание и сфера применения

Единая система программной документации (ЕСПД) — отечественный комплекс стандартов на программную документацию. В профессиональном просторечии его еще называют «девятнадцатым гостом», что не совсем правильно, поскольку речь идет не об одном, а примерно о 30 разных нормативно-технических документах.

В основном стандарты ЕСПД содержат требования к составу, содержанию и оформлению документов, описывающих программу на разных стадиях ее жизненного цикла. Кроме того, несколько документов посвящено порядку хранения и обновления документации.

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

Стандарты ЕСПД были приняты в конце 70-х годов и дошли до нас в виде, близком к первоначальному. В них отражена практика работы ведомственных вычислительных центров, где эксплуатировались большие ЭВМ. Взаимодействие человека с компьютерной системой тогда было построено совсем не так, как теперь, и осуществлялось через громоздкие пульты, перфокарты и распечатки, а для «простых смертных», решающих прикладные задачи, еще и при посредничестве квалифицированного персонала. Надо ли долго объяснять, насколько эти стандарты к настоящему времени устарели? Достаточно сказать, что им неведомы такие распространенные сегодня документы, как руководство пользователя и руководство администратора.

И все-таки ими продолжают активно пользоваться. Формально «девятнадцатому» есть современная альтернатива. Переведены на русский язык и приняты в России на правах национальных некоторые стандарты ИСО/МЭК в области системной и программной инженерии. Но крупные, в том числе, государственные заказчики переходить на них не торопятся. Это можно объяснить их косностью (или верностью традиции, как вам больше нравится), но лишь отчасти.

Дело в том, каждый стандарт ЕСПД при небольшом (страницы три максимум) объеме представляет собой набор довольно формальных и поэтому легко проверяемых требований к документу или к комплекту документации. Строго говоря, это не мешает разработчику документации писать правильно оформленные глупости. Но поскольку ЕСПД четко определяет, из чего должен состоять и как должен выглядеть результат, мы можем, по крайней мере, сразу отклонить пачку бумаги, которая в эти рамки не вписывается. Что существенно упрощает задачу сдачи-приемки документации как для заказчика, так и для исполнителя.

Стандарты ИСО/МЭК, напротив, содержат много разумных правил содержательного характера, но сложно представить себе процедуру их формальной проверки. Впрочем, никто не мешает применять оба ряда стандартов одновременно, благо, они касаются разных аспектов документирования и друг другу практически не противоречат.

Состав нормативно-технических документов

Обозначение	Наименование
ГОСТ 19.001-77	Единая система программной документации. Общие положения
ГОСТ 19.002-80	Единая система программной документации. Схемы алгоритмов и программ. Правила выполнения
ГОСТ 19.004-80	Единая система программной документации. Термины и определения
ГОСТ 19.005-85	Единая система программной документации. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения
ГОСТ 19.101-77	Единая система программной документации. Виды программ и программных документов
ГОСТ 19.102-77	Единая система программной документации. Стадии разработки
ГОСТ 19.103-77	Единая система программной документации. Обозначение программ и программных документов
ГОСТ 19.104-78	Единая система программной документации. Основные надписи
ГОСТ 19 105-78	Единая система программной документации. Общие требования к программным документам
ГОСТ 19.106-78	Единая система программной документации. Требования к программным документам, выполненным печатным способом
ГОСТ 19.201-78	Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.202-78	Единая система программной документации. Спецификация. Требования к содержанию и оформлению
ГОСТ 19.301-79	Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению
ГОСТ 19.401-78	Единая система программной документации. Текст программы. Требования к содержанию и оформлению
ГОСТ 19.402-78	Единая система программной документации. Описание программы
ГОСТ 19 403-79	Единая система программной документации. Ведомость держателей подлинников
ГОСТ 19.404-79	Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению
ГОСТ 19.501-78	Единая система программной документации. Формуляр. Требования к содержанию и оформлению
ГОСТ 19.502-78	Единая система программной документации. Описание применения. Требования к содержанию и оформлению
ГОСТ 19.503-79	Единая система программной документации. Руководство системного программиста. Требования к содержанию и оформлению
ГОСТ 19.504-79	Единая система программной документации. Руководство программиста. Требования к содержанию и оформлению
ГОСТ 19.505-79	Единая система программной документации. Руководство оператора. Требования к содержанию и оформлению
ГОСТ 19.506-79	Единая система программной документации. Описание языка. Требования к содержанию и оформлению
ГОСТ 19.507-79	Единая система программной документации. Ведомость эксплуатационных документов
ГОСТ 19.508-79	Единая система программной документации. Руководство по техническому обслуживанию. Требования к содержанию и оформлению
ГОСТ 19.601-78	Единая система программной документации. Общие правила дублирования, учета и хранения
ГОСТ 19.602-78	Единая система программной документации. Правила дублирования, учета и хранения программных документов, выполненных печатным способом
ГОСТ 19.603-78	Единая система программной документации. Общие правила внесения изменений
ГОСТ 19.604-78	Единая система программной документации. Правила внесения изменений в программные документы, выполненные печатным способом

По теме: методические разработки, презентации и конспекты

Мне нравится

Навигация

Домашнее задание для ПО 3.11 по документирование и сертификация от 23.10.20
учебно-методический материал

Скачать:

Предварительный просмотр:

По теме: методические разработки, презентации и конспекты

Домашнее задание для ПО 3.11 по Документирование и сертификация от 21.10.20

Домашнее задание для ПО 3.11 по документирование и сертификация от 22.10.20

Домашнее задание для ПО 3.11 по документированию и сертификации от 11.11.20

Домашнее задание для ПО 3.11 по Документирование и сертификация от 17.11.20

Домашнее задание для ПО 3.11 по Документирование и сертификация от 18.11.20

Домашнее задание для ПО 3.11 по документирование и сертификация от 19.11.20

Домашнее задание для ПО 3.11 по документирование и сертификация от 20.11.20

Навигация

Домашнее задание для ПО 3.11 по документирование и сертификация от 23.10.20учебно-методический материал

Скачать:

Предварительный просмотр:

По теме: методические разработки, презентации и конспекты

Домашнее задание для ПО 3.11 по Документирование и сертификация от 21.10.20

Домашнее задание для ПО 3.11 по документирование и сертификация от 22.10.20

Домашнее задание для ПО 3.11 по документированию и сертификации от 11.11.20

Домашнее задание для ПО 3.11 по Документирование и сертификация от 17.11.20

Домашнее задание для ПО 3.11 по Документирование и сертификация от 18.11.20

Домашнее задание для ПО 3.11 по документирование и сертификация от 19.11.20

Домашнее задание для ПО 3.11 по документирование и сертификация от 20.11.20

Домашнее задание для ПО 3.11 по документирование и сертификация от 23.10.20
учебно-методический материал