Intrusion detection system (система обнаружения вторжений)

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

Многие организации полагаются в защите информации на различные спосо­бы шифрования. Шифрование — это кодирование и скремблирование (шифро­вание путем перестановки и инвертирования участков спектра сигнала или групп символов) данных с целью обеспечения их безопасности или надежности переда­чи. Сообщение может быть закодировано при помощи секретного цифрового кода, называемого ключом шифра, и отправлено в виде набора символов. (Ключ может состоять из большого набора букв, цифр и других символов.) Для того что­бы прочесть его, необходимо воспользоваться подходящим ключом для расшиф­ровки. В число стандартов шифрования входят SSL (протокол защищенных со-кетов) и S-HTTP (протокол защищенной передачи гипертекста), используемые в Интернете. Они позволяют программе-клиенту и серверу автоматически вы­полнять процедуры кодирования/декодирования при обмене web-сообщениями. Существует множество альтернативных методов шифрования, однако по-на­стоящему широкое распространение получила только технология шифрования с «открытым ключом». Эта методика, изображенная на рис. 14.5, использует два различных ключа, один закрытый, а второй — открытый. Ключи связаны матема­тической зависимостью таким образом, что данные, зашифрованные одним из них, могут быть декодированы только при помощи второго. Чтобы отправлять и получать сообщения, корреспонденты вначале создают отдельные пары закры­тых и открытых ключей. Открытый ключ хранится в компьютерной директории, а секретный — в максимально защищенном месте. Отправитель зашифровыва­ет сообщение при помощи открытого ключа получателя. Получив письмо, реци­пиент использует свой закрытый ключ для его декодирования. Кроме него, этот ключ никому не известен, поэтому можно быть уверенным, что переписка оста­нется в тайне.

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

Согласно документу Electronic Signatures in Global and National Commerce Act, электронные подписи получили статус обычных подписей. Цифровая подпись использует шифрование с открытым ключом с целью присоединения цифрового кода к электронному сообщению для подтверждения его подлинности. Таким об­разом, сообщение ассоциируется с его отправителем, как и при использовании обычной подписи.

Важную роль в процедуре аутентификации играют цифровые сертификаты. Цифровые сертификаты — это файлы данных, используемые для установления идентичности отдельных людей, а также обеспечивающие защиту сетевых транз­акций (рис. 14.6). Система цифровых сертификатов пользуется услуги прове­ренной третьей стороны, Бюро сертификации (СА), для определения идентично­сти пользователей. Система СА может функционировать внутри организации или быть запущена во внешней компании, такой как VeriSign Inc. (штат Калифор­ния). Система регистрирует пользователей при помощи телефона, обычной поч­ты или при личной встрече. Полученная информация помещается в память сер­вера, который генерирует закодированные цифровые сертификаты, содержащие идентификационную информацию и копию открытого ключа пользователя. Сер­тификат удостоверяет, что открытый ключ принадлежит указанному лицу. Соб­ственный открытый ключ СА можно получить как через Интернет, так и в печат­ном виде. Получатель зашифрованного сообщения использует этот ключ для декодирования цифрового сертификата, приложенного к письму, проверяет, со­здан ли он СА, а затем получает открытый ключ отправителя и идентификацион­ную информацию, содержащуюся в этом сертификате. Используя полученную информацию, реципиент может отправить своему корреспонденту зашифрован­ный ответ. Система электронной сертификации может, например, помочь вла­дельцу кредитной карты и продавцу во взаимной проверке сертификатов, прежде чем они обменяются данными и совершат сделку.

Многие системы электронных платежей, работающие с кредитными картами, используют для шифрования данных SSL-протокол. Однако такая методика не позволяет удостовериться в том, что картой пользуется ее истинный владелец. Компании VISA International, MasterCard International, American Express и другие ведущие фирмы — эмитенты кредитных карт, а также многие банки используют протокол безопасных электронных транзакций (SET) для шифрования данных по операциям с кредитными картами, а также для их передачи через Интернет и другие открытые сети. На рис. 14.7 показано, каким образом работает SET-npo-

токол. Пользователь получает цифровой сертификат и специальный «цифровой бумажник». Бумажник и сертификат подтверждают идентичность пользователя и его кредитной карты. Когда он совершает покупки на web-сайте, использующем SET-протокол, сервер посылает сигнал, активизирующий электронный бумаж­ник. Последний зашифровывает платежную информацию и отсылает ее продав­цу, который декодирует сообщение и проводит сделку через свой банк. Затем банк продавца отсылает закодированную информацию эмитенту кредитной кар­ты пользователя, который подтверждает сделку или отказывает в ее совершении. В случае подтверждения платежеспособности покупателя банк продавца перево­дит средства на свой счет, а счет покупателя соответствующим образом изменяет­ся. После этого заказанный товар отправляется клиенту.

Разработка структуры контроля: выгоды и издержки

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

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

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

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

происшествие может случиться не чаще одного раза в год и привести к потере всего $ 1 тыс., нет смысла тратить $20 тыс. на то, чтобы иметь возможность его пред­отвратить. В том случае, если подобный сбой может происходить каждый день, то потери компании могут составить уже $300 тыс. и даже 100 тыс., затраченных на его предотвращение, не являются слишком высокой ценой.

В табл. 14.5 представлен пример оценки рисков для интерактивной системы, обрабатывающей 30 тыс. заказов в день. Вероятность обесточивания системы хотя бы один раз в год составляет 30%. Потери при обесточивании системы могут со­ставить от $5 до $200 тыс. для каждого случая в зависимости от длительности простоя. Вероятность хищений в течение года составляет около 5%, при этом убытки могут составить от $1 до $50 тыс. в каждом отдельном случае. Пользова­тели допустят ошибки с вероятностью 98% (применительно к годовому периоду), что может привести к потерям в размере от $200 до $40 тыс. Величина годовых потерь вычисляется путем умножения вероятности события на средний ущерб от него. После оценки рисков системные проектировщики стараются выявить наи­более уязвимые места системы, сбои в которых могут вызвать наибольший ущерб. В данном случае необходимо максимально снизить вероятность обесточивания системы и уменьшить количество пользовательских ошибок. Информирован­ность руководства обо всех мерах, которые можно принять с целью уменьшения рисков, также снижает возможный ущерб (Straub, Welke, 1998).

В некоторых случаях организации не в состоянии рассчитать вероятность того, что какое-либо событие произойдет, или не могут оценить возможный ущерб. В та­кой ситуации руководство может принять решение об использовании методик качественной оценки (Rainer, Snyder, and Carr, 1991).

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

ства управления. Комбинация средств управления для какого-либо отдельного приложения формирует его управляющую структуру.

Роль аудита в процессе контроля

Как руководство компании может убедиться в том, что средства контроля инфор­мационными системами работают достаточно эффективно? Чтобы ответить на

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

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

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

14.3. Обеспечение качества системы

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

Обеспечение качества программного обеспечения: методики и инструменты

Решение проблем качества программ включает в себя использование подходя­щих методик разработки систем, правильное распределение ресурсов на всех эта­пах создания и внедрения системы, использование метрик и тщательное тестиро­вание.

Структурированные методики

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

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

Методологии разработки отражают различные подходы к созданию информа­ционных систем. В гл. 10 описана технология объектно-ориентированной разра­ботки программного обеспечения. Традиционные структурные методики и авто­матизированное проектирование и создание программ (CASE) — другие примеры инструментов создания качественного программного обеспечения. Структуриро­ванные методики используются для документирования, предварительного ана­лиза и проектирования информационных систем еще с 70-х гг. прошлого века. Их структурированность заключается в том, что они выполняются поэтапно, при этом каждый последующий шаг основывается на результатах предыдущего. Та­кие методики являются «нисходящими», действуя начиная с верхнего, общего уровня до нижнего — максимально детализированного, иными словами — от об­щего к частному. К примеру, самый высокий уровень описания системы кадрово­го учета будет включать в себя основные функции, связанные с трудовыми ресур­сами предприятия: состав сотрудников, результаты их работы, льготы, зарплаты и соответствие нормам ЕЕО (Equal Employment Opportunity, равные возможно­сти занятости). Каждый из этих пунктов делится на составляющие компоненты следующего уровня. Например, льготы могут включать в себя пенсию, сбереже­ния, медицинское обслуживание и страховку. Данные «подпункты», в свою оче­редь, также подразделяются на отдельные элементы на следующем уровне дета­лизации.

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

Структурированный анализ

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

стему в виде отдельных модулей с различной степенью детализации. Данный вид анализа четко определяет, какие процессы или преобразования происходят в каж­дом модуле и как модули взаимодействуют друг с другом. Структурный анализ является основным инструментом для построения диаграммы информационных потоков данных (Data flow diagram, DFD) — графического отображения процес­сов, происходящих в отдельных элементах системы, и их взаимодействия друг с дру­гом (в виде потоков данных).

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

Данная диаграмма показывает, что студенты передают по почте регистрацион­ные формы, в которых содержатся имя, идентификационный номер и количество курсов, которые они хотят прослушать. Процесс 1.0 представляет собой проце­дуру проверки доступности курса, основанную на данных из курсового файла. В файле указано, какие курсы отменены, полностью заполнены и те, доступ на которые еще открыт. Затем Процесс 1.0 определяет, какой запрос студента можно принять, а какой — нет. В Процессе 2.0 студент зачисляется на курс, для которого ранее было получено подтверждение. Курсовой файл обновляется — в него вно­сятся имя нового студента, его идентификационный номер, а затем пересчиты-вается размер группы. Если достигнуто максимальное число студентов, то курс «закрывается». Процесс 2.0 также обновляет главный файл данных университе­та, добавляя туда информацию о новых студентах или изменения в личных дан­ных, уже существующих. После этого Процесс 3.0 отправляет каждому студенту письмо с подтверждением регистрации и списком курсов, на которые он зачис­лен. Курсы, на которые студент попасть не смог, также перечислены.

Диаграммы могут быть использованы для отображения процессов более высо­кого уровня или, наоборот, максимальной детализации деятельности предприя­тия. Благодаря применению многоуровневых диаграмм потоков данных сложный процесс может быть разбит с учетом нескольких последовательных уровней дета­лизации. Информационная система может быть разделена на подсистемы, каж­дой из которых будет соответствовать своя диаграмма потока данных высокого уровня. Такие подсистемы, в свою очередь, можно разделить на дополнительные подсистемы, которым будут соответствовать диаграммы потоков данных второго уровня и т. д.

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

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

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

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

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

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

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

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

Сторонники структурного программирования утверждают, что любая про­грамма может быть написана с использованием всего трех основных управля­ющих элементов или командных блоков (блоков инструкций): (1) простая после­довательность, (2) выбор и (3) итерация. Эти управляющие элементы представлены

на рис. 14.11.

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

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

Итерационная конструкция повторяет определенный участок кода до тех пор, пока тест на проверку условия дает положительные результаты. Здесь проверяет­ся условие S. Если результат положительный, то выполняется оператор Е, затем производится новое тестирование. Если результат теста не отвечает заданному условию, то Е пропускается и программа переходит к следующему оператору.

Блок-схемы

Составление блок-схем — один из самых cfapbix инструментов проектирования, который актуален по сей день. Блок-схема отображает поток данных внутри всей

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

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

System flowchart (блок-схема системы)

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

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

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

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

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

Автоматизированное проектирование и создание программ (CASE) Автоматизированное проектирование и создание программ — это автоматизи­рованная пошаговая методика разработки, обеспечивающая сокращение затрат времени на повторяющиеся действия, а также повышение общей эффективности работы проектировщика. Применение данной технологии позволяет разработчи­ку сконцентрироваться на творческих задачах, переложив всю рутину «на плечи» компьютера. Автоматизированное проектирование также упрощает подготовку сопутствующей документации и координацию работы членов команды. Они мо­гут получать доступ к общим файлам для оценки проделанной работы или улуч­шения результатов. Некоторые исследования показали, что системы, разработан­ные при помощи такой методики, являются более надежными и гораздо реже нуждаются в обслуживании. При правильном применении инструментов автома­тизированного проектирования можно достичь и более высокой эффективности системы. Многие такие инструменты предназначены для использования на пер­сональных компьютерах и обладают мощными и дружественными графическими интерфейсами.

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

♦ помогают в применении стандартных методик разработки;

♦ улучшают процессы коммуникации между пользователями и технически­ми специалистами;

♦ упорядочивают и устанавливают связи между различными компонентами и обеспечивают доступ к ним;

I Computer-aided software engineering (CASE) (автоматизированное про-| ектирование и создание программ)

! Автоматизация пошаговых методик разработки информационных систем и про­граммного обеспечения с целью сокращения затрат времени на повтордющи-j еся действия и повышения общей эффективности работы проектировщика.

♦ автоматизируют рутинные процессы, присутствующие в анализе и разра­ботке;

♦ автоматически генерируют программный код и тестируют его.

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

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

В информационном хранилище хранится вся информация, полученная от ана­литиков на различных этапах проекта. В нем находятся схемы информационных потоков, блок-схемы, схемы взаимосвязей между отдельными компонентами си­стемы, описания типов данных, спецификации процессов, форматы отчетов, заметки и комментарии, а также результаты тестов. Программы автоматизиро­ванного проектирования в настоящее время поддерживают приложения типа «клиент—сервер», объектно-ориентированное программирование и реинжини­ринг бизнес-процессов (Nissen, 1998).

Для того чтобы эффективно использовать технологии автоматизированного проектирования, необходимо поддерживать строгую дисциплину в организации. Каждый член команды разработчиков должен придерживаться общих соглаше­ний об именах и других стандартов, а также использовать в своей работе обще­принятые методики (Scott, Horvath, and Day, 2000). Распределение ресурсов при разработке системы

Подходы к распределению ресурсов при разработке информационных систем меняются со временем. Распределение ресурсов состоит в распределении временных и финансовых затрат, а также функций между сотрудниками на различных ста­диях разработки системы. Ранее разработчики концентрировали все усилия на программировании, и только около 1 % и средств уходило на системный анализ (создание спецификаций). Необходимо уделять этим аспектам больше внимания, что позволит в дальнейшем значительно сократить расходы на обслуживание но­вой системы. Правильное определение информационных потребностей органи­зации также может сократить число ошибок в программах, снизить временные и финансовые затраты (Domges, Pohl, 1998). В современных специальных изда­ниях утверждается, что системному анализу и созданию спецификаций необхо-