96389

Стандарты и профили в области ИС

Лекция

Информатика, кибернетика и программирование

Опыт разработки крупных ИС показывает что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы.; требования к конфигурации рабочих мест разработчиков включая настройки операционной системы настройки CASE-средств общие настройки проекта и т.д.

Русский

2015-10-05

45.4 KB

1 чел.

Тема 1. Стандарты и профили в области ИС

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

  1.  технология должна поддерживать полный ЖЦ ПО;
  2.  технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
  3.  технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
  4.  технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
  5.  технология должна обеспечивать минимальное время получения работоспособной ИС.
  6.  технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
  7.  технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
  8.  технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

К таким стандартам относятся следующие:

  1.  стандарт проектирования;
  2.  стандарт оформления проектной документации;
  3.  стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

  1.  набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
  2.  правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;
  3.  требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;
  4.  механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.

Стандарт оформления проектной документации должен устанавливать:

  1.  комплектность, состав и структуру документации на каждой стадии проектирования;
  2.  требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),
  3.  правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
  4.  требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
  5.  требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
  6.  Стандарт интерфейса пользователя должен устанавливать:
  7.  правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
  8.  правила использования клавиатуры и мыши;
  9.  правила оформления текстов помощи;
  10.  перечень стандартных сообщений;
  11.  правила обработки реакции пользователя.

Проектирование и разработка сложных ИС может быть выполнена с применением программных инструментариев СУБД Oracle: функциональная модель может быть построена с помощью Process Modeller, Function Hierarchy Diagrammer; база данных логического уровня – с помощью Entity Relationship Diagrammer; пользовательский интерфейс – на основе языка 4-го поколения Oracle Forms и программные модули на языке 3-го поколения PL/SQL.

Для проектирования и разработки простых ИС, в том числе и для учебных целей, удобно использовать более простые программные инструментарии. Обычно в этих случаях применяют пакет BPwin для построения всего комплекта диаграмм для описания функционального наполнения предметной области: организационная диаграмма, диаграммы плавательных дорожек и интегрированная иерархическая функциональная модель на основе методологий IDEF0, IDEF3, DFD.

Информационная модель логического и физического уровней строится с помощью пакета ERwin в виде ER-диаграммы.

Пользовательский интерфейс и программные модули реализуются в среде СУБД Access или с помощью средства быстрого разработки программного обеспечения Delphi.

Стандартизация процесса разработки ИС (СИО)

В настоящее время существует ряд общих методологий разработки ИС. Главное в них – единая дисциплина работы на всех этапах жизненного цикла системы, учет критических задач и контроль их решения, применение развитых инструментальных средств поддержки процессов анализа, проектирования и реализации ИС.

Понятие жизненного цикла информационной системы

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов.

В общем случае под термином жизненный цикл системы понимается определенная эволюция, период времени и совокупность работ, меняющих состояние системы от появления замысла и начала ее разработки до окончания эксплуатации. Понятие ЖЦ системы позволяет определить понятие жизненный цикл ИС (ЖЦ ИС) – это модель создания и использования (эволюция) ИС, отражающая ее различные состояния, начиная с момента возникновения необходимости в данном комплексе средств создания и обмена информацией, и заканчивая моментом ее полного выхода из употребления у пользователей.

Модель жизненного цикла информационной системы включает в себя:

  1.   последовательность выполняемых стадий;
  2.   результаты выполнения работ на каждой стадии;
  3.   ключевые события - точки завершения работ и принятия решений.

Стадия ЖЦ – это часть процесса создания ИС, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями. Для каждой стадии определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Соотношение между процессами и стадиями определяется используемой моделью жизненного цикла ИС. Стадии ЖЦ системы могут повторяться итерационным образом в связи с постепенным уточнением требований к системе и/или с необходимостью ее адаптации к тем изменениям, которые возникают в предметной области системы.

Условными стадиями жизненного цикла ИС являются анализ, проектирование, реализация проекта, внедрение (ввод в эксплуатацию), сопровождение (эксплуатация, наращивание возможностей – модернизация), вывод из эксплуатации (замена):

анализ – определение того, что должна делать система;

проектирование  (концептуальная разработка) – определение того, как система будет делать то, что она должна делать. Проектирование – это, прежде всего, спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;

реализация (физическая разработка) – создание функциональных компонентов и подсистем по отдельности, соединение подсистем в единое целое и тестирование – проверка функционального и параметрического соответствия системы показателям, определенным на этапе анализа;

внедрение – установка и ввод системы в действие;

эксплуатация: сопровождение – обеспечение штатного процесса эксплуатации системы на предприятии заказчика.

Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом. Такой цикл проходят все технические, технологические и иные информационные системы и в каждом случае они должны быть экономически обоснованы и привязаны к конкретным условиям.

Структура ЖЦ

Поскольку ЖЦ – это технологический процесс разработки информационной системы, то нормативно-методическая документация в первую очередь должна регламентировать и методически поддерживать процессы жизненного цикла.

Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-02 [5]. Согласно стандарту структура жизненного цикла основывается на трех группах процессов:

основные процессы (заказ, поставка, разработка, эксплуатация, сопровождение);

вспомогательные процессы (обеспечивают выполнение основных процессов):

документирование – работы по разработке, выпуску, редактированию, распространению и сопровождению документов, в которых нуждаются все заинтересованные лица;

управление конфигурацией (конфигурационное управление) включает работы: определение и установление состояния программных объектов в системе; управление изменениями и выпуском объектов; обеспечение полноты, совместимости и правильности объектов; управление хранением, обращением и поставкой объектов;

обеспечение качества – работы по обеспечению соответствия создаваемой системы и реализуемых процессов жизненного цикла установленным требованиям и утвержденным планам;

верификация – работы соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия создаваемых промежуточных результатов установленным требованиям по мере реализации проекта. Различают верификацию договора, процесса, требований, проекта, системы, сборки системы и документации;

аттестация – работы соответствующего субъекта по проверке полного соответствия требований и конечного продукта функциональному назначению системы;

совместный анализ – работы по оценке состояния или результатов какой-либо работы (системы);

аудит – работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора;

разрешение проблем – работы по анализу и устранению проблем, обнаруженных при реализации проекта;

организационные:

управление проектами – работы по планированию и управлению процессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности;

создание инфраструктуры проекта – работы по установлению и обеспечению инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения системы;

усовершенствование – работы по оценке, контролю и улучшению процессов жизненного цикла;

обучение – работы по планированию и проведению обучения персонала, включая разработку учебных материалов. При этом под персоналом понимаются не только конечные пользователи, которые будут эксплуатировать систему, но и разработчики системы. Например, разработчики должны быть обучены технологиям и средствам программирования, принятым в организации, и даже обучены правильно внедрять и обучать конечных пользователей работе с системой. Как бы это ни парадоксально звучало, но обучать правильной методике и приемам обучения тоже необходимо.

Основные процессы жизненного цикла

 В табл. 2.1 предпринята попытка сопоставления стадий классического жизненного цикла (автор Уинстон Ройс, 1970 г.), стандарта ИСО/МЭК 12207-02, ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00.

Таблица 1. Стадии жизненного цикла информационной системы

Классический ЖЦ

ИСО/МЭК 12207

ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00

Стадия

Основные этапы (работы)

Систем-ный анализ

Заказ

Формирование требований к ИС

Технико-
экономическое обоснование
1
(ТЭО)

1. Обследование объекта и обоснование необходимости создания ИС.
2. Формирование требований Заказчика к ИС.
3. Оформление договора между Разработчиком и Заказчиком.

Анализ требова-ний

Разработка

Разработка концепции ИС (для комплексн. многоуровни интегрир. систем)

1. Поиск путей удовлетворения требований Заказчика на уровне концепции создаваемой системы (структура, функции, программно-техническая платформа, режимы).
2. Рассмотрение альтернативных вариантов концепции системы, их анализ и выбор лучшей концепции.

Проектирование

Техническое задание (ТЗ)

Разработка, согласование и утверждение ТЗ на создание ИС.

Эскизный проект
(для комплексных многоуровн-х и интегриров. систем)

Разработка предварительных проектных решений2 по системе и ее частям.

Пилот-проект
(макетирование
3, прототипирование)
(при необходимости)

1. Разработка частей проекта для испытаний в реальных, но ограниченных условиях функционирования с целью проверки предварительно принятых решений.
2. Проведение испытаний на головном объекте или стенде и анализ результатов испытаний.

Технический проект

1. Разработка проектных решений по системе и ее частям.
2. Разработка документации на ИС и ее части.
3. Разработка документации на поставку изделий для комплектования ИС и/или технических заданий на их разработку.
4. Разработка заданий на проекти-рование в смежных частях проекта объекта автоматизации (строи-тельство, монтаж, наладка и др.).

Кодирование
(реализация)

Рабочая документация

1. Разработка рабочей документации на систему и ее части.
2. Разработка программных и технических средств и/или адаптация приобретаемых.
3. Тестирование средств.

Тестирование

Интеграция и тестирование

1. Загрузка БД типовыми исходными данными и тестами.
2. Интеграция программ и тестирование в имитированной среде.
3. Интеграция программных средств с аппаратными в реальной операционной и внешней среде.
4. Тестирование в реальной среде.
5. Разработка комплекта документации для пользователей.

Внедрение
и
сопровождение

Поставка
и
эксплуатация

Ввод в действие на головном объекте
(ввод в эксплуатацию, внедрение)

1. Подготовка объекта автоматизации к вводу ИС в действие.
2. Подготовка персонала.
3. Комплектация ИС поставляемыми изделиями.
4. Проведение предварительных испытаний
4 и передача ИС для опытной эксплуатации5.
5. Проведение опытной экспл-ции.
6. Проведение приемочных испытаний
6 по сдаче ИС в постоянную эксплуатацию.

Тиражирование
(при внедрении на нескольких объектах)

1. Передача эталона загрузочных модулей ПО и эксплуатю докум-ции в группу сопровождения или ОФАП7 ОАО «РЖД».
2. Тиражирование документации.
3. Обучение и консультации пользователей.
4. Поставка ПО и документации на объекты внедрения.

Сопровождение
и
эксплуатация

Сопровождение
(авторский надзор)

1. Выполнение работ в соотв-вии с гарантийными обязательствами8.
2. Оказание научно-технических услуг в послегарантийный период
9.
3. Разработка методики оформления отчетов об ошибках и предложениях на изменение версий. 4. Учет состояния конфигураций ИС.

Примечания:

1. Не по ГОСТ и ОРММ ИСЖТ.

2. Основные проектные решения на создание ИС включают в себя определение:

- функциональной и организационной структур системы;

- состава и структуры комплекса технических и программных средств;

- применяемых инструментальных средств;

- технологии обработки информации;

- состава, структуры и технологии ведения информационной базы;

- входных и выходных форм;

- алгоритмов обработки данных.

3. Цель макетирования (прототипирования) - снять неопределенность в требованиях Заказчика.

4. Предварительные испытания информационной системы проводят для определения ее работоспособности и решения вопроса о возможности приемки ее в опытную эксплуатацию.

5. Опытную эксплуатацию проводят с целью определения фактических значений количественных и качественных характеристик информационной системы; готовности персонала к работе с ней; фактической эффективности ее работы; корректировки (при необходимости) документации.

6. Приемочные испытания проводят для определения соответствия информационной системы ТЗ, оценки качества опытной эксплуатации и решения вопроса о возможности приемки ИС в постоянную (промышленную) эксплуатацию.

7. ОФАП – отраслевой фонд алгоритмов и программ.

8. Гарантийные обязательства (выполняются бесплатно согласно договору):

- устранение выявленных недостатков и ошибок;

- внесение необходимых изменений в программы и документацию;

- внесение изменений в технологический процесс;

- консультации пользователей.

9. Послегарантийные обязательства (выполняются за отдельную плату):

- анализ функционирования системы;

- выявление отклонений фактических эксплуатационных характеристик ИС от проектных значений и установление причин этих отклонений;

- устранение выявленных недостатков и обеспечение стабильности эксплуатационных характеристик ИС;

- внесение необходимых изменений в документацию на ИС;

- передача очередных версий.

 

В табл. 1 отсутствует процесс поставки из стандарта ИСО/МЭК 12207-02, так как он определяет работы, выполняемые на всем протяжении жизненного цикла. Эти работы связаны с управлением и обеспечением проекта, начиная с момента подготовки договора и заканчивая сопровождением.

Согласно ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00 допускается:

- исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях;

- объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект»;

- выполнять отдельные этапы работ до завершения предшествующих стадий;

- параллельное во времени выполнение этапов работ;

- включение дополнительных этапов работ.

Распределение обязанностей между участниками проекта

 

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

Таблица 2. Роли участников в проекте

Роль

Функции

Руководитель (менеджер) проекта

Ищет потенциальных заказчиков. Заключает договор на разработку системы. Отвечает за планирование сроков и ресурсов. Выполняет управление и контроль за ходом выполнения проекта. Отвечает за взаимодействие с заказчиком

Эксперт-технолог

Делает постановку задачи. Определяет (совместно с системным аналитиком) основные функциональные и нефункциональные требования к системе. Определяет технологию использования разрабатываемой системы. Консультирует разработчиков в процессе создания системы. Участвует в процессе приемки системы в эксплуатацию

Системный аналитик (архитектор, главный конструктор)

Определяет функциональные и нефункциональные требования к системе, а также технологию ее использования. Выполняет анализ требований и ищет пути их реализации на уровне концепции системы. Задает архитектуру (скелет) системы и несет ответственность за соответствие моделей системы заданной архитектуре (отвечает за проектирование). Квалифицированный аналитик должен быть специалистом в области разработки программного обеспечения и должен быть (стать) специалистом в предметной области

Проектировщик

Разрабатывает модели системы на основе архитектуры

Программист

Реализует модели в виде программного обеспечения

Тестировщик

Разрабатывает тесты и тестирует модели системы и разработанное программное обеспечение

Технический редактор (писатель)

Готовит документацию для пользователей на разработанную систему. В комплект документации могут входить технологические инструкции, руководства пользователя, администратора системы, БД и т. д.

Инженер по внедрению

Внедряет разработанную систему на объекте автоматизации. В его функции может входить как первоначальная установка и настройка системы, так и обучение пользователей

Пользователь

Эксплуатирует систему в штатном режиме. Желательно, чтобы пользователь (помимо эксперта-технолога) был вовлечен в процесс формирования требований к системе

 У проекта должен быть один руководитель и, как правило, один системный аналитик. За остальные роли в крупных проектах отвечает обычно по несколько человек. В табл. 2.2 роли эксперта-технолога и пользователя выполняют представители заказчика, остальные роли – представители разработчика. Эксперты-технологи могут быть приглашены из сторонней организации. По мере необходимости в проекте могут принимать участие

координатор работ (ответственный) со стороны заказчика, аудиторы и т. д.

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

Нормативно-методическая база процесса разработки ИС (организации жизненного цикла ИС) включает следующие стандарты:

  1.   Стандарты обеспечения качества
  2.   Стандарты надежности
  3.   Стандарты разработки ИС
  4.   Стандарты тестирования
  5.   Стандарты документирования
  6.   Стандарты интерфейса
  7.   Стандарты программирования
  8.   Стандарты обмена данными

Техническое документирование.

Каждый процесс ЖЦ ИС характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы.  На каждом этапе жизненного цикла порождается определенный набор технических решений и отражающих их документов, при этом для каждого этапа исходными являются документы и решения, принятые на предыдущем этапе. В процессе разработки ИС разрабатывается техническая документация на систему.

Термин «техническая документация» в различных источниках трактуется по-разному. Можно дать такое определение технической документации – это коммерческие документы, которые нужны при поставках оборудования и технических потребительских товаров длительного пользования. В документе Р 50-605-80-93 «Система разработки и постановки продукции на производство. Термины и определения» техдокументация представлена как совокупность документов, необходимая и достаточная для непосредственного использования на каждой стадии жизненного цикла продукции.

К технической документации относятся: конструкторская, технологическая документация,  техническое задание на разработку продукции и т.д.

Техническую документацию можно подразделить на три категории:

  1.   Документация разработки. Документы описывают процесс разработки ИС, определяют требования, которым должна удовлетворять ИС, определяют проект ИС, определяют как его контролируют и как обеспечивают его качество. Документация разработки также включает в себя подробное описание ИС. Разработка документов преследует следующие цели:
  2.   они являются средствами связи между всеми участникам и описывают подробные решения, принятых относительно требований к ИС, проекту, программированию, тестированию и т.д.;
  3.    они описывают обязанности группы разработки и определяют, кто, что и когда делает, учитывая роли всех групп пользователей;
  4.   они выступают как контрольные пункты, которые позволяют руководству оценивать ход разработки;
  5.   они образуют основу документации сопровождения ИС, как часть документации продукции;
  6.   они описывают историю разработки ИС.

Документация разработки включает: исходную, проектную, рабочую, информационную документацию:

  1.   к исходной относятся: заявка на разработку и освоение продукции, исходные требования, аванпроект, рекомендации по разработке продукции, выполняемые в процессе НИР, техническое задание.
  2.   к проектной документации относятся: для конструкторской документации - техническое предложение, эскизный проект, технический проект; для технологической - предварительный проект.
  3.   к рабочей документации - рабочая конструкторская, технологическая документация, эксплуатационная документация, ремонтная документация.
  4.   к информационной документации - карта технического уровня и качества продукции, патентный формуляр, информационная карта расчета экономической эффективности и цен новой (модернизированной) продукции, каталоги, отчет о патентных исследованиях, экспертное заключение, акты и протоколы об испытаниях, решение о снятии продукции с производства и др. [из п. 1.6.1 Р 50-605-80-93].
  5.   Документация продукции. Эта документация обеспечивает информацию, необходимую для эксплуатации ИС (использования ИС в деятельности предприятия), а так же сопровождения, модернизации, преобразования и передачи проектной документации. Эта документация преследует следующие цели:
  6.   обеспечение учебной и справочной информации для любого, использующего или эксплуатирующего ИС;
    1.   облегчение сопровождения и модернизации ИС, специалистам, не разрабатывающим ИС;
    2.   помощь при продаже или приемке ИС.

Документация продукции должна включать материалы для следующих групп: пользователей, операторов, сопровождающих программистов и т.д. Эта документация включает: учебные руководства, справочные руководства и руководства пользователей, руководства по сопровождению.

Если обратиться к ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя……., то в нем вводится определение документации пользователя, как документации, которая обеспечивает пользователя информацией, необходимой для установки и прогона ПО и является обязательной в поставке (документация пользователя выполняется в виде одного или нескольких руководств и вкладывается вместе с программным продуктом внутрь упаковки). Данный стандарт определяет три категории информации:

  1.   обязательная – информация, поставляемая с каждым пакетом;
  2.   условная – информация, поставляемая с каждым пакетом. для которого она необходима;
  3.   факультативная – информация, поставляемая с каждым пакетом по усмотрению изготовителя или торгующей организации.

Назначением документации пользователя является обеспечение конечного пользователя достаточной информацией для ясного понимания:

  1.   целей, функций и характеристик ПО;
  2.   того, как ввести в действие и использовать ПО;
  3.   договорных прав и обязанностей.
  4.   Документация управления проектом. Документы создаются на основе информации управления проектом, такой как:
  5.   графики для каждой стадии процесса разработки и отчеты об изменениях графика;
    1.   отчеты о согласованных изменениях ИС;
      1.   отчеты о решениях, связанных с разработкой ИС;
      2.   распределение обязанностей.

Структура проектной, технологической и эксплуатационной документации, языки ее представления должны быть стандартизованными, поскольку одна и та же проектная документация может быть использована многократно в разных проектах, а одна и та же технологическая документация – в разных производственных условиях, что существенно сократит и удешевит общий цикл проектирования и производства.

Р 50-605-80-93 дает определение техдокументации на промышленную продукцию в целом. Для автоматизированных систем, являющихся частным случаем промышленной продукции, нормативно-технической документацией предусмотрены целых два определения:

«Комплект взаимоувязанных документов, полностью определяющих технические требования к АС, проектные и организационные решения по созданию и функционированию АС» [из п. 5.1 ГОСТ 34.003-90]

В ГОСТ 34.201-89 имеется иная трактовка, а именно:

Документация на автоматизированную систему - комплекс взаимоувязанных документов, в котором полностью описаны все решения по созданию и функционированию системы, а также документов, подтверждающих соответствие системы требованиям технического задания и готовность ее к эксплуатации (функционированию) [из п. 1 Приложения 1 ГОСТ 34.201-89].

Довольно странно видеть в единой 34-й системе стандартов два определения одного и того же термина, причем в одном из них идет речь о комплексе документов, а в другом - о комплекте.



 

А также другие работы, которые могут Вас заинтересовать

44801. Земная кора 20.22 KB
  Мантия Земли Мантия это силикатная оболочка Земли сложенная преимущественно перидотитами породами состоящими из силикатов магния железа кальция и др. Мантия составляет 67 всей массы Земли и около 83 всего объёма Земли. Хотя сведения о составе нижней мантии ограничены и число прямых данных весьма невелико можно уверенно утверждать что её состав со времён формирования Земли изменился значительно меньше чем верхней мантии породившей земную кору.
44802. Атмосфера 36.5 KB
  Нижний наиболее плотный слой воздуха тропосфера ее высота 10 15 км. В вертикальном распределении температуры имеет место максимум около 0 С Выше стратосферы примерно до высоты 80 км простирается мезосфера в которой температура воздуха с высотой падает до нескольких десятков градусов ниже нуля. Под действием ультрафиолетовой и рентгеновской солнечной радиации и космического излучения происходит ионизация воздуха основные области ионосферы лежат внутри термосферы. Далее до 10 000 км простирается экзосфера где плотность воздуха с...
44803. География населения. Демографические показатели регионов мира 15.99 KB
  Демографические показатели регионов мира География населения изучает численность структуру и размещение населения рассматриваемого в процессе общественного воспроизводства и взаимодействия с окружающей природной средой. Под воспроизводством населения понимают совокупность процессов рождаемости смертности и естественного прироста которые обеспечивают беспрерывное возобновление и смену людских поколений. Для первого типа характерны относительно невысокие показатели рождаемости смертности и естественного прироста для экономически развитых...
44804. Правило минимума Либиха. Закон оптимума. Закон толерантности Шелфорда 38 KB
  Закон оптимума. Закон толерантности Шелфорда. Закон минимума Либиха закон открытый. Либихом 1840 согласно которому относительное действие отдельного экологического фактора тем сильнее чем больше он находится по сравнению с другими факторами в минимуме; по данному закону от вещества концентрация которого лежит в минимуме зависят рост растений величина и устойчивость их урожайности.
44805. Понятие популяции. Структура и динамика популяций 41 KB
  Свободно скрещивающихся и дающих плодовитое потомство Основные характеристики популяций: 1 численность– общее количество особей на выделяемой территории; 2 плотность популяции – среднее число особей на единицу площади или объема занимаемого популяцией пространства; плотность популяции можно выражать также через массу членов популяции в единице пространства; 3 рождаемость– число новых особей появившихся за единицу времени в результате размножения; 4 смертность – показатель отражающий количество погибших в популяции особей за...
44806. Потоки вещества и энергии в биологических сообществах. Продуценты, консументы, редуценты. Трофические цепи и трофические сети. Пирамиды численности и биомассы в сообществах 37.5 KB
  Энергия основа работы экосистемы основной источник энергии Солнце. Поток солнечной энергии протекает через фототрофные экосистем при передаче в пищевых трофических цепях происходит рассеивание в виде тепла Пищевая цепь сеть – последовательность организмов где каждый предыдущий пища для последующего. Из всей поступающей солнечной энергии растениями усваивается только 2 остальное расходуется на транспирацию отражается листьями идет на нагревание воздуха воды и почвы.
44807. Продуктивность экосистем. Первичная и вторичная продукция 18.66 KB
  Пример экосистемы пруд с обитающими в нём растениями рыбами беспозвоночными животными микроорганизмами составляющими живую компоненту системы биоценоз. Все живые компоненты экосистемы – продуценты консументы редуценты составляют общую биомассу живой вес. Для экосистемы океана пирамида биомассы имеет перевернутый вид т. Знание энергетики экосистемы и количественных ее показателей позволяют точно учесть возможность изъятия из природной экосистемы того или иного количества растительной и животной биомассы без подрыва ее эффективности.
44809. Тhe purpose of grammar as a linguistic discipline 25 KB
  Lаnguаge is mens of forming nd storing ides s reflections of relity nd exchnging them in the process of humn intercourse. Lnguge is socil by nture; Lnguge incorportes the three constituent prts sides ech being inherent in it by virtue of its socil nture. Only the unity of these three elements forms lnguge; without ny one of them there is no humn lnguge in the bove sense. The phonologicl system is the subfoundtion of lnguge; it determines the mteril phoneticl ppernce of its significtive units.