Большая техническая энциклопедия
2 3 6
A N P Q R S U
А Б В Г Д Е Ж З И К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я
СА СБ СВ СГ СЕ СЖ СИ СК СЛ СМ СН СО СП СР СС СТ СУ СХ СЪ СЫ

Системная документация

 
Системная документация ( один из результатов фазы построения) состоит из собственно репозитория и тех отчетов об описаниях его составляющих, которые, по вашему мнению, необходимы.
Системная документация [ System Documentation ] - совокупность документов, которые описывают требования, возможности, ограничения, устройство, функционирование и обслуживание системы обработки информации.
Таким образом, системная документация, сгенерированная СССД, будет непременно отражать текущее состояние разработанных систем. Поэтому банк, по-видимому, уже не окажется в такой ситуации, когда документация не соответствует системе. Если метаданные для системы генерируются с помощью СССД, документация получается точной, своевременной и полной, особенно если банк реализует активную СССД.
Вот почему нужно стремиться к автоматизации методов производства системной документации.
Позднее для описания и анализа задач обработки информации использовались пакеты системной документации, включающие блок-диаграммы, специальные таблицы и блок-схемы для описания процесса обработки информации. Даже с появлением вычислительных машин к концу этого периода системщики продолжали использовать методы анализа и представления информации, ориентированные на механизированную обработку информации.
Фаза построения завершается, когда все приложения протестированы на уровне программных единиц, создание пользовательской и системной документации практически закончено, база данных заполнена, а все элементы прошли начальный контроль качества в вашей компании.
Операции процесса сопровождения и инструментальные средства Oracle Designer. Все же стоит просмотреть полный перечень отчетов и определить, какие из них могут применяться в качестве системной документации или документации справочной службы на фазе внедрения.
Для ответов на эти вопросы у Вас есть два хороших источника информации: программист или системный аналитик и системная документация. Если система находится еще в стадии планирования, то документация к ней будет представлять собой функциональную или, возможно, программную спецификацию.
Здесь мы сознательно не употребляем термин база данных, как, впрочем, это вполне справедливо делается и в системной документации. Причина заключается в том, что концепция единой базы данных системой Clarion не поддерживается. По существу, совокупность файлов и таблиц, с которой работает система, не представляет собой единого целого. Все они существуют автономно, а если и взаимосвязаны каким-либо образом, то только в мысленном представлении проектировщика.
Значительная часть пользователей средств разработки систем баз данных для ПЭВМ, как, впрочем, и пользователей других программных продуктов, не считает нужным утруждать себя изучением системной документации. Специалисты этого типа полагают, что можно вполне ограничиться тем объемом знаний, который удается получить фольклорным путем от коллег или используя информацию, предоставляемую средствами оперативной помощи пользователю в инструментальных программных пакетах.
Разработанные в период 1961 - 1970 гг. методы формализованного определения систем были ориентированы на автоматизацию отдельных этапов проектирования, но такой подход не позволил вплотную приступить к автоматизации процесса проектирования, а дал лишь частичную возможность использовать ЭВМ на этапах анализа для машинной обработки системной документации.
Материалы данного раздела, к сожалению, не равноценны. Некоторые из них подготовлены на основе системной документации, специальных монографий или других достаточно содержательных публикаций, позволивших автору сформировать обстоятельное собственное мнение. В ряде случаев, однако, представленные здесь описания пришлось кропотливо реконструировать на основе рекламных материалов, а также иных частичных и недостаточно основательных источников.
Авторы считают своим приятным долгом выразить сердечную благодарность проф. Большую признательность авторы выражают В. Д. Мартынову за разработку системной документации для формализованного описания информационных потоков, а также М. Д. Оттмаа, Н. В. Астановской, Р. А. Асу за разработку программ, В. Г. Семеновой, И. Н. Копченовой и М. В. Ярушниковой за помощь при оформлении рукописи.
Создание документации по системе продолжается и во время фазы разработки. На фазе построения мы объединяем и завершаем системную документацию.

Отчеты, в которых фигурируют элементы фазы анализа, не слишком важны для пользовательской документации или для документации справочной службы. Однако можно представить группы текущих отчетов в качестве системной документации тем проектировщикам и разработчикам, которые не имеют доступа к репозиторию. Единственным недостатком таких отчетов является то, что они устаревают сразу же после внесения в репозиторий каких-либо изменений. Самой лучшей документацией для системы всегда является сам репозиторий, если, конечно, он обслуживается на должном уровне. Если отчеты крайне важны, можно создать отчет Report Builder, запрашивающий и отображающий текущее содержимое репозитория.
После шумного успеха на начальном этапе поставок версии dBaselV 1.0 пользователям судьба системы значительно осложнилась: в ней обнаружилось большое количество ошибок. Не поддерживается использование дополнительной памяти ПЭВМ, как было обещано в системной документации. Недостаточно высока производительность системы, она требует слишком много ресурсов на стадии исполнения. Как признали руководители Ashton-Tate, при разработке dBaselV были допущены также и некоторые просчеты архитектурного характера.
Эта проблема возникает при неудачном выборе структуры пользовательских интерфейсов и плохом качестве системной документации. Кроме того, чтобы полностью изучить некоторые системы, нужно обладать очень глубокими знаниями в области системного программирования. С увеличением числа модулей или команд, составляющих систему, увеличивается и число руководств, которые приходится штудировать. Для освоения большой системы нужно прочесть тысячи страниц. Хотя далеко не все имеют дело с полной документацией, объем ее все-таки, как правило, слишком велик. Документация на небольшие системы более обозрима, но это не обязательно означает, что она качественнее, полнее и доступнее.
На рис. 4.7 показана часть базы БДАРХ, которую использует отдельный протокольный объект. Каждый протокольный объект имеет связь со своим словесным описанием, находящимся в разделе системной документации, которая готовится разработчиком с fиспользованием штатных средств редактирования.
Дополнительно инженер знаний стремится усвоить объяснение и обоснование связей, условий и стратегических методов, которыми пользуется эксперт при решении задачи. Их очень важно регистрировать не только ради собственного понимания инженера знаний, но и для создания надлежащей системной документации и обеспечения точных объяснений системы. Эти типы знаний облегчают задачу проектирования, построения, а в последующем и модификации экспертной системы.
Этот уровень содержит информацию, необходимую для оценки эффективности функционирования системы, и поэтому является важной частью системной документации.
Хотя теоретически ни один проект не может развиваться без получения визы ККС, виза ККС 1 часто не принимается во внимание, а визы ККС 2 и ККС 3 получают задним числом. Это происходит из-за того, что, с одной стороны, нажимает руководство ( системы нужно разрабатывать быстрее), а с другой - не хватает времени у помощников вице-президента, в результате чего они не успевают изучить системную документацию. Виза же ККС 4 является обязательной, и к переводу системы на новую технологию никогда не приступают, не получив одобрения ККС. В частности, одобрение ККС при переводе системы ОТС на технологию баз данных было получено только на последнем этапе. Поскольку затраты на СУБД, СССД, преобразавание и дополнительный персонал вполне обоснованны, работам по ОТС дается высший приоритет, с тем чтобы ничто не мешало ее реализации.
В конце фазы построения система почти готова. База данных построена, данные перенесены, модули протестированы на уровне программных единиц. Остается только выполнить дополнительное тестирование, придать окончательную форму пользовательской и системной документации и обучить пользователей.
Организация документации. Чтобы проследить за каждым шагом процесса объединения, необходимо составить план объединения. И наконец, пятый и шестой уровни включают документацию по аппаратным средствам и план отладки аппаратных средств. Эти шесть уровней составляют полный набор системной документации, которая может сопровождаться и храниться в соответствии с принятыми нормами.
 
Loading
на заглавную 10 самыхСловариО сайтеОбратная связь к началу страницы

© 2008 - 2014
словарь online
словарь
одноклассники
XHTML | CSS
Лицензиар ngpedia.ru
1.8.11