Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы разработки информационных систем. Учебное пособие.pdf
фикации и специализации, от которых требуется высокая ответственность за
качество результатов деятельности каждого из них;
• от разработчиков проектов требуются гарантии высокого качества,
надёжности функционирования и безопасности применения компонентов и
поставляемых программных продуктов, в которые недопустимо прямое вмешательство заказчика и пользователей для изменений, не предусмотренных
эксплуатационной документацией разработчиков;
• необходимо при
менять индустриальные, регламентированные стандартами процессы, этапы и документы, а также методы, методики и комплексы,
средства автоматизации, технологии обеспечения ЖЦ комплексов программ.
Алистер Коберн для характеристики проектов ПО ввёл два параметра –
критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в программном средстве, её уровень может иметь одно
из четырёх значений:
дефекты вызывают потерю удобства;
• C –
• D – дефекты вызывают потерю возместимых средств (материальных
или финансовых);
• E – дефекты вызывают потерю невозместимых средств;
• L – дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участвующих в
проекте:
• от 1 до 6 человек – малый масштаб;
• от 6 до 20 человек – средний масштаб;
• свыше 20 человек – боль
шой масштаб.
Масштаб и критичность проекта программных средств оказывает значительное влияние на выбор методов и средств ПО.
1.3. ПОНЯТИЕ CASE
Тенденции развития информационных технологий приводят к постоянному возрастанию сложности ИС. Современные ИС характеризуются следующими особенностями:
• сложность описания (достаточно большое количество функций, про-
цессов, элементов данных и сложные взаимосвязи между ними), требующая
тщательного моделирования и анализа данных и процессов;
• наличие совокупности тесно взаимодействующих компонентов,
имеющих свои локальные задачи и цели функцио
нирования;
• отсутствие прямых аналогов, ограничивающее возможность исполь-
зования типовых проектных решений;
• необходимость интеграции существующих и вновь разрабатываемых
приложений;
• функционирование в неоднородной среде на нескольких аппаратных
платформах;
• существенная временная протяжённость проекта.
11
Для успешной реализации ИС должна быть адекватно описана, должны
быть построены полные и непротиворечивые функциональные и информационные модели системы.
В 70 – 80 годах прошлого века при разработке ИС применялись структурные методы, предоставляющие в распоряжение разработчиков строгие
формализованные методы описания проектных решений. Эти методы основаны на использовании наглядных графических моделей: для о
писания архитектуры ИС с различных точек зрения (как статической структуры, так и динамики поведения системы) используются схемы и диаграммы. Однако широкое применение этих методов и следование их рекомендациям при разработке конкретных систем сдерживалось отсутствием адекватных инструментальных средств, поскольку при ручной разработке все их преимущества
практически сведены к нул
ю. Вручную очень трудно разработать и графически представить строгие формальные спецификации ИС, проверить их на
полноту и непротиворечивость и тем более изменить. Ручная разработка
обычно порождала следующие проблемы:
• неадекватная спецификация требований;
• неспособность обнаруживать ошибки в проектных решениях;
• низкое качество документации, снижающее эксплуатационные качества;
• затяжной цикл и неудо
влетворительные результаты тестирования.
Перечисленные факторы способствовали появлению программнотехнологических средств специального класса – CASE-средств, реализующих
CASE-технологию создания и сопровождения ИС.
Понятие CASE (Computer Aided Software Engineering) первоначально
было ограниченно только задачами автоматизации разработки ИС. В настоящее время понятие CASE охватывает все процессы ЖЦ ИС:
• анализ и формулировку требований;
• проектирование приложений и баз данных (БД);
• генер
ацию кода;
• тестирование;
• документирование;
• обеспечение качества;
• конфигурационное управление и управление проектом.
В разряд CASE-средств попадают как относительно дешёвые системы
для персональных компьютеров с весьма ограниченными возможностями,
так и дорогостоящие системы для неоднородных вычислительных платформ
и операционных сред. Современный рынок программных средств насчитывает несколько сотен разли
чных CASE-средств.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов ЖЦ программного продукта и обладающее следующими основными характерными особенностями:
• мощные графические средства для описания и документирования
ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие
его творческие возможности;
12
• интеграция отдельных компонент CASE-средств, обеспечивающая
управляемость процессом разработки ИС;
• использование специальным образом организованного хранилища
проектных метаданных (репозитория).
Все CASE-средства могут быть классифицированы в основном по типам
и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и
включает от
дельные локальные средства, решающие небольшие автономные
задачи, набор частично интегрированных средств, охватывающих большинство этапов ЖЦ ИС и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием.
Классификация по типам в основном совпадает с компонентным соста-
вом CASE-средств и включает следующие основные типы:
• средства анал
иза, предназначенные для построения и анализа моде-
лей предметной области;
• средства анализа и проектирования, поддерживающие наиболее рас-
пространенные методологии проектирования и использующиеся для создания проектных спецификаций;
• средства проектирования БД, обеспечивающие моделирование дан-
ных и генерацию схем БД для наиболее распространенных СУБД;
• средства разработки приложений;
• средства р
еинжиниринга, обеспечивающие анализ программных кодов и схем БД и формирование на их основе различных моделей и проектных
спецификаций.
Вспомогательные типы включают:
• средства планирования и управления проектом;
• средства конфигурационного управления;
• средства тестирования;
• средства документирования.
Появлению CASE-технологий предшествовали исследования в области
методологии программирования. Программирование обрело черты с
истемного подхода с разработкой и внедрением языков высокого уровня, методов
структурного и модульного программирования, языков проектирования и
средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д. Кроме того, появлению CASEтехнологий способствовали и такие факторы, как:
• широкое внедрение и постоянный рост производительности компью-
теров, по
зволившие использовать эффективные графические средства и ав-
томатизировать большинство этапов проектирования;
• внедрение сетевой технологии, предоставившей возможность объе-
динения усилий отдельных исполнителей в единый процесс проектирования
путём использования БД, содержащей информацию о проекте.
13
CASE-технология представляет собой совокупность методов проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на
всех стадиях разработки и сопровождения системы и разрабатывать приложения в соответствии с информационными потребностями пользователей.
Пользователи CASE-технологий должны быть готовы к необходимости
долгосрочных затрат на эк
сплуатацию, частому появлению новых версий и
возможному быстрому моральному старению средств, а также постоянным
затратам на обучение и повышение квалификации персонала. Несмотря на
всё это, успешное внедрение CASE-технологии должно обеспечить такие
выгоды, как:
• высокий уровень технологической поддержки процессов разработки
и сопровождения ИС;
• положительное воздействие на: производительность, качество про-
дукции, собл
юдение стандартов, документирование;
• приемлемый уровень отдачи от инвестиций в CASE-средства.
Основные задачи CASE-технологии:
• разработка моделей предметной области, функциональной структуры
системы, структур данных на графических языках;
• хранение моделей в единой базе данных – репозитории, доступном
всем участникам разработки;
• формальный анализ разрабатываемых моделей, позволяющий избе-
гать некоторых семантических ошибок;
• автоматизированная генерация структу
р баз данных, приложений,
текстов программ;
• автоматизированная генерация документации на программные системы;
• обеспечение повторного использования наработок при модерниза-
ции, перепроектировании системы.
1.4. ЭТАПЫ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ
В процессе разработки ИС можно выделить следующие этапы:
• предварительный;
• сбор требований;
• проектирование;
• реализация;
• подготовка к эксплуатации;
• опытно-промышленная эксплуатация;
• сопровождение и развитие системы.
Предварительный этап. На данном этапе необходимо осознать основ-
ные цели и задачи будущей ИС. Для этого представители заказчика и разработчики ор
ганизуют встречи, на которых обсуждают концепцию ИС, ключе-
вые технические моменты, сроки и объёмы выполняемых работ, а также
14
стоимость и источники финансирования. Итогом предварительного этапа,
помимо согласованных условий будущего договора, должен стать первый и
самый фундаментальный проектный документ – устав проекта.
Устав проекта определяет следующие принципиальные моменты, свя-
занные с процессом разработки и внедрения ИС:
• краткое описание проекта, цели и задачи создания ИС;
• общее описание состава работ;
аницы проекта (сроки, бюджет, перечень объектов автоматизации);
• гр
• описание продукта (перечень поставляемого аппаратного и про-
граммного обеспечения, тип и количество лицензий и т.д.);
• организационная структура проекта (список и роли участников про-
ектной группы со стороны разработчиков и заказчика, их ответственность и
обязанности, система документооборота проекта);
• основные этапы разработки и внедрения ИС, укр
упнённый план-
график их реализации;
• наиболее значимые риски невыполнения обязательств по проекту,
а также способы минимизации рисков.
Завершением предварительного этапа можно считать момент, когда
подписан договор на услуги по разработке и внедрению ИС и утверждён
устав проекта.
Сбор требований. На этом этапе представители исполнителя общаются
с будущими пользователями и администр
аторами системы, а также с их руководством. В ходе обследования не только систематизируются требования и
пожелания к внедряемому решению, но и анализируется документация, которая должна стать источником исходных данных системы, или формирование
которой должно быть в результате автоматизации.
Результатом данного этапа должно стать появление технического зада-
ния (ТЗ) на ра
зработку и внедрение ИС. ТЗ должно базироваться на условиях
договора и требованиях, изложенных в уставе проекта и содержать следующие разделы:
• назначение и цели создания системы;
• описание объекта автоматизации и основных автоматизируемых биз-
нес-процессов;
• требования к системе (требования к структуре; задачам, решаемым
системой; требования к тех
ническому и организационному обеспечению;
требования к надёжности, безопасности и т.д.);
• состав и содержание работ по созданию ИС;
• порядок контроля и приёмки результатов работ;
• требования к составу работ по подготовке объекта автоматизации
для запуска ИС в эксплуатацию;
• требования к составу проектной и пользовательской документации.
Завершение этапа сбора т
ребований – это утверждение заказчиком ТЗ.
В некоторых случаях у заказчика до начала работ по проекту может уже су-
15
ществовать ТЗ (входит в состав конкурсной документации), в этом случае
результаты обследования и сбора требований фиксируются в частных технических заданиях, детализирующих и конкретизирующих общие требования к
ИС, представленные в исходном ТЗ.
На этапе формирования требований к ИС могут выполняться следую-
щие виды работ:
Разработка и анализ бизнес-модели. На этой стадии оп
ределяются основные задачи ИС, проводится декомпозиция задач по модулям и определяются функции, с помощью которых решаются эти задачи. Описание функций
осуществляется на языке производственных (описание процессов предметной
области), функциональных (описание форм обрабатываемых документов) и
технических требований (аппаратное, программное, лингвистическое обеспечение ИС).
• Формализация бизнес-модели, разработка логической модели би
знес-процессов. На этой стадии разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели ИС.
• Выбор лингвистического обеспечения.На этой стадии выбирается
лингвистическое обеспечение, т.е. среда разработки ИС (язык программирования, CASE-средства, СУБД и т.д.).
Проектирование. На этом этапе усилиями разработчиков детально пр
оектируются все сценарии, связанные с разработкой и внедрением ИС. Делается это в соответствии с условиями ИТ-инфраструктуры организации и требованиями к интеграции создаваемой ИС с уже имеющимися и эксплуатируемым ПО. Результатом этапа проектирования должно стать оформление
следующих разделов технического (концептуального) проекта:
• архитектура ИС;
• описание структур инфор
мационного хранилища (базы данных);
• проектные решения, представленные детальным описанием сценариев
автоматизации всех затрагиваемых внедрением системы бизнес-процессов;
• сценарии интеграции разрабатываемой ИС с внешним ПО;
• источники исходных данных и варианты первоначального информа-
ционного наполнения системы;
• концепция разграничения прав доступа к данным на основе ролей
пользователей, определяющих, в том чи
сле, их полномочия;
• концепция обучения пользователей ИС.
Реализация. Этап реализации всех требований к ИС, изложенных в ТЗ.
В этот период разрабатываются все необходимые программные компоненты,
создаётся структура БД, производится установка, настройка и тестирование
всех компонентов ИС на территории разработчика, имитируются сценарии
интеграции и т.д. Завершение этапа реализации подтверждается п
оявлением
таких проектных документов, как руководство по установке и настройке системы, программа и методика испытаний системы, а также шаблон БД.
16
Подготовка информационной системы к эксплуатации. Все работы
данного этапа уже проводятся на территории заказчика и включают в себя
установку и настройку всех компонентов системы в ИТ-инфраструктуре
организации заказчика, проведение предварительного тестирования, разработку пользовательской документации, обучение пользователей, загрузку
исходных данных, проведение испытаний системы в соответствии с
программой и методикой испытаний и прочие подготовительные работы.
К моменту окончания всех подготовительных работ должен быть разработан и утверждён регламент эксплуатации системы. Регламент, в частности,
должен определять пользователей и их роли в системе, в соответствии с их
должностными обязанностями.
Опытно-промышленная эксплуатация. Последний этап в рамках раз-
работки и первоначального внедрения ИС, задачей которого является успешное
проведение опытной эксплуатации системы в течение определённого времени,
а целью – подтвердить, что созданная ИС удовлетворяет требованиям ТЗ.
В этот период пользователи начинают эксплуатировать систему в соответствии с разработанным на предыдущем этапе регламентом. В ходе опытнопромышленной эксплуатации фиксируются ошибки и согласовываются необходимые доработки. Исполнитель устраняет ошибки, выполняет доработки
и при условии, что система начинает функционировать в соответствии
со всеми предъявленными к ней ранее требованиями, в конце установленного
периода получает протокол об успешном завершении опытно-промышленной
эксплуатации.
С завершением опытно-промышленной эксплуатации, как правило,
завершается действие договора на создание ИС. Сама система переходит в
режим промышленной эксплуатации, а разработчик, если в этом заинтересован заказчик, заключает отдельный договор на её сопровождение, на
период установленного условиями договора срока.
Сопровождение и развитие системы. Промышленная эксплуатация
может выявить то, что некоторые требования к созданной ИС содержали
неточности и требуют иной формулировки или дополнений, а сама система
требует доработки. Не каждая организация имеет в своём штате персонал,
который способен самостоятельно внести в работу ИС изменения, поэтому
может заключаться отдельный договор на сопровождение системы.
Пользователи ИС начинают общаться с представителями службы
поддержки, которые принимают от них заявки на доработку функционала и
устранение дефектов. Перечень возможных доработок и регламент обработки
заявок определяется условиями договора. Если появляется потребность
в работах, которые не укладываются в суть договора на сопровождение,
то составляется отдельный догов
ор на данный вид работ, который уже можно
отнести к работам по модернизации и развитию ИС.
17
1.5. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
Современная организация является сложной системой, деятельность которой включает в себя исполнение множества взаимовлияющих функций и
операций. Человек не в состоянии понимать, как такая система функционирует в деталях. Поэтому предполагается построение моделей деятельности
(или модели бизнес-процессов) организации. Отсутствие таких моделей является одной из главных причин неудач многих проектов. Тр
ебования к ИС
формируются на основе бизнес-модели.
Моделирование бизнес-процессов – это отражение субъективного видения реально существующих в организации процессов с помощью графических, табличных, текстовых способов представления. Моделирование бизнеспроцессов – формирование структур, функций и процессов, оптимальным
способом реализующих цели предприятия.
Бизнес-процесс определяется как логически завершённый набор взаимосвязанных и вз
аимодействующих видов деятельности, поддерживающий деятельность организации и реализующий её политику, направленную на достижение поставленных целей. Бизнес-процесс использует определённые ресурсы (финансовые, материальные, человеческие, информационные) для
преобразования входных элементов в выходные.
Бизнес-процесс характеризуется следующими свойствами:
• входы и выходы бизнес-процесса – входы обозначают необходимые
для выполнения процесса ресурсы (мате
риальные, информационные, трудо-
вые); выходы обозначают результаты процесса;
• владелец процесса – должностное лицо, несущее ответственность за
получение результата процесса и обладающее полномочиями для распоряжения ресурсами, необходимыми для выполнения процесса;
• начало, окончание и продолжительность – процесс характеризуется
временными параметрами.
Важным шагом структуризации деятельности любой организации явля-
ются выделение и классификация бизнес-процессов. Мо
жно выделить следующие классы процессов: основные процессы, обеспечивающие процессы и
процессы управления.
Основными бизнес-процессами являются процессы, непосредственно
связанные с созданием стоимости, ориентированные на производство товаров
или оказание услуг, составляющих основную деятельность организации и
обеспечивающих получение дохода.
Обеспечивающие бизнес-процессы не увеличивают ценность продукта
или услуги для по
требителя, но необходимы для деятельности организации.
Они предназначены для поддержки выполнения основных бизнес-процессов.
Такими процессами являются финансовое обеспечение деятельности, обеспечение кадрами, юридическое обеспечение, администрирование, обеспечение безопасности, поставка комплектующих материалов, ремонт и техническое обслуживание и т.д.
18
Бизнес-процессы управления – это процессы, охватывающие весь комплекс функций управления на уровне каждого бизнес-процесса и системы в
целом. Примерами таких процессов могут быть процессы стратегического,
оперативного и текущего планирования, процессы формирования и выполнения управляющих воздействий. Процессы управления оказывают воздействие на все остальные процессы организации.
Типовые бизнес-процессы пр
едприятия, разработанные Американским
центром производительности и качества (american productivity&quality
center):
• Разрабатывать, создавать и оценивать прототипы продуктов и услуг.
• Измерение удовлетворения потребителей.
• Продавать продукты/услуги.
• Позиционирование продуктов и услуг на сегментах потребительско-
го рынка.
• Осуществлять мониторинг изменений на рынке или в ожиданиях по-
требителей.
• Определять концепцию бизнеса и стратег
ию организации.
• Управлять процессом производства и поставки.
• Анализировать рынок и потребности потребителей.
• Управлять процессом разработки продукта/услуги.
• Разрабатывать продукты или услуги.
• Тестировать эффективность новых или изменённых продуктов или
услуг.
• Производить и обеспечивать производство.
• Обрабатывать заказы потребителей.
• Определять потребности и пожелания потребителей.
• Планировать и получать н
еобходимые ресурсы.
• Разрабатывать и ранжировать цели организации.
• Разрабатывать видение и стратегию.
• Осуществлять мониторинг внешней среды.
• Разрабатывать организационную структуру и систему взаимоотно-
шений между организационными единицами.
• Разрабатывать концепцию и план продукта/услуги.
• Совершенствовать существующие продукты/услуги.
• Преобразовывать ресурсы или входы в продукты.
• Пос
тавлять продукт.
Бизнес-модель – это формализованное (в нашем случае – графическое)
описание процессов, связанных с ресурсами и отражающих существующую
или предполагаемую деятельность организации.
Целью построения бизнес-модели является:
• обеспечить понимание структуры организации и динамики происхо-
дящих в ней процессов;
19
• обеспечить понимание текущих проблем организации и возможно-
стей их решения;
• убедиться, что заказчики, пользователи и разработчики одинаково
понимают цели и задачи организации;
• создать базу для формирования требований к будущей ИС.
Используются модели двух типов: «AS-IS» и «AS-TO-BE».
Модели «AS-IS» («как есть»), отражающие существующее на момент
обследования положение дел в организации и по
зволяющие понять, каким
образом функционирует данная организация, а также выявить узкие места и
сформулировать предложения по улучшению ситуации.
Модели «AS-TO-BE» («как должно быть»), отражающие представление
о новых процессах и технологиях работы организации. Переход от модели
«AS-IS» к модели «AS-TO-BE» может выполняться двумя способами:
1) совершенствованием существующих технологий на основе оценки
их эффективности;
2) радикальным изменением техн
ологий и перепроектированием (ре-
инжинирингом) бизнес-процессов.
Требования к ИС формируются на основе бизнес-модели, а критерии
проектирования системы, прежде всего, основываются на наиболее полном
их удовлетворении. Модели бизнес-процессов являются не просто промежуточным результатом, используемым консультантом для выработки какихлибо рекомендаций и заключений, а представляют собой самостоятельный
результат, име
ющий большое практическое значение.
Модель бизнес-процесса должна давать ответы на вопросы:
• Какие механизмы контроля и управления существуют в рамках рас-
сматриваемого бизнес-процесса?
• Какие процедуры (функции, работы) необходимо выполнить для по-
лучения заданного конечного результата?
• Какие параметры характеризуют выполнение процедур и процесса в
целом?
• В какой п
оследовательности выполняются эти процедуры?
• Кто выполняет процедуры процесса?
• Какую исходящую информацию генерирует процедура процесса?
• Какую входящую информацию использует каждая процедура про-
цесса?
• Какие ресурсы необходимы для выполнения каждой процедуры про-
цесса?
Важным элементом модели бизнес-процессов являются правила предметной области. Примером таких правил являются государственные и меж-
одные законы.
дунар
20