ПОИСК Статьи Чертежи Таблицы Общие требования из "Как интегрировать САПР и АСТПП " Пользовательская документация. Она должна быть написана с учетом того, что пользователь может быть не знаком с компьютер -ной технологией. Поэтому ее следует изложить в понятных словах, старательно избегая технических терминов, сокращений и жаргона (если они не являются специфическими для технической функции пользователя). [c.245] В объяснении а не ясно, что вы — это пользователь, набирающий на клавиатуре данные. Оно написано в высокопарном стиле третьего лица. Объяснение б напоминает беседу одного человека с другим. Оно также указывает, как вам узнать, что сделанное вами оказалось успешным и тем самым оказывает существенную помощь в овладении новым для вас мастерством. [c.246] В пользовательской документации должны присутствовать следующие разделы. [c.246] Программная документация. Основная цель программной документации состоит в облегчении сопровождения. Имейте это в виду при изготовлении всей документации. Как минимум программная документация должна содержать следующие данные. [c.246] Логика. Документ о назначении каждой существенной части программы. Если есть сложная логика, включите раздел с формулировкой содержания этой логики. [c.246] Раздел работы над ошибками. Для каждого блока обработки ошибки документируйте, какой отказ или какая ошибка вызывают работу этого блока. Кратко укажите, какие действия предпринимаются для обнаружения дефекта. [c.246] Типовые стандарты программирования. При программировании преследуются следующие цели. [c.247] НЕОБХОДИМО выполнить предписанную работу, т. е. функционировать так, как описано в функциональных спецификациях. [c.247] НЕОБХОДИМО обрабатывать вое условия возникновения ошибок (а не просто выходить из строя). Если вы не в состоянии предвидеть все возможные проблемы, то обеспечьте раздел последнего средства с дампом информации, достаточной для отладки программы. Для экранных программ нужен дамп в файл (а не только показ на экране сообщения об ошибке). Пользователи часто неточно записывают или докладывают сообщения, появляющиеся на экране. [c.247] НЕОБХОДИМО освободиться от ошибок до передачи для производственного (пользовательского) применения. СЛЕДУЕТ обеспечивать эффективность, используя для выполнения задания минимум вычислительных ресурсов. [c.247] СЛЕДУЕТ применять ясную логику, доступную для персонала сопровождения (см. следующий раздел). [c.247] СЛЕДУЕТ обеспечивать быструю работу. [c.247] Присваиваемые этим стандартом приоритеты могут весьма изменяться от организации к организации в зависимости от ориентации, но пренебрежение любым из них быстро приведет к возникновению проблем. [c.247] Что такюе ясная логика Поток управления в программе, направленный в основном от начала (сверху) к концу (вниз), а не иначе. [c.247] При каждой возможности избегайте операторов 1Р, вложенных 13 глубину более двух уровней. [c.247] Если из соображений производительности вы применяете специ-1льные приемы (например, стеки запросов ввода-вывода, системных Ызовов и т. д.), то документируйте причину такого решения. [c.247] Производительность. При проектировании текста программы юдумайте о том, что будет влиять на производительность. Особенно [ритическими являются обращения к базам данных. Обсудите вою предполагаемую последовательность обращений с человеком, [меющим некий опыт программирования баз данных в системе, оторой вы пользуетесь. Применяйте монитор производительности программ, если он существует. [c.247] Пра использованяи циклов убедитесь в том, что цикл не содержит оператора, не зависящего от переменной цикла. Если же он содержит такой оператор, то вы без надобности повторяете одни и те же вычисления. [c.248] Вернуться к основной статье