Некоторые проблемы создания больших информационных систем в учреждении

Горбачев В.Г.

Введение

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

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

• системы автоматизированного проектирования;

• системы электронного документооборота предприятия (конторские системы);

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

• системы управления сложными технологическими комплексами

• и т.д.

Именно о такого рода системах, - и, в первую очередь, системах электронного документооборота, - пойдет речь в данном документе.

Словарь терминов

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

Предметная область - конкретная область деятельности человека, характеризующаяся своими понятиями, предметами и методами исследования.

Системный анализ - научная дисциплина, направленная на исследование (познание) систем различной физической природы.

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

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

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

Когда создается некоторая крупная информационная система, то у руководителя сразу же встают следующие вопросы:

• Кому поручить разработку информационной системы?

• Сколько будет стоить вся система (имеется в виду создание и развертывание системы)?

• За какие сроки она будет создана?

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

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

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

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

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

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

Однако, начнем все по порядку.
 

Некоторые свойства больших программно-технических систем

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

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

Во-вторых, большая система всегда создается надолго. Говорят, что она является долгоживущей. Это особенно верно в отношение системы электронного документооборота, которая будет развиваться и совершенствоваться пока живет и развивается само учреждение. Процесс развития, а также устранения ошибок программной системы называется СОПРОВОЖДЕНИЕМ. Можно утверждать, что большая система никогда не будет разработана окончательно, потому что она, как правило, эксплуатируется в постоянно изменяющихся условиях. Поэтому в большую систему разработчиками в обязательном порядке необходимо закладывать способность к модифицированию и развитию. Это могут обеспечить только опытные высококвалифицированные коллективы разработчиков. На то, будет ли система развиваемой или нет, сильно влияют инструментальные средства и методы разработки. которыми пользуются эти коллективы. Такие средства стоят очень дорого (десятки тысяч долларов), но они быстро окупаются.

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

Системно-аналитические работы требуют наличия достаточно большого коллектива опытных системных аналитиков высокой квалификации (и соответственно, высокооплачиваемых), причем коллектив этот должен работать НЕПОСРЕДСТВЕННО В ВАШЕМ ГОРОДЕ ВСЕ ВРЕМЯ, пока система живет и развивается. (Впрочем, и системный анализ не дает стопроцентных гарантий того, что будет учтено все, однако, с его проведением вероятность ошибки резко падает, а при качественном анализе серьезных ошибок может не быть вообще).

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

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

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

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

Покупать или разрабатывать?

Введение

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

Дело в том, что производительность труда проектировщиков и программистов в тех коллективах, которые уже перешли на новые технологии (32-х разрядная техника, объектно-ориентированное проектирование и программирование, новейшие операционные системы типа MS Windows, CASE-технологии) превышает производительность труда "отставших" коллективов примерно в 10-20 раз! Из этого следует, что новый продукт с теми же функциями сейчас можно создать почти во столько же раз быстрее. Поэтому фразы типа "мы уже работаем над этой программой 10 лет..." сегодня скорее являются отрицательной, чем положительной характеристикой программы, поскольку она несет в себе объективно устаревшую технологию, не позволяющую легко развивать систему и делать ее открытой для интеграции в большие комплексы. Затраты на развитие системы, сделанной на основе старой технологии, сегодня намного превышают затраты на создание новой системы "с нуля".

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

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

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

Проблемы интеграции программных систем

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

Нужно сказать, что именно таким образом рушились в нашей стране все крупные проекты в области сложных программных систем. Дело в том, что чрезвычайно редко можно связать несколько систем друг с другом без того, чтобы не возникли непреодолимые проблемы, особенно, если их разработчики не соблюдали международные стандарты. Интересно, что многие специалисты отдают должное ситуации, когда в простейших, вроде бы, случаях два человека не могут договориться между собой (даже общаясь на одном языке). Но в отношение информационных систем считается, что подобной проблемы не существует (дескать, ее делал человек, значит легко может и переделать). К сожалению, не все так просто. Как раз для информационных систем куда как более характерна неспособность к интеграции, если такая задача при разработке программы специально не ставилась и, следовательно, не решалась. Два человека могут НЕ ХОТЕТЬ договориться, а две системы просто НЕ МОГУТ этого сделать, т.к. принципиально неспособны к компромиссам вследствие своей "неразумности". И, если возникает задача интеграции нескольких систем, разработанных разными коллективами для достижения разных целей, то связать их очень тяжело.

Здесь могут возразить: "А как же стандартные интерфейсы?" (правила и средства обмена информацией между системами). Можно сказать, что никак! Вопрос стоит не в этой плоскости. Сопряжение на интерфейсном уровне - необходимое, но недостаточное условие. Для больших и сверхбольших систем взаимная адаптация проводится НА КОНЦЕПТУАЛЬНОМ, СОДЕРЖАТЕЛЬНОМ, АРХИТЕКТУРНОМ УРОВНЕ. Одна из сопрягаемых систем может просто "не мочь" предоставить своим партнерским системам какую-то запрашиваемую ими информацию, т.к. ее, скорее всего, изначально не проектировали с такими свойствами. И, если общающиеся люди все-таки "договариваются сами", то большие программные системы нужно ПЕРЕДЕЛЫВАТЬ,- хотя бы в какой-нибудь своей части. И те, кто разрабатывал большие программы, хорошо знают, что для описания проблемы переделок очень подходящей аналогией является аналогия с карточным домиком, где не всякую карту можно убрать или заменить (и это больше, чем аналогия).

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

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

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

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

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

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

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

• Если разработчики используемой программы расположены не далеко,- в идеале в Вашем же городе,- то с ними можно договориться (очевидно, за деньги) о модификации их программы на предмет наделения ее свойством хотя бы минимальной интеграции.

• Часто предпочтительным является просто написание новой программы. Еще пару лет назад такая постановка вопроса могла бы снискать ее автору лавры дилетанта, но сегодня это часто становится предпочтительным. С учетом новой технологии разработок программ их можно разработать за короткий срок, затратив относительно небольшие ресурсы, по сравнению с той ситуацией, когда комплексная система, работая крайне неэффективно из-за необходимости "подстраиваться" под плохую программу, будет являться скорее обузой, чем помощником. Еще хуже, если заказчик потребует от исполнителя обеспечения совместимости интегрированной системы с уже имеющимися небольшими программами. Можно утверждать, что родится уродливое детище, не всегда поддающееся лечению. Еще Коперник, имея ввиду, астрологов, писал об их "методах" построения теорий из эклектических лоскутков по отдельности прекрасных: "Они как плохие скульпторы берут руку от Геракла, туловище от Венеры, голову от Апполона и, складывая вместе, получают не что иное, как чудовище." И действительно, только целостный подход, базирующийся на комплексном анализе, может позволить создать гармоничную систему.

Ввод данных

Очень часто и заказчики, и неопытные проектировщики забывают о существенном моменте, связанным с внедрением разработанной системы. Это касается ввода данных в систему (называемое наполнением баз данных). Финансовые ресурсы планируются на анализ, проектирование и разработку, но не на ввод данных, которыми должна будет оперировать система. Однако, без рассмотрения задач ввода данных можно создать мертворожденную систему, которая не будет продуктивной. Никому не нужен информационный комплекс в поликлинике, если в него не будут введены данные по больным. В больших системах все большое, - в том числе и количество данных для ввода. Например, если ввод в машину одного документа "История развития ребенка" составит 1 час (эйфорическая оценка), тогда ввод этих данных по поликлинике в целом составит величину порядка 125 рабочих человеко-дней или 6 месяцев.

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

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

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

Стратегия взаимоотношений заказчика и разработчика в задачах создания больших программно-технических систем

Кто будет разрабатывать информационную систему?

Этот вопрос сам по себе весьма сложен, поскольку от выбора исполнителя работ определяющим образом зависит, будет ли вообще сделано что-нибудь путное. Здесь мы не будем подробно рассматривать проблему выбора разработчика, - об этом будет сказано ниже - в разделе 6.Скажем лишь несколько слов о Генеральном подрядчике.

Если система большая, то вместо нескольких подрядчиков заказчику целесообразно иметь дело с одним - Генеральным (если, конечно, есть заслуживающая этот статус фирма).Должен ли Заказчик иметь дело с одним подрядчиком на работы, связанные с созданием системы, или с несколькими?

- И да, и нет.

"Да", потому, что, если система потеряла работоспособность, удобнее иметь дело с одним ответственным за систему без перспективы разборок споров, возникающих между субподрядчиками по типу "кто виноват?".

"Нет", потому что в столь большой задаче, как разработка весьма крупной (учрежденческой или корпоративной) информационной системы, никакая фирма в одиночку не справится со всем объемом работ.

Поясним эту концепцию.

Заказчик имеет дело с одним Генеральным подрядчиком, а уж последний может подбирать себе (если ему это необходимо) субподрядчиков. Такая схема взаимоотношений имеет следующие положительные моменты:

• Заказчик работает не с "симфоническим оркестром" исполнителей работ, которым надо умело дирижировать, а только с одним подрядчиком - Генеральным, который несет всю ответственность за разработанные подсистемы и всю информационную систему в целом (при условии ее правильной эксплуатации).

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

• Поскольку в результате проведения системного анализа проблемы Генеральный Подрядчик глубоко знакомится с задачей, то в значительной степени снижается и вероятность краха проекта в результате таких событий, как распад коллектива субподрядчика или не совсем порядочные действия последнего. В подобных случаях Генеральный Подрядчик может принять достаточно эффективные "пожарные" меры, например, взяться за разработку "провалившейся" подсистемы своими силами. Кроме того, хорошо знакомого с проблемой Генерального Подрядчика ни один субподрядчик не сможет ввести в заблуждение.

• Только при реализации описанной схемы Генеральный Подрядчик может и обязан взять на себя полную ответственность за работоспособность как системы в целом, так и ее подсистем. Роль единственного ответственного позволяет Заказчику не участвовать в спорах о том, кто виноват в неудовлетворительной работе системы, поскольку во всех случаях именно Генеральный подрядчик ставил задачу субподрядчикам и принимал от него работу. Генеральному Подрядчику остается только как можно оперативнее устранять неисправности. При реализации описанной схемы можно установить достаточно жесткие сроки восстановления работоспособности системы.

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

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

Что такое "обследование" и "системный анализ"?

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

• указанием функций организационной системы, которые должны быть автоматизированы;

• определением правил взаимодействия между человеком и машиной;

• описанием способов взаимодействия системы с ее окружением.

Иными словами, этап анализа и проектирования является критическим для создания эффективных и надежных систем.

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

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

• ОБСЛЕДОВАНИЕ СУЩЕСТВУЮЩЕЙ СИСТЕМЫ ОБРАБОТКИ ИНФОРМАЦИИ - описание того, как обрабатывается информация в организации до автоматизации.

• СИСТЕМНЫЙ АНАЛИЗ - определение функций, которые должна будет выполнять система, оптимизация структуры процессов обработки информации, построение информационной модели деятельности организации.

• Собственно ПРОЕКТИРОВАНИЕ - определение подсистем и правил взаимодействия между ними (интерфейсов).

• РАЗРАБОТКА (программирование) подсистем и их интерфейсов.

• ИНТЕГРАЦИЯ - объединение подсистем в единое целое.

• ТЕСТИРОВАНИЕ - проверка правильности работы системы.

• УСТАНОВКА (инсталляция) - введение системы в действие.

• ЭКСПЛУАТАЦИЯ - использование системы.

• СОПРОВОЖДЕНИЕ - исправление в процессе эксплуатации ошибок, невыявленных при тестировании, а также развитие системы (добавление новых функций).

Однако, при этом на каждом этапе применялись традиционные подходы, что обусловливало возникновение многих проблем после внедрения систем. Эксплуатационные расходы существенно превышали расходы на создание систем и продолжали стремительно расти по мере увеличения их сложности. Многие эксперты справедливо связывали рост эксплуатационных расходов с природой ошибок, допущенных в процессе создания системы. Исследования показали, что больше всего ошибок "закладывается" на этапах обследования, анализа и проектирования и гораздо меньше их возникает на этапах реализации и тестирования. Стоимость обнаружения и исправления ошибок увеличивается по мере прохождения этапов разработки (чем более поздний этап, тем выше стоимость). Например, исправление ошибки на этапе проектирования может стоить в 2 раза, на этапе тестирования - в 10 раз и на этапе эксплуатации - в 100 раз дороже, чем на этапе анализа. На обнаружение ошибок, допущенных на этапах анализа и проектирования, тратится примерно в 2 раза меньше времени, а на их исправление - примерно в 5 раз меньше времени, чем на те же процедуры в случае ошибок, допущенных на более поздних стадиях. Именно поэтому качественный системный анализ проблемы необходим, если заказчик и исполнитель хотят получить хороший результат в обозримые сроки и потратить на это только необходимые ресурсы.

Обратим особое внимание на этап обследования.

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

На данном этапе основными работами являются:

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

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

• Разработка (совместно со специалистами информатизируемой организации) рекомендаций по организационным проблемам работы учреждения в условиях перехода к работе с информационной системой.

Процесс решения задачи

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

• Заказчик комплексной системы,- если он сам не разрабатывает систему,- заказывает ее полностью одному Генеральному подрядчику, который несет ответственность ЗА ВСЮ систему и за ее дальнейшее сопровождение. Эта фирма (Генеральный подрядчик) должна быть опытной, иметь квалифицированных проектировщиков, ядро которых работает в штате, а не на полставки, и кроме всего прочего, владеет методологией создания больших систем. Задачей Генерального подрядчика является обеспечение ведения всех работ в рамках единой идеологии (концепции) и действенное руководство субподрядчиками.

• Генеральный подрядчик проводит предварительное обследование структуры организации, призванное оценить ресурсы, требуемые для проведения уточненного системного анализа (полное обследование).

• Генеральный подрядчик по результатам предварительного анализа переходит к полному обследованию существующей (до автоматизации) структуры обработки информации, а также системному анализу деятельности учреждения в вопросе обработки информации. Задачами этого этапа решения проблемы являются: изучение предметной области (построение ее функциональной и информационной модели), в которой предполагается функционирование системы, определение приоритетов в разработке, разработка концепции системы, определение требуемых для разработки, внедрения и сопровождения ресурсов (технико-экономическое обоснование) и сроков, выработка технического задания на систему, определение этапов разработки и внедрения системы (календарный план работ) и др. Именно после этого этапа Заказчик видит в достаточной подробности что он получит, в какие сроки и за какие деньги.

• Если Заказчик не готов идти на требуемые затраты, то на этом взаимоотношения участников теоретически могут закончиться (практически этого не бывает, поскольку качественный анализ дает объективные результаты, и заказчик может действовать "зряче"). И если желание продолжать работы осталось, денег и времени достаточно, то Генеральный подрядчик переходит к эскизному проектированию системы, в результате которого вырабатывается концепция системы, первичные спецификации и уточненное техническое задание. (Кстати, денег в целом может потребоваться больше, чем располагает заказчик. Тогда правильно планировать такую последовательность работ, при которой разрабатываемые в рамках целостного проекта подсистемы при свом внедрении ведут к получению заказчиком дополнительной прибыли, часть которой можно направлять на развитие работ. И так далее).

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

• Генеральный подрядчик переходит к техническому проектированию и реализации высокоприоритетных подсистем комплексной системы.

• По окончании разработок Генеральный подрядчик производит установку комплексов и обучение пользователей работе с системой.

• Далее Генеральный подрядчик сопровождает систему в течение оговоренного с Заказчиком срока.

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

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

Обычные заблуждения

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

Заблуждение 1: "Все программы можно интегрировать".

Предыдущее изложение в достаточно подробной степени касалось этой проблемы, и мы не будем ее еще раз рассматривать.

Заблуждение 2: "Вот купим вычислительную технику, установим вычислительную сеть, - и у нас все изменится к лучшему."

Не изменится.

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

Во-вторых, покупать технику без качественной постановки задачи просто ошибочно, поскольку:

• можно потратить деньги и купить такую технику, которая для вашей задачи затем окажется неподходящей (а требования к технике дает системный проект);

• даже, если у вас все будет развиваться хорошо и вы создадите первую версию информационной системы, на что уйдет по крайней мере несколько месяцев, за это время вычислительная техника уйдет вперед (уж больно быстро она развивается) и простоявшее купленное вами ранее оборудование окажется просто морально устаревшим. Цены на вычислительную технику падают в среднем на 15% в квартал (в долларовых ценах, естественно), а производительность при той же цене возрастает на 30%;

• ранняя необоснованная закупка техники выведет большие ресурсы "из игры", поскольку для техники не будет адекватной информационной системы, которая, собственно, и делает вычислительную систему эффективной в тех или иных применениях. Деньги на начальных этапах лучше потратить на постановку задачи, разработку системы, наполнение баз данных и решение организационных проблем, связанных с информатизацией. Конечно, технику можно покупать и раньше, особенно, если что-то на ней уже нужно делать, но покупки должны быть хорошо выверенными и не масштабными. Масштабность разумна тогда, когда для такой акции все подготовлено. Да и вообще крупные закупки не ведут ни к чему хорошему; впоследствии, когда техника устареет, опять слишком много новой техники придется покупать "за раз", тогда как эволюция часто лучше революции и много менее накладна.

Кстати, вообще нужно очень осторожно покупать вычислительную технику. Имеется в виду - не у всякой фирмы. Самый главный принцип здесь, если у Вас или нет достаточно грамотных специалистов в области информатики, или задуманная система весьма велика - это покупать, все хорошо продумав. Торговые фирмы могут "подставить" Вам некачественную технику за большие деньги, и Вы об этом можете никогда не узнать (она будет просто раза в 2 менее производительной, хотя и будет нормально работать). Но и это еще не все. Дело в том, что, если Вы не очень хорошо представляете какое оборудование Вам необходимо, то фирмы, торгующие оборудованием, могут "предложить" Вам либо слишком дорогую технику, либо слишком мощную, заведомо превышающую потребности Вашей задачи, а, возможно, и просто негодную по характеристикам. Торговые фирмы на то и торговые, что они не имеют никакого представления о том, как разрабатываются программные системы и какое оборудование для этих систем потребуется. Здесь не спасает даже их возможное умение устанавливать локальные вычислительные сети, - сеть это то же оборудование, только связанное вместе. Практически во всех случаях наиболее правильное для Вас решение - обратиться в фирмы-системные интеграторы (но не те, которые так себя называют - а так себя называют почти все фирмы, которые устанавливают, например, сети или решают узкие задачи "какие знают"). Действительные системные интеграторы, которые занимаются именно разработкой больших информационных систем - вот кто Вам нужен. Они понимают в проблемах использования вычислительной техники несравнимо больше других, поскольку используют технику непосредственно в своих разработках.
Торговым фирмам нужно продавать как можно больше техники. Для крупных фирм-разработчиков главное - решить всю задачу, - и в этом вся разница!

Заблуждение 3: "Надо разрабатывать программы под ту технику, которая имеется (или под недорогую)".

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

Стоимость работ можно представить формулой:

Стоим.техники + Стоимость постановки задачи + Стоимость решения организационных проблем + Стоим.разработки программ + Стоим. внедрения+Стоим.сопровождения + др.

Из этой формулы видно, что стоимость техники - не единственная составляющая в работах по информатизации. Для малых систем остальные составляющие малы и в расчет могут не приниматься. Поскольку до настоящего времени в большинстве учреждений создавались лишь небольшие программные системы, автоматизирующие очень узкие сферы деятельности его сотрудников, мало кто задумывался над тем, что другие составляющие формулы могут быть хотя бы соизмеримы с первой (многие и не знают о существовании этих составляющих). Оказывается, для больших программно-технических комплексов стоимость разработки программ и стоимость внедрения много больше, чем стоимость собственно техники, составляющая 10-15% всех затрат. Если речь идет о большой системе, разрабатываемой для слабой техники, то затраты на реализацию и внедрение во много раз больше стоимости не только этой слабой техники, но и даже более совершенной. Это определяется тем, что для техники с малыми возможностями, проектировщикам для того, чтобы реализовать функции сложной системы, приходится сильно "выкручиваться" (что обходится заказчику в дополнительные средства и сроки выполнения работ, усложняя также и сопровождение), тогда как на мощной технике эти же функции реализуются со значительно меньшими затратами (для больших систем "серьезные" функции на несовершенном инструменте вообще реализовать невозможно). Поэтому часто для организации-заказчика выгодны даже экстремистские действия; вообще не использовать слабые машины в этой задаче, поскольку разработка для них больших программ очень дорога, а сроки исполнения весьма велики. Сейчас, когда в области вычислительной техники произошел качественный скачок, в мире вообще перестали выпускать ту технику, которая имеется в наших организациях (речь идет о машинах типа IBM PC/AT 286, IBM PC/AT-386 или машин на процессорах SX, а теперь и машинах на 486 процессорах). Соответственно и новейшее инструментальное программное обеспечение, которое позволяет относительно легко создавать большие программно-технические комплексы, для малых персональных машин также не выпускается.

Справедливости ради нужно сказать, что экстремизм в нашем случае и не требуется; для имеющихся машин на ближайший год работы хватит. Их можно использовать для ввода баз данных, печатания отчетов, использования в опросных комплексах, в комплексах, работающих с диагностической аппаратурой и т.д. Важно только не покупать их в дальнейшем, так как все новые программы дешевле создавать для более мощных машин. Если опять обратиться к аналогиям, то можно привести следующую: до Дальнего Востока можно доехать и на простом велосипеде, но обойдется это все же дороже, чем на самолете. Может быть в первом случае и доехать не удастся.

Цель этого материала - пояснить, ту мысль, что средства, подходящие для малых задач, не подходят для крупных.

Заблуждение 4: "Только наша работа самая сложная, а программы создавать может каждый, тем более, если его этому учили в вузе".

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

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

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

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

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

Как и кому заказывать разработку программного обеспечения.

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

Что можно предложить для того, чтобы минимизировать возможные ошибки, которые особенно дороги в начале пути?

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

Тогда руководитель может реализовать следующие три стратегии:

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

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

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

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

3. Действовать без конкурса, и тогда весьма большое значение имеют следующие вопросы, которые руководитель должен задать себе и руководителям той фирмы, которую он рассматривает как кандидата на разработку [следует почитать прекрасную книгу руководителя Хьюстонского подразделения корпорации IBM Фокса "Программное обеспечение и его разработка"];

• Прежде всего необходимо хорошее и ясное описание того, что важно для вас и вашего будущего подрядчика. Если для составления такого описания Вам нужна помощь, не скупитесь на расходы. Она сохранит Вам в дальнейшем много денег.

• Требуйте, чтобы Вас познакомили с теми, кто будет работать по вашему контракту. Здесь Вам может потребоваться знакомство с руководителем разработки - причем самого высокого ранга,- который будет полностью отвечать за проектирование. От него полностью зависит Ваш успех или неудача. Достаточно ли он компетентен? Достаточно ли решителен в своих поступках? четко ли формулирует решения и мысли? Обладает ли он всеми необходимыми знаниями? Уклоняется ли он от вопросов или старается найти на них ответы? Осведомлен ли он о возможных ловушках, имеющихся в Вашем проекте? Знает ли он, что наибольшую опасность представляет ошибка в определении требований? Остерегайтесь навязывать ему свое собственное мнение по различным вопросам. Посмотрите: не путаются ли эти люди в Ваших каверзных вопросах? Если Вам удалось их запутать, - остерегайтесь. Вы выбираете не тех, кто будет потом торговать готовой продукцией, а тех, кто должен руководить ее разработкой. Кто еще входит в руководящую группу вашего заказа? Достаточно ли они свободны для этого? Заняты ли они еще в каких-нибудь проектах? Не приглашают ли их еще в какие-либо проекты? Или им поручается только Ваш проект?

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

• Достаточно ли велика выбранная Вами фирма, чтобы Ваш заказ был выполнен?

• Есть ли у нее резервы как людские, так и материальные, которые можно пустить в ход в кризисные ситуации (а такие ситуации при крупных разработках будут обязательно)?

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

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

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

Но из всех вышеперечисленных вопросов, которые должны интересовать Вас как Заказчика, самые важные все же следующие:

• Постоянность и величина коллектива разработчиков.

• Опыт фирмы в разработке крупных систем (имеются ли внедренные проекты и где?)

• Личности руководителей фирмы и проекта. Являются ли они в психологическом смысле лидерами? Владеют ли речью и легко ли формулируют свои мысли (при обязательной профессиональной компетентности)? Соглашаются ли они без предварительного анализа назвать Вам сроки исполнения работы и требуемые для этого ресурсы? Если они сделают это - не имейте с ними дела - и Вы сохраните свои деньги для более грамотного разработчика.

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

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

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

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