Конспект лекций
 Скачать 489 Kb.
|
|
1.2 Развитие рынка в программных средств в России. Критические информационные, компьютерные и телекоммуникационные технологии. Информационные ресурсы России являются громадным по объему, стоимости и сложности комплексом, включающим несколько миллионов баз данных, электронных информационных массивов библиотечных и архивных фондов. В последнее время быстро растет количество российских сайтов в Интернете, ежегодно их число удваивается. Однако нельзя не отметить, что по показателю доступности информационных ресурсов наша страна отстает от развитых стран. Сегодня в большинстве крупных городов России эффективно функционируют провайдеры — организации, обеспечивающие пользователям доступ в Интернет. Широко используется бесплатное (некоммерческое) обслуживание пользователей. Быстро расширяется и рынок сетевой коммерческой информации (сведения о компаниях, товарных рынках, рынке ценных бумаг, объектах инвестиций). Это означает серьезный шаг по пути к информационной экономике. Бурному развитию процессов информатизации и, соответственно, отечественных территориальных компьютерных сетей и информационных систем различного рода в первой половине 90-х годов в значительной мере способствовало как ускорение развития инфраструктуры связи, так и определенное насыщение страны персональными компьютерами. В настоящее время отечественные сетевые структуры (при отставании на 1-2 года) развиваются в направлениях, по которым идут США, Великобритания, Германия, Франция. Разумеется, развитие ИС требует постоянного совершенствования научно-технической и технологической базы этого развития. Эту базу составляют прежде всего критические информационные, компьютерные и телекоммуникационные технологии. Термин "критические" технологии применительно к информации означает, что именно их уровень и масштабы применения определяют эффективность достижения главных целей информатизации. К этим технологиям прежде всего следует отнести: многопроцессорные ЭВМ с параллельной структурой; вычислительные системы на базе нейрокомпьютеров, транспьютеров и оптических ЭВМ; системы распознавания и синтеза речи, текста и изображений; системы искусственного интеллекта и виртуальной реальности; информационно - телекоммуникационные системы; системы математического моделирования. В ближайшем будущем важнейшими задачами политики информатизации будут селективная государственная поддержка приоритетных технологий, в том числе фундаментальных и прикладных научных исследований, стимулирование использования конкурентоспособных отечественных технологий в различных финансируемых из госбюджета проектах и программах. Что касается российского информационного рынка, то его главная отличительная черта состоит в его неоднородности по регионам страны. Это связано, естественно, с географическим положением регионов, неравномерностью их социально-экономического развития, направленностью экономической деятельности и т. д. Развитие рынка по традиции идет от центра к регионам. Кроме того, слабость правового регулирования рынка также накладывает серьезные ограничения на его развитие. Необходимо отметить развитие сферы домашнего потребления компьютеров, которая быстро растет, и в ближайшие годы количество домашних компьютеров может составить до половины всего парка ПК, что вызовет резкое повышение спроса на информационные продукты и услуги (до 60—70% в общем объеме продаж). Российская культурная среда оказывает непосредственное воздействие на процессы информатизации. Имеется ряд благоприятных для этого развития социально-демографических характеристик, в частности высокий процент городских жителей. Другой важный индикатор — высокий процент молодых, 15—16-летних людей, активных, способных и желающих осваивать компьютерный мир. Однако сегодня работают и тормозящие факторы: неразвитые информационные потребности населения и неготовность общества жить в условиях открытого общества. Политика информатизации должна быть ориентирована и на решение главных задач информационной политики: обеспечение широкого, свободного доступа к информационным ресурсам; обеспечение граждан общественно значимой и востребованной информацией; подготовка человека к жизни и работе в грядущем информационном веке. 1.3 Стандартизация Определение термина "стандартизация" прошло длительный эволюционный путь. Представление людей о стандартизации формировалось в процессе развития науки и техники, совершенствования форм и методов производства. С расширением экономических связей на национальном и международном уровнях уточнение этого термина происходило параллельно с развитием самой стандартизации и отражало на различных этапах достигнутый уровень ее развития. В документах Международной организации по стандартизации (ИСО) термин стандартизация определяется следующим образом: Стандартизация - деятельность, заключающаяся в нахождении решений для повторяющихся задач в сферах науки, техники и экономики, направленная на достижения оптимальной степени упорядочения в определенной области. В общем, эта деятельность проявляется в процессах разработки, опубликования и применения стандартов. Это определение отражает все многообразие стандартизации, характеризует ее как активную деятельность, направленную на упорядочение не только в технике, но и в других областях, предусматривает обязательное участие в ней всех заинтересованных сторон, подчеркивает, что стандартизация - это не механический отбор устоявшихся характеристик, а выбор или разработка наиболее оптимальных решений, рассчитанных не только на сегодняшний уровень науки и техники, но и учитывающих тенденции и направления технического прогресса. Важный результат стандартизации — улучшение соответствия продукции или услуг их функциональному назначению. Стандартизация увязывает технические нормы и требования к взаимообмениваемой продукции, гарантирует ее технический уровень, надежность, долговечность и качество, создает необходимые предпосылки для углубления и расширения специализации и кооперирования производства, активно воздействует на экономию всех видов природных, материальных и энергетических ресурсов, а также приводит к постепенному выравниванию уровней технических норм и требований в национальных стандартах и доведению их до высших мировых научно-технических образцов. В дальнейшем, говоря о стандартизации и сертификации, мы будем использовать также понятие совместимость, которое определяется следующим образом: Совместимость - пригодность изделий или их систем к совместному использованию при определенных условиях для выполнения соответствующих требований, которая не вызывает при этом нежелательных последствий. Правовые основы стандартизации, обязательные для всех государственных органов управления, объектов хозяйственной деятельности и общественных объединений Российской Федерации, определены Законом "О стандартизации", принятым в 1993 году. Общее руководство работами по стандартизации в Российской Федерации возложено на Госстандарт России. Возрастание роли информатизации, расширение областей применения средств информатизации и повышение ответственности решаемых с их помощью задач обусловливают в настоящее время резкое повышение требований к качеству систем и средств информатизации. Качество средств и систем информатизации сегодня определяется: качеством элементной базы средств информатизации; их безопасностью; совместимостью с другими средствами; уровнем помех; степенью экологичности; функциональными характеристиками; устойчивостью к внешним воздействиям; надежностью; конструкцией; параметрами электропитания; соответствием принципам открытых систем. Основной задачей работ по стандартизации в сфере информатизации является создание нормативной базы, отражающей современный научно-технический уровень и тенденции развития средств и систем информатизации. Применительно к информатизации стандартизация заключается в определении требований к средствам, системам, процессам и др., излагаемым в соответствующим образом утвержденных документах (стандартах), обязательных для применения в установленной для них области действия. По мере развития информационной индустрии и совершенствования рыночных механизмов в России информационные системы, их компоненты и результаты их функционирования все в большей степени (по объемам и номенклатуре) становятся товарными продуктами. В результате для потребителя становится все более актуальной проблема определения соответствия средств и систем информатизации установленным требованиям. Действительно, в стране может быть принято много замечательных стандартов, но как вы в качестве потребителя сможете убедиться, что продукция или услуга действительно им соответствуют? Решению этой проблемы призваны способствовать процессы сертификации продукции и услуг, к рассмотрению которых мы и переходим. 1.4 Лицензирование Основным отличием процесса лицензирования от процесса сертификации является состав категорий, по отношению к которым они применяются. В процессе лицензирования фигурируют такие категории, как "деятельность" (подразумеваются виды или направления деятельности) и "субъект" (физическое лицо, предприятие, организация или иное юридическое лицо). В соответствии с действующим законодательством в Российской Федерации отдельные виды деятельности осуществляются предприятиями, организациями и учреждениями независимо от организационно-правовой формы, а также физическими лицами, осуществляющими предпринимательскую деятельность без образования юридического лица, на основании лицензии — специального разрешения органов, уполномоченных на ведение лицензирования. Лицензия является официальным документом, который разрешает осуществление указанного в нем вида деятельности в течение установленного срока, а также определяет условия его осуществления. Основу нормативно-правовой базы лицензирования в сфере информатизации составляют Законы "О лицензировании отдельных видов деятельности", "Об информации, информатизации и защите информации" и "Об участии в международном информационном обмене". Общие принципы лицензирования видов деятельности в сфере информатизации России можно сформулировать следующим образом: Целью лицензирования является защита интересов государства и граждан от неумышленного или сознательного некачественного выполнения работ, соответствующих определенным видам деятельности в сфере информатизации. Виды деятельности в сфере информатизации, подлежащие лицензированию, а также органы, осуществляющие лицензирование конкретных видов деятельности в различных областях информатизации, определены рядом нормативных документов. Право на осуществление деятельности, подлежащей лицензированию, может получить субъект, отвечающий определенным критериям, которые заранее определяются правилами проведения лицензирования и являющимися их неотъемлемой частью требованиями к предприятию-заявителю. Таким образом, субъектом лицензирования становится лишь то физическое или юридическое лицо, которое представляет все необходимые и правильно оформленные документы и удовлетворяет соответствующим требованиям. За органом, уполномоченным на проведение лицензионной деятельности, закрепляется право на осуществление контроля за деятельностью лицензиата. Существует несколько типов лицензий на программные продукты. Исключительная лицензия — продажа всех имущественных прав на программный продукт или базу данных, покупателю лицензии предоставляется исключительное право на их использование, а автор или владелец патента отказывается от самостоятельного их применения или предоставления другим лицам. Это самый дорогой вид лицензии, к нему прибегают для монопольного владения с целью извлечения дополнительной прибыли либо с целью прекращения существования на рынке программных средств программного продукта. Простая лицензия — лицензиар предоставляет право лицензиату использовать программный продукт или базу данных, оставляя за собой право применять их и предоставлять на аналогичных условиях неограниченному числу лиц (лицензиат при этом не может сам выдавать сублицензии, может лишь продать копии приобретенного программного продукта или базы данных). Такой вид лицензии приобретают дилер (торговец) либо фирмы-производители, использующие купленные лицензии как сопутствующий товар к основному виду деятельности. Например, многие производители и фирмы, торгующие компьютерной техникой, осуществляют продажу вычислительной техники с установленным лицензионным программным обеспечением (операционная система, текстовый редактор, электронная таблица, графические пакеты и т.д.). Этикеточная лицензия — лицензия на одну копию программного продукта или базы данных. Данный тип лицензии применяется при розничной продаже. Каждый официальный покупатель заключает лицензионное соглашение с продавцом на их использование, но при этом сохраняется авторское право разработчика. 1.6 Жизненный цикл программного продукта. Программный продукт любого вида характеризуется жизненным циклом, состоящим из отдельных этапов (рис.1):  Рис.1 Жизненный цикл программного продукта. Маркетинг предназначен для изучения требований к создаваемому программному продукту (технических, программных, пользовательских). Изучаются также существующие аналоги и продукты-конкуренты. Оцениваются необходимые для разработки материальные, трудовые и финансовые ресурсы, а также устанавливаются примерные сроки разработки. Проектирование структуры — алгоритмизация процесса обработки данных, детализация функций, разработка архитектурного проекта, выбор методов и средств создания программ. Программирование, тестирование и отладка — основной этап работы по разработке программного средства. Часто отдельные работы этого этапа ведутся параллельно, что позволяет сократить общее время разработки. Документирование — обязательный вид работы. Документация должна содержать необходимые сведения по установке, обеспечению надёжной работы продукта, справочное пособие для пользователя, демонстрационные версии, примеры документов, создаваемых при помощи данного программного продукта, обучающие программы. Выход программного продукта на рынок связан с организацией продаж массовому пользователю. Здесь применяются стандартные методы — реклама, увеличение числа каналов реализации, создание дилерской и дистрибьюторской сети, гибкая ценовая политика. Эксплуатация и сопровождение идут, как правило, параллельно. В процессе эксплуатации могут выявляться ошибки, и устранение этих ошибок ведётся в режиме сопровождения, то есть оказание сервисной помощи, обеспечение новыми версиями программ, организация «горячих телефонных линий» для консультаций. Снятие программного продукта с продажи и отказ от его сопровождения происходит, как правило, в случае изменения технической политики фирмы-изготовителя, неэффективности работы программного продукта, наличия в нём неустранимых ошибок, отсутствие спроса. Длительность жизненного цикла разных программных продуктов неодинакова. Для большинства современных программ его длительность составляет 2-3 года. Хотя часто встречаются на компьютерах и давно снятые с производства программные продукты. Исторически, в ходе эволюционного развития теории проектирования программного обеспечения и по мере его усложнения, сложились три основные модели жизненного цикла. Эти модели выражают последовательность этапов ЖЦ ПО. До 80-х годов имела место каскадная модель ЖЦ (рис.2) подразумевавшая переход на последующие этапы ЖЦ только после полного окончания работ на предыдущих этапах.  Рис.2 Каскадная модель жизненного цикла С развитием вычислительной техники, в середине 80-х, сложность и объемы программного обеспечения существенно возросли. В связи с этим возникли проблемы с разработкой и отладкой ПО. Продумать все шаги разработки нового ПО, наметить этапы проектирования и предусмотреть все варианты поведения при отладке программного обеспечения стало не под силу одному разработчику. Каскадная модель ЖЦ стала существенно сдерживать темпы создания сложных программных систем. Процесс отладки, при этом, затягивался и не давал гарантий безошибочной работы программ. На смену каскадной модели, жестко регламентирующей последовательность этапов и критерии переходов между ними, пришла поэтапная модель с промежуточным контролем (рис. 3).  Рис.3 Поэтапная модель с промежуточным контролем Это итерационная модель разработки ПО с обратными связями между этапами. Проверки и корректировки разрабатываемого ПО проводится на каждом из этапов, что позволяет существенно снизить трудоемкость отладки по сравнению с каскадной моделью. Итерационность модели проявляется в обработке ошибок выявленных промежуточным контролем. Если на каком-либо из этапов в ходе промежуточной проверки обнаружилась ошибка, допущенная на более ранней стадии разработки, работы этапа, повлекшего ошибку, необходимо провести повторно. При этом, анализируются причины ошибки и корректируются, по необходимости, исходные данные этапа или перечень проводимых работ. Аналогичная ситуация возникает если в ходе разработки ПО возникают новые требования заказчика или изменяются какие-либо условия функционирования ПО. Спиральная модель (рис. 4) поддерживает итерации поэтапной модели, но особое внимание уделяется начальным этапам проектирования: анализу требований, проектированию спецификаций, предварительному проектированию и детальному проектированию. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии ПО, уточняются цели и требования к ПО, оценивается качество разработанного фрагмента или версии ПО и планируются работы следующего витка. Таким образом, углубляются и конкретизируются все детали проектируемого ПО, и в результате получается вариант, который удовлетворяет всем требованиям заказчика.  Рис.4 Спиральная модель Количество, состав и последовательность этапов ЖЦ для каждого конкретного ПО определяется на ранних стадиях планирования создания ПО. При этом учитываются особенности эксплуатации, наличие разного рода ограничений, численность и квалификация персонала разработчиков и эксплуатационников, а также множество других факторов. Как было отмечено выше, жизненные циклы систем, процессов их разработки, эксплуатации и сопровождения регламентированы в стандартах. При этом стандарты, разрабатываемые международными организациями в той или иной области деятельности, носят рекомендательный характер и не возведены в ранг закона. Руководящие принципы, определенные в стандартах, имеют официальную силу тогда, когда приняты правительством той или иной страны. В настоящее время общепризнанными международными лидерами в области стандартизации разработки ПО стали следующие организации: Американский национальный институт по стандартизации - ANSI; Международная организация по стандартизации - ISO; Министерство обороны США - DOD, Институт инженеров по электронике и радиотехнике (IEEE). Основная цель управления ЖЦ программных продуктов (ПП) состоит в обеспечении заданных сроков разработки с учетом имеющихся людских, материальных и финансовых ресурсов. В рамках поставленной цели управления нужно решить задачу оптимизации структуры ЖЦ как по продолжительности отдельных фаз цикла, так и по затратам различных видов ресурсов по фазам. К задачам управления ЖЦ ПП относят: планирование; регулирование; рациональное использование трудовых и финансовых ресурсов; учет затрат и нормирование труда разработчиков; снижение производственных затрат в ходе разработки ПП; устранение непроизводительных расходов при заданном уровне качества ПП. 1.6.1 Подход к разработке прикладного ПО. Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих: небольших групп разработчиков (3-7 чел.), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива; короткого, но тщательного проработанного производственного графика (до 3 месяцев); повторяющегося цикла, при котором разработчики по мере того, как приложение начинает приобретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в проектировании, программировании и тестировании ПО, способных хорошо взаимодействовать с конечным пользователем и трансформировать их предложения в рабочие прототипы. ЖЦ ПО в соответствии с подходом RAD включает 4 стадии: 1. Анализ и планирование требований предусматривает действия: определение функций, которые должна выполнять система; выделение наиболее приоритетных функций, требующих проработки в первую очередь; описание информационных потребностей. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков. Кроме того, на данной стадии реализуются следующие задачи: - ограничивается масштаб времени; - устанавливаются временные рамки для каждой из последующих стадий. Определяется сама возможность реализации проекта в заданных рамках финансирования, на имеющихся аппаратных средствах. Результатом стадии должны быть список расставленных по приоритету функций будущего ПО ЭИС и предварительные модели ПО. 2. Проектирование. На этой стадии часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE – средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии: более детально рассматриваются процессы системы; при необходимости для каждого элементарного процесса создается частичный прототип: экранная форма, диалог, отчет, устраняющий неясности и неоднозначности; устанавливаются требования разграничения доступа к данным; определяется состав необходимой документации. После детального определения состава процессов оценивается количество так называемых функциональных точек разрабатываемой системы и принимается решение о разделении ЭИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое время (до 3 месяцев). Под функциональной точкой понимается любой из следующих элементов разрабатываемой системы: входной элемент приложения (входной документ или экранная форма); выходной элемент приложения (отчет, документ, экранная форма) запрос (пара «вопрос/ответ»); логический файл (совокупность записей данных, используемых внутри приложения); интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него). Далее проект распределяется между различными командами разработчиков. (Опыт показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций). Результатом данной стадии должно быть: общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; точно определенные интерфейсы между автономно разрабатываемыми подсистемами; построенные прототипы экранных форм, отчетов, диалогов. На стадии реализации выполняется непосредственно сама быстрая разработка приложения. Разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требования к надежности, производительности и т.д.). Пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом. Реализация системы завершается выполнением работ: Осуществляется анализ использования данных и определяется необходимость их распределения. Производится физическое проектирование базы данных Формируются требования к аппаратным ресурсам. Устанавливаются способы увеличения производительности. Завершается разработка документации проекта. Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям. На стадии внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы продолжается эксплуатация существующей системы (до полного внедрения новой). Так как стадия реализации достаточно продолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на стадии проектирования системы. Приведенная схема разработки ЭИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование организации и существует модель ее деятельности. В организации уже существует некоторая ЭИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой системой. Следует отметить, что подход RAD, как и любой другой подход, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникаций, то на первый план выступают такие показатели проекта как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки. Подход RAD не применим для построения сложных расчетных программ, операционных систем. Не годится этот подход и для приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы и приложений, от которых зависит безопасность людей (например программа управления самолетом или атомной станцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Итак, перечислим основные принципы подхода RAD. Разработка приложений итерациями. Необязательность полного завершения работ на каждой стадии ЖЦ ПО. Обязательность вовлечения пользователей в процесс разработки ЭИС. Целесообразность применения CASE – средств, обеспечивающих целостность проекта и генерацию кода приложений. Целесообразность применения средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы. Использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей. Тестирование и развитие проекта, осуществляемые одновременно с разработкой. Ведение разработки немногочисленной хорошо управляемой командой профессионалов. Грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. 1.6.2 Модели качества процессов конструирования В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO / IЕС 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model - СММ) Института программной инженерии при американском университете Карнеги-Меллон. Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IЕС 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IЕС 15504 взята из модели СММ. Базовым понятием модели СММ считается зрелость компании. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта. Напротив, в зрелой компании работают ясные процедуры управления проектами и построения программных продуктов. По мере необходимости эти процедуры уточняются и развиваются. Оценки длительности и затрат разработки точны, основываются на накопленном опыте. Кроме того, в компании имеются и действуют корпоративные стандарты на процессы взаимодействия с заказчиком, процессы анализа, проектирования, программирования, тестирования и внедрения программных продуктов. Все это создает среду, обеспечивающую качественную разработку программного обеспечения. Таким образом, модель СММ фиксирует критерии для оценки зрелости компании и предлагает рецепты для улучшения существующих в ней процессов. Иными словами, в ней не только сформулированы условия, необходимые для достижения минимальной организованности процесса, но и даются рекомендации по дальнейшему совершенствованию процессов. Очень важно отметить, что модель СММ ориентирована на построение системы постоянного улучшения процессов. В ней зафиксированы пять уровней зрелости (рис.5) и предусмотрен плавный, поэтапный подход к совершенствованию процессов - можно поэтапно получать подтверждения об улучшении процессов после каждого уровня зрелости.  |