Requirements
|
Полезность
|
Статус
|
Сложность
|
Стабильность
|
FEAT1: Авторизация Система
должна разграничивать пользователей по правам.
|
Важная
|
Включена в проект
|
Низкая
|
Высокая
|
FEAT2: Регистрация Система
должна иметь возможность регистрировать пользователей
|
Важная
|
Включена в проект
|
Средняя
|
Высокая
|
FEAT3: Изменить аккаунт
Система должна предоставлять возможность зарегистрированному пользователю
изменять аккаунт.
|
Важная
|
Включена в проект
|
Средняя
|
Высокая
|
FEAT4: Сохранение
измененных данных Система должна позволять сохранять измененные данные
пользователя.
|
Важная
|
Включена в проект
|
Средняя
|
Высокая
|
Requirements
|
Полезность
|
Статус
|
Сложность
|
Стабильность
|
FEAT5: Добавить участника
Система должна иметь возможность добавлять новых участников.
|
Критическая
|
Включена в проект
|
Высокая
|
Высокая
|
FEAT6: Удалить участника
Система должна иметь возможность удалять участников (зарегистрированных
пользователей, авторов)
|
Важная
|
Включена в проект
|
Низкая
|
Высокая
|
FEAT7: Добавить статью
Система должна иметь возможность добавлять новую статью.
|
Критическая
|
Включена в проект
|
Высокая
|
Высокая
|
FEAT8: Удалить статью
Система должна иметь возможность удалить статью.
|
Важная
|
Включена в проект
|
Средняя
|
Высокая
|
FEAT9: Поиск Система должна
осуществлять поиск по архиву журнала
|
Критическая
|
Включена в проект
|
Высокая
|
Средняя
|
Полезная
|
Включена в проект
|
Средняя
|
Средняя
|
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;
В комплект поставки входит техническая документация в составе:
· "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-приложение, которое содержит более сложную логику взаимодействия
с клиентом;
· система интегрирует сразу несколько технологий, состоит из
большого количества файлов.
После расчета технико-экономических показателей проекта выбираем исходные
данные (трудозатраты/длительность/средняя численность) для определения
стоимости (договорной цены) на создание программной системы.
.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 руб.
Определение
фонда оплаты труда на проведение опытной эксплуатации программной системы
Численность сотрудников, привлекаемых к опытной эксплуатации,
определяется по формуле:
,
где 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 тыс. рублей.
Заключение
В результате проделанной работы были выполнены все поставленные задачи:
был спроектирован и реализован сайт "Сибирского медицинского журнала"
для ФГБУ "НИИ Кардиологии" СО РАМН г. Томска. Сайт доступен для
просмотра по адресу #"791912.files/image054.gif">
Рисунок 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 - Работы и ожидаемый результат