Разработка логической модели программного изделия

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

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

Логическая модель должна удовлетворять следующим прави­лам:

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

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

3. Связи между функциями (функциональными блоками модели) минимизируют.

4. Каждая функция может разделяться не более чем на 7 под­функций следующего уровня.

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

6. Для каждой функции приводятся входные данные.

7. Каждой функции соответствует список выходных данных (вы­ходных отчетов).

6.4. Классификация требований к программному изделию

Требования к программному изделию систематизируются в со­ответствии с классификацией, которая будет описана далее, и со­держат следующие категории:

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

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

Количественные требования нецелесообразно фиксировать в виде качественных характеристик типа "быстрый ответ", а следует записывать, например, в виде "время ответа должно быть не более Х сек", или вместо "в большинстве случаев" указывать "для Y% случаев среднее время ответа должно быть менее Z сек" и т. п.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.5. Атрибуты требований к программному изделию

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

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

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

3. Приоритет, указывающий некоторый порядок очеред­ности при планировании работ и при проектировании изделия.

4. Стабильность отражает степень постоянства требо­вания. Здесь приводятся все те требования, которые могут быть из­менены на протяжении ЖЦПИ в результате получения дополни­тельной информации об изделии.

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

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

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

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

Документ Требования к программному изделию

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

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

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

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

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

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

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

Этапы разработки требований пользователя и требований к программному изделию в практике разработки программных изде­лий в нашей стране рассматриваются в схеме ЖЦПИ как стадия разработки Технического задания.

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

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

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

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

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

Таким образом, первые три пункта описывают проблему авто­матизации.

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

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

6. Иерархическая функциональная диаграмма программного из­делия, отражающая иерархию функций и подфункций.

7. Описание данных — схем потоков данных, всех структур дан­ных и взаимосвязей между ними.

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

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

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

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

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

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

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

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

13. Технические и программные средства, на базе которых должно работать программное изделие. Здесь указываются тип и требуемые ресурсы ЭВМ, а также — в среде каких программных средств должно функционировать разрабатываемое изделие.

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

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