Этапы проектирования информационных систем. Стадии создания и функционирования автоматизированной информационной системы. Проектирование информационной системы

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

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

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

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

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

Процесс создания ИС делится на ряд этапов (стадий [ 1.1 ]), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).

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

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

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

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

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

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

Конечными продуктами этапа проектирования являются:

• схема базы данных (на основании ER-модели, разработанной на этапе анализа);
• набор спецификаций модулей системы (они строятся на базе моделей функций).

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

• будет ли это архитектура "файл-сервер" или "клиент-сервер";
• будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
• будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
• будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
• будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Этап проектирования завершается разработкой технического проекта ИС.

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

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

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

Стандарт ГОСТ 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 вопроса:

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

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

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

Каноническое проектирование ИС

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

Стадия 1. Формирование требований к ИС .

На начальной стадии проектирования выделяют следующие этапы работ: обследование объекта и обоснование необходимости создания ИС; формирование требований пользователей к ИС; оформление отчета о выполненной работе и тактико-технического задания на разработку.

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

Стадия 3. Техническое задание : разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект : разработка предварительных проектных решений по системе и ее частям; разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект : разработка проектных решений по системе и ее частям; разработка документации на ИС и ее части; разработка и оформление документации на поставку комплектующих изделий; разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация : разработка рабочей документации на ИС и ее части; разработка и адаптация программ.

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

Стадия 8. Сопровождение ИС : выполнение работ в соответствии с гарантийными обязательствами; послегарантийное обслуживание.

Модели деятельности организации создаются в двух видах:

• модель «как есть»(«as-is»)- отражает существующие в организации бизнес-процессы;
• модель «как должно быть»(«to-be») — отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.

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

На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.

Стадии: 1) Пояснительная записка 2) Функциональная и организационная структура системы 3) Постановка задач и алгоритмы решения 4) Организация информационной базы 5) Альбом форм документов 6) Система математического обеспечения 7) Принцип построения комплекса технических средств 8) Расчет экономической эффективности системы 9) Мероприятия по подготовке объекта к внедрению системы

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

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

Введение

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

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

Производительность является главным фактором, определяющим эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

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

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

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

Считается, что сложную систему невозможно описать в принципе. Это, в частности, касается систем управления предприятием. Одним из основных аргументов является изменение условий функционирования системы, например директивное изменение тех или иных потоков информации новым руководством. Еще один аргумент - объемы технического задания, которые для крупного проекта могут составлять сотни страниц, в то время как технический проект может содержать ошибки. Возникает вопрос: а может, лучше вообще не проводить обследования и не делать никакого технического проекта, а писать систему «с чистого листа» в надежде на то, что произойдет некое чудесное совпадение желания заказчика с тем, что написали программисты, а также на то, что все это будет стабильно работать?

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

Рис. 1. Cхема «водопада»

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

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

Ниже мы рассмотрим некоторые схемы разработки проекта.

«Водопад» - схема разработки проекта

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

Ниже мы рассмотрим каждый из этапов, подробнее остановившись на этапе проектирования.

Стратегия

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

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

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

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

В документе обязательно должны быть описаны:

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

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

Следует отметить, что и на этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MoSCoW - предложен в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won’t have - отсутствующие функции.

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

Анализ

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

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

Двумя классическими результатами анализа являются:

• иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);
• модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

Ниже мы рассмотрим три наиболее часто применяемые методологии структурного анализа:

• диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;
• диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;
• диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

ER-диаграммы

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

Рис. 2. Пример ER-диаграммы

Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности (например, TITLES). В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом1, являются ключевыми (так Title Identity - ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются).

Отношение изображается линией между двумя сущностями (синие линии на рисунке).

Одиночная линия справа (рис. 3) означает «один», «птичья лапка» слева - «многие», а отношение читается вдоль линии, например «один ко многим». Вертикальная черта означает «обязательно», кружок - «не обязательно», например для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

Рис. 3. Элемент ER-диаграммы

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

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

Рис. 4. ER-диаграмма рефлексивного отношения

Атрибуты сущностей могут быть ключевыми - они выделяются полужирным шрифтом; обязательными - перед ними ставится знак «*», то есть их значение всегда известно, необязательными (optional) - перед ними ставится О, то есть значения этого атрибута в какие-то моменты могут отсутствовать или быть неопределенными.

Дуги

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

Рис. 5. Дуга

В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности - сущность делится на типы по категориям: «для физического лица» и «для юридического лица». Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рис. 6.

Рис. 6. Подтипы (справа) и супертип (слева)

Нормализация

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

Допустимые типы связей. При ближайшем рассмотрении связи типа «один к одному» (рис. 7) почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Рис. 7. Связи «один к одному»

Связи «многие к одному» представлены на рис. 8.

Рис. 8. Связи «многие к одному»

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

II - это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

III - применяется редко. Как A, так и B могут существовать без связи между ними.

Связи «многие ко многим» представлены на рис. 9.

Рис. 9. Связи «многие ко многим»

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

II - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

Рассмотрим теперь рекурсивные связи (рис. 10).

Рис. 10. Рекурсивные связи

I - редко, но имеет место. Отражает связи альтернативного типа.

II - достаточно часто применяется для описания иерархий с любым числом уровней.

III - имеет место на ранних этапах. Часто отражает структуру «перечня материалов» (взаимная вложенность компонентов). Пример: каждый КОМПОНЕНТ может состоять из одного и более (других) КОМПОНЕНТОВ и каждый КОМПОНЕНТ может использоваться в одном и более (других) КОМПОНЕНТОВ.

Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь «многие ко многим» (рис. 11) и ряд рекурсивных связей (рис. 12).

Рис. 11. Недопустимые связи «многие ко многим»

Обязательная связь «многие ко многим» в принципе невозможна. Такая связь означала бы, что ни одно из вхождений A не может существовать без B, и наоборот. На деле каждая подобная конструкция всегда оказывается ошибочной.

Рис. 12. Недопустимые рекурсивные связи

Диаграммы потоков данных

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

Рис. 13. Пример DFD

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

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

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

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

Хранилище данных (data storage) позволяет на ряде участков определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информацию, которую оно содержит, можно использовать в любое время после ее определения, при этом данные могут выбираться в произвольном порядке. Имя хранилища должно идентифицировать его содержимое. В случае когда поток данных входит (выходит) в (из) хранилище и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например «Клиент». Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

Диаграммы изменения состояний STD

Жизненный цикл сущности относится к классу STD-диаграмм (рис. 14). Эта диаграмма отражает изменение состояния объекта с течением времени. Например, рассмотрим состояние товара на складе: товар может быть заказан у поставщика, поступить на склад, храниться на складе, проходить контроль качества, может быть продан, забракован, возвращен поставщику. Стрелки на диаграмме показывают допустимые изменения состояний.

Рис. 14. Пример диаграммы жизненного цикла

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

Некоторые принципы проверки качества и полноты информационной модели
(источник - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

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

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

Качество сущностей

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

Список проверочных вопросов для сущности:

• Отражает ли имя сущности суть данного объекта?
• Нет ли пересечения с другими сущностями?
• Имеются ли хотя бы два атрибута?
• Всего атрибутов не более восьми?
• Есть ли синонимы/омонимы данной сущности?
• Сущность определена полностью?
• Есть ли уникальный идентификатор?
• Имеется ли хотя бы одна связь?
• Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?
• Ведется ли история изменений?
• Имеет ли место соответствие принципам нормализации данных?
• Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?
• Не имеет ли сущность слишком общий смысл?
• Достаточен ли уровень обобщения, воплощенный в ней?

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

• Отсутствуют ли пересечения с другими подтипами?
• Имеет ли подтип какие-нибудь атрибуты и/или связи?
• Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?
• Имеется ли исчерпывающий набор подтипов?
• Не является ли подтип примером вхождения сущности?
• Знаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный подтип от других?

Качество атрибутов

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

Список проверочных вопросов для атрибута:

• Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
• Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
• Имеет ли атрибут только одно значение в каждый момент времени?
• Отсутствуют ли повторяющиеся значения (или группы)?
• Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
• Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?
• Не может ли он быть пропущенной связью?
• Нет ли где-нибудь ссылки на атрибут как на «особенность проекта», которая при переходе на прикладной уровень должна исчезнуть?
• Есть ли необходимость в истории изменений?
• Зависит ли его значение только от данной сущности?
• Если значение атрибута является обязательным, всегда ли оно известно?
• Есть ли необходимость в создании домена для этого и ему подобных атрибутов?
• Зависит ли его значение только от какой-то части уникального идентификатора?
• Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Качество связи

Нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями.

Список проверочных вопросов для связи:

• Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис?
• Участвуют ли в ней только две стороны?

Не является ли связь переносимой?

• Заданы ли степень связи и обязательность для каждой стороны?
• Допустима ли конструкция связи?

Не относится ли конструкция связи к редко используемым?

• Не является ли она избыточной?
• Не изменяется ли она с течением времени?
• Если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?

Для исключающей связи:

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

Функции системы

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

Рис. 15. Пример декомпозиции

Очевидно, что операция выбора и расчета скидок может быть также разбита на более мелкие операции, например на расчет скидок за приверженность (клиент покупает товары в течение долгого времени) и на расчет скидок за количество покупаемого товара. Атомарные функции описываются подробно, например с помощью DFD и STD. Очевидно, что такое описание функций не исключает и дополнительное словесное описание (например, комментарии).

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

Уточнение стратегии

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

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

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

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

Проектирование информационных систем

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

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

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

 информационные связи - подразделения обмениваются информацией (документами, факсами, письменными и устными распоряжениями и т. п.);

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

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

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

 в терминах основных потоков работ: исполнители, действия, последовательность действий и т. п.;

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

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

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

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

Можно выделить следующие основные отличительные признаки проекта как объекта управления:

 изменчивость - целенаправленный перевод системы из существующего в некоторое

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

 ограниченность конечной цели;

 ограниченность продолжительности;

 ограниченность бюджета;

 ограниченность требуемых ресурсов;

 новизна для предприятия, для которого реализуется проект;

 комплексность - наличие большого числа факторов, прямо или косвенно влияющих на прогресс и результаты проекта;

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

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

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

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

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

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

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

 формирование концепции;

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

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

 изготовление;

 ввод системы в эксплуатацию.

Рассмотрим каждую из них более подробно.

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

Концептуальная фаза

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектирование

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

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

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

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

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

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

Разработка

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

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

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

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

Ввод системы в эксплуатацию

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

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

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

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

Существует международный стандарт, регламентирующий жизненный цикл ин формационных систем - ISO/IEC 12207.

ISO - International Organization of Standardization (международная организация по стандартизации). IEC- International Electrotechnical Commission (международная комиссия по электротехнике).

Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы.

Согласно данному стандарту структура жизненного цикла основывается на трех группах процессов:

 основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

 организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).

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

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

 обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по автоматизации деловых процессов;

 гарантия создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;

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

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

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

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

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

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

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

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

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

 данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;

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

 программными и техническими средствами;

 исполнителями.

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

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

 поддерживать полный жизненный цикл информационной системы;

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

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

 технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

 обеспечивать минимальное время получения работоспособной системы;

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

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

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

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

Понятие профиля информационной системы

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

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

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

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

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

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

Обычно рассматривают две группы профилей :

 регламентирующие архитектуру и структуру информационной системы;

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

В зависимости от области применения профили могут иметь разные категории и соответственно разные статусы утверждения:

 профили конкретной информационной системы, определяющие стандартизованные проектные решения в пределах данного проекта;

 профили информационной системы, предназначенные для решения некоторого класса прикладных задач.

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

Принципы формирования профиля информационной системы

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

 снижение трудоемкости проектов;

 повышение качества компонентов информационной системы;

 обеспечение расширяемости и масштабируемости разрабатываемых систем;

 обеспечение возможности функциональной интеграции в информационную систему задач, которые раньше решались раздельно;

 обеспечение переносимости прикладного программного обеспечения.

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

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

 существует множество международных и национальных стандартов, которые не

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

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

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

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

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

Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на две составляющие: приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют.

Между приложениями и средой определяются стандартизованные интерфейсы - Application Program Interface (API), которые являются необходимой частью про филей любой открытой системы.

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

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

 стандартизованные описания функций, выполняемых данной системой;

 функции взаимодействия системы с внешней для нее средой;

 стандартизованные интерфейсы между приложениями и средой информационной системы;

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

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

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

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

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

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

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

Структура профилей информационных систем

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

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