Методология проектирования информационных систем. Проектирование информационных систем стадии проектирования информационных систем

Требования к технологиям разработки ИС.

Фазы и этапы программного проекта.

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

Формирование требований к АС

1. Обследование объекта и обоснование необходимости создания АС

   Формирование требований пользователя к АС

   Оформление отчета о выполнении работ и заявки на разработку АС

Разработка концепции АС

1. Изучение объекта

   Проведение необходимых научно-исследовательских работ

   Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

   Оформление отчета о проделанной работе

Техническое задание

1. Разработка и утверждение технического задания на создание АС

Эскизный проект

1. Разработка предварительных проектных решений по системе и ее частям

Технический проект

1. Разработка проектных решений по системе и ее частям

   Разработка документации на АС и ее части

   Разработка и оформление документации на поставку комплектующих изделий

   Разработка заданий на проектирование в смежных частях проекта

Рабочая документация

1. Разработка рабочей документации на АС и ее части

   Разработка и адаптация программ

Ввод в действие

1. Подготовка объекта автоматизации

   Подготовка персонала

   Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

   Строительно-монтажные работы

   Пусконаладочные работы

   Проведение предварительных испытаний

   Проведение опытной эксплуатации

   Проведение приемочных испытаний

Сопровождение АС.

1. Выполнение работ в соответствии с гарантийными обязательствами

   Послегарантийное обслуживание

Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

Данный стандарт не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели.

Жизненный цикл программного проекта.

Стандарт группирует различные виды деятельности, которые могут выполняться в течение жизненного цикла программных систем, в семь групп процессов. Каждый из процессов жизненного цикла в пределах этих групп описывается в терминах цели и желаемых выходов, списков действий и задач, которые необходимо выполнять для достижения этих результатов.

процессы соглашения - два процесса;

процессы организационного обеспечения проекта - пять процессов;

процессы проекта - семь процессов;

технические процессы - одиннадцать процессов;

процессы реализации программных средств - семь процессов;

процессы поддержки программных средств - восемь процессов;

процессы повторного применения программных средств - три процесса.

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

Инициирование приобретения

Подготовка заявочных предложений

Подготовка и корректировка договора

Надзор за деятельностью поставщика

Приемка и завершение работ

Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:

Формирование требований к системе

Формирование списка программных продуктов

Установление условий и соглашений

Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

Модель жизненного цикла ПО - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1. Результаты выполнения работ на каждой стадии;

   Ключевые события - точки завершения работ и принятия решений.

Стадия - часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

Каскадная модель.

Каскадная модель , в которой переход на следующий этап означает полное завершение работ на предыдущем этапе.

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ (или “водопад” ). Его основной характеристикой является разбиение всей разработки на этапы, при этом переход на следующий этап происходит только после полного завершения работ на текущем (рис. 1).

Рис. 1. Каскадная схема разработки ПО.

Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. При этом этапы работ выполняются в логичной последовательности, что позволяет планировать сроки завершения всех работ и соответствующие затраты. Этот подход хорошо зарекомендовал себя при построении ИС, для которых в начале разработки можно достаточно точно и полно сформулировать все требования и предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.

Его недостатки связаны с тем, что реальный процесс создания ПО ИС обычно не укладывается в такую жёсткую схему. Практически постоянно возникает потребность возвращаться к предыдущим этапам, уточнять или пересматривать принятые решения. В результате затягиваются сроки выполнения работы, пользователи могут вносить замечания лишь по завершению всех работ с системой. При этом модели автоматизируемого объекта могут устареть к моменту их утверждения.

Для преодоления этих проблем предложена поэтапная модель с промежуточным контролем (рис. 2).

Рис. 2. Поэтапная схема разработки ПО.

В поэтапной модели с промежуточным контролем разработка ПО ведётся итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоёмкость процесса разработки по сравнению с каскадной моделью. Время жизни каждого из этапов растягивается на весь период разработки.

Спиралевидная модель.

Затем появилась спиральная модель ЖЦ (рис. 3), в которой на начальных этапах ЖЦ осуществляются анализ и проектирование.

Рис 3. Спиральная модель.

В этой модели особое внимание уделяется начальным этапам разработки – выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание фрагмента (компонента) или версии программного продукта. На них уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

Полный жизненный цикл ИС должен поддерживаться комплексом инструментальных средств с учётом необходимости: адаптации типового проекта к различным системно-техническим платформам (техническим средствам, операционным системам и СУБД) и организационно-экономическим особенностям объектов внедрения; интеграции с существующими разработками (включая реинжиниринг приложений и конвертирование БД); обеспечения целостности проекта и контроля за его состоянием (наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность репозитария). При этом желательно обеспечить независимость от программно-аппаратной платформы и СУБД, поддержку одновременной работы групп разработчиков, открытую архитектуру и возможности экспорта/импорта.

Итерационная модель.

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки(англ. iterative and incremental development, IID ), получившей также от Т. Гилба в 70-е гг. название эволюционной модели . Также эту модель называют итеративной моделью и инкрементальной моделью .

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение - инкремент - к его возможностям, которые, следовательно, развиваются эволюционно . Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

По выражению Т. Гилба, «эволюция - прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».

Подход IID имеет и свои отрицательные стороны, которые, по сути, - обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже».

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP,MSF,XP).

Разновидности моделей.

Моделирование – представление объекта моделью для получения информации о нём путём проведения экспериментов с его моделью.

Под термином “моделирование ” обычно понимают процесс создания точного описания системы; метод познания, состоящий в создании и исследовании моделей.

Моделирование облегчает изучение объекта с целью его создания, дальнейшего преобразования и развития. Оно используется для исследования существующей системы, когда реальный эксперимент проводить нецелесообразно из-за значительных финансовых и трудовых затрат, а также при необходимости проведения анализа проектируемой системы, т.е. которая ещё физически не существует в данной организации.

Для формирования модели используются:

структурная схема объекта;

структурно-функциональная схема объекта;

алгоритмы функционирования системы;

схема расположения технических средств на объекте;

схема связи и др.

Все модели можно разбить на два больших класса: предметные (материальные) и знаковые (информационные).

Для проектирования ИС используют информационные модели , представляющие объекты и процессы в форме рисунков, схем, чертежей, таблиц, формул, текстов и т.п.

Информационная модель – это модель объекта, процесса или явления, в которой представлены информационные аспекты моделируемого объекта, процесса или явления.

Она является основой разработки моделей ИС.

Для создания описательных текстовых информационных моделей обычно используют естественные языки .

Наряду с естественными языками (русский, английский и т.д.) разработаны и используются формальные языки : системы счисления, алгебра высказываний, языки программирования и др.

Основное отличие формальных языков от естественных состоит в наличие у формальных языков не только жёстко зафиксированного алфавита, но и строгих правил грамматики и синтаксиса.

С помощью формальных языков строят информационные модели определённого типа – формально-логические модели.

При изучении нового объекта сначала обычно строится его описательная модель, затем она формализуется, те есть выражается с использованием математических формул, геометрических объектов и т.д.

Процесс построения информационных моделей с помощью формальных языков называют формализацией .

Модели, построенные с использованием математических понятий и формул, называют математическими моделями .

Модель должна учитывать как можно большее число факторов. Однако реализовать такое положение затруднительно особенно в слабоструктурируемых системах. Поэтому зачастую стремятся создавать модели достаточно простых элементов, с учётом их микро- и макросвязей. Это позволяет получать обозримые результаты. Фрагмент классификации методов моделирования представлен на рис. 3.1.

Рис. 3.1. Классификация методов моделирования.

Обычно различают реальное (материальное, предметное) и мысленное (идеализированное, концептуально-методологическое)моделирование.

Концептуально-методологическое моделирование представляет собой процесс установления соответствия реальному объекту некоторой абстрактной конструкции, позволяющий получить характеристики объекта. Данная модель, как и всякая другая, описывает реальный объект лишь с некоторой степенью приближения к действительности.

Концептуальное моделирование представляет собой структурированный процесс создания систем, состоящий из следующих этапов:

1. Проектирование,

   Программирование,

   Тестирование,

   Внедрение.

Важнейшей формой системного анализа сложных систем является имитационное моделирование на ЭВМ, описывающее процессы функционирования систем в виде алгоритмов. Его применяют в случаях, когда необходимо учесть большое разнообразие исходных данных, изучить протекание процессов в различных условиях. Процесс имитации на любом этапе может быть приостановлен для проведения научного эксперимента на вербальном (описательном) уровне, результаты которого после оценки и обработки могут быть использованы на последующих этапах имитации.

Существует нескольких методов и принципов построения информационных систем (автоматизированных ИС), среди которых можно выделить: методы “снизу-вверх” и “сверху-вниз”, принципы “дуализма”, многокомпонентности и др.

Метод “снизу-вверх” Опыт и методы работы отечественных программистов сформировались в крупных вычислительных центрах (ВЦ), основной целью которых было не создание тиражируемых продуктов, а выполнение задач конкретного учреждения. Современные руководители зачастую прибегают к нему, полагая, что им удобно иметь своих специалистов. Разработка программ “снизу-вверх”, осуществляемая квалифицированными программистами, позволяет автоматизировать, как правило, отдельные рабочие процессы.Такой метод весьма затратный и всё реже используется, особенно в малых и средних предприятиях.

Метод “сверху-вниз” Развитие коммерческих и иных современных структур послужило основанием к формированию рынка различных программных средств. Наибольшее развитие получили ИС, ориентированные на автоматизацию ведения бухгалтерского аналитического учёта и технологических процессов. В результате появились ИС, разработанные сторонними, как правило, специализированными организациями и группами специалистов “сверху”, в предположении, что одна ИС сможет удовлетворять потребности многих пользователей.

Такая идея ограничила возможности разработчиков в структуре информационных множеств БД, в использовании вариантов экранных форм, алгоритмов расчёта и, следовательно, лишила возможности принципиально расширить круг решаемых задач. Заложенные “сверху” жёсткие рамки (“общие для всех”) ограничивают возможности ИС. Стало очевидным, что для успешной реализации задач полной автоматизации организации следует менять идеологию построения автоматизированных информационных систем (АИС).

Принципы “дуализма” и многокомпонентности Развитие систем и предприятий, увеличение числа их филиалов и клиентов, повышение качества обслуживания и другое вызвали существенные изменения в разработке и функционировании АИС, в основном базирующиеся на сбалансированном сочетании двух предыдущих методов.

Новый подход ориентирован на специализированное программное обеспечение (СПО), возможность адаптации программного аппарата к практически любым условиям и различным требованиям инструктивных материалов и принятым правилам работы. Кроме того, гибкая система настроек СПО в АИС при проведении модернизации одного из компонентов позволяет не затрагивать центральную часть (ядро) АИС и другие её компоненты, что значительно повышает надёжность, продолжительность жизни ИС и обеспечивает наиболее полное выполнение требуемых функций.

Такой подход лег в основу “принципа дуализма ”. Его реализация потребовала построения АИС нового поколения в виде программных модулей, органически связанных между собой, но в то же время способных работать автономно.

Многокомпонентная система обеспечивает соблюдение основополагающего принципа построения АИС – отсутствия дублирования ввода исходных данных.

Информация по операциям, проведённым с применением одного из компонентов системы, может использоваться любым другим её компонентом. Модульность построения АИС нового поколения и принцип одноразового ввода дают возможность гибко варьировать конфигурацией этих систем. Такая структура позволяет включить в АИС нового поколения компоненты создания хранилищ данных, разделяя системы оперативного действия и системы поддержки принятия решения.

Кроме того, одно из достоинств принципа многокомпонентности , являющегося базовым при создании АИС нового поколения, состоит в возможности поэтапного внедрения ИС. На первом этапе внедрения устанавливают или заменяют уже устаревшие компоненты ИС, нуждающихся в обновлении ПО. На втором этапе происходит развитие системы с подсоединением новых компонентов и отработкой межкомпонентных связей. Возможность применения такой методики внедрения обеспечивает её достаточно простое тиражирование и адаптацию к местным условиям.

Из сказанного можно предположить, что автоматизированная информационная система нового поколения – это многокомпонентная система с распределённой базой данных.

Процессы создания моделей носят этапный характер. Основные виды моделей, типа “каскад” (“водопад”), “водоворот” и “спираль” описаны во второй главе. Возвращение к их рассмотрению связано с особенностями использования этих моделей в процессе разработки ИС.

Каскадная модель ИС состоит из последовательно выполняемых этапов. Каждый этап полностью заканчивается до того, как начнется следующий. Этапы не перекрываются во времени: следующий этап не начинается до тех пор, пока не завершится предыдущий. Возврат к предыдущим этапам не предусмотрен или всячески ограничен. Исправление ошибок происходит лишь на стадии тестирования. Результат появляется только в конце разработки ИС. Критерием появления результата является отсутствие ошибок и точное соответствие полученной ИС первоначальной её спецификации.

Поэтапная (итерационная) модель с промежуточным контролем Эта модель известна как итерационная модель или “водоворот”. В ней, так же, как и в модели “водопад” используется последовательность расположения этапов создания ИС. Но каждый следующий этап имеет обратную связь с предыдущими этапами. Исправление ошибок происходит на каждом из этапов, сразу при выявлении проблемы – промежуточный контроль . Следующий этап не начинается, пока не завершится предыдущий. При первом проходе по модели сверху вниз, как только обнаружена ошибка, осуществляется возврат к предыдущим этапам (снизу вверх), вызвавшим ошибку. Этапы оказываются растянутыми во времени. Результат появляется только в конце разработки ИС, как и в модели “водопад”.

Спиральная модель В этой модели результат появляется фактически на каждом витке спирали. Этот промежуточный результат анализируется, и выявленные недостатки ИС побуждают проведение следующего витка спирали. Таким образом последовательно конкретизируются детали проекта и в итоге выбирается и доводится до реализации обоснованный вариант. Спираль завершается тогда, когда клиент и разработчик приходят к согласию относительно полученного результата.

Автоматизированная система моделирования (АСМ) – компьютерная система, предназначенная для оказания помощи пользователю по представлению нужной ему задачи в виде определённой математической схемы, принятой в данной системе, решить задачу (провести моделирование по полученной схеме) и проанализировать результаты.

АСМ состоит из трёх основных компонент: функциональное наполнение, язык заданий и системное наполнение.

Функциональное наполнение является совокупностью конструктивных элементов (модулей), из которых составляется схема (модель).

Системное наполнение – это набор программ, отражающих специфику реализации АСМ и обеспечивающих собственно функционирование системы: трансляцию и исполнение заданий, поддержку базы знаний о предметной области и т.д.

Язык заданий (ЯЗ) служит для описания задач, вводимых в систему.

Средствами и инструментом автоматизированного проектирования и разработки информационных систем являются CASE-средства и системы (Глава1), ориентированные на поддержку разработки информационных систем.

Методики (методологии) управления ИТ-проектами (тяжеловесные, легковесные): особенности, примеры.

Методики (методологии) управления ИТ-проектами

Модели (методики, методологии) процессов разработки ПО принято классифицировать по «весу» - количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше «вес» модели.

Делятся на:

Тяжеловесные: RUP, MSF

Легковесные или agile-методики.

ГОСТы

Таблица 6

Вес модели
	Процессы рассчитаны на среднюю квалификацию исполнителей. Большая специализация исполнителей. Ниже требования к стабильности команды. Отсутствуют ограничения по объему и сложности выполняемых проектов.	Требуют существенной управленческой надстройки Более длительные стадии анализа и проектирования. Более формализованные /коммуникации. 8
	Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурациями. Упрощенные стадии анализа и проектирования, основной упор на разработку функциональности, совмещение ролей. Неформальные коммуникации.	Эффективность сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды. Объем и сложность выполняемых проектов ограничены.

ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Стандарты на разработку и сопровождение автоматизированных систем» ориентированы на последовательный подход к разработке ПО.

Разработка в соответствии с этими стандартами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ, и завершается выпуском достаточно большого числа весьма формализованных и обширных документов.

Таким образом, строгое следование этим гостам не только приводит к водопадному подходу, но и требует очень высокой степени формализованности разработки.

На основе этих стандартов разрабатываются программные системы по госзаказам в России.

В середине 80-х годов 20-го столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения.

Модель определяет 5уровней зрелости процесса разработки ПО:

Начальный - процесс разработки носит хаотический характер. Определены лишь немногие из процессов, и успех проектов зависит от конкретных исполнителей.

Повторяемый - установлены основные процессы управления проектами: отслеживание затрат, сроков и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах.

Определенный - процессы разработки ПО и управления проектами описаны и внедрены в единую систему процессов компании. Во всех проектах используется стандартный для организации процесс разработки и поддержки программного обеспечения, адаптированный под конкретный проект.

Управляемый - собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных.

Оптимизируемый - постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.

Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.

RUP

Один из самых известных процессов, использующих итеративную модель разработки – Rational Unified Process (RUP).

Cоздан во второй половине 1990-х годов в компании Rational Software.

Основныt разработчики Филипп Крачтен (Philippe Kruchten), Грейди Буч (Grady Booch), Джеймс Рамбо (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson).

Последние трое являются также создателями нотации UML.

Rational Unified Process предлагает итеративную модель разработки, включающую 4 фазы: начало, исследование, построение и внедрение.

Каждая фаза может быть разбита на этапы (итерации) , в результате которых выпускается версия для внутреннего или внешнего использования.

Прохождение через фазы - цикл разработки , каждый цикл завершается генерацией версии системы.

Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы.

Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Термин RUP означает как методологию разработки, так и продукт компании IBM (ранее – Rational) для управления процессами разработки.

Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.

Рабочий процесс в RUP

В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles).

Артефактами являются спецификации, модели, исходный код и т.п.

Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline).

В дисциплины входят:

Бизнес-моделирование (Business Modeling) – исследование и описание существующих бизнес-процессов заказчика, а также поиск их возможных улучшений.

Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком.

Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта.

Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы.

Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.

Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей.

Управление конфигурациями и изменениями (Configuration and Change Management) – управление версиями исходного кода и документации, процесс обработки запросов на изменение (change requests).

Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками.

Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки.

В ходе жизненного цикла проекта распределение усилий проектной команды между дисциплинами постоянно меняется.

Например, как правило, в начале проекта большая часть усилий затрачивается на анализ и дизайн, а ближе к завершению – на реализацию и тестирование системы. Однако в общем случае задачи из всех девяти дисциплин выполняются параллельно.

Рисунок иллюстрирует выполнение проекта среднего размера.

Для полноценного внедрения RUP организация должна затратить значительные средства на обучение сотрудников.

При этом попытка обойтись своими силами скорее всего будет обречена на неудачу – необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов.

База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины.

Структурно пакет руководств MSF разделён на пять документов, так называемых «белых книг», каждый из которых охватывает определенную дисциплину или модель MSF:

«Модель процессов MSF»,

«Модель проектной группы MSF»,

«Дисциплина управления проектами MSF»,

«Дисциплина управления рисками MSF» и

«Дисциплина управления подготовкой MSF».

Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process.

Personal Software Process определяет требования к компетенциям разработчика.

Согласно этой модели каждый программист должен уметь:

учитывать время, затраченное на работу над проектом;

учитывать найденные дефекты;

классифицировать типы дефектов;

оценивать размер задачи;

осуществлять систематический подход к описанию результатов тестирования;

планировать программные задачи;

распределять их по времени и составлять график работы.

выполнять индивидуальную проверку проекта и архитектуры;

осуществлять индивидуальную проверку кода;

выполнять регрессионное тестирование.

Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков.

Команды должны:

установить собственные цели;

составить свой процесс и планы;

отслеживать работу;

поддерживать мотивацию и максимальную производительность.

Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.

Основная идея всех гибких моделей заключается в том, что применяемый в разработке ПО процесс должен быть адаптивным .

Они декларируют своей высшей ценностью ориентированность на людей и их взаимодействие, а не на процессы и средства.

По сути, так называемые, гибкие методологии это не методологии, а набор практик , которые могут позволить (а могут и нет) добиваться эффективной разработки ПО, основываясь на итеративности, инкрементальности, самоуправляемости команды и адаптивности процесса.

В течение 1990-х годов все больше разработчиков ПО начинали искать альтернативу традиционным, как правило, основанным на модели водопада, процессам разработки. К 2000 году существовало уже целое множество так называемых легковесных (lightweight) методологий .

В 2001 году группа создателей и экспертов по различным легковесным методологиям провела семинар, на котором были сформулированы основные принципы гибкой разработки ПО (так называемый Agile Manifesto) – манифест гибкой разработки.

На том же семинаре было предложено новое название легковесных методологий – гибкая разработка (agile software development).

Общими особенностями гибких методологий являются:

Ориентированность на людей – как разработчиков, так и заказчиков. Считается, что умение собрать в проектной команде «правильных» людей определяет успех или неудачу проекта в значительно большей степени, чем любые процессы или технологии.

Использование устных обсуждений вместо формальных спецификаций везде, где это возможно. Обсуждения должны быть главным способом коммуникации как с заказчиком, так и внутри проектной команды.

Итеративная разработка с возможно более короткой (в разумных пределах) продолжительностью итерации, при этом в результате каждой итерации выпускается полноценная работающая версия продукта.

Ожидание изменений – в гибком процессе проектная команда не пытается зафиксировать требования в начале проекта и затем следовать жестко определенному плану. Изменения могут быть сделаны на сколь угодно позднем этапе проекта.

Принципы, которые разъясняет Agile Manifesto :

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

работающее программное обеспечение - лучший измеритель прогресса;

спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

постоянное внимание улучшению технического мастерства и удобному дизайну;

простота - искусство не делать лишней работы;

лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

постоянная адаптация к изменяющимся обстоятельствам.

eXtreme Programming или XP (экстремальное программирование)

Методология XP была создана Кентом Беком (Kent Beck) в 1996 году в ходе попытки спасти провальный проект по разработке системы расчета зарплаты для компании Крайслер.

В 2000 году проект был закрыт, но XP к тому времени уже получила известность и начала распространяться среди разработчиков ПО.

XP наследует все общие принципы гибких методологий, достигая их при помощи двенадцати инженерных практик.

Она описывается как 12 практик: игра в планирование, короткие релизы, метафоры, простой дизайн, переработки кода (refactoring), разработка "тестами вперед", парное программирование, коллективное владение кодом, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода.

Интерес к XP рос снизу вверх, от разработчиков и тестировщиков, замученных тягостным процессом, документацией, метриками и прочим формализмом. Они не отрицали дисциплину, но не желали бессмысленного соблюдения формальных требований. И искали новые быстрые и гибкие подходы к разработке высококачественных программ.

Crystal Clear

Разработчик Алистер Коуберн

Crystal - семейство методологий, определяющих необходимую степень формализации процесса разработки в зависимости от количества участников и критичности задач.

Уступает XP по производительности, зато максимально проста в использовании. Требует минимальных усилий для внедрения, так как ориентирована на человеческие привычки.

Считается, что она описывает тот естественный порядок разработки ПО, который устанавливается в достаточно квалифицированных коллективах, если в них не занимаются целенаправленным внедрением другой методологии.

Основные характеристики методологии:

Итеративная инкрементная разработка;

Автоматическое регрессионное тестирование;

Пользователи привлекаются к активному участию в проекте;

Состав документации определяется участниками проекта;

Как правило, используются средства контроля версий кода.

Помимо Crystal Clear в семейство Crystal входит еще несколько методологий, предназначенных для выполнения более крупных или более критических проектов. Они отличаются несколько более жесткими требованиями к объему документации и вспомогательным процедурам, таким как управление изменениями и версиями.

Feature Driven Development

Функционально-ориентированная разработка (FDD, Feature Driven Development).

На самом деле используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, используемому в RUP.

Едва ли не самое существенное отличие - это дополнительное ограничение: "каждая функция должна допускать реализацию не более, чем за две недели". То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций.

FDD включает 5 процессов, последние два из которых повторяются для каждой функции:

Разработка общей модели.

Составление списка необходимых функций системы.

Планирование работы над каждой функцией.

Проектирование функции.

Конструирование функции.

Разработчики в FDD делятся на "хозяев классов" – class owners и "главных программистов" chief programmers.

Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения, в XP нет персонально ответственных за классы или методы. К работе над любым классом может привлекаться любой из участников разработки.

Работа над проектом предполагает частые сборки и делится на итерации, каждая из которых предполагает реализацию определенного набора функций.

OpenUP

Итеративно-инкрементальный метод разработки ПО. Позиционируется как легкий и гибкий вариант RUP.

Базовый процесс OpenUP является независимым от инструментов, малорегламентированным процессом, который может быть расширен для удовлетворения потребностей широкого диапазона типов проектов.

В основу OpenUP положены следующие основные принципы :

Совместная работа с целью согласования интересов и достижения общего понимания;

Развитие с целью непрерывного обеспечения обратной связи и совершенствования проекта;

Концентрация на архитектурных вопросах на ранних стадиях для минимизации рисков и организации разработки;

Выравнивание конкурентных преимуществ для максимизации потребительской ценности для заинтересованных лиц.

Scrum

Scrum - методология управления разработкой информационных систем для гибкой разработки программного обеспечения.

Scrum чётко делает акцент на качественном контроле процесса разработки.

Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.

Это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет.

Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Спринт - итерация, в ходе которой создаётся функциональный рост программного обеспечения.

Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель.

Считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении.

По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур».

Названия были использованы из-за шутки:

Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать "Яичница с беконом"?». «Так не пойдёт», - отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»

Основные роли:

Скрам-мастер (ScrumMaster) – проводит совещания следит за соблюдением всех принципов, разрешает противоречия и защищает команду от отвлекающих факторов. Только ведет скрам-процесс.

Владелец проекта (Product Owner) – представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

Скрам-команда (Scrum Team) – кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат.

Неосновные роли:

Пользователи (Users)

Клиенты, Продавцы (Stakeholders) – лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

Управляющие (Managers) – люди, которые управляют персоналом.

Эксперты-консультанты (Consulting Experts)

Ежедневное совещание (Daily Scrum meeting):

начинается точно вовремя;

все могут наблюдать, но только основные говорят;

длится не более 15 минут;

проводится в одном и том же месте в течение спринта.

В течение совещания каждый член команды отвечает на 3 вопроса:

Что сделано с момента предыдущего ежедневного совещания?

Что будет сделано с момента текущего совещания до следующего?

Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

Основная

Г.Н. Смирнова, А.А.Сорокин, Ю.Ф. Тельнов Проектирование экономических информационных систем. Учебник. М., «Финансы и статистика»,2002

Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М., «Финансы и статистика»,2000

Маклаков С.В. Создание ИС с AllFusion Modelling Suite. М., «Диалог-МИФИ», 2003

Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование ИС. Учебное пособие. Интернет-университет, М., 2005

Дополнительная

Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. М.,СИНТЕГ, 2000

Калянов Г.Н. Структурный системный анализ.

М., Лори, 1996

Марка Д.А., МакГоуэн К. SADT – методология структурного анализа и проектирования., М., Метатехнология, 1993

Г. Буч Д. Рамбо А. Джекобсон Язык UML. Руководство пользователя, 1999

М. Фаулер К. Скотт Основы UML

Т. Кватрани Rational Rose 2000 и UML. Визуальное моделирование. Москва, 2001

Дополнительная

Колтунова Е. Требования к информационной системе и модели жизненного цикла. Carabi Solutions , www.carabisolutions.sp.ru

Автоматизированные Системы Стадии создания. ГОСТ 34.601-90 Комплекс стандартов на автоматизированные системы. ИПК издательство стандартов, М., 1997

ISO/IEC 12207:1995

Thiele D. Life cycle management using life cycle process standards. Abstract. http://www.fostas.ru/library/show_article.php? id=22

Проектирование и разработка корпоративных информационных систем. http://zeus.sai.msu.ru:7000/cfin/prcorpsys/index.sht ml.

Основные понятия

методологии проектирования ИС

1. Цели и содержание методологии проектирования ИС

2. Жизненный цикл ИС

Методология проектирования ИС

В реальных условиях проектирование - это поиск способа, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений.

Системный подход : любая система представляет собой совокупность взаимосвязанных элементов, функционирующих совместно для достижения общей цели.

Метод проектирования : организованная совокупность процессов создания ряда моделей, которые описывают различные аспекты создаваемой системы с использованием четко определенной нотации.

Технология проектирования : совокупность технологических операций в их последовательности и взаимосвязи, приводящая к разработке проекта системы.

Подсистемы ИС

Информационное обеспечение совокупность

единой системы

унифицированных

массивов (обычно –

Техническое

средств, предназначенных

системы и ее пользователей,

Программное

специальные программные

Организационное ро

мероприятий и

взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации информационной системы.

Математическое

математических методов,

управления системой и

Лингвистическоепр

использующихся при

программирования, я

Правовое о

определяющих со

информационных

преобразования и исполь

Этапы развития технологий проектирования ИС

1. Метод "снизу-вверх" - не создание тиражируемых продуктов, а обслуживание сотрудников конкретного учреждения. Успешно автоматизируются отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривается недостаточно хорошо, особенно в перспективе.

(«Лоскутная автоматизация»)

2. Метод "сверху-вниз " - из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы были спроектированы "сверху", т.е. в предположении что одна программа должна удовлетворять потребности всех пользователей: резко ограничены возможности разработчиков в структуре информационных множеств базы данных, использовании вариантов экранных форм, алгоритмов расчета и, следовательно, лишила возможности по ведению глубокого, часто специфического аналитического и производственно - технологического учета.

Этапы развития технологий проектирования

(продолжение)

3. Метод многокомпонентности - адаптация подсистемы ПО к принятым в организации условиям работы. Проведение модернизации одного из компонентов не затрагивает центральную часть (ядро) и другие ее компоненты, что значительно повышает надежность, продолжительность жизни автоматизированной системы и обеспечивает наиболее полное выполнение требуемых функций.

Проектирование имеет целью обеспечить эффективное функционирование автоматизированной информационной системы (АИС) и взаимодействие автоматизированной информационной технологии (АИТ) со специалистами, использующими в сфере деятельности конкретного экономического объекта ПЭВМ и развитые средства коммуникации для выполнения своих профессиональных задач и принятия управленческих решений. В процессе проектирования совершенствуются как организация основной деятельности экономического объекта (производственной, хозяйственной), так и организация управленческих процедур. Массовое проектирование информационных технологий потребовало разработки единых теоретических положений, методических подходов к их созданию и функционированию.

Первоначально сформулированные академиком В.М. Глушковым научно-методические положения и практические рекомендации по проектированию автоматизированных систем в настоящее время сложились как основополагающие принципы создания АИС: системности, развития, совместимости, стандартизации и унификации, эффективности.

Принцип системности является важнейшим при создании, функционировании и развитии АИС. Он позволяет подойти к исследуемому объекту как единому целому; выявить на этой основе многообразные типы связей между структурными элементами, обеспечивающими целостность системы; установить направления производственно-хозяйственной деятельности системы и реализуемые ею конкретные функции. Системный подход предполагает проведение двухаспектного анализа, получившего название макро- и микроподходов.

При макроанализе система или ее элемент рассматриваются как часть системы более высокого порядка. Особое внимание уделяется информационным связям: устанавливается их число, выделяются и анализируются те связи, которые обусловлены целью изучения системы, а затем выбираются наиболее предпочтительные, реализующие заданную целевую функцию. При микроанализе изучается структура объекта, анализируются ее составляющие элементы с точки зрения их функциональных характеристик, проявляющихся через связи с другими элементами и внешней средой. В процессе проектирования АИС системный подход позволяет использовать математическое описание функционирования, исследование различных свойств отдельных элементов и системы в целом, моделировать изучаемые процессы для анализа работы вновь создаваемых систем.

Для АИС управления характерна многоуровневая иерархия с вертикально соподчиненными элементами (подсистемами). Преимущества иерархических структур способствовали их широкому распространению в системах управления. Практическое значение системного подхода и моделирования состоит в том, что они позволяют в доступной для анализа форме не только отразить все существенное, интересующее создателя системы, но и использовать ЭВМ для исследования поведения системы в конкретных, заданных экспериментатором условиях. Поэтому в основе создания АИС в настоящее время лежит метод моделирования на базе системного подхода, позволяющий находить оптимальный вариант структуры системы и тем самым обеспечивать наибольшую эффективность ее функционирования.

Принцип развития заключается в том, что АИС создается с учетом возможности постоянного пополнения и обновления функций системы и видов ее обеспечений. Предусматривается, что автоматизированная система должна наращивать свои вычислительные мощности, оснащаться новыми техническими и программными средствами, быть способной постоянно расширять и обновлять круг задач и информационный фонд, создаваемый в виде системы баз данных. Принцип совместимости заключается в обеспечении способности взаимодействия АИС различных видов, уровней в процессе их совместного функционирования. Реализация принципа совместимости позволяет обеспечить нормальное функционирование экономических объектов, повысить эффективность управления народным хозяйством и его звеньями.

Принцип стандартизации и унификации заключается в необходимости применения типовых, унифицированных и стандартизированных элементов функционирования АИС. Внедрение в практику создания и развития АИС этого принципа позволяет сократить временные, трудовые и стоимостные затраты на создание АИС при максимально возможном использовании накопленного опыта в формировании проектных решений и внедрении автоматизации проектировочных работ.

Принцип эффективности заключается в достижении рационального соотношения между затратами на создание АИТ и целевым эффектом, получаемым при ее функционировании.

Как правило, кроме основополагающих принципов для эффективного осуществления управления выделяют также ряд частных принципов, детализирующих общие. Соблюдение каждого из частных принципов позволяет получить определенный экономический эффект. Один из них - принцип декомпозиции - используется при изучении особенностей, свойств элементов и системы в целом. Он основан на разделении системы на части, выделении отдельных комплексов работ, создает условия для более эффективного ее анализа и проектирования.

Принцип первого руководителя предполагает закрепление ответственности при создании системы за заказчиком - руководителем предприятия, организации, отрасли, т.е. будущим пользователем, который отвечает за ввод в действие и функционирование АИТ.

Принцип новых задач - поиск постоянного расширения возможностей системы, совершенствование процесса управления, получение дополнительных результатных показателей с целью оптимизировать управленческие решения. Это может сопровождаться постановкой и реализацией при использовании ЭВМ и других технических средств новых задач управления.

Принцип автоматизации информационных потоков и документооборота предусматривает комплексное использование технических средств на всех стадиях прохождения информации от момента ее регистрации до получения результатных показателей и формирования управленческих решений.

Принцип независимости данных предполагает, что модели данных должны быть проанализированы и спроектированы независимо от процессов их обработки, а также от их физической структуры и распределения в технической среде.

Принцип структурирования данных предусматривает необходимость структурирования и иерархической организации элементов информационной базы системы.

Принцип доступа конечного пользователя заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования). Соблюдение приведенных принципов необходимо при выполнении работ на всех стадиях создания и функционирования АИС и АИТ, т.е. в течение всего их жизненного цикла.

Жизненный цикл (ЖЦ) - период создания и использования АИС (АИТ), охватывающий ее различные состояния, начиная с момента возникновения необходимости в данной автоматизированной системе и заканчивая моментом ее полного выхода из употребления у пользователей.

Жизненный цикл АИС и АИТ позволяет выделить четыре основные стадии: предпроектную, проектную, внедрение и функционирование. От качества проектировочных работ зависит эффективность функционирования системы. Поэтому каждая стадия проектирования разделяется на ряд этапов и предусматривает составление документации, отражающей результаты работы.

Основными работами, выполняемыми на стадиях и этапах проектирования, можно считать:

I стадия - предпроектное обследование:

1-й этап - сбор материалов для проектирования -формирование требований, изучение объекта проектирования, разработка и выбор варианта концепции системы;

2-й этап - анализ материалов и формирование документации -создание и утверждение технико-экономического обоснования и технического задания на проектирование системы на основе анализа материалов обследования, собранных на первом этапе.

II стадия - проектирование:

1-й этап - техническое проектирование, где ведется поиск наиболее рациональных проектных решений по всем аспектам разработки, создаются и описываются все компоненты системы, а результаты работы отражаются в техническом проекте,

2-й этап - рабочее проектирование, в процессе которого осуществляется разработка и доводка программ, корректировка структур баз данных, создание документации на поставку, установку технических средств и инструкций по их эксплуатации, подготовка для каждого пользователя системы обширного инструкционного материла, оформленного в виде должностных инструкций исполнителям-специалистам, реализующим свои профессиональные функции с использованием технических средств управления. Технический и рабочий проекты могут объединяться в единый документ - техно-рабочий проект.

III стадия - ввод системы в действие:

1-й этап - подготовка к внедрению - установка и ввод в эксплуатацию технических средств, загрузка баз данных и опытная эксплуатация программ, обучение персонала;

2-й этап - проведение опытных испытаний всех компонентов системы перед передачей в промышленную эксплуатацию, обучение персонала;

3-й этап (завершающая стадия создания АИС и АИТ) - сдача в промышленную эксплуатацию; оформляется актами приема-сдачи работ.

VI стадия - промышленная эксплуатация кроме повседневного функционирования включает сопровождение программных средств и всего проекта, оперативное обслуживание и администрирование баз данных.

Жизненный цикл (ЖЦ) образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер; реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т.п. На каждом этапе ЖЦ формируется определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Этап завершается проверкой предложенных решений и документов на их соответствие сформулированным требованиям и начальным условиям.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

Каскадная модель (70-85 г.г.);

Спиральная модель (86-90 г.г.).

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рисунок 1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Рисунок 1 - Каскадная схема разработки ПО.

Положительные стороны применения каскадного подхода заключаются в следующем:

На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

Выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид.

Рисунок 2 - Реальный процесс разработки ПО по каскадной схеме

Основным недостатком каскадного подхода является существенное запаздывание с получением результатов.

Для преодоления перечисленных проблем была предложена спиральная модель, делающая упор на начальные этапы ЖЦ: анализ и проектирование. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Рисунок 3 - Спиральная модель ЖЦ

При проектировании автоматизированная информационная технология рассматривается в пяти взаимосвязанных аспектах.

1. Техническом - как аппаратно-коммуникационный комплекс, имеющий конкретную конфигурацию и служащий для обработки и передачи информации.

2. Программно-математическом - как набор статистических, математических, инфологических, алгоритмических и прочих машинно-ориентированных моделей, а также реализующих их компьютерных программ.

3. Методическом - как совокупность средств реализации функций управления по отношению к экономическому объекту - предприятию, объединению, региональному хозяйству и т. д.

4. Организационном - как описание документооборота и регламента деятельности аппарата управления.

5. Пооперационном - как совокупность технологических, логических и арифметических операций, реализуемых в автоматическом режиме.

Исходя из реальных условий конкретной предметной области формулируются основные требования к АИТ. Перечислим наиболее общие из них, характерные для современных информационных технологий.

Принцип системности. Такой принцип предполагает подразделение информационных потоков на внешние и внутренние по отношению к объекту управления, учет структурно-динамических свойств протекающих в нем процессов, моделирование прямых и обратных связей с окружающей средой.

Работа в многозадачном режиме. Использование децентрализованных средств сбора и предварительной обработки данных согласно принятой декомпозиции задач и распределения управленческих функций, что достигается с помощью технологии «клиент - сервер», позволяющей системе функционировать в многозадачном режиме.

Способность к адаптации всей системы и гибкое приспособление АИТ к изменениям рыночной среды, возможность быстрого переключения на разные режимы использования аппаратных и телекоммуникационных средств.

Ориентация АИТ на реализацию единой информационно-логической модели объекта управления в сочетании с необходимыми процедурами обработки данных и вывода результатов.

Синхронизация процессов переработки и выдачи информации с процессами принятия решений на всех уровнях за счет использования диалогового и планового (в масштабе реального времени) режимов эксплуатации АИТ.

Использование безбумажного документооборота, естественно-профессионального " языка для общения специалиста с ПЭВМ, электронных подписей, машинных архивов и библиотек, удаленного доступа к массивам данных.

Возможность обработки больших объемов информации в регламентном и произвольном режимах, а также интеграции данных в соответствии с иерархией управления.

Наличие экспертной поддержки, учет неполноты информации, возможность получения прогнозных данных.

Названные свойства АИТ обеспечиваются применением современных высокоразвитых аппаратно-программных комплексов, средств связи и формулируются в процессе проектирования разработчиками системы. Такие пользователи-разработчики относятся к классу профессионалов. Для них существует множество инструментальных средств, облегчающих создание АИТ. Например, можно назвать системы Oraclе, Visual C++, Gupta SQL, Windows, CA-Visual Objects, а также CASE-технологии, позволяющие конструировать сложные компьютерные системы из отдельных стандартизированных программных модулей.

Другой класс пользователей - специалисты проблемной области, которые применяют в своей деятельности программные средства с широкими технологическими возможностями, такие как MS Word, CorelDraw, MS Excel, MS Project, MS Access.

Автоматизированные системы проектирования - быстроразвивающийся путь ведения проектировочных работ. В области автоматизации проектирования АИС и АИТ за последнее десятилетие сформировалось новое направление - CASE (Computer-Aided Software/System Engineering). Дальнейшее развитие работ в этом направлении привело к созданию ряда концептуально целостных, оснащенных высокоуровневыми средствами проектирования и реализации вариантов, доведенных по качеству и легкости тиражирования до уровня программных продуктов технологических систем, которые получили название CASE-систем или CASE-технологий.

В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. CASE-технология представляет собой совокупность методов анализа, проектирования, разработки и сопровождения АИС, поддержанной комплексом взаимосвязанных средств автоматизации. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки АС, прочно вошедший в практику создания и сопровождения АИС и АИТ. Основная цель CASE-технологии состоит в том, чтобы отделить проектирование АИС и АИТ от ее кодирования и последующих этапов разработки, а также максимально автоматизировать процессы разработки и функционирования систем.

При использовании CASE-технологий изменяется технология ведения работ на всех этапах жизненного цикла автоматизированных систем и технологий, при этом наибольшие изменения касаются этапов анализа и проектирования. В большинстве современных CASE-систем применяются методологии структурного анализа и проектирования, основанные на наглядных диаграммных техниках, при этом для описания модели проектируемой АИС используются графы, диаграммы, таблицы и схемы.

Конец работы -

Эта тема принадлежит разделу:

Информационные технологии в юридической

Образовательное учреждение.. высшего профессионального образования.. государственный морской университет..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Жизненный цикл информационных систем

Разработка корпоративной информационной системы, как правило, выполняется для вполне определенного предприятия. Особенности предметной деятельности предприятия, безусловно, будут оказывать влияние на структуру информацион­ной системы. Но в то же время структуры разных предприятий в целом похожи между собой. Каждая организация, независимо от рода ее деятельности, состоит из ряда подразделений, непосредственно осуществляющих тот или иной вид дея­тельности компании. И эта ситуация справедлива практически для всех организа­ций, каким бы видом деятельности они ни занимались.

Основные фазы проектирования информационной системы

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта приня­то разделять на фазы (стадии, этапы}.

В определении количества фаз и их содержания имеются некоторые отличия, по­скольку эти характеристики во многом зависят от условий осуществления конк­ретного проекта и опыта основных участников. Тем не менее логика и основное содержание процесса разработки информационной системы почти во всех случа­ях являются общими.

Можно выделить следующие фазы развития информационной системы:

1. формирование концепции. Главным содержанием работ на этой фазе является определение проекта, разра­ботка его концепции, включающая:

Формирование идеи, постановку целей;

Формирование ключевой команды проекта;

Изучение мотивации и требований заказчика и других участников;

Сбор исходных данных и анализ существующего состояния;

Определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;

Сравнительную оценку альтернатив;

Представление предложений, их экспертизу и утверждение;

2. разработка технического задания. Главным содержанием этой фазы является разработка технического предложения и переговоры с заказчиком о заключении контракта. Общее содержание работ этой фазы:

Разработка основного содержания проекта, базовой структуры проекта;

Разработка и утверждение технического задания;

Планирование, декомпозиция базовой структурной модели проекта:

Составление сметы и бюджета проекта, определение потребности в ресурсах;

Разработка календарных планов и укрупненных графиков работ;

Подписание контракта с заказчиком;

Ввод в действие средств коммуникации участников проекта и контроля за хо­дом работ;

3. проектирование. На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характер­ные работы этой фазы:

Выполнение базовых проектных работ;

Разработка частных технических заданий;

Выполнение концептуального проектирования;

Составление технических спецификаций и инструкций;

Представление проектной разработки, экспертиза и утверждение.

На этом этапе решаются вопросы определения входных и выходных потоков информации, их типов, средств защиты данных, программ, компьютерной системы. В этот момент разрабатываются схема данных, меню действий, схемы ресурсов системы, взаимодействия программ, схемы программ:

· схема данных графически отображает путь данных при решении задач от момента возникновения до передачи потребителю и определяет этапы обработки, а также применяемые носители данных;

· меню действий – это горизонтальный список объектов на экране, представляющих группу действий, доступных пользователю для выбора;

· схема ресурсов системы отображает конфигурацию блоков данных и обрабатывающих средств, которые требуются для решения задачи;

· схема программы отображает последовательность операций в программе;

· схема взаимодействия программ показывает путь активации программ и взаимодействий с соответствующими данными;

· схема работы системы отображает управление операциями и потоками данных и отражает технологический процесс обработки данных в системе.

4. изготовление. На этой фазе производятся координация и оперативный контроль работ по проек­ту, осуществляется изготовление подсистем, их объединение и тестирование. Ос­новное содержание:

Выполнение работ по разработке программного обеспечения;

Выполнение подготовки к внедрению системы;

Контроль и регулирование основных показателей проекта.

5. ввод системы в эксплуатацию . На этой фазе проводятся испытания, опытная эксплуатация системы в реальных условиях, ведутся переговоры о результатах выполнения проекта и о возможных новых контрактах. Основные виды работ:

Комплексные испытания;

Подготовка кадров для эксплуатации создаваемой системы;

Подготовка рабочей документации, сдача системы заказчику и ввод ее в экс­плуатацию;

Сопровождение, поддержка, сервисное обслуживание;

Оценка результатов проекта и подготовка итоговых документов;

Разрешение конфликтных ситуаций и закрытие работ по проекту;

Накопление опытных данных для последующих проектов, анализ опыта, состо­яния, определение направлений развития.

Вторую и частично третью фазы принято называть фазами системного проектирования, а последние две (иногда сюда включают и фазу проектирования) - фазами реализации.

Начальные фазы проекта имеют решающее влияние на достигаемый результат, так как в них принимаются основные решения, определяющие качество информацион­ной системы. При этом обычно 30 % вклада в конечный результат проекта вносят фазы концепции и предложения, 20 % -фаза проектирования, 20 % - фаза изготовления, 30 % - фаза сдачи объекта и завершения проекта.

Кроме того, на обнаружение ошибок, допущенных на стадии системного проекти­рования, расходуется примерно в два раза больше времени, чем на последующих фазах, а их исправление обходится в пять раз дороже. Поэтому на начальных ста­диях проекта разработку следует выполнять особенно тщательно. Наиболее часто на начальных фазах допускаются следующие ошибки:

Ошибки в определении интересов заказчика;

Концентрация на маловажных, сторонних интересах;

Неправильная интерпретация исходной постановки задачи;

Неправильное или недостаточное понимание деталей;

Неполнота функциональных спецификаций (системных требований);

Ошибки в определении требуемых ресурсов и сроков;

Редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

Проектирование информационных систем (ИС) представляет сложный многоступенчатый вид деятельности, без научной организации которого немыслимо создание и использование современных сложных ИС, в том числе в образовании, предпринимательстве, менеджменте и других областях жизнедеятельности общества. Наряду с получением необходимых для этого теоретических знаний проектировщику ИС требуется обрести устойчивые практические навыки этого вида деятельности.

Главной особенностью проектирования является работа с еще не существующим объектом. В этом отличие проектирования от моделирования, где объект не может не существовать.

Проектирование ИС охватывает три основные области:

Проектирование объектов данных, которые будут реализованы в базе данных;

Проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

Учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Проектирование информационных систем всегда начинается с определения цели проекта. В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:

Требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

Требуемой пропускной способности системы;

Требуемого времени реакции системы на запрос;

Безотказной работы системы;

Необходимого уровня безопасности;

Простоты эксплуатации и поддержки системы .

Технология проектирования

Технология проектирования АИС – это совокупность методов и средств проектирования АИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта АИС). В основу технологии проектирования лежит технологический процесс (ТП), который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий.

ТП проектирования АИС представляет собой совокупность последовательно-параллельных, связанных и соподчиненных цепочек действий, каждое из которых может иметь свой предмет. Действия, которые выполняются при проектировании АИС, могут быть определены как неделимые технологические операции или как подпроцессы технологических операций.

Все действия могут быть собственно проектированными, которые формируют или модифицируют результаты проектирования, и оценочными, которые вырабатывают по установленным критериям оценки результатов проектирования.

Таким образом, технология проектирования задается регламентированной последовательностью технологических операций, выполняемых в процессе создания проекта на основе того или иного метода.

Предметом выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла АИС .

Основные требования, предъявляемые к выбираемой технологии проектирования, следующие:

Созданный с помощью этой технологии проект должен отвечать требованиям заказчика;

Технология должна максимально отражать все этапы цикла жизни проекта;

Технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта;

Технология должна способствовать росту производительности труда проектировщиков;

Технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;

Технология должна способствовать простому ведению проектной документации.

Технология проектирования АИС реализует определенную методологию проектирования. В свою очередь, методология проектирования предполагает наличие некоторой концепции, принципов проектирования и реализуется набором методов и средств.

Методы проектирования АИС можно классифицировать по степени использования средства автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.

По степени автоматизации различают:

Ручное проектирование;

Компьютерное проектирование;

По степени использования типовых проектных решений различают:

Оригинальное проектирование;

Типовое проектирование;

По степени адаптивности проектных решений различаются следующие методы:

Реконструкция – адаптация проектных решений выполняется путем переработки соответствующих компонентов;

Параметризация – проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами;

Реструктуризация модели – изменяется модель предметной области, что приводит к автоматическому переформированию проектных решений.

В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной АИС, стадии и этапы работ могут иметь различную трудоёмкость. Допускается объединять последовательные этапы и исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей .

Основные стадии создания автоматизированной информационной системы:

Формирование требований к АИС;

Разработка концепции АИС;

Разработка технического задания;

Разработка эскиза проекта;

Разработка технической части проекта;

Разработка рабочей документации на АИС;

Ввод в действие;

Сопровождение АИС .

Методология проектирования

Основу технологии проектирования информационных систем составляет методология. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства.

Методы проектирования ИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям. Так, по степени автоматизации методы проектирования разделяются на:

1. Ручное, при котором проектирование компонентов ИС осуществляется без использования специальных инструментальных программных средств, а программирование - на алгоритмических языках;

2. Компьютерное, при котором производится генерация или конфигурирование (настройка) проектных решений на основе использования специальных инструментальных программных средств.

По степени использования типовых проектных решений различают следующие методы проектирования:

1. Оригинальное (индивидуальное), когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС. Характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его особенности;

2. Типовое, предполагающее конфигурирование ИС из готовых типовых проектных решений (программных модулей). Выполняется на основе опыта, полученного при разработке индивидуальных проектов. Типовые проекты, как обобщение опыта для некоторых групп организационно-экономических систем или видов работ, в каждом конкретном случае связаны с множеством специфических особенностей и различаются по степени охвата функций управления, выполняемым работам и разрабатываемой проектной документации.

По степени адаптивности проектных решений выделяют методы:

1. Реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);

2. Параметризации, когда проектные решения настраиваются (генерируются) в соответствии с изменяемыми параметрами;

3. Реструктуризации модели, когда изменяется модель проблемной области, на основе которой автоматически заново генерируются проектные решения.

Сочетание различных признаков классификации методов обусловливает характер используемых технологий проектирования ИС, среди которых выделяют два основных класса: каноническую и индустриальную технологии. Индустриальная технология проектирования, в свою очередь, разбивается на два подкласса: автоматизированное (использование CASE-технологий) и типовое (параметрически-ориентированное или модельно-ориентированное) проектирование. Использование индустриальных технологий не исключает использования в отдельных случаях канонических .

Проектирование - это практическая деятельность, целью которой является поиск новых решений, оформленных в виде комплекта документации. Процесс поиска представляет собой последовательность выполнения взаимообусловленных действий, процедур, которые, в свою очередь, подразумевают использование определенных методов. Сложность процесса проектирования (как и любой другой творческой деятельности), нестандартность проектных (жизненных) ситуаций вызывают необходимость знания различных методов и умения владеть ими.

Технология проектирования определяется как совокупность трех составляющих:

Пошаговой процедуры, определяющей последовательность технологических операций проектирования;

Критериев и правил, используемых для оценки результатов выполнения технологических операций;

Нотаций (графических и текстовых средств), используемых для описания проектируемой системы .

Сравнительная характеристика инструментов проектирования

Основной целью выбора корпоративного стандарта организационного проектирования является задание общего и обязательного к применению языка общения управленческого звена, разработчиков организационных и технологических процессов и исполнителей этих процессов. Частными применениями таких стандартов является синтез требований к создаваемым системам, положений об организационных подразделениях, служебные инструкции и т.д.

Существует около 30 технологий проектирования организационно-технических систем и несколько сотен инструментов, предназначенных для автоматизации этого процесса. Поэтому, с учетом временного фактора, сравнительный анализ был ограничен четырьмя наиболее популярными на российском рынке продуктами: Bpwin/Erwin (Platinum Technology), Rational Rose (Rational Software Corporation), ARIS (Scheer AG) и Oracle Designer (Oracle Developer Suite). Справочные данные по CASE-технологиям и средствам проектирования приведены ниже по тексту и в таблице №1.

Таблица 1

Средства проектирования и их сравнительная характеристика

Критерии				Oracle Designer
Поддержка полного жизненного цикла ИС
Обеспечение целостности проекта
Независимость от платформы	+ (DoDAF, TeaF/FeaT, Zachman)	+ (ORACLE, Informix, Sybase)	+ (ORACLE, Informix, Sybase, Ingres и др.)
Одновременная групповая разработка БД и приложений

*) разработчики приложений могут начинать работу с базой данных только после завершения ее проектирования.

CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

Согласно обзору передовых технологий, составленному фирмой Systems Development Inc. в 2007 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся «полочным» ПО (shelfware). В связи с этим необходимо отметить следующее:

1. CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

2. Реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

3. CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.

Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-либо безоговорочные утверждения относительно реального удовлетворения тех или иных ожиданий от их внедрения. Можно перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств:

1. Широкое разнообразие качества и возможностей CASE-средств;

2. Относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

3. Широкое разнообразие в практике внедрения различных организаций;

4. Отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

5. Широкий диапазон предметных областей проектов;

6. Различная степень интеграции CASE-средств в различных проектах.

Вследствие этих сложностей доступная информация о реальных внедрениях крайне ограничена и противоречива. Она зависит от типа средств, характеристик проектов, уровня сопровождения и опыта пользователей. Некоторые аналитики полагают, что реальная выгода от использования некоторых типов CASE-средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.

В разряд СП попадают как относительно дешевые системы для персональных компьютеров (ПК) с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 30 различных CASE-систем, наиболее мощные из которых, так или иначе, используются практически всеми ведущими западными фирмами .

Применение СП требует от потенциальных пользователей специальной подготовки и обучения. Опыт показывает, что внедрение СП осуществляется медленно, однако по мере приобретения практических навыков и общей культуры проектирования эффективность применения этих средств резко возрастает, причем наибольшая потребность в использовании СП испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми СП:

ERWin / BPWin;

Rational Rose;

Oracle Designer.

ARIS - Интегрированное средство моделирования бизнес-процессов, объединяющее разнообразные методы моделирования и анализа систем. В первую очередь, это средство описания, анализа, оптимизации и документирования бизнес-процессов, чем средство проектирования программного обеспечения.

BPWin - инструмент визуального моделирования бизнес-процессов. ERWin - средство, используемое при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность - связь».

Rational Rose - средство моделирования объектно-ориентированных информационных систем. Позволяет решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

Oracle Designer - функциональное средство для описания предметной области. Входит в комплекс инструментальных средств Oracle9i Developer Suite по проектированию программных систем и баз данных, реализующих технологию CASE и собственную методологию разработки ИС компании Oracle - «CDM», позволяющих команде разработчиков провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Это средство имеет смысл использовать при ориентации на всю линейку продуктов Oracle, применяемую для проектирования, разработки и реализации сложной программной системы.

Анализ данных, приведенных в таблице, показывает, что из перечисленных СП только комплекс ARIS наиболее полно удовлетворяет всем критериям, принятым в качестве основных. Так, например, в комплексе Rational Rose целостность базы проектных данных и единая технология сквозного проектирования ИС обеспечивается за счет использования интерфейса Corba. Следует отметить, что каждый из двух продуктов сам по себе является одним из наиболее мощных в своем классе.

Таким образом, наиболее развитыми средствами разработки крупномасштабных ИС на сегодняшний день является, по мнению автора, комплекс ARIS.