74511

ПРОЕКТИРОВАНИЕ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Лекция

Информатика, кибернетика и программирование

Более подробно жизненный цикл КИС корпоративной информационной системы можно представить следующим образом: Этап анализа на котором происходит сбор предложений требований пожеланий аналогий фактов примеров эскизов сценариев и т. Этап управления вариантами системы необходим чтобы не утонуть в накапливаемом аналитическом материале. Этап конструирования знаменуют собой начало синтеза первых очертаний системы. Здесь происходит разработка вариантов архитектуры системы концептуальных моделей системы диаграмм взаимодействия подсистем...

Русский

2015-01-04

192.5 KB

9 чел.

PAGE  19

ПРОЕКТИРОВАНИЕ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

1. Жизненный цикл КИС. Модели жизненного цикла КИС.

2. Каноническое и индустриальное проектирование КИС. Этапы проектирования КИС.

3. Реинжиниринг бизнес-процессов.

4. Стандарты и методики реинжиниринга бизнес-процессов.

5. Оценка эффективности внедрения информационных систем.

1. Жизненный цикл КИС. Модели жизненного цикла КИС

Кратко жизненный цикл (ЖЦ) КИС можно условно разделить на шесть этапов:

  •  выбор;
  •  приобретение;
  •  внедрение;
  •  эксплуатация;
  •  усовершенствование;
  •  замена на новую.

Более подробно жизненный цикл КИС (корпоративной информационной системы) можно представить следующим образом:

  1.  Этап анализа, на котором происходит сбор предложений, требований, пожеланий, аналогий, фактов, примеров, эскизов, сценариев и т.п.
  2.  Этап управления вариантами системы необходим, чтобы не утонуть в накапливаемом аналитическом материале. Требования разбиваются на группы по важности, срочности, трудоемкости и т.д. - в зависимости конкретной ситуации количество групп может меняться, и эти изменения так же управляются на этом этапе.
  3.  Этап конструирования знаменуют собой начало синтеза первых очертаний системы. Здесь происходит разработка вариантов архитектуры системы, концептуальных моделей системы, диаграмм взаимодействия подсистем, блоков и модулей и т.п.
  4.  Этап управления выпусками вариантов системы включает в себя работы по определению последовательности наполнения системы функциональностью на уровне разработанных на этапе конструирования элементов системы.
  5.  Этап проектирования - предназначен для разработки структур метаданных различных модулей, блоков и подсистем и алгоритмов их взаимодействия между собой
  6.  Этап управления сборками выпусков вариантов системы дает возможность определить, что именно нужно включить в работающую систему, какие объекты проработаны достаточно детально, чтобы их реализовать и предоставить для эксплуатации
  7.  Этап реализации заключается в разработке объектов метаданных и алгоритмов их действия, кодировании в различных платформах, тестировании работы объектов, документировании различных аспектов работы реализованных объектов, касающихся использования, администрирования и описания примененных технических приемов реализации
  8.  Этап управление редакциями сборок системы представляет собой определение конкретного наполнения предоставляемой пользователю работающей системы. Иначе говоря, включение, обновление и исключение различных редакций структуры, описаний и исходного кода объектов в/из сборки системы. А, кроме того, подготовка презентаций и демонстрационных материалов, определение актуального состояния документации различных уровней, наиболее точно соответствующей текущему состоянию предоставленной пользователям системы
  9.  Этап презентаций и демонстраций заказчикам и пользователям системы предполагает первый показ работоспособности измененных частей системы, а также оформление протоколов презентаций и демонстраций, оформление актов по замечаниям и предложениям пользователей.
  10.  Этап обучения пользователей включает в себя подготовку планов обучения, материалов, необходимых для обучения, собственно обучение и проверку усвоения знаний и навыков владения системой пользователями.
  11.  И, наконец, этап управления изменениями в системе, включает в себя администрирование, ввод в эксплуатацию новых и измененных объектов системы, вывод из эксплуатации устаревших и замененных объектов системы, в которой непосредственно работают пользователи.

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

Жизненный цикл программного обеспечения – период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы:

  •  возникновение и исследование идеи;
  •  анализ требований и проектирование;
  •  программирование;
  •  тестирование и отладка;
  •  ввод программы в действие;
  •  эксплуатация и сопровождение;
  •  завершение эксплуатации.


2. Каноническое и индустриальное проектирование КИС. Этапы проектирования КИС.

  •  Основные фазы проектирования ИС (КИС):
  •  Формирование концепции 
  •  Разработка технического задания 
  •  Проектирование 
  •  Реализация 
  •  Ввод в эксплуатацию 

Формирование концепции

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

Разработка технического задания

  •  разработка основного содержания;
  •  разработка базовой структуры;
  •  планирование декомпозиции;
  •  составление сметы;
  •  составление бюджета;
  •  разработка календарных планов;
  •  разработка графика работ;
  •  подписание контракта.

Проектирование

  •  базовые проектные работы;
  •  частные технические задания;
  •  технические спецификации;
  •  технические инструкции;
  •  представление разработки;
  •  экспертиза разработки;
  •  утверждение разработки.

Реализация

  •  разработка ПО;
  •  подготовка к внедрению;
  •  контроль и регулирование основных показателей проекта;
  •  объединение подсистем.

Ввод в эксплуатацию

  •  комплексные испытания;
  •  подготовка кадров для эксплуатации;
  •  подготовка документации;
  •  сдача заказчику;
  •  ввод в эксплуатацию;
  •  сопровождение системы;
  •  поддержка;
  •  сервисное обслуживание.

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

Не смотря на то, что большинство крупных промышленных предприятий в последние годы произвели значительные инвестиции в область построения собственных корпоративных информационных систем (КИС), задача построения КИС, соответствующей потребностям управленческого аппарата, остается актуальной. Проекты построения КИС на базе ERP-систем, требуют значительных ресурсов, не редко выходят за рамки планируемых сроков и бюджета, а реализованная в КИС функциональность по ряду параметров не всегда соответствует ожиданиям пользователей.

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

Типичные проблемы информационных систем предприятий:

  •  В эксплуатации находится большое количество не связанных или слабо информационно связанных АРМов;

  •  Отсутствуют централизованно ведущиеся справочники: договоров, контрагентов, материалов и комплектующих, затрат, др.;

  •  Не определены общие подходы к интеграции информационных систем на корпоративном и цеховом уровнях;

  •  Отсутствуют приоритеты развития, нет плана и этапов развития КИС;

  •  Неоднородность состава технических средств и программного обеспечения;

  •  Незаконченность проектов внедрения модулей и подсистем КИС;

  •  Недостаточное финансирование программ внедрения модулей и подсистем КИС.

Проблемы IT-проектов

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

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

  1.  Соответствие функциональности КИС потребностям бизнеса и Руководства предприятия.

  1.  Управление рамками проекта (сроки, бюджет, состав работ). IT-проекты склонны к разбуханию и расползанию. Это происходит по разным причинам, среди которых могут быть:
  •  изменение организационной структуры и бизнес-процессов предприятия,
  •  отсутствие детального проекта КИС,
  •  неконтролируемый поток требований в ходе проекта со стороны заказчика,
  •  изменение проектных решений разработчиками системы в ходе ее реализации,
  •  отсутствие типизации проектных решений и т.д.

  1.  Взаимодействие различных групп участников IT-проекта. В крупном IT-проекте может принимать участие до нескольких сотен человек. Условно их можно разделить на несколько групп: разработчики КИС, аналитики и методологи, функциональные специалисты заказчика, специалисты по обучению и сопровождению КИС и т.д. Каждая группа является носителем определенной категории знаний и выполняет определенные роли в проекте. В силу различного профессионального опыта, терминологического базиса, возложенных функциональных задач, общение между представителями различных групп часто вызывает проблемы и может приводить к конфликтным ситуациям.

  1.  Объективный мониторинг текущего состояния проекта. На практике, Руководство IT-проекта, часто не имеет эффективных средств доступа к объективной (свободной от частных точек зрения подчиненных, полной и достоверной) информации о текущем состоянии проекта. Это, в свою очередь, препятствует формированию своевременных и оптимальных управленческих воздействий на проект.

  1.  Ведение проектной документации. На многих IT-проектах предъявляются низкие требования к ведению проектной документации. Это негативно сказывается на этапах сопровождения и развития КИС, обучении конечных пользователей, приводит к смене участников проектной команды.

Предложенный список проблем не претендует на абсолютную полноту. На IT-проект влияют многие другие факторы, например, состав и квалификация участников проекта, функциональные ограничения типовых решений КИС и т.д.

Основные принципы построения КИС предприятий:

  •  Процессно-ориентированный подход к проектированию подсистем КИС;

  •  Централизация управления и финансирования проектом;

  •  Этапность и пилотная фаза проекта;

  •  Методы проектирования, основанные на системном анализе и моделировании;

  •  Масштабируемость и тиражирование технических решений;

  •  Использование современных типов информационных систем;

  •  Обеспечение информационной безопасности.

Системный подход к ведению и управлению IT-проектом позволяет:

  •  Повысить качество проектирования, обеспечить ориентацию КИС на достижение бизнес целей, через решение бизнес задач автоматизируемого предприятия;

  •  Повысить эффективность планирования и контроля над процессом выполнения КИС и использования ресурсов проекта;

  •  Повысить обоснованность принимаемых проектных решений и затраченных на реализацию КИС средств;

  •  Повысить эффективность взаимодействия различных групп и отдельных участников проекта;

  •  Снизить общие риски по проекту;

  •  Обеспечить на регулярной основе документирование результатов работы разработчиков КИС;

  •  Ускорить процесс обучения и вхождения в проект новых специалистов предприятия;

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

В работах [2,3] в качестве основного каркаса, объединяющего и систематизирующего все знания по IT-проекту, предлагают использовать референтную модель. Референтная модель, по мнению авторов, не только обеспечивает эффективный доступ ко всем знаниям по IT-проекту, но и служит инструментом управления IT-проектом на всех фазах проекта.

Референтная модель бизнес-процесса представляет собой совокупность логически взаимосвязанных его (бизнес-процесса) функций [2,3]. Для каждой функции указывается исполнитель, входные и выходные документы или информационные объекты. Элементы (функции и документы) референтной модели бизнес процесса содержат ссылки на соответствующие объекты КИС, а также документы и другую информацию (пользовательские инструкции, ответственных разработчиков) расположенную в репозитарии проекта. Отсюда и название - референтная модель (в переводе с английского ссылочная модель).

Фаза проектирования:

  •  Разработка и согласование референтной модели;

  •  Автоматизированное формирование по референтной модели Системного проекта информационной системы, структуры типовых рабочих мест и информационных потребностей участников бизнес процессов;

  •  Занесение в модель информации об ответственных лицах и плановых сроках для фаз реализации и ввода в эксплуатацию;

  •  Автоматизированное формирование по референтной модели базы планирования работ для фаз реализации, тестирования и ввода в эксплуатацию.

  •  Фазы реализация и тестирование:

  •  Автоматизированное формирование по референтной модели детального плана работ на фазы реализация и тестирование;

  •  Занесение в референтную модель информации о ходе выполнения работ по разработке и настройке модулей КИС;

  •  Контроль над процессом реализации КИС на основе отчетов из референтной модели;

  •  Привязка к функциям референтной модели документов, объектов, типовых ролей участников бизнес-процессов, актов тестирования реализованных в прототипе КИС бизнес-процессов, пользовательских инструкций и технической документации;

  •  Анализ информационной потребности и нормативно-справочной информации бизнес-процессов;

  •  Уточнение референтной модели по результатам выполнения работ фазы реализации.

Фаза ввода в эксплуатацию:

  •  Автоматизированное формирование по референтной модели детального плана работ на фазу ввода в опытную эксплуатацию;

  •  Автоматическое формирование технологических карт выполнения бизнес процессов с использованием КИС;

  •  Занесение в референтную модель информации о ходе выполнения работ по созданию КИС;

  •  Контроль над процессом ввода в опытную эксплуатацию КИС на основе отчетов по референтной модели;

  •  Привязка к функциям референтной модели актов о вводе в эксплуатацию и об обучении конечных пользователей;
  •  Использование референтной модели для обучения конечных пользователей и разработки методик и регламентов работы с КИС;

  •  Использование референтной модели группой сопровождения КИС.

Планирование развития КИС:

  •  Планирование работ по достижению бизнес целей предприятия путем внедрения функциональности КИС;

  •  Согласование проектных решений по развитию КИС;

  •  Контроль над процессом развития КИС на основе отчетов по референтной модели;

  •  Использование референтной модели для адаптации IT-решений в случае изменения условий ведения бизнеса;

  •  Референтная модель используются для тиражирования модулей и технических решений КИС, например, в дочерние предприятия.

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

 Итак, что необходимо:

  •  Всевозможное оборудование и документация на него
  •  Системное программное обеспечение, с документацией (так и хочется сказать - с супругой)
  •  Описание бизнес-процессов в виде регламентов взаимодействия пользователей с объектами КИС
  •  Технические задания на систему
  •  Тестовые примеры
  •  Конструкторская документация
  •  Проектная документация
  •  Исходные коды системы
  •  Описания структуры баз данных системы
    Шаблоны баз данных системы
  •  Исполняемые модули системы
  •  Документация пользователя
  •  Документация системного администратора
  •  Документация администратора баз данных
    Документация администратора системы
  •  Документация демонстратора
  •  Документация преподавателя
  •  Документация прикладного программиста
  •  Документация системного программиста
  •  Пакеты презентаций и материалы демонстраций для заказчиков и пользователей
  •  Планы демонстраций и испытаний
  •  Протоколы демонстраций и испытаний
  •  Результаты тестирования
  •  Акты устранения замечаний


4. Стандарты и методики реинжиниринга бизнес-процессов

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

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

В России разработка и испытания автоматизированных систем (АС), в частности ПС, регламентированы ГОСТ 34.601--90. Стадии создания АС, ГОСТ 34.602--89. ТЗ на создание АС, ГОСТ 34.603--92. Виды испытаний АС. Однако создание, сопровождение и развитие прикладных ПС для нынешних информационных систем в этих стандартах отражены недостаточно, а отдельные их положения устарели с точки зрения построения современных распределенных комплексов прикладных программ высокого качества в системах управления и обработки данных с различной архитектурой. Поэтому целесообразно выбирать и использовать апробированные зарубежные стандарты в этой области. Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информации и управления в реальном времени. К таким ПС предъявляются наиболее высокие требования по качеству функционирования, они создаются большими коллективами специалистов в течение длительного времени [3, 4]. Представленные ниже шесть стандартов ЖЦ ПС отличаются по структуре, терминологии и графическому представлению этапов и их взаимодействию. В большинстве стандартов детализация ЖЦ ПС ограничивается 8--10 крупными этапами или процессами. Для практического применения стандартов при реальном планировании и управлении проектами необходима более подробная информация о содержании процессов. В подобных руководствах должны быть представлены исходные данные, содержание частных работ и ожидаемые результаты, а также структура и содержание документов, сопутствующих их реализации. Обычно такая детализация на 50--100 частных процессов производится в фирменных инструкциях и руководящих документах при формировании технологии и комплекса инструментальных средств поддержки разработки, сопровождения и эксплуатации конкретных ПС.

Содержание стандартов, регламентирующих ЖЦ ПС. Впервые формализованный и утвержденный стандарт жизненного цикла был утвержден в 1985 г. (уточнен в 1988 г.) для проектирования ПС систем военного назначения по заказам Министерства обороны США - стандарт DOD-STD-2167 А. Этим документом регламентированы 8 фаз (этапов) при создании сложных критических ПС и около 250 типовых обязательных требований к процессам и объектам проектирования на этих этапах.

ПС рассматриваются как часть специализированных информационных систем военного назначения. Поэтому начальные этапы проектирования и заключительные этапы испытаний и сдачи заказчику объединены в совместный анализ программных и аппаратных средств цельной системы вооружения, полностью решающей поставленные функциональные задачи. В стандарте DOD представлена часть ЖЦ ПС, отражающая только непосредственно создание программ. Отсутствуют этапы эксплуатации и сопровождения, а также не полностью раскрыты процессы управления разработкой и интегральные процессы технологической поддержки ЖЦ ПС.

В начале стандарта DOD-STD-2167 A определена область его действия и общие условия применения. Приведены базовый перечень ссылочных документов и определения понятий, терминов и аббревиатур. Основная совокупность требований изложена в двух крупных разделах: наиболее общие требования ко всему процессу создания ПС и детальные требования к каждому его этапу.

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

Детальные требования распределены по восьми этапам разработки. В этом стандарте после того, как сформулированы концепция и общие требования к системе (этап 1), выделяются и детализируются требования к ПС (этап 2). Далее начинается собственно процесс создания программ (этапы 3--6). Названия, последовательность и содержание этапов предварительного (этап 3) и детального (этап 4) проектирования, а также разработки компонентов (этап 5) и их интеграции (комплексирования) и тестирования (этап 6) достаточно близки к соответствующим процессам в стандартах ISO (см. ниже). По окончании этапов 3--6 проводятся тестирование ПС на реализующей (объектной) ЭВМ (этап 7), интегрирование и испытание ПС в составе системы (этап 8). Для всех этапов детальные требования имеют одинаковую структуру разделов. В них для каждого этапа конкретизируются разделы общих требований и отражены требования к управлению проектом, технологии, официальным квалификационным испытаниям, оценке качества программной продукции и к конфигурационному управлению.

Весь процесс создания ПС поддерживается комплектом из 30 частных документов и 7 сводных отчетов (обзоров) по этапам. Наиболее полно раскрыты этапы предварительного (эскизного) и детального (технического) проектирования, каждый из которых состоит из 6--7 процессов. В результате представленную схему можно использовать как базу для планирования, организации и автоматизации процессов разработки критических ПС. Для замены стандартов DOD-STD-2167 A, 7935 A, 1703 Министерством обороны США в декабре 1994 г. утвержден Военный стандарт MIL-STD-498. Разработка и документирование программного обеспечения. Он предназначен для применения всеми организациями и предприятиями, получающими заказы Министерства обороны США. Этот стандарт базируется на процессах и документах, представленных в стандарте ISO 12207 и предшествующих военных стандартах. Общая структура стандарта близка к структуре DOD-STD-2167 A, однако детальные требования пятого раздела изложены значительно глубже и шире в 19 подразделах. Кроме того, число приложений увеличено до девяти. В 1996 г. утверждено очень подробное (407 стр.) руководство "Применение и рекомендации к стандарту MIL-STD-498". Основную часть пятого раздела составляют 75 подразделов - рекомендаций по обеспечению и реализации процессов ЖЦ сложных критических ПС высокого качества и надежности, функционирующих в реальном времени.

Наиболее полно и подробно ЖЦ, технология создания и обеспечения качества сложных ПС отражены в двух представленных ниже стандартах ISO. Стандарт ISO 12207:1995. Процессы жизненного цикла программных средств. Регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах: -- основы жизненного цикла ПС и определяющие работы;

  •  процессы, поддерживающие жизненный цикл ПС;
  •  организация и управление жизненным циклом ПС.

Стандарт состоит из семи разделов и четырех приложений. Разделы 1-4 являются вводными. В первом разделе сформулированы цели стандарта, области его применения, подчеркнуты его гибкость и ограничения при использовании. Во втором приведены нормативные ссылки на некоторые общие стандарты, поддерживающие разработку и качество ПС и их компонентов, а также терминологию. В третьем даны основные термины. Общая структура пятого - седьмого разделов и их краткое содержание изложены в четвертом разделе. В стандарте расшифровано свыше 220 работ и комментариев к ним. Основные этапы подготовки, эксплуатации и сопровождения ПС изложены в пятом разделе. Приобретение или подготовка к созданию ПС (подраздел 5.1) включает 23 вида работ и начинается с инициализации проекта, анализа концепции и рынка аналогичных продуктов, выработки требований и состава поддерживающих документов, создания предварительного плана действий. Далее анализируются предложения возможных исполнителей и подготавливается проект контракта. Организуется отслеживание проекта, его приемка и завершение. В подразделе 5.2. детализируются 23 процесса организации последующей подготовки к поставке ПС. Оцениваются отзывы фирм о проекте, заключается контракт, планируется ЖЦ, организуются поддержка разработки отчетами и обеспечение развития, а также процессы сдачи и завершения проекта. Основные 55 работ по созданию сложного комплекса программ представлены в подразделе 5.3. Подготовка проекта начинается с определения состава сопровождающих документов, выбора средств конфигурационного управления и обеспечения качества, а также выбора методов и средств технологического обеспечения всей ИС. Анализируются и формализуются функциональные, коммерческие, пользовательские, системные требования и критерии качества ПС: защищенность, интерфейсы с внешней средой, сопровождаемость и т. д. На этой базе проектируется архитектура всей ИС, выделяются и анализируются требования к программным средствам. При формировании характеристик качества ПС рекомендуется руководствоваться стандартом ISO 9126 и предложенной в нем номенклатурой показателей. Все эти работы отражаются в документах, на каждый компонент проекта отслеживается их взаимодействие и связи с внешней средой в ИС. Кодирование и тестирование каждого компонента ПС должно быть оформлено комплексом документов, удостоверяющих соответствие первичной спецификации, содержащих тесты и результаты тестирования.

Для интеграции компонентов рекомендуется подготавливать план работ, включающий их комплексирование, тестирование по всем требованиям и показателям качества, а также документирование плана, результатов интеграции, использованных тестов, критериев оценки и полученных результатов. Затем ПС необходимо подвергнуть квалификационному (аттестационному) тестированию по всем разделам требований, при широком варьировании тестов и значений критериев, а также протестировать адекватность программам и полноту технической и пользовательской документации. Проверенный таким образом комплекс программ интегрируется с вычислительными средствами ИС, средствами визуализации и телекоммуникации. После объединения всех средств ИС система подвергается квалификационному тестированию и испытаниям на всю совокупность требований к системе, а также производится оформление и проверка полного комплекта документации. При этом рекомендуется использовать методы и средства поддержки ЖЦ ПС, изложенные в шестом разделе. Далее следует создать план установки программного продукта в соответствии с контрактом и производить инсталляции, результаты которых документируются. Должна быть обеспечена поддержка разработчиком поставки ПС.

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

Эти работы взаимодействуют с описанными в подразделе 5.5, обеспечивающими сопровождение ПС (24 работы). Предполагается, что сопровождение может выполняться другими специалистами, не теми, кто создавал ПС на предыдущих этапах. Они анализируют сообщения об ошибках и предложения о модификации ПС, селектируют их на соответствие требованиям контракта и оценивают целесообразность проведения изменений. Подготовленные изменения тестируют и проверяют по критериям, определенным в документации. При подтверждении необходимости изменений в программах производится корректировка документации. Далее планируется распространение внесенных изменений или новой версии пользователям, которым была поставлена предшествующая версия. Рекомендуется учитывать возможность одновременного использования клиентами версий ПС с разным составом проведенных модификаций. Некоторые версии с определенной совокупностью изменений планируются для ликвидации. В разделе 6 представлено около 70 технологических работ, поддерживающих ЖЦ ПС. Процессы документирования ПС (6.1) охватывают планирование и регламентирование документирования, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комплекта документации на ПС. Конфигурационное управление (6.2) включает план реализации версий как часть общего плана управления проектом, рекомендации по конфигурационной идентификации, контролю, учету, отчетности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирования, методологии, процедур и стандартов качества в соответствии с контрактом и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в процессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Верификация ПС (6.4) включает организацию, планирование и техническое обеспечение. Представлена структура контракта на верификацию, содержание процесса, состав требований, проектирование процесса верификации, обобщение и документирование результатов. Валидация (6.5) - удостоверение правильности (аттестация) - должна гарантировать полное соответствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее выполнение независимыми специалистами путем тестирования во всех возможных ситуациях исходных данных. По существу, этот процесс аналогичен сертификации, которая в стандарте не упоминается. Управление проектом (6.6) подразумевает в основном подготовку и обеспечение планирования и управления ресурсами, персоналом, аппаратурой, программными средствами и инструментарием. Общий контроль проекта должен учитывать состояние доступных ресурсов и возможность изменения плана проектирования, а также систематические технические отчеты. Процессы ревизии -- аудит (6.7) - служат для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Ревизоры должны быть независимыми от проектировщиков ПС, они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования. В процессе устранения дефектов и ошибок (6.8) решаются проблемы обеспечения последующего применения ПС и их функционирования. Каждый дефект или ошибка должны быть определены, идентифицированы, описаны, проанализированы и исправлены в процессе сопровождения в соответствии с контрактом. Раздел 7 посвящен процессам организации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, производством и средствами для обеспечения прикладных процессов по созданию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструктуры (7.2) включают выбор и установление аппаратных и программных средств, технологии, стандартов и способов обслуживания, используемых для разработки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к проекту и подлежит конфигурационному управлению. Совершенствование ЖЦ ПС (7.3) подразумевает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходимые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответствующему плану. В приложении А (нормативное) изложены основы преобразования и обобщения базовой структуры этого международного стандарта для конкретного проекта. Следует подчеркнуть необходимость реализации двух важнейших вариантов адаптации положений и рекомендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руководство по процессам адаптации и преобразования ЖЦ ПС для конкретного проекта, а также рекомендации по возможным изменениям ряда работ из разделов 5 и 6 стандарта в зависимости от характеристик объекта. Технология обеспечения качества в ЖЦ ПС представлена в стандарте ISO 9000-3:1991. Руководящие указания предназначены для унификации описания методов разработки и поставки ПС, а также способов контроля их качества, отвечающих требованиям заказчика. Этой унификации предлагается добиваться, предотвращая отклонения от стандарта на всех этапах ЖЦ - от начала разработки до технического обслуживания и ремонта. Предполагается, что в контракте будут особо оговорены важнейшие компоненты технологии проектирования и требования к техническим характеристикам ПС, иначе это делается в процессе разработки. Поставщик должен документально оформить цели, технологию и свои обязательства по обеспечению качества ПС. Необходимо определить ответственность, полномочия и взаимодействие всего руководящего, исполняющего работы и контролирующего персонала, который влияет на качество, надежность и безопасность применения создаваемого комплекса программ. Обеспечение и проверка качества проводится персоналом поставщика, независимым от специалистов, непосредственно ответственных за выполнение работ и создание изделий. Покупатель-заказчик назначает своего представителя, ответственного за сотрудничество с поставщиком в процессе создания ПС по данному контракту. В стандарте определена структура системы обеспечения качества и ее функции в жизненном цикле ПС. Эта деятельность предусматривает:

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

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

  •  формализации состава, содержания и процессам утверждения документации;
  •  управлению конфигурацией версий ПС и проведению изменений в программах и данных.

Стандарт IEEE 1074-1995. Процессы жизненного цикла для развития программного обеспечения. Охватывает полный жизненный цикл ПС, в котором выделяются шесть крупных базовых процессов. Эти процессы детализируются 16 частными процессами. В последних имеется еще более мелкая детализация в совокупности на 65 процессов-работ. Содержание каждого частного процесса начинается с описания общих его функций и задач и перечня действий -- работ при последующей детализации. Для каждого процесса в стандарте представлена входная и результирующая информация о его выполнении и краткое описание сущности процесса. В стандарте внимание сосредоточено преимущественно на непосредственном создании ПС и на процессах предварительного проектирования. В приложении представлены четыре варианта адаптации максимального состава компонентов ЖЦ ПС к конкретным особенностям типовых проектов. Хотя основные процессы близки к описанным в стандарте ISO 12207, общая архитектура и детализация частных процессов и работ в данном стандарте значительно отличается. Процессы непосредственного создания ПС и его поддержки в стандарте представлены наибольшим числом частных процессов (около 70%), начинающимся с разработки требований к ПС и завершающимся приемо-сдаточными испытаниями, проводимыми заказчиком или пользователем.

Возрастающая роль применения комплексов программ в бортовых системах, используемых на самолетах и других объектах для управления в реальном времени, привела в начале 80-х к необходимости разработки нормативных документов и руководств, обеспечивающих высокое качество, надежность и безопасность ПС в таких системах. Для этого в США был создан документ DO-178 В "Соглашение по сертификации бортовых систем и оборудования в части программного обеспечения", пересмотренный и развитый в дальнейшем с учетом накопленного опыта, который следует рассматривать как стандарт в этой области. Цель этого документа состоит в том, чтобы обеспечить руководящие принципы и методологию разработки ПС для бортовых систем, которые выполняют функции с высоким уровнем доверия в обеспечении безопасности, соответствующим авиационным требованиям. Этот документ ориентирован на регламентирование процессов удовлетворения ПС требованиям авиационной сертификации.

За основу представления в документе процессов разработки и сертификации принят жизненный цикл системы и его связь с ЖЦ ПС. В разделе 2 приведена информация, необходимая для понимания взаимодействия между ЖЦ системы и ЖЦ ПС. Раздел 3 является иллюстративным описанием ЖЦ ПС. Как определено в подпараграфе 2.2.2, этот документ определяет задачи для высоких уровней критичности ПС, т. е. для комплексов программ высокой надежности и безопасности применения. Разделы 4 и 5 посвящены процессам планирования и разработки ПС. Интегральные процессы - верификация, управление конфигурацией, обеспечение качества и сертификационное сопровождение -- представлены в разделах 6--9. Раздел 11 содержит рекомендации по структуре документов, создаваемых главным образом для обеспечения сертификации ПС. В разделе 12 обсуждаются дополнительные соглашения, включая руководство по использованию ранее разработанных ПС, сертификации инструментальных средств и применению альтернативных методов для тех задач, которые обсуждаются в разделах 2-11. Раздел необязательно использовать при сертификации всех видов ПС. Таблицы процессов ЖЦ для вариантов уровней критичности ПС, содержащиеся в приложении А, являются нормативной частью этого документа.

Адаптация процессов и работ в стандартах жизненного цикла программных средств к характеристикам конкретных проектов. Не бывает двух одинаковых проектов. Вариации в организационных службах и процедурах, методах и стратегиях приобретения, размере и сложности проекта, требованиях системы и методах разработки среди прочего влияют на способ создания, применения и сопровождения ПС. Используемые реально в фирмах жизненные циклы ПС в последнее время зачастую отличаются от приведенных в стандартах в связи с развитием и внедрением объектно-ориентированного анализа и проектирования, а также методов быстрой разработки прикладных программ, CASE-систем и языков четвертого поколения. В новых технологиях сокращаются стадии непосредственного создания программных и информационных компонентов и детализируются процессы системного анализа и проектирования ПС в целом. Кроме того, возрастает роль и конкретизация работ по технологической поддержке и графической визуализации проектирования, а также по стандартизации интерфейсов компонентов в создаваемых приложениях. Особое внимание уделяется детализации процессов ЖЦ, обеспечивающих высокое качество создаваемых ПС и возможности их эффективного итерационного развития длительное время в многочисленных версиях [1]. Отечественные разработчики и пользователи современных инструментальных средств создания программ, как правило, не знают и не учитывают опыт, формализованный и отраженный в зарубежных стандартах на ЖЦ ПС. Технологические комплексы собираются из отдельных, относительно слабо связанных инструментальных пакетов прикладных программ, решающих частные задачи автоматизации без анализа и учета всего ЖЦ ПС. В результате технология и процессы разработки формируются не системно - с позиции достижения наивысших показателей эффективности и качества всего жизненного цикла конкретного ПС, а с позиции скорейшего достижения видимых для заказчика результатов проекта. В случае критических ПС это сказывается впоследствии на их низкой надежности функционирования и безопасности применения, а также затрудняет модернизацию и развитие версий.

Альтернативой является выбор и формирование комплекса инструментальных средств под технологию, формализованную на базе одного из адаптированных стандартов ЖЦ ПС. Для снижения затрат и обеспечения качества выбранный стандарт ЖЦ следует адаптировать к индивидуальному проекту ПС. Должны быть определены характеристики окружения проекта, которые могут воздействовать на адаптацию. Этими характеристиками могут быть: функции ЖЦ информационной системы; требования системы и ПО; организационные основы коллективов специалистов, процедуры и стратегии их работы; размер, критичность и типы системы; число задействованного персонала и сторон-участников. В стандартах на ЖЦ ПС отражено содержание этапов работ и результирующих документов на методологическом и концептуальном уровне. Методы и средства реализации каждой работы в этих стандартах не раскрываются и адресуются к специальным, детализирующим нормативным документам различного уровня. Однако ряд характерных особенностей этапов принципиально не позволяет создать полную гамму международных стандартов, поддерживающих все этапы и процессы ЖЦ ПС. Например, быстро оснащающиеся различными методами и инструментальными средствами этапы системного анализа, моделирования и предварительного проектирования не позволяют стабилизировать основу этих процессов, достаточную для формализации на уровне международных стандартов, для подготовки которых требуется несколько лет. Поэтому для этих этапов создаются нормативные документы на уровне стандартов де-факто, руководств фирм или сопровождающей документации конкретных инструментальных средств.

1. Sommerville I. Software engineering. Addison -- Wesley. LancasterUniversity,1992.

2. Cargill C.F. Information technologie stangardisation. Digital Press, 1989.

3. Липаев В. В., Филинов Е. Н. Мобильность программ и данных в открытых информационных системах. М., РФФИ, 1997.

4. Щербо В. К., Козлов В. А. Функциональные стандарты в открытых системах. Ч. 1. Концепция открытых систем. М., МЦНТИ, 1997.

С автором статьи можно связаться по телефону: (095) 196-6365.


5. Оценка эффективности внедрения информационных систем.

Литература

  1.  Тернавский А.А., Табаков В.А., Парамонов В.П., Тавровский Л.Д. Репозитарий эффективное средство управления проектом внедрения информационно-управляющей системы НПЗ на базе R/3, М.: Нефтяное хозяйство, 1999, 11. Стр.432.
    1.   Август Вильгельм Шеер. Бизнес-процессы. Основные понятия. Теория. Методы. , пер. с англ., М.: Весть-Метатехнология, 1999.
    2.  А.Каменова, А.Громов, М.Ферапонтов, А.Шматалюк. Моделирование бизнеса. Методология ARIS. Практическое руководство , М.: Весть-Метатехнология, 2001.
    3.  Михеев В. Н., Товб А. С. Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов. В сб. трудов 2-й Всероссийской практической конференции "Стандарты в проектах современных информационных систем", М., 2002. С. 33-37.

Источник: http://www.asutp.ru/go/?id=600396&url=www.my-ikt.ru/cgi-bin/link.cgi?517



Другие статьи раздела: 

  •  06.06.2006 Энергетика + ИТ = вечный двигатель (Михаил Александров, Ольга Васильева, TopS BI)
  •  03.11.2005 Управление через проекты (Михаил Казеннов, Владимир Рябов, TopSBI)
  •  06.10.2005 Штрихкодирование и ремонт в ООО "ПО " Киришинефтеоргсинтез" (А.А. Анискин (ООО "КИНЕФ") А.И. Мигаловский, В.М. Журавлев, О.Н. Меленчук (ОАО "СПИК СЗМА") )
  •  21.09.2005 Введение в LIMS (И.В. Куцевич, ЗАО "РТСофт")
  •  21.09.2005 Структуризация пространства управления производством в ИУС "Орбита" (Т.Б.Потапова, В.Ф.Шварцкопф, ЗАО "ПЛК Системы")


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

Информационное обеспечение

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

 

Информационное сопровождение

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

Лингвистическое обеспечение автоматизированной системы

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

Математическое обеспечение автоматизированной системы

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

 

Опытная эксплуатация автоматизированной системы

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

Подсистема автоматизированной системы

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

 

Прикладное программное обеспечение (Application software)

Прикладное программное обеспечение - программное обеспечение, состоящее из:

- отдельных прикладных программ и пакетов прикладных программ, предназначенных для решения различных задач пользователей; и

- автоматизированных систем, созданных на основе этих (пакетов) прикладных программ.

 

Программное обеспечение автоматизированной системы

Программное обеспечение автоматизированной системы - совокупность программ для реализации целей и задач автоматизированной системы.

 

Рабочий проект автоматизированной системы

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

 Система автоматизированного проектирования (САПР, Компьютерное проектирование Computer-Aided Desing (CAD)

- система:

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

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

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

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

 

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

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

- программы для электронных вычислительных машин;

- средства вычислительной техники и связи;

- словари, тезаурусы и классификаторы;

- инструкции и методики;

- положения, уставы, должностные инструкции;

- схемы и их описания;

- другая эксплуатационная и сопроводительная документация.

 

Технический проект автоматизированной системы

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

 

Техническое задание на автоматизированную систему

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

 

Техническое обеспечение автоматизированной системы

Техническое обеспечение автоматизированной системы - комплекс технических средств, предназначенных для обеспечения работы автоматизированной системы.

 

Функциональная подсистема

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

 


 

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

60078. Яким має бути добро на Землі? 33 KB
  Обладнання: малюнки про добро малюнок дуба калини сонечко. Вступ Діти усміхнімось один одному скажімо: Доброго дня і на краплинку сонця побільшає у світі на краплинку щастя на краплинку радіснішим стане життя вихователь вивішує на дошку...
60079. Ми діти твої, Україно! 59.5 KB
  Мета: стимулювати в учнів інтерес до історії України; формувати національну свідомість школярів; розвивати почуття відповідальності за долю своєї держави; виховувати почуття патріотизму та національної гідності.
60080. Подаруємо ялинці новорічні шати 65.5 KB
  Мета: 1. Виховна: виховувати любов до природи, до народних календарних свят, акуратність, організованість, дисциплінованість. 2. Корекційна: корекція мовлення, розвиток уваги, дрібної моторики рук.
60081. Людина починається з добра 72 KB
  Вчитель: Доброго дня дорогі діти шановні гості А день сьогодні дійсно добрий тому що людським теплом і добротою зігріте серце. Людина в світ приходить для добра Щоб в світі цім добро творити Вам розуміти діточки пора Що серденьку з любов’ю треба жити.
60082. Что такое счастье и как его измерить? 46.5 KB
  Цель: раскрыть историческое происхождение слова счастья. Соедините первые буквы каждого слова и прочитайте полученное слово Счастье. Тема занятия: Что такое счастье и как его измерить.
60083. Как празднуют Новый год во всем мире? 54 KB
  Новый год 2.До начала правления Юлия Цезаря новый год в Риме начинался 1 марта. В Индонезии тоже 2 празднования Нового года: один 1 января другой исламский новый год дата которого меняется из года в год.
60084. Позакласний захід з української літератури 63 KB
  Мета: перевірити опанування навчального м матеріалу; розвивати логічне мислення та усне мовлення; прищеплювати любов до української літератури. м любіть Україну свою і вічні ми будемо з нею...