Структурное проектирование, текущий и целевой процессы

TL;DR

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

Структурное проектирование

Для описания процессов полезно отдельно обсудить методы проектирования. Разные способы проектирования уместны в разных частях модели.

Самый классический вариант — это структурное проектирование. Как следует из названия, в основе подхода лежит выделение определённой структуры решаемой задачи и её последующая декомпозиция.

Декомпозиция — процесс разделения задачи на несколько более простых и независимых друг от друга подзадач.

Структурное проектирование подразумевает, что у нас есть три типа базовых конструкций, которые мы можем вкладывать друг в друга произвольным образом:

• Последовательное исполнение;
• Ветвление;
• Цикл.

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

Структурное проектирование в свою очередь можно разделить на три подхода:

• Нисходящее проектирование (сверху вниз);
• Восходящее проектирование (снизу вверх);
• Проектирование вширь.

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

Восходящее проектирование работает от обратного: мы определяем набор базовых подзадач и из них пытаемся собрать задачи более высокого уровня до тех пор, пока не сможем выполнить исходную задачу. Тут, скорее всего, переложить пример на код проще :)

Проектирование вширь работает немного иначе: мы применяем пошаговую детализацию для одного конкретного сценария использования (чаще всего это успешный сценарий) и далее уточняем крайние случаи.

На практике эти подходы применяются вместе в той или иной пропорции. Например, проектирование вширь применяется непосредственно при моделировании процессов ИС, а нисходящее проектирование — при реализации этих процессов в виде компонентов ПО.

As-is и To-be

При проектировании процессов для дополнительного анализа полезно разделить текущий и целевой процесс.

As-is описывает, как процесс выполняется сейчас: вручную, в старой системе, через таблицы, документы, звонки или внешние сервисы. Здесь важно найти проблемы текущего процесса, а не просто переписать его шаги.

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

Это разделение помогает не моделировать “как есть” как будто это уже проектное решение. Иногда текущий процесс нужно сохранить, иногда изменить, а иногда убрать лишний ручной шаг за счёт новой функции системы.