Дипломная работа: Автоматизация обработки заявок ООО «МОСОБЛЕИРЦ»
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
66
Возможность планирования сроков завершения всех работ и
соответствующих затрат.
Недостатками данной модели являются:
Отсутствия обратных связей между этапами;
Несоответствие реальной разработке, так как возникает потребность в
возврате к предыдущему этапу.
Таким образом, данная модель эффективна для проектов с высокими
требованиями к качеству при отсутствии жестких ограничений затрат и
графика работ.
Спиральная модель жизненного цикла допускает начало работы на
следующем этапе, не завершая предыдущего (рис. 9). Таким образом, суть
спиральной модели состоит в возможности цикличного прохождения всех
этапов жизненного цикла системы в несколько повторений, или «витков»,
каждый раз создавая новый образец и проверяя актуальность требований, по
которым он создавался. На каждом «витке» вносятся технические доработки в
интерфейс и функциональность системы. Такая гибкость позволяет использовать
модель на предприятиях любого масштаба. [12]
Рис. 9 Спиральная модель ЖЦ
67
В спиральной модели делается упор на начальные этапы жизненного цикла:
анализ требований, проектирование. На этих этапах в каждом «витке»
проверяется работоспособность технических решений, а также соблюдение
плана и функционала проекта. Каждый пройденный круг соответствует
поэтапной модели создания фрагмента или версии системы, на нем определяется
качество, планируются работы следующего витка спирали. [7]
Данная модель используется для того, чтобы как можно быстрее показать
пользователям системы работоспособный продукт, в результате чего более
очевидны требования к системе.
Преимущества спиральной модели:
накопление и повторное использование программных средств, моделей
и прототипов;
ориентация на развитие и модификацию системы в процессе ее
проектирования;
анализ риска и издержек в процессе проектирования. [7]
Недостатком спиральной модели является отсутствие регламентаций стадий
разработки. Основная проблема спирального цикла - определение момента
перехода на следующий этап. Для разрешения данной проблемы требуется
введение временных ограничений на каждый из этапов жизненного цикла.
В итоге считаю лучшим выбором каскадную модель, так как в начале
разработки можно достаточно точно и полно сформулировать все требования к
системе. Однако в качестве вариации целесообразней выбрать каскадную модель
с промежуточным контролем, чтобы предусмотреть возможность возвращения к
предыдущим этапам для внесения определенных изменений и пересмотра
отдельных вопросов.
Теперь остановимся более детально на анализе и выборе одного из
общеизвестных стандартов ЖЦ. Среди них ГОСТ 34, ISO 12207, ISO 15288,
MSF, RUP, COBIT, Oracle CDM, XP.
ГОСТ 34.601-90. Отличается высокой степенью формализации и
предполагает каскадный подход. На сегодняшний день ГОСТ многократно
68
становился основой для доработок и частичного использования в других
стандартах / методологиях и в целом в исходном виде не является
исчерпывающим как единственный источник информации для выполнения
проекта разработки / внедрения. Благодаря своей структурированности, ГОСТ
34.601-90 до сих пор служит базой для адаптации, которую можно адаптировать
к конкретным условиям деятельности предприятия. [7] Приложение к стандарту
содержит детальное описание работ, включая списки формируемых по
завершении этапа документов.
ISO/IEC 12207. В РФ был разработан и принят идентичный ISO 12207
стандарт ГОСТ Р ИСО/МЭК 12207-2010. Основной идеей разработчиков ГОСТ
12207 являлось создание единого общекорпоративного стандарта, которым было
бы возможно воспользоваться при возникновении любой задачи из тех, которые
описаны в документе. Данный ГОСТ предполагает, что процессы состоят из
этапов, для которых определены задачи (а также цели и результаты). Тем не
менее, допускается адаптация процессов к уже имеющимся стандартам
предприятия. [12]
ISO/IEC 15288. В отличие от рассмотренного ранее стандарта, ISO 15288
распространяется на системы в целом, охватывая такие их элементы. Согласно
данному стандарту, любой процесс ЖЦ может быть начат в любой момент, без
ограничения порядка использования. Имеет более высокий уровень абстракции в
сравнении с ISO 12207, так как данный стандарт не приводит ролей, конечных
результатов в виде списка выходных документов, либо же состава работ, лишь
оставаясь на уровне концепции. [4]
Microsoft Solution Framework, (MSF). Важным преимуществом MSF
является ее практическая направленность и простота. Для MSF очень важно
взаимодействие внутри проектной команды и несмотря на то, что минимальное
число ее участников официально в методологии ограничено всего тремя,
выделяются шесть основных ролей внутри команды, и связь между участником
и ролью имеет тип «многие-ко-многим». Среди шести упомянутых кластеров:
‒ управление программой (архитектурным решением);
‒ разработка (программной и технической архитектуры);
69
‒ тестирование (планирование, разработка, отчетность);
‒ управление релизами;
‒ управление требованиями заказчика (в части интерфейса решения, а также,
конечно, обучения и технической поддержки);
‒ управление продуктом.
MSF представляет собой более гибкий и универсальный подход для
внедрения других систем / программных продуктов. [12]
Rational Unified Process, (RUP). Является одним из наиболее
ориентированных на пользователя подходов. Предполагает итеративную
разработку, большое внимание к архитектуре, к потенциальным рискам и
управлению. Широкий диапазон возможностей и инструментов, предлагаемый
методологией, является общей моделью «конструктора», необходимые элементы
которого можно выбрать – и таким образом, значительно снизить стоимость и
сроки внедрения.
Control Objectives for Information and related Technology, (COBIT).
Предоставляет сохранение единого подхода к сбору, анализу информации,
подготовке выводов и заключений на всех уровнях управления, контроля и
аудита ИТ, возможность сравнения существующих ИТ процессов с лучшими
практиками.
Custom Development Method, Oracle CDM. Данная методология опирается
на использование инструментария Oracle. Все модели жизненного цикла
являются каскадными. Для различных систем CDM предусматривает три
модели жизненного цикла. При условии, что предусмотрены все этапы и работы,
выбирается «классическая» модель. В случае, если проект небольшой,
выбирается «облегченный подход», а в условиях быстрой разработки,
выбирается «Fast track».
eXtreme Programming, (XP). Основная особенность данной методологии
состоит в ее эффективности в условиях неопределенных или нечетких
требований. Методология предлагала простой дизайн, переработку кода для
контроля затрат, постоянное присутствие заказчика, разработку через тесты и
другие аспекты, выгодно отличавшие ее. [12]
70
Проанализируем основные критерии выбора стандарта жизненного цикла
системы:
Характеристика требований к проекту.
Характеристика пользователей.
Характеристика типов проекта и рисков.
Мною выбран стандарт Oracle CDM, так как данная методология опирается
на инструментарий Oracle, а в качестве сервера приложений используется
промышленный сервер приложений Oracle WebLogic server, и в качестве СУБД
используется промышленная СУБД Oracle 11G.
Согласно данной методике жизненный цикл состоит из определенных этапов
проекта и процессов, каждый из которых выполняется в течение нескольких
этапов.
Как известно, выделяются следующие этапы жизненного цикла:
1) Анализ. На данном этапе происходит формулирование детальных
требований к проектируемой системе. Для этого выполняется уточнение
требований заказчиков, которые формализуются и документируются.
Фактически на этом этапе определяется, что должна делать будущая система. В
формулировании четких целей лежит ключ к успеху всего проекта. Данные
задачи решаются системным аналитиком. Результатом данного этапа является
модель требований к системе. [7]
2) Проектирование. На данном этапе происходит преобразование требований,
полученных в результате анализа системы. Этап проектирования определяет,
каким образом система будет удовлетворять предъявленным к ней требованиям.
Менеджер проекта на данном этапе продумывает всю архитектуру ИС, а
программист выбирает язык программирования. Результатом этапа будет
построенная модель реализации, демонстрирующая, как система будет
удовлетворять предъявленным к ней требования, без описания технических
подробностей. Фактически модель реализации является развитием и уточнением
модели требований, а само проектирование является мостом между анализом и
реализацией. Конечным результатом будет схема базы данных и набор
спецификаций модулей системы. [1]
Источник: https://baza.diplomsite.ru/previewfile/1896