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

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

Но среди разработчиков информационных систем нередко практикуется «технологически конструктивистский» подход к своей деятельности. Люди увлекаются чисто техническими решениями типа «как получить такой-то эффект в новой версии», «как соединить одно с другим» и т. п. Разработка информационной системы при таком  подходе часто видится как подбор комбинации и организация взаимодействия технологических решений, предоставляющих возможность выполнения требуемой задачи. Однако, нужно помнить, что, кроме технической конкретики, не менее важны абстракции [DM1].

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

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

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

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

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

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

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

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

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

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

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

Для функционирования ИС необходимы следующие основные компоненты:

Рассмотрим кратко каждый из этих компонентов. Начнем с базы данных. Существует немало ее определений. Вот нестрогое определение БД, которое  Дейт (С. J. Date), один из известных экспертов в области баз данных, дает в начале своего учебного курса: «Базу данных можно рассматривать как подобие электронной картотеки, то есть хранилище для некоторого набора занесенных в компьютер файлов данных» [DATE6].

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

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

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

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

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

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

Между собственно БД (т. е. данными) и пользователями располагается уровень программного обеспечения – система управления базой данных. Все запросы пользователей на доступ к БД обрабатываются СУБД.

СУБД важный, но не единственный компонент программного обеспечения ИС. Среди других – упомянутые выше бизнес-приложения, утилиты, CASE-средства, генераторы отчетов и форм и т.д.

Технические средства информационных систем могут включать:

Одним из базовых понятий методологии разработки ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО).

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

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

Структура ЖЦ ПО по стандарту ISO/IЕС  12207 базируется на трех группах процессов:

Рассмотрим кратко некоторые из этих процессов [DM2].

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

Разработка ПО включает в себя, как правило:

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

Обеспечение качества проекта – связано с проблемами верификации, проверки и тестирования ПО.

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

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

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

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

Анализ является составной частью разработки информационной системы. Анализ – это подробное исследование бизнес-процессов (функций) и информации, необходимой для выполнения этих функций (сущностей с их атрибутами и связями). Моделирование является основным приемом анализа. Поэтому методы моделирования считаются частью анализа [DM3].

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

Вот два вида классических результатов анализа:

Проектирование выполняется на основе данных анализа и охватывает три основные области:

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

По завершении исходного проектирования следует этап реализации, на котором создаются и тестируются программные модули, определенные при проектировании. Главными результатами этого этапа являются модули исходного кода и объектные модули. После реализации переходят к тестированию системы, а затем к сдаче ее в эксплуатацию[DM7].

Важно понимать, что вплоть до запуска ИС в эксплуатацию вам придется постоянно возвращаться к этапам проектирования и анализа.

Использованы материалы [DM2].

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

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

В 70- и 80-х годах XX в. при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям (менеджеры, бухгалтеры) с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений.

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

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

качества;

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

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

CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

Использованы материалы [DM2].

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

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

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

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

Классификация CASE-средств по типам отражает их функциональную ориентацию на те или иные процессы ЖЦ и включает: