Информационные системы

Лекция 11. Спиральная модель жизненного цикла

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

Итерации.

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

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

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

Преимущества спиральной модели.

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

· итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

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

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

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

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

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

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

Проблемы, возникающие при использовании спиральной модели.

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

Методология и технология разработки информационных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методология RAD - Rapid Application Development

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

Лекция 12. Основные особенности методологии RAD

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

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

· небольшой команде программистов (обычно от 2 до 10 человек);

· тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до б мес.);

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

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

Основные принципы методологии RAD можно свести к следующему:

· используется итерационная (спиральная) модель разработки;

· полное завершение работ на каждом из этапов жизненного цикла не обязательно;

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

· необходимо применение CASE-средств и средств быстрой разработки приложений;

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

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

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

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

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

Объектно-ориентированный подход

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

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

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

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

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

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

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

Визуальное программирование

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

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

Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных-- с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разрабатываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как использонанием драйверов ODBC или OLE DB, так и применением специализированных средств (компонентов).

Специализированные средства разработки ориентированы только на создание приложений баз данных. Причем, как правило, они привязаны к вполне определенным системам управления балами данных. В качестве примера таких систем можно привести Power Builder фирмы Sybase (естественно, предназначенный для работы с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft. Поскольку задачи создания прототипов и разработки пользовательского интерфейса, по существу, слились, программист получил непрерывную обратную связь с конечными пользователями, которые могут не только наблюдать за созданием приложения, но и активно участвовать в нем, корректировать результаты и свои требования. Это также способствует сокращению сроков разработки и является важным психологическим аспектом, который привлекает к RAD все большее число пользователей.

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

Событийное программирование

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

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

Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPD ATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы данных при операциях удаления, вставки и обновления, а также автоматическую генерацию первичных ключей.

Лекция 13. Профили открытых информационных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· опубликовать профиль и/или продвигать его по формальным инстанциям для дальнейшего распространения.

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

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

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

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

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

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

Лекция 14. Общая структура профиля информационной системы

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

· определение целей использования данного профиля;

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

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

· сводку требований к информационной системе или ее компонентам, определяющих их соответствие профилю, и требований к методам тестирования соответствия;

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

· информационные ссылки на все исходные документы.

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

· профиль прикладного программного обеспечения;

· профиль среды информационной системы;

· профиль защиты информации в информационной системе;

· профиль инструментальных средств, встроенных в информационную систему.

Профиль прикладного программного обеспечения

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

Профиль среды информационной системы

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

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

· область графического пользовательского интерфейса;

· область реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам данных);

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

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

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

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

Профиль защиты информации

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

· функции, реализуемые операционной системой;

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

· функции управления данными, реализуемые СУБД;

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

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

· функции администрирования средств безопасности.

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

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

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

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

· управлением конфигурацией прикладного программного обеспечения, тиражированием версий;

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

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

· настройкой пользовательских интерфейсов (генерацией экранных форм и отчетов);

· ведением баз данных системы;

· восстановлением работоспособности системы после сбоев и аварий.

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

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

Лекция 15. Фазы жизненного цикла в рамках методологии RAD

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

· фаза анализа и планирования требований;

· фаза проектирования;

· фаза построения;

· фаза внедрения.

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

Фаза анализа и планирования требований.

На данной фазе выполняются следующие работы:

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

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

· проводится описание информационных потребностей;

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

· ограничивается масштаб проекта;

· определяются временные рамки для каждой из последующих фаз;

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

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

Фаза проектирования

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

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

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

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

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

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

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

· общая информационная модель системы;

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

· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранов, диалогов и отчетов.

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

Фаза построения

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

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

· определяется необходимость распределения данных;

· производится анализ использования данных;

· производится физическое проектирование базы данных;

· определяются требования к аппаратным ресурсам;

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

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

Фаза внедрения

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

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

Ограничения методологии RAD

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

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

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

Лекция 16. Стандарты и методики

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

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

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