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-й системе стандартов два определения одного и того же термина, причем в одном из них идет речь о комплексе документов, а в другом - о комплекте.



 

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

33476. Вина 46 KB
  Форми вини — це зазначені в кримінальному законі сполучення певних ознак свідомості і волі особи, що вчиняє суспільно небезпечне діяння
33477. Виправні роботи 26 KB
  57 КК застосовуються до особи за місцем роботи на строк визначений за вироком суду з відрахуванням у доход держави відповідного відсотка її заробітку. Виправні роботи призначаються на строк від шести місяців до двох років і обов'язково супроводжуються відрахуванням із суми заробітку засудженого у доход держави в розмірі встановленому вироком суду в межах від десяти до двадцяти відсотків заробітку засудженого. Виправні роботи це покарання яке широко застосовується на практиці.
33478. Громадські роботи 24.5 KB
  56 КК полягають у виконанні засудженим у вільний від роботи чи навчання час безоплатних суспільне корисних робіт вид яких визначають органи місцевого самоврядування. Громадські роботи встановлюються на строк від шістдесяти до двохсот сорока годин і відбуваються не більш як чотири години на день.
33479. Звільнення від кримінальної відповідальності 26 KB
  Перебіг давності переривається в разі ухилення особи від органу досудового розслідування або суду або в разі вчинення іншого злочину середньої тяжкості тяжкого чи особливо тяжкого. Давність не застосовується в разі вчинення таких злочинів: ст.
33480. Територія України 29.5 KB
  6 КК де зазначено що особи які вчинили злочини на території України підлягають кримінальній відповідальності за цим Кодексом. б КК злочин визнається вчиненим на території України якщо його було почато продовжено закінчено або припинено на території України незалежно від того де особу було віддано до суду в зв'язку з його вчиненням. Зазначене положення охоплює як випадки вчинення всього діяння на території України так і випадки вчинення діяння як на території України так і на території інших держав. Поняттям територія України...
33481. Принципи чинності кримінального закону у часі 30.5 KB
  За загальним правилом закон про кримінальну відповідальність набирає чинності через десять днів з дня його офіційного оприлюднення. При цьому під опублікуванням закону про кримінальну відповідальність треба розуміти опублікування його в офіційному друкованому виданні.Зворотна дія закону про кримінальну відповідальність. Закон про кримінальну відповідальність який скасовує злочинність діяння або пом’якшує кримінальну відповідальність має зворотну дію у часі тобто поширюється на осіб що вчинили відповідні діяння до набрання таким законом...
33482. Ексцес виконавця 26 KB
  Ексцес виконавця вчинення виконавцем злочину дій які не охоплюються умислом інших співучасників якщо його дії утворюють самостійний склад злочину або його дії суттєво відрізняються від дій запланованих іншими учасниками. Кількісний ексцес має місце там де виконавець учинив однорідний злочин але більш тяжкий ніж було заплановано співучасниками наприклад вчинив розбій замість крадіжки. В цьому разі виконавець несе відповідальність за статтею що передбачає покарання за фактично вчинений ним злочин а співучасники несуть...
33483. Загальні засади призначення покарання 28 KB
  Інакше кажучи яка б кримінальна справа не розглядалася яке б покарання не призначалося винному суд зобов'язаний виходити з цих загальних критеріїв. 65 загальні засади призначення покарання складаються з таких трьох критеріїв. Суд призначає покарання: 1 у межах встановлених у санкції статті Особливої частини КК що передбачає відповідальність за вчинений злочин; 2 відповідно до положень Загальної частини КК; 3 враховуючи ступінь тяжкості вчиненого злочину особу винного та обставини що пом'якшують та обтяжують покарання.
33484. Звільнення від відбування покарання з випробуваннями 41.5 KB
  Відомий багато років нашому праву інститут засудження з випробуванням умовне засудження і відстрочка виконання вироку трансформований новим КК в один із видів звільнення від відбування покарання звільнення від відбування покарання з випробуванням. 75 КК зазначено якщо суд при призначенні покарання у виді виправних робіт службових обмежень для військовослужбовців обмеження волі а також позбавлення волі на строк не більше п'яти років враховуючи тяжкість злочину особу винного та інші обставини справи дійде висновку про можливість...