Понятие технологии программирования, жизненный цикл программы и постановка задачи

Постановка задачи. Оценка осуществимости

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

Можно, конечно, выполнить эту работу за свой счет (и многие крупные предприятия так и делают), но, во-первых, отношение к внутренним разработкам – более спокойное, а, во-вторых, оплаченный договор гарантирует серьезность намерений обеих сторон. К сожалению, часто бывает, что недобросовестные заказчики пользуются таким приемом, чтобы бесплатно получить идеи разработки или просто выполнить экспертизу оценок своих специалистов без всякого намерения передать разработку на сторону.

Постановка задачи – наиболее творческая часть ЖЦП, которая поднимает почти философские проблемы.

Требуется описать поведение разрабатываемой системы. Эта система получает какие-то сигналы из ее окружения, поэтому надо описать поведение окружения, но окружение само зависит и изменяется под влиянием системы, ее сигналов, особенно аварийных.

Разрешают это противоречие, постепенно уточняя поведение как системы, так и ее окружения. Для действительно важных систем заказчик требует разработки имитационных моделей системы и окружения, не уступающих по сложности и детальности самой системе. Была у меня однажды трагикомическая ситуация, когда военные заказчики потребовали модель системы, точно соответствующую реальной жизни. Никакие мои объяснения про сущность моделирования не помогали. Кончилось тем, что я сказал: "Хорошо, я сделаю такую модель, но саму систему делать не буду. Зачем? Ведь модель и так все делает". Это произвело на них впечатление. Хотя, конечно, стремиться к более точным моделям нужно всегда.

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

Однако, формализация формализации рознь. Тридцать лет назад бытовало мнение, что можно и нужно каждую задачу формально специфицировать с помощью логики предикатов чтобы можно было доказать корректность ее решения[6]. Для каждой программы P нужно задать предусловие A, описывающее состояние среды (в частности, переменных программы) перед исполнением программы, и постусловие S, описывающее состояние после завершения ее исполнения:

A {P} S

Очевидно, что A и S – несопоставимы, поскольку описывают состояние в разные моменты времени. Можно "протянуть" предусловие A через текст программы, изменяя его соответственно каждому проходимому оператору, при этом логическая формула предусловия фантастически быстро растет, например, после условного предложения будет дизъюнкция двух вариантов, описывающих текущие предусловия после веток then и else – мы же не знаем, какая именно ветка будет исполняться. Обозначим результат протягивания через A'. Тогда остается доказать истинность импликации A' => S, и программа корректна! Мы тоже потратили несколько лет, работая в этом направлении, например, Н. Ф. Фоминых в 1976-м году защитил под моим руководством дипломную работу, реализовав "протягиватель" для Алгола 68. Все эти предусловия и постусловия были очень громоздкими – много больше, чем текст программы и затраты на их создание – тоже.

Собственно доказательством теорем мы не занимались, опираясь на тот факт, что у нас в Ленинграде активно работала одна из лучших в мире группа математиков ТРЭПЛО (теоретические разработки эвристического поиска логического обоснования). Мы пригласили к нам в лабораторию системного программирования одного из самых активных ее членов Юрия Маслова – автора наиболее популярного в то время обратного метода выводимости [7] – выступить у нас на семинаре. Слушали его целый день, и к вечеру я осмелился спросить, когда же ЭВМ будет доказывать не учебные, а настоящие теоремы? Ответ был ошеломляющим. Сложные, но короткие – уже сейчас, длинные – никогда. Наш практический интерес к этой теме иссяк. Позже это направление трансформировалось в доказательство корректности преобразования одной программы в другую, проверку доказательства, сочиненного человеком, но это уже не имеет отношения к нашей теме.

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