56
Основа сравнения
между MySQL и
Oracle
Oracle
MySQL
Тип
Это объектно-реляционная
система управления базами
данных (ORDBMS)
Это система управления
реляционными базами
данных с открытым
исходным кодом.
Стоимость
Oracle лицензирована, но
мы можем получить Express
Edition бесплатно.
Редакция Express
поставляется с очень
ограниченными
функциональными
возможностями и
рекомендуется только для
образовательных и
тестовых целей.
MySQL является
бесплатным и
лицензируется в
соответствии с GNU
General Public License.
Масштабируемость
Oracle рекомендуется для
очень крупных
развертываний.
MySQL рекомендуется
для малого и крупного
бизнеса.
Хранимая
процедура
Oracle поддерживает
хранимую процедуру,
встроенную в базу данных.
Хранимые процедуры могут
быть выполнены
независимо или вызваны
определенными событиями.
До версии 5 поддержка
хранимых процедур в
MySQL отсутствует.
Customizability
Oracle не настраивается,
поскольку является
закрытым исходным кодом.
Программист может
модифицировать MySQL
в соответствии с
индивидуальными
требованиями среды.
Продолжение таблицы 2.3
Разделение
данных
Oracle поддерживает
разделение данных.
MySQL не поддерживает
разделы данных.
Требуется сервер для
каждого набора файлов
данных.
Безопасность
Для входа в Oracle
требуется имя
пользователя, пароль и
проверка профиля.
MySQL требует только
имя пользователя,
пароль и хост. Однако
безопасность может
быть достигнута
57
дополнительными
средствами
В рамках проектируемого приложения предлагается использовать СУБД
MySQL, поскольку она бесплатная, обладает хорошим быстродействием, может
настраиваться под требования среды.
2.1.3. Обоснование проектных решений по техническому обеспечению
Поскольку разрабатывается веб-ориентированное приложение, то следует
представить минимальные требования к техническому обеспечению как сервера,
так и клиента.
Минимальные требования к серверу представлены в таблице 2.4.
Таблица 2.4
Минимальные требования к серверу
CPU
Intel Xeon QC и выше
Кол-во ядер
2
ОП
8 GB и более
Дисковая
память
Минимальные требования: 2 x 80 GB SAS RAID 1(под
систему) + 100 GB x 3 SAS RAID 5 (под базу).
Наличие модуля аварийного питания на контроллере
(Battery Backup Unit) и включенного механизма
отложенной записи (Write Back) – обязательно.
Возможно использование дисков большего объема и
единого дискового массива.
СУБД
А: Рекомендуемый вариант: Enterprise Edition Database
12c (12.1.0.2), Oracle Partitioning option.
Б: Допустимый с определёнными ограничениями вариант:
Oracle Database Standard Edition 2 12c.
ОС
любая ОС соответствующая аппаратной платформе и
сертифицированная под требуемую версию СУБД.
Минимальные требования к клиенту представлены в таблице 2.5.
Таблица 2.5
Минимальные требования к клиенту
CPU
Pentium IV 1.8 GHz
Кол-во ядер
1 (2 и более)
ОП
1 GB (Windows XP), 8GB и более (Windows 7,8) (x86-
64)
HDD
80 GB и более
Видеокарта
SVGA (должна поддерживать разрешение 1024x768,
цветовая палитра 16 бит)
58
Монитор
LCD 15» и более (должен поддерживать разрешение
1024х768)
ОС
Windows (XP, 7, 8) Professional
2.2. Разработка проекта автоматизации
2.2.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл проекта автоматизации представляет собой период
времени, который начинается с момента принятия решения о необходимости
создания программного продукта автоматизации и заканчивается в момент его
полного изъятия из эксплуатации [4].
Для облегчения проектирования, создания и выпуска качественного
программного продукта существуют различные модели жизненного цикла ПО.
Требования к проекту являются определяющими при выборе подхода к
циклу разработки.
Можно выделить такие модели ЖЦ проекта автоматизации:
каскадная или водопадная модель;
v-образная модель;
инкрементная модель;
спиральная модель;
гибкая модель;
скрам.
Рассмотрим данные модели более подробно.
Каскадная или водопадная модель (Waterfall model)
При такой модели каждая из фаз проекта проводится единожды, следуя
одна за другой. Для того чтобы начать следующую стадию, необходимо полное
завершение предыдущей (рисунок 2.5).
59
Рис. 2.5. Этапы каскадной модели
Плюсы:
все стадии проекта выполняются в строгой последовательности;
строгость этапов позволяет планировать сроки завершения всех работ и
соответствующие ресурсы (денежные и человеческие);
требования остаются неизменными в течение всего цикла.
Минусы:
сложности при формулировке четких требований и невозможность их
изменения;
тестирование начинается только с середины развития проекта;
до завершения процесса разработки пользователи не могут убедиться,
качествен ли разрабатываемый продукт.
V-образная модель (V-model)
Данная модель стала последователем каскадной модели, так как с ее
помощью можно устранить недостатки, которые были ранее.
Суть этой модели состоит в том, что процессы на всех этапах
контролируются, чтобы убедиться в возможности перехода на следующий
уровень. Уже на стадии написания требований начинается процесс тестирования
(рисунок 2.6).
60
Рис. 2.6. Этапы V-образной модели
Плюсы:
строгая этапизация;
минимизация рисков и устранение потенциальных проблем за счет того,
что тестирование появляется на самых ранних стадиях;
усовершенствованный тайм-менеджмент.
Минусы:
невозможность адаптироваться к измененным требованиям заказчика;
длительное время разработки (иногда длится до нескольких лет)
приводит к тому, что продукт может быть уже не нужен заказчику,
поскольку его потребности меняются;
нет действий, направленных на анализ рисков.
Инкрементная модель (Incremental model)
При инкрементной модели (англ. increment – увеличение, приращение)
программное обеспечение разрабатывается с линейной последовательностью
стадий, но в несколько инкрементов (версий). Таким образом, улучшение
продукта проходит запланировано все время пока жизненный цикл разработки
ПО не завершится (рисунок 2.7).
61
Рис. 2.7. Этапы инкрементной модели
Требования к системе определяются в самом начале работы, после чего
процесс разработки проводится в виде последовательности версий, каждая из
которых является законченным и работоспособным продуктом.
Плюсы:
заказчик может дать свой отзыв касательно каждой версии продукта;
есть возможность пересмотреть риски, которые связаны с затратами и
соблюдением графика;
привыкание заказчика к новой технологии происходит постепенно.
Минусы:
функциональная система должна быть полностью определена в начале
жизненного цикла для выделения итераций;
при постоянных изменениях структура системы может быть нарушена;
сроки сдачи системы могут быть затянуты из-за ограниченности
ресурсов (исполнители, финансы).
Спиральная модель (Spiral model)
В спиральной модели жизненный путь разрабатываемого продукта
изображается в виде спирали, которая, начавшись на этапе планирования,
раскручивается с прохождением каждого следующего шага. Таким образом, на
выходе из очередного витка получаем готовый протестированный прототип,
который дополняет существующую сборку. Прототип, удовлетворяющий всем
требованиям, готов к выпуску (рисунок 2.8).
62
Рис. 2.8. Этапы спиральной модели
Плюсы:
управлению рисками уделяется особое внимание;
дополнительные функции могут быть добавлены на поздних этапах;
есть возможность гибкого проектирования.
Минусы:
оценка рисков на каждом этапе является довольно затратной;
постоянные отзывы и реакция заказчика может провоцировать все
новые и новые итерации, которые могут приводить к временному
затягиванию разработки продукта;
более применима для больших проектов.
Гибкая модель (Agile model)
Представляет собой совокупность различных подходов к разработке ПО.
Включает серии подходов к разработке программного обеспечения,
ориентированных на использование итеративной разработки (в Scrum итерации
называются спринтами), динамическое формирование требований и обеспечение
их реализации в результате постоянного взаимодействия внутри
самоорганизующихся рабочих групп, состоящих из специалистов различного
профиля. Отдельная итерация представляет собой миниатюрный программный
проект. Одной из основных идей Agile, является взаимодействие внутри команды
и с заказчиком лицом к лицу (рисунок 2.9).
63
Рис. 2.9. Этапы гибкой модели
Плюсы:
быстрое принятие решений за счет постоянных коммуникаций;
минимизация рисков;
облегченная работа с документацией.
Минусы:
большое количество митингов и бесед, что может увеличить время
разработки продукта;
сложно планировать процессы, так как требования постоянно меняются;
редко используется для реализации больших проектов.
Скрам (Scrum)
Скрам – это гибкая модель разработки ПО, в которой делается акцент на
качественном контроле процесса разработки (рисунок 2.10).
Рис. 2.10. Этапы модели Скрам
64
Роли в методологии (Scrum Master, Product Owner, Team) позволяют четко
распределить обязанности в процессе разработки. За успех Scrum в проекте
отвечает Scrum Master и является связующим звеном между менеджментом и
командой. За разработку продукта отвечает Product Owner, который также ставит
задачи и принимает окончательные решения для команды.
Команда – это единое целое, в ней результаты оцениваются не по каждому
отдельному участнику, а по тому, что получается в итоге у всех.
Спринты в данной методологии длятся от 1 до 4 недель. После каждого спринта
команда предоставляет вариант законченного продукта.
Плюсы:
быстрая обратная связь от специалистов в разных сферах (дизайнеров,
архитекторов, тестировщиков и пр.);
благодаря вовлеченности тестировщика в работу происходит быстрое
добавление нового функционала и быстрый запуск продукта с
минимальными функциями;
самостоятельная и самоорганизованная команда.
Минусы:
некоторые люди, знающие продукт, становятся незаменимыми, так как
документация не предоставляется в процессе разработки;
невозможно спланировать точную дату завершения, так как всё
уточняется по результатам предыдущего спринта;
заказчики не всегда могут понять суть данной методологии и
необходимо потратить время на «ликбез».
Таким образом, существует множество вариантов моделей разработки ПО.
Выбор того или иного варианта зависит от особенностей и требований проекта,
моделей оплаты. Частично методологии пересекаются и похожи друг на друга, но
тем не менее, каждая находит своих почитателей.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в
некоторых случаях и процессы разработки.
Среди наиболее известных стандартов можно выделить следующие [5]:
65
ГОСТ 34.601-90 – распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте
содержится описание содержания работ на каждом этапе. Стадии и
этапы работы, закрепленные в стандарте, в большей степени
соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207:1995 – стандарт на процессы и организацию жизненного
цикла. Распространяется на все виды заказного ПО. Стандарт не
содержит описания фаз, стадий и этапов.
Custom Development Method (методика Oracle) по разработке
прикладных информационных систем – технологический материал,
детализированный до уровня заготовок проектных документов,
рассчитанных на использование в проектах с применением Oracle.
Применяется CDM для классической модели ЖЦ (предусмотрены все
работы/задачи и этапы), а также для технологий «быстрой разработки»
(Fast Track) или «облегченного подхода», рекомендуемых в случае
малых проектов.
В качестве стандарта жизненного цикла проекта автоматизации
предлагается ГОСТ 34.601-90 [1], который предполагает использование
каскадной модели жизненного цикла.
Согласно ГОСТ 34.601-90 выделяют такие этапы жизненного
цикла ИС:
Формирование требований к ИС.
Разработка концепции ИС.
Техническое задание.
Эскизный проект.
Технический проект.
Рабочая документация.
Ввод в действие.
Сопровождение ИС.
Существуют следующие основные стратегии внедрения системы: