Файл: 1. Аналитическая часть Техникоэкономическая характеристика предметной области и предприятия.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 26.10.2023
Просмотров: 763
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
1.2. Характеристика комплекса задач, задачи и обоснование необходимости автоматизации
1.2.1. Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов
1.3. Анализ существующих разработок и выбор стратегии автоматизации "КАК ДОЛЖНО БЫТЬ»"
1.4. Обоснование проектных решений
2.1. Разработка проекта автоматизации
2.2. Информационное обеспечение задачи
2.3. Программное обеспечение задачи
2.3.4. Описание программных модулей
2.4. Контрольный пример реализации проекта и его описание
3. ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ПРОЕКТА
3.1 Выбор и обоснование методики расчёта экономической эффективности
3.2 Расчёт показателей экономической эффективности проекта
Рисунок 1.12 – Фрагмент "Согласование фрагмента договора"
Нова технология решает устраняет следующие недостатки:
В качестве способа приобретения выбрана собственная разработка.
Обоснованием выбора собственной разработки обуславливается тем, что при разработке программного обеспечения будут использоваться программные средства, которые распространяются по свободной лицензии. А именно среда программирования Delphi 10.4 Sidney Community Edition и MySQL 8.0.28. Поэтому расходы на создание программного обеспечения будут сведены лишь к затратам на заработную плату и сопутствующим затратам, таким как затраты на электроэнергию, оборудование, отчисления страховых взносов из заработной платы разработчиков и т. п.
Проектные решения по информационному обеспечению обосновываются с точки входной и выходной информации.
В разрабатываемом приложении не используются какие-либо унифицированные формы входных документов, накладной ТОРГ-12. Цель приложения заключается в формировании электронного документооборота между поставщиком и аптекой.
Входящей информацией является:
Результатная информация представляет из себя ту информацию, которую пользователь должен получить на выходе, в результате обработки данных программой.
Результатная информация в разрабатываемой информационной системе представляется многочисленными результатами выборок, которые описаны в соответствующем разделе работы "Характеристика результатной информации".
В таблице 1.2 представлен программный комплекс, применяемый в процессе проектирования.
Таблица 1.2 – Программные средства, используемые в ходе проектирования
В таблице 1.3 представлен аппаратный комплекс, применяемый в процессе проектирования.
Таблица 1.3 – Аппаратные средства, используемые в ходе проектирования
На рисунке 1.13 представлен скрин свойства системы.
Рисунок 1.13 – Окно "Система"
Жизненный цикл разработки информационной системы включает в себя прохождение этапов жизненных циклов, которые начинаются от создания системы и заканчивая её эксплуатацией.
К таким стадиям относятся:
В течение жизненного цикла системы проводится модернизация ее технико-программной базы. При этом, прикладное программное обеспечение системы должно быть сохранено и перенесено на обновляемые аппаратно-программные платформы.
Международный стандарт ISO/IEC 12207 определяет структуру жизненного цикла. Он содержит процессы, которые должны быть выполнены во время создания информационной системы.
Данные процессы делятся на три группы:
Указанный стандарт ISO/IEC 12207 не определяет конкретной модели жизненного цикла и методов его разработки. Он содержит общие рекомендации, предназначенные для любых моделей жизненного цикла. Эти рекомендации ориентированы на разработку информационной системы в рамках организации. Есть стандарты, которые более ориентированы на производителей информационных систем. Они подразумевают более четкие требования.
В настоящее время наиболее распространена каскадная модель. Каскадная модель создания информационной системы является однородной и ее программное обеспечение определяется как единое (с ней) целое. Каскадная модель обеспечивает хорошие результаты. Она показана на рисунке 2.1.
Рисунок 2.1 ‒ Каскадная модель жизненного цикла
Именно каскадная модель была применена для реализации проекта в данной работе.
Весь процесс разработки, в соответствии с данной моделью разбивается на несколько этапов, переход от одного этапа к другому происходит только после полного выполнения предыдущего этапа.
Это означает, что на каждом этапе формируется законченный набор проектной документации, этого набора должно быть абсолютно достаточно для передачи проекта другой группе разработчиков, функционирующих на следующем этапе жизненного цикла по разработке информационной системы. Так же одним из положительных моментов каскадной модели является возможность планирования сроков завершения работ и затрат на их выполнение. Как и у любой модели, у каскадной модели есть свой недостаток. Он заключается в том, что сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему. В связи с этим часто возникает потребность возврата на предыдущий этап, с целью уточнения и пересмотра решений, принятых ранее.
Весь процесс разработки программного обеспечения начинается с изучения предметной области.
При данной модели разработки сначала осуществляется чертеж на бумаге. Этот этап называется проектированием. На бумаге проектируется база данных, а именно, наименование таблиц, наименование и структура полей таблиц, связей между таблицами. Далее осуществляется чертеж эскиза форм и прочих элементов интерфейса. Чертеж начинается с основной формы MDI и ее меню. Далее, последовательно чертятся формы, информация в которых отображается из справочных таблиц и формы, содержащие информацию из учетных (оперативных) таблиц. Следующим этапом разработки является проектирование дизайна в среде программирования, то есть построение пользовательского интерфейса. Осуществляется в той же последовательности. На данном этапе интерфейс пока еще не выполняет своих функций.
При наступлении третьего этапа начинается "оживление" пользовательского интерфейса посредством записи процедур и функций. Последовательность разработке такая же, как при составлении эскизов. Разрабатываются различные модули для осуществления рабочих функций приложения. Тестируется каждый модуль на наличие возможных ошибок.
После кодирования созданное приложение необходимо протестировать на наличие ошибок уже комплексно. Здесь следует предусмотреть все нелепые операции, которые может осуществить пользователь, который будет работать с данным программным обеспечением.
После успешного прохождения теста, программе необходима техническая поддержка по внесению определенных изменений, которые будут происходить в регламенте учебного заведения.
Так как начальный процесс в построении системы является процесс изучения предметной области, то становится очевидным, что для того, чтобы начать проектировать базу данных, то есть перейти на следующий этап проектирования, следует максимально разбираться в той предметной области, в которой будет вестись разработка. Следует отметить, что для того, чтобы обеспечить функциональность приложения, собирается целая команда разработчиков, в которую входят не только программисты, но и другие специалисты. Это, прежде всего специалисты той предметной области, одну из задач которой собираются программировать, поскольку программисты не могут, например, разбираться так же хорошо в вопросах фармацевтики, как это делают специалисты, работающие в аптеках. Применительно к разрабатываемой системе, следует хорошо себе представлять общую структуру работы по заказу товаров и медикаментов у поставщиков.
Первым специалистом в исследуемой предметной области аптеки, который непосредственно общается с поставщиками является менеджер по закупкам. Именно он занимается всем документооборотом в аптеке. Основной риск проектирования здесь может заключаться в том, что менеджер может в техническом задании отметить не все функции, которые он выполняет при традиционной работе. В этом случае программисты, разрабатывающие структуру базы данных, могут вернуть менеджеру проект на доработку (на предыдущий этап).
Уже после повторной доработки менеджедром технического задания станет ясно, достаточно ли данной информации для проектирования базы данных, либо нет. В процессе возврата проекта на предыдущий этап нет ничего необычного. Это процесс доработки. Именно так и должна проходить любая разработка программного обеспечения. Процесс проектирования базы данных сначала делается на обычном листе карандашом. Чертятся таблицы, дается название полям, чертятся связи между таблицами по ключевым полям. После успешного проектирования на бумаге начинается непосредственное проектирования на выбранного для проекта СУБД. В данном случае был выбран СУБД MySQL.
Нова технология решает устраняет следующие недостатки:
-
Весь процесс взаимодействия с поставщиком теперь осуществляется в рамках электронного документооборота. Вместо обсуждения стоимости заказа по телефону, поставщик может присылать коммерческое предложение, может согласовывать договор, вносить в него свои корректировки перед тем, как будет сформирован окончательный вид договора. -
Вся информация о договоре, включая заявку, перечень товаров, проект договора, информацию о поставщике хранится в базе данных, что позволит в самые короткие сроки получить необходимую из базы данных информацию.
1.3.3. Выбор и обоснование способа приобретения ИС для автоматизации задачи
В качестве способа приобретения выбрана собственная разработка.
Обоснованием выбора собственной разработки обуславливается тем, что при разработке программного обеспечения будут использоваться программные средства, которые распространяются по свободной лицензии. А именно среда программирования Delphi 10.4 Sidney Community Edition и MySQL 8.0.28. Поэтому расходы на создание программного обеспечения будут сведены лишь к затратам на заработную плату и сопутствующим затратам, таким как затраты на электроэнергию, оборудование, отчисления страховых взносов из заработной платы разработчиков и т. п.
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному обеспечению
Проектные решения по информационному обеспечению обосновываются с точки входной и выходной информации.
В разрабатываемом приложении не используются какие-либо унифицированные формы входных документов, накладной ТОРГ-12. Цель приложения заключается в формировании электронного документооборота между поставщиком и аптекой.
Входящей информацией является:
-
Потребность в товарах; -
Коммерческое предложение; -
Накладная.
Результатная информация представляет из себя ту информацию, которую пользователь должен получить на выходе, в результате обработки данных программой.
Результатная информация в разрабатываемой информационной системе представляется многочисленными результатами выборок, которые описаны в соответствующем разделе работы "Характеристика результатной информации".
1.4.2. Обоснование проектных решений по программному обеспечению
В таблице 1.2 представлен программный комплекс, применяемый в процессе проектирования.
Таблица 1.2 – Программные средства, используемые в ходе проектирования
| Наименование | Описание |
| ОС Windows 10 | Операционная система Windows 64-х разрядная, разработанная компанией Microsoft. |
| Delphi 10.4.Sidney Community Edition | Интегрированная среда разработки от компании Embarcadero Technologies/ Распространяется по бесплатной лицензии. Delphi - полноценный объектно-ориентированный язык программирования общего назначения, разработанный компанией Borland на основе object pascal. |
| MySQL 8.0.28 | Система управления базами данных от компании Microsoft, предназначенная для не сильно нагруженных файл-серверных сетей. |
| FastReport 6 VCL | Визуальный конструктор отчетов для Delphi 10, созданный одноименной компанией |
| AC Allfusion Process Modeler r7 (BP-win) | Инструмент моделирования предметной области, который используется для анализа, документирования и реорганизации сложных бизнес-процессов |
1.4.3. Обоснование проектных решений по техническому обеспечению
В таблице 1.3 представлен аппаратный комплекс, применяемый в процессе проектирования.
Таблица 1.3 – Аппаратные средства, используемые в ходе проектирования
| Аппаратная часть | Характеристика |
| Центральный процессор | Intel Pentium CPU G3240 |
| Тактовая частота центрального процессора | 3.10 Ггц |
| Количество ядер ЦПУ | 2 |
| Разрядность процессора | 64 |
| Объем оперативной памяти | 4 Гб |
| Объем жесткого диска | 296 Гб |
На рисунке 1.13 представлен скрин свойства системы.
Рисунок 1.13 – Окно "Система"
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл разработки информационной системы включает в себя прохождение этапов жизненных циклов, которые начинаются от создания системы и заканчивая её эксплуатацией.
К таким стадиям относятся:
-
Предпроектный анализ. На этой стадии формируется информационная и функциональная модель объекта, для которого будет осуществляться проектирование информационной системы; -
Проектирование системы. Эта стадия включая разработку технического задания, а также технического и эскизного проектов; -
Разработка системы. Это этап непосредственного создания системы, то есть, программирования и тестирования создаваемой программы. -
Проведение испытаний программы; -
Эксплуатация и сопровождение информационной системы.
В течение жизненного цикла системы проводится модернизация ее технико-программной базы. При этом, прикладное программное обеспечение системы должно быть сохранено и перенесено на обновляемые аппаратно-программные платформы.
Международный стандарт ISO/IEC 12207 определяет структуру жизненного цикла. Он содержит процессы, которые должны быть выполнены во время создания информационной системы.
Данные процессы делятся на три группы:
-
Основные. К ним относятся приобретение, поставка, разработка, эксплуатация, а также сопровождение. -
Вспомогательные. Это процессы документирования, управления конфигурацией, верификации, процессы обеспечения качества, процессы аттестации, оценки, аудита и решения проблем. -
Организационные. Это процессы управления проектами, создание инфраструктуры проекта, определения, оценка и улучшение самого жизненного цикла, процессы обучения.
Указанный стандарт ISO/IEC 12207 не определяет конкретной модели жизненного цикла и методов его разработки. Он содержит общие рекомендации, предназначенные для любых моделей жизненного цикла. Эти рекомендации ориентированы на разработку информационной системы в рамках организации. Есть стандарты, которые более ориентированы на производителей информационных систем. Они подразумевают более четкие требования.
В настоящее время наиболее распространена каскадная модель. Каскадная модель создания информационной системы является однородной и ее программное обеспечение определяется как единое (с ней) целое. Каскадная модель обеспечивает хорошие результаты. Она показана на рисунке 2.1.
Рисунок 2.1 ‒ Каскадная модель жизненного цикла
Именно каскадная модель была применена для реализации проекта в данной работе.
Весь процесс разработки, в соответствии с данной моделью разбивается на несколько этапов, переход от одного этапа к другому происходит только после полного выполнения предыдущего этапа.
Это означает, что на каждом этапе формируется законченный набор проектной документации, этого набора должно быть абсолютно достаточно для передачи проекта другой группе разработчиков, функционирующих на следующем этапе жизненного цикла по разработке информационной системы. Так же одним из положительных моментов каскадной модели является возможность планирования сроков завершения работ и затрат на их выполнение. Как и у любой модели, у каскадной модели есть свой недостаток. Он заключается в том, что сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему. В связи с этим часто возникает потребность возврата на предыдущий этап, с целью уточнения и пересмотра решений, принятых ранее.
Весь процесс разработки программного обеспечения начинается с изучения предметной области.
При данной модели разработки сначала осуществляется чертеж на бумаге. Этот этап называется проектированием. На бумаге проектируется база данных, а именно, наименование таблиц, наименование и структура полей таблиц, связей между таблицами. Далее осуществляется чертеж эскиза форм и прочих элементов интерфейса. Чертеж начинается с основной формы MDI и ее меню. Далее, последовательно чертятся формы, информация в которых отображается из справочных таблиц и формы, содержащие информацию из учетных (оперативных) таблиц. Следующим этапом разработки является проектирование дизайна в среде программирования, то есть построение пользовательского интерфейса. Осуществляется в той же последовательности. На данном этапе интерфейс пока еще не выполняет своих функций.
При наступлении третьего этапа начинается "оживление" пользовательского интерфейса посредством записи процедур и функций. Последовательность разработке такая же, как при составлении эскизов. Разрабатываются различные модули для осуществления рабочих функций приложения. Тестируется каждый модуль на наличие возможных ошибок.
После кодирования созданное приложение необходимо протестировать на наличие ошибок уже комплексно. Здесь следует предусмотреть все нелепые операции, которые может осуществить пользователь, который будет работать с данным программным обеспечением.
После успешного прохождения теста, программе необходима техническая поддержка по внесению определенных изменений, которые будут происходить в регламенте учебного заведения.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Так как начальный процесс в построении системы является процесс изучения предметной области, то становится очевидным, что для того, чтобы начать проектировать базу данных, то есть перейти на следующий этап проектирования, следует максимально разбираться в той предметной области, в которой будет вестись разработка. Следует отметить, что для того, чтобы обеспечить функциональность приложения, собирается целая команда разработчиков, в которую входят не только программисты, но и другие специалисты. Это, прежде всего специалисты той предметной области, одну из задач которой собираются программировать, поскольку программисты не могут, например, разбираться так же хорошо в вопросах фармацевтики, как это делают специалисты, работающие в аптеках. Применительно к разрабатываемой системе, следует хорошо себе представлять общую структуру работы по заказу товаров и медикаментов у поставщиков.
Первым специалистом в исследуемой предметной области аптеки, который непосредственно общается с поставщиками является менеджер по закупкам. Именно он занимается всем документооборотом в аптеке. Основной риск проектирования здесь может заключаться в том, что менеджер может в техническом задании отметить не все функции, которые он выполняет при традиционной работе. В этом случае программисты, разрабатывающие структуру базы данных, могут вернуть менеджеру проект на доработку (на предыдущий этап).
Уже после повторной доработки менеджедром технического задания станет ясно, достаточно ли данной информации для проектирования базы данных, либо нет. В процессе возврата проекта на предыдущий этап нет ничего необычного. Это процесс доработки. Именно так и должна проходить любая разработка программного обеспечения. Процесс проектирования базы данных сначала делается на обычном листе карандашом. Чертятся таблицы, дается название полям, чертятся связи между таблицами по ключевым полям. После успешного проектирования на бумаге начинается непосредственное проектирования на выбранного для проекта СУБД. В данном случае был выбран СУБД MySQL.