Внутренняя спецификация

Cтраница 3

Этапы разработки и отладки программы. [31]

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

Структура изделия ASK. [33]

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

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

Отметим, что здесь выполняется именно функциональная декомпозиция, поскольку СТ является функциональным документом и не указывает, как предлагаемое изделие будет физически разбито на модули. Во внутренних спецификациях, создаваемых на основе СТ, обязательно должно быть описано физическое разбиение на модули. Чтобы было легче сопоставлять внутренние спецификации с предшествующими им соглашениями о требованиях, удобно представить какое-либо конкретное физическое разбиение и попытаться определить функциональные модули, которые могут быть реализованы как физические модули. Но, поступая так, следует помнить, что в СТ более важным является четкое разбиение по функциям, а физическое разбиение только подразумевается, но не диктуется СТ. [36]

Чтобы еще более уточнить понятия внешнего и внутреннего проектов, обратимся к рис. 7.7 и 7.8. Древовидная структура, изображенная на рис. 7.7, построена по схеме, представленной на рис. 7.6, и показывает, где используется каждый модуль. Будем считать, что а внешний контур каждого блока из рис. 7.7 отображается совокупность параметров, принадлежащих соответствующему модулю. Контур Р, изображенный на рис. 7.8, на который отображаются все параметры, видимые при рассмотрении программного изделия извне, соответствует внешнему проекту. Внутренние спецификации описывают параметры, принадлежащие остальным контурам блоков. [37]

Входные и выходные данные программы и их связи определяются на этапе составления спецификаций. Спецификацией называется полное описание требований к исходной программе для конкретного типа ЭВМ. В спецификации учитываются ограничения на представление данных и связи с другими программными модулями. Различают внешние и внутренние спецификации. [38]

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

Внутренние спецификации согласуются с внутренними целями ИТ-организации, достижение которых означает удовлетворение потребностей заказчика. Разграничение между внутренними и внешними спецификациями может оказаться особенно полезным уже после того, как Процесс Управления Уровнем Сервиса запущен в работу. Начиная с этого момента, Управление Уровнем Сервиса означает стремление поддерживать соответствие внутренних спецификаций внешним. Этому содействуют выполнение таких действий, как Контроль документов и Внутренний анализ ( ре-вью), в ходе которых ведется регистрация относящихся к данному вопросу документов, управление версиями п организуются регулярные аудиторские проверки. [40]

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

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

Кодирование программ начинается на раннем этапе фазы программирования. На рис. 7.10, представляющем фрагмент сети, выделенной из общего стандартного сетевого графика, показаны этапы последовательного выполнения работ в рамках функции разработки в фазе программирования: Р21 - кодирование ачато, РЗО - внешние спецификации утверждены. Эти точки демонстрируют проявление волнового эффекта, когда составление внутренних и внешних спецификаций, кодирование, отладка и компоновка программ выполняются одновременно на различных уровнях дерева структуры программного изделия. Например, в некоторый момент фазы программирования состояние разработки модулей ( рис. 7.6) может иметь вид, отображаемый табл. 7.2. К этому времени внешние спецификации всего программного изделия могут быть уже утверждены, а внутренние спецификации составлены не до конца. [43]

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

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