УНИВЕРСУМНАЯ МЕТОДИКА ОПИСАНИЯ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В.И. Масликов (Дальневосточный государственный гуманитарный университет,
г. Хабаровск, [email protected])
Предлагается методика описания процесса разработки программного обеспечения, основанная на идее ранжирования этапов работ по критерию соотношения материальных и информационных потоков. Показано, что этапы создания разработки соответствуют универсумной функции управления. Делается вывод о том, что универсумный подход повышает оперативность и качество разработок.
Ключевые слова: универсум, разработка программ, программотехника, автоматизация проектирования, функция управления, организационная структура, управление, программирование.
Описанием жизненного цикла программного обеспечения (ПО) занимались и продолжают заниматься многие исследователи [1-2]. Тем не менее, несмотря на большое число оригинальных предложений, к настоящему времени так и не создана научно систематизированная классификация процессов, сопровождающих разработку программ. Можно согласиться с тем, что, в принципе, традиционный подход к разработке ПО АСУ, найденный еще в 70-80 гг. прошлого века, не претерпел существенных изменений.
Универсумная методология разработки, основанная на эволюционном развитии как онтологической, так и гносеологической стратификации объектов исследования, открывает возможности разработки и внедрения более технологичных процедур процессов автоматизации предприятий.
Универсумные описания среды разработки ПО
Универсумное описание как возрастающее соотношение меры информационной (по отношению к материальной) составляющей объектов, явлений и процессов характерно для многих компонентов, в среде которых разрабатывается ПО. На рисунке 1 приведены универсумы различных классов: касающихся стратификации типов памяти ЭВМ (рис. 1а), процесса обмена данными между вычислительными системами по модели International Standards Organization (OSI, рис. 1б) и иерархии программных кодов, циркулирующих в компьютерной системе при разработке ПО (рис. 1в).
Универсумный подход применим к разработке программных комплексов любой сложности. Например, вариабельные автоматизированные информационные системы (АИС) правомерно рассматривать как результат процесса проектирования, включающего спиральный анализ и синтез с переходом по различным рангам и уровням моделирования с использованием различного класса языков моделирования, в которых на верхнем слое используются принципы управления с ориентацией на учет человеческого фактора, а на нижнем слое - машинно-ориентированные языки программирования и представления данных с организацией на компьютерный, формальный аспект. В этом случае АИС представляет собой некую пирамиду моделей представления - пирамиду знаний [3]. Очевидно, что при ее выстраивании в АИС автор вполне правомерно опирается именно на универсумную онтологию [4].
Развертывание принципов универсумного подхода к разработке ПО, учитывающего вышеупомянутые процедуры анализа и синтеза, приводит к необходимости рассмотрения универсумной функции управления.
Универсумное описание процесса разработки ПО
Универсумная функция управления (УФУ) -целостная совокупность разнокачественных действий, описывающая процессы и особенности протекания, преобразования и реорганизации ^/-потоков в универсуме. На рисунке 2 представ-
6U ВНУТРЕННЯЯ ПАМЯТЬ ЭВМ 7U УРОВНИ МОДЕЛИ 081 8U ПО
6 РП (Регистровая память) 7 Прикладной уровень 8 Разрабатываемое приложение
5 ОП (Оперативная память) 6 Представительский 7 Объектная среда разработки ПО
4 Flash-память 5 Сеансовый 6 Компоненты на языках высокого уровня
3 HDD (Жесткий диск), FDD 4 Транспортный 5 Компиляторы, интерпретаторы
2 ППЗУ (Программируемая) 3 Сетевой 4 Операционная система
1 ПЗУ (Постоянная память) 2 Канальный 3 Ассемблерные программы
1 Физический 2 Машинные коды, BIOS
1 Логика аппаратной части (Hardware)
а) б) в)
Рис. 1 Универсумные описания среды разработки ПО
44/ 1 Х-*.!------ /6)
® ! / -Т.-^г2 ту/г. (7)
© / _ ^------1 ©
к А ®
(Р
©
лены 9 этапов УФУ, соответствующие универсуму класса 4ГО. Коротко суть этапов изложена в работе [4]. Это описание согласуется с понятием полной функции управления (ПФУ) как классической, так и достаточно общей теории управления [5]. Поскольку УФУ методологически описывает самую общую последовательность этапов управления, это позволяет легко объединять и дискретизировать соседние стратификационные уровни и каскады в зависимости от класса универсума. ПФУ является частным случаем УФУ. Соответствие между этапами ПФУ и УФУ показано в таблице.
Этапы выполнения УФУ класса 4Ш и ПФУ (сокращенно)
Рис. 2. Девять этапов УФУ в универсуме класса 4и3
Этап ПФУ Этапы УФУ Краткое содержание этапа по УФУ Содержание этапа ПФУ^^^В
1 Стимул - 8 Возникновение фактора Опознавание факторов среды (объективных явлений), с которыми сталкивается интеллект
Различение - 1 Перцепция
2 Селекция - 2 Согласование с эталонами, стереотипами Формирование стереотипа (навыка) распознавания фактора на будущее
3 Анализ - 3 Идентификация вариабельного решения Формирование вектора целей управления в отношении фактора
4 Абстрагирование - 4 Поиск принципиально новых вариантов Формирование концепции управления и частных целевых функций управления
Интеллект -5 Выработка новой концепции решения
Обобщение - 6 Конкретизация нового решения
5 Синтез - 7 Компиляция готовых вариантов решения Организация и реорганизация целесообразных управляющих структур
Мультиплексирование - 8 Использование эталонов, стереотипов
Исполнение - 9 Реализация действий
6 Рекурсия - ■ Переход на этапы 1, 2, 3, 4 Контроль (наблюдение) за деятельностью структур в процессе управления
7 Реакция - Я Отработка фактора Ликвидация существующих структур в случае ненадобности или их поддержание
Процесс разработки ПО, являющийся объектом данного исследования, можно связать с ПФУ
как с последовательностью этапов управления объектом. Однако более адекватно этот процесс может быть описан посредством УФУ.
На рисунке 3 представлена обобщенная структура процесса разработки ПО в виде универсума класса 6ГО, в котором фреймы представляют главные этапы разработки (функционалы) ПО, содержащие основные виды проектных работ, должностей ответственных лиц и соответствующую этапам подготовки документацию.
Конечно же, в различных организациях функционалы, наименования подразделений и должностей (универсумных фреймов) могут существенно отличаться, тем не менее, универсумная схема процесса разработки ПО в любом случае останется неизменной.
Основные этапы разработки ПО
Последовательность этапов разработки ПО в виде УФУ соответствует последовательности протекания и-потока по универсумным контурам, включающим фреймы:
- восходящего Г -потока: 8-1-2-3-4-5-6; концептуальной (интеллектуальной) обработки: 6-7-8, 14-15-16-17-18;
- нисходящего Г -потока: 8-9-10-11-12-13.
Общее описание этапов проектирования допускает переходы по контурам на соседние уровни стратификации, циклические процессы, проходящие через разные контуры, а также рекурсивные обращения на различных этапах проектирования.
Отметим, что данное описание ограничивается рассмотрением только универсума «Разработка ПО» без затрагивания вопросов прохождения и-потоков по внешним для него контурам универсума «Заказчик», то есть вопросы внедрения и эксплуатации ПО, обучения пользователей и тому подобные вопросы в данном описании не рассматриваются.
^-каскад универсума описывает начальные стадии проектирования («Что делать?»), /-каскад -должности ЛПР соответствующих уровней («Кто отвечает?»), а ^-каскад - процесс создания ПО («Как делать?»).
Нижний универсумный уровень - работа с заказчиком - содержит максимум материальной составляющей и-потока, высший уровень - аналитика - оперирует преимущественно информацией.
Результаты исследования
Рассмотрение универсумной модели этапов разработки ПО позволяет сделать выводы о том, что универсумная методология, примененная к процессу проектирования ПО, обеспечивает единый контекст взаимодействия всех участников проекта на основе общей терминологии и лучшего понимания всей последовательности этапов разработки; позволяет выработать более точные про-
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
- Анализ, оценка реализуемости всего проекта
- Согласование системных про тиворечий
О
ТЕХНИКО-ЭКОНОМИЧЕС КОЕ ОБОСНОВАНИЕ
- Спецификация новых комплексов ПО, анализ всех спецификаций
©
Спецификация сложных настраиваемых комплексов
- Изучение прецедентов
- Обобщение и поиск компиля тивных решений
О
Спецификация
на общесистемное ПО - Формирование списка необходимых типовых задач (компонентов)
О
Спецификация форматов входных и выходных данных, стандартов обмена аппаратной части с ПО, типовые задачи и ме тоды
©
Спецификации на структуру входных и выходных данных, рассмотрение требований заказчика, аппаратные ограниче ния
О
м
ФОРМУЛИРОВКА ТРЕБОВАНИЙ К ПО
- Внешняя спецификация (формулировка требований заказчика)
СИСТЕМНЫЙ аналитик
- Выработка концептуальной модели (методологии разработ ки) всего проекта
О
РУКОВОДИТЕЛЬ ПРОЕКТА
- Разработка архитектуры ПО, НИР, выбор методики, идеоло гии разработки ПО
©
ИНЖЕНЕР-СИСТЕМОТЕХНИ К©
- Определение методов разработки, проектирование комплексов
ПРОГРАММИСТ-КОНСТРУКТОР
- Сборка из специальных компонент (повторное использова ние кода)
®
ПРОГРАММИСТ
- Выбор стандартных библиотек, компонентов, функций, классов, подпрограмм, модулей и т.д.
МЕНЕДЖЕР ПО РАБОТЕ С ЗАКАЗЧИКАМИ
Поддержка стандартов разработки ПО, согласование требований сторон
©
©
ЭСКИЗНЫЙ ПРОЕКТ
- Определение целей ПО в со ответствии с концепцией
- Планирование проекта
©
ТЕХНИЧЕСКИЙ ПРОЕКТ
- Внутренняя спецификация комплексов, интерфейсы
- План работ, сетевой график их выполнения
©
©
РАБОЧИЙ ПРОЕКТ
- Новые системы разработки, программирование новых комплексов
- Интерфейс, документация (типовые задачи)
ПРОГРАММИРОВАНИЕ слож-ч^) ных, уникальных задач - Проектирование компонент интерфейса, программная документация
ПРОГРАММИРОВАНИЕ
типовых задач (компонент)
■ Тестирование ПО
■ Эксплуатационная документа ция
©
ОПЫТНАЯ ЭКСПЛУАТАЦИЯ
- Конфигурирование продукта, настройка интерфейса пользо-
©
®
СОПРОВОЖДЕНИЕ
- Интегральная оценка качества (удобства использования) ПО
ПЕРЕДАЧА ПО В ЭКСПЛУАТАЦИЮ
- Пользовательская документация, обучение пользователей
Рис. 3. Универсумное описание процесса разработки ПО класса 6U3
цедуры взаимодействия проектных подразделений, за счет чего можно резко снизить различного рода потери, связанные с размытостью границ ответственности исполнителей; дает возможность усовершенствовать и универсализировать программный инструментарий проектировщиков, что создает основы для более оперативной и качественной реализации разработок.
Литература
1. Попов Д.В. Информационная поддержка распределенной разработки программного обеспечения на основе
онтологии // Программные продукты и системы. 2008. № 1. С. 81-84.
2. Шильников П.С. Компьютерная поддержка построения онтологий // Программные продукты и системы. 2006. N° 2. С. 50-52.
3. Фомина И.К. Вариабельные автоматизированные информационные системы // Программные продукты и системы. 2007. № 4. С. 50-51.
4. Масликов В.И. Универсум: эволюция мыслящей материи. Хабаровск: Изд-во Приамурского географического общества, «РИОТИП» краевой типографии, 2008. 192 с.
5. Достаточно общая теория управления: Постановоч. матер. учеб. курса фак-та прикладной математики - процессов управления СПбГУ (1997-2003 гг.) / СПб, 2003. 420 с.