Стадии и этапы создания АС 1 страница

2.1. Стадии и этапы создания АС в общем случае приведены в таблице.

2.2. Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта.

Допускается исключать стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.

3.2.2 ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

Общие положения

1.1. Техническое задание на автоматизированную систему (ТЗ на АС) является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС и т. п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

1.3. Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.

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

1.5. ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС», установленной ГОСТ 24.601.

1.6. В ТЗ на АС включают только те требования, которые дополняют требования к системам данного вида (АСУ, САПР, АСНИ и т. д.), содержащиеся в действующих НТД, и определяются спецификой конкретного объекта, для которого создается система.

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с ... ».

Состав и содержание

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

В ТЗ на АС могут включаться приложения.

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

В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.

2.3. В разделе «Общие сведения» указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

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

2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

1) назначение системы;

2) цели создания системы.

2.4.1. В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать.

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.

2.5. В разделе «Характеристики объекта автоматизации» приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание: Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

2.6. Раздел «Требования к системе» состоит из следующих подразделов:

1) требования к системе в целом;

2) требования к функциям (задачам), выполняемым системой;

3) требования к видам обеспечения.

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида.

2.6.1. В подразделе «Требования к системе в целом» указывают:

требования к структуре и функционированию системы;

требования к численности и квалификации персонала системы и режиму его работы;

показатели назначения;

требования к надежности;

требования безопасности;

требования к эргономике и технической эстетике;

требования к транспортабельности для подвижных АС;

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

требования к защите информации от несанкционированного доступа;

требования по сохранности информации при авариях;

требования к защите от влияния внешних воздействий;

требования к патентной чистоте;

требования по стандартизации и унификации;

дополнительные требования.

3.3 Концепция открытых систем. Основные понятия

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

Под основными свойствами открытости понимаются:

· переносимость и многократность использования программного обеспечения, данных и опыта людей;

· интероперабельность, т. е. возможность взаимодействия компонентов распределенной системы посредством обмена

· масштабируемость как свойство сохранения работоспособности системы ИТ в условиях варьирования значений параметров, определяющих технические и ресурсные характеристики системы и/или поддерживающей среды.

Более полные определения этих понятий мы рассмотрим ниже.

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

Пример 1. В данном примере зададимся целью определить профили основных функциональных компонентов корпоративной информационной технологии некоторой организации, которая хотела бы обеспечить переносимость разрабатываемых ей SQL-приложений (как серверной, так и клиентских частей), написанных с использованием языков C++ и SQL. При этом для определенности будем предполагать, что сетевая инфраструктура данной организации основана на использовании локальной оптоволоконной сети FDDI (смотри рисунок 3.2).

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

один, специфицирующий требования к интерфейсам клиентских систем,

другой - к интерфейсам сервера баз данных.

Рисунок 3.2 Пример корпоративной информационной системы

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

Для коммуникационного интерфейса можно выбрать протокол прикладного уровня RDA (ISO 9579), используемый, в частности, для реализации распределенных SQL-приложений с архитектурой клиент-сервер над стеком протоколов модели RM OSI. Для большей гибкости решения разобьем стек протоколов модели RM OSI на две группы - протоколы верхних трех уровней, которые обозначим OSI Stack (7-5), и протоколы транспортной системы, обеспечивающие транспортные услуги OSI в режиме с соединением.

В справочнике международных стандартизованных профилей существует профиль, описывающий набор протоколов для реализации передачи данных по транспортному протоколу OSI через локальную сеть FDDI. Данный профиль имеет наименование ТС54. Он включает ссылки на стандарт транспортного протокола OSI, стандарт протокола сетевого уровня (Х.25) вместе с дополнениями, адаптирующими этот протокол для использования в локальных сетях, а также ссылки на стандарты протоколов нижних уровней, определяющих функционирование сети FDDI. Профиль ТС54 является типичным примером OSI-профиля, так как определяет только функции сетевого взаимодействия, определенные стандартными протоколами, разработанными в соответствии с моделью RM OSI.

Таким образом, описание коммуникационного интерфейса в профиле Рс будет включать ссылки на следующие спецификации:

· стандарт протокола DRA,

· стандарты протоколов верхних уровней модели RM OSI (OS Stack (7-5)) профиль ТС54.

В состав спецификаций API следует включить стандарты языков C++ и SQL (обозначим их как Std «C++» и Std «SQL» соответственно), а также интерфейс RDA, реализующий сервис протокола RDA для клиентских систем. Таким образом, описание интерфейса API в профиле Рс включает ссылки на следующие спецификации:

· Std «C++»

· Std «SQL»

· интерфейс RDA-клиента.

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

Профиль серверной части, обозначим его Ps, будет содержать идентичный с профилем Рс коммуникационный интерфейс (иначе клиентские и серверные системы не смогли бы взаимодействовать). Интерфейс API профиля Ps будет почти идентичным соответствующему интерфейсу профиля Рс, за исключением различий в программных интерфейсах для сервиса RDA в клиентской и сервисных системах. Однако для простоты примера не будем заострять внимание на этих различиях.

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

Стандартизации сервисов и принципов функционирования систем обработки сообщений (Message Handling System - MHS) посвящена серия рекомендаций ITU-T X.400 (в эквивалентном этим рекомендациям стандарте ISO 10021 системы данного класса называются системами обмена текстовыми сообщениями (Message-oriented Text Interchange Systems - MOTIS)). Кроме этого, серия F.400 рассматривает вопросы использования для передачи сообщений систем телематики (телекс, телетекст, видеотекст, факс) и систем физической доставки сообщений (почта, курьерская доставка), а также использование систем передачи сообщений для передачи электронных данных.

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

Прежде, чем перейти к описанию профилей для классов систем MHS, рассмотрим функциональную модель системы обработки сообщений, а также принципы ее работы. Данная модель иллюстрируется на приведенном ниже рисунке 3.3.

Рисунок 3.3. Функциональная модель системы обработки сообщений (MHS):

На рисунке обозначено:

MTS - Message Transfer System - система передачи сообщений;

МТА - Message Transfer Agent - агент системы передачи сообщений;

MS — Message Store - система хранения сообщений;

UA — User Agent — агент пользователя;

PDAU - Physical Delivery Access Unit - блок доступа к услугам физической доставки;

AUs - Access Units - блоки доступа к услугам систем телематики;

user – пользователь.

Система обработки сообщений предоставляет пользователям возможность обмениваться сообщениями на основе метода промежуточного хранения сообщений (Store-and-forward - запомни-передай). Сообщения, отправляемые пользователем-отправителем (originator) через соответствующий ему прикладной процесс UA, передаются системой передачи сообщений MTS (являющейся составной частью системы обработки сообщений MHS) одному или нескольким пользователям -получателям (recipient). Все функции в MHS выполняются активными сущностями (прикладными процессами OSI), какими являются МТА, MS, UA, AU.

В частности:

· агенты МТА обеспечивают передачу между узлами системы MTS накопленных в них сообщений, а также предоставление сервиса MTS своим пользователям (агентам UA и системам хранения MS);

· системы хранения сообщений MS хранят полученные от MTS сообщения и предоставляют возможность своим пользователям осуществлять поиск полученных сообщений и манипулирование ими;

· агенты UA обеспечивают пользователям доступ к сервисам MHS;

· блоки доступа AU реализуют подключение к системе передачи MTS различных служб телематики и служб физической доставки почты.

Для описанной системы может быть применена система профилей X.400, которая содержит описание сервисов рассмотренных выше функциональных компонентов системы MHS и протоколов взаимодействия между ними. Это описание содержит несколько сотен страниц и охватывает три сферы применения систем MHS, а именно: