1.2. Обзор существующих решений
Говоря о представленных на рынке технологических платформах для реализации корпоративных интранет и интернет-порталов, прежде всего, стоит упомянуть продукты крупных производителей ПО. Наиболее известными из таких продуктов являются
Oracle WebCenter от компании Oracle;
WebSphere Portal компании IBM;
SharePoint Portal от Microsoft;
Alfresco;
SAP Enterprise Portal от SAP.
Эти «гиганты» портальных технологий занимают значительную долю рынка, однако проекты, где применяется такая «тяжелая артиллерия» чаще всего характеризуются огромным масштабом (см. Табл 1.).
-
Название
Цена
Oracle WebCenter
$50 000 за каждый процессор сервера
IBM WebSphere Portal Server
$240 000
Microsoft SharePoint
$20 000
1C: Битрикс
$7 000
Табл 1. Цены на готовые решения для корпоративных порталов
Вследствие высокой стоимости и сложности внедрения "тяжелых" решений, в нише интранет решений для небольших компаний доминируют легкие, комбинированные веб-решения. Таким образом, очевидно, что перед заказчиками и исполнителями проектов по внедрению корпоративных интранет-порталов встает сложная задача выбора платформы приложения. Какие же критерии стоит применять и факторы учитывать?
1.3. Этапы внедрения корпоративного портала
Каждый проект проходит через определенные этапы проектирования. Такие стадии образуют жизненный цикл разработки программной системы. Как правило, жизненный цикл начинается с формирования общего представления о разрабатываемой системе и его формализации в виде требований верхнего уровня. Завершается жизненный цикл разработки вводом системы в эксплуатацию. Однако, нужно понимать, что разработка ‑ только один из процессов, связанных с программной системой, которая также имеет свой жизненный цикл. В отличие от жизненного цикла разработки системы, жизненный цикл самой системы заканчивается выводом ее из эксплуатации и прекращением ее использования.
Любой этап жизненного цикла имеет четко определенные критерии начала и окончания. Состав этапов жизненного цикла, а также критерии, в конечном итоге определяющие последовательность этапов жизненного цикла, определяется коллективом разработчиков и/или заказчиком. В настоящее время существует несколько основных моделей жизненного цикла, которые могут быть адаптированы под реальную разработку.
Каскадный жизненный цикл
Каскадный жизненный цикл (иногда называемый водопадным) основан на постепенном увеличении степени детализации описания всей разрабатываемой системы. Каждое повышение степени детализации определяет переход к следующему состоянию разработки.
Р
ис.
1
Каскадная
модель жизненного цикла
На первом этапе составляется концептуальная структура системы, описываются общие принципы ее построения, правила взаимодействия с окружающим миром, ‑ определяются системные требования.
На втором этапе по системным требованиям составляются требования к программному обеспечению ‑ здесь основное внимание уделяется функциональности программной компоненты, программным интерфейсам. Естественно, все программные комплексы выполняются на какой-либо аппаратной платформе. Если в ходе проекта требуется также разработка аппаратной компоненты, параллельно с требованиями к программному обеспечению идет подготовка требований к аппаратному обеспечению.
На третьем этапе на основе требований к программному обеспечению составляется детальная спецификация архитектуры системы ‑ описываются разбиение системы по конкретным модулям, интерфейсы между ними, заголовки отдельных функций и т.п.
На четвертом этапе пишется программный код, соответствующий детальной спецификации, на пятом этапе выполняется тестирование ‑ проверка соответствия программного кода требованиям, определенным на предыдущих этапах.
Особенность каскадного жизненного цикла состоит в том, что переход к следующему этапу происходит только тогда, когда полностью завершены все работы предыдущего этапа. То есть сначала полностью готовятся все требования к системе, затем по ним полностью готовятся все требования к программному обеспечению, полностью разрабатывается архитектура системы и так далее до тестирования.
Естественно, что в случае достаточно больших систем такой подход себя не оправдывает. Работа на каждом этапе занимает значительное время, а внесение изменений в первичные документы либо невозможно, либо вызывает лавинообразное изменения на всех других этапах.
Как правило, используется модификация каскадной модели, допускающая возврат на любой из ранее выполненных этапов. При этом фактически возникает дополнительная процедура принятия решения.
Действительно если тесты обнаружили несоответствие реализации требованиям, то причина может крыться:
в неправильном тесте,
в ошибке кодирования (реализации),
в неверной архитектуре системы,
в некорректности требований к программному обеспечению и т.д.
Все эти случаи требуют анализа, для того чтобы принять решение о том, на какой этап жизненного цикла надо возвратиться для устранения обнаруженного несоответствия.
V-образный жизненный цикл
В качестве своеобразной "работы над ошибками" классической каскадной модели стала применяться модель жизненного цикла, содержащая процессы двух видов ‑ основные процессы разработки, аналогичные процессам каскадной модели, и процессы верификации, представляющие собой цепь обратной связи по отношению к основным процессам.
Р
ис.
1.2.
V-образный жизненный цикл
Таким образом, в конце каждого этапа жизненного цикла разработки, а зачастую и в процессе выполнения этапа, осуществляется проверка взаимной корректности требований различных уровней. Данная модель позволяет более оперативно проверять корректность разработки, однако, как и в каскадной модели, предполагается, что на каждом этапе разрабатываются документы, описывающие поведение всей системы в целом.