Информационная подсистема коммерческого отдела авиакомпании по продаже билетов на авиарейсы клиентам, отсутствующим в списке «клиенты постоянные»

МИНИСТЕРСТВО ФИНАНСОВ МОСКОВСКОЙ ОБЛАСТИ

КОРОЛЁВСКИЙ ИНСТИТУТ УПРАВЛЕНИЯ, ЭКОНОМИКИ И СОЦИОЛОГИИ

Кафедра информационных технологий и управляющих систем

КУРСОВОЙ ПРОЕКТ

по дисциплине «Проектирование информационных систем»

на тему

«Информационная подсистема коммерческого отдела авиакомпании по продаже билетов на авиарейсы клиентам, отсутствующим в списке „клиенты постоянные“»

Королёв 2012

РЕФЕРАТ

Курсовая работа: 56с., 14 рис., 4 табл., 4 источника.

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

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

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

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

· разработана диаграмма деятельности, моделирующая бизнес-процесс;

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

· разработана диаграмма классов, взаимодействующих в ИС;

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

· разработана диаграмма развертывания;

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

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

• ВВЕДЕНИЕ
• 1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ИНФОРМАЦИОННОЙ ПОДСИСТЕМЕ
• 1.1 Словесное описание содержания бизнес-процесса
• 1.2 Выбор метода моделирования информационных процессов в хозяйственной деятельности организации
• 1.2.1 Описание процессного подхода к моделированию
• 1.2.2 Описание объектного подхода к моделированию
• 1.2.3 Выбор метода
• 1.3 Определение требования к информационной подсистеме
• 1.3.1 Варианты использования проектируемой информационной подсистемы действующими лицами бизнес-процесса
• 1.3.2 Диаграмма деятельности, моделирующая бизнес-процесс
• 1.4 Выводы
• 2. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ
• 2.1 Спецификации вариантов использования информационной подсистемы
• 2.2 Интерфейсы пользователей информационной подсистемы. Запросы пользователей
• 2.3 Диаграммы интерфейсных классов, классов управления и сущностей
• 2.4 Ассоциации классов. Диаграммы последовательности и кооперативные
• 2.5 Атрибуты и методы классов
• 2.6 Диаграмма развертывания, показывающая состав аппаратного и обеспечивающего ПО информационной подсистемы
• 2.7 Выводы
• 3. ОЦЕНКА ТРУДОЕМКОСТИ И СТОИМОСТИ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. СТОИМОСТЬ АППАРАТНЫХ СРЕДСТВ
• 3.1 Определение весовых показателей действующих лиц
• 3.2 Определение весовых показателей вариантов использования
• 3.3 Определение технической сложности проекта
• 3.4 Определение уровня квалификации разработчиков
• 3.5 Оценка трудоемкости проекта
• 3.6 Стоимость аппаратных средств
• 3.7 Выводы
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• ПРИЛОЖЕНИЕ
• ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

Перечисленные проблемы породили потребность в программно-технологических средствах специального класса — CASE (Computer Aided Software Engineering) -средствах, реализующих CASE-технологию создания и сопровождения ПО ЭИС.

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

1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ИНФОРМАЦИОННОЙ ПОДСИСТЕМЕ

1.1 Словесное описание содержания бизнес-процесса

• информационный коммерческий авиарейс билет

Коммерческий отдел авиакомпании предложил расширить свой Web-сайт, чтобы пользователи смогли:

· узнать о выполнении рейсов текущего дня;

· запросить информацию о расписании рейсов, стоимости билетов и наличии мест;

· купить билеты.

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

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

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

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

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

· систему управления счетами, хранящую информацию о постоянных клиентах и балансе «премиальных километров»;

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

· базу данных тарифов;

· базу данных наличия билетов.

1.2 Выбор метода моделирования информационных процессов в хозяйственной деятельности организации

1.2.1 Описание процессного подхода к моделированию

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

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

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

— принцип решения сложных проблем их разбиения на множество меньших независимых задач, легких для понимания и решения;

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

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

1. SADT (Structured Analysis and Design Technique) — модели и соответствующие функциональные диаграммы;

2. DFD (Data Flow Diagrams) — диаграммы потоков данных;

3. ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь».

На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели «AS-IS» и модели «ТО-ВЕ», отражая, таким образом, существующую и предлагаемую структуру бизнес процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД).

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

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

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

1.2.2 Описание объектного подхода к моделированию

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

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

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются:

* абстрагирование (abstraction);

* инкапсуляция (encapsulation);

* модульность (modularity);

* иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

* типизация (typing);

* параллелизм (concurrency);

* устойчивость (persistence).

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

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

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

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

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

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

Устойчивость — свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве.

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

В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language).

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:

1. Информационная система (Use-case diagram), которая отображает функциональность ЭИС в терминах бизнес-процессов;

2. Диаграммы классов-объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов;

3. Диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;

4. Диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;

5. Диаграммы деятельности (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);

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

7. Диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;

8. Диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.

1.2.3 Выбор метода

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

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

Объектная декомпозиция имеет несколько преимуществ перед алгоритмической:

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

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

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

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

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

1.3 Определение требования к информационной подсистеме

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

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

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

Для наглядного представления вариантов использования применяются диаграммы вариантов использования.

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

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

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

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

Достоинства модели вариантов использования заключаются в том, что она:

— определяет пользователей и границы системы;

— определяет системный интерфейс;

— удобна для общения пользователей с разработчиками;

— используется для написания тестов;

— является основой для написания пользовательской документации;

— хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).

В процессе курсового проектирования были выделены следующие участники процесса и их действия:

1. Клиент

· Узнает о выполнении рейсов текущего дня;

· Запрашивает информацию о расписании рейсов, стоимости билетов и наличии мест;

· Покупает билеты.

2. База данных тарифов

3. База данных наличия билетов

4. Текущее время Рисунок 1.3.1 — Диаграмма вариантов использования

Для того, чтобы учитывать временные изменения рейсах, которые будут выполняться, следует обновлять временным таймером через какой-то промежуток времени данные таблицы «Рейсы, которые будут выполняться». Обновление таблицы «Рейсы, которые будут выполняться» будет осуществляться сверху — вниз процедурой procedure TForm1. Button1Click (Sender: TObject). Данная процедура копирует нужные строчки таблицы «Рейсы» и помещает их в первую запись таблицы «Рейсы, которые будут выполняться», остальные записи в данной таблице будут сдвигаться вниз, при этом последняя запись в таблице будет стираться (т.е. сначала данные о рейсе будут находиться в первой строчке таблицы БД и по мере обновления будут спускаться по строчкам таблицы вниз, последняя строчка будет стираться).

Чтобы учитывать временные изменения в выполненных рейсах, следует обновлять временным таймером через какой-то промежуток времени данные таблицы «Выполненные рейсы». Обновление таблицы «Выполненные рейсы» будет осуществляться сверху — вниз процедурой procedure TForm1. Button2Click (Sender: TObject). Данная процедура копирует нужные строчки таблицы «Рейсы» и помещает их в первую запись таблицы «Выполненные рейсы», остальные записи в данной таблице будут сдвигаться вниз, при этом последняя запись в таблице будет стираться.

Из разработанных диаграмм вариантов использования и диаграммы деятельности можно выделить основные требования к подсистеме.

Требования к подсистеме:

· предоставить информацию о расписании рейсов;

· предоставить информацию о расписании рейсов, стоимости билетов, наличии мест;

· продать билеты клиенту;

· накопить данные о поступивших заказов;

· подготовить информацию о выполненных рейсов;

· подготовить информацию о предстоящих рейсах.

Функциональные возможности

— система должна обеспечивать многопользовательский режим работы;

— система должна реализовывать все вышеперечисленные варианты использования.

Удобство использования

— доступ к пользовательскому интерфейсу должен осуществляться через Web-браузер.

Надежность

— система должна быть в работоспособном состоянии 24 часа в сутки, 7 дней в неделю. Время простоя не более 10%.

Производительность

— система должна поддерживать до 10 000 одновременно работающих с ней пользователей.

Безопасность

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

Проектные ограничения

— система должна быть интегрирована с рядом существующих систем (БД наличия билетов, БД тарифов, маркетинговой БД).

1.3.2 Диаграмма деятельности, моделирующая бизнес-процесс

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

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

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

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

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

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

Рисунок 1.3.2 — Диаграмма деятельности с плавательными дорожками, моделирующая бизнес-процесс

1.1. 1.4 Выводы

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

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

2. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ

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

Вариант использования «Узнать о выполнении рейсов текущего дня»

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

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

1. Осуществляется выборка информации из БД наличия билетов;

2. Web-сайт отображает сведения о выполнении рейсов текущего дня.

Альтернативные потоки Отсутствуют.

Предусловия Отсутствуют.

Постусловия Отсутствуют.

Вариант использования «Купить билеты»

Краткое описание Данный вариант использования позволяет клиенту купить билеты.

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

1. Web-сайт предлагает пользователю выбрать рейс и места.

2. Пользователь выбирает рейс и места.

3. Пользователь подтверждает покупку билетов.

4. В БД наличия билетов выбранные места на выбранный рейс помечаются как проданные.

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

— вернуться к началу основного потока;

— отказаться от покупки билетов и завершить работу с web-сайтом, при этом выполнение варианта использования завершается.

Предусловия Отсутствуют.

Постусловия Если вариант использования завершится успешно, то в БД наличия билетов и будут внесены изменения. Иначе состояние системы не изменится.

Вариант использования «Запросить информацию о расписании рейсов, стоимости билетов и наличии мест»

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

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

1. Пользователь выбирает дату для отображения информации;

2. Осуществляется выборка информации из БД тарифов и из БД наличия билетов;

3. Web-сайт отображает сведения о расписании рейсов, стоимости билетов и наличии мест.

Альтернативные потоки Отсутствуют.

Предусловия Отсутствуют.

Постусловия Отсутствуют.

Анализ бизнес- процессов

Цель анализа — подготовка к отображению концепции информационной системы в виде следующих диаграмм:

· вариантов использования;

· классов;

· ассоциации классов.

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

Концепция функционирования информационной подсистемы

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

1) Ввод и сохранение атрибутов заказов и атрибутов клиентов, обращавшихся в авиакомпанию с 1.01.2012 по настоящее время.

В течение года фиксировать всех клиентов.

2) Архивирование и сохранение данных о заказах клиентов в период с 1.01.2011 по 31.12.2011.

Формирование БД о рейсах, выполненных на истекшем 24 часовом интервале. Интервал является скользящим по оси времени.

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

Создать БД с расписанием рейсов на временном интервале равном длине периода повторения расписания во времени.

Иметь процедуру, обращающуюся с запросом к существующим:

1) БД тарифов авиарейсов

2) БД о наличии билетов на авиарейсы

2.1.1.1.6 Продажа билетов.

Возможные решения: 2.1.1.1.6.1 Терминал. Клиент вводит ответы на вопросы терминала. Вносит деньги. Терминал выдаёт билет. 2.1.1.1.6.2 Дистанционная оплата. Вариант достаточно сложный, его не рассматриваем.

БД, используемые информационной подсистемой

Готовые. Тарифы для авиарейсов и наличие мест на авиарейсы.

Создаваемые заново:

— БД для поступающих заказов текущая и архивная;

— БД о расписании авиарейсов на периоде повторяемости;

— Скользящая по времени БД выполненных рейсов;

— Скользящая во времени БД предстоящих рейсов.

Процедуры обработки сведений в БД

Процедура, формирующая информацию о расписании рейсов, стоимости билетов и наличии мест.

Процедура о выполнении рейсов текущего дня Процедура купить билеты

Уточнение концепции состава и назначения программных средств и таблиц БД WEB - сайта авиакомпании

Цель уточнения: используется для отображения взаимодействия классов посредством UML диаграмм с плавательными дорожками.

1. Имеем адрес WEB — сайта авиакомпании на сайте адресов транспортных предприятий города или области.

2. Уточнённая концепция.

2.1 Новая домашняя страница WEB — сайта с перечнем существующих и новых информационных услуг.

2.2 СУБД.

2.3 Программы, содержащие SQL операторы, извлекающие из таблиц БД запрашиваемые клиентом сведения.

2.4 БД с таблицами:

· готовыми;

· новыми:

Ш со скользящим временным интервалом;

Ш постоянным периодом;

Ш с атрибутами клиентов и их заказов.

2.5 Динамические HTML — страницы для передачи клиенту сведений извлечённых SQL запросами из таблиц БД.

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

2.7 Датчик текущего времени

2.8 Программа, запускаемая на выполнение по прерываниям от датчика текущего времени и обеспечивающая:

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

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

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

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

2.2 Интерфейсы пользователей информационной подсистемы. Запросы пользователей

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

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

На форме расположены следующие компоненты:

· DBGrid_ADOData (таблица) — для вывода таблиц БД;

· Edit_ADODataSet (поле) — для ввода даты вылета;

· Button1 (кнопка) — для поиска и вывода рейсов на определенную дату;

· Button4 (кнопка) — для вывода всех рейсов;

· Edit1 (поле) — для ввода № рейса (узнать наличие свободных мест);

· Button5 (кнопка) — для поиска и вывода свободных мест на нужный № рейса;

· Button3 (кнопка) — для вывода всех свободных мест на все рейсы;

· Button2 (кнопка) — для вывода стоимости билетов;

· Button6 (кнопка) — для вывода списка самолетов всего авиапарка;

· Button7 (кнопка) — для вывода списка авиабилетов.

На рисунке 2.2.1 показано расписание всех рейсов:

Рисунок 2.2.1 - Расписание всех рейсов

На рисунке 2.2.2 показано расписание рейсов на дату, введенную пользователем:

Рисунок 2.2.2 - Расписание рейсов на дату

На рисунке 2.2.3 показаны все свободные места на все рейсы:

Рисунок 2.2.3 - Все свободные места на все рейсы

На рисунке 2.2.4 показаны свободные места рейс, введенный пользователем:

Рисунок 2.2.4 - Свободные места на рейс, введенный пользователем

На рисунке 2.2.5 показана стоимость билетов:

Рисунок 2.2.5 — Стоимость билетов На рисунке 2.2.6 показан список самолетов всего авиапарка:

Рисунок 2.2.6 — Список самолетов всего авиапарка На рисунке 2.2.7 показан список всех авиабилетов:

Рисунок 2.2.7 — Список всех авиабилетов На рисунке 2.2.8 приведена схема базы данных информационной подсистемы:

Рисунок 2.2.8 — Схема БД

Перечень запросов:

— Запросить сведения о расписании всех рейсов — выборка данных из таблицы «Рейсы»;

select * from Рейсы

— Запросить сведения о расписании рейсов на определенную датувыборка данных из таблицы «Рейсы»;

select * from Рейсы where дата_вылета like '''+Form1.Edit_ADODataSet.Text+'%''

— Запросить сведения о свободных местах на все рейсы — выборка данных из таблицы «Рейсы», «Самолеты»;

SELECT Рейсы.№_рейса, [Самолеты]. Кол-во_мест]-[Запрос3]. Занятые_места] AS Свободные_места'+ ' FROM Самолеты INNER JOIN (Рейсы INNER JOIN Запрос3 ON Рейсы. ID_рейса = Запрос3.№_рейса) ON Самолеты.№_самолета = Рейсы. Самолет

— Запросить сведения о свободных местах на определенный рейс — выборка данных из таблицы «Рейсы», «Самолеты»;

SELECT Рейсы.№_рейса, [Самолеты]. Кол-во_мест]-[Запрос3]. Занятые_места] AS Свободные_места'+ ' FROM Самолеты INNER JOIN (Рейсы INNER JOIN Запрос3 ON Рейсы. ID_рейса = Запрос3.№_рейса) ON Самолеты.№_самолета = Рейсы. Самолет'+ ' where Рейсы.№_рейса like '''+Form1.Edit1.Text+'%''

Запрос 3 (занятые места по номерам рейсов):

SELECT Авиабилет.№_Рейса, Count (Авиабилет.№_рейса) AS Занятые_места FROM Авиабилет GROUP BY Авиабилет.№_Рейса;

— Запросить сведения о стоимости авиабилетов — выборка данных из таблицы «Тип билета»;

select * from Тип_билета

— Запросить сведения о самолетах авиапарка — выборка данных из таблицы «Самолеты»;

select * from Самолеты

— Запросить сведения об авиабилетах — выборка данных из таблицы «Авиабилет», «Пассажир», «Рейсы, «Тип билета»;

SELECT Авиабилет.№_билета, Авиабилет. дата_покупки, Авиабилет. время_покупки, Авиабилет.№_места, Пассажир. Паспорт, Рейсы.№_рейса, Тип_билета.Тип

FROM Тип_билета INNER JOIN (Рейсы INNER JOIN (Пассажир INNER JOIN Авиабилет ON Пассажир. ID_пассажир = Авиабилет. Паспорт) ON Рейсы. ID_рейса = Авиабилет.№_рейса) ON Тип_билета.ID_тип = Авиабилет. Тип;

2.3 Диаграммы интерфейсных классов, классов управления и сущностей

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

* ассоциации (например, клиент может сделать заказ);

* подтипы (частный клиент является разновидностью клиента)

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

2.4 Ассоциации классов. Диаграммы последовательности и кооперативные

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

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

Диаграммы ассоциации классов (показаны на Рисунке 2.4.1):

Рисунок 2.4.1 — Диаграммы ассоциации классов

Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов (в рамках варианта использования или некоторой операции класса).

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

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

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

Сообщение-запрос (interrogative) — сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

Императивное (imperative) сообщение — сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.

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

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

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз.

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

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

Диаграмма взаимодействия (последовательности) (показана на Рисуноке 2.4.2):

Рисунок 2.4.2 — Диаграммы последовательности

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

Кооперативная диаграмма (показана на Рисуноке 2.4.3):

Рисунок 2.4.3- Кооперативная диаграмма

1) Номера в прямоугольниках соответствуют номерам классов диаграммы взаимодействия.

2) Номера над дугами соответствуют номерам текстов над стрелками диаграммы взаимодействия

3) Кооперативная диаграмма используется для планирования процесса отладки программ информационной системы Web-сайта в связи с тем, что она показывает количество обращений из процедур класса i к процедурам класса j.

2.5 Атрибуты и методы классов

· Класс интерфейса клиента

· Класс поисковика

· Класс «Начальная страница Web-сайта»

· Класс с SQL-операторами

2.6 Диаграмма развертывания, показывающая состав аппаратного и обеспечивающего ПО информационной подсистемы

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

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

Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. Ее основные элементы:

— узел (node) — вычислительный ресурс — процессор или другое устройство (дисковая память, контроллеры различных устройств и т. д;

— соединение (connection) — канал взаимодействия узлов (сеть).

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

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

— масштабируемость;

— конфигурируемость — изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

— высокая безопасность;

— высокая надёжность;

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

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

Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

— более высокая сложность создания приложений;

— сложнее в развертывании и администрировании;

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

— высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

Диаграмма развертывания показана на Рисунке 2.6:

Рисунок 2.6 — Диаграмма развертывания для проектируемой ИС

Состав обеспечивающего ПО на стороне клиента:

· Internet Explorer

Состав обеспечивающего ПО на сервере:

· IIS — служба Internet Information Services

· Delphi 7.0 — для создания источника ODBC, создания динамических html-страниц

· СУБД — Microsoft Access 2003

· Блокнот — для создания шаблонов динамических страниц

2.7 Выводы

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

3. ОЦЕНКА ТРУДОЕМКОСТИ И СТОИМОСТИ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. СТОИМОСТЬ АППАРАТНЫХ СРЕДСТВ.

3.1 Определение весовых показателей действующих лиц

Все действующие лица разрабатываемой подсистемы делятся на три типа: простые, средние и сложные.

Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом (API). В настоящем курсовом проекте простым действующим лицом являются «БД наличия билетов», «БД тарифов». Среднее действующее лицо представляет либо внешнюю систему, взаимодействующую с данной системой посредством протокола наподобие TCP/IP, либо личность, пользующуюся текстовым интерфейсом. В настоящем курсовом проекте отсутствуют средние действующие лица.

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

Таблица 1

Таким образом, весовой показатель действующих лиц равен:

А = 2· 1 + 1· 3 = 5

3.2 Определение весовых показателей вариантов использования

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

Подсчитанное количество вариантов использования каждого типа умножается на соответствующий весовой коэффициент, затем вычисляется общий весовой показатель UCP (use case points — количество вариантов использования).

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

Таблица 2

Таким образом, общий весовой показатель равен:

UСР = 5· 2 + 10· 1=20

В результате получаем показатель UUCP (unadjusted use case points — количество вариантов использования без учета поправочного коэффициента):

UUCP = A + UCP = 20 + 5= 25

3.3 Определение технической сложности проекта

Техническая сложность проекта (TCF — technical complexity factor) вычисляется с учетом показателей технической сложности.

Таблица 3

Каждому показателю присваивается значение Ti в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 — высокую значимость). Значение TCF вычисляется по следующей формуле:

TCF = 0,6+(0,01*(?T_i *Вес_i))

Вычисленное значение TCF для проектируемой ИС:

TCF = 0,6 +(0,01 * 49) =1,09.

3.4 Определение уровня квалификации разработчиков

Уровень квалификации разработчиков (EF — environmental factor) вычисляется по формуле:

EF = 1,4 + (-0,03· (?F_i·Вес_i))

где F_i — показатель уровня сложности.

Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1 — F4 0 означает отсутствие, 3 — средний уровень, 5 — высокий уровень. Для показателя F5 0 означает отсутствие мотивации, 3 — средний уровень, 5 — высокий уровень мотивации. Для F6 0 означает высокую нестабильность требований, 3 — среднюю, 5 — стабильные требования. Для F7 0 означает отсутствие специалистов с частичной занятостью, 3 — средний уровень, 5 — все специалисты с частичной занятостью. Для показателя F8 0 означает простой язык программирования, 3 — среднюю сложность, 5 — высокую сложность.

Таблица 4

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

EF = 1,4 + (-0,03· 16,5) = 0,905

В результате получаем окончательное значение UCP:

UCP = UUCP· TCF·EF = 65· 1,09·0,905 = 64,12

3.5 Оценка трудоемкости проекта

В качестве начального значения предлагается использовать 20 человеко-часов на одну UCP. Эта величина может уточняться с учетом опыта разработчиков.

Для уточнения этой величины надо рассмотреть показатели F1—F8 и определить, сколько показателей F1—F6 имеют значение меньше 3 и сколько показателей F7-F8 имеют значение больше 3. Если общее количество меньше или равно 2, следует использовать 20 чел.-ч. на одну UCP, если 3 или 4 — 28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск провала слишком высок.

Для разрабатываемой подсистемы на одну UCP получается 20 человеко-часов, таким образом, общее количество человеко-часов на весь проект равно 20*64,12=1282,4 человека-часа, что составляет 33 недели при 40-часовой рабочей неделе. Если предположить, что команда разработчиков состоит из четырех человек, и добавить 3 недели на различные непредвиденные ситуации, тогда в итоге получается 12 недель на весь проект.

3.6 Стоимость аппаратных средств

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

— сервер БД;

— север приложений.

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

Допустим, что аппаратные средства должны обеспечивать возможность работы с ИС одновременно 10 000 клиентов. В таком случае стоимость каждого из серверов будет около 250 тыс. руб., а значит стоимость аппаратных средств составит 500 тыс. руб.

3.7 Выводы

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

ЗАКЛЮЧЕНИЕ

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

Внедрение спроектированной подсистемы в работу авиакомпании позволило бы:

· повысить число клиентов авиакомпании;

· упростить и ускорить процесс покупки билетов;

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: учебник. — 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006.

2. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. — 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006.

3. Смирнова Г. Н., Сорокин А. А., Тельнов Ю. Ф. Проектирование экономических информационных систем: учебник. — М.: Финансы и статистика, 2003.

4. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. — М. Диалог МИФИ, 2005 г

ПРИЛОЖЕНИЕ

ГЛОССАРИЙ ПРОЕКТА