Жизненный цикл имитационной модели
На основе имитационной модели можно построить самые точные и действенные методы анализа и прогнозирования показателей эффективности бизнес-процессов.
Для дальнейшего рассмотрения методики имитационного моделирования выделим четыре главные категории бизнес-процессов: процессы, связанные с работой над проектом, производственные процессы, распределительные процессы и процессы обслуживания клиентов.
Такая классификация, разумеется, не означает, что все бизнес-процессы четко попадают в одну из этих категорий. Например, обслуживание клиентов может включать в себя реализацию как функций приема заказов, так и функций их выполнения. В этом случае прием заказов является процессом обслуживания клиентов, а выполнение заказов – производственным процессом.
Процессы, связанные с работой над проектом.
Подобные процессы, как правило, выполняются одним человеком или группой людей. Типичными примерами служат разработка нового продукта и административные процессы. Обычно анализ подобных процессов проводится с использованием инструментария управления проектом. Тем не менее, оценки времени полного цикла процесса и требований к ресурсам, получаемые в результате анализа, основанного на методике имитационного моделирования, являются более точными, так как временные параметры выполнения проекта крайне неустойчивы, а совместное использование ресурсов приводит к появлению множества взаимосвязей.
При создании корректной имитационной модели проекта в первую очередь рассматривается моделирование следующих элементов: приоритеты, выполнение срочных работ, разбиение на смены, простой, сверхурочные работы и кривые обучения.
Одним из самых важных моментов, на который следует обратить внимание при имитационном моделировании работ над проектом, является процедура повторения измерений. Поскольку временные параметры крайне неустойчивы, один прогон модели даст только один вариант развития бизнес-процессов. На основе множества повторов измерений можно получить несколько вариантов сценария, что позволит получить более точные оценки и выделить наиболее уместные интервалы для фиксации показателей эффективности.
Производственные процессы
Результатом производственных процессов является достаточно большое количество различных “продуктов”, разбитых на группы или же получаемых в непрерывном потоковом режиме. Типичными примерами служат выполнение заказов, работа отдела счетов к оплате или обработка заявок.
Такие операции, как разбиение на группы, объединение групп, сборка, разборка, монтаж, контроль качества и устранение брака, представляют собой типичные функции, реализуемые производственными процессами. Для того чтобы точно смоделировать эти функции, модель должна отслеживать информацию об отдельных объектах потока и их атрибутах. Кроме того, в ходе создания модели важно учитывать правила построения очередей, а также моделирование простоя.
Цель моделирования производственных процессов, как правило, состоит в получении устойчивой схемы, поскольку последовательность выпускаемой продукции повторяется. Важной процедурной концепцией анализа эффективности является определение периода неустойчивой работы и устранение искажения, вносимого статистическими данными, собранными за такой период.
Распределительные процессы
Распределительные процессы включают в себя транспортировку и доставку, в ходе которых происходит перемещение продукции или людей между различными точками в сети распределения. Фундаментальным отличием транспортировки от доставки является то, что потоковые объекты при транспортировке – это люди, а не товары.
Типичные процессы транспортировки можно найти в системах общественного транспорта. На типичных процессах доставки основаны сбыт произведенной продукции, доставка почты и товаров покупателю.
При моделировании распределительных процессов, для отслеживания таких характеристик, как место назначения, размер или затраты, важно описать свойства потоковых объектов. При моделировании перемещения иногда будет более правильным представлять ресурсы транспортировки как потоковые объекты.
Процессы обслуживания клиентов
Процессы обслуживания клиентов представляют собой одну из важнейших областей применения имитационного моделирования, поскольку в типичном процессе обслуживания суммарное время ожидания может достигать 95 % общего времени обработки.
Процессами обслуживания клиентов могут являться: оказание услуг по телефону (справочные центры), работа «фабрик» услуг (рестораны, центры копирования), «магазинов» услуг (госпитали, ремонтные мастерские) и универмагов.
Имитационное моделирование процессов обслуживания клиентов считается исключительно сложной задачей, так как в данном случае как потоковые объекты, так и ресурсы – это люди. Люди обладают гораздо более сложным и непредсказуемым поведением по сравнению с продуктами, документами, оборудованием или транспортными средствами. Например, клиенты, стоящие в очереди, могут вступать в пререкания, схитрить тем или иным способом или вообще уйти. Чтобы смоделировать подобные ситуации требуется значительная гибкость программирования.
Как правило, время обслуживания непостоянно, а моменты появления клиентов случайны. Поэтому для корректного представления необходимо использовать вероятностные распределения.
Поскольку поступление в систему носит циклический и случайный характер, системы обслуживания редко находятся в устойчивом положении. Поэтому было бы правильным представлять осуществление операций в такой системе в рамках временных окон (периодов) и соответствующим образом описывать элементы модели.
Виды инструментария для имитационного моделирования.
За последние несколько лет был разработан целый ряд новых программных инструментов, непосредственно предназначенных для моделирования бизнес-процессов. В большинстве этих продуктов бизнес-процессы описываются с использованием графических символов или объектов. Отдельные функции процесса изображаются в виде последовательности прямоугольников и стрелок. Специальные характеристики каждого процесса или функции могут быть затем отображены как атрибуты процесса.
Многие из таких программных инструментов позволяют также проводить некоторый анализ, глубина которого зависит от степени сложности методологии, лежащей в основе программы. Программные инструменты имитационного моделирования бизнес-процессов можно разбить на три категории:
Инструментарий имитационного моделирования, основанного на потоковых диаграммах. Подобный – самый простой – инструментарий построения потоковых диаграмм помогает описывать выполняемые функции и определять их последовательность. Модели, основанные на потоковых диаграммах, не зависят от методологии и наиболее просты в изучении. К сожалению, следствием легкости использования является ограниченность возможностей моделирования и анализа. Примерами инструментария имитационного моделирования подобного рода служат Process Charter и Optima.
Инструментарий динамического моделирования. На следующем уровне располагаются программные продукты аналогового моделирования, которые позволяют отображать динамику системы. Модели, созданные подобными продуктами, состоят из таких специфических для выбранной методологии логических структур, как уровни, стеки, потоки, преобразователи и соединители. Примеры: ithink и PowerSim.
Инструментарий дискретно-событийного имитационного моделирования.
Наиболее развитым и мощным инструментарием имитационного моделирования бизнес-процессов являются программные продукты дискретно-событийного моделирования. Эти инструменты поддерживают моделирование потока объектов (продуктов) и предоставляют возможности анимации, что позволяет пользователю производить наблюдение за движением в системе потоковых объектов. Некоторые из подобных технологий обеспечивают даже возможности объектно-ориентированного моделирования, упрощающего разработку больших моделей бизнес-процессов. Примеры: ServiceModel и SIMPROCESS.
Источник
Здравствуйте, уважаемые хабровчане! Думаю будет кому-то интересно вспомнить какие модели разработки, внедрения и использования программного обеспечения существовали ранее, какие модели в основном используются сейчас, зачем и что это собственно такое. В этом и будет заключаться моя небольшая тема.
Собственно, что же такое жизненный цикл программного обеспечения — ряд событий, происходящих с системой в процессе ее создания и дальнейшего использования. Говоря другими словами, это время от начального момента создания какого либо программного продукта, до конца его разработки и внедрения. Жизненный цикл программного обеспечения можно представить в виде моделей.
Модель жизненного цикла программного обеспечения — структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта.
Эти модели можно разделить на 3 основных группы:
- Инженерный подход
- С учетом специфики задачи
- Современные технологии быстрой разработки
Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.
Модель кодирования и устранения ошибок
Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.
Данная модель имеет следующий алгоритм:
- Постановка задачи
- Выполнение
- Проверка результата
- При необходимости переход к первому пункту
Модель также ужасно устаревшая. Характерна для 1960-1970 гг., по-этому преимуществ перед следующими моделями в нашем обзоре практически не имеет, а недостатки на лицо. Относится к первой группе моделей.
Каскадная модель жизненного цикла программного обеспечения (водопад)
Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.
Преимущества:
- Последовательное выполнение этапов проекта в строгом фиксированном порядке
- Позволяет оценивать качество продукта на каждом этапе
Недостатки:
- Отсутствие обратных связей между этапами
- Не соответствует реальным условиям разработки программного продукта
Относится к первой группе моделей.
Каскадная модель с промежуточным контролем (водоворот)
Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на разработку. Относится к первой группе моделей.
V модель (разработка через тестирование)
Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.
Модель на основе разработки прототипа
Данная модель основывается на разработки прототипов и прототипирования продукта.
Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:
- Прояснить не ясные требования (прототип UI)
- Выбрать одно из ряда концептуальных решений (реализация сцинариев)
- Проанализировать осуществимость проекта
Классификация протопипов:
- Горизонтальные и вертикальные
- Одноразовые и эволюционные
- бумажные и раскадровки
Горизонтальные прототипы — моделирует исключительно UI не затрагивая логику обработки и базу данных.
Вертикальные прототипы — проверка архитектурных решений.
Одноразовые прототипы — для быстрой разработки.
Эволюционные прототипы — первое приближение эволюционной системы.
Модель принадлежит второй группе.
Спиральная модель жизненного цикла программного обеспечения
Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.
Преимущества:
- Быстрое получение результата
- Повышение конкурентоспособности
- Изменяющиеся требования — не проблема
Недостатки:
- Отсутствие регламентации стадий
Третьей группе принадлежат такие модели как экстремальное программирование (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике.
Большое спасибо за внимание!
Источник
Имитационное моделирование реализуется с помощью математических инструментальных средств, специальных компьютерных программ и приемов, которые позволяют с помощью компьютера провести целенаправленное моделирование в режиме «имитации» структуры и функций сложного процесса и оптимизацию некоторых его параметров. При имитационном моделировании происходит запуск в компьютере взаимодействующих вычислительных процессов, которые являются по своим временным параметрам аналогами исследуемых процессов.
Процесс последовательной разработки имитационных моделей начинается с создания простой модели, которая постепенно усложняется в соответствии с требованиями, предъявляемыми к результату разрешения некоторой проблемы.
В каждом цикле имитационного моделирования можно выделить следующие этапы.
1. Формулировка проблемы
Здесь проводится описание исследуемой проблемы и определение целей исследования.
2. Разработка модели
Логико-математическое описание моделируемой системы в соответствии с формулировкой проблемы. Включает в себя разработку концептуальной модели и формализацию построенной концептуальной модели.
2.1. Разработка концептуальной модели
Концептуальная (содержательная) модель – это абстрактная модель, определяющая структуру моделируемой системы, свойства ее элементов и причинно-следственные связи, присущие системе и существенные для достижения цели моделирования.
Построение концептуальной модели включает следующие этапы:
— определение типа системы (пункт 6.2.);
— описание рабочей нагрузки (пункт 6.3.);
— декомпозиция системы (пункт 6.4.).
2.2. Формализация построенной концептуальной модели
Осуществляется с помощью языка или аппарата математических методов.
3. Подготовка данных
Включает идентификацию, спецификацию и сбор данных.
Идентификация – статистический анализ модели, статистическое оценивание неизвестных параметров.
Спецификация – определение конечных целей моделирования; определение набора экзогенных и эндогенных переменных; определение состава системы уравнений, их структур; формулировка исходных предпосылок, ограничений. Спецификация опирается на имеющиеся экономические теории, специальные знания, интуицию исследователя.
4. Трансляция модели
Трансляция модели – это перевод модели со специальных имитационных языков или языка математики на язык программирования, на котором будет реализована прикладная программа, соответствующая имитационной модели.
5. Верификация
Верификация – это установка правильности разработанной программы, формальное, либо практическое доказательство ее правильной работоспособности на ЭВМ.
6. Валидация
Валидация – это оценка требуемой точности и адекватности имитационной модели.
7. Планирование
Определение условий машинного эксперимента с имитационной моделью, а также параметров при тестировании модели, результаты по входным данным.
На данном этапе необходимо определить условия, в которых будет осуществляться тестирование, проверка работоспособности и возможности функционирования; параметры, на которые надо обратить внимание при тестировании модели. Параметры могут быть связаны со способностью модели реагировать на какие-либо стохастические воздействия, на неверные входные данные, либо полное их отсутствие, на неверные действия персонала.
8. Постановка экспериментов
Предполагает прогон программы имитационной модели на ЭВМ для получения выходных данных или результатов, позволяющих оценить адекватность построенной модели.
9. Анализ результатов
Предполагает рассмотрение и изучение результатов имитационного эксперимента для подготовки выводов о возможности применения имитационной модели для решения некоторой проблемы.
10. Реализация и документирование
На основе построенной имитационной модели можно дать рекомендации о принятии того или иного управленческого решения и документально отразить процесс функционирования модели и полученные результаты.
Популярные статьи
БАНКИ ДАННЫХ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ УПРАВЛЕНИЯ
ДОСТОИНСТВА И НЕДОСТАТКИ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ОБРАБОТКИ ДАННЫХ
ВИДЫ ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
ОСНОВНЫЕ ПОНЯТИЯ ТЕОРИИ АЛГОРИТМОВ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ ОФИСА
КОМПЛЕКСНОЕ ТЕСТИРОВАНИЕ
КОМПОНЕНТЫ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ АВТОМАТИЗАЦИИ ОФИСА
АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО СПЕЦИАЛИСТА
ЭТАПЫ РАЗВИТИЯ ИНФОРМАТИЗАЦИИ
ПОНЯТИЕ МУНИЦИПАЛЬНОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
РЕЖИМЫ ОБРАБОТКИ ИНФОРМАЦИИ
ФУНКЦИИ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ
МЕТОДЫ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ ПРОГРАММНЫХ СРЕДСТВ
ПРАВИЛА ЗАЩИТЫ ОТ КОМПЬЮТЕРНЫХ ВИРУСОВ
ДОКУМЕНТАЛЬНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ
ПРОТОКОЛЫ ТЕСТИРОВАНИЯ
ДЕСТРУКТИВНЫЕ ВОЗМОЖНОСТИ ВИРУСОВ
КЛАССИФИКАЦИЯ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
КОНЦЕПТУАЛЬНАЯ, ЛОГИЧЕСКАЯ И ФИЗИЧЕСКАЯ МОДЕЛИ
КОМПЬЮТЕРНЫЕ ТЕХНОЛОГИИ ПОДГОТОВКИ ТЕКСТОВЫХ ДОКУМЕНТОВ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ЭКСПЕРТНЫХ СИСТЕМ
ДИАЛОГОВЫЙ РЕЖИМ АВТОМАТИЗИРОВАННОЙ ОБРАБОТКИ ИНФОРМАЦИИ
ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ КОМПЬЮТЕРНЫХ СЕТЕЙ
Источник
2.2.3. Спиральная модель
Исходя из возможности внесения изменений, как в процесс, так и в создаваемый промежуточный продукт была создана спиральная модель (рис. 2.6). Внесение изменений ориентировано на удовлетворение потребности пользователей сразу, как только будет установлено, что созданные артефакты или элементы документации (описание требований проекта, комментарии различного вида и т.п.), не соответствуют действительному состоянию разработки.
Данная модель ЖЦ допускает анализ продукта на витке разработки, его проверку, оценку правильности и принятия решения двигаться на следующий виток или опуститься на предыдущий виток для доработки на нем промежуточного продукта.
Отличие этой модели от каскадной модели состоит в возможности обеспечивать многоразовое возвращение к процессу формулирования требований и к повторной разработке с любого процесса выполнения работ. На изображенной модели (рис. 2.6), каждый виток спирали соответствует одной из версий разработки системы.
При необходимости внесения изменений в систему на каждом витке с целью получения новой версии системы обязательно вносятся изменения в предварительно зафиксированные требования, после чего происходит возврат на предыдущий виток спирали для продолжения реализации новой версии системы с учетом изменений.
2.2.4. Эволюционная модель ЖЦ
В случае эволюционной модели система разрабатывается в виде последовательности блоков структур (конструкций). В отличие от инкрементной модели ЖЦ подразумевается, что требования устанавливаются частично и уточняются в каждом последующем промежуточном блоке структуры системы.
Использование эволюционной модели предполагает проведение исследования предметной области для изучения потребностей заказчика проекта и анализа возможности применения этой модели для реализации. Модель применяется для разработки несложных и не критических систем, для которых главным требованием является реализация функций системы. При этом требования не могут быть определены сразу и полностью. Тогда разработка системы проводится итерационно путем ее эволюционного развития с получением некоторого варианта системы – прототипа, на котором проверяется реализация требований. Иными словами, такой процесс по своей сути является итерационным, с повторяющимися этапами разработки, начиная от измененных требований и до получения готового продукта. В некотором смысле к этому типу модели можно отнести спиральную модель.
Развитием этой модели является модель эволюционного прототипирования в рамках всего ЖЦ разработки (рис. 2.7). В литературе она часто называется моделью быстрой разработки приложений RAD (Rapid Application Development). В данной модели приведены действия, которые связаны с анализом ее применимости для конкретного вида системы, а также обследование заказчика для определения потребностей пользователя для разработки плана создания прототипа.
В модели есть две главные итерации разработки функционального прототипа, проектирования и реализации системы. Проверяется, удовлетворяет ли она всем функциональным и нефункциональным требованиям. Основной идеей этой модели является моделирование отдельных функций системы в прототипе и постепенное эволюционная его доработка до выполнения всех заданных функциональных требований.
Итераций по получению промежуточных вариантов прототипа может быть несколько, в каждой из которых добавляется функция и повторно моделируется работа прототипа. И так до тех пор, пока не будут промоделированы все функции, заданные в требованиях к системе. Потом выполняется еще итерация – окончательное программирование для получения готовой системы.
Эта модель применяется для систем, в которых наиболее важными являются функциональные возможности, и которые необходимо быстро продемонстрировать на CASE-средствах.
Так как промежуточные прототипы системы соответствуют реализации некоторых функциональных требований, то их можно проверять и при сопровождении и эксплуатации, т.е. параллельно с процессом разработки очередных прототипов системы. При этом вспомогательные и организационные процессы могут выполняться параллельно с процессом разработки и накапливать сведения по данным количественных и качественных оценок на процессах разработки.
При этом учитываются такие факторы риска:
- реализация всех функций системы одновременно может привести к громоздкости;
- ограниченные человеческие ресурсы заняты разработкой в течение длительного времени.
Преимущества применения данной модели ЖЦ следующие:
- быстрая реализация некоторых функциональных возможностей системы и их апробирование;
- использование промежуточного продукта в следующем прототипе;
- выделение отдельных функциональных частей для реализации их в виде прототипа;
- возможность увеличения финансирования системы;
- обратная связь устанавливается с заказчиком для уточнения функциональных требований;
- упрощение внесения изменений в связи с заменой отдельной функции.
Модель развивается в направлении добавления нефункциональных требований к системе, связанных с защитой и безопасностью данных, несанкционированным доступом к ним и др.
2.2.5. Стандартизация модели ЖЦ
Типичный ЖЦ системы начинается с формулировки идеи или потребности, проходит все процессы разработки, производства, эксплуатации и сопровождения системы. Стандартный ЖЦ состоит из процессов, каждый процесс характеризуется видами деятельности и задачами, которые выполняются на нем. Переход от одного процесса
к другому должен быть санкционирован и определены входные и выходные данные.
Модель данного ЖЦ включает в себя процессы:
- определение требований;
- разработка (проектирование, конструирование);
- верификация, валидация, тестирование;
- изготовление;
- эксплуатация;
- сопровождение.
Данной модели соответствуют все виды деятельности, начиная с разработки проекта или концепции программного продукта и заканчивая его изготовлением. Как было сказано выше, стандарт ISO/IEC 12207 объединяет эти виды деятельности в следующие три категории: основные, организационные и вспомогательные процессы, которые и составляют стандартный ЖЦ.
Процессы приобретения, поставки и разработки используются для анализа и определения системных требований и решений верхнего уровня проектирования системы и предварительного определения требований к компонентам системы, включая ПО. Процесс разработки может быть использован для анализа, демонстрации, прототипирования требований и проектных решений.
На этапе проектирования разрабатывается техническое, программное, организационное обеспечение системы, а также проектируются, разрабатываются, интегрируются, тестируются и оцениваются ее компоненты. Результатом этого процесса является система, которая разрабатывалась согласно контракту или договора.
Стандарт разработан так, чтобы его можно было применить полностью или частично. Действия и задачи основных процессов отбираются, адаптируются и применяются при разработке или модификации системы. Процесс разработки может включать одну или более итераций. Результатом являются требования к ПО, проект и реализованный продукт.
Если разрабатываемое ПО – часть системы, то к ней могут применяться все действия процессов разработки, и если эта часть – автономное ПО, то некоторые общие действия на уровне системы могут не использоваться при его разработке.
Во время процесса изготовления система готовится для поставки заказчику и покупателям. Цель процесса – тиражирование (производство) и установка работающей системы у заказчика для
сопровождения. Данный процесс заключается в копировании изготовленного продукта и документации на соответствующие носители пользователей. К видам деятельности на процессе относится достижение качества реализации и создания конфигурации (версии) системы. Другие вспомогательные процессы и действия (например, сбор данных о результатах контроля) могут применяться по мере необходимости.
Изготовленная система, начиная с первой ее версии, передается заказчику или продается желающим покупателям. Другие процессы (приобретения, поставки и разработки) могут использоваться при инсталляции и проверке разработанной или модифицированной системы.
Процесс эксплуатации включает использование системы ее покупателями. Когда система больше не удовлетворят пользователей, она утилизируется, т.е. удаляются из употребления путем уничтожения кодов, архивов, процедур и т.п.
Во время сопровождения система модифицируется вследствие обнаруженных ошибок и недостатков в ее разработке либо по требованиям пользователя, который желает ее адаптировать к новой среде или усовершенствовать отдельные ее функции.
Источник