57
1.4.2. Обоснование проектных решений по программному обеспечению
С самого начала работы над проектом я пришел к выводу что для работы
необходим некоторый набор программного обеспечения. Сервер с СУБД, на
котором работает база данных MariaDB
47
. Это перспективный форк
48
проекта
MySQL. Возможностей MySQL более чем достаточно. Однако, в планах
развития есть использование PostgreSQL
49
.
В качестве ОС используется Linux Fedora. Использование Fedora на
данный момент удобно в плане развертывания на существующей аппаратной
части в стадии проектирования. А в дальнейшем позволит без проблем
развернуть окружение для работы программы на ОС Linux Centos и Red Hat.
В проектировании архитектуры таблиц базы данных используется
программа MySQL Workbench.
Непосредственно программу автоматизации решено разрабатывать на
объектно-ориентированном языке Java. Графическая оболочка должна быть
основана на библиотеке Swing
50
. Обосновано это тем, что существуют планы
перевода рабочих мест пользователей на Unix операционные системы. Какое-то
продолжительное время ОС Windows и Unix будут использоваться параллельно.
Поэтому, программа должна быть кроссплатформенной.
Разработка проекта будет проводиться в IDE NetBeans и Eclipse. У каждой
свои особенности. Основной код в NetBeans, а GUI в Eclipse. У меня много
сложных таблиц в формах, а Eclipse позволит сильно ускорить разработку и
получить чистый код графической формы пригодный для дальнейшей
модификации (например, в Notepad++), в отличие от NetBeans. Такой
эксперимент успешно проведен.
47
Может выступать в качестве прозрачной замены MySQL, обладая при этом рядом расширенных
функций, включая оптимизации производительности и поставляется с набором дополнительных
движков хранилищ.
48
Ответвление. Использование кодовой базы одного программного проекта для старта другого.
49
Постоянно вбирает в себя результаты исследований ведущих мировых специалистов. Эта СУБД
выступает в роли универсального конструктора.
50
Swing — библиотека для создания графического интерфейса для программ на языке Java.
58
Для связи с базой данных отладки и сборки проекта, в NetBeans должен
быть подключен драйвер JDBC
51
.
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение – это комплекс технических средств,
предназначенных для обеспечения работы информационной системы, а также
соответствующая документация на эти средства и технологические процессы.
Требования к техническому обеспечению в этом проекте совсем
небольшие. Они сформированы главным образом возможностью запустить
современную операционную систему. Выбран Linux. Это эффективно,
экономично и не требовательно к аппаратным ресурсам.
Но это то что касается скомпилированной и отлаженной программы. А
при разработке, иногда было некомфортно работать на компьютере с 12 ГБ
оперативной памяти и процессором Intel Core i5-2320. Так случилось, когда
оказались запущены одновременно три IDE и браузер с 30 вкладками
технической документации. Процессор сильно загрузился, но справился. Узким
местом оказался HDD
52
. Разработчикам стоит иметь ввиду что порождается
много сотен процессов, обращающихся к диску. С такой нагрузкой может
справиться сейчас SSD
53
накопитель.
Требования к рабочему месту оператора сильно проще. Необходимо
установить программное обеспечение JVM
54
для запуска виртуальной машины
Java и предусмотреть разрешение экрана монитора не менее 1366х768,
желательно 1440x900 или более. Работать при меньшем разрешении будет
некомфортно. Работать с длинными списками табличных форм неудобно.
51
MySQL Connector/J is the official JDBC driver for MySQL. https://dev.mysql.com/downloads/connector/j/.
52
Жесткий диск использующий магнитные пластины для хранения данных.
53
Накопитель использующий микросхемы флэш-памяти.
54
Java Virtual Machine — виртуальная машина Java — основная часть исполняющей системы Java , так
называемой Java Runtime Environment (JRE).
59
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Интервал времени от момента возникновения потребности до завершения
проекта называется «жизненным циклом проекта». Жизненный цикл проекта —
это все что касается технических работ и их финансового обеспечения.
Проектный цикл состоит из фаз: концепция, разработка и планирование,
осуществление, завершение.
Следование стандартам оформления проектов автоматизации имеет строго
положительное значение. Даже если разработчики – люди с разным опытом и
привычные к разным методикам. Методика – это шаблон. Возможно в нем не
будет достаточной гибкости. Зато нет необходимости придумывать снова и
снова ключевые точки контроля состояния проекта. Мала вероятность упустить
что-то важное. А добавить отсутствующую важную веху, ничто не мешает.
Достаточно добавить свой подраздел. На крупных проектах так и поступают.
Стандарты, касающиеся жизненного цикла, бывают: Российский
государственный ГОСТ 34, международные ISO, фирменные коммерческие
(Oracle
55
).
Выбор стандарта жизненного цикла с одной стороны обусловлен
инструментарием, используемым в разработке. С другой – принятыми
договорными отношениями между участниками.
Важное свойство - степень адаптивности. Так Oracle CDM ограничена.
Нельзя добавить или удалить задачу. Она ориентирована на работу с
инструментарием моделирования и разработки самой Oracle.
ISO 12207 - слишком общий. Степень адаптивности высокая. Возможно
исключить процессы, виды деятельности и задачи, не применимые в конкретном
проекте. Основной плюс стандарта в том, что он описывает набор задач,
критериев оценки, др. характеристик, дающих всесторонний охват возможных
55
Oracle CDM. Возникла как развитие версии Oracle CASE-Method.
60
проектных ситуаций. Стандарт содержит мало описаний, направленных на
проектирование баз данных.
ГОСТ 34 задумывался как универсальный всеобъемлющий комплекс
взаимосвязанных межотраслевых стандартов. Комплекс рассчитан на
взаимодействие заказчика и разработчика. Аналогично ISO 12207
предусмотрено, что заказчик сам может разрабатывать автоматизированную
систему для себя. ГОСТ 34 в большей степени уделяет внимание содержанию
проектных документов в сравнении с ISO 12207. Состав: ГОСТ 34.601-90
(Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические
указания РД 50-34.698-90 (Требования к содержанию документов). ГОСТ
является методической и справочной поддержкой.
Согласно ГОСТ 34.601-90 «Стадии создания» - допускается исключать
стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять
стадии "Технический проект" и "Рабочая документация" в одну стадию
"Технорабочий проект". В зависимости от специфики создаваемых АС и условий
их создания допускается выполнять отдельные этапы работ до завершения
предшествующих стадий, параллельное во времени выполнение этапов работ,
включение новых этапов работ.
Поскольку я систему разрабатываю самостоятельно для нужд своей
организации, и отчитываюсь непосредственно перед техническим директором,
то, фактически, взаимодействуют технический отдел и генеральный директор.
Также я разрабатываю базу данных. Ни один из стандартов не подходит
идеально, это и необязательно. Выбираю то что проще адаптировать и что
полнее описывает задачу. В данном случае выбор делаю в пользу ГОСТ 34.
Порядок выполнения стадий во время разработки, критерии выделения
отдельных стадий работ, моменты перехода между стадиями – называются
моделями жизненного цикла. Выделяют:
каскадная модель – модель «сверху вниз», однозначно
сформированные этапы, упорядоченные во времени. Следующий
этап не начинается пока не завершится предыдущий;
61
инкрементная модель – поэтапная модель (как в предыдущей
модели) с линейным приращением последовательности стадий.
Инкрементная – значит запланировано улучшение проекта.
Появляются улучшенные версии. Важное отличие в том, что
результат виден до окончания работ над проектом. Применяется
при разработке сложных систем;
спиральная модель – создается последовательность версий. В
начале определены не все требования, а только важные. Реализация
системы идет поэтапно, с контролем на каждом этапе. Позволяет
увидеть в какую сторону движется разработка. Модель также
позволяет показать пользователю готовый продукт до окончания
разработки. Требования уточняются по ходу разработки.
Мне больше подходит предсказуемая и однозначная каскадная модель.
Стадию эскизного проекта решено исключить, а стадии 5 и 6 объединить.
Формирую этапы и стадии согласно ГОСТ 34.601-90 Стадии создания АС.
62
Таблица 6
СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС
1. ФТ -
Формирование
требований к
АС.
1.1. Обследование объекта и обоснование необходимости создания
АС;
1.2. Формирование требований пользователя к АС;
1.3. Оформление отчета о выполненной работе и заявки на разработку
АС (тактико-технического задания);
2. РК -
Разработка
концепции АС.
2.1. Изучение объекта;
2.2. Проведение необходимых научно-исследовательских работ;
2.3. Разработка вариантов концепции АС, удовлетворяющей
требованиям пользователя
2.4. Оформление отчета о выполненной работе;
3. ТЗ -
Техническое
создание АС.
3.1. Разработка и утверждение технического задания на задание.
4. ТРП -
Технорабочий
проект.
4.1. Разработка проектных решений по системе и ее частям;
4.2. Разработка документации на АС и ее части;
4.3. Разработка заданий на проектирование в смежных частях проекта
объекта автоматизации;
4.4. Разработка или адаптация программ.
5. ВД - Ввод в
действие.
5.1. Подготовка объекта автоматизации к вводу АС в действие;
5.2. Подготовка персонала;
5.3. Комплектация АС поставляемыми изделиями (программными и
техническими средствами, программно-техническими комплексами,
информационными изделиями);
5.4. Пуско-наладочные работы;
5.5. Проведение предварительных испытаний;
5.6. Проведение опытной эксплуатации;
5.7. Проведение приемочных испытаний.
6. СП -
Сопровождение
АС.
6.1. Выполнение работ в соответствии с гарантийными
обязательствами;
6.2. Послегарантийное обслуживание.
Этап 1.1 "Обследование объекта и обоснование необходимости создания
АС".
Цель этапа - сбор данных об объекте автоматизации и осуществляемых
видах деятельности.
Ключевые участники - организация-заказчик (пользователь). Это
соответственно, разработчик этого проекта, я как исполнитель проекта.
63
Требования к входной информации: фактические данные (стандарты
компании, шаблоны форм отчетов, годовые отчеты);
Получаемые результаты:
o оценка качества функционирования объекта и осуществляемых видах
деятельности, выявление проблем, решение которых возможно
средствами автоматизации;
o оценка (технико-экономической, социальной и т.п.) целесообразности
создания АС.
Этап 1.2 "Формирование требований пользователя к АС".
Цель этапа - подготовка исходных данных для формирования требований к
АС (характеристика объекта автоматизации, описание требований к системе,
ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию,
эффект, ожидаемый от системы, условия создания и функционирования
системы).
Ключевой участник – разработчик и исполнитель проекта.
В результате получаем формулировку и оформление требований пользователя к
АС.
Этап 1.3 "Оформление отчета о выполненной работе и заявки на
разработку АС (тактико-технического задания)".
Целью является оформление отчета о выполненных работах на данной стадии.
Ключевой участник – разработчик и исполнитель проекта.
В результате оформляется заявка на разработку АС (тактико-технического
задания).
Этапы 2.1 "Изучение объекта" и 2.2 "Проведение необходимых научно-
исследовательских работ".
Целью является проведение разработчиком детального изучения объекта
автоматизации и необходимые научно-исследовательские работы (НИР),
64
связанные с поиском путей и оценкой возможности реализации требований
пользователя.
Ключевой участник – разработчик и исполнитель проекта.
В результате оформляют и утверждают отчеты о НИР.
Этап 2.3 "Разработка вариантов концепции АС и выбор варианта
концепции АС, удовлетворяющего требованиям пользователя".
Цели:
провести разработку альтернативных вариантов концепции, создаваемой
АС и планов их реализации;
оценку необходимых ресурсов на их реализацию и обеспечение
функционирования;
оценку преимуществ и недостатков каждого варианта; сопоставление
требований пользователя и характеристик предлагаемой системы и выбор
оптимального варианта;
определение порядка оценки качества и условий приемки системы;
оценку эффектов, получаемых от системы.
Ключевой участник – разработчик и исполнитель проекта.
Этап 2.4 "Оформление отчета о выполненной работе".
Цель - подготовить данные содержащие описание выполненных работ на стадии;
Ключевой участник – разработчик и исполнитель проекта.
Результат - оформление отчета, содержащего описание и обоснование
предлагаемого варианта концепции системы.
Этап 3.1 "Разработка и утверждение технического задания на создание
АС".
Цель - провести разработку ТЗ, согласовать и утвердить техническое задание на
АС.
Ключевой участник – разработчик и исполнитель проекта.
65
В результате - оформить ТЗ.
Этап 4.1 "Разработка проектных решений по системе и ее частям".
Цель - разработка решений по системе и ее частям, функционально-
алгоритмической структуре системы, по функциям персонала и
организационной структуре, по структуре технических средств, по алгоритмам
решений задач и применяемым языкам, по организации и ведению
информационной базы, системе классификации и кодирования информации, по
программному обеспечению.
Ключевой участник – разработчик и исполнитель проекта.
Этап 4.2 "Разработка документации на АС и ее части".
Цель - разработка рабочей документации, содержащей все необходимые и
достаточные сведения для обеспечения выполнения работ по вводу АС в
действие и ее эксплуатации, а также для поддерживания уровня
эксплуатационных характеристик (качества) системы в соответствии с
принятыми проектными решениями.
Ключевой участник – разработчик и исполнитель проекта.
Результат - оформление, согласование и утверждение. Виды документов - по
ГОСТ 34.201.
Этап 4.3 "Разработка заданий на проектирование в смежных частях
проекта объекта автоматизации".
Цель - разработка, согласование и утверждение заданий на проектирование
в смежных частях проекта объекта автоматизации, связанных с созданием АС.
Ключевой участник – разработчик и исполнитель проекта.
Результат – оформление задания.
Этап 4.4 "Разработка программ".
Цель - разработка программ и программных средств системы.
Ключевой участник – разработчик и исполнитель проекта.
66
Этап 5.1 "Подготовка объекта автоматизации к вводу АС в действие".
Цель этапа - провести работы по организационной подготовке объекта
автоматизации к вводу АС в действие, в том числе:
выбрать и согласовать подсеть локальной сети, в которой будет работать
внедряемое ПО;
согласовать тип и разрядность устанавливаемой на сервер операционной
системы;
выбрать и согласовать IP адреса рабочих мест с которых будут обращения
к серверу баз данных;
написать скрипт для настройки политики доступа на сервере баз данных;
согласовать выделение места на сервере с виртуальными машинами под
внедряемую ОС Linux с ПО MySQL сервер.
Существуют четыре стратегии внедрения новой системы:
Параллельная – одновременно с функционирующей старой вводится
новая;
Скачек – когда выбирается момент, когда старую систему выключают
и начинают запускать новую;
Узкое место – выполняется очень критичная, но малая по объему часть
работ, вмешательство серьезное, но кратковременное;
Пилотный проект – стратегия скачка, примененная к опытным
процессам.
Скачек не подойдет по причине того, что нет времени остановить процессы и
заниматься внедрением нового.
Узкое место по определению невозможно. Нельзя выделить критичную часть
работ.
Как и скачек, не позволяет высвободить время для внедрения пилотного
проекта.
Я выбираю параллельную стратегию. Потому как, пока я не соединю все
накопленные данные (даже за предыдущие года, т.к. мне нужны данные для