Void Smog (long mz[][n2]);

Void main ()

{ int i,j;

long MZO[N1][N2]={{ 120000,150000, 102000,110000,130000,

150000,200000,130000,112000,105000,110000,0

},

{0,120000,125000,130000,134000,145000,0,0,0,0,0,0},

{0,0,0,0,120000,125000,130000,134000,145000,0,0,0}

} ;

clrscr();

Smog (MZO);

getch();

}

// модуль СМОГ

Void Smog (long mz[][n2])

{int i,j,Pnrt,Inf = 0;

long Sum;

printf(" часы ср. значение число нарушений \n");

for(i=0;i < N1; i++)

{ Sum = 0;

Pnrt = 0;

for (j = 0; j < N2; j++)

{ Sum+=MZ[i][j];

if (MZ[i][j] > 100000)

{ Inf+=1;

if (Inf == 5)

{ Pnrt += 1;

Inf = 0;

}

}

else

Inf = 0;

}

Sum /= N2;

printf (" %d %6ld %d \n",i+1, Sum, Pnrt);

}

}

В этой программе модуль СМОГ тестируется для количества часов N1 = 3 и N2 = 12. При этих параметрах получим следующий результат:

часы ср. значение число нарушений

1 118250 2

2 54500 1

3 54500 1

4.3.Сквозной структурный контроль

Сквозной структурный контроль -это средство, которое облегчает управление проектом. Является составной частью рабочего цикла и проводится заранее предопределенным и продуманным во всех тонкостях способом.

Термин «структурный» подчеркивает то обстоятельство, что этот контроль является составной частью рабочего цикла и проводится заранее предопределенным и продуманным во всех тонкостях способом.

Термин «сквозной» указывает на способ проверки – все контролируемые элементы мысленно выполняются шаг за шагом. Сквозной контроль придуман для того, чтобы обнаруживать ошибки в принятых решениях и при этом создать такую атмосферу, при которой каждый, и особенно сам проектировщик, стремился бы найти эти ошибки как можно раньше.

На рис.11 показаны этапы разработки. Площадь под кривой представляет затраченные ресурсы (люди, финансы и т. п.) для проекта в области систем обработки данных. Сквозной контроль осуществляется на всех этапах разработки – начинается как можно раньше и продолжается до самого этапа реализации включительно.

В табл.1 показаны те элементы, которые могут проверяться при использовании структурного контроля на различных стадиях разработки.

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

На этапепроектированияследует проверять, как система будет работать на конкретных данных, чтобы убедиться, что это согласуется со спецификациями

Таблица 1

Элементы, которые должны проверяться на контрольных сессиях

этапы проекта	что проверяется	наиболее вероятные недостатки
Определение требований	Планы проекта Сроки Сфера применения проекта	Различного рода упущения Нереальные сроки Недоступность основных пользователей
Начало проектирования	Спецификация системы Постановка задачи	Неполные спецификации Нечеткая постановка
Проектирование	Функциональные спецификации программы Проектирование программы (схемы иерархии) Обработка особых случаев Проверки	Неполные спецификации Передача управления не по вертикали, плохо определены функции Недостаточная детальная проработка Неполное соответствие требованиям
Планирование	План порядка разработки модулей План порядка тестирования модулей Тесты	Не полностью выявлена зависимость модулей по данным Неполное соответствие требованиям Недостаточно полный набор
Реализация	Детальное проектирование программы Взаимодействие модулей Документация Псевдокод или программа	Отклонения от общего проекта Незафиксированные предположения Неясности, ненужные подробности Логические ошибки
Приемка	Окончательная документация Окончательный продукт (соответствие результатов спецификациям)	Не установлен критерий пригодности документации Изменения в спецификациях

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

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

Наконец, на этапе приемки готовый продукт снова полностью проверяется.

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

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