2Спецификации программного обеспечения

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

Определение целей и требований к программному обеспечению

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

В качестве примера можно привести следующий вариант ТЗ.

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

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

• получать списки неуспевающих студентов в академической группе и по предметам;

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

• хранить и отображать ‘историю’ успеваемости студента до момента окончания вуза.

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

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

Принятые на этом этапе проектные решения определят облик будущей АСОИУ., поэтому для принятия удачных проектных решений необходимы весьма обширные знания о достоинствах и недостатках тех или иных проектных решений. Для выполнения этой части проектирования необходимы все знания, которые Вы приобретете в вузе, поэтому сейчас мы не будем останавливаться на этой проблеме более подробно.

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

Следует отметить, что наиболее общей рекомендацией для этого этапа является структурирование (декомпозиция) целей программного продукта по схеме: основные цели —> подцели 1-го уровня. . . —>. . . подцели i-го уровня —>. . . . . —> подцели n-го уровня —> функции для пользователя ПО.

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

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

Автоматизация анализа успеваемости студентов

Ввод информации об успеваемости

Обработка информации об успеваемости

Ввод результатов экзаменов

Вывод результатов анализа

. . . . .

Ввод информации из зачетной ведомости

Корректиров-ка информа-ции об успеваемости

Получение итоговой ведомости успеваемости

Получе-ние списков неуспевающих

Получе-ние рейтин-говой ведомости

. . . .

Восстановление

из архив-

ных копий

Защита от несакцио-нирован-ного доступа

Сохране-ние архив-ных копий

Рис. 2.1. Пример функциональной архитектуры

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

Документирование на этапе проектирования

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

Функциональные спецификации есть ни что иное, как блок-схемы программ (в ГОСТ 19.701-90 они называются схемами программ) и другие схемы, описанные в том же ГОСТ /5/.

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

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

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

• программ (или иначе блок-схем), в которых формализуется алгоритм обработки данных;

• данных, в которых уточняются потоки данных между процессами и (или) носителями данных;

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

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

Правила оформления схем описаны в ГОСТ 19.701-90 /5/ и /6/.

Общие рекомендации к выполнению схем следующие:

• схемы выполняются без соблюдения масштаба, действительное пространственное расположение составных частей изделия в схеме не учитывается или учитывается приближенно;

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

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

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

• линии связи и линии графических обозначений должны быть одной толщины. Рекомендуемая толщина линий – 0.3- 0.4 мм ( пределы изменения толщины – от 0.2 мм до 1.0 мм);

• линии связи должны состоять из вертикальных и горизонтальных отрезков и иметь наименьшее число возможных изломов и точек пересечения.

Структура проектируемого программного продукта представляется в виде схемы деления изделия на составные части (ГОСТ 2.711-82). Условных графические обозначения составных частей изделия приведены на рисунке 2.2. Наименование изделия и его составных частей помещается внутри условного обозначения.

а) новые б) покупные в) заимствованные

разрабатываемые изделия изделия или

изделия и составные

составные части

части

Рис. 2.2. Условные графические обозначения составных частей изделия

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

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

Т а б л и ц а 2.1

Функции и соответствующие им модули задачи учета успеваемости

Наименование функции обработки информации	Наименование модуля
Автоматизация анализа успеваемости студентов	USPEV
Ввод информации об успеваемости	VVOD
Обработка информации об успеваемости	ANALIZ
Вывод результатов анализа	REZ
Ввод информации из зачетной ведомости	ZACH_VED
Корректировка информации об успеваемости	KORR
Получение итоговой ведомости успеваемости	ITOG_VED
Получение списков неуспевающих	POLET
Получение рейтинговой ведомости успеваемости	REITING
Ввод результатов экзаменов	EKZ_VED
Восстановление из архивных копий	IZ_ARH
Защита от несанкционированного. доступа	SANKS
Сохранение архивных. копий	V_ARH

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

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