Рубрикатор 

Web-сайт сибирского медицинского журнала

 

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования "Томский государственный университет систем управления и радиоэлектроники" (ТУСУР)

Кафедра автоматизации обработки информации (АОИ)








Пояснительная записка к дипломному проекту

Web-сайт сибирского медицинского журнала















2014

РЕФЕРАТ


Дипломный проект 91 стр., 26 рис., 17 табл., 12 источника, 1 приложение.

WEB-САЙТ, СИБИРСКИЙ МЕДЕЦИНСКИЙ ЖУРНАЛ.

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

Цель работы - повышение цитируемости авторов статей "Сибирского медицинского журнала" и импакт-фактора журнала, продвижение журнала в Интернет-пространстве.

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

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

Дипломный проект выполнен в текстовом редакторе MS Word 2000, Web-сайт разработан на языке PHP.


ABSTRACT

91 p., 26 fig., 17 tables., 12 sources, 1 adj.SITE, THE SIBIRIAN MEDICAL JOURNAL.object of research is activities in the field of electronic medical journals, ways to improve citation indexes.aim is improving the authors of articles citing "Siberian Medical Journal" and the journal impact factor, promoting the magazine in the Internet space.result of the graduation project was a Web-site "The Siberian medical journal"explanatory note contains a description of the subject area, the problem situation, solutions to the problem.degree project is executed in a text editor, MS Word 2000, the Web-site was developed in PHP.


СОДЕРЖАНИЕ


ВВЕДЕНИЕ

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

2. ПОСТАНОВКА ЗАДАЧИ И ПУТИ РЕШЕНИЯ

.1 Описание проблемной ситуации

.2 Пути решения проблемы

.3 Постановка задачи

.4 Обзор аналогов

.5 Выбор средств реализации

3. ВЫЯВЛЕНИЕ И СБОР ТРЕБОВАНИЙ

.1 Запросы заинтересованных сторон

.2 Бизнес-правила

.3 Функциональные требования

.4 Нефункциональные требования

4. ПРОЕКТИРОВАНИЕ

.1 Описание методологии RUP

.2 Описание структуры сайта

.3 Диаграмма прецедентов

.4 Модель предметной области

.5 Диаграмма последовательности

.6 Диаграмма деятельности

.7 Модель базы данных

5. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ

.1 Сервер

.2 Клиент

.3 Обмен данными

.4 Система управления сайтом

.5 Описание разделов сайта

6. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА

.1 Описание программного продукта

.2 Определение технико-экономических показателей проекта прямым методом

.3 Метод определения ТЭП проекта на основе размерности базы данных

.4 Определение технико-экономических показателей методом функциональных точек

.5 Определение договорной цены на создание программной системы

.6 Резюме

ЗАКЛЮЧЕНИЕ

Список использованных источников

ПРИЛОЖЕНИЕ

медицинский журнал сайт прецедент

ВВЕДЕНИЕ


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

Кроме того, целесообразность создания сайта журнала, как инструмента аккумулирования и распространения знаний, может и должна быть обоснована экономически. Потребность в сайте "Сибирского медицинского журнала" возникла в результате изменений в законодательстве: в конце августа 2010 г. был издан Приказ Министерства здравоохранения и социального развития РФ № 738н "Об оценке результативности деятельности научных организаций, подведомственных Минздравсоцразвития России, выполняющих научно-исследовательские, опытно-конструкторские и технологические работы гражданского назначения". Согласно приказу планируется оценка научного потенциала. Один из основных критериев оценки - участие в организации индексирования библиометрических показателей Scopus. Scopus- библиографическая и реферативная база данных и инструмент для отслеживания цитируемости статей, опубликованных в научных изданиях. Индексирует 18 000 названий научных изданий по техническим, медицинским и гуманитарным наукам 5000 издателей. Результаты оценки библиометрических показателей влияют на финансирование научного учреждения. Чтобы повысить этот показатель для ФГБУ "НИИ кардиологии" СО РАМН, было принято решение создать сайт "Сибирского медицинского журнала".


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


ФГБУ "НИИ кардиологии" СО РАМН занимает стабильную позицию среди лидеров федеральных медицинских учреждений, участвующих в оказании высокотехнологичной медицинской помощи гражданам РФ по профилю "сердечно-сосудистая хирургия" за счет ассигнований федерального бюджета.

Основные направления научной деятельности института:

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

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

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

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

·В ФГБУ "НИИ кардиологии" СО РАМН проводятся интенсивные научные исследования практически по всем актуальным направлениям современной кардиологии.

·В рамках ФЗ № 217 ФГБУ "НИИ кардиологии" СО РАМН и Национальным исследовательским Томским государственным политехническим университетом создано первое совместное инновационное предприятие "Нанокор", которое будет работать в условиях Фонда "Сколково" [2].

ФГБУ "НИИ кардиологии" СО РАМН выпускает рецензируемый журнал "Сибирский медицинский журнал", который был основан в 1922 году. Это ежеквартальный рецензируемый научно-практический журнал, ориентирован на практических врачей всех специальностей, научных работников и студентов, а также на широкую читательскую аудиторию, проявляющую интерес к достижениям современной медицины. Содержит уникальные материалы и фотографии по истории медицины и здравоохранения Сибири и Дальнего Востока.

"Сибирский медицинский журнал" издавался в г. Томске с 1923 по 1931 гг. В 1996 году выпуск журнала был возрожден под издательством Российской академии медицинских наук Научно-исследовательский институт кардиологии Сибирского отделения Российской академии медицинских наук. В журнал входят следующие основные разделы:

·Клинические исследования;

·Лабораторные и экспериментальные исследования;

·Организация здравоохранения и общественное здравоохранение;

·Опыт регионов;

·В помощь практическому врачу;

·Обзоры и лекции;

·Рецензии и рефераты;

·Интеллектуальная собственность в медицине;

·История медицины.

·Главный редактор журнала: Р.С. Карпов, академик РАМН.

·Члены редакционной коллегии:

·Л.А. Агаркова, профессор;

·Ф.В. Алябьева, доцент;

·А.В. Врублевский, д.м.н.;

·Н.П. Гарганеева, профессор;

·В.В. Климов, профессор;

·М.А. Медведев, академик РАМН;

·Г.И. Мендрина, профессор;

·С.А. Некрылов, доцент;

·В.В. Поддубный, профессор;

·С.В. Попов, профессор;

·Р.Г. Соляник, профессор;

·Ф.Ф. Тетенев, профессор;

·И.А. Трубачева, д.м.н.;

·В.В. Удут, профессор.


2. ПОСТАНОВКА ЗАДАЧИ И ПУТИ РЕШЕНИЯ


.1 Описание проблемной ситуации


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

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

Использование библиометрических показателей стало возможным благодаря созданию д-ром Ю. Гарфилдом в 1961 г. Института научной информации США, выпускающего с 1964 г. Указатель цитированной литературы - Science Citation Index. Мониторинг этих показателей проводится во всех промышленных странах мира [3]. Целесообразность использования библиометрических показателей была в 2003 г. была подтверждена статистическим институтом ЮНЕСКО, который ввел в качестве параметров измерения научной деятельности следубщие библиометрические данные: количество публикаций, их цитируемость, количество поданных патентов [4].

Таким образом, чтобы упрочнить свое положение и финансовое обеспечение ФГБУ "НИИ кардиологии" СО РАМН необходимо повысить публикационную своих сотрудников.


2.2 Пути решения проблемы


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


2.3 Постановка задачи


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

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

·повысить импакт-фактор издания;

·улучшить контроль за научной деятельностью сотрудников;

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

·расширить читательскую аудиторию;

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

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

·повысить рейтинг ФГБУ "НИИ кардиологии" СО РАМН среди научных учреждений РФ.

Сайт способен вывести журнал на новый уровень развития и эффективно решить проблему библиометрических показателей сотрудников ФГБУ "НИИ кардиологии" СО РАМН.


2.4 Обзор аналогов


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

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


Таблица 2.1 - Сравнение по функциональным возможностям

№Функциональные возможности сайтов"Сибирский медицинский журнал""Pоссийский онкологический журнал""Журнал российского государственного медицинского университета"1Удобное и интуитивно понятное меню+-+2Возможность подать электронную заявку на опубликование статьи++-№Функциональные возможности сайтов"Сибирский медицинский журнал""Pоссийский онкологический журнал""Журнал российского государственного медицинского университета"3Возможность подать электронную заявку на участие в независимом рецензировании+--4Возможность поиска по архиву журнала+--5Возможность скачивания статей++-6Просмотр полного текста статей+--7Возможность комментирования статей+--8Информация о предстоящих научных событиях+++9Обращение главного редактора+--10Информация для авторов+++11Информация о редакционной коллегии и редакционном совете+++

2.5 Выбор средств реализации


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

СУБД

MySQL - это объектно-реляционная система управления базами данных (СУБД), которая имеет традиционные возможности коммерческих СУБД с расширениями, которые есть в СУБД нового поколения. MySQL - это свободное и полностью открытое программное обеспечение. MySQL базируется на языке SQL и поддерживает многие из возможностей стандарта SQL:2003 (ISO/IEC 9075) [6].

Сильными сторонами MySQL считаются:

·поддержка БД практически неограниченного размера;

·мощные и надёжные механизмы транзакций и репликации;

·наследование;

·легкая расширяемость.

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

Производительность MySQL сходна с другими коммерческими СУБД и с СУБД с открытым исходным кодом.

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

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

Сервер Apache

В качестве сервера приложений, выбран web-сервер Apache. С апреля 1996 и до настоящего времени является самым популярным HTTP-сервером в Интернете. По статистике Netcraft, в августе 2007 года он установлен на 51 % всех веб-серверов, в марте 2009 года - на 49 % [6].

Будучи бесплатной открытой программой, предназначенной для эксплуатации под управлением Unix-систем (FreeBSD, Linux и др.), Apache по функциональным возможностям и надежности не уступает коммерческим серверам, а широкие возможности конфигурирования позволяют настроить его для работы практически с любой конкретной системой. Существуют локализации сервера для различных языков, в том числе и для русского [7].


3. ВЫЯВЛЕНИЕ И СБОР ТРЕБОВАНИЙ


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

Этап сбора требований необходим для:

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

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

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

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

Согласно рекомендациям RUP требования необходимо сгруппировать по категориям:

·функциональные возможности (functionality);

·практичность (usability);

·надежность (reliability);

·производительность (performance);

·возможность поддержки (supportability).

Требования практичности (usability) - требования такого типа описывают, как пользователи будут приспосабливаться к системе.

Требования надежности (reliability) - требования, которые определяют насколько приемлемым с точки зрения пользователя образом должна вести себя система.

Требования к производительности (performance) - требования, которые показывают все параметры производительности системы.

Требования к возможности поддержки (supportability) - требования, которые заключаются в способности легко модифицировать программное обеспечение с целью внесения изменений и исправлений [11].


3.1 Запросы заинтересованных сторон


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

Сведения о заинтересованных сторонах:

·ФГБУ "НИИ кардиологии" СО РАМН - непосредственный заказчик и потребитель, представитель - руководитель отделения популяционной кардиологии с группой научно-медицинской информации, патентоведения и международных связей;

·ФГУ Центральный НИИ организации и информатизации здравоохранения - заинтересовано в повышении доступности и увеличении рейтинга российских научных исследований в области медицины, представитель - заведующий отделением коммуникационных технологий и общего программного обеспечения;

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

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

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

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


Таблица 3.1 - Запросы заинтересованных сторон

Запросы заинтересованных сторонПриоритетПроисхождениеSTRQ1: Улучшить контроль Улучшить контроль за научной деятельностью соктрудниковНизкийРуководитель одела межд. связейSTRQ2: Повысить доступность журнала Повысить доступность материалов опубликованных в журналеСреднийЧитательская аудиторияSTRQ3: Расширить читательскую аудиториюСреднийРуководитель одела межд. связейSTRQ4: Повысить цитируемость сотрудников НИИ Индексы цитируемости сотрудников один из пунктов оценки деятельности НИИВысокийРуководитель одела межд. связейSTRQ5: Увеличить популярность журналаВысокийЗаведующий отд. коммуник. техн.STRQ6: Привлечь новых авторов Повысить привлекательность журнала в научной средеСреднийРуководитель одела межд. связейЗапросы заинтересованных сторонПриоритетПроисхождениеSTRQ7: Увеличить прибыль Увеличить прибыль за счет новых способов рекламы СреднийРуководитель одела межд. связейSTRQ10: Повысить рейтинг ФГБУ "НИИ кардиологии" СО РАМН среди научных организаций РФСреднийРуководитель одела межд. связей

3.2 Бизнес-правила


Бизнес-правила предназначены для защиты структуры бизнеса или влияния на его операции. В таблице3.2 приведена матрица атрибутов бизнес-правил.


Таблица 3.2 - Бизнес-правила проекта

Бизнес-правилаВид бизнес-правилаBR1: Оформление статьи К каждой статье публикуется аннотация на русском и английском языкахФактBR2: Оформление статьи Каждой статье соотствует список литературы в романском алфавитеФактBR3: Оформление статьи Заглавие статьи публикуется на английском и русском языкахФактBR4: ISSN У журнала есть Международный стандартный номер журналаФактBR5: Редакционный совет Журнал возлавляет редакционный советФактBR6: Для авторов Существуют специальные правила оформления статейФактBR7: Авторы У статьи может быть несколько авторовФактBR8: Письмо главного редактора К каждому новому номеру прилагается письмо редактора.ФактBR9: Рецензенты Каждая статья рецензируетсяФактBR10: Заявка на размещение статьи Рассмотрение статьи на публикацию происходит по заявке автораФактBR11: Правила подачи заявки Существуют специальные правила подачи заявки на публикациюФактBR12: Правила оформления статьи Существуют определенные правила оформления статьи к публикации в журналеФактBR13: Архив журнала Вышедшие номера журнала попадают в архив журналаФактBR14: Вопрос автору Чиататели могут задавать вопросы авторамФактБизнес-правилаВид бизнес-правилаBR15: Переодичность Журнал издается 3 раза в годФактBR16: Срок рассмотрения заявки 2 неделиФактBR17: Публикация платная автор оплачивает публикациюФактBR18: Заявка Авторы подают в журнал заявку на публикацию статьиФакт

3.3 Функциональные требования


Функциональные требования (functional requirements) определяют функциональность разрабатываемой системы, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным "должен" или "должна".

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

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

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


Таблица 3.3 - Матрица атрибутов функциональных требований

RequirementsПолезностьСтатусСложностьСтабильностьFEAT1: Авторизация Система должна разграничивать пользователей по правам. ВажнаяВключена в проектНизкаяВысокаяFEAT2: Регистрация Система должна иметь возможность регистрировать пользователей ВажнаяВключена в проектСредняяВысокаяFEAT3: Изменить аккаунт Система должна предоставлять возможность зарегистрированному пользователю изменять аккаунт. ВажнаяВключена в проектСредняяВысокаяFEAT4: Сохранение измененных данных Система должна позволять сохранять измененные данные пользователя. ВажнаяВключена в проектСредняяВысокаяRequirementsПолезностьСтатусСложностьСтабильностьFEAT5: Добавить участника Система должна иметь возможность добавлять новых участников. КритическаяВключена в проектВысокаяВысокаяFEAT6: Удалить участника Система должна иметь возможность удалять участников (зарегистрированных пользователей, авторов) ВажнаяВключена в проектНизкаяВысокаяFEAT7: Добавить статью Система должна иметь возможность добавлять новую статью. КритическаяВключена в проектВысокаяВысокаяFEAT8: Удалить статью Система должна иметь возможность удалить статью. ВажнаяВключена в проектСредняяВысокаяFEAT9: Поиск Система должна осуществлять поиск по архиву журнала КритическаяВключена в проектВысокаяСредняяFEAT10: Информация об авторах Система должна иметь возможность хранить информацию об авторах. ПолезнаяВключена в проектСредняяСредняяFEAT11: Авторы Система должна иметь возможность выводить краткую информацию об авторах ПолезнаяВключена в проектНизкаяСредняяFEAT12: Статьи журнала Система должна предоставлять возможность зарегистрированным пользователям скачивать полные тексты статей ВажнаяВключена в проектСредняяВысокаяFEAT13: Архив журнала Система должна иметь возможность хранить весь архив номеров журнала. ВажнаяВключена в проектСредняяВысокаяFEAT14: Скачать архив журнала Система должна предоставлять возможность зарегистрированным пользователям скачать архив номеров журнала за определенный год. ПолезнаяВключена в проектСредняяВысокаяFEAT15: Посмотреть статью Система должна предоставлять пользователю возможность просматривать тексты статей. КритическаяВключена в проектСредняяСредняяFEAT16: Оформление статьи Система должна предоставить пользователю правила оформления статьи к публикации в журнале. ВажнаяВключена в проектНизкаяВысокаяRequirementsПолезностьСтатусСложностьСтабильностьFEAT17: Заявка на публикацию Система должна предоставить зарегистрированному пользователю возможность оформить заявку на публикацию статьи в журнале. ВажнаяВключена в проектСредняяСредняяFEAT18: Ответ на заявку Система должна уведомлять пользователя о статусе заявки (принята/отклонена). ВажнаяВключена в проектСредняяСредняяFEAT19: Комментарии к статье Система должна предоставлять зарегистрированному пользователю возможность оставлять комментарии к статье . ПолезнаяВключена в проектСредняяВысокаяFEAT20: Информация о журнале Система должна предоставлять пользователю информацию о журнале. КритическаяВключена в проектНизкаяВысокаяFEAT21: Новости Система должна предоставлять пользователю информацию о предстоящих/прошедших научных событиях в сфере медицины. ПолезнаяВключена в проектСредняяСредняяFEAT22: Новостная рассылка Система должна предоставлять зарегистрированному пользователю возможность подписаться на новостную рассылку. ПолезнаяВключена в проектСредняяСредняяFEAT23: Отмена новостной рассылки Система должна предоставлять зарегистрированному пользователю возможность отказаться от новостной рассылки ПолезнаяВключена в проектНизкаяВысокаяFEAT24: Облако тегов Система должна вести статистику популярности ключевых слов исходя из просмотров статей пользователями КритическаяПредложенаСредняяСредняяFEAT25: Восстановление пароля Система должна восстанавливать пароль по запросу пользователя. ВажнаяВключена в проектСредняяВысокаяFEAT26: Статистика Система должна собирать статистику по количеству просмотров статей определенных категорий зарегистрированными пользователями. ПолезнаяВключена в проектВысокая Средняя

.4 Нефункциональные требования


Требования практичности

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

·система должна легко осваиваться пользователем в течение 7-10 минут;

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

Требования надежности

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

·время обработки запроса должно занимать не более 5 сек.;

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

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

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


4. ПРОЕКТИРОВАНИЕ


.1 Описание методологии RUP


В процессе разработки приложения учитывались рекомендации Rational Unified Process (RUP) - методологии разработки программного обеспечения от компании Rational Software.обеспечивает строгий подход к назначению задач и ответственности в пределах группы разработки. Его цель состоит в том, чтобы гарантировать высокое качество программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого временного графика и бюджета.предполагает создание и актуализацию моделей на протяжении всего жизненного цикла проекта. RUP фокусирует внимание не на создании большого количества бумажных документов, а на развитии и эксплуатации моделей - семантически богатых представлений программной системы при ее разработке.сосредотачивает внимание на первоначальной разработке и компоновке устойчивой архитектуры программы, которая облегчает параллельную разработку, минимизирует модификации, увеличивает возможность многократного использования и надежность эксплуатации. Эта архитектура используется для планирования использования и управления развитием программных компонентов.

Также RUP поддерживает объектно-ориентированную технологию. Некоторые из моделей являются объектно-ориентированными моделями, которые базируются на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам - артефактам, используют унифицированный язык моделирования (UML) как общую систему обозначений [8].

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

·IBM Rational Requisite Pro - инструмент сбора и управления требованиями;

·IBM Rational Rose - средство визуального моделирования бизнес процессов, и проектирования на языке UML;

·UML (Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения [8].


4.2 Описание структуры сайта


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

Ниже представлена структура сайта:

·О журнале:

а)Из истории;

б)Положение о журнале;

в)Редакционная коллегия;

г)Редакционный совет;

д)Учредители;

е)Партнеры;

ж)Подписка;

·Редакция:

а)Редакционно-издательская группа;

б)Контакты;

·Авторам:

а)Условия публикации;

б)Правила оформления статей;

в)Образцы документов;

г)Реквизиты для оплаты публикаций;

д)Авторские права;

е)Наши авторы;

ж)Услуги;

з)Полезные ссылки;

·Рецензентам:

а)Положение об институте рецензентов;

б)Образец рецензии;

в)Предложение к сотрудничеству;

г)Анкета рецензента;

·Новости;

·Архив;

·Вопрос-ответ;

·Скачать свежий номер;

·Поиск;

·Обращение главного редактора;

·Личный кабинет пользователя.

Подробнее о структуре сайта в приложении А.


4.3 Диаграмма прецедентов


Диаграмма прецедентов (use case diagram) относится к концептуальному представлению системы, описывая назначение системы. Она разрабатывается для достижения следующих целей [8]:

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

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

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

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

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


Рисунок 4.1 - Диаграмма прецедентов


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

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

·"Удалить пользователя" - Администратор выбирает пункт меню "Управление пользователями". Система открывает специальную форму с таблицей, в которой собрана информация обо всех пользователях. Администратор в поле поиска вводит имя пользователя. Система осуществляет поиск по таблице, выводит совпадения. Администратор выбирает пользователя из результата поиска, нажимает кнопку удалить. Система запрашивает подтверждение удаления. Администратор подтверждает удаление. Система удаляет пользователя;

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

·"Опубликовать новости" - Администратор выбирает пункт меню "Добавить новость". Система открывает специальную форму. Администратор заполняет требуемые поля, прикрепляет изображение; нажимает кнопку добавить. Система загружает новость;

·"Искать по архиву журнала" - Пользователь выбирает пункт меню "Поиск". Система открывает форму поиска. Пользователь заполняет необходимые поля и нажимает кнопку "Найти". Система осуществляет поиск по заданным критериям; выводит результат поиска;

·"Просматривать тексты статей" - Пользователь выбирает пункт меню "Архив". Система переходит на страницу с временной шкалой. Пользователь выбирает год, номер журнала. Система выводит список заголовков статей и авторов соответственно. Пользователь нажимает на заголовок статьи. Система загружает полный текст статьи в формате pdf;

·"Просматривать новости" - Пользователь выбирает пункт меню "Новости". Система загружает необходимую страницу;

·"Посмотреть информацию о журнале" - Пользователь выбирает пункт меню "О журнале". Система переходит на соответствующую страницу;

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

·"Войти в систему" - Зарегистрированный пользователь нажимает кнопку "Вход". Система открывает специальную форму. Пользователь вводит e-mail и пароль; нажимает кнопку "Войти". Система проверяет введенные данные; загружает главную страницу;

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

·"Подать заявку на размещение статьи в журнале" - Зарегистрированный пользователь выбирает пункт меню "Подать заявку". Система загружает специальную форму. Зарегистрированный пользователь вводит требуемую информацию; прикрепляет свою статью, резюме, сопроводительное письмо. Система верифицирует и регистрирует изменения. Пользователь нажимает кнопку "Отправить". Система регистрирует заявку;

·"Скачать статью" - Зарегистрированный пользователь выбирает пункт меню "Архив". Система переходит на страницу с временной шкалой. Пользователь выбирает год, номер журнала. Система выводит список заголовков статей и авторов соответственно. Пользователь выбирает статью; нажимает кнопку "Скачать"; через диалоговое окно указывает путь, куда сохранить. Система загружает статью с сервера;

·"Профиль" - Зарегистрированный пользователь нажимает кнопку "Настроить аккаунт". Система загружает станицу с информацией об этом пользователе. Зарегистрированный пользователь вносит изменения. Система верифицирует и регистрирует изменения. Зарегистрированный пользователь нажимает кнопку "Сохранить". Система сохраняет изменения.

Спецификация прецедента "Добавить статью"

Краткое описание:

Администратор добавляет статью в БД системы.

Основной актер:

Администратор.

Заинтересованные стороны и их потребности:

·Автор. Увеличить число читателей статьи, повысить свой индекс цитируемости;

·Организация. Повысить свой рейтинг;

·Администратор. Актуализировать электронную версию журнала;

·Читатель. Бесплатно получить новый актуальный источник знаний.

Предусловия: Администратор идентифицирован и аутентифицирован.

Постусловия: Статья успешно сохранена в БД.

Потоки событий:

Основной поток (Основной успешный сценарий)

1)Администратор выбирает пункт меню "Добавить статью".

)Система открывает специальную форму.

)Администратор вводит заголовок на русском языке.

)Администратор вводит заголовок на английском языке.

)Администратор вводит УДК.

)Администратор выбирает автора из выпадающего списка.

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

)Администратор водит ключевое слово.

)Система формирует список близких по лексическому значению ключевых слов.

)Администратор выбирает из списка нужное ключевое слово.

)Система добавляет ключевое слово к списку ключевых слов этой статьи.

)Администратор выбирает категорию из выпадающего списка.

)Администратор нажимает кнопку "Прикрепить аннотацию на русском языке".

14)Система открывает диалоговое окно.

15)Администратор выбирает из каталога файл.

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

)Администратор нажимает кнопку "Прикрепить аннотацию на английском языке".

)Система открывает диалоговое окно.

)Администратор выбирает из каталога файл.

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

)Администратор нажимает на кнопку "Прикрепить статью".

)Система открывает диалоговое окно.

)Администратор выбирает из каталога файл.

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

)Администратор нажимает кнопку "Добавить".

)Система загружает новую статью на сервер.

)Система выдает сообщение об успешной загрузки статьи.

)Система увеличивает рейтинг категории.

)Система обновляет облако тегов.

Альтернативные потоки (Расширения):

*а. При каждом выходе системы из строя.

)Система выдает сообщение об ошибке

)Система возвращает Администратора на главную страницу

a. Автора нет в списке.

)Администратор нажимает на кнопку "+".

)Система отрывает форму добавления нового участника.

)Администратор заполняет пустые поля.

)Нажимает кнопку добавить.

)Система проверяет правильность заполнения формы. Если форма заполнена некорректно возвращает пользователя на форму и выделяет красным необходимые для корректировки поля.

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

)Система создает нового участника.

a. Ключевого слова нет в списке или список пуст.

)Администратор нажимает кнопку "+".

)Система сохраняет новое ключевое слово.

a.Категории нет в списке.

)Администратор вводит в поле новое слово.

)Администратор нажимает кнопку "+".

)Система создает новую категорию.

a. Не все поля заполнены.

)Система возвращает администратора на форму добавления.

)Система выдает сообщение об ошибке.

)Система выделяет поля, которые необходимо заполнить.

а. Произошла ошибка при загрузке.

)Система выдает сообщение об ошибке.

)Система возвращает администратора на форму добавления.


4.4 Модель предметной области


Модель предметной области - визуальное представление концептуальных классов или объектов реального мира в терминах предметной области [9].

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

Модель предметной области сайта представлена в виде диаграммы классов на рисунке 4.2.


Рисунок4.2 - Модель предметной области


4.5 Диаграмма последовательности


Диаграмма последовательности (рис. 4.3) - это быстрый и легко создаваемый артефакт, иллюстрирующий входные и выходные события, связанные с разрабатываемой системой. Прецеденты определяют, как исполнители взаимодействуют с программной системой. В процессе этого взаимодействия исполнителем генерируются события, предаваемые системе, которые представляют собой запросы на выполнение некоторой операции [10].


Рисунок 4.3 - Диаграмма последовательности для прецедента "Добавить статью"

Рисунок 4.4 - Диаграмма последовательности для прецедента "Добавить статью" (продолжение)


4.6 Диаграмма деятельности


В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. Отдельные элементарные вычисления, приводящие к некоторому результату, называют действием (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате осуществления деятельности. Результат может привести к изменению состояния системы или возвращению некоторого значения. На рисунке 4.5 представлена диаграмма деятельности да прецедента "Добавить статью".


Рисунок 4.5 - Диаграмма деятельности для прецедента "Добавить статью"

4.7 Модель базы данных


Логическая и физическая модели базы данных представлены на рисунках 4.6-4.7.


Рисунок 4.6 - Концептуальная модель базы данных


Рисунок 4.7 - Физическая модель базы данных


5. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ


5.1 Сервер


В качестве сервера приложений, выбран web-сервер Apache. С апреля 1996 и до настоящего времени является самым популярным HTTP-сервером в Интернете. По статистике Netcraft, в августе 2007 года он установлен на 51 % всех веб-серверов, в марте 2009 года - на 49 % [10].

Будучи бесплатной открытой программой, предназначенной для эксплуатации под управлением Unix-систем (FreeBSD, Linux и др.), Apache по функциональным возможностям и надежности не уступает коммерческим серверам, а широкие возможности конфигурирования позволяют настроить его для работы практически с любой конкретной системой. Существуют локализации сервера для различных языков, в том числе и для русского [10].


5.2 Клиент


Клиенту для доступа к приложению необходимо иметь подключение к Интернету, Internet-браузер с предустановленным плагином для просмотра файлов формате *.pdf. Персональный компьютер: Intel Celeron 1,3 GHz, 256 Mb, HDD - 80 Gb.


5.3 Обмен данными

(от англ. HyperText Markup Language - "язык разметки гипертекста") - стандартный язык разметки документов во Всемирной паутине. Большинство веб-страниц создаются при помощи языка HTML. Язык HTML интерпретируется браузерами и отображается в виде документа, в удобной для человека форме.

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


Рисунок 5.1 - Процесс построения html-страниц на сайте


5.4 Система управления сайтом


Для управления содержимым сайта использовано готовое интернет-решение "SEO CMS", которое:

·обеспечивает редактирование содержимого сайта;

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


5.5 Описание разделов сайта


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

·навигационное меню по разделам сайта;

·блок "Поиск";

·блок "Авторизация";

·модуль "Линейка фотографий";

·графический элемент "Скачать свежий номер";

·блок "Рубрики";

·блок "Обращение главного редактора";

·блок "Карта сайта".

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

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

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

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


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


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


Рисунок 5.3 - Форма регистрации


Раздел "О журнале"

Раздел "О журнале" состоит из шести информационных подразделов, заполняемых администратором сайта (рис 6.4):

·"Из истории";

·"Положение о журнале";

·"Редакционная коллегия";

·"Учредители";

·"Партнеры";

·"Подписка".

Рисунок 5.4 - Подразделы раздела "О журнале"


Раздел "Авторам"

На сайте создан специальный раздел для размещения информации актуальной для авторов журнала (рис 6.5). Данный раздел включает восемь подразделов:

·"Условия публикации";

·"Правила оформления статей";

·"Образцы документов";

·"Реквизиты для оплаты публикаций";

·"Авторские права";

·"Наши авторы";

·"Услуги";

·"Полезные ссылки".

Раздел "Редакция"

Чтобы получить информацию о редакционно-издательской группе, посетитель сайта может воспользоваться разделом "Редакция" (рис. 5.6)


Рисунок 5.5 - Подразделы раздела "Авторам"

Рисунок 5.6 - Подразделы раздела "Редакция"


Раздел "Новости"

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


Рисунок 5.7 - Раздел новости


Раздел "Архив"

Все выпуски журнала доступны посетителям сайта в разделе "Архив".

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

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

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

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

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


Рисунок 5.8 - Форма поиска по архиву журнала


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


Рисунок 5.9 - Страница статьи журнала


Личный кабинет зарегистрированного пользователя

Для того чтобы войти в личный кабинет (рис. 6.10), посетитель сайта должен авторизоваться, т.е. в форме авторизации указать свой адрес электронный почты и пароль, после чего нажать кнопку "Войти". Скрипт проверяет: существует ли такая пара логин-пароль в таблице пользователей, если такой пользователь найден - то он авторизуется в системе, в противном случае система перенаправляет пользователя на страницу авторизации, где ему выдается информационное сообщение об ошибки авторизации.

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

·"Мой профиль" (рис. 6.10);

·"Подать заявку" (рис. 6.11);

·"Мои заявки";

·"Выйти".

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

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

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

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

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

Рисунок 5.10 - Личный кабинет зарегистрированного пользователя


Рисунок 5.11 - Форма заявки на публикацию в журнале


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

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


6. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА


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

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

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

В качестве основных показателей оценки стоимости программной системы используются [12]:

·сложность (размеры) программной системы;

·трудозатраты на разработку;

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

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

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

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


6.1 Описание программного продукта


Официальный web-сайт "Сибирского медицинского журнала".

Поставщик: кафедра автоматизации обработки информации ТУСУР. Адрес: 634045, г. Томск, ул. Вершинина, 74, корп. ФЭТ ТУСУРа, ауд. 405. тел. 41-44-70.

Официальный web-сайт "Сибирского медицинского журнала" - web-приложение, предназначенное для обеспечения Интернет-аудитории информацией о научной деятельности ФГБУ "НИИ кардиологии".

Необходимая программно-аппаратная платформа.

Сайт разработан в архитектуре "клиент-сервер". Основной язык программирования -PHP/ Для обеспечения нормального функционирования системы необходим персональный компьютер с предустановленной и сконфигурированной ОС семейства Unix, СУБД MySQL, Web-сервером Apache 2.0.х.

Для корректного просмотра пользовательской части сайта необходимо использовать Internet-браузер с предустановленным плагином для просмотра файлов с расширением *.pdf. Для доступа к сайту достаточным является dial-up соединение. Рекомендуется использовать широкополосное подключение.

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

·Сервер: Intel Pentium IV 3.0 GHz/2048 Mb, HDD 120Gb, сеть 1000/100 Mbps;

·Клиент: Intel Celeron 1,3 GHz, 256 Mb, HDD - 80 Gb, доступ в Интернет и Интернет-браузер с предустановленным плагином просмотра файлов с расширением *.pdf.приложение не снабжено программой инсталляции, поэтому разработчик возлагает на себя обязанности по установке программного продукта на сервер.

В комплект поставки входит техническая документация в составе:

·"Web-сайт "Сибирского медицинского журнала". Техническое задание;

·"Web-сайт "Сибирского медицинского журнала". Общее описание системы.

Документация выполнена в соответствии с Государственный стандартом РФ ГОСТ Р ИСО/МЭК 15910-2002. Информационная технология. Процесс создания документации пользователя программного средства. Эффективность использования web-приложения заключается в:

·улучшении контроля за научной деятельностью сотрудников;

·повышении доступности материалов, опубликованных в журнале;

·расширении читательской аудитории;

·повышении цитируемости сотрудников учреждения;

·повышении привлекательности журнала в научной среде;

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

·повышении рейтинга ФГБУ "НИИ кардиологии" СО РАМН среди научных учреждений РФ.

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

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

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

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

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

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

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

При работе с сайтом предполагается, что пользователь знаком в общих чертах с операционной системой MS Windows 2000/XP, и владеет базовыми навыками работы в ней, при этом он должен обладать простейшим опытом работы с окнами (Windows) и минимальными навыками работы в сети Интернет. Экономическая часть дипломного проекта выполнена в соответствии с методическими указаниями "Технико-экономическое обоснование стоимости программных систем. Методические указания по выполнению экономической части дипломного проекта для студентов специальности 230102 "Автоматизированные системы обработки информации и управления" [12].

Определим технико-экономические показатели (ТЭП) и структуру договорной цены системы на основании методики, изложенной в [12].


6.2 Определение технико-экономических показателей проекта прямым методом


Исходные данные:

·тип системы: программно-информационная;

·сложность системы: простая;

·язык программирования - PHP;

·плановый срок разработки системы, установленный заказчиком - 6 месяцев.

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

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

Каждый из экспертов должен дать оптимистическую (о), пессимистическую (p) и реалистическую (b) оценки.

Средняя оценка по бета-распределению определяется по формуле:


.


Оценка размерности программной системы проводилась двумя экспертами, результаты оценки представлены в таблицах 7.1 и 7.2. Используемые сокращения: П - пессимистическая оценка; Р - реалистическая оценка; О - оптимистическая оценка.


Рисунок 6.1 - Структура сайта "Сибирского медицинского журнала"


Таблица 6.1 - Бланк экспертного оценивания размерности программной системы первым экспертом (представитель разработчика)


Таблица 6.2 - Бланк экспертного оценивания размерности программной системы первым экспертом (представитель заказчика)


Рассчитаем сумму средних значений по формуле:


,


где q - количество экспертов;

- количество программных компонент на i -ом уровне.

Размер программной системы R = 12352 строк кода.

Оценка трудозатрат и средней численности разработчиков основывается на согласовании между разработчиком и заказчиком производительности труда программиста. Принимая норматив трудоемкости разработки программ P=220 строк/чел.-месяц (простая информационно-справочная система, количество строк - до 30 тыс.) табл. 2.3. [12], рассчитаем трудозатраты по формуле:


чел./ месяц.


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


чел.,


где Д - длительность разработки.

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

·трудозатраты на разработку системы составят 56.15 человеко-месяцев;

·необходимые людские ресурсы = 9.35 чел.


6.3 Метод определения ТЭП проекта на основе размерности базы данных


Исходные данные:

·тип системы: программно-информационная;

·сложность системы: простая;

·СУБД - MySQL

·плановый срок разработки системы - 6 месяцев.

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

Рисунок 6.2 - Фрагмент логической модели базы данных


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

N - количество таблиц (объектов) = 11;

- количество взаимосвязей между объектами = 10;

M - количество атрибутов на один объект 20/11 = 1.82.

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



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


полей БД


Далее переходим к расчету ТЭП проекта. Вводится понятие "нормализованной величины" при создании программной системы. Это количество формируемых атрибутов, входящих в электронные таблицы посредством установленных связей.

При значениях N, и М, равных единице, величина, выражающая их количество равна 100. Трудозатраты определяются на основе статистических нормативов трудоемкости, приведенных в таблице 2.15 [12] по формуле:


В нашем случае размерность базы данных (2002) находится в первом нормативном промежутке, что соответствует значению норматива = 0,00566. Таким образом, трудоемкость будет равна:


чел.-месяцев.


Длительность разработки, установленная заказчиком Д = 6 месяцев, тогда средняя численность специалистов, которые должны быть привлечены к реализации ПС, определяется по формуле:


чел.


Таким образом, применяя метод определения ТЭП на основе размерности базы данных, мы определили следующие основные технико-экономические показатели разработки:

·трудозатраты на разработку системы составят 1,13 человеко-месяцев;

·необходимые людские ресурсы = 0,2 чел.


6.4 Определение технико-экономических показателей методом функциональных точек


Исходные данные:

·тип системы: программно-информационная;

·сложность системы: простая;

·язык программирования - PHP;

·плановый срок разработки системы - 6 месяцев.

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

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

·выделение множества бизнес-процессов;

·подсчет количества функциональных точек бизнес-процесса в разрезе каждой категории;

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

·учет факторов и требований среды разработки программной системы;

·вычислений интегральных показателей сложности;

·вычисление итогового количества функциональных точек;

·определение размеров программного комплекса в показателях LOC;

·определение размеров программной системы в целом.

Размеры программной системы определяются в виде количества строк исходного кода в терминах Lines of code-LOC [12].

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


Таблица 6..3 - Определение количества функциональных точек бизнес-процесса "Администраторская часть сайта"

Таблица 6.4 - Определение количества функциональных точек бизнес-процесса "Пользовательская часть сайта"

Категории функцийПростыеСредниеСложныеКоличество точекКол-во выводов007*35245Кол-во вводов007*43301Кол-во опросов вывода4*30012Кол-во опросов ввода03*17051Кол-во файлов0010*60600Кол-во интерфейсов7*20017Общее количество функциональных точек1226

Общее количество функциональных точек F = 2416

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

Влияние этих факторов на размеры программного обеспечения оценивается по ряду показателей, каждый из которых, в свою очередь, оценивается по пятибалльной шкале измерения (степень влияния фактора), которая приведена в таблице 2.12 [12]. Шкала измерения показателей для нашего проекта приведена в таблице 7.5.


Таблица 6.5 - Факторы среды разработки

Факторы средыВариантыКаналы передачи данных4Распределенные вычисления0Производительность системы3Конфигурирование 0Частота транзакций4Интерактивная обработка3Пользовательский интерфейс5Интерактивное обновление базы данных4Сложность обработки запросов4Сложность инсталляции (установки) программной системы1Сложность эксплуатации системы0Степень распределенности системы0Гибкость изменения функций3Суммарное значение коэффициентов (N)33

Уровень влияния факторов внешней среды определим по формуле:


,


где N - суммарное значение весовых коэффициентов факторов среды.

Уточненное количество функциональных точек с учетом факторов внешней среды определяется по формуле:


.


В качестве базового показателя количества строк исходного кода используется число операторов языка ассемблер. В нашем случае используется язык PHP, по характеристикам близкий к языку Web Scripts. Преобразовав размеры программной системы, написанной на языке PHP (Web Scripts), получаем соответствие 21,3 строк кода ассемблер и 1 строки кода PHP (Web Scripts), при этом показатель LOC на 1 функциональную точку равен 15 (табл. 2.12 [12]).

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


строк,


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

Оценка трудозатрат проводится с помощью степенной функции вида:


,


где T - трудозатраты, выраженные в человеко-месяцах;

R (KLOC) - размерность программной системы, выраженная в тысячах строк кода.

Значения параметров A и E получим из таблицы коэффициентов математической модели оценки трудозатрат на основе базовой модели COCOMO в зависимости от типа программной системы (табл. 2.13 [12]) A = 3, E = 1.12.


человеко-месяцев.


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


чел.


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

·трудозатраты на разработку системы составят 13.63 человеко-месяцев;

·необходимые людские ресурсы = 2.27 чел.

Выводы: При расчете технико-экономических показателей по трем методам трудозатраты и численность исполнителей приведены в табл. 7.6.


Таблица 6.6 - Выводы. Оценка методов определения трудозатрат

МетодТрудозатраты, чел.-месяц.Длительность, месяцевИсполнителей, чел.Прямой метод (экспертных оценок)56.1569.3На основе размерности базы данных программной системы1.1360.2Метод функциональных точек 13.6362.27

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

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

·система интегрирует сразу несколько технологий, состоит из большого количества файлов.

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


.5 Определение договорной цены на создание программной системы


Определение фонда оплаты труда на разработку и комплексные испытания программной системы

В основу определения фонда оплаты труда положены:

·длительность реализации каждого этапа жизненного цикла проекта;

·количество и качественный состав специалистов, привлекаемых на каждом этапе проекта;

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

Используем исходные данные, полученные с помощью метода функциональных точек:

·трудоемкость (Т) = 13.63 чел.-месяцев;

·длительность (Д) = 6 месяцев.

Заполняем таблицу средней численности сотрудников, занятых на каждом из этапов создания ПС, используя данные таблицы 2.16 [12], и получаем расчетную таблицу 6.7.


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

Этапы жизненного циклаЧисленностьДлительностьАнализ предметной области и разработка требований2.270.6Проектирование1.671.8Программирование2.632.1Тестирование и комплексные испытания2.51.5

Выполняем расчет средней численности сотрудников, занятых на каждом из этапов создания ПС:


где i=1,4.


Следующий шаг - распределение специалистов по этапам жизненного цикла системы, при этом численность каждого типа специалистов на каждом из этапов жизненного цикла создания ПС определяется с использованием статистического распределения таблицы 2.17 [12]:


, i=1,4 j=1,3 ,


где - относительная доля (%) специалистов J-го типа, привлекаемых для реализации проекта на i-ом этапе. Данные заносим в таблицу 6.8:

Таблица 6.8 - Численность каждого типа специалистов на каждом из этапов жизненного цикла создания программной системы

Этапы жизненного циклаТипы специалистов, чел. (Zij)АналитикиПрограммистыТехнические специалистыАнализ предметной области и разработка требований0.910.450.91Проектирование0.580.580.49Программирование0.121.710.65Тестирование и комплексные испытания0.371.50.62

Фонд заработной платы для реализации i-го этапа проекта определим по формуле:


, i = 1,4,


где - длительность i-го этапа проекта; - месячный фонд заработной платы j-го типа специалиста.

Примем размер ставки программиста 8 750 рублей, как среднемесячную зарплату программиста на кафедре АОИ.

Соотношение месячной ставки специалиста-программиста к месячной ставке системного аналитика составляет как 1:1,3, а к месячной ставке технического специалиста - как 1:0,7, то есть:

·базовая ставка программиста = 8 750 руб.;

·ставка системного аналитика = 11 375 руб.;

·ставка технического специалиста = 6 125 руб.

Рассчитаем фонд зарплаты для каждого этапа - и далее общий фонд зарплаты (таблица 6.9).


Таблица 6.9 - Распределение фонда заработной платы по этапам жизненного цикла программной системы, руб.

Этапы жизненного циклаАналитикПрограм-мистТехникФЗП по этапуАнализ предметной области и разработка требований62112363334511919Проектирование118769135540326414Программирование286731422836142650Тестирование и комплексные испытания639925594574337736Итого общий фонд заработной платы118719

Таким образом, фонд оплаты труда на разработку и комплексные испытания ПС составляет 118719 руб.

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

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


,


где ton - срок опытной эксплуатации.

Установим срок опытной эксплуатации, согласованный с Заказчиком - 3 месяца.

Норматив трудоемкости при проведении опытной эксплуатации N определяется из таблицы 2.18 [12] (категория сложности) - примем его равным 0,0095 человеко-месяцев, так как количество пользователей не ограничено и количество сеансов работы с системой в течение года от 650 до 6000. Таким образом, численность сотрудников, привлекаемых для опытной эксплуатации составит:


(чел.)

Фонд зарплаты сотрудников, привлекаемых для опытной эксплуатации определяется по формуле:


,


где Sn - месячная базовая ставка программиста.

В нашем случае вышеуказанный фонд составит:


руб.


Общий фонд зарплаты на разработку и внедрение системы = 118 719 руб. + 636 руб. = 119 355 руб.

Структура договорной цены на программное обеспечение

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

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

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

Так как система разработана в государственной бюджетной организации (ТУСУР), то налог на добавленную стоимость не предусмотрен.

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

С учетом нормативов, приведенных в таблице 2.19 [12] составим смету затрат и определим общую стоимость проекта (таблица 6.10).


Таблица 6.10 - Смета затрат на разработку и внедрение системы

Наименование статей расходовСумма (руб.)Фонд оплаты труда119 355Единый социальный налог (30%)35 807Коммунальные услуги, услуги связи 3180Прочие расходы 780Итого прямые расходы159 122Накладные расходы (13% от прямых затрат)15 912Фонд развития производства (10% от прямых затрат)20 686Итого договорная цена195 719

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


.6 Резюме


Представленная дипломная работа отражает эксклюзивное программное обеспечение (web-приложение), разработанное "под заказ" для ФГБУ "НИИ кардиологии" г. Томска, поэтому не предназначена для дальнейшего тиражирования. Таким образом, анализ рыночной стоимости системы не производился.

Приложение работает под управлением OC Linux. Информация хранится в базе данных, функционирующей под управлением СУБД MySQL. Язык программирования скриптов - PHP. Web-сервер - Apache. Сайт реализован на HTML.

При установленном заказчиком сроке выполнения проекта 6 месяцев (разработка и комплексные испытания системы) необходимо финансирование в объеме порядка 195.7 тыс. рублей.


Заключение


В результате проделанной работы были выполнены все поставленные задачи: был спроектирован и реализован сайт "Сибирского медицинского журнала" для ФГБУ "НИИ Кардиологии" СО РАМН г. Томска. Сайт доступен для просмотра по адресу #"justify">Оценить прямое влияние сайта на увеличение индекса цитируемости научных сотрудников организации импакт-фактора будет возможно только по истечению значительного времени, поскольку работа сайта это шаг в сторону увеличения доступности результатов научной деятельности. Об эффективности работы сайта можно судить по его посещаемости и оценке пользователей.

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

На основании данной работы была написана статья, которая вошла в сборник статей всероссийской научно-технической конференции студентов, аспирантов и молодых ученых "Научная сессия ТУСУР -2014", посвященной 50-летию ТУСУРа.


Список использованных источников


1Кузнецов О.Л. Обращение к читателю // Международный электронный журнал ISSN 2076-1163 [Электронный ресурс]. - Режим доступа: #"justify">Приложение A

САЙТ СИБИРСКОГО МЕДИЦИНСКОГО ЖУРНАЛА

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Перечень сокращений и условных обозначений

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


ОбозначениеОписаниеПОПрограммное обеспечениеСУБДСистема управления базами данныхТЗТехническое заданиеЖурнал"Сибирский медицинский журнал"СайтСайт "Сибирского медицинского журнала"

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

1.1.Полное наименование системы

Полное наименование Системы: Web-сайт "Сибирского медицинского журнала".

Условное обозначение: сайт.

1.2.Сведения о заказчиках и исполнителях

1.2.1.Заказчик

Заказчик: ФГБУ "НИИ кардиологии" СО РАМН

Адрес: РФ, 634012, г. Томск, ул. Киевская, 111-а

1.2.2.Исполнитель

Исполнитель: ТУСУР, каф. АОИ

Адрес исполнителя: РФ, 634034 г. Томск ул. Вершинина, 74

1.3.Основания разработки

1.3.1.Нормативные документы

Настоящее ТЗ разработано в соответствии с требованиями ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы".

При создании проектно-эксплуатационной документации Исполнитель должен руководствоваться требованиями следующих нормативных документов Госстандарта:

1)ГОСТ 34. Информационная технология. Комплекс стандартов на автоматизированные системы;

2)РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов;

)ГОСТ 19. Единая система программной документации.

1.4.Сроки исполнения работ

Начало разработки - 16.01.2014 г.

Окончание разработки - 31.05.2014 г.

1.5.Порядок оформления и предъявления заказчику результатов работ

Работы по созданию Системы производятся и принимаются поэтапно.

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

·ТЗ на разработку сайта;

·разработка дизайна;

·перевод дизайна в HTML-формат;

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

·подключение модулей, программирование шаблонов и скриптов;

·размещение сайта на хостинговом сервере Исполнителя;

·тестирование сайта на реальных данных;

·опытная эксплуатация сайта;

·сдача сайта Заказчику;

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

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

Для модифицируемых и разрабатываемых компонент Web-сайт на различных стадиях создания должны быть выпущены документы в соответствии с ГОСТ 34.201-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем" и ГОСТ 19.101-77 "Единая система программной документации. Виды программ и программных документов".

Исходные коды разработанного программного обеспечения предоставляются в соответствии с ГОСТ 19.101-77.

2 Назначение и цель развития системы

2.1.Назначение системы

Потребность в сайте возникла в результате изменений в законодательстве: в конце августа 2010 г. был издан Приказ Министерства здравоохранения и социального развития РФ № 738н "Об оценке результативности деятельности научных организаций, подведомственных Минздравсоцразвития России, выполняющих научно-исследовательские, опытно-конструкторские и технологические работы гражданского назначения". Согласно приказу планируется оценка научного потенциала. Один из основных критериев оценки - участие в организации индексирования библиометрических показателей Scopus. Результаты оценки влияют на финансирование научного учреждения. Чтобы повысить этот показатель для ФГБУ "НИИ кардиологии" СО РАМН было принято решение создать сайт "Сибирского медицинского журнала".

2.2.Цели создания системы

2.2.1.Общие цели проекта

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

2.2.2.Цели разработки системы

·Применение системы обеспечит достижение следующих целей:

·улучшение контроля над научной деятельностью сотрудников;

·повышение доступности материалов опубликованных в журнале;

·включение журнала в БД SCOPUS;

·расширение читательской аудитории;

·увеличение индексов цитируемости сотрудников ФГБУ "НИИ кардиологии" СО РАМН (суммарный объем цитирования, индекс Хирша);

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

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

·повышение рейтинга ФГБУ "НИИ кардиологии" СО РАМН.

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

3.1.Краткие сведения об объекте автоматизации

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

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

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

·опубликование статей;

·рецензирование статей;

·учет публикационной активности авторов;

·ведение архива журнала.

4 Требования к системе

.1 Требования к системе в целом

4.1.1Требования к структуре и функционированию системы

На логическом уровне сайт имеет две части:

·пользовательскую (Front-End);

·администраторскую (Back-End),

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

Сайт подлежит реализации в двухзвенной архитектуре клиент-сервер.

Серверная часть системы представляет собой приложение, использующее Internet в качестве транспортной среды. Для обеспечения нормального функционирования системы необходим персональный компьютер с предустановленной и сконфигурированной ОС семейства Unix, СУБД PostgreSQL, Web-сервером Apache 2.0.х и программным интерфейсом CGI.

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

4.1.1.1Требования к способам и средствам связи для информационного обмена между компонентами системы

Для доступа к сайту достаточным является dial-up соединение. Рекомендуется использовать широкополосное подключение.

Взаимодействие клиентской и серверной части осуществляется посредством SQL-запросов.

4.1.1.2Требования к режимам функционирования системы

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

·нормальный режим функционирования;

·аварийный режим функционирования.

Основным режимом функционирования сайта является нормальный режим.

В нормальном режиме функционирования:

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

·исправно функционирует серверная часть системы.

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

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

В случае перехода СУБД в режим отказа обработки запросов необходимо:

·разместить на сайте информационное сообщение о технических работах;

·принять меры по восстановлению работоспособности СУБД.

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

4.1.2Требования к численности и квалификации персонала системы

Для эксплуатации системы определены следующие роли:

·Системный администратор;

·Администратор баз данных;

·Пользователь.

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

·Модернизация, настройка и мониторинг работоспособности web-сервера;

·Ведение учетных записей пользователей системы.

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

Основными обязанностями администратора баз данных являются:

·Установка, модернизация, настройка параметров программного обеспечения СУБД;

·Оптимизация БД по времени отклика, скорости доступа к данным;

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

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

Определены следующие типы пользователей сайтом:

·начинающий;

·опытный;

·администратор сайта.

4.1.3Показатели назначения

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

По методу GOMS можно примерно оценить время, затрачиваемое пользователями на выполнение некоторых задач:


Типы пользователейЗадачаНачинающийОпытныйАдминистратор сайтаАвторизоваться2 мин40 сек7 секПерейти в раздел новостей10 сек5 сек2 секОсуществить быстрый поиск по сайту1 мин20 сек7 секДобавить новую статью--30 сек

4.1.4Требования к надежности

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

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

·при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС;

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

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

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

4.1.5Требования к безопасности

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

Все внешние элементы технических средств системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.

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

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

4.1.6Требования к эргономике и технической эстетике

·Дизайн должен быть разработан с разрешением 1024x768;

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

·сайт должен корректно отображаться в браузерах Microsoft Internet Explorer (не ниже версии 6.0), Mozilla Firefox (не ниже версии 3.0), Opera (не ниже версии 9.0).

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

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

4.1.7Требования по сохранности информации при авариях

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

4.1.8Требования по стандартизации и унификации

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

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

Структура сайта:

·О журнале

з)Из истории *

и)Положение о журнале *

к)Редакционная коллегия *

л)Редакционный совет *

м)Учредители *

н)Партнеры *

о)Подписка *

·Редакция

п)Редакционно-издательская группа *

р)Контакты *

·Авторам

с)Условия публикации *

т)Правила оформления статей *

у)Образцы документов *

ф)Реквизиты для оплаты публикаций *

х)Авторские права *

ц)Наши авторы

ч)Услуги

ш)Полезные ссылки

·Рецензентам

щ)Положение об институте рецензентов *

ы)Образец рецензии *

э)Предложение к сотрудничеству *

ю)Анкета рецензента

·Новости

·Архив

·Вопрос-ответ

·Скачать свежий номер

·Поиск

·Обращение главного редактора

* - статические страницы

Модули:

·Модуль "Линейка фотографий"

·Модуль "Регистрация"

·Модуль "Новостная рассылка"

·Модуль "Личный кабинет"

·Модуль "Облако тегов"

4.2.1Требования к главной странице сайта

Главная страниц сайта должна содержать следующие элементы (см. рис. 1):

·навигационное меню по разделам сайта;

·блок "Авторизация";

·ссылка "Зарегистрироваться";

·ссылка "Забыли пароль?"

·блок "Обращение главного редактора"

·блок "Поиск"

·графический элемент (кнопка) "Скачать свежий номер";

·модуль "Облако тегов";

·модуль "Линейка фотографий на главной странице".

·блок "Карта сайта"

Ссылка "Зарегистрироваться"

При нажатии на ссылку посетитель сайта переходит на страницу с формой регистрации.

Ссылка "Забыли пароль?"

При нажатии на ссылку посетитель сайта переходит к форме восстановления пароля с помощью e-mail.

Блок "Обращение главного редактора"

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

Блок "Поиск"

Осуществляет поиск по сайту на основе введенных в специальное поле ключевых слов.

Графический элемент (кнопка) "Скачать свежий номер"

Посетитель сайта может сохранить последний выпуск журнала в формате *.pdf, нажав на кнопку "Скачать свежий номер".

Модуль "Рубрики"

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

Модуль "Линейка фотографий на главной странице"

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

Блок "Карта сайта"

Данный блок расположен в нижней части главной страницы и содержит ссылки на второстепенные разделы сайта.


Рисунок 4.1 - Схема главной страницы сайта.


4.2.2Требования к модулю "Регистрация"

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

·редактирование своего профиля;

·формирование заявки на опубликование в журнале;

·отслеживание статусов текущих заявок;

·ведение истории своих публикаций;

·получение рассылки;

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

Атрибутный состав

Форма регистрации пользователей на сайте имеет следующий атрибутный состав:

·E-mail *;

·Пароль *;

·Повторить пароль *;

·Имя *;

·Отчество;

·Фамилия *;

·Организация;

·Должность

·Город*;

·Телефон;

·Код защиты *.

* - поля, обязательные для заполнения

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

·E-mail *;

·Пароль *;

·Имя *;

·Отчество;

·Фамилия *;

·Организация;

·Город*;

·Адрес *;

·Телефон;

·Признак "Подписан на рассылку";

·Список заявок;

·Список публикаций;

·Признак "Автор";

* - поля, обязательные для заполнения

4.2.3Требования к блоку "Обращение главного редактора"

Описание

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

Функции

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

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

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

·Модифицировать значение всех атрибутов статьи;

·Осуществлять форматирование и оформление полного текста статьи, добавлять изображения с использованием "RTF-редактора".

Атрибутный состав

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

·заголовок *;

·изображение *;

·краткое описание (Plain-text) *;

·полное описание (RTF-редактор) *.

·*- поля, обязательные для заполнения.

4.2.4Требования к разделу "Архив"

Описание

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

Функции

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

·Просматривать список статей;

·Осуществлять поиск по ключевым словам;

·Просматривать список статей, в привязке к выбранному из "Облака тегов" ключевому слову;

·Перемещаться по списку статей, используя постраничное листание;

·Просматривать список статей, используя фильтры "Темы", "Автор", "Искать в номерах за период", "Искать в одном номере";

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

·Просматривать полные тексты статей, в формате *.pdf;

·Оставить комментарий к статье

·Оценить статью

·Сохранить статью в формате *.pdf

·Осуществлять выбор статей.

·Функциональность разрабатываемого раздела позволяет администратору:

·Формировать справочник "Ключевые слова"

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

·Формировать справочник "Темы"

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

·Формировать справочник "Авторы"

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

·Добавлять, удалять статьи

·Модифицировать значение атрибутов статей

·Просматривать статьи

а)Сортировать статьи по полю "Оценка"

б)Устанавливать фильтры по следующим полям "Темы", "Автор"

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

·Удалять комментарии к статьям

Атрибутный состав

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

·Дата публикации (в формате dd.mm.yyyy);

·Номер журнала*;

·Номер выпуска;

·Заголовок *;

·Аннотация *;

·Изображение;

·Тема (справочник) *;

·Список ключевых слов *;

·Статья (файл в формате .pdf) *;

·Список авторов *;

·Рецензия (файл в формате .doc);

·Оценка;

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

Если посетитель сайта, используя форму, оставил свой комментарий, то на e-mail соответствующих авторов высылаются уведомления.


Рисунок 4.2 - Схема архива журнала


4.2.5Требования к модулю "Личный кабинет"

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

Функции

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

·Модифицировать личные данные в области "Мой профиль";

·Подать заявку на опубликование статьи в журнале;

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

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

·Просматривать поступившие заявки

·Модифицировать значения атрибутов заявок;

·Удалять заявки;

·Просматривать заявки в привязке к статусу, используя фильтр условно называемый "Статус";

·Сортировать заявки (по возрастанию и убыванию) по дате размещения.

Атрибутный состав

Форма "Подать заявку" состоит из следующих функциональных элементов:

·Поле для ввода текста "Заголовок статьи"

·Ссылка "Прикрепить статью"

·Ссылка "Прикрепить сопроводительное письмо"

·Ссылка "Прикрепить резюме"

·Таблица "Информация об авторах"

·Кнопка "Отправить заявку"

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

·Дата размещения (dd.mm.yyyy);

·Заголовок статьи;

·Аннотация;

·Список ключевых слов;

·Список авторов;

·Статья (файл в формате *.doc);

·Сопроводительное письмо (файл в формате *.doc);

·Резюме (файл в формате *.doc);

·Статус.

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

·поступила в портфель журнала;

·присвоен регистрационный номер (указывается соответствующий номер);

·на редакционном рецензировании;

·возвращена на доработку;

·на независимом рецензировании;

·принята к печати;

·назначена к опубликованию (указывается номер журнала);

·отказано в опубликовании.

Каждый автор из списка характеризуется:

·ФИО;

·Ученая степень/Ученое звание;

·Должность;

·Место работы;

·Служебный адрес;

·E-mail;

·Служебный телефон.

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


Рисунок 4.3 - Схема формы "Подать заявку"


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


Рисунок 4.4 - Схема страницы "Личный кабинет"


4.2.6Требования к модулю "Линейка фотографий на главной странице"

Описание

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

Функции

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

·Переходить по слайдам используя элементы навигации;

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

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

·Добавлять, модифицировать, удалять слайды;

·Сопоставлять слайду страницу сайта;

·Осуществлять сортировку слайдов.

Атрибутный состав

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

·Название;

·Изображение;

·Описание;

·Ссылка (в виде URL).

4.2.7Требования к разделу "Анкета рецензента"

Описание

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

Функции

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

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

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

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

·Просматривать поступившие заявки;

·Модифицировать значения атрибутов заявок;

·Удалять заявки;

·Просматривать заявки в привязке к статусу, используя фильтр условно называемый "Статус";

·Сортировать заявки (по возрастанию и убыванию) по дате размещения.

Атрибутный состав заявки:

·Дата (dd.mm.yyyy);

·E-mail;

·Фамилия;

·Имя;

·Отчество;

·Место работы;

·Должность;

·Статус.

Поле статус может принимать одно из следующих значений:

·Принята;

·Рассмотрена;

4.3Требования к видам обеспечения

4.3.1Требования к информационному обеспечению системы

4.3.1.1Требования к составу, структуре и способам организации данных в системе

В системе должны быть обеспечено хранение следующей информации:

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

·информация о редакционной коллегии и редакционном совете;

·информационно-справочные материалы об организации работы журнала;

·информация об изданных номерах;

Должны быть реализованы удобные механизмы экспорта и при необходимости импорта данных в систему.

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

·достоверность;

·непротиворечивость;

·полнота;

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

4.3.1.2Требования к информационному обмену между компонентами системы

Система должна обеспечивать предоставление и получение информации в форматах XML, HTML, DOC, JPEG,RTF, PDF или иной формат для хранения и передачи информации, а также средства взаимодействия внутренних программных интерфейсов (API) и обмен данными через общую базу данных.

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

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

Общие требования к используемой СУБД:

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

·поддержка реляционной или объектно-реляционной модели базы данных;

·поддержка технологии клиент-сервер;

·автоматическое восстановление базы данных;

·наличие механизма блокировки транзакций;

·реализация SQL, совместимого со стандартом ANSI 1992 г.;

·поддержка стандарта Open DataBase Connectivity (ODBC);

·наличие встроенных средств контроля целостности баз данных;

·наличие встроенных средств резервного копирования базы данных;

·импорт и экспорт данных;

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

·поддержка сетевых протоколов TCP/IP;

·возможность контроля доступа к данным;

·оптимизация запросов;

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

4.3.2Требования к лингвистическому обеспечению системы

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

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

Языки манипулирования данными должны отвечать требованиям стандарта ANSI 1992 (реализация SQL).

4.3.3Требования к программному обеспечению системы

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

В состав программных средств должны входить:

·База данных (свободно распространяемая);

·Microsoft Windows XP/Vista/7.

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

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

·сервер: Intel Pentium IV 3.0 GHz/2048 Mb, HDD 120Gb, сеть 1000/100 Mbps;

·клиент: Intel Celeron 1,3 GHz, 256 Mb, HDD - 80 Gb, доступ в Интернет и Интернет-браузер

5 Стадии и этапы работ по созданию системы

Выполнение работ по созданию типовой АИС "Формирование технических отчетов при диагностировании производственных объектов" разделяется на пять стадий работ:

·разработка технического решения;

·разработка программного решения;

·наполнение контентом;

·тестирование;

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

·комплексная проверка решения.

Наименование, содержание и срок выполнения работ представлены в таблице 5.1.

Таблица 5.1 - Наименование, содержание, срок выполнения работ


Работы и ожидаемый результат представлены в таблице 5.2.


Таблица 5.2 - Работы и ожидаемый результат


Министерство образования и науки РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования "Томский госу

Больше работ по теме:

Автоматизация вещевого учета на военном складе
Диплом
Автоматизация кадрового учёта персонала на примере компании ООО "Альбион Плюс"
Диплом
Автоматизация комплекса задач менеджера отдела продаж торговой организации
Диплом
Автоматизация пакета методик "Изучение мотивации в профессиональной деятельности"
Диплом
Автоматизация процесса обработки информации для сотрудников приёмной комиссии техникума
Диплом

Предмет: Информационное обеспечение, программирование

Тип работы: Диплом

найти  

ПОИСК

Новости образования

Российский государственный социальный университет реорганизует сеть своих филиалов
22 Июля 2016 16:26
Более 70 представителей крупных вузов АСЕАН подтвердили участие в форуме во Владивостоке
22 Июля 2016 12:51
Абызов: публикация первичных статсведений снизит бюрократическую нагрузку на школы
22 Июля 2016 11:53
В Чечне свыше 200 школьников сдали ЕГЭ с результатом свыше 90 баллов - министр
22 Июля 2016 05:36
Замглавы Минобрнауки РФ: задача сократить число людей с высшим образованием не стоит
21 Июля 2016 20:19

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ