Документирование разработки программного продукта.
Как было показано на рисунке 1.1. ЖЦ ПП сопровождается разработкой таких документов, как потребность в автоматизации, функциональная архитектура, системная архитектура и программный продукт. Остановимся подробнее на содержании этих документов, сопровождающих процесс разработки программ.
Потребность в автоматизации - в технике подобный документ называется техническим заданием (для его обозначения часто используется аббревиатура - ТЗ). Этот документ содержит описание целей автоматизации (или целей разрабатываемого программного продукта) с точки зрения пользователя ( или заказчика ПП).
В качестве примера можно привести следующий вариант ТЗ.
Разработать автоматизированную систему анализа успеваемости студентов одного факультета, которая позволяла бы:
получать итоговые ведомости успеваемости по отдельным академическим группам и по предметам;
получать списки неуспевающих студентов в академической группе и по предметам;
получать рейтинговые ведомости успеваемости студентов в академической группе и по предметам;
хранить и отображать ‘историю’ успеваемости студента до момента окончания вуза.
Словесная формулировка целей разрабатываемого ПП, как правило, сопровождается формами входных и выходных документов, перечислением отделов или других служб организации, которые являются источниками входной информации, указанием периодичности и сроков получения выходных документов, а также сроков хранения архива и другой подобной информацией (в данном тексте не приводятся).
Функциональная архитектура включает формализованное описание предъявляемых к ПП требований как с точки зрения пользователя, так и с точки зрения разработчика программ. В технике аналогичный документ называется техническими требованиями (аббревиатура - ТТ). В состав функциональной архитектуры должны входить: описание функций ПП, требуемых режимов функционирования среды, в которой будет реализовываться программный продукт.
Описание функций ПП удобно представлять в виде дерева целей, как на рисунке 1.4, на котором изображены основные и обеспечивающие функции, соответствующие приведенному выше техническому заданию.
Системная архитектура представляет собой документ, отражающий модульно-иерархическую структуру проектируемого программного продукта с подробным описанием функциональных спецификаций отдельных модулей. Последнее есть ни что иное, как блок-схемы программ (в ГОСТ они называются схемами программ) и другие схемы, описанные в том же ГОСТ. Следуя Винеру формулу программного продукта можно записать как ‘программный продукт = коды программ + проект’. Под проектом разработчики понимают окончательное и исчерпывающее обоснование и описание средств реализации поставленных целей.
ь
Автоматизация анализа
успеваемости студентов Ввод
информации об успеваемости Обработка
информации об успеваемости Ввод
информации из зачетной ведомости Корректировка
инф-и об успеваемости Ввод
результатов экзаменов Восстановление из
архив. копий Защита
от несакц. доступа Сохранение
архив. копий Получение
итоговой ведомости успеваемости Получение
списков неуспевающих Получение
рейтинговой ведомости успеваемости .
. . . . 
Вывод результатов
анализа
.
. . . .
Рисунок 1.4. Пример функциональной архитектуры
При документировании проекта разработки ПО применяют схемы:
работы системы, в которой формализуется процесс выполнения программы, взаимодействие с пользователем и данными;
программ (или иначе блок-схем), в которых формализуется алгоритм обработки данных;
данных, в которых уточняются потоки данных между процессами и (или) носителями данных;
взаимодействия программ, отображающих путь активации программ и взаимодействий с данными;
ресурсов системы, отображающих конфигурацию блоков данных и обрабатывающих блоков, требуемую для решения задачи или набора задач.
Правила оформления схем описаны в ГОСТ 19.701-90 и /3/.
Общие рекомендации к выполнению схем следующие:
схемы выполняются без соблюдения масштаба, действительное пространственное расположение составных частей изделия в схеме не учитывается или учитывается приближенно;
в схемах применяют условные графические обозначения: чаще всего прямоугольники или другие простые фигуры. Размеры условных графических обозначений и толщина составляющих их линий должны быть одинаковыми на всех схемах проекта;
допускается пропорциональное изменение условных графических обозначений;
условные графические обозначения составных частей узла устройства допускается изображать уменьшенными по сравнению с узлами;
линии связи и линии графических обозначений должны быть одной толщины. Рекомендуемая толщина линий – 0.3- 0.4 мм ( пределы изменения толщины – от 0.2 мм до 1.0 мм);
линии связи должны состоять из вертикальных и горизонтальных отрезков и иметь наименьшее число возможных изломов и точек пересечения.
Структура проектируемого программного продукта представляется в виде схемы деления изделия на составные части (ГОСТ 2.711-82). Линии связи выполняются со стрелками, направленными от комплектующих к узлам (снизу вверх), как показано на рисунке 1.6. Наименование изделия и его составных частей помещается внутри условного обозначения. Допускается данные о составных частях изделия помещать в таблице, расположенной под схемой деления.
Условных графические обозначения составных частей изделия приведены на рисунке 1.5.
а) новые б) покупные в) заимствованные
разрабатываемые изделия изделия или
изделия и составные
составные части
части
Рисунок 1.5 Условные графические обозначения составных частей изделия
Приведем таблицу соответствия функций и разрабатываемых модулей для рассматриваемого нами примера разработки автоматизированной системы учета успеваемости.
Таблица 1.1 – Соответствие функций и реализующих их модулей
|
Наименование функции обработки информации |
Наименование модуля |
|
Автоматизация анализа успеваемости студентов |
USPEV |
|
Ввод информации об успеваемости |
VVOD |
|
Обработка информации об успеваемости |
ANALIZ |
|
Вывод результатов анализа |
REZ |
|
Ввод информации из зачетной ведомости |
ZACH_VED |
|
Корректировка информации об успеваемости |
KORR |
|
Получение итоговой ведомости успеваемости |
ITOG_VED |
|
Получение списков неуспевающих |
POLET |
|
Получение рейтинговой ведомости успеваемости |
REITING |
|
Ввод результатов экзаменов |
EKZ_VED |
|
Восстановление из архивных копий |
IZ_ARH |
|
Защита от несанкционированного. доступа |
SANKS |
|
Сохранение архивных. копий |
V_ARH |
Допустим, что модули восстановления из архивных копий, сохранения архивных копий и защиты от несанкционированного доступа разрабатывались ранее для другой АСОИ, но применимы и для вновь разрабатываемой системы анализа успеваемости. При этих условиях схема деления изделия на составные части будет выглядеть так, как показано на рисунке 1.6.