Г осударственное профессиональное образовательное учреждение Кузбасский колледж архитектуры, строительства и цифровых технологий
 Скачать 1.46 Mb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ КУЗБАССА Г  осударственное профессиональное образовательное учреждение«Кузбасский колледж архитектуры, строительства и цифровых технологий» (ГПОУ ККАСиЦТ) Специальность 09.02.04 Информационные системы (по отраслям) ОТЧЁТ по учебной практике УП.02.01 Практика по разработке информационных систем Студента группы ИС18-1 Побережец Данила Александрович «23» марта 2022г. Отчет по практике выполнен на оценку ___________ Руководитель практики Куранова Светлана Витальевна «12» апреля 2022г. Новокузнецк 2022 Задание на учебную практику УП.02.01 Практика по разработке информационных систем Студента: Побережец Данила Александрович Группы: ИС18-1 Начало практики: 23.03.2022 Конец практики 12.04.2022 Индивидуальное задание. Разработка информационной системы для
Руководитель практики: Куранова С.В. /__________/ СОДЕРЖАНИЕ1.1 Анализ требований к АИС 1 1.3 Разработка ТЗ 27 1.4 Создание диаграмм в среде BPwin 56 1.5 Проектирование диаграммы ERD (MS Access) 62 1.6 Моделирование UML-диаграмм 63 1.7 Реализация приложения 65 1.8 Реализация приложения 68 1.9 Реализация приложения 68 1.10 Управление проектом по разработке ИС 69 1.11 Построение концепции ИБ предприятия 70 1.12 Экономическое обоснование ИС 94 1.13 Экономическое обоснование ИС 94 1.14 Тестирование ИС 96 2 Приложение А 97 1.1 Анализ требований к АИСЦель: Необходимо выявить и описать высокоуровневые требования к информационной системе в соответствии с вариантом задания; выявить и описать требования пользователей (ранг - специалист, потенциальный пользователь) к информационной системе в соответствие с вариантом задания, определить основных акторов и сформулировать варианты использования. Введение Цель Цель создания данного документа состоит в том, чтобы собрать, проанализировать и определить высокоуровневые потребности и возможности системы Тур агентства. Документ акцентирует внимание на возможностях, необходимых совладельцам и целевым пользователям, и на том, почему эти потребности существуют. Подробности того, как система Тур агентство по продаже туристических путевоквыполняет эти потребности, будут детализированы в прецедентах и дополнительных спецификациях. 1.2. Краткое содержание Документ описывает высокоуровневые требования к системе тур агенства. Указаны основные деловые преимущества рассматриваемого в «Видении» решения, сформулированы ключевые проблемы и способы их решения, приведены характеристики пользователей системы, возможности системы, ограничения, показатели качества и другие требования к продукту. (Таблица 1.1 - 1.3) Таблица 1.1 – Определение проблемы №1
Таблица 1.2 – Определение проблемы №2
Таблица 1.3 – Определение проблемы №3
2. Определение позиции изделия. (Таблица 1.4) Таблица 1.4 – Позиция услуги
3. Описания пользователей 3.1 Сведения о пользователях У системы существуют два основных пользователя: менеджер, заказчик. Заказчик – создает заказ, отправляет созданный заказ Менеджеру и проверяет при получении заказа его качество. Менеджер – получает заказы, планирует план заказа, по завершению заказа уведомляет Заказчика о готовности заказа. 3.2 Пользовательская среда В настоящее время на предприятии имеется 1 компьютер (главный), 1 менеджер. 3.3 Профили пользователей. (Таблица 1.5 – 1.7) Таблица 1.5 – Профиль Менеджер
Таблица 1.6 – Профиль Заказчика
3.4 Ключевые потребности пользователей Менеджер затрачивает большое количество времени на составление очереди и внесение необходимых изменений. Заказчики затрачивают значительное количество времени на регулирование накладок с Менеджер. Предприятие нуждается в системе, которая бы имела готовые варианты туров для заказчика, чтобы ускорить процесс работы. 4. Краткий обзор изделия 4.1 Контекст использования системы Система является законченной независимой разработкой. В перспективе возможно использование системы в комплексе с системами автоматизации. 4.2 Сводка возможностей. (Таблица 1.8) Таблица 1.8. - Система рекламное агентство
4.3 Предположения и зависимости Система будет использоваться на территориально сосредоточенном (без внешних филиалов) предприятии. В случае изменений в формах документов АИС должна претерпеть малосущественные изменения (нужно будет модифицировать отчётные формы). В случае приобретения или разработки информационных систем, автоматизирующих смежные участки (маркетинг), будет необходимо разработать соответствующие средства импорта-экспорта информации. Прочие требования к АИС 5. Возможности продукта 5.1 Структурированное описание заказа Возможность описания заказа через упорядоченную во времени совокупность работ, а также параметров. 5.2 Расчёт нормативного времени выполнения работ заказа Возможность для каждой из работ заказа автоматически определить, на основании введённых параметров. 5.3 Передача заказа в производство Возможность направить заказ, в котором указаны все необходимые параметры, автору. 5.4 Контроль исполнения и оперативная корректировка планов Возможность контроля исполнения работ над заказами. Возможность оперативной корректировки планов при возникновении критичных ситуаций. 6. Ограничения Внедрение системы не должно занимать более 3 месяцев. В ядре системы должна быть представлена промышленная СУБД реляционного доступа. Все обращения к информации должны осуществляться через драйвер ODBC. 7. Показатели качества 7.1 Применимость Время, необходимое для обучения обычных пользователей – 1рабочий день (2 часа), для обучения продвинутых пользователей – 1 рабочий день (1 час); Время отклика для типичных задач – не более 5 секунд, для сложных задач – не более 20 секунд. 7.2 Надежность доступность – время, затрачиваемое на обслуживание системы не должно превышать 3% от общего времени работы; среднее время безотказной работы – 10 рабочих дней; максимальная норма ошибок или дефектов – 1 ошибка на десять тысяч строк кода. 8. Применяемые стандарты Система должна соответствовать всем стандартам интерфейса пользователя Microsoft® Windows®. 8.1 Системные требования Минимальные системные требования: 64 Mb памяти; 192 Gb свободного дискового пространства; процессор с тактовой частотой 2300 MHz; Операционная система Windows 10. 8.2 Эксплуатационные требования Система должна быть способна поддерживать минимум 15 одновременно работающих пользователей, связанных с общей базой данных и иметь возможность увеличить их количество на случай увеличения. 9. Требования к документации 9.1 Руководство пользователя В руководстве пользователя будет алгоритм заказа услуги, автоматизированный сбор заказов. 9.2 Интерактивная справка Интерактивная справка необходима для разрешения возникших во время работы вопросов. В справке должна быть реализована возможность поиска информации, по ключевым словам, а также вариант представления информации по отдельным позициям меню программы. Справка должна содержать максимально полную и подробную информацию по работе системы. 10. 10.1 Выявление акторов Рисунок 1.1 – Анализ акторов системы Интервью, проведённое с указанными выше кандидатами, показало, что автор предполагает использовать разрабатываемую АИС однотипно. (Таблица 1.9) Таблица 1.9 - Выявление акторов
11. Выявление вариантов использования. (Таблица1.10) Таблица 1.10 - Выявление вариантов использования
Рисунок 1.2 - Диаграмма прецедентов системы 13. 13.1 Структуризация вариантов использования Анализ вариантов использования выявил следующие взаимосвязи. Варианты использования «Регистрация заказа» и «Регистрация срочного заказа» не содержат принципиальных отличий, поэтому было принято решение ввести новый вариант использования «Регистрация стандартного заказа», оставить прецедент «Регистрация заказа», как основной, обобщающий вновь введённый прецедент и прецедент «Регистрация срочного заказа». Рисунок 1.3 - Обобщение вариантов использования регистрации заказа Вариант использования «Планирование срочного заказа» основан на базовом прецеденте «Планирование нового заказа», но содержит более сложную логику обработки. Поэтому было принято решение связать указанные прецеденты расширяющим отношением. Кроме того, прецедент «Планирование срочного заказа» использует логику прецедента «Коррекция плана». Поэтому было принято решение связать указанные прецеденты отношением включения. (Рисунок 1.4) планирования заказа Выявлена пропущенные ассоциация между Менеджером и прецедентами «Изменить заказ», «Удалить заказ» и прецедентом «Коррекция плана». Данные ассоциации позволяют осуществлять необходимые обратные связи между функциями системы. 14. Реестр вариантов использования По результатам анализа, проделанного в параграфе «13.1 Структуризация вариантов использования» было принято решение об исключении двух вариантов использования: «Регистрация стандартного заказа» и «Регистрация срочного заказа», т.к. осуществляемые в них активности отличаются малосущественно. Их функциональность сводится к функциональности прецедента «Регистрация заказа». (Таблица 1.11) Таблица 1.11 - Реестр вариантов использования
15. Конкретизация вариантов использования. (Таблица 1.12) Таблица 1.12 - Регистрация заказа
Основное действующее лицо: Менеджер. Другие участники прецедента: отсутствуют. Связи с другими вариантами использования: отсутствуют. Краткое описание. Данный вариант использования позволяет Менеджер регистрировать и передавать новые заказы. Каждый заказ в электронной форме содержит дату требуемой готовности и упорядоченный перечень работ с указанием протяжённости каждой из них во времени, и Менеджер отправляется пожелания Заказчика. Срочные заказы помечаются признаком «Срочно». Срочные заказы необходимо выполнить в срок, возможно, даже в ущерб обычным заказам. Для прочих заказов дата требуемой готовности должна носит рекомендательный характер. Заказчик обговаривает сам заказ либо Менеджер выбирает один из готовых вариантов. Времена работ рассчитывается в зависимости от сложности работы. (Таблица 1.13) Таблица 1.13 -Изменение заказа
Основное действующее лицо: Менеджер. Другие участники прецедента: отсутствуют. Связи с другими вариантами использования: отсутствуют. Краткое описание. Данный вариант использования позволяет Менеджер внести изменения в описания заказов, находящихся в производстве. Для заказов, работы над которыми ещё не начались, возможны изменения параметров заказа: даты готовности и комментарии к заказу. Для заказов, выполнение которых уже началось, существуют следующие ограничения. Статус заказа, при изготовлении, как «обычный», не может быть изменён на «срочный». Плановый срок исполнения не может быть сдвинут назад по временной шкале. Запрещаются глобальные изменения в описаниях работ, которые уже начаты. Менеджер уведомляется о результатах изменений. (Таблица 1.14) Таблица 1.14 - Удаление заказа
Основное действующее лицо: Менеджер. Другие участники прецедента: Заказчик. Связи с другими вариантами использования: отсутствуют Краткое описание Данный вариант использования позволяет Менеджеру или Заказчику снимать заказы с производства. Для заказов, работы над которыми ещё не начались, удаляется вся информация. Для заказов, выполнение которых уже началось, удаляется плановая информация о работах, которые ещё не начаты. (Таблица 1.15) Таблица 1.15 - Запрос о заказе
Основное действующее лицо: Заказчик. Другие участники прецедента: отсутствуют. Связи с другими вариантами использования: отсутствуют. Краткое описание. Данный вариант использования позволяет Заказчику узнавать о планах производства заказа, а также о фактических результатах исполнения работ над заказом. Так как Менеджер не всегда имеет доступ к компьютеризованному рабочему месту, данный вариант использования должен быть доступен также и Автору, для консультирования Заказчика по телефону. (Таблица 1.16) Таблица 1.16 - Планирование нового заказа
Основное действующее лицо: Заказчик. Другие участники прецедента: отсутствуют. Связи с другими вариантами использования: расширяется прецедентом «Z3. Планирование срочного заказа». Краткое описание Система уведомляет Заказчика о наличии вновь поступившего заказа и отображает список работ по заказу, их продолжительность и плановый срок заказа. Заказчик наблюдает загрузку ресурсов на диаграмме загрузки оборудования. Каждый ресурс отображается в виде линейки загрузки ресурса – линии времени с указанием свободных и занятых промежутков. Система следит за тем, чтобы соблюдалась последовательность работ внутри заказа и прописывает дату окончания этапа. (Таблица 1.17) Таблица 1.17 Коррекция плана
Основное действующее лицо: Заказчик. Другие участники прецедента: Отсутствует. Связи с другими вариантами использования. Включается прецедентом «Z3. Планирование срочного заказа». Краткое описание. Система уведомляет Заказчика о наличии заказа, который был ранее запланирован, но с которым произошла внеплановая ситуация. Система раздельно отображает список уже выполненных работ по заказу и список оставшихся работ с указанием их продолжительности. В зависимости от статуса заказа, Менеджер планирует оставшиеся работы так, как это предусмотрено прецедентом Z2, либо Z3. Система автоматически уведомляет Заказчика обо всех изменениях в планах работ по заказу. (Таблица 1.18) 1.2 Спецификация требований к АИС Введение Цель Глоссарий содержит описания терминов, используемых при проектировании информационной системы рекламного агентства. Определяются основные понятия, непосредственно связанные с самим рекламным агентством и стилизации Менеджером. Определения Понятия, используемые при описании исходной информации Сайт рекламного агентства - веб-ресурс, содержащий каталог товаров и предоставляющий покупателю (посетителю веб-сайта) выбрать из каталога товар, заказать товар, оплатить его через платежные интернет системы и получить его, используя различные способы доставки. Покупатель - гражданин, который намерен заказать (заказывающий) или приобрести (приобретающий) или уже использующий товары только для коммерческих нужд. Drag-and-drop (D&D, DnD, DND, в переводе с английского означает букв. — «тащи-и-бросай»; «Бери-и-Брось») — способ оперирования элементами интерфейса в интерфейсах пользователя (как графическим, так и текстовым, где элементы GUI реализованы при помощи псевдографики) при помощи манипулятора «мышь» или сенсорного экрана. Продавец - организация любой организационно-правовой формы, а также гражданин осуществляющий продажу товаров дистанционным способом (тур агентство) на правах индивидуального предпринимателя. Баннер - 1) прямоугольный планшет из пластика, картона или бумаги, подвешенный в витрине; 2) картинка на сайте, ведущая на сайт рекламодателя (см. также баннерная сеть, ссылка) Билл борд - большой щит с рекламным плакатом 3х6 м или 4х10 м. устанавливается на собственной подставке. |