Г осударственное профессиональное образовательное учреждение Кузбасский колледж архитектуры, строительства и цифровых технологий
 Скачать 1.46 Mb.
|
|
Вывеска - средство наружной рекламы по месту продажи. Обычно это плоская табличка с надписью или рисунком, вешающаяся на здании магазина (кафе, ателье и т.п.). Визитки вкладываются в промо-материалы, раздаются на выставках, раскладываются в магазинах возле кассы, на столиках в кафе и ресторанах, также их можно выложить в приемной. Буклет- новичка позволяет в доступной форме донести до нового сотрудника свод правил и действий, принятых в компании, нормы поведения, общения и прочие важные моменты. Нейтральный плакат наименее-эффективен из всех перечисленных разновидностей, т. к. его рекомендации не мотивированы, кроме того, на нем обычно отсутствует изображение человека. Поиск ключевых вариантов использования Анализ сформулированных вариантов использования показал, что с точки зрения потенциальных рисков и архитектурной значимости наиболее существенными являются прецеденты, связанные с работой Менеджера и заказчика. Для дальнейшей детализации выбраны три прецедента: А1. Регистрация заказа. Z1. Планирование нового заказа. Z3. Планирование срочного заказа. Прецедент Z1: планирование нового заказа. Планирование нового заказа Краткое описание Менеджер размещает вновь поступивший от Заказчика заказ в план в «хвост» очереди. Действующие лица этого прецедента – Менеджер. Поток событий Прецедент начинается, когда Менеджер выбирает деятельность “создать новый заказ” из «Главной формы». Базовый поток – Планирование нового заказа Менеджер выбирает «создать новый заказ». Система отображает список новых заказов, подлежащих планированию. Менеджер выбирает из предложенного списка заказ, который он желает запланировать. Система определяет, что статус заказа – «Обычный». Система отображает список работ заказа, отсортированных по очерёдности исполнения с указанием времени исполнения. Система отображает для каждого из ресурсов линейки планирования, состоящие из свободных и занятых временных интервалов на шкале времени. Менеджер выбирает работу заказа. Система ограничивает набор доступных ресурсов, «затеняя» несовместимые. Менеджер находит на шкале одного из доступных ресурсов интервал необходимого размера и размещает (drag and drop) туда работу заказа. Система делает соответствующие отметки в базе данных. ПП. 7-10 повторяются, пока все работы заказа не будут размещены. 12.Система удаляет заказ из списка вновь поступивших Альтернативные потоки Планирование по частям Если при выполнении п. Error: Reference source not found основного потока событий Менеджеру не удалось обнаружить интервал необходимого раздела, то Менеджер выбирает «планировать по частям». Менеджер находит на шкале одного из доступных ресурсов интервал произвольного размера и размещает (drag and drop) туда работу заказа. Система разбивает работу на интервалы и размещает её на свободные позиции выбранного ресурса. Переход к п. 10 основного потока событий. Планирование заказа в срок невозможно Если Менеджер обнаружил, что он не может запланировать заказ с соблюдением зафиксированного в заказе срока, то Менеджер выбирает «отменить планирование». Система отправляет уведомление Заказчику «Заказ №… не может быть спланирован с соблюдением оговоренного с заказчиком срока». Специальные требования Время планирования одного заказа не должно превышать 15 минут. Предусловия Регистрация Перед тем как начинается этот прецедент, Менеджер зарегистрирован в системе. Постусловия При успешном окончании прецедента Менеджер составляет план, гарантирующий исполнение заказа в срок. При неуспешном – Менеджер делегирует ответственность за соблюдение сроков исполнения заказа Заказчику. Точки расширения Если при выполнении п. Error: Reference source not found выясняется, что заказ имеет статус «Срочный», Система переходит к выполнению расширяющего прецедента «Error: Reference source not found» Цель Задача данного документа – в том, чтобы квалифицировать вспомогательные запросы к разрабатываемой АИС. Рассматриваются активные запросы, описание которых в форме фактов проблемно, или бессмысленно. Описываются нефункциональные запросы, относящиеся в целом к системе. Функциональность Авторизация и аутентификация пользователей в системе В АИС должны быть представлены справочник ролей пользователей (Автор, Заказчик, Поставщик) и справочник пользователей. Должна быть возможность регистрации пользователя и назначения пользователю роли. Ведение справочника работ Работы, включаемые в описание заказа, выбираются из справочника типов работ. Ведение справочника ресурсов В АИС должны быть представлены средства управления типами ресурсов, справочниками персонала и оборудования. Применимость Удобство использования Интерфейс Сайта «Заказчик» и «Поставщик» должен быть обладать свойствами удобства и интуитивной ясности и не требовать дополнительной подготовки пользователей. Интерфейс Сайта «Менеджера» должен быть рассчитан на предварительно обученного специалиста, время обучения не должно превышать 1 рабочий недели. Помощь в режиме online На данном сайте присутствует раздел тех поддержка случает возникновения вопросов. Надежность Доступность Сайт в режиме заказов должен быть доступен в рабочие дни в рабочее время с 8:00 до 18:00. Сайт Менеджера должен быть доступен в круглосуточном режиме. Время, затрачиваемое на обслуживание системы не должно превышать 3% от общего времени работы. Наработка на отказ Среднее время безотказной работы – все календарные дни в году. Норма дефектов Максимальная норма ошибок или дефектов – 1 ошибка на десять тысяч строк кода. Производительность Одновременно работающие пользователи Система должна быть способна поддерживать минимум 15 одновременно работающих пользователей, связанных с общей базой данных. Время отклика Время отклика для типичных задач – не более 5 секунд, для сложных задач – не более 20 секунд. Пригодность к эксплуатации Масштабируемость Система должна быть способна поддерживать минимум 15 одновременно работающих пользователей, связанных с общей базой данных и иметь возможность увеличить их количество на случай увеличения покупателей. В настоящее время на предприятии имеется 1 Менеджер, который выполняет функции: менеджера, диспетчера. Также автор покупает у Поставщика материалы. В дальнейшем штат будет расширяться, добавление в штат: менеджера, диспетчера – ближайшие 1-2 года, через 3 года – помощник автора. Обновление версий Обновление версий должно реализовываться в автоматизированном режиме на основе системы контроля версий и системы (сервера) обновления версий на рабочих местах пользователей. Ограничения проектирования Применяемые стандарты Система должна соответствовать всем веб интерфейса. Требования к среде выполнения Система должна удовлетворять вышеуказанным требованиям на компьютере в следующей минимальной комплектации: 264 Gb памяти; 100 Gb свободного дискового пространства; процессор с тактовой частотой 2,300 MHz; Операционная система Windows 10. Требования к СУБД и доступу к данным. В ядре системы должна быть представлена промышленная СУБД реляционного доступа. Все обращения к информации должны осуществляться через драйвер ODBC. Спецификация требований к АИС 1. Введение 1.1 Цель Цель этого документа – в том, чтобы сформулировать требования к разрабатываемой АИС диспетчеризации полиграфического производства. Данные требования описаны в форме прецедентов, кратких описаний функциональных требований и описаний нефункциональных требований. 2. Обзор системы 2.1 Обзор прецедентов. (Таблица 2.1, 2.2) Таблица 2.1 - Краткое описание акторов
Таблица 2.2 - Список вариантов использования
2.2 Предположения и зависимости Система будет использоваться на территориально сосредоточенном (без внешних филиалов) предприятии. В случае изменений в формах документов АИС должна претерпеть малосущественные изменения. В случае приобретения или разработки информационных систем, автоматизирующих смежные участки, будет необходимо разработать соответствующие средства импорта-экспорта информации. 3. Описание требований 3.1 Краткие описания вариантов использования. (Таблица 2.3) Таблица 2.3 - Регистрация заказа
Основное действующее лицо: Менеджер. Другие участники прецедента: отсутствуют. Связи с другими вариантами использования: отсутствуют. Краткое описание. Данный вариант использования позволяет Менеджеру регистрировать и передавать новые заказы. Каждый заказ в электронной форме содержит дату требуемой готовности и упорядоченный перечень работ с указанием протяжённости каждой из них во времени. Срочные заказы помечаются признаком «Срочно». Срочные заказы необходимо выполнить в срок, возможно, даже в ущерб обычным заказам. Для прочих заказов дата требуемой готовности должна носит рекомендательный характер. Данный вариант использования позволяет Менеджеру или Заказчику снимать заказы с производства в зависимости от сложности работы. (Таблица 2.4) Таблица 2.4 - Изменение заказа
Основное действующее лицо: Менеджер. Другие участники прецедента: отсутствуют. Связи с другими вариантами использования: отсутствуют. Краткое описание. Данный вариант использования позволяет автору внести изменения в описания заказов, находящихся в производстве. Для заказов, работы над которыми ещё не начались, возможны изменения параметров заказа: даты готовности и комментарии к заказу. Для заказов, выполнение которых уже началось, существуют следующие ограничения. Статус заказа, при изготовлении, как «обычный», не может быть изменён на «срочный». Плановый срок исполнения не может быть сдвинут назад по временной шкале. Запрещаются глобальные изменения в описаниях работ, которые уже начаты. Автор уведомляется о результатах изменений. (Таблица 2.5) Таблица 2.5 - Удаление заказа
Основное действующее лицо: Менеджер. Другие участники прецедента: Заказчик. Связи с другими вариантами использования: отсутствуют. Краткое описание. Данный вариант использования позволяет Менеджеру или Заказчику снимать заказы с производства. Для заказов, работы над которыми ещё не начались, удаляется вся информация. Для заказов, выполнение которых уже началось, удаляется плановая информация о работах, которые ещё не начаты. (Таблица 2.6) Таблица 2.6 - Запрос о заказе
Основное действующее лицо: Заказчик. Другие участники прецедента: отсутствуют. Связи с другими вариантами использования: отсутствуют. Краткое описание. Данный вариант использования позволяет Заказчику узнавать о планах производства заказа, а также о фактических результатах исполнения работ над заказом. Так как Менеджер не всегда имеет доступ к компьютеризованному рабочему месту, данный вариант использования должен быть доступен также и Менеджеру, для консультирования Заказчика по телефону. (Таблица 2.7) Таблица 2.7 - Планирование нового заказа
Основное действующее лицо: Заказчик. Другие участники прецедента: отсутствуют. Связи с другими вариантами использования: расширяется прецедентом «Z3. Планирование срочного заказа» Краткое описание. Система уведомляет Заказчика о наличии вновь поступившего заказа и отображает список работ по заказу, их продолжительность и плановый срок заказа. Заказчик наблюдает загрузку ресурсов на диаграмме загрузки оборудования. Каждый ресурс отображается в виде линейки загрузки ресурса – линии времени с указанием свободных и занятых промежутков. Система следит за тем, чтобы соблюдалась последовательность работ внутри заказа и прописывает дату окончания этапа. (Таблица 2.8) Таблица 2.8 - Коррекция плана
Основное действующее лицо: Заказчик. Другие участники прецедента: Отсутствует. Связи с другими вариантами использования. Включается прецедентом «Z3. Планирование срочного заказа» Краткое описание. Система уведомляет Заказчика о наличии заказа, который был ранее запланирован, но с которым произошла внеплановая ситуация. Система раздельно отображает список уже выполненных работ по заказу и список оставшихся работ с указанием их продолжительности. В зависимости от статуса заказа, Менеджер планирует оставшиеся работы так, как это предусмотрено прецедентом Z2, либо Z3. Система автоматически уведомляет Заказчика обо всех изменениях в планах работ по заказу. (Таблица 2.9) Таблица 2.9 - Планирование срочного заказа
Основное действующее лицо: Поставщик. Другие участники прецедента: Отсутствуют. Связи с другими вариантами использования: Расширяет прецедент «Z2. Планирование заказа». Краткое описание. Менеджер связывается с Поставщиком, чтобы узнать о наличии нужных ему материалов. Поставщик сообщает срок доставки. 3.2 Полные описания вариантов использования Анализ сформулированных вариантов использования показал, что с точки зрения потенциальных рисков и архитектурной значимости наиболее существенными являются прецеденты, связанные с работой Менеджера. Для дальнейшей детализации выбраны три прецедента: А1. Регистрация заказа; А2. Планирование нового заказа; А3. Планирование срочного заказа. 3.3 Специальные требования 3.3.1 Функциональность 3.3.1.1 F1. Авторизация и аутентификация пользователей в системе В АИС должны быть представлены справочник ролей пользователей (Заказчик, Менеджер, Поставщик) и справочник пользователей. Должна быть возможность регистрации пользователя и назначения пользователю роли. 3.3.1.2 F2. Ведение справочника работ Работы, включаемые в описание заказа, выбираются из справочника типов работ. В АИС должны быть представлены средства управления типами работ. 3.3.1.3 F3. Ведение справочника ресурсов В АИС должны быть представлены средства управления типами ресурсов (оператор/оборудование), справочниками персонала и оборудования. 3.3.2 Применимость 3.3.2.1 U1. Удобство использования Интерфейс Сайта «Менеджер» и «Заказчик» должен быть обладать свойствами удобства и интуитивной ясности и не требовать дополнительной подготовки пользователей. Интерфейс Сайта «Менеджер» должен иметь навыки на уровне уверенного пользователя. 3.3.2.2 U2. Помощь в режиме online Сайт должен поддерживать контекстную справку в форме стандартного help. 3.3.3 Надежность 3.3.3.1 R1. Доступность Сайт в режиме заказов должен быть доступен в рабочие дни в рабочее время с 8:00 до 18:00 Сайт Менеджера должен быть доступен в круглосуточном режиме. Время, затрачиваемое на обслуживание системы не должно превышать 3% от общего времени работы. 3.3.3.2 R2. Наработка на отказ Среднее время безотказной работы – все календарные дни в году. 3.3.3.3 R3. Норма дефектов Максимальная норма ошибок или дефектов – 1 ошибка на десять тысяч строк кода. 3.3.4 Производительность 3.3.4.1 T1. Одновременно работающие пользователи Система должна быть способна поддерживать минимум 15 одновременно работающих пользователей, связанных с общей базой данных. 3.3.4.2 T2. Время отклика Время отклика для типичных задач – не более 5 секунд, для сложных задач – не более 20 секунд. 3.3.5 Пригодность к эксплуатации 3.3.5.1 S1. Масштабируемость Система должна быть способна поддерживать минимум 15 одновременно работающих пользователей, связанных с общей базой данных и иметь возможность увеличить их количество на случай увеличения покупателей. В настоящее время на предприятии имеется 1 Менеджер, который выполняет функции: менеджера, диспетчера. Также Менеджер покупает у Поставщика материалы. В дальнейшем штат будет расширяться, добавление в штат: менеджера, диспетчера – ближайшие 1-2 года, через 3 года – помощник Менеджера. 3.3.5.2 S2. Обновление версий Обновление версий должно реализовываться в автоматизированном режиме на основе системы контроля версий и системы (сервера) обновления версий на рабочих местах пользователей. 3.3.6 Ограничения проектирования 3.3.6.1 X1. Применяемые стандарты Система должна соответствовать всем веб интерфейса. 3.3.6.2 X2. Требования к среде выполнения Система должна удовлетворять вышеуказанным требованиям на компьютере в следующей минимальной комплектации: 264 Gb памяти; 100 Gb свободного дискового пространства; процессор с тактовой частотой 2,300 MHz; Операционная система Windows 10. 3.3.6.3 X3. Требования к СУБД и доступу к данным. В ядре системы должна быть представлена промышленная СУБД реляционного доступа. Все обращения к информации должны осуществляться через драйвер ODBC. 4. Вспомогательная информация Перечень вспомогательной информации представлен в п. 1.3. Формулировка вопросов По результатам предварительного ознакомления с материалами и анализа выступления докладчиков экспертами были сформулированы следующие вопросы. Как устроена расчётная система, позволяющая определять время выполнения работ заказа? Сколько заказов в среднем проходит в день? Каков механизм передачи информации от заказчика к Менеджера? Каков горизонт планирования? Где отражена информация о графиках сменной работы Менеджера? Каков средний срок готовности заказа? Общая оценка требований Для удобства оперирования с требованиями все они были сведены в таблицу 1. Введена следующая типизация требования (поле «тип»): UC – функциональное, в форме прецедента; F – функциональное; U – нефункциональное (применимость); R – нефункциональное (надёжность); P – нефункциональное (производительность); S – нефункциональное (пригодность к эксплуатации); –прочее. Количественное оценивание требований Свойства требований были оценены по количественной шкале [0,1]: 0 – очень низкое качество; 1 – очень высокое качество. Для свойств полноты и ясности шкала – дробная, для свойств корректности и верифицируемости – бинарная (0 или 1). В результирующей таблице для каждого из свойств представлены 4 оценки. (Таблица 2.10) Таблица 2.10 – Реестр требований, количественная оценка
Формулировка замечаний к требованиям Для всех требований, количественная оценка которых составила менее 0,5, подготовлены замечания. 2.2.1. A1. Полнота. Выбранная степень подробности оставляет открытыми ряд вопросов, основной из которых – как осуществляется расчёт времени работ заказа. 2.2.2. Z2. Корректность. Требование сформулировано не вполне корректно, т.к. фраза «доступны только совместимые ресурсы» не подкрепляется механизмом определения совместимости ресурсов нигде по тексту. Оценка вариантов использования Все требования, представленные в форме вариантов использования, были оценены по ряду параметров: Автономность и законченность; Наличие цели (измеримого значения); Правильный выбор уровня абстракции; Полнота описания альтернативных сценариев; Полнота описания нефункциональных требований; Структурированность. Количественное оценивание прецедентов Оценивание производилось на основе использования шкалы [0,1]. (Таблица 2.11) Таблица 2.11 - Реестр существенных прецедентов; количественная оценка
Формулировка замечаний к прецедентам Для всех требований, количественная оценка которых составила менее 0,5, подготовлены замечания. 3.2.1. Z2. Полнота описания альтернативных сценариев. Не проанализировано поведение системы в исключительных ситуациях. Оценка системы требований Полнота системы требований 4.1.1. Пропущено описание поведения, связанного с управлением нормативно-справочной информацией: справочниками персонала, ресурсов, оборудования, ассоциаций «ресурс-персонал». 4.1.2. Пропущено описание поведения, связанного с управлением графиками смен. Система требований является неполной. Согласованность системы требований. Экспертами не обнаружено требований, входящих в противоречие друг с другом. Система требований признана согласованной. Оценка качества создания документа Соответствие шаблону Все представленные документы соответствуют шаблонам оформления. Корректность правописания Опечаток в словах не обнаружено. 5.2.1. Обнаружены ошибки управления в предложениях. Менеджером необходимо воспользоваться встроенной системой проверки правописания MS Word. Качество написания блоков текста, не относящегося непосредственно к требованиям Все представленные блоки текста SRS (введение, предположения и зависимости), не относящиеся непосредственно к формулировке требований, написаны на приемлемом уровне. Выводы Представленные на экспертизу документы проработаны недостаточно и подлежат переработке с последующим проведением повторной экспертизы. Входным условием для проведения повторной экспертизы является устранение замечаний. (Таблица 2.12) Таблица 2.12 - Реестр замечаний
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||