Что может облегчить труд программиста?

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

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

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

Опыт, сын ошибок трудных

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

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

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

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

В рамках обсуждаемой темы уместно будет отметить следующие моменты:

1. Отставание документации от актуального состояния проекта.

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

2. Проблема уникальности проекта.

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

3. Проблема количества и качества сопровождения ПО.

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

Новые решения

Каким же видится выход из этой ситуации?

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

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

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

(Окончание следует)

Сергей ДМИТРИЕВ,
ПКП "Веспол",
boma98@yahoo.com