* Очевидно, использование средств CM может принести гораздо больше пользы, если они будут интегрированы со средствами разработки приложений. Например, SourceSafe (Microsoft) может быть, а может и не быть самым лучшим средством контроля версий ПО, однако тот факт, что оно тесно интегрировано с Visual Basic, является весомым аргументом в его пользу. Аналогично, многие другие средства разработки приложений интегрированы с PVCS (InterSolv), ENY/Developer (IBM) или другими подобными средствами CM.

* Средства тестирования и отладки – многие из нас автоматически включают эти средства в «базовый» набор средств разработки приложений, позволяющих создавать, компилировать и выполнять код. Однако, когда мы перешли от онлайновых приложений на мэйнфреймах к клиент-серверным системам с графическим пользовательским интерфейсом, то постепенно поняли, что необходим совершенно новый набор средств тестирования; в то же время средства таких поставщиков, как SQA и Mercury Interactive, ещё не получили достаточного распространения в тех организациях, где мне удалось побывать. Аналогично, проектные команды, разрабатывающие приложения в среде Internet, скорее всего нуждаются в полностью новых средствах тестирования и отладки.

* Средства управления проектом (оценка, планирование, PERT/GANTT и т.д.) – обычно их считают средствами менеджера проекта и, наверное, так оно и есть; возможно, только менеджеру проекта приходится каждый день пересчитывать «критический путь». Однако, к той же категории следует отнести такие средства оценки, как ESTIMACS (Computer Associates, автор – Howard Rubin), CHECKPOINT (Software Productivity Research) и SLIM (Quantitative Software Management). Эти средства, по моему мнению, являются достаточно важными, поскольку они позволяют в ходе выполнения проекта динамически пересматривать планы и сроки.

* Наборы повторно используемых компонент – если проектная команда знакома с концепцией повторного использования ПО, и если она рассматривает её как стратегическое оружие, позволяющее достичь высокого уровня продуктивности разработки, то набор повторно используемых компонент должен быть в списке тех средств, которые «необходимо использовать». Это может быть набор компонент VBX для Visual Basic, библиотека классов ParkPlace Digitalk Smalltalk или библиотека классов MFC для C++ (Microsoft) ; разумеется, можно также использовать компоненты, разработанные другими проектными командами в организации. Выбор компонент обычно зависит от используемого языка программирования, и это ещё одна проблема, нуждающаяся в выработке единого подхода со стороны проектной команды.

* CASE-средства для анализа/проектирования – некоторые проектные команды рассматривают CASE-средства как «костыли» для новичков, а другие считают их не менее важными, чем текстовые процессоры. Я сам отдаю предпочтение простым, недорогим и гибким CASE-средствам; кроме того, я избегаю рекомендовать какой-либо конкретный продукт или поставщика, поскольку самым разумным ответом на вопрос, какие CASE-средства использовать, будет «это зависит от …». В самом деле, как заметил Doug Scott, может вообще не понадобиться никакой технологии:

Как я говорил ранее, самая большая проблема, связанная с CASE-средствами, заключается в том, что они поддерживают (а иногда навязывают) определённую методологию, которую проектная команда не понимает и не желает использовать.

6.2 Средства и процессы

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