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

Подождите немного. Документ загружается.

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

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



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

Применение вариантов использования имеет ряд преимуществ по срав-

нению с традиционным подходом, когда определяются отдельные деклара-

тивные программные требования:

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

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

варианты использо

вания предлагают связные сценарии поведения, ко-

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

Благодаря описанию «сценариев поведения», содержащимся в языке

UML специализированным элементам и нотациям моделирования, варианты

использования обеспечивают дополнительные возможности связывать дея-

тельность по разработке требований с проектированием и реализацией.

Графическое представление вариантов использования в UML и их под-

держка различными инструментальными средств

ами моделирования обеспе-

чивают визуализацию связей между вариантами использования, что может

содействовать пониманию сложной программной системы.

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

практически без изменений применяется в качестве сценария тестирования

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

Псевдокод – это кв

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

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

щими структурами языка программирования. В чистом виде псевдокод со-

стоит из комбинации следующих элементов.

Императивных предложений с одним глаголом и одним объектом.

Ограниченного множеств

а (как правило, не более 40–50) «ориентиро-

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

ложения.

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

Итеративных действий, представленных структурами DO-WHILE и

FOR-NEXT.

На рис. 3.6

представлен пример спецификации с помощью псевдокода

алгоритма вычисления отложенного дохода от услуг в течение данного меся-

ца в бизнес-приложении.

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

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



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

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

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

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

синтаксических ограничений, формата и разбивки существенно уменьшает

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

сложным и расплывчатым. В то же время такое представление требования

вполне понятно для человека, не являющегося программистом. Не нужно

быть выдающимся ученым, чтобы понимать псевдокод, и нет необходимости

знать C++ или Java.

Представление в виде конечного автомата описывает возможные жиз-

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

Каждое состояние – это такой период жизненного цикла объекта, когда

он удовлетворяет определенным условиям. Некоторое событие может при-

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

При переходе может выполняться действие, предписанное данно

му переходу.

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

состояний и переходов.

На рис. 3.7

приведен пример диаграммы состояний и переходов для

объекта «Заказ».

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

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

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

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

Выполнение заказа

приостановлено

Отменён

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

Выполнен

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

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

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

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

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

Выполнение заказа

приостановлено

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

Добавить к заказу новую позицию[

Остаются незаполненные позиции ]

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

Добавить к заказу новую

позицию[ Не осталось

незаполненных позиций ]

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

Set Sum(X)=0

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

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

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

месяц)<=(14 мес. после даты приобретения))

then Sum

(

)

= Sum

(

)

(

мма

заплаченная клиентом

)

/12

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

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



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

Дерево решений применяется для отображения информации в виде

графа. На рис. 3.8

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

следовательности действий.

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

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

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

Нет

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

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

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

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

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

Да

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

Нет

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

оповещение?

Да

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

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

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

Нет

Да

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

Нет

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

Деятельн

ость представляет собой поток работ или выполнение опера-

ции. Представление деятельности отображает как последовательные, так и

параллельные виды деятельности. Изображаются такие модели на диаграм-

мах деятельности.

На рис. 3.9

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

покупателя в Интернет-магазине. Здесь представлены две точки ветвления –

для выбора способа поиска товара и для принятия решения о покупке. При-

сутствуют три линейки синхронизации: верхняя – отражает разделение на

два параллельных процесса, средняя отражает и разделение, и слияние про-

цессов, а нижняя – только слияние процессов. Дополнительно на этой диа-

грамме показаны две дорожки – дорожка покупателя и дорожка магазина,

которые разделены вертикальной линией. Кажд

ая дорожка имеет имя и фик-

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

венности.

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

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



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

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

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

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

каталога

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

поиска

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

товара

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

корзину

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

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

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

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

Подготовка к

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

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

корзине

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

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

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

Интернет-ма га з инПокупатель

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

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

ской организации. Такое бизнес-моделирование и есть основное ее назначе-

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

программного приложения.

(

–

)

Настоящий стандарт распространяется на автоматизированные систе-

мы (АС) для автоматизации различных видов деятельности (управление,

проектирование, исследование и т. п.), включая их сочетания, и устанавлива-

ет состав, содержание, правила оформления документа «Техническое задание

на создание (развитие или модернизацию) системы».

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

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



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

В этот раздел включают: полное наименование системы и ее условное

обозначение; шифр темы или шифр (номер) договора; наименование пред-

приятий (объединений) разработчика и заказчика (пользователя) системы и

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

сте-

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

чания работы по созданию системы; сведения об источниках и порядке фи-

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

татов работ по созданию системы (ее частей), по изготовлению и наладке от-

дельных средств (технических, программных, информационных) и про-

граммно-технических (программно-методическ

их) комплексов системы.

(

)

Здесь указывают вид автоматизируемой деятельности (управление,

проектирование и т. п.) и перечень объектов автоматизации, на которых

предпо

лагается ее использовать. Для АСУ дополнительно указывают пе

речень

автоматизируемых органов (пунктов) управления и управляемых объектов.

Приводят наимено

вания и требуемые значения технических, техноло-

гических, производственно-экономических или других показателей объекта

автоматизации, которые должны быть достигнуты в результате соз

дания АС,

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

В данном разделе приводят: кратки

е сведения об объекте автомат

иза-

ции или ссылки на документы, содержащие такую информацию; сведения об

условиях эксплуатации объекта автоматизация и характеристиках окружаю-

щей среды.

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

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

Состав требований к сист

еме, включаемых в данный раздел ТЗ на АС,

устанавливают в зависимости от вида, назначения, специфических особенно-

стей и условий функционирования конкретной сист

емы. В каждом подразде-

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

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



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

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

темам соответствующего вида.

Требования к стру

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

водят: перечень подсистем, их назначение и основные характеристики, тре-

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

вания к способам и средст

вам связи для информационного обмена между

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

ваемой системы со смежными системами, требования к ее совместимости, в

том числе указания о способах обмена информацией (автоматически, пере-

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

жимам функциони-

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

развития, модернизации системы.

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

водят: требования к численности персонала (пользователей) АС; требования

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

выков; требуемый режим работы персонала АС.

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

раметров, характеризующих степ

ень соответствия системы ее назначению.

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

нию процессов, к отклонениям параметров объекта управления; номер мето-

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

роятностно-временные характеристики, при которых сохраняется целевое на-

значени

е системы.

Требования к надежности. Включают: состав и количественные зна-

чения показателей надежности для системы в целом или ее подсистем; пере-

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

бования к надежности, и значения соответствующих показателей; требования

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

к методам оценки и контроля показателей надежности на разных стадиях

создания сист

емы в соответствии с действующими нормативно-технически-

ми документами.

Требования по безопасности. Включают требования по обеспечению

безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте

технических средств системы (защита от воздействий электрического тока,

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

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



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

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

ням освещенности, вибрационных и шумовых нагрузок.

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

затели АС, задающие необходимое качество взаимодействия человека с ма-

шиной и комфортность условий работы персонала.

Требования к эксплуатации, техническому обслуживанию, ремонту

и хранению. Включают: условия и регламент (режим) эксплу

атации, кото-

рые должны обеспечивать использование технических средств (ТС) системы

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

обслуживания ТС системы или допустимость работы без обслуживания;

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

сонала и ТС системы, к параметрам сетей энергоснабжения и т. п.; требова-

ния по ко

личеству, квалификации обслуживающего персонала и режимам его

работы; требования к составу, размещению и условиям хранения комплекта

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

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

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

(ведомстве) заказчика.

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

ечень собы-

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

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

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

дят: требования к радиоэлектронной защите средств АС; требования по стойко-

сти, устойчивости и прочности к внешним воздействиям (ср

еде применения).

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

нии которых должна быть обеспечена патентная чистота системы и ее частей.

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

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

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

программных средств, типовых математических методов и моделей, типовых

проектных решени

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

установленных ГОСТ 6.10.1, общесоюзных классификаторов технико-

экономической информации и классификаторов других категорий в соответ-

ствии с областью их применения, требования к использованию типовых ав-

томатизированных рабочих мест, компонентов и комплексов.

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

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



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

Дополнительные требования. Включают: требования к оснащению

системы устройствами для обучения персонала (тренажерами, другими уст-

ройствами аналогичного назначения) и документацией на них; требования

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

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

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

(

)

Здесь приводят: по каждой подсистеме перечень функций, задач ил

и их

комплексов (в том числе обесп

ечивающих взаимодействие частей системы),

подлежащих автоматизации; при создании системы в две или более очереди –

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

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

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

реализации каждой функции (задачи или комп

лекса задач), к форме пред-

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

времени выполнения, требования одновременности выполнения группы

функций, достоверности выдачи результатов; перечень и критерии отказов

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

В з

ависимости от вида системы приводят требования к математическо-

му, информационному, лингвистическому, программному, техническому,

метрологическому, организационному, методич

ескому и другие видам обес-

печения системы.

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

требования к составу, области применения (ограничения) и способам исполь-

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

алгоритмов, подлежащих разработке.

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

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

еме; к ин-

формационному обмену между компонентами системы; к информационной

совместимости со смежными системами; по использованию общесоюзных и

зарегистрированных республиканских, отраслевых классификаторов, унифи-

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

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

процесса сбора, обработки, передачи данных в системе и предс

тавлению

данных; к защите данных от разрушений при авариях и сбоях в электропита-

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

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



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

нии системы; к контролю, хранению, обновлению и восстановлению данных;

к процедуре придания юридической силы документам, продуцируемым тех-

ническими средствами АС (в соответствии с ГОСТ 6.10.4).

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

к применению в системе языков программирования высокого уровня, языков

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

бования к кодированию и декодированию данных, к языкам ввода-вывода

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

области (объекта автоматизации), к способам организации диалога.

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

купных п

рограммных средств. А также требования: к независимости про-

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

рационной среды; к качеству программных средств, а также к способам его

обеспеч

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

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

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

к видам технических средств, в том числе к видам комплексов технических

средств, программно-технических комплексов и других комплектующих из-

делий, допустимых к использованию в системе; к функциональным, конст-

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

обеспечения системы.

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

тельный перечень измерительных каналов; требования к точности измерений

параметров и (или) к метрологическим характеристикам измерительных ка-

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

системы; перечень управляющих и вычислительных каналов системы, для

которых необходимо оценивать точностные характеристики; требования к

метрологическому обеспечению технических и программных средств, вхо-

дящих в состав измерительных каналов системы, средств, встроенного кон-

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

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

ческой ат

тестации (государственная или ведомственная) с указанием порядка

ее выполнения и организаций, проводящих аттестацию.

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

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

или обеспечивающих эксплуатацию; к организации функционирования сис-

темы и порядку взаимодействия персонала АС и персонала объекта автома-

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

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

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



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

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

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

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

(

)

Содержат

ься перечень стадий и этапов работ по созданию системы в

соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций –

исполнителей работ, ссылки на документы, подтверждающие согласие этих

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

ветственного (заказчик или ра

зработчик) за проведение этих работ.

Кроме того приводят: перечень документов по ГОСТ 34.201, предъяв-

ляемых по окончании соответствующих стадий и этапов работ; вид и поря-

док проведения экспертизы технической документации (стадия, этап, объем

проверяемой документации, организация-эксперт); программу работ, направ-

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

темы (при необходимости); перечень работ по метрологическому обеспече-

нию на всех стадия

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

организаций-исполнителей (при необходимости).

Указыв

ают: виды, состав, объем и методы испытаний системы и ее со-

ставных ч

астей (виды испытаний в соответствии с действующими нормами,

распространяющимися на разрабатываемую систему); общие требования

к приемке работ по стадиям (перечень участвующих предприятий и органи-

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

приемочной документации; статус приемочной комиссии (государственная,

межведомственная, ведомственная).

Здесь нео

бходимо привести перечень основных мероприятий и их ис-

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

ции к вводу АС в действие.

В перечень основных мероприятий включают: приведение поступаю-

щей в систему информации (в соответствии с требованиями к информацион-

ному и лингвистическому обеспеч

ению) к виду, пригодному для обработки

с помощью ЭВМ; изменения, которые необходимо осуществить в объекте ав-

томатизации; создание условий функционирования объекта автоматизации,

при которых гарантируется соответствие создаваемой системы требованиям,