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

Вид работы:

Дипломная (ВКР)
Предмет:

Информационное обеспечение, программирование
Язык:

Русский
,
Формат файла:
MS Word

4,17 Mb
Опубликовано:

2011-06-29

Все дипломные работы по информационному обеспечению

Скачать дипломную работу Читать текст online Заказать дипломную
*Помощь в написании! Посмотреть все дипломные работы

Вы можете узнать стоимость помощи в написании студенческой работы.

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

. РЕЗУЛЬТАТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ ГОУ ВПО "Северо-Кавказский Государственный Технический Университет". ФОРМУЛИРОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ

.1 Результаты предпроектного обследования

.1.1 Объекты и методы проведения предпроектного обследования

.1.2 Программа проведения обследования

.1.3 Результаты предпроектного обследования и их анализ

.1.4 Анализ проблемных ситуаций и обоснование путей их решения

.2 Формулировка задач проектирования

.2.1 Общие сведения

.2.2 Назначение, цели создания интерактивных сервисов

.2.3 Характеристика объекта автоматизации

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

.2.5 Состав и содержание работ по созданию подсистемы

.2.6 Порядок контроля приемки подсистемы

.2.7 Требования к составу и содержанию работ по подготовке объекта

автоматизации к вводу интерактивного сервиса в действие

.2.8 Требование к документированию

.2.9 Источники разработки

Выводы

2. РЕАЛИЗАЦИЯ ИНТЕРАКТИВНЫХ СЕРВИСОВ

.1 Обоснование выбора среды реализации сервисов

.3 Концептуальное проектирование интерактивных сервисов

.4 Создание логической модели базы данных интерактивных сервисов

.3.1 Определение сущностей модели базы данных

.3.2 Определение атрибутов сущностей базы данных интерактивного сервиса

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

.3.4 Задание первичных ключей сущностей

.3.5 Логическа модель данных

.4 Создание физической модели базы данных интерактивных сервисов

2.4.1 Генерирование SQL-сценария создания базы данныхинформационной подсистемы средствами Django ORM

.5 Создание проекта и модулей

2.6 Реализация интерактивных сервисов

2.6.1 Разработка интерфейса сервисов

.6.2 Создание модели данных

.6.3 Создание представлений и привязок URL

.6.4 Реализация формы обратной связи

.6.5 Реализация формы поиска

.6.6 Пользовательская проверка орфографии в сервисе

.6.7 Настройка Web-сервера lighthttpd

Выводы

. ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

.1 Общие сведения об интерактивных сервисах доступа к справочнику СевКавГТУ г. Ставрополь

.2 Функциональное назначение интерактивных сервисов доступа к телефонному справочнику СевКавГТУ г. Ставрополь

.3 Описание логической структуры интерактивных сервисов доступа к телефонному справочнику СевКавГТУ, г. Ставрополь

.4 Требование к техническому обеспечению

.4.1 Общие требования

.4.2 Требования к центральному процессору

.4.3 Требования к оперативному запоминающему устройству

.4.4 Требования к наличию сводного места на жестком диске

.4.5 Требования к монитору

.4.6 Требования к принтеру

.5 Установка и вызов интерактивных сервисов

.6 Входные данные интерактивных сервисов

.6.1 Входные данные сервиса вывода телефонных номеров

.6.2 Входные данные интерактивного сервиса генерации текстовой версии телефонного справочника

.7 Выходные данные

.7.1 Выходные данные интерактивных сервисов вывода телефонных номеров

.8 Результаты тестирования

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

Выводы

4. Технико-экономическое обоснование проекта

4.1 Краткая характеристика проекта

4.2 Трудоёмкость выполняемых работ

4.3 Расчёт себестоимости интерактивных сервисов

4.4 Оценка экономической эффективности внедрения программного продукта

4.5 Основные технико-экономические показатели проекта

Выводы

ЗАКЛЮЧЕНИЕ

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

Актуальность разработки интерактивных сервисов доступа к расписанию занятий СевКавГТУ, г. Ставрополь обусловлена отсутствием быстрого и удобного доступа к контактным данным сотрудников и подразделений ГОУ ВПО "Северо-Кавказский Государственный Технический Университет" (далее ВУЗ).

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

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

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

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

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

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

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

В библиографическом списке указан перечень из 23 источников информации.

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

интерактивный программирование база данный

1. РЕЗУЛЬТАТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ ГОУ ВПО "Северо-Кавказский Государственный Технический Университет". ФОРМУЛИРОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ

1.1 Результаты предпроектного обследования

1.1.1 Объекты и методы проведения предпроектного обследования

В рамках темы дипломного проекта объектами обследования являются:

а) Образовательно-информационный отдел ВУЗа;

б) организационно-функциональная структура ВУЗа;

в) организация документооборота ВУЗа.

Обследование предприятия производится путем опроса сотрудников ВУЗа.

Основными целями выполнения предпроектного обследования являются:

а) изучение предметной области;

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

в) интеграция с IP-телефонией ВУЗа.

1.1.2 Программа проведения обследования

Программа обследования ВУЗа представлена в таблице 1.1.

Таблица 1.1 - Программа обследования предприятия

Наименование вопроса	Источник информации	Получатель информации
Общая характеристика	Устав СевКавГТУ	Проектировщик Сучков Р.Г.
Организационная структура	Аналогично	Аналогично
Цели деятельности	Аналогично	Аналогично
Наличие проблемных ситуаций в деятельности СевКавГТУ	Аналогично	Аналогично
Цели деятельности ОИЦ	Директор ОИЦ, положение о ОИЦ СевКавГТУ	Аналогично
Наличие проблемных ситуаций в деятельности ОИЦ	Директор ОИЦ	Аналогично
Наличие средств вычислительной техники и программного обеспечения в ОИЦ	Заместитель директора ОИЦ	Аналогично

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

.1.3 Результаты предпроектного обследования и их анализ

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

Полное наименование университета: государственное образовательное учреждение высшего профессионального образования "Северо-Кавказский государственный технический университет". Сокращенное наименование - СевКавГТУ.

Место нахождения СевКавГТУ: Россия, Ставропольский край, г. Ставрополь, проспект Кулакова, дом 2. Почтовый адрес: Россия, 355029, г. Ставрополь, проспект Кулакова, дом 2.

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

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

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

Рисунок 1.1 - Схема организационной структуры ВУЗа

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

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

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

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

В составе учреждения целесообразно выделить четыре области управления:

) управление планированием;

) управление учебным процессом;

) управление обеспечением;

) управление научной деятельностью.

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

Таблица 1.2 - Функциональные области и процессы в них протекающие

Номер и название функциональной области	Функциональные процессы
1. Управление планированием	1.1 Прогнозирование спроса на выпускаемых специалистов
	1.2 Внесение изменений в сроки, периоды обучения, графики проведения экзаменов и зачетов
	1.3 Составление требований к подготовке специалистов
2. Управление учебным процессом	2.1 Составление расписания занятий
	2.2 Распределение нагрузки преподавателям
	2.3 Разработка учебно-методических пособий
	2.4 Организационно-воспитательная деятельность
	2.5 Организация учебного процесса
3. Управление обеспечением	3.1 Управление кадрами
	3.2 Управление материальными средствами
	3.3 Делопроизводство
4. Управление научной деятельностью	4.1 Организация и планирование научно-исследовательских работ по инновационной деятельности и проведения фундаментальных и поисковых исследований
	4.2 Организация семинаров, конференций
	4.3 Создание наиболее благоприятных условий при подготовке специалистов и создании кандидатских и докторских диссертаций

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

Х - полное участие в процессе;

/ - частичное участие в процессе;

- ответственность за выполнение процесса.

Таблица 1.3 - Организационно-управленческая модель ВУЗа

Функциональные области

Управление планированием

Управление учебным процессом

Управление обеспечением

Управление научной деятельностью

Ответственные лица

1.1

1.2

1.3

2.1

2.2

2.3

2.4

2.5

3.1

3.2

3.3

4.1

4.2

4.3

Проректор

×/

Бухгалтерия

×/

УМУ

×/

Деканаты

×/

Отдел кадров

×/

Общий отдел

ОИЦ

×/

НТЦ

Лаборатории

×/

Кафедры

×/

Диспетчерская

0×

Цели функционирования. В результате проведенного обследования ВУЗа были выделены основные цели, средства их достижения и сформулированы критерии эффективности применяемых мер. Главной целью функционирования является подготовка высококвалифицированных специалистов для удовлетворения потребности общества в высококвалифицированных кадрах, разработка и внедрение результатов научных исследований, проведение семинар и научных конференций. Правильно построенное дерево целей в дальнейшем легко может быть преобразовано в план-график или диаграмму Ганта [1].

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

Таблица 1.4 - Цели деятельности ВУЗа, средства достижения и критерии оценки уровня достижения цели

Цель	Средства достижения	Критерий эффективности
Ц₁ - улучшение качества образования	Ц₁₁ - совершенствование учебно-технологической базы Ц₁₂ - совершенствование научно-методической базы Ц₁₃ - совершенствование программ обучения Ц₁₄ - внедрение новых и улучшение существующих средств контроля качества образования Ц₁₅ - поощрение лучших студентов Ц₁₆ - подбор профессорско-преподавательского состава Ц₁₇ - проведение работ по повышению квалификации специалистов	Проведение и победы в региональных, федеральных и международных олимпиадах, участие в конференциях, хозяйственно-договорных тематиках Увеличение количества договоров о проведении производственной практики и договоров о сотрудничестве с университетом сторонних организаций на 20 %
Ц₂ - выполнение научно-исследовательских и опытно-конструкторских работ, проведение фундаментальных научных исследований	Ц₂₁ - привлечение студентов и сотрудников университета к НИР Ц₂₂ - стимулирование проведения НИР Ц₂₃ - обеспечение необходимым оборудованием Ц₂₄ - финансирование НИР Ц₂₅ - сотрудничество с НИИ, КБ и сторонними организациями	Увеличение числа завоеванных грантов, проводимых научных хозяйственно-договорных тематик, внедренных результатов НИР, количества публикаций и участий в научных конференциях
Ц₃ - эффективная организация деятельности университета	Ц₃₁ - обеспечение университета необходимыми ресурсами и средствами Ц₃₂ - совершенствование структуры управления университетом	Уменьшение затрат университета, управление и согласование обеспечивающей образовательный процесс деятельности
Ц₄ - развитие социальной и материальной инфраструктуры университета	Ц₄₁ - развитие жилищно-коммунального хозяйства Ц₄₂ - рациональная организация труда и отдыха Ц₄₃ - повышение благосостояния коллектива	Снижение текучести кадров на 15 %

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

Рисунок 1.2 - Дерево целей ВУЗа

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

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

Определены следующие этапы обработки внутренних документов:

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

2. Затем директор ОИЦ отдает распоряжение о покупке нового номера телефона.

. После покупки номера отдел закупок извещает директора ОИЦ о наличии свободного номера.

. Директор ОИЦ дает задание сотрудникам внести изменения в телефонном справочнике.

. После внесения изменений отправляется отчет.

Все внутренние документы регистрируются, размножаются секретарем (или в канцелярии) и направляются в структурные подразделения для исполнения.

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

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

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

Таблица 1.5 - Схема документооборота учреждения

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

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

Основными операционными системами на ПК является Linux и Windows Vista. На серверах чаще всего используются операционные системы Linux дистрибутивов Debian и Suse.

Таблица 1.6 - Технические характеристики ПК

Техническая характеристика или периферийное устройство	Условное обозначение
	ПК1	ПК2	ПК3	ПК4	ПК5	ПК6	ПК7
Частота, процессора, ГГц	1,5	2,5	2,5	2,5	2,5	2,5	2,5
Оперативная память, ГБ	512	2	2	2	2	2	2
Видеокарта	Nvidia	Nvidia	Nvidia	Nvidia	Nvidia	Nvidia	Nvidia
Жёсткий диск, ГБ	60	320	320	320	320	320	320
Монитор	17″ LCD	17″ LCD	17″ LCD	17″ LCD	20″ LCD	20″ LCD	20″ LCD
Принтер	HP	HP	Canon	Parser	HP	HP	HP
Сканер				Canon	Canon

Для интерактивного сервиса был использован сервер компании IBM. Так же в учреждении используются сервера Sun и HP.

1.1.4 Анализ проблемных ситуаций и обоснование путей их решения

После изучения информационной подсистемы ВУЗа были выявленные следующие недостатки:

а) отсутствие удобного доступа к контактным данным сотрудников и подразделений ВУЗа;

б) отсутствие быстрого доступа к реквизитам ВУЗа.

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

1.2 Формулировка задач проектирования

1.2.1 Общие сведения

Полное наименование сервисов - "Телефонный справочник СевКавГТУ".

Наименование организации разработчика - ГОУ ВПО "Северо-Кавказский государственный технический университет", факультет информационных технологий и телекоммуникаций, кафедра прикладной информатики, студент группы ПИ-061 Сучков Роман Геннадьевич.

Наименование организации заказчика - ГОУ ВПО "Северо-Кавказский государственный технический университет".

Перечень документов, на основе которых создается система:

) отчет о преддипломной практике студента группы ПИ-061 Сучкова Р. Г.;

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

) договор на предоставление услуг связи.

Источники финансирования - заработная плата техника ОИЦ СевКавГТУ

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

1.2.2 Назначение, цели создания интерактивных сервисов

Сервисы предназначены для:

) получения телефонных номеров сотрудников ВУЗа;

) получения телефонных номеров подразделений ВУЗа;

) получение контактной информации ВУЗа;

) интеграции с IP-телефонией ВУЗа;

) формирования версии для печати.

1.2.3 Характеристика объекта автоматизации

Краткие сведения об объекте автоматизации - рабочее место сотрудника ОИЦ СевКавГТУ.

Условия эксплуатации - стандартные.

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

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

а) добавление новых объектов в базу данных (БД);

б) изменение характеристик объектов базы данных;

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

г) информирование о появлении новых элементов и технологий.

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

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

1.2.5 Состав и содержание работ по созданию подсистемы

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

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

а) изучение предметной области - с 18 февраля по 8 марта 2011 г.;

б) кодирование - с 12 марта по 01 мая 2011 г.;

в) отладка и тестирование - с 01 по 15 мая 2011 г.;

г) сдача проектной документации - с 15 по 20 мая 2011 г.

Наиболее ответственной работой, выполняемой на этом этапе, являются "Кодирование и составление программной документации", в состав которой входят следующие компоненты:

а) описание программ;

б) спецификация программ;

в) тексты программ;

г) контрольные примеры;

д) инструкции для системного программиста, оператора и пользователя.

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

Технологическая документация разрабатывается в соответствии с требованиями ГОСТ 3.11.09 - 82 "Система технологической документации. Термины и определения основных понятий", и составляет содержание технологического обеспечения информационной системы.

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

1.2.6 Порядок контроля приемки подсистемы

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

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

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

1.2.7 Требования к составу и содержанию работ по подготовке объекта

автоматизации к вводу интерактивного сервиса в действие

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

а) MySql;

б) Python;

в) Django;

г) LightHttpd.

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

1.2.8 Требование к документированию

Разработчиком предоставляется:

) Исходные коды программы;

) Инструкция для обучения персонала в формате PDF.

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

Исходные коды разработанных интерактивных сервисов хранятся на локальном сетевом хранилище, доступ к которым осуществляется через систему контроля версий Mercurial. А так же на CD-ROM вместе с результатами тестирования и краткой инструкцией оператору по установке и работе с интерактивными сервисами.

1.2.9 Источники разработки

Источниками разработки являются:

) материалы отчета по преддипломной практике студента группы ПИ-061 Сучкова Р. Г;

) договор на предоставление услуг связи;

) заказ на разработку.

Выводы

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

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

2. РЕАЛИЗАЦИЯ ИНТЕРАКТИВНЫХ СЕРВИСОВ

2.1 Обоснование выбора среды реализации сервисов

Для разработки дипломного проекта была выбрана среда реализации

Eclipse вместе с плагином PyDev. Основные преимущества среды Eclipse:

1) бесплатность;

) легкость в установке и настройке;

) поддержка большого числа языков программирования;

) кроссплатформенность;

) поддержка всех популярных систем контроля версий;

) возможность установки дополнительных плагинов;

) расширенная документация;

) удобный графический интерфейс.

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

Проект был разработан на языке программирования Python с использования Web-фреймворка Django. Данный фреймверк является open-source продуктом и распространяется под лицензией BSD. Этот фреймверк был выбран из-за ряда причин:

а) модульная разработка;

б) использование объектно-реляционных проекций (Object-Relation Mapping, ORM);

в) гибкая система шаблонов;

г) кроссплатформенность;

д) приложение для административного интерфейса;

е) множество библиотек от сторонних разработчиков;

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

2.3 Концептуальное проектирование интерактивных сервисов

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

Таблица 2.1 - Названия и назначения страниц

Страница	Назначение
Главная	Содержит реквизиты университета и контактную информацию, а также меню навигации по сервисам
Руководство	Содержит контактную информацию руководства ВУЗа
Подразделения	Содержит контактную информацию о подразделениях ВУЗа и о его сотрудниках
Научные подразделения	Содержит контактную информацию о научных подразделениях ВУЗа и о его сотрудниках
Филиалы	Содержит контактную информацию о филиалах ВУЗа
Факультеты	Содержит контактную информацию факультетов ВУЗа. Включает в себя подраздел "Кафедры"
Инструкция по работе с внутренними телефонами	Содержит инструкции по работе с внутренними телефонами
Форма обратной связи	Служит для связи пользователей с администраторами сервиса

Kонцептуальная схема предоставлена на рисунке 2.1.

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

2.4 Создание логической модели базы данных интерактивных сервисов

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

а) из каких отношений должна состоять база данных;

б) какие атрибуты должны быть у этих отношений;

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

Требования к выбранному набору отношений и составу их атрибутов должны удовлетворять следующим условиям:

а) отношения должны отличаться минимальной избыточностью атрибутов;

б) выбранные для отношения первичные ключи должны быть минимальными;

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

2.3.1 Определение сущностей модели базы данных

Создание базы данных осуществлялось при помощи Web-фреймворка Django. Данный фреймворк при создании таблиц использует следующее правило: имя таблицы начинается с названия приложения, после идет нижнее подчёркивание и название таблицы (класса). В таблице 2.2 приведены все сущности, используемые в интерактивном сервисе.

Таблица 2.2 - Сущности базы данных

Сущность	Назначение
group	Информация о группах
group_permissions	Права групп
message	Сообщения пользователям
permission	Права доступа
user	Данные пользователей
user_groups	Группы пользователей
admin_log	Содержит историю действий пользователей
content_type	Хранит названия всех моделей
session	Хранит сессии
body	Содержит названия корпусов, их сокращения и описание
category	Содержит категории телефонных номеров
country	Содержит коды стран
department	Содержит информацию о подразделениях ВУЗа
page_text	Содержит текст отображаемый на информационных страницах Справочника
persone	Содержит информацию о работниках ВУЗа
phone	Содержит номера телефонов
prefix	Содержит префиксы телефонных номеров
tag	Содержит теги

2.3.2 Определение атрибутов сущностей базы данных интерактивного сервиса

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

Таблица 2.3 - Атрибуты сущностей базы данных

Сущность	Атрибут	Тип	Назначение
body	id	Целое число	Идентификатор
	title	Строка	Имя корпуса
	name_body	Строка	Короткое имя корпуса
	description	Строка	Описание
category	id	Целое число	Идентификатор
	name_category	Строка	Название категории
	description	Строка	Описание
	css_class	Строка	CSS класс категории
country	id	Целое число	Идентификатор
	country	Строка	Название страны
	code_country	Целое число	Код страны
	description	Строка	Описание
department	id	Целое число	Идентификатор
	name	Строка	Имя подразделения
	shortname	Строка	Короткое имя
	description	Строка	Описание
department	tag	Целое число	Код тега
	body	Целое число	Код корпуса
	town	Целое число	Код город
	room	Строка	Кабинет
	email	Строка	Email
page_text	id	Целое число	Идентификатор
	page	Строка	Страница
	title	Строка	Заголовок
	text	Строка	Текст страницы
	section	Строка	Раздел
persone	id	Целое число	Идентификатор
	first_name	Строка	Имя
	second_name	Строка	Фамилия
	last_name	Строка	Отчество
	post	Строка	Пост
	is_manager	Логический	Директор
	tag	Целое число	Код тега
	town	Целое число	Код города
	room	Строка	Кабинет
	email	Строка	Email
	body	Целое число	Корпус
phone	id	Целое число	Идентификатор
	category	Целое число	Категория
	prefix	Целое число	Префикс
	country	Целое число	Страна
	phone	Строка	Телефон
	description	Строка	Описание
	long_distance	Логический	Разрешить междугородние звонки
	view_phone	Логический	Показывать номер
	priority	Целое число	Приоритет
prefix	id	Целое число	Идентификатор
	region	Строка	Регион
	code_region	Целое число	Код региона
prefix	description	Строка	Описание
	town	Логический	Если город
tag	id	Целое число	Идентификатор
	tagname	Строка	Имя

2.3.3 Определение связей между сущностями базы данных интерактивного сервиса

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

Таблица 2.4 - Данные о взаимодействии сущностей базы данных

Зависимая сущность	Наследуемый (внешний) ключ	Независимая сущность	Тип связи	Кратность связи
Persone	tag	Tag	Неидентифицирущая	1:N
	town	Prefix	Аналогично	1:N
	body	Body	Аналогично	1:N
Department	tag	Tag	Аналогично	1:N
	town	Prefix	Аналогично	1:N
	body	Body	Аналогично	1:N
Phone	category	Category	Аналогично
	prefix	Prefix	Аналогично	1:N
	country	Country	Аналогично	1:N

2.3.4 Задание первичных ключей сущностей

Аппарат нормализации отношений обеспечивает удовлетворение следующих требований:

а) выбор отношений и атрибутов должен обеспечивать минимальное дублирование данных;

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

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

г) перестройка набора отношений при введении новых типов должна быть минимальной.

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

В таблице 2.5 приведены ключи для сущностей, имеющих типы ключей первичный и внешний. Сущности, не указанные в таблице, имеют тип ключа первичный с названием id.

Таблица 2.5 - Характеристика ключевых атрибутов сущностей

Таблица	Ключ	Тип ключа
group_permissions	id	первичный
	group_id	внешний
	permission_id	внешний
message	id	первичный
	user_id	внешний
permission	id	первичный
	content_type_id	внешний
user_groups	id	первичный
	user_id	внешний
	group_id	внешний
admin_log	id	первичный
	user_id	внешний
	content_type_id	внешний
department	id	первичный
	content_type_id	внешний
department	object_id	внешний
person	id	первичный
	content_type_id	внешний
	object_id	внешний
phone	id	первичный
	object_id	внешний
	category_id	внешний
	prefix_id	внешний
	country_id	внешний

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

2.3.5 Логическа модель данных

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

2.4 Создание физической модели базы данных интерактивных сервисов

При использовании платформы Django для каждого приложения определяется своя собственная схема. В каталоге каждого приложения присутствует файл с именем models.py содержащий определения таблиц и столбцов, которые будут использоваться приложением. В Django, как и в других платформах разработки веб-приложений, опирающихся на использование объектно- реляционных проекций (Object-Relation Mapping, ORM), вполне возможно создавать и использовать базы данных, не написав ни одного SQL-выражения.

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

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

Рисунок 2.2 - Логическая модель данных

2.4.1 Генерирование SQL-сценария создания базы данных информационной подсистемы средствами Django ORM

При необходимости можно увидеть сгенерированный код на языке SQL, который платформа использует для создания базы данных, для этого достаточно будет запустить в каталоге проекта команду python manage.py sql appname, где аргумент appname соответствует имени приложения. Сгенерированный код в приложении А.

2.5 Создание проекта и модулей

Проект в django может быть самостоятельным приложением, но в большой степени это просто структура директорий и настройки общие для всех приложений внутри. А приложение - это как раз код, который выполняется. Ждя создания приложения используется команда django-admin.py startproject project. Другой вариант создание проекта Django с помощью среды Eclipse.

Создать приложение можно с помощью команды: python manage.py startapp newapp.

Создаётся структура указанная на рисунке 2.3.

Рисунок 2.3 - Структура созданного проекта

Создаётся структура указанная на рисунке 2.4.

Перед запуском надо записать изменения в базу данных (если она используется): python manage.py syncdb

Рисунок 2.4 - Структура созданного приложения

Запустить тестовый сервер можно с помощью команды: python manage.py runserver.

2.6 Реализация интерактивных сервисов

Архитектура разработанного сервиса похожа на "Модель-Вид-Контроллер" (MVC). Контроллер классической модели MVC примерно соответствует уровню, который в Django называется Вид, а презентационная логика Вида реализуется в Django уровнем Шаблонов . Из-за этого уровневую архитектуру Django часто называют "Модель-Шаблон-Вид" (MTV).

2.6.1 Разработка интерфейса сервисов

Разработанные сервисы построены на основе архитектуры клиент-сервер. Клиентом зачастую выступает браузер отображающий данные сгенерированные сервером. Данные отдаются сервером как html-страница с подключенными к ней каскадными таблицами стилей (css). HTML - стандартный язык разметки документов во Всемирной паутине. Большинство Web-страниц создаются при помощи языка HTML (или XHTML). При генерации html-страницы Django использует систему шаблонов. Шаблон Django - это строка текста, которая предназначена для разделения представления документа от его данных. Шаблон определяет места подстановки и различные виды основной логики, которая управляет отображением документа. Обычно, шаблоны используются для создания HTML, но шаблоны Django также способны участвовать в генерации любого текстового формата. На рисунке указан пример сгенерированной страницы.

.6.2 Создание модели данных

При использовании платформы Django для каждого приложения определяется своя собственная схема. В каталоге каждого приложения присутствует файл с именем models.py содержащий определения таблиц и столбцов, которые будут использоваться приложением. В Django, как и в других платформах разработки веб-приложений, опирающихся на использование объектно-реляционных проекций (Object-Relation Mapping, ORM), вполне возможно создавать и использовать базы данных, не написав ни одного SQL-выражения. Механизм ORM платформы Django превращает классы в таблицы, а атрибуты классов в столбцы этих таблиц. Созданные классы необходимо наследовать от класса Model платформы Django.

Код скрипта отвечающий за создание сущности country:

Country( models.Model ):= models.CharField( max_length=100, null=False, blank=False)_country = models.CharField(max_length=3, null=False, blank=False)= models.TextField(blank=True, null=False)Meta:_name = _(u'Страна')_name_plural = _(u'Cтраны')__unicode__(self):self.country

Данный скрипт указывает Django, что необходимо создать сущность country с атрибутами id, country, code_country, description . Класс Meta содержит настройки сортировки данных таблицы. SQL-запрос для данного класса генереруется автоматически и выглядит следующим образом:

Рисунок 2.5 - Главная страница

TABLE `phonesdb_country` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`country` varchar(100) NOT NULL,

`code_country` varchar(3) NOT NULL,

`description` longtext NOT NULL

);

Для просмотра всех SQL-запросы, которые генерирует Django ORM существует команда python manage.py sqlall appname, где appname - имя приложения.

2.6.3 Создание представлений и привязок URL

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

main_page( request ):

main_page_obj = Page_text.objects.get(page="main")= main_page_obj.title_title = title= main_page_obj.text= { "title" : title,

"content_title": content_title,

"content" : content,

"ip":request.META['REMOTE_ADDR']

}_path = "pages.html"render_to_response( template_path, context,_instance=RequestContext(request) )

Для привязки функции представления к конкретному URL в Django используются файлы привязки URL. Файл привязки URL можно рассматривать как таблицу с содержанием сайта. Этот файл определяет соответствие между URL и функциями представления, которые должны быть вызваны для этих URL.

Файл urls.py:

django.conf.urls.defaults import *= patterns('',

(r'^$', views.main_page ),

)

(r'^$', views.main_page) - это обычный кортеж языка Python, в котором первый элемент является шаблоном регулярного выражения, а второй элемент - функция представления, которая должна использоваться при совпадении данного шаблона.

Регулярные выражения - компактный метод определения шаблонов в тексте.

2.6.4 Реализация формы обратной связи

HTML формы являются основой интерактивных веб-сайтов, от простой формы поиска Google и вездесущих форм для комментирования в блогах до сложных уникальных интерфейсов для ввода данных. Для реализации форм Django использует Библиотеку Forms.

Библиотека Django Forms включена в состав фреймворка Django. Она использует конфигурацию моделей базы данных и формирует из них HTML формы. Также она содержит серверную функциональность для проверки допустимости введенных значений и помещения этих данных в базу данный. Работая с этой библиотекой, вы можете простым способом интегрировать модели данных в страницы сайта и использовать их для добавления информации в базу данных. После того, как данные будут помещены в базу данных, можно как обычно осуществлять к ним запросы, сформированные на языке SQL или при помощи Django ORM.

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

Форма обратной связи указана на рисунке 2.7

Листинг скрипта формы обратной связи:

class ContactForm(forms.Form):= forms.CharField(required=True, label=_(u'Ваше имя'), max_length=30)= forms.EmailField(required=False, label=_(u'Эл. почта'))= forms.CharField(required=True, label=_(u'Тема'), max_length=30)= forms.CharField(required=True, max_length=400, widget=forms.Textarea(), label=_(u'Текст сообщения'))

2.6.5 Реализация формы поиска

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

Рисунок 2.6 - Форма поиска

Данные насервер отправляются методом POST. Это нужно в случае, если запрос пришёл из плагина. Присланный запрос обрабатывается и ищется на соответствие в базе данных. При успешном поиске результат отдается клиенту. Результат поиска по запросу "ОИЦ" показан на рисунке.

Рисунок 2.7 - Форма обратной связи

Рисунок 2.8 - Результат поиска по запросу "ОИЦ"

Рисунок 2.9 - Проверка орфографии

2.6.6 Пользовательская проверка орфографии в сервисе

Любой пользователь, увидев опечатку на сайте, может сообщить о ней администраторам сервиса, выделив её и нажав сочетание клавиш "Ctrl + Enter". После чего появится окно проверки орфографии (рисунок 2.9).

Форма содержит в себе поле, содержащее контекст ошибки, и поле для комментария.

2.6.7 Настройка Web-сервера lighthttpd

Lighttpd - Web-сервер, разрабатываемый с расчётом на быстроту и защищённость, а также соответствие стандартам. Это свободное программное обеспечение, распространяемое по лицензии BSD. lighttpd работает в Linux и других Unix-подобных операционных системах, а также в Microsoft Windows. Django взаимудействует с сервером через fastcgi протокол. Конфигурирация /etc/lighttpd/lighttpd.conf:

# lighttpd configuration file.modules= (

"mod_fastcgi",

).document-root = "/var/www/lighttpd".server = ( "/spravka.fcgi" =>

( "main" =>

(

"socket" => "/tmp/spravka.sock", "check-local" => "disable",

)

).rewrite-once = (

"^(/media.*)$" => "$1",

"^/favicon\.ico$" => "/media/favicon.ico",

"^(/.*)$" => "/spravka.fcgi$1",

)

Выводы

Для реализации сервиса был выбран объектно-ориентированный Web-фреймвёрк Django. Django написан на языке программирования Python, что позволяет использовать все возможности этого языка при написании дипломного проекта.- динамически развиваемый язык программирования. Существует множество дополнительных библиотек, благодаря которым разработка приложений значительно упрощается. Утилита Python Setup Tools позволяет устанавливать дополнительные библиотеки автоматически. Это позволяет программисту больше времени быть сконцентрированным на разработке приложений, вместо того, чтобы тратить его на ручную установку.разработан по принципу модульного программирования, это облегчает использование одного кода в разных приложениях, а так же позволяет создавать библиотеки(приложения), непосредственно для фреймверка. Django - приложения так же можно устанавливать используя утилиту Python Setup Tools.

3. ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

3.1 Общие сведения об интерактивных сервисах доступа к телефонному справочнику СевКавГТУ, г. Ставрополь

Интерактивные сервисы доступа к телефонному справочнику СевКавГТУ, г. Ставрополь имеют архитектуру клиент - сервер. Функционирование сервисов достигается благодаря следующему программному обеспечению:

) операционная система Linux;

2) Web-сервер lighthttpd;

) язык программирования Python;

) фреймворк Django;

) СУБД MySQL.

Клиентом интерактивных сервисов является любой web-браузер.

3.2 Функциональное назначение интерактивных сервисов доступа к телефонному справочнику СевКавГТУ г. Ставрополь

Общие сведения о функциональном назначении интерактивных сервисов представлены в таблице 3.1.

Таблица 3.1 - Функциональное назначение интерактивных сервисов

Наименование сведений	Содержание сведений
Назначение интерактивных сервисов	Обеспечение простого и удобного доступа к расписанию СевКавГТУ, г. Ставрополь для широкого круга пользователей
Цель создания интерактивных сервисов	Сокращение временных на доступ к контактным данным сотрудников и подразделений ВУЗа, а также к реквизитам университета
Функциональные ограничения на применение	Наличие на компьютере пользователя установленного web-браузера

3.3 Описание логической структуры интерактивных сервисов доступа к телефонному справочнику СевКавГТУ, г. Ставрополь

Логическую структуру интерактивных сервисов иллюстрирует диаграмма компонентов (рисунок 3.1).

Рисунок 3.1 - Диаграмма компонентов интерактивных сервисов доступа к телефонному справочнику СевКавГТУ, г. Ставрополь

На логическом уровне взаимодействаия классов Python. реализующих указанные модули зависимостей нет.

3.4 Требование к техническому обеспечению

3.4.1 Общие требования

Интерактивные сервисы выполнены в виде web-приложения. Для работы сервисов на стороне клиента необходим установленный web-браузер и выхода в сеть ВУЗа.

Для работы сервисов на сервере необходимо установить:

) операционную систему Linux или Windows;

) систему управления базой данных MySQL;

) язык программирования Python;

4) Web-фреймворк Django.

3.4.2 Требования к центральному процессору

В результате контрольных прогонов для работы с интерактивными сервисами достаточно сервера с тактовой частотой центрального процессор 100 МГц. Обоснование: при более низкой тактовой чистоте центрального процессора быcтродействие интерактивных сервисов является неудовлетворительным, например, время выполнения генерация версии для печати в формате pdf увеличивается до одного часа.

Для персонального компьютера клиента с операционной системой Microsoft Windows XP необходим центральный процессор с тактовой частотой 233 МГц. Это минимальной. Обоснование: данное требование сформулировано фирмой Microsoft, как минимальное при установке Microsoft Windows XP. Web-браузер Internet Explorer 6 предустановлен в операционной системе Microsoft Windows XP и не требует дополнительных ресурсов центрального процессора.

3.4.3 Требования к оперативному запоминающему устройству

Необходимый размер оперативного запоминающего устройства (ОЗУ) W_ОЗУ, Мбайт рассчитаем по формуле

_ОЗУ = W_ОЗУ1 + W_ОЗУ2 + W_ОЗУ3 , (3.1)

где - минимально необходимый размер ОЗУ, требуемый для работы операционной системы (ОС), Мбайт; - объем ОЗУ, требуемый интерактивными сервисами, Мбайт; W_ОЗУ3 - минимальных требований со стороны дополнительных программных модулей, обеспечивающих работу программного продукта, Мбайт.

Значение параметра для серверной версии операционной системы определяется, как 16 Мбайт. Обоснование: данное требование сформулировано разработчиками Linux дистибутива Debian, как минимальное при установке Linux Debian.

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

Значение параметра W_ОЗУ3 в рассматриваемом случае определяется, как сумма требуемой оперативной памяти для прогрммных модулей, обеспечивающих работу интерактивных сервисов. Для СУБД MySQL необходимо минимум 64Мбайт, для web-сервера lighthttpd 12 Мбайт, для Python 1 Mайт, для фреймворка Django 1 Мбайт, тогда W_ОЗУ3буде результатом сложения требований программных модулей и равен 78 МБайт.

Таким образом, воспользовавшись формулой (3.1) получаем

W_ОЗУ= 16 + 2,15+ 78= 96,15 Мбайт.

Для персонального компьютера клиента размер оперативного запоминающего устройства определяется в зависимости от установленной операционной системы и Web-браузера. Значение параметра для Microsoft Windows XP определяется, как 64 Мбайт. Обоснование: данное требование сформулировано фирмой Microsoft, как минимальное при установке Microsoft Windows XP. Web-браузер Internet Explorer 6 предустановлен в операционной системе Microsoft Windows XP и не требует дополнительной оперативной памяти.

Для нормальной работы интерактивных сервисов на сервере под управлением операционной системы Linux будет достаточно 96,15 Мбайт оперативной памяти. Для обеспечения комфортных условий работы информационной подсистемы рекомендуется использовать ОЗУ размером 200 Мбайт и более. Для персонального компьютера клиента с установленной операционной системой Microsoft Windows XP необходимо 64 Мбайт оперативной памяти.

3.4.4 Требования к наличию сводного места на жестком диске

Свободное пространство на жестком диске для клиентского ПК должно хватать на установку браузера. Компания Microsoft, для браузера IE 8, рекомендует не менее 150 Мбайт. Определить минимально необходимое свободное пространство можно, используя формулу следующим соотношением

, (3.2)

где, W₁, W₂- размер пространства, которое занимает инсталляция, Мбайт.

Для сервера объем свободного места должен быть не менее 347 Мб на приложения (MySQL требует 211 Мбайт без базы данных, HTTP-сервер требует 35 Мбайт и python, 101 Мб), плюс предполагаемый объем данных в базе (с учетом возможности добавления новых данных примерно составляет от 50 Мбайт) и объем для дампа базы данных от 50 Мбайт. Таким образом, учитывая все параметры, получается минимального пространства должно быть не менее 447 Мбайт.

3.4.5 Требования к монитору

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

3.4.6 Требования к принтеру

Интерактивные сервисы предоставляют версию для печати телефонного справочника ВУЗа в формате pdf, который требует принтер с разрешение не меньше 300 точек/дюйм. При меньшем разрешении данные будут пропечатывать нечётко, поскольку размер текста в документа рассчитан на современные принтеры с подержкой разрешения 300 разрешением 300 точек/дюйм и выше.

3.5 Установка и вызов интерактивных сервисов

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

1. Производится соединение с сервером через протокол ssh.

2. Исходные коды устанавливаются из системы контроля версий mercurial.

. Настраивается Web-сервер lighthttpd.

. Создается база данных.

. Настраивается и запускается проект.

На этом процесс установки интерактивных сервисов завершен.

Для доступа к сервисам в браузере в адресной строке необходимо написать #"516588.files/image017.gif">

Рисунок 3.3 - Телефонные номера руководства

Рисунок 3.4 - Телефонные номера подразделения "Расчётный отдел"

Рисунок 3.5 - Результаты поиска

3.8 Результаты тестирования

Интерактивные сервисы доступа к телефонному справочнику СевКавГТУ. Сервисы были протестированы на отображении в четырех популярных браузерах, таких как IE, Firefox, Opera и Chrome. Результаты отображения в различных версиях браузеров указаны на рисунках 3.6 - 3.9 Во всех браузерах информация отображалась корректно. Ставрополь прошли тестирование в условиях запуска тестовой версии. В результате тестирования установлено, что они в полном объеме удовлетворяет требованиям заказчика. В настоящее время, разработанные интерактивные сервисы, уже внедрены в практику работы СевКавГТУ, и находится в стадии опытной эксплуатации.

Рисунок 3.6 - Отображение в браузере "Google chrome"

Рисунок 3.7 - Отображение в браузере "Internet Explorer"

Рисунок 3.8 - Отображение в браузере "Opera"

Рисунок 3.9 - Отображение в браузере "Firefox"

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

Для вызова интерактивных сервисов необходимо открыть браузер и в адресной строке набрать адрес <#"516588.files/image024.gif"> ед.

В этом разделе рассмотрены вопросы расчёта:

− трудоёмкости выполняемых работ;

− суммарных затрат на создание программного продукта;

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

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

− внутренней нормы доходности проекта и срока его окупаемости.

4.2 Трудоёмкость выполняемых работ

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

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

Трудоёмкость разработки программного обеспечения , чел-ч., определяется по формуле:

, (4.1)

Все составляющие в правой части формулы (4.1) определены через общее число операторов D, ед.:

(4.2)

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

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

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

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

= 4030 × 1,5×(1+0,1) = 6649,5 ед.

Работу по описанию задачи и все другие работы по созданию программного продукта выполняет инженер-программист без категории с окладом 8000 руб. в месяц и коэффициентом квалификации =1.

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

, (4.3)

где D - общее число строчек кода в тексте программы, ед.;

b - коэффициент увеличения затрат труда вследствие недостаточного описания задачи;

В связи с тем, что решение рассматриваемой задачи потребовало уточнения и доработок, примем коэффициент b = 1,5.

Количество строчек кода в тексте программы, приходящееся на один чел-ч., примем равным = 60 ед. / чел-ч.

Таким образом, на основании формулы (4.3) получим:

103,89 чел-ч.

Затраты труда на разработку алгоритма решения задачи , чел-ч., рассчитываются по формуле:

, (4.4)

где D - общее число строчек кода в тексте программы, ед.;

Для расчёта по формуле (4.4) примем = 35 ед./чел-ч.

Подставив численные значения параметров и коэффициентов в формулу (4.4), получим:

118,74 чел-ч.

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

, (4.5)

где D - общее число строчек кода в тексте программы, ед.;

Для расчёта по формуле (4.5) примем = 20 ед./чел-ч.

83,12 чел-ч.

Затраты труда на отладку программы на персональном компьютере

, (4.6)

где D - общее число строчек кода в тексте программы, ед.;

Для расчёта по формуле (4.6) примем = 45 ед./чел-ч.

Подставив численные значения параметров и коэффициентов в формулу (4.6), получим:

92,35 чел-ч.

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

, (4.7)

Затраты труда на подготовку материалов в рукописи , чел-ч., вычислим по формуле:

, (4.8)

где D - общее число строчек кода в тексте программы, ед.;

Для расчёта по формуле (4.8) примем = 30 ед./чел-ч.

Подставив численные значения параметров и коэффициентов в формулу (4.8) получим:

138,53 чел-ч.

Затраты труда на редактирование, печать и оформление документации, чел-ч., вычислим по формуле:

(4.9)

Подставив численное значение затраты труда на подготовку материалов в рукописи, чел-ч., в формулу (4.9), получим:

чел-ч.

Таким образом, подставив численные значения затраты труда на подготовку материалов в рукописи , чел-ч., и затраты труда на редактирование, печать и оформление документации , чел-ч., в формулу 4.7, получим:

чел-ч.

Подставив все полученные данные, составляющие трудоёмкость разработки программного обеспечения в формулу (4.1), получим:

чел-ч.

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

, (4.10)

Использованная среда разработки относится к алгоритмическому языку высокого уровня, с учётом этого примем = 0,95.

Таким образом, получим по формуле (4.10) итоговую откорректированную трудоёмкость разработки программы:

чел-ч.

4.3 Расчёт себестоимости интерактивных сервисов

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

, (4.11)

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

, (4.12)

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

Таким образом, часовая тарифная ставка , руб./ч, инженера-программиста первой категории составляет:

Основная заработная плата , руб., производственного персонала определяется по формуле:

. (4.13)

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

руб.

Дополнительная заработная плата производственного персонала определяется по формуле:

, (4.14)

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

руб.

Отчисления в Пенсионный фонд Российской Федерации, Фонд социального страхования Российской Федерации и фонды обязательного медицинского страхования Российской Федерации согласно закону № 212-Ф3 от 24.07.2009 , руб., вычислим по формуле:

В соответствие с законом № 212-Ф3 от 24.07.2009 норматива страховых взносов составляет 34 % (=34 %).

Подставив все численные значения в формулу (4.15) получим, что отчисления на страховые взносы равны:

Таким образом, размер страховых взносов составит 9991,59 руб.

Затраты на потребляемую электроэнергию, руб.:

, (4.16)

Мощность ЭВМ, на которой работает инженер-программист без категории, равна =0,3 кВт.

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

, (4.17)

Для расчётов по формуле (4.17) примем =1,1 и =0,8. Подставив все численные значения параметров в формулу (4.17) получим:

75 ч.

Стоимость 1 кВтч электроэнергии составляет 5,62 руб./кВтч.

Подставив все численные значения параметров в формулу (4.16) получим, что затраты на потребляемую энергию составят:

620,03 руб.

Данные для расчёта затрат на материалы и запасные части занесём в таблицу 4.1.

Таблица 4.1 - Затраты на материалы и покупные изделия

Материал, покупаемое изделие	Количество, ед.	Цена за единицу, руб.	Сумма, руб.
Бумага офисная	2	120	250,00
DVD-диск	10	15	150,00
Итого			400,00

Следовательно, затраты на материалы и запасные части составят:

руб.

Затраты на техническое обслуживание и текущий ремонт вычислительной техники, руб.:

Для расчётов по формуле (4.18) примем:

− балансовая стоимость вычислительной техники 60000,00 руб.;

− норма отчислений на ремонт = 4 %;

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

Затраты на амортизацию вычислительной техники руб.:

Для расчётов по формуле (4.19) примем:

− балансовая стоимость вычислительной техники 60000,00 руб.;

− норма отчислений на амортизацию = 10 %;

− годовой фонд времени работы вычислительной техники при 40-часовой рабочей неделе в текущем году = 1986 ч.

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

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

Таблица 4.2 - Величины затраты, составляющих себестоимость автоматизированной информационной системы

Статья расхода	Сумма, руб.
Основная з/п производственного персонала	29387,00
Дополнительная заработная плата производственного персонала	0,00
Отчисления на страховые взносы	9991,59
Затраты на потребляемую электроэнергию	444,41
Расходы на материалы и запасные части	400,00
Затраты на техобслуживание вычислит. техники	1111,04
Затраты на амортизацию вычислительной техники	1111,04
Итого	41954,13

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

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

, (4.20)

Для расчётов по формуле (4.20) примем = 0 %. Подставив численное значение параметров в формулу (4.20) получим:

руб.

Капиталовложения при внедрении программного продукта равняются его оптовой цене:

К = Ц = 41954,13руб.

4.4 Оценка экономической эффективности внедрения программного продукта

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

, (4.21)

Где Э - стоимостная оценка результатов применения программного продукта в течение года, руб.;

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

, (4.22)

Данные сервисы используются всеми сотрудниками ВУЗа. Оклад сотрудников составляет 8000 руб., премиальный фонд - 10 % от оклада. Тогда, цена одного часа работы кредитного инспектора отдела финансирования строительных проектов, руб./ч., составит:

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

Таблица 4.3 - Данные о времени, затрачиваемом на обработку информации вручную и при использовании программного продукта за один месяц

Наименование работы	, ч., ч.
Обработка первичных документов	10	5
Получение информации	30	1
Обработка информации	60	1
Составление отчётов	10	3
Итого	110	10

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

Из таблицы 4.4 следует, что общие затраты времени на ручную обработку информации в месяц, ч., составляют 110 ч., а общие затраты на автоматизированную обработку информации 10 ч. Годовые затраты (затраты за 12 месяцев) сотрудников отдела финансирования кредитных продуктов Банка при ручной обработке информации вычислим по формуле:

. (4.23)

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

= 66000руб.

Годовые затраты (затраты за 12 месяцев) сотрудников отдела финансирования кредитных продуктов Банка при автоматизированной обработке информации вычислим по формуле:

. (4.24)

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

= 6000 руб.

Следовательно, годовой эффект от внедрения программного продукта, даже без учёта дополнительного экономического эффекта (= 0), на основании формулы (4.22), получится равным:

руб.

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

На основании формулы (4.16), для персональных компьютеров специалистов за 12 месяцев затраты на электроэнергию при потребляемой мощности компьютера P_в =0,3 кВт составят (стоимость электроэнергии Ц_э=2,31 руб./кВт-ч.):

= 202,32 руб.

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

Затраты на амортизацию вычислительной техники по формуле (4.19) составят:

Тогда, эксплуатационные затраты при использовании программного продукта составят:

202,32+1450,16 +3625,15 = 5277,85 руб.

Прибыль от использования программного продукта за год рассчитаем по формуле (4.21):

П = Э - З = 60000 - 5277,85 = 54722,15 руб.

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

шаг (капиталовложения) - 41954,13 руб.;

шаг − 722,15 руб.;

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

Где N - расчётный период, год;

К - капиталовложения при внедрении программного продукта, руб.

Следовательно, ЧДД, руб., при N = 7, т. е. за семь лет использования программного продукта (срок до морального старения рассматриваемой информационной системы) при норме дисконта Е = 20 % в соответствие с формулой (4.25) составит:

= 53649,17 + 38001,49 + 31667,91 + 21613,21 - 419= 102977,67 руб.

Приходим к выводу, что ЧДД положителен, т. е. проект эффективен.

Внутреннею норму доходности проекта , %, определим по формуле:

Где − максимальное значение внутренней нормы дисконта, %, при которой ЧДД является положительной величиной (ЧДД > 0);

− минимальное значение внутренней нормы дисконта, %, при которой ЧДД является отрицательной величиной (ЧДД < 0);

− ЧДД, руб., вычисляемый по формуле (4.25) при подстановке нормы дисконта E = ;

− ЧДД, руб., вычисляемый по формуле (4.25) при подстановке нормы дисконта E = .

Предполагаем, что лежит в диапазоне 205 … 206 %. При норме дисконта =205 % получаем ЧДД = 102,98 руб. Таким образом, при =205 % ЧДД положителен.

При норме дисконта =206 % получаем ЧДД = −212,11 руб. Таким образом, при =206 % ЧДД отрицателен.

Следовательно, по формуле (4.26) имеем:

Рассчитаем срок окупаемости проекта. Срок окупаемости проекта , год, найдём по формуле:

Где N - максимальное количество лет, прошедших с начала эксплуатации программного продукта, в течение которых величина дохода от его использования не превысила величины капиталовложения при внедрении программного продукта;

Э - величины приведённых (дисконтированных) годовых эффектов за j-й год, руб., прошедший с начала эксплуатации программного продукта, вычисленные по формуле (4.25) при подстановке нормы дисконта Е = 20 %.

Величина приведённого (дисконтированного) годового эффекта за первый год расчётного периода по формуле (4.25) равна:

что меньше величины капиталовложений (К =26678,79 руб.).

Тогда, в формуле (4.27) имеем N = 0 и срок окупаемости составит:

4.5 Основные технико-экономические показатели проекта

Для удобства анализа, все основные технико-экономические показатели проекта сведены в таблицу 4.4.

Таблица 4.4 - Основные технико-экономические показатели проекта

Основные характеристики	Единицы измерения	Проект
Итоговая трудоёмкость разработки	чел-ч.	680,54
Полные затраты на создание программного продукта	руб.	41954,13
Оптовая цена программного продукта	руб.	41954,13
Годовой экономический эффект от внедрения программного продукта	руб.	54722,15
Чистый дисконтированный доход	руб.	102977,67
Внутренняя норма доходности	%	105,46
Срок окупаемости проекта	год	0,92

Выводы

1. Итоговая трудоёмкость разработки программного продукта составила 680,54 чел-ч.;

. Полные затраты на создание программного продукта составляют 41954,13 руб.;

. Оптовая цена программного продукта - 41954,13 руб.;

. Годовой эффект от внедрения программного продукта составляет 54722,15 руб.;

. Чистый дисконтированный доход - 54722,15 руб.;

. Внутренняя норма доходности - 105,46 %;

. Срок окупаемости проекта 0,92 года;

. После интерактивных сервисов ежемесячные затраты времени сотрудников ВУЗа на выполнение работ, связанных с доступа к телефонному справочнику с 52 до 15 часов, т. е. в 3,5 раза.

. Таким образом, разработка интерактивных сервисов доступа к телефонному справочнику СевКавГТУ является экономически обоснованной и эффективной.

ЗАКЛЮЧЕНИЕ

Разработка интерактивных сервисов доступа к телефонному справочнику СевКавГТУ, г Ставрополь велась с использованием самых современных технологий. Web-фреймворк Django, на котором был написан дипломный проект, известен своей популярностью у таких компаний, как Google и Яндекс. Дипломный проект был разработан в среде Eclipse, основное преимущество которого в кроссплатформенности, что позволяло вести разработку в различных операционных системах.

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

1. Итоговая трудоемкость разработки программного продукта (интерактивные сервисы доступа к телефонному справочнику СевКавГТУ) составляет 680,54 чел.-ч.

2. Полные затраты на создание программного продукта составляют 41954,13 руб.

. Годовой эффект от внедрения программного продукта составляет 54722,15 руб.

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

5. Внутренняя норма доходности 105,46%.

. Срок окупаемости проекта 0,92 года.

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Пятибратов А.П., Гудыно Л.П., Кириченко А.А. Вычислительные системы, сети и телекоммуникации: Учебник. - 2-е изд., перераб. и доп. - М.: Финансы и статистика, 2002.

2. Методические указания по определению экономической эффективности новых машин и оборудования/ Горлов С.М., Небесский В.Д. - Ставрополь, 2003.

. Бурлак Г.Н. Безопасность работы на компьютере: организация труда на предприятиях информационного обслуживания. - М.: "Финансы и статистика", 1998.

. ГОСТ 2.105-95 ЕСКД Общие требования к текстовым документам.

5. Ротков Л. Ю., Рябов А. А., Виценко А. Ю. Современные сетевые технологии, технологии Интернет. Учебное пособие. Нижний Новгород: ННГУ, 2002, 244 с.

. Будилов И.Ю. JavaSсript, XML и объктная модель документа - М.: "Диалог - МИФИ", 2001. - 352 с.: ил.

7. Николенко С.А. Практические занятия по HTML. -М.: ЗАО "Издательство БИНОМ", 2001. - 784 с.: ил.

. Цеховой А.Д. Программирование на языке Java: краткий курс. -СПб: "КОРОНА принт" ,2002. - 672с.

. Серогодский Ф.Д. Энциклопедия дизайнера Corel Draw 10.: Пер с англ. - М.: и.д. "Вильямс", 2002. - 256с.

10. Финков В.И. Интерент. Шаг второй: от пользователя к профессионлау. - М.: и.д. "Вильямс", 2004. - 384с.

. Колисниченко Т.С. Web: дизайн и коммерция. - СПб.: "Питер", 2002. - 304с.

12. Подольский С.В. Самоучитель по Web-дизайну.- СПб.: "Питер", 2000. - 543 с.

13. Петров, А. И. Информационные системы [Текст]/ А. И. Петров. - М.: Горячая линия-Телеком, 2000. − 300с., ил.

14. Буч, Г., Рамбо, Д., Джекобсон, А. Язык UML для пользователя: Пер. с англ [Текст]/ Г. Буч, Д. Рамбо, А. Джекобсон. - М.: ДМК, 2000. − 432 с., ил. (Серия "для программистов").

. Боггс, У., Боггс, М.. UML и Rational Rose: Пер. с англ [Текст] / У. Боггс, М. Боггс. - М.: Издательство "Лори", 2000.- 581 с.

. Калянов, Г. Н. CASE-технологии. Консалтинг при автоматизации бизнес процессов. 2-е изд. перераб. И доп [Текст] /Г. Н. Калянов. - М.: Горячая линия- Телеком, 2000. − 320 с.

. Ларман, К. применение UML и шаблонов проектирования: Пер. с англ [Текст] / К. Ларман. - М.: Издательский дом "Вильямс", 2001. - 496 с.

. Гуидо, А. Я. Программирование в Python [Текст] / А. Я. Гуидо. - М.: ООО "Бином-Пресс", 2003. - 1152 с.

. Баженова, И. Ю. Разработка распределенных приложений [Текст] / И. Ю. Баженова. - М.: Кудиц-Образ, 2003. - 436 с.

. Кобейн, К. Б. Основы программирования в Python[Текст] / К. Б. Кобейн. - СПб.: БХВ-Петербург, 2003. - 608 с.

21. Гофман, В.Э, Хомоненко, А. Д. Python [Текст] / В.Э. Гофман, А. Д. Хомоненко. - СПб.: БХВ, 2000. - 800 с.: ил.

22. Тейксера Стив, Пачеко Ксавье. Eclipse. Руководство разработчика. : Пер. с англ. - М.: Издательский дом "Вильямс", 2000. - 817 с..

23. Кандзюба, С. П., Громов, В. Н. Django. Базы данных и приложения. Лекции и упражнения [Текст] / С. П. Кандзюба, В. Н. Громов. - К.:Издательство "ДиаСофт", 2001. - 576 с.

Приложение А

Листинг файла models.py

from django.db import modelsdjango.utils.translation import ugettext as _django import formsdatetime import datetimedjango.contrib.contenttypes.models import ContentTypedjango.contrib.contenttypes import genericdjango.conf import settingspdfgen.models import TemplateFile

__models__ = ["Department", "Person" ]_states = ( ( True, _( "published" ) ),

( False, _( "private" ) ) )TreeNodeMeta( models.Model ):_type = models.ForeignKey(ContentType, null=True, blank=True)_id = models.PositiveIntegerField( null=True, blank=True )= generic.GenericForeignKey( 'content_type', 'object_id' )Meta:= True

# Metadata fieldsBaseMetadata( models.Model ):= models.CharField(_('Name'), max_length=150, help_text=_("Full name of object."), unique=True)= models.CharField(_('Shortname'), max_length=50, help_text=_("Short name of object( using in breadcrumbs )."),blank=True, null=True )= models.TextField( verbose_name=_('Description'), blank=True, max_length=400, \_text=_("Description of object.") )_time = models.DateTimeField( blank=True, null=True )Meta:= Truesave(self):.modification_time = datetime.now()(BaseMetadata, self).save()Metadata( BaseMetadata ):= models.BooleanField(verbose_name=_('State'), choices=wf_states, default=False, \_text=_("Private objects are not be allowed, instead of published.") )_time = models.DateTimeField( verbose_name=_("Publication time"), blank=True, null=True )Meta:= True= ['name']save(self):self.state:not self.publication_time:.publication_time = datetime.now():.publication_time = None(Metadata, self).save()__unicode__(self):u'%s' % self.shortname and self.shortname or self.name

# Implementation of folder type:Container( models.Model ):

# Generic reletions:_container=TrueMeta:= True= [ '-modification_time' ]

# Implementation of simple item:SimpleItem( models.Model ):_container = FalseMeta:= TrueTag(models.Model):_type="Tag"= models.CharField(verbose_name=_("tag name"), max_length=50)Meta:_name = _('Tag')_name_plural = _('Tags')__unicode__(self):self.tagnameCategory(models.Model):_category = models.CharField(_(u'Категория'), max_length=30, null=False, blank=False, help_text=_(u'Название категории'))= models.TextField(_(u'Описание'), blank=True, null=False, help_text=_(u'Описание категории'))_class = models.CharField(_(u'CSS класс'), max_length=30, null=False, blank=False, help_text=_(u'класс необходим для отображения иконок возле номера'))Meta:_name = _(u'Категория')_name_plural = _(u'Категории')__unicode__(self):'%s' % self.name_categoryCountry( models.Model ):= models.CharField(_(u'Страна'), max_length=100, null=False, blank=False, help_text=_(u'Название страны'))_country = models.CharField(_(u'Код'), max_length=3, null=False, blank=False, help_text=_(u'Телефонный код страны'))= models.TextField(_(u'Описание'), blank=True, null=False, help_text=_(u'Описание страны'))Meta:_name = _(u'Страна')_name_plural = _(u'Cтраны')__unicode__(self):self.countryPrefix( models.Model ):= models.CharField( _(u'Регион'), max_length=255, help_text=_(u'Назавние региона/города') )_region = models.CharField( _(u'Код'), max_length=5, help_text=_(u'Код региона') )= models.TextField(_(u'Описание'), blank=True, null=False, help_text=_(u'Описание префикса') )= models.BooleanField(_(u'Город'), help_text=_(u'Если данный префикс код города, то надо поставить галочку'))Meta:_name = _(u'Префикс')_name_plural = _(u'Префиксы')__unicode__(self):('%s-%s') % (self.region, self.code_region)Phone( Container, TreeNodeMeta ):_type = "Phone"= models.ForeignKey( Category, verbose_name=_(u'категория'), db_index=True )= models.ForeignKey( Prefix, blank=True, verbose_name=_(u'префикс'), null=True, db_index=True )= models.ForeignKey( Country, verbose_name=_(u'страна'), blank=True, null=True, db_index=True )= models.CharField( _(u'Телефон'), max_length=255, help_text=_(u'Номер телефона'), db_index=True )= models.TextField(_(u'Описание'), blank=True, null=False, help_text=_(u'Описание телефона'))_distance = models.BooleanField(_(u'Разрешить междугородние звонки'), default=False, db_index=True)_phone = models.BooleanField(_(u'Отображать номер телефона'), default=True)= models.IntegerField(_(u'Приоритет'), blank=True, null=True, help_text=_(u'Чем выше значение приоритета, тем он выше (5 выше 3)'), db_index=True)Meta:_name = _(u'Телефон')_name_plural = _(u'Телефоны')__unicode__(self):self.country != None:= '+%s' % self.country.code_country:= ''self.prefix != None:= '(%s)' % self.prefix.code_region:= ''u'%s %s %s' % (country, prefix, self.phone)Body(models.Model):_type = "Body"= models.CharField(verbose_name=_(u"Полное название"), max_length=30, unique=True )_body = models.CharField(verbose_name=_(u"Короткой название"), max_length=30, unique=True )= models.TextField(_(u'Описание'), blank=True, null=False, help_text=_(u'Описание корпуса'))Meta:_name = _(u'корпус')_name_plural = _(u'корпуса')__unicode__(self):"%s" % self.titleContactInfo( models.Model ):= models.EmailField( blank=True, null=True )= models.CharField( max_length=20, blank=True, null=True )= models.ForeignKey( Body, blank=True, null=True )Meta:= TrueDepartment( Container, BaseMetadata, TreeNodeMeta ):

# meta_type - will be allowed in admin interface:_type = "Department"

#-----------------------------------------------_id = models.PositiveIntegerField(null=True, blank=True )= models.ForeignKey(Tag, blank=True, null=True)= models.ForeignKey( Body, blank=True, null=True )= models.ForeignKey( Prefix, verbose_name=_(u'город') )= models.CharField( max_length=20, blank=True, null=True )= models.EmailField( blank=True, null=True )__unicode__(self):"%s" % self.nameget_absolute_url(self):"/admin/phonesdb/department/edit/%d" % self.idMeta:_name = _(u'подразделение')_name_plural = _(u'подразделения')= ['name']Person( SimpleItem, TreeNodeMeta, ContactInfo ):

# meta_type - will be allowed in admin interface:_type = "Person"

#-----------------------------------------------_name = models.CharField(max_length=30)_name = models.CharField(max_length=30, blank=True, null=True )_name = models.CharField(max_length=30)= models.CharField( max_length=100, blank=True, null=True )_manager = models.BooleanField()= models.ForeignKey(Tag, blank=True, null=True)= models.ForeignKey( Prefix, verbose_name= u'город' )= models.IntegerField(blank=True, null=True)_boss = models.IntegerField(blank=True, null=True)Meta:= ['last_name']__unicode__(self):"%s %s %s" % ( self.last_name, self.first_name, self.second_name )getfio(self):u"%s %s %s" % ( self.last_name, self.first_name, self.second_name )Page_text(models.Model):= models.CharField(verbose_name=_(u'Страница'), max_length=30, unique=True)= models.CharField(verbose_name=_(u'Заголовок'), max_length=100)= models.TextField( verbose_name=_('Text'), help_text=_("Text of page.") )= models.CharField(verbose_name=_(u'Раздел'), max_length=100, blank=True, null=True, help_text=_(u'Раздел к которому относится страница. Например для инструкций "manuals"') )__unicode__(self):"%s" % self.titleMeta:_name = _(u'текст на странице')

verbose_name_plural = _(u'текст на страницах')

Приложение Б

SQL сценарий создания структуры базы данных

BEGIN;CREATE TABLE `phonesdb_tag` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`tagname` varchar(50) NOT NULL

)

;TABLE `phonesdb_category` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`name_category` varchar(30) NOT NULL,

`description` longtext NOT NULL,

`css_class` varchar(30) NOT NULL

)

;TABLE `phonesdb_country` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`country` varchar(100) NOT NULL,

`code_country` varchar(3) NOT NULL,

`description` longtext NOT NULL

)

;TABLE `phonesdb_prefix` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`region` varchar(255) NOT NULL,

`code_region` varchar(5) NOT NULL,

`description` longtext NOT NULL,

`town` bool NOT NULL

)

;TABLE `phonesdb_phone` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`content_type_id` integer,

`object_id` integer UNSIGNED,

`category_id` integer NOT NULL,

`prefix_id` integer,

`country_id` integer,

`phone` varchar(255) NOT NULL,

`description` longtext NOT NULL,

`long_distance` bool NOT NULL,

`view_phone` bool NOT NULL,

`priority` integer

)

;TABLE `phonesdb_phone` ADD CONSTRAINT `category_id_refs_id_4ccabbd6` FOREIGN KEY (`category_id`) REFERENCES `phonesdb_category` (`id`);TABLE `phonesdb_phone` ADD CONSTRAINT `content_type_id_refs_id_78474e02` FOREIGN KEY (`content_type_id`) REFERENCES `django_content_type` (`id`);TABLE `phonesdb_phone` ADD CONSTRAINT `country_id_refs_id_7fe8c99b` FOREIGN KEY (`country_id`) REFERENCES `phonesdb_country` (`id`);TABLE `phonesdb_phone` ADD CONSTRAINT `prefix_id_refs_id_67edd7dc` FOREIGN KEY (`prefix_id`) REFERENCES `phonesdb_prefix` (`id`);TABLE `phonesdb_body` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`title` varchar(30) NOT NULL UNIQUE,

`name_body` varchar(30) NOT NULL UNIQUE,

`description` longtext NOT NULL

)

;TABLE `phonesdb_department` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`content_type_id` integer,

`object_id` integer UNSIGNED,

`name` varchar(150) NOT NULL UNIQUE,

`shortname` varchar(50),

`description` longtext NOT NULL,

`modification_time` datetime,

`dep_id` integer UNSIGNED,

`tag_id` integer,

`body_id` integer,

`town_id` integer NOT NULL,

`room` varchar(20),

`email` varchar(75)

)

;TABLE `phonesdb_department` ADD CONSTRAINT `tag_id_refs_id_38f9a532` FOREIGN KEY (`tag_id`) REFERENCES `phonesdb_tag` (`id`);TABLE `phonesdb_department` ADD CONSTRAINT `body_id_refs_id_19c3be83` FOREIGN KEY (`body_id`) REFERENCES `phonesdb_body` (`id`);TABLE `phonesdb_department` ADD CONSTRAINT `content_type_id_refs_id_641557a3` FOREIGN KEY (`content_type_id`) REFERENCES `django_content_type` (`id`);TABLE `phonesdb_department` ADD CONSTRAINT `town_id_refs_id_584d8ffd` FOREIGN KEY (`town_id`) REFERENCES `phonesdb_prefix` (`id`);TABLE `phonesdb_person` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`content_type_id` integer,

`object_id` integer UNSIGNED,

`email` varchar(75),

`room` varchar(20),

`body_id` integer,

`first_name` varchar(30) NOT NULL,

`second_name` varchar(30),

`last_name` varchar(30) NOT NULL,

`post` varchar(100),

`is_manager` bool NOT NULL,

`tag_id` integer,

`town_id` integer NOT NULL,

`boss` integer,

`level_boss` integer

)

;TABLE `phonesdb_person` ADD CONSTRAINT `body_id_refs_id_40ecff50` FOREIGN KEY (`body_id`) REFERENCES `phonesdb_body` (`id`);TABLE `phonesdb_person` ADD CONSTRAINT `content_type_id_refs_id_34952670` FOREIGN KEY (`content_type_id`) REFERENCES `django_content_type` (`id`);TABLE `phonesdb_person` ADD CONSTRAINT `tag_id_refs_id_11936ae7` FOREIGN KEY (`tag_id`) REFERENCES `phonesdb_tag` (`id`);TABLE `phonesdb_person` ADD CONSTRAINT `town_id_refs_id_581f0136` FOREIGN KEY (`town_id`) REFERENCES `phonesdb_prefix` (`id`);TABLE `phonesdb_page_text` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`page` varchar(30) NOT NULL UNIQUE,

`title` varchar(100) NOT NULL,

`text` longtext NOT NULL,

`section` varchar(100)

)

;TABLE `phonesdb_temp` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`temp_id_dept` integer,

`temp_id_pers` integer

)

;TABLE `phonesdb_odttemplates` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`name_template` varchar(255) NOT NULL,

`file_template` varchar(100) NOT NULL

)

;INDEX `phonesdb_phone_1bb8f392` ON `phonesdb_phone` (`content_type_id`);INDEX `phonesdb_phone_42dc49bc` ON `phonesdb_phone` (`category_id`);INDEX `phonesdb_phone_33145cfa` ON `phonesdb_phone` (`prefix_id`);INDEX `phonesdb_phone_534dd89` ON `phonesdb_phone` (`country_id`);INDEX `phonesdb_phone_1350014a` ON `phonesdb_phone` (`phone`);INDEX `phonesdb_phone_73d5af42` ON `phonesdb_phone` (`long_distance`);INDEX `phonesdb_phone_5341e6d3` ON `phonesdb_phone` (`priority`);INDEX `phonesdb_department_1bb8f392` ON `phonesdb_department` (`content_type_id`);INDEX `phonesdb_department_3747b463` ON `phonesdb_department` (`tag_id`);INDEX `phonesdb_department_5b892844` ON `phonesdb_department` (`body_id`);INDEX `phonesdb_department_1fb3d69c` ON `phonesdb_department` (`town_id`);INDEX `phonesdb_person_1bb8f392` ON `phonesdb_person` (`content_type_id`);INDEX `phonesdb_person_5b892844` ON `phonesdb_person` (`body_id`);INDEX `phonesdb_person_3747b463` ON `phonesdb_person` (`tag_id`);INDEX `phonesdb_person_1fb3d69c` ON `phonesdb_person` (`town_id`);COMMIT;

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

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

1.1 Результаты предпроектного обследования

1.1.1 Объекты и методы проведения предпроектного обследования

1.1.2 Программа проведения обследования

.1.3 Результаты предпроектного обследования и их анализ

1.1.4 Анализ проблемных ситуаций и обоснование путей их решения

1.2 Формулировка задач проектирования

1.2.1 Общие сведения

1.2.2 Назначение, цели создания интерактивных сервисов

1.2.3 Характеристика объекта автоматизации

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

1.2.5 Состав и содержание работ по созданию подсистемы

1.2.6 Порядок контроля приемки подсистемы

1.2.7 Требования к составу и содержанию работ по подготовке объекта

автоматизации к вводу интерактивного сервиса в действие

1.2.8 Требование к документированию

2.1 Обоснование выбора среды реализации сервисов

2.3 Концептуальное проектирование интерактивных сервисов

2.4 Создание логической модели базы данных интерактивных сервисов

2.3.1 Определение сущностей модели базы данных

2.3.2 Определение атрибутов сущностей базы данных интерактивного сервиса

2.3.3 Определение связей между сущностями базы данных интерактивного сервиса

2.3.4 Задание первичных ключей сущностей

2.3.5 Логическа модель данных

2.4 Создание физической модели базы данных интерактивных сервисов

2.4.1 Генерирование SQL-сценария создания базы данных информационной подсистемы средствами Django ORM

2.5 Создание проекта и модулей

2.6 Реализация интерактивных сервисов

2.6.3 Создание представлений и привязок URL

2.6.4 Реализация формы обратной связи

2.6.5 Реализация формы поиска

2.6.6 Пользовательская проверка орфографии в сервисе

2.6.7 Настройка Web-сервера lighthttpd

Выводы

3.1 Общие сведения об интерактивных сервисах доступа к телефонному справочнику СевКавГТУ, г. Ставрополь

3.2 Функциональное назначение интерактивных сервисов доступа к телефонному справочнику СевКавГТУ г. Ставрополь

3.4 Требование к техническому обеспечению

3.4.1 Общие требования

3.4.2 Требования к центральному процессору

3.4.3 Требования к оперативному запоминающему устройству

3.4.4 Требования к наличию сводного места на жестком диске

3.4.5 Требования к монитору

3.5 Установка и вызов интерактивных сервисов

3.8 Результаты тестирования

4.2 Трудоёмкость выполняемых работ

4.3 Расчёт себестоимости интерактивных сервисов

4.4 Оценка экономической эффективности внедрения программного продукта

4.5 Основные технико-экономические показатели проекта

Выводы

Листинг файла models.py

SQL сценарий создания структуры базы данных

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