4.2.2. Разработка ПО, АСУ, проектирование

4.2.2. Разработка ПО, АСУ, проектирование

Универсумный подход применим к рассмотрению вопросов, связанных с разработкой программных комплексов автоматизированный систем управления (АСУ) [43]. Если классический сетевой график работ представляет только количественные характеристики процесса выполнения работ, то универсумное описание позволяет сосредоточиться на качественном описании процесса разработки АСУ. В зависимости от сложности проекта он может быть описан как ПФУ (УФУ-7), а может представлять и более детальное описание последовательности этапов выполнения работ в привязке к должностным обязанностям разработчиков, например, как УФУ-13 (рис. 4.3), соответствующей классу 6U3.

Последовательность основных этапов разработки программного обеспечения (ПО) АСУ в виде УФУ соответствует последовательности протекания U-потока по универсумным контурам, включающим фреймы:

– восходящего U-потока: S-1–2–3–4-5;

– концептуальной обработки: 6–7–8,

– нисходящего U-потока: 9–10–11–12–13.

Интеллектуальный каскад описания 14–15–16–17–18 стратифицирует должностную (качественную) подчинённость процесса управления проектом. Общее описание этапов проектирования допускает переходы по контурам на соседние уровни стратификации, циклические процессы, проходящие через разные контуры, а также рекурсивные обращения на различных этапах проектирования.

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

S-каскад универсума описывает начальные стадии проектирования (получение ответов на вопросы «Что и почему надо делать?»), I-каскад – должности специалистов соответствующих уровней («Кто и что должен делать?»), а R-каскад – процесс создания ПО («Как и для чего это будем делать?»)[112].

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

– обеспечивает единый контекст взаимодействия всех участников проекта на основе общей терминологии и лучшего понимания всей последовательности этапов разработки;

– позволяет выработать более точные процедуры взаимодействия проектных подразделений, за счёт чего можно резко снизить различного рода потери, связанные с «размытостью» границ ответственности исполнителей;

– позволяет усовершенствовать и универсализировать программный инструментарий проектировщиков, что создаёт основы более оперативной и качественной реализации разработок [42].

Рис. 4.3. U-методика разработки программного обеспечения для АСУ

Любые самые изощрённые методологии проектирования информационных систем – On Target, Microsoft Business Solution Partner Methodology, OneMethodology, Application Implementation Method [21, 36] и др. оптимально, эффективно и единообразно могут быть представлены в едином универсумном формате. Это чрезвычайно полезно для сравнительного анализа и выделения в каждой методологии всех удачных решений с последующим их объединением в едином проектном комплексе.

Конечно же, представленный здесь процесс проектирования разработки АСУ легко переносится на другие области человеческой деятельности как методология, позволяющая осуществлять проектирование изделий заданного уровня качества.

Данный текст является ознакомительным фрагментом.