Организуя испытания программного изделия, необходимо иметь четкий ответ на вопрос Где кончается процесс оценки и начинается процесс отладки программного обеспечения Прежде всего важно ограничить деятельность испытателей, возложив на них только обязанность фиксировать факт наличия ошибки им не следует разрешать диагностировать причины ошибок и, более того, указывать точное место их возникновения. Если не проводить в жизнь такое разделение труда, то никогда не удастся отделить задачи разработки от обязанностей испытателей и разработчики будут уповать на то, что группа испытаний сама завершит отладку программ. Надо также тщательно продумать вопрос о том, на кого следует возложить ответственность за компоновку программных средств в систему или за обеспечение единства программных, микропрограммных и аппаратных средств ЭВМ. В условиях, когда в большом проекте участвуют несколько фирм-подрядчиков, [c.156]
Впрочем, на практике все оказывается не так уж и просто. Крупные фирмы порой тратят до пяти-десяти млн. долларов на RM-системы и получают при этом совершенно неудовлетворительные результаты. Менее 30% компаний, использующих систему RM, считают, что им удалось окупить соответствующие вложения. Основные проблемы связаны вовсе не с программным обеспечением (жалобы на него поступали только в 2% случаев). RM-Forum объясняет неудачи следующими причинами организационные преобразования (29%), политика/инерция компании (22%), непонимание принципов RM (20%), ошибки планирования (12%), неправильное использование RM (6%), бюджетные проблемы (4%), программные сбои (2%), неправильные рекомендации (1%), прочее (4%).56 [c.203]