Фаза - предварительная разработка
Cтраница 2
Исполняемые на фазе предварительной разработки отчеты служат для внесения в план разработки описаний структуры базы данных и приложения. Как всегда, сам репозиторий является частью документации, поскольку представляет собой централизованное место, где можно выяснить подробности проектирования системы и проведенного анализа. Репозиторий - электронное хранилище, не имеющее бумажной копии, поэтому он вторичен по отношению к документированию требований. [16]
Для малых систем фаза предварительной разработки не нужна, если уже имеются необходимые стандарты. Обычно аналитик хранит в голове небольшое количество требований к системе и использует интеллектуальные инструменты Oracle Designer, чтобы сразу начать ее построение. [17]
Во время оценки фазы предварительной разработки внимание перемещается с пользователей на систему. На этой фазе специалисты по системам говорят гораздо больше, чем пользователи хотят услышать. Пользователи должны прочувствовать план проекта, но специалисты по системам - это именно тс люди, которые будут создавать систему, поэтому их влияние на этой фазе гораздо больше, чем влияние пользователей. [18]
Одна из целей фазы предварительной разработки состоит в создании работающей доски хранения, или прототипа, чтобы показать вид законченной системы. [19]
Одним из последних этапов фазы предварительной разработки является синхронизация отображения требований к системе на модули. Хотя Application Design Transformer создает модули из функций и копирует использования данных, не имеется никакой утилиты для копирования требований из функций в модули. Необходимо связать эти два элемента, поскольку одной из проверок на фазе предварительной разработки станет исследование того, все ли требования переадресованы модулями в системе. [20]
 |
Действия и законченные части фазы предварительной разработки. [21] |
Кроме стандартов разработки GUI, основной законченной частью, поддерживаемой Oracle Designer на фазе предварительной разработки, является доска хранения, или концептуальный проект ( разработки) приложения. [22]
В конце процесса разработки будут получены полностью определенная база данных и связанные с ней приложения. Генерируемый на фазе предварительной разработки план проекта должен учитывать все упомянутые аспекты. [23]
В этой главе мы не рассматриваем утилиту Capture Design of Server Model From Database ( CM. Работа с генераторами на фазе предварительной разработки аналогична операциям на фазе построения, но с одним основным отличием: на фазе предварительной разработки для генерации применяются все заданные по умолчанию предпочтения для каждого из модулей. [24]
 |
Операции при анализе требований и инструменты Oracle Designer. [25] |
Такая последовательность обеспечивает выбор между заполнением использования атрибутов для функций вручную ( в Function Hierarchy Diagrammer или Dataflow Diagrammer) или принятием значения по умолчанию из утилиты Function / Attribute Matrix. Эти результаты будут нужны на фазе предварительной разработки, когда запускается Application Design Transformer для создания модулей-кандидатов. На фазе разработки все равно потребуется время на совершенствование таблиц и использование столбцов для модулей, но лучше принять заданный по умолчанию атрибут CRUD на фазе анализа и усовершенствовать это использование на фазе разработки. К тому времени проект станет более устойчив, и можно обратить внимание не только на свойства столбца данных, но и на свойства отображения столбца. [26]
Большинство требований к системе будет заморожено в конце фазы предварительной разработки. Поэтому очень важно обдумать все аспекты приложения и базы данных формируемой системы до реального начала работ на фазе разработки. [27]
В этой главе мы не рассматриваем утилиту Capture Design of Server Model From Database ( CM. Работа с генераторами на фазе предварительной разработки аналогична операциям на фазе построения, но с одним основным отличием: на фазе предварительной разработки для генерации применяются все заданные по умолчанию предпочтения для каждого из модулей. [28]
Концептуальный план приложения создается до начала разработки базы данных. Выбор инструментов, досок хранения, создание удобного для пользователя интерфейса, выделение модулей, отображение требований и создание функционального описания - все части концептуального плана приложения мы обсудим в данном разделе. Этот план выполняется как часть фазы предварительной разработки, поскольку без ясного представления о виде приложений нельзя переходить к разработке проекта базы данных. [29]
Одним из последних этапов фазы предварительной разработки является синхронизация отображения требований к системе на модули. Хотя Application Design Transformer создает модули из функций и копирует использования данных, не имеется никакой утилиты для копирования требований из функций в модули. Необходимо связать эти два элемента, поскольку одной из проверок на фазе предварительной разработки станет исследование того, все ли требования переадресованы модулями в системе. [30]
Страницы: 1 2 3