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

Для более подробного изучения процесса проектирования описание ЖЦ ПП может быть детализировано более подробно, как, например, предлагается в /?/. Приведем эту более подробную детализацию в виде таблицы соответствия традиционно выделяемых этапов ЖЦ и более детализированного описания ( таблица 1.1).

Таблица 1.1 - Детальное описание ЖЦ ПП.

Традиционные этапы ЖЦ ПП	Составляющие части этапов разработки
Анализ	Формулировка требований и постановка целей Предварительное внешнее проектирование
Проектирование	Детальное внешнее проектирование Проектирование структуры системы Проектирование структуры программных модулей Проектирование базы данных
Кодирование	Проектирование логики программных модулей
Тестирование	Тестирование комплексного программного средства Отладка комплексного программного средства
Сопровождение	Внедрение в опытную эксплуатацию Внедрение в промышленную эксплуатацию Сопровождение программного продукта

Поясним содержание детализированных этапов и методики, которые применяются при выполнении этапов ЖЦ ПП.

USPEV

VVOD

ANALIZ

REZ

ZACH_VED

KORR

ITOG_VED

POLET

REITING

EKZ_VED

Рисунок 1.6. Пример системной архитектуры

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

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

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

Предварительное внешнее проектирование.

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

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

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

Однако, кроме ответа на вопрос, что должна делать программа, для создания конкурентоспособных ПП в ходе выполнения этого этапа должны быть получены четкие ответы и на ряд других вопросов:

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

• что представляют собой входные данные;

• какими должны быть выходные данные;

• какими ресурсами располагает проектировщик.

Детальное внешнее проектирование

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

- текстовое описание,

- структурированный естественный язык,

- таблица решений,

- дерево решений,

- визуальный язык,

- блок-схема,

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

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

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

ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа ‘да-нет’. Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО. Левая часть ТР содержит собственно описание условий и действий, а в правой части перечисляются все возможные комбинации условий и, соответственно, указывается, какие конкретно действия и в какой последовательности выполняются, когда определенная комбинация условий имеет место.

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

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

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

б) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки;

в) если очередной символ не находится в заданном диапазоне, (положим, от ‘а’ до ‘я’), то подать звуковой сигнал и вернуть код ошибки;

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

Таблица решений для данного примера приведена ниже ( таблица 1.1).

Здесь ‘Д’ означает ‘да’, ‘Н’ - ‘нет’, 1,2 - помеченные действия выполняются в указанном порядке.

Таблица 1.1 - ТР для функции выбора символов из входного потока

Условия	1	2	3	4	5	6	7	8
С1 символ управляющий?	Д	Д	Д	Д	Н	Н	Н	Н
С2 буфер заполнен?	Д	Д	Н	Н	Д	Д	Н	Н
С3 символ от ‘a’ до ’я’?	Д	Н	Д	Н	Д	Н	Д	Н
Действия
D1 подать звуковой сигнал	1	1	1	1	1	1		1
D2 вернуть код ошибки (>0)	2	2	2	2	2	2		2
D3 увеличить значение счетчика и вернуть его							2
D4 поместить символ в буфер							1

Заметим, что если выполняется условие С1, то нет необходимости в проверке условий С2 и С3. Поэтому комбинации условий 1,2,3,4 могут быть заменены обобщающей комбинацией (Д, -, -), где ‘-’ означает любую из возможных альтернатив (в данном случае Д или Н).

Аналогично комбинации условий 5 и 6 могут быть заменены обобщающей комбинацией (Н, Д, -). Редуцированная таким образом ТР будет иметь вид таблицы 1.2.

Таблица 1.2 Редуцированная ТР

Условия	1	2	3	4
С1 символ управляющий?	Д	Н	Н	Н
С2 буфер заполнен?	-	Д	Н	Н
С3 символ от ‘a’ до ’я’?	-	-	Д	Н
Действия
D1 подать звуковой сигнал	1	1		1
D2 вернуть код ошибки (>0)	2	2		2
D3 увеличить значение счетчика и вернуть его			2
D4 поместить символ в буфер			1

Методика построения ТР заключается в следующем:

а) определить все условия и действия в спецификации;

б) вписать действия и условия в таблицу;

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

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

Отметим, что на основе ТР легко осуществить кодирование программы на языке высокого уровня, таком, как Pascal.

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

Литература

1. Липаев В.В. Управление разработкой программных комплексов. М.: Финансы и статистика, 1993. - 286 с.

2. Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение).-М.: Издательство ‘Лори’ 1996.- 242 с.

3. Валеева Р.Г. Методические указания к выполнению схем при документировании программного обеспечения (электронный вариант).

4. В.Н. Мукасеева, А.Ю. Хасанов Специфицирование и тестирование программ. Методические указания к курсовой работе по дисциплине ‘Технология программирования’ для студентов направления 552800 - Информатика и вычислительная техника- Уфа, 1999.