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

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

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

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

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

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

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

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

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

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

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

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

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

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

О предотвращения дефектов;

О управления изменениями технологии;

О управления изменениями процесса.

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

Глава 8

ПРОГРАММИРОВАНИЕ

8.1 Введение

На этапе программирования можно выделить три самостоятельные группы задач: проектирование, составление (кодирование) и тестирование (отладку) программ.

8.2 Проектирование логики программы

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

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

Общие правила проектирования логики программ.

1. Прежде всего следует считывать управляющий файл.

2. Запись читается сразу по завершении обработки предыдущей записи.

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

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

Эти правила положены в основу принципа предварительного считывания.

Альтернативный метод спецификации программ.

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

В качестве альтернативы были предложены так называемые спецификационные языки (псевдокоды). Для построения типовых логических конструкций применяются ключевые слова: ВЫБОР, ВАРИАНТ, КОНЕЦ ВЫБОРА, ЕСЛИ, ТО, ИНАЧЕ, КОНЕЦ ЕСЛИ, ПОВТОРЯТЬ ПОКА, КОНЕЦ ПОВТОРЕНИЙ. Для описания действий, выполняемых программой, используются предложения естественного языка. Большое значение имеют пробелы, улучшающие восприятие текста.

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

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

ОТКРЫТЬ ФАЙЛЫ

ЧИТАТЬ ОСНОВНОЙ ФАЙЛ

ОБРАБОТАТЬ ЗАГОЛОВОК ФАЙЛА

ВЫПОЛНЯТЬ ПОКА ЕСТЬ РАЙОНЫ

ОБРАБОТАТЬ ЗАГОЛОВОК РАЙОНА

ЧИТАТЬ ОСНОВНОЙ ФАЙЛ

ВЫПОЛНЯТЬ ПОКА ЕСТЬ ЕЩЕ ДЕТАЛЬНЫЕ ДАННЫЕ

ЕСЛИ ПРЕДПРИЯТИЕ

ОБРАБОТАТЬ ДАННЫЕ ПО ПРЕДПРИЯТИЮ

КОНЕЦ ЕСЛИ

КОНЕЦВЫП

ВЫВЕСТИ СТРОКУ ИТОГОВ ПО РАЙОНУ

КОНЕЦВЫП

ОБРАБОТАТЬ ИТОГОВЫЕ ДАННЫЕ ПО ФАЙЛУ

ВЫВЕСТИ СТРОКУ ОБЩИХ ИТОГОВ

ЗАКРЫТЬ ФАЙЛЫ

Рис. 8.6 Псевдокод программы выборки из основного файла.

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

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

8.3 Структура программы

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

- точность и достаточность детлизации имеющихся спецификаций;

- наличие источников всех выходных данных;

- принципиальная возможность решения прикладной программ

- уровень сложности будущей программы

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

Прежде всего нужно выписать все выходные данные и их источники

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

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

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

- будет невозможно получить выходные данные в требуемой последовательности;

- для принятия решений в ходе обработки придется запоминать множество зписей;

- составленная по спецификации программа окажется слишком большой и сложной.

1.4. Логическое проектирование программ

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

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

2. Выбор управляющего файла

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

4. Выявление соответствия между файлами

5. Разработка укрупненной структуры программы

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

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

8. Оценка полученных результатов

Рис. 8.14 Логическое проектирование программы

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

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

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

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

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

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

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

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

- Можно ли сформулировать назначение модуля одним предложеним? Если это так, то скорее всего, его логика достаточно прорста.

- Предназначен ли модуль для обработки данных?

- Соответствуют ли процедуры инициализации и завершения своему прямому назначению и не модифицируют ли они вместо этого какие-либо физические записи?

8.5 Уточнение прoекта

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

1. Проверка приемлемости размера модулей

2. Объединение или разделение модулей

3. Выявление общих функций и выделение самостятельных модулей

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

5. Критический анализ внесенных уточнений

Рис. 8.17. Последовательность операций при уточнении проекта

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

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

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

По завершении всех уточнений выполняется критический анализ скорректированного проекта.

8.6 Оптимизация программы

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

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

Стараться не проводить оптимизацию

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

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

8.7 Физическое проектирование программ

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

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

- производительность технических средств;

- возможность применения общих подпрограмм;

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

- простота тестирования и отладки программы;

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

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

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

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

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

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

1. Объединение взаимосвязанных логических модулей в физические модули

2. Разработка иерархической схемы физических модулей

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

4. Критический анализ результатов

8.8 Принципы структурного программирования

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

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

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

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

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

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

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

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

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

8.12 Тестирование программы

При тестировании программы проверяется работает ли программа т все ее ветви в соответствии со своей спецификацией.

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

Формирование единого нбора тестовых данных для системы гарантирует их достоверность и уменьшает трудоемкость тестирования.

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

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

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

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

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

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

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

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

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

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

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

- совместное редактирование связей уже проверенных модулей и комплексное тестирование.

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

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

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

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

8.13. Проектирование программ для систем реального времени

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

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

Различают:

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

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

Особеннсти разработки.

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

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

- Если телемонитор на поддерживает область сохранения данных автоматически, то за их сохранность и восстановление «отвечает» прикладная программа.

8.14. Разработка программ в диалоговом режиме

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

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

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

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

Глава 9.

ТЕСТИРОВАНИЕ

9.1 Введение

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

Основная цель тестирования – проверить. Выполняет ли разработанная система возложенные на нее функции и высока ли ее надежность.

Основные стадии тестирования:

Системный анализ

Проектирование системы

Программирование

Тестирование программ

Испытания системы

Предъявление системы пользователю.

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

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

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

9.2 Подготовка тестовых данных

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

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

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

9.3 Разделение тестовых данных

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

9.4. Процедура тестирования.

1. Общее планирование испытаний

2. Детальное планирование испытаний

3. Планирование проверки внешних функций.

4. Планирование проверки интерфейсов с другими системами

5. Планирование проверки работоспособности системы

6. Систематизация проверок

7. Формирование плана выполнения контрольных примеров

8. Подготовка тестовых данных

9. Использование тестовых данных

10. Прогнозирование результатов проверок

11. Разработка заданий на выполнение контрольных примеров

12. Составление календарного плана испытаний

13. Выполнение контрольных примеров

14. Анализ результатов испытаний

15. Анализ объемно-временных характеристик системы

16. Анализ ошибок, обнаруженных в ходе испытаний

17. Ведение библиотеки испытаний системы

18. Утверждение результатов и завершение испытаний

Рис. 9.3. Задачи, решаемые при подготовке и проведении испытаний системы

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

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

1. Описание стратегии тестирования системы.

2. Сетевой график выполнения основных работ.

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

4. Краткое описание каждой работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

- воспользоваться генератором тестовых данных;

- подготовить тестовые данные силами проектной группы;

- привлечь пользователей к подготовке тестовых данных;

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

- выделить тестовые данные из имеющихся машинных файлов;

- выделить тестовые данные из внемашинных докуметов.

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

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

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

Разработка заданий на выполнение контрольных примеров. Во время программирования могут быть подготовлены задания для выполнения контрольных примеров.

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

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

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

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

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

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

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

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

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

9.5. Хранение тестовых данных систем

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

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

9.6. Заключение.

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

Дата добавления: 2014-01-04