48
Скорость работы
приложения
отличная (++)
хорошая (+)
Скорость разработки
решения
маленькая (-)
очень высокая (++)
Наличие документации
много (+)
MSDN не содержит
примеров кода на pascal
(+-)
Необходимость в
будущем, ввиду
конкуренции с языками
C#,VB, Java
маленькая (–)
средняя (-)
Итого
5+/5-
7+/3-
На основании вышеприведенных данных для разработки модуля было
решено использовать продукт Delphi 10.2.
Современные базы данных — один из тех объектов в сфере
информатизации, от которых иногда требуется особенно высокое качество и
наличие возможности его оценки.
БД – база данных. Под этим термином понимается информация, которую
надо сохранить.
СУБД – система управления базой данных. Это программа, которая
предоставляет доступ внешним приложениям к базе данных, обеспечивает ее
работу.
База данных проектируется и создается для каждого конкретного
проекта, СУБД же выбирается из небольшого списка стандартных средств.
В качестве возможных вариантов рассматриваются MySQL против
Firebird.
MySQL - сервер, который работает с MYISAM и InnoDB таблицами. Как
изветсно,InnoDB, это научная работа Хейки Туури в Хельсинском универе
(1994-2000) в области высокопроизводительных технологий БД.
В серверах на Linux, mysql это практически стандарт де факто. А
Firebird, де факто, БД для Windows в небольших корпорациях стран СНГ. А
вот за границей его применяют в основном как БД накопления и хранения
данных в пользовательских приложениях удаленных сотрудников и
49
малопользовательских CRM.
Если внимательно почитать лицензию interbase , то найдем примерно
такое: не ставьте сервер в системы реального времени. MySQL же работает
нормально на больших объемах.
Когда нужно проверить период в год и собрать серьезную аналитику в
учете реального времени, конкуренцию mysql никто из бесплатных БД не
может составить.
Firebird - то что вредит но часто будет использоваться в проекте.
подходит только для простых и не глобальных решений
нет автоинкремента потому приходится создавать генератор
(использование которого аукается некоторыми весьма неприятными
последствиями). А именно в FireBird для поля введён некий генератор. т. е.,
чтобы всё-таки получить очередное уникальное значение, сначала потребуется
увеличить значение генератора. Нужно создать запрос, получить результат,
обработать его в программе, и уже с ним генерить второй запрос INSERT INTO
catalog VALUES(, 'text value');таким образом получаем два запроса к БД вместо
одного, и два обработчика на стороне клиента. Иными словами, получаем
двойные накладные расходы на каждом запросе записи.
Элементарный и наиболее часто используемый запрос выбора всех
записей таблицы типа SELECT * FROM driver WHERE id = 1 сразу возвращает
все что нам нужно и цифровые и текстовые данные,но Firebird не делает этого
-вместо ожидаемого текста возвращается идентификатор (BLOB_ID), с
помощью которого (и дополнительного запроса!) можно получить значение
поля. а если всё-таки нужно получать текст, то полю назначается другой тип:
VARCHAR(32765). Как итог накладные расходы на селект выростают в 4
раза!! По сравнению с другими БД.
А нам как раз нужно совершать огромное количество именно SELECT.
Невозможно себе позволить такие накладные расходы. БД Firebird не
подходит однозначно.
Лучшая по результатам линейных SELECT всегда была и остается
50
MySql обгоняя любые другие БД. MySql проигрывает почти всем при
выполнении сложных составных запросов, требующих промежуточных
вычислений самой БД, но в программах документооборота таких нет. По
крайне мере всегда можно согласиться в одном или двух местах на некоторое
увеличение накладных расходов, но это не будут постоянные и неоправданные
расходы при всех SELECT которые неизбежны с Firebird. Единственное
преимущество Firebird в том что на него можно возложить обработку запросов
которые имеют данные связанные между собой, но находящиеся в разных
таблицах. В нем нет нет хранимых процедур, триггеров и еще много чего. Но
все это можно сделать внутри приложения. Будет немного больше кода, но оно
с лихвой окупается малыми накладными расходами процессора, памяти,
времени обработки в конце концов.
Firebird необходим при массовой вставке записей, при работе с
индексами, файловое кэширование, коэф. сжатия записей, управление
памятью сортировок, но для документооборота это не используется.
Firebird применяется в основном для небольших и средних
встраиваемых приложений, то есть когда сервер ставится в комплекте какого-
то приложения (бухгалтерского или складско-учетного) и работает в
"невидимом" для пользователей режиме. Также можно отметить, что в
крупных компаниях Firebird в основном используется как "вспомогательная"
база данных - когда нецелесообразно ставить большую БД (с неизбежным
администратором) в небольшой филиал или удаленное подразделение, в этом
случае в качестве "заменителя" часто выбирают именно Firebird.
Оптимальным вариантом является MySQL. Данная программа не
сильно нагружает систему. Данная СУБД широко распространена, поэтому
будет не сложно найти того, кто сможет ее обслуживать
На основании вышеприведенных доводов решено в качестве СУБД
MySQL.
51
1.8.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение - совокупность технических средств,
специализированных для работы информационной системы, а кроме того
надлежащая документация на эти средства и технологические процессы[3].
Совокупность технических средств составляют:
компьютеры;
устройства сбора, накопления, обработки, передачи и вывода
информации - жесткие диски, устройства хранения данных, сканеры,
принтеры, факсимильные аппараты;
устройства передачи данных и линий связи - модемы;
эксплуатационные материалы - бумага, CD (DVD) - диски и т.п.
В нашем случае главными компонентами технического обеспечения
будут:
автоматизированные рабочие места персонала организации
Сеть интернет и локальная вычислительная сеть, которая может
состоять из сетевых устройств (маршрутизаторов, коммутаторов и т.д.), и
соединяющего их кабеля.
В качестве АРМ необходимо использовать персональные компьютеры
со следующей минимальной конфигурацией:
Частота процессора 2,8 ГЦ и выше
Оперативная память объемом 2048 или выше
·Жесткий диск 200,0 Gb или выше.
Привод DVD.
Монитор 17" или выше
ИБП APC Back-CS500VA, аналогичный или лучше.
Такая конфигурация даст возможность реализовать работу в
разрабатываемом модуле с значительной степенью надежности. Размер
оперативной памяти и жесткого диска - стандартны в настоящее время. Кроме
52
указанных элементов еще необходима сетевая карта для возможности
подключения к локальной сети предприятия, но в данный момент найти
материнскую плату без встроенной сетевой картой очень сложно. Такие
элементы, как картридер и привод DVD±RW, не являются обязательными. Их
отсутствие даже положительно влияет на сохранность конфиденциальной
информации. ИБП - в условиях постоянных перерывов в энергоснабжении -
необходимый элемент.
53
II ПРОЕКТНАЯ ЧАСТЬ
2.5. Разработка проекта автоматизации
2.5.1. Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла – структура, содержащая процессы, действия и
задачи, которые осуществляются в ходе разработки, функционирования и
сопровождения программного продукта в течение всей жизни системы, от
определения требований до завершения ее использования. Имеется несколько
моделей и стандартов, в какой-то степени регламентирующих жизненный цикл,
большая часть из них принадлежит заказному ПО (автоматизированным системам
АС, и др.) и помимо непосредственно ЖЦ регламентируют кроме того и процессы
разработки:
Custom Development Method (и, технология Oracle) по разработке прикладных
информационных систем под заказ – определенный материал, конкретизированный
вплоть до степени заготовок проектных документов, предназначенных на
применение в проектах с применением Oracle. Степень адаптивности CDM
ограничивается 3-мя моделями ЖЦ: "классическая" (учтены все без исключения
работы/задачи и этапы), "быстрая разработка" (Fast Track), "упрощенный подход",
предлагаемый в случае небольших проектов и возможности ускоренно
прототипировать приложения.
Rational Unified Process (RUP) предлагает итеративную модель разработки,
включающую четыре фазы: начало, исследование, построение и внедрение.
Прохождение через четыре ключевые фазы именуется циклом разработки, при этом
каждый цикл заканчивается генерацией версии системы.
Microsoft Solution Framework (MSF) аналогична с RUP, точно так же содержит
четыре фазы: исследование, проектирование, разработка, стабилизация, является
итерационной, подразумевает применение объектно-ориентированного
моделирования. MSF в сопоставлении с RUP в большей части нацелена на
разработку бизнес-приложений.
54
Extreme Programming (XP). Экстремальное программирование считается
наиболее новейшим из числа рассматриваемых методологий, сложилась в 1996 году.
В основе методологии командная деятельность, результативная связь между
заказчиком и исполнителем на протяжении всего проекта по созданию ИС, а
создание проводится с использованием поочередно дорабатываемых прототипов.
Главными аспектами для выбора стандарта ЖЦ будут:
актуальность и современность применяемых методов контролирования
разработки
разработка в итерационном режиме с возможностью осуществлять
контроль риски
и исполнения самого проекта на некоторых контрольных точках,
отсутствие добавочных требований по моделированию процесса разработки и
внедрения.
Резюмируя представление стандартов выше итерационными из них считаются
4 стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT не подходит, потому что основной целью его использования
“является проведения аудита и стратегического планирования ИС и IT
инфраструктуры в целом”.
Стандарт XP тоже не подходит, так как он не содержит полноценных этапов
ЖЦ, таких как выработка концепции, планирование, разработка, стабилизация,
внедрение.
Таким образом, перед выбором стоит Rup и MSF. Эти два стандарта
считаются молодыми и поддерживающими всё новейшие технологии продуктивной
разработки и контролирования их исполнения.
Ключевые характерные особенности MSF, RUP и XP объединены в таблицу
2.1. Согласно этой таблицы по ней возможно судить, что Rational Unified Process
считается хорошо сбалансированным решением для средних по размерам
коллективов разработчиков, работающих с применением продуктов и технологий
компании Rational.
Extreme Programming хорошо подойдет для проектных групп небольшого
размера и для малых систем с зачастую модифицируемыми требованиями. Основная
трудность XP - сопровождение. В случае текучки сотрудников в коллективе
55
разработчиков существенная доля проектных данных может быть утрачена из-за
почти отсутствующей документации. В таблице 2.1 показаны ключевые
характеристики Жизненного цикла ИС
Таблица 2.1
Технологии MSF, RUP и XP
Технология
Лучший
размер
команды
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство
модификации и
сопровождения
Rational
Unified
Process
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
Microsoft
Solutions
Framework
3 - 20 чел.
адаптируема
любые
Удобно
(MSF+MOF)
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
конкретных
участников
коллектива)
Microsoft Solutions Framework является наиболее сбалансированной
технологией, ориентированной на проектные группы малых и средних размеров.
Разрабатываемая ИС считается небольшой. Помимо этого главным
преимуществом MSF считается итерационная модель одновременно с уточняющими
вехами (аналог каскадной модели). То есть, реализация MSF предприняла попытку
совместить каскадную и итерационную модель разработки и внедрения ПО.
По описанным выше преимуществам, был выбран стандарт MSF как наиболее
гибкий и удобный для реализации ИС.
Этапы разработки АИС показаны в таблице 2.2
56
Таблица 2.2
Этапы разработки АИС
Этап проекта
Начало
Длительность
Конец
Фаза выработки концепции
Изучение и анализ предметной области
15.03.2019
3
19.11.2018
Изучение и анализ области внедрения
20. 03.2019
3
22.11.2018
Фаза планирования
Составление технического задания
25. 03.2019
4
26.11.2018
Фаза разработки
Построение концептуальной модели ИС
29. 03.2019
5
01.12.2018
Описание входных и выходных данных
05.04.2019
7
08.12.2018
Разработка структур данных
16. 04.2019
8
16.12.2018
Разработка технического проекта
26. 04.2019
10
26.12.2018
Написание программ, модулей утилит
10. 05.2019
10
05.01.2019
Фаза стабилизации
Отладка
24. 05.2019
7
12.01.2019
Тестирование
04. 06.2019
5
17.01.2019
Разработка документации
11. 06.2019
2
19.01.2019
Фаза внедрения
Внедрение
13. 06.2019
7
26.01.2019
Итого
71
дней
Проектная группа состоит из 1 человека.
Результатом фазы выработки концепции было следующее
Формулировка видения. Разработанная система ведения документации и
отчетности позволит предприятию повысить эффективность учета выполненных
платежных поручений и анализа их выполнения.
Цели системы:
работать с клиентами предприятия;
Задачи системы:
работать с базой данных предприятия;
57
учитывать платежные поручения
В нашем случае на системы накладываются следующие ограничения:
система не является распределенной;
интерфейс системы представлен в одном окне;
система должна наглядно демонстрировать формы и способы
хранения и взаимодействия данных.
Функциональность решения
Хранилище находится в оперативной памяти
Добавление клиентов по нажатию кнопки
Проверка корректности введены данных
o Проверка существования платежного поручения с введенным
номером
Создание визуальной формы для отображения данных клиентов
Добавление платежного поручения
Проверка корректности введены данных
o Проверка наличия данных
Добавление в визуальные формы поручений информации о
добавленных поручениях
Удаление поручений
Удаление всех сопутствующих данных
Фаза планирования
Результатом данной фазы является техническое задание и план разработки
ПО, приведенный в таблице 2.2.
Фаза разработки
Результатом данной фазы явилась разработанная концептуальная модель базы
данных с указанием сущности и атрибутов каждой сущности. Приведены входные и
выходные документы. После этого разработано технический проект, написана
программа.
Фаза стабилизации
Во время фазы стабилизации было проведено тестирование разработанного