Cтраница 1
Сквозной структурный контроль должен комбинироваться с др угими методами, упоминавшимися ранее. Так, при проектировании сверху вниз нужно контролировать правильность выделения модулей верхнего уровня, прежде чем разрабатывать модули более низкого уровня. Простота и ясность программ достигаются легче, если сквозной структурный контроль применять совместно со структурным программированием. В этом случае контроль служит и для того, чтобы удостовериться в соблюдении основных требований структурного программирования. [1]
Сквозной структурный контроль необходим для обнаружения и исправления ошибок на ранних стадиях проектирования, пока стоимость исправления ошибок минимальна, а последствия их наличия незначительны. Такой контроль обеспечивается регулярным обсуждением принятых решений всеми взаимодействующими разработчиками. Кроме того, наличие базовых структур, унификация правил взаимодействия компонент и заведомо известная последовательность их разработки в порядке соподчиненности создают предпосылки для автоматизации процесса структурного контроля. [2]
Сквозной структурный контроль - это общее название, предложенное фирмой ИБМ для серии проверок, проводимых с различными целями и на разных фазах цикла разработки программ. Основная цель - добиться того, чтобы каждая достаточно значительная доля затраченных усилий была внимательно изучена компетентными людьми, к тому же непосредственно заинтересованными в успехе. Сквозной контроль используется и для проверки спецификаций вместе с пользователем, и для проверки проекта, чтобы быть уверенным в том, что он соответствует спецификациям, и чтобы убедиться в правильности плана тестирования и самих тестов. При этом программисты проверяют программы друг друга до их перфорации. [3]
Сквозной структурный контроль - это новое средство, которое в конечном итоге очень облегчает управление проектом, но является по существу не управленческим, а техническим, используемым людьми, непосредственно занятыми в проекте. Термин структурный подчеркивает то обстоятельство, что этот контроль становится естественной составной частью рабочего цикла и проводится заранее предопределенным и продуманным во всех тонкостях способом. Термин сквозной указывает на способ проверки - все контролируемые элементы мысленно выполняются шаг за шагом. Сквозной контроль придуман для того, чтобы обнаруживать ошибки в принятых решениях и при этом создать такую атмосферу, при которой каждый, и особенно сам проектировщик, стремился бы найти эти ошибки как можно раньше. [4]
Сквозной структурный контроль может в значительной степени способствовать успеху проекта. [5]
Сквозной структурный контроль позволяет обнаруживать ошибки проектирования и логические ошибки на ранних стадиях разработки. Сессии становятся важными событиями, существенно повышающими продуктивность. [6]
Опыт использования сквозного структурного контроля очень обнадеживает. Несомненно, существует много способов модифицировать его для применения к другим типам проектов. [7]
На самом деле плохому сотруднику сквозной структурный контроль дает не так уж много, так как именно он должен внести все изменения. [8]
В текущем десятилетии подобной новинкой может стать сквозной структурный контроль. [9]
Структурный подход к проектированию комплексов программ предполагает организацию нисходящей разработки программ, применение структурного программирования и дсуществление сквозного структурного контроля. Поскольку программы разрабатываются сверху вниз, появляется необходимость использовать вместо программ: нижнего уровня их имитаторы, которые могут содержать только операторы входа и выхода; в некоторых случаях, однако, возмож - но включение операторов других типов, например вызовы других программ, печати. [10]
Итак, структурный контроль - это прежде всего продуктивно работающие сессии, которые не только следят за продвижением вперед, но и сами вносят вклад в это продвижение. Организационные и психологические аспекты сквозного структурного контроля описаны в гл. [11]
Сквозной структурный контроль должен комбинироваться с др угими методами, упоминавшимися ранее. Так, при проектировании сверху вниз нужно контролировать правильность выделения модулей верхнего уровня, прежде чем разрабатывать модули более низкого уровня. Простота и ясность программ достигаются легче, если сквозной структурный контроль применять совместно со структурным программированием. В этом случае контроль служит и для того, чтобы удостовериться в соблюдении основных требований структурного программирования. [12]
Число ошибок, обнаруженных в процессе тестирования модулей, должны быть небольшим. Это следует из всей совокупности принципов, изложенных в этой книге. Функциональное проектирование приводит к простым модулям, а в результате сквозного структурного контроля ошибки обнаруживаются до этапа машинного тестирования. Дисциплина программирования, базирующаяся на разумных управляющих структурах, приводит к более тщательно продуманной программе и, следовательно, к меньшему количеству ошибок. [13]
Авторы не претендуют на изложение теоретических основ структурного подхода. Особую ценность придают книге конкретные рекомендации по структурному программированию на КОБОЛе, ФОРТРАНе и ПЛ / 1, трансляторы с которых имеются на отечественных машинах, а также по организации нисходящей разработки, пошаговой детализации, сквозному структурному контролю и тестированию. Правда, иногда авторы слишком увлекаются упрощенчеством, не сообщая читателю о возможных трудностях при попытках использовать их рекомендации в лоб. Для советского читателя может оказаться трудным разобраться досконально в некоторых примерах из американской экономики, тем более, что авторы рассматривают лишь фрагменты, а не полные программы. Пугаться этого не следует - как правило, для понимания существа излагаемой технологии достаточно общего представления о назначении рассматриваемого фрагмента. [14]
Но ни сами документы, ни их коллегиальное обсуждение не смогут обеспечить действенных взаимосвязей, если отсутствуют частые непосредственные контакты функциональных групп. Каждый из фазовых обзоров должен либо от начала до конца проводиться на совещании, либо заканчиваться им. Для этого территориально функциональные группы должны быть расположены достаточно близко друг к другу, чтобы можно было организовывать совместные встречи, когда это необходимо. Но сессии сквозного структурного контроля [23] или аттестации изделий [24], хотя и будут всегда включать участников разработки проекта системы программного обеспечения, могут не предусматривать участия групп выпуска документации и испытаний, несмотря на то что они находятся рядом. Таким образом, ничто не может так действенно способствовать установлению связей между отдельными функциональными группами, как частые и непосредственные контакты самих разработчиков. [15]