Как собственно АИС, так и компоненты АИС являются сложными системами, и при их проектировании целесообразно использовать нисходящий стиль блочно-иерархического проектирования, включающего ряд уровней и этапов [19, 51]. [c.116]
При создании системы хозяйственного учета на базе микро-ЭВМ в основу должно быть положено нисходящее проектирование задач (проектирование сверху вниз). Это требование определяется необходимостью балансового отражения на счетах бухгалтерского учета и отчетного обобщения всех хозяйственных операций за учитываемый и контролируемый периоды. [c.80]
Сущность нисходящего проектирования заключается в разработке общей системной концептуальной модели системы хозяйственного учета с выделением информационно взаимосвязанных комплексов учетных задач, охватываемых этой моделью. Далее должны быть разработаны детальные информационные модели этих комплексов и структурные схемы решения отдельных задач, входящих в комплексы, и выполнены постановки этих задач. [c.80]
| Рис. 4.1.1. Концептуальная модель нисходящего проектирования компьютеризации учетно-информационных процессов |  |
Рассмотренные нами системы автоматизации проектирования СМОД различны по своей ориентации на пользователя, способу реализации модельного подхода к проектированию, структурному составу, степени автоматизации процессов проектирования СМОД и другим параметрам. В то же время наблюдается определенная общность принципов и методов, положенных в их основу. В частности, все эти САПР имеют нисходящий (сверху вниз) принцип проектирования. Процесс разработки развивается от первоначально заданных нечетких целей к конкретным решениям путем последовательной детализации и уточнения исходных целей. При создании программного обеспечения СМОД в этих системах используются прогрессивные принципы и методы программирования. [c.172]
Эта книга содержит описание методологии управления процессами планирования, проектирования, конструирования, оценивания, документирования, распространения, технического обслуживания (сопровождения) систем программного обеспечения. В рамках предлагаемой методологии учитываются взаимосвязи между различными фазами жизненного цикла программ-ных средств и функциями, которые должны выполняться в этих фазах. Показано, как на основе принципов нисходящего проектирования, целевого управления, управления конфигурацией систем программного обеспечения и ряда других создается эффективная система взаимосогласованных и усиливающих друг друга документов и процедур. В книге особое внимание уделяется концепции программного изделия под программным изделием понимается универсальное программное обеспечение, которое предназначается для широкого круга пользователей, быть может даже неизвестных заранее, и должно рекламироваться, поддерживаться в работоспособном состоянии, расширяться на протяжении длительного периода времени. Описанные методы и средства ориентированы специально на организацию управления процессом созданная именно такого универсального программного обеспечения. Читателю же предлагается самостоятельно выбрать те методы и средства, которые в наибольшей степени отвечают его потребностям как руководителя отдела обработки данных, или как руководителя проекта системы обороны, или администратора организации, производящей программное обеспечение, или руководителя программных разработок в фирме, производящей технические средства. Описываемая методология полностью совместима с современными принципами структурного программирования и бригад главного программиста, но она может применяться и без учета этих принципов. [c.8]
Все рассматриваемые методы и средства прошли, в той или иной мере, практическую проверку, которая показала, что многие из них могут использоваться независимо друг от друга. В основе предлагаемой методологии лежит принцип нисходящего модульного проектирования. Поскольку все рассматриваемые в книге методы и средства очень тесно связаны между собой, наибольший выигрыш достигается при их совместном использовании, когда они усиливают друг друга. Однако там, где это требуется, мы обращаем особое внимание на нежелательность слишком раннего, поспешного или запоздалого применения тех или иных методов и средств. [c.9]
Нисходящий анализ процесса управления проектированием программного изделия [c.49]
Организуя процесс разработки программного изделия, необходимо иметь в виду основную идею иерархической декомпозиции проекта, при которой всегда сохраняется завершенность (с точки зрения учета всех аспектов проектирования) на различных этапах все более увеличивающейся детализации. Декомпозиция проекта является вторым этапом в цепочке, включающей три этапа декомпозиции, следующих друг за другом. Первый этап — декомпозиция плана, третий—программная декомпозиция, часто называемая программированием сверху вниз или нисходящим программированием. [c.87]
Наконец, в вершине иерархии методов проектирования помещается концепция бригады главного программиста, в состав которой входят главный программист, его помощник, администратор библиотеки, а также от одного до пяти проблемных программистов. Главный программист является старшим техническим руководителем группы, который управляет ею и вместе со своим помощником проектирует, кодирует и объединяет модули высокого уровня или наиболее важные модули. Помощник главного программиста, на котором лежит ответственность за разработку некоторых из этих модулей, также является старшим техническим экспертом, он, кроме того, всегда должен быть готов взять на себя роль главного программиста бригады. Администратор библиотеки, являющийся высококвалифицированным секретарем, осуществляет функции, связанные с библиотекой поддержки разработки. Проблемные программисты составляют младший технический персонал, который по указанию главного программиста занимается написанием и отладкой отдельных модулей, не играющих критической роли в системе. Используя методы нисходящего проектирования, структурного программирования, а также библиотеку поддержки разработки, главный программист и его помощник тщательным образом проверяют тексты программы, написанные проблемными программистами с точки зрения функциональной полноты этих программ и их соответствия правилам структурного программирования. [c.91]
Концепция бригады главного программиста хорошо вписывается в методологию, излагаемую в данной книге. Библиотека поддержки разработки является хорошей иллюстрацией методов конфигурационного управления на уровне проекта. Структурное программирование удовлетворяет многим требованиям методологии проектирования, которые упоминаются в этой книге. Нисходящее проектирование, называемое также программированием сверху вниз, является фактически постепенной детализацией описаний функциональной структуры на уровнях более простых функций до тех пор, пока, наконец, не будет достигнут уровень собственно операторов языка программирования [14]. В ходе этого процесса фактически осуществляется декомпозиция проекта, описанная в предыдущей главе. Как заметил Бейкер [39], один из недостатков работы бригад главного программиста заключается в отсутствии подробных описаний функциональной структуры, которые отражали бы все внешние аспекты системы, не затрагивая внутренней структуры проекта. Ясно, что речь здесь идет о внешних спецификациях, рассмотренных в гл. 2. Бригада главного программиста, в составе которой предусмотрена должность руководителя проек- [c.91]
Продолжим изучение рис. 7.8. Отметим, что контур модуля А — высшего в иерархии модулей — полностью проецируется на внешний контур программного изделия Р. Это является прямым следствием нисходящего проектирования, в соответствии с принципами которого модуль высшего уровня лишь инициирует и прекращает работы программного изделия, устанавливает другие виды взаимодействия изделия с пользователем и синхронизирует выполнение модулей более низкого уровня. Вследствие такой декомпозиции модуль А не имеет внутреннего проекта и внутренних спецификаций. [c.107]
Вопрос о назначении внешней спецификации неоднократно рассматривался в этой книге. В данном разделе описывается форма внешней спецификации, которая определяет машинные программы, документацию, тесты испытаний и помогает при оценке качества внешнего проектирования программного изделия. Как указано в разд. 7.5, назначение внешней спецификации ограничивается описанием лишь внешних аспектов проектирования, что, во-первых, предполагает нисходящее проектирование, а во-вторых, помогает официальным рецензентам этого документа не Путать внешние характеристики ( что представляет собой изделие) fr1 внутренней структурой (-как изделие организовано). [c.268]
Достоинствами данной организации труда проектировщиков ЭИС являются применение нисходящего проектирования, повышение производительности труда проектировщиков, повышение качества проектных решений, интенсивное обучение и эффективное использование начинающих разработчиков ЭИС. Следует также отметить, что в данном случае предъявляются высокие требования к квалификации и организаторским способностям главного специалиста. [c.445]
Содержание последующих этапов нисходящего проектирования — определение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование баз данных и их первоначального наполнения, разработка собственного прикладного ПО, которая в свою очередь делится на ряд этапов нисходящего проектирования. [c.118]
Некоторые формы иерархической декомпозиции, с которыми мы встретимся, представляют собой нисходящее управление (гл. 5), декомпозицию планов (гл. 6), декомпозицию проекта (гл. 7) и структурирование планов выпуска и спецификаций изделий (частично гл. 13 и разд. 15.1—15.3). Вероятно, многие знакомы с такими видами формальной иерархической декомпозиции, как поэтапная обработка [11], уровни абстракции [12], иерархия документации [13], нисходящее программирование [14], модульная декомпозиция [15], композиционное [16] и структурное [17] проектирование. Александер [18] предлагает весьма интересное представление декомпозиции. В небольшой, но очень полезной книге он проводит философское обсуждение процессов анализа и синтеза конструкций, за которым следует математический метод разложения множества ограничений на подмножества, приводящий к минимизации их взаимодействия. Его работы и работы Бёма [19], Хоара [20], Милза [21], а также некоторые пока еще не опубликованные работы представляют собой значитёлньый вклад в проектирование программного обеспечения благодаря введению количественной меры оценки этого процесса и средствам доказательства правильности программ. [c.31]
Следующим в иерархии методов является метод нисходящего проектирования [39], который состоит в том, что одновременно выполняемые внутреннее проектирование, кодирование и тестирование осуществляются для отдельных модулей в том порядке, чтобы тестирование каждого модуля не зависело от еще не написанных модулей или от еще неподготовленных данных. Этот прием подразумевает постоянную скомпонованность отдельных модулей программ, благодаря чему система всегда сохраняет способность к выполнению функций на определенном уровне, который служит количественным выражением прогресса в разработке. Поскольку ранее написанные модули постоянно участвуют в отладке, по мере появления новых модулей, вплоть до полного их объединения в систему, обычно приходится проводить больше тестовых прого- [c.90]
Основная цель фазы конструирования заключается в выработке и анализе требований к программному изделию. Процесс декомпозиции проекта, начатый при составлении соглашения о требованиях, продолжается путем разбиения спецификаций а два компонента — внутренний и внешний. Внешний проект — это совокупность характеристик программного изделия, которые видит пользователь. Внутренний проект — это совокупность характеристик программного изделия, скрытых от любого пользователя. На первый взгляд это разделение кажется искусственным, однако это не так, поскольку такая классификация характеристик программного изделия дает много преимуществ. Она хорошо согласуется с рядом практических методов программирования, таких, как нисходящее программирование [14], метод утаивания информации (information hiding) [15], композиционное проектирование [16] и структурное проектирование 17]. С точки зрения руководителя несомненным достоинством такой классификации является то, что пользователи могут критически рассматривать те характеристики программного изделия, которые имеют к ним непосредственное отношение, не вдаваясь в критику внутренних характеристик изделия. Другими словами, можно во внешних спецификациях описать, что делает программное изделие, а во внутренних спецификациях указать, каким образом оно должно быть сконструировано. Внеш- [c.105]