Обозначение
|
Наименование
|
Характеристика
|
PS
|
Presentation Services
(средства представления)
|
Обеспечиваются
устройствами, принимающими ввод от пользователя и отображающими то, что
сообщает ему компонент логики представления PL, с использованием
соответствующей программной поддержки
|
PL
|
Presentation Logic (логика
представления)
|
Управляет взаимодействием
между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе
команды в меню, нажатии кнопки или выборе элемента из списка
|
BL
|
Business or
Application Logic (прикладная логика)
|
Набор правил для принятия
решений, вычислений и операций, которые должно выполнить приложение
|
DL
|
Data Logic (логика
управления данными)
|
Операции с базой данных
(SQL-операторы), которые нужно выполнить для реализации прикладной логики
управления данными
|
DS
|
Data Services (операции с
БД)
|
Действия СУБД, вызываемые
для выполнения логики управления данными, такие как манипулирование данными,
определения данных, фиксация или откат транзакций и т. п. СУБД обычно
компилирует SQL-предложения
|
FS
|
File Services (файловые
перации)
|
Дисковые операции чтения и
записи данных для СУБД и других компонентов. Обычно являются функциями
операционной системы (ОС)
|
Архитектура файл-сервер не имеет сетевого разделения компонентов диалога
PS и PL и использует компьютер для функций отображения, что облегчает
построение графического интерфейса. Файл-сервер только извлекает данные из
файлов, так что дополнительные пользователи и приложения добавляют лишь
незначительную нагрузку на центральный процессор. Каждый новый клиент добавляет
вычислительную мощность к сети.
Объектами разработки в файл-серверном приложении являются компоненты
приложения, определяющие логику диалога PL, а также логику обработки BL и
управления данными DL. Разработанное приложение реализуется либо в виде
законченного загрузочного модуля, либо в виде специального кода для
интерпретации.
Однако такая архитектура имеет существенный недостаток: при выполнении
некоторых запросов к базе данных клиенту могут передаваться большие объемы
данных, загружая сеть и приводя к непредсказуемости времени реакции.
Значительный сетевой трафик особенно сильно сказывается при организации
удаленного доступа к базам данных на файл-сервере через низкоскоростные каналы
связи. Одним из вариантов устранения данного недостатка является удаленное
управление файл-серверным приложением в сети. При этом в локальной сети
размещается сервер приложений, совмещенный с телекоммуникационным сервером
(обычно называемым сервером доступа), в среде которого выполняются обычные
файл-серверные приложения. Особенность состоит в том, что диалоговый ввод-вывод
поступает от удаленных клиентов через телекоммуникации. Приложения не должны
быть слишком сложными, иначе велика вероятность перегрузки сервера, или же
нужна очень мощная платформа для сервера приложений.
Одним из традиционных средств, на основе которых создаются файл-серверные
системы, являются локальные СУБД. Однако такие системы, как правило, не
отвечают требованиям обеспечения целостности данных (в частности, они не
поддерживают транзакции). Поэтому при их использовании задача обеспечения
целостности данных возлагается на программы клиентов, что приводит к усложнению
клиентских приложений. Однако эти инструменты привлекают своей простотой,
удобством использования и доступностью. Поэтому файл-серверные информационные
системы до сих пор представляют интерес для малых рабочих групп и, более того,
нередко используются в качестве информационных систем масштаба предприятия.
Архитектура клиент-сервер предназначена для разрешения проблем
файл-серверных приложений путем разделения компонентов приложения и размещения
их там, где они будут функционировать наиболее эффективно. Особенностью
архитектуры клиент-сервер является использование выделенных серверов баз
данных, понимающих запросы на языке структурированных запросов SQL (Structured
Query Language) и выполняющих поиск, сортировку и агрегирование информации.
Отличительная черта серверов БД - наличие справочника данных, в котором
записана структура БД, ограничения целостности данных, форматы и даже серверные
процедуры обработки данных по вызову или по событиям в программе. Объектами
разработки в таких приложениях помимо диалога и логики обработки являются,
прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов
для типовых запросов к базе данных.
Большинство конфигураций клиент-сервер использует двухуровневую модель, в
которой клиент обращается к услугам сервера. Предполагается, что диалоговые
компоненты PS и PL размешаются на клиенте, что позволяет обеспечить графический
интерфейс. Компоненты управления данными DS и FS размешаются на сервере, а
диалог (PS, PL), логика BL и DL - на клиенте. Двухуровневое определение
архитектуры клиент-сервер использует именно этот вариант: приложение работает у
клиента. СУБД - на сервере (рис. 1.4.).
Рис. 1.4. Классический вариант клиент-серверной информационной системы
Поскольку эта схема предъявляет наименьшие требования к серверу, она
обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие
большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть.
Результаты SQL-запроса должны вернуться клиенту для обработки, потому, что там
находится логика принятия решения. Такая схема приводит к дополнительному
усложнению администрирования приложений, разбросанных по раз личным клиентским
узлам.
Для сокращения нагрузки на сеть и упрощения администрирования приложений
компонент BL можно разместить на сервере. При этом вся логика принятия решении
оформляется в виде хранимых процедур и выполняется на сервере БД. Хранимая
процедура - процедура с операторами SQL для доступа к БД, вызываемая по имени с
передачей требуемых параметров и выполняемая на сервере БД, Хранимые процедуры
могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку
на сервер.
Хранимые процедуры улучшают целостность приложений и БД, гарантируют
актуальность коллективно используемых операций и вычислений. Улучшается
сопровождение таких процедур, а также безопасность (нет прямого доступа к
данным).
Следует помнить, что перегрузка хранимых процедур прикладной логикой
может перегрузить сервер, что приведет к потере производительности. Эта
проблема особенно актуальна при разработке крупных информационных систем, в
которых к серверу может одновременно обращаться большое количество клиентов.
Поэтому в большинстве случаев следует принимать компромиссные решения: часть
логики приложения размещать на стороне сервера, часть - на стороне клиента.
Такие клиент-серверные системы называются системами с разделенной логикой.
Данная схема при удачном разделении логики позволяет получить более
сбалансированную загрузку клиентов и сервера, но при этом затрудняется
сопровождение приложений.
Создание архитектуры клиент-сервер возможно и на основе многотерминальной
системы. В этом случае в многозадачной среде сервера приложений выполняются
программы пользователей, а клиентские узлы вырождены и представлены
терминалами. Подобная схема информационной системы характерна для UNIX. В
настоящее время архитектура клиент-сервер получила признание и широкое
.распространение как способ организации приложений для рабочих групп и
информационных систем корпоративного уровня. Подобная организация работы
повышает эффективность выполнения приложений за счет использования возможностей
сервера БД, разгрузки сети и обеспечения контроля целостности данных.
Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым
проблемам в сложных информационных приложениях с множеством пользователей и
запутанной логикой. Решением этих проблем может стать использование
многоуровневой архитектуры.
Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в
своей классической форме состоит из трех уровней:
· нижний уровень представляет собой приложения клиентов,
выделенные для выполнения функций и логики представлений PS и PL и имеющие
программный интерфейс для вызова приложения на среднем уровне;
· средний уровень представляет собой сервер приложений, на
котором выполняется прикладная логика BL и с которого логика обработки данных
DL вызывает операции с базой данных DS;
· верхний уровень представляет собой удаленный
специализированный сервер базы данных, выделенный для услуг обработки данных DS
и файловых операций FS (без риска использования хранимых процедур).
Подобную концепцию обработки данных пропагандируют, в частности фирмы Oracle. Sun, Borland
и др.
Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на
разные узлы и сеть, а также способствует специализации инструментов для
разработки приложений и устраняет недостатки двухуровневой модели
клиент-сервер.
Централизация логики приложения упрощает администрирование и
сопровождение. Четко разделяются платформы и инструменты для реализации
интерфейса и прикладной логики, что позволяет с наибольшей отдачей
реализовывать их специалистам узкого профиля. Наконец, изменения прикладной
логики не затрагивают интерфейса, и наоборот. Но поскольку границы между
компонентами PL, BL и DL размыты, прикладная логика может появиться на всех
трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает
интерфейс с клиентами и другими серверами, может управлять транзакциями и
гарантировать целостность распределенной базы данных. Средства удаленного
вызова процедур наиболее соответствуют идее распределенных вычислений: они
обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на
другом узле, передачу параметров, удаленную обработку и возврат результатов.
С ростом систем клиент-сервер необходимость трех уровней становится все
более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы
транзакций, являются относительно новыми. Эти инструменты в основном
ориентирован!.: на среду UNIX, однако прикладные серверы можно cтроить на базе
Qicrosoft\Windows NT с использованием вызова удалённых процедур для организации
связи клиентов с сервером. На практике в локальной сети могут использоваться
смешанные архитектуры (двухуровневые и трёхуровневые) с одним и тем же сервером
БД. С учетом глобальных связей архитектура может иметь больше трех звеньев. В
настоящее время появились новые инструментальные средства для гибкой
сегментации приложений клиент-сервер по различным узлам сети.
Таким образом, многоуровневая архитектура распределенных приложений
позволяет повысить эффективность работы корпоративной информационной системы и
оптимизировать распределение ее программно-аппаратных ресурсов. Но пока на
российском рынке по-прежнему доминирует архитектура клиент-сервер,
Интернет/интранет-технологии
В развитии технологии Интернет/интранет основной акцент пока что делается
на разработке инструментальных программных средств. В то же время наблюдается
отсутствие развитых средств разработки приложений, работающих с базами данных.
Компромиссным решением для создания удобных и простых в использовании и
сопровождении информационных систем, эффективно работающих с базами данных,
стало объединение Интернет/интранет-технологии с многоуровневой архитектурой.
При этом структура информационного приложения приобретает следующий вид:
браузер - сервер приложений - сервер баз данных - сервер динамических страниц -
web-сервер
Благодаря интеграции Интернет/интранет технологий и архитектуры
клиент-сервер процесс внедрения и сопровождения корпоративной информационной
системы существенно упрощается при сохранении достаточно высокой эффективности
и простоты совместного использования информации.
Лекция 7. Общие сведения об управлении проектами. Понятие проекта.
Классификация проектов
Общие сведения об управлении проектами
Информационная система предприятия разрабатывается как некоторый проект.
Многие особенности управления проектами и фазы разработки проекта (фазы
жизненного цикла) являются общими, не зависящими не только от предметной
области, но и от характера проекта (неважно, инженерный это или экономический).
Понятие проекта
Проект - это ограниченное по времени целенаправленное изменение отдельной
системы с изначально четко определенным и целями, достижение которых определяет
завершение проекта, а также с установленными требованиями к срокам,
результатам, риску, рамкам расходования средств и ресурсов и к организационной
структуре.
Обычно для сложного понятия {каким, в частности, является понятие
проекта) трудно дать однозначную формулировку, которая полностью охватывает все
признаки вводимого понятия. Поэтому приведенное определение не претендует на
единственность и полноту.
Можно выделить следующие основные отличительные признаки проекта как
объекта управления:
1) изменчивость - целенаправленный перевод системы из существующего
в некоторое желаемое состояние, описываемое в терминах целей проекта;
2) ограниченность конечной цели;
) ограниченность продолжительности;
) ограниченность бюджета;
) ограниченность требуемых ресурсов;
) новизна для предприятия, для которого реализуется проект;
) комплексность - наличие большого числа факторов, прямо пли
косвенно влияющих на прогресс и результаты проекта;
) правовое и организационное обеспечение - создание специфической
организационной структуры па время реализации проекта.
Рассматривая планирование проектов и управление ими, необходимо четко
осознавать, что речь идет об управлении неким динамическим объектом. Поэтому
система управления проектом должна быть достаточно гибкой, чтобы допускать
возможность модификации без глобальных изменений в рабочей программе. В
системном плане проект может быть представлен «черным ящиком», входом которого
являются технические требования и условия финансирования, а итогом работы -
достижение требуемого результата (рис. 2.1).
Рис. 2.1. Представление проекта в виде «черного ящика»
Выполнение работ обеспечивается наличием необходимых ресурсов:
· материалов;
· оборудования;
· человеческих ресурсов.
Эффективность работ достигается за счет управления процессом реализации
проекта, которое обеспечивает распределение ресурсов, координацию выполняемой
последовательности работ и компенсацию внутренних и внешних возмущающих
воздействий.
С точки зрения теории систем управления проект как объект управления
должен быть наблюдаемым и управляемым, то есть выделяются некоторые
характеристики, по которым можно постоянно контролировать ход выполнения
проекта (свойство наблюдаемости). Кроме того, необходимы механизмы
своевременного воздействия на ход реализации проекта (свойство управляемости).
Свойство управляемости особенно актуально в условиях неопределенности и изменчивости
предметной области, которые нередко сопутствуют проектам по разработке
информационных систем. Для обоснования целесообразности и осуществимости
проекта, анализа хода его реализации, а также для заключительной оценки степени
достижения поставленных целей проектa и сравнения фактических результатов с
запланированными существует ряд характеристик проекта. К важнейшим из них
относятся технико-экономические показатели:
1) объем работ;
2) сроки выполнения;
) себестоимость;
) экономическая эффективность, обеспечиваемая реализацией проекта;
) социальная и общественная значимость проекта.
Классификация проектов
Проекты могут сильно отличаться по сфере приложения, составу, предметной
области, масштабам, длительности, составу участников, степени сложности, значимости
результатов и т. п. Проекты могут быть классифицированы по самым различным
признакам. Отметим основные из них.
Класс проекта определяется по составу и структуре проекта. Обычно
различают:
· монопроект (отдельный проект, который может быть любого типа, вида и
масштаба);
· мультипроект (комплексный проект, состоящий из ряда
монопроектов и требующий применения многопроектного управления),
Тип проекта определяется по основным сферам деятельности, в которых
осуществляется проект. Можно выделить пять основных типов проекта:
1) технический;
2) организационный;
) экономический;
) социальный;
) смешанный.
Разработка информационных систем относится, скорее всего, к техническим
проектам, которые имеют следующие особенности:
· главная цель проекта четко определена, но отдельные цели должны
уточняться по мере достижения частных результатов;
· срок завершения и продолжительность проекта определены
заранее, желательно их точное соблюдение, однако они также могут
корректироваться в зависимости от полученных промежуточных результатов и общего
прогресса проекта.
Масштаб проекта определяется по размерам бюджета и количеству участников:
· мелкие проекты;
· малые проекты;
· средние проекты;
· крупные проекты.
Можно также рассматривать, масштабы проектов в более конкретной форме -
отраслевые, корпоративные, ведомственные проекты, проекты одного предприятия.
Лекция 8. Основные фазы проектирования информационной системы
Каждый проект, независимо от сложности и объема работ, необходимых для
его выполнения, проходит в своем развитии определенные состояния: от состояния,
когда «проекта еще нет», до состояния, когда "проекта уже нет".
Совокупность ступеней развития от возникновения идеи до полного завершения
проекта принято разделять на фазы (стадии, этапы).
В определении количества фаз и их содержания имеются некоторые отличия,
поскольку эти характеристики во многом зависят от условий осуществления
конкретного проекта и опыта основных участников. Тем не менее логика и основное
содержание процесса разработки информационной системы почти во всех случаях
являются общими.
Можно выделить следующие фазы развития информационной системы:
1. формирование концепции;
2. разработка технического задания;
. проектирование;
. изготовление;
. ввод системы в эксплуатацию.
Вторую и частично третью фазы принято называть фазами системного
проектирования, а последние две (иногда сюда включают и фазу проектирования) -
фазами реализации.
Рассмотрим каждую из фаз более подробно.
1. Концептуальная фаза
Главным содержанием работ на этой фазе является определение проекта,
разработка его концепции, включающая:
· формирование идеи, постановку целей;
· формирование ключевой команды проекта;
· изучение мотивации и требований заказчика и других
участников;
· сбор исходных данных и анализ существующего состояния;
· определение основных требовании и ограничений, требуемых
материальных, финансовых и трудовых ресурсов;
· сравнительную оценку альтернатив;
· представление предложении, их экспертизу и утверждение,
2. Разработка технического предложения
Главным содержанием этой фалы является разработка технического
предложения и переговоры с заказчиком о заключении контракта. Общее содержание
работ этой фазы:
· разработка и утверждение технического задания;
· планирование, декомпозиция базовой структурной модели
проекта;
· составление сметы и бюджета проекта, определение потребности
в ресурсах;
· разработка календарных планов и укрупненных графиков работ;
· подписание контракта с заказчиком;
· ввод в действие средств коммуникации участников проекта и
контроля за ходом работ.
3. Проектирование
На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее
эффективные способы выполнения проекта и использования ресурсов. Характерные
работы этой фазы:
· выполнение базовых проектных работ;
· разработка частных технических заданий;
· выполнение концептуального проектирования;
· составление технических спецификаций и инструкций;
· представление проектной разработки, экспертиза и утверждение.
4. Разработка
На этой фазе производятся координация и оперативный контроль работ по
проекту, осуществляется изготовление подсистем, их объединение и тестирование.
Основное содержание;
· выполнение работ по разработке программного обеспечения;
· выполнение подготовки к внедрению системы;
· контроль и регулирование основных показателей проекта.
5. Ввод системы в эксплуатацию
На этой фазе проводятся испытания, опытная эксплуатация системы в
реальных условиях, ведутся переговоры о результатах выполнения проекта и о
возможных новых контрактах. Основные виды работ:
· комплексные испытания;
· подготовка кадров для эксплуатации создаваемой системы;
· подготовка рабочей документации, сдача системы заказчику и
ввод её в эксплуатацию;
· сопровождение, поддержка, сервисное обслуживание;
· оценка результатов проекта и подготовка итоговых документов;
· разрешение конфликтных ситуаций и закрытие работ по проекту;
· накопление опытных данных последующих проектов, анализ опыта,
состояния, определение направлений развития.
Начальные фазы проекта имеют решающее влияние на достигаемый результат,
так как в них принимаются основные решения, определяющие качество
информационной системы. При этом обычно 30% вклада в конечный результат проекта
вносят фазы концепции и предложения, 20 % - фаза проектирования, 20 % - фаза
изготовлений, 30 % - фаза сдачи объекта и завершения проекта.
Кроме того, на обнаружение ошибок, допущенных на стадии системного
проектирования, расходуется примерно в два раза больше времени, чем на
последующих фазах, а их исправление обходится в пять раз дороже. Поэтому па
начальных стадиях проекта разработку следует выполнять особенно тщательно.
Наиболее часто на начальных фазах допускаются следующие ошибки:
· ошибки в определении интересов заказчика;
· концентрация на маловажных, сторонних интересах;
· неправильная интерпретация исходной постановки задачи;
· неправильное или недостаточное понимание деталей;
· неполнота функциональных спецификаций (системных требований);
· ошибки в определении требуемых ресурсов и сроков;
· редкая проверка на согласованность этапов и отсутствие
контроля со стороны заказчика (нет привлечения заказчика).
Процессы, протекающие на протяжении жизненного цикла информационной
системы
Понятие жизненного цикла является одним из базовых понятий методологии
проектирования информационных систем. Жизненный цикл информационной системы
представляет собой непрерывный процесс, начинающийся с момента принятия решения
о создании информационной системы и заканчивается в момент полного изъятия ее
из эксплуатации.
Существует международный стандарт, регламентирующий жизненный цикл
информационных систем - ISO/IEC 12207.
ISO - International Organization of Standardization (международная организация по стандартизации).
IEC - International Bectrotechnical Commission (международная комиссия по
электротехнике).
Стандарт ISO, IEC 12207 определяет структуру жизненного цикла, содержащую
процессы, действия и задачи, которые должны быть выполнены во время создания
информационной системы. Согласно данному стандарту структура жизненного цикла
основывается на трех группах процессов:
· основные процессы жизненного цикла (приобретение, поставка, разработка,
эксплуатация, сопровождение);
· вспомогательные процессы, обеспечивающие выполнение основных процессов
(документирование, управление конфигурацией, обеспечение качества, верификация,
аттестация, оценка, аудит, разрешение проблем);
· организационные процессы (управление проектами, создание
инфраструктуры проекта, определение, оценка и улучшение самого жизненного
цикла, обучение).
Рассмотрим каждую из указанных групп более подробно.
Основные процессы жизненного цикла
Среди основных процессов жизненного цикла наибольшую важность имеют три
разработка, эксплуатация и сопровождение. Каждый процесс характеризуется
определёнными задачами и методами их решения, исходными данными, полученными на
предыдущем этапе, и результатами.
Разработка информационной системы включает в себя все работы по созданию
информационного программного обеспечения и его компонентов в соответствие с
заданными требованиями. Разработка информационного программного обеспечения
также включает:
· оформление проектной и эксплуатационной документации;
· подготовку материалов, необходимых для проведения
тестирования разработанных программных продуктов;
· разработку материалов, необходимых для организации обучения
персонала.
Разработка является одним из важнейших процессов жизненного цикла
информационной системы и, как правило, включает в себя стратегическое
планирование, анализ, проектирование и реализацию (программирование).
Эксплуатационные работы можно подразделить на подготовительные и
основные.
К подготовительным относятся:
· конфигурирование базы данных и рабочих мест пользователей;
· обеспечение пользователей эксплуатационной документацией;
· обучение персонала.
Основные эксплуатационные работы включают:
· непосредственно эксплуатацию;
· локализацию проблем и устранение причин их возникновения;
· модификацию программного обеспечения;
· подготовку предложений по совершенствованию системы;
· развитие и модернизацию системы.
Сопровождение
Службы технической поддержки играют весьма заметную роль в жизни любой
корпоративной информационной системы. Наличие квалифицированного технического
обслуживания на этапе эксплуатации информационной системы является необходимым
условием для решения поставленных перед ней задач, причем ошибки обслуживающего
персонала могут приводить к явным или скрытым финансовым потерям, сопоставимым
со стоимостью самой информационной системы.
Основными предварительными действиями при подготовке к организации
технического обслуживания информационной системы являются следующие:
· выделение наиболее ответственных узлов системы и определение
для них критичности простоя. Это позволит выделить наиболее критичные
составляющие информационной системы и оптимизировать распределение ресурсов для
технического обслуживания;
· определение задач технического обслуживания и их разделение
на внутренние (решаемые силами обслуживающего подразделения) и внешние
(решаемые специализированными сервисными организациями). Таким образом производится
четкое определение круга исполняемых функции и разделение ответственности;
· проведение анализа имеющихся внутренних и внешних ресурсов,
необходимых для организации технического обслуживания в рамках описанных задач
и разделения компетенции. Основные критерии для анализа: наличие гарантии на
оборудование, состояние ремонтного фонда, квалификация персонала;
· подготовка плана организации технического обслуживания, в
котором необходимо определить этапы исполняемых действий, сроки их исполнения,
затраты на этапах, ответственность исполнителей.
Обеспечение качественного технического обслуживания информационной
системы требует привлечения специалистов высокой квалификации, которые в
состоянии решать не только каждодневные задачи администрирования, но и быстро
восстанавливать работоспособность системы при сбоях.
Вспомогательные процессы
Среди вспомогательных процессов одно из главных мест занимает управление
конфигурацией. Это один из вспомогательных процессов, поддерживающих основные
процессы жизненного цикла информационной системы, прежде всего процессы
разработки и сопровождения. При разработке проектов сложных информационных
систем, состоящих из многих компонентов каждым из которых может разрабатываться
независимо п. следовательно, иметь несколько вариантов реализации и/или
несколько версий одной реализации, возникает проблема учета их связей и
функции, создания единой структуры и обеспечения развития всей системы.
Управление конфигурацией позволяет организовывать, систематически учитывать и
контролировать внесение изменений в различные компоненты информационном системы
на всех стадиях ее жизненного цикла.
Организационные процессы
Управление проектом связано с вопросами планирования и организации работ,
создания коллективов разработчиков и контроля за сроками и качеством
выполняемых работ. Техническое и организационное обеспечение проекта включает:
· выбор методов и инструментальных средств для реализации проекта;
· определение методов описания промежуточных состояний
разработки;
· разработку методов и средств испытаний созданного
программного обеспечения;
· обучение персонала.
Обеспечение качества проекта связано с проблемами верификации, проверки и
тестирования компонентов информационной системы.
Верификация - это процесс определения соответствия текущего состояния
разработки, достигнутого на данном этапе, требованиям этого этапа. Проверка -
это процесс определения соответствия параметров разработки исходным
требованиям. Проверка отчасти совпадает с тестированием, которое проводится для
определения различий между действительными и ожидавшимися результатами и оценки
соответствия характеристик информационной системы исходным требованиям.
Лекция 9. Структура жизненного цикла информационной системы
Полный жизненный цикл информационной системы включает в себя, как
правило, стратегическое планирование, анализ, проектирование, реализацию,
внедрение и эксплуатацию. В общем случае жизненный цикл можно, в свою очередь,
разбить на ряд стадий. В принципе это деление на стадии достаточно произвольно.
Мы рассмотрим один из вариантов такого деления, предлагаемый корпорацией
Rational Software. Это одна из ведущих фирм на рынке программного обеспечения
средств разработки информационных систем (среди которых большой популярностью
заслуженно пользуется универсальное CASE-средство Rational Rose). Согласно
методологии, предлагаемой Rational Software, жизненный цикл информационной
системы подразделяется на четыре стадии:
· начало;
· уточнение;
· конструирование;
· переход (передача в эксплуатацию).
Границы каждой стадии определены некоторыми моментами времени, в которые
необходимо принимать, определенные критические решения и в которые,
следовательно, должны быть достигнуты определенные ключевые цели.
Начальная стадия
На начальной стадии устанавливается область применения системы и определяются
граничные условия. Для этого необходимо идентифицировать все внешние объекты, с
которыми должна взаимодействовать разрабатываемая система, и определить
характер этого взаимодействия на высоком уровне. На начальной стадии
идентифицируются все функциональные возможности системы и производится описание
наиболее существенных из них.
Деловое применение включает:
· критерии успеха разработки;
· оценку риска;
· оценку ресурсов, необходимых для выполнения разработки;
· календарный план с указанием сроков завершения основных
этапов.
Стадия уточнения
На этой стадии проводится анализ прикладной области, разрабатывается
архитектурная основа информационной системы. При принятии любых решений,
касающихся архитектуры системы, необходимо принимать во внимание всю
разрабатываемую систему в целом. Это означает, что необходимо описать
большинство функциональных возможностей системы и учесть взаимосвязи между
отдельными ее составляющими. В конце стадии уточнения проводится анализ
архитектурных решений и способов устранения главных элементов риска,
содержащихся в проекте.
Стадия конструирования
На стадии конструирования разрабатывается законченное изделие, готовое к
передаче пользователю. По окончании этой стадии определяется работоспособность
разработанного программного обеспечения.
Стадия перехода
На стадии перехода производится передача разработанного программного
обеспечения пользователям. При эксплуатации разработанной системы в реальных
условиях часто возникают различного рода проблемы, которые требуют дополнительных
работ по внесению корректив в разработанный продукт, Это, как правило, связано
с обнаружением ошибок и недоработок. В конце стадии перехода необходимо
определить, достигнуты цели разработки или нет.
Моделью жизненного цикла информационной системы будем называть некоторую
структуру, определяющую последовательность осуществления процессов, действий и
задач, выполняемых на протяжении жизненного цикла информационной системы, а
также взаимосвязи между этими процессами, действиями и задачами. В стандарте ISO/TEC
12207 не конкретизируются в деталях методы реализации и выполнения действий и
задач, входящих в процессы жизненного цикла информационной системы, а лишь
описываются структуры этих процессов. Это вполне понятно, так как регламенты
стандарта являются общими для любых моделей жизненного цикла, методологий и
технологий разработки. Модель же жизненного цикла зависит от специфики
информационной системы и условий, в которых она создается и функционирует.
Поэтому не имеет смысл, а предлагать какие-либо конкретные модели жизненного
цикла и методы разработки информационных систем для общего случая, без привязки
к определенной предметной области. К настоящему времени наибольшее
распространение получили следующие две основные модели жизненного цикла:
· каскадная модель, иногда также называемая моделью «водопад» (waterfall);
· спиральная модель.
Каскадная модель демонстрирует классический подход к разработке различных
систем в любых прикладных областях. Для разработки информационных систем данная
модель широко использовалась в 70-х и первой половине 80-х годов. Каскадные
методы проектирования хорошо описаны в зарубежной и отечественной литературе
разных направлений: методических монографиях, стандартах, учебниках.
Организация работ по каскадной схеме официально рекомендовалась и широко
применялась в различных отраслях. Таким образом, наличие не только
теоретических оснований, но и промышленных методик и стандартов, а также
использование этих методов в течение десятилетий позволяет называть каскадные
методы классическими.
Каскадная модель предусматривает последовательную организацию работ. При
этом основной особенностью является, разбиение всей разработки на этапы, причем
переход с одного этапа на следующий происходит только после того, как будут
полностью завершены все работы на предыдущем этапе. Каждый этап завершается
выпуском полного комплекта документации, достаточной для того, чтобы разработка
могла быть продолжена другой командой разработчиков.
Основные этапы разработки по каскадной модели
За десятилетия существования модели «водопад» разбиение работ на стадии и
названия этих стадий менялись. Кроме того, наиболее разумные методики и
стандарты избегали жесткого и однозначного приписывания определенных работ к
конкретным этапам. Тем не менее, вес же можно выделить ряд устойчивых этапов
разработки, практически не зависящих от предметной области:
· анализ требований заказчика;
· проектирование;
· разработка;
· тестирование и опытная эксплуатация;
· сдача готового продукта
На первом этапе проводится исследование проблемы, которая должна быть
решена, четко формулируются все требования заказчика. Результатом, получаемым
на данном этапе, является техническое задание (задание на разработку),
согласованное со всеми заинтересованными сторонами.
На втором этапе разрабатываются проектные решения, удовлетворяющие всем
требованиями, сформулированным в техническом задании. Результатом данного этапа
является комплект проектной документации, содержащей все необходимые данные для
реализации проекта.
Третий этап - реализация проекта. Здесь осуществляется разработка
программного обеспечения (кодирование) в соответствии с проектными решениями,
полученными на предыдущем этапе. Методы, используемые для реализации, не имеют
принципиального значения. Результатом выполнения данного этапа является готовый
программный продукт.
На четвертом этапе проводится проверка полученного программного
обеспечения на предмет соответствия требованиям, заявленным в техническом
задании. Опытная эксплуатация позволяет выявить различного рода скрытые
недостатки, проявляющиеся в реальных условиях работы информационной системы.
Последний этап - сдача го нового проекта. Главная задача этого этапа - убедить
заказчика, что все его требования реализованы в полной мере. Этапы работ в
рамках каскадной модели часто также называют частями «проектного цикла»
системы. Такое название возникло потому, что этапы состоят из многих
итерационных процедур уточнения требований к системе и вариантов проектных
решении. Жизненный цикл самой системы существенно сложнее ее и больше. Он может
включать в себя произвольное число циклов уточнения, изменения и дополнения уже
принятых и реализованных проектных решений. В этих циклах происходит развитие
информационной системы и модернизация отдельных ее компонентов.
Лекция 10. Основные достоинства каскадной модели
Каскадная модель имеет ряд положительных сторон, благодаря которым она
хорошо зарекомендовала себя при выполнении различного рода инженерных
разработок и получила широкое распространение. Рассмотрим основные достоинства
модели «водопад»:
· на каждом этане формируется законченный набор проектной документации,
отвечающий критериям полноты и согласованности. На заключительных этапах также
разрабатывается пользовательская документация, охватывающая нее предусмотренные
стандартами виды обеспечения информационной системы: организационное,
методическое, информационное, программное, аппаратное;
· выполняемые в логичной последовательности этапы работ
позволяют планировать сроки завершения и соответствующие затраты.
Каскадная модель изначально разрабатывалась для решения различного рода
инженерных задач и не потеряла своего значения для прикладной области до
настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя и
при построении определенных информационных систем. Имеются в виду системы, для
которых в самом начале разработки можно достаточно точно и полно сформулировал
все требования, с тем чтобы предоставить разработчикам свободу выбора
реализации, наилучшей с технической точки зрения. К таким информационным
системам, в частности, относятся сложные расчетные системы, системы реального
времени. Тем не менее, несмотря на все свои достоинства, каскадная модель имеет
ряд недостатков, ограничивающих ее применение при разработке информационных
систем. Причем эти недостатки делают ее либо полностью неприменимой, либо
приводят к увеличению сроков разработки и стоимости проекта. В настоящее время
многие неудачи программных проектов объясняются именно применением
последовательного процесса разработки.
Недостатки каскадной модели
Перечень недостатков каскадной модели при ее использовании для разработки
информационных систем достаточно обширен. Вначале просто перечислим их, а затем
рассмотрим основные из них более подробно:
· существенная задержка получения результатов;
· ошибки и недоработки на любом из этапов выясняются, как
правило, на последующих этапах работ, что приводит к необходимости возврата на
предыдущие стадии;
· сложность распараллеливания работ по проекту;
· чрезмерная информационная перенасыщенность каждого из этапов;
· сложность управления проектом;
· высокий уровень риска и ненадежность инвестиций.
) Задержка получения результатов обычно считается главным недостатком
каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие
последовательного подхода к разработке согласование результатов с
заинтересованными сторонами производится только после завершения очередного
этапа работ. Поэтому может оказаться, что разрабатываемая информационная
система не соответствует требованиям пользователей. Причем такие несоответствия
могут возникать на любом этапе разработки - искажения могут непреднамеренно
вноситься и проектировщиками-аналитиками, и программистами, так как они не
обязательно хорошо разбираются в тех предметных областях, для которых
производится разработка информационной системы.
Кроме того, используемые при разработке информационной системы модели
автоматизируемого объекта, отвечающие критериям внутренней согласованности и
полноты, могут в силу различных причин устареть за время разработки (например,
из-за внесения изменений в законодательство, колебания курса валют и т. п.).
Это относится и к функциональной модели, и к информационной модели, и к
проектам интерфейса пользователя, и к пользовательской документации.
) Возврат на более ранние стадии. Данный недостаток каскадной модели в
общем-то является одним из проявлений предыдущего. Поэтапная и последовательная
работа над проектом может быть следствием то го, что ошибки, допущенные на
более ранних этапах, как правило, обнаруживаются только на последующих стадиях
работы над проектом. Поэтому, после того как ошибки проявятся, проект
возвращается на предыдущий этап, перерабатывается и снова передается на
последующую стадию. Это может служить причиной срыва графика работ и усложнения
взаимоотношений между группами разработчиков, выполняющих отдельные этапы
работы. Самым же неприятным является то, что недоработки предыдущего уровня
могут обнаруживаться не сразу на последующем уровне, а позднее (например, на
стадии опытной эксплуатации могут проявиться ошибки в описании предметной
области). Это означает, что часть проекта должна быть возвращена на начальный
уровень работы.
Одной из причин данной ситуации является то, что в качестве экспертов,
участвующих в описании предметной области, часто выступают будущие пользователи
системы, которые нередко не могут четко сформулировать то, что они хотели бы
получить. Кроме того, заказчики и исполнители часто неправильно понимают друг
друга вследствие того, что исполнители обычно не являются специалистами в
предметной области решаемой задачи, а заказчики далеки от программирования.
) Сложность параллельного ведения работ. Отмеченные выше проблемы
возникают вследствие того, что работа над проектом строится в виде цепочки
последовательных шагов. Причем даже в том случае, когда разработку некоторых
частей проекта (подсистем) можно вести параллельно, при использовании каскадной
схемы распараллеливание работ весьма затруднительно. Сложности параллельного
ведения работ связаны с необходимостью постоянного согласования различных
частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем
чаще и тщательнее должна выполняться синхронизация, тем сильнее зависимы друг
от друга группы разработчиков. Поэтому преимущества параллельного ведения работ
просто теряются.
Отсутствие параллелизма негативно сказывается и на организации работы
всего коллектива разработчиков. Работа одних групп сдерживается другими. Пока
производится анализ предметной области, проектировщики, разработчики и те, кто
занимается тестированием и администрированием, почти не имеют работы. Кроме
того, при последовательной разработке крайне сложно внести изменения в проект
после завершения этапа и передаче проекта на следующую стадию. Так, например,
если после передачи проекта на следующий этап группа разработчиков нашла более
эффективное решение, оно не может быть использовано. Это связано с тем, что
более раннее решение уже, возможно, реализовано и связано с другими частями
проекта. Поэтому исключается (или, по крайней мере, существенно затрудняется)
доработка проекта после его передачи на следующий этап.
) Информационная перенасыщенность. Проблема информационной
перенасыщенности возникает вследствие сильной зависимости между различными
группами разработчиков. Данная проблема заключается в том, что при внесении
изменений в одну из частей проекта необходимо оповещать всех разработчиков,
которые использовали или могли использовать эту часть в своей работе. Когда
система состоит из большого количества взаимосвязанных подсистем, то
синхронизация внутренней документации становится важной самостоятельной
задачей.
Причем синхронизация документации на каждую часть системы - это не более
чем процесс оповещения групп разработчиков. Самим же разработчикам необходимо
ознакомиться с изменениями и оценить, не сказались ли эти изменения на уже
полученных результатах. Все это может потребовать проведения повторного
тестирования и даже внесения изменений в уже готовые части проекта. Причем эти
изменения, в свою очередь, должны быть отражены во внутренней документации И
быть разосланы другим группам разработчиков. Как следствие, объем документации
по мере разработки проекта растет очень быстро, так что требуется все больше
времени для составления документации и ознакомления с ней.
Следует также отметить, что, кроме изучения нового материала, не отпадает
и необходимость в изучении старой информации. Это связано с тем, что вполне
вероятна ситуация, когда в процессе выполнения разработки изменяется состав
группы разработчиков (этот процесс носит название ротации кадров). Новым
разработчикам необходима информация о том, что было сделано до них. Причем чем
сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика
в курс дела.
)Сложность управления проектом при использовании каскадной схемы в
основном обусловлена строгой последовательностью стадий разработки и наличием
сложных взаимосвязей между различными частями проекта.
Последовательность разработки проекта приводит к тому, что одни группы
разработчиков должны ожидать результатов работы других команд. Поэтому
требуется административное вмешательство для того, чтобы согласовать сроки
работы и состав передаваемой документации.
В случае же обнаружения ошибок в выполненной работе необходим возврат к
предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям
в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены
прервать текущую работу (над новым проектом) и заняться исправлением ошибок.
Следствием этого обычно является срыв сроков выполнения как исправляемого, так
и нового проектов. Требовать же от команды разработчиков ожидания окончания
следующей стадии разработки нерационально, так как приводит к существенным
потерям рабочего времени.
Упростить взаимодействие между группами разработчиков и уменьшить
информационную перенасыщенность документации можно, уменьшая количество связей
между отдельными частями проекта. Однако это обычно весьма непросто. Далеко не
каждую информационную систему можно разделить на несколько слабо связанных
подсистем.
) Высокий уровень риска. Чем сложнее проект, тем больше продолжительность
каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями
проекта, количество которых также увеличивается. Причем результаты разработки
можно реально увидеть и оценить лишь на этапе тестирования, то есть после
завершения анализа, проектирования и разработки - этапов, выполнение которых
требует значительного времени и средств. Как уже было отмечено выше, запоздалая
оценка создает значительные проблемы при выявлении ошибок анализа и
проектирования - требуется возврат проекта на предыдущие стадии и повторение
процесса разработки.
Однако возврат на предыдущие стадии может быть связан не только с
ошибками, но и с изменениями, произошедшими за время выполнения разработки в
предметной области или в требованиях заказчика. Причем возврат проекта
вследствие этих причин на доработку не гарантирует, что предметная область
снова не изменится к тому моменту, когда будет готова следующая версия проекта.
Фактически это означает, что существует вероятность того, что процесс разработки
«зациклится» и никогда не дойдет до сдачи в эксплуатацию. Расходы на проект
будут постоянно расти, а сроки сдачи готового продукта - постоянно
откладываться.
Поэтому можно утверждать, что сложные проекты, разрабатываемые по
каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается
практикой: по сведениям консалтинговой компании The Standish Group, в США более
31 % проектов корпоративных информационных систем (IT-проектов) заканчивается
неуспехом; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем
на 189 %, то есть почти в два раза); и только 16,2 % проектов укладывается и в
срок, и в бюджет.
Существует еще один серьезный недостаток, присущий каскадной модели
разработки, на который также следует обратить внимание. Этот недостаток связан
с конфликтом (не всегда явным) между разработчиками, участвующими в выполнении
проекта. Этот конфликт обусловлен тем, что возврат части проекта на предыдущую
стадию обычно сопровождается поиском причин и виновных. А так как однозначно персонифицировать
ответственного за ошибки далеко не всегда возможно, то попытки поиска виноватых
могут сильно усложнить отношения в коллективе. Как следствие, в рабочей группе
часто ценится не тот руководитель, который имеет высокую квалификацию и больший
опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более
удобные условия работы и т, п. В результате появляется опасность снижения и
квалификации, и творческого потенциала всей команды. Соответственно,
техническое руководство проектом начинает в большей степени подменяться
организационным руководством, все более детальной проработкой должностных
инструкций и все более формальным исполнением этих инструкций. Тот, кто не
умеет организовать работу, обречен бороться за дисциплину. И здесь возникает
проблема несовместимости дисциплины и творчества. Чем строже дисциплина, тем
менее творческой становится атмосфера в коллективе. И такое положение вещей
может привести к тому, что наиболее одаренные кадры со временем покинут
коллектив.
Лекция 11. Спиральная модель жизненного цикла
Спиральная модель, в отличие от каскадной, предполагает итерационный
процесс разработки информационной системы. При этом возрастает значение
начальных этапов жизненного цикла, таких как анализ и проектирование. На этих
этапах проверяется и обосновывается реализуемость технических решений путем
создания прототипов.
Итерации.
Каждая итерация представляет собой законченный цикл разработки,
приводящий к выпуску внутренней или внешней версии изделия (или подмножества
конечного продукта), которое совершенствуется от итерации к итерации, чтобы
стать законченной системой. Таким образом, каждым виток спирали соответствует
созданию фрагмента или версии программного изделия, на нем уточняются цели и
характеристики проекта, определяется его качество, планируются работы
следующего витка спирали, На каждой итерации углубляются и последовательно
конкретизируются детали проекта, в результате чего выбирается обоснованный
вариант, который доводится до окончательной реализации.
Использование спиральной модели позволяет осуществлять переход на
следующий этап выполнения проекта, не дожидаясь полного завершения работы на
текущем - недоделанную работу можно будет выполнить на следующей итерации.
Главная задача каждой итерации - как можно быстрее создать
работоспособный продукт, который можно показать пользователям системы. Таким
образом, существенно упрощается процесс внесения уточнений и дополнений в
проект.
Преимущества спиральной модели.
Спиральный подход к разработке программного обеспечения позволяет
преодолеть большинство недостатков каскадной модели и, кроме того, обеспечивает
ряд дополнительных возможностей, делая процесс разработки более гибким.
Рассмотрим преимущества итерационного подхода более подробно:
· итерационная разработка существенно упрощает внесение
изменений в проект при изменении требований заказчика;
· при использовании спиральной модели отдельные элементы
информационной системы интегрируются в единое целое постепенно. При
итерационном подходе интеграция производится фактически непрерывно. Поскольку
интеграция начинается с меньшего количества элементов, то возникает гораздо
меньше проблем при ее проведении (по некоторым оценкам, при использовании
каскадной модели разработки интеграция занимает до 40 % всех затрат в конце
проекта);
· уменьшение уровня рисков. Данное преимущество является
следствием предыдущего, так как риски обнаруживаются именно во время
интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По
мере продвижения разработки ожидаемый риск уменьшается. Данное утверждение
справедливо при любой модели разработки, однако при использовании спиральной
модели уменьшение уровня рисков происходит с наибольшей скоростью. Это связано
с тем, что при итерационном подходе интеграция выполняется уже на первой итерации
и при выполнении начальных итераций выявляются многие аспекты проекта, такие
как пригодность используемых инструментальных средств и ПО, квалификация
разработчиков и т. п. Ниже приведены зависимости уровня рисков от времени
разработки при использовании каскадного и итерационного подходов;
· итерационная разработка обеспечивает большую гибкость в
управлении проектом, давая возможность внесения тактических изменений в
разрабатываемое изделие. Например, можно сократить сроки разработки за счет
уменьшения функциональности системы пли использовать в качестве составных
частей системы продукцию сторонних фирм вместо собственных разработок.
· итерационный подход упрощает повторное использование
компонентов позволяет использовать компонентный подход к программированию -
более подробно об этом мы будем говорить в следующей главе). Это обусловлено
тем. что гораздо проще выявить (идентифицировать) общие части проекта, когда
они уже частично разработаны, чем пытаться выделить их в самом начале проекта.
Анализ проекта после проведения нескольких начальных итерации позволяет выявить
общие, многократно используемые компоненты, которые на последующих итерациях
будут совершенствоваться;
· спиральная модель позволяет получить более надежную и
устойчивую систему. Это связано с тем, что по мере развития системы ошибки и
слабые места обнаруживаются и исправляются на каждой итерации. Одновременно
могут корректироваться критические параметры эффективности, что при
использовании каскадной модели выполняется только перед внедрением системы;
· итерационный подход позволяет совершенствовать процесс
разработки - анализ, проводимый в конце каждой итерации, позволяет проводить
оценку того, что должно быть изменено в организации разработки, и улучшить ее
на следующей итерации.
Проблемы, возникающие при использовании спиральной модели.
Основная проблема спирального цикла - определение момента перехода на
следующий этап. Для её решения необходимо ввести временные ограничения на
каждый из этапов жизненного цикла. Иначе процесс разработки может прекратится в
бесконечное совершенствование уже сделанного. При итерационном подходе полезно
следовать принципу "лучшее - враг хорошего". Поэтому завершение
итерации должно производиться строго в соответствии с планом, даже если не вся
запланированная работа закончена. Планирование работ обычно проводится на
основе статистических данных, полученных в предыдущих проектах, и личного опыта
разработчиков.
Методология и технология разработки информационных систем
Методология создания информационных систем заключается в организации
процесса построения информационной системы и обеспечении управления этим
процессом для того, чтобы гарантировать выполнение требований, как к самой
системе, так и к характеристикам процесса разработки.
Основными задачами, решение которых должна обеспечивать методология
создания корпоративных информационных систем (с помощью соответствующего набора
инструментальных средств), являются следующие:
· обеспечение создания информационных систем, отвечающих целям
и задачам предприятия и соответствующих предъявляемым к ним требованиям по
автоматизации деловых процессов;
· гарантия создания системы с заданными параметрами в течение
заданного времени в рамках оговоренного заранее бюджета;
· простота сопровождения, модификации и расширения системы с
целью обеспечения ее соответствия изменяющимся условиям работы предприятия;
· обеспечение создания корпоративных информационных систем,
отвечающих требованиям открытости, переносимости и масштабируемости;
· возможность использования в создаваемой системе разработанных
ранее и применяемых на предприятии средств информационных технологий
(программного обеспечения, баз данных, средств вычислительной техники,
телекоммуникаций).
Методологии, технологии и инструментальные средства проектирования
(CASE-средства) составляют основу проекта любой информационной системы.
Методология реализуется через конкретные технологии и поддерживающие их
стандарты, методики и инструментальные средства, которые обеспечивают
выполнение процессов жизненного цикла информационных систем.
Основное содержание технологии проектирования составляют технологические
инструкции, состоящие из описания последовательности технологических операций,
условий, в зависимости от которых выполняется та или иная операция, и описаний
самих операций.
Технология проектирования может быть представлена как совокупность трех
составляющих:
· заданной последовательности выполнения технологических
операций проектирования;
· критериев и правил, используемых для оценки результатов
выполнения технологических операций;
· графических и текстовых средств (нотаций), используемых для
описания проектируемой системы.
Каждая технологическая операция должна обеспечиваться следующими
материальными и информационными ресурсами:
· данными, полученными на предыдущей операции (или исходными
данными), представленными в стандартном виде;
· методическими материалами, инструкциями, нормативами и
стандартами;
· программными и техническими средствами;
· исполнителями.
Результаты выполнения операции должны представляться в некотором стандартном
виде, обеспечивающем их адекватное восприятие при выполнении следующей
технологической операции (на которой они будут использоваться в качестве
исходных данных).
Можно сформулировать следующий ряд общих требований, которым должна
удовлетворять технология проектирования, разработки и сопровождения
информационных систем:
· поддерживать полный жизненный цикл информационной системы;
· обеспечивать гарантированное достижение целей разработки
системы с заданным качеством и в установленное время;
· обеспечивать возможность разделения крупных проектов на ряд
подсистем - декомпозицию проекта на составные части, разрабатываемые группами
исполнителей ограниченной численности, с последующей интеграцией составных
частей;
Декомпозиция проекта позволяет повысить эффективность работ. Подсистемы,
на которые разбивается проект, должны быть слабо связанны по данным и функциям.
Каждая подсистема разрабатывается отдельной группой разработчиков. При этом
необходимо обеспечить координацию работ и исключить дублирование результатов,
получаемых каждой проектной группой.
· технология должна обеспечивать возможность ведения работ по
проектированию отдельных подсистем небольшими группами (3-7 человек). Это
обусловлено принципами управляемости коллектива и повышения производительности
за счет минимизации числа внешних связей;
· обеспечивать минимальное время получения работоспособной
системы;
Здесь имеется в виду не реализация информационной системы в целом, а
разработка ее отдельных подсистем. Как правило, даже при наличии полностью завершенного
проекта внедрение разработанной системы проводится последовательно, по
отдельным подсистемам. Реализация же всей системы в сжатые сроки может
потребовать привлечения большого числа разработчиков, при этом эффект может
оказаться ниже, чем при реализации отдельных подсистем в более короткие сроки
меньшим числом разработчиков.
· предусматривать возможность управления конфигурацией проекта,
ведения версий проекта и его составляющих, возможность автоматического выпуска
проектной документации и синхронизацию ее версий с версиями проекта;
· обеспечивать независимость выполняемых проектных решений от
средств реализации системы - системы управления базами данных, операционной
системы, языка и системы программирования.
Методология RAD - Rapid Application Development
На начальном этапе существования компьютерных информационных систем их
разработка велась на традиционных языках программирования. Однако по мере
возрастания сложности разрабатываемых систем и увеличения запросов
пользователей (чему в значительной степени способствовал прогресс в области
вычислительной техники, а также появление удобного графического интерфейса
пользователя в системном программном обеспечении) потребовались новые средства,
обеспечивающие значительное сокращение сроков разработки. Это послужило
предпосылкой к созданию целого направления в области программного обеспечения -
инструментальных средств для быстрой разработки приложений. Развитие этого
направления привело к появлению на рынке программного обеспечения средств
автоматизации практически всех этапов жизненного цикла информационных систем.
Лекция 12. Основные особенности методологии RAD
Методология разработки информационных систем, основанная на использовании
средств быстрой разработки приложений, получила в последнее время широкое
распространение и приобрела название методологии быстрой разработки приложений
- RAD (Rapid Application Development). Данная методология охватывает все этапы
жизненного цикла современных информационных систем. RAD - это комплекс
специальных инструментальных средств быстрой разработки прикладных
информационных систем, позволяющих оперировать с определенным набором
графических объектов, функционально отображающих отдельные информационные
компоненты приложений.
Под методологией быстрой разработки приложений обычно понимается процесс
разработки информационных систем, основанный на трех основных элементах:
· небольшой команде программистов (обычно от 2 до 10 человек);
· тщательно проработанный производственный график работ,
рассчитанный на сравнительно короткий срок разработки (от 2 до б мес.);
· итерационная модель разработки, основанная на тесном
взаимодействии с заказчиком - по мере выполнения проекта разработчики уточняют
и реализуют в продукте требования, выдвигаемые заказчиком.
При использовании методологии RAD большое значение имеют опыт и
профессионализм разработчиков. Группа разработчиков должна состоять из
профессионалов, имеющих опыт в анализе, проектировании, программировании и
тестировании программного обеспечения.
Основные принципы методологии RAD можно свести к следующему:
· используется итерационная (спиральная) модель разработки;
· полное завершение работ на каждом из этапов жизненного цикла
не обязательно;
· в процессе разработки информационной системы необходимо
тесное взаимодействие с заказчиком и будущими пользователями;
· необходимо применение CASE-средств и средств быстрой
разработки приложений;
· необходимо применение средств управления конфигурацией,
облегчающих внесение изменений в проект и сопровождение готовой системы;
· необходимо использование прототипов, позволяющее полнее
выяснить и реализовать потребности конечного пользователя;
· тестирование и развитие проекта осуществляются одновременно с
разработкой;
· разработка ведется немногочисленной и хорошо управляемой
командой профессионалов;
· необходимы грамотное руководство разработкой системы, четкое
планирование и контроль выполнения работ.
Объектно-ориентированный подход
Средства RAD дали возможность реализовывать совершенно иную, по сравнению
с традиционной, технологию создания приложений: информационные объекты
формируются как некие действующие модели (прототипы), чье функционирование
согласовывается с пользователем, а затем разработчик может переходить
непосредственно к формированию законченных приложений, не теряя из виду общей
картины проектируемой системы.
Возможность использования подобного подхода в значительной степени
является результатом применения принципов объектно-ориентированного
проектирования. Применение объектно-ориентированных методов позволяет
преодолеть одну из главных трудностей, возникающих при разработке сложных
систем - колоссальный разрыв между реальным миром (предметной областью
описываемой проблемы) и имитирующей средой.
Использование объектно-ориентированных методов позволяет создать описание
(модель) предметной области в виде совокупности объектов - сущностей,
объединяющих данные и методы обработки этих данных (процедуры). Каждый объект
обладает своим собственным поведением и моделирует некоторый объект реального
мира. С этой точки зрения объект является вполне осязаемой вещью, которая
демонстрирует определенное поведение.
В объектном подходе акцент переносится на конкретные характеристики
физической или абстрактной системы, являющейся предметом программного
моделирования. Объекты обладают целостностью, которая не может быть нарушена.
Таким образом, свойства, характеризующие объект и его поведение, остаются
неизменными. Объект может только менять состояние, управляться или становиться
в определенное отношение к другим объектам.
Широкую известность объектно-ориентированное программирование получило с
появлением визуальных средств проектирования, когда было обеспечено слияние
(инкапсуляция) данных с процедурами, описывающими поведение реальных объектов,
в объекты программ, которые могут быть отображены определенным образом в
графической пользовательской среде. Это позволило приступить к созданию
программных систем, максимально похожих на реальные, и добиваться наивысшего
уровня абстракции. В свою очередь, объектно-ориентированное программирование
позволяет создавать более надежные коды, так как у объектов программ существует
точно определенный и жестко контролируемый интерфейс.
При разработке приложений с помощью инструментов RAD используется
множество готовых объектов, сохраняемых в общедоступном хранилище. Однако
обеспечивается и возможность разработки новых объектов. При этом новые объекты
могут разрабатываться как на основе существующих, так и «с нуля».
Инструментальные средства RAD обладают удобным графическим интерфейсом
пользователя и позволяют на основе стандартных объектов формулировать простые
приложения без написания кода программы. Это является большим преимуществом
RAD, так как в значительной степени сокращает рутинную работу по разработке
интерфейсов пользователя (при использовании обычных средств разработка
интерфейсов представляет собой достаточно трудоемкую задачу, отнимающую много
времени). Высокая скорость разработки интерфейсной части приложений позволяет
быстро создавать прототипы и упрощает взаимодействие с конечными
пользователями.
Таким образом, инструменты RAD позволяют разработчикам сконцентрировать
усилия на сущности реальных деловых процессов предприятия, для которого
создается информационная система. В итоге это приводит к повышению качества
разрабатываемой системы.
Визуальное программирование
Применение принципов объектно-ориентированного программирования позволило
создать принципиально новые средства проектирования приложений, называемые
средствами визуального программирования. Визуальные инструменты RAD позволяют
создавать сложные графические интерфейсы пользователя вообще без написания кода
программы. При этом разработчик может на любом этапе наблюдать то, что
закладывается в основу принимаемых решений. Визуальные средства разработки
оперируют в первую очередь со стандартными интерфейсными объектами - окнами,
списками, текстами, которые легко можно связать с данными из базы данных и
отобразить на экране монитора. Другая группа объектов представляет собой
стандартные элементы управления - кнопки, переключатели, флажки, меню и т. п.,
с помощью которых осуществляется управление отображаемыми данными. Все эти
объекты могут быть стандартным образом описаны средствами языка, а сами
описания сохранены для дальнейшего повторного использования.
В настоящее время существует довольно много различных визуальных средств
разработки приложений. Но все они могут быть разделены на две группы -
универсальные и специализированные.
Среди универсальных систем визуального программирования сейчас наиболее
распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их
называем потому, что они не ориентированы на разработку только приложений баз
данных- с их помощью могут быть разработаны приложения почти любого типа, в том
числе и информационные приложения. Причем программы, разрабатываемые с помощью
универсальных систем, могут взаимодействовать практически с любыми системами
управления базами данных. Это обеспечивается как использонанием драйверов ODBC
или OLE DB, так и применением специализированных средств (компонентов).
Специализированные средства разработки ориентированы только на создание
приложений баз данных. Причем, как правило, они привязаны к вполне определенным
системам управления балами данных. В качестве примера таких систем можно
привести Power Builder фирмы Sybase (естественно, предназначенный для работы с
СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft. Поскольку задачи
создания прототипов и разработки пользовательского интерфейса, по существу,
слились, программист получил непрерывную обратную связь с конечными пользователями,
которые могут не только наблюдать за созданием приложения, но и активно
участвовать в нем, корректировать результаты и свои требования. Это также
способствует сокращению сроков разработки и является важным психологическим
аспектом, который привлекает к RAD все большее число пользователей.
Визуальные инструменты RAD позволяют максимально сблизить этапы создания
информационных систем: анализ исходных условий, проектирование системы,
разработка прототипов и окончательное формирование приложений становятся
сходными, так как на каждом этапе разработчики оперируют визуальными объектами.
Событийное программирование
Логика приложения, построенного с помощью RAD, является
событийно-ориентированной. Это означает следующее: каждый объект, входящий в
состав приложения, может генерировать события и реагировать на события,
генерируемые другими объектами. Примерами событий могут быть: открытие и
закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши,
изменение данных в базе данных и т. п.
Разработчик реализует логику приложения путем определения обработчика
каждого события - процедуры, выполняемой объектом при наступлении
соответствующий события. Например, обработчик события «нажатие кнопки» может
открыть диалоговое окно. Таким образом, управление объектами осуществляется с
помощью событий.
Обработчики событий, связанных с управлением базой данных (DELETE,
INSERT, UPD ATE), могут реализовываться в виде триггеров на клиентском или
серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность
базы данных при операциях удаления, вставки и обновления, а также
автоматическую генерацию первичных ключей.
Лекция 13. Профили открытых информационных систем
Создание, сопровождение и развитие современных сложных информационных
систем базируется на методологии построения таких систем как открытых. Открытые
информационные системы создаются в процессе информатизации всех основных сфер
современного общества: органов государственного управления, финансово-кредитной
сферы, информационного обслуживания предпринимательской деятельности,
производственной сферы, науки, образования. Развитие и использование открытых
информационных систем неразрывно связаны с применением стандартов на основе
методологии функциональной стандартизации информационных технологий.
Понятие профиля информационной системы
При создании и развитии сложных, распределенных, тиражируемых
информационных систем требуется гибкое формирование и применение
гармонизированных совокупностей базовых стандартов и нормативных документов
разного уровня, выделение в них требований и рекомендаций, необходимых для
реализации заданных функций системы. Для унификации и регламентирования такие
совокупности базовых стандартов должны адаптироваться и конкретизироваться
применительно к определенным классам проектов, функций, процессов и компонентов
системы. В связи с этим выделилось и сформировалось понятие профиля
информационной системы как основного инструмента функциональной стандартизации.
Профиль - это совокупность нескольких (или подмножество одного) базовых
стандартов с четко определенными и гармонизированными подмножествами
обязательных и факультативных возможностей, предназначенная для реализации
заданной функции или группы функций.
Профиль формируется исходя из функциональных характеристик объекта стандартизации,
В профиле выделяются и устанавливаются допустимые возможности и значения
параметров каждого базового стандарта и/или нормативного документа, входящего в
профиль.
Профиль не должен противоречить использованным в нем базовым стандартам и
нормативным документам. Он должен применять выбранные из альтернативных
вариантов необязательные возможности и значения параметров в пределах
допустимых.
На базе одной совокупности базовых стандартов могут формироваться и
утверждаться различные профили для разных проектов информационных систем.
Ограничения базовых документов профиля и их согласованность, проведенная
разработчиками профиля, должны обеспечивать качество, совместимость и
корректное взаимодействие отдельных компонентов системы, соответствующих
профилю, в заданной области его применения.
Базовые стандарты и профили в зависимости от проблемно-ориентированной
области применения информационных систем могут использоваться как
непосредственные директивные, руководящие или рекомендательные документы, а
также как нормативная база, необходимая при выборе или разработке средств
автоматизации технологических этапов или процессов создания, сопровождения и
развития информационных систем. Обычно рассматривают две группы профилей:
· регламентирующие архитектуру и структуру информационной
системы;
· регламентирующие процессы проектирования, разработки,
применения, сопровождения и развития системы.
В зависимости от области применения профили могут иметь разные категории
и соответственно разные статусы утверждения:
· профили конкретной информационной системы, определяющие
стандартизованные проектные решения в пределах данного проекта;
· профили информационной системы, предназначенные для решения
некоторого класса прикладных задач.
Профили информационных систем унифицируют и регламентируют только часть
требований характеристик, показателей качества объектов и процессов, выделенных
и формализованных на базе стандартов и нормативных документов. Другая часть
функциональных и технических характеристик системы определяется заказчиками и
разработчиками творчески, без учета положений нормативных документов.
Принципы формирования профиля информационной системы
Использование профилей информационных систем призвано решить следующие
задачи:
· снижение трудоемкости проектов;
· повышение качества компонентов информационной системы;
· обеспечение расширяемости и масштабируемости разрабатываемых
систем;
· обеспечение возможности функциональной интеграции в
информационную систему задач, которые раньше решались раздельно;
· обеспечение переносимости прикладного программного
обеспечения. В зависимости от того, какие из указанных задач являются наиболее
приоритетными, производится выбор стандартов и документов для формирования
профиля.
Актуальность использования профилей информационных систем обусловлена
современным состоянием стандартизации информационных технологий, которое
характеризуется следующими особенностями:
· существует множество международных и национальных стандартов,
которые не полностью и неравномерно удовлетворяют потребности в стандартизации
объектов и процессов создания и применения сложных информационных систем;
· длительные сроки разработки, согласования и утверждения
международных и национальных стандартов приводят к их консерватизму и
хроническому отставанию от современных информационных технологий;
· функциональными стандартами поддержаны и регламентированы
только самые простые объекты и рутинные, массовые процессы: телекоммуникации,
программирование, документирование программ и данных. Наиболее сложные и
творческие процессы создания и развития крупных распределенных информационных
систем - системный анализ и проектирование, интеграция компонентов и систем,
испытания и сертификация - почти не поддержаны требованиями и рекомендациями
стандартов из-за трудности их формализации и унификации;
· совершенствование и согласование нормативных и методических
документов в ряде случаев позволяют создать на их основе национальные и
международные стандарты.
Подходы к формированию профилей информационных систем могут быть
различными. В международной функциональной стандартизации информационных
технологий принято довольно жесткое понятие профиля. Считается, что его основой
могут быть только международные и национальные, утвержденные стандарты.
Использование стандартов де-факто и нормативных документов фирм не допускается.
При таком подходе затруднены унификация, регламентирование и параметризация
множества конкретных функций и характеристик сложных объектов архитектуры и
структуры современных информационных систем. Другой подход к разработке и применению
профилей информационных систем состоит в использовании совокупности
адаптированных и параметризованных базовых международных и национальных
стандартов и открытых спецификаций, отвечающих стандартам де-факто и
рекомендации международных консорциумов.
Эталонная модель среды открытых систем (OSE/RM) определяет разделение
любой информационной системы на две составляющие: приложения (прикладные
программы и программные комплексы) и среду, в которой эти приложения
функционируют.
Между приложениями и средой определяются стандартизованные интерфейсы -
Application Program Interface (API), которые являются необходимой частью
профилей любой открытой системы. Кроме того, в профилях могут быть определены
унифицированные интерфейсы взаимодействия функциональных частей друг с другом и
интерфейсы взаимодействия между компонентами среды системы. Спецификации
выполняемых функций и интерфейсов взаимодействия могут быть оформлены в виде
профилей компонентов системы. Таким образом, профили информационной системы с
иерархической структурой могут включать в себя:
· стандартизованные описания функций, выполняемых данной системой;
· функции взаимодействия системы с внешней для нее средой;
· стандартизованные интерфейсы между приложениями и средой
информационной системы;
· профили отдельных функциональных компонентов, входящих в систему. Для
эффективного использования конкретного профиля необходимо;
· выделить объединенные логической связью проблемно-ориентированные области
функционирования, где могут применяться стандарты, общие для одной организации
или группы организаций;
· идентифицировать стандарты и нормативные документы, варианты
их использования и параметры, которые необходимо включить в профиль;
· документально зафиксировать участки конкретного профиля, где
требуется создание новых стандартов или нормативных документов, и
идентифицировать характеристики, которые могут оказаться важными для разработки
недостающих стандартов и нормативных документов этого профиля;
· формализовать профиль в соответствии с его категорией, включая
стандарты, различные варианты нормативных документов и дополнительные
параметры, которые непосредственно связаны с профилем;
· опубликовать профиль и/или продвигать его по формальным
инстанциям для дальнейшего распространения.
При использовании профилей важное значение имеет обеспечение проверки
корректности их применения путем тестирования, испытаний и сертификации. Для
этого требуется создание технологии контроля и тестирования в процессе
применения профиля. Данная технология должна поддерживаться совокупностью
методик, инструментальных средств, составом и содержанием оформляемых
документов на каждом этапе выполнения проекта.
Использование профилей способствует унификации при разработке тестов,
проверяющих качество и взаимодействие компонентов проектируемой информационной
системы. Профили должны определяться таким образом, чтобы тестирование их
реализации можно было проводить по возможности наиболее полно по
стандартизованной методике. При этом возможно применение ранее разработанных
методик, так как международные стандарты и профили являются основой для
создания общепризнанных аттестационных тестов.
Структура профилей информационных систем
Разработка и применение профилей являются органической частью процессов
проектирования, разработки и сопровождения информационных систем. Профили
характеризуют каждую конкретную информационную систему на всех стадиях ее
жизненного цикла, задавая согласованный набор базовых стандартов, которым
должна соответствовать система и ее компоненты.
Стандарты, важные с точки зрения заказчика, должны задаваться в ТЗ на
проектирование системы и составлять ее первичный профиль. То, что не задано в
ТЗ, первоначально остается на усмотрение разработчика системы, который,
руководствуясь требованиями ТЗ, может дополнять и развивать профили системы и
впоследствии согласовывать их с заказчиком. Таким образом, профиль конкретной
системы не является статичным, он развивается и конкретизируется в процессе
проектирования информационной системы и оформляется в составе документации
проекта системы.
В профиль конкретной системы включаются спецификации компонентов,
разработанных в составе данного проекта, и спецификации использованных готовых
программных и аппаратных средств, если эти средства не специфицированы
соответствующими стандартами. После завершения проектирования и испытаний
системы, в ходе которых проверяется ее соответствие профилю, профиль
применяется как основной инструмент сопровождения системы при эксплуатации,
модернизации и развитии.
Лекция 14. Общая структура профиля информационной системы
Формирование и применение профилей конкретных информационных систем
выполняется на основе использования международных и национальных стандартов,
ведомственных нормативных документов, а также стандартов де-факто при условии
доступности соответствующих им спецификаций. Для обеспечения корректного
применения профилей их описания должны содержать:
· определение целей использования данного профиля;
· точное перечисление функций объекта или процесса
стандартизации, определяемого данным профилем;
· формализованные сценарии применения базовых стандартов и
спецификаций, включенных в данный профиль;
· сводку требований к информационной системе или ее
компонентам, определяющих их соответствие профилю, и требований к методам
тестирования соответствия;
· нормативные ссылки на конкретный набор стандартов и других
нормативных документов, составляющих профиль, с точным указанием применяемых
редакций и ограничений, способных повлиять на достижение корректного
взаимодействия объектов стандартизации при использовании данного профиля;
· информационные ссылки на все исходные документы.
На стадиях жизненного цикла информационной системы выбираются и затем
применяются основные функциональные профили:
· профиль прикладного программного обеспечения;
· профиль среды информационной системы;
· профиль защиты информации в информационной системе;
· профиль инструментальных средств, встроенных в информационную
систему.
Профиль прикладного программного обеспечения
Прикладное программное обеспечение всегда является проблемно-ориентированным
и определяет основные функции информационной системы. Функциональные профили
системы должны включать в себя согласованные базовые стандарты. При
использовании функциональных профилей информационных систем следует еще иметь в
виду согласование этих профилей между собой. Необходимость такого согласования
возникает, в частности, при использовании стандартизованных API, в том числе
интерфейсов приложений со средой их функционирования и со средствами защиты
информации. При согласовании функциональных профилей возможны также уточнения
профиля среды системы и профиля встраиваемых инструментальных средств создания,
сопровождения и развития прикладного программного обеспечения.
Профиль среды информационной системы
Профиль среды информационной системы должен определять ее архитектуру в
соответствии с выбранной моделью обработки данных.
Стандарты интерфейсов приложений со средой (API) должны быть определены
по функциональным областям профилей информационной системы. Декомпозиция
структуры среды функционирования системы на составные части, выполняемая на
стадии эскизного проектирования, позволяет детализировать профиль среды
информационной системы по функциональным областям эталонной модели OSE/RM:
· область графического пользовательского интерфейса;
· область реляционных или объектно-ориентированных СУБД
(например, стандарт языка SQL-92 и спецификации доступа к разным базам данных);
· область операционных систем с учетом сетевых функций,
выполняемых на уровне операционной системы;
· область телекоммуникационной среды в части услуг и служб
прикладного уровня: электронной почты, доступа к удаленным базам данных,
передачи файлов, доступа к файлам и управления файлами.
Профиль среды распределенной системы должен включать стандарты протоколов
транспортного уровня, стандарты локальных сетей (например, стандарт Ethernet
IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 и), а также стандарты средств
сопряжения проектируемой информационной системы с сетями передачи данных общего
назначения.
Выбор аппаратных платформ информационной системы связан с определением их
параметров: вычислительной мощности серверов и рабочих станций в соответствии с
проектными решениями по разделению функций между клиентами и серверами; степени
масштабируемости аппаратных платформ; надежности. Профиль среды должен
содержать стандарты, определяющие параметры технических средств и способы их
измерения (например, стандартные тесты измерения производительности).
Профиль защиты информации
Профиль защиты информации должен обеспечивать реализацию политики
информационной безопасности, разрабатываемой в соответствии с требуемой
категорией безопасности и критериями безопасности, заданными в ТЗ на систему.
Построение профиля защиты информации в распределенных системах клиент-сервер
методически связано с точным определением компонентов системы, ответственных за
те или иные функции, службы и услуги, и средств защиты информации, встроенных в
эти компоненты. Функциональная область защиты информации включает в себя
следующие функции защиты, реализуемые разными компонентами системы:
· функции, реализуемые операционной системой;
· функции защиты от несанкционированного доступа, реализуемые
на уровне программного обеспечения промежуточного слоя;
· функции управления данными, реализуемые СУБД;
· функции защиты программных средств, включая средства защиты
от вирусов;
· функции защиты информации при обмене данными в распределенных
системах, включая криптографические функции;
· функции администрирования средств безопасности.
Профиль защиты информации должен включать указания на методы и средства
обнаружения в применяемых аппаратных и программных средствах недекларированных
возможностей. Профиль должен также включать указания на методы и средства
резервного копирования информации и восстановления информации при отказах и сбоях
аппаратуры системы.
Профиль инструментальных средств, встроенных в информационную систему,
должен отражать решения по выбору методологии и технологии создания,
сопровождения и развития информационной системы. В этом профиле должны
содержаться ссылки на описание выбранных методологии и технологии, выполненное
на стадии эскизного проектирования системы.
Состав инструментальных средств определяется на основании решений и
нормативных документов об организации сопровождения и развития информационной
системы. При этом должны быть учтены правила и порядок, регламентирующие
внесение изменений в действующие системы. Функциональная область профиля
инструментальных средств, встроенных в систему, охватывает функции
централизованного управления и администрирования, связанные с:
· контролем производительности и корректности функционирования системы в
целом;
· управлением конфигурацией прикладного программного
обеспечения, тиражированием версий;
· управлением доступом пользователей к ресурсам системы и
конфигурацией ресурсов;
· перенастройкой приложений в связи с изменениями прикладных
функций информационной системы;
· настройкой пользовательских интерфейсов (генерацией экранных
форм и отчетов);
· ведением баз данных системы;
· восстановлением работоспособности системы после сбоев и
аварий.
Дополнительные ресурсы, необходимые для функционирования встроенных
инструментальных средств, такие как минимальный и рекомендуемый объем
оперативной памяти, размеры требуемого дискового пространства и т. п., должны
быть учтены в разделе проекта, относящемся к среде информационной системы.
Выбор инструментальных средств, встроенных в систему, должен производиться в
соответствии с требованиями профиля среды. Ссылки на соответствующие стандарты,
входящие в профиль среды, должны содержаться и в профиле инструментальных
средств.
В этом профиле должны также содержаться ссылки на требования к средствам
тестирования, которые необходимы для процессов сопровождения и развития системы
и должны быть в нее встроены. В число встроенных в информационную систему
средств тестирования должны входить средства функционального тестирования
приложений, тестирования интерфейсов, системного тестирования и тестирования
серверов/клиентов при максимальной нагрузке.
Лекция 15. Фазы жизненного цикла в рамках методологии RAD
При использовании методологии быстрой разработки приложений жизненный
цикл информационной системы состоит из четырех фаз:
· фаза анализа и планирования требований;
· фаза проектирования;
· фаза построения;
· фаза внедрения.
Рассмотрим каждую из них более подробно.
Фаза анализа и планирования требований.
На данной фазе выполняются следующие работы:
· определяются функции, которые должна выполнять
разрабатываемая информационная система;
· определяются наиболее приоритетные функции, требующие разработки
в первую очередь;
· проводится описание информационных потребностей;
Определение указанных выше требований выполняется совместно будущими
пользователями системы и разработчиками.
· ограничивается масштаб проекта;
· определяются временные рамки для каждой из последующих фаз;
· в заключение, определяется сама возможность реализации
данного проекта в установленных рамках финансирования, на имеющихся аппаратных
и программных средствах.
Если реализация проекта принципиально возможна, то результатом фазы анализа
и планирования требований будет список функций разрабатываемой информационной
системы с указанием их приоритетов и предварительные функциональные и
информационные модели системы.
Фаза проектирования
На фазе проектирования необходимым инструментом являются CASE-средства,
используемые для быстрого получения работающих прототипов приложений.
Термин CASE (Computer Aided Software/System Engineering) используется в
настоящее время в весьма широком смысле. Первоначальное значение термина CASE
ограничивалось лишь вопросами автоматизации разработки программного
обеспечения. Однако в дальнейшем значение этого термина расширилось и приобрело
новый смысл, охватывающий процесс разработки сложных информационных систем в
целом. Теперь под термином -CASE-средства» понимаются программные средства,
поддерживающие процессы создания и сопровождения информационных систем, включая
анализ и формулировку требований, проектирование прикладного программного
обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение
качества, конфигурационное управление и управление проектом, а также другие
процессы.
Прототипы, созданные с помощью CASE-средств, анализируются
пользователями, которые уточняют и дополняют те требования к системе, которые
не были выявлены на предыдущей фазе. Таким образом, на данной фазе также
необходимо участие будущих пользователей в техническом проектировании системы.
Для построения всех моделей и прототипов должны быть использованы именно
те CASE-средства, которые будут затем применяться при построении системы.
Данное требование связано с тем, что при передаче информации о проекте с этапа
на этап может произойти фактически неконтролируемое искажение данных.
Применение единой среды хранения информации о проекте позволяет избежать этой
опасности.
Далее на этой фазе проводится анализ и при необходимости корректировка
функциональной модели системы. Детально рассматривается каждый процесс системы.
При необходимости для каждого элементарного процесса создается частичный
прототип: экран, диалог или отчет (это позволяет устранить неясности или
неоднозначности). Затем определяются требования разграничения доступа к данным.
После детального рассмотрения процессов определяется количество функциональных
элементов разрабатываемой системы. Это позволяет разделить информационную
систему на ряд подсистем, каждая из которых реализуется одной командой
разработчиков за приемлемое для RAD-проектов время (порядка полутора месяцев).
С использованием CASE-средств проект распределяется между различными командами
- делится функциональная модель.
На этой же фазе происходит определение набора необходимой документации.
Результатами данной фазы являются;
· общая информационная модель системы;
· функциональные модели системы в целом и подсистем,
реализуемых отдельными командами разработчиков;
· точно определенные с помощью CASE-средства интерфейсы между
автономно разрабатываемыми подсистемами;
· построенные прототипы экранов, диалогов и отчетов.
Фаза построения
На фазе построения выполняется собственно быстрая разработка приложения.
На данной фазе разработчики производят итеративное построение реальной системы
на основе полученных ранее моделей, а также требований нефункционального
характера. Разработка приложения ведется с использованием визуальных средств
программирования. Формирование программного кода частично выполняется с помощью
автоматических генераторов кода, входящих в состав CASE-средств. Код
генерируется на основе разработанных моделей.
На фазе построения также требуется участие пользователей системы, которые
оценивают получаемые результаты и вносят коррективы, если в процессе разработки
система перестает удовлетворять определенным ранее требованиям. Тестирование
системы осуществляется непосредственно в процессе разработки. После окончания
работ каждой отдельной команды разработчиков производится постепенная
интеграция данной части системы с остальными, формируется полный программный
код, выполняется тестирование совместной работы данной части приложения с
остальными, а затем тестирование системы в целом. Завершается физическое
проектирование системы, а именно:
· определяется необходимость распределения данных;
· производится анализ использования данных;
· производится физическое проектирование базы данных;
· определяются требования к аппаратным ресурсам;
· определяются способы увеличения производительности;
· завершается разработка документации проекта.
Результатом данной фазы является готовая информационная система,
удовлетворяющая всем требованиям пользователей.
Фаза внедрения
Фаза внедрения в основном сводится к обучению пользователей разработанной
информационной системы. Так как фаза построения достаточно непродолжительна,
планирование и подготовка к внедрению должны начинаться заранее, еще на этапе
проектирования системы.
Приведенная схема разработки информационной системы не является
универсальной. Вполне возможны различные отклонения от нее. Это связано с
зависимостью схемы выполнения проекта от начальных условий, при которых
начинается разработка (например, разрабатывается совершенно новая система или на
предприятии уже существует некоторая информационная система). Во втором случае
существующая система может либо использоваться в качестве прототипа новой
системы, либо интегрироваться в новую разработку в качестве одной из подсистем.
Ограничения методологии RAD
Несмотря на все свои достоинства, методология RAD тем не менее (как,
впрочем, и любая другая методология) не может претендовать на универсальность.
Ее применение наиболее эффективно при выполнении сравнительно небольших систем,
разрабатываемых для вполне определенного предприятия.
При разработке же типовых систем, не являющихся законченным продуктом, а
представляющих собой совокупность типовых элементов информационной системы,
большое значение имеют такие показатели проекта, как управляемость и качество,
которые могут войти в противоречие с простотой и скоростью разработки. Это
связано с тем, что типовые системы обычно централизованно сопровождаются и
могут быть адаптированы к различным программно-аппаратным платформам, системам
управления базами данных, коммуникационным средствам, а также интегрироваться с
существующими разработками. Поэтому для такого рода проектов необходим высокий
уровень планирования и жесткая дисциплина проектирования, строгое следование
заранее разработанным протоколам и интерфейсам, что снижает скорость
разработки.
Методология RAD неприменима не только для создания типовых информационных
систем, но и для построения сложных расчетных программ, операционных систем или
программ управления сложными инженерно-техническими объектами программ,
требующих написания большого объема уникального кода. Методология RAD не может
быть использована для разработки приложений, в которых интерфейс пользователя
является вторичным, то есть отсутствует наглядное определение логики работы
системы. Примерами таких приложений могут служить приложения реального времени,
драйверы или службы. Совершенно неприемлема методология RAD для разработки
систем, от которых зависит безопасность людей, - например, систем управления
транспортом или атомных электростанций. Это обусловлено тем, что итеративный
подход, являющейся одной из основ RAD, предполагает, что первые версии системы
не будут полностью работоспособны, что в данном случае может привести к
серьезнейшим катастрофам.
Лекция 16. Стандарты и методики
Одним из важных условий эффективного использования информационных
технологий является внедрение корпоративных стандартов. Корпоративные стандарты
представляет собой соглашение о единых правилах организации технологии или
управления. При этом за основу корпоративных могут приниматься отраслевое,
национальные и даже международные стандарты.
Однако высокая динамика развития информационных технологий приводит к
быстрому устареванию существующих стандартов и методик разработки
информационных систем. Так, например, в связи со значительным прогрессом в
области программного обеспечения и средств вычислительной техники наблюдается
рост размеров и сложности информационных систем. При этом существенно меняются
требования как к основным функциям и сервисным возможностям систем, так и к
динамике изменения этих функций. В этих условиях применение классических
способов разработки и обеспечения качества информационных систем становиться
малоэффективным и не приводит к уровню качества, адекватному реальным
требованиям.
Полезны в этом отношении стандарты открытых систем (в первую очередь
стандарты на интерфейсы различных видов, включая лингвистические, и на
протоколы взаимодействия). Однако разработка систем в новых условиях требует
также новых методов проектирования и новой организации проектных работ.
Проектирование и методическая поддержка организации разработки информационных
систем (включая программное обеспечение (ПО), и базы данных (БД)) традиционно
поддерживаются многими стандартами и фирменными методиками. Вместе с тем известно,
что требуется адаптивное планирование разработки, в том числе в динамике
процесса ее выполнения. Одним из способов адаптивного проектирования является
разработка и применение профилей жизненного цикла информационных систем и
программного обеспечения. Корпоративные стандарты образуют целостную систему,
которая включает три вида стандартов:
· стандарты на продукты и услуги;
· стандарты на процессы и технологии;
· стандарты на формы коллективной деятельности, или
управленческие стандарты.
Виды стандартов
Существующие на сегодняшний день стандарты можно несколько условно
разделить на несколько групп по следующим признакам:
· по предмету стандартизации. К этой группе можно отнести функциональные
стандарты (стандарты на языки программирования, интерфейсы, протоколы) и
стандарты на организацию жизненного цикла создания и использования
информационных систем и программного обеспечения;
· по утверждающей организации. Здесь можно выделить официальные
международные, официальные национальные или национальные ведомственные
стандарты (например, ГОСТы, ANSI, IDEFO/i), стандарты международных
консорциумов и комитетов по стандартизации (например, консорциума OMG),
стандарты «де-факто» - официально никем не утвержденные, но фактически
действующие (например, стандартом «де-факто» долгое время были язык
взаимодействия с реляционными базами данных SQL и язык программирования С),
фирменные стандарты (например, Microsoft ODBC);
· по методическому источнику. К этой группе относятся
различного рода методические материалы ведущих фирм-разработчиков программного
обеспечения, фирм-консультантов, научных центров, консорциумов по
стандартизации.
Необходимо иметь в виду, что, хотя это и не очевидно, в каждую из
указанных выше групп и подгрупп входят стандарты, существенно различающиеся по
степени обязательности для различных организаций; конкретности и детализации
содержащихся требований; открытости и гибкости, а также адаптируемости к
конкретным условиям.
Ниже мы рассмотрим следующие стандарты и методики, касающиеся организации
жизненного цикла информационных систем и программного обеспечения:
· методика Oracle CDM (Custom Development Method) no разработке
прикладных информационных систем под заказ;
· международный стандарт ISO/IEC 12207:1995-08-01 на
организацию жизненного цикла продуктов программного обеспечения;
· отечественный комплекс стандартов ГОСТ 34.
Поскольку рассматриваемые стандарты представляют собой весьма объемные
документы, изложенные на десятках и даже сотнях страниц, то мы рассмотрим их
лишь на уровне общей структуры и основных особенностей.
Методика Oracle CDM
Одним из уже сложившихся направлений деятельности фирмы ORACLE стала
разработка методологических основ и производство инструментальных средств для
автоматизации процессов разработки сложных прикладных систем, ориентированных
на интенсивное использование баз данных. Методика Oracle CDM является развитием
давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве
Oracle CASE (в новых версиях - Designer/2000).
Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:
· методология структурного нисходящего проектирования, при которой
разработка прикладной системы представляется в виде последовательности четко
определенных этапов;
· поддержка всех этапов жизненного цикла прикладной системы,
начиная с самых общих описаний предметной области до получения и сопровождения
готового программного продукта;
· ориентация на реализацию приложений в архитектуре
клиент-сервер с использованием всех особенностей современных серверов баз
данных, включая декларативные ограничения целостности, хранимые процедуры,
триггеры баз данных, и с поддержкой в клиентской части всех современных
стандартов и требований к графическому интерфейсу конечного пользователя;
· наличие централизованной базы данных, репозитария, для хранения
спецификаций проекта прикладной системы на всех этапах ее разработки. Такой
репозитарий представляет собой базу данных специальной структуры, работающую
под управлением СУБД ORACLE;
· возможность одновременной работы с репозитарием многих
пользователей. Такой многопользовательский режим почти автоматически
обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение
проекта системы и управление одновременным доступом к нему всех участников
разработки поддерживают согласованность действий разработчиков и не допускают
ситуацию, когда каждый проектировщик или программист работает со своей версией
проекта и модифицирует ее независимо от других;
· автоматизация последовательного перехода от одного этапа
разработки к следующему. Для этого предусмотрены специальные утилиты, с помощью
которых можно по спецификациям концептуального уровня (модели предметной
области) автоматически получать первоначальный вариант спецификации уровня
проектирования (описание структуры базы данных и состава программных модулей,
чтобы на его основе после всех необходимых уточнений и дополнений автоматически
генерировать готовые к выполнению программы;
· автоматизация различных стандартных действий по
проектированию и реализации приложения: предусматривается генерация
многочисленных отчетов по содержимому репозитария, обеспечивающих полное
документирование текущей версии системы на всех этапах ее разработки; с помощью
специальных процедур предоставляется возможность проверки спецификаций на
полноту и непротиворечивость.
Общая структура
Жизненный цикл формируется из определенных этапов (фаз) проекта и
процессов, каждый из которых выполняется в течение нескольких этапов, Методика
Oracle CDM определяет следующие фазы жизненного цикла информационной системы:
· стратегия (определение требований);
· анализ (формулирование детальных требований к прикладной
системе);
· проектирование (преобразование требований в детальные
спецификации системы);
· реализация (написание и тестирование приложений);
· внедрение (установка новой прикладной системы, подготовка к
началу эксплуатации);
· эксплуатация (поддержка приложения и слежение за ним,
планирование будущих функциональных расширений).
Первый этап связан с моделированием и анализом процессов, описывающих
деятельность организации, технологические особенности работы. Целью является
построение моделей существующих процессов, выявление их недостатков и возможных
источников усовершенствования. Этот этап не является обязательным в случае,
когда существующая технология и организационные структуры четко определены,
хорошо понятны и не требуют дополнительного изучения и реорганизации.
На втором этапе разрабатываются детальные концептуальные модели
предметной области, описывающие информационные потребности организации,
особенности функционирования и т. п. Результатом являются модели двух типов:
· информационные, отражающие структуру и общие закономерности
предметной области;
· функциональные, описывающие особенности решаемых задач. На
третьей стадии (этапе проектирования) на основании концептуальных моделей
вырабатываются технические спецификации будущей прикладной системы -
определяются структура и состав базы данных, специфицируется набор программных
модулей. Первоначальный вариант проектных спецификаций может быть получен
автоматически с помощью специальных утилит па основании данных концептуальных
моделей. На этапе реализации создаются программы, отвечающие всем требованиям
проектных спецификаций.
Использование генераторов приложений, входящих в состав DESIGNER/2000,
позволяет полностью автоматизировать этот этап, существенно сократить сроки
разработки системы и повысить ее качество и надежность.
Методика Oracle CDM выделяет следующие процессы, протекающие на
протяжении жизненного цикла информационной системы;
· определение производственных требований;
· исследование существующих систем;
· определение технической архитектуры;
· проектирование и построение базы данных;
· проектирование и реализация модулей;
· конвертирование данных;
· документирование;
· тестирование;
· обучение;
· переход к новой системе;
· поддержка и сопровождение.
Процессы состоят из последовательностей задач, задачи разных процессов
взаимосвязаны с помощью явных ссылок.
Особенности методики Oracle CDM
Отметим основные особенности методики Oracle CDM, определяющие область ее
применения и присущие ей ограничения.
· Степень адаптивности CDM ограничивается тремя моделями
жизненного цикла:
o классическая - предусматривает все этапы;
o быстрая разработка - ориентированна на использование
инструментов
o моделирования и программирования Oracle;
o облегчённый подход - рекомендуется в случае малых проектов и
возможности быстро прототипировать приложения.
· Методика не предусматривает включение дополнительных задач, которые не
оговорены в CDM, и их привязку к остальным. Также исключено удаление задачи (и
порождаемых ею документов), не предусмотренное пи одной из трех моделей
жизненного цикла, и изменение последовательности выполнения задач по сравнению
с предложенной.
· Все модели жизненного цикла являются по сути каскадными. Даже
«облегченный подход», несмотря на итерационность выполнения действий по
прототипированию, сохраняет общий последовательный и детерминированный порядок
выполнения задач.
· Методика не является обязательной, но может считаться
фирменным стандартом. При формальном применений степень обязательности
полностью соответствует ограничениям возможностей адаптации.
· Прикладная система рассматривается в основном как
программно-техническая система - например, возможность выполнения
организационно-структурных преобразований, практически всегда происходящих при
переходе к новой информационной системе, в этой методике отсутствуют.
· CDM теснейшим образом опирается на использование
инструментария Oracle, несмотря на утверждения о простом приспособлении CDM к
проектам, в которых используется другой комплект инструментальных средств.
· Методика Oracle CDM представляет собой вполне конкретный
материал, детализированный до уровня заготовок проектных документов,
рассчитанных на прямое использование в проектах информационных систем с опорой
на инструментальные средства и СУБД фирмы Oracle.
Международный стандарт ISO/IEC 12207: 1995-08-01
Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным
техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7,
проектирование программного обеспечения».
По определению, ISO 12207 - базовый стандарт процессов жизненного цикла
ПО, ориентированный на различные виды ПО и типы проектов автоматизированных
систем, в которых ПО является одной из составных частей. Стандарт определяет
стратегию и общий порядок в создании и эксплуатации ПО, он охватывает жизненный
цикл от концептуализации идей до завершения проекта. Целесообразность
совместного использования стандартов на информационные системы и на ПО
обусловливается одним из положений ISO 12207, согласно которому процессы,
используемые во время жизненного цикла ПО, должны быть совместимы с процессами,
используемыми во время жизненного цикла автоматизированной системы.
Согласно ISO 12207, система - это объединение одного или нескольких
процессов, аппаратных средств, программного обеспечения, оборудования и людей
для обеспечения возможности удовлетворения определенных потребностей или целей.
В отличие от Oracle COM стандарт ISO 12207 в равной степени ориентирован
на организацию действий каждой из двух сторон: поставщика (разработчика) и
покупателя (пользователя); он может быть применен и в том случае, когда обе
стороны - из одной организации.
Общая структура
В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий)
жизненного цикла информационной системы. Данный стандарт определяет лишь ряд
процессов, причем по сравнению с Oracle CDM стандарт ISO 12207 состоит из
гораздо более крупных обобщенных процессов: приобретение, поставка, разработка
и т. п. Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоставим
со всеми процессами Oracle CDM вместе взятыми.
Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а
каждое действие - на ряд задач.
Очень важной особенностью ISO 12207 по сравнению с CDM является то, что
каждый процесс, действие или задача инициируются и выполняются другим процессом
по мере необходимости, причем нет заранее определенных последовательностей
(естественно, при сохранении логики связей по исходным сведениям задач и т.
п.).
Основные и вспомогательные процессы жизненного цикла.
В стандарте ISO 12207 описаны пять основных процессов жизненного цикла
программного обеспечения:
· процесс приобретения определяет действия
предприятия-покупателя, которое приобретает информационную систему, программный
продукт или службу программного обеспечения;
· процесс поставки определяет действия предприятия-поставщика,
которое снабжает покупателя системой, программным продуктом или службой
программного обеспечения;
· процесс разработки определяет действия
предприятия-разработчика, которое разрабатывает принцип построения программного
изделия и программный продукт;
· процесс функционирования определяет действия
предприятия-оператора, которое обеспечивает обслуживание системы в целом (а не
только программного обеспечения) в процессе ее функционирования в интересах
пользователей. В отличие от действий, которые определяются разработчиком в
инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во
всех трех рассматриваемых стандартах), определяются действия оператора по
консультированию пользователей, получению обратной связи и др., которые он
планирует сам и берет на себя соответствующие обязанности;
· процесс сопровождения определяет действия персонала,
обеспечивающего сопровождение программного продукта, то есть управление
модификациями программного продукта, поддержку его текущего состояния и
функциональной пригодности; сюда же относятся установка программного изделия на
вычислительной системе и его удаление.
Кроме основных, стандарт ISO 12207 оговаривает 8 вспомогательных
процессов, которые являются неотъемлемой частью всего жизненного цикла
программного изделия и обеспечивают должное качество проекта программного
обеспечения.
К вспомогательным процессам относятся:
· процесс решения проблем;
· процесс документирования;
· процесс управления конфигурацией;
· процесс обеспечения качества;
· процесс верификации;
· процесс аттестации;
· процесс совместной оценки;
· процесс аудита.
В стандарте ISO 12207 также определяются четыре организационных процесса:
· процесс управления;
· процесс создания инфраструктуры;
· процесс усовершенствования;
· процесс обучения.
Под процессом усовершенствования в стандарте ISO 12207 понимается не
усовершенствование информационной системы или программного обеспечения, а улучшение
самих процессов приобретения, разработки, обеспечения качества и т. д., реально
осуществляемых в организации.
И наконец, в стандарте ISO 12207 определен один особый процесс,
называемый процессом адаптации, который определяет основные действия, необходимые
для адаптации этого стандарта к условиям конкретного проекта.
Особенности стандарта ISO 12207
Все сказанное выше позволяет сформулировать следующие особенности
стандарта ISO 12207.
· Стандарт ISO 12207 имеет динамический характер, обусловленный
способом определения последовательности выполнения процессов и задач, при
котором один процесс при необходимости вызывает другой или его часть. Такой
характер позволяет реализовать любую модель жизненного цикла.
Согласно стандарту ISO 12207, модель жизненного цикла - это структура,
содержащая процессы, действия и задачи, которые осуществляются в ходе
разработки, функционирования и сопровождения программного продукта в течение
всей жизни систеы, от определения требований до завершения ее использования.
· Стандарт ISO 12207 обеспечивает максимальную степень
адаптивности. Множество процессов и задач сконструировано так, что возможна их
адаптация в соответствии с конкретными проектами информационных систем. Эта
адаптация сводится к исключению процессов, видов деятельности и задач,
неприменимых в конкретном проекте.
Согласно ISO 12207, добавление уникальных или специфических процессов,
действий и задач должно быть оговорено в контракте между сторонами. Причем
«контракт» понимается в самом широком смысле - от юридически оформленного
документа до неформального соглашения. Это соглашение может быть определено
даже единственной стороной - как задача, поставленная самому себе.
· Стандарт принципиально не содержит описания конкретных
методов действий, а тем более - заготовок решений или документации. Он лишь
описывает архитектуру процессов жизненного цикла программного обеспечения, но
не конкретизирует в деталях, как реализовывать или выполнять услуги и задачи,
включённые в процессы. Данный стандарт не предписывает имена, форматы или
точное содержание получаемой документации. Решения такого типа принимаются
сторонами, использующими стандарт.
· Обеспечение качества разными процессами выполняется с разной
предусмотренной степенью организационной независимости контролирующей деятельности
вплоть до обязательных требований к полной независимости проверяющею персонала
от какой-либо прямой ответственности за проверяемые объекты. В отличие от CDM
контроль этого вида предусмотрен на самых ранних шагах разработки, начиная с
анализа системных требований посредством их проверок на соответствие
потребностям приобретения.
· Степень обязательности рассматриваемого стандарта следующая:
после решения организации о применении ISO 12207 в качестве условия торговых
отношений является ее ответственность за указание минимального набора требуемых
процессов и задач, которые обеспечивают согласованность с этим стандартом.
· Стандарт содержит предельно мало описаний, направленных на
проектирование базы данных. Это можно считать оправданным, так как разные
системы и разные прикладные комплексы программного обеспечения могут не только
использовать весьма специфические типы баз данных, но и вообще не использовать
базу данных.
Ценность стандарта ISO 12207 в том, что он содержит наборы задач,
характеристик качества, критериев оценки и т. п., дающие всесторонний охват
проектных ситуаций. Например, при выполнении анализа требований к системе
предусматривается, что:
· рассматривается область применения системы для определения
требований, предъявляемых к системе;
· спецификация требований системы должна описывать функции и
возможности системы, области применения системы, организационные требования и
требования пользователя, безопасность, защищенность, человеческие факторы,
эргономику, связи, операции и требования сопровождения; проектные ограничения и
квалификационные требования,
Далее, при выполнении анализа требований к программному обеспечению
предусмотрено 11 классов характеристик качества, которые используются позже при
обеспечении качества.
При этом разработчик должен установить и документировать в виде
требований к программному обеспечению следующие спецификации и характеристики:
· функциональные и возможные спецификации, включая исполнение,
физические характеристики и условия среды эксплуатации, при которых единица
программного обеспечения должна быть выполнена;
· внешние связи (интерфейсы) с единицей программного
обеспечения;
· требования квалификации;
· спецификации надежности, включая спецификации, связанные с
методами функционирования и сопровождения, воздействия окружающей среды и
вероятностью травмы персонала;
· спецификации защищенности, включая спецификации, связанные с
компрометацией точности информации;
· человеческие факторы спецификаций по инженерной психологии
(эргономике), включая связанные с ручным управлением, взаимодействием человека
и оборудования, ограничениями на персонал и областями, нуждающимися в
концентрированном человеческом внимании, которые являются чувствительными к
ошибкам человека и обучению;
· определение данных и требований к базе данных;
· установочные и приемочные требования поставляемого
программного продукта в местах функционирования и сопровождения (эксплуатации);
· документацию пользователя;
· работа пользователя и требования выполнения;
· требования сервиса пользователя.
Согласно стандарту IS012207, требование квалификации - это набор
критериев или условий (квалификационные требования), которые должны быть
удовлетворены для того, чтобы квалифицировать программный продукт как
подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для
использования в целевой окружающей среде.
Хотя стандарт не предписывает конкретной модели жизненного цикла или
метода разработки, он определяет, что стороны-участники при использовании
стандарта ответственны за следующее:
· выбор модели жизненного цикла для разрабатываемого проекта;
· адаптацию процессов и задач стандарта к этой модели;
· выбор и применение методов разработки программного
обеспечения;
· выполнение действий и задач, подходящих для проекта
программного обеспечения.
Стандарты комплекса ГОСТ 34
ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс
взаимосвязанных межотраслевых документов. Объектами стандартизации являются
автоматизированные системы различных видов и все виды их компонентов, а не
только программное обеспечение и базы данных.
Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично
ISO 12207, в нем предусмотрено, что заказчик может разрабатывать
автоматизированную систему для себя сам (например, создав для этого
специализированное подразделение). Однако формулировки ГОСТ 34 не ориентированы
на столь явное и в известном смысле симметричное отражение действий обеих
сторон, как это сделано в ISO 12207. Поскольку ГОСТ 34 в основном уделяет
внимание содержанию проектных документов, распределение действий между
сторонами обычно производится исходя из этого содержания.
Общая структура
Из всех существующих групп документов будем основываться только на группе
0 "Общие положения" и группе 6 «Создание, функционирование и развитие
автоматизированной системы». Наиболее популярными можно считать стандарты ГОСТ
34.601-90 (стадии создания автоматизированной системы), ГОСТ 34.602-89
(техническое задание на создание автоматизированной системы) и методические
указания РД 50-34.698-90 (требования к содержанию документов). Стандарты
предусматривают стадии и этапы выполнения работ по созданию автоматизированной
системы, но не предусматривают сквозных процессов в явном виде.
Согласно ГОСТ 34, разработка автоматизированной системы разбивается на
следующие этапы и стадии.
· Этап формирования требований к автоматизированной системе.
Состоит из следующих стадий:
o обследование объекта и обоснование необходимости разработки
автоматизированной системы;
o формирование требований заказчика к автоматизированной системе;
o разработка отчета о проделанной работе и заявки на разработку
технического задания.
· Разработка концепции:
o изучение объекта;
o проведение необходимых научно-исследовательских работ;
o разработка вариантов концепции автоматизированной системы,
удовлетворяющей требованиям заказчика;
o разработка отчета о проделанной работе.
· Разработка и утверждение технического задания на разработку
автоматизированной системы.
· Разработка эскизного проекта автоматизированной системы:
o разработка предварительных проектных решений по всей системе
в целом и по ее отдельным составляющим;
o разработка документации.
· Разработка технического проекта:
o разработка проектных решений по всей системе и по ее частям;
o разработка документации на автоматизированную систему и на
подсистемы, входящие в ее состав;
o разработка и оформление документации на поставку изделий для
комплектования автоматизированной системы и/или технических требований на их
разработку;
o разработка заданий на проектирование в смежных частях проекта
объекта автоматизации.
· Разработка технической документации:
o разработка рабочей документации на систему и ее части;
o разработка и/или адаптация программного обеспечения.
· Ввод разработанной системы в действие:
o подготовка объекта автоматизации;
o подготовка персонала;
o комплектация автоматизированной системы программными и
техническими средствами;
o монтажные работы;
o пуско-наладочные работы;
o предварительные испытания;
o опытная эксплуатация;
o приемочные испытания.
· Сопровождение:
o выполнение работ в соответствии с гарантийными
обязательствами;
o послегарантийное обслуживание.
В ГОСТ 34 приводится описание содержания документов, разрабатываемых на
каждом из этапов.
Особенности
Основными особенностями комплекса стандартов ГОСТ 34 являются следующие:
· Основной целью разработки комплекса нормативных документов ГОСТ 34 было
разрешение противоречий, возникающих при интеграции систем вследствие
несогласованности нормативно-технической документации. Комплекс стандартов ГОСТ
34 более близок к схемам конкретных методик, чем к стандартам типа ISO 12207.
· Степень адаптивности стандарта ГОСТ 34 определяется
следующими возможностями:
o возможностью отказаться от этапа эскизного проектирования и
объединять
o этапы разработки технического проекта и рабочей документации;
o возможностью отказываться от некоторых стадий разработки, а
также объединять большинство документов и их разделов;
o возможностью вводить дополнительные документы, разделы
документов и работы;
o возможностью динамически создавать частные технические
задания, что позволяет достаточно гибко формировать жизненный цикл
автоматизированной системы.
o Стадии и этапы, выполняемые организациями - участниками работ
по созданию автоматизированной системы, устанавливаются в договорах и
техническом задании, что близко к подходу ISO 12207.
· Несмотря на достаточно большую гибкость формирования жизненного цикла,
предопределенные документами ГОСТ 34 этапы и стадии разработки на практике
ориентируют разработчиков на каскадную схему жизненного цикла.
· Документы ГОСТ 34 определяют единую терминологию и вполне
разумно классифицируют работы по созданию автоматизированной системы и
документы, разрабатываемые в результате этих работ. Благодаря ГОСТ 34
упрощается интеграция разных систем и повышается качество систем, полученных в
результате интеграции.
· Обеспечение качества согласно ГОСТ 34 определяется в
техническом задании на автоматизированную систему и производится на любых
последующих этапах и с любой степенью независимости экспертизы. В
последовательности этапов разработки эти экспертизы располагаются несколько
позже, чем в ISO 12207.
· Степень обязательности ГОСТ 34: полная обязательность
отсутствует, материалы ГОСТ 34, по сути, являются методической поддержкой.
Причем эта поддержка в значительной степени ориентирована на заказчика: в
стандарте имеется набор требований к содержанию технического задания и
проведению испытаний разработанной системы.
· Ключевым документом взаимодействия сторон является
техническое задание (ТЗ) на создание автоматизированной системы. ТЗ является
основным исходным документом для создания автоматизированной системы нее
приемки, оно определяет важнейшие точки взаимодействия заказчика и
разработчика.
Техническое Задание Разрабатывается Организацией-Разработчиком (По Гост
34.602-89); Но Формально Техническое Задание Выдает Разработчику Заказчик (По
Рд 50-680-88).
Согласно ГОСТ 34, автоматизированная система состоит из
программно-технических, программно-методических комплексов и отдельных
компонентов организационного, технического, программного и информационного
обеспечения. Документы комплекса ГОСТ 34 определяют автоматизированную систему
следующим образом:
· «организационно-техническая система, обеспечивающая выработку
решений на основе автоматизации информационных процессов в различных сферах деятельности
(управление, проектирование, производство и т. д.) или их сочетаниях» - РД
50-680-88;
· «система, состоящая из персонала и комплекса средств
автоматизации его деятельности, реализующая информационную технологию
выполнения установленных функций» - ГОСТ 34.003-90.
Таким образом, автоматизированная система рассматривается в первую
очередь как персонал, принимающий решения и выполняющий другие управляющие
действия, поддержанный организационно-техническими средствами.
Выводы
· Ни один из рассмотренных стандартов не является
универсальным, описывающим все виды действий и задач; выполняемых в конкретных
проектах. Такая ситуация, вероятно, объективно неизбежна для любых достаточно
конкретных стандартов и фирменных методик.
· Наиболее широкий набор процессов, действий и задач,
охватывающий большинство возможных ситуаций при максимальной адаптируемости,
содержится в стандарте ISO 12207. Он может служить примером хорошо
организованного стандарта, содержащего минимум ограничений и конкретных
рекомендаций. При использовании ISO 12207 детальные определения процессов, форм
документов и т. п. целесообразно выносить в различные функциональные стандарты,
ведомственные нормативные документы или фирменные методики, которые могут быть
использованы или не использованы в каждом конкретном проекте.
· ГОСТ 34 достаточно полно и фундаментально определяет.
ü систему как объект создания или развития;
ü аналитические и при необходимости исследовательские работы,
направленные на разработку обоснованной концепции автоматизированной системы;
ü виды обеспечения системы, которые, в общем, согласуются с
требованиями ISO 12207 к системе и программному обеспечению.
Материалы ГОСТ 34 почти так же, как и ISO 12207, а может быть, еще более
четко определяют, что автоматизированная система - это в первую очередь люди,
которые выполняют свои функции с помощью информационных технологий.
· ГОСТ 34 благодаря своей комплексной ориентации на систему и
обеспечению единой терминологии позволяет избежать ситуаций, в которых
разработчики разных профессий (например, финансовые аналитики и проектировщики
баз данных) «говорят на разных языках», от чего в итоге страдают цельность и
глубина проработки проекта.
· ГОСТ-34 и CDM в первую очередь ориентированы на действия по
созданию и поддержке систем ISO 12207 - на приобретение и эксплуатацию систем
(при этом разработка является процессом, логически вытекающим из приобретения).