2. По крайней мере первый день целиком посвящайте прослушиванию; отложите выяснения на второй или третий день.
3. Обратите внимание на то, кто представляет прослушиваемых: коммерческий директор или сам руководитель программным обеспечением.
4. Обратите внимание на используемые термины. Используется ли, например, слово «модульность»? «Упрятывание информации»?
5. Требуйте четкого определения каждого термина.
6. Попросите посмотреть текущую схему организации работ и краткие резюме ведущих разработчиков.
7. Попросите посмотреть документацию по стандартам; обратите внимание на даты их изменения.
Кадры и инструментарий
Руководитель разработкой программного обеспечения должен заботиться об очень многих вещах, но два момента являются определяющими — люди, которые будут выполнять работу, и средства, которыми они будут это делать. Выделение людских ресурсов может быть двояким! С упором на количество или на качество. В крупных разработках нам нужно и то и другое! Ключом к успеху является качество. Правильно подобранные люди способствуют успеху всего проекта, и наоборот. Хорошие работники стоят тех денег, которые им платят; но встречаются они редко!
После завершения планирования и проектирования необходимо привлечь к работе большое количество людей. Здесь опять нас ждут неприятности. Мир страдает от хронического недостатка разработчиков программного обеспечения. Не надо недооценивать суровости такого положения. Если вы по плану должны выполнить работу в 120 человеко-лет за три года, но не сможете найти больше 20 квалифицированных специалистов, ваши 120 человеко-лет могут потребовать целых 6 лет. Компании по производству программного обеспечения сталкиваются с той же проблемой, поэтому передача кому-нибудь контракта на разработку не гарантирует вас от встречи с этой ситуацией.
Поскольку средства, используемые для программирования, очень сильно влияют на производительность труда, от них также сильно зависит успех или неудача проекта. В предыдущих главах мы уже обсуждали этот вопрос.
Среди самых основных инструментов можно упомянуть вычислительные машины, формирующие рабочие программы, программное обеспечение, выполняемое на этих машинах, людей, разбирающихся в вопросах поддержания рабочего состояния инструментальных средств, системы тестирования, а также механизмы управления конфигурацией.
Часто приходится сталкиваться с проблемой недостаточной мощности центрального процессора, на котором должно работать инструментальное программное обеспечение. Этот недостаток приводит к увеличению времени ожидания решения и снижению производительности труда. Преодолеть беды, вызванные плохим инструментарием, удается редко; графики из-за него срываются, а затраты увеличиваются.
Тем, кто отваживается первым использовать новый язык программирования или операционную систему, это обычно очень дорого достается.
Купить или сделать
Наиболее ответственным можно считать решение купить готовое программное обеспечение или построить его самому. Обсудим сначала само это решение и последствия, к которым оно приводит, а затем посмотрим, из каких компонент оно состоит. (См. рис. 6.23.)
Выбор — покупать или строить самим — в первую очередь зависит от наличия людей, способных вести разработку программного обеспечения. Если в моей организации таких людей нет, то мне ничего не остается, как решиться на покупку. Но, даже если такие люди найдутся, перед нами может встать необходимость решить, какие именно разработки им поручить.
Вообще говоря, если можно приобрести стандартный пакет, который сможет работать на моей системе, следует его купить. Это может сэкономить скудные, быстро становящиеся еще более скудными ресурсы разработчиков программного обеспечения. И, несмотря на большие затраты на аппаратуру, такое решение обычно оказывается приемлемым.

Рис. 6.23. Покупать или создавать программное обеспечение самому.
Стандартный пакет имеет и свои достоинства, и свои недостатки. (См. табл. 6.23.) Но, невзирая на некоторые минусы, при малейшем шансе на успех мы должны использовать стандартное обеспечение.
Таблица 6.23 «3а» и «против» стандартных пакетов
Преимущества |
Недостатки |
Доступен сразу же |
Универсален и, значит, не очень точно подходит |
Модифицируется и исправляется поставщиком |
Тратит некоторые ресурсы ЦП |
Позволяет использовать разработчиков программного обеспечения на других работах |
Не точно соответствует данной прикладной области |
Зависит от некоторой посторонней организации |
Разрабатывать самим или заказывать на стороне
Если программное обеспечение нужно разрабатывать, должны ли мы делать это сами или можно заказать его на стороне? Посмотрите на табл. 6.4 — в ней перечислены все «за» и «против».
Читать дальше