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

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

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

Рассмотрим по порядку эти характеристики. На переднем плане первые два пункта. Они представляют собой наиболее важное отличие от информационных систем, функционирующих в закрытых сетях. Мы не имеем возможности хранить и обрабатывать какую-либо информацию на стороне клиента. Все должно выполнятся на сервере. При разработке информационной системы с клиентским программным обеспечением можно было бы хранить часть пользовательской информации и обрабатывать ее на стороне клиента. Такая возможность позволила бы нам разгрузить сервер и трафик сети. Например, в случае анализа посетителей веб-сайтов, мы хранили бы основные объемы информации у клиентов, а на сервере - лишь общедоступные статистические отчеты, выжимки и сравнительные показатели с другими клиентами. Но мы не имеем такой возможности, поэтому надо тратить большие деньги на накопители жестких дисков и вычислительные мощности серверов. Многопользовательский доступ и разграничение доступа являются общими требованиями для всех информационных систем. Важным критерием является ограничение по объему передаваемой информации. На сервере может быть канал с большой пропускной способность, но по этому каналу идет информация от множества клиентов. В свою очередь, у пользователя информация идет только для него, но очень часто пользователи сидят на плохих каналах, например, на модемном соединении, или же просто, в силу удаленности и большого количества шлюзов между клиентом и сервером, скорость передачи информации очень медленная. В связи с тем, что в сети Интернет находится огромное количество людей, среди которых есть и злоумышленники, то необходимо предъявлять повышенные требования к безопасности. Вы не можете написать инструкцию пользователю: делай так, а не иначе, а вот здесь у нас дырка, чтобы ее обойти, делайте так-то. Вы не знаете, чего ожидать от пользователя. В связи с тем, что на сервере происходят все вычисления, и что пользователь хочет работать в режиме реального времени и не намерен ждать и 30 секунд, выполнение отдельно взятой CGI-программы должно происходить максимально быстро. И наконец, переносимость. Конечно, эта особенность не столь важна, но допустим, вам потребовалось открыть зеркало сайта на другом континенте. Принципиально надо решить две проблемы. Во-первых, настройка серверной платформы и вашего программного обеспечения для функционирования вашей информационной системы. Во-вторых, перевод системы на другой язык. На другом континенте может просто не оказаться ни требуемой вашей информационной системой платформы, ни специалистов, которые бы могли все это установить, настроить и поддерживать. Например, будет другая разновидность Unix. Все эти характерные особенности, в основном, и определяют стадию проектирования.

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

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

На первом этапе проектирования необходимо выяснить требования пользователей к системе и, на основании этих требований, сделать макет сайта, показывающего все HTML-формы и HTML-файлы отчетов взаимодействия с информационной системой. Желательно, чтобы HTML-формы содержали некоторые данные по умолчанию и ссылались на HTML-документы, которые, предполагается, будут результатом выполнения запроса к системе. В этом случае, пользователям будет легче понять, что же вы спроектировали.
Проектирование базы данных подробно обсуждалось в главе "Проектирование баз данных", поэтому здесь повторяться не будем. Отметим лишь, что данный этап скрыт от пользователей, и вся ответственность за выбор верного решения ложится на вас, как на разработчика.
На третьем этапе выясняется набор CGI-программ. Что делает каждая CGI-программа, и взаимосвязи между ними. Сразу хочется отметить одну очень распространенную ошибку начинающих веб-разработчиков, которые в одной программе реализуют несколько функций. Например, при разработке гостевой книги делается один CGI-скрипт, который вызывается во всех HTML-формах: и при показе сообщений, и при добавлении, еще хуже, если туда же включают функции администраторского доступа, т.е. удаление и редактирование сообщений. Есть три существенных причины, по которым не стоит так делать. Во-первых, это потенциальная дыра в безопасности. Во-вторых, загрузка и выполнение такой CGI-программы будет происходить медленнее. И в-третьих, такую программу сложно модифицировать, тестировать и отлаживать, т.к. она сама по себе представляет сложность из-за объема исходного текста.
Наиболее правильным решением является однозначная связь между функциональным требованием и CGI-программой. Одна функция (операция) - одна CGI-программа. В этом случае, исходный код будет простым и небольшим, а следовательно, значительно снижается вероятность пропустить в нем дыру в безопасности. Загрузка и выполнение такой программы будет происходить значительно быстрее. И самое главное, модифицировать и поддерживать такую программу будет значительно легче.
Помимо того, чтобы расписать, какая программа какую функцию выполняет, вам необходимо установить взаимосвязи между ними. Это такая паутинная схема. В простых системах она простая, в больших ее сложность возрастает нелинейно. Конечно, можно расставлять связи по месту. В простых системах вообще ничего не рисуют, т.к. и так все очевидно. Но вот в больших системах, особенно, если вы работаете в команде из нескольких человек, полезно иметь визуальное представление, откуда и какой CGI-скрипт вызывается, и куда вы попадете после его выполнения. Принципиально, как мы уже рассматривали в главе "CGI-программирвание", CGI-программа может выдавать либо текст, либо перенаправлять на другой адрес в Интернет, либо же выдавать картинку или еще какой файл. Вот такого рода схемку, набросанную от руки, полезно иметь, чтобы ясно представлять себе архитектуру проекта.

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

Часть 1. Этапы разработки проекта: стратегия и анализ

Введение "Водопад" - схема разработки проекта Стратегия Анализ ER-диаграммы Дуги Нормализация Диаграммы потоков данных Некоторые принципы проверки качества и полноты информационной модели Качество сущностей Качество атрибутов Качество связи Функции системы Уточнение стратегии

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В начало

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

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

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

В начало

Стратегия

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

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

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

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

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

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

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

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

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

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

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

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

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

что не будет реализовано в рамках проекта.

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

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

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

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

В начало

Анализ

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

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

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

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

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

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

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

модель "сущность-связь" (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

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

диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;

диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;

диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

В начало

ER-диаграммы

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

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

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

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

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

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

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

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

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

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

В начало

Дуги

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

Рис. 5. Дуга

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

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

В начало

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В начало

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

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

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

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

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

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

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

выполняют ориентированное на данные секционирование всей системы.

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

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

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

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

В начало

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

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

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

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

В начало

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

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

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

В начало

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

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

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

Отражает ли имя сущности суть данного объекта?

Нет ли пересечения с другими сущностями?

Имеются ли хотя бы два атрибута?

Всего атрибутов не более восьми?

Есть ли синонимы/омонимы данной сущности?

Сущность определена полностью?

Есть ли уникальный идентификатор?

Имеется ли хотя бы одна связь?

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

Ведется ли история изменений?

Имеет ли место соответствие принципам нормализации данных?

Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?

Не имеет ли сущность слишком общий смысл?

Достаточен ли уровень обобщения, воплощенный в ней?

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

Отсутствуют ли пересечения с другими подтипами?

Имеет ли подтип какие-нибудь атрибуты и/или связи?

Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?

Имеется ли исчерпывающий набор подтипов?

Не является ли подтип примером вхождения сущности?

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

В начало

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

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

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

Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?

Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?

Имеет ли атрибут только одно значение в каждый момент времени?

Отсутствуют ли повторяющиеся значения (или группы)?

Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?

Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?

Не может ли он быть пропущенной связью?

Есть ли необходимость в истории изменений?

Зависит ли его значение только от данной сущности?

Если значение атрибута является обязательным, всегда ли оно известно?

Есть ли необходимость в создании домена для этого и ему подобных атрибутов?

Зависит ли его значение только от какой-то части уникального идентификатора?

Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание жизненного цикла информационной системы предполагает оперирование такими понятиями:

Процесс - цепочка работ, последовательно выполняются;

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

Традиционно выделяют следующие основные этапы ЖЦ АИС :

Анализ требований;

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

Программирование / внедрения;

Тестирование и отладка;

Эксплуатация и сопровождение.

Рассмотрим подробнее основные этапы ЖЦ АИС:

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

Перечень требований к АИС должен включать:

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

2) описание функций, которые должен выполнять система;

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

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

Результатом этапа должна быть модель требований к системе (то есть - системный проект), что значит:

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

2) интерфейсы и разделение функций между человеком и системой;

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

Модель требований должна включать;

1) полное функциональную модель требований к будущей системе с глубиной обработки до уровня каждой операции каждого должностного лица;

2) спецификации операций нижнего уровня;

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

4) концептуальную информационную модель требований;

5) пакет отчетов и документов по информационной модели;

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

7) предложения по организации структуры для поддержки системы.

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

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

Описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

Уменьшить затраты на разработку и внедрение системы;

Оценить разработку по времени и результатам;

Достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами)

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

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

3) Модель требований может быть использована для самостоятельной разработки или корректировки уже реализованных на ее основе программных средств силами программистов отдела автоматизации предприятия.

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

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

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

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

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

Определение требований к программным средствам;

Разработку топологии, состава и структуры локальной вычислительной сети;

Требования к этапам и срокам выполнения работ.

3. Проектирование. Этот этап дает ответ на вопрос: "Как (каким образом) система будет удовлетворять требованиям, предъявляемым к ней? Задачей этого этапа

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

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

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

Иными словами, проектирование является этапом ЖЦ, на котором определяется, как следует реализовывать требования к ЛЕС, порожденные и зафиксированы на этапе анализа. В результате должна быть построена модель реализации, которая демонстрирует, как система будет удовлетворять предъявленные к ней требования (без технических подробностей). Фактически модель реализации является развитием и уточнением модели требований, а именно проектирования является мостом между анализом и реализацией.

4. Реализация (программирование / адаптация). На этом этапе осуществляется создание ЛЕС, как комплекса программно-аппаратных средств (начиная с проектирования и создания телекоммуникационной инфраструктуры и заканчивая разработкой и установкой приложений).

5. Тестирование и отладка. Корректность АИС является ее важнейшим свойством и главным предметом заботы разработчиков. В идеальном случае под корректностью 1C подразумевают отсутствие в ней ошибок. Однако для большинства сложных программных продуктов достичь этого невозможно (в каждой программе содержится хотя бы одна ошибка). Поэтому под "корректным" обычно понимают программный продукт, работающий в соответствии с предъявленных к нему требований, то есть - продукт, для которого пока еще не найдены такие условия, в которых он окажется неработоспособным.

Установление корректности является главной целью этапа жизненного цикла, рассматривается. Надо отметить, что этап тестирования и отладки - один из самых трудоемких, утомительных и непредсказуемых этапов разработки ИС. В среднем за разработки традиционными методами этот этап занимает от 1/2 до 1/3 всего времени разработки. С другой стороны, тестирования и отладки представляют собой серьезную проблему: в некоторых случаях тестирования и отладки программы требуют в несколько раз больше времени, чем непосредственно программирования.

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

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

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

1) формулировка целей тестирования;

2) критерии качества тестирования, позволяющие оценить его результаты;

3) стратегию проведения тестирования, обеспечивающий достижение заданных критериев качества;

4) потребности в ресурсах для достижения заданного критерия качества по выбранной стратегии.

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

6. Эксплуатация и сопровождение. Основными задачами этого этапа являются:

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

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

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

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

Особое внимание на этапе эксплуатации и сопровождения нужно уделить вопросам обучения персонала и, соответственно, планированию инвестиций в этот процесс.

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

Существующие модели ЖЦ определяют порядок выполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили следующие три модели ЖЩ4]:

1. Каскадная модель (70 - 80-е годы) предусматривает переход к следующему этапу после полного завершения работ на предыдущем этапе и характеризуется четким разделением данных и процессов их обработки (рис. 2.6).

Рис. 2.6. Каскадная модель жизненного цикла ИС

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

3. Спиральная модель (86 - 90-е годы) - заостряет внимание на начальных этапах ЖЦ: анализе требований, проектировании спецификаций, предыдущем и детальном проектировании. На этих этапах проверяется и обосновывается реализуемость технических решений созданием прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации (рис. 2.7.).

Рис. 2.7. Спиральная модель жизненного цикла ИС

Специалисты отмечают такие преимущества спиральной модели:

Накопление и повторное использование программных средств, моделей и прототипов;

Ориентация на развитие и модификацию системы в ходе ее проектирования;

Анализ риска и издержек в процессе проектирования.

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

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

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

Проектированием информационных систем называется многоступенчатый процесс их создания и/или модернизации путём применения упорядоченной совокупности методологий и инструментария. Проектирование (в отличие от моделирования) предполагает работу с пока несуществующим объектом и направлено на создание информационной системы в области:

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

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

Цель проектирования информационной системы и связанные понятия

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

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

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

Организация проектирования ИС

Организацию проектирования ИС принято разделять на 2 типа:

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

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

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

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

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

Этапы, в случае необходимости, можно укрупнять или детализировать – объединять последовательные этапы, исключать «лишние», начинать выполнение очередной стадии до завершения предыдущей.

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

Декомпозиция может иметь несколько уровней, что позволяет выделить классы ТПР:

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

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

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

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

Основные методологии проектирования ИС

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

SADT . Методология функционального моделирования работ, которая основана на структурном анализе и графическом представлении организации как системы функций. Тут выделяется функциональная, информационная и динамическая модели. В настоящее время методология известна как нотация (стандарт) IDEF0. Анализируемый процесс графически представляется в виде четырёхугольника, где сверху изображаются регламентирующие и управляющие воздействия, снизу – объекты управления, слева – входные данные, а справа – выходные.
RAD . Методология быстрой разработки приложений. В RAD быстрая разработка приложений возможна за счёт применения компонентно-ориентированного конструирования. Методология применяется на проектах с ограниченным бюджетом, нечёткими требованиями к ИС, при сжатых сроках реализации. К ней прибегают, если пользовательский интерфейс можно продемонстрировать в прототипе, а проект разделить на функциональные элементы.
RUP . В методологии RUP реализуются итерационный и наращиваемый (инкрементный) подходы. Построение системы происходит на базе архитектуры информационной системы, а планирование и проектное управление – на базе функциональных требований к ИС. Разработка общей информационной системы происходит итерациями, как комплекс отдельных небольших проектов со своими планами и задачами. Для итерационного цикла характерна периодическая обратная связь и адаптация к ядру ИС.

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Введение

1. Проектирование информационных систем. Общие принципы

1.2 Общая схема проектирования ИС

1.2.1 Структура процесса проектирования ИС

1.2.3 Документирование процесса проектирования ИС

Заключение

Список используемой литературы

Введение

информационная система консалтинг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· схема базы данных (на основании ER-модели, разработанной на этапе анализа);

· набор спецификаций модулей системы (они строятся на базе моделей функций).

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

· будет ли это архитектура "файл-сервер" или "клиент-сервер";

· будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

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

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

· будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB).

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

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

· обнаружение отказов модуля (жестких сбоев);

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

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

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

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

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

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

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

1.1 Основы создания и функционирования информационной системы

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

Компоненты системы:

Структура системы - множество элементов системы и и взаимосвязи между ними.

Функция каждого элемента.

Цели и ограничения системы и ее компонентов.

Вход и выход каждого элемента системы.

Свойства системы:

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

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

Компоненты ИС:

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

Обеспечивающая част ИС - состоит из информационной, программной, математической, технической, правовой, лингвистической, эргономической и метрологической частей.

Потребительские свойства ИС:

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

· Временная обеспеченность - возможность получения нужной информации в требуемое время.

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

· Эффективность - система должна приносить пользу.

· Адаптивность - она должна приспосабливаться к частично изменившимся условиям объекта и обеспечивать устойчивое функционирование на большом интервале времени.

· Иерархичность - возможность быть составной частью системы более высокого уровня.

Характерные особенности современных крупных проектов ИС:

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

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

· Отсутствие полных аналогов.

· Необходимость интеграции существующих и вновь разрабатываемых приложений.

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

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

· Значительная временная протяженность проекта.

Проблемы, с которыми сталкивается системный аналитик:

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

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

· Чрезмерное кол-во подробных сведений о предметной области и о новой системе у аналитика.

· Основополагающие принципы создания ИС:

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

· Принцип развития - ИС создается с учетом возможности постоянного пополнения и обновления системы и видов ее обеспечений.

· Принцип комплексности, обеспечение ИС связностью проектирования отдельных элементов и всего объекта в целом на всех стадиях.

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

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

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

· Принцип первого руководителя предполагает закрепление ответственности при создании системы за лицом отвечающим за ввод в действие и функционирование ИС.

· Принцип новых задач - поиск постоянных расширений возможностей системы.

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

· Принцип автоматизации проектирования имеет целью повысить эффективность самого процесса проектирования и создания ИС на всех уровнях деятельности.

· Непонимание спецификации системы из-за объема технических терминов заказчиком

· Организационно-технологические принципы:

· Принцип абстрагирования.

· Принцип формализации.

· Принцип концептуальной общности.

· Принцип непротиворечивости и полноты.

· Принцип независимости данных.

· Принцип структурирования данных.

· Принцип доступа конечного пользователя.

1.2 Общая схема проектирования ИС.

Основные принципы создания ИС:

· Управленческие (п 1.1).

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

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

Подходы к проектированию ИО:

· Дедуктивный.

· Индуктивный.

Общая схема проектирования ИО:

1. Анализ, определение всех типов решений, для принятия которых необходима информация.

2. Анализ и определение типа информации, которая требуется для принятия каждого решения.

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

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

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

1.2.1 Структура процесса проектирования ИС:

Подходы к проектированию и сопровождению ИС:

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

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

Составные части процесса создания ИС:

· Иерархическая структура системы; организация их проектирования

· Анализ и моделирование систем - задачи моделирования: создание моделей сложных систем, анализ свойств систем на основе анализа их моделей.

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

Аспекты представлений о проектируемых объектах:

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

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

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

· Структурное описание характеризует составные части системы и их межсоединяния.

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

Так же выделяют такие аспекты проектирования систем:

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

· Конструкторский - определение форм и пространственного расположения изделий.

· Алгоритмический - разработка алгоритмов и программного обеспечения.

· Технологический - разработка технологических процессов.

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

В соответствии с ГОСТ 34.201 можно выделить следующие стадии проектирования автоматизированной информационной системы (АИС):

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

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

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

Стадии проектирования ИО:

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

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

Методы изучения информационных потребностей и запросов:

1. Анализ управленческой документации и документооборота применительно к каждому уровню управления и рабочему месту специалиста. Нормативно-справочные виды документов, должностные инструкции, положения о деятельности подразделений дают возможность выяснить и оценить уровень ИО.

2. Проведение социологического исследования среди потенциальных пользователей системы ИО.

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

Для создания БД необходимо:

· Определить объем и характер информации.

· Классифицировать ее массив.

· Определить структуру БД.

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

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

· Порядок корректировки и пополнения БД.

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

Анализ информационных массивов осуществляется в два этапа: обследование; построение и анализ информационной модели организации.

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

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

Методы моделирования информационных связей:

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

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

1.2.3 Документирование процесса проектирования ИС.

Типы документации, формируемые в процессе создания ИС:

1. Предпроектная документация включает технико-экономическое обоснование и техническое задание.

2. Проектно-сметная документация содержит краткое описание проекта; описание комплекса технических средств; план мероприятий по подготовке объекта к внедрению; описание структуры системы.

1.3 Понятие консалтинга в области ИТ

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

1. Бизнес-консалтинг. Бизнес-анализ и реструктуризация (реинжиниринг бизнес процессов).

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

Так же важным элементом консалтинга является формирование рабочих групп.

Основные этапы разработки консалтинговых проектов:

1. Анализ первичных требований и планирование работ.

2. Проведение обследования деятельности предприятия.

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

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

5. Разработка предложения по автоматизации.

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

7. Разработка новой системы или настройка существующей. Программирование модулей, их тестирование и отладка.

1.4 CASE-технологии - методологическая и инструментальная база консалтинга

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

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

Заключение

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

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

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

Литература

1. Грекулов В.И., Денищенко Г.Н., Коровкина Интернет - университет информационных технологий - ИНТУИТ. ру, 2008г, 304 стр.

2. www.intuit.ru/department/se/devis/

3. Основы построения телекоммуникационных систем и сетей (Под редакцией Гордиенко В.Н. и Крухмалевой В.В. г. Москва, Горячая линия Телеком, 2004 год)

4. Компьютерные сети. Под редакцией Гагариной А.Г. г. Москва., Инфра, 2011 г.

5. Дж.Беллами Цифровая Телефония,г.Москва,Эко-Тренд,2005 год.

6. Олифер. Компьютерные сети. М. Вильяж, 2010 год.

Размещено на Allbest.ru

Подобные документы

Особенности проектирования информационных систем основанных на базах данных. Использование CASE-средств и описание бизнес процессов в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и визуальное представление web-сайта.

курсовая работа , добавлен 25.04.2012

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

курсовая работа , добавлен 17.06.2003

Области применения и реализации информационных систем. Анализ использования Web-технологий. Создание физической и логической модели данных. Проектирование информационных систем с Web-доступом. Функции Института Искусств и Информационных Технологий.

дипломная работа , добавлен 23.09.2013

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

курс лекций , добавлен 28.05.2010

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

реферат , добавлен 29.04.2010

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

дипломная работа , добавлен 22.11.2015

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

курсовая работа , добавлен 16.09.2011

Жизненный цикл автоматизированных информационных систем. Основы методологии проектирования автоматизированных систем на основе CASE-технологий. Фаза анализа и планирования, построения и внедрения автоматизированной системы. Каскадная и спиральная модель.

курсовая работа , добавлен 20.11.2010

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

контрольная работа , добавлен 30.09.2011

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