Стандатризация программных средств

РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ ПРОГРАММНЫХ СРЕДСТВ

И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Курс лекций

2006 г.

ВВЕДЕНИЕ

ТЕМА 1. РОЛЬ СТАНДАРТИЗАЦИИ, СЕРТИФИКАЦИИ И ЛИЦЕНЗИРОВАНИЯ В ПРОЦЕССЕ ИНФОРМАТИЗАЦИИ

ЛЕКЦИЯ 1. Сущность процесса информатизации и основные положения государственной политики в сфере информатизации

ЛЕКЦИЯ 2. Информатизация России. Рынок программных средств

ЛЕКЦИЯ 3. Основные задачи стандартизации, сертификации и лицензирования в сфере информатизации

ЛЕКЦИИ 4-6. Состояние и перспективы стандартизации информационных технологий в Российской Федерации

ЛЕКЦИЯ 7. Сертификация средств информатизации в Российской Федерации. Основные понятия и термины в области сертификации

ЛЕКЦИЯ 8. Лицензирование деятельности в сфере информатизации

ТЕМА 2. РАЗРАБОТКА ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

ЛЕКЦИЯ 9. Программная инженерия как совокупность инженерных методов и средств создания программного обеспечения

ЛЕКЦИЯ 10. Жизненный цикл программного обеспечения

ЛЕКЦИЯ 11. Модели и стадии ЖЦ ПО

ЛЕКЦИЯ 12. Понятие метода и технологии проектирования ПО

ЛЕКЦИЯ 13. Сущность структурного подхода. Методы документирования ПО

ЛЕКЦИЯ 14. Моделирование потоков данных (процессов)

ЛЕКЦИЯ 15. Моделирование данных

ТЕМА 3. КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ

ЛЕКЦИЯ 16. Основные понятия качества программных средств

ЛЕКЦИЯ 17. Ресурсы для жизненного цикла сложных программных средств

ЛЕКЦИЯ 18. Стандарты, регламентирующие качество программных средств

ЛЕКЦИЯ 19. Характеристики качества баз данных

ЛЕКЦИЯ 20. Модели оценки характеристик качества и надежности ПО

ЗАКЛЮЧЕНИЕ

БИБЛИОГРАФИЯ

ПРИЛОЖЕНИЕ

О стандарте пользовательского интерфейса для диалоговых ИТ

ВВЕДЕНИЕ

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

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

• наше умение строить программы отстает от требований к новым программам.

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

Тема 1. РОЛЬ СТАНДАРТИЗАЦИИ, СЕРТИФИКАЦИИ И ЛИЦЕНЗИРОВАНИЯ В ПРОЦЕССЕ ИНФОРМАТИЗАЦИИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• обеспечение условий для развития и защиты всех форм собственности на информационные ресурсы;

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

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

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

• содействие формированию рынка информацион­ных ресурсов, услуг, информационных систем, тех­нологий, средств их обеспечения;

• формирование и осуществление единой науч­но-технической и промышленной политики в сфере информатизации с учетом современного мирового уровня развития информационных техно­логий;

• поддержка проектов и программ информатиза­ции;

• создание и совершенствование системы привлече­ния инвестиций и механизма стимулирования разра­ботки и реализации проектов информатизации;

• развитие законодательства в сфере информаци­онных процессов, информатизации и защиты ин­формации.

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

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

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

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

• организационные структуры, обеспечивающие функционирование и развитие единого информационного пространства, в частности сбор, обработку, хранение, распространение, поиск и передачу информации;

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

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

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

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

• создание и поддержание необходимого для устойчивого развития общества уровня информа­ционного потенциала;

• повышение согласованности решений, прини­маемых федеральными органами государственной власти, органами власти субъектов Федерации и органами местного самоуправления;

• повышение уровня правосознания граждан путем предоставления им свободного доступа к правовым и нормативным документам, определяющим их права, обязанности и возможности;

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

• повышение деловой и общественной активности граждан путем предоставления равной с государ­ственными структурами возможности;

• интеграция с мировым информационным про­странством. Развитие информационной инфраструктуры России во многом определяется современным уровнем развития отечественной индустрии информатизации.

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

• создание отечественных современных информа­ционных технологий и развитие производства средств для их реализации;

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

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

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

Лекция 2. Информатизация России. Рынок программных средств

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

Во многом благодаря последовательной реализации рассмотренных в предыдущем разделе основных принци­пов государственной политики в сфере информатизации показатели развития информационной среды российского общества выглядят достойно, хотя по ряду из них Россия существенно уступает США и другим развитым странам.

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

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

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

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

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

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

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

• многопроцессорные ЭВМ с параллельной струк­турой;

• вычислительные системы на базе нейрокомпьютеров, транспьютеров и оптических ЭВМ;

• системы распознавания и синтеза речи, текста и изображений;

• системы искусственного интеллекта и виртуаль­ной реальности;

• информационно - телекоммуникационные системы;

• системы математического моделирования.

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

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

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

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

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

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

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

• обеспечение широкого, свободного доступа к ин­формационным ресурсам;

• обеспечение граждан общественно значимой и востребуемой информацией;

• подготовка человека к жизни и работе в гряду­щем информационном веке.

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

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

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

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

Лекция 3. Основные задачи стандарти­зации, сертификации и лицензи­рования в сфере информатизации

Стандартизация. Основные задачи работ по стандартиза­ции в сфере информатизации. Сертификация. Основными целями сертификации.

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

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

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

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

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

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

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

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

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

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

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

• качеством элементной базы средств информати­зации;

• их безопасностью;

• совместимостью с другими средствами;

• уровнем помех;

• степенью экологичности;

• функциональными характеристиками;

• устойчивостью к внешним воздействиям;

• надежностью;

• конструкцией;

• параметрами электропитания;

• соответствием принципам открытых систем.

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

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

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

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

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

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

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

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

Результатом выполнения процедуры сертифика­ции является так называемый сертификат соответ­ствия.

Сертификат соответствия — документ, выданный по правилам системы сертифи­кации для подтверждения соответствия сертифицированной продукции установленным требованиям.

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

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

• создания условий для деятельности предприятий, учреждений, организаций и предпринимателей на едином товарном рынке Российской Федерации, а также для участия в международном экономи­ческом, научно-техническом сотрудничестве и меж­дународной торговле;

• содействия потребителям в компетентном выборе продукции;

• защиты потребителя от недобросовестности изго­товителя (продавца, исполнителя);

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

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

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

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

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

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

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

• обеспечение условий для информационного вза­имодействия субъектов негосударственной принад­лежности с субъектами государственной принад­лежности;

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

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

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

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

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

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

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

• нормативные документы на методы испыта­ний для оценки характеристик объектов сертифи­кации;

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

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

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

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

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

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

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

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

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

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

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

Лекции 4-6. Состояние и перспективы стандартизации информационных техно­логий в Российской Федерации

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

Национальная стандартизация. Международная стандартизация. Международные органы стан­дартизации. Проблемы информационной совместимости. Основные направления работ по стандартизации в сфере инфор­матизации. Основные положения Государ­ственного профиля взаимосвязи открытых систем России (ГОСПРОФИЛЬ ВОС).

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

Стандарт. Международная организация по стан­дартизации (ИСО) приняла следующее определение:

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

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

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

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

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

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

В зависимости от масштабов работы по стандар­тизации она может быть национальной и междуна­родной.

Национальная стандартизация - это работа по стандартизации в масштабах одной страны.

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

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

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

Международный стандарт - стандарт, принятый международным органом, занимающимся стандартиза­цией.

Среди таких органов наиболее представительными являются Международная организация по стандартиза­ции (ИСО) и Международная электротехническая ко­миссия (МЭК). В них входят соответственно 90 и 43 страны.

Международная стандартизация в сфере информатизации

Международные органы стандартизации

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

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

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

Стандарты ИСО разрабатываются в несколько этапов. Исходный документ представляется в виде про­екта комитета - ПРК (Committee Draft - CD). В рам­ках технического комитета (ТК) ИСО ПРК проходит, как правило, несколько стадий обсуждения и голосова­ния, после чего документ приобретает статус проекта международного стандарта - ПМС (Draft International Standard - DIS). После одной или нескольких стадий обсуждения и голосования ПМС представляется в цент­ральный секретариат ИСО для утверждения в качестве международного стандарта (International Standard).

Задачи стандартизации в области информационной технологии в рамках ИСО решаются в рамках созданно­го в 1987 г. Совместного технического комитета - СТК1 "Информационные технологии", в сферу деятельности которого входит стандартизация в области микроэлек­троники, вычислительной техники, средств связи и пере­дачи данных, включая стандартизацию технологии и оборудования. Этими вопросами занимаются несколько подкомитетов (ПК) СТК1, в основном ПК6 "Передача данных и обмен информацией между системами", ПК21 "Взаимосвязь открытых систем, управление данными и открытая распределенная обработка", ПК2 "Наборы знаков и кодирование информации", ПК7 "Програм­мная инженерия", ПК 18 "Обработка документов и соот­ветствующие коммуникации", ПК22 "Языки програм­мирования, их среды и системные программные интер­фейсы", ПК24 "Машинная графика и обработка изоб­ражений", ПК25 "Взаимосвязь оборудования информа­ционных технологий", ПК29 "Кодирование аудио-, видео-, мультимедиа и гипермедиа информации" и ПКЗО "Открытый электронный обмен данными".

В общей сложности к концу 1997 г. силами пере­численных технических подкомитетов СТК1 разработа­но свыше 1000 международных стандартов и дополнений к ним.

Определенный вклад в стандартизацию некоторых аспектов вычислительных сетей вносит Международная электротехническая комиссия (МЭК), которая несет от­ветственность за стандартизацию в области электротех­ники, включая вопросы взаимосвязи и интерфейсов обо­рудования определенных видов. Стандарты МЭК изда­ются под названием "Публикации". Вопросы стандарти­зации в рассматриваемой области решаются в рамках нескольких технических комитетов МЭК. В частности, ТК83 "Оборудование информационных технологий", созданный в 1985 г., до 1987 г. занимался в МЭК стан­дартизацией некоторых аспектов локальных вычисли­тельных сетей (общие характеристики, классификация, руководство по планированию и установке и др.). В 1987 г. ТК83 вошел в состав ИСО/МЭК СТК1 в виде ПК83 с со­хранением своего названия и функций, а в 1989 г. его функции были переданы вновь образованному ПК25 СТК1.

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

До 28 февраля 1993 г. в состав МСЭ входили три комитета: Международный консультативный коми­тет по телеграфии и телефонии (МККТТ), Международный консультационный комитет по радиосвязи (МККР).

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

Ассоциация электронной промышленности (EIA), США, внесла заметный вклад в разработку и стандарти­зацию интерфейсов систем передачи данных. Стандарты EIA издаются под названием "Рекомендуемые стандар­ты" (Recommended Standards - RS).

Американский национальный институт по стандар­тизации (ANSI) разработал ряд стандартов по протоко­лам управления звеном данных, которые легли в основу многих стандартов ИСО.

Из фирменных разработок следует выделить доку­менты фирмы IBM по протоколам управления звеном данных и по концепции сетевой архитектуры системы SNA, которые стали фактически стандартами для промышленности средств передачи и обработки дан­ных и послужили основой международных стандартов ИСО.

Международная стандартизация и проблемы информационной совместимости

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

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

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

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

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

В конце 70-х годов Международная организация по стандартизации (ИСО) начала разработку общей базо­вой эталонной модели, которая затем получила статус международного стандарта ИСО 7498. В последующие годы к этому стандарту был разработан ряд дополнений, которые в 1993 г. вошли во второе расширенное издание ИСО/МЭК 7498-1.

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

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

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

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

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

Правительственные профили взаимосвязи открытых систем (Government Open Systems Interconnection Profi­le - GOSIP) возникли в результате появившихся потреб­ностей упростить и облегчить процесс ассимиляции тех­нологии ВОС в федеральных правительственных службах.

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

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

Сейчас в мире уже доступен широкий набор изде­лий, реализующих протоколы ВОС. Например, почти каждый основной разработчик компьютеров в США, в том числе фирма IBM, объявили о производстве совмес­тимых с GOSIP изделий.

Все протоколы, на которые ссылается GOSIP, облада­ют многими общими характеристиками. К ним относятся:

• широкая применимость (общее использование не только службами отдельной страны, но и на все­мирной основе);

• доступность (реализации либо уже существуют, либо появятся в ближайшее время);

• стабильность (протоколы технически "замороже­ны" и в предсказуемом будущем их изменений не предвидится);

• эффективность (протоколы могут удовлетворять общим потребностям федеральных служб).

В России работы по проблеме открытых систем ве­дутся рядом ведущих институтов Минсвязи России, Гос­стандарта России и Российской академии наук. Одним из результатов этих работ является создание Государствен­ного профиля взаимосвязи открытых систем - "ГОСПРОФИЛЬ ВОС России" основные положения кото­рого будут рассмотрены далее.

Национальная (государственная) стандартизация в сфере информатизации

Основные принципы организации работ по стандартизации в России

Работы по стандартизации в России осуществляют­ся на основе принятого в 1995 году Закона Российской Федерации "О стандартизации" и комплекса стандартов Государственной системы стандартизации.

К нормативным документам по стандартизации, действующим на территории Российской Федерации, от­носятся:

• государственные стандарты Российской Федера­ции;

• применяемые в установленном порядке междуна­родные (региональные) стандарты, правила, нормы и рекомендации по стандартизации;

• общероссийские классификаторы технико-экономической информации;

• стандарты отраслей;

• стандарты предприятий;

• стандарты научно-технических, инженерных об­ществ и других общественных объединений.

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

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

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

Вся практическая работа по координации стан­дартизации в сфере информатизации, разработке и согла­сованию с Госстандартом России проектов стандартов в сфере информатизации, а также вводу стандартов в действие после утверждения возложена на Минсвязи России.

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

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

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

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

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

Особого внимания требует расширение примене­ния международных стандартов. Так, по состоянию на 1998 год по различным направлениям информационных технологий и смежных областей (вычислительная техни­ка, системы связи и передачи данных, радиоэлектронные средства, открытые системы, программная инженерия и др.) в России действовали свыше 700 государственных стандартов, обеспечивающих применение в стране около 400 международных стандартов. Это составляет всего 25% от общего числа международных стандартов ИСО, МЭК, МККТ, МККР, актуальных для применения в данной области.

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

Направления 1-го приоритета

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

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

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

• Сервисы управления данными. Данное направление является перспективным в плане создания и развития отечественных систем распределенных баз данных и формирования национальных информационных ресур­сов федерального, регионального и местного уровней в структуре Единого информационного пространства России.

• Работа в сетях, и соответствующие соединения.

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

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

• Терминология. Это направление предполагает разработку терминологии для информационных техно­логий и связанных областей.

Направления 2-го приоритета

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

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

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

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

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

Направления 3-го приоритета

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

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

• Информационные технологии в охране здоровья.

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

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

Работы по стандартизации, проводимые Минсвязи России

Стандартизация элементов информационных технологий и компонентов информационной инфраструктуры

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

С 1993 г. по настоящее время подведомственные Минсвязи России предприятия разработали 171 ГОСТ Р, из которых 160 ГОСТ Р утверждены Госстандартом России.

В 1997 г. предприятиями Госкомсвязи России сов­местно со специалистами Российской академии наук и Госстандарта России разработана первая версия ГОС­ПРОФИЛЯ ВОС России, которая была рассмотрена и одобрена Коллегией Госкомсвязи России. Коллегия по­становила разработать вторую версию ГОСПРОФИЛЯ ВОС России и Программу стандартизации на 1999-2000 гг. Вторая версия ГОСПРОФИЛЯ ВОС России была разработана в 1998г.

Предприятия министерства совместно со специа­листами Госстандарта России и других ведомств опти­мизировали процесс стандартизации и разработали:

• Концепцию комплексной стандартизации в об­ласти информационных технологий;

• Программы комплексной стандартизации в об­ласти информатизации на период 1993-1995 гг., на период 1996-1998 гг. и на период 1999-2000 гг., содержащие соответственно 772, 980 и 1019 стан­дартов;

• Аннотированную базу данных международных стандартов в области информатизации;

• Полнотекстовую базу государственных стандар­тов России (ГОСТ Р), разработанных на базе меж­дународных стандартов. Выпущена на CD-ROM;

• Ежегодные государственные и отраслевые планы стандартизации в области информатизации;

• Сформировали информационный фонд государ­ственных и международных стандартов, их проек­тов (ПМС) и дополнений (на бумажных и магнит­ных носителях).

Предприятия Минсвязи России ведут работы по стандартизации в рамках Технического комитета "Информационные технологии" (ТК 22). При выполне­нии работ по проблеме "Открытые информационные си­стемы" в области стандартизации информационных тех­нологий предприятия министерства активно участвуют в работе международных форумов, конференций, всесо­юзных симпозиумов, семинаров, сессий и секций САНИ РАН, МИИТ, Российской академии Госслужбы, Мин­обороны и др.

Основные положения государ­ственного профиля взаимосвязи открытых систем россии (госпрофиль вос)

Одним из действенных элементов практической реализации государственной политики информатизации средствами стандартизации по предотвращению про­никновения на российский рынок несовместимых ин­формационных технологий и обеспечения выхода России в мировое информационное пространство является соз­дание Государственного профиля взаимосвязи открытых систем России (ГОСПРОФИЛЬ ВОС) в виде соответ­ствующего структурированного комплекса нормативных документов на основе базовых международных стандар­тов и международных стандартизованных профилей.

Государственный профиль взаимосвязи открытых систем России (ГОСПРОФИЛЬ ВОС, версии 1 и 2) был разработан Госкомсвязи России на основе анализа и систематизации более 500 базовых и функциональ­ных международных стандартов, "Правительствен­ных профилей взаимосвязи открытых систем" (GOSIP) различных стран и объединений, в первую очередь GOSIP США, с учетом особенностей состояния и по­требностей развития информатизации в Российской Федерации.

Объединенные в ГОСПРОФИЛЕ ВОС протоколы ВОС устраняют зависимость пользователей от отдель­ного поставщика при покупке новых сетевых изделий и услуг и содействуют взаимодействию в среде изделий раз­личных поставщиков.

Поскольку ГОСПРОФИЛЬ ВОС имеет дело с функциональными возможностями обмена данными, а не с конкретной конфигурацией, то на функциональные возможности ГОСПРОФИЛЯ ВОС не налагается ника­ких ограничений со стороны технических, программных средств или операционной системы. Это означает, что ГОСПРОФИЛЬ ВОС может быть применим ко всем ти­пам систем и во всех функциональных средах. Размеры системы не имеют значения для ГОСПРОФИЛЯ ВОС; не имеет значения также используемая коммуникационная среда.

ГОСПРОФИЛЬ ВОС обеспечивает две основные возможности.

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

Во-вторых, ГОСПРОФИЛЬ ВОС обеспечивает на­дежные услуги между оконечными пользователями, пользуясь которыми пользователи могут записать свои собственные прикладные программы.

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

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

Лекция 7. Сертификация средств информатизации в Российской Федерации. Обязательная сертификация. Добровольная сертификация. Основные понятия и термины в области сертификации

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

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

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

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

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

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

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

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

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

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

• организует ведение обязательной сертификации продукции по поручению органов законодательной или исполнительной власти;

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

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

• проводит аккредитацию испытательных центров (лабораторий) совместно с ведомственными орга­нами по сертификации и выдает аттестат аккреди­тации;

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

• регистрирует и аннулирует сертификаты соответ­ствия и сертификационные лицензии, рассматри­вает спорные вопросы, возникающие в процессе сертификации;

• организует периодическую публикацию инфор­мации по сертификации.

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

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

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

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

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

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

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

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

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

• вычислительные машины и комплексы;

• персональные ЭВМ;

• устройства внешней памяти, ввода-вывода и от­ображения информации;

• устройства подготовки и телеобработки данных.

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

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

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

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

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

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

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

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

Сертификация средств информатизации по функ­циональным характеристикам будет рассмотрена нами в следующих разделах.

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

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

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

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

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

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

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

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

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

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

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

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

• сохранение государственной тайны, конфиденци­альности документированной информации в соот­ветствии с законодательством;

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

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

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

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

Мы думаем, что на роли и общих задачах ФАПСИ здесь нет необходимости останавливаться подробно, по­скольку они, в допустимых пределах, достаточно широ­ко освещаются в печати. А вот название такого государ­ственного органа, как Гостехкомиссия России, некото­рым из наших читателей, возможно, незнакомо.

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

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

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

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

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

• "Система сертификации средств защиты инфор­мации по требованиям безопасности информа­ции", разработанная Гостехкомиссией России и зарегистрированная Госстандартом за № РОСС RU.OOOI.OIBHOO;

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

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

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

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

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

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

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

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

Лекция 8. Лицензирование деятельности в сфере информатизации

Общие принципы организа­ции работ по лицензированию деятельности в сфере информатизации в Российской Федерации

Предметные области лицензи­руемой деятельности. Виды деятельности в области защиты информации, подлежащих лицензированию ФАПСИ. Лицензирование деятельно­сти по международному информационному обмену.

Предметные области лицензируемой деятельности

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

Лицензирование должно ограничивать следующие виды деятельности:

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

• формирование информационных ресурсов на основе использования современных информацион­ных технологий;

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

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

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

Проблема лицензирования отдельных элементов деятельности в сфере информатизации поставлена в Законе "Об информации, информатизации и защите инфор­мации":

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

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

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

Указанными статьями установлено, что порядок лицензирования определяется законодательством Рос­сийской Федерации.

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

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

Лицензирование деятельности в области создания и применения информационных технологий

Для продукции серийного и массового производ­ства в области информатизации важное значение имеет Закон "О сертификации продукции и услуг". Он пред­усматривает лицензирование деятельности, связанной с маркированием продукции и услуг знаком соответствия этой продукции и услуг государственным стандартам. Этот Закон устанавливает обязательную регистрацию продукции и услуг в Государственном реестре продукции и услуг, а также обязанности Госстандарта России по установлению порядка лицензирования и ведения ука­занного Реестра.

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

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

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

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

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

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

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

Лицензирование деятельности в области формирования и ведения информационных ресурсов

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

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

Деятельность по международному информацион­ному обмену в части государственных информационных ресурсов, которые вывозятся за пределы Российской Фе­дерации, или документированной информации для пополнения государственных информационных ресурсов, которая ввозится на территорию Российской Федерации, подлежит лицензированию согласно Закону "Об участии в международном информационном обмене" (ст. 18), по­рядок лицензирования определяется "Положением о ли­цензировании деятельности по международному инфор­мационному обмену", утвержденным Постановлением Правительства РФ от 3 июня 1998 года № 564.

Лицензирование услуг по информационному обеспечению потребителей информационных ресурсов

Данные виды деятельности связаны с предоставле­нием информации пользователям в соответствии с их правовым статусом и с категориями информации по доступу.

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

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

Согласно статье 24 Конституции РФ сбор, хране­ние и распространение информации о частной жизни лица без его согласия не допускается. Принципиальным является то, что формируемые базы персональных дан­ных должны строго соответствовать целям сбора и ис­пользоваться исключительно в интересах конкретного лица при оказании ему услуг различного характера. Ли­цензирующий орган должен установить минимально не­обходимый для оказания услуг объем персональных данных, необходимость защиты информации, некоторые технологические аспекты ее сбора и актуализации, а также проконтролировать выполнение обязательств по целевому использованию информации персонального характера. В настоящее время в Госдуме РФ готовится законопроект "Об информации персонального характе­ра", принятие которого позволит установить порядок лицензирования данного вида услуг.

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

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

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

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

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

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

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

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

Обязательное государственное лицензирование деятельности в области защиты информации криптогра­фическими методами, а также в области выявления элек­тронных устройств перехвата информации в технических средствах и помещениях государственных структур вве­дено Постановлением Правительства РФ от 24 декабря 1994 года № 1418 "О лицензировании отдельных видов деятельности". Данное постановление распространяет механизм обязательного лицензирования на все виды деятельности в области криптографической защиты ин­формации, независимо от ее характера и степени секрет­ности, на все субъекты этой деятельности, независимо от их организационно-правовой формы, включая и физиче­ских лиц.

Указ Президента Российской Федерации от 3 апре­ля 1995 года № 334 "О мерах по соблюдению законности в области разработки, производства, реализации и экс­плуатации шифровальных средств, а также предоставле­ния услуг в области шифрования информации" запре­щает любую деятельность, связанную с разработкой, производством, реализацией и эксплуатацией шифро­вальных средств, предоставлением услуг в области шиф­рования информации, без лицензии ФАПСИ.

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

Сферы компетенции Гостехкомиссии России и ФАПСИ, а также практический механизм лицензирова­ния определены в "Положении о государственном лицен­зировании деятельности в области защиты информации", которое утверждено 27 апреля 1994 года совместным решением Гостехкомиссии России и ФАПСИ.

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

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

• Сертификация, сертификационные испытания защищенных технических средств обработки ин­формации (ТСОИ), технических средств защиты информации, технических средств контроля эффек­тивности мер защиты информации, защищенных программных средств обработки информации, про­граммных средств по требованиям безопасности, программных средств защиты информации, про­граммных средств контроля защищенности инфор­мации.

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

• Разработка, производство, реализация, монтаж, наладка, установка, ремонт, сервисное обслужива­ние защищенных ТСОИ, технических средств защи­ты информации, технических средств контроля эф­фективности мер защиты информации, защищен­ных программных средств обработки информации, программных средств защиты информации, про­граммных средств контроля защищенности инфор­мации.

• Проведение специсследований на побочные элек­тромагнитные излучения и наводки (ПЭМИН) ТСОИ.

• Проектирование объектов в защищенном испол­нении.

• Подготовка и переподготовка кадров в области защиты информации по видам деятельности, пере­численным в данном перечне.

Перечень видов деятельности в области защиты информации, подлежащих лицензированию ФАПСИ:

Деятельность названных выше организаций по ли­цензированию в области защиты информации осу­ществляется на основании следующих принципов:

• Соответствия действующим российским законо­дательным и нормативным актам.

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

• Дифференцированного подхода к отдельным ви­дам деятельности и средствам защиты.

• Наложения на лицензиата обязательств по вы­полнению требований Российского законодатель­ства и иных нормативных актов в области защиты информации.

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

• Четкой регламентации предоставляемых лицен­зиату прав и полномочий, а также механизма его взаимодействия с Гостехкомиссией и ФАПСИ.

• Централизации выдачи, учета, приостановления и отзыва лицензий и сертификатов.

• Доступности и открытости систем лицензирова­ния и сертификации в рамках вышеперечисленных принципов.

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

• выдачу лицензий - рассмотрение заявления на лицензирование, оформление и выдачу лицензий, переоформление лицензий;

• проведение специальной экспертизы заявителя;

•проведение аттестации руководителя предприя­тия или лиц, уполномоченных им для руководства лицензируемой деятельностью;

• проведение технической экспертизы изделий.

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

• Лицензирование в области защиты информации является обязательным. Здесь необходимо иметь в виду, что для занятия деятельностью в области защиты информации необходимо получение права на ее осуществле­ние. Конкретные виды деятельности вводятся в виде перечисления в соответствующих норма­тивных актах.

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

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

Лицензирование деятельности по международному информационному обмену

Согласно ст. 18 Закона "Об участии в международ­ном информационном обмене" одним из видов лицензи­рования в области связи и информатизации в Российской Федерации является лицензирование деятельности по международному информационному обмену.

Деятельность по международному информационно­му обмену включает:

• сбор, обработку, хранение и передачу информа­ции, а также использование документированной информации и информационных ресурсов при международном информационном обмене;

• создание документированной информации и ин­формационных продуктов для целей международ­ного информационного обмена;

• получение документированной информации, ин­формационных ресурсов, информационных про­дуктов;

• оказание информационных услуг.

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

Объектами международного информационного об­мена являются: документированная информация, ин­формационные ресурсы, информационные продукты, информационные услуги и средства международного информационного обмена.

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

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

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

Субъектами международного информационного об­мена могут являться:

• Российская Федерация;

• субъекты Российской Федерации;

• органы государственной власти и органы местно­го самоуправления;

• физические и юридические лица Российской Фе­дерации;

• физические и юридические лица иностранных го­сударств;

• лица без гражданства.

В соответствии с "Положением о лицензировании деятельности по международному информационному обмену", утвержденному Постановлением Правитель­ства РФ от 03 июля 1998 года № 564, федеральным орга­ном исполнительной власти, уполномоченным на ведение лицензионной деятельности по международному обмену федеральными информационными ресурсами и информаци­онными ресурсами, находящимися в совместном ведении Российской Федерации и субъектов Российской Федера­ции, определен Государственный комитет Российской Федерации по связи и информатизации (как мы уже от­мечали, его правопреемником являлся Государственный комитет Российской Федерации по телекоммуникациям, в настоящее время - Министерство Российской Федера­ции по связи и информатизации), а лицензирование деятелъности по международному информационному обмену информационными ресурсами субъектов Российской Фе­дерации уполномочены осуществлять органы исполни­тельной власти субъектов Российской Федерации.

Методическое обеспечение лицензирования дея­тельности по международному информационному обме­ну осуществляет Минсвязи России.

Порядок взаимодействия Минсвязи России с органа­ми исполнительной власти субъектов Российской Федера­ции включает:

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

• установление структуры записи "Сводного реест­ра выданных, зарегистрированных, приостано­вленных и аннулированных лицензий" и структуры номера лицензии, присваиваемого лицензионными органами субъектов Российской Федерации;

• организацию изготовления бланков лицензий и определение организации - изготовителя этих бланков;

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

• проведение анализа лицензионной деятельности и совместную разработку мер по ее совершенство­ванию.

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

Лицензионные органы субъектов Российской Феде­рации:

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

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

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

В соответствии с Законом "Об участии в междуна­родном информационном обмене" и во исполнение По­становления Правительства Российской Федерации от 03.06.98 № 564 "Об утверждении Положения о лицензи­ровании деятельности по международному информационному обмену" Минсвязи России разработало и внед­рило ряд нормативно-правовых документов, в том числе:

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

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

В соответствии с вышеуказанными Законом и по­становлением Правительства Российской Федерации мэром г. Москвы издано распоряжение "О лицензиро­вании деятельности по международному информацион­ному обмену" от 31 декабря 1998 года № 1331-РМ, в ко­тором ставятся конкретные задачи Московской лицен­зионной палате о проведении необходимых организаци­онных мероприятий по созданию (на уровне субъекта Российской Федерации) органа лицензирования деятель­ности по международному информационному обмену.

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

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

В настоящее время Федеральным унитарным госу­дарственным предприятием Московский научно-исследовательский центр реализуется проект "Разработка организационно-методического и про­граммно-аппаратного обеспечения системы лицензиро­вания в сфере информатизации".

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

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

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

• разработку Сборника организационно-мето­дических документов по организации и проведению лицензионной деятельности по международному информационному обмену для субъектов Россий­ской Федерации;

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

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

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

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

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

Автоматизированная система по ведению Сводного реестра создаст условия для повышения производитель­ности труда специалистов по лицензированию.

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

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

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

Тема 2. РАЗРАБОТКА ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Лекция 9. Программная инженерия как совокупность инженерных методов и средств создания программного обеспечения. Программная инженерия. Понятие модели архитектуры ПО. Особенности современных крупных проектов ЭИС

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

Основная доля трудозатрат при создании ИЭС приходится на прикладное программирование и базы данных. Производство ПО – это крупнейшая отрасль мировой экономики, в которой занято около трех млн. специалистов.

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

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

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

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

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

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

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

• Необходимость интеграции существующих и вновь разрабатываемых приложений.

• Функционирование в неоднородной среде на нескольких аппаратных платформах.

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

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

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

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

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

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

Лекция 10. Жизненный цикл программного обеспечения

Понятие ЖЦ ПО. Международный стандарт ISO/IEC 12207: 1995. Основные и вспомогательные процессы ЖЦ ПО. Организация процессов ЖЦ. Связь между процессами.

Понятие ЖЦ

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 “Information Technology - Software Life Cycle Processes” (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

В России существуют стандарты:

ГОСТ 34601 - 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

ГОСТ 34601 - 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

ГОСТ 34601 - 92. «Информационная технология. Виды испытаний автоматизированных систем».

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

В соответствии с ISO/IEC 12207: 1995 все процессы ЖЦ ПО разделены на три группы:

Основные процессы:

• приобретение;

• поставка;

• разработка;

• эксплуатация;

• сопровождение.

Вспомогательные процессы:

• документирование;

• управление конфигурацией;

• обеспечение качества;

• верификация;

• аттестация;

• совместная оценка;

• аудит;

• разрешение проблем.

Организационные процессы:

• управление;

• усовершенствование;

• создание инфраструктуры;

• обучение.

Основные процессы

Процесс приобретения состоит из действий и задач заказчика:

Действие - инициирование приобретения - включает задачи:

• определение заказчиком своих потребностей в приобретении;

• анализ требований к системе;

• принятие решения относительно приобретения;

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

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

Действие – подготовка заявочных предложений. Заявочные предложения должны содержать:

• требования к системе;

• перечень программных продуктов;

• условия и соглашения;

• технические ограничения (например, среда функционирования системы).

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

Действие - подготовка и корректировка договора - включает задачи:

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

• выбор конкретного поставщика на основе анализа предложений.;

• подготовку и заключение договора с поставщиком;

• внесение изменений (при необходимости) в договор в процессе его выполнения.

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

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

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

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

Планирование включает задачи:

• принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;

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

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

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

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

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

Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО:

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

• внешних интерфейсов;

• спецификаций надежности и безопасности;

• эргономических требований;

• требований к используемым данным;

• требований к установке и приемке;

• требований к пользовательской документации;

• требований к эксплуатации и сопровождению.

Требования к ПО оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании.

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

• трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав ее компонентов;

• разработку и документирование программных интерфейсов ПО и баз данных;

• разработку предварительной версии пользовательской документации;

• разработку и документирование предварительных требований к тестам и планам интеграции ПО.

Архитектура компонентов ПО должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.

Детальное проектирование ПО включает следующие задачи:

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

• разработку и документирование детального проекта базы данных;

• обновление (при необходимости) пользовательской документации;

• разработку и документирование требований к тестам и плана тестирования компонентов ПО;

• обновление плана интеграции ПО.

Кодирование и тестирование ПО охватывает задачи:

• разработку и документирование каждого компонента ПО и базы данных а также совокупности тестовых процедур и данных для их тестирования;

• тестирование каждого компонента ПО и базы данных на соответствие предъявляемых к ним требованиям. Результаты тестирования компонентов должны быть документированы;

• обновление (при необходимости) пользовательской документации;

• обновление плана интеграции ПО.

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

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

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

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

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

Процесс эксплуатации охватывает действия и задачи оператора – организации, эксплуатирующей систему и включает действия:

Подготовительная работа включает проведение оператором следующих задач:

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

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

Эксплуатационное тестирование осуществляется для каждой очередной редакции программного продукта, после чего она передается в эксплуатацию.

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

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

Процесс сопровождения предусматривает действия и задачи, выполняемые службой сопровождения. В соответствии со стандартом IEEE-90 под сопровождением понимается внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.

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

Процесс сопровождения охватывает следующие действия:

Подготовительная работа службы сопровождения включает в себя следующие задачи:

• планирование действий и работ, выполняемых в процессе сопровождения;

• определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения.

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

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

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

• утверждение выбранного варианта модификации.

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

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

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

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

Вспомогательные процессы ЖЦ ПО

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

Процесс документирования включает действия:

• подготовительную работу;

• проектирование и разработку;

• выпуск документации;

• сопровождение.

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

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ ПО. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/IEC 12207-2: 1995 “Information Technology - Software Life Cycle Processes. Part2. Configuration Management for Software”.

Процесс управления конфигурацией включает действия:

• подготовительную работу (планирование управления конфигурацией);

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

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

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

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

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

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

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

Процесс обеспечения качества включает действия:

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

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

• обеспечение качества процесса предполагает гарантирование соответствия процессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам;

• обеспечение прочих показателей качества системы осуществляется в соответствии с условиями договора и стандартом ISO 9001.

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

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

Процесс верификации включает следующие действия:

• подготовительную работу;

• верификацию;

В процесс верификации проверяются следующие условия:

• непротиворечивость требований к системе и степень учета потребностей пользователей;

• возможности поставщика выполнять заданные требования;

• соответствие выбранных процессов ЖЦ ПО условиям договора;

• адекватность стандартов, процедур и среды разработки процесса ЖЦ ПО;

• соответствие проектных спецификаций ПО заданным требованиям;

• корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики;

• соответствие кода проектным спецификациям и требованиям;

• тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

• корректность интеграции компонентов ПО в систему;

• адекватность, полнота и непротиворечивость документации.

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

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

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

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

Процесс совместной оценки включает действия:

• подготовительную работу;

• оценку управления проектом;

• техническую оценку.

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

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

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

Организационные процессы ЖЦ ПО

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

Процесс управления включает следующие действия:

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

• планирование подразумевает выполнение, как минимум, следующих задач:

• составление графиков выполнения работ;

• оценку затрат;

• выделение требуемых ресурсов;

• распределение ответственности;

• оценку рисков, связанных с конкретными задачами;

• создание инфраструктуры управления.

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

Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

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

Связь между процессами ЖЦ ПО

Процессы ЖЦ ПО, регламентированные стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (рис.1). Такими аспектами являются:

• договорный аспект;

• аспект управления;

• аспект эксплуатации;

• инженерный аспект;

• аспект поддержки.

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

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

Лекция 11. Модели и стадии ЖЦ ПО

Понятие модели ЖЦ ПО (каскадная, спиральная). Стадии: формирование требований к ПО; проектирование; реализация; тестирование; ввод в действие; эксплуатация и сопровождение; снятие с эксплуатации. Подход RAD. Модели качества процессов проектирования.

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

Международный стандарт ISO/IEC 12207: 1995 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО. Стандарт описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать и выполнить действия и задачи, включенные в эти процессы.

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

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

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

4. Тестирование.

5. Ввод в действие.

6. Эксплуатация и сопровождение.

7. Снятие с эксплуатации.

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

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

• определение целей разработки;

• предварительная экономическая оценка проекта;

• построение плана – графика выполнения работ;

• создание и обучение совместной рабочей группы.

Проведение обследования деятельности автоматизируемого объекта (организации), в рамках которого осуществляются:

• предварительное выявление требований к будущей системе;

• определение структуры организации;

• определение перечня целевых функций организации;

• анализ распределения функций по подразделениям и сотрудникам;

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

• анализ существующих средств автоматизации деятельности организации.

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

• модели “AS-IS” («как есть»), отражающей существующее на момент обследования положение дел в организации и позволяющее понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;

• модели “TO-BE” («как должно быть»), отражающей представление о новых технологиях работы организации.

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

Переход от модели “AS-IS” к модели “TO-BE” может выполняться двумя способами:

• совершенствованием существующих технологий на основе оценки их эффективности;

• радикальным изменением технологий и перепроектированием бизнес-процессов (реинжиниринг бизнес-процессов).

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

Стадия проектирования включает этапы:

Разработка системного проекта. На этом этапе дается ответ на вопрос: «Что должна делать будущая система?», а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели проектируемой ЭИС, которые строятся на основе модели “TO-BE” . Документальным результатом является техническое задание.

Разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: «Как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям?». Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня.

К настоящему времени наибольшее распространение получили следующие две модели ЖЦ ПО: каскадная (1970-1985) и спиральная (1986-1990).

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

Рис.1. Каскадная модель

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

Преимущества применения каскадного способа:

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

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

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

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

Рис. 2. Итерационный процесс создания программного обеспечения

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

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

• пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;

• за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

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

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

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

Как показано на рис. 3, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

1. Планирование — определение целей, вариантов и ограничений.

2. Анализ риска — анализ вариантов и распознавание/выбор риска.

3. Конструирование — разработка продукта следующего уровня.

4. Оценивание — оценка заказчиком текущих результатов конструирования.

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

Планирование Анализ риска

Рис. 3. Спиральная модель: 1 - начальный сбор требований и планирование проекта; 2 - та же работа, но на основе рекомендаций заказчика; 3 - анализ риска на основе начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход к комплексной системе; б - начальный макет системы; 7 - следующий уровень макета; 8 - сконструированная система; 9 - оценивание заказчиком.

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

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

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

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

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

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

• наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

• позволяет явно учитывать риск на каждом витке эволюции разработки;

• включает шаг системного подхода в итерационную структуру разработки;

• использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели:

• новизна (отсутствует достаточная статистика эффективности модели);

• повышенные требования к заказчику;

• трудности контроля и управления временем разработки.

Подход RAD

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

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

• короткого, но тщательного проработанного производственного графика (до 3 месяцев);

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

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

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

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

• определение функций, которые должна выполнять система;

• выделение наиболее приоритетных функций, требующих проработки в первую очередь;

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

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

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

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

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

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

• более детально рассматриваются процессы системы;

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

• устанавливаются требования разграничения доступа к данным;

• определяется состав необходимой документации.

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

• входной элемент приложения (входной документ или экранная форма);

• выходной элемент приложения (отчет, документ, экранная форма)

• запрос (пара «вопрос/ответ»);

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

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

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

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

• общая информационная модель системы;

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

• точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

• построенные прототипы экранных форм, отчетов, диалогов.

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

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

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

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

• Осуществляется анализ использования данных и определяется необходимость их распределения.

• Производится физическое проектирование базы данных

• Формируются требования к аппаратным ресурсам.

• Устанавливаются способы увеличения производительности.

• Завершается разработка документации проекта.

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

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

• разрабатывается совершенно новая система;

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

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

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

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

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

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

• Разработка приложений итерациями.

• Необязательность полного завершения работ на каждой стадии ЖЦ ПО.

• Обязательность вовлечения пользователей в процесс разработки ЭИС.

• Целесообразность применения CASE – средств, обеспечивающих целостность проекта и генерацию кода приложений.

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

• Использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей.

• Тестирование и развитие проекта, осуществляемые одновременно с разработкой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• предотвращения дефектов;

• управления изменениями технологии;

• управления изменениями процесса.

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

Лекция 12. Понятие метода и технологии проектирования ПО

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

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

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

• Концепций и теоретических основ. В качестве таких основ могут выступать структурный или объектно-ориентированный подход.

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

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

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

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

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

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

1. Соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех процессов ЖЦ ПО).

2. Гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время.

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

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

5. Независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования).

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

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

1. Стандарт проектирования.

2. Стандарт оформления проектной документации.

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

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

• Набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации.

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

• Требования к конфигурации рабочих мест разработчиков, включая настройки ОС, настройки CASE – средств и т.д.

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

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

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

• требования к оформлению документации (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.);

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

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

• требования к настройке CASE – средств для обеспечения подготовки документации в соответствии с установленными правилами.

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

• Правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления.

• Правила использования клавиатуры и мыши.

• Правила оформления текстов помощи.

• Перечень стандартных сообщений.

• Правила обработки реакций пользователя.

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

Лекция 13. Сущность структурного подхода. Методы документирования ПО

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

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

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

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

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

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

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

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

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

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

1. Принцип «разделяй и властвуй»;

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

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

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

2. Принцип непротиворечивости обоснованность и согласованность элементов системы.

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

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

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

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

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

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

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

2. Диаграммы, моделирующие данные и их отношения (ERD).

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

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

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

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

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

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

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

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

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

• Отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель).

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

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

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

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

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

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

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

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

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

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

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

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

Верхняя диаграмма является родительской для нижней диаграммы

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

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

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

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

Системные требования

Комментарии

Предварительная

Спецификация

Улучшенный проект

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

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

Каждый блок на диаграмме имеет свой номер. Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок А21 на диаграмме А2. Аналогично диаграмма А2 детализирует блок А2 на диаграмме А0, которая является самой верхней диаграммой модели. На рис. 12 показан пример дерева диаграмм.

З аконодательство Внутренние органы

Отчетность Отчетность

Налогоплательщиков вышестоящим

организациям

Отдел по работе с юридическими лицами

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

А0

Работа Государственной налоговой инспекции

А1 А2 А3

Работа Работа Работа

с физическими с юридическими вспомогательных

лицами лицами подразделениями

А11 А12 А13

Работа Работа Работа

по подоходному по налогу по налогу

налогу на имущество на землю

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

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

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

• случайная;

• логическая;

• временная;

• процедурная;

• коммуникационная;

• последовательная;

• функциональная.

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

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

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

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

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

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

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

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

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

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

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

Типы связей

Таблица 1

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

Лекция 14. Моделирование потоков данных (процессов). Состав диаграмм потоков данных. Построение иерархии потоков данных. Сравнительный анализ SADT- моделей и диаграмм потоков данных

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе.

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

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

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

Далее при построении будет использоваться нотация Гейна –Сэрсона.

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

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

Состав диаграмм потоков данных

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

• внешние сущности (рис.18);

• системы и подсистемы (рис.19);

• процессы (рис. 20);

• накопители данных (рис.21);

• потоки данных (рис.22).

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

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

Рис.18. Графическое изображение внешней сущности

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

Поле номера

Поле имени

Поле физической реализации

Рис.19. Изображение системы (подсистемы)

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

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

Поле номера

Поле имени

Поле физической организации

Рис.20. Графическое изображение процесса

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

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

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

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

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

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

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

1.5

Сформировать отчетность по подоходному налогу

Отдел отчетности

Отчетность по

подоходному

налогу

Рис. 22. Поток данных между процессом и внешней сущностью

Построение иерархии потоков данных

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

• Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

• Не загромождать диаграммы не существенными на данном уровне деталями.

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

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

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

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

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

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

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

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

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

• Правило нумерации – при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

Спецификация является конечной вершиной иерархии DFD . Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:

• Наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3).

• Возможности описания преобразования данных процессом в виде последовательного алгоритма.

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

• Возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

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

• Для каждого процесса нижнего уровня должна существовать одна и только одна спецификация.

• Спецификация должна определять способ преобразования входных потоков в выходные.

• Нет необходимости (по крайней мере на стадии формирования требований) определять метод реализации этого преобразования.

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

• Набор конструкций для построения спецификаций должен быть простым и понятным.

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

1. Номер и/или имя процесса.

2. Списки входных и выходных данных.

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

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

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

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

• глаголы, ориентированные на действие и применяемые к объектам;

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

• предлоги и союзы, используемые в логических отношениях;

• общеупотребительные математические, физические и технические термины;

• арифметические уравнения;

• таблицы, диаграммы, графы;

• комментарии.

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

При использовании структурированного естественного языка приняты следующие соглашения:

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

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

• логика процесса должна быть выражена четко и недвусмысленно.

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

Каждый объект должен состоять из элементов, являющихся его атрибутами. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение показывает, что данный компонент может отсутствовать в структуре (например, структура «данные о страховании» для объекта «служащий»). Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация предусматривает вхождение любого числа элементов в указанном диапазоне (например, элемент «имя ребенка» для объекта «служащий»).

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

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

Сравнительный анализ SADT-моделей и диаграмм

потоков данных

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

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

• диаграммы, моделирующие данные и их отношения (ERD).

Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в средствах функционального моделирования. С этой точки зрения все разновидности структурного анализа могут быть разбиты на две группы – использующие DFD (в различных нотациях) и использующие SADT - модели. Соотношение применения этих двух разновидностей структурного анализа в существующих CASE - средствах составляет 90% для DFD и 10% для SADT.

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

• Адекватность средств решаемым задачам;

• Согласованность с другими средствами структурного анализа;

• Интеграция с последующими стадиями ЖЦ ПО (прежде всего со стадией проектирования).

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

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

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

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

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

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

Функциональные модели, используемые на стадии проектирования

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

Так, например, для DFD переход от модели бизнес - процессов организации к модели системных процессов может происходить следующим образом:

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

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

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

• определяется и изображается на диаграмме тип связи между процессорами (например, локальная сеть - LAN);

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

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

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

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

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

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

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

• определяется верхняя форма (главная форма приложения), связывающая все формы с меню.

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

Лекция 15. Моделирование данных

Основные понятия. Метод Баркера. Подход, используемый в CASE - средстве SILVERRUN.

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

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

Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD), нотация которых впервые была введена Питером Ченом в 1976 г. Базовым понятием ERD являются:

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

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

• иметь уникальное имя;

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

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

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

Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь – это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе и нулевым) количеством экземпляров второй сущности, и наоборот.

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

Метод баркера

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

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

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

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

Первый шаг моделирования - извлечение информации из интервью и выделение сущностей.

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

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

Второй шаг моделирования – идентификация связей.

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

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

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

• продавец может получить вознаграждение за один контракт или более;

• контракт должен быть инициирован ровно одним продавцом.

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

Рис.24. Отображение связи «продавец – контракт»

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

Рис.25. Диаграмма «сущность-связь» без атрибутов

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

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

С учетом имеющейся информации дополним построенную ранее диаграмму (рис.26).

Рис.26. Диаграмма «сущность - связь с атрибутами»

Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных.

Супертипы и подтипы: одна сущность является обобщающим понятием для группы подобных сущностей.

Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих (рис.28).

Подход, используемый в case – средстве silverrun

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

Физическое лицо

Банковский счет

0,N 1,1

Рис.29. Обозначение сущностей и связей

В данном примере:

• физическое лицо может не иметь банковского счета (необязательная связь) либо иметь много счетов (степень связи N);

• каждый банковский счет может принадлежать одному (обязательная связь) и только одному физическому лицу (степень связи - 1).

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

Существуют следующие виды идентификаторов:

• Первичный/альтернативный: сущность может иметь несколько идентификаторов. Один должен являться основным (первичным), а другие – альтернативными. Первичный идентификатор на диаграмме подчеркивается. Альтернативные идентификаторы начинаются с символов <1> для первого альтернативного идентификатора, <2> - для второго и т.д. В реляционной модели, полученной из концептуальной модели данных, первичные ключи используются в качестве внешних ключей. Альтернативные идентификаторы не копируются в качестве внешних ключей в другие таблицы.

• Простой/составной: идентификатор, состоящий из одного атрибута, является простым, из нескольких атрибутов – составным (рис.31);

• Абсолютный / относительный: если все атрибуты, составляющие идентификатор, принадлежат сущности, то идентификатор является абсолютным. Если один или более атрибутов идентификатора принадлежат другой сущности, то идентификатор является относительным. Когда первичный идентификатор является относительным, сущность определяется как зависимая сущность, поскольку ее идентификатор зависит от другой сущности (рис.32). В примере на рисунке ниже идентификатор сущности Строка-заказа является относительным. Он включает идентификатор сущности ЗАКАЗ, что показано на рисунке подчеркиванием 1,1.

Рис.32. Относительный идентификатор

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

0,N 0,N

Рис. 33. Связь с атрибутами

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

В связи «супертип-подтип» общие атрибуты типа определяются в сущности- супертипе, сущность-подтип наследует все атрибуты супертипа (рис. 34). Экземпляр подтипа существует только при условии существования определенного экземпляра супертипа. Подтип не может иметь идентификатора (он импортирует его из супертипа).

Рис. 34. Связь «супертип-подтип»

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

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

ТЕМА 3. КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ

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

Лекция 16. Основные понятия качества программных средств

Системы качества. Качество функционирования. Качество в использовании. Основные факторы качества.

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

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

• практическая необходимость методов количественной оценки характеристик качества продукции для решения задач их планирования и контроля на различных уровнях управления созданием и применением;

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

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

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

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

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

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

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

Разнообразие областей применения компьютеров становится все шире

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

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

Потребителя-заказчика, прежде всего, интересуют функции и качество

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

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

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

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

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

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

• готового программного продукта с полным комплектом адекватной эксплуатационной документации.

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

Основой для формирования требований к ПС является анализ свойств,

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

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

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

• проблемно-ориентированной областью применения, техническим и социальным назначением программного комплекса;

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

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

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

• степенью связи решаемых задач с реальным масштабом времени или допустимой длительностью ожидания результатов решения задачи;

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

• предполагаемым тиражом производства и применения комплекса программ;

• степенью необходимой документированности программ.

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

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

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

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

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

• метрики, меры и шкалы, выбранных и пригодных для измерения и оценивания конкретных характеристик и атрибутов качества ПС с учетом определенной достоверности;

• уровни возможной детализации при описании и оценивании определенных характеристик и атрибутов качества ПС;

• цели и особенности потребителей результатов оценивания характеристик качества ПС;

• внешние и внутренние, негативные факторы, влияющие на достигаемое качество создания и применения ПС;

• доступные ресурсы, ограничивающие возможные величины реальных характеристик качества ПС;

• конкурентоспособность, выраженная отношением эффективности применения к стоимости приобретения и эксплуатации ПС.

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

на две принципиально различающихся группы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако для заказчика и разработчика перед заключением контракта необходим достаточно достоверный системный анализ, прогнозированием

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

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

Многие молодые программисты - "художники" лихо утверждают, что

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

Ориентирами для оценивания необходимых ресурсов трудоемкости, длительности и числа специалистов по крупным этапам работ, при создании сложных ПС высокого качества, могут служить данные, опубликованные в [5,6]. В табл. 1 представлен вариант, относительного распределения затрат ресурсов по этапам работ для сложных встроенных ПС реального времени, который можно использовать как базу для приближенных оценок. Соотношение затрат по этапам в процентах достаточно инвариантно для различных по объему и сложности проектов и для ориентировочных оценок может быть пересчитано в реальные значения с учетом размера ПС, доступных ресурсов и средней производительности труда в фирме.

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

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

Табл. 2.

Этапы жизненного цикла	Относительная трудоемкость этапа работ (%)	Относительная длительность этапа работ (%)	Относительное число специалистов на этапе (%)
1. Анализ требований к программам и планирование	8	22	25
2. Архитектурное проектирование программного средства	16	22	40
3. Детальное проектирование программного средства	26	18	60
4. Кодирование и тестирование программных компонентов	28	18	100
5. Интеграция, квалификационное тестирование и испытания программного средства	22	20	70

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

Вследствие этого в широких пределах могут изменяться трудоемкость

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

Лекция 18. Стандарты, регламентирующие качество программных средств

Стандарт 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. Качество в использовании - это объединенный эффект функциональных и конструктивных характеристик качества ПС для пользователей. Связь качества в использовании с другими характеристиками ПС зависит от задач и функций их потребителей:

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

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

• для персонала сопровождения ПС качество в использовании определяется преимущественно сопровождаемостью;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• определять корреляцию отдельных характеристик программного кода с качеством готовой системы;

• контролировать стадии развития проекта;

• анализировать явные и скрытые дефекты;

• на основе экспериментального сравнения выявлять лучшие методы и технологии.

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

Лекция 19. Характеристики качества баз данных

Функциональные и конструктивные характеристики качества

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

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

• программные средства системы управления базой данных (СУБД), независимые от сферы их применения, структуры и смыслового содержания накапливаемых и обрабатываемых данных;

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

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

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

• технологией и средствами автоматизации разработки и обеспечения всего ЖЦ каждого объекта;

• категориями специалистов, обеспечивающих: создание, эксплуатацию или применение компонентов БД;

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

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

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

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

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

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

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

• полнотой накопленных описаний объектов – относительным числом объектов или документов, имеющихся в БД, к общему числу объектов по данной тематике или по отношению к числу объектов в аналогичных БД того же назначения;

• идентичностью данных - относительным числом описаний объектов, не содержащих дефекты и ошибки, к общему числу документов об объектах в ИБД;

• актуальностью данных - относительным числом устаревших данных об объектах в ИБД к общему числу накопленных и обрабатываемых данных.

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

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

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

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

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

• глубина ретроспективы - максимальный интервал времени от даты выпуска и/или записи в базу данных самого раннего документа до настоящего времени;

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

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

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

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

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

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

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

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

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

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

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

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

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

Простота использования ИБД - возможность удобно и комфортно ее

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

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

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

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

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

• форматная совместимость характеризуется степенью соответствия данных в ИБД анализируемых платформ требованиям стандартов на форматы представления данных для документальных, фактографических, словарных и иных БД;

• лингвистическая совместимость определяется степенью использования в рассматриваемых ИБД единых лингвистических

средств (классификаторов, рубрикаторов, словарей), формализованных соответствующими стандартами этих платформ;

• физическая совместимость заключается в степени соответствия кодировки информации БД одинаковым стандартам на машиночитаемые носители информации.

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

Лекция 20. Модели оценки характеристик качества ПО

Размерно-ориентированные метрики. Функционально-ориентированные метрики. Пример применения метрик. Достоинства и недостатки размерно – ориентированных и функционально-ориентированных метрик.

Размерно-ориентированные метрики

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC – оценках (Lines Of Code). LOC - оценка – это количество строк в программном продукте.

Исходные данные для расчета этих метрик сводятся в таблицу (табл.3).

Табл. 3.Исходные данные для расчета LOC- метрик

Проект	Затраты, чел.-мес.	Стоимость тыс. $	КLOC, тыс. LOC	Страниц	Ошибки	Количество человек
А01	24	168	12,1	365	29	3
В02	62	440	27,2	1224	86	5
С03	43	314	20,2	1050	64	6

Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте А01 показывает: 12100 строк программы были разработаны за 24 чел.-мес. И стоили $168 000. Кроме того, по проекту было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект три человека.

На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества проекта:

Производительность = Длина / Затраты (тыс.LOC/чел.-мес.);

Качество = Ошибки / Длина (Единиц/тыс. LOC);

Удельная стоимость = Стоимость /Длина (тыс.$/LOC);

Документированность = Страниц_Документа / Длина (Страниц/тыс.LOC)

Достоинства размерно-ориентированных метрик:

• широко распространены;

• просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

• зависимы от языка программирования;

• требуют исходных данных, которые трудно получить на начальной стадии проекта;

• не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики

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

Используется 5 информационных характеристик.

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

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

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

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

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

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

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

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

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

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

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

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

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

Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла.

Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП).

Табл.4. Примеры элементов данных

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

Табл.5. Правила учета элементов данных из ГИП

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

Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).

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

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

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

Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл.6-10 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4.

Табл.6. Ранг и оценка сложности внешних вводов

Ссылки на файлы	Элементы данных
1-4	5-15	>15
0-1	Низкий (3)	Низкий (3)	Средний (4)
2	Низкий (3)	Средний (4)	Высокий (6)
>2	Средний (4)	Высокий (6)	Высокий (6)

Табл.7. Ранг и оценка сложности внешних выводов

Ссылки на файлы	Элементы данных
1-4	5-19	>19
0-1	Низкий (4)	Низкий (4)	Средний (5)
2-3	Низкий (4)	Средний (5)	Высокий (7)
>3	Средний (5)	Высокий (7)	Высокий (7)

Табл.8. Ранг и оценка сложности внешних запросов

Ссылки на файлы	Элементы данных
1-4	5-19	>19
0-1	Низкий (3)	Низкий (3)	Средний (4)
2-3	Низкий (3)	Средний (4)	Высокий (6)
>3	Средний (4)	Высокий (6)	Высокий (6)

Табл.9. Ранг и оценка сложности внутренних логических файлов

Ссылки на файлы	Элементы данных
1-19	20-50	>50
0-1	Низкий (7)	Низкий (7)	Средний (10)
2-5	Низкий (7)	Средний (10)	Высокий (15)
>5	Средний (10)	Высокий (15)	Высокий (15)

Табл.10. Ранг и оценка сложности внешних интерфейсных файлов

Ссылки на файлы	Элементы данных
1-19	20-50	>50
0-1	Низкий (5)	Низкий (5)	Средний (7)
2-5	Низкий (5)	Средний (7)	Высокий (10)
>5	Средний (7)	Высокий (10)	Высокий (10)

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

После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (Function Points). Автором этой метрики является А. Альбрехт (1979).

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

Табл.11. Исходные данные для расчета FP – метрик

Имя характеристики	Ранг, сложность, количество
Низкий	Средний	Высокий	Итого
Внешние вводы	*3=_	*4=_	*6=_	=
Внешние выводы	*4=_	*5=_	*7=_	=
Внешние запросы	*3=_	*4=_	*6=_	=
Внутренние логические файлы	*7=_	*10=_	*15=_	=
Внешние интерфейсные файлы	*5=_	*7=_	*10=_	=
Общее количество	=

Количество функциональных указателей вычисляется по формуле:

FP= Общее количество*(0,65+0,01*F_>i>), (1)

Где F_>i> – коэффициент регулировки сложности (I=1..14).

Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.12).

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

Производительность = ФункцУказатель / Затраты (FP/чел.-мес.);

Качество = Ошибки / ФункцУказатель (Единиц/FP);

Удельная Стоимость = Стоимость / ФункцУказатель (Тыс.$/FP);

Документированность=СтраницДокумента/ФункцУказатель (Страниц/FP)

Табл.12. Определение системных параметров приложения

№	Системный параметр	Описание
1	Передачи данных	Сколько средств данных требуется для пердачи или обмена информацией с приложением или системой?
2	Распределенная обработка данных	Как обрабатываются распределенные данные и функции обработки?
3	Производительность	Нуждается ли пользователь в фиксации времени ответа или производительности?
4	Распространенность используемой конфигурации	Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение?
5	Скорость транзакций	Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)?
6	Оперативный ввод данных	Какой процент информации нужно вводить в режиме онлайн?
7	Эффективность работы конечного пользователя	Приложение проектировалось для обеспечения эффективной работы конечного пользователя?
8	Оперативное обновление	Как много внутренних файлов обновляется в онлайновой транзакции?
9	Сложность обработки	Выполняет ли приложение интенсивную логическую или математическую обработку?
10	Повторная используемость	Приложение разрабатывалось для удовлетворения требований одного или многих пользователей?
11	Легкость инсталляции	Насколько трудны преобразования и инсталляция приложения?
12	Легкость эксплуатации	Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления?
13	Разнообразные условия размещения	Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций?
14	Простота изменений	Была ли спроектирована, разработана и поддержана в приложении простота изменения?

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

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

Табл.13. Исходные данные для расчета указателя свойств

№	Характеристика	Количество	Сложность	Итого
1	Вводы		*4	=
2	Выводы		*5	=
3	Запросы		*4	=
4	Логические файлы		*7	=
5	Интерфейсные файлы		*7	=
6	Количество алгоритмов		*3	=
Общее количество	=

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

Достоинства функционально-ориентированных метрик:

• не зависят от языка программирования;

• Легко вычисляются на любой стадии проекта.

Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

FP – оценки легко пересчитать в LOC – оценки. Как показано в табл.14, результаты пересчета зависят от языка программирования, используемого для реализации ПО.

Табл.14. Пересчет FP – оценок в LOC – оценки

Язык программирования	Количество операторов на 1 FP
Ассемблер	320
С	128
Паскаль	90
С++	64
Java	53
Visual Basic	32
Visual С++	34
Delphi Pascal	29
HTML 3	15
LISP	64
Prolog	64

ЗАКЛЮЧЕНИЕ

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

БИБЛИОГРАФИЯ

1. А.М. Вендров. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: «Финансы и статистика». 2000. - 339 с.

2. А.М. Вендров. Практикум по проектированию программного обеспечения экомических информационных систем. М.: «Финансы и статистика». 2002. -190 с.

3. Практические аспекты информатизации. Стандартизация, сертификация и лицензирование. Справочная книга руководителя. Под редакцией Л.Д. Реймана. М.: 2000. -259с.

4. В.В. Липаев. Качество программных средств. Методические рекомендации. М.: «Янус-К». 2002. – 298с.

5. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ./Под ред. А.А. Красилова. М.:Радио и связь, 1985.

6. В.В. Липаев, А.И. Потапов. Оценка затрат на разработку программных средств. М.: Финансы и статистика. 1988.

7. С.А. Орлов. Технологии разработки программного обеспечения. Учебник для вузов. М., Санкт-Петербург: «Питер». 2002.

8. Г. Коллинз, Дж. Блей. Структурные методы разработки систем: от стратегического планирования до тестирования. М.: «Статистика», 1980. 260с.:ил.

9. ГОСТ Р ИСО 9127 – 94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов».

10. ГОСТ 34601 – 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

11. ГОСТ 34601 – 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

12. ГОСТ 34601 – 92. «Информационная технология. Виды испытаний автоматизированных систем».

13. Информационные системы в экономике. Под ред. Проф. В.В. Дика. Учебник для вузов, М., «Финансы и статистика». 1996. – 270 с.

ПРИЛОЖЕНИЕ

О СТАНДАРТЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ДЛЯ ДИАЛОГОВЫХ ИТ

Стандарт фирмы IBM. Проектирование пользовательского интерфейса на персональном компьютере.- Вильнюс, 1992

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

Пользовательский интерфейс включает в себя три понятия: общение приложения с пользователем, общение пользователя с приложением, язык общения. Язык общение определяется разработчиком программного приложения. Свойствами интерфейса являются наглядность и конкретность. Наиболее распространенный ранее командный интерфейс имел ряд недостатков (многочисленность команд, отсутствие стандарта для приложения), что ограничивало круг его применения. Для преодоления этих недостатков были предприняты попытки его упростить (например, NC). Однако настоящим решением проблемы стало создание графической оболочки для ОС. В настоящее время практически все распространенные ОС используют для своей работы графический интерфейс. Примером здесь может служить интерфейс, разработанный в исследовательском центре Пало Альто фирмы Xerox для компьютеров Macintosh фирмы Apple. Немного позже была разработана графическая оболочка под названием Microsoft Windows, реализующая технологию WIMP и удовлетворяющая стандарту CUA. Новшеством были применение мыши, выбор команд из меню, предоставление программам отдельных окон, использование для обозначения программ образов в виде пиктограмм.

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

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

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

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

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

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

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

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

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

Путь, по которому движется диалог, называется навигацией. Он может быть изображен в виде графа, где узлы - действия, дуги - переходы. Диалог состоит из двух частей: запросов на обработку информации и навигации по приложению. Часть запросов на обработку и навигацию является унифицированной. Унифицированные действия диалога – это действия, имеющий одинаковый смысл во всех приложениях. Некоторые унифицированные действия могут быть запрошены из выпадающего меню посредством действия “команда” функциональной клавишей. К унифицированным действиям диалога относятся: "отказ", “команда”, “ввод”, “выход”, “подсказка”, “регенерация”, “извлечение”, “идентификаторы”, “клавиши”, “справка” (см. прил.3).

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

Стандарт фирмы IBM. Элементы экрана

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

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

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

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

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

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

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

Заголовок поля обозначает поле выбора, поле ввода поле переменной информации.

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

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

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

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

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

В поле однозначного выбора пользователь должен выбрать только один объект. Если на панели несколько полей выбора, то пользователь явно указывает поле выбора.

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

В поле расширенного выбора пользователь выбирает объект, и к нему во всплывающем или вторичном окне дается пояснение (расширение). Если в первоначальном состоянии имеется один объект, то это поле рассматривается как поле однозначного выбора, а если есть несколько объектов, то многозначного.

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

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

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

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

Рекомендуемая палитра:

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

Стандарт фирмы IBM. Унифицированные действия диалога

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

Действие “ввод” включается, если панель содержит поле ввода или более одного поля выбора (многозначный выбор).

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

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

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

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

Общая справка. Обеспечивает общую справку о панели, из которой она затребована.

Описание клавиш. Должен быть представлен список используемых функциональных клавиш с их функциями.

Указатель. Содержит перечень имеющихся в приложении справок в алфавитном порядке. Тот же список отображается при выборе клавиши “указатель” в панели “справка”.

Учебная справка. Предусматривается в режиме приложения и должна быть последней в выпадающем меню “Справка”.

“Справка” должна быть включена во все панели и меню действий. Если меню отсутствует, то справка появляется в области функциональных клавиш.

“Подсказка” сообщает пользователю, как завершить работу с полем ввода. Для получения подсказок пользователь устанавливает курсор выбора в то поле ввода, список допустимых значений которого должен быть высвечен. По действию “подсказка” появляется всплывающее меню с панели типа меню. Меню может содержать поля однозначного и многозначного выбора. После выбора одного или нескольких объектов всплывающее окно исчезает, а выбранные объекты копируются в поле ввода, как если бы пользователь выбрал эти значения на клавиатуре. Если пользователь выбрал несколько объектов поля многозначного выбора, то порядок их следования определяется приложением. Пользователь должен иметь возможность отказаться от выбора объекта в всплывающем окне подсказки. Отказ не влияет на поле ввода. Если пользователь запрашивает подсказку, не установив курсор выбора в поле ввода, никакого действия не происходит. Если курсор выбора установлен в поле ввода и пользователь просит подсказку, а приложение не предусматривает ее, то выдается звуковой сигнал и во всплывающем окне или в области сообщений этой панели появляется сообщение, что приложение не поддерживает эту подсказку.

“Подсказка” включается, когда панель содержит поле ввода, и зависит от позиции курсора. Во всплывающем окне высвечивается одно или несколько значений, которые могут быть выбраны пользователем для заполнения поля ввода.

“Регенерация” зависит от типа панели, из которой запрашивается это действие. В панели ввода восстанавливается исходное состояние панели без учета того, что было набрано пользователем с момента последнего заполнения или обработки этой панели. В панели, отражающей текущее состояние объектов, повторно выводится содержимое панели с учетом всех изменений объектов, которые появились с момента последнего отображения этой панели. Если панель позволяет ввести информацию, то “регенерация” выполняется, как в панели ввода. Действие “регенерация” рекомендуется включать в панели, содержащие поля выбора и ввода.

Действие “Клавиши” изменяет представление области функциональных клавиш в нижней части выпадающего меню. По умолчанию появляется длинная форма представления, по запросу – краткая. При повторном запросе краткая форма исчезает и появляется длинная и т.д.

Посредством действия “Идентификатор” пользователь запрашивает включение или выключение идентификатора панели.