Проектирование информационных систем

1. Стандарт 12207. Основные процессы. Место процессов в ЖЦ ИС.

ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД). В последние годы, акцент делается на стандарты ГОСТ, соответствующие международным стандартам. В то же время, 34-я серия является важным дополнительным источником информации для разработки и стандартизации внутрикорпоративных документов и формирования целостного понимания и видения концепций жизненного цикла в области программного обеспечения.

Стандарт описывает 17 процессов жизненного цикла, распределенных по трем категориям (основные, вспомогательные, организационные) процессов (названия представлены с указанием номеров разделов стандарта, следуя определениям на русском и английском языке, определяемыми [ГОСТ 12207, 1999] и оригинальной версией ISO/IEC 12207, соответственно):

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

Основные процессы инстанцируют согласно ситуации.

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

1 Заказ (приобретение). Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений.

Все работы проводятся в рамках проектного подхода.

2 Поставка. Процесс поставки, в свою очередь, определяет работы и задачи поставщика. Работы также проводятся с использованием проектного подхода.

3 Разработка. Процесс разработки определяет работы и задачи разработчика.

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

4 Эксплуатация. Процесс разработки определяет работы и задачи оператора службы поддержки.

5 Сопровождение. Процесс разработки определяет работы и задачи, проводимые специалистами службы сопровождения.

Таблица - Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

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

создающая и реализующая данный процесс. Данная организация гарантирует реальность существования и функциональные особенности конкретного процесса.

2. Стандарт 12207. Вспомогательные процессы. Место процессов в ЖЦ ИС.

ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД). В последние годы, акцент делается на стандарты ГОСТ, соответствующие международным стандартам. В то же время, 34-я серия является важным дополнительным источником информации для разработки и стандартизации внутрикорпоративных документов и формирования целостного понимания и видения концепций жизненного цикла в области программного обеспечения.

Стандарт описывает 17 процессов жизненного цикла, распределенных по трем категориям (основные, вспомогательные, организационные) процессов.

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

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

1)Процесс документирования. Определяет работы по описанию информации, выдаваемой в процессе жизненного цикла.

2)Процесс управления конфигурацией. Определяет работы по управлению

конфигурацией.

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

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

5)Процесс аттестации. Определяет работы (заказчика, поставщика или независимой стороны) по аттестации программных продуктов программного проекта.

6)Процесс совместного анализа. Определяет работы по оценке состояния и результатов какой-либо работы. Данный процесс может использоваться двумя любыми сторонами, когда

одна из сторон (проверяющая) проверяет другую сторону (проверяемую) на совместном совещании.

7) Процесс аудита. Определяет работы по определению соответствия требованиям, планам и договору. Данный процесс может использоваться двумя сторонами, когда одна из сторон (проверяющая) контролирует программные продукты или работы другой стороны (проверяемой).

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

Ответственность за работы и задачи вспомогательного процесса несет организация, выполняющая данный процесс. Данная организация гарантирует реальность существования и функциональные особенности конкретного процесса. Данная организация организует и выполняет управление вспомогательным процессом на проектном уровне в соответствии с процессом управления; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры; адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации и управляет вспомогательным процессом на организационном уровне в соответствии с процессами усовершенствования и обучения. В качестве методов обеспечения качества могут быть использованы: совместные анализы, аудиторские проверки, верификация и аттестация.

3. Стандарт 12207. Организационные процессы. Место процессов в ЖЦ ИС.

ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД). В последние годы, акцент делается на стандарты ГОСТ, соответствующие международным стандартам. В то же время, 34-я серия является важным дополнительным источником информации для разработки и стандартизации внутрикорпоративных документов и формирования целостного понимания и видения концепций жизненного цикла в области программного обеспечения.

Стандарт описывает 17 процессов жизненного цикла, распределенных по трем категориям (основные, вспомогательные, организационные) процессов.

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

1)Процесс управления. Определяет основные работы по управлению, включая управление проектом, при реализации процессов жизненного цикла.

2)Процесс создания инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.

3)Процесс усовершенствования. Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или

администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.

4) Процесс обучения. Определяет работы по соответствующему обучению персонала.

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

4. Стандарт 34-601.90.

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

Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединённых в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям.

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

Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания

АС.

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

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

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

4.Эскизный проект. частям.

4.2.Разработка документации на АС и её части.

8. Сопровождение АС 8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание.

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

Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

5. Понятие открытой системы.

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

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

Существует достаточное число определений, даваемых различными организациями по стандартизации и отдельными фирмами. Например, Ассоциация французских пользователей UNIX и открытых систем (AFUU) дает следующее определение: «Открытая система — это система, состоящая из элементов, которые взаимодействуют друг с другом через стандартные интерфейсы».

Производитель средств вычислительной техники — компания Hewlett Packard: «Открытая система — это совокупность разнородных компьютеров, объединенных сетью, которые могут работать как единое интегрированное целое независимо от того, как в них представлена информация, где они расположены, кем они изготовлены, под управлением какой операционной системы они работают».

Определение Национального института стандартов и технологий США (NIST): «Открытая система — это система, которая способна взаимодействовать с другой системой посредством реализации международных стандартных протоколов. Открытыми системами являются как конечные, так и промежуточные системы. Однако открытая система не обязательно может быть доступна другим открытым системам. Эта изоляция может быть обеспечена или путем физического отделения, или путем использования технических возможностей, основанных на защите информации в компьютерах и средствах коммуникаций».

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

Это определение, сформулированное специалистами Комитета IEEE POSIX 1003.0 Института инженеров по электротехнике и электронике (IEEE), унифицирует содержание среды, которую предоставляет открытая система для широкого использования. Базовым в этом определении является термин «открытая спецификация», имеющий следующее.толкование: «это общедоступная спецификация, которая поддерживается открытым, гласным, согласительным процессом, направленным на постоянную адаптацию новой технологии, и которая соответствует стандартам». Таким образом, под открытыми системами следует понимать системы, обладающие стандартизованными интерфейсами. Решение проблемы открытости систем основывается на стандартизации интерфейсов систем и протоколов взаимодействия между их компонентами.

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

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

стандартом.

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

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

Для реальных систем полная открытость является недостижимым идеалом. Как правило, даже в системах, называемых открытыми, этому определению соответствуют лишь некоторые части, поддерживающие внешние интерфейсы. Например, открытость семейства операционных систем Unix заключается, кроме всего прочего, в наличии стандартизованного программного интерфейса между ядром и приложениями, что позволяет легко переносить приложения из среды одной версии Unix в среду другой версии. Еще одним примером частичной открытости является применение в достаточно закрытой операционной системе Novell NetWare открытого интерфейса Open Driver Interface (ODI) для включения в систему драйверов сетевых адаптеров производства независимых компаний. Чем больше открытых спецификаций использовано при разработке системы, тем более открытой она является.

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

Если две сети построены с соблюдением принципов открытости, то это дает следующие преимущества:

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

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

возможность легкого сопряжения одной сети с другой;

простота освоения и обслуживания сети.

Ярким примером открытой системы является сеть Internet. Эта сеть развивалась в полном соответствии с требованиями, предъявляемыми к открытым системам. В разработке ее стандартов принимали участие тысячи специалистов-пользователей из различных университетов, научных организаций и фирм-производителей вычислительной аппаратуры и программного обеспечения, работающих в разных странах. Само название стандартов, определяющих работу Internet — Request For Comments (RFC, что можно перевести как "запрос на комментарии",) — говорит об открытом характере принимаемых стандартов. В результате сеть Internet объединила в себе разнообразное оборудование и программное обеспечение огромного количества сетей, разбросанных по всему миру.

6. Модель OSI.

Модель OSI, как следует из ее названия (Open System Interconnection), описывает взаимосвязи открытых систем.

Эталонная модель OSI, иногда называемая стеком OSI представляет собой 7-уровневую сетевую иерархию разработанную Международной организацией по стандартам (International Standardization Organization - ISO). Эта модель содержит в себе по сути 2 различных модели:

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

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

В горизонтальной модели двум программам требуется общий протокол для обмена данными. В вертикальной - соседние уровни обмениваются данными с использованием интерфейсов API.

Рисунок 1 Модель OSI

Уровень 1, физический

Физический уровень получает пакеты данных от вышележащего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включаются тип кабелей и разъемов, разводка контактов в разъемах.

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

EIA-RS-232-C, CCITT V.24/V.28 - механические/электрические характеристики несбалансированного последовательного интерфейса.

EIA-RS-422/449, CCITT V.10 - механические, электрические и оптические характеристики сбалансированного последовательного интерфейса.

IEEE 802.3 -- Ethernet

IEEE 802.5 -- Token ring

Уровень 2, канальный

Канальный уровень обеспечивает создание, передачу и прием кадров данных. Этот уровень обслуживает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов. Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC). LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде.

Наиболее часто используемые на уровне 2 протоколы включают:

HDLC для последовательных соединений

IEEE 802.2 LLC (тип I и тип II) обеспечивают MAC для сред 802.x

Ethernet

Token ring

FDDI

X.25

Frame relay

Уровень 3, сетевой

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

Наиболее часто на сетевом уровне используются протоколы:

IP - протокол Internet

IPX - протокол межсетевого обмена

X.25 (частично этот протокол реализован на уровне 2)

CLNP - сетевой протокол без организации соединений

Уровень 4, транспортный

Транспортный уровень делит потоки информации на достаточно малые фрагменты (пакеты) для передачи их на сетевой уровень.

Наиболее распространенные протоколы транспортного уровня включают:

TCP - протокол управления передачей

NCP - Netware Core Protocol

SPX - упорядоченный обмен пакетами

TP4 - протокол передачи класса 4

Уровень 5, сеансовый

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

Уровень 6, уровень представления

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

Уровень 7, прикладной

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

К числу наиболее распространенных протоколов верхних уровней относятся:

FTP - протокол переноса файлов

TFTP - упрощенный протокол переноса файлов

X.400 - электронная почта

Telnet

SMTP - простой протокол почтового обмена

CMIP - общий протокол управления информацией

SNMP - простой протокол управления сетью

NFS - сетевая файловая система

FTAM - метод доступа для переноса файлов