Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
58
Добавлен:
12.03.2016
Размер:
2.5 Mб
Скачать

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.2.Формализация требований

3.2.1.3.Преимущества

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

варианты использования относительно легко писать; варианты использования пишутся на языке пользователя;

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

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

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

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

3.2.2. Псевдокод

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

Императивных предложений с одним глаголом и одним объектом. Ограниченного множества (как правило, не более 40–50) «ориентиро-

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

Решений, представленных формальной структурой IF-ELSE-ENDIF. Итеративных действий, представленных структурами DO-WHILE и

FOR-NEXT.

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

Технологии разработки программного обеспечения. Учеб. пособие

-121-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.2.Формализация требований

Set Sum(X)=0

for каждого клиента х

if клиент оплатил услуги вперед

and ((Текущий месяц)>=(2 мес. после даты приобретения)) and ((Текущий месяц)<=(14 мес. после даты приобретения))

then Sum(X) = Sum(x) + (сумма, заплаченная клиентом)/12

Рис. 3.6. Пример спецификации с использованием псевдокода

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

3.2.3. Конечныеавтоматы

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

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

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

На рис. 3.7 приведен пример диаграммы состояний и переходов для объекта «Заказ».

Добавить к заказу новую позицию[ Остаются незаполненные позиции ]

Инициализация

 

entry/ Сохранить дату заказа

Выполнить заказ

do/ Собрать клиентскую информацию

 

do/ Добавить к заказу новые позиции

 

Отменить заказ

Отменён

exit/ Сохранить дату отмены

Выполнение заказа приостановлено

Добавить к заказу новую позицию[ Не осталось незаполненных позиций ]

Выполнен

do/ Выписать счет

Рис. 3.7. Диаграмма состояний и переходов объекта «Заказ»

Технологии разработки программного обеспечения. Учеб. пособие

-122-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.2.Формализация требований

3.2.4.Графическиедеревьярешений

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ничего не делать

 

 

 

 

 

 

 

 

 

 

 

 

 

Да

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ответила ли удалённая

 

 

 

 

 

 

 

 

 

 

 

 

 

система безопасности?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Нет

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Инициировать

 

 

 

 

 

 

 

 

 

 

 

 

 

 

сообщение о тревоге

 

 

 

 

 

 

 

Включить сирену

 

 

 

 

 

Да

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Включено ли дистанционное

 

 

 

 

 

 

 

 

 

 

 

 

оповещение?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Да

Включить сирену

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Да

 

Нет

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Включен ли местный

 

 

 

 

 

 

 

 

Поступила ли последовательность сигналов,

 

 

 

 

 

 

 

 

 

 

 

сигнал тревоги?

 

 

 

 

 

 

 

 

соответствующая состоянию тревоги?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Нет

 

Нет

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ничего не делать

 

 

 

Ничего не делать

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 3.8. Графическое дерево решений

3.2.5. Диаграммыдеятельности

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

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

Технологии разработки программного обеспечения. Учеб. пособие

-123-

3. АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

 

 

 

3.2. Формализация требований

 

Покупатель

 

Интернет-магазин

 

Вход в каталог

 

 

 

Интернет-магазина

 

 

[ Поиск по разделу ]

 

[ Поиск по ключу ]

 

 

Переход к разделу

 

Ввод критерия

Поиск в каталоге

 

каталога

 

поиска

 

 

 

 

 

Формирование

Подготовка к

 

 

 

результата поиска

приёму заказа

Исследование

 

 

 

 

товара

 

 

 

 

[ Товар выбран ]

Положить товар в

Выполнить заказ в

 

корзине

 

 

 

корзину

 

 

 

 

 

[ Товар не выбран ]

 

 

 

 

Рис. 3.9. Диаграмма деятельности покупателя в Интернет-магазине

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

3.3. Техническоезадание(ГОСТ34.602–89)

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

Технологии разработки программного обеспечения. Учеб. пособие

-124-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.3.Техническое задание (ГОСТ 34.602–89)

3.3.1.Общиесведения

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

3.3.2. Назначениеицелисоздания(развития) системы

3.3.2.1. Назначениесистемы

Здесь указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации, на которых предполагается ее использовать. Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

3.3.2.2. Целисозданиясистемы

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

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

3.3.3.Характеристикиобъектаавтоматизации

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

Примечание. Для САПР дополнительно приводят основные параметры

ихарактеристики объектов проектирования.

3.3.4. Требованияксистеме

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразде-

Технологии разработки программного обеспечения. Учеб. пособие

-125-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.3.Техническое задание (ГОСТ 34.602–89)

ле приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида.

3.3.4.1. Требованияксистемевцелом

Требования к структуре и функционированию системы. Здесь при-

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

Требования к численности и квалификации персонала на АС. При-

водят: требования к численности персонала (пользователей) АС; требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков; требуемый режим работы персонала АС.

Требования к показателям назначения АС. Приводят значения па-

раметров, характеризующих степень соответствия системы ее назначению. Для АСУ указывают: степень приспособляемости системы к измене-

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

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

кнадежности технических средств и программного обеспечения; требования

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

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

Технологии разработки программного обеспечения. Учеб. пособие

-126-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.3.Техническое задание (ГОСТ 34.602–89)

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

Требования по эргономике и технической эстетике. Включают пока-

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

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

Требования к защите информации от несанкционированного дос-

тупа. Включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

Требования по сохранности информации. Приводят перечень собы-

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

Требования к средствам защиты от внешних воздействий. Приво-

дят: требования к радиоэлектронной защите средств АС; требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

Требования к стандартизации и унификации. Включают: показате-

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

Технологии разработки программного обеспечения. Учеб. пособие

-127-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.3.Техническое задание (ГОСТ 34.602–89)

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

ксервисной аппаратуре, стендам для проверки элементов системы; требования

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

3.3.4.2. Требованиякфункциям(задачам)

Здесь приводят: по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации; при создании системы в две или более очереди – перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях; временной регламент реализации каждой функции, задачи (или комплекса задач); требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов; перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

3.3.4.3.Требованияквидамобеспечения

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

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

Требования к информационному обеспечению. Приводят требова-

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

Технологии разработки программного обеспечения. Учеб. пособие

-128-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.3.Техническое задание (ГОСТ 34.602–89)

нии системы; к контролю, хранению, обновлению и восстановлению данных; к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

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

Требования к программному обеспечению. Приводят перечень по-

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

Требования к техническому обеспечению. Приводят требования:

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

Требования к метрологическому обеспечению. Приводят: предвари-

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

Требования к организационному обеспечению. Приводят: к структу-

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

Технологии разработки программного обеспечения. Учеб. пособие

-129-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.3.Техническое задание (ГОСТ 34.602–89)

Требования к методическому обеспечению САПР. Приводят требова-

ния к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.).

3.3.5. Состависодержаниеработпосозданию(развитию) системы

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

Кроме того приводят: перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ; вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт); программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости); перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

3.3.6. Порядокконтроляиприемкисистемы

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

3.3.7. Требованияксоставуисодержаниюработ поподготовкеобъектаавтоматизацииквводусистемывдействие

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

В перечень основных мероприятий включают: приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ; изменения, которые необходимо осуществить в объекте автоматизации; создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям,

Технологии разработки программного обеспечения. Учеб. пособие

-130-

3.АНАЛИЗ ТРЕБОВАНИЙ И ИХ ФОРМАЛИЗАЦИЯ

3.3.Техническое задание (ГОСТ 34.602–89)

содержащимся в ТЗ; создание необходимых для функционирования системы подразделений и служб; сроки и порядок комплектования штатов и обучения персонала.

Например, для АСУ приводят: изменения применяемых методов управления; создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

3.3.8. Требованиякдокументированию

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

3.3.9. Источникиразработки

Должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-иссле- довательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

Технологии разработки программного обеспечения. Учеб. пособие

-131-

Соседние файлы в папке Материалы