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

Содержание 

Введение………………………………………………………………………………….......3

1. Стратегия и анализ проектирования информационных систем…………..…...….4
2. Определение стратегии тестирования и проектирование …………………..……8
3. Заключительные стадии проектирования, схема базы данных ……………........10

Заключение……………………………………………………………………………….....13

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

Введение 

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

1. Требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;
2. Требуемую пропускную способность системы;
3. Требуемое время реакции системы на запрос;
4. Безотказную работу системы в требуемом режиме, иными словами - готовность и доступность системы для обработки запросов пользователей;
5. Простоту эксплуатации и поддержки системы;
6. Необходимую безопасность.

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

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

1. Проектирование объектов данных, которые будут реализованы в базе данных;
2. Проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
3. Учет конкретной среды или технологии.

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

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

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

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

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

         
 
 
 

Рисунок 1 – Схема «Водопад»

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

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

       Стратегия

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

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

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

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

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

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

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

       Анализ

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

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

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

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

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

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

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

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

• диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;
• диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;
• диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

 
 
 
 
 
 
 
 
 

       2 Определение стратегии тестирования и проектирование 

       Определение стратегии тестирования

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

       Для автоматизации тестирования следует  использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.

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

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

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