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

[1], гл. 1, стр. 15 – 58

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

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

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

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

В последнее время ведущие зарубежные аналитики отмечают как одну из причин многих неудач тот факт, что множество проектов выполняется в экстремальных условиях. В англоязычной литературе с легкой руки Эдварда Йордана, одного из ведущих мировых специалистов в области программирования инженерии, утвердилось выражение «deathmarch», буквально – «смертельный марш». Под ним понимается такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50%. По отношению к проектам создания ПО это означает наличие, как минимум, одного из следующих ограничений:

• план проекта сжат более чем на половину по сравнению с нормальным расчетным планом;

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

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

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

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

Впервые этот термин был использован как тема конференции, проводившейся под эгидой NATO в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии.

В процессе становления и развития программной инженерии можно выделить два этапа: 70-е и 80-е гг. – систематизация и стандартизация процессов создания ПО (на основе структурного подхода) и 90-е гг. – начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода).

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

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

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

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

Язык моделирования должен включать: элементы модели – фундаментальные концепции моделирования и их семантику; нотацию – визуальное представление элементов моделирования; руководство по использованию – правила применения элементов в рамках построения тех или иных типов моделей ПО.

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

Понятие жизненного цикла программного обеспечения (ЖЦ ПО) является одним из базовых в программной инженерии. Жизненный цикл программного обеспечения определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 "Information Technology – Software Life Cycle Processes" (ISO – International Organization for Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (или программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документации данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.

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

В соответствии со стандартом ISO/IEC12207 все процессы ЖЦ ПО разделены на три группы (рис.1).

Жизненный цикл ПО в соответствии с подходом RAD включает четыре стадии:

1) анализ и планирование требований;

2) проектирование;

3) реализация;

4) внедрение.

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

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

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

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

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

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

Рис.1. Процессы жизненного цикла программного обеспечения

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

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

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

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

Рис.2. Контекст технологической операции проектирования

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

Пример 1.

Требуется описать процесс приобретения программного обеспечения АСУ котла согласно стандарту ISO/IEC12207.

Согласно стандарту ISO/IEC12207 процессы жизненного цикла программного обеспечения АСУ котла можно разделить на 3 группы: основные, вспомогательные и организационные. Согласно стандарту ISO/IEC12207 процесс приобретения программного обеспечения АСУ котла можно отнести к основным процессам.

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

1) инициирование приобретения;

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

3) подготовку и корректировку договора;

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

5) приемку и завершение работ.

Инициирование приобретения ПО АСУ котла включает следующие задачи:

• определение заказчиком своих потребностей;

• анализ требований к системе;

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

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

Заявочные предложения должны содержать:

• требования к системе;

• условия и соглашения;

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

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

Подготовка и корректировка договора включают следующие задачи:

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

• выбор конкретного поставщика на основе анализа предложений;

• подготовку и заключение договора с поставщиком;

• внесение изменений (при необходимости) в договор в процессе его выполнения.

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

ТЕМА 2. АНАЛИЗ И МОДЕЛИРОВАНИЕ ФУНКЦИОНАЛЬНОЙ ОБЛАСТИ ВНЕДРЕНИЯ ПРОГРАММНЫХ СИСТЕМ

Поиск по сайту: