Unknown

Исследование британских компаний, проведенное компанией KPMG Peat Marwick McLintock (KPMG, 1990), показало, что "30% крупнейших компьютерных проектов в Великобритании значительно превышали бюджет, выполнялись сверхурочно, а если и завершались, то не справлялись с поставленными задачами". Кроме того, Willcocks (1992) утверждает, что "к 1992 году расходы Великобритании на ИТ превысили £ I0 млрд. в год", причем эта цифра не включает расходы государственного сектора. Все эти цифры вместе взятые свидетельствуют о том, что необходим мета-метод, хотя бы для того, чтобы сократить часть из этих примерно 3 млрд. фунтов стерлингов, потраченных впустую.

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

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

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

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

3.2. Теория

В этом разделе я рассматриваю две работы, посвященные выбору или классификации методологий разработки. Обе методики относятся к разработке компьютерных систем. Однако я считаю, что извлеченные из них уроки могут быть экстраполированы на разработку всей информационной системы, независимо от того, основана ли она на компьютерах, бумажной работе, взаимодействии с человеком или их сочетании, а также на других средствах передачи и хранения информации. Для того чтобы не превысить установленный объем статьи, я просто бегло проанализировал работы Коннора (Connor, 1985) и Олле (Olle, et. al.) (1991), чтобы выделить, на мой взгляд, их сильные и слабые стороны.

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