Эта книга содержит описание методологии управления процессами планирования, проектирования, конструирования, оценивания, документирования, распространения, технического обслуживания (сопровождения) систем программного обеспечения. В рамках предлагаемой методологии учитываются взаимосвязи между различными фазами жизненного цикла программ-ных средств и функциями, которые должны выполняться в этих фазах. Показано, как на основе принципов нисходящего проектирования, целевого управления, управления конфигурацией систем программного обеспечения и ряда других создается эффективная система взаимосогласованных и усиливающих друг друга документов и процедур. В книге особое внимание уделяется концепции программного изделия под программным изделием понимается универсальное программное обеспечение, которое предназначается для широкого круга пользователей, быть может даже неизвестных заранее, и должно рекламироваться, поддерживаться в работоспособном состоянии, расширяться на протяжении длительного периода времени. Описанные методы и средства ориентированы специально на организацию управления процессом созданная именно такого универсального программного обеспечения. Читателю же предлагается самостоятельно выбрать те методы и средства, которые в наибольшей степени отвечают его потребностям как руководителя отдела обработки данных, или как руководителя проекта системы обороны, или администратора организации, производящей программное обеспечение, или руководителя программных разработок в фирме, производящей технические средства. Описываемая методология полностью совместима с современными принципами структурного программирования и бригад главного программиста, но она может применяться и без учета этих принципов. [c.8]
Имеются весьма основательные доводы в пользу отделения друг от друга некоторых из функций, правильное выполнение которых способствует успешному выпуску изделия. К тому времени, когда почерпнутые из этой книги методы и средства будут введены в действие, такое разграничение функций наверняка можно будет реализовать. И тогда следует удовлетвориться, что группа испытаний работает независимо от группы разработки и потому не подчинена и не может ей подчиняться. Затем следует обособить функцию обслуживания, которая должна в равной степени охватывать обеспечение нормальной деятельности всех остальных групп. При этом, однако, нельзя забывать о планировании, организации поддержки, документирования и сопровождения программных изделий в целях лучшего удовлетворения потребностей пользователя. Если потребности пользователя изменяются, следует без колебаний преобразовывать и эти функции. Приняв такую стратегию, можно-смело приступать к более полной реализации принципов проектирования программного обеспечения и применять методы управления этим процессом точно так же, как их применяют в целом или по частям преуспевающие. руководители. [c.20]
Именно о таком конвейере идет речь в данной книге, которая целиком посвящена важным и мало изученным проблемам управления крупномасштабными разработками в условиях ограниченных временных и финансовых ресурсов. В ней развивается концепция программного обеспечения как изделия, имеющего самостоятельное значение, процессы проектирования и изготовления которого аналогичны процессам, связанным с созданием любых других изделий, и не в меньшей степени требуют стандартизации методов и про- [c.5]
Внутреннее проектирование определяет, как изделие должно функционировать. Модули, подпрограммы, оверлейные структуры, динамические таблицы, блок-схемы и таблицы решений являются строительным материалом при внутреннем проектировании. Методы корректного внутреннего проектирования и управления этим процессом составляют целый раздел техники программного обеспечения — методологию программирования, являющуюся вполне законченной дисциплиной. Вероятно, точнее было бы говорить, что эти методы охватывают несколько конкретных проблем, поскольку никакой положительный опыт проектирования программ одного типа (например, программ вычислительного характера) не имеет ничего общего с практикой программирования других задач (например, с разработкой компиляторов). Во всяком случае, этот вопрос является чисто техническим и выходит за рамки тематики этой книги. [c.30]
Некоторые формы иерархической декомпозиции, с которыми мы встретимся, представляют собой нисходящее управление (гл. 5), декомпозицию планов (гл. 6), декомпозицию проекта (гл. 7) и структурирование планов выпуска и спецификаций изделий (частично гл. 13 и разд. 15.1—15.3). Вероятно, многие знакомы с такими видами формальной иерархической декомпозиции, как поэтапная обработка [11], уровни абстракции [12], иерархия документации [13], нисходящее программирование [14], модульная декомпозиция [15], композиционное [16] и структурное [17] проектирование. Александер [18] предлагает весьма интересное представление декомпозиции. В небольшой, но очень полезной книге он проводит философское обсуждение процессов анализа и синтеза конструкций, за которым следует математический метод разложения множества ограничений на подмножества, приводящий к минимизации их взаимодействия. Его работы и работы Бёма [19], Хоара [20], Милза [21], а также некоторые пока еще не опубликованные работы представляют собой значитёлньый вклад в проектирование программного обеспечения благодаря введению количественной меры оценки этого процесса и средствам доказательства правильности программ. [c.31]