ров исходного языка в машинные команды можец сильно колебаться. Следовательно, для характеристики объема программных средств следует исполь*. зовать два показателя: число машинных команд и число исходных операторов, выявляющие разницу;. объемов, связанную с наличием исполняемых и неисч полняемых команд, а также комментариев. Однако даже при наличии этих двух показателей мы все еще не располагаем информацией, достаточной для про /; ведения сравнения. Оказывается, необходимо даты определение того объекта, объем которого подлежит., измерению. В случае Проекта 3 объем совокупности исходных программ конечного изделия был очень блн* зек к общему числу написанных команд. Для Проект та 5 объем конечного изделия составлял только часта всего количества написанных команд. Это связано частично, во-первых, с применением нисходящего про*. ектирования, при котором сознательно планируется, определенное число ненужных или заменяемых \ впоследствии команд, и, во-вторых, с использованием : специальных средств, необходимых для разработки программ, ориентированных на режим реального времени. Подобные обстоятельства следует иметь в; виду для представительного сравнения удельного koi; личества ошибок (измеряемого их числом на единицу, объема) и особенно при сравнении производительное сти программистов.

Таким образом, проблема создания необходимой базы для сравнения данных по разным проектам сво- дится к введению единой терминологии и выбору об-, щих параметров, которые должны использоваться при описании различных проектов. Результаты данного, исследования дают основания надеяться, что указанная проблема не является неразрешимой. В этой свя-. зи особенно обнадеживающими являются данные по. ошибкам (и это, к сожалению, пока единственная об- . ласть для сравнений и обобщений) и, в частности, тот, факт, что в основном совпадают перечни типов ошш бок. Расширение области сравнения, по-видимому, станет возможным благодаря разработке унифици*. рованных подходов к сбору и анализу данных и их внедрению в активные экслерименты.

4.7. Средства и методы создания систем программного обеспечения

Для усовершенствования процессов разработки и испытаний программного обеспечения могут быть использованы различные средства. Это становится все более очевидным, если учесть данные последних публикаций в специальных журналах и проанализировать направления текущих правительственных научно-исследовательских программ. Работа, проводимая в этом направлении, касается обычно усовершенствования либо средств, либо методов разработки программного обеспечения. Подобные усовершенствования, как правило, осуществляются с целью улучшения как организационной, так и технологической структуры систем программного обеспечения на всех этапах их жизненного цикла, т. е. от предпроектного анализа через этапы выборки требований, проектирования, программирования, испытаний и до этапов эксплуатации и технического обслуживания. Под средствами программного обеспечения в данном случае имеются в виду машинные программы, предназначенные для выполнения работ, которые в противном случае пришлось бы делать вручную. Методы программного обеспечения определяются как стандарты и процедуры, используемые при разработке и сопровождении систем программного обеспечения. Основное Назначение этих средств и методов может быть сформулировано следующим образом:

- исключить ошибки до их попадания в конечное изделие (программу или документацию);

- выявить ошибки, которые попали в программное изделие на предыдущих этапах разработки;

- облегчить исполнителям проекта выполнение рутинных задач и тем самым создать условия для творческой работы над техническими проблемами;

- повысить интенсивность общения и способствовать общему взаимопониманию между исполнителями проекта, заказчиком и пользователем.

Почти любой вопрос, относящийся к разработке системы программного обеспечения, может служить

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

При выборе средств программного обеспечения и методов их разработки важную роль играют зконо-мнческие соображения, основой которых могут служить эмпирические данные и результаты работ [10, 11]. Так, например, ошибки, возникающие при преобразовании единиц измерения, обнаруживались при помощи средства, называемого Анализатор согласо* ванности единиц измерений. Однако для этой же цели могут быть использованы метод тестирования стержневой логики алгоритма, многократный анализ проектных решений и программ, а также сквозной структурный контроль. При испытании программных средств Проекта 3 ошибки вычислений в 9,3% случаев (что составляет 0,8% всех ошибок) могли быть обнаружены при помощи анализатора согласованности единиц измерений. Если средство подобного типа использовать для выявления сходных ошибок вычислительного характера, то можно увеличить цифру 9,3% ДО величины 15,9% (а 0,8% соответственно до 1,4%)). Вместе с тем практически любая ошибка вычислений, включая и вышеупомянутые (9,3% всех ошибок), может быть обнаружена при помощи многоцелевых проверок проектных решений и путем тестирования стержневой логики алгоритма. Подобный анализ был выполнен нами применительно к базовому Проекту 3 и ограничивался исследованиями технологических усовершенствований средств и методов, которые применялись на таких этапах жизненного цикла программного обеспечения, как разработка и испытания. Подход, принятый при таком анализе, был аналогичен подходу, предложенному в работе [12].