Как использовать сценарии использования для точной оценки трудоемкости работы
Каждый из программистов и руководителей разработки хоть раз, но попадал на сроки, т.е. нарушал их, сильно или не очень.
Попробуйте открутить назад все Ваши проекты и оцените реальное опоздание по ним.
Может оказаться, что задержки достигают просто гигантских значений.
Автор статьи видел проекты с задержкой сроков в 400% и 700%!
Бытует мнение, что разрабатывать программы без опоздания невозможно в принципе.
Вообще, причина такой точки зрения ясна, ведь люди не провидцы и не могут видеть будущее.
На момент оценки трудоемкости ТЗ есть не всегда. И даже если оно есть, фактор неизвестности всё равно продолжает играть огромную роль – ведь люди, к сожалению, действительно не провидцы, и каким бы подробным не было ТЗ, всё равно остаются моменты, скрытые от глаз.
Кроме скрытой функциональности, на ошибочную оценку также довольно сильно влияет квалификация и личный опыт программирования самого оценщика (человеку без личного опыта программирования труднее оценить сколько времени займёт разработка).
Интересно, что сценарии (варианты) использования позволяют довольно точно оценить трудоемкость работ.
Практика показала, что можно достигнуть 20% точности (=%ошибки) при оценке. А ведь опоздание 20% это совсем не 700%, верно?
С чего начать
Суть в альтернативах!
Прелесть сценариев использования в том, что они расписывают не только основной ход событий, но и все возможные и невозможные альтернативные ситуации. А альтернативы – это и есть те самые подводные камни, из-за которых и возникают ошибки в оценке трудоемкости.
Как же посчитать трудоёмкость с помощью сценариев?
Представьте, что Вам нужно запрограммировать вот такое небольшое окошко:
Пример не совсем корректный, т.к. не является бизнес-задачей, но его вполне можно использовать в качестве иллюстрации к расчету трудоемкости. Поэтому сделайте, пожалуйста, скидку на точность изложения сценария и сконцентрируйтесь на трудоёмкости, хорошо?
Вкратце распишем сценарий:
Сценарий использования «Найти документ»
Успешный результат: выбранный документ прописан в свойство какого-то объекта
Основной успешный сценарий
1.Пользователь вводит поисковую фразу.
2.Система выводит список подходящих документов, в названии которых есть искомая фраза. Документы представлены своим названием. Список упорядочен по алфавиту.
3.Пользователь выбирает один из документов.
4.Система прописывает выбранный документ в нужный объект.
Альтернативы
2а.Пользователь хочет найти документы по состоянию на указанную дату
1.Система выводит список подходящих документов, ограниченных по дате создания. Исполнение продолжается согласно п.3.
2б.Пользователь хочет найти документ в архиве
1. 1.Система выводит список подходящих действующих и архивных документов. Исполнение продолжается согласно п.3.
3а.Не найдено ни одного документа
1.Система выводит сообщение: «Не найдено ни одного документа». Исполнение продолжается согласно п.1.
Обратите внимание, что сценарий разделен на две части: «Основной успешный сценарий» и «Альтернативы».
А теперь подумайте, как обычно происходит оценка трудоёмкости? Думаю, Вы согласитесь, что работу обычно оценивают только по успешному сценарию (как самому очевидному, приходящему на ум в первую очередь), а про альтернативы не думают вообще.
В этом и заключается суть проблемы – именно в альтернативах часто зарыта основная трудоёмкость.
Пойдём дальше.
В примере италиком отмечены операции, которые программисту нужно запрограммировать.
В альтернативах можно увидеть две операции, которых нет в основном сценарии. Давайте подумаем, что представляют из себя эти операции? По сути это обычные SQL-запросы к базе, но!
В них фигурируют дополнительные параметры, которых нет в основном запросе. И вполне может получиться так, что отладка запросов с этими параметрами займёт в 10 раз больше времени, чем основной запрос. И именно так и бывает, верно?
Использование сценариев позволяет вытащить на свет все эти альтернативы (или большинство из них), и т.о. в несколько раз точнее оценить итоговую трудоёмкость работы.
Как оценить трудоёмкость
Давайте сведём всю информацию по сценарию в одну таблицу и попробуем посчитать сколько времени у нас займёт реализация:
Создание инфраструктуры классов – 1ч
Формирование окна – 2ч
Вывод списка документов по ключевой фразе – 1ч
Вывод списка документов с учётом даты создания – 1ч
Вывод списка документов с учётом архивных – 1 ч
Прописывание выбранного документа в свойства объекта – 1ч
Тестирование 4 * 0,5ч = 2ч
Итого: 9 ч
Как видите, в оценке учтены дополнительные 2ч на реализацию альтернатив и еще 1ч на их тестирование. А если бы оценка проводилась только по успешному сценарию, то этих 3-х часов мы бы не досчитались.
А это почти 50% времени (6ч на основной сценарий и 3ч на альтернативы)!
Итоги
Сценарии использования однозначно дают очень большое преимущество в оценке трудоемкости. Используйте их, чтобы получить конкурентное преимущество перед другими разработчиками ПО.
P.S.А как быть, если сценариев ещё нет?
Если на момент оценки Вы ещё не расписали сценарии, попробуйте хотя бы вкратце набросать основные альтернативы. Это уже хорошо улучшит оценку.
P.P.S. Где еще зарыта свинья
Бывает так, что шаги сценария недостаточно мелкие. Представьте, например, что в система должна опубликовать какие-либо данные.
Как Вы понимаете, под «публикацией» может быть скрыт целый ворох действий, которые трудно определить сразу.
Такие ситуации очень легко определяются, когда в оценке трудоемкости ставится время > 3ч. Это однозначно указывает на то, что человек, дающий оценку, не знает, что скрыто внутри. И там 100% сидит БОЛЬШАЯ засада! Проверено многократно.
В таком случае обязательно продумывайте и прописывайте, что скрыто внутри, иначе можно очень сильно попасть на сроки.
НИМС — специфичный сценарный софт (для ролевых игр живого действия)
Существует много программ для написания сценариев и много поводов, чтобы написать свой сценарий. Но, как и все рабочие инструменты, сценарный софт адаптируется под требования предметной области. По этой причине программа для разработки сценария кино не приспособлена для написания сценария компьютерной игры и наоборот. Моя область ещё более специфична — я разработал программу НИМС (набор инструментов мастера-сюжетника) для создания сценариев ролевых игр живого действия (далее РИ).
Оно используется? Да, проекту уже два года. За это время на НИМСе сделано больше 20 игр.
Оно платно? Бесплатно — donationware.
В этом посте я расскажу о видах сценарных задач, о специфике написания сценариев для РИ, что умеет НИМС и об особенностях его реализации.
На картинке социальная сеть по сюжетам РИ «Порт-Артур», МГ S&M (кликабельно).
Дисклеймер 1: настольные ролевые игры это самостоятельный вид игр и их я буду упоминать как НРИ.
Классификация задач по написанию сценариев
Много веков сценарий как явление принадлежал исключительно сцене. В конце 19 века появился кинематограф, а в конце 20 — многообразные игры (компьютерные, настольные, живого действия и пр.) И везде есть сценарии. С художественной точки зрения они схожи и подчиняются единым законам сценаристики. Но с точки зрения формы представления информации каждая область применения сценариев ставит свои задачи. Давайте попробуем разобраться в этом.
Задачи по написанию сценариев можно разделить по наличию/отсутствию интерактива со зрителем/пользователем. Кино, сериалы, книги, театр требуют безынтерактивного сценария. Соответственно, зритель никак не может повлиять на ход повествования и в итоге имеется лишь вариант развития событий. В противоположность им существуют интерактивные сценарии, предполагающие влияние зрителя. Это сценарии всевозможных игр.
Интерактивные сценарии можно разделить на закрытые и открытые. Закрытые сценарии требуют описания всех возможных вариантов развития истории. Например, сценарии для компьютерных игр и ролевых книг-игр.
На РИ происходит взаимодействие большого количества игроков в рамках установленных до игры правил и договорённостей. Мастерам нет необходимости следить за каждым шагом, но в их компетенции обычно остаётся разрешение спорных вопросов и латание ошибок правил в процессе игры. Ещё раз подчеркну, что игроки взаимодействуют друг с другом автономно, без вмешательства мастера.
Дисклеймер 2: описанное здесь не догма, скорее типичный вариант, НРИ бывают автономными, РИ бывают авторозависмыми и ещё полный спектр промежуточных вариантов.
Сценарии на ролевых играх живого действия
Разработка РИ имеет определённые требования. В процессе разработки создается модель мира, который населяется персонажами, и прописываются конфликты. Часто для игры необходимо придумать десятки активных персонажей и десятки открытых историй, имеющих способы разрешения.
Перед игрой игроку выдают вводную, описывающую положение его персонажа: предыстория, родственники, друзья, враги, имущество, конфликты, позиции фракций по ключевым вопросам и т.д. Обобщая, во вводную можно поместить любую информацию, которая «может сыграть».
И ещё один дисклеймер: описанное здесь тоже не догма. Есть игры вообще без вводных, или у части игроков вводные есть, а у части нет. Игрок может увидеть свою вводную непосредственно на игре, а может принять участие в её разработке за несколько месяцев до игры с указанием, во что он хочет поиграть и с кем.
Каждый игрок должен получить свою порцию информации и оперировать ею на игре. Бич написания вводных это несостыковки. Любое событие из предыстории пересказывается многократно и с разными акцентами, потому что каждый участник видит ситуацию по-своему. Мало того, что каждый факт необходимо расписать в нескольких вариантах, но и в случае каких-то изменений, все эти изменения необходимо продублировать в каждом из вариантов. Например, если в каком-то эпизоде было задействовано 5 персонажей, то в случае малейшего изменения в этом эпизоде необходимо внести 5 правок, а не одну. Такая ситуация приводит к большому количеству несостыковок.
Проект НИМС предназначен для разработки сценариев РИ, предполагающих наличие множества историй с большим количеством участников. С его помощью информация распределяется между игроками, а процесс написания текстов сопровождается механизмами контроля для устранения несостыковок и выявления «забытых» линий.
Процесс написания вводных
Условие задачи: есть история, в которой задействовано множество персонажей. Необходимо предоставить каждому персонажу ту часть истории, которая ему известна.
Можно решать эту задачу в лоб: Фродо, твоя предыстория такая, Гэндальф, твоя предыстория такая. Проблема, с которой мы столкнёмся — рассинхронизация информации. Например, мы напишем во вводной Фродо «Громко свисти, если увидишь орков». А всем остальным членам Братства кольца забудем это написать, и они не будут знать, что значит свист Фродо. Ещё «лучше», если мы про «свист Фродо» напишем только половине Братства кольца.
Для решения этой задачи мы разбиваем историю на события, где событие это единство времени, места и персонажей. Фиксируем событие: «Совет кольца, время: 3018/10/25 12:00, участники. описание события. » Теперь мы точно знаем, кто был участником события. У каждого участника есть своё видение события, которое мы описываем в адаптации события. Адаптация всей истории для выбранного персонажа состоит из всех адаптаций событий с этим персонажем.
Финальный этап: все адаптации написаны, мы группируем их в текстовые файлы по персонажу. Одной картинкой это выглядит так:
В итоге, мы получаем структурированные данные, которые вдобавок пригодны для визуализации:
Пример хронологии событий базы-примера по Властелину Колец (кликабельно):
Пример социальной сети с игры РИ «Mad Mad Max», Mk. Albion (кликабельно):
Отношения персонажей
Таблица отношений персонажей широко применяется в РИ и НРИ. Таблица отношений это квадратная таблица, в которой каждая строка и каждая колонка соответствует персонажу, а в ячейках таблицы мы записываем отношение персонажа А к персонажу Б. Интересный момент: персонажам не обязательно быть знакомыми между собой, чтобы иметь отношение друг к другу. Персонаж из низов может иметь какие-то счеты с боссом мафии, но сам босс мафии может быть совершенно не в курсе этого.
Досье
Досье это список фактов о персонаже. Структуру досье определяет мастер игры, так как важная информация для одной игры является не важной для другой. Например, возраст персонажа может влиять на допуск к полетам на какой-нибудь игре про космос, но во Властелине колец к возрасту нет никакой привязки и от него ничего не зависит.
Досье это, конечно, хорошо, но полезно оно не само по себе, а в сочетании с возможностью искать по нему персонажей. Например, нам в романтическую историю необходимо добавить молодого неженатого дворянина. Настроим фильтр: возраст «до 30», сословие «дворянское», семейное положение «холост», отсортировать по возрастанию возраста.
Группы персонажей
Развивая идею фильтра, мы пришли к группам персонажей. Например, у нас на игре есть группа Тамплиеры, и мы хотим предоставить историю ордена только людям из этой группы. Решение в лоб: Петя, Витя, Боря тамплиеры, мы их включаем в группу, текст для группы выводится во вводные. Потом Витя уходит в ассасины, на его место приходит Гоша, а мы вручную редактируем списки групп. Вместо этого мы можем собрать фильтр по досье: фракция тамплиеры. Только тем персонажам, которые проходят этот фильтр, будет выводиться текст для тамплиеров, и никаких проблем с ручным обновлением данных.
Карта сюжета
Карта сюжета это инструмент проработки межфракционных конфликтов. Инструмент тоже достаточно известный как в РИ так и НРИ. В качестве спецификации я использовал вот эту статью. Вкратце — есть действующие на игре группы-силы, которые как-то относятся друг к другу. Например, добрые хотят уничтожить злых, и наоборот. Есть ресурсы, которые пассивны, но входят в сферу интересов групп. Например, если считать кольцо Всевластья ресурсом, то добрые хотят его уничтожить, злые хотят его захватить, нейтральные хотят его эффективно использовать. На основе карты сюжета мы можем спланировать список конфликтов, которые будут решаться по игре и сделать для них сюжетную подводку.
О реализации
Изначальное требование к системе это автономность. Я хотел, чтобы у мастера ролевой игры была возможность работать с ноутбука там, где плохо со связью. Например, на фудкорте или даже на полигоне. Именно поэтому НИМС сделан как приложение, а не как сервис (большинство систем для РИ со схожим функционалом являются сервисами).
Второе требование — это отсутствие исполняемых файлов и инсталляторов. Потому что они засоряют систему, потому что их выкладывают на файлопомойки с возможностью доустановить всякий ненужный мусор и т.д.
Для того, чтобы это провернуть, необходима виртуальная машина на компьютере пользователя, и она есть — это браузер. Собственно, так НИМС и реализован — архив с автономной веб-страницей, которая открывается в браузере.
Это было моё первое приложение написанное полностью на JavaScript, поэтому я старался свести к минимуму использование библиотек и фреймворков.
Реализация в виде автономной веб-страницы имеет следующие неприятные побочные эффекты:
И, кстати, отсутствие исполняемых файлов и возможный оффлайн приводят к тому, что я не могу использовать внешнюю СУБД. Только что-нибудь в браузере in-memory. Я выбрал путь велосипеда и сделал хранение данных в виде JSON объекта с валидацией JSON Schema при загрузке. JSON объект хранится в обычном текстовом файле, именуемом «базой».
Во всём остальном это обычная SPA.
Вскоре после релиза мне сообщили о проблеме: игр, над которыми работает строго один мастер, меньшинство. Поэтому возможность совместной работы над игрой несколькими мастерами является вопросом жизни и смерти проекта.
Проблема: у нас есть рабочее ядро, но заточенное под автономную работу. Как обеспечить совместную работу нескольких мастеров?
Решение: переделываем ядро для работы с базой под асинхронный режим работы и модифицируем таким образом, чтобы оно могло запускаться на node.js. Оффлайн режим работает как раньше. Серверный режим раздаёт веб-страницу, а все обращения к ядру преобразуются в Remote Procedure Call для исполнения запросов на сервере. То, что раньше было интерфейсом ядра, становится интерфейсом API. Попутно серверный режим расширяет API функциями управления пользователями и разграничения доступа.
В результате и оффлайн и серверное решение используют одно и то же ядро. Схематично это выглядит так:
Материалы
Для пользователей мы подготовили множество материалов:
Оффлайн версию можно скачать здесь. Проверялась работа в Chrome и Firefox. Должно работать независимо от ОС, но специально это не проверялось.
Что касается исходного кода — проект разделён на клиент, сервер и текстовые ресурсы:
Заключение
Проект НИМС даёт возможность посмотреть на сценаристику с другой стороны. Сценарии для РИ это незавершённые истории и нет необходимости формировать из них последовательное повествование для зрителя/читателя. В РИ каждый игрок получает свою часть информации и действует исходя из этого, так же как и в реальности. В этом случае задача сценариста состоит не только в том, чтобы рассказать историю, но ещё и распределить историю между действующими лицами.
Пользовательские сценарии: что это такое, как и для чего их нужно строить
Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.
Сценарии описывают пользовательские истории и взаимосвязи между ними. Они помогают определить, зачем и почему пользователи приходят на сайт и как достигают своих целей: совершают покупки, заказывают по телефону, сравнивают товары, общаются с консультантами.
Прежде чем разработать сценарий, нужно ответить на три вопроса:
1. Кто те люди, что заходят на ваш сайт?
Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.
2. Почему они заходят к вам?
На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.
3. Какие цели при этом преследуют и как их достигают?
Вариантов не так много, особенно если мы говорим о коммерческих сайтах. Обычные цели — изучить предложение с целью сравнить его с другими, непосредственно купить или сделать заказ, но возможны и другие варианты.
Пошагово достижение целей обычно расписывается в профилях задач. Здесь такая детализация не нужна, просто нужно понимать, какие шаги делает пользователь для достижения цели.
Для чего нужны пользовательские сценарии
Сценарии помогают лучше понимать предпочтения посетителей сайта и анализировать пользовательский опыт. Это нужно, чтобы в дальнейшем проектировать сайт или интерфейс так, чтобы он вписывался в привычные для клиентов паттерны и приводил к цели посещения за наименьшее количество шагов и с минимальными затратами сил, времени и внимания.
Также сценарии используют для анализа пользовательского опыта при проведении юзабилити-тестов и других маркетинговых исследований.
Сценарий — наглядное схематическое представление того, как пользователь решает свою задачу с помощью сайта, что ему помогает и что мешает в достижении цели.
Разновидности сценариев
Пользовательские сценарии по степени детализации и технической проработки делятся на четыре группы.
1. Пользовательские истории
Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.
Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.
Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».
Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:
Сценарий работы программы
3.5 Сценарий работы программы
Сразу после старта программы на экране появляется форма «Модель многофазной многопоточной системы обслуживания» Эта форма предназначена для ввода исходных данных. В правом верхнем углу на данной форме расположена надпись «Исходные данные». Ниже помещаются общие параметры, которые пользователь должен ввести для исследования работы системы. Общие параметры включают:
Количество рабочих станций — K;
Распределение времени между заявками (экспоненциальное или нормальное);
Число заявок на входе в систему — N;
Среднее время между заявками;
Стандартное отклонение [в % от среднего] —для нормального распределения.
Общие параметры представлены в виде окон для ввода значений, с пояснением, какой параметр пользователь будет вводить в данное окно. Пользователь выбирает, как распределено время между заявками и, в зависимости от выбора, при указании нормального распределения появляется, а при выборе экспоненциального распределения исчезает окно для ввода значения стандартного отклонения.
Для ввода параметров пользователь должен щелчком мыши нажать на помещенную внизу формы кнопку «Ввод». После нажатия все окна для ввода общих параметров высветятся голубым цветом и станут активными. Пользователь должен ввести значения во все активные окна, перемещая курсор с помощью мыши, щелкая ею в том окне, куда он собирается ввести следующий параметр.
После ввода всех необходимых параметров необходимо повторно нажать на кнопку «Ввод» для задания связей между рабочими станциями. В случае ввода количества станций превышающего предусмотренные работой программы 10, после нажатия на кнопку «Ввод» пользователю выдается сообщение об ошибке: «Количество станций не более 10 [десяти]!» и для дальнейшей работы необходимо изменить значение на корректное.
После повторного нажатия на кнопку «Ввод», на экране появляется форма «Задание связей между рабочими станциями». В левом верхнем углу данной формы расположены три кнопки: «Создать связь», «Убрать связь» и «Загрузить связи». В зависимости от количества рабочих станций, заданного пользователем в общих параметрах, на форме расположены от 1 до 10 рабочих станций. Каждая станция представлена в виде двух кнопок (левой и правой), вплотную прилегающих друг к другу. Левая кнопка станции обозначена «S» (Station), а правая показывает номер данной рабочей станции (от 1 до 10). Для задания связей между станциями нужно:
1. Нажать на кнопку «Создать связь»;
(далее вводятся все необходимые связи)
2. Нажать на правую кнопку (с указанием номера) той станции, откуда пойдет связь;
3. Нажать на левую кнопку (с обозначением «S» ) той станции, куда пойдет связь.
Чтобы убрать связь между станциями, нужно:
1. Нажать на кнопку «Убрать связь»;
(далее удаляются все необходимые связи)
2. Нажать на правую кнопку (с указанием номера) той станции, откуда идет связь;
3. Нажать на левую кнопку (с обозначением «S» ) той станции, куда идет связь.
Возможно задать только связи, идущие от станции с меньшим номером к станции с большим номером.
Связи обозначаются линиями, соединяющими станции, с кружком на том конце, куда приходит связь.
Чтобы ввести связи, нужно нажать на кнопку «Загрузить связи».
После нажатия на кнопку «Загрузить связи», на экране появляется форма «Создание матрицы связей». Эта форма представляет собой матрицу коэффициентов связи между станциями. В зависимости от того, какие связи задал пользователь в форме «Задание связей между рабочими станциями», становятся активными соответствующие этим связям поля матрицы (окна для ввода значений коэффициентов связи). Строки матрицы пронумерованы от 1 до 9, столбцы пронумерованы от 2 до 10. Строка обозначает ту станцию, откуда идет связь, столбец — ту станцию, куда связь приходит. В активные окна пользователь должен внести значения коэффициентов связей, соответствующих вероятностям того, что заявка пойдет именно по данному каналу связи. Внизу этой формы расположены три кнопки: «Возврат», «Проверить» и «Загрузить». После того, как пользователь задал значения всех коэффициентов, он должен нажать на кнопку «Проверить» для проверки корректности введенных значений. Так как сумма вероятностей выхода заявки со станции по всем каналам должна быть равна единице, то по каждой станции проводится проверка выполнения этого условия и значение приводится к корректному (вероятность последней, задаваемой по строке связи, считается как единица минус сумма вероятностей всех предыдущих связей по этой строке). Если сумма вероятностей всех связей, кроме последней больше единицы, то пользователю выдается сообщение «Суммарная вероятность не может быть больше единицы!» и все окна этой строки очистятся, после чего пользователь должен заново задать эти значения и повторить проверку корректности. После проверки корректности нужно загрузить значения коэффициентов, нажав на кнопку «Загрузить». Кнопка «Возврат» позволяет вернуться в форму «Задание связей между рабочими станциями».
После нажатия на кнопку «Загрузить» на экране появляется форма «Модель многофазной многопоточной системы обслуживания» для задания параметров рабочих станций. Параметры рабочих станций располагаются под общими параметрами и включают:
Распределение времени обслуживания для всех станций (экспоненциальное или нормальное);
Среднее время обслуживания для каждой станции;
Вероятность снятия заявки на выходе i-ой станции;
Стандартное отклонение [в % от среднего] —для нормального распределения.
В зависимости от количества рабочих станций, указанного в общих параметрах (от 1 до 10) станет активным аналогичное количество окон для ввода каждого параметра (параметры рабочих станций вводятся для каждой станции в отдельности). Пользователь выбирает, как распределено время обслуживания станций и, в зависимости от выбора, при указании нормального распределения появляется, а при выборе экспоненциального распределения исчезает ряд окон для ввода значений стандартных отклонений.
Внизу формы, под параметрами рабочих станций, рядом с кнопкой «Ввод» располагаются кнопки «Старт», «По формулам», «Повтор» и «Стоп». Для начала имитационного моделирования после ввода общих параметров и параметров рабочих станций необходимо нажать на кнопку «Старт». Для запуска расчета по формулам необходимо нажать на кнопку «По формулам». При указании пользователем в параметрах рабочих станций вероятности снятия заявки на выходе какой-либо станции большей или равной единице после нажатия на кнопку «Старт» или кнопку «По формулам» пользователю выдается сообщение об ошибке: «Вероятность не может быть больше единицы. » и для дальнейшей работы необходимо изменить значение на корректное. Кнопка «Повтор» предназначена для повторения процесса моделирования, кнопка «Стоп» завершает работу программы.
После нажатия на кнопку «Старт» или на кнопку «По формулам» происходит моделирование и на экране появляется форма «Результаты моделирования многофазной системы обслуживания». Эта форма состоит из двух частей (представленные на двух страницах): «Графики» и «Числовые результаты». Для выбора страницы в верхней части формы помещены две закладки «Графики» и «Числовые результаты», при нажатии на которые пользователь сможет ознакомиться соответственно с графическими или числовыми результатами.
При нажатии на закладку «Графики», на экране появятся графические результаты моделирования. Они представлены шестью окнами с графическим отображением шести параметров для заданных в исходных данных значений. Параметры при имитационном моделировании включают:
Среднее время ожидания;
Среднее время простоя;
Максимальная длина очереди;
Число снятых заявок;
Среднее время нахождения заявки на станции;
Максимальное время пребывания заявки на станции.
Параметры при расчете по формулам включают:
Среднее время ожидания обслуживания;
Среднее время простоя станции;
Среднее число заявок в очереди;
Среднее время нахождения заявки на станции.
Над каждым окном указано, какой из перечисленных параметров в нем представлен. Также над графиком выводится максимальное значение выводимого параметра.
Информация в окнах представлена в виде гистограммы. В зависимости от количества рабочих станций, указанного в общих параметрах, гистограмма состоит из соответствующего числа столбцов. Для удобства столбцы выделены разными цветами. Длина максимального столбца представлена в численном виде в правом верхнем углу окна. Длина остальных столбцов показана в масштабе от максимального.
При нажатии на закладку «Числовые результаты», на экране появятся числовые результаты моделирования. При имитационном моделировании они включают для каждой станции:
Среднее время ожидания обслуживания;
Среднее время простоя станции;
Максимальная длина очереди;
Число снятых заявок;
Среднее время нахождения заявки на станции;
Максимальное время нахождения заявки на станции.
В нижней части формы помещены общие показатели, которые рассчитываются только при имитационном моделировании. Они включают:
Общее время прихода N заявок;
Время выхода последней заявки;
Общий коэффициент использования системы по времени;
Общий коэффициент использования системы по числу заявок.
При расчете по формулам числовые результаты моделирования включают для каждой станции:
Среднее время ожидания обслуживания;
Среднее время простоя станции;
Среднее число заявок в очереди;
Среднее время нахождения заявки на станции.
Внизу формы «Результаты моделирования многофазной системы обслуживания» расположена кнопка «Возврат», позволяющая вернуться в исходную форму.