Инжиниринг ИС презентация

(RR, Visio)

явлениях и процессах независимо от формы их представления. (Закон РФ «Об информации, информатизации и защите информации»)
Данные – это информация, представленная в виде, пригодном для обработки автоматическими средствами (ISO – International Organization of Standardization (Международная организация по стандартизации))

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

ISO, IEC, ГОСТ);
- стандарты международных консорциумов и комитетов по стандартизации (например, стандарты ОМG);
- стандарты «де-факто» – официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL);
- фирменные стандарты (например, Microsoft ODBC).

ИСЖТ))

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

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

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

самом начале разработки можно достаточно точно и полно сформулировать все требования.

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

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

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

Барри Боэм, 1988 г.

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

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

Методология быстрой разработки приложений (Rapid Application Development, RAD)

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

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

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

Экстремальное программирование (eXtreme Programming, XP – автор Кент Бек, 1999)

Process Modeller
5-10 IBM Rationa Rose|

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

сроки и финансирование работ
техническое задание – основные требования к системе (ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы»)

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

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

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

и выходных форм

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

их разбиения на множество меньших независимых задач, легких для понимания и решения.
2. Принцип иерархического упорядочения – организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
3. Принцип концептуальной общности  заключается в следовании единой философии на всех стадиях жизненного цикла
4. Принцип абстрагирования - выделение существенных элементов системы и отвлечении от несущественных.
5. Принцип формализации - строгий методический подход к решению проблемы и описании системы на формальном языке, пригодном для ее анализа, проектирования и разработки, а также автоматизированной генерации кода и БД.

или однотипных элементов в разных моделях.
7. Принцип логической независимости - концентрации внимания на логическом проектировании в целях обеспечения независимости от физической реализации.
8. Принцип многомодельности - единственная модель не может с достаточной степенью адекватности описать различные аспекты сложной системы.
9. Принцип непротиворечивости (согласованности) - согласованность элементов моделей и самих моделей между собой.
10. Принцип информационной закрытости (инкапсуляции) - содержание внутреннего устройства элементов системы должно быть скрыто друг от друга - обмен информацией между элементами системы только в минимально необходимом объеме и ограничение доступа к операциям и данным каждого из них.
11. Принцип полиморфизма  –построения элементов модели таким образом, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Или свойство родственных элементов решать сходные по смыслу проблемы разными способами.

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

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

описывают поведение системы и/или ее отдельных элементов. Как правило, такие модели описывают порядок действий или состояния системы и переходы между ними. Другими словами, в этих моделях явно или не явно присутствует понятие времени;

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

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

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

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

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

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

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

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

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

подфункции, подфункции – на задачи и т.д. до конкретных процедур

СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА К МОДЕЛИРОВАНИЮ СИСТЕМ

Система

и ее внешнего окружения до определения окончательных требований к ней

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

– 2000: прямоугольник, содержащий имя и номер и используемый для описания функции

ФУНКЦИОНАЛЬНЫЙ БЛОК

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

ИНТЕРФЕЙСНАЯ ДУГА

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

ТОЧКА ЗРЕНИЯ

Иначе диаграмма будет плохо читаемой.
2. Функциональные блоки должны располагаться слева направо сверху вниз в порядке доминирования.
3. Следует избегать излишнего пересечения стрелок.

ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ДИАГРАММ

быть и обратные связи по входу и управлению.

ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ДИАГРАММ

описания циклов.

Обратная связь по управлению – выход нижестоящей работы передается на управление вышестоящей

Обратная связь по механизму – выход нижестоящей работы создает ресурсы, выполняющие вышестоящую работу

в) обратная связь по механизму

миром. Они могут начинаться у границы диаграммы и заканчиваться у функционального блока и наоборот. Такие стрелки называются граничными [8]. Граничные стрелки помечаются с помощью ICOM-меток (Input, Control, Output, Mechanism)

ГРАНИЧНЫЕ СТРЕЛКИ

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

ТОННЕЛЬНЫЕ СТРЕЛКИ

поддержку набора соответствующих определений, ключевых слов, повествований, изложений и т.д, которые характеризуют объект, отраженный данным элементом. Этот набор – глоссарий, являющийся описанием сущности данного элемента.
FEO-диаграмма (For Exposition Only) – это диаграмма, которая поясняет особо интересные и тонкие аспекты диаграмм. Эти диаграммы не ограничены синтаксисом IDEF0. В них может быть текстовая, графическая информация, схемы, альтернативная точка зрения на процесс и т.п.

ГЛОССАРИЙ И FEO-СТРАНИЦА

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

МАСТЕРСКАЯ СТРАНИЦА (КАРКАС ДИАГРАММЫ)

постройки дачного домика

Точка зрения: владельца дачного участка

1. Строим контекстную диаграмму.

преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;
- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);
- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;
- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;
- вызов (англ. call) – стрелка указывает, что некоторая часть работы выполняется за пределами рассматриваемого блока. Стрелки выхода рисуются исходящими из нижней грани работы.

из которых она состоит.

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

Регламентирующая (управляющая, подчиненная) связь

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

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

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

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

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

и ту же информацию.

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

стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер