Внешний проект

Cтраница 2

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

Ранее внешний проект представлялся как состоящий из двух процессов: первоначального и подробного внешних проектов. Допуская, что спецификация является иерархически организованной, эти два процесса просто представляют контрольные точки в проектировании системы согласно иерархии. На первом этапе описываются основные средства ( то, что соответствует разбиению на первом уровне), затем средства, функции пользователя и подробности для каждой функции пользователя. [17]

Те атрибуты модулей, которые играют существенную роль при составлении описания программного изделия как единого целого, составляют внешний проект. Все остальные параметры модулей, полностью или частично скрытые внутри программного изделия, составляют в совокупности внутренний проект. Обратим внимание на естественное следствие описанного выше подхода: все управляющие структуры, которые связывают недоступные извне модули, принадлежат внутреннему проекту. Эти структуры определяют, как реализовано программное изделие, и поэтому не входят во внешний проект. [18]

Соответствие между главами и методами обеспечения надежности. [19]

Следующий шаг касается постановки целей - задач, которые ставятся перед окончательным результатом и самим проектом. Затем выполняется внешний проект высокого уровня. [20]

В производственной модели внешний проект ( задание на разработку) выполняется с участием пользователя. С точки зрения рыночной модели определяется степень удовлетворения потребностей пользователя в планируемом продукте, его цене, аналогичных пакетов прикладных программ или отдельных разработок, доступных на рынке. Сбор, обработка и анализ полученных результатов должны помочь в построении маркетинговой стратегии. [21]

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

Другой областью повышения надежности является доведение до минимума сложности внешнего проекта для того, чтобы довести до минимума внутреннюю сложность системы, а также свести к минимуму ошибки пользователя. Общим мнением является то, что очеловеченный внешний проект должен быть более сложным, включая сложные системы сообщений и автоматическое исправление ошибок. [23]

Фаза проектирования заканчивается утверждением внешних спецификаций, что придает внешнему проекту постоянство и стимулирует завершение внутреннего проекта. Утверждение внешних спецификаций не означает запрещения проводить изменения внешнего проекта, а лишь сдерживает их поток и позволяет другим функциональным группам выполнять свою работу, не дожидаясь дальнейшего уточнения проекта. Для внесения новых изменений в утвержденные внешние спецификации используются заявки на расширение ( разд. Эти заявки необходимо тщательно изучать, чтобы не допустить нежелательных изменений календарных сроков работ, особенно тех, которые проводятся в рамках других функций, реагирующих на дополнительные изменения непредвиденным образом. [24]

Они уникальны по своим достоинствам в качестве средства общения между разработчиком - внешнего проекта, пользователем и программистом. С одной стороны, в них легко может разобраться пользователь, просматривающий внешние спецификации. С другой стороны, они служат идеальными исходными данными для программиста, разрабатывающего внутреннюю логику программы. Это двойственное применение таблиц решений сокращает число ошибок перевода. Например, можно было бы применить эти методы к таблице на рис. 4 3, чтобы проверить, все ли условия на входе предусмотрены. Поскольку многие ошибки в программном обеспечении вызываются непредвиденными условиями, такие механические средства весьма ценны. [25]

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

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

Основная цель фазы конструирования заключается в выработке и анализе требований к программному изделию. Процесс декомпозиции проекта, начатый при составлении соглашения о требованиях, продолжается путем разбиения спецификаций а два компонента - внутренний и внешний. Внешний проект - это совокупность характеристик программного изделия, которые видит пользователь. [28]

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

Из рис. 3.2 следует, что критический анализ архитектуры должны выполнять разработчики исходных внешних спецификаций и предполагаемые разработчики структуры каждой компоненты. Проектировщик уровня п - 1 ищет примеры неполного или неточного перевода внешнего проекта. Проектировщик уровня п 1 проверяет, понятна ли архитектура системы и работоспособна ли она. Поскольку архитектура часто разрабатывается параллельно с детальным внешним проектом, важно также сопоставить результаты обоих процессов, чтобы выявить ошибки. [30]

Страницы: 1 2 3