42
Таблица 1.3
Требования к ресурсам со стороны технического обеспечения
Уровень системы
Требование к техническому обеспечению
Siebel Gateway Name Server
3.0 GHz dual core Intel Xeon processors and 2 GB of
RAM and 2 4 GB HDD(SSD)
Siebel Server
3.4 GHz dual core Intel Xeon processors and 3.25 GB
of RAM and 2 8 GB HDD(SSD)
Web Server
3.0 GHz dual core Intel Xeon processors and 2 GB of
RAM and 2 1 GB HDD(SSD)
Database Server
В зависимости от выбранной БД. В случае Oracle
11gR2:
RAM: 4 GB
Минимальный объем на диске для СУБД: 4.76 GB
CPU: 3.0 GHz
Следует отметить, что это минимальные системные требования, которые
необходимы для запуска системы. Реальные требования рассчитываются из
количества пользовательских компонент х1.5, что означает: 2х1.5х«требование»,
т.к. в нашем случае будет 2 пользовательские компоненты: дополнительный
офис и контакт центр.
43
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Процессы жизненного цикла проекта автоматизации
В период, когда ИТ-общество пришло ко мнению, что необходимо внести
изменения в процесс разработки программ, при котором использовались
устаревшие методы, появляется понятие жизненного цикла программного
обеспечения (далее - жизненный цикл ПО).
Концепции жизненного цикла появлялись в процессе поиска подходящих
для него моделей. Основные причины, обуславливающие поиск таковых
моделей выделены в таблице. Далее будут выделены основные модели
жизненного цикла ПО.
Среди основных моделей жизненного цикла ПО принято выделять:
Общепринятую модель;
Классическую итерационную модель;
Каскадную модель
Общепринятая модель (см. рисунок 2.1). Состоит из 2 фаз:
1. разработка,
2. сопровождение.
Рис. 2.1 Общепринятая модель жизненного цикла программного обеспечения
44
Разберем более подробно этапы каждой из фаз.
Разработка:
1. Постановка задач и определение требований. При определении
требований описывается общий пул задач, отражающих функции системы и ее
ограничения. Данный процесс также применяется и для разработки
нетрадиционных приложений. Описанные задачи и требования согласуются с
заказчиком.
2. Спецификация системы в соответствии с требованиями.
Выдвигаемые заказчиком требования фиксируются в виде спецификаций
системы. Спецификация отражает информацию о том, что должна делать
система, а не как она будет реализована. Все требования перед реализацией
проверяются на непротиворечивость, полноту, соответствие первоначальным
целям и однозначность. Главная задача этапа - логически выстроить описание
программы, понятной всем заинтересованным сторонам: заказчикам,
исполнителям и пользователям системы.
3. Проектирование. На этом этапе происходит последовательная
декомпозиция системы для понимания, как ее реализовать. Декомпозиция
производится до тех пор, пока не получатся очевидно реализуемые модули или
процедуры.
4. Реализация или кодирование. Каждый модуль, полученный на
предыдущем этапе, программируется на определенном языке, соответствующем
языке, подходящем для приложения.
5. Тестирование и ввод в эксплуатация. Разработанные модули передаются
на тестирование и в случае положительного результата передаются в качестве
единой системы в эксплуатацию.
После этого начинается следующая фаза - фаза эксплуатации и
сопровождения.
При эксплуатации системы проводятся все действия, позволяющие
нормально функционировать разработанной системе. При этом могут быть
выявлены ошибки, не проявившиеся при тестировании, осуществлен поиск
причин их возникновения и устранение. В этот момент производится адаптация
45
разработанной системы к окружающей среде. Как правило, на эту фазу
расходуется наибольшая часть средств.
Тем не менее, в некоторых случаях разработчики не придерживаются
четкого алгоритма данного метода, например, когда разрабатывается программа
с четко поставленной целью.
Классическая итерационная модель.
Классическая итерационная модель отличается от общепринятой тем, что
только простые и понятные задачи проходят каждый этап без возврата и повтора
предыдущих шагов технологического процесса (итераций). При написании кода
может выясниться, что разработка некоторых функций чрезвычайно велики и не
могут быть эффективны, из-за чего возникает противоречие с
производительностью, описанной в требованиях. В случае разработки больших
нетрадиционных систем необходимость возврата к предыдущим итерациям
возникает регулярно, что вызвано ошибками или неточностями на предыдущих
шагах, а также ввиду постоянно меняющихся внешних требований.
Основные мотивы классической итерационной модели жизненного
цикла представлены на рисунке 2.2, где стрелки, ведущие наверх, показывают
возврат к более ранним шагам.
Рис. 2.2 Классическая итерационная модель
Несмотря на возможность возвратов, классическая итерационная модель
имеет серьезный недостаток. Помимо того, что программные разработки ведутся
46
без опоры на ООП, при возврате на какую-либо итерацию всегда необходимо
осуществлять проверку того, что было сделано до этого и считалось готовым.
При использовании ООП происходит отказ от завершения этапов и фаз.
Здесь распределяется наращивание функциональности, а также интерфейсных
возможностей по итерациям, что ослабляет требования о переделывании уже
сделанной работы.
Для сложной системы, разумеется, требуются новые модели жизненного
цикла, способных отразить специфические особенности, перечисленными ранее.
Далее мы рассмотрим варианты традиционных моделей ЖЦ.
Обзор начнем с каскадной модели. Каскадную модель можно считать
одной из самых строгих разновидностей классической модели. Это объясняется
тем, что при ее реализации используются методы, позволяющие свести к
минимуму возвраты к предыдущим итерациям.
Основными чертами рассматриваемой модели являются:
проверка результата при завершении каждой итерацией (как и в
классической модели), что позволяет своевременно устранить большее
количество проблем, имеющих отношение к разработке системы;
циклическое повторение пройденных этапов.
При использовании каскадной модели исполнители концентрируются на
управлении качеством ПО.
На рисунке 2.3 отражена схема каскадной модели в качестве модификации
классической итерационной модели. Действия, указанные на сером фоне,
обозначают завершающий этап в рамках каждого соответствующего блока.
Стоит отметить, что тестировании не выделено в отдельный этап. Оно является
лишь порогом, проходя который, этап можно считать завершенным, как и при
других подобных действиях.
47
Рис. 2.3 Схема каскадной модели
Как видно на схеме, в конце этапа определения системных требований
должны быть сформированы специальные документы - обзоры, включающие в
себя описание требований (функциональных) системы, а подтверждением
выполнения всех указанных требований является спецификация требований к
программам. Это подтверждение должно быть также на первом этапе, когда
определены все требования. Этот момент демонстрирует то, что требования
должны быть в обязательном порядке согласованы с заказчиком.
Верификация является результатом проектирования. При ее выполнении
осуществляется проверка корректности выбранной структуры системы и
реализационных механизмов отвечают заявленным в спецификации
требованиям, т.е. выполнимы.
При реализации ведется контроль с помощью тестирования компонент.
После интеграции компонент в систему и комплексной отладки проводится
аттестация. Под аттестацией понимается проверка реализованных функций
системы, фиксация ограничений реализации, их описание и т.д.
48
Затем в ходе эксплуатации и сопровождения производится
переаттестация.
Все перечисленные ранее проверки могут возвращать разработчиков
системы к повторному проведению той или иной итерации, как показывают
стрелки на рисунке 2.3. Подчеркнем, что каскадная модель создана для
снижения уровня возвратов к предыдущим шагам за счет ужесточения проверок.
При таком подходе удается избежать возвратов сразу на несколько этапов. Такой
метод используется в строгой каскадной модели, изображенной на рисунке 2.4.
Рис. 2.4 Строгая каскадная модель
В этой модели ошибки на ранних этапах исправляются несколько иным
способом. Как показано на схеме, в качестве задания на разработку разработчик
получает результат предыдущего этапа, прошедший проверку. В идеальном
случае разработчики вообще не должны знать о ранних этапах. При выполнении
задания на разработку могут помешать следующие причины:
1. противоречивость требований;
49
2. отсутствие выработанных критериев для выбора одного из
предложенных вариантов решения.
Это пример ошибок задания (ошибки предыдущего этапа). Для их
исправления возобновляются работы предыдущего этапа. Тогда или ошибки
устраняются, и задание для разработки снова передается разработчику, или
констатируется факт невозможности ликвидации ошибок, что можно отнести к
ошибке предыдущих этапов.
В строгой каскадной модели стоит отметить два важных момента ЖЦ;
1. существование точного разделения работ, заданий, инициатив,
ответственных за переход от одного этапа к другому;
2. циклы между соседними этапами довольно малы, что позволяет
достигать компромиссное задание.
Строгая каскадная модель фиксирует два важных момента жизненного
цикла:
точное разделение работ, заданий и ответственности разработчиков
этапов и тех, кто, проверяя работы, инициирует переход к следующему этапу;
малые циклы между соседними этапами, в результате которых до-
стигается компромиссное задание.
Модель фаз-функции
В модели фаз-функции в отличии от предыдущих моделей ЖЦ
накладываются контрольные точки и функции, защищающие проект в рамках
его организации и времени, что позволяет поддерживать функции менеджера.
Наглядно эта модель, иначе именуемая как модель Гантера, представлена в виде
матрицы. Модель Гантера имеет 2 измерения:
1. Фазовое (отражает этапы выполнения, а также соответствующие им
события);
2. Функциональное (отражает функции, касающиеся организации,
которые реализуются в ходе реализации проекта, их интенсивность в период
каждого этапа).
Особенностью модели Гантера является то, что функции, выполняемые на
одном этапе, могут продолжаться и на следующем.
50
На рисунке 2.5 можно ознакомиться с фазовым измерением модели.
Процесс разработки обозначен жирной чертой с разрывом и стрелкой,
обозначающими временное направление. Над этой чертой указываются
контрольные точки и названия событий. Контрольные точки и события служат
опорой для развития проекта в модели.
Рис. 2.5 Фазовое измерение модели фазы—функции
Жизненный цикл модели Гантера имеет перекрывающие друг друга фазы:
исследования;
анализ осуществимости;
конструирование;
программирование;
оценка;
использование.
Среди основных функций, выполняемых в течение фаз ЖЦ
разработчиками можно выделить следующие технологические функции:
планирование, разработка, обслуживание, выпуск документации, испытания,
поддержка, сопровождение. Данные функции могут отличаться содержанием и
интенсивностью в зависимости от этапа, на котором они выполняются, они
совмещаются при выполнении проекта. В случае наложения функционального
измерения модели на фазовое измерение удастся получить матрицу фаз-функций
(рис.2.6). На этом графике интенсивность выполнения тех или иных функций
отражается густотой закраски.
51
Рис. 2.6 Матрица фазы—функции модели Гантера
Организационные функции и их интенсивность могут изменяться. На это
влияет специфика проекта, особенности, а также приоритеты руководства. При
этом отметим, что в определенных случаях необходимо разграничение
моделирования и контроля. В рассматриваемой модели контрольные функции
ярко не выражены. При объектно-ориентированном программировании (далее -
ООП) роль моделирования сильно велика, для чего его переводят из методов
проектирования в технологическую функцию. Более подробно об этом речь
пойдет в следующем пункте.
В модели Гантера учитываются технологические функции в соотношении
с фазами ЖЦ, что сильно отличает ее от других “идеальных моделей”, однако в
ней отсутствует отражение итеративности в явном виде. Тем не менее,
перекрытие смежных фаз, а также выпуск документации в соответствии
событиям уже минимизируют количество возвратов к предыдущим этапам.
Таким образом, мы подошли к обсуждению ООП. В своей работе для
описания бизнес процессов я планирую пользоваться нормативами ГОСТ
Р50.1.028-2001 и ГОСТ Р 53633.0.