Проверьте философию утилит вашего поставщика

 Критично для бизнеса

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

1. Говорят, что выбор утилиты разработки  -  то же самое, что свидание, т.е., если вы не удовлетворены, можно легко переключиться на что-то новенькое. Вы согласны? А во что обходится такое переключение? Значит ли это, что надо держаться за приложения, которые поддерживают стандартные языки, например Си, Си++ или Кобол?

2. Языки четвертого поколения дают нам возможность более быстрой кодировки, но имеют потенциально меньшую гибкость и более низкую производительность. Однако языки третьего поколения требуют больше времени на кодирование и сложнее в освоении. Какие приложения лучше всего выбрать для отдела так, чтобы они прослужили как можно дольше? Когда нам надо предпочесть Си, Си++ языку четвертого поколения?

3. Затраты на обслуживание и модернизацию ПО совершенно не поддаются контролю. Как ваша утилита поможет справиться с этой проблемой?

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

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

6. Многие эксперты советуют выбирать "чистопородные" средства разработки (конструкторы приложений, инструменты тестирования и моделирования и т.д.). Если вы поставите себя на место разработчика, что вы порекомендуете?

7. Дайте определение, что такое быстрая разработка приложений? Зачем она нам нужна? Как ваша утилита поддерживает ее?

8. Согласно The Standish Group многие руководители полагают, что разработка ПО сейчас пребывает в худшем состоянии, чем десять лет назад. Почему? Не слишком ли много внимания мы уделяем инструментарию в ущерб технике?

9. Разработчики ПО концентрируют внимание в основном на непосредственных задачах разработки, таких как выбор технологии/инструментария, продолжительность цикла, уровни функциональности. В результате многие программы не отвечают нуждам пользователей, для которых они были предназначены. Является ли эта проблема отражением сравнительной незрелости индустрии ПО? Если это так, как изменить эту позицию и поднять уровень зрелости?

Мои друзья из Hurwitz Consulting Group обещали мне дать беспристрастные ответы на эти вопросы. (Я сейчас занята записью трехсот с лишним сообщений для автоответчика  -  для вас!) Сообщите им по факсу ваше имя и адрес: (617) 965-6901. А потом подвергнете вашего поставщика допросу.

С Кристиной Комафорд можно связаться по MCI Mail: 371-9004, CompuServe (74603,3664), Internet (74603.3664@Compuserve.com) или факсу: (708) 374-1124.

Кристина Комафорд