Методология управления качеством информационных систем и по

Лекция 1 (3 сентября)2021 (10-00)

МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ КАЧЕСТВОМ

Рис. 2. Обобщенная схема синтеза систем совершенствования качества ИС

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

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

На основе рассмотренной методологии СКИС и методики формирования дефиниций можно принять следующее определение этого понятия — «методология совершенствования качества информационных систем — это совокупность принципов, логики организации, методов и средств, реализация которых направлена на решение задач по обеспечению и улучшению качества информационных систем» [101].

 

ПОНЯТИЕ МЕТОДОЛОГИИ УПРАВЛЕНИЯ КАЧЕСТВОМ ИС

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

Например, ИС менеджмента (ИСМ или MIS) или “управленческие системы”- комплексы бухгалтерских или торгово-складских программ.

Информационные системы используются в настоящее

Время в различных сферах экономики областях и бизнеса - системы поддержки принятия решений (DSS), ИС менеджмента (MIS), ИС управления нвестициями (PROJECT EXPERT), ИС риск-менеждмента (RMIS).

Таблица 1. Структура жизненного цикла КС УКИС-

Иерархические уровни структуры жизненного цикла КС УКИС
Фаза	Стадия	Этапы
1. Создание	1Л. Исследование	1.1.1. Концептуальное моделирование
		1.1.2. Формализованное моделирование
		1.1.3. Физическое моделирование
	1.2. Проектиро- вание	1.2.1. Предпроектное обследование
		1.2.2. Разработка технического задания
		1.2.3. Разработка технического проекта
		1.2.4. Разработка рабочего проекта
	1.3. Построение	1.3.1. Приобретение оборудования
		1.3.2. Сборка комплекса технических средств
		1.3.3. Монтаж комплекса технических средств
		1.3.4. Настройки и тестирование КС УКИС
2. Функционирование	2.1. Внедрение	2.1.1. Сдача КС УКИС в опытную эксплуатацию
		2.1.2. Опытная эксплуатация
	2.2. Эксплуатация	2.2.1. Вывод КС УКИС на производственный режим
		2.2.2. Производственная эксплуатация
		2.2.3. Развитие системы
		2.2.4. Стабилизация эксплуатационных характеристик системы
		2.2.5. Снижение уровня эксплуатационных характеристик системы
3. Ликвидация	3.1. Подготовка	3.1.1. Подготовка документов и средств по ликвидации
	3.2. Проведение	3.2.1. Выполнение работ по утилизации (демонтаж, разборка, выделение компонентов, пригодных для дальнейшего использования, и др.)
	3.3. Окончание	3.3.1. Оформление результатов ликвидации (сдача ненужных компонентов в утиль, реализация работоспособных компонентов, оформление документации)

Модели жизненного цикла

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

Рис. 2.. Каскадная схема разработки ПО

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

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

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

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

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

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

Рис. 3. Итерационная модель ЖЦ: 1—5 — циклы корректировки процесса

Инкрементная модель.

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

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

Рис.5. Схема инкрементной модели ЖЦ

 

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

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

планируются работы следующего витка спирали (рис. 6). Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также «продолжающимся проектированием». Позднее в проектный цикл дополнительно стали включать стадии разработки и апробации прототипа системы. Это называлось: «быстрое прототипирование», «rapid prototyping approach» или «fast-track».

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

Спиральная модель была предложена Б. Боэмом (Barry Boehm) в 1988 г. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Сам Б. Боэм так характеризует спиральную модель разработки: «Главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время, ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта».

Спиральная модель обладает рядом преимуществ:

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

Модель «фазы-функции».

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

Одно из наиболее последовательных таких дополнений классических схем реализовано в модели Гантера в виде матрицы «ф а з ы - ф у н к ц и и», которая имеет две координаты (табл. 2.):

• фазы — отражает этапы выполнения проекта и сопутствующие им события;

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

Таблица 2.. Матрица «фазы-функции» модели Гантера

В данной модели жизненный цикл распадается на следующие перекрывающие друг друга фазы (этапы):

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

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

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

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

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

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

Я половина лекции

Модель Джелинского-Моранды.

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

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

2. Все ошибки в программе равновероятны и не зависят друг от друга.

3. Все ошибки имеют одинаковую степень важности.

4. Время до следующего отказа программы распределено экспоненциально.

5. Исправление ошибок происходит без внесения в программу новых ошибок.

6. R(t) = const в промежутке между любыми двумя соседними моментами обнаружения ошибок.

Согласно этим предположениям, функция риска будет представлена как:

В этой формуле t – это произвольный момент времени между обнаружением (i-1)-й и i-й ошибок; K – неизвестный коэффициент масштабирования; B – начальное количество оставшихся в программе ошибок (также неизвестное). Таким образом, если в течении времени t было обнаружено (i-1) ошибок, это означает, что в программе еще остается B-(i-1) необнаруженных ошибок. Полагая, что

и используя предпосылку 6, а также равенство (13.2), можно заключить, что все X_i имеют экспоненциальное распределение

и плотность вероятности отказа, соответственно, равна

Тогда функцию правдоподобия (согласно предпосылке 2) можно записать как

или, переходя к логарифму функции правдоподобия, имеем

(13.2)

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

(13.3)

(13.4)

Из формулы (13.3) получается оценка максимального правдоподобия для K

(13.5)

Подставляя выражение (13.5) в (13.4), находим нелинейное уравнение для вычисления –оценки максимального правдоподобия для B

(13.6)

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

(13.7)

где

Поскольку имеют смысл лишь целочисленные значения , функции из выражения (13.7) можно рассматривать только для целочисленных аргументов. Более того, , поскольку n ошибок с программе уже обнаружено. Таким образом, оценка максимального правдоподобия для B может быть получена с помощью вычисления начальных значений функций f_n(m) и g_n(m) для m=n+1, n+2…, и анализа разницы |f_n(m)-g_n(m)|.

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

(13.8)

В противном случае оценка максимального правдоподобия будет Условие (13.8) можно переписать в более удобном виде

(13.9)

где A – то же самое выражение, что и в формуле (13.7). Необходимо отметить, что, A является интегральной характеристикой n встретившихся в программе за время тестирования ошибок, и представляет (в статистическом смысле) набор интервалов X_i между ошибками.

Рассмотрим пример использования модели Джелинского-Моранды, в котором она применяется к следующим экспериментальным данным: в течение 250 дней было обнаружено 26 ошибок, интервалы между обнаружением которых представлены в таблице 13.1. Для этих данных мы имеем n=26 и . Условие (13.9) выполняется, и, таким образом, оценка максимального правдоподобия имеет единственное решение. В таблице 13.2 представлены начальные значения функций, входящих в уравнение (13.7), для множества аргументов

Наилучшим решением для уравнения (13.7) является m=32 (соответствующая строка в таблице дает минимальное значение разницы функций по модулю, то есть максимально приближает ее к нулю, что нам и требуется), то есть = m-1=31. Из выражения (13.5) находим = 0.007.

Среднее время (время, оставшееся до обнаружения (n+1)-й ошибки) есть инвертированная оценка интенсивности для предыдущей ошибки:

В этом примере, , и время до полного завершения тестирования

 

Таблица 10. Интервалы между обнаружением ошибок.

I	Xi	I	Xi	i	Xi	i	Xi

 

Таблица 11. Значения функций.

m
	3.854	2.608	1.246
	2.891	2.371	0.520
	2.427	2.172	0.255
	2.128	2.005	0.123
	1.912	1.861	0.051
	1.744	1.737	0.007
	1.608	1.628	-0.020
	1.496	1.532	-0.036

Простая экспоненциальная модель.

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

Продифференцируем обе части этого уравнения по времени:

Учитывая, что - это R(t) (количество ошибок, обнаруживаемых в единицу времени), получаем дифференциальное уравнение для R(t)

(13.10)

Если рассмотреть начальные значения N(0)=0, R(0)=KB, то решением уравнения (3.10) будет

(13.11)

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

 

                                                                 3 сентября

1-я половина.

Тема лекции - “Стандартизация, надежность и качество разработки программных средств” 

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

 

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

 

 

    

  

        

             

 

 

 

 

 

 

 

2-я половина лекции

 

 

                                      Пояснения к аббревиатуре   - МЦИ

МЭР - совокупность отношений между подразделениями расчетной сети Банка России, находящихся на территории различных субъектов Российской Федерации, а также между кредитными организациями, клиентами Банка России и подразделениями расчетной сети Банка России по совершению платежей с использованием платежных и служебно-информационных документов, составляемых в электронной форме. Правила осуществления межрегиональных электронных платежей являются едиными для всех регионов и регламентированы Положением «О межрегиональных электронных расчетах, осуществляемых через расчетную сеть Банка России» в редакции от 11.04.2000г. № 36-П.

3 уровня: банк-участник, региональный ГРКЦ Банка России и Межрегиональный центр информации Банка России (МЦИ). МЦИ расчетов не производит, а осуществляет лишь коммуникационные функции и является центром передачи сообщений. МЭП осуществляются региональными ГРКЦ по схеме «каждое с каждым» (на двусторонней основе) по счетам, открытым друг у друга. Межрегиональные электронные платежи совершаются в зависимости от удаленности часовых поясов регионов, в которых располагаются плательщик и получатель и, как правило, завершаются в течение дня или не позднее следующего рабочего дня.

                                                                    Рис.0.1 МЭР

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

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

Входят два уровня участников: ГРКЦ региона и региональные КБ, включая филиалы банков других регионов. Для проведения платежей банки-участники открывают корсчета в ГРКЦ.

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

Рис.02. ВЭР

1. Предоставление клиентом-плательщиком платежного документа в банк.

            2. Списание денежных средств со счета плательщика.

            3. Передача ЭПД в ГРКЦ.

            4. Передача подтверждения принятия ЭПД к исполнению.

            5. Обработка и проведение ЭПД по корреспондентским счетам банков.