Характеристика стандартов разработки программных и информационных систем
Международный стандарт ISO/OSI разработан международной организацией по стандартизации (ISO), предназначен для использования в области сетевого информационного обмена, представляет эталонную семиуровневую модель, известную как модель OSI. Первоначально усилия были направлены на разработку структуры (модели) протоколов связи цифровых устройств. Основная идея была связана с разбиением функций протокола на семь различных категорий (уровней), каждый из которых связан с одним более высоким и с одним более низким уровнем (за исключением самого верхнего и самого нижнего). Идея семиуровневого открытого соединения состоит не в попытке создания универсального множества протоколов связи, а в реализации «модели», в рамках которой могут быть использованы уже имеющиеся различные протоколы. В последнее время достигнут значительный прогресс в реализации различных типов протоколов, о чем говорит успешное функционирование многих сетей передачи данных, например, Интернета.
Международный стандарт ISO/IEC 12207:2008 «Информационные технологии. Процессы жизненного цикла программного обеспечения» – базовый стандарт процессов жизненного цикла программного обеспечения, ориентированный на различные его виды, а также типы информационных систем, куда программное обеспечение входит как составная часть. Разработан объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения». Включает описание основных, вспомогательных и организационных процессов.
Основные процессы жизненного цикла программного обеспечения:
• процесс приобретения, определяющий действия покупателя, приобретающего программный продукт или его сервис;
• процесс поставки, регламентирующий действия поставщика, снабжающего указанными выше компонентами;
• процесс разработки, определяющий действия разработчика по построению программного изделия;
• процесс функционирования, определяющий действия оператора, обслуживающего программную систему в интересах пользователей и включающий помимо требований инструкции по эксплуатации консультирование пользователей и организацию обратной связи с ними;
• процесс сопровождения, регламентирующий действия персонала по модификации программного продукта, поддержке его текущего состояния и функциональной работоспособности.
Вспомогательные процессы жизненного цикла программного обеспечения регламентируют документирование, управление конфигурацией, обеспечение качества, верификацию, аттестацию, совместную оценку, аудит.
Стандарт содержит мало описаний, направленных на проектирование баз данных, что объясняется наличием отдельных стандартов по данной тематике.
ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» в качестве объекта стандартизации рассматривает автоматизированные системы различных видов и все виды их компонентов, в том числе программное обеспечение и базы данных. Стандарт в основном рассматривает проектные документы, что отличает его от стандарта ISO/IEC 12207. В структуре стандарта выделяют стадии и этапы разработки автоматизированных систем (АС):
1) формирование требований к АС:
• обследование объекта автоматизации и обоснование необходимости создания АС;
• формирование требований пользователя к АС;
• оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания);
2) разработка концепции АС:
• изучение объекта;
• проведение необходимых научно-исследовательских работ;
• разработка вариантов концепции АС, удовлетворяющей требованиям пользователя;
• оформление отчета о выполненной работе;
3) техническое задание на создание АС:
• разработка и утверждение технического задания на создание АС;
4) эскизный проект:
• разработка предварительных проектных решений по системе и ее частям;
• разработка документации на АС и ее части;
5) технический проект:
• разработка проектных решений по системе и ее частям;
• разработка документации на АС и ее части;
• разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку;
• разработка заданий на проектирование в смежных частях проекта объекта автоматизации;
6) рабочая документация:
• разработка рабочей документации на систему и ее части;
• разработка или адаптация программ;
7) ввод в действие:
• подготовка объекта автоматизации к вводу АС в действие;
• подготовка персонала;
• комплектация АС поставляемыми изделиями (программными, техническими и информационными средствами);
• строительно-монтажные работы;
• пуско-наладочные работы;
• предварительные испытания;
• опытная эксплуатация;
• приемочные испытания;
8) сопровождение АС:
• выполнение работ в соответствии с гарантийными обязательствами;
• послегарантийное обслуживание.
ГОСТ 34.601 содержит обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов. В настоящее время обязательность выполнения ГОСТа 34.601 отсутствует, поэтому его используют в качестве методической поддержки.
Методика Oracle COM (Custom Development Method) является развитием ранее разработанной версии Oracle CASE-Method. Она ориентирована на разработку прикладных информационных систем. Структурно построена как иерархическая совокупность этапов, процессов и последовательностей задач.
Этапы:
• стратегия (определение требований);
• анализ (формирование детальных требований);
• проектирование (преобразование требований в спецификации);
• реализация (разработка и тестирование приложений);
• внедрение (установка, отладка и ввод в эксплуатацию);
• эксплуатация (поддержка, сопровождение, расширение).
Процессы:
• RD – определение производственных требований;
• ES – исследование и анализ существующих систем;
• ТА – определение технической архитектуры;
• DB – проектирование и реализация базы данных;
• MD – проектирование и реализация программных модулей;
• CV – конвертирование данных;
• DO – документирование;
• ТЕ – тестирование;
• TR – обучение;
• TS – переход к новой системе;
• PS – поддержка и сопровождение.
Процессы состоят из последовательностей задач, причем задачи разных процессов взаимосвязаны ссылками.
Методика не предусматривает включение новых задач, удаление старых, изменение последовательности выполнения задач.
В связи с широким использованием в настоящее время объектной технологии большой интерес представляет CORBA (Common Object Request Broker Architecture) – стандарт в виде набора спецификаций для промежуточного программного обеспечения (middleware) объектного типа. Его автором является международный консорциум OMG (Object Management Group), объединяющий более 800 компаний (IBM, Siemens, Microsoft, Sun, Oracle и др.). OMG разработал семантический стандарт, включающий 4 основных типа:
• объекты, моделирующие мир (студент, преподаватель, экзамен);
• операции, относящиеся к объекту и характеризующие его свойства (дата рождения студента, пол и др.);
• типы, описывающие конкретные значения операций;
• подтипы, уточняющие типы.
На основе этих понятий OMG определил объектную модель, спецификацию для развития стандарта CORBA, постоянно развиваемую. В настоящее время CORBA состоит из 4 основных частей:
• Object Request Broker (посредник объектных запросов);
• Object Services (объектные сервисы);
• Common Facilities (общие средства);
• Application and Domain Interfaces (прикладные и отраслевые интерфейсы).
Параллельно с CORBA корпорацией Microsoft был разработан стандарт COM/DCOMB (Component Object Model / Distributed СОМ), предназначенный для объединения небольших офисных программ. Основным недостатком данного стандарта была ориентация на Windows и Microsoft. Корпорация Microsoft долгое время не присоединялась к OMG и развивала собственный стандарт. OMG взаимодействует с другими центрами стандартизации: ISO, Open Group, WWW консорциум, IEEE и многими другими. CORBA стал неотъемлемой частью распределенных объектных компьютерных систем.
Приведенные примеры стандартов дают представление о подходах к решению проблем стандартизации. Естественно затраты на стандартизацию могут сделать проектные работы по внедрению информационных технологий более дорогостоящими, однако эти затраты окупаются в процессе эксплуатации и развития системы, например при замене оборудования или программной среды.