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

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

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

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

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

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

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

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

Для нетерпеливых или тех, у кого мало времени: итоги вкратце и интересные ссылки в конце текста.

Начнем с очевидностей.
Очевидность #1: Информация нужна людям, чтобы принимать решения.
Очевидность #2: Информация может быть:

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

Очевидность #3: В любом из вышеперечисленных случаев вся работа над красотой, элегантностью и функциональностью интерфейсов представления информации теряют смысл. К примеру, при ложной информации идеальный интерфейс позволит пользователю быстро принять ложное решение.
Очевидность #4: Информация организована в некую структуру, которая имеет архитектуру.
Очевидность #5, итоговая: Если пользователь не находит нужную информацию или не воспринимает ее, заказчик или компания теряют прибыль.
В ходе работы UX-дизайнером в сфере ecommerce, я столкнулся с многообразием представлений об информационной архитектуре. Большей частью, ее воспринимают как один из несущественных аспектов проектирования взаимодействия. Как следствие, работе над информационной архитектурой не выделяется ни ресурсов, ни времени. В конечном итоге страдают пользователи, а компании теряют значительную долю доходов.

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

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

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

Что ж, приступим.

Зачем работать над информационной архитектурой?

Все совпадения с реальными персонажами, сервисами
и продуктами – случайны.

Что случилось с Иваном Владимировичем

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

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

Его выбор остановился на магазине «Eliteboose.com», о котором он слышал, что самый лучший выбор спиртного. С первого взгляда Ивана Владимировича впечатлил стильный и аккуратный дизайн сайта.

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

Он минут с 15 полистал предлагаемые продукты. К его разочарованию, рома в списке товаров не было. А предлагаемые подарки были далеки и от его нужд и от финансовых возможностей.

Уже сильно хотелось спать, но Иван Владимирович предпринял еще одну попытку, перейдя в другой пункт меню – «Для друзей». Среди многочисленного пива, водки и ликеров он наконец заметил и одинокий ром, притаившийся в конце списка. Бутыль Demo Anejo возможно была и неплохим выбором, но его смущало отсутствие выбора. Да и врял ли его шеф – руководитель департамента одного из ведущих банков страны - оценит подарок ценою всего лишь 13 долларов США.

Иван Владимирович вышел на балкон перекурить. Потом вернулся, сел за ноут и предпринял третью и последнюю попытку: выбрал пункт меню «Для застолья». И тут свершилось долгожданное чудо: он узрел впечатляющий список разнообразнейшего рома любой ценовой категории. Поразмышляв над списком пару минут, он добавил в корзину пятнадцатилетний ром Gran Demo Blender и с легкостью прошел процедуру заказа. Иван Владимирович был доволен собой но предчувствие колоссального недосыпа существенно отравляло настроение.

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

А теперь в цифрах

В вышеуказанной истории налицо проблема с ИА, пусть и утрированная. У Eliteboose.com мы видим нечетко очерченные и наименованные категории, неочевидную классификацию товаров по категориям.

Можем констатировать факт, что с Иваном Владимировичем магазину Eliteboose.com весьма повезло. Наш герой был а) достаточно упрям, чтобы не забить на идею купить ром в интернет-магазине, б) достаточно принципиален, чтобы не отказаться от покупки подарка в целом и в) достаточно инертным для того, чтобы уйти в конкурирующий интернет-магазин.

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

Адаптируем подход Джареда Спула (Jared Spool) , который он использовал для расчета стоимости фрустрации пассажиров от проблем с юзабилити для транспортной компании Amtrak:

Вычисляем идеальный потенциальный доход – Iideal=a*b , где а и b – средний чек и кол-во потенциальных покупателей (лидов) в день
Получаем совокупный недополученный доход – Iforgone= Iideal -(Iideal *x/100) , где x – доля отказов от покупки в целом
Узнаем стоимость ошибки в ИА – IAcost= Iforgone *y/100, $3500*20/100 , где y – доля отказов по вине ИА.

Пример
Дано:

Средний чек заказа – $100 ;
кол-во потенциальных покупателей (лидов) в день – 50 ;
доля отказов от покупки – 70% ;
из них, по вине ИА – 20% .

Считаем:

Идеальный доход – $100*50=$5000 в день
Совокупный недополученный доход –$5000-($5000*70/100)=$3500 в день
Стоимость ошибки в ИА – $3500*20/100 = $700 в день

Делаем вывод:
Стоимость погрешностей в ИА - $700 в день, $21.000 в месяц или $252.000 дохода в год.

В случае с корпоративным ПО, потери в потраченном времени сотрудников будут ничуть не менее существенными.

Но прежде чем переходить к решению проблемы, резонно возникает следующий вопрос:
«А что мы понимаем под информационной архитектурой?»

Что такое информационная архитектура?

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

«Это то, как организована информация? Где и что находится?»;
«Что-то из юзабилити, для удобства пользования сайтом?»;
«Точно, карта сайта! Да, конечно это полезно… Я, правда, ею не пользуюсь»;
«Навигация, вроде… Ну, как по сайту перемещаться»;

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

Ричард Сол Вурмен

Отец информационной архитектуры, Ричард Сол Вурмен (Richard Saul Wurman) , дает следующие определения информационной архитектуре:

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

Питер Морвиль и Луи Розенфельд в классической работе по ИА «Информационная архитектура в интернете» приводят целых четыре определения:

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

К Морвилю и Розенфельду присоединяется и Донна Спенсер , которая опирается на их определения в своей работе «Practical Guide to Information Architecture».

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

Предлагаю следующее (которое не противоречило бы вышеуказанным подходам к пониманию ИА):
«ИА – это схема организации информации сайта»

Лаконично и весьма абстрактно. Измеряемые показатели качества ИА должны быть вполне конкретными:

Скорость нахождения информации (KPI: кол-во шагов для нахождения информации или затраченное время);
Качество найденной информации (KPI: качественный показатель соответствия информации ожиданиям пользователя, от 1 до 10).

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

Отсюда вопрос номер два:
Если она так важна, каким образом интегрировать работу над ИА в общий процесс проектирования взаимодействия?

Как работать над информационной архитектурой?

Мне близка точка зрения Дэна Саффера (Dan Saffer) , который в своей работе «Designing for Interaction» рассматривает четыре практических подхода к проектированию взаимодействия, которые я привожу ниже. Как целесообразно работать над ИА в рамках каждого из подходов?

A. Ориентированный на пользователя (User-centered)

Идея: Пользователю виднее

Фокус: Цели и нужды пользователя

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

Где используется: крупные продуктовые компании, стартапы и digital-агентства.

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

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

Подпроцесс создания ИА

Заметка: метод исследования «Карточная сортировка» - далеко не единственный. Отличный сравнительный обзор методов исследования ИА описан Джимом Россом .

B. Ориентированный на деятельность (Activity-centered)

Идея: Отталкиваемся от задач пользователя.

Фокус: Деятельность пользователя.

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

Где используется: Как стартапы, так и аутсорсинговые компании.

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

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

Подпроцесс создания ИА

C. Дизайн системы (Systems design)

Идея: Пользователь – часть окружающей его системы.

Фокус: Окружение пользователя.

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

Где используется: Digital-агентства, крупные продуктовые компании.

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

Место ИА: непосредственное исследование и проектирование ИА здесь заменяется работой над архитектурой системы, с иным инструментарием и подходами.

D. «Гениальный» дизайн (Genius design)

Идея: Дизайнер – всему голова.

Фокус: Собственное понимание дизайна, эвристики дизайна (примеры можно посмотреть у

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

Классификация информационных систем по степени автоматизации

Основные понятия технологии проектирования

Лекция № 1

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Лекции по предмету информационных систем (ИС)

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

· хранение

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

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

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

o источника информации,

o аппаратной части ИС,

o программной части ИС,

o потребителя информации.

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

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

управляющие
советующие

Ситуационные центры (информационно-аналитические комплексы)

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

1. Традиционные архитектурные решения основаны на использовании выделенных файл-серверов (File-server) или серверов баз данных (Client-server).

2. Корпоративные информационные системы , базируются на технологии Internet (Intranet-приложения).

3. "Хранилища данных" (DataWarehouse) - интегрированные информационные среды, включающие разнородные информационные ресурсы.

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

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

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

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

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

Согласно статистическим данным , собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

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

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

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

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

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

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

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

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

каскадная модель (характерна для периода 1970-1985 гг.);
спиральная модель (характерна для периода после 1986.г.).

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

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

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

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

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

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

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

Методология проектирования ИС охватывает три основные области :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап проектирования завершается разработкой технического проекта ИС.

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

Введение

Заключение

Литература

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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