Our Blog

Введение

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

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

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

Общая часть.

Информационная система. Что это?

Рис.1. Структура любой информационной системы

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

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

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

Это:

  1. техническое обеспечение;
  2. программное обеспечение;
  3. математическое обеспечение;
  4. сетевая инфраструктура.

От ничего к информационной системе. Этапы создания.

 

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

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

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

 

Информационные технологии

Термин «технология» можно определить так: — это последовательность действий, которая приводит к гарантированному получению результата и может быть передана другому человеку за короткий промежуток времени.

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

Составляющие информационной технологии

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

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

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

• включать весь набор элементов, необходимых для достижения поставленной цели;

• иметь регулярный характер.

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

Инструментарий информационной технологии

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

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

Информационная система

В самой простой трактовке можно принять следующее: информационная система— это система работы с информацией. А что же такое система?

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

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

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

Технологические операции с данными

  1. Сбор данных (чтение с входных устройств, это и ручной ввод с клавиатуры, и чтение данных с портов ввода и.т.п.);
  2. Преобразование;
  3. Хранение;
  4. Обработка;
  5. Передача;
  6. Вывод (визуализация, представление, отображение).

Проектирование информационной системы.

Особенности проектирования ИС

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

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

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

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

Объем работ по проектированию зависит от масштабности разрабатываемой системы.

Оценка масштабности зависит от следующих факторов:

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

 

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

 

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

 

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

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

В процессе проектирования при повышении степени детализации теряется смысловая составляющая между бизнесом и пониманием его смысла IT-шниками.

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

Рис.2 Информационные пазлы системы

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

  • Форма
  • Бизнес-правила
  • Бизнес-логика
  • Роли

 

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

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

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

 

Нотации и подходы к функциональному моделированию

На текущий момент, существуют следующие системы описания предметной области в терминах, специалистов IT-области:

  • Методология IDEF3 представляющая собой методологию функционального моделирования, согласно которой система представляется как совокупность взаимодействующих процессов/работ/функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Поэтому исследование или разработка любой сложной системы начинается с функционального анализа и моделирования как системы в целом, так и всех ее подсистем.
    Методология IDEF0 предназначена для функционального моделирования, то есть моделирования выполнения функций объекта, путем создания
    описательной графической модели, показывающей что, как и кем делается в рамках функционирования любого предприятия. Разработанные IDEF0 модели предназначены для документирования процессов производства, отображения какая информация и ресурсы используются на каждом этапе.
  • Методология IDEF3 является способом графического моделирования, предназначенным для описания и документирования информационных
    потоков в системе, в которой процессы выполняются в заданной последовательности, взаимоотношений между процессами обработки информации и объектами, являющихся частью этих процессов и участвующие совместно в одном процессе.

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

  • Система ARIS представляющая
    собой комплекс средств анализа и моделирования деятельности предприятия, а
    также разработки автоматизированных информационных систем. В ее основу положена
    обширная методология, вобравшая в себя особенности различных методов
    моделирования, отражающих разные взгляды на исследуемую систему.
    Рассматриваемая методология основывается на разработанной профессором Шером
    теории «Построения Интегрированных Информационных Систем»,
    определяющей принципы визуального отображения всех аспектов функционирования
    анализируемых компаний.

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

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

В Архимейте процессы представляются на трех уровнях:

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

Сквозной пример

Описание предметной области

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

Зададимся вопросами: «Кто является участником процесса»? и «Что они делают, т.е. какие работы они выполняют»?

 

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

  1. Офис-менеджер
  2. Ассистент сервиса (оператор сервис-бюро)
  3. Мастер-приёмщик (мастер-консультант)
  4. Менеджер отдела запасных частей
  5. Работник склада
  6. Мастер цеха
  7. Механик
  8. Кассир
  9. Бухгалтер
  10. Руководитель отдела сервиса и запасных частей

 

 

Функции участников рабочего процесса ремонта автомобилей

 

  1. 1. Офис-менеджер

1.1. Встретить клиентов

1.2. Получить информацию о причинах их визита

1.3. Направить клиентов в зону сервиса, если это необходимо

1.4. Информирование клиентов по телефонным звонкам

  1. 2. Ассистент сервиса

2.1. Приветствие клиентов в зоне сервиса и начало беседы

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

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

2.4. Напоминание клиенту о необходимости принести требуемые документы.

2.5. Подтверждение заказа и сроков.

  1. 3. Мастер-приёмщик (мастер-консультант)

3.1. Приемка автомобиля и составление заказ — наряда:

3.1.1. Приветствие клиента и начало работы.

3.1.2. Открытие компьютерной версии заказ-наряда и внесение дополнительных

3.1.3. данных клиента.

3.1.4. Уточнение пожеланий клиента.

3.1.5. Определение объема работ и составление заказ — наряда путем тщательной дефектовки (беседа с клиентом у автомобиля, приемка на подъемнике, при необходимости – совместный тест-драйв).

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

Внимательно осматриваются:

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

Внутренний осмотр автомобиля включает:

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

Осмотр подкапотного пространства:

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

Осмотр автомобиля снизу:

1.1. При нахождении оси автомобиля на уровне глаз:

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

1.2.
При полном поднятии автомобиля на подъемнике, осматривая автомобиль от задней части к передней:

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

 

3.2. Консультирование клиента в отношении объема, продолжительности и стоимости работ.

3.3. Обязательное предложение дополнительной продукции и услуг.

3.4. Согласование с клиентом способа оплаты и (если требуется) лимита расходов при расширении заказа.

3.5. При необходимости – составление предварительной сметы расходов.

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

 

Ремонт и оказание услуг:

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

Контроль качества и подготовка автомобиля к выдаче:

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

 

Выдача автомобиля и расчеты с клиентом:

  • Приветствие клиента и начало беседы.
  • Идентификация клиента и его права забрать автомобиль на основании копии заказ -наряда.
  • Разъяснение выполненных работ и (если предоставлялись) – дополнительных бесплатных услуг и
    передача счета.
  • Формирование у клиента предоставления о широких возможностях предприятия.
  • При необходимости – приемка и проверка подменного автомобиля.
  • Обязательное консультирование клиента в отношении необходимого в ближайшем будущем
    технического обслуживания.
  • Личная выдача автомобиля клиенту после оплаты счета.
  • Профилактические указания в отношении мер по обеспечению качества сервиса.
  • Мастер-консультант лично прощается с клиентом.

 

4.Менеджер отдела запасных частей

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

 

5.Работник склада

 

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

 

6.Мастер цеха

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

7.Механик

  • Непосредственно выполняет работы по техническому обслуживанию и ремонту Диагностирует технические дефекты
  • Устраняет найденные технические дефекты После окончания ремонтных работ производит самостоятельный контроль их результатов
  • Оформление приёмо-сдаточной документации

8. Кассир

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

9.Бухгалтер

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

10. Руководитель отдела сервиса и запасных частей

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

Схематичное представление функций

Рис.3

Рис.4

Рис.5

Рис.6

 

Визуальное представление функций

Для примера приведем описание работы в отделе снабжения предприятия. В качестве примера
приведем описание процесса и его представление в нотации IDEF0 c источника [6].
Менеджер по закупу запасных частей дает следующее описание своих процессов:

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

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

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

1.Материал
2.Заказ
3.Текущий поставщик
4.Главный бухгалтер
5.Заказ на поставку
6.Отдел снабжения
7.Потенциальный поставщик
8.Заявитель
9.Заместитель
10.Выбранный поставщик
11.Контракт
12.Предложение
13.Требование на закупку
14.Проектный счет

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

  1. Сделать заявку на материал.
  2. Идентифицировать потенциальных поставщиков.
  3. Идентифицировать текущего поставщика.
  4. Запросить предложения.
  5. Произвести оценивание предложений.
  6. Заказать требуемый материал.
  7. Подготовить требование на закупку.
  8. Получить разрешение главного бухгалтера.
  9. Получить утверждающую подпись.
  10. Представить подписанное требование на закупку.

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

Начальный список может включать следующие данные:

  1. Есть 7 текущих поставщиков.
  2. Никто, кроме назначенного главного бухгалтера или
    его заместителя, не может дать разрешение на закупки по соответствующему
    счету.
  3. Заявитель не может быть одновременно лицом,
    разрешающим или утверждающим требование.

Как только начальная задача идентификации объектов, работ, фактов и ограничений приближается к завершению, можно приступить к разработке схематики процессов IDEF3 (или набора схематик). Наблюдения, записанные во время интервью, при разработке схематик процессов используются в качестве базиса. Возможные UOB, внесенные в список во время анализа данных, на этом этапе используются для
построения UOB. Факты и ограничения, идентифицированные в записях, полученных во время интервью, используются для построения детальных описаний UOB.
Разработка схематики процессов включает два основных этапа: (1) построение UOB в правильной последовательности; (2) разработка детальных описаний UOB.

Рис.7 Схематика процессов.

Контрольный пример

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

Заключение

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

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

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

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

 

 

 

 

Список использованных источников

  1. Якунин Ю.Ю, Красноярский СФУ-Технологии Разработки ПО,
    2008.
  2. http://citforum.ru/seminars/cis99/vest_03.shtml
  3. http://www.intuit.ru/studies/courses/2195/55/lecture/1628?page=1
  4. http://pubs.opengroup.org/architecture/archimate2-doc/m/index.html
  5. http://www.itstan.ru/funk-strukt-analiz/idef0-metodologija-funkcionalnogo-modelirovanija.html
  6. http://dit.isuct.ru/ivt/books/CASE/case10/idef3/5_5.2.1.htm
  7. ГОСТ 34.601-90
  8. РД 50-34.698-90
  9. ISO 12207-95

10. РД IDEF0-2000

11. Стандарт IDEFIX

12. ГОСТ 34.602-89

13. ISO 12207

14. ЕСПД

15. ГОСТ 34.201-90

16. ГОСТ 34.603-92

17. ISO15910:1999 (ГОСТР–2002)

18. ISO18019:2004

Картинка профиля admin

admin

2 Comments

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

    Ответить
    • Картинка профиля admin

      Сергей, смысл данного разделения в том, что при разработке приходится выполнять разные виды работ. У сетевой структуры БОЛЬШОЙ пласт работ связанный с настройкой функционирования сети. При этом множество такой работы находится на стороне смежный систем. Т.е. не связанные с «железом». Если же ты не выделяешь данные структуру, то ты начинаешь зависеть при обсуждении данного вопроса от мысленной связи с железкой. Также с математическим обеспечением. Разные артефакты. Программный код и алгоритм. Если ты не разделяешь разные по сути работы (артефакты), то не можешь управлять процессом во времени. Ведь ты можешь иметь законченный алгоритм, но не иметь, или не заниматься разработкой программного обеспечения.

      Ответить

So, what do you think ?

Перейти к верхней панели