360 Часть III: Управление проектами и группами

• Пре-бета

• Бета

• Бета-тестирование вне компании

• Замораживание пользовательского интерфейса

• Перед завершением

• Коэффициенты надежности

• Последняя проверка целостности

• Выпуск продукта

• Анализ продукта после его выпуска

Библиография

По вопросу о контроле качества программных продуктов можно порекомен­довать бестселлер Американского общества контроля качества (American Society for Quality Control) Principles of Quality Costs (Campanella, 1990). Он будет очень полезен тем, кто захочет внедрить в своей компании систему контроля затрат на качество продукта. Кроме того, интересны книги таких авторов, как Джуран и Грайне (Juran & Gryna, 1980), а также Фейгенбаум (Feigenbaum, 1991).

В главе 3 уже рассказывалось о стадиях разработки, и многие определен­ные там концепции используются в данной главе. Гласс (Glass, 1992) рассмат­ривает этапы разработки программного продукта с точки зрения руководителя проекта, помогающего программистам улучшить его качество.

Чем приходится поступаться разработчикам программного обеспечения

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

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

• надежностью продукта;

• количеством и глубиной его функций;

Глава 13: Объединяющая 361

• деньгами, необходимыми для выполнения дальнейшей работы;

• сроками выпуска продукта.

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

• Надежность. Чтобы удешевить продукт и выпустить его быстрее, проще всего сократить время тестирования и оставить в программе множество ошибок. Однако, даже если этого не делать, в продукте все равно останется некоторое количество ошибок, которые могли бы быть выявлены в ходе дальнейшего тестирования. Ведь тестирование

— процесс бесконечный, но так или иначе когда-нибудь приходит­ся остановиться.

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

• Деньги. Бывает, что для успешного завершения проекта необходимо пойти на дополнительные затраты. Возникшие проблемы можно решить таким образом: купить дополнительный инструментарий, нанять высокопрофессиональных консультантов или подключить дополнительный персонал. Последний вариант используется чаще всего, однако это не всегда помогает. Ведь чем больше людей рабо­тает над проектом, тем больше возникает всевозможных проблем и тем выше его стоимость. Руководящие сотрудники вынуждены от­влекаться от своих основных задач, организуя работу нового персо­нала. В результате это может даже затянуть весь процесс разработки. (См. Брукс (Brooks, 1995).) Это касается дополнительного подклю­чения к работе как программистов, так и тестировщиков. В конце проекта и тот, и другой варианты могут серьезно дестабилизировать работу всей команды.

• Дата выпуска. Если проект выбивается из графика, его руководи тель может отложить выпуск. Однако это может обойтись компании крайне дорого.