Организация дочерних требований

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

Чтобы при чтении проще было связать дочерние требования с родительским, обо значение дочерних требований должно основываться на обозначении родительских. Предположим, что требование к программному обеспечению SR63.1 (см. табл. 23.1) имеет одно или несколько дочерних требований. Естественно будет обозначить дочерние требования SR 63.1.1, SR 63.1.2, SR 63.1.3 и т.д. Иерархический вид табл. 23.1 будет тогда I выглядеть следующим образом.

Функция 63

SR 63.1

SR 63.1.1

SR 63.1.2

SR 63.1.3

5К63.2

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

Глава 7

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

7.1 Введение

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

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

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

Опреационная диаграмма этапа проектирования предполагает такую последовательность операций.

1. Изучение требований.

2. Выделение в системе основных компонентов, типов данных и процессов.

3. Разработка логической структуры системы.

4. Усовершенствование этой структуры в соответствии с техническими ограничениями.

5. Завершение спецификации системы и переход к программированию.

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

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

7.2 Декомпозиция данных

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

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

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

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

1. Выявление входных данных

2. Выявление выходных данных

3. Анализ хранимых данных

4. Определение связей между хранимыми данными

5. Анализ взаимосвязанных файлов

6. Сопоставление хранимых и входных данных

7. Сопоставление выходных данных с хранимыми и входными данными.

Рис. 7.5. Подзадачи при декомпозиции системы.

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

Каждому входу в систему присваивается некоторый идентификатор, скажем IN01, IN02 и т.д., а каждому элементу данных – порядковый номер. Это обеспечивает наглядную идентификацию всех элементов данных и может быть полезно при последующем анализе перкрестных связей. Например, «Домашний телефон» должен обозначаться на бланке как IN04/6, т.е. как шестой элемент данных на входе IN04 «Заказы». Там, где требуются особые проверки, метод контроля указывается в графе «содержание».

Аналогичная форма используется для описания выходных джанных. Идентификаторы показывают, что компоненты – выходные, например, OP01 – «Список корректировок», OP02 – «Отчет по отелям» и т.д. Графа «Содержание» остается незаполненной до проведения перекрестноо анализа, после чего в нее вносятся специальные замечания по формату вывода.

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

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

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

7.3 Декомпозиция процессов

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

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

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

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

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

3. Сопоставляются хранимые и входные данные для процессов

4. Идентифицируются элементы данных, не выявленные при сопоставлении

5. Идентифицируются и перечисляются ограничения и перспективные потребности

6. Проводится подготовка к критическому анализу.

Рис. 7.7. Подзадачи при декомпозиции процесов

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

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

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

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

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

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

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

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

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

Указатель бланков процессов.Необходимо создать и вести указатель процессов.

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

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

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

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

7.4. Разработка профилей транзакций

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

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

После сортировки следует определить логическую стуктуру процессов. Р азличают пять видов структур: последовательную, параллельную, с ветвлением (выбор), с циклами (итерации) и вложенную. Все эти структуры аналогичны используемым в программировании и описанным в гл.8. Типовые структуры приведены на рис. 7.12-7.16.

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

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

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

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

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

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

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

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

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

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

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

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

Критический анализ логического проекта. Скомпонованный логический проект рассматривается аналитиками и проектировщиками совместно с представителями организации-заказчика.

Такой структурный анализ имеет особое значение, поскольку он проводится на грани логического и технического проектирования. Для пользователя, который не участвует в техническом проекте, это «последний шанс» повлиять на ход разработки. Задача пользователя на этой стадии существенно упростится. Если на этапе системного анализа состоялось детальное согласование проекта.

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

7.6. Уточнение технических деталей

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

Вщ-первых, Не следует полагать. Что существует совершенный во всех отношениях технический проект. Речь может идти о нескольких корректных альтернативах.

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

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

В основном техническое проектирование предуссматривает следующие операции:

- документирование и утверждение ограничений;

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

- оценка объемно-временных характеристик системы и при необходимости корректировка проекта.

Рис. 7.20 задачи, решаемые при техническом уточнении проекта

1.Выявление имеющихся ограничений.

2.Определение целей проектирования

3.Фиксация первоначальной версии структуры файлов

4.Определение необходимости в сортировках

5.Установление оптимального способа доступа к каждому файлу

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

7.Определение требований по обеспечению безопасности данных и реорганизации файлов.

8.Критический анализ первой версии проекта

9.Оценка ресурсов оперативной памяти

10. Оценка времени работы системы

11. оценка ресурсов дисковой памяти

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

13. Коректировка проекта при необходимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Достаточно точное приближение дает оценка времени, затрачиваемог на обращение к файлам.

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

Требования к объему дисковой памяти (исходя из числа и размеров блоков в файлах)

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

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

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

7.7. Группирование компонентов

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

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

Правила группирования

Процессы	Данные
1.	Небольшой файл в оперативной памяти
2. Процессы, «обрабатывающие одни и те же входные данные, но различные ссылки.
3. Процессы, «обрабатывающие» одни и те же входные данные (сходные процессы)	Выделение таблицы
4. Процесс посылки и выборки данных
5.	Объединение файлов
6. Все процессы для функций
7. Все процессы для входных данных
8. Все процессы для тактовой линии
9. Все процессы для системы

Рис. 7.23 Группирование процессов и данных

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

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

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

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

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

Трудности

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

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

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

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

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

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

Окончательный просмотр.

7.8. Детализация проекта.

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

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

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

-проверка упорядоченности файла;

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

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

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

1. Схема выполнения программы, на которой показаны входные и выходные данные.

2. Общее описание функций и интерфейсов программы

3. Описание структуры входных и выходных данных

4. Описание структуры выходных отчетов с указанием источников результатов среди входных данных.

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

6. Описание (копии спецификаций) системных процедур контроля

7. Копии спецификаций общих модулей

8. Детальное описание логики программы.

Рис. 7.26. Содержание спецификации программ

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

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

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

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

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

7.9 Структурное проектирование систем реального времени

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

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

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

-управление сетью терминалов;

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

-доступ к файлам с помощью стандартных методов;

-возможность одновременной обработки сообщений;

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

-тестирование интерфейсов;

-организацию службы времени;

-интерфейс с системами пакетной обработки;

-защиту данных.

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

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

- определение чмсла терминалов в каждом пункте;

- расчет времени передачи сообщений;

- проектирование линий связи.

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

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

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

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

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

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

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

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

Основыне характеристики, на которые в системах реального времени накладываются ограничения:

- время (реакции или восстановления);

- объем памяти (оперативной или дисковой);

- доступ к системе;

- возможность рестарта после отказа;

- среднее время между отказами и т.д.

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

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

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

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

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

7.10 Структурное проектирование систем баз данных.

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

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

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

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

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

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

1. отображение (обощенной) логической модели данных на модель данных, поддерживаемую СУБД.

2. Определение структуры типов записей (сегментов).

3. Выбор физических характеристик файлов (включая размеры блоков).

4. Реализация связей между записями и обеспечение путей доступа.

5. Расчет эффективности обработки наиболе частых обращений к базе данных и при необходимости модификации ее структуры.

Вслед за первой версией проекта необходимо разработать структуру данных, которая может быть реализована средствами СУБД. Такая структура должна обеспечивать обработку всех требуемых запросов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Различают:

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

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

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

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

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

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

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

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

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

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

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

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

9.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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