Глава 3: Типы тестов ... 57

Разработка программного обеспечения для американских воздушных сил обошлась (для одного компьютера) в S75 в пересчете на одну программную инструкцию, а его сопровождение стоило уже $4 тыс. на инструкцию.

Чем раньше найти и исправить ошибку, тем дешевле это обойдется.

Подробное обсуждение стадий разработки программного обеспечения можно найти в работах Де Грейса и Стала (DeGrace & Stahl, 1990), Май­ерса (Myers, 1976) и Роутзейма (Roetzheim, 1991). А детальный анализ сто­имости разработки приводили Боэм (Boehm, 1981), Джонс (Jones, 1991) и Волвертон (Wolverton, 1974).

Стадии планирования

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

Определение целей

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

Анализ требований

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

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

58 Часть I: Основы

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

Определение функциональных характеристик программного продукта

Определение функциональных характеристик можно представить как мост между требованиями к программному продукту и будущими инженер- но-проектными документами. Требования к продукту связаны прежде всего с маркетингом и важны именно для этого отдела. Инженеру же нужно нечто более определенное, полное и конкретное. Это “нечто” и есть фун­кциональные характеристики, среди которых он найдет перечень функций будущего программного продукта и описание входных и выходных доку­ментов. Способов реализаций этих функций данный документ не касает­ся, только в самых необходимых случаях, когда это поможет понять документ, в нем может быть в общих чертах описана возможная реализа­ция, но конечная внутренняя и внешняя структура продукта, скорее все­го, окажется совсем иной.

Прекрасной моделью для разработки функциональных характеристик может быть документ IEEE Software Requirements Specification (руководство IEEE по определению требований к программному обеспечению, стандарт ANSI/IEEE 830-1984).

Тестирование на этапе планирования

На этом этапе пока еще тестируются не программы — “тестируются” идеи. К их анализу привлекаются специалисты по маркетингу, руководи­тели проекта, главные конструкторы и специалисты по анализу человечес­кого фактора. А вот члены группы тестирования участвуют в этой работе очень редко. (В главе 13 рассказывается о том, какую полезную работу могут выполнять специалисты по тестированию на этапе планирования продукта.)

Группа аналитиков читает черновики проектных документов. Затем она собирает информацию, которая может оказать помощь в их оценке и даль­нейшем планировании. Для этого существует несколько стандартных спо­собов: сравнительный анализ, дискуссионные группы и обследование объекта. Результаты каждой из этих процедур могут привести к значитель­ному пересмотру существующих планов.