13. Проектирование информационной системы. Понятия и структура проекта ис. Требования к эффективности и надежности проектных решений.

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

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

--требуемую пропускную способность системы;

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

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

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

--необходимую безопасность.

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

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

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

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

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

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

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

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

Известны следующие модели жизненного цикла:

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

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

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

14. Основные компоненты технологии проектирования ИС. Методы и средства проектирования ИС. Краткая характеристика применяемых технологий проектирования. Требования, предъявляемые к технологии проектирования ИС. Выбор технологии проектирования ИС.

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

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

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

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

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

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

- технология должна поддерживать полный ЖЦ ПО;

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

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

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

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

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

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

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

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

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

- стандарт оформления проектной документации;

- стандарт пользовательского интерфейса.

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

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

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

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

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

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

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

Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.

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

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

ГЛАВНОЕ ОТЛИЧИЕ БП ОТ ТЕХНОЛОГИЧ. ПРОЦЕССА – БП не происходит сам по себе, он управл-ся и производится конкретными исполнителями или группой с пом. механизма. Тот, кто потребляет рез-т процесса явл-ся клиентом процесса.

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

Целью моделирования является систематизация знаний о компании и ее бизнес-процессах в наглядной графической форме более удобной для аналитической обработки полученной информации. Модель должна отражать структуру бизнес-процессов организации, детали их выполнения и последовательность документооборота. Моделирование бизнес-процессов организации включает два этапа структурное и детальное. Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

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

--существующая организационная структура;

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

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

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

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

--набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

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

--диаграммы взаимодействия, отражающие схемы документооборота.

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

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

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

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

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

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

Известны следующие модели жизненного цикла:

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

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

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

Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки. Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Среди наиболее известных стандартов можно выделить следующие:

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

--ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

--Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

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

--Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

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

16. Каноническое проектирование ИС. Стадии и этапы процесса проектирования ИС. Формирование требований к ИС, обследование предметной области. Разработка концепции ИС. Модели деятельности предприятий: модель "как есть"("as-is") и модель "как должно быть"("to-be"). Реализация моделей с помощью CASE – средства.

Организация канонического проект-ния ориентирована на использ-е каскадной модели ЖЦ ИС и описана в стандарте ГОСТ 34.601.90.

Стадии и этапы проектирования ИС

Прописываются в договорах и технич. заданиях на вып-ние работы.

Стадия 1. «Формирование требований к ИС». На нач. стадии проект-ния выделяют этапы работы:

- Обследование объекта и обосн-е необх-ти создания ИС.

- Формирование требоваий пользователей к ИС.

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

Стадия 2. «Разработка концепции ИС»

- Изучение объекта автоматизации

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

- Разработка вариантов концепции ИС, удовлетворяющих требованиям пользователя.

Стадия 3. «Техническое задание»

- Разработка и утверждение ТЗ на создание ИС

Стадия 4. «Эскизный проект»

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

- Разработка эскизной док-ции на ИС и ее часть.

Стадия 5. «Технический проект»

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

- Разработка док-ции на ИС и ее части (подсистемы)

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

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

Стадия 6. «Рабочая док-ция»

- Разработка раб. док-ции на ИС и ее части

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

Стадия 7. «Ввод действия»

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

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

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

- пусконаладочные работы:

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

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

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

Стадия 8. Сопровождение ИС

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

- послегарантийное обслуживание.

Стадия1. Обследование предм. области.

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

1)обоснование разработки и поэтапного внедрения ИС.

2)составление ТЗ на разработку ИС

3) разработки технич. и рабочего проектов ИС.

Осн. задача 1 этапа – обследование, оценка реального объема проекта (разработки ИС), его цели и задачи на основе вычисленных ф-ций и инф.элементов (объектов).

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

Стадия 2. Разработка концепции ИС.

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

Д. б. выявлены:

1) инструктивно-методические и директивные материалы, на основании которых определяется состав подсистем и перечень задач.

2) происходит сбор и фиксация инф-ции в 2х взаимосвязанных формах:

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

- сущности – инф-ция о вещах, имеющих значение для орг-ции.

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

- кол-во док-тов

- место формир-я показ-лей док-тов

- взаимосвязь док-тов при их формировании

- маршрут и длительность движения док-в

- место использ-я и хранения данного док.

- внутр. и внешн. инф. связи

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

На этом этапе обследования следует классиф-ть планируемые ф-ции разработанной системы по степени важности: MUSCOW:

must have – необх. ф-ции

should have – желательн. ф-ции

could have – возможн.ф.

won’t have – отсутствующие ф.

Ф-ции 1 категории обеспеч-т критичные для успешной работы ИС возможности. Реализация ф-ций 2 и 3 категории ограничивается временными и финансовыми рамками. Разрабатывается то, что необходимо, + макс. возможн. в порядке приоритета. 4 категория ф-ций особенно важна, поскольку при разработке ИС необх-мо четко представлять границы проекта и набор ф-й, кот. будет отсутствовать в системе.

Модель деят-ти орг-ции создается в 2х видах:

1.AS-IS – как есть. отражает сущ-щий в орг-ции бизнесс-процесс. Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной.

2. Найденные в модели AS—IS недостатки можно исправить при создании модели TO BE – как должно быть. Отражает необх-е измен-я бизнесс-процессов с учетом внедрения ИС. Рез-ты исследования представляют объективную основу для формирования ТЗ на ИС.

Реализация моделей с помощью CASE – средства

Термин CASE используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE (Computer Aided Software Engineering - автоматизированное проектирование программного обеспечения), ограничивалось вопросами автоматизации разработки только лишь программного обеспечения (ПО). В настоящее время термин CASE - (Computer Aided System Engineering - системы для структурного проектирования БД и связанных с ними ИС) подчеркивает направленность на поддержку концептуального проектирования сложных систем. Такие CASE-системы называют системами BPR (Business Process Reengineering - реинжиниринг бизнес-процессов компании. Значение слова инжиниринг - разработка, проектирование. Реинжиниринг - это подготовка проекта перехода от «как есть» к «как надо».

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

-- Функциональная модель системы описывает совокупность наполняемых системой функций.

-- Информационная модель отражает структуры данных — их состав и взаимосвязи.

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

-- Структурная модель характеризует морфологию системы (ее построение) - состав подсистем, их взаимосвязи. Каждая из представленных моделей имеет свою методику описания с помощью CASE-технологии. Взаимосвязанная совокупность методик концептуального проектирования IDEF (Integrated Definition (Icam DEFinition)разработана по программе Integrated Computer Aided Manufacturing в США. В этой совокупности имеются методики функционального, информационного и поведенческого моделирования и проектирования, в ее состав в настоящее время входят и другие IDEF—методики:

IDEF0 - Функциональное моделирование (Function Modeling Method, IDEF1 и IDEF1X - Информационное моделирование (Information and Data Modeling Methods), IDEF2 - Поведенческое моделирование (Simulation Modeling Method), IDEF3- Моделирование процессов (Process Flow and Object State Description Capture Method, IDEF4 - Объектно-ориентированное проектирование {Object-Oriented Design Method), IDEF5 - Систематизации объектов приложения (Ontology Description Capture method), IDEF6- Использование рационального опыта проектирования (Design Rationale Capture Method), IDEF8 - Взаимодействие человека и системы {Human—System Interaction Design), IDEF9- Учет условий и ограничений {Business Constraint Discovery), IDEF14 - Моделирование вычислительных сетей {Network Design).

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

--SADT (Structured Analysis and Design Technique) – технология структурного анализа и проектирования и ее подмножество стандарт IDEF;

-- DFD (Data Flow Diagrams) - диаграммы потоков данных;

-- ERD {Entity-Relationship Diagrams) - диаграммы «сущность-связь»;

-- STD (State Transition Diagrams) - диаграммы переходов состояний.