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

Форму оформления заявки визуально можно разделить на 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-сайт "Сибирского медицинского журнала". Техническое задание;

· "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 - Определение количества функциональных точек бизнес-процесса "Пользовательская часть сайта"

Категории функций	Простые	Средние	Сложные	Количество точек
Кол-во выводов	0	0	7*35	245
Кол-во вводов	0	0	7*43	301
Кол-во опросов вывода	4*3	0	0	12
Кол-во опросов ввода	0	3*17	0	51
Кол-во файлов	0	0	10*60	600
Кол-во интерфейсов	7*2	0	0	17
Общее количество функциональных точек	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.15	6	9.3
На основе размерности базы данных программной системы	1.13	6	0.2
Метод функциональных точек	13.63	6	2.27

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этапы жизненного цикла	Численность	Длительность
Анализ предметной области и разработка требований	2.27	0.6
Проектирование	1.67	1.8
Программирование	2.63	2.1
Тестирование и комплексные испытания	2.5	1.5

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

где i=1,4.

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

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

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

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

Этапы жизненного цикла	Типы специалистов, чел. (Zij)
	Аналитики	Программисты	Технические специалисты
Анализ предметной области и разработка требований	0.91	0.45	0.91
Проектирование	0.58	0.58	0.49
Программирование	0.12	1.71	0.65
Тестирование и комплексные испытания	0.37	1.5	0.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 -- Распределение фонда заработной платы по этапам жизненного цикла программной системы, руб.

Этапы жизненного цикла	Аналитик	Програм-мист	Техник	ФЗП по этапу
Анализ предметной области и разработка требований	6211	2363	3345	11919
Проектирование	11876	9135	5403	26414
Программирование	2867	31422	8361	42650
Тестирование и комплексные испытания	6399	25594	5743	37736
Итого общий фонд заработной платы	118719

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

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

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

,

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

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

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

(чел.)

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

,

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

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

руб.

Общий фонд зарплаты на разработку и внедрение системы = 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.6 Резюме

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

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

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

Заключение

В результате проделанной работы были выполнены все поставленные задачи: был спроектирован и реализован сайт "Сибирского медицинского журнала" для ФГБУ "НИИ Кардиологии" СО РАМН г. Томска. Сайт доступен для просмотра по адресу http://niikg.s1.hitrate.ru.

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

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

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

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

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

2 Официальный сайт ФГБУ "НИИ кардиологии" СО РАМН [Электронный ресурс].- Режим доступа: http://www.cardio-tomsk.ru/

3 Маркусова В.А. Информационные ресурсы для мониторинга российской науки //Вест. РАН. 2005. С:607-612 .

4 Маркусова В.А., Иванов В.В., Варшавский А.Е. Библиометрические показатели российской науки и РАН (1997-2007)//Вестник Российской академии наук, 2009, №7. 483-491 с.

5 Зандстра М. PHP: объекты, шаблоны и методики программирования, 3-е издание, PHP Objects, Patterns and Practice, Third Edition. М.: "Вильямс", 2010. С. 560

6 Поддержка MySQL в России [Электронный ресурс].- режим доступа: http://postgresmen.ru/

7 Что такое Apache [Электронный ресурс].- режим доступа: http://yapro.ru/web-master/apache/chto_takoe_apache.html/

8 Крачтен Ф. Введение в Rational Unified Process. 2-е издание..// М.: Издательский дом "Вильямс", 2002. - 240 с.

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

10 Ларман К. Применение UML и шаблонов проектирования. 2-е издание. : Пер. с англ. - М. : Издательский дом "Вильямс", 2004. - 624 с. : ил. - Парал. тит. англ.

11 Соловьев Д.А. Курс лекций по дисциплине "Проектирование ПАСОИУ" для студентов специальности 220200/ Д.А. Соловьев - Томск: ТУСУР,2003.-25 с.

12 Ехлаков Ю.П., Рыбалов Б.А. Технико-экономическое обоснование стоимости программных систем: методические указания по выполнению экономической части дипломного проекта для студентов специальности 230102 "Автоматизированные системы обработки информации и управления" -- Томск: 2011. - 86 с. - http://edu.tusur.ru/humans/963

Приложение A

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

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

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

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

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

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. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов;

3) ГОСТ 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 Требования к системе

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 Требования к составу, структуре и способам организации данных в системе

В системе должны быть обеспечено хранение следующей информации:

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

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

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

· информация об изданных номерах;

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

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

· достоверность;

· непротиворечивость;

· полнота;

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