Роль стандартизации и сертификации в управлении качеством ПС

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

Стандартизация выполняет следующие функции:

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

2) закрепление в нормативных документах оптимальных требований к упорядоченным объектам;

3) установление правил применения этих нормативных документов.

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

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

2) сближает уровень качества товаров, производимых в разных странах;

3) содействует взаимообмену научно-технической информацией;

4) содействует международной торговле.

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

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

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

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

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

Роль стандартизации и сертификации в управлении качеством ПС - student2.ru

Рис.6. Схема разновидностей нормативных документов

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

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

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

2. Стандарты предоставляют необходимую основу для процесса обеспечения качества: достаточно контролировать соблюдение стандартов.

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

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

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

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

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

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

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

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

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

Типовые этапы в разработке программ:

· разработка спецификации требований к программе;

· определение архитектуры;

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

· разработка кода и тестирование.

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

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

Таблица 1. Состав метрик, их влияние и анализ эффективности использования

Метрика	Зачем нужна	Влияет на…	Анализ на основе статистических данных (как тренд, так и прогноз)
Усилия разработчика при реализации.	Насколько эффективен труд разработчика.	Точность прогнозов оценки трудоемкости при выполнении организацией типовых или мало отличающихся запросов	Можно анализировать усилия разработчика во временном срезе или в срезе по релизам или проектам. Выявлять, на каких задачах программист полностью выкладывается, а какие ему не по душе. Тренд позволит менеджеру лучше понимать, кто и каких задачах максимально эффективен при формировании команды нового проекта, а также какие подсистемы относительно сложны, а какие – просты.
Длина и объем программы		Оценку объема изменений	Увеличивается или уменьшается объем программы во времени. Используем для прогноза сложности на ранних этапах на основе статистики.
Анализ цикломатической сложности		Оценку сложности изменений	Сложность растет или нет? Используем для прогноза сложности на ранних этапах на основе статистики.
Усилия программиста при разработке.	Для определения сложности реализации того или иного блока кода (класса, функции и т.д.)	Понимание того, насколько интеллектуально-затратной для разработчика была та или иная функция.	Анализируется увеличение или уменьшение усилий разработчика во времени. На предварительных этапах метрику можно использовать для прогноза.
Количество строк на реализацию требования.	Меряем общую температуру. Эта метрика принимается во внимание при анализе реализации запроса.	Понимание КПД. Отслеживаем всплески.	Сигнал опасности при выявлении увеличения количества строк во время выполнения типового запроса. Используем для оценки сложности на ранних этапах на основе статистики.
Количество комментариев на единицу кода.	Код должен быть документирован. Если соотношение кода к комментарию не 1:4, то разработчик обязан доработать.	Качество кода, его прозрачность.	Общая культура разработчиков растет или нет? Если растет – хорошо. Если нет – плохо. Если скачкообразно – соотносим менеджеров\руководителей проектов со скачками. Выделяем сложные проекты, проблемные модули или подсистемы
Прочие количественные метрики (число функций, классов, файлов).	Отношение новых функций к измененным.	Количество добавленных, удаленных и измененных строк по отношению к предыдущей версии.	Глубокий анализ изменений по релизам (версиям, сборкам) дает понять: Количество изменений (на что угодно) – сколько раз один и тот же блок кода корректировался. Возможно выявить узкое место в программе: интенсивно меняющийся блок кода может влиять на общее качество программы (потенциальное место возникновения ошибок). Возможно, необходимо изменить архитектуру блока.
Плотность дефектов на единицу кода.	Количество дефектов на 1-у строку кода	Производная метрика: количество строк/число дефектов.	Данная метрика более полезна для временной оценки: Плотность увеличивается от билда к билду, от версии к версии? Плотность дефектов по подсистемам (выявляем проблемную подсистему. В этом случае показатель почти наверняка будет коррелироваться с метрикой, отвечающей за интенсивность изменений участка кода, так как в этом месте наверняка "тонко")

Метрика	Описание
Взвешенная насыщенность класса 1 (Weighted Methods Per Class (WMC)	Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются.
Взвешенная насыщенность класса 2 (Weighted Methods Per Class (WMC2))	Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются.
Глубина дерева наследования (Depth of inheritance tree)	Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков.
Связность объектов (Coupling between objects)	Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода.
Отклик на класс (Response For Class)	Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов

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

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

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

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

Операторы организаций циклов наверняка присутствуют в вашей программе. Оптимизация здесь проста: по возможности заменить операторы WHILE и REPEAT на оператор FOR, который выполняется примерно на 10-15 процентов быстрее первых двух.

Основная идея оптимизации самых различных вычислений чрезвычайно проста: надо использовать более быстрые операции и по возможности заменять дробные числа целыми.

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

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

Существует возможность повысить производительность программ обработки текстовых файлов (например, файл контекстной подсказки) без применения процедур BlockRead и BlockWrite. Такие программы чаще всего ведут активный диалог с пользователем, эффективность которого может сильно упасть из-за возможных задержек при выполнении файловых операций. Выход из такой ситуации состоит в увеличении размера стандартного буфера. Его объем составляет 128 байт. Увеличив буфер до 8192 байт для текстового файла, можно повысить скорость файловых операций почти в 2 раза:

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

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

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

Задание по работе

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

Вариант 1

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

IF X=1 THEN

BEGIN <оператор> END;

IF X=2 THEN

BEGIN <оператор> END;

IF X=3 THEN

BEGIN <оператор> END;

IF X=1 THEN

BEGIN <оператор> END

ELSE IF X=2 THEN

BEGIN <оператор> END

ELSE IF X=3 THEN

BEGIN <оператор> END;

CASE X OF

1: BEGIN <оператор> END;

2: BEGIN <оператор> END;

3: BEGIN <оператор> END;

END;

Вариант 2

Посчитать в процентном соотношении быстродействие циклических операторов (WHILE, REPEAT, FOR):

Вариант 3

Посчитать в процентном соотношении быстродействие арифметических операторов. Произвести для сравнения замену дробных чисел целыми, замену оператора деления на оператор умножения и так далее. Например, Rez:= X / 4.0 заменить на Rez:= X * 0.25.

Вариант 4

Посчитать в процентном соотношении быстродействие операций записи на диск и чтения с диска с помощью замены процедур Read и Write на BlockRead и BlockWrite.

Пример: Пусть требуется записать на диск 12800 значений научных наблюдений в виде целых чисел типа Byte. Затем считать в память и вычислить их среднее значение. Чтобы упростить вычисления, можно условиться, что все элементы массива натурных данных равны 1.

Вариант 5

Повысить производительность программ обработки текстовых файлов за счет увеличения размера стандартного буфера, объем которого составляет 128 байт. Увеличить буфер до 8192 байт.

Вариант 6

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

a) замены операций обработки строк на операции с массивами. Например, замените оператор иницилизации строки

FOR I := 1 TO 240 DO

St:=St + ‘*’;

на

FOR I:=1 TO 240 DO

St[I]:=‘*’;

St[0]: = Chr[240];

b) замены процедуры Copy на команду Move:

например, заменив оператор

NewSt:= Copy(DldSt, 60, 38);