• Название:

    пис 2011

  • Размер: 10.94 Мб
  • Формат: PDF
  • или

    ВСЕ МОЛОДЧИКИ! - 22й не готов - там бред!
    Вопросы и ответы для сдачи экзамена
    информационных систем (4 июня 2011)
    Постарайтесь следить за форматированием текста.
    И отмечать, что уже сделано жирным в списке вопросов.

    Распределение вопросов среди студентов
    1. Сергей Шибалов 1-3
    2. Артем Петров 4-6
    3. Олег Бердников 7-9
    4. Михаил Пантелеев 10,11
    5. Ира Савельева 13-15
    6. Ира Игнатьева - Забила болт Отчислена(16-18)
    6. Жуков Сергей - 16, 17
    6. Ася - 18
    7. Аня Иванова 19-21
    8. Паша Варченко 22-24
    9. Саша Сапыгин 25 26 27
    10. Ксюша Горбунова
    11. Лавров Виктор 28, 29, 31
    12. Александр Плетнев 32-33, 12,30

    Коротко про этапы построения ИС, не помню, в какой вопрос
    http://www.prj-exp.ru/dwh/stages_of_model_development.php
    Еще одна очень полезная ссылка про проектирование

    Вопросы и ответы
    1.Жизненный цикл информационной системы. ГОСТ 51 904.

    по

    предмету

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

    2.Модели жизненного цикла информационной системы. ГОСТ 15 271.

    Модели жизненного цикла ПО :
    Каскадная модель
    Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970
    г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго
    фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем
    этапе. Требования, определенные на стадии формирования требований, строго документируются в виде
    технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском
    полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой
    командой разработчиков.
    Этапы проекта в соответствии с каскадной моделью:

    1.

    Формирование требований;

    2.

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

    3.

    Реализация;

    4.

    Тестирование;

    5.

    Внедрение;

    6.

    Эксплуатация и сопровождение.

    Ее плюсы:
    1.

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

    2.

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

    Минусы:
    Основным недостатком каскадного подхода является существенное запаздывание с получением результатов.
    Согласование результатов с пользователями производится только в точках, планируемых после завершения
    каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания.
    Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет
    полностью завершена. В случае неточного изложения требований или их изменения в течение длительного
    периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как
    функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их
    утверждением.
    Спиральная модель
    Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана
    на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в
    несколькоитераций (витков спирали) методом прототипирования.
    Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и
    характеристики проекта, оценивается качество полученных результатов и планируются работы следующей
    итерации.
    На каждой итерации оцениваются:
    1.
    риск превышения сроков и стоимости проекта;
    2.
    необходимость выполнения ещё одной итерации;
    3.
    степень полноты и точности понимания требований к системе;
    4.
    целесообразность прекращения проекта.
    Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод
    быстрой разработки приложений).

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

    Итеративная и инкрементальная модель
    Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций,
    каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших
    фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей
    версии программной системы, включающей функциональность, определенную интегрированным содержанием всех
    предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность
    продукта. Таким образом, с завершением каждой итерации,продукт развивается инкрементально.
    С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения
    развития продукта – инкрементальной (incremental). Опыт индустрии показывает, что невозможно рассматривать каждый
    из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модельназывают просто итеративной (говоря
    о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта).
    Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования)
    версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для
    определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает
    развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному
    плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации
    как полную версию системы. С другой стороны, Скотт Амблер [Ambler, 2004], например, определяет эволюционную
    модель как сочетание итеративного и инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47]

    пишет: “Итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной.
    Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны,
    как противостояние итеративного метода и метода водопада.”
    Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему:




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

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

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

    3.Методологии проектирования. Каноническое проектирование. ГОСТ 34.601-90.
    Проектирование информационных систем
    Каноническое проектирование ИС
    Организация канонического проектирования ИС ориентирована на использование главным образом каскадной
    модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
    В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании
    конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять
    последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также
    начинать выполнение работ следующей стадии до окончания предыдущей.
    Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и
    технических заданиях на выполнение работ:
    Стадия 1. Формирование требований к ИС.
    На начальной стадии проектирования выделяют следующие этапы работ:
    обследование объекта и обоснование необходимости создания ИС;
    формирование требований пользователей к ИС;
    оформление отчета о выполненной работе и тактико-технического задания на разработку.
    Стадия 2. Разработка концепции ИС.
    изучение объекта автоматизации;
    проведение необходимых научно-исследовательских работ;
    разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
    оформление отчета и утверждение концепции.
    Стадия 3. Техническое задание.
    разработка и утверждение технического задания на создание ИС.
    Стадия 4. Эскизный проект.
    разработка предварительных проектных решений по системе и ее частям;
    разработка эскизной документации на ИС и ее части.
    Стадия 5. Технический проект.
    разработка проектных решений по системе и ее частям;
    разработка документации на ИС и ее части;
    разработка и оформление документации на поставку комплектующих изделий;
    разработка заданий на проектирование в смежных частях проекта.
    Стадия 6. Рабочая документация.

    разработка рабочей документации на ИС и ее части;
    разработка и адаптация программ.
    Стадия 7. Ввод в действие.
    подготовка объекта автоматизации;
    подготовка персонала;
    комплектация ИС поставляемыми изделиями (программными и техническими средствами, программнотехническими комплексами, информационными изделиями);
    строительно-монтажные работы;
    пусконаладочные работы;
    проведение предварительных испытаний;
    проведение опытной эксплуатации;
    проведение приемочных испытаний.
    Стадия 8. Сопровождение ИС.
    выполнение работ в соответствии с гарантийными обязательствами;
    послегарантийное обслуживание.
    Oбследование- это изучение и диагностический анализ организационной структуры предприятия, его
    деятельности и существующей системы обработки информации.Материалы, полученные в результате
    обследования, используются для:
    обоснования разработки и поэтапного внедрения систем;
    составления технического задания на разработку систем;
    разработки технического и рабочего проектов систем.
    На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и
    детальный анализ деятельности организации.
    Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач на
    основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня.
    Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых
    организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями
    системы и бизнес-экспертами. Основная задача взаимодействия - получить полное и однозначное понимание
    требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед
    или семинаров с руководством, экспертами и пользователями.
    По завершении этой стадии обследования появляется возможность определить вероятные технические
    подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение,
    закупаемое программное обеспечение и разработку нового программного обеспечения ).
    Результатом этапа определения стратегии является документ (технико-экономическое обоснование проекта),
    где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит
    готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть
    составлен график финансирования на разных этапах работ). В документе желательно отразить не только

    затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если
    его удается оценить).
    Ориентировочное содержание этого документа:
    ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
    совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы,
    аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи
    системы;
    сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите
    информации;
    описание выполняемых системой функций;
    возможности развития системы;
    информационные объекты системы;
    интерфейсы и распределение функций между человеком и системой;
    требования к программным и информационным компонентам ПО, требования к СУБД;
    что не будет реализовано в рамках проекта.
    На этапе детального анализа деятельности организации изучаются задачи, обеспечивающие реализацию
    функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а
    также характер подчиненности вышестоящим органам управления. На этом этапе должны быть выявлены:
    инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем
    и перечень задач;
    возможности применения новых методов решения задач.
    Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
    функции - информация о событиях и процессах, которые происходят в бизнесе;
    сущности - информация о вещах, имеющих значение для организации и о которых что-то известно.
    При изучении каждой функциональной задачи управления определяются:
    наименование задачи; сроки и периодичность ее решения;
    степень формализуемости задачи;
    источники информации, необходимые для решения задачи;
    показатели и их количественные характеристики;
    порядок корректировки информации;
    действующие алгоритмы расчета показателей и возможные методы контроля;
    действующие средства сбора, передачи и обработки информации;
    действующие средства связи;
    принятая точность решения задачи;
    трудоемкость решения задачи;
    действующие формы представления исходных данных и результатов их обработки в виде документов;
    потребители результатной информации по задаче.
    Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа является описание
    документооборота организации. При обследовании документооборота составляется схема маршрута

    движения документов, которая должна отразить:
    количество документов;
    место формирования показателей документа;
    взаимосвязь документов при их формировании;
    маршрут и длительность движения документа;
    место использования и хранения данного документа;
    внутренние и внешние информационные связи;
    объем документа в знаках.
    По результатам обследования устанавливается перечень задач управления, решение которых целесообразно
    автоматизировать, и очередность их разработки.
    На этапе обследования следует классифицировать планируемые функции системы по степени важности.
    Один из возможных форматов представления такой классификации - MuSCoW [9].
    Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные
    функции; Could have - возможные функции; Won't have - отсутствующие функции.
    Функции первой категории обеспечивают критичные для успешной работы системы возможности.
    Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками:
    разрабатывается то, что необходимо, а также максимально возможное в порядке приоритета число функций
    второй и третьей категорий.
    Последняя категория функций особенно важна, поскольку необходимо четко представлять границы проекта и
    набор функций, которые будут отсутствовать в системе.
    Модели деятельности организации создаются в двух видах:
    модель "как есть"("as-is")- отражает существующие в организации бизнес-процессы;
    модель "как должно быть"("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения
    ИС.
    На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач:
    получения сравнительных характеристик предполагаемых к использованию аппаратных платформ,
    операционных систем, СУБД, иного окружения;
    разработки плана работ по обеспечению надежности информационной системы и ее тестирования.
    Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов.
    Если проектное решение оказалось неудачным и это обнаружено слишком поздно (на этапе разработки или,
    что еще хуже, на этапе внедрения в эксплуатацию), то исправление ошибки проектирования обходится очень
    дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость
    сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует
    предусматривать не только на этапе разработки, но и на этапе проектирования.

    Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это
    позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость
    и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также
    поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по email и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.
    Результаты обследования представляют объективную основу для формирования технического задания на
    информационную систему.
    Техническое задание- это документ, определяющий цели, требования и основные исходные данные,
    необходимые для разработки автоматизированной системы управления.
    При разработке технического задания необходимо решить следующие задачи:
    установить общую цель создания ИС, определить состав подсистем и функциональных задач;
    разработать и обосновать требования, предъявляемые к подсистемам;
    разработать и обосновать требования, предъявляемые к информационной базе, математическому и
    программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);
    установить общие требования к проектируемой системе;
    определить перечень задач создания системы и исполнителей;
    определить этапы создания системы и сроки их выполнения;
    провести предварительный расчет затрат на создание системы и определить уровень экономической
    эффективности ее внедрения.

    4.Методологии проектирования. Типовое проектирование.

    4.Методологии проектирования. Типовое проектирование.
    В данном курсе приведены основные определения и представлено задание для разработки проекта
    ИС методом типового проектирования (кейс "Проектирование ИС предприятия оптовой торговли
    лекарственными препаратами").
    Типовое проектирование ИС предполагает создание системы из готовых типовых элементов.
    Основополагающим требованием для применения методов типового проектирования является возможность
    декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач,
    программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на
    рынкетиповые проектные решения, которые настраиваются на особенности конкретного предприятия.
    Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию)
    проектное решение.
    Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы
    ТПР:




    элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному,
    программному, техническому, математическому, организационному);
    подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом



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

    Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов
    (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в
    соответствии с требованиями разрабатываемой системы.
    Основные особенности различных классов ТПР приведены в таблице 3.3.
    Класс ТПР
    Реализация ТПР

    Элементные
    ТПР Библиотеки
    методоориентированных
    программ

    Достоинства

    Недостатки

    1) обеспечивается применение
    модульного подхода к проектированию и
    документированию ИС

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

    2) большие затраты времени на
    доработкуТПР отдельных элементов

    Подсистемные
    ТПР Пакеты
    прикладных
    программ

    1) достигается высокая степень
    интеграции элементов ИС

    2) позволяют осуществлять: модульное
    проектирование; параметрическую
    настройку программных компонентов на
    различные объекты управления
    3) обеспечивают: сокращение затрат на
    проектирование и программирование
    взаимосвязанных компонентов; хорошее
    документирование отображаемых
    процессов обработки информации

    Объектные ТПР
    Отраслевые
    проекты ИС

    1) комплексирование всех компонентов
    ИС за счет методологического единства
    и информационной, программной и
    технической совместимости

    1) адаптивность ТПР недостаточна с
    позиции непрерывного инжиниринга
    деловых процессов

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

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

    2) открытость архитектуры — позволяет
    устанавливатьТПРна разных
    программно-технических платформах

    3) масштабируемость — допускает
    конфигурацию ИС для переменного
    числа рабочих мест

    4) конфигурируемость — позволяет
    выбирать необходимое подмножество
    компонентов

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












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

    Внутри каждой группы критериев выделяется некоторое подмножество частных показателей,
    детализирующих каждый из десяти выделенных аспектов анализа выбираемых ППП. Достаточно полный
    перечень показателей можно найти в литературе [10].

    Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале
    оценок (например, 10-бальной). На их основе формируются групповые оценки и комплексная оценка
    пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты
    также получаются экспертным путем.
    Модельно-ориентированное проектирование заключается в адаптации состава и характеристик
    типовой ИС в соответствии с моделью объекта автоматизации.
    Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью
    типовой ИС, так и с моделью конкретного предприятия.
    Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации,
    на основе которой осуществляется конфигурирование программного обеспечения. Таким образом,
    модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта
    автоматизации с использованием специального программного инструментария (например, SAP Business
    Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой
    модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере
    накопления опыта проектирования информационных систем для различных отраслей и типов производства.
    Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных
    классов ИС, модели конкретных ИС предприятий.
    Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнесобъектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями
    типовой ИС.
    Типовые модели описывают конфигурации информационной системы для определенных отраслей или
    типов производства.
    Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели
    в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем
    автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering
    Workbench).
    Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости
    может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и
    настройка информационной системы.
    Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и
    используются для поддержания целостности создаваемой системы.
    Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности
    предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области
    внедрения ИС").

    Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнесфункций (подробное описание см. в разделе "Спецификация функциональных требований к ИС"). Для
    отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain).
    Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений
    информационной системы в соответствии с характерными особенностями конкретного предприятия.
    Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение
    различных бизнес-процессов (подробное описание см. в разделе "Этапы проектирования ИС с применением
    UML").
    Модель организационной структуры предприятия представляет собой традиционную иерархическую
    структуру подчинения подразделений и персонала (подробное описание см. в разделе "Анализ и
    моделирование функциональной области внедрения ИС").
    Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС,
    которые выявляются на основе результатов предпроектного обследования объекта автоматизации (см.
    раздел "Анализ и моделирование функциональной области внедрения ИС"). Для оценки соответствия этим
    требованиям программных продуктов может использоваться описанная выше методика оценки ППП. После
    выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная
    модель ИС, в которой отражаются все особенности реализации ИС для конкретного предприятия.
    Предварительная модель является основой для выбора типовой модели системы и определения перечня
    компонентов, которые будут реализованы с использованием других программных средств или потребуют
    разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, ABAP в SAP,
    Tools в BAAN).
    Реализация типового проекта предусматривает выполнение следующих операций:










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

    5.Процессы жизненного цикла информационной системы. ГОСТ 12 207.
    5.Процессы жизненного цикла информационной системы. ГОСТ 12 207.
    ссылка на ГОСТ 12 207 в формате .doc

    1. 5 Основные процессы жизненного цикла
    В настоящем разделе определены следующие основные процессы жизненного цикла:
    1) процесс заказа;
    2) процесс поставки;
    3) процесс разработки;
    4) процесс эксплуатации;
    5) процесс сопровождения.
    Ответственность за выполнение работ и задач в основном процессе несет организация, создающая и
    реализующая данный процесс. Данная организация гарантирует реальность существования и функциональные
    особенности конкретного процесса.

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

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

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

    Разработчик управляет процессом разработки на проектном уровне в соответствии с процессом управления
    (подраздел 7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в
    соответствии с процессом создания инфраструктуры (подраздел 7.2); адаптирует данный процесс к условиям проекта
    в соответствии с процессом адаптации (приложение А) и управляет процессом разработки на организационном уровне
    в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4). Если разработчиком
    является доставщик разрабатываемого программного продукта, то разработчик должен также выполнять процесс
    поставки (подраздел 5.2).

    1. 5.4 Процесс эксплуатации
    Процесс эксплуатации состоит из работ и задач оператора. Процесс охватывает эксплуатацию программного
    продукта и поддержку пользователей в процессе эксплуатации. Так как эксплуатация программного продукта входит в
    эксплуатацию системы, работы и задачи данного процесса связаны с системой.
    Оператор управляет процессом эксплуатации на проектном уровне в соответствии с процессом управления
    (подраздел 7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в
    соответствии с процессом создания инфраструктуры (подраздел 7.2); адаптирует данный процесс к условиям проекта в
    соответствии с процессом адаптации (приложение А) и управляет процессом эксплуатации на организационном уровне
    в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4). Если оператор является
    поставщиком программной услуги, то оператор выполняет также процесс поставки.

    1. 5.5 Процесс сопровождения
    Процесс сопровождения состоит из работ и задач, выполняемых персоналом сопровождения. Данный процесс
    реализуется при изменениях (модификациях) программного продукта и соответствующей документации, вызванных
    возникшими проблемами или потребностями в модернизации или настройке. Целью процесса является изменение
    существующего программного продукта при сохранении его целостности. Данный процесс охватывает вопросы
    переносимости и снятия программного продукта с эксплуатации. Процесс заканчивается снятием программного продукта
    с эксплуатации.
    Работы, выполняемые в данном процессе, характерны для процесса сопровождения, однако в данном процессе
    могут использоваться другие процессы, определенные в настоящем стандарте. Если в данном процессе используется
    процесс разработки (подраздел 5.3), то персонал сопровождения выступает в роли разработчика.
    Персонал сопровождения управляет процессом сопровождения на проектном уровне в соответствии с процессом
    управления (подраздел 7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного
    процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2); адаптирует данный процесс к
    условиям проекта в соответствии с процессом адаптации (приложение А) и управляет процессом сопровождения на
    организационном уровне в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел
    7.4). Если персонал сопровождения является поставщиком услуги по сопровождению, он реализует процесс поставки
    (подраздел 5.2).

    1. 6 Вспомогательные процессы жизненного цикла
    В данном разделе определены следующие вспомогательные процессы жизненного цикла:
    1) процесс документирования;
    2) процесс управления конфигурацией;
    3) процесс обеспечения качества;
    4) процесс верификации;
    5) процесс аттестации;
    6) процесс совместного анализа;
    7) процесс аудита;
    8) процесс решения проблем.

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

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

    1. 6.2 Процесс управления конфигурацией
    Процесс управления конфигурацией является процессом применения административных и технических процедур
    на всем протяжении жизненного цикла программных средств для: обозначения, определения и установления состояния
    (базовой линии) программных объектов в системе; управления изменениями и выпуском объектов; описания и сообщения
    о состояниях объектов и заявок на внесение изменений в них; обеспечения полноты, совместимости и правильности
    объектов; управления хранением, обращением и поставкой объектов.
    Примечание - Когда данный процесс применяется к другим программным продуктам или объектам,
    термин "программный объект" интерпретируется ниже соответствующим образом.
    Список работ. Данный процесс состоит из следующих работ:

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

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

    1. 6.5 Процесс аттестации
    Процесс аттестации является процессом определения полноты соответствия установленных требований,
    созданной системы или программного продукта их функциональному назначению. Аттестация может проводиться на
    начальных этапах работы. Данный процесс может проводиться как часть работы по обеспечению приемки программных
    средств (см. 5.3.13).
    Данный процесс может выполняться с различными степенями независимости исполнителей. Степень
    независимости исполнителей может распределяться как между различными субъектами в самой организации, так и
    субъектами в другой организации, с различными степенями распределения обязанностей. Данный процесс называется
    процессом независимой аттестации, если организация-исполнитель не зависит от поставщика, разработчика, оператора
    или персонала сопровождения.

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

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

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

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

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

    вспомогательные процессы.

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

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

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

    6.Процессы жизненного цикла информационной системы. Процессы планирования.

    6.Процессы жизненного цикла информационной системы. Процессы планирования.
    источник - ГОСТ 51904 стр.

    7.Процессы жизненного цикла информационной системы. Процессы определения требований к ИС.
    ГОСТ 34.601-90
    1. Формирование требований к АС
    1.1. Обследование объекта и обоснование необходимости создания АС.
    а) сбор данных об объекте автоматизации и осуществляемых видах деятельности;
    б) оценку качества функционирования объекта и осуществляемых видах деятельности,
    выявление проблем, решение которых возможно средствами автоматизации;
    в) оценку (технико-экономической, социальной и т.д.) целесообразности создания АС.
    1.2. Формирование требований пользователя к АС.
    а) подготовку исходных данных для формирования требований АС (характеристика объекта
    автоматизации, описание требований к системе, ограничения допустимых затрат на разработку,
    ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и
    функционирования системы);
    б) формулировку и оформление требований пользователя к АС.
    1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического
    задания)
    На этапе 1.3. "Оформление отчёта о выполненной работе и заявки на разработку АС (техникотехнического задания)" проводят оформление отчета о выполненных работах на данной стадии и
    оформление заявки на разработку АС (тактико-технического задания) или другого заменяющего её
    документа с аналогичным содержанием.
    Необходимость определения требований к информационной системе возникает в следующих случаях:
    в момент выбора новой информационной системы, при подготовке тендерной документации, при
    заключении договора на разработку или настройку выбранной информационной системы, при
    уточнении (детализации) потребностей бизнеса в процессе разработки или настройки системы, а так
    же при необходимости внесения изменений в систему в ходе эксплуатации. В каждом случае перед















    специалистами предприятия и организации встает задача выбора уровня детализации требований,
    методов описания, включая формализованное описание с использованием графического моделирования.
    На уровень детализации, область определения, а так же используемые методы описания влияют:
    выбранная модель жизненного цикла разработки и внедрения;
    характера разрабатываемого и внедряемого ПО (заказная разработка, настройка информационной
    системы).
    используемые средств и методов проектирования (в случае заказной разработки).
    В зависимости от этих параметров следует использовать ту или иную методологию моделирования,
    которая определяет выбор нотации, а выбор нотации, в свою очередь, определяет используемые
    инструментальные средства.
    Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые
    осуществляются в ходе разработки, функционирования и сопровождения программного продукта в
    течение всей жизни системы, от определения требований до завершения ее использования. Существует
    несколько моделей и стандартов, в той или иной степени регламентирующих жизненный цикл,
    большинство из них относятся к заказному ПО (автоматизированным системам АС, и др.) и кроме
    непосредственно ЖЦ регламентируют также и процессы разработки:
    ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы
    их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии
    и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели
    жизненного цикла [1].
    ISO/IEC 12207:1995 (наш аналог ГОСТ Р ИСО/МЭК 12207-99) стандарт на процессы и организацию
    жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз,
    стадий этапов.
    Custom Development Method (и, методика Oracle) по разработке прикладных информационных
    систем под заказ - конкретный материал, детализированный до уровня заготовок проектных
    документов, рассчитанных на использование в проектах с применением Oracle. Степень адаптивности
    CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и
    этапы), "быстрая разработка" (Fast Track), "облегченный подход", рекомендуемый в случае малых
    проектов и возможности быстро прототипировать приложения.
    Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре
    фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы
    (итерации), в результате которых выпускается версия для внутреннего или внешнего использования.
    Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается
    генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный
    продукт продолжает развиваться и снова минует те же фазы [2]. Суть работы в рамках RUP - это
    создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан
    к использованию конкретных средств моделирования (UML), а так же конкретной технологии
    проектирования и разработки (объектно-ориентированный анализ, object-oriented analysis, OOA,
    объектно-ориентированное программирование, object-oriented programming, OOP).
    Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ,










    проектирование, разработка, стабилизация, является итерационной, предполагает использование
    объектно-ориентированного моделирования. [7]. MSF в сравнении с RUP в большей степени
    ориентирована на разработку бизнес-приложений.
    Extreme Programming (XP). Экстремальное программирование является самым новым среди
    рассматриваемых методологий, сформировалось в 1996 году. В основе методологии командная работа,
    эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке
    ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
    Приведенный перечень далеко не полный, разработчики крупных информационных систем и компанииинтеграторы так же предлагают свои методологии внедрения, содержащие основные этапы (модель
    жизненного цикла), формы документов, перечни вопросов и инструменты моделирования. Компания
    IBM внесла значительный вклад в теорию проектирования и разработки информационных систем,
    предложив еще в середине 1970-х годов методологию BSP (Business System Planning, система
    организационного планирования).
    Все существующие сегодня методики определения требований к ИС являются наследниками BSP,
    используют предложенные в ней методы сбора информации, подходы в определении приоритетов
    требований, обеспечении полноты и непротиворечивости требований. Структурирование информации
    с использованием матриц пересечения бизнес-процессов, функциональных подразделений, систем
    обработки данных (информационных систем), информационных объектов, документов и баз данных,
    предложенный в BSP, используется сегодня не только в ИТ проектах, но и проектах по реинжинирингу
    бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их
    последовательность (получить поддержку высшего руководства, определить процессы предприятия,
    определить классы данных, провести интервью, обработать и организовать данные интервью) можно
    встретить практически во всех формальных методиках, а так же и в проектах, реализуемых на практике.
    Различают основные формальные модели ЖЦ.
    Каскадная модель
    Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в
    1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта
    в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ
    на предыдущем этапе. Требования, определенные на стадии формирования требований, строго
    документируются в виде технического задания и фиксируются на все время разработки проекта.
    Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы
    разработка могла быть продолжена другой командой разработчиков.
    Этапы проекта в соответствии с каскадной моделью:
    Формирование требований;
    Проектирование;
    Реализация;
    Тестирование;
    Внедрение;
    Эксплуатация и сопровождение.
    Спиральная модель

    Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она
    основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели
    ПО создается в несколько итераций (витков спирали) методом прототипирования.
















    Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и
    характеристики проекта, оценивается качество полученных результатов и планируются работы
    следующей итерации.
    На каждой итерации оцениваются:
    риск превышения сроков и стоимости проекта;
    необходимость выполнения ещё одной итерации;
    степень полноты и точности понимания требований к системе;
    целесообразность прекращения проекта.
    Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод
    быстрой разработки приложений).
    Итерационная модель
    Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению
    современного итерационного подхода, который представляет рациональное сочетание этих моделей.
    Различные варианты итерационного подхода реализованы в большинстве современных технологий и
    методов (RUP, MSF, XP).
    На сегодняшний день существует несколько популярных средств формализованного описания
    требований к информационным системам, среди них:
    UML (Unified Modeling Language), Rational Rose или Visual Modeler как инструмент моделирования,
    сценарии использования для описания работы пользователей (функциональные требования). Use Case
    диаграммы используются для описания границ системы и выявления функциональных требований
    самого высокого уровня. Диаграммы деятельности и последовательностей используются для
    моделирования процессов, а диаграммы классов - для проектирования структуры данных.
    SADT (Structured Analysis and Design Technique): язык IDEF (IDEF0, IDEF3), средство моделирования:
    BPWin / ERWin (после переименования, All Fusion Process Modeler и Data Modeler).
    ARIS (Architecture of Integrated Information Systems) доктора Шеера (IDS Scheer AG): нотация eEPC
    (Event Driven Process Chain) и инструмент ARIS Toolset.
    Выбор той или иной совокупности методов зависит от следующих факторов:
    Корпоративный стандарт. В крупных компаниях на определенном этапе возникает необходимость
    в структурированном описании бизнес-процессов. Для обеспечения эффективности инвестиций в
    приобретение средств моделирования и обучение сотрудников, а так же обеспечения согласованности
    структурированного описания предприятия (моделирования) компания должна выбрать определенную
    нотацию и средство моделирования в качестве стандарта, и использовать их как во внутренних
    проектах, так и в проектах с привлечением консультантов.
    Квалификация персонала. Даже обладая знаниями и навыками работы в различных CASE-средствах,
    специалист, как правило, отдает предпочтение одному из них, и применяет его наиболее эффективно.
    Информационная система. CASE-средство должно не только поддерживать нотацию, максимально














    полно описывающую требования к устанавливаемой системе, но и быть с ней интегрировано.
    (Например, нотация eEPC и инструмент ARIS Toolset используются в случае внедрения SAP/R3, а UML
    и Rational Rose при заказной разработке с использованием SQL Server и Visual Studio).
    Проект. Внедрение информационной системы часто бывает частью проекта по реинжинирингу
    деятельности компании, одновременно с определением требований к информационной системе
    проектируется новая организационная структура, формулируются должностные инструкции. В этом
    случае требования к нотации моделирования и используемым инструментам оказываются шире. В
    этом случае очевидное преимущество имеет ARIS Toolset, поддерживающий 86 различных нотаций,
    обеспечивающих моделирование различных аспектов деятельности предприятия. Использование
    BPWin и нотации IDEF0 так же имеет свои преимущества, поскольку строгость нотации обеспечивает
    относительно высокое качество модельного описания (связанность моделей, обязательное наличие
    управления в блоке).
    Функциональные требования к информационной системе, которые описываются, в том числе, и с
    помощью моделей процессов и структур данных, являются только частью общих требований, которые
    содержаться в техническом задании. Раздел требований к информационной системе технического
    задания может содержать следующие подразделы:
    Требования к функциональным характеристикам. В этом разделе должны быть указаны требования
    к составу выполняемых функций, организации входных и выходных данных. При выборе между
    объектными и структурными методами следует использовать принцип концептуальной общности,
    который предполагает следование единой философии на всех этапах ЖЦ. Если предполагается
    использовать структурное программирование, то и на этапе анализа следует использовать структурный
    подход, а в случае использования объектно-ориентированных языков разработки - объектный
    анализ и объектное проектирование. При необходимости структурный и объектный подходы могут
    использоваться одновременно.
    Требования к надежности. В разделе должны быть определены требования к обеспечению надежного
    функционирования: контроль входной и выходной информации, время и механизмы восстановления
    после программных и аппаратных отказов. В этом разделе описывается организация системы
    безопасности, включая подсистемы контроля доступа, шифрования и т. п.
    Настраиваемость. Определяются требования к адаптационным возможностям ПО, то есть указывается,
    какие изменения в методах управления и бизнес процессах должны быть предусмотрены.
    Условия эксплуатации. В этом разделе описывается необходимое обслуживание, которое требуется
    для работы системы, например, создание резервных копий, реиндексерование баз и т. п., а так же
    требования к квалификации персонала (пользователей и обслуживающего персонала).
    Требования к составу и параметрам технических средств. Указывается необходимый состав
    технических средств с указанием их основных технических характеристик. Могут указываться
    требования к помещениям, в которых будет находиться оборудование. В этом разделе указываются
    требования к переносимости системы.
    Требования к информационной и программной совместимости. Требования к информационным
    структурам на входе и выходе, методам решения, исходным кодам, языкам программирования и
    программным средствам, используемым программой.



    Требования к программной документации. В этом разделе указывается предварительный состав
    программной документации, и при необходимости, специальные требования к ней.
    Еще раз необходимо подчеркнуть, что состав разделов технического задания определяется
    особенностями проекта.Динамика изменения требований зависит от выбранной модели жизненного
    цикла, в каскадной модели требования определяются один раз в начале проекта, а в итерационной уточняются в ходе выполнения проекта. Во втором случае должна быть предусмотрена процедура
    управления требованиями. Одним из возможных подходов является представление совокупности
    требований в виде набора атомарных требований - утверждений, между которыми выявляются
    отношения зависимости. Например, продукт Rational RequsitePro позволяет вести базу данных
    требований, определять их атрибуты, а так же отношения (трассируемость, иерархические связи).
    При использовании каскадной модели все требования содержаться в техническом задании, затем они
    преобразуются в архитектурное решение в техническом проекте, в этом случае процедура управления
    требованиями упрощается, ведь предполагается, что требования не будут меняться в ходе проекта.
    Каковы типичные ошибки при определении требований к информационной системе:
    ● неполнота требований (структура). Определяются только часть требований, например
    функциональные требования, при этом не указываются требования к надежности, производительности,
    программной совместимости и т.д. применение стандарта на программную документацию (техническое
    задание) поможет избежать эту проблему. Кроме того,
    ● ошибки или неполнота описания бизнес-логики. Описывается только основной поток процесса,
    а многочисленные альтернативные потоки не исследуются. При этом количество и сложность
    альтернативных потоков значительно превосходит количество и сложность основных потоков.
    Пример: фрагмента основного потока процесса: прибыл заказанный товар на склад, количество и
    номенклатура совпадают с заказанным, товар отправлен покупателю. Для этого потока существует
    несколько альтернативных потоков: прибыл заказанный товар, но количество отличается от заказанного
    (варианты, в большую, меньшую сторону), отличается номенклатура товара (отклонения по размеру,
    цвету, сортности). Проводится согласование с покупателем. Покупатель согласен (не согласен)
    получить товар в ином количестве (ассортименте). Пример можно продолжить, но наша задача лишь
    показать сложность и количество альтернативных потоков. Выявление альтернативных потоков важно
    и по той причине, что мониторинг отклонения процесса от основного потока, сбор статистики, является
    важной функций управления.
    ● избыточность требований. Избыточность требований встречается так же часто, как и неполнота,
    как правило, они соседствуют в одном документе. Основные признаки избыточности: описываемые
    требования реализуются автоматически благодаря используемой технологии разработки или выбранной
    архитектуре, требования не влияют на архитектуру информационной системы, ее бизнес-логику
    (например, требования к содержанию данных, вместо требований к структуре и объему информации),
    требования повторяются многократно в различных частях документа (дублирование). Основная
    опасность избыточности требований в отвлечении внимания, создании иллюзии полноты выявленных
    требований.

    8.Процессы жизненного цикла информационной системы. Процессы
    проектирования.

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




    необходимого уровня безопасности;
    простоты эксплуатации и поддержки системы.
    Согласно современной методологии, процесс создания ИС представляет собой процесс построения и
    последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС.
    На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС,
    требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются
    и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление
    в коллективное пользование осуществляется с использованием специальных программных инструментов CASE-средств.
    Процесс создания ИС делится на ряд этапов (стадий), ограниченных некоторыми временными рамками и
    заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).
    Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование,
    реализация, тестирование, ввод в действие, эксплуатация и сопровождение. (Последние два этапа далее не
    рассматриваются, поскольку выходят за рамки тематики курса.)
    Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в
    организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов
    и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение
    методологии обеспечивает объективность в выработке требований к проектированию системы. Множество
    моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный
    проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и
    информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные
    БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка,
    тестирование и интеграция.
    Целью начальных этапов создания ИС, выполняемых на стадии анализа деятельности организации, является
    формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика.
    Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и
    четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования
    заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы
    обеспечить соответствие целям и задачам организации.
    Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых
    и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства
    и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую
    эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому
    удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное,
    неточное или неполное определение требований к ИС на этапе анализа.
    На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной
    информации получают результаты анализа. Построение логической и физической моделей данных является
    основной частью проектирования базы данных. Полученная в процессе анализа информационная модель
    сначала преобразуется в логическую, а затем в физическую модель данных.
    Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить

    спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть
    бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная
    цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули
    информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню,
    вид окон, горячие клавиши и связанные с ними вызовы.
    Конечными продуктами этапа проектирования являются:
    ● схема базы данных (на основании ER-модели, разработанной на этапе анализа);
    ● набор спецификаций модулей системы (они строятся на базе моделей функций).
    Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в
    себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС
    могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных
    операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие
    характеристики архитектуры:
    ● будет ли это архитектура "файл-сервер" или "клиент-сервер";
    ● будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер
    приложений), клиентское ПО;
    ● будет ли база данных централизованной или распределенной. Если база данных будет распределенной,
    то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
    ● будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того
    же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база
    данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД
    разных производителей (уже существующее или разработанное специально как часть проекта);
    ● будут ли для достижения должной производительности использоваться параллельные серверы баз
    данных (например, Oracle Parallel Server, DB2 UDB и т.п.).
    Этап проектирования завершается разработкой технического проекта ИС.
    На этапе реализации осуществляется создание программного обеспечения системы, установка технических
    средств, разработка эксплуатационной документации.
    Этап тестирования обычно оказывается распределенным во времени.
    После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует
    две основные цели:
    ● обнаружение отказов модуля (жестких сбоев);
    ● соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних
    функций).
    После того как автономный тест успешно пройден, модуль включается в состав разработанной части системы и
    группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
    Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации
    отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо
    система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая
    группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время
    безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую

    нагрузку на систему.
    Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий
    уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
    Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ
    информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнеспроцессы, чтобы показать соответствие реализации требованиям заказчика.
    Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и
    соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в
    этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного
    моделирования, CASE-систем.
    Проектирование АИС и АИТ - процесс создания и внедрения проектов комплексного решения экономических
    задач по новой технологии, т.е. детальная разработка отдельных проектных решений, их анализ, апробация
    и внедрение. В каждом подразделении организации должен быть назначен сотрудник, ответственный за
    проектирование и внедрение АИС и АИТ, который собирает нужную информацию, подбирает технику и
    программные средства, ведет обучение персонала, руководит внедрением и анализом функционирования ИС.
    На фазе построения выполняется собственно быстрая разработка приложения. На данной фазе разработчики
    производят итеративное построение реальной системы на основе полученных ранее моделей, а также
    требований нефункционального характера. Разработка приложения ведется средствами визуального
    программирования. Формирование программного кода частично выполняется с помощью автоматических
    генераторов кода, входящих в состав CASE-средств. Код генерируется на основе разработанных моделей.
    На фазе построения также требуется участие пользователей системы, которые оценивают получаемые
    результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным
    ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
    После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция
    данной части системы с остальными, формируется полный программный код, выполняется тестирование
    совместной работы данной части приложения с остальными, а затем тестирование системы в целом.
    Завершается физическое проектирование системы, а именно:
    • определяется необходимость распределения данных;
    • производится анализ использования данных;
    • производится физическое проектирование базы данных;
    • определяются требования к аппаратным ресурсам;
    • определяются способы повышения производительности;
    • завершается разработка документации проекта.
    Результатом данной фазы является готовая информационная система, удовлетворяющая всем требованиям
    пользователей.
    9.Процессы жизненного цикла информационной системы. Процессы кодирования.
    Коди́рование — процесс написания программного кода, скриптов, с целью реализации определённого

    алгоритма на определённом языке программирования.
    Некоторые путают такие понятия, как программирование и непосредственно кодирование. Кодирование
    является лишь частью программирования, наряду с анализом, проектированием, компиляцией, тестированием
    и отладкой, сопровождением.
    Кодирование - процесс присвоения новых условных обозначений различным позициям по определенным
    правилам, установленным системой кодирования. Наибольшее распространение получили системы
    кодирования: порядковая, серийная, позиционная и комбинированная.
    Коды могут быть следующих видов: цифровые, буквенные, смешанные.
    К кодам предъявляются следующие требования:
    ● должны охватывать все номенклатуры, по которым делается группировка;
    ● быть едиными для разных задач внутри одного экономического объекта;
    ● должны быть стабильными, часто не пересматриваться;
    ● иметь резерв на случай появления новых позиций номенклатуры;
    ● быть экономичными, т.е. обладать минимальной значностью.
    Назначение кодов состоит в обеспечении группировки информации, подсчете итогов по группировочным
    признакам и их печати в выходных ведомостях. Коды необходимы для удобства поиска информации, хранения
    и выборки, передачи ее по каналам связи.
    Релизация ИС:
    ● Анализ
    ● Проектирование — разработка комплекса алгоритмов
    ● Кодирование и компиляцию — написание исходного текста программы и преобразование его в
    исполнимый код с помощью компилятора
    ● Тестирование и отладку — выявление и устранение ошибок в программах
    ● Испытания и сдачу программ
    ● Сопровождение
    В более широком смысле под программированием понимают весь спектр активностей, связанных с
    созданием и поддержанием в рабочем состоянии программ (программного обеспечения ЭВМ). Более
    точный и современный термин - программная инженерия, или инженерия ПО. Сюда входят анализ и
    постановка задачи, проектирование программы, построение алгоритмов, разработка структур данных,
    написание текстов программ, отладка и тестирование программ (испытания программ), документирование,
    настройка (конфигурирование), доработка и сопровождение.
    10.Процессы жизненного цикла информационной системы. Процессы интеграции.
    Информационная система редко разрабатывается с нуля. Чаще проектировщики сталкиваются с задачами
    наследования данных из старых систем, которые уже выполняют какие-либо задачи автоматизации бизнеса.
    Такие системы могут на начальном этапе быть интегрированы в новую систему и постепенно заменяться
    новыми, более современными модулями. Этот подход может навязываться руководством фирмы для того,
    чтобы ускорить ввод новой информационной системы. Следует рассмотреть все плюсы и минусы такой
    постепенной интеграции (минусов, как правило, оказывается больше). Одну операцию придется делать в

    любом случае: переносить ценные данные, хранящиеся в старой информационной системе, в новую, то
    есть проектировать механизмы конвертации данных. Возможно, что придется делать конвертацию данных
    не только из старой системы в новую, но и обратно (полную или частичную), поскольку возможен вариант
    развития событий, при котором старая и новая информационные системы будут работать параллельно - хотя
    бы в период опытной эксплуатации новой системы.
    Задачи интеграции возникают в случае внедрения в компании новых информационных систем или добавления
    в существующие системы новой функциональности.
    Кроме вопросов наследования собственно данных из старых информационных систем, возможно, вам
    придется также решать задачи взаимодействия вашего ПО с продуктами третьих фирм. В этом случае вам
    следует изучить интерфейсы обмена данными ПО других разработчиков и обеспечить должный уровень
    поддержки этих интерфейсов в разрабатываемой информационной системе.
    Следует понимать, что при интеграции информационных систем производится интеграция именно данных, и
    только потом техническая реализация канала, способа, формата передачи данных. В связи с этим, основной
    проблемой, возникающей при интеграции, является проблема, связанная с качеством данных. Возникают
    также организационные трудности и сложности технической реализаций процессов.
    Основываясь на опыте участия в нескольких проектах, в которых приходилось решать вопросы интеграции
    информационных систем, приведу несколько типичных проблем, возникающих в ходе решения задач
    интеграции, а также рекомендации по их избежанию.
    Качество данных
    Отсутствие качественных данных (приведенных к единому формату, недублирующихся, согласованных
    между собой, без “мусорных” записей) в информационных системах многих компаний является данностью,
    с которой приходится работать. Зачастую этот факт при внедрении новых ИС не учитывается, и в конце
    реализации проекта компания получает еще одну систему со своим набором данных, слабо согласующимися
    с данными других систем. В таких случаях при попытке настройки взаимодействия несогласованность данных
    приводит к тому, что интеграция систем есть, а интеграции данных нет. Может даже получиться несколько
    наборов данных в одной системе идентичных по сути, но разных по представлению (например, “юр. лицо”
    и “Юридические лица”).
    Решать задачу согласованности данных призваны системы управления мастер-данными (Master Data
    Management, MDM). Но сегодня эти системы в российских компаниях являются больше экзотикой, чем
    нормой (об этом свидетельствует список референсов основных поставщиков MDM-решений). В отсутствии
    единой MDM-системы в компании задачи согласования данных и обеспечения их качества ложатся на
    процессы интеграции. Для этого разрабатываются бизнес-правила преобразования данных, создаются
    таблицы соответствия и т.п. решения, что по сути своей представляет систему MDM для одного или группы
    интеграционных процессов.
    Конечно, не рекомендуется решать задачи интеграции, миграции данных и задачи улучшения качества
    данных, дедубликации в рамках одного проекта. Но если выхода нет, то прежде чем начинать разрабатывать
    бизнес-правила и таблицы соответствия, необходимо изучить данные, провести их предварительный анализа
    путем профилирования (Data Profiling). Проведение профилирования позволяет получить информацию
    о содержании, качестве и структуре данных. Этот важный этап, предшествующий этапу проектирования
    процессов интеграции, очень часто игнорируется, что приводит в итоге к несогласованности данных в
    интегрируемых системах. Еще одной важной задачей профилирования данных является сужение множества

    передаваемых данных, ведь в процессе анализа можно выявить “мусорные”, дублирующиеся или ненужные
    вообще для передачи данные.
    Итак, к типичным проблемам интеграции, связанным с качеством данных, можно отнести:
    ● несогласованность интегрируемых данных, в следствие отсутствия в компании единой системы
    управления мастер-данными;
    ● непридание важности профилированию, анализу и очистки данных перед реализацией процессов
    интеграции.
    Процесс организации интеграции сводится к следующим действиям:
    ● определение источника/приемника данных;
    ● анализ данных источника;
    ● выбор инструмента интеграции;
    ● согласование форматов, способа и периодичности обмена данными (согласование регламента
    интеграции);
    ● проектирование и разработка процессов интеграции;
    ● тестирование;
    ● промышленная эксплуатация.
    Интегрированные (корпоративные) ИС - используются для автоматизации всех функций фирмы и охватывают
    весь цикл работ от планирования деятельности до сбыта продукции. Они включают в себя ряд модулей
    (подсистем), работающих в едином информационном пространстве и выполняющих функции поддержки
    соответствующих направлений деятельности.
    Для любой компании важным элементом, способствующим оптимальному функционированию, является
    сопровождение информационных систем. Зачастую на современном предприятии при использовании
    информационных систем, разработанных разными производителями, обмен данными между ними становится
    непростой задачей: информация может храниться в разных форматах, а системы базироваться на различных
    платформах. То есть данные из одной системы не могут быть просто импортированы в другую, что затрудняет
    создание целостного информационного пространства. Решить проблему унификации больших объемов
    данных и оптимизировать процесс взаимодействия разрозненных систем позволяет их интеграция и
    дальнейшее сопровождение информационных систем.
    Процесс интеграции систем состоит из двух объемных задач:
    ● интеграция данных;
    ● интеграция приложений и бизнес-процессов.
    Интеграция данных
    Хранилище данных, как один из важнейших инструментов управления и развития бизнеса является
    предметно-ориентированным, интегрированным, зависимым от времени набором оперативной информации.
    Архивация данных нацелена не только на автоматизацию бизнес-процессов, но и на содержательный и
    вдумчивый анализ показателей, необходимый для поддержки принятия решений руководством компании.
    Формирование корпоративного хранилища данных предназначено для решения задач интегрирования
    распределенных информационных потоков и источников информации, а также для реализации задач

    извлечения, доставки и согласования первичных данных, сведения их к единой системе классификации,
    поддержки информации в актуальном состоянии.
    Преимущества подобных корпоративных хранилищ данных:
    ● обеспечение целостности и непротиворечивости данных для управленческой отчетности;
    ● формирование многомерных витрин, агрегирующих и консолидирующих детальную информацию для
    осуществления полнофункционального анализа данных компании;
    ● публикация выходных данных на портале – предоставление эргономичного и привычного для
    пользователя интерфейса по работе с данными хранилища;
    ● оперативный и повторный анализ показателей может проводиться столько раз, сколько это
    необходимо;
    ● наличие в аналитической системе хранения данных множества шаблонов уменьшает время на
    генерацию разнообразных отчетов;
    ● снижение нагрузки на транзакционные и учетные системы при формировании аналитических запросов;
    ● упрощение поддержки безопасности системы за счет централизации хранения актуальной информации
    и исторических данных.
    Полный цикл интеграции данных включает:
    ● консолидацию данных - извлечение данных из различных систем и создание слоя метаданных,
    приведение данных к единому виду, независимо от источников;
    ● очистку и обогащение данных, которые позволяют избежать недостоверной информации,
    дублирующихся и / или неполных записей;
    ● извлечение, преобразование и загрузку (ETL) данных из информационных систем предприятия в
    единое хранилище данных и подготовку для анализа;
    ● миграцию и синхронизацию, позволяющие выявить изменения данных в реальном времени, чтобы
    обеспечить своевременное обновление данных;
    ● управление мастер-данными (Master Data Management).
    В целом корпоративное хранилище данных и система оперативной аналитической обработки позволит
    компаниям любого масштаба создать оптимальную информационную инфраструктуру и упростить доступ к
    данным для их оперативного анализа.
    Интеграция функциональных приложений и бизнес-процессов
    Решить задачи построения общего информационного пространства призвана технология интеграции
    приложений (Enterprise Application Integration, EAI).
    Наиболее экономным вариантом является интеграция систем по принципу «точка-точка», то есть
    последовательная интеграцию небольшого количества систем друг с другом на базе мастер-системы.
    Современным методом, подходящим для интеграции большого количества систем, является корпоративная
    сервисная шина (Enterprise Service Bus).
    Интеграционная шина нужна предприятию, когда:
    ● используется большое количество ИТ-систем (больше пяти);
    ● протоколы и форматы данных в этих системах раличаются;





    бизнес-процессы задействуют несколько систем;
    имеются большие объемы данных (больше тысячи записей в день по каждой из основных систем);
    существует необходимость в консолидации информации из нескольких систем (например, для
    получения отчетности);
    ● есть вероятность увеличения количества информационных систем или объемов данных.
    Интеграция приложений, как правило, возникает в компаниях с «лоскутной» автоматизацией, когда
    значительная часть бизнес-процессов уже автоматизирована и существующие системы в основном
    удовлетворяют требованиям бизнеса. В этом случае предпочтительнее автоматизировать оставшиеся бизнеспроцессы и обеспечить интеграцию приложений в единое решение, чем инициировать долгосрочный и
    дорогостоящий проект замены существующих систем на новую.
    Задачи, которые решает интеграция приложений:
    ● объединение приложений уровня предприятия в единую информационную систему;
    ● возможность интеграции через множество протоколов;
    ● многократное использование корпоративных данных и сервисов;
    ● маршрутизация и система управления событиями, управление транзакциями;
    ● унификация знакомых пользователю интерфейсов и уменьшение потребности в создании и поддержке
    новых интерфейсов;
    ● повышение скорости внедрения новых корпоративных приложений, использующих SOA, и интеграция с
    унаследованными системами;
    ● дополнительные возможности для мониторинга бизнес-процессов.
    Основные преимущества интеграции систем:
    ● создание единого информационного пространства, позволяющего избежать противоречий между
    данными в различных системах и обновлять информацию симультанно;
    ● при настроенном и интегрированном потоке бизнес-процессов на предприятии повышается скорость
    обработки информации, информационного обмена и, как следствие, его эффективность;
    ● пользователи получают простой, удобный и единообразный интерфейс ко всем функционирующим
    приложениям, что позволяет увеличить скорость и эффективность труда;
    ● независимость от конкретного поставщика решений – в интегрированную систему достаточно просто
    и быстро можно включать новые приложения, не будучи привязанным к конкретному поставщику, а
    выбирая лучшее решение в классе.
    Несмотря на то, что процесс интеграции информационных систем на уровне предприятия является
    достаточно сложным и ресурсоемким, его стоимость может варьироваться. В зависимости от потребностей
    заказчика специалисты РАМЭК-Интеграция могут предложить различные схемы интеграции – от вертикальной
    интеграции (в этом случае интегрируется только часть систем с определенным функционалом) до полной
    интеграции с дальнейшим сопровождением информационных систем.
    11.Процессы планирования. Планирование инфраструктуры проекта.
    Своевременное создание инфраструктуры проекта является одним из критических факторов успеха на
    этапе планирования.
    Планирование инфраструктуры начинается с формирования требований. Как правило, требования к

    компьютерному оборудованию и сопутствующей инфраструктуре формируются на основе анализа внутренней
    информации компании, включающей оценку характеристики работы компьютерного оборудования.
    Инфраструктуру необходимо оценить относительно задач различного профиля, и проводить ее оценку на
    следующих уровнях:
    рабочие места;
    сеть;
    системы (серверы приложений и баз данных).
    Рекомендуется назначать ответственного за обеспечение команды проекта оборудованием, созданием
    рабочей среды, библиотеки проекта. Работы по созданию инфраструктуры проекта необходимо
    контролировать. Для членов команды проекта на территории заказчика должны быть подготовлены рабочие
    места, оснащенные офисным оборудованием, телефонами, персональными компьютерами, принтерами,
    комнатами для ведения переговоров, учебными аудиториями и прочими материальными ресурсами. Одним из
    обязательных элементов инфраструктуры является библиотека проекта.
    Пример требований к инфраструктуре офиса проекта (фрагмент)
    Специальные помещения
    Для осуществления рабочей группой проекта работ в группе компаний "Звездочка" заказчик предоставляет
    специальные помещения для размещения объединенной рабочей группы проекта.
    Требования к помещениям
    Помещение проектного офиса должно удовлетворять следующим требованиям:
    ü на одного сотрудника должно приходиться не менее 5 м2 площади рабочей комнаты, рабочее место
    каждого сотрудника должно быть обеспечено:
    отдельным рабочим столом;
    стулом;
    двумя розетками электрической сети;
    одной розеткой для доступа в информационную сеть;
    одной розеткой для доступа в телефонную сеть (по дополнительному обоснованию);
    телефонным аппаратом (по дополнительному обоснованию). Каждое помещение офиса должно быть
    обеспечено:
    сетевым лазерным черно-белым принтером с возможностью двухсторонней печати на листах формата
    А4 и скоростью печати не менее 30 страниц в минуту;
    вешалкой для верхней одежды всех сотрудников, размещенных в рабочей комнате;
    одним шкафом для документов.
    ü Рабочей группе проекта должна быть выделена в пользование рабочая комната для проведения
    переговоров, оборудованная:
    столом для заседаний;
    стульями;
    флип-чартом;
    экраном и проектором для проведения совещаний с участием 10 человек.
    Обеспечение членов рабочей группы проекта персональными компьютерами:
    исполнитель, по возможности, привлекает к работе по проекту сотрудников, обеспеченных переносными
    компьютерами;
    сотрудники заказчика, привлекаемые к работам по проекту, обеспечиваются заказчиком персональными
    компьютерами в кратчайшие сроки;
    требования к характеристикам персональных компьютеров могут быть оговорены в зависимости от

    конкретных задач, выполняемых сотрудником.
    Обеспечение рабочей группы проекта копировальной техникой Рабочая группа проекта
    обеспечивается заказчиком одним копировальным аппаратом с возможностью двухстороннего копирования
    листов формата А3 и А4 и автоматической подачей листов оригинала.
    Обеспечение рабочей группы проекта канцелярскими принадлежностями Рабочая группа проекта
    обеспечивается заказчиком канцелярскими принадлежностями и бумагой по заявке администратора проекта
    от исполнителя.
    Обеспечение информационного обмена членов рабочей группы проекта
    Заказчик обеспечивает выделение дискового ресурса совместного доступа для организации библиотеки
    проектной документации и библиотеки программных приложений, используемых проектом создания СДО.
    Заказчик обеспечивает выделение рабочей подсети для организации взаимодействия членов рабочей
    группы проекта.
    Заказчик обеспечивает доступ в Интернет для всех членов рабочей группы проекта.
    Заказчик обеспечивает выделение адреса электронной почты каждому члену рабочей группы проекта.
    Заказчик обеспечивает наличие телефонной связи с возможностью выхода в городскую телефонную
    сеть для каждого члена рабочей группы проекта от исполнителя (по дополнительному обоснованию).
    Режим и место работы членов объединенной рабочей группы проекта
    Работы по проекту выполняются сотрудниками исполнителя или субподрядчика на территории
    заказчика и/или на территории исполнителя/субподрядчика.
    Начало рабочего дня для членов рабочей группы проекта - 9 часов 00 минут, окончание рабочего
    дня - 18 часов 00 минут, длительность обеденного перерыва - 1 час в интервале времени с 12:00 до 15:00.
    Руководители проекта от заказчика и исполнителя имеют право изменять режим работы для привлекаемых к
    проекту сотрудников при условии взаимного согласования таких изменений.
    Заказчик обеспечивает возможность работы сотрудников исполнителя на территории заказчика
    в вечернее и ночное время, а также в выходные и праздничные дня (при необходимости возможна
    круглосуточная работа) по предварительной заявке от исполнителя.
    Пример процедуры создания инфраструктуры проекта
    Для создания инфраструктуры необходимо:
    обеспечить поставки материальных ресурсов - требуется заказать или запросить необходимые ресурсы;
    организовать установку оборудования - обеспечить доставку, провести установку и тестирование
    оборудования;
    обеспечить сервисное обслуживание оборудования - разработать график сервисного обслуживания;
    протестировать рабочую среду на предмет ее совместимости с требованиями к функциональности,
    совместимости и доступности.

    12.Процессы планирования. Планирование
    ресурсов проекта.
    Типы ограничений проекта
    Технические или логические ограничения

    Технические ограничения связаны с последовательностью, в которой должны выполняться операции проекта
    и показаны на рис. 3.1.А.
    Сеть проекта для каркаса дома должна отражать последовательность трех операций:
    1. заливка фундамента,
    2. строительство каркаса,
    3. возведение крыши.
    В сети для проекта нового программного обеспечения можно последовательно расположить операции:
    1. проектирования,
    2. кодирования,
    3. испытания в сети.

    Рис. 3.1. Примеры ограничений

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

    Предположим, что вы занимаетесь планированием приема по случаю бракосочетания, который состоит из 4
    операций:
    1.
    2.
    3.
    4.

    план,
    заказ оркестра,
    украшение зала и
    закупка легкой закуски.

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

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

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

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

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

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

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

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

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

    Проекты, ограниченные по времени
    Если потребность в конкретном типе ресурсов колеблется, то управление затруднено и использование
    ресурса может быть весьма неэффективным.
    Практики решают эту проблему, используя метод выравнивания ресурсов, который уравнивает или
    сглаживает потребность в ресурсах.
    Все методы выравнивания приводят к отсрочке исполнения некритических операций для снижения пика
    потребностей и восполняя их нехватку.
    При демонстрации этого примера будет использован только один тип ресурсов (например, плотники); в рамках
    этого типа все ресурсы взаимозаменяемы.
    На рис. 3.2 представлен пример сети, ES графика потребности в ресурсах и график использования ресурсов.
    Затемненные области на графике потребности представляют границы календарного графика для каждой
    операции.

    Рис. 3.2A. Ограниченная по времени сеть
    Поскольку было заявлено, что проект ограничен по времени, целью будет сокращение пика потребностей в
    ресурсах и, таким образом, повышение степени их использования.
    Изучение ES графика загрузки ресурса показывает, что только две операции имеют простой, который можно
    использовать для сокращения пика - операции B и D.
    Любая из этих операций может быть задержана, чтобы сократить пик потребности в ресурсах от 5 до 4,
    используя 2 единицы времени простоя. Выбор, очевидно, будет сделан в пользу операции, которая имеет
    наименьший риск опоздания (вероятно, операция D, поскольку она имеет наибольший простой).
    Схема загрузки ресурсов при раннем
    старте (ES)

    ID

    RE
    S

    DU
    R

    E
    S

    LF TS
    0

    1 2 3 4 5 6 7 8 9 1
    0

    A

    2

    2

    0

    2

    2 2

    B

    2

    6

    2

    10 2

    2 2 2 2 2 2

    C

    2

    4

    2

    6

    2 2 2 2

    D

    1

    2

    2

    10 6

    E

    1

    2

    6

    10 6

    1 1

    F

    1

    4

    6

    10 0

    1 1 1 1

    G

    1

    2

    10 12 0

    Общая загрузка ресурсов

    0

    0

    1
    1

    1
    2

    1

    1

    1

    1

    1 1

    2 2 5 5 4 4 4 4 1 1

    Рис. 3.2B. Ограниченная по времени сеть
    На рис.3.3А показаны результаты задержки операции B.

    Рис. 3.3А. График выравнивания ресурсов. Результаты задержки операции В

    Рис. 3.3B. Показаны результаты задержки операции D
    На рис.3.3В показаны результаты задержки операции D.

    Рис. 3.3C. График выравнивания ресурсов. Результаты задержки операции D
    Обратите внимание на различие в графиках ресурсов. Важным моментом является то, что ресурсы,
    необходимые на время существования проекта, были сокращены с 5 до 4 (20%) и использование ресурсов
    возросло с 57% [необходимые 34 единицы ресурсов в целом (5х12)] до 71% [34/(4x12)].
    Кроме того, график был выровнен, что означает облегчение в управлении,
    Обратной стороной процесса выравнивания потребности в ресурсах является потеря эластичности сетевого
    графика, которая происходит в результате сокращения резервов времени выполнения работ.
    Риск того, что какие-то операции могут задержать проект, также увеличивается, поскольку сокращение
    резервов времени выполнения работ приводит к появлению большего числа критических и/или почти
    критических операций.
    Стремление слишком сильно выровнять график ресурсов рискованно. Тогда каждая операция становится
    критической.
    Обычно для выравнивания ресурсов проекта используются операции, которые имеют наибольший резерв
    времени их выполнения. Это объясняется тем, что с такими операциями связан наименьший риск.

    Проекты, ограниченные по количеству ресурсов
    Когда количество людей и/или оборудования не соответствует удовлетворению пика потребностей и их
    невозможно получить в большем количестве, руководители проектов сталкиваются с проблемой ограниченных
    ресурсов.
    Искусство заключается в том, что необходимо определить приоритеты и распределить ресурсы таким
    образом, чтобы свести к минимуму задержку проекта, не превышая при этом лимит ресурсов и не изменяя
    технические отношения сети.
    Проблема составления календарного графика ресурсов представляет большую комбинаторную проблему.
    Огромное количество данных, которое требуются для решения крупных проблем, сделало практически
    нецелесообразными чисто математические решения (например, линейное программирование).
    Альтернативным подходом к проблеме было использование эвристического (приближенного метода) для
    решения больших комплексных проблем.
    Эвристика не всегда дает оптимальный календарный график, но весьма подходит для составления "хороших"
    графиков для очень сложных сетей с разными типами ресурсов.
    Ниже приводится простой пример эвристического подхода.

    Ресурсы для выполнения операций распределены так, чтобы уменьшить риск отставания проекта от
    заданного срока; то есть, определен приоритет выделения ресурсов на операции, а также то, какие операции
    задерживаются, если количество ресурсов недостаточно.
    Были выявлены следующие эвристические критерии, которые всегда сводят к минимуму задержку самых
    разнообразных проектов:
    1. Минимум резерва времени начала выполнения операции.
    2. Наименьшая продолжительность выполнения операции.
    3. Наименьший порядковый номер операции.
    Наиболее часто применяется метод распараллеливания операций.
    Этот метод представляет собой итерационный процесс, который начинается в исходной точке проекта, и
    затем исследует сетевой график период за периодом с целью определения операций, которые должны
    начаться в данном периоде.
    Если для выполнения двух или нескольких установленных таким образом операций требуются одни и те же
    ресурсы, то применяется правило приоритетности выделения ресурсов.
    Если в пятом периоде должны начаться 3 операции (т.е. они имеют тот же ES ) и требуют таких же ресурсов,
    то первой операцией на графике будет операция с наименьшим резервом времени (применяем правило 1).
    Если у всех операций резерв времени одинаков, нужно обратиться к следующему правилу (правило 2), тогда
    операция с наименьшей продолжительностью будет на графике первой.
    В очень редких случаях, когда операции имеют одинаковые резервы времени и продолжительности, связь
    нарушается операцией с самым низким идентификационным номером (правило 3).
    Когда лимит ресурсов достигнут, ранний старт (ES) последующих операций, которые еще не внесены в
    график, будет задержан (все последующие операции, не имеющие свободного резерва времени) и их резерв
    времени сократится.
    В последующие периоды процедуpa повторяется до тех пор, пока не будет составлен график всего проекта.
    Обратимся к рис. 3.4.
    Период

    Действие

    0-1

    Приемлема только операция A. Она потребует 2 ресурса. Внесите операцию A в
    график

    1-2

    Нет приемлемых операций для внесения в график

    2-3

    Операции В, С, D приемлемы для внесения в график. Операция С имеет
    наименьший резерв времени (0) - примените правило 1.
    Внесите операцию С в график.
    Следующей операцией является операция B с резервом 2; но для ее выполнения
    требуется 2 ресурса и только 1 имеется в наличии.
    Отложите операцию B. Скорректируйте ES =3, резерв =1.
    Следующая приемлемая операция D, для ее выполнения требуется 1 ресурс.
    Внесите операцию D в график
    ----------------------------------см.рис. 3.5-----------------------------------------------

    3-4

    Операция B приемлема, но превышает лимит 3 ресурсов общего фонда.
    Задержите операцию B. Скорректируйте ES = 4, резерв =0

    4-5

    Операция B приемлема, но превышает лимит 3 ресурсов общего фонда.
    Задержите операцию B. Скорректируйте ES = 5, резерв = -1. Задержите
    операцию G. Скорректируйте ES = 11, резерв = -1

    5-6

    Операция B приемлема, но превышает лимит 3 ресурсов общего фонда.
    Задержите операцию B. Скорректируйте ES = 6, резерв = -2. Задержите
    операцию G. Скорректируйте ES = 12, резерв = -2

    6-7

    Операции B,E,F приемлемы с резервами времени выполнения -2, 2, 0
    соответственно.
    Внесите операцию B в график (правило 1).
    Так как операция F имеет резерв 0, она следующая приемлемая операция.
    Внесите операцию F в график (правило 1).
    Лимит ресурсов 3 достигнут.
    Задержите операцию E. Скорректируйте ES = 7, резерв = 1

    7-8

    Лимит достигнут. Ресурсов в наличии нет.

    Задержите операцию E. Скорректируйте ES = 8, резерв = 0

    8-9

    Лимит достигнут. Ресурсов в наличии нет.
    Задержите операцию E. Скорректируйте ES = 9, резерв = -1

    9-10

    Лимит достигнут. Ресурсов в наличии нет.
    Задержите операцию E. Скорректируйте ES = 10, резерв = -2

    10-11

    Операция E приемлема.
    Внесите операцию E в график.
    (Заметьте, операция F не имеет простоя, так как нет ресурсов в наличии - 3
    максимум)

    11-12

    Нет приемлемых операций

    12-13

    Операция G приемлема.
    Внесите операцию G в график

    увеличить изображение
    Рис. 3.4. График ресурсов, подчиненных ограничению в периоды 2-3
    Важно корректировать каждый период, чтобы отражать изменения в самом начале резерва времени
    выполнения операции, чтобы действительность могла отражать изменения приоритетов.
    В сети на рис. 3.5 на графике календарного планирования указана новая дата в 14 единиц времени против
    продолжительности в 12 единиц времени проекта, подчиненного ограничениям по времени.
    Сеть была скорректирована и отражает новое время начала, окончания и резервы времени для каждой
    операции.
    Сравните резервы времени для каждой операции на рис. 3.4 и рис. 3.5; резервы времени значительно
    сократились.

    увеличить изображение
    Рис. 3.5. График ресурсов, подчиненных ограничению в периоды 5-6
    На рис. 3.6 показана другая сеть проекта, когда используются три различных типа ресурсов (A, B и С); общий
    фонд каждого типа состоит из 2 ресурсов.

    Рис. 3.6. Первоначальный план сети
    Первоначальный критический путь показан в сети пунктирной линией.
    Ниже сетевого графика приводится график потребности в ресурсах. Время ("план") и ресурсы показаны внизу
    на графике 3.6.
    Время, которое ограничивает критический путь, составляет 3, 5, 8 и 11, продолжительность проекта
    составляет 27 единиц времени.
    Ресурсы, которые ограничивают выполнение критических операций, составляют 1, 4, 5, 7, 8 и 10 при
    продолжительности проекта 20 единиц времени.
    Операции 3 и 11 уже не являются критическими и имеют резервы времени. Операции 4, 5, 7 и 8 уже являются
    не параллельными, а последовательными. Резервы времени сократились. Ресурсы A, B, и С в какой-то точке
    проекта являются критическими.

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

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

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

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

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

    Ход выполнения проекта в процентах с учетом оставшегося времени тщательно контролируется для того,
    чтобы выявить любую операцию, которая опережает установленное время завершения, и позволяет начать
    выполнение как критических, так и некритических последующих операций досрочно.
    Контролирование и поощрение раннего завершения операций обеспечивает возможность не терять время,
    а начать выполнение последующих операций раньше за счет сэкономленного при досрочном завершении
    времени.
    Смысл в том, чтобы сэкономить резерв времени, как буфер для завершения проекта досрочно, или решить
    проблему с отставанием, которая может возникнуть при выполнении критических операций в дальнейшем.
    Элиаху Голдрэт выступает за альтернативный подход управления простоями.
    Он считает, что к своим оценкам люди вполне естественно добавляют время (на всякий случай).
    Считается, что время оценки выполнения операции в срок или раньше оправдывается лишь в 80-90% случаев.
    Следовательно, среднее время (50/50) преувеличено примерно на 30-40%. Например, по оценке
    программиста существует шанс 50/50, что он сможет завершить операцию за 5 дней. Однако, чтобы
    обеспечить успех и застраховаться от потенциальных проблем, он добавляет два дня для страховки и
    сообщает, что потребуется 7 дней для завершения задачи. В этом случае среднее(50/50) время преувеличено
    на 40%.
    Эта ситуация создает интересный парадокс. Почему при наличии тенденции к преувеличению времени
    продолжительности операции многие проекты отстают от графика? Голдрэт предлагает несколько объяснений
    этому явлению.
    Первое - вся работа распределена во времени. Зачем спешить и стараться выполнить работу сегодня, если
    она должна быть выполнена завтра?
    Второе - в организации могут отсутствовать стимулы для досрочного завершения работ: качество работ
    ставится под сомнение, или считают, что рабочие всегда должны выполнять работу раньше установленного
    срока.
    Третье - раннее завершение операции не обязательно приведет к началу следующей операции, так как люди,
    выделенные на ее выполнение, не готовы начать работу раньше. Выигранное время тратится напрасно. И,
    наконец, чрезмерное количество задач увеличивает время выполнения отдельных задач.
    Голдрэт предлагает решить проблему превышения времени проекта, используя "истинную 50/50" оценку
    времени выполнения операции (а не оценку, когда шанс выполнения досрочно составляет 80-90%).
    Он предлагает ввести "временные буферы" или время подстраховки только в случаях возникновения
    потенциальных проблем.
    Буферы времени вводятся в сеть для соблюдения трех условий:

    1. Поскольку при выполнении операций всегда существует фактор неопределенности, который
    трудно предсказать, время продолжительности проекта неопределенно. Поэтому буферы времени
    добавляются к предполагаемой продолжительности - скажем, 40% от совокупной скрытой
    продолжительности операции на непредвиденные обстоятельства на критическом пути.
    2. Буфер времени слияния вводится в сеть там, где некритические пути сливаются с критическим путем.
    Эти буферы помогают предотвратить отставание операций на критическом пути.
    3. Буфер ресурса времени вводится, когда для выполнения операции требуются дефицитные ресурсы.
    Отсутствие ресурсов может вызвать появление критического пути, отличающегося от первоначального,
    и привести к задержке проекта.
    Элиах Голдрэт создал фразу "критическая цепочка" (C-C), чтобы показать, что сетевой график проекта может
    быть ограничен как ресурсами, так и логическими зависимостями. Все эти буферы сокращают риск отставания
    выполнения проекта и повышают шанс его раннего завершения.
    Сторонников у метода С-С в планировании проекта сегодня немного, но у него есть перспективы. Например,
    Harris Semiconductor сумел построить новые автоматизированные установки по производству тонких
    кристаллических пластин за 13 месяцев, используя метод С-С, тогда как обычные сроки составляют от 26
    до 36 месяцев. Авиационная промышленность в Израиле использовала метод С-С для сокращения времени
    технического обслуживания самолета с двух месяцев до двух недель.
    Успешное выполнение проекта требует, чтобы его участники сократили свою оценку времени, которое
    выделено "на всякий случай", и использовать время "50/50".

    Выгода от календарного планирования ресурсов
    Польза от создания календарного плана до начала осуществления проекта состоит в том, что остается время
    для рассмотрения приемлемых альтернатив.
    Если запланированное отставание неприемлемо или задержка слишком рискованна, то предположение
    относительно ограничений по ресурсам требуется пересмотреть.
    Альтернативы стоимости времени также могут быть пересмотрены.
    Графики потребности и использования ресурсов предоставляют информацию, необходимую для подготовки
    бюджетов поэтапной работы с определенными датами.
    Будучи однажды установлены, они дают возможность руководителю проекта быстро установить влияние
    непредвиденных событий, таких, как товарооборот, поломки оборудования или перевод персонала проекта.
    Календарное планирование ресурсов также позволяет руководителям проекта оценить эластичность
    определенных ресурсов.

    Распределение работ по проекту

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

    Команды и проекты
    В рамках проектной деятельности под "командой" понимается организационная структура проекта,
    создаваемая на период осуществления всего проекта либо одной из фаз (стадий) его жизненного цикла.
    В организационной структуре больших проектов можно выделить три типа проектных команд.
    1. Команда проекта (КП) - организационная структура проекта, в которую вовлечены как все лица,
    непосредственно выполняющие работы проекта, так и лица, представляющие интересы различных
    участников проекта.
    2. Задачей руководства команды проекта является выработка политики и утверждение стратегии проекта
    для достижения его целей.
    3. Команда управления проектом (КУП) - организационная структура команды проекта, включающая
    тех членов КП, которые вовлечены в управление проектом, в том числе представителей некоторых
    участников проекта и административно-управленческий персонал.
    4. Задачей КУП является исполнение всех управленческих функций и работ в проекте по ходу его
    осуществления.
    5. Команда менеджмента проекта (КМП) - организационная структура проекта, возглавляемая
    управляющим (главным менеджером) проекта и создаваемая на период осуществления проекта или
    одной из стадий его жизненного цикла.
    Часто в КМП входят физические лица, осуществляющие менеджерские и другие функции управления
    проектом, а также непосредственно участвующие в принятии решений.
    Главными задачами такой команды являются осуществление политики и стратегии проекта, реализация
    стратегических решений и осуществление тактического (ситуационного) менеджмента. КМП часто называют
    группой менеджмента, просто менеджментом или топ менеджментом, руководством и т. п.

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

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

    участники, которые отвечают за выполнение каждой операции.
    В табл. 3.1 показана RM для изучения возможностей рынка.
    R - ответственный
    S - помогает
    Задача

    Ричард

    Дэн

    Определение целевых покупателей

    R

    S

    Разработка проекта опросного листка

    R

    S

    Экспериментальная проверка опросного листка
    Окончательный вариант опросного листка

    Дэйв

    S

    Элизабетт

    S
    S

    R
    R

    Линда

    S
    S

    с

    Тираж опросного листка

    R

    Подготовка адресов рассылки

    R

    Рассылка опросного листка

    R

    Получение и обработка ответов

    R

    Ввод ответов в компьютер

    S

    R

    Анализ результатов
    Подготовка проекта отчета

    S

    Подготовка окончательного отчета

    R

    R

    S

    S

    R

    S

    S

    S

    "S" используется для обозначения членов команды из 5 человек, которые будут поддерживать и помогать
    работнику, ответственному за выполнение задачи.
    Такие простые матрицы особенно полезны при организации распределения ответственности за небольшие
    проекты или локальные проекты более крупных и сложных проектов.
    Более сложные матрицы ответственности не только определяют ответственность, но и выявляют критическое
    взаимодействие между подразделениями и отдельными людьми, которые требуют координации.
    Например, табл. 3.2 представляет матрицу более крупного и сложного проекта, требующего разработки нового
    блока испытательного оборудования.
    Каждая ячейка с цифровым кодом используется для определения характера вовлечения в выполнение
    конкретной задачи.
    Список
    1. Ответственность

    2. Поддержка
    3. Консультация
    4. Уведомление
    5. Одобрение
    Организация
    Промежуто
    чные этапы
    работы

    Проект Разработк Документаци
    а
    я

    Архитектурный
    проект

    1

    2

    Технические
    2
    характеристики
    оборудования

    1

    Спецификация
    ядра
    программы

    1

    3

    Спецификация
    обслуживающи
    х программ

    2

    1

    Дизайн
    оборудования

    1

    Дисководы

    3

    1

    Управление
    памятью

    1

    3

    Документация
    оперирующей
    системы

    2

    2

    Прототипы

    5

    Комплексные
    испытания

    5

    Сборк
    а

    Испытани
    е

    2

    3

    2

    Производств
    о

    3

    3

    3

    3

    3

    3

    3

    2
    3

    1

    4
    2

    Закупка Гара
    нтия
    качества

    2

    3

    1

    3
    1

    3

    3

    4

    5

    5

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

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

    Управление трудовыми ресурсами проекта и менеджмент человеческих ресурсов проекта
    Персонал - это конкретные индивидуумы, частью которых является их квалификация, исполнение
    функционально-должностных обязанностей и проч., что описывается в рамках штатного расписания проекта.
    Планировать можно то, что поддается измерению. В рамках организационного планирования проекта
    проводится расчет требующихся для его осуществления трудовых ресурсов.
    Во всех специализированных программных продуктах (ПП) по управлению проектами используются блоки по
    управлению штатом и трудовыми ресурсами с хорошими коммуникационными возможностями для совместной
    работы персонала по проекту. Но этого недостаточно.
    Для проекта важно понимание границ применимости программных продуктов в области управления
    человеческими ресурсами: там, где речь идет об "управлении человеком" как измеряемым ресурсом, там
    использование специализированных программных продуктов по управлению проектами достаточно.
    В проектах, в которых человеческий фактор имеет решающее значение, ориентация только на
    управление "трудовыми ресурсами" и "штатом" без учета организационной и профессиональной культур,
    индивидуальных особенностей членов команд и других плохо идентифицируемых и измеряемых
    характеристик команд часто приводит к конфликтам и неуспеху всего проекта.

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

    Стратегия.
    Определение стратегии предполагает обследование системы. Основная задача обследования - оценка
    реального объема проекта, его целей и задач, а также получение определений сущностей и функций на
    высоком уровне.
    На этом этапе привлекаются высококвалифицированные бизнес-аналитики, которые имеют постоянный
    доступ к руководству фирмы; этап предполагает тесное взаимодействие с основными пользователями
    системы и бизнес-экспертами. Основная задача взаимодействия - получить как можно более полную
    информацию о системе (полное и однозначное понимание требований заказчика) и передать данную
    информацию в формализованном виде системным аналитикам для последующего проведения этапа анализа.
    Как правило, информация о системе может быть получена в результате бесед или семинаров с руководством,
    экспертами и пользователями. Таким образом определяются суть данного бизнеса, перспективы его развития
    и требования к системе.
    По завершении основной стадии обследования системы технические специалисты формируют вероятные
    технические подходы и приблизительно рассчитывают затраты на аппаратное обеспечение, закупаемое
    программное обеспечение и разработку нового программного обеспечения (что, собственно, и предполагается
    проектом).
    Результатом этапа определения стратегии является документ, где четко сформулировано, что получит
    заказчик, если согласится финансировать проект; когда он получит готовый продукт (график выполнения
    работ); сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на
    разных этапах работ). В документе должны быть отражены не только затраты, но и выгода, например время
    окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
    В документе обязательно должны быть описаны:
    ● ограничения, риски, критические факторы, влияющие на успешность проекта, например время реакции
    системы на запрос является заданным ограничением, а не желательным фактором;
    ● совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура
    системы, аппаратные и программные ресурсы, предоставляемые системе, внешние условия ее
    функционирования, состав людей и работ, которые обеспечивают бесперебойное функционирование
    системы;
    ● сроки завершения отдельных этапов, форма сдачи работ, ресурсы, привлекаемые в процессе
    разработки проекта, меры по защите информации;
    ● описание выполняемых системой функций;
    ● будущие требования к системе в случае ее развития, например возможность работы пользователя с
    системой с помощью Интернета и т.п.;
    ● сущности, необходимые для выполнения функций системы;
    ● интерфейсы и распределение функций между человеком и системой;
    ● требования к программным и информационным компонентам ПО, требования к СУБД (если проект
    предполагается реализовывать для нескольких СУБД, то требования к каждой из них, или общие
    требования к абстрактной СУБД и список рекомендуемых для данного проекта СУБД, которые
    удовлетворяют заданным условиям);
    ● что не будет реализовано в рамках проекта.
    Методы проектирования информационных систем
    Методы проектирования ИС можно классифицировать по степени использования средств автоматизации,

    типовых проектных решений, адаптивности к предполагаемым изменениям.
    Так, по степени автоматизации методы проектирования разделяются на:
    ручное, при котором проектирование компонентов ИС осуществляется без использования специальных
    инструментальных программных средств, а программирование — на алгоритмических языках;
    компьютерное, при котором производится генерация или конфигурирование (настройка) проектных решений
    на основе использования специальных инструментальных программных средств.
    По степени использования типовых проектных решений различают следующие методы проектирования:
    оригинальное (индивидуальное), когда проектные решения разрабатываются «с нуля» в соответствии с
    требованиями к АИС. Характеризуется тем, что все виды проектных работ ориентированы на создание
    индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его
    особенности;
    типовое, предполагающее конфигурирование ИС из готовых типовых проектных решений (программных
    модулей). Выполняется на основе опыта, полученного при разработке индивидуальных проектов. Типовые
    проекты, как обобщение опыта для некоторых групп организационно-экономических систем или видов работ,
    в каждом конкретном случае связаны со множеством специфических особенностей и различаются по степени
    охвата функций управления, выполняемым работам и разрабатываемой проектной документации.
    По степени адаптивности проектных решений выделяют методы:
    реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих
    компонентов (перепрограммирования программных модулей);
    параметризации, когда проектные решения настраиваются (генерируются) в соответствии с изменяемыми
    параметрами;
    реструктуризации модели, когда изменяется модель проблемной области, на основе которой автоматически
    заново генерируются проектные решения.
    Сочетание различных признаков классификации методов обусловливает характер используемых технологий
    проектирования ИС, среди которых выделяют два основных класса: каноническую и индустриальную
    технологии. Индустриальная технология проектирования, в свою очередь, разбивается на два подкласса:
    автоматизированное (использование CASE-технологий) и типовое (параметрически-ориентированное или
    модельно-ориентированное) проектирование. Использование индустриальных технологий не исключает
    использования в отдельных случаях канонических.
    14.Анализ объекта автоматизации. Методологии анализа.
    Каждый аналитик, приступая к анализу системы, должен ориентироваться на минимальный “джентльменский
    набор” стартовых условий, в состав которого входят:
    - Информация об объекте проектирования - ИС предприятия (“черный ящик”).
    - Знания о предметной области, в которой работает предприятие (они могут быть получены путем
    предварительного изучения объекта и /или на основании опыта).
    - Знания об эталонных процедурах выполнения ключевых процессов в соответствии с международными или
    национальными стандартами.
    - Знания о методах и средствах моделирования и анализа систем.
    - Программные средства (инструменты) для моделирования и анализа.
    - Ограничения на создаваемую систему, связанные с реальными возможностями и существующими
    традициями предприятия (особенностями финансирования, корпоративной культуры и т. д.), чаще всего не
    отраженными в условиях договора на создание ИСУП. Информационная система управления проектами

    Формальный перечень работ, которые необходимо выполнить на начальных этапах анализа системы,
    практически не зависит от того, какие методологии и инструменты будут использованы для моделирования и
    анализа. От инструментов зависит только результат.
    В процессе разработки ИСУП выполняются три уровня анализа, каждый из которых соответствует трем
    основным стадиям создания ИСУП:
    - определение требований;
    - формирование спецификаций;
    - внедрение.
    Определение требований начинается со сбора информации об исходной системе. После предварительного
    экспресс-анализа собранная информация отображается в виде моделей текущего состояния объекта
    проектирования. Анализ этих моделей позволяет изучить особенности функционирования объекта, выявить
    имеющиеся узкие места, определить недостатки в организации процессов, структур, используемых систем и т.
    д.
    Следующий шаг - создание концептуальных моделей будущей ИСУП. На этом этапе происходит наложение
    знаний о предметной области и эталонных знаний на знания об объекте проектирования, представленные в
    виде моделей текущего состояния. Результатом первого уровня анализа чаще всего становится техническое
    задание на ИСУП.
    Формирование спецификаций сопровождается выпуском проекта ИСУП, составной частью которого являются
    модели. На этом шаге обычно принимаются во внимание ограничения, которые необходимо учитывать в
    моделях ИСУП.
    Третий уровень анализа - внедрение - связан с конкретной реализацией проекта ИСУП на предприятии.
    При выполнении работ по моделированию на каждом из трех представленных выше уровней могут быть
    использованы различные инструментальные средства. Вместе с тем необходимость комплексного анализа
    при создании ИСУП оказывает существенное влияние на выбор инструментов моделирования.
    В зависимости от класса создаваемой ИСУП для решения задачи выбора инструмента моделирования
    целесообразно классифицировать существующие инструментальные средства в соответствии с имеющейся
    классификацией ИСУП (см. PC Week/RE, № 44/98, с. 21).
    Методологии проектирования ИС с использованием CASE-средств
    В настоящее время существует два основных подхода к проектированию:
    ○ Функционально-ориентированный (структурный);
    ○ Объектно-ориентированный.




    В основе функционально-ориентированного подхода лежат две идеи:
    Декомпозиция;
    Графическое представление.

    В настоящее время в качестве основных средств структурного анализа и проектирования используют
    следующие виды диаграмм:
    ● Business Function Diagram (BFD) – диаграммы функциональных спецификаций. Позволяют представить
    общую структуру исследуемого объекта, отражающую взаимосвязь различных задач в процессе
    получения требуемых результатов. Основные элементы BFD – это функции (некоторые действия,
    необходимые для решения поставленных задач) и декомпозиции функций (разбиение функции на

    множество подфункций). На практике диаграмма функциональных спецификаций, используется,
    например, для верификации диаграмм сущность-связь при проектировании базы данных ИС.
    ● Диаграммы SADT (диаграммы работ и объектов).
    ● Диаграммы потоков данных (DFD).
    ● State Transition Diagram (STD) – диаграммы переходов состояний. Моделируют поведение системы
    во времени в зависимости от произошедших событий. Позволяют осуществить декомпозицию
    управляющих процессов, происходящих в системе и описать отношение между управляющими
    потоками. С формальной точки зрения, диаграммы переходов состояний описывают некоторый
    конечный автомат. К основным элементам диаграммы перехода состояний относятся:
    o
    Состояние – устойчивое значение некоторого свойства в течение определенного времени.
    В каждый момент времени система находится строго в одном состоянии. Находясь в
    текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие
    перехода в следующее состояние.
    o
    Начальное состояние – узел диаграммы, являющийся стартовой точкой для начального
    системного перехода. В диаграмме может быть множество конечных состояний, но только
    одно начальное.
    o
    Переход – определяет перемещение моделируемой системы из одного состояния в другое.
    Имя перехода определяется событием, которое вызвало этот переход. Переход может быть
    вызван каким-либо действием.
    o
    Триггер – логическое выражение, написанное на каком-либо макроязыке, которое
    показывает условие перехода в данное состояние.
    Применяется два способа построения ST-диаграммы. Первый способ заключа-ется в идентификации всех
    возможных состояний и дальнейшем исследо-вании всех не бессмысленных связей (переходов) между ними.
    По второ-му способу сначала строится начальное состояние, затем следующие за ним и т.д. В результате
    формируется предварительная диаграмма перехода состояний, для которой необходимо выполнить контроль
    состоятельности. Обычно он заключается в отве-те на следующие вопросы;
    ■ все ли состояния определены и имеют уникальное имя?
    ■ все ли состояния достижимы?
    ■ все ли состояния имеют выход?
    ■ реагирует ли система соответствующим об-разом на все возможные условия (особенно на
    ненормальные)?
    ■ все ли входные (выходные) потоки управляющего процесса отражены в условиях диаграммы?
    ■ Диаграммы инфологических моделей «сущность-связь».
    ■ System Structure Diagram (SSD) – Диаграммы структуры программного приложения ИС.
    Представляют собой иерархическую взаимосвязь программных модулей, которые реализуют ИС.
    Диаграмма SSD служит «мостом» для перехода от системных требований, которые отображены в
    таких диаграммах, как BFD, DFD, ERD и STD, к реализации информационной системы.
    15.Анализ объекта автоматизации. Инструментальные средства поддержки процессов анализа.
    Классификация инструментальных средств
    Инструментальные средства, предназначенные для моделирования информационных систем, могут быть
    отнесены к одной из следующих категорий:
    - локальные, поддерживающие один-два типа моделей и методов (Design/IDEF, ProCap, S-Designor, “CASE.
    Аналитик”);

    - малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов
    (ERwin, BPwin);
    - средние интегрированные средства моделирования, поддерживающие от 4 до 10-15 типов моделей и
    методов (Rational Rose, Paradigm Plus, Designer/2000);
    - крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов
    (ARIS Toolset).
    При разработке ИСУП локальные средства моделирования могут быть использованы только на
    концептуальном уровне для предварительного анализа или как средство демонстрации заказчику общих
    предложений по будущему проекту. Задача комплексного анализа системы локальными средствами не может
    быть решена.
    Малые интегрированные средства моделирования, как правило, “исторически выросли” из локальных. Так
    же, как и последние, они изначально не были ориентированы на комплексный анализ систем. Возможности
    по интеграции различных моделей в рамках общей модели появились в процессе совершенствования и
    развития этих программных средств. Характерными особенностями этой категории является наличие в
    инструментальном средстве независимых компонентов и интеграция моделей путем экспорта и импорта
    данных (рис. 1).

    Рис. 1. Применение локальных, малых и средних интегрируемых
    средств моделирования на различных этапах создания ИСУП
    Типичный представитель малых интегрированных средств моделирования - комплект программных продуктов
    Platinum Technology (CA/ Platinum/Logic Works), основанный на популярных пакетах BPwin и Erwin.
    BPwin. Поддерживает три методологии моделирования: IDEF0 (диаграммы функций), IDEF3 (только
    диаграммы процессов), DFD (диаграммы потоков данных) и обеспечивает интеграцию моделей трех типов
    без экспорта или импорта данных. Интеграция выполняется как путем слияния нескольких моделей, так и
    посредством переключения на различные методологии в процессе разработки отдельных диаграмм модели.
    Предусмотрено расширение возможностей анализа систем как в самом пакете BPwin (функциональностоимостный анализ), так и с помощью экспорта данных в другие пакеты.
    ERwin. Поддерживает несколько разновидностей методологии информационного моделирования, основанной
    на ER-диаграммах (сущность - связь). Интеграция моделей BPwin с моделями ERwin выполняется путем
    обмена данными через функции экспорта/импорта.
    Малые интегрированные системы, так же как и локальные, практически не позволяют выполнить

    комплексный анализ систем, который в большей или меньшей степени необходим для создания малых,
    средних и крупных ИСУП. С их помощью можно разрабатывать локальные ИСУП или небольшие подсистемы,
    предназначенные для автоматизации отдельных бизнес-цепочек, т. е. когда нет необходимости в комплексном
    анализе предприятия. Типичная сфера использования малых интегрированных средств - решение задач так
    называемой “кусочной” автоматизации предприятия.
    Средние интегрированные средства моделирования. Эта категория представлена программными
    продуктами, при создании которых изначально были заложены требования комплексного использования
    различных методов и типов моделей. Продукты средней категории имеют единую среду для разработки всех
    поддерживаемых типов моделей, что позволяет применять одни и те же объекты в разных моделях.
    К средним интегрированным средствам можно отнести такие известные продукты, как Rational Rose (Rational
    Software), Paradigm Plus (CA/Platinum), Designer/2000 (Oracle).
    Rational Rose и Paradigm Plus основаны на объектно-ориентированном подходе к моделированию и
    ориентированы на метод UML (Unified Modeling Language).
    Помимо UML поддерживаются и другие методы. Отличия между Rational Rose и Paradigm Plus состоят в
    основном в доступных пользователю типах диаграмм и методов.
    Последние версии Rational Rose позволяют строить восемь типов диаграмм UML: диаграммы прецедентов
    (Use Cases Diagrams), диаграммы классов (Class Diagrams), диаграммы последовательности (Sequence
    Diagrams), диаграммы сотрудничества (Collaboration Diagrams), диаграммы состояний (State Diagrams),
    диаграммы действий (Activity Diagrams), компонентные диаграммы (Component Diagrams), диаграммы
    развертывания (Deployment Diagram). Основным типом диаграмм, своеобразным ядром моделирования в
    UML являются диаграммы классов. Кроме UML предусмотрено использование и других методов (Booch, OMT).
    Пакет применим на всех стадиях и циклах создания ИСУП (рис. 2).

    Рис. 2. Диаграммы классов - ключевой тип диаграмм Rational Rose
    Пакет Paradigm Plus ориентирован на методологию OOCL (Object Oriented Change and Learning) и
    компонентную технологию проектирования и разработки. Он поддерживает диаграммы различных методов
    (UML, CLIPP, TeamFusion, OMT, Booch, OOCL, Martin/Odell, Shlaer/ Mellor, Coad/Yourdon). Пакет может быть
    использован на всех циклах создания ИСУП (рис. 3).

    Рис. 3. Циклическое использование моделей Paradigm Plus при создании ИСУП
    В состав Designer/2000 входят Process Modeller и System Modeller. Process Modeller предназначен для
    разработки моделей процессов, а System Modeller - для моделей иерархии функций (Function Hierarchy
    Diagrammer), моделей потоков данных (Dataflow Diagrammer) и моделей типа сущность - отношение (Entity
    Relationship Diagrammer) (рис. 4).

    Рис. 4. Модели Designer/2000
    Process Modeller позволяет повысить наглядность представления процессов за счет анимации и
    использования мультимедийных файлов, он пригоден для всех стадий разработки ИСУП.
    Средства моделирования среднего класса предназначены для выполнения комплексного анализа систем.
    Они могут быть успешно применены при создании малых и средних ИСУП, особенно с этапа анализа
    спецификаций. Слабая сторона - недостаточные возможности для моделирования и анализа на верхнем
    уровне (анализ требований).
    Крупные интегрированные средства моделирования. К этой категории относится инструментальное средство,
    специально предназначенное для проектирования крупных ИСУП, таких, например, как системы управления
    предприятием класса ERP.
    Это - семейство ARIS (ARIS Toolset, ARIS Easy Design) компании IDS Sheer AG. В ARIS воплощен
    практический опыт множества аналитиков, работающих в области проектирования ИСУП, а также учтены
    недостатки существующих инструментальных средств. Отличительная особенность ARIS - особое внимание к

    первому уровню анализа (анализ требований) (рис. 5).

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

    использовать при создании локальных, малых или средних ИСУП, не относящихся к классу ERP (рис. 6).

    Рис. 6. Оценка применимости инструментальных средств для анализа ИСУП
    Из рассмотренных выше инструментальных средств к категории ERP можно отнести только ARIS.
    ARIS обеспечивает четыре различных “взгляда” на моделирование и анализ. Для каждого “взгляда”
    поддерживаются три уровня анализа (требования, спецификации, внедрение). Каждый из уровней анализа
    состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и
    др. Каждый объект моделей ARIS имеет (рис. 7) множество атрибутов, которые позволяют контролировать
    процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа,
    имитационного моделирования, взаимодействия с workflow-системами и т. д.

    Рис. 7. Количество типов моделей ARIS для
    разных “взглядов” и уровней моделирования
    “Взгляды” ARIS: Процессы, Функции (с Целями), Данные, Организация - являются “комнатами”, из которых
    состоит так называемый домик ARIS. Главная “комната” домика ARIS (основной “взгляд”) - Процессы, для
    моделирования которых предназначено 57 типов моделей из 85. Процессный взгляд является характерной
    особенностью и для ERP- систем, предназначенных для автоматизации процессов, пронизывающих
    организационную структуру предприятия.
    Понятие домика ARIS позволяет не только наглядно представить “взгляды” на моделирование. Домик
    используется и в процессе моделирования для выбора комплекта моделей, соответствующего “взгляду” и

    уровню анализа.
    Резюме. Все рассмотренные выше инструментальные средства широко используются для моделирования и
    анализа систем, в том числе и при создании ИСУП.
    Среди локальных и малых инструментальных средств весьма популярными остаются программы, основанные
    на реализации структурного подхода к анализу и проектированию систем и методологий IDEF. Несмотря на
    почтенный возраст, направление IDEF развивается и сегодня, правда, в основном в США. На сайте Knowledge
    Based Systems, Inc. (www.kbsi.com) содержится информация о методологиях IDEF0, IDEF1, IDEF1X, IDEF3,
    IDEF4, IDEF5, IDEF6, IDEF8, IDEF9, IDEF14 и инструментальных средствах их поддержки (AI0 WIN, SmartER,
    ProCap и др.). Все они относятся к категории локальных инструментальных средств.
    Среди малых инструментальных средств доминируют пакеты BPwin и ERwin компании Platinum. Эти пакеты,
    например, являются стандартными средствами для анализа процессов в НАТО.
    Локальные и малые инструментальные средства могут быть использованы при разработке соответственно
    локальных и малых ИСУП. Для средних и крупных ИСУП использование этих средств имеет смысл в качестве
    дополнения к более универсальному инструментальному средству средней категории.
    Средства моделирования средней категории, как правило, основаны на использовании объектноориентированного подхода к моделированию и анализу систем. Фактическим стандартом для этой категории
    инструментальных средств является унифицированный язык моделирования UML.
    По данным исследовательской компании International Data Corporation, среди инструментальных средств,
    которые можно отнести к этой категории, лидирующее положение занимает пакет Rational Rose. Прибыль от
    продажи Rational Rose за 1998 г. превышает суммарную прибыль от продажи продуктов четырех ближайших
    конкурентов: STERLING, SELECT, Platinum, AONIX www.rational.com/products/rose/prodinfo/2000ds.jtmpl).
    Средние интегрированные средства предназначены в основном для уровней анализа спецификаций и
    внедрения. Они удобны при разработке средних, малых и локальных ИСУП. Недостаточные возможности для
    анализа на уровне требований могут быть компенсированы путем их использования вместе с локальными или
    малыми инструментальными средствами.
    Система ARIS как крупное интегрированное средство моделирования имеет уникальные возможности
    для моделирования и анализа систем. Моделирование в ARIS может выполняться как “сверху вниз”, так
    и “снизу вверх”. Для конкретных разработок количество используемых типов моделей и методик может быть
    ограничено с помощью специальных фильтров. Система позволяет контролировать процесс моделирования
    и выполнять расширенный анализ системы: определение целей и критических факторов, оценку рисков и
    конкурентов и др. Система ARIS предоставляет аналитикам возможность интегрированного “управления
    всеми ресурсами”, необходимыми для использования на всех уровнях анализа при разработке ИСУП любой
    сложности.

    16.Анализ объекта автоматизации. Методологии анализа. SADT, ГОСТ 50.1.028.
    SADT (акроним от англ. Structured Analysis and Design Technique) — методология структурного анализа и
    проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование

    дополнительных языковых средств и руководство проектом со своим графическим языком.
    Описание системы с помощью SADT называется моделью. В SADT-моделях используются как естественный,
    так и графический языки. Для передачи информации о конкретной системе источником естественного языка
    служат люди, описывающие систему, а источником графического языка - сама методология SADT. С точки
    зрения SADT модель может быть сосредоточена либо на функциях системы, либо на ее объектах. SADTмодели, ориентированные на функции, принято называть функциональными моделями, а ориентированные
    на объекты системы - моделями данных, функциональная модель представляет с требуемой степенью
    детализации систему функций, которые в свою очередь отражают свои взаимоотношения через объекты
    системы. Полная методология SADT поддерживает создание множества моделей для более точного описания
    сложной системы.
    Элементы диаграммы SADT:
    ● основной блок с именем действия или процесса
    ● слева в блок входят начальные данные (например, ресурсы, из которых с помощью действия из
    основного блока мы получим готовый результат)
    ● сверху в блок входят важные для совершения действия данные (например, документация, следуя
    которой мы будем совершать над ресурами описываемый процесс)
    ● снизу в блок входят необходимые для совершения действия ресурсы (например, оборудование, на
    котором будет совершаться описываемое действие)
    ● справа из блока выходит готовый результат
    Пример базового элемента:

    Пример диаграммы:

    Линки:
    http://www.interface.ru/fset.asp?Url=/case/sadt4.htm
    http://en.wikipedia.org/wiki/Sadt

    Р 50.1.028-2001 Информационные технологии поддержки жизненного цикла продукции.
    Методология функционального моделирования
    В США в конце 70-х годов была предложена и реализована Программа интегрированной компьютеризации
    производства ICAM (Integrated Computer Aided Manufacturing), направленная на увеличение эффективности
    промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.
    Реализация программы ICAM потребовала создания адекватных методов анализа и проектирования
    производственных систем и способов обмена информацией между специалистами, занимающимися
    такими проблемами. Для удовлетворения этой потребности в рамках программы ICAM была разработана
    методология моделирования IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и
    характеристики производственно-технических и организационно-экономических систем. Общая методология
    IDEF состоит из трех частных методологий моделирования, основанных на графическом представлении
    систем:
    IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а

    также потоки информации и материальных объектов, преобразуемые этими функциями;
    IDEF1 применяется для построения информационной модели, отображающей структуру и содержание
    информационных потоков, необходимых для поддержки функций системы;
    IDEF2 позволяет построить динамическую модель меняющихся во времени поведения функций, информации
    и ресурсов системы.
    Синтаксис графического языка:
    Блок.
    Блок описывает функцию. Внутри каждого блока помещаются его имя и номер. Имя должно быть активным
    глаголом или глагольным оборотом, описывающим функцию. Номер блока размещается в правом нижнем
    углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте.
    Стрелка.
    Стрелка формируется из одного или нескольких отрезков прямых и наконечника на одном конце. Сегменты
    стрелок могут быть прямыми или ломаными; в последнем случае горизонтальные и вертикальные отрезки
    стрелки сопрягаются дугами, имеющими угол 90°. Стрелки не представляют поток или последовательность
    событий, как в традиционных блок-схемах потоков или процессов (потоковых диаграммах). Они лишь
    показывают, какие данные или материальные объекты должны поступить на вход функции для того, чтобы эта
    функция могла выполняться.
    Семантика:
    Поскольку IDEF0 есть методология функционального моделирования, имя блока, описывающее функцию,
    должно быть глаголом или глагольным оборотом. Например имя блока «Выполнить проверку» означает, что
    блок с таким именем превращает непроверенные детали в проверенные.
    Каждая сторона функционального блока имеет стандартное назначение с точки зрения связи блок/
    стрелки. В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее
    роль. Стрелка(и), входящая(ие) в левую сторону блока, - вход(ы). Входы преобразуются или расходуются
    функцией, чтобы создать то, что появится на ее выходе. Стрелка(и), входящая(ие) в блок сверху, управление(я). Управление(я) определяет(ют) условия, необходимые функции, чтобы произвести правильный
    выход. Стрелка(и), покидающая(ие) блок справа, - выход(ы), то есть данные или материальные объекты,
    произведенные функцией.
    Стрелки, подключенные к нижней стороне блока, представляют механизмы, то есть все то, с помощью
    чего осуществляется преобразование входов в выходы. Стрелки, направленные вверх, идентифицируют
    средства, поддерживающие выполнение функции. Другие средства могут наследоваться из родительского
    блока. Стрелки механизма, направленные вниз, являются стрелками вызова. Стрелки вызова обозначают
    обращение из данной модели или из данной части модели к блоку, входящему в состав другой модели или
    другой части модели, обеспечивая их связь, то есть разные модели или разные части одной и той же модели
    могут совместно использовать один и тот же элемент (блок).
    Пример диаграммы:

    Линк: http://www.znaytovar.ru/gost/2/R_5010282001_Informacionnye_te.html
    17.Анализ объекта автоматизации. Методологии анализа. RUP, UML.

    RUP (полный копипаст статьи с вики - http://ru.wikipedia.org/wiki/Rational_Unified_Process)
    Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией
    Rational Software.

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

    ● Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
    ● Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
    ● Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит
    архитекторам.

    Жизненный цикл разработки
    RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от
    2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать
    или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного
    продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать
    и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого
    продукта.
    Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя
    одну или несколько итераций:
    1. Начало (Inception)
    В фазе Начало:







    Формируются видение и границы проекта.
    Создается экономическое обоснование (business case).
    Определяются основные требования, ограничения и ключевая функциональность продукта.
    Создается базовая версия модели прецедентов.
    Оцениваются риски.

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






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

    Успешное выполнение фазы разработки означает достижение вехи архитектуры жизненного цикла (англ.
    Lifecycle Architecture Milestone).

    3. Построение (Construction)
    Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение
    завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial
    Operational Capability).
    4. Внедрение (Transition)
    Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику.
    Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества
    продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным
    в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи
    готового продукта (Product Release) и завершение полного цикла разработки.
    Графическое представление процесса разработки по RUP:

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

    кодогенерация.
    Использование UML не ограничивается моделированием программного обеспечения. Его также используют
    для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
    UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических
    обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization),
    объединение (aggregation) и поведение), и больше сконцентрироваться на проектировании и архитектуре.
    Словарь UML:
    Модель представляется в виде сущностей и отношений между ними, которые показываются на диаграммах.
    Сущности - это абстракции, являющиеся основными элементами моделей. Имеется четыре типа сущностей
    - структурные (класс, интерфейс, компонент, вариант использования, кооперация, узел), поведенческие
    (взаимодействие, состояние), группирующие (пакеты) и аннотационные (комментарии). Каждый вид сущностей
    имеет свое графическое представление.
    Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:
    ● Зависимость показывает такую связь между двум сущностями, когда изменение одной из них независимой - может повлиять на семантику другой - зависимой. Зависимость изображаетс пунктирной
    стрелкой, направленной от зависимой сущности к независимой.
    ● Ассоциация - это структурное отношение, показывающее, что объекты одной сущности связаны с
    объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые
    сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация
    между классами <Заказ> и <Товар> может быть использована для нахождения всех товаров, указанных
    в конкретном заказе - с одной стороны, или для нахождения всех заказов в которых есть данный
    товар, - с другой. Понятно, что в соответствующих программах должен быть реализован механизм,
    обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно
    показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование отношение вида <целое> - <часть>. Графически оно выделяется с помощью ромбика на конце около
    сущности-целого.
    ● Обобщение - это отношение между сущностью-родителем и сущностью-потомком. По существу, это
    отношение отражает свойство наследования для классов и объектов. Обобщение показывается в
    виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок
    наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь
    новые элементы структуры и новые методы. UML допускает множественное наследование, когда
    сущность связана более чем с одной родительской сущностью.
    ● Реализация - отношение между сущностью, определяющей спецификацию поведения (интерфейс) с
    сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно
    используется при моделировании компонент
    В UML используются следующие виды диаграмм:
    Структурные диаграммы:
    ● Диаграмма классов
    ● Диаграмма компонентов
    ● Композитной/составной структуры

    ○ Диаграмма кооперации (UML2.0)





    Диаграмма развёртывания
    Диаграмма объектов
    Диаграмма пакетов
    Диаграмма профилей (UML2.2)

    Диаграммы поведения:
    ● Диаграмма деятельности
    ● Диаграмма состояний
    ● Диаграмма прецедентов
    ● Диаграммы взаимодействия:
    ○ Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
    ○ Диаграмма обзора взаимодействия (UML2.0)
    ○ Диаграмма последовательности
    ○ Диаграмма синхронизации (UML2.0)
    Что обеспечивает UML:
    ● иерархическое описание сложной системы путем выделени пакетов;
    ● формализацию функциональных требований к системе с помощью аппарата вариантов использования;
    ● детализацию требований к системе путем построения диаграмм деятельностей и сценариев;
    ● выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;
    ● выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;
    ● описание процессов взаимодействия объектов при выполнении системных функций;
    ● описание поведения объектов в виде диаграмм деятельностей и состояний;
    ● описание программных компонент и их взаимодействия через интерфейсы;
    ● описание физической архитектуры системы.
    Диаграмма классов UML на примере структуры UML диаграмм:

    Линки:
    http://ru.wikipedia.org/wiki/UML
    http://shepelin.com/technology/uml.html
    18.Анализ объекта автоматизации. Методологии анализа. ARIS.
    Методология ARIS
    Одной из современных методологий бизнес-моделирования, получившей широкое распространение в
    России является методология ARIS, которая расшифровывается как Architecture of Integrated Information
    Systems - проектирование интегрированных информационных систем.
    Методология ARIS на данный момент времени является наиболее объемной и содержит около 100
    различных бизнес-моделей, используемых для описания, анализа и оптимизации различных аспектов
    деятельности организации. Часть моделей методологии ARIS используются в настроечном модуле
    интегрированной информационной системы SAP/R3, который применяется при внедрении системе и ее
    настройке на деятельности компании. В виду большого количества бизнес-моделей методология ARIS делит
    их на четыре группы (рис. 15):
    Группа "Оргструктура".
    Состоит из моделей с помощью которых описывается организационная структура компании, а также другие
    элементы внутренней инфраструктуры организации.
    Группа "Функции".
    Состоит из моделей, используемых для описания стратегических целей компании, функций и прочих
    элементов функциональной деятельности организации.
    Группа. "Информация".
    Состоит из моделей с помощью которых описывается информация, используем ая в деятельности

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

    Рис. 15. Группы моделей методологии ARIS.
    Большим преимуществом методологии ARIS является эргономичность и высокая степень визуализации
    бизнес-моделей, что делает данную методологию удобной и доступной в использовании всеми
    сотрудниками компании, начиная от топ-менеджеров и заканчивая рядовыми сотрудниками. В методологии
    ARIS смысловое значение имеет цвет, что повышает восприимчивость и читабельность схем бизнесмоделей. Например, структурные подразделения по умолчанию изображаются желтым цветом, бизнеспроцессы и операции - зеленым. Помимо большего количества моделей по сравнению с другими
    методологиями, методология ARIS имеет наибольшее количество различных объектов, используемых
    при построении бизнес-моделей, что увеличивает их аналитичность. Например, материальные и
    информационные потоки на процессных схемах обозначаются разными по форме и цвету объектами, что
    позволяет быстро определить тип потока.
    Несмотря на большее количество моделей в методологии ARIS в проектах по описанию и оптимизации
    деятельности в общем случае их используется не более десяти. Методология ARIS позиционирует себя
    как конструктор, из которого под конкретный проект в зависимости от его целей и задач разрабатывается
    локальная методология, состоящая из небольшого количества требуемых бизнес-моделей и объектов. В
    общем случае практика показала, что в проектах наиболее часто используются модели, приведенные в
    таблице 7.
    Таблица 7. Наиболее часто используемые на практике модели методологии ARIS.


    1.

    Название модели

    Описание и предназначение
    модели

    Английский вариант

    Русский
    вариант

    OD-Objective diagram.

    Диаграмма целей.

    Модель описывает стратегические

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

    PST-Product/Service tree.

    Дерево продуктов
    и услуг.

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

    3.

    FT-Function tree.

    Дерево функций.

    Модель описывает функции,
    выполняемые в компании и их
    иерархию.

    4.

    FAD-Function allocation diagram.

    Диаграмма
    окружения
    процесса.

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

    5.

    VACD-Value added chain
    diagram.

    Диаграмма
    цепочки
    добавленной
    стоимости.

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

    6.

    PSM - Process selection matrix.

    Матрица выбора
    процесса.

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

    7.

    eEPC - Extended event driven
    Process Chain.

    Расширенная
    цепочка
    процессов,
    управляемая
    событиями.

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

    8.

    ORG - Organizational chart.

    Модель
    организационной
    структуры.

    Модель описывает
    организационную структуру
    компании.

    9.

    ASTD-Application system type
    diagram.

    Диаграмма типов
    информационных
    систем.

    Модель описывает структуру
    информационных систем,
    используемых в компании.

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

    Рис. 16. Модель "Диаграмма целей" - OD/ARIS.
    Модель "Дерево продуктов и услуг" - PST применяется для описания продуктов и услуг, производимых
    в компании, а также и связи со стратегическими целями компании, бизнес-процессами, поддерживающими
    их производство (рис. 17).

    Рис. 17. Модель "Дерево продуктов и услуг - PST/ARIS".
    Модель "Дерево функций" - FT описывает функции, выполняемые в компании и их иерархию. Данная
    модель часто применяется для для построения дерева бизнес-процессов компании (рис. 18).

    Рис. 18. Модель "Дерево функций" - PST/ARIS.
    Модель "Диаграмма окружения процесса" - FAT позволяет описать окружение или границы бизнеспроцесса, показывая его входы, выходы, поставщиков и клиентов (рис. 19).

    Рис. 19. Модель "Диаграмма окружения процесса" - PST/ARIS.
    Модель "Диаграмм цепочки добавленной стоимости" - VACD является прототипом классического
    DFD-стандарта и используется для описания бизнес-процессов верхнего уровня. Дополнительным отличием
    данной и других процессных моделей является то, что информационные и материальные потоки на схеме
    VACD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой
    объект. На модели VACD методологии ARIS в отличие от классического подхода также используется
    логические связи между работами, которые позволяют отобразить логическую последовательность
    выполнения работ. В качестве одного из вариантов логической последовательности может выступать
    временная последовательность выполнения работ, что характерно для классического подхода WFD. (рис.
    20).

    Рис. 20. Модель "Расширенная цепочка процессов, управляемая событиями" - eEPC/ARIS.
    Модель "Матрица выбора процесса" - PSM является прототипом классического DFD-стандарта и
    используется как альтернатива для модели VACD. Матрица выбора процессов по отношению к диаграмме
    цепочки добавленной стоимости является с одной стороны более упрощенным вариантом описания
    процесса, с другой стороны данная модель содержит дополнительные объекты, позволяющие показать
    другие аспекты бизнес-процесса. Простота матрицы выбора бизнес-процессов связана с тем, что на данной
    модели не показываются информационные и материальные потоки. Что касается других аспектов, то
    данная модель позволяет на одной схеме компактно и наглядно показать различные варианты выполнения
    бизнес-процесса, который описывается. Соответственно матрицу выбора процессов целесообразно
    применять вместо диаграммы цепочки добавленной стоимости в случаях, когда описываемый бизнеспроцесс имеет несколько вариантов исполнения, каждый из которых ложится базовую схему. Пример
    применения матрицы выбора процессов для описания деятельности компании "Эврика", имеющий
    функциональную организационную структуру показан на рис. 21.

    Рис. 21. Модель "Матрица выбора процессов" - PSM/ARIS.
    Модель "Extended event driven Process Chain" - eEPC является прототипом классического WFDстандарта и используется для описания бизнес-процессов нижнего уровня. Дополнительным отличием
    eEPC-модели от классической WFD-схемы является наличие на модели объекта, который называется
    событием. С помощью событий изображается факт, время или событие инициирующие начало выполнения
    работ процесса, а также факт или время их завершения (рис. 22).

    Рис. 22. Модель "Расширенная цепочка процессов, управляемая событиями" - VACD/ARIS.
    Модель "Организационная структура" - ORG используется для описания организационной структуры
    компании. На данной модели изображаются структурные подразделения, группы, должности, роли и прочие
    элементы организационной структуры и связи между ними (рис. 23).

    Рис. 23. Модель "Организационная структура" - ORG/ARIS.
    Модель "Диаграмма типов информационных систем" - ASTD используется для описания структуры
    информационных систем, используемых в компании. На данной модели показываются типы и модули
    информационных систем, программные продукты, взаимосвязь между ними и бизнес-процессами
    организации, которые они автоматизируют (рис. 24).

    Рис. 24. Модель "Диаграмма типов информационных систем" - VACD/ASTD.

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

    Компоненты системной архитектуры

    Прикладная архитектура включает в себя:
    ● прикладные системы (приложения), обеспечивающие исполнение бизнес- функций и бизнес-процессов;
    ● интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками
    или потребителями данных;
    ● средства и методы разработки и сопровождения приложений.
    Архитектура данных включает в себя:
    ● автоматизированные базы данных, обеспечивающие накопление, хранение и обработку данных,
    определяемых бизнес-архитектурой;
    ● применяемые для этого системы управления базами данных или хранилищами данных;
    ● правила и средства санкционирования доступа к данным.
    Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.
    Сетевая архитектура включает в себя:
    ● локальные и территориальные вычислительные сети, включая физические собственные и
    арендованные каналы связи и каналообразующую аппаратуру;
    ● используемые в сетях коммуникационные протоколы, сервисы и системы адресации;
    ● аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных
    обстоятельств.
    Архитектура платформ включает в себя:
    ● аппаратные средства вычислительной техники - серверы, рабочие станции, накопители и другое
    компьютерное оборудование;
    ● операционные и управляющие системы, утилиты и офисные программные системы;
    ● аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом - серверов) и
    баз данных в условиях чрезвычайных обстоятельств.
    Для решения задач системной архитектуры в штате компании, как правило, создается выделенная Служба
    системного архитектора. Эта служба отвечает за решение следующих задач:
    ● координация работ ИТ-подразделений по документированию текущей системной архитектуры на
    начальном этапе и последующее поддержание базы знаний о системной архитектуре в актуальном
    состоянии;
    ● определение перспективных направлений развития системной архитектуры в соответствии со
    стратегическими целями и задачами банка, детализированными в форме перспективной бизнесархитектуры;
    ● проектирование (совместно с другими профильными подразделениями по информационным
    технологиям) перспективной системной архитектуры и планов миграции от текущего состояния к
    перспективному;
    ● формулирование требований и ограничений к создаваемым или внедряемым средствам
    автоматизации, обеспечивающим качество и целостность системной архитектуры;
    ● контроль непротиворечивости системных архитектур, разработанных в рамках различных проектов;
    ● контроль соблюдения требований по обеспечению качества и целостности системной архитектуры
    подразделениями банка, осуществляющими разработку, обслуживание и эксплуатацию
    информационных систем.
    Отдельно следует остановиться на одном принципиальном вопросе: кто осуществляет разработку системной
    архитектуры — системный архитектор или разработчик программного обеспечения, технолог. Правильным
    является решение, когда ответственность за разработку системной архитектуры закрепляется за ИТ-

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

    Жизненный цикл системной архитектуры

    ТАБЛИЦА 3.

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

    Рис. 3.6. Рамочная модель разработки архитектуры по IEEE 1471
    В качестве примеров можно указать следующие методики:
    ● методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и
    другими;
    ● модель Захмана; (на паре рассматривали только эту)
    ● методика TOGAF;
    ● методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для
    публичного использования в 1996 году.
    Важным для понимания методик являются используемые в них модели, различные представления (view) или
    домены архитектуры.
    Описание ИТ-архитектуры служит детальным руководством, которое определяет основные, стандартные
    или типовые элементы ИТ-систем, их взаимосвязи, а также процессы управления информационными
    системами. Что хотелось бы получить от такого документа? Можно сформулировать следующие, частично
    противоречивые, требования:
    ● достаточно высокий уровень детализации для практического использования специалистами в области
    информационных технологий при разработке новых систем;
    ● простоту для понимания бизнес-аудиторией;
    ● динамику рассмотрения (т.е. "Архитектура как есть" – "Краткосрочные и среднесрочные задачи" –
    "Стратегические планы");
    ● возможность адаптации по новым требованиям бизнеса и учет возможностей реализации
    незапланированных (ad-hoc) проектов.

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

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

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






    места выполнения этих процессов (где?)
    организации и персоналии–участники (кто?)
    управляющие события (когда?)
    цели и ограничения, определяющие работу системы (зачем?)

    Основные правила заполнения таблицы следующие:
    ● каждая клетка таблицы независима от других, вместе они образуют функционально полное
    пространство для описания системы ("базис");
    ● порядок следования колонок несущественен;
    ● каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной
    модели или, возможно, простого описания (текстового документа);
    ● базовые модели для каждой из колонок являются уникальными;
    ● соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с
    выбранной перспективы;
    ● заполнение клеток должно проводиться последовательно "сверху вниз", попытка пропуска одного
    из рядов является, скорее, "шаманством" (в том плане, что нельзя создать хорошо работающую
    систему, "перепрыгнув" определенные уровни ее описания на этапе проектирования).
    Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне
    вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги,
    клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация).
    Фактически, данная строка определяет контекст всех последующих строк.
    Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры
    организации, ключевых и вспомогательных бизнес-процессов.
    Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора.
    Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы
    данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
    На четвертом уровне – технологической или физической модели – осуществляется привязка данных и
    операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор
    реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной
    среды.
    Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования,
    топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код.
    Многие из работ на данном уровне часто выполняются субподрядчиками.
    Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том
    числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы
    HelpDesk. Надо заметить, что в исходной работе Захмана содержание этого уровня не детализируется. При
    развитии модели, как будет показано ниже, отмечены возможности рассмотрения аспектов функционирования
    работающей системы с точки зрения, например, конечного пользователя или эксплуатирующих служб.
    Основными характеристиками данной модели Захмана являются следующие:
    ● простота для понимания как техническими, так и нетехническими специалистами;
    ● целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с
    предприятием в целом;
    ● поддержка обсуждений сложных вопросов с использованием относительно небольшого количества






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

    21.Процессы проектирования. Архитектурные стили и шаблоны проектирования.
    http://citforum.ru/SE/project/pattern/p_3.shtml#4
    Согласно предложенному принципу классификации паттерны проектирования архитектурные системные
    паттерны объединены в группы в соответствии с теми задачами, для решения которых они разработаны. Для
    организации классов или обьектов системы в базовые подструктуры используются структурные архитектурные
    паттерны. С другой стороны, для обеспечения требуемого системного функционала первостепенное значение
    имеет адекватная организация взаимодействия отдельных архитектурных элементов системы - этой цели
    служат управления.

    4.1

    Структурные паттерны

    4.1.1 Репозиторий
    Описание

    Все совместно используемые подсистемами данные хранятся в
    центральной базе данных, доступной всем подсистемам. Репозиторий
    является пассивным элементом, а управление им возложено на
    подсистемы.

    Рекомендации

    Логично использовать, если система обрабатывает большие объёмы
    данных.

    Преимущества

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

    Недостатки

    Все подсистемы должны быть согласованы со структурой
    репозитория (моделью данных). Модернизировать модель данных
    достаточно трудно
    К разными подсистемам предъявляются различные требования
    по безопасности, восстановлению и резервированию данных, а в
    паттерне Репозиторий ко всем подсистемам применяется одинаковая
    политика.

    4.1.2 Клиент/сервер
    Описание

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

    Рекомендации

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

    Преимущества

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

    Недостатки

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

    4.1.3 Обьектно - ориентированный, Модель предметной области (Domain Model), модуль
    таблицы (Data Mapper)

    Задача

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

    Решение

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

    Преимущества

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

    Недостатки

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

    Пример 1.

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

    Пример 2.

    Модуль таблицы также является частным случаем данного
    паттерна. В отличие от модели предметной области Модуль таблицы
    содержит по одному объекту Контракт для каждого контракта, а
    Модуль таблицы является единственным объектом. Модуль таблицы
    используется совместно с множеством записей (Record Set). Сначала
    создается объект "Контракт", затем - "Продукт", множество записей
    передается ему в качестве аргумента.. Для совершения операций над
    отдельным контрактом, следует сообщить объекту соответствующий
    идентификатор (Id).

    Модуль таблицы представляет собой промежуточный вариант
    между "Сценарием транзакции" 4.2.1.1 и "Моделью предметной
    области" (Пример1).

    4.1.4 Многоуровневая система (Layers) или абстрактная машина

    Описание

    В соответствии с паттерном "Многоуровневая система" структурные
    элементы системы организуются в отдельные уровни со
    взаимосвязанными обязанностями таким образом, чтобы на нижнем
    уровне располагались низкоуровневые службы и службы общего
    назначения, а на более высоких - объекты уровня логики приложения.
    При этом взаимодействие и связывание уровней происходит сверху
    вниз. Связывания обьектов снизу вверх следует избегать.
    На рисунке показаны типичные уровни логической архитектуры
    системы [ 5].

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

    Пример

    Примером данного подхода может служить модель взаимодействия
    открытых систем (OSI - Open System Interconnection - международная
    программа стандартизации обмена данными между компьютерными
    системами на основе семиуровневой модели протоколов передачи
    данных в открытых системах).

    Преимущества

    Многоуровневая система может быть разработана пошагово
    (итеративно).

    Недостатки

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

    4.1.5 Потоки данных (конвейер или фильтр)
    Описание

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

    Преимущества

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

    Недостатки

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

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

    4.2

    Паттерны управления

    4.2.1 Паттерны централизованного управления
    4.2.1.1 Вызов - возврат (сценарий транзакции - частный случай).
    Описание

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

    Рекомендации

    Применима только в последовательных системах, то есть в таких
    системах, в которых процессы должны происходить последовательно.

    Преимущества

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

    Недостатки

    Сложно обрабатывать исключительные ситуации.

    Пример

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

    Сценарий транзакции не годится для сложной бизнес - логики.

    4.2.1.2 Диспетчер
    Описание

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

    Рекомендации

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

    Пример

    Можно использовать в системах реального времени, где нет чересчур
    строгих временных ограничений (в так называемых "мягких" системах
    реального времени).

    22.Процессы проектирования. Проектирование информационной архитектуры.
    см 2.
    Информационная архитектура (часто сокращается до «ИА») — Сочетание схем организации,
    предметизации и навигации, реализованных в информационной системе.
    «Информационная архитектура занимается принципами систематизации информации и навигации
    по ней с целью помочь людям более успешно находить и обрабатывать нужные им данные»
    Louis Rosenfeld

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

    Что же такое информационная архитектура?
    Information Architecture Revealed!
    Интервью с Луи Розенфельдом (Louis Rosenfeld), основателем и президентом Argus Associates. Луи также
    является соавтором популярнейшей книги Information Architecture for the World Wide Web.
    Интервью основано на переписке по электронной почте, которую вел Джон Роудс (John S. Rhodes) 24 мая 99
    года
    Что такое информационная архитектура? В общих чертах, о самом важном?
    Эта сфера знаний пока относительно нова, и находится в стадии развития; следовательно определение
    информационной архитектуры зависит о того, кто его дает. Вот определение, которое нравится нам:
    Информационная архитектура занимается принципами систематизации информации и навигации по
    ней с целью помочь людям более успешно находить и обрабатывать нужные им данные.
    Это означает, что оптимизация поисковой программы на вашем сайте с целью помочь посетителям быстрее
    найти то, что им нужно, является информационной архитектурой (information architecture - IA). Оптимизация же
    поисковой программы для балансирования нагрузки в ведение IA не входит. Разработка системы надписей в
    меню навигации на сайте - является IA. Решение о том, каким цветом будет оформлено это меню навигации
    уже не в ведении IA.
    Почему так велико значение IA? Ну, например, представьте себе, что вы вложили несколько миллионов

    долларов в свой сайт. С эстетической точки зрения он выглядит великолепно, технологически совершенен,
    и на нем полным полно прекрасного материала. Но вот вы узнаёте, что пользователи не могут найти нужную
    им информацию, а вы сами не можете определить, куда следует положить новый материал и когда следует
    убирать старый. Вот здесь-то и возникает необходимость обратиться к информационной архитектуре.
    Или представьте, что работники вашей компании испытывают такие трудности с поиском ответа на вопросы,
    которые задают им ваши клиенты, что они распечатывают каждую страницу интранет-сайта, так как боятся,
    что снова не смогут ее отыскать. Естественно, при изменении информации на сайте распечатки будут
    устаревать, но ваши работники не будут об этом знать, и следовательно они будут давать устаревшие,
    неправильные сведения вашим клиентам. Именно такого рода проблем позволяет избежать информационная
    архитектура. Мы даже сталкивались с ситуацией, когда работники компании сами выдумывали ответы для
    клиентов из-за того, что интранет-сайт был плохо структурирован. Упс! Лучше уж исправить структуру сайта,
    чем попадать в такую ситуацию.
    Какова связь между информационной архитектурой и юзабилити?
    Хороший вопрос. Но я не уверен, что у меня готов хороший ответ на него, во всяком случае - не сегодня. Но я
    тем не менее попытаюсь на него ответить экспромтом.
    Я считаю, что юзабилити в широком понимании этого слова одинаково хорошо подходит к описанию
    процедур испытания и улучшения и панели приборов в автомобиле, и банкоматов, и веб-сайтов. Я,
    как информационный архитектор, много научился у специалистов по юзабилити о том, как ведут себя
    пользователи на сайте, и о том, как оценивать результат их работы с сайтом. Однако я не думаю, что я могу
    что-то узнать от специалистов по юзабилити о самой информации: о том, как его материалы и их характер
    влияют на скорость поиска и обработки информации. Я также обнаруживаю, что специалисты юзабилити
    не всегда достаточно хорошо понимают, как часто меняются требования пользователя к одной и той же
    информации, а также то, как эти различные требования влияют на скорость поиска.
    Так что, я представляю себе юзабилити, как дисциплину с чрезвычайно широкой сферой применения, но к
    сожалению недостаточной при применении к специфическим областям. В своей компании Argus мы как раз
    экспериментируем с этой проблемой; недавно мы наняли Кейт Инстоун (Keith Instone), а также еще одного
    специалиста по взаимодействию человек-компьютер. Так что теперь в нашей компании есть свои собственные
    лучшие специалисты по юзабилити. Потом мы посмотрим, какого рода услуг от нас потребует рынок, и если
    потребуется, мы будем смешивать наш опыт в информационной архитектуре с опытом в юзабилити. Так что
    год-два спустя мой ответ может быть совсем другим.
    Каким образом хорошо продуманная информационная архитектура сайта может сделать сайт более удобным
    в использовании?
    Прежде всего, необходимо понять, что каждая информационная система - будь то книга или интранет
    предприятия - имеют свою информационную архитектуру. Слова "хорошо продуманная" являются ключевыми:
    многие сайты вообще не имеют продуманную архитектуру. Они подобны зданиям, которые строились
    без проекта: решения, используемые на сайте, отражают личную точку зрения дизайнеров, сайт трудно
    масштабируется со временем, дизайн полностью зависит от технологий, используемых на сайте, а не
    наоборот, и так далее. Так что давайте исходить из того, что хорошо продуманная архитектура сайта
    планируется с самого начала.

    Если мы будем считать, что архитектура сайта разрабатывается заранее, на стадии планирования, трудно
    сказать, какой подход лучше использовать. Существует столько много способов организовывать информацию
    в систему, что использование на сайте всех этих подходов вместе будет излишним. Хорошо продуманная
    архитектура сайта помогает пользователям тем, что использует только некоторый набор из всех этих методов,
    т.е. набор, который больше всего подходит для сайта исходя из:
    информационных потребностей посетителей сайта
    материалов сайта
    целей и бюджетных ограничений
    В компании Argus мы очень сильно полагаемся на правило "80/20", которое гласит: если мы можем
    использовать несколько основных методов организации информации, которые удовлетворят 80%
    посетителей, тогда мы можем с уверенностью сказать, что пользователи не заблудятся на нашем сайте. Их
    не запутает обилие "информационных коридоров", многие из которых лишь изредка будут использоваться,
    но зато потребуют значительных затрат в поддержке. И так же, мы часто замечаем, что примерно 20%
    информации, которую нам представляет компания-клиент, удовлетворяет все запросы посетителей сайта.
    Благодаря этому правилу мы можем создавать некрупные, более точные массивы информации, с которыми
    проще работать. Не пытаясь объять необъятное и удовлетворить все нужды и требования посетителей,
    владельцы и менеджеры сайтов будут тратить меньше средств и усилий на поддержку сайтов при этом
    получая от него наибольшую отдачу.
    Говоря более конкретно, хорошо продуманная информационная архитектура гарантирует, что пользователи
    потратят меньше времени на поиск нужной информации, и почти никогда не скажут, что они чего-то не нашли.
    При хорошей архитектуре они всегда обнаружат, что один документ связан ссылками с другими документами
    по той же теме. Они всегда смогут легко переключаться с поиска документов на их просмотр и обратно. Они
    лучше будут понимать, какую информацию сайт может им предложить. Они станут добрее к своим ближним и
    будут заботиться о своих родителях. В общем, вы поняли...
    Уточните, почему пользователям трудно найти информацию на веб-сайтах? Каковы типичные проблемы?
    В общем случае, работа с информацией - это очень, очень трудоемкий процесс. Поиск информации
    напоминает игру "испорченный телефон": вы пытаетесь преобразовать свои мысли и образы в слова, а затем
    - в текст или в запрос для поиска. Затем вам приходится вручную перебирать все документы сайта (что очень
    неэффективно), либо обратиться к программе (например, к поисковому серверу), чтобы он сделал это за вас.
    В результате вы получаете текст, который с большей или меньшей степенью точности отражает в словах
    исходные мысли автора. Учтите при этом неопределенность, присущую всем человеческим языкам, и вы
    получаете тот самый испорченный телефон.
    Исследования процесса поиска информации показывают, что попытка в совместить требования
    пользователей к информации с тем, что им предлагают авторы этой информации, провалилась. Примером
    может служить специфическая узконаправленная онлайновая база данных LEXUS/NEXUS. Web вносит еще
    больший хаос в эту проблему: информация в нем присутствует во множестве форматов, на различные темы,
    в различной подаче. В результате объем информации вырастает на порядки. Учтем еще всех пользователей
    Web-а со всеми их различиями, и в результате - результативность поиска информации уменьшается до нуля.

    Чем больше варьируется содержание информации, тем хуже будут результаты поиска. Не следует сваливать
    все в кучу, но в Web-е именно это обычная практика на веб-сайтах. Вот почему так часто на каждом сайте
    самая популярная страница - это страница поиска. Вот почему так часто невозможно работать с информацией
    в интрасети компании и при этом не запутаться окончательно.
    Пожалуйста, опишите вкратце ключевые идеи вашей популярнейшей книги Information Architecture for World
    Wide Web. Так же, не могли бы вы объяснить успех этой книги?
    За обязательными вводными главами у нас идут две основные части. Первая описывает то, что мы
    считаем основными предметами информационной архитектуры: организация информации, навигация по
    ней, присвоение обозначений и поиск. В следующей части описывается сам процесс: описание того, как
    разрабатывать и реализовывать архитектуру веб-сайта. И в конце книги мы приводим пример нашей работы.
    Мы не показываем вам, как вам надо разрабатывать ваш сайт; нет такого универсального метода, который
    подходит всем. Информационная архитектура каждого веб-сайта строится на присущих ему уникальных
    характеристиках пользователей, материалов и целей. В своей книге мы просто пытаемся представить
    читателям основные понятия информационной архитектуры, дать им терминологию, с помощью которой им
    легче будет вести разговор на данную тему, а также (как мы надеемся) лучше разрабатывать сайты.
    Почему у книги такой грандиозный успех? Я был бы рад заявить, что это произошло благодаря
    революционным идеям, изложенным в ней. Но я знаю точно другую причину: реальная причина - точное время
    выхода книги. Сегодня веб-разработчики имеют дело с пятой или шестой реинкарнацией своего сайта. Их уже
    не надо учить тому, как надо оптимизировать картинки на сайте, как программировать на Java, и так далее. Но
    тем не менее они обнаруживают у своих сайтов такой недостаток, который берет начало от более абстрактных
    понятий дизайна: организация информации и юзабилити. Веб-разработчики уже начали сознавать это, а тут
    выходит как раз наша книга. Точное время - вот секрет успеха!
    Каково будущее информационной архитектуры? Что будет дальше?
    Ах, если бы я знал. Все больше выпускается приложений управления контентом для веб-сайтов, основанных
    на XML. Это позволит создавать более гибкие архитектуры, а также позволит более эффективно использовать
    опубликованный материал. Это очень интересный феномен. Но я несколько пессимистично смотрю
    на то, что когда-либо появится система, которая позволит эффективно организовывать разрозненные,
    неструктурированные материалы в различных форматах и проводить поиск по ним. Пожалуй положение
    с этим делом становится все хуже и хуже. С другой стороны, как бизнесмен работающий в сфере
    информационной архитектуры, я полон оптимизма...
    Лу, большое спасибо.

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

    поиска ответа на вопрос и т.д.).
    Качественная информационная архитектура — это синоним хорошего юзабилити, так как
    хорошо разработанная структура упрощает создание навигационной системы и макетов страниц.
    Без эффективной информационной архитектуры, сила и мощь методов юзабилити будет
    вхолостую тратиться на поддержание фундамента каждой страницы сайта. Слово «архитектура»
    используется здесь по одной очень важной причине: информационные архитекторы создают
    чертежи, на которых потом "держится" весь сайт.
    Большинство веб-мастеров при разработке сайтов уделяет основное внимание тому, что сайт
    делает и как он выглядит. Контент сайта, его структура, навигация, названия пунктов меню,
    подписи к элементам форм обычно находятся на втором плане.
    При таком раскладе сможет или не сможет пользователь получить от сайта то, что он хочет,
    зависит от воли случая или удачи. Сайты с недостаточно спланированной структурой могут
    привести пользователей в замешательство и помешать им в решении их задач. Чтобы
    пользователи могли находить на сайте то, что они ищут, содержимое сайта должно иметь ясную и
    логическую структуру, понятную всем. Только в этом случае сайт будет эффективным.
    Разработать информационную архитектуру, которая будет реально помогать пользователям,
    не так просто, как может показаться на первый взгляд. Структурировать информацию таким
    образом, чтобы обычные люди (а не только ваш начальник или коллега) смогли понять
    и использовать структуру в своей работе, довольно сложное занятие. Пользователи не
    заинтересованы в том, чтобы разбираться со структурой сайта только для того, чтобы достичь
    своих целей. Если они могут решать свои задачи без осознания и осмысления структуры сайта,
    значит спроектированная ИА работает. Информационная архитектура должна быть невидима
    пользователю, но в то же время она должна быть логичной и интуитивной. Вот почему ИА так
    сложно создать и так легко использовать. При создании ИА нужно учитывать различные типы
    поведения, которые пользователи могут демонстрировать при поиске информации. Существуют
    два основных типа: поиск и просмотр. Так пользователи, которые предпочитают поиск, придут в
    замешательство, если на главной странице не окажется формы поиска и наоборот, пользователи,
    которые предпочитают просматривать информацию, классифицированную по категориям, будут
    сильно расстроены, если не смогут найти на сайте каталог. Именно поэтому в информационной
    архитектуре нужно закладывать разные способы организации информации для разных типов
    поведения посетителей сайта. Информационные архитекторы не только разрабатывают
    иерархическую структуру сайта, но и создают навигационную схему, отвечая при этом на
    вопросы: какие элементы принадлежат глобальной навигации (пункты меню, которые находятся
    на всех страницах сайта), какие элементы будут локальными (меню, которое показывается в
    подразделах сайта) и какие элементы будут зависеть от контекста страницы (ссылки, которые
    показываются внутри конкретной страницы).
    Для создания структуры сайта и навигации используются таксономии. Таксономия — это система
    классификации, в которой информация группируется по категориям (элемент может входить
    только в одну категорию). Только после того, как информация организована по таксономиям,
    архитекторы начинают создавать структуру меню (глобального, локального) и навигацию.
    Работы по классификации информации в категории дают хорошую возможность продумать
    смысловое значение элементов информации для пользователя. Жаргон и другие термины,

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

    23.Процессы проектирования. Построение ER модели. Виды нотаций.
    Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship
    diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Представляет собой
    графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать
    объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является
    мета-моделью данных, то есть средством описания моделей данных.
    ER-модель удобна при прототипировании (проектировании) информационных систем, баз данных,
    архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить
    ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться
    между этими сущностями.
    ER-модель является одной из самых простых визуальных моделей данных (графических нотаций).
    Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры
    называется ER-диаграммой или онтологией выбранной предметной области (area of interest).
    На этапе перехода к реализации данной ER-диаграммы в виде реальной информационной системы
    или программы, происходит отображение ER-модели в более детальную модель данных реляционной
    (объектной, сетевой, логической, или др.) базы данных, которая называется даталогической моделью данных
    по отношению к исходной ER-диаграмме.
    История создания
    Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen
    Chen) – американским профессором компьютерных наук в университете штата Луизиана. Фактически Чен не
    изобретал модель, он взял идеи из более ранних работ таких практиков, как А. Браун и других. Однако Питер
    Чен сделал больше, чем кто бы то ни было до него для формализации и популяризации ER-модели, а также
    для её внедрения в научную литературу.
    Применение
    В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое

    распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных
    баз данных. Среди множества нотаций ER-моделей одна из наиболее развитых – Unified Modeling Language
    (Унифицированный язык моделирования), сокр. UML – применяется в системе CASE фирмы ORACLE.
    Нотация UML так же используется и/или поддерживается: Borland Software Corporation, Университетом
    Бремена, Университетом Кента, Университетом Йорка и Дрезденским Университетом Технологии.
    В 2005 году в работе "Design-Level LINUX Documentation" был представлен наиболее полный анализ
    структуры ядра Linux версии 2.6 в представлении UML 2.0. В данном документе для каждой из базовых
    подсистем ядра (управление памятью, ФС, безопасность, криптография, инициализация, драйверы,
    архитектура, межпроцессное взаимодействие), представлено детальное описание структуры и связей
    составных частей (вплоть до структур данных и функций).
    Базовые понятия7

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

    Связи между объектами могут быть 3-х типов:
    Один - к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более
    одного объекта второго вида, и наоборот. Например: сотрудник может руководить только одним отделом, и у

    каждого отдела есть только один руководитель.
    Один - ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать
    более одного объекта второго вида, но каждому объекту второго вида соответствует не более одного объекта
    первого вида. Например: в каждом отделе может быть множество сотрудников, но каждый сотрудник работает
    только в одном отделе.
    Многие - ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать
    более одного объекта второго вида, и наоборот. Например: каждый счет может включать множество товаров,
    и каждый товар может входить в разные счета.
    Ромб связи и прямоугольник объекта соединяются ненаправленными дугами в сторону "ко многим" и
    направленными в сторону "к одному".

    Связь может соединять сущность саму с собой, например:

    Если связь соединяет две сущности, она называется бинарной. Связь может соединять более двух сущностей,
    например, связь, соединяющая три сущности, называется тернарной:

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

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

    Сущность "Контрагент" является надтипом для своих подтипов.
    Предложенная Питером Ченом
    Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются
    в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является
    обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним
    отношением или с одной сущностью.

    Crow's Foot
    Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest) под названием Inverted Arrow
    ("Перевёрнутая стрелка"), однако сейчас чаще называемая Crow's Foot ("Воронья лапа") или Fork ("Вилка").
    Согласно данной нотации, сущность изображается в виде прямоугольника, содержащем её имя,
    выражаемое существительным. Имя сущности должно быть уникальным в рамках одной модели. При этом,
    имя сущности - это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется
    конкретный представитель данной сущности.
    Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца
    связи указывается графически, множественность связи изображается в виде "вилки" на конце связи.
    Модальность связи так же изображается графически - необязательность связи помечается кружком на
    конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего
    времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает_в_себя», и
    т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае,
    название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий

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

    Прочие нотации
    • Bachman notation
    • EXPRESS
    • IDEF1x
    • Martin notation
    • (min, max)-Notation
    • UML
    24.Процессы проектирования. Построение логической модели данных.
    Логическая модель данных является визуальным представлением структур данных, их атрибутов и бизнесправил. Логическая модель представляет данные таким образом, чтобы они легко воспринимались бизнеспользователями. Проектирование логической модели должно быть свободно от требований платформы и
    языка реализации или способа дальнейшего использования данных.
    Разработчик модели использует требования к данным и результаты анализа для формирования логической
    модели данных. Разработчик приводит логическую модель к третьей нормальной форме и проверяет ее на
    соответствие корпоративной модели данных, если она существует.
    Три уровня моделей, объединяющие в себе логические модели, состоят из Entity Relationship Diagram
    (Диаграмма сущность-связь), the Key-Based (Модель данных, основанная на ключах) Model и the Fully Attributed
    model (Полная атрибутивная модель).

    Уровни методологии IDEF1X
    Диаграмма сущность-связь
    Диаграмма сущность-связь является самым высоким уровнем в модели данных и определяет набор
    сущностей и атрибутов проектируемой системы. Целью этой диаграммы является формирование общего
    взгляда на систему для ее дальнейшей детализации.
    Модель данных, основанная на ключах
    Этот тип модели описывает структуру данных системы, в которую включены все сущности и атрибуты,
    в том числе ключевые. Целью этой модели является детализация модели сущность-связь, после чего модель
    данных может начать реализовываться.
    Полная атрибутивная модель
    Эта модель включает в себя все сущности, атрибуты и является наиболее детальным представлением
    структуры данных. Полная атрибутивная модель представляет данные в третьей нормальной форме.
    Компоненты логической модели данных
    Логическая модель использует сущности, атрибуты и отношения для представления данных и бизнесправил. Сущности представляют собой объекты, о которых корпорация заинтересована хранить данные.
    Атрибуты - это данные, которые корпорация заинтересована хранить. Отношения описывают взаимосвязи
    между сущностями в терминах бизнес-правил.
    Сущности
    Сущности представляют собой объекты, данные о которых корпорация заинтересована сохранять.
    Сущностями могут быть вещественные объекты, такие как персона или книга, но они могут представлять
    и абстрактные концепции, такие как центр затрат или производственная единица. Сущности для ясности и
    обеспечения целостности обозначаются существительными в единственном числе, например, Потребитель
    (CUSTOMER) а не Потребители (CUSTOMERS).
    Вы должны описать сущность, используя фактографические подробности, которые уникально
    ее идентифицируют. Каждый экземпляр сущности должен быть отдельным и отличным от всех других
    экземпляров этой сущности. Например, модель данных для хранения информации о клиентах должна
    обеспечивать способ, позволяющий отличить одного клиента от другого.

    На рисунке представлено несколько примеров сущностей.

    Пример использования ERwin для отображения сущностей в простейшей форме.
    Атрибуты
    Атрибуты представляют данные об объектах, которые необходимо иметь корпорации. Атрибуты
    представляются именами существительными, которые описывают характеристики сущностей.
    Рисунок иллюстрирует несколько примеров атрибутов.

    В качестве атрибутов могут выступать дата рождения клиента, модель автомобиля или код ISBN книги.
    Отношения
    Отношения представляют взаимосвязи между объектами, о которых корпорация заинтересована
    хранить данные. Отношения выражаются глаголами или глагольными фразами, которые описывают
    взаимосвязь. На рис. 2.4 приведено несколько примеров отношений, представленных в нотации IE (Information
    Engineering - информационная инженерия) системы ERwin.

    Примеры отношений используют нотацию IE системы ERwin, в которой "коровьи копыта" или "трезубцы"
    отображают многие стороны отношений.

    Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity
    Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей.
    Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи глаголами.
    ERD-диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее
    разработки, касающиеся хранения информации.
    ERD-диаграммы можно подразделить на отдельные куски, соответствующие отдельным задачам,
    решаемым проектируемой системой. Это позволяет рассматривать систему с точки зрения функциональных
    возможностей, делая процесс проектирования управляемым.

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

    Рис. 6.1. Пример ERD-диаграммы,
    Определение сущностей и атрибутов
    Сущность - это субъект, место, вещь, событие или понятие, содержащие информацию. Точнее, сущность
    - это набор (объединение) объектов, называемых экземплярами. В приведенном на рис. 6.1 примере сущность
    CUSTOMER (клиент) представляет всех возможных клиентов. Каждый экземпляр сущности обладает набором
    характеристик. Так, каждый клиент может иметь имя, адрес, телефон и т. д. В логической модели все эти
    характеристики называются атрибутами сущности.
    На рис. 6.2 показана ERD-диаграмма, включающая в себя атрибуты сущностей.

    Рис. 6.2. ERD-диаграмма с атрибутами
    Логические взаимосвязи
    Логические взаимосвязи представляют собой связи между сущностями. Они определяются глаголами,
    показывающими, как одна сущность относится к другой.
    Некоторые примеры взаимосвязей:
    ● команда включает много игроков,
    ● самолет перевозит много пассажиров,
    ● продавец продает много продуктов.
    Во всех этих случаях взаимосвязи отражают взаимодействие между двумя сущностями,
    называемое «один-ко-многим». Это означает, что один экземпляр первой сущности взаимодействует с
    несколькими экземплярами другой сущности. Взаимосвязи отображаются линиями, соединяющими две

    сущности с точкой на одном конце и глаголом, располагаемым над линией.
    Кроме взаимосвязи «один-ко-многим» существует еще один тип - это «многие-ко-многим». Этот тип
    связи описывает ситуацию, при которой экземпляры сущностей могут взаимодействовать с несколькими
    экземплярами других сущностей. Связь «многие-ко-многим» используют на первоначальных стадиях
    проектирования. Этот тип взаимосвязи отображается сплошной линией с точками на обоих концах.
    Связь «многие-ко-многим» может не учитывать определенные ограничения системы, поэтому может
    быть заменена на «один-ко-многим» при последующем пересмотре проекта. '
    Проверка адекватности логической модели
    Если взаимосвязи между сущностями были правильно установлены, то можно составить предложения,
    их описывающие. Например, по модели, показанной на рис. 6.3, можно составить следующие предложения:
    ● Самолет перевозит пассажиров.
    ● Много пассажиров перевозятся одним самолетом.
    Составление таких предложений позволяет проверить соответствие полученной модели требованиям и
    ограничениям создаваемой системы.

    Рис. 6.3. Пример логической модели со взаимосвязью

    2. Модель данных, основанная на ключах
    Каждая сущность содержит горизонтальную линию, разделяющую атрибуты на две группы. Атрибуты,
    расположенные над линией, называются первичным ключом. Первичный ключ предназначен для уникальной
    идентификации экземпляра сущности.
    Выбор первичного ключа
    При создании сущности необходимо выделить группу атрибутов, которые потенциально могут стать
    первичным ключом (потенциальные ключи), затем произвести отбор атрибутов для включения в состав
    первичного ключа, следуя следующим рекомендациям:
    ● Первичный ключ должен быть подобран таким образом, чтобы по значениям атрибутов, в него
    включенных, можно было точно идентифицировать экземпляр сущности.
    ● Никакой из атрибутов первичного ключа не должен иметь нулевое значение.
    ● Значения атрибутов первичного ключа не должны меняться. Если значение изменилось, значит, это уже
    другой экземпляр сущности.
    При выборе первичного ключа можно внести в сущность дополнительный атрибут и сделать его
    ключом. Так, для определения первичного ключа часто используют уникальные номера, которые могут
    автоматически генерироваться системой при добавлении экземпляра сущности в БД. Применение уникальных
    номеров облегчает процесс индексации и поиска в БД.
    Первичный ключ, выбранный при создании логической модели, может быть неудачным для
    осуществления эффективного доступа к БД и должен быть изменен при проектировании физической модели.

    Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Key).
    ERWin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации
    схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа
    на диаграмме рядом с атрибутом появляются символы (АК).
    Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion
    Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр
    уникальным образом, но часто используются для обращения к экземплярам сущности. ERWin генерирует
    неуникальный индекс для каждого инверсионного входа.
    При проведении связи между двумя сущностями в дочерней сущности автоматически образуются
    внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности,
    и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются
    символами (FK) после своего имени.

    25.Процессы проектирования. Построение физической модели данных.
    http://78.85.20.33:3232/department/database/rdbdev/11/1.html - если у вас айпад, то тут очень много написано
    Первый вариант:
    Заключительным шагом создания модели данных является разработка объектов на уровне конкретной
    базы данных. Физическая модель данных создается специалистом по модели данных совместно с
    администратором (экспертом) базы данных.
    Процесс формирования физической модели заключается в:
    ● определении правил наименования объектов базы данных;
    ● разработке объектов хранения (таблиц, материализованных представлений, кубов и т.п.);
    ● определении состава полей (Columns) и их типов данных (Data Types);
    ● формирование первичных (Primary Keys) и внешних ключей (Foreign Keys);
    ● уточнении состава значений (Domains) для измерений и иерархий;
    ● проектирование состава и структуры разделов (Partitions), индексов (Indexes), последовательностей
    (Sequences) и т.д.
    ● формирование рабочего документа с описанием физической модели;
    ● согласование физической модели с техническими специалистами Заказчика.

    Второй вариант:
    Коротко на примере лабораторной работы
    http://itteach.ru/bpwin/sozdanie-fizicheskoy-modeli/vse-stranitsi (только там вирус, так что аккуратно)

    Создание физической модели

    Нормализация. Создание физической модели
    Цель работы:





    изучить виды нормальных форм,
    освоить роль
    CASE-средства ERWin при нормализации и денормализации БД,построить физическую модель,
    изучить алгоритмы перевода БД в первую, вторую и третью нормальную форму (для самостоятельного
    изучения).

    1. Нормализация

    Нормализация - процесс проверки и реорганизации сущностей и атрибутов с
    целью удовлетворения требований к реляционной модели данных. Нормализация
    позволяет быть уверенным, что каждый атрибут определен для своей сущности,
    значительно сократить объем памяти для хранения данных.
    Для рассмотрения видов нормальных форм введем понятия функциональной и
    полной функциональной зависимости.
    Функциональная зависимость. Атрибут В сущности Е функционально зависит от атрибута А
    сущности Е, если и только если каждое значение А в Е связало с ним точно одно значение В в Е. Другими
    словами, А однозначно определяет В.
    Полная функциональная зависимость. Атрибут Е сущности В полностью функционально
    зависит от ряда атрибутов Асущности Е, если и только если В функционально зависит от Л и не зависит ни от
    какого подряда А.

    Существуют следующие виды нормальных форм:

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

    атрибут полностью зависит от первичного ключа, т. е. не существует зависимостей от части ключа.
    ● Третья нормальная форма (3 NF). Сущность Е находится в третьей нормальной форме, если она
    находится во второй нормальной форме и неключевые атрибуты сущности Е зависят от других
    атрибутов Е.

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

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

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

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

    2. Создание физической модели

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

    Таблица 7.1. Сопоставление компонентов логической и физической модели

    Логическая модель

    Физическая модель

    Сущность

    Таблица

    Атрибут

    Столбец

    Логический
    тип
    Физический тип (корректный тип, зависящий от выбранной
    СУБД)
    (текст, число, дата, blob)

    Первичный ключ

    Первичный ключ, индекс РК

    Внешний ключ

    Внешний ключ, индекс FK

    Альтернативный
    ключ

    АК-индекс - уникальный, непервичный индекс

    Правило
    логики

    Триггер или сохраненная процедура

    бизнес-

    Взаимосвязи

    3. Денормализация

    Взаимосвязи, определяемые использованием FK-атрибутов

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

    уровне модели. В
    ● ERWin существует возможность выделения элементов логической модели таким
    образом, чтобы они не появлялись на физическом уровне.Таблицы, столбцы, индексы
    и домены можно создавать только на физическом уровне. В
    ● ERWin существует возможность выделения элементов модели таким образом, чтобы
    они не появлялись на логическом уровне. Эта возможность напрямую поддерживает
    денормализацию физической модели, так как позволяет проектировщику включать
    таблицы, столбцы и индексы в физическую модель, ориентированную на конкретную
    СУБД.
    ● Разрешение связей «многие-ко-многим». При разрешении этих связей в логической
    модели ERWin добавляет ассоциированные сущности и позволяет добавить в них атрибуты. При
    разрешении связей в логической модели автоматически разрешаются связи и в физической модели.

    4. Пример

    Нормализуем полученную в предыдущей лабораторной работе БД до третьей
    нормальной формы. Для приведения БД в первую нормальную форму необходимо
    выполнить условие, при котором все атрибуты содержат атомарные значения. Рассмотрим
    атрибуты сущности «Студент». Студент может иметь несколько адресов электронной
    почты и несколько телефонных номеров, что является нарушением первой нормальной
    формы. Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с
    сущностью «Студент» (рис. 7.1).

    Рис. 7.1. ERD-диаграмма БД студентов в первой нормальной форме

    Проверим соответствие БД второй нормальной форме. Все неключевые
    атрибуты полностью должны зависеть от первичного ключа. Нетрудно заметить, что
    это условие выполняется для всех сущностей БД; следовательно, можно сделать
    вывод о том, что она находится во второй нормальной форме.
    Для приведения БД к третьей нормальной форме необходимо обеспечить
    отсутствие
    транзитивных
    зависимостей
    неключевых
    атрибутов.
    Такая
    зависимость наблюдается у атрибутов «Специальность» и «Специализация»
    у сущности «Студент»: специализация зависит от специальности и от
    группы, в которой обучается студент. Создадим новую независимую
    сущность «Специальность», перенеся в нее атрибут «Специализация» и
    создав новый атрибут «Группа», являющийся ключевым и определяющий
    атрибуты «Специальность» и «Специализация». Проведем неидентифицирующую связь от сущности «Специальность» к сущности «Студент», при этом
    ключевой атрибут «Группа» мигрирует в сущность «Студент». Получим БД в
    третьей нормальной форме, так как других транзитивных зависимостей неключевых
    атрибутов нет (рис. 7.2).

    Рис. 7.2. ERD-диаграмма БД студентов в третьей нормальной форме
    Перейдем к построению физической модели. Перед построением физической модели
    необходимо выбрать тип базы данных в меню при создании физической модели. Выберем
    в качестве DataBase Microsoft Access 97 или 2000, получив физическую модель,
    сгенерированную ERWin по умолчанию (рис. 4.4).
    В полученной модели необходимо скорректировать типы и размеры полей. Кроме
    того, на этапе создания физической модели данных вводятся правила валидации колонок,
    определяющие списки допустимых значений и значения по умолчанию (закладка Access у
    атрибута).
    Таблица 7.2. Свойства колонок таблиц физической модели БД студентов

    Колонка

    Тип

    Размер

    Правило
    валидации

    Номер

    LongInteger

    Группа

    Text

    7

    Ф.И.О.

    Text

    64

    Пароль

    Text

    15

    Возраст

    Integer

    Пол

    Text

    Характеристика

    Memo

    E-mail

    Text

    >10 и <100

    1

    40

    M или Ж

    Специальность

    Text

    20

    Специализация

    Text

    20

    Опыт

    Integer

    Место работы

    Text

    20

    Язык

    Text

    25

    Уровень владения

    Number

    Название

    Text

    Описание

    Memo

    >0

    >2и <5

    30

    Оценка

    Integer

    >2и <5

    Text

    30

    Ф.И.О.
    преподавателя

    Text

    64

    Предмет

    Text

    30

    Дисциплина

    После установки правил валидации (для этого сначала надо дать имя Validation Name, а затем
    отредактировать Validation Rule) в диалоговом окне Validation Rule Editor должны получиться следующие
    правила

    Рис. 7.3. Правила валидации

    После установки правил валидации в диалоговом окне Column Editor необходимо присвоить
    соответствующим колонкам таблиц установленные для них правила (рис. 4.4).

    Рис. 7.4. Физическая модель БД студентов

    Таким образом, проделав все вышеописанные действия, мы получили модель БД, готовую для
    помещения в СУБД. Для генерации кода создания БД необходимо выбрать иконку Forward Engineer после
    чего откроется окно установки свойств генерируемой схемы данных. Для предварительного просмотра SQLскрипта служит кнопка Preview, для генерации схемы - Generate. В процессе генерации ERWin связывается
    с БД, выполняя SQL-скрипт. Если в процессе генерации возникают какие-либо ошибки, то она прекращается,
    открывается окно с сообщениями об ошибках.

    Читайте также:





    Анализ предметной области
    Методология IDEF0
    DFD и WorkFlow (IDEF3)
    Отчеты в BPWin

    26.Процессы проектирования. Шаблоны информационной архитектуры.

    Николай Михайловский
    В предыдущих работах автора архитектура информационной системы выступала в качестве
    связующего звена между экономической эффективностью системы и бизнес-требованиями к
    ней (поскольку бизнес-требования определяют риски). В данном докладе рассматривается связь
    информационной архитектуры предприятия (описанной в терминах модели Захмана) со стратегией
    предприятия. Для этого рассматриваются шаблоны информационных систем в привязке к столбцам
    модели Захмана. Эти шаблоны ставятся в соответствие описанию стратегии компании. Таким
    образом, стратегия компании определяет типы (шаблоны) информационных систем на предприятии,
    что в свою очередь, является значимой частью ИТ-стратегии компании. Таким образом, архитектура
    предприятия выступает связующим звеном между стратегией компании и ее ИТ-стратегией.
    Архитектура системы, согласно ANSI/IEEE Std 1471-2000 - это "фундаментальная организационная
    структура системы, воплощенная в ее компонентах, их взаимоотношениях между собой и с
    окружением, и принципы, управляющие ее построением и эволюцией"
    Из чего состоит архитектура? В соответствии с типичным определением архитектуры
    информационной системы (принятым, например, в популярных продуктах IBM Rational), архитектура это
    ● что делает система;
    ● на какие части она разделяется;
    ● как эти части взаимодействуют;
    ● где эти части размещены;
    Но для предприятия важно также:
    ● Кто работает с системой;
    ● Когда происходят действия и события;
    ● Почему производятся те или иные действия;
    Поэтому с точки зрения предприятия необходимо рассматривать полную модель Захмана архитектуры
    системы. О такой архитектуре, по сути являющейся архитектурой предприятия (с точки зрения
    информационных систем) мы будем говорить как об информационной архитектуре предприятия.
    Одним из ключевых вопросов при построении информационной системы является выбор ее
    архитекруры. И в первую очередь - это выбор того, что должна делать система. Соответственно
    внедрение информационной системы оказывает влияние на бизнес компании, на ее бизнесархитектуру. Разные информационные системы оказывают значимое влияние на различные колонки
    модели Захмана. Это позволяет классифицировать инфорамционные системы и выделить их
    шаблоны.
    Мы выделили следующие основные шаблоны:
    Шаблон

    Характеристики

    Колонки

    1. учет

    Вводятся, хранятся и обрабатываются данные,
    которые обрабатывались вручную Пример:

    Data

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

    Data
    Function

    3. коммуникатор

    ИТ используется для неформализованного обмена
    информацией между пользователями системы
    Пример: система электронной почты Эффект:
    экономия времени, доступность сотрудников,
    изменения корпоративной культуры

    Data
    Network
    People

    4.
    сотрудничество

    ИТ используется для сотрудничества людей в ходе
    частично формализованной деятельности Пример:
    система управления закупками Эффект: экономия
    финансовых и материальных ресурсов!!

    Data
    Function
    Network
    People

    5. планирование

    ИТ используется для составления планов
    деятельности по историческим и внутренним
    данным Пример: система бюджетирования Эффект:
    согласованность ресурсов и как следствие их
    экономия

    Data
    Function
    Time

    6.
    фундаментальны
    й анализ

    ИТ используется для составления планов
    деятельности по внешним для организации данным
    Пример: система маркетингового анализа Эффект:
    согласованность ресурсов и как следствие их
    экономия

    Data
    Function
    Network
    Time

    7. оптимизация
    операций

    ИТ используется для оптимизации выполнения
    существующих в организации бизнес-процессов
    Пример: система оптимизации прямого маркетинга
    Эффект: оптимизация эффекта деятельности
    организации или оптимизация использования
    ресурсов

    Data
    Function
    Time
    Motivation

    8. кастомизация
    по запросу

    ИТ используется для планирования на лету частично
    формализованной деятельности Пример: система

    Data
    Function

    производства под заказ Эффект: удовлетворенность
    пользователей, экономия ресурсов

    Network
    People
    Time

    9. система
    поддержки
    принятия
    решений

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

    Data
    Function
    People
    Time
    Motivation

    10.
    самоорганизующ
    аяся система

    ИТ используется для самоорганизации бизнеспроцесса в сообществе Пример: электронная
    торговая площадка Эффект: синергия, новый уровень
    бизнеса

    Data
    Function
    Network
    People
    Time
    Motivation

    Стратегия компании, в свою очередь, обычно характеризуется отнесением к одному из типов. Такими
    типами могут быть:
    ● Дифференцирование
    Органичные, свободные действия, высокая степень координации между отделами
    Большой потенциал в научных исследованиях и разработках
    Творческое чутье, оригинальные идеи
    Развитые маркетинговые способности
    Поощрение инноваций
    Высокий уровень качества и технологическое лидерство
    ● Лидерство по издержкам
    Централизованное руководство, жесткий контроль над издержками
    Приоритетность стандартных процедур
    Производство основывается на простых в освоении технологиях
    Высокий уровень эффективности систем закупок и распределения продукции
    Контроль над деятельностью работников, ограничение их полномочий
    Частные и детальные контрольные отчеты
    ● Фокусирование
    Для достижения конкретной стратегической цели используется комбинация из
    перечисленных выше характеристик
    Высоко ценится и вознаграждается гибкость и устойчивые связи с покупателями
    Издержки соразмерны уровню сервиса и степени лояльности потребителей
    Работники, контактирующие с покупателями, в обязательном порядке наделяются

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

    Шаблон "коммуникатор" (портал)

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

    Шаблон "сотрудничество" (система
    управления проектами)

    Творческое чутье, оригинальные идеи

    Шаблон "кастомизация по запросу"
    (гибкое производство)

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

    Шаблон "фундаментальный анализ"
    (система маркетингового анализа)

    Поощрение инноваций

    Система поддержки принятия
    решений (CAD, автоматизация
    исследований

    Высокий уровень качества и
    технологическое лидерство

    Оптимизация операций

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

    Шаблон "планирование" (ERP - система)

    Приоритетность стандартных
    процедур

    Шаблон "автоматизация бизнеспроцессов" (ERP, CAM, MES96, система
    документооборота)

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

    Оптимизация операций

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

    Шаблон "автоматизация бизнес-процессов"
    (ERP, система документооборота)

    Частные и детальные контрольные
    отчеты
    Для стратегии фокусирования:
    Для достижения конкретной стратегической
    цели используется комбинация из
    перечисленных выше характеристик

    Шаблон "Кастомизация по
    запросу" (гибкое производство),
    шаблон "коммуникатор" (CRM)

    Высоко ценится и вознаграждается гибкость
    и устойчивые связи с покупателями
    Издержки соразмерны уровню сервиса и
    степени лояльности потребителей

    Шаблон "Планирование" (система
    гибкого бюджетирования)

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

    Шаблон "поддержка принятия
    решений" (CRM-аналитика)

    Идеи, изложенные в данной работе, применимы и к другим классификациям стратегии компании, а
    также к конкретно сформулированным стартегиям.
    ДОПОЛНИТЕЛЬНО:
    Что такое архитектура системы?

    ANSI/IEEE Std 1471-2000:
    «фундаментальная организационная структура системы, воплощенная в ее компонентах, их
    взаимоотношениях между собой и с окружением, и принципы, управляющие ее построением и
    эволюцией"
    Из чего состоит архитектура ИС?

    Типичное определение:

    что делает система;

    на какие части она разделяется;

    как эти части взаимодействуют;

    где эти части размещены

    Для предприятия важно также:

    Кто работает с системой;





    Когда происходят действия и события;

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

    Стратегия компании и КИС
    •Дифференцирование
    –Органичные, свободные действия, высокая степень координации между отделами
    –Большой потенциал в научных исследованиях и разработках
    –Творческое чутье, оригинальные идеи
    –Развитые маркетинговые способности
    –Поощрение инноваций
    –Высокий уровень качества и технологическое лидерство
    •Лидерство по издержкам
    –Централизованное руководство, жесткий контроль над издержками
    –Приоритетность стандартных процедур
    –Производство основывается на простых в освоении технологиях

    –Высокий уровень эффективности систем закупок и распределения продукции
    –Контроль над деятельностью работников, ограничение их полномочий
    –Частные и детальные контрольные отчеты
    •Фокусирование
    –Для достижения конкретной стратегической цели используется комбинация из перечисленных выше
    характеристик
    –Высоко ценится и вознаграждается гибкость и устойчивые связи с покупателями
    –Издержки соразмерны уровню сервиса и степени лояльности потребителей
    –Работники, контактирующие с покупателями, в обязательном порядке наделяются дополнительными
    полномочиями

    27.Процессы проектирования. Проектирование программной архитектуры.
    Проектирование — итерационный процесс, при помощи которого требования к ПС транслируются в
    инженерные представления ПС. Вначале эти представления дают только концептуальную информацию (на
    высоком уровне абстракции), последующие уточнения приводят к формам, которые близки к текстам на
    языках программирования.
    Обычно в проектировании выделяют две ступени: предварительное проектирование и детальное
    проектирование. Предварительное проектирование формирует абстракции архитектурного уровня,
    детальное проектирование уточняет эти абстракции, добавляет подробности алгоритмического уровня.
    Кроме того, во многих случаях выделяют интерфейсное проектирование, цель которого — сформировать
    графический интерфейс пользователя (GUI). Схема информационных связей процесса проектирования
    приведена на рис. 4.2.

    Предварительное проектирование обеспечивает:
    q идентификацию подсистем;
    q определение основных принципов управления подсистемами, взаимодействия подсистем.
    Предварительное проектирование включает три типа деятельности:
    1. Структурирование системы. Система структурируется на несколько подсистем, где под подсистемой
    понимается независимый программный компонент. Определяются взаимодействия подсистем.
    2. Моделирование управления. Определяется модель связей управления между частями системы.
    3. Декомпозиция подсистем на модули. Каждая подсистема разбивается на модули. Определяются типы
    модулей и межмодульные соединения.

    ИЛИ________________________
    Процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или ее
    компонентов называется проектированием. Результат процесса проектирования – дизайн. Рассматриваемое
    как процесс, проектирование есть инженерная деятельность в рамках жизненного цикла (в данном контексте
    – программного обеспечения), в которой надлежащим образом анализируются требования для создания
    описания внутренней структуры ПО, являющейся основой для конструирования программного обеспечения
    как такового. Программный дизайн (как результат деятельности по проектированию) должен описывать
    архитектуру программного обеспечения, то есть представлять декомпозицию программной системы в виде
    организованной структуры компонент и интерфейсов между компонентами. Важнейшей характеристикой
    готовности дизайна является тот уровень детализации компонентов, который позволяет заняться их
    конструированием. Термины дизайн и архитектура могут использоваться взаимозаменяемым образом, но
    чаще говорят о дизайне как о целостном взгляде на архитектуру системы.
    Проектирование играет важную роль в процессах жизненного цикла создания программного обеспечения
    (Software Development Life Cycle), например, IEEE и ISO/IEC (ГОСТ Р ИСО.МЭК) 12207. Проектирование
    программных систем можно рассматривать как деятельность, результат которой состоит из двух составных
    частей:
    ● Архитектурный или высокоуровневый дизайн (software architectural design, top-level design) – описание
    высокоуровневой структуры и организации компонентов системы;
    ● Детализированная архитектура (software detailed design) – описывающая каждый компонент в том
    объеме, который необходим для конструирования.
    В результате консенсуса, принятого создателями SWEBOK, данная область знаний не описывает все
    сущности или понятия, имеющие в своем названии слово “дизайн” или “архитектура”. В 1999 году Том
    ДеМарко (Tom DeMarco) [DeMarco, 1999], один из известных специалистов в программной инженерии,
    предложил терминологическое разделение различных видов дизайна:
    ● D-дизайн (D-design, decomposition design) – декомпозиция структуры программного обеспечения в виде
    набора фрагментов или компонент;
    ● FP-дизайн (FP-design, family pattern design) – семейство архитектурных представлений, базирующихся
    на шаблонах;
    ● I-дизайн (I-design, invention) – создание высоко-уровневой концепции, видения того, что из себя будет
    представлять программная система; данный вид дизайна является результатом процесса анализа
    требований и их трансформации в подходы к реализации.
    Если обсуждать данную область знаний в терминах ДеМарко, проектирование программного обеспечения в
    понимании программной инженерии подразумевает D- и FP-дизайн. I-дизайн в большей степени относится к
    работе с программными требованиями.

    Соответственно, данная область знаний тесно связана со следующими областями программной инженерии:
    ● Software Requirements
    ● Software Construction
    ● Software Maintenance
    ● Software Engineering Management
    ● Software Quality
    Сама же область знаний по проектированию программного обеспечения представлена в виде 6 секций,
    структурированных по темам.

    28.Процессы проектирования. Модели описания программной архитектуры.
    Архитектура программного обеспечения (англ. software architecture) — это структура программы или
    вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих
    компонентов, а также отношения между ними. Этот термин также относится к документированию архитектуры
    программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между
    заинтересованными лицами (англ. stakeholders), позволяет зафиксировать принятые на ранних этапах
    проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого

    дизайна и шаблоны повторно в других проектах.
    Архитектура программной системы определяет ее структуру, точнее — несколько структур, каждая из которых
    включает в себя элементы и взаимосвязи между ними. Элементы могут быть вычислительными объектами,
    связанными потоком управления или бизнес-объектами, связанными семантическими ограничениями.
    В целом процесс проектирования архитектуры состоит из систематической декомпозиции элементов
    верхнего уровня на совокупности более мелких элементов. На рис. 1 исходный элемент путем декомпозиции
    разделяется на элементы «Модель», «Контроллеры» и «Представления». Каждый из них влияет на общее
    поведение исходного элемента.

    Рис. 1. Декомпозиция архитектуры
    С помощью подхода ADD архитектор выбирает конкретную декомпозицию, стремясь улучшить определенные
    свойства конечного продукта. Следует, однако, иметь в виду, что каждая декомпозиция, как правило,
    какие-то свойства ухудшает. На рис. 1 декомпозиция «Модель — Представление — Контроллер» (Model
    — View — Controller, MVC) выбрана для расширения возможностей модификации системы, в частности,
    для более эффективного добавления новых представлений модели. Но такая декомпозиция приведет
    к снижению производительности, поскольку при возникновении любых изменений «Модели» придется
    уведомлять «Представление». С точки зрения архитектора, это приемлемый компромисс, поскольку система
    работает не в реальном (компьютерном) времени, а в расчете на восприятие изменений человеком.
    Процесс создания архитектуры предполагает разработку системы с конкретными свойствами и
    функциональностью, причем каждое из таких свойств имеет заданный приоритет. Начиная с общей структуры,
    которая поддерживает всю требуемую функциональность (она представлена в квадрате в левой части рис. 1),
    архитектор методично проводит декомпозицию функциональности и распределяет ее между компонентами.

    Рис. 2. Дальнейшая декомпозиция
    Процесс декомпозиции, показанный на рис. 2, продолжается до тех пор, пока компоненты не будут
    детализированы должным образом. Другими словами, нужно достигнуть оптимального соотношения между
    характеристиками заданных свойств. Затем на предприятии могут быть созданы рабочие группы, каждая из
    которых станет заниматься проектированием и реализацией своего подмножества элементов архитектуры.
    На рис. 1 и 2 схематически показаны элементы и связи простой архитектуры, но они не конкретизированы.

    Специалистам, знакомым с шаблоном проектирования MVC, изображение на рис. 1 покажется вполне
    информативным, но в нем отсутствуют существенные детали, непонятные новичкам. Были разработаны
    несколько языков описания архитектур [2, 7], поддерживающих детальные спецификации архитектур, но они
    так и получили широкого распространения. Многие из концепций, представленных в этих языках, реализованы
    в последней версии языка Unified Modeling Language — UML 2.0 [14]. Рис. 3 иллюстрирует некоторые из
    обозначений в декомпозиции, представленной в правой части рис. 1.

    Рис. 3. Диаграмма архитектуры UML
    Диаграмма UML содержит дополнительную информацию об интерфейсах предоставления/запроса и сигнала/
    получения для каждого модуля. Любой из маленьких прямоугольников на границе большого прямоугольника
    представляет собой порт — абстракцию интерфейса, которая скрывает, как именно интерфейс связан с
    модулем, большим прямоугольником. Каждое «шарнирное соединение» служит для иллюстрации механизма
    предоставления и запроса данных или ресурсов. Эти соединения на диаграмме показывают связи между
    модулями, но не описывают детально реализацию соответствующих механизмов. Диаграмма удобна для
    последующих ссылок.
    Это — лишь малая часть необходимой информации; в нашем случае — преимущественно информация
    о статической структуре. Архитектор создает разные диаграммы для отображения компонентной
    структуры, взаимодействий между компонентами и их размещения. Описание архитектуры содержит
    несколько «представлений», которые используются собственно для отображения разных типов информации о
    структуре программного обеспечения. Одно из динамических взаимодействий между элементами статической
    архитектуры рис. 1 показано на рис. 4 с помощью диаграммы последовательностей UML.

    Рис. 4. Выполнение изменений в модели
    Приведенное описание включает в себя базовые операции проектирования архитектуры, но не
    отражает типичного процесса разработки архитектуры. В большинстве случаев архитектор начинает с
    предопределенной, эталонной архитектуры. Ею может быть пресловутый «фактический отраслевой стандарт»
    (скажем, J2EE для электронной коммерции и Web-приложений) или предписание (например, архитектурная
    платформа Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance,
    предусмотренная для определенных военных систем в США). Эталонные архитектуры обеспечивают
    декомпозицию высокого уровня, которая позволяет установить базовые характеристики свойств структуры, но
    оставляет за архитектором свободу в выполнении декомпозиций низкого уровня, более точно определяющих
    качество свойств его продукта.
    Выбрав эталонную архитектуру, можно использовать разработанные с ее помощью компоненты как
    основу проектирования. Немаловажный фактор при выборе архитектуры — формирующееся вокруг нее
    коммерческое сообщество. Чем оно больше и разнообразнее, тем больше вероятность приобретения
    компонентов, позволяющих существенно ускорить разработку продукта. Кроме того, для такой архитектуры
    существуют шаблоны, справочники, примеры и другие активы.
    Разработка архитектуры — процесс в равной степени творческий и планируемый. Бизнес-цикл разработки
    побуждает предприятие подумать о своей стратегии с учетом конкуренции, тенденций в отрасли и эволюции
    технологии [3].

    Языки описания архитектуры
    Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения.
    Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE),
    Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL
    (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете
    Малаги), а также ByADL (Университет L'Aquila, Италия). Общими элементами для всех этих языков являются
    понятия компонента, коннектора и конфигурации.

    Виды (views)
    Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в
    строительстве зданий. В онтологии, установленной ANSI / IEEE 1471-2000, виды являются экземплярами
    точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества

    заинтересованных лиц.
    Примеры видов:
    * Функциональный/логический вид
    * Вид код/модуль
    * Вид разработки (development)/структурный
    * Вид параллельности выполнения/процесс/поток
    * Физический вид/вид развертывания
    * Вид с точки зрения действий пользователя
    * Вид с точки зрения данных

    Хотя было разработано несколько языков для описания архитектуры программного обеспечения, но в
    настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В
    качестве стандарта "для моделирования программных систем (и не только)" был создан язык UML.

    Базовые фреймворки для архитектуры ПО (software architecture frameworks)
    Существуют следующие фреймворки, относящихся к области архитектуры ПО:




    4+1
    RM-ODP (Reference Model of Open Distributed Processing)
    Service-Oriented Modeling Framework (SOMF)

    Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к
    области архитектуры предприятия (enterprise architectures).

    Отличие архитектуры ПО от детального проектирования ПО
    Архитектура ПО является реализацией нефункциональных требований к системе, в то время проектирование
    ПО является реализацией функциональных требований.
    Архитектура ПО, которую также можно представить себе в виде разработки стратегии - это деятельность,
    связанная с определением глобальных ограничений, накладываемых на проектирование системы, такие
    как выбор парадигмы программирования, архитектурных стилей, стандарты разработки ПО, основанные на
    использовании компонентов, принципы проектирования и ограничения, накладываемые государственным
    законодательством. Детальное проектирование, т.е. разработка тактики - это деятельность, связанная с
    определением локальных ограничений проекта, такие как шаблоны проектирования, архитектурные модели,
    идиомы программирования и рефакторинга. Согласно "гипотезе напряжения/окрестности" (Intension/Locality
    Hyphotysis), различие между архитектурным и детальным проектированием определяется критерием
    окрестности (Locality Criteria), согласно которому утверждение, что дизайн ПО не является локальным (а
    является архитектурным) истинно тогда и только тогда, когда программа, которая удовлетворяет этому
    критерию может быть расширена в программу, которая не удовлетворяет ему. Например, стиль приложения

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

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





















    Blackboard
    Клиент-серверная модель (client-server)
    Архитектуры, построенные вокруг базы данных (database-centric architecture)
    Распределенные вычисления (distributed computing)
    Событийная архитектура (event-driven architecture)
    Front end and back end
    Неявные вызовы (implicit invocations)
    Монолитное приложение (monolithic application)
    Peer-to-peer
    Пайпы и фильтры (pipes and filters)
    Plugin
    Representational State Transfer
    Rule evaluation
    Поиск-ориентированная архитектуры
    Сервис-ориентированная архитектура
    Shared nothing architecture
    Software componentry
    Space based architecture
    Структурированная
    Трех-уровневая

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

    Подобно тому, как проект здания может включать в себя элементы ранее созданных конструкций,
    так и реализация поддержки бизнес-процесса в информационной системе может использовать уже
    известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с
    одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет
    использования фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании
    подходящих шаблонов (patterns). Английский термин "pattern" имеет различные варианты перевода, в том
    числе "образец", "шаблон" и т.п. В данном случае мы будем использовать русский термин "шаблон", оставляя
    кальку "паттерн" для обозначения аналогичных объектов в области программной архитектуры. Шаблоны
    являются как бы проверенными способами построения какой-то части системы.
    Одним из удачных определений шаблонов является следующее: "Шаблон – это общее решение некоторой
    повторяющейся проблемы в определенном контексте" [4.34].

    Рис. 7.7. Шаблон – решение проблемы в контексте
    То есть важным аспектом, связанным с шаблонами, является то, что они сопровождаются определенными
    обоснованиями того, почему данное решение является хорошим в условиях заданного контекста. Шаблоны
    являются следующим шагом в понимании и применении моделей. Шаблон показывает, что делает некоторую
    модель хорошим решением и как создать некоторое решение для определенной проблемы.
    Осознание важности шаблонов привело к тому, что, например, методика описания архитектуры Gartner
    выделяет шаблоны в качестве отдельного "слоя" архитектуры.
    Использование шаблонов имеет явные корни в строительной архитектуре. Определяющий вклад в
    формирование исходного понятия "pattern" принадлежит известному архитектору Кристоферу Александеру.
    В своей фундаментальной работе 1987 года [4.35] он выделил более 250 типовых архитектурных решений,
    таких как лестницы, альковы, связи между офисами и др. Согласно Александеру, каждый такой прототип
    фактически определяет рекомендуемое решение отдельной проблемы в фиксированном контексте. В
    оригинале Александер выделяет контекст, воздействующие силы и особенности применения данного

    шаблона. В соответствии с аллегорическим комментарием Коупа, описание шаблона – это пьеса. Контекст
    задает место действия и определяет актеров, силы плетут заговор, найденное решение обеспечивает
    Катарсис.
    Исходной целью этих работ Александера была не разработка каких-то новых идей, а, напротив, анализ
    накопленного опыта строительства – как отдельных зданий, так и целых городов – с целью выявления
    удачных архитектурных решений и способствовавших этому факторов. Конечно, критерии определения
    удачности в данной области во многом субъективны, так как зависят от общества, использующего данные
    постройки. В области информационных технологий такими критериями могут быть полнота выполнения
    требований, долговечность, эффективность реализации, а также, в соответствии с [4.36], ориентация,
    прежде всего, на расширение, а не на ограничение возможностей организации. Еще одним важным понятием
    из строительной архитектуры, которое нашло свое отражение в сфере информационных технологий,
    стал язык шаблонов (Pattern Language). В соответствии с определением Коупа, он является коллекцией
    взаимодействующих между собой шаблонов, образующих систему.
    В приведенном выше определении шаблона имеется три ключевых словосочетания:
    ● Общее решение. Это означает, что шаблон не дает полного законченного решения. Он, скорее,
    определяет класс проблемы и то, как эта проблема может быть решена с использованием
    определенного подхода, с демонстрацией аргументов в пользу этого подхода. Сила шаблона состоит в
    том, что он сформулирован на достаточно высоком уровне абстракции, чтобы быть использованным в
    большом количестве ситуаций;
    ● Повторяющаяся проблема. Это означает, что шаблоны используются в тех случаях, когда проблема не
    является уникальной, и они наиболее полезны для решения часто встречающихся проблем;
    ● Определенный контекст. Это означает, что шаблон обеспечивает решение проблемы, границы которой
    в общих чертах определены. Понимая условия, в которых предлагаемое решение в форме шаблона
    является хорошим, вы далее строите свое собственное решение на основе этого шаблона.
    В области информационных технологий первоначально шаблоны получили признание в области программной
    архитектуры. В широко известной работе группы авторов [4.37] (которых в англоязычной литературе по
    числу авторов книги часто называют "бандой четырех") описаны типовые конструкции для объектноориентированных языков программирования, таких как C++. Большое количество ссылок по данной тематике
    и примеров приведены на http://www.patterns.com. Но оказывается, что понятие шаблона оказывается весьма
    эффективно и в области архитектуры предприятия в целом!
    В отношении информационных технологий можно сказать, что шаблоны являются логическими моделями
    технологий: это проектировочные идеи, которые могут быть многократно использованы в рамках предприятия
    в целом [4.38]. Как правило, эти решения служат, в каком-то смысле, индустриальными стандартами и обычно
    существуют продолжительное время. Их можно рассматривать как некоторые схемы, которые определяют
    компоненты решения, т.е. логический уровень проектирования (например, сервер данных или сервер
    приложений), и которые показывают роли, взаимодействия и связи компонент на этом уровне абстракции.
    Когда мы говорим о шаблонах, то речь не идет о конкретных моделях аппаратного или программного
    обеспечения. Как проиллюстрировано рисунком 7.8, интерес представляет другое: как серверы

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

    Рис. 7.8. Шаблон показывает взаимодействие компонент системы между собой
    Важность шаблонов для архитектуры предприятия в целом обусловлена следующими причинами:
    ● если используются корректные шаблоны, то вероятность получения адекватно работающей
    физической реализации архитектуры возрастает;
    ● разработка и использование шаблонов в рамках предприятия в целом обеспечивает преимущества,
    связанные с их многократным использованием для решения различных проблем. Это дает
    архитекторам возможности по использованию опыта и стандартизации решений при создании новых
    систем;
    ● использование шаблонов отделяет логический уровень от физического уровня архитектуры.
    Это позволяет создать долговременно работающие решения и придает гибкость, поскольку на
    последующем этапе эти достаточно постоянные конструкции могут быть связаны с конкретными
    технологическими решениями.
    Можно сказать, что архитектурные концепции (методики) и шаблоны являются двумя инструментами
    для успешного, быстрого, эффективного с точки зрения затрат создания моделей и реализации систем с
    минимальными рисками. Принято идентифицировать шаблоны, которые относятся к различным доменам
    архитектуры (бизнес-шаблоны, шаблоны инфраструктуры и т.д.) и различным уровням абстракции
    архитектуры.

    Рис. 7.9. Архитектура, шаблоны и модели
    В рамках предприятия целесообразно создать репозиторий шаблонов. Характерное для предприятия число
    различных шаблонов составляет порядка 30. Это включает шаблоны использования унаследованных и старых
    клиент/серверных систем, модели для будущей архитектуры (например, сервис-ориентированной) и т.д.
    Описание шаблонов может выполняться с различной степенью детализации и соответствия реальным
    условиям. В зависимости от этого уровня можно рассматривать элементы языка шаблонов различной
    степени абстракции – идиомы, шаблоны дизайна (design patterns) и рамочные модели (frameworks). При этом
    идиомы представляют собой шаблоны самого "низкого уровня", которые зависят от конкретной технологии.
    Шаблоны дизайна обладают определенной независимостью, но в то же время не могут рассматриваться как
    система в целом. Хорошим примером являются шаблоны стандартных классов. Например, понятие "Фабрики
    Объектов" в объектно-ориентированных приложениях, вообще говоря, не зависит от выбора конкретного
    языка программирования и может быть реализовано схожим образом и на С++, и на Java. Наконец, рамочные
    модели представляют собой "частично законченные" системы, которые либо демонстрируют наиболее
    принципиальные элементы реализации, либо являются полностью работоспособными системами для
    определенных упрощенных, ограниченных или идеализированных внешних условий. Эти модели могут
    быть использованы как основа для специализированных доработок, а также для быстрого создания модели
    системы в целом на основе таких отдельных компонент.
    Далее концепция шаблонов была расширена и в область инфраструктуры, так что теперь можно вести речь
    о соответствующих комплексных программно-аппаратных решениях. Для нашего рассмотрения наибольший
    интерес представляют шаблоны достаточно высокого уровня. Применение таких решений значительно
    облегчает задачу реализации новых элементов информационных систем. Каждый такой шаблон может
    объединять конкретное прикладное ПО, операционную систему, сервер СУБД, аппаратную платформу или
    несколько распределенных платформ, интерфейсы, метаданные и т.п. Типичными примерами являются

    шаблон B2B (Business-to-Business) для взаимодействия с Клиентами/Поставщиками или B2E (Business-toEmployee), описывающий взаимодействие между информационной системой и сотрудниками.
    Инфраструктурные шаблоны можно определить как стандартизированный набор требований, компонент
    и сервисов, которые в совокупности формируют необходимую адекватную инфраструктуру для данной
    прикладной системы и реализации логики бизнес-процессов [4.39]. Рисунок 7.10 иллюстрирует общее
    определение инфраструктурного шаблона в форме многоуровневой классификации функций и примерного
    списка технологических компонент на каждом уровне.

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

    Рис. 7.11. От традиционной архитектуры – к архитектуре, использующей инфраструктурные шаблоны
    Большой интерес при создании бизнес-архитектуры предприятия представляют бизнес-шаблоны. В
    соответствии с [4.34] описание бизнес-шаблона включает:
    ● описание поддерживаемой бизнес-функции;
    ● данные, которые требуются для выполнения описанной бизнес-функции;
    ● бизнес-компоненты, которые являются представлением данных и функций бизнеса на языке
    информационных технологий;
    ● возможно, описание инфраструктуры, которая необходима для поддержки функций, данных и
    компонент.
    Заинтересованным в этом вопросе читателям мы рекомендуем статью [4.34], которая опубликована в журнале
    Microsoft, посвященном вопросам архитектуры; в электронном виде публикацию можно найти по адресу http://
    msdn.microsoft.com/architecture/journ/.
    В качестве другого примера рассмотрим возможности предложенных компанией IBM "шаблонов для
    электронного бизнеса" [4.40].
    Так как практически все приложения для электронного бизнеса сталкиваются с необходимостью решения

    таких вопросов, как масштабируемость, надежность, доступность, безопасность, то представляется, что
    использование относительно небольшого числа стандартизованных решений может оказаться полезным.
    Эти решения можно, в свою очередь, подразделить в зависимости от уровня абстракции – соответственно на
    бизнес-шаблоны, архитектурные шаблоны, шаблоны уровня приложений и т.п. При этом:
    ● бизнес-шаблоны (Business pattern) предназначены для описания взаимодействия между участниками
    процесса;
    ● шаблоны дизайна (Design pattern) отражают внутреннюю компонентную структуру системы;
    ● шаблоны уровня приложений (Application pattern) определяют различные варианты взаимодействия
    между пользователями, приложениями и данными в системе, а также соответствующий прототип
    уровня выполнения;
    ● шаблоны уровня выполнения (Runtime pattern) описывают привязку компонент системы к физическим
    узлам и определяют конкретные возможные продукты и их комбинации.
    В соответствии с предлагаемой схемой выделяются 4 основных бизнес-шаблона (см. табл. 7.1).
    Интегрированный
    доступ

    Cамообслуживание (U2B- User-to-Business)

    Интеграция
    приложений

    Cотрудничество (U2U – User-to-User)
    Агрегированная информация (U2D – User-toData)
    Расширенное предприятие (B2B- Businessto-Business)
    Кроме этого, выделяют также два служебных шаблона: соответственно интеграции доступа и интеграции
    приложений.
    Эти шаблоны предназначены для описания таких типовых областей, как:
    ● интерактивная – взаимодействие пользователя с предприятием (например, продажа товаров и услуг не
    по каталогам) – U2B;
    ● программное взаимодействие между приложениями различных предприятий (B2B);
    ● коллективная работа пользователей, включая электронную почту, обмен мгновенными сообщениями,
    общие форумы и т.п. – U2U;
    ● поиск информации в каталогах и базах данных, анализ данных, подписки – U2D;
    ● взаимодействие между приложениями "в рамках предприятия", в том числе и не обязательно с
    использованием web-интерфейсов;
    ● централизованный доступ к системе на уровне выбранного интерфейса (портал) или на более общем
    уровне (Web, речевая телефония, мобильные устройства и т.п.);
    ● обеспечение безопасности.
    Шаблоны могут быть использованы по отдельности или в комбинации при реализации более сложных
    комплексных решений. Для идентификации классов этих решений общеупотребительным стали
    аббревиатуры, использующие сходное звучание в английском языке цифры 2 и отношения между двумя
    сторонами – системы типа B2B, B2C и т.д. Например, традиционный электронный магазин (B2C) может
    включать элементы прототипов U2D (User-to-Data – работа пользователя с каталогом товаров), U2B (Userto-Business – оформление заказа), U2U (User-to-User – консультация у продавца или обращение в службу

    поддержки).
    Для реализации на практике единой архитектуры предприятия особое значение приобретают шаблоны
    интеграции приложений. Прежде всего, стоит выделить две категории, связанные с уровнем реализации
    взаимодействия, – интеграция на уровне процессов и интеграция на уровне данных. Первая категория
    используется, если данные из одного процесса непосредственно используются в другом процессе, связанном
    с первым. Примером может служить использование средств обмена сообщениями для гарантированной
    доставки данных из филиала банка в центральное отделение. Другая категория связана с синхронизацией
    данных между несвязанными непосредственно между собой процессами (например, загрузка агрегированных
    данных из системы биллинга клиентов в систему управления маркетингом).
    Собственно шаблоны строятся на основе набора предварительно определяемых общих служб, которые могут
    входить в шаблон в необходимой комбинации. Примерами таких общих служб могут являться:
    ● преобразование данных (в частности, объединение/разделение, подстановки, округления, перевод c
    языка на язык, использование XSL для преобразования XML->XML и т п);
    ● маршрутизация сообщений (в том числе оптимизация маршрута, мультипликация/демультипликация
    для доставки один-ко-многим, динамическая маршрутизация в зависимости от содержания и т.п.);
    ● гарантированная доставка;
    ● репозиторий сообщений и метаданных;
    ● управление транзакциями, в том числе распределенными;
    ● планирование задач и активностей;
    ● журналирование и аудит;
    ● управление нагрузкой (в том числе поддержка кластеров, динамическая балансировка, горячая замена
    и т.п.);
    ● управление системами, в том числе обнаружение ошибок, мониторинг параметров;
    ● служба каталогов;
    ● безопасность, включая шифрование данных.
    Аналогичные архитектурные шаблоны в терминологии Microsoft представляют собой Решения уровня
    предприятия [4.41]. Они группируются в виде специальной модели в соответствии с уровнем абстракции и
    архитектурным доменом (см. рис. 7.12).

    Рис. 7.12. Категоризация архитектурных шаблонов Microsoft
    При этом область шаблонов как бы "ограничена сверху" за счет включения в рассмотрение только
    реляционных баз данных, многоуровневой (layered) архитектуры объектно-ориентированных приложений и
    N-звенных систем. За счет такого ограничения (в частности, из рассмотрения исключены OLAP-системы и
    монолитные или исполняемые на одной платформе приложения) удается достичь существенной глубины
    проработки. В состав набора входят шаблоны для представления информации через Web, поддержки
    распределенных систем, предоставления сервисов, обеспечения производительности и надежности систем.

    Сервис-ориентированная архитектура (SOA) и архитектура, управляемая
    моделями (MDA)
    В последнее время необходимость интеграции и взаимодействия приложений в рамках совокупности
    большого количества информационных систем предприятия или нескольких предприятий, объединенных
    в целую партнерскую цепочку, оказывают существенное влияние на используемые программные
    архитектуры. Детальное рассмотрение этих аспектов выходит за рамки данного курса, но мы посчитали
    целесообразным привести краткую информацию о новых подходах к проектированию архитектуры
    информационных систем, так как они имеют непосредственное влияние на принципы формирования
    архитектуры предприятия в целом.
    Речь идет, прежде всего, о сервисной модели взаимодействия между приложениями общей системы в
    рамках так называемой сервис-ориентированной архитектуры (Service-oriented architecture SOA) и о
    реализации архитектуры, "управляемой моделями" (модельная архитектура. Model-driven architecture MDA).

    Что такое сервис-ориентированная архитектура и как она связана с вопросами бизнес-архитектуры и
    архитектуры информационных технологий предприятия?
    Хотя концепция сервис-ориентированной архитектуры была сформулирована специалистами в области
    ИТ, но в действительности это был прямой ответ на потребности сегодняшнего дня, когда становится
    уже не совсем понятно, где заканчиваются бизнес-функции организации и начинаются информационные
    технологии, их обеспечивающие, и наоборот. Ведущие поставщики информационных технологий,
    такие как Microsoft [4.42] и IBM [4.43], развивают эту концепцию в рекомендациях по проектированию
    информационных систем на своих программных платформах. А такие компании, как Gartner, считают, что
    сервис-ориентированная архитектура будет ведущим принципом проектирования новых критически-важных
    прикладных систем и бизнес-процессов в ближайшем будущем.
    Мы уже говорили о том, что в основе бизнес-архитектуры должна быть процессно-ориентированная модель
    функций предприятия. Комбинация этого подхода с концепцией сервис-ориентированной архитектуры
    информационных технологий позволяет лучше увязать процесс разработки компонент информационных
    систем с миссией, основными задачами и функциями организаций.
    С помощью SOA организации имеют потенциальную возможность разрабатывать набор реализаций
    различных бизнес-процессов, которые могут быть многократно использованы предприятием как готовые
    сервисы.
    Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных
    информационных систем, который руководствуется следующими принципами [4.44]:
    ● явное отделение бизнес-логики прикладной системы от логики презентации информации;
    ● реализация бизнес-логики прикладной системы в виде некоторого количества программных
    модулей (сервисов), которые доступны извне (пользователям и другим модулям), чаще всего в
    режиме "запрос-ответ", через четко определенные формальные интерфейсы доступа;
    ● при этом "потребитель услуги", который может быть прикладной системой или другим
    сервисом, имеет возможность вызвать сервис через интерфейсы, используя соответствующие
    коммуникационные механизмы.
    В целом, SOA представляет собой модель взаимодействия компонент, которая связывает различные
    функциональные модули приложений (сервисы) между собой с помощью четко определяемых интерфейсов.
    Заметим, что одним из известных интеграционных шаблонов как раз и является "Сервис". Интерфейсы
    сами по себе не зависят от используемых аппаратных платформ, операционных систем или языков
    программирования, используемых для разработки этих приложений. Это позволяет отдельным сервисам
    взаимодействовать между собой одним и тем же стандартным, но в то же время универсальным способом.
    Такая особенность использования интерфейса, независимого от окружения и платформы, получила
    название модели "слабой связи". Ее очевидным преимуществом является повышенная гибкость и
    адаптируемость, поскольку замена или модернизация одной из компонент системы не сказывается на
    остальных. Достаточно интересное введение в эту проблематику и обсуждение связи терминов SOА и webcервисов можно найти, например, в [4.45].
    Само понятие SOA не является чем-то принципиально новым, так как сходные возможности
    реализовывались и ранее, например, с помощью технологий обмена сообщениями. Принципиальным
    фактором является то, что современные подходы к реализации SOA охватывают не только технологический
    уровень обмена данными, но и уровень бизнес-операций. В частности, одним из важных результатов стала
    разработка специализированного языка BPEL (Business Process Executable Language for Web Services)
    для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-правил.
    Вообще говоря, принятие SOA как целевой архитектуры будет подразумевать и соответствующий подход к
    разработке приложений (SODA – service-oriented development architecture).
    Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне web-

    сервисов (служб). Под web-сервисами понимаются программные системы, которые используют XML в
    качестве формата данных, стандарты Web Services Description Language (WSDL) для описания своих
    интерфейсов, Simple Object Access Protocol (SOAP) для описания формата принимаемых и посылаемых
    сообщений и стандарт Universal Description, Discovery and Integration (UDDI) для создания каталогов
    доступных сервисов. И хотя принципы сервис-ориентированной архитектуры создания информационных
    систем не обязательно предполагают использование технологий web-сервисов, связь между этими двумя
    направлениями в развитии информационных технологий является достаточно тесной. При этом web-сервисы
    являются технологическими спецификациями, в то время как сервис-ориентированная архитектура (SOA)
    является принципом проектирования архитектуры программных систем.
    С учетом отмеченных выше существующих тенденций перехода к бизнесу "реального времени" и создания
    систем так называемого "расширенного предприятия", объединяющих само предприятие, его поставщиков,
    партнеров и клиентов в единую систему, становится очевидно, что технологии web-cервисов найдут свое
    применение на всех уровнях корпоративных информационных систем. Предполагается, что в будущем
    практически все взаимодействие приложений как в рамках одной информационной системы, так и между
    системами отдельных участников бизнес-процесса, будет осуществляться с использованием такого
    механизма, так что достаточно критическими становятся вопросы согласованной работы этих сервисов. Для
    описания такой работы были предложены даже специальные термины – "хореография" и "оркестровка"
    (очевидно, по аналогии с управлением оркестром из различных инструментов или ансамблем разных
    исполнителей). При этом, если хореография определяет взаимодействие различных участников с
    использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнеспроцесса, в частности, с использованием языка типа BPEL.
    Более того, даже интеграцию унаследованных приложений целесообразно проводить с применением
    данной технологии, когда определенная, наиболее важная часть существующей функциональности как
    бы "инкапсулируется" и представляется стандартизированным интерфейсом. При наличии существующей
    инфраструктуры web-сервисов на предприятии можно ожидать существенного сокращения сроков и затрат
    на интеграцию.
    Таким образом, влияние сервис-ориентированных подходов на изменения в архитектуре можно
    охарактеризовать как сбалансированный переход от централизованной инфраструктуры информационных
    технологий и замкнутого на себе функционала прикладных систем в сторону архитектуры, обеспечивающей
    возможности быстрого создания новых систем из набора доступных сервисов, т.е. более гибкой,
    динамичной и способной к взаимодействию.
    Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель архитектуры
    предприятия, которая в единой манере описывает как бизнес, так и ИТ [4.46]:
    Эта модель состоит из следующих основных компонент:
    ● презентационный уровень описывает интерфейсные сервисы для взаимодействия пользователей
    с информационной системой, включая корпоративные и публичные порталы, доступ с мобильных
    устройств, а также различные преобразования информации при взаимодействии с внешними
    системами и устройствами;
    ● на уровне бизнес-сервисов формируются модели и осуществляется управление выполнением
    бизнес-процессов предприятия с использованием специализированных средств (типа BPEL), а также
    координация автоматизированных и "ручных" операций;
    ● интеграционные сервисы обеспечивают взаимодействие между приложениями, которое может быть
    реализовано, в частности, с использованием средств обмена сообщениями или в рамках единой
    среды исполнения, такой как сервер приложений J2EE;
    ● cервисы уровня данных реализуют средства извлечения и повторного использования данных
    из СУБД и приложений. Явное выделение такого уровня позволяет изолировать вышестоящие



    компоненты архитектуры от изменений в технологиях (например, смены вендора или версии
    продукта), а также обеспечить единый унифицированный подход к выполнению операций с
    данными;
    уровень инфраструктуры, приложений и СУБД является как бы основой для всей структуры, и
    именно здесь концентрируются основные инвестиции в ИТ.

    Рис. 7.13. Ссылочная модель сервис-ориентированной Архитектуры предприятия
    Взаимодействие между этими уровнями, однако, осуществляется не напрямую, а через сервисы,
    выделенные на уровень обработки событий. Сервисы этой компоненты архитектуры обеспечивают сбор
    данных о событиях в масштабе всего предприятия, необходимое преобразование и маршрутизацию этих
    данных между разными уровнями, а также "обратную связь" между сервисами каждого отдельного уровня.
    В предложенной модели, наряду с рассмотренными уровнями, отвечающими за взаимодействие различных
    групп сервисов "как бы в процессе деятельности предприятия", выделяется отдельная компонента
    архитектуры, которая описывает аспекты, связанные с жизненным циклом сервисов – то есть их созданием,
    эксплуатацией и оптимизацией.
    MDA является еще одной важной архитектурной концепцией создания информационных систем. Концепция
    MDA была предложена консорциумом OMG (Object Management Group,http://www.omg.org/), в который
    сегодня входит более 800 известных производителей программного и аппаратного обеспечения. MDA
    является определенным обобщением идей SOA, с одной стороны, и повторно используемых программных
    компонент (шаблонов, паттернов) с другой, предназначенным прежде всего для повышения гибкости
    разрабатываемых приложений масштаба предприятия, чтобы обеспечить простоту обеспечения

    соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ.
    MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям
    интеграции. Она основана на следующих принципах [3.18]:
    ● основой для разработки приложений масштаба предприятия являются детальные модели с
    общепринятой нотацией;
    ● построение систем может быть организовано в соответствии с рамочной системой моделей, которые
    позволяют отделить бизнес-логику приложений от конкретной реализации. Исходной является так
    называемая независимая модель вычислений (Computational Independent Model), которая путем
    последовательных трансформаций через платформо-независимые (PIM) и платформо-специфичные
    модели (PSM) автоматически или с минимальным участием программиста приводится к исполняемому
    коду и соответствующим структурам данных;
    ● существует формальное описание используемых моделей на основе системы метамоделей (в
    частности, для таких областей как распределенные вычисления и транзакции, операции в реальном
    времени и т.п.);
    ● принятие и широкое использование этого подхода основано на открытости промышленных
    стандартов и на поддержке со стороны производителей соответствующих средств разработки.
    В рамках такого подхода сначала создается архитектура, которая описывает модель бизнесфункциональности и поведения прикладной системы независимо от технических деталей реализации.
    Эта разработка должна вестись в контексте всей корпоративной архитектуры организации. На основе
    этой модели, не зависящей от платформы реализации, может быть разработана одна или несколько
    специфических для конкретной платформы моделей, в зависимости от того, какая платформа используется
    и поддерживается организацией. Уже на основе этих специфических для конкретной платформы моделей
    разрабатывается код конкретной прикладной системы, как показано на рис. 7.14.

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

    30.Процессы проектирования. Проектирование инфраструктуры.

    Идентификация объектов управления конфигурацией проекта
    Для введения в этот раздел, относительно редко выносимый на отдельное рассмотрение, дадим определение
    ключевым терминам.
    Конфигурация - поименованный набор элементов, являющихся результатами проекта.
    Элемент конфигурации - результат проекта или компонент результата, контролируемый в рамках процесса
    управления конфигурацией.
    Ответственность за планирование, функционирование и контроль процесса управления конфигурацией
    возложена на менеджера по управлению конфигурацией. Если проект небольшой, эти функции выполняет
    руководитель проекта, но с увеличением масштаба проекта эта роль становится главной и требует отдельного
    назначения.
    В должностные обязанности менеджера по управлению конфигурацией обязательно входит [22]:






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

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

    инфраструктуры проекта является одним из критических факторов успеха на этапе планирования.

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

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




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

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

    Пример требований к инфраструктуре офиса проекта (фрагмент)
    Специальные помещения
    Для осуществления рабочей группой проекта работ в группе компаний "Звездочка" заказчик предоставляет
    специальные помещения для размещения объединенной рабочей группы проекта.
    Требования к помещениям
    Помещение проектного офиса должно удовлетворять следующим требованиям:
    на одного сотрудника должно приходиться не менее 5 м2 площади рабочей комнаты, рабочее место каждого
    сотрудника должно быть обеспечено:




    отдельным рабочим столом;
    стулом;
    двумя розетками электрической сети;








    одной розеткой для доступа в информационную сеть;
    одной розеткой для доступа в телефонную сеть (по дополнительному обоснованию);
    телефонным аппаратом (по дополнительному обоснованию). Каждое помещение офиса должно быть
    обеспечено:
    сетевым лазерным черно-белым принтером с возможностью двухсторонней печати на листах формата
    А4 и скоростью печати не менее 30 страниц в минуту;
    вешалкой для верхней одежды всех сотрудников, размещенных в рабочей комнате;
    одним шкафом для документов.

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





    столом для заседаний;
    стульями;
    флип-чартом;
    экраном и проектором для проведения совещаний с участием 10 человек.

    Обеспечение членов рабочей группы проекта персональными компьютерами:




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

    Обеспечение рабочей группы проекта копировальной техникой Рабочая группа проекта обеспечивается
    заказчиком одним копировальным аппаратом с возможностью двухстороннего копирования листов формата
    А3 и А4 и автоматической подачей листов оригинала.
    Обеспечение рабочей группы проекта канцелярскими принадлежностями Рабочая группа проекта
    обеспечивается заказчиком канцелярскими принадлежностями и бумагой по заявке администратора проекта
    от исполнителя.
    Обеспечение информационного обмена членов рабочей группы проекта







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

    Режим и место работы членов объединенной рабочей группы проекта


    Работы по проекту выполняются сотрудниками исполнителя или субподрядчика на территории





    заказчика и/или на территории исполнителя/субподрядчика.
    Начало рабочего дня для членов рабочей группы проекта - 9 часов 00 минут, окончание рабочего
    дня - 18 часов 00 минут, длительность обеденного перерыва - 1 час в интервале времени с 12:00 до
    15:00. Руководители проекта от заказчика и исполнителя имеют право изменять режим работы для
    привлекаемых к проекту сотрудников при условии взаимного согласования таких изменений.
    Заказчик обеспечивает возможность работы сотрудников исполнителя на территории заказчика в
    вечернее и ночное время, а также в выходные и праздничные дня (при необходимости возможна
    круглосуточная работа) по предварительной заявке от исполнителя.

    Пример процедуры создания инфраструктуры проекта
    Для создания инфраструктуры необходимо:





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

    31.Процессы проектирования. Проектирование интерфейсов.
    http://www.williamspublishing.com/PDF/5-8459-0276-2/part7.pdf - тут рассмотрено очень подробно

    Интерфейс информационных систем
    В системах построенных по технологии клиент-сервер существует два вида интерфейса:



    Интерфейс, реализуемый при помощи клиентского приложения;
    Web -интерфейс.

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




    Свойства объекта - это его характеристики (высота, ширина и т.д.);
    События объекта - это события операционных систем или события инициируемые пользователем, на
    которые может реагировать объект (нажатие кнопки);
    Методы объекта - действия, которые можно производить с объектом в ходе выполнения программ.

    В БД все объекты форм делятся на два класса:


    Объекты управления - объекты, осуществляющие управление БД (Например: Кнопка или Выпадающий



    список);
    Объекты для отображения информации - элементы, отображающие содержимое таблиц, запросов или
    фильтров, позволяющие добавлять изменять и удалять информацию, и проводить ее анализ.

    Все формы в клиентском приложении делятся на три группы:
    1. Формы для работы с данными - формы, содержащие как объекты управления, так и объекты
    просмотра данных. Такие формы предназначены для отображения, изменения, удаления и анализа
    данных;
    2. Кнопочные формы - формы, содержащие только объекты управления, предназначаются для открытия
    всех других форм.
    3. Замечание: Кнопочная форма, которая появляется первой после запуска программы, называется,
    главной кнопочной формой.
    4. Информационные и служебные формы - формы, содержащие только элементы управления,
    предназначены для отображения служебной информации (справки), несвязанной с таблицами,
    запросами и фильтрами, либо для выполнения служебных операций не связанных с данными
    (Например: форма с калькулятором)
    Замечание: Существует два вида дизайна форм:
    1. Ленточные формы - формы, выводящие информацию по одной записи;
    2. Табличные формы - формы выводящие информацию в виде таблицы.
    Замечание: Объекты связи используются только в клиентском интерфейсе. В web-интерфейса функции
    объекта связи выполняет сервер.
    Основой web-интерфейса являются страницы (файл с расширенным htm или html). Работа со страницами
    осуществляется с помощью программы - браузера. Изначально страницы находятся на сервере, пользователь
    сначала загружает их на свой компьютер с сервера, а затем с помощью страниц пользователь работает с
    файлом данных.
    Замечание: В web- интерфейсе отсутствуют отчёты, их роль выполняют сами страницы.

    Создание интерфейса пользователя
    Создание интерфейса при помощи окна "Data Sources"
    Visual Basic 2008 позволяет создавать не сложный интерфейс БД, без помощи панели объектов и окна
    свойств, лишь используя окно "Data Sources". В окне "Data Sources" после подключения источника данных
    отображается все таблицы, запросы, фильтры данных и их поля. В Visual Basic 2008 как и в Visual Basic 6.0
    можно перетаскивать источники данных, соответственно таблицы, запросы, фильтры прямо из окна "Data
    Sources" на форму (в Visual Basic 6.0 окно "Data Sources" заменено на окно "Data Environment"). Главное
    отличие Visual Basic 2008 является то, что при перетаскивании можно выбирать для каждого поля источника
    данных объект, который будет отображать его содержимое.
    Замечание: Таким способом можно создавать только определённые объекты для отображения данных поля,

    и набор этих объектов зависит от типа данных поля.
    Создание объектов для отображения данных перетаскиванием состоит из двух шагов:






    Для каждого поля таблицы, запроса, или фильтра выбирается объект, который будет отображать его
    содержимое. Для этого необходимо щелкнуть мышью по полю в окне "Data Sources", рядом с именем
    поля появится кнопка, со стрелкой, щелкнув мышью по стрелке, отобразится выпадающее меню с
    объектами, которые могут отображать информацию, содержащуюся в поле. Для полей стандартными
    объектами являются: TextBox, ComboBox, Label, LinkLabel, ListBox. Для полей типа данных Дата
    Время (DateTime) возможно использования объекта DataTimePicker. Для полей логических типов
    данных возможно использование объекта CheckBox. Для отображения таблиц, запросов или фильтров
    целиком возможно два варианта отображения:
    ○ При помощи объекта DataGridView - информация из таблицы, запроса или фильтра
    отображается в виде таблицы;
    ○ DetalledView - отображение всех полей источника данных в TextBox по отдельности
    Замечание: В выпадающем меню с вариантами выбора объектов имеется пункт "Customize"
    (Настройки), который позволяет выбрать дополнительные допустимые объекты для отображения
    информации.
    после выбора объектов для отображения необходимо их поместить на форму, перетаскивая мышью с
    панели "Data Sources" в нужное место на форме.

    Замечание: При помещении первого объекта на форму на ней автоматически создаются объекты для связей
    с файлом данных и объекты по навигациям по источникам данных (DataSet, BindingSource, TableAdapter,
    BindingNavigator).
    Замечание: По умолчанию панель навигации располагается в верхней части формы. Эту панель можно
    прикрепить около различных краев формы. Для этого необходимо воспользоваться меню действий объектов.
    Это меню схоже с окном "Property Pages" из Visual Basic 6.0, но кроме основных свойств объектов оно
    содержит и действия, которые можно производить с объектами. Чтобы вызвать это меню необходимо
    выделить объект. В его правом верхнем углу появится (квадратик со стрелочкой) при нажатии этой кнопки
    появляется выпадающее меню с настройками и действия с объектом. Например, чтобы поменять место
    положение навигации панели надо в этом меню выбрать настройку Docking.
    Замечание: При перетаскивании на форму полей источников данных автоматически создаются подписи к ним
    (Label).
    Замечание: После перетаскивания с созданным объектом можно работать как и с обычным объектом Visual
    Basic.

    Подключение объектов к источнику данных при помощи окна свойств
    Visual Basic 2008 позволяет подключать источники данных к объектам без использования перетаскивания,
    то есть вручную, с использованием панели свойств, как в Visual Basic 6.0. Для этого на форму помещается
    объект, который будет подключаться к источнику данных. Его выделяют, затем на панели свойств
    разворачивается группа свойств "DataBindings" она содержит два свойства:




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

    32.Процессы верификации. Понятия качества. Оценка качества.
    Что такое качество и почему оно должно быть столь глубоко представлено (в виде самостоятельной
    области знаний) в SWEBOK? На протяжении многих лет отдельные авторы и целые организации
    определяли термин “качество” по-разному. Фил Кросби (Phil Crosby) в 1979 году дал определение качеству
    как “соответствие пользовательским требованиям”. Уотс Хемпфри (Watts Hamphrey, оригинальный автор
    концепции модели оценки зрелости CMM, а также PSP и TSP – People Software Process и Team Software
    Process) описывает качество как “достижение отличного уровня пригодности к использованию”. Компания
    IBM, в свою очередь, ввела в оборот фразу “качество, управляемое рыночными потребностями” (“marketdriven quality”). Критерий Бэлдриджа (Baldrige) для организационного качества (см. NIST - National Institute of
    Standards and Technology, “Baldrige National Quality Program”, http://www.quality.nist.gov) использует похожую
    фразу - “качество, задаваемое потребителем” (“customer-driven quality”), рассматривая удовлетворение
    потребителя в качестве главного соображения в отношении качества. Чаще, понятие качества используется в
    соответствии с определением системы менеджмента качества ISO 9001 как “степень соответствия присущих
    характеристик требованиям”

    1. Основы качества программного обеспечения (Software Quality Fundamentals)
    Согласие, достигнутое по требованиями к качеству (в оригинале - quality requirements), наравне с четким
    доведением до инженеров того, что составляет качество <получаемого продукта>, требуют обсуждения и
    формального определения многих аспектов качества.
    Инженеры должны понимать смысл, вкладываемый в концепцию качества, характеристики и значение
    качества в отношении разрабатываемого или сопровождаемого программного обеспечения.
    Важной идеей является то, что программные требования определяют требуемые характеристики качества
    программного обеспечения, а также влияют на методы количественной оценки и сформулированные для
    оценки этих характеристик <соответствующие> критерии приемки.

    1.1 Культура и этика программной инженерии (Software Engineering Culture and Ethics)
    Ожидается, что инженеры по программному обеспечению воспринимают вопросы качества программного
    обеспечения как часть своей <профессиональной> культуры. SWEBOK дает ссылки на источники,
    описывающие здоровую культуру программной инженерии.
    Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения,
    культуре и отношении инженеров <к своей работе>. IEEE Computer Society и ACM разработали кодекс этики
    (“моральный кодекс” – code of ethics) и профессиональной практики, основанный на восьми принципах,
    помогающих инженерам укрепить их отношение к качеству и независимость <в решении вопросов
    обеспечения достойного качества создаваемых программных продуктов> в их повседневной работе.

    1.2 Значение и стоимость качества (Value and Costs of Quality)
    Понятие “качество”, на самом деле, не столь очевидно и просто, как это может показаться на первый взгляд.
    Для любого инженерного продукта существует множество <интерпретаций> качества, в зависимости от
    конкретной “системы координат” (в оригинале – “перспективы”). Множество этих точек зрения необходимо
    обсудить и определить на этапе выработки требований к программному продукту. Характеристики
    качества могут требоваться в той или иной степени, могут отсутствовать или могут задавать определенные
    требования, все это может быть результатом определенного компромисса (что вполне перекликается
    с пониманием “приемлемого качества”, как менее жесткой точки зрения на обеспечение качества, как
    достижение совершенства).
    Стоимость качества (cost of quality) может быть дифференцирована на стоимость предупреждения
    <дефектов> (prevention cost), стоимость оценки (appraisal cost), стоимость внутренних (internal failure cost), а
    также внешних сбоев (external failure cost).
    Движущей силой программных проектов является желание создать программное обеспечение, обладающее
    определенной ценностью (значимое для решения определенных задач или достижения целей). Ценность
    программного обеспечения в может выражаться в форме стоимости, а может и нет. Заказчик, обычно,
    имеет свое представление о максимальных стоимостных вложениях, возврат которых ожидается в
    случае достижения основных целей создания программного обеспечения. Заказчик может, также, иметь
    определенные ожидания в отношении качества ПО. Иногда, заказчики не задумываются о вопросах качества и
    связанной с ними стоимостью. Является ли характеристики качества чисто декоративными (умозрительными)
    или, все же, это неотъемлемая часть программного обеспечения? Ответ, вероятно, находится где-то
    посередине, как почти всегда бывает в таких случаях, и является предметом обсуждения степени вовлечения
    заказчика в процесс принятия решений и полного понимания заказчиком стоимости и выгоды, связанной с
    достижением того или иного уровня качества. В идеальном случае, большинство такого рода решений должно
    приниматься процессе работы с требованиями (см. область знаний SWEBOK “Программные требования”),
    однако эти вопросы могут (и должны) подниматься на протяжении всего жизненного цикла программного
    обеспечения. Не существует каких-то <“стандартных”> правил того, как именно необходимо принимать такие
    решения. Однако, инженеры должны быть способны представить различные альтернативы (в достижении
    различного уровня качества) и их стоимость. Здесь SWEBOK приводит некоторые источники, в которых более
    подробно обсуждаются вопросы значимости качества и соответствующих характеристик стоимости.

    1.3 Модели и характеристики качества (Models and Quality Characteristics)
    В различных источниках (таксономиях и моделях) терминология характеристик качества программного
    обеспечения отличается. Каждая модель включает различное число уровней иерархии и общее число
    <”распознанных”> характеристик качества. Различные авторы создали разные модели качества со своим
    набором характеристик и атрибутов (в частности, Барри Боэм, автор спиральной модели жизненного цикла
    разработки программного обеспечения, которая рассматривается в отдельной дополнительной главе). Эти
    модели могут быть полезны для обсуждения, планирования, (адаптации) и оценки качества программных
    продуктов. ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 912601 Software Engineering - Product Quality, Part 1: Quality Model) – внутреннее качество, внешнее качество и
    качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного

    обеспечения (ISO14598-98 Software Product Evaluation).
    1.3.1 Качество процессов программного обеспечения (Software engineering process quality)
    Управление качеством (software quality management) и качество процессов программной инженерии (software
    engineering process quality) имеют непосредственное отношение к качеству создаваемого программного
    продукта.
    Модели и критерии оценки возможностей организаций, занимающихся разработкой программного
    обеспечения, прежде всего касаются рассмотрения организации проектных работ и аспектов управления.
    Соответственно, они рассматриваются в областях знаний SWEBOK “Управление программной инженерией”
    и “Процесс программной инженерии”.
    Конечно, невозможно полностью отделить качество процесса от качества продукта.
    Качество процесса, обсуждаемое в области знаний “Процесс программной инженерии”, влияют на
    характеристики качества продукта, которые, в свою очередь, отражаются в восприятии качества продукта в
    процессе эксплуатации со стороны заказчика.
    Существует два важнейших стандарта в области качества программного обеспечения. TickIT - касается
    рассмотрения общей системы менеджмента качества ISO 9001-00 в приложении к программным проектам
    (и, в частности, сочетания такого взгляда с положениями стандарта жизненного цикла ISO 12207) и
    представленный, также, в виде специальных рекомендаций ISO 90003-04 “Software and Systems Engineering Guidelines for the Application of ISO9001:2000 to Computer Software”.
    Другой важный стандарт – CMMI, обсуждаемый в области знаний “Процесс программной инженерии”,
    предоставляет рекомендации по совершенствованию процесса. (здесь нельзя не упомянуть и ISO
    15504 “Information Technology - Software Process Assessment”, известный как SPICE - Software Process
    Improvement and Capability dEtermination, который также рассматривается в упомянутой области знаний).
    Непосредственно с управлением качеством связаны процессные области (области компетенции)
    CMMI: обеспечение качества процесса и продукта (process and product quality assurance, категория
    процессов CMMI “Support”), проверка (verification, категория “Engineering”) и аттестация (validation,
    категория “Engineering”). При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов
    верификации, но не как самостоятельные процессы, в отличие, например, от стандарта 12207.
    Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для обеспечения качества
    программного обеспечения – CMMI или ISO 9001, продолжаются с самого создания этих стандартов.
    Сегодня можно сказать о том, что данные стандарты все же рассматривают как взаимодополняющие и, что
    сертификация по ISO 9001 помогает в достижении старших уровней зрелости по CMMI.
    1.3.2 Качество программного продукта (Software product quality)
    Прежде всего, инженеры должны определить цели создания программного обеспечения. В этом контексте,
    особо важно помнить, что требования заказчика - первичны и содержат требования в отношении качества,
    а не только функциональности (функциональные требования). Таким образом, инженеры ответственны за

    извлечение требований к качеству, которые не всегда представлены явно, а также обсуждение их важности
    и степени сложности их достижения. Все процессы, ассоциированные с качеством (например, сборка,
    проверка и повышение качества), должны проектироваться с учетом этих требований и несут на себе тяжесть
    дополнительных расходов (как важную составную часть стоимости программного обеспечения).
    Стандарт ISO 9126-01 (Software Engineering - Product Quality, Part 1: Quality Model) определяет для двух из
    трех описанных в нем моделей, связанные характеристики и "суб-характеристики" качества, а также метрики,
    полезные для оценки качества программных продуктов.
    Понимание термина “продукт” расширено включением всех артефактов, создаваемых на выходе всех
    процессов, используемых для создания конечного программного продукта. Примерами продукта являются
    (но не ограничиваются этим): полная спецификация системных требований (system requirements specification),
    спецификация программных требований для программных компонент системы (software requirements
    specification, SRS), модели, код, тестовая документация, отчеты, создаваемые в результате работ по анализу
    качества. Хотя, чаще всего термин качество используется в отношении конечного продукта и поведения
    системы в процессе эксплуатации, хорошей инженерной практикой является требование к тому, чтобы
    соответствие заданным характеристикам качества оценивалось и для промежуточных результатов/продуктов
    жизненного цикла в рамках всех процессов программной инженерии.

    1.4 Повышение качества (Quality Improvement)
    Качество программного обеспечения может повышаться за счет итеративного процесса постоянного
    улучшения. Это требует контроля, координации и обратной связи в процессе управления многими
    одновременно выполняемыми процессами: (1) процессами жизненного цикла, (2) процессом обнаружения,
    устранения и предотвращения сбоев/дефектов и (3) процессов улучшения качества.
    К программной инженерии применимы теории и концепции, лежащие в основе совершенствования качества.
    Например, предотвращение и ранняя диагностика ошибок, постоянное совершенствование (continuous
    improvement) и внимание к требованиям заказчика (customer focus), составляющие принцип “building in quality”.
    Эти концепции основываются на работах экспертов по качеству, пришедших к мнению, что качество продукта
    напрямую связано с качеством используемых для его создания процессов.
    Такие подходы, как TQM (Total Quality Management – всеобщее управление качеством) PDCA (Plan, Do,
    Check, Act – Планирование, Действие, Проверка, Реакция/Корректировка), являются инструментами
    достижения задач, связанных с качеством. Поддержка менеджмента помогает в выполнении процессов,
    оценке продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая программа
    совершенствования (improvement program, обычно является целевой и охватывает работу подразделения или
    организации, в целом) детально идентифицирует все действия и проекты по улучшению <отдельных аспектов
    деятельности> в рамках определенного периода времени, за который такие проекты можно осуществить с
    успешным решением соответствующих задач. При этом, поддержка менеджмента означает, что все проекты
    по улучшению обладают достаточными ресурсами для достижением поставленных целей. Поддержка
    менеджмента тесно связана с реализацией активного взаимодействия в коллективе, и должна предупреждать
    возникновение потенциальных проблем (и пассивного или даже активного противодействия реализации
    программы совершенствования или отдельных ее проектов). Формирование рабочих групп, поддержка

    менеджеров среднего звена и выделенные ресурсы на уровне проекта – эти вопросы обсуждаются в области
    знаний “Процесс программной инженерии”.

    33.Процессы верификации. Тестирование.
    2.1 Подтверждение качества программного обеспечения (Software Quality Assurance, SQA)
    Процессы SQA обеспечивают подтверждение того, что программные продукты и процессы жизненного цикла
    проекта соответствуют заданным требованиям. Такое подтверждение проводится на основе планирования
    (planning), постановки <работ> (enacting) и исполнения (performing) набора действий, направленных на то,
    чтобы качество стало неотъемлемой частью программного обеспечения (см. выше определения качества).
    Такой взгляд подразумевает ясное и точное формулирование проблемы, а также то, что определены и
    четко выражены (полны и однозначно интерпретируемы) требования к соответствующему <программному>
    решению. SQA добивается обеспечения качества в процессе разработки и сопровождения за счет выполнения
    различных действий на всех этапах <жизненного цикла>, что позволяет идентифицировать проблемы еще на
    ранних стадиях, которые практически неизбежны в любой сложной деятельности.
    Такая идентификация возможна во многих случаях (если даже не в большинстве ситуаций), когда проблема
    еще является риском и возможно ее предотвращение. Это – задача управления рисками, которое вполне
    можно было бы вынести в качестве самостоятельной области знаний SWEBOK, в силу уже достаточно
    большого совокупного опыта не только индустрии ИТ или дисциплины управления проектами. Так или иначе,
    можно сказать, что уже было подчеркнуто при обсуждении SQM, управление рисками (Risk Management)
    является серьезным дополнительным инструментом для обеспечения качества программного обеспечения.
    Однако, ограничиваться упоминанием управления рисками только в контексте SQM было бы неправильно, так
    как сегодняшнее понимание Risk Management включает в себя не только вопросы предупреждения рисков, но
    и управление процессом разрешения проблем.
    SQA, как это сформулировано SWEBOK, концентрируется на процессах. Роль SQA состоит в том, чтобы
    обеспечить соответствующее планирование процессов, дальнейшее исполнение процессов на основе
    заданного плана и проведение необходимых измерений процессов с передачей результатов измерений
    заинтересованным сторонам (организационными структурам и лицам).
    SQA-план определяет средства, которые будут использоваться для обеспечения соответствия
    разрабатываемого продукта заданным пользовательским требованиям с максимальным уровнем качества,
    возможным при заданных ограничениях проекта (т.е., в предлагаемой в данном переводе терминологии
    – приемлемым уровнем качества). Для того, чтобы этого добиться, в первую очередь необходимо, чтобы
    цели качества были четко определены и понимаемы (а также, однозначно интерпретируемы, что является
    обязательным условием любых целей и соответствующих требований). Это, в обязательном порядке,
    должно быть отражено в соответствующих планах управления <проектом>, разработки и сопровождения.
    Подробности можно найти в стандарте IEEE 730-02 “IEEE Standard for Software Quality Assurance Plans”.
    Конкретные работы и задачи по обеспечению качества структурируются с детализацией требований

    по их стоимости и ассоциированным ресурсам, целям с точки зрения управления и соответствующим
    расписанием в контексте целей, заданных планами управления, разработки и сопровождения. SQA-план
    должен согласовываться с планом конфигурационного управления (см. область знаний “Software Configuration
    Management”). План SQA идентифицирует документы, стандарты, практики и соглашения, применяемые
    при контроле проекта, а также то, как эти аспекты будут проверяться и отслеживаться для обеспечения
    достаточности и соответствия заданному плану. Также, SQA-план идентифицирует метрики, статистические
    техники, процедуры формирования сообщений о проблемах и проведения корректирующих действий, такие
    средства (в оригинале SWEBOK используется термин resources), как инструменты, техники и методологии,
    вопросы безопасности физических носителей (это, скорее, вопрос базовой инфраструктуры проектов, а не
    SQA-плана), тренинги, а также формирование отчетности и документации, относящиеся к вопросам SQA.
    Кроме того, SQA-план касается и вопросов работ по обеспечению качества, относящихся к другим типам
    деятельности, описанным в <различных> планах по созданию программного обеспечения, к которым также
    относятся поставка, установка, обслуживание (поддержка и сопровождение) заказных и/или тиражируемых/
    готовых программных решений (commercial off-the-shelf, COTS), необходимых для данного проекта
    программного обеспечения. Наконец, SQA-план может содержать необходимые для обеспечения качества
    критерии приемки программного обеспечения и действия по формированию отчетности и управлению <и
    контролю над> работами.

    2.2 Проверка (верификация) и аттестация (Verification and Validation, V&V)
    С целью краткости <изложения> (что, не мешало их детализировать достаточным образом, в
    виде соответствующих "подтем" в рамках формата SWEBOK, так как, будучи тесно связанными и
    взаимодополняющими, проверка и аттестация все же обладают и самостоятельным содержанием), проверка
    (верификация) и аттестация – Validation and Verification (V&V*) – рассмотрены в SWEBOK в рамках единой
    темы. В свою очередь, они являются самостоятельными темами, например, в стандарте жизненного цикла
    программного обеспечения 12207. Стандарт IEEE 1059-93 “IEEE Guide for Software Verification and Validation
    Plans” дает такое определение V&V*: “Проверка и аттестация программного обеспечения – упорядоченный
    подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия,
    прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как
    неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований”
    (здесь и далее, как и при обсуждении SQA, пользовательские требования, скорее, не user requirements в
    понимании управления требованиями, а потребности пользователей, ради удовлетворения которых создается
    программное обеспечение).
    * здесь и далее в переводе намеренно используется обозначение V&V, как общепринятое в индустрии
    программного обеспечения
    V&V напрямую адресуется вопросам качества программного обеспечения и использует соответствующие
    техники тестирования для обнаружения тех или иных дефектов. V&V может применяться для промежуточных
    продуктов, однако, в том объеме, который соответствует промежуточным “шагам” <соответствующих>
    процессов жизненного цикла.
    V&V напрямую адресуется вопросам качества программного обеспечения и использует соответствующие
    техники тестирования для обнаружения тех или иных дефектов. V&V может применяться для промежуточных

    продуктов, однако, в том объеме, который соответствует промежуточным “шагам” <соответствующих>
    процессов жизненного цикла.
    Процесс V&V определяет в какой степени продукт (результат) тех или иных работ по разработке и
    сопровождению соответствует требованиям, сформулированным в рамках этих работ, а конечный продукт
    удовлетворяет заданным целям и пользовательским требованиям (корректнее было бы говорить не только
    и, может быть, не столько о “требованиях”, то есть потребностях, сколько об ожиданиях). Верификация –
    попытка обеспечить правильную разработку продукта (продукт построен правильным образом; обычно, для
    промежуточных, иногда, для конечного продукта), в том значении, что получаемый в рамках соответствующей
    деятельности продукт соответствует спецификациям, заданным в процессе предыдущей деятельности.
    Аттестация – попытка обеспечить создание правильного продукта (построен правильный продукт; обычно,
    в контексте конечного продукта), с точки зрения достижения поставленной цели. Оба процесса – верификация
    и аттестация – начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают исследованию
    (экспертизу) ключевых возможностей продукта как в контексте непосредственно предшествующих результатов
    (промежуточных продуктов), так и с точки зрения удовлетворения соответствующих спецификаций.
    Целью планирования V&V является обеспечение процессов верификации и аттестации необходимыми
    ресурсами, четкое назначение ролей и обязанностей. Получаемый план V&V документирует и <детально>
    описывает различные ресурсы, роли и действия, а также используемые техники и инструменты. Понимание
    различных целей каждого действия в рамках V&V может помочь в точном планировании техник и ресурсов
    (включая, финансовые), необходимых для достижения заданных целей. Стандарты IEEE 1012-98 “Software
    Verification and Validation” и 1059-93 “IEEE Guide for Software Verification and Validation Plans” (Appendix A)
    определяют типичное содержание плана проверки и аттестации.
    План также касается аспектов управления, коммуникаций (взаимодействия), политик и процедур в отношении
    действий по верификации и аттестации и их взаимодействия. Кроме того, в нем могут быть отражены вопросы
    формирования отчетности по дефектам и документирования требований (конечно, с точки зрения выполнения
    задач по проверке и аттестации продуктов).

    2.3 Оценка (обзор) и аудит (Review and Audits)
    В целях краткости изложения, оценка (review) и аудит объединены в SWEBOK в одну тему (в данном случае,
    такое объединение выглядит более обоснованным, чем в случае V&V, где частью процесса аттестации могут
    быть, например, приемо-сдаточные испытания, наверняка отсутствующие при верификации; оценка же и
    аудит, на практике, часто отличаются лишь степенью детализации, акцентам в отношении исследуемых
    аспектов, лицом/органом, выполняющим соответствующие работы, а также степенью формализации
    процесса). В стандарте жизненного цикла 12207 эти работы разделены на самостоятельные темы. Более
    детально они описаны в стандарте IEEE 1028-97 “IEEE Standard for Software Reviews”, в котором представлено
    пять типов оценок и аудитов (обратите внимание, что классификация рассматривает аудит лишь как один из
    типов оценки):





    Управленческие оценки (management reviews)
    Технические оценки (technical reviews)
    Инспекции (inspections)
    “Прогонки” (walk-throughs)



    Аудиты (audtis)

    2.3.1 Управленческие оценки (Management Reviews)
    “Назначение управленческих оценок состоит в отслеживании развития <проекта/продукта>, определения
    статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности
    управленческих подходов, используемых для достижения поставленных целей.” - IEEE 1028-97 “IEEE
    Standard for Software Reviews”. Управленческие оценки поддерживают принятие решений о внесении
    изменений и выполнении корректирующих действий, необходимых в процессе выполнения программного
    проекта. Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время,
    контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи
    фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), V&V-отчетов, а также различных типов
    планов – управления рисками, проекта/проектного управления, конфигурационного управления, безопасности
    <использования> программного обеспечения (safety), оценки рисков и т.п. Информация, связанная с
    данными вопросами, также представлена в областях знаний “Управление программной инженерией”
    и “Конфигурационное управление”.
    2.3.2 Технические оценки (Technical Reviews)
    “Назначением технических оценок является исследование программного продукта для определения его
    пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с
    утвержденными спецификациями и стандартами.” - IEEE 1028-97 “IEEE Standard for Software Reviews”.
    2.3.2 Технические оценки (Technical Reviews)
    “Назначением технических оценок является исследование программного продукта для определения его
    пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с
    утвержденными спецификациями и стандартами.” - IEEE 1028-97 “IEEE Standard for Software Reviews”.
    Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее
    решения (decision-maker); лидер оценки (review leader); регистратор (recorder); а также технический персонал,
    поддерживающий (непосредственно исполняющий) действия по оценке. Техническая оценка требует, в
    обязательном порядке, наличия следующих входных данных:






    Формулировки целей
    Конкретного программного продукта (подвергаемого оценке)
    Заданного плана проекта (плана управления проектом)
    Списка проблем (вопросов), ассоциированных с продуктом
    Процедуры технической оценки

    Команда <технической оценки> следует заданной процедуре оценки. Квалифицированные (с технической
    точки зрения) лица представляют обзор продукта (представляя команду разработки). Исследование
    <продукта> проводится в течение одной и более встреч (между теми, кто представляет продукт и теми, кто
    провидит оценку). Техническая оценка завершается после того, как выполнены все предписанные действия по
    исследованию продукта.

    2.3.3 Инспекции (Inspections)
    “Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте.” IEEE 1028-97 “IEEE Standard for Software Reviews”. Существует два серьезных отличия инспекций от оценок
    (управленческой и технической):
    1. Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам команды
    инспектирования, не должны участвовать в инспекциях.
    2. Инспекция должна вестись под руководством непредвзятого (независимого от проекта и его целей)
    лидера, обученного техникам инспектирования.
    Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного
    продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Инспекции (как
    временные организационные единицы – группы, команды) включают лидера, регистратора, рецензента
    и нескольких (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в
    различных областями экспертизы (обладать различными областями компетенции), например, предметной
    области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции
    проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь
    на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнесправил, функциональных требований или атрибутов качества). Каждый член команды должен исследовать
    программный продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно,
    те или иные аналитические техники (описанные ниже в подтеме 3.3.3) в небольшим фрагментам продукта или
    к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая
    найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе
    инспекции лидер руководит сессией <инспекции> и проверяет, что все <члены команды> подготовились к
    инспектированию. Общим инструментом, используемым при инспектировании, является проверочный лист
    (checklist), содержащий аномалии и вопросы, связанные с аспектами <программного продукта>, вызывающими
    интерес. Результирующий лист часто классифицирует аномалии (см. стандарт IEEE 1044-93 “IEEE Standard for
    the Classification of Software Anomalies”) и оценивается командой с точки зрения его завершенности и точности.
    Решение о завершении инспекции принимается в соответствии с одним (любым) из трех критериев:
    1. Принятие <продукта> с отсутствием либо малой необходимостью переработки
    2. Принятие <продукта> с проверкой переработанных фрагментов
    3. Необходимость повторной инспекции
    Инспекционные встречи занимают, обычно, несколько часов, в отличие от технической оценки и аудита,
    предполагающих, в большинстве случаев, больший объем работ и, соответственно, длящиеся дольше.
    2.3.4 Прогонки (Walk-throughs)
    “Назначение прогонки состоит в оценке программного продукта. Прогонка может проводиться с целью
    ознакомления (обучения) аудитории с программным продуктом.” - IEEE 1028-97 “IEEE Standard for Software
    Reviews”. Главные цели прогонки состоят (по IEEE 1028) в:




    Поиске аномалий
    Улучшении продукта
    Обсуждении альтернативных путей реализации



    Оценке соответствия стандартам и спецификациям

    Прогонка похожа на инспекцию, однако, обычно проводится менее формальным образом. В основном,
    прогонка организуется инженерами для других членов команды с целью получения отклика от них на свою
    работу, как одного из элементов (техник) обеспечения качества.
    2.3.5 Аудиты (Audits)
    “Назначением аудита программного обеспечения является независимая оценка программных продуктов и
    процессов на предмет их соответствия применимым регулирующим документам, стандартам, руководящим
    указаниям, планам и процедурам.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Аудит является
    формально организованной деятельностью, участники которой выполняют определенные роли, такие как
    главный аудитор (lead auditor), второй аудитор (another auditor), регистратор (recorder) и инициатор (initiator). В
    аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате
    аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде <разработки>
    для принятия корректирующих действий.
    При том, что существуют различные формальные названия (и классификации) оценок и аудита (например, как
    мы видели в стандарте IEEE 1028-97), важно отметить, что такого рода действия могут проводиться почти для
    любого продукта на любой стадии процесса разработки или сопровождения.