Введение. 2
Глава 1. Исследование предметной области. 5
1.1 Центр проектирования контента белгородского филиала МЭСИ.. 5
1.2 Электронные образовательные ресурсы и их виды.. 7
1.3 Постановка задачи и определение основных требований к разрабатываемой системе 10
1.4 Анализ существующих разработок. 12
Глава 2. Проектирование системы учета работ по созданию электронных образовательных ресурсов. 15
2.1 Выбор методологии. 15
2.2 Выбор инструментального средства проектирования. 23
2.3 Проектирование системной архитектуры.. 24
2.4 Структура базы данных. 35
Глава 3. Разработка автоматизированной системы учета работ по созданию электронных образовательных ресурсов. 40
3.1 Выбор средств реализации системы.. 40
3.2 Разработка пользовательского интерфейса. 44
3.3 Контрольный пример. 50
Глава 4. Оценка экономической эффективности проекта. 56
4.1 Технико-экономическое обоснование разработки ПО.. 56
4.2 Расчет единовременных затрат на разработку ПО.. 57
4.3 Стоимость внедрения ПО Заказчиком. 62
4.4 Расходы заказчика при эксплуатации ПО.. 65
4.5 Эффективность внедрения для Заказчика ПО.. 65
Заключение. 68
Список литературы.. 70
Введение
Еще совсем недавно ведущие российские ученые спорили о том, можно ли говорить о переходе России к информационному обществу. На сегодняшний день такие споры практически прекратились: большинство исследователей сошлись во мнении, что в сегодняшней России присутствуют основные тенденции, явно свидетельствующие о ее движении к обществу информационному.
В первую очередь это означает, что информация становится ведущим ресурсом экономического, социального, политического и культурного развития, а современные технологии ее обработки и распространения только усиливают данную тенденцию. Также это означает увеличение темпа жизни, что в свою очередь требует повышения уровня мобильности, образованности, адаптивности людей к постоянно изменяющимся условиям.
Переход к информационному обществу приводит к тому, что успех достигается, в основном, за счет личного конкурентного преимущества, которое можно определить, как способность индивида наиболее эффективно функционировать в постоянно меняющемся мире.
Чем же на сегодняшний день определяется этот уровень эффективности? Что является главным критерием успешности? Ответ достаточно очевиден: если информация становится ведущим общественным ресурсом, наиболее конкурентоспособным является индивид, способный в максимально короткий промежуток времени находить, получать и усваивать необходимую ему информацию, а также использовать полученные знания наиболее удачным в конкретной ситуации образом.
Неуклонно возрастающий интерес к получению базового образования, переобучения или повышения квалификации имеет объективную основу. Технический прогресс и растущий динамизм жизни приводят, с одной стороны, к росту потребностей людей в эффективном образовании, с другой — к новым методам его получения.
Сто лет назад образование получали избранные. У одного ученика было несколько учителей, передающих знания, в прямом смысле «из рук в руки». Технический прогресс привел к необходимости увеличения доступности образования, а, следовательно, и к росту количества студентов на одного педагога. Происходила трансформация форм и методов передачи знаний. Появилось заочное обучение. Сегодня идея «образования через всю жизнь» приводит к необходимости поиска новых методов передачи знаний и технологий обучения. В этом контексте дистанционное обучение необходимо рассматривать не как альтернативу очной форме получения образования, но как ее дополнение, позволяющее оптимизировать учебный процесс за счет предоставления разным категориям граждан различных образовательных услуг, наиболее полно удовлетворяющих их потребности.
Опыт показывает, что студент, обучающийся дистанционно становится более самостоятельным, мобильным, ответственным. Без этих качеств он не сможет учиться. Если их не было изначально, но мотивация к обучению велика, они развиваются и по окончанию обучения выходят специалисты, действительно востребованные на рынке.
Московский государственный университет экономики, статистики и информатики является одним из лидеров на рынке образовательных услуг в сфере дистанционного образования. Направление на развитие ДО, заданное головным вузом, реализуется и на уровне филиалов. Белгородский филиал МЭСИ первым в Белгородской области применил дистанционные технологии для получения высшего образования. Такая удобная, прогрессивная форма обучения пользуется спросом и уже привлекла сотни студентов.
В рамках снабжения студентов новыми учебными материалами, белгородскому филиалу МЭСИ пришлось столкнуться с такими задачами как подготовка качественного и достаточно информативного контента, что, в свою очередь, привело к появлению такого подразделения как отдел РЦПК, который принял на себя всю ответственность по решению данной задачи.
Проектирование информационной системы это логически сложная, трудоемкая и длительная работа, требующая определенных знаний. В данной дипломной работе проектируется автоматизированная информационная система учета работ по созданию электронных образовательных ресурсов.
Так как предполагается, что с данной системой будет работать ограниченное число людей в рамках одного отдела, то разумнее было бы построить ее по принципу «файл-сервер». Преимуществами данного принципа является относительная простота создания и обслуживания СУБД.
Автоматизированная система учета работ по созданию электронных образовательных ресурсов проектируется с целью повышения эффективности и качества работы сотрудников ЦПК, с целью увеличения скорости обработки информации, что позволит ускорить процесс выполнения монотонной, но важной работы по созданию ресурсов учебного назначения.
Применение автоматизированной системы позволит максимально упростить и оптимизировать труд работников отдела при назначении и выполнении задач и при формировании отчетов. Качество выполняемой работы возрастет при сокращении сроков выполнения.
Глава 1. Исследование предметной области
1.1 Центр проектирования контента белгородского филиала МЭСИ
В настоящее время в сфере образования России происходит формирование единой информационно-образовательной среды. В концепции создания и развития системы дистанционного образования в России под информационно-образовательной средой понимается "системно-организованная совокупность средств передачи данных, информационных ресурсов, протоколов взаимодействия, аппаратно-программного и организационно-методического обеспечения, ориентированная на удовлетворение образовательных потребностей пользователей".
В последнее время в основном используется менее технократичное определение, рассматривающее информационно-образовательную среду с точки зрения двух основных ее функций: информационной и образовательной, т.е. как образовательную среду, базирующуюся на широком использовании информационных технологий. Под информационной образовательной средой учебного заведения понимается сложная система, аккумулирующая интеллектуальные, культурные, программно-методические, организационные и технические ресурсы, обеспечивающие образовательный процесс в целом и процесс обучения в частности.
Московский государственный университет экономики, статистики и информатики (МЭСИ) является флагманом движения российских вузов к электронному обучению. В вузе практикуется смешанная форма обучения с постепенным увеличением доли электронного обучения. На каждом факультете МЭСИ выбираются учебные программы, преподаватели по которым готовы перейти в режим электронного взаимодействия со своими студентами. Практически каждая группа студентов вуза попадает хотя бы на один курс, в котором лекции и семинары проводятся в интерактивном режиме: студент самостоятельно изучает лекционный материал, выполняет лабораторные работы, сдает тесты, общается в дискуссионных форумах и чатах с сокурсниками и преподавателем. Переводом традиционных учебных курсов в электронную форму занимается специальное подразделение — Центр проектирования контента (ЦПК). Курс разбивается на темы, включающие в себя рекомендации по обучению, собственно учебное пособие, краткое содержание по теме, практикум, тест и общую презентацию.
Одной из главных целей создания центра проектирования контента является организация, научно-методическое обеспечение, и собственно разработка ресурсов учебного назначения.
В своей деятельности региональный центр проектирования контента руководствуется действующим законодательством, Уставом Московского государственного университета экономики, статистики и информатики, Положением о филиале МЭСИ и положением об отделе РЦПК.
В ЦПК разрабатываются электронные учебные курсы любой сложности, причем с использованием видеолекций, видеоконференций, презентаций, анимации, тренингов. Все это стыкуется в единый документ, представляющий собой последовательность учебных материалов. Курс делается при активной поддержке преподавателя, разрабатывавшего эти материалы.
Можно выделить основные функции Центра проектирования контента:
1. Участие в разработке инструкций, методических и нормативных стандартов, связанных с проектированием, разработкой и оформлением контента.
2. Участие в согласовании плана подготовки контента.
3. Контроль входящего контента на соответствие стандартам.
4. Участие во внедрении и запуске систем управления обучением.
5. Разработка электронных учебных курсов по плану ЦПК МЭСИ.
6. Разработка электронных изданий на заказ.
7. Участие в организации электронного обучения в БФ МЭСИ.
Иерархическую структуру сотрудников Центра проектирования контента можно отобразить в виде следующей схемы:
1.2 Электронные образовательные ресурсы и их виды
Одним из главных элементов информационно-образовательной среды являются образовательные ресурсы.
Под образовательными ресурсами понимается учебная, методическая, справочная, нормативная, организационная и другая информация, необходимая для эффективной организации прохождения учебного процесса с гарантированным уровнем качества.
Вводится также понятие электронного образовательного ресурса (ЭОР): Электронный образовательный ресурс - это любой электронный ресурс, содержащий информацию образовательного характера.
Электронные образовательные ресурсы являются основой для содержательного наполнения образовательного пространства.
Общепринятой классификации образовательных ресурсов не существует, что создает определенные проблемы при их каталогизации, но по функциональному признаку, определяющему значение и место образовательного ресурса в учебном процессе, их можно классифицировать как:
1. Программно-методические электронные ресурсы (учебные планы, рабочие программы учебных дисциплин в соответствии с учебными планами);
2. Учебно-методические электронные ресурсы (методические указания, методические пособия, методические рекомендации для изучения отдельного курса, руководства по выполнению проектных работ, тематические планы);
3. Обучающие электронные ресурсы (сетевые учебники и учебные пособия, мультимедийные учебники, электронные текстовые учебники, электронные учебные пособия);
4. Вспомогательные электронные ресурсы (сборники документов и материалов, справочники, указатели научной и учебной литературы, научные публикации педагогов, материалы конференций);
5. Контролирующие электронные ресурсы (тестирующие программы, банки контрольных вопросов и заданий по учебным дисциплинам, банки тем рефератов, проектных работ).
Данная классификация поможет произвести каталогизацию и обеспечит удобную навигацию по всей базе имеющегося контента.
Центр проектирования контента в своей деятельности специализируется в основном на разработке обучающих и контролирующих электронных ресурсов.
Примером обучающего электронного ресурса может служить электронный учебный курс, отвечающий требованиям спецификации IMS. Его оптимальный состав определен согласно требованиям замкнутости, системности и дидактической достаточности, и включает в себя следующие компоненты:
- Руководство по изучению дисциплины;
- Теоретическая часть (учебное пособие);
- Практикум;
- Глоссарий;
- Список рекомендуемой литературы;
- Система контроля.
Можно выделить следующие этапы разработки такого курса:
1. Создание элементов (страниц) электронного курса (инженер- (техник- ) программист);
2. Сборка элементов в единый ресурс (инженер- (техник- ) программист);
3. Проверка на наличие орфографических и иных видов ошибок (начальник);
4. Исправление несоответствий, ошибок (инженер- (техник- ) программист);
5. Публикация готового ресурса в среде обучения (начальник).
Примером контролирующего электронного ресурса может служить тест, разработанный в соответствии с требованиями системы электронного тестирования слушателей. Можно выделить следующие этапы его разработки:
1. Анализ и обработка материалов, предоставленных тьюторами;
2. Конвертация данных материалов в формат, поддерживаемый системой тестирования;
3. Подготовка теста к публикации, проверка;
4. Размещение в системе тестирования.
Актуальной является проблема отслеживания стадий разработки того или иного ресурса, а так же его готовности к участию в учебном процессе. Данная проблема является решаемой в рамках настоящего проекта.
Задачи по созданию электронных образовательных ресурсов назначаются начальником ЦПК, при этом необходимо указывать крайний срок выполнения работы. Сотрудник может выполнить задание раньше или позже назначенного срока, но в любом случае он должен указать период в виде даты начала и окончания работ.
В конце каждого месяца сотрудник обязан представить отчет по выполненным работам. Данный отчет является обязательным документом, функционирующим в пределах ЦПК. Пример такого отчета приведен в приложении 7.
Другим документом, функционирующим в рамках данного процесса, является отчет о состоянии электронных образовательных ресурсов. Данный отчет формируется в виде выборки из общего хранилища ресурсов по каким-либо критериям. Например, может возникнуть необходимость создать отчет, в котором указать все ресурсы, разработанные за конкретный период времени, либо ресурсы, разработанные авторами белгородского филиала МЭСИ. Данные отчеты являются статистическими показателями, отражающими достаточность и актуальность функционирующего в образовательном процессе контента. Пример такого отчета приведен в приложении 8.
Более подробно и детализировано процесс подготовки электронных образовательных ресурсов будет рассмотрен при проектировании физической модели системы.
1.3 Постановка задачи и определение основных требований к разрабатываемой системе
Основной задачей автоматизации деятельности Центра проектирования контента является создание системы, которая обеспечит достижение следующих целей:
1. Уменьшение времени поиска по базе готового контента в 2 раза;
2. Уменьшение времени на формирование отчетов на 15 минут;
3. Оперативный доступ к текущим задачам каждого из сотрудников отдела;
Для достижения этих целей необходимо решить следующие задачи:
- Ведение базы данных (отображения, редактирования и сохранения данных):
- всех видов контента,
- сотрудников отдела,
- работ, осуществляемых сотрудниками,
- отчетов.
- Организация поиска по базе данных, используя различные критерии.
Требования к разрабатываемой системе
:
Функциональные требования
Целью данной автоматизированной системы является повышение оперативности, производительности и уровня организации труда работников отдела ЦПК.
Система должна обеспечивать возможность выполнения следующих функций:
· ввод данных;
· редактирование данных;
· хранение данных;
· просмотр данных;
· поиск данных.
Требования к надежности
Система должна обеспечивать высокий уровень надежности при хранении и обработке информации. Это необходимое требование для любой операции на каждом из этапов функционировании автоматизированной системы управления, ведь важна не только сохранность информации, но и ее целостность, структура. И если ответственность за сохранность лежит большей частью на аппаратном комплексе и системе управления базами данных, то обеспечение целостности информации лежит целиком на автоматизированной системе. Необходимо исключить повреждение структуры данных в результате работы человеческого фактора или нарушении логики работы системы.
Требования к информационной и программной совместимости
Автоматизированная система должна обеспечивать информационную совместимость с известными приложениями операционной системы
Windows (MS Word, MS Excel, MS Access). Программная совместимость обеспечивается автоматически в связи с использованием программных средств, совместимость которых обеспечена конструктивно (на этапе их создания) – Delphi, MS Access и т.д. Система реализуется под операционной системой Windows XP-Vista и СУБД InterBase.
Требования к техническому и аппаратному обеспечению
Разрабатываемая система ориентирована на использование персональным компьютером класса IBM PC, начиная с Pentium III, включенного в локальную сеть.
Необходимое аппаратное обеспечение:
– компьютер типа Pentium III или старше,
– минимум 64 Мб оперативной памяти.
Необходимый объем свободного пространства на жестком диске составляет 2 Мб. При работе с приложением в ходе модификации баз данных объем требуемого дискового пространства возрастает в зависимости от объема хранимых данных.
1.4 Анализ существующих разработок
Программные продукты такого рода являются коммерческими разработками, не подлежащими распространению среди различных организаций, поэтому отыскать существующую систему, выполняющую необходимые функции, нелегко.
Среди подобных систем, имеющих распространение, можно выделить программный модуль «БЭРОН» («Банк электронных ресурсов образовательного назначения»).
БЭРОН - программный модуль, обеспечивающий хранение, систематизацию и последующее использование электронных ресурсов создаваемых педагогами; интеграцию и ассимиляции готовых электронных ресурсов.
Ресурс, заносимый в БЭРОН, может быть также позиционирован по виду и назначению.
БЭРОН реализуется в виде трех самостоятельных рабочих мест: пользователя, создателя, администратора. Пользовательское рабочее место обеспечивает возможности поиска требуемых ресурсов по классификатору, по атрибутам. Производит формирование выборок и сортировку данных внутри выборок.
Действующая модель банка электронных ресурсов образовательного назначения предполагает участие практически всех субъектов образовательного процесса и представляет собой сложную схему их взаимодействия.
Рассмотрим данный продукт с точки зрения решения поставленных задач:
1. База данных ведется, но в ней содержатся данные только об электронных образовательных ресурсах, не предусматривается хранение данных о сотрудниках и задачах;
2. Поиск по базе так же реализован, но не предусмотрено сохранение искомых данных в виде отчетов;
3. С помощью данного программного модуля невозможно отследить текущие задачи того или иного сотрудника.
Учитывая вышеперечисленные особенности рассмотренного программного продукта, можно сделать вывод о том, что задача разработки автоматизированной системы учета работ по созданию электронных образовательных ресурсов остается актуальной.
Выводы по главе
Данная глава дипломной работы посвящена постановке задачи автоматизации и анализу предметной области системы учета работ по созданию электронных образовательных ресурсов, а также описанию предприятия, на примере которого будет продемонстрирована работоспособность и эффективность разрабатываемого приложения.
В результате были определены основные требования к разрабатываемому программному обеспечению.
Глава 2. Проектирование системы учета работ по созданию электронных образовательных ресурсов
2.1 Выбор методологии
Наличие методологии является обязательным условием для осуществления проектов разработки информационных систем (ИС) в заданные сроки и с высоким качеством. На практике методология представляет собой совокупность взаимоувязанных стадий, этапов и операций, образующих технологический процесс разработки программного обеспечения.
Существует множество различных методологий проектирования, вот некоторые из них:
- ГОСТ 34.601-90
распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла;
- ISO/IEC 12207:1995
стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного программного обеспечения. Стандарт не содержит описания фаз, стадий этапов;
- Rational Unified Process
(RUP) от Rational Software предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (Unified Modeling Language, UML), а так же конкретной технологии проектирования и разработки;
- Microsoft
Solution
Framework
(MSF) представляет общую методологию разработки и внедрения решений в сфере информационных технологий (Information Technologies, IT). Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT-проектов. Последняя версия модели дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения и включает пять фаз: анализ, проектирование, разработка, стабилизация и внедрение, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений;
- Application
Lifecycle
Management
(ALM) от Borland направлена на ускорение и оптимизацию жизненного цикла приложений, а также интеграцию и совместное использование продуктов Borland. Данная стратегия, реализованная в наборе кросс-платформенных средств управления жизненным циклом приложений, призвана ускорить создание программных систем и обеспечить гарантированное получение нужного результата в рамках контролируемого и предсказуемого процесса разработки.
Методологии ГОСТ 34.601-90 и ISO/IEC 12207:1995 не поддерживают объектно-ориентрованный подход, поэтому использоваться не будут.
Наиболее подходящую методологию проектирования определим с помощью метода бальных оценок, используя критерии доступности, охвата всех этапов жизненного цикла, скорости разработки и простоты изучения:
Таблица 2.1. Сравнительный анализ методологий проектирования
| Критерии выбора |
RUP |
MSF |
ALM Borland |
Вес |
| Доступность |
5 |
5 |
4 |
3 |
| Охват всех этапов Ж.Ц. |
5 |
4 |
5 |
4 |
| Скорость разработки |
4 |
2 |
2 |
1 |
| Простота изучения |
5 |
3 |
4 |
2 |
| Итого: |
49 |
39 |
42 |
В соответствии с проведенным анализом, для проектирования ИС выбрана методология RUP
(Rational Unified Process) - одна из технологий, претендующая на роль фактического стандарта.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 2.1. Жизненный цикл программного обеспечения по RUP
Согласно RUP, жизненный цикл программного обеспечения разбивается на отдельные циклы, в каждом из которых создается новое поколение продуктов. В RUP входят 6 основных циклов:
1. Бизнес-моделирование (Business modeling);
2. Управление требованиями (Requirements);
3. Анализ и Проектирование (Analysis and Design);
4. Реализация (Implementation);
5. Тестирование (Test);
6. Развертывание (Deployment).
И три вспомогательные:
1. Управление проектом (Project management);
2. Управление изменениями (Change management);
3. Среда (Environment).
Каждый цикл, в свою очередь, разбивается на 4 стадии:
1. начальная стадия (Inception),
2. стадия разработки (Elaboration),
3. стадия конструирования (Construction),
4. стадия ввода в действие – (Transition).
Каждая стадия завершается в четко определенной точке (milestone). В этот момент времени должны достигается важные результаты и приниматься критически важные решения для дальнейшей разработки.
Основными принципами RUP являются:
1. Итерационный и инкрементный (наращиваемый) подход к созданию программного обеспечения;
2. Планирование и управление проектом на основе функциональных требований к системе – вариантов использования;
3. Построение системы на базе архитектуры программного обеспечения.
Rational
Unified
Process
поддерживает объектно-ориентированную технологию. Моделирование по методологии RUP является объектно-ориентированным и базируется на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), в качестве единого стандарта для организации взаимодействия участников проекта используют Unified Modelling Language™ (UML)
— универсальный язык моделирования.
Важнейшие аспекты
RUP
Главная цель любой организации, занимающейся созданием информационных систем — работать эффективнее, а значит, быстрее создавать более качественные продукты и получать бизнес-преимущества от успешного ведения проектов. Внедрение передовой методологии, подобной RUP, позволяет гарантировать выработку и дальнейшее развитие в организации необходимых для этого навыков.
Однако внедрение методологии – не столь уж простой процесс, как это может показаться на первый взгляд. Очень важно, стремясь к более эффективному ведению проектов, не разрушить то, что уже достигнуто. Особенность методологии RUP в том, что она может быть настроена и адаптирована в соответствии с особенностями и требованиями организации-разработчика, при этом варианты внедрения RUP могут варьироваться в зависимости от конкретных условий.
Для упрощения перехода к методологии RUP допускается постепенное его внедрение. Но при этом RUP акцентирует внимание на нескольких важнейших элементах, без которых сложно гарантировать успех в проекте:
1. Общее видение проекта - сюда относятся первоначальный анализ будущего проекта, организация единого словаря для общения и ведение спецификации требований. Это важно потому, что участники проекта должны четко понимать цели проекта.
2. Бизнес-перспективы проекта - важны потому, что в основном проект выполняется для реализации каких-либо бизнес-целей. И если такие цели существуют, то имеет смысл начинать процесс разработки. Это не относится напрямую к научным и исследовательским проектам, т. к. их финансирование имеет иные корни.
3. План работ - позволяет определить ресурсы проекта, привязать их к задачам и рассчитать бюджет проекта. Таким образом, имеется возможность заранее спрогнозировать, насколько выгодно вести конкретный проект и какие могут быть при этом затраты.
4. Анализ рисков - важен потому, что обычно намного легче и дешевле выявить и устранить возможные проблемы заранее, чем делать это уже на поздних стадиях проекта.
5. Гибкая и надежная архитектура системы - гарантирует, что проект не потерпит крушение задолго до его завершения, что разработчики смогут развивать данную систему при изменении условий и правил ведения бизнеса на стороне заказчика.
6. Управление запросами на изменения - позволяет организовать эффективную работу и взаимодействие участников проекта. Возрастает контроль за качеством выполнения задания любого уровня, отслеживанием устранения ошибок и обработки предложений по дальнейшему развитию ИС.
7. Тестирование - дает возможность гарантировать высокое качество продукта, а, следовательно, не даст заказчику повод усомниться в возможностях организации-разработчика.
8. Акцент на самом продукте - крайне важен, потому что продукт — конечная цель любого проекта. Надо помнить в любой момент, что важны не модели или многочисленные документы проекта сами по себе, а именно конечный продукт. Все остальное создается только с тем, чтобы как можно скорее создать качественный продукт.
9. Документы для поддержки пользователя - необходимы, т. к. без них многие сильные стороны созданного продукта могут остаться неизвестными и недоступными.
10. Измерение проекта - в любой момент времени необходимо вовремя реагировать на возможные отклонения проекта от бюджета и на перерасход ресурсов.
Язык
UML
и его особенности
Инструментальные CASE-средства и диапазон их практического применения в большой степени зависят от удачного определения семантики и нотации соответствующего языка моделирования. Специфика языка UML заключается в том, что он определяет семантическую метамодель, а не модель конкретного интерфейса и способы представления или реализации компонентов.
Язык UML ориентирован для применения в качестве языка моделирования различными пользователями и научными сообществами для решения широкого класса задач ООАП. Многие специалисты по методологии, организации и поставщики инструментальных средств обязались использовать язык в своих разработках. При этом термин "унифицированный" в названии UML не является случайным и имеет два аспекта. С одной стороны, он фактически устраняет многие из несущественных различий между известными ранее языками моделирования и методиками построения диаграмм. С другой стороны, создает предпосылки для унификации различных моделей и этапов их разработки для широкого класса систем, не только программного обеспечения, но и бизнес-процессов. Семантика языка UML определена таким образом, что она не является препятствием для последующих усовершенствований при появлении новых концепций моделирования.
Унифицированный язык моделирования (UML) является стандартным инструментом для создания "чертежей" программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем.
UML подходит для моделирования любых систем: от информационных систем масштаба предприятия до распределенных web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Изучение UML удобнее всего начать с его концептуальной модели, которая включает в себя три основных элемента: базовые строительные блоки, правила, определяющие, как эти блоки могут сочетаться между собой, и некоторые общие механизмы языка.
Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств.
Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма - в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы.
Таким образом, в UML выделяют девять типов диаграмм:
- диаграммы классов;
- диаграммы объектов;
- диаграммы прецедентов;
- диаграммы последовательностей;
- диаграммы кооперации;
- диаграммы состояний;
- диаграммы действий;
- диаграммы компонентов;
- диаграммы развертывания.
2.2 Выбор инструментального средства проектирования
Наиболее распространенными средствами проектирования, поддерживающими язык UML и объектно-ориентированный подход, являются:
- Rational
Rose
– мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта является возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.
- Microsoft
Office
Visio
– это решение для создания технических и деловых диаграмм, предназначенных для систематизации и наглядного представления различных данных, процессов и систем. Данный продукт позволяет специалистам технических и коммерческих направлений визуализировать свои идеи, информацию и проекты. Диаграммы Microsoft Office Visio позволяют без труда осуществлять визуализацию и обмен различной информацией с высочайшей точностью, надежностью и эффективностью, недостижимыми при использовании текстовых и числовых данных.
- Borland
Together
Architect
представляет собой платформу визуального моделирования, предназначенную для архитекторов, проектировщиков, UML-дизайнеров, аналитиков бизнес-процессов и разработчиков моделей данных и позволяющую ускорить разработку высококачественного программного обеспечения. Together Architect помогает разработчикам лучше использовать информацию, получаемую от экономистов и лиц, определяющих и комментирующих требования к разрабатываемому программному обеспечению. Данное решение позволяет создавать модели UML и модели бизнес-процессов для генерации языка выполнения бизнес-процессов с возможностью описания web-сервисов. Повышает производительность и качество путем автоматизации отображения структуры и кода приложения с использованием аудита и метрик на уровнях моделей и кода.
Составим таблицу, в которой с помощью метода бальных оценок определим наиболее подходящее инструментальное средство проектирования, согласно критериям доступности, требования к ресурсам и удобства интерфейса:
Таблица 2.2. Сравнительный анализ средств проектирования
| Критерии выбора |
Rational Rose |
Microsoft Office Visio |
Borland Together |
Вес |
| Доступность |
3 |
5 |
3 |
3 |
| Требования к ресурсам |
5 |
4 |
3 |
1 |
| Удобство интерфейса |
4 |
5 |
3 |
2 |
| Итого: |
22 |
29 |
18 |
Итак, в соответствии с проведенным анализом, в качестве средства проектирования используется Microsoft Office Visio.
2.3 Проектирование системной архитектуры
Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения.
Системная архитектура является, пожалуй, наиболее важным артефактом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем протяжении ее жизненного цикла.
Архитектура - это совокупность существенных решений касательно:
- организации программной системы;
- выбора структурных элементов, составляющих систему, и их интерфейсов;
- поведения этих элементов, специфицированного в кооперациях с другими элементами;
- составления из этих структурных и поведенческих элементов все более и более крупных подсистем;
- архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способ их объединения.
Моделью называется семантически замкнутая абстракция системы. Модель строится для того, чтобы лучше понимать разрабатываемую систему.
Моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме, так называемой диаграммы вариантов использования (Use Case Diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.
2.3.1 Построение диаграммы вариантов использования
Диаграммы вариантов использования показывают взаимодействия между вариантами использования и действующими лицами, отражая функциональные требования к системе с точки зрения пользователя. Цель построения диаграмм вариантов использования – это документирование функциональных требований в самом общем виде, поэтому они должны быть предельно простыми.
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представление о поведении системы с точки зрения пользователя. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он преследует по отношению к разрабатываемой системе.
Актер представляет собой связное множество ролей, которые пользователи вариантов использования исполняют во время взаимодействия с ними. Обычно актер представляет роль, которую в данной системе играет человек, аппаратное устройство или даже другая система. Экземпляр актера представляет собой конкретную личность, взаимодействующую с системой определенным образом. Актеры не являются частью системы, так как существуют вне нее. Актеров можно связывать с вариантами использования только отношениями ассоциации. Ассоциация между актером и вариантом использования показывает, что они общаются друг с другом, возможно, посылая или принимая сообщения.
Основными участниками процесса создания электронных образовательных ресурсов являются начальник и простые сотрудники Центра проектирования контента. В целом их функции в системе очень схожи, однако, существуют и такие, которые доступны либо только начальнику, либо только обычному сотруднику.
Рис. 2.3.1. Пользовательская диаграмма вариантов использования
Например, непосредственно разработкой электронного образовательного ресурса занимается только сотрудник, соответственно только он может получить назначенное задание. Функция же начальника в этом случае заключается лишь в контроле выполнения работ. Однако, и начальник и простой сотрудник имеют возможность работать с базой данных электронных образовательных ресурсов, назначать задачи и формировать отчетную документацию.
Более детально процесс представлен на системной диаграмме вариантов использования, которая приводится в приложении 1.
2.3.2 Спецификация вариантов использования
На данном этапе каждый вариант использования специфицируется посредством построения одного или двух типов диаграмм, в зависимости от характера моделируемых действий.
Диаграмма деятельности - это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами.
Диаграммы последовательности отражают временную упорядоченность сообщений.
Процесс разработки нового электронного образовательного ресурса начинается с работы с базой данных ресурсов. В нее необходимо внести запись об образовательном ресурсе, который будет разрабатывается. Каждый ресурс в базе имеет свою категорию, которая выбирается в процессе создания записи о ресурсе. Если же подходящей категории нет, то ее можно создать путем внесения новой записи в таблицу Категории ресурсов. После выбора категории необходимо ввести другие сведения о ресурсе: его наименование, автора, краткие сведения, а так же имя сотрудника, который будет заниматься его разработкой. Данный процесс представлен на рис. 2.3.2.
Диаграмма последовательности данного процесса приведена в приложении 3.
Рис. 2.3.2. Диаграмма деятельности «Работа с БД ЭОР»
После внесения записи и ресурсе, необходимо назначить задачу на разработку данного ресурса. Для этого, прежде всего, нужно выбрать задачу из общего списка задач, только что созданный ресурс и разработчика, которому поручается данная работа. Кроме того, здесь необходимо указать крайние сроки выполнения работы, а так же дополнительные сведения о задаче.
Рис. 2.3.3. Диаграмма деятельности «Назначение задачи»
Диаграмма последовательности приведена в приложении 4.
После назначения данная задача появляется в списке новых задач назначенного разработчика. После просмотра основных сведений о задаче, сотрудник приступает к разработке указанного образовательного ресурса, при этом он указывает дату начала работ. При завершении разработки, соответственно, дату окончания работ.
Рис. 2.3.4. Диаграмма деятельности «Получение задания»
Диаграмма последовательности приведена в приложении 5.
После того как разработчик внесет дату окончания работ, в профиле начальника появится запись о вновь созданном образовательном ресурсе. Начальник должен проконтролировать выполнение задания разработчиком и проверить ресурс на наличие несоответствий требованиям. Если несоответствий не обнаружено, начальник публикует ресурс на образовательном портале, при этом в системе указывает дату публикации. В противном случае создается новая задача на исправление несоответствий в данном ресурсе. При этом в сведениях о задаче вносится информация о несоответствиях, которые необходимо исправить.
Время от времени, руководство филиала требует отчетности о состоянии учебного контента, кроме того, каждому сотруднику по окончании месяца необходимо предоставить отчет по деятельности. С помощью данной системы задача составления таких отчетов существенно упрощается. Сведения о ресурсах и обо всех выполненных и невыполненных работах хранятся в системе, и для того чтобы их получить, достаточно внести все необходимы параметры, после чего отчет будет сгенерирован системой, и его можно будет сохранить и вывести на печать.
Рис. 2.3.5. Диаграмма деятельности «Формирование отчетной документации»
Диаграмма последовательности приведена в приложении 6.
Помимо данного отчета, в пределах отдела действует и другая отчетная документация, например, отчеты по электронным учебным курсам. Принципы составления таких отчетов практически не отличаются, меняются лишь атрибуты, по которым производится выборка.
В общем виде весь процесс представлен на общей диаграмме деятельности с дорожками, которая приведена в приложении 2.
2.3.3 Построение диаграммы классов
На данном этапе выявленные в процессе концептуального проектирования объекты были преобразованы в классы и построены соответствующие диаграммы, которые в совокупности являются логическим проектом базы данных.
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Вид и интерпретация диаграммы классов существенно зависит от точки зрения (уровня абстракции): классы могут представлять сущности предметной области (в процессе анализа) или элементы программной системы (в процессах проектирования и реализации).
При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования.
Диаграмма классов проектируемой системе изображена на рисунке 2.3.6.
Рис. 2.3.6. Диаграмма классов
Структура классов
Класс Сотрудники ЦПК используется для хранения информации о сотрудниках.
Атрибуты класса Сотрудники ЦПК
| Имя атрибута |
Тип атрибута |
Описание атрибута |
| ID сотрудника |
integer |
Уникальный идентификатор сотрудника |
| ФИО |
string |
Фамилия, имя, отчество сотрудника |
| Телефон |
string |
Телефон |
| |
string |
Электронная почта |
| Адрес |
string |
Адрес |
Данный класс подразделяется на два подкласса: Начальник ЦПК и Сотрудник ЦПК, их атрибуты совпадают.
Методы класса Сотрудники ЦПК
| Имя метода |
Описание метода |
| Показать |
Используется для вывода сведений о сотрудниках |
| Редактировать |
Используется для редактирования сведений о сотрудниках |
Класс Задачи используется для хранения информации обо всех типах задач, которые могут быть назначены сотруднику.
Атрибуты класса Задачи
| Имя атрибута |
Тип атрибута |
Описание атрибута |
| ID задачи |
integer |
Уникальный идентификатор задачи |
| Наименование |
string |
Наименование задачи |
Методы класса Задачи
| Имя метода |
Описание метода |
| Добавить |
Используется для добавления новой задачи |
| Удалить |
Используется для удаления задачи |
| Редактировать |
Используется для редактирования задачи |
Класс Назначенные задачи используется для хранения сведений о назначенных задачах.
Атрибуты класса Назначенные задачи
| Имя атрибута |
Тип атрибута |
Описание атрибута |
| ID назначения |
integer |
Уникальный идентификатор назначения |
| ID задачи |
integer |
Уникальный идентификатор задачи |
| ID ресурса |
integer |
Уникальный идентификатор ресурса |
| ID разработчика |
integer |
Уникальный идентификатор того, кому назначена задача |
| ID назначающего |
integer |
Уникальный идентификатор того, кто назначил задачу |
| Дополнительные сведения |
string |
Дополнительные сведения о задаче |
| Дата назначения |
date |
Дата назначения задачи |
| Крайний срок выполнения |
date |
Крайний срок, к которому задача должна быть выполнена |
| Дата начала выполнения |
date |
Дата начала работ по выполнению |
| Дата окончания выполнения |
date |
Дата окончания работ по выполнению |
Методы класса Назначенные задачи
| Имя метода |
Описание метода |
| Назначить |
Используется для назначения задачи по разработке ЭОР одному из сотрудников |
| Редактировать |
Используется для редактирования основных сведений о задаче |
Класс Категории ресурсов используется для хранения информации о категориях электронных образовательных ресурсов.
Атрибуты класса Категории ресурсов
| Имя атрибута |
Тип атрибута |
Описание атрибута |
| ID категории |
integer |
Уникальный идентификатор категории |
| Наименование |
string |
Наименование категории |
Методы класса Категории ресурсов
| Имя метода |
Описание метода |
| Добавить |
Используется для добавления новой категории |
| Удалить |
Используется для удаления категории |
| Редактировать |
Используется для редактирования категории |
Класс Электронные образовательные ресурсы используется для хранения информации об электронных образовательных ресурсах.
Атрибуты класса Электронные образовательные ресурсы
| Имя атрибута |
Тип атрибута |
Описание атрибута |
| ID ресурса |
integer |
Уникальный идентификатор ресурса |
| ID категории |
integer |
Уникальный идентификатор категории ресурса |
| ID кафедры |
integer |
Уникальный идентификатор кафедры |
| Наименование |
string |
Наименование ресурса |
| Автор |
string |
Автор |
| Город |
string |
Город, в котором проживает автор, написавший курс |
| Описание |
string |
Описание ресурса, краткие сведения |
| ID разработчика |
integer |
Уникальный идентификатор сотрудника, которому поручено разработать данный ресурс |
| Дата публикации |
date |
Дата публикации данного ресурса на образовательном портале |
Методы класса Электронные образовательные ресурсы
| Имя метода |
Описание метода |
| Добавить |
Используется для добавления нового ресурса |
| Удалить |
Используется для удаления ресурса |
| Редактировать |
Используется для редактирования сведений о ресурсе |
Класс Кафедры служит для хранения информации о кафедрах белгородского филиала МЭСИ.
Атрибуты класса Кафедры
| Имя атрибута |
Тип атрибута |
Описание атрибута |
| ID кафедры |
integer |
Уникальный идентификатор кафедры |
| Наименование |
string |
Наименование задачи |
Методы класса Кафедры
| Имя метода |
Описание метода |
| Добавить |
Используется для добавления новой кафедры |
| Удалить |
Используется для удаления кафедры |
| Редактировать |
Используется для редактирования кафедры |
Класс Отчеты служит для хранения сведений о выданных отчетах сотрудников.
Атрибуты класса Отчеты
| Имя атрибута |
Тип атрибута |
Описание атрибута |
| Номер |
integer |
Номер (уникальный идентификатор) отчета |
| Наименование |
string |
Наименование (краткое описание) выдаваемого отчета |
| ID сотрудника |
string |
Уникальный идентификатор сотрудника, которому выдается отчет |
| Дата запроса |
date |
Дата запроса отчета |
Методы класса Отчеты
| Имя метода |
Описание метода |
| Сгенерировать |
Используется для выбора задач выполненных сотрудником за указанный период времени |
| Сохранить |
Используется для сохранения отчета |
| Вывести |
Вывод отчета на бумагу или в текстовый формат |
2.4 Структура базы данных
2.4.1 Логическая модель данных
База данных (БД) — это особым образом организованный набор значений данных, а схема БД определяет, как именно организованы данные в БД. В процессе физического дизайна члены проектной команды создают схему БД, чтобы определить, что именно нужно создавать, о том же, какими инструментами это будет реализовываться, следует думать позже.
В процессе логического дизайна команда описывает сущности и атрибуты, которые будут храниться в БД, и то, как пользователи будут получать к ним доступ, оперировать ими и просматривать их. В процессе физического дизайна команда создает схему базы данных, которая представляет собой спецификацию по созданию, чтению, изменению и удалению используемых в продукте данных.
В результате исследования диаграмм использования и диаграммы классов, с учетом предметной области были выделены следующие сущности:
1.Категории ресурсов,
2.Электронные образовательные ресурсы (ЭОР),
3.Сотрудники,
4.Кафедры,
5.Задачи,
6.Назначенные задачи,
7.Отчеты.
Сущность «Сотрудники» используется для хранения информации о сотрудниках. Одному сотруднику может быть одновременно назначено несколько задач, поэтому между сущностями «Сотрудники» и «Назначенные задачи» - отношение «один ко многим». Кроме того, один и тот же сотрудник может разработать несколько образовательных ресурсов, поэтому сущности «Сотрудники» и «ЭОР» имеют отношение «один ко многим». Так же, один сотрудник может выводить несколько различных отчетов, поэтому сущности «Сотрудники» и «Отчеты» имеют отношение «один ко многим».
Сущность «ЭОР» используется для хранения информации об электронных образовательных ресурсах. Несколько образовательных ресурсов могут относиться к одной категории, поэтому между сущностями «Категории ресурсов» и «ЭОР» - отношение «один ко многим». Кроме того, несколько образовательных ресурсов могут одновременно относиться к одной кафедре, поэтому сущности «ЭОР» и «Кафедры» связаны отношением «один ко многим».
Сущность «Назначенные задачи» используется для хранения сведений о назначенных задачах. Существует определенный набор задач, которые выполняет сотрудник при разработке образовательных ресурсов, все эти задачи собраны в сущности «Задачи». Так как одновременно может быть назначено сразу несколько различных задач, то сущности «Задачи» и «Назначенные задачи» связаны отношением «один ко многим».
Сущность «Отчеты» служит для хранения сведений о выданных отчетах. Сотрудник имеет право получать много различных отчетов, поэтому между сущностями «Сотрудники» и «Отчеты» - отношение «один ко многим».
При проектировании структуры базы данных необходимо соблюдать законы нормализации БД.
Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные.
Функциональная зависимость. Поле В таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно существует только одно из различных значений поля В. Отметим, что здесь допускается, что поля А и В могут быть составными.
Полная функциональная зависимость. Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А.
Многозначная зависимость. Поле А многозначно определяет поле В той же таблицы, если для каждого значения поля А существует хорошо определенное множество соответствующих значений В.
Этот процесс включает:
· устранение повторяющихся групп (приведение к 1НФ)
· удаление частично зависимых атрибутов (приведение к 2НФ)
· удаление транзитивно зависимых атрибутов (приведение к 3НФ).
Проведем нормализацию данных в рассматриваемой концептуальной модели.
Первая нормальная форма
требует, чтобы каждое поле таблицы БД было неделимым, не содержало повторяющихся групп.
Вторая нормальная форма
требует, чтобы все поля зависели от первичного ключа. Те поля, которые зависят только от части первичного ключа должны быть выделены в отдельные таблицы. Набор полей однозначно определяет одну запись.
Ключ или
возможный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за
первичный ключ. Первичный ключ обеспечивает идентификацию записи, устанавливает связи между таблицами. Выделяем первичные ключи:
· В категориях ресурсов – ID категории,
· В ЭОР – ID ресурса,
· В Кафедрах – ID кафедры,
· В Сотрудниках – ID сотрудника,
· В Задачах – ID задачи,
· В Назначенных задачах – ID назначения,
· В Отчетах – Номер.
Третья нормальная форма
требует, чтобы значение любого поля таблицы, не входящего в первичный ключ, не зависело от значения другого поля не входящего в первичный ключ. Данная нормальная форма требует, чтобы поля, которые можно вычислить, необходимо удалить из таблиц. В рассматриваемой концептуальной модели таких полей нет.
Руководствуясь ранее выделенными сущностями, и, применив законы нормализации, получим таблицы проектируемой нормализованной базы данных:
Рис. 2.2. Структура базы данных
Выводы по главе
Вторая глава дипломной работы посвящена проектированию системы учета работ по созданию электронных образовательных ресурсов.
Был проведен сравнительный анализ и выбор инструментальных средств проектирования системы. Были выбраны методологии, язык моделирования и инструментальные средства для проектирования. При помощи данного набора инструментов была спроектирована система, описаны все ее функции, формализованы варианты использования, определены классы внутри системы, методы передачи и обработки информации.
Глава 3. Разработка автоматизированной системы учета работ по созданию электронных образовательных ресурсов
3.1 Выбор средств реализации системы
3.1.1 Выбор СУБД
Базами данных (БД) называют электронные хранилища информации, доступ к которым осуществляется с одного или нескольких компьютеров. Обычно БД создаются для хранения данных, содержащих сведения о некоторой предметной области, то есть некоторой области человеческой деятельности или области реального мира, и доступа к ним.
Системы управления базами данных (СУБД) – это программные средства, предназначенные для создания, наполнения, обновления и удаления баз данных.
В зависимости от местоположения отдельных частей СУБД различают локальные и сетевые СУБД.
В локальной СУБД все части локальной СУБД размещаются на компьютере пользователя базы данных. Чтобы с одной и той же БД одновременно могли работать несколько пользователей, каждый пользовательский компьютер должен иметь свою копию локальной БД. Существенной проблемой СУБД такого типа является синхронизация копий данных, именно поэтому для решения задач, требующих совместной работы нескольких пользователей, локальные СУБД практически не применяются.
К сетевым относятся файл-серверные, клиент-серверные и распределенные СУБД. Непременным атрибутом этих систем является сеть, обеспечивающая аппаратную связь компьютеров и делающая возможной корпоративную работу множества пользователей с одними и теми же данными.
Проектируемая система должна удовлетворять требованиям надежности, корректности всей информации, удобства управления и работы с данным программным средством.
Наибольшее распространение получили модели доступа данных ADO.NET, OLE DB, поэтому для реализации базы данные будет использоваться файл-серверная СУБД.
В файл-серверных СУБД все данные обычно размещаются в одном или нескольких каталогах достаточно мощной машины, специально выделенной для этих целей и постоянно подключенной к сети. Безусловным достоинством СУБД этого типа является относительная простота ее создания и обслуживания – фактически все сводится лишь к развертыванию локальной сети и установке на подключенных к ней компьютерах сетевых операционных систем. Недостатком файл-серверных систем является значительная нагрузка на сеть. При интенсивной работе с данными нескольких десятков клиентов, пропускная способность сети может оказаться недостаточной, и пользователя будут раздражать значительные задержки в реакции СУБД на его запросы. Файл-серверные СУБД могут успешно использоваться в относительно небольших фирмах с количеством клиентских мест до нескольких десятков.
С учетом того, что весь штат сотрудников отдела ЦПК составляет на данный момент всего три человека, можно сделать вывод о том, что файл-серверная СУБД будет оптимальным решением поставленной задачи по управлению данными.
Таблицы БД создаются с помощью утилиты Database Desktop. Тип таблицы – Paradox 7, так как он, по сравнению с другими, поддерживает самый богатый набор типов полей. Это позволяет автоматически следить за правильностью вводимых в поля данных, выбирать данные из другой таблицы, строить вторичные индексы, в том числе составные, следить за ссылочной целостностью БД, защищать таблицу от несанкционированного доступа, выбирать языковой драйвер.
3.1.2. Выбор средства разработки системы
Для реализации системы принято решение использовать объектно–ориентированный подход в программировании. Этот подход позволяет лучше отражать динамическое поведение системы в зависимости от возникающих событий. Конкретный процесс обработки информации при объектно-ориентированном подходе формируется в виде последовательности взаимодействия объектов. Так как этот подход предполагает совместное моделирование данных и процессов, то система объектно-ориентированных моделей последовательно направляется к модели динамического взаимодействия объектов, на основе которой могут быть сгенерированы классы объектов в конкретной программно-технической среде. Основываясь на знании языка программирования Object Pascal и требованиях к программе (операционная система, в которой она будет работать, наличие баз данных и т.д.), средой для реализации данного проекта выбран программный продукт компании Borland – Borland Developer Studio 2006.
Borland Developer Studio – единая среда быстрой разработки приложений, поддерживающая четыре языка программирования:
1. C++ для разработки библиотек по обеспечению доступа к специальному оборудованию;
2. Delphi для организации доступа к базам данных. (Delphi 2006 считается лучшей средой доступа к инструментам проектирования баз данных);
3. C# – для создания приложений управления предприятием на платформе .Net от компании Microsoft;
4. Java – для создания приложений управления предприятием на платформе CORBA/J2EE от компании Sun.
Благодаря новой среде можно, не выходя из неё, создавать микс из программ, написанных на различных языках программирования. Цель нового продукта – улучшение качества совмещения различных средств отладки, улучшение производительности и повышение стабильности среды разработки и приложений, и, безусловно, повышение продуктивности всех разработчиков, работающих в этой среде программирования.
Ниже приводятся отличительные особенности среды разработки Delphi 2006:
· Локальный BackUp. В среде ведётся история разработки проекта до 99-ти версий, включая содержание форм;
· Переработанный дизайнер форм (в частности облегчена проблема стартового размещения формы);
· Изменённый функционал редактора кода:
а) подсвечивание кода (подсветка изменений после последнего сохранения);
б) свёртывание фрагментов кода;
в) автоматическое составление списка локальных переменных;
г) автоматическая глобальная замена идентификаторов переменных;
д) автоматическая расстановка кавычек при вводе длинных значений для строковых переменных;
е) быстрое комментирование кода;
ж) подсветка/выделение ожидаемого ввода информации;
з) возможность рефакторинга (автоматическое добавление новых переменных во все объявления глобальных функций);
и) инспектирование отладочной информации на этапе отладки в форме всплывающих подсказок.
· Возможность автоматически запускать системные задачи перед или после компиляции программы.
Большинство функций автоматизации процесса редактирования кода выполняется "живыми шаблонами" и, либо выполняются анализатором кода на лету, либо вызываются из контекстного меню. Наборы "живых шаблонов" хранятся в XML-файлах. Эти файлы создаются и подключаются к контекстному меню без необходимости выходить из среды разработки.
3.2 Разработка пользовательского интерфейса
После выбора средства разработки системы можно переходить к реализации. Прежде всего, средствами Database Desktop были созданы таблицы базы данных, с которыми будет работать система. В таблицах использовались следующие типы данных:
· Number (n) – тип число;
· Alpha (a) – текстовое поле указанной длины;
· Date (d) – тип дата.
Для удобства пользования системой, ее экранные формы должны отвечать требованиям простоты и доступности.
Иерархия разработанных модулей системы представлена на рисунке:
Рис. 3.1. Иерархия основных модулей программы
Как видно на рис. 3.1 главный модуль изначальной включает два интерфейса: интерфейс начальника и интерфейс сотрудника. Один из них выбирается автоматически, в зависимости от того, кто авторизовался в системе.
При запуске системы, первое, что она будет делать, это искать базу данных для подключения. По умолчанию предполагается, что база находится в том же каталоге, где располагается файл запуска системы. Если базы там не окажется, система предложит указать путь расположения искомого каталога:
Рис. 3.2. Поиск базы данных
После того, как директория с базой данных будет указана, первая форма, которую увидит пользователь при запуске системы, будет форма авторизации, которая представлена на рис. 3.3:
Рис. 3.3. Авторизация в системе
В данном окне можно авторизоваться или, если вход осуществляется в первый раз, ввести свой пароль, который сохранится в базе данных, и в последующем будет постоянно использоваться при авторизации:
Рис. 3.4. Ввод пароля при первом входе в систему
После того, как система опознает входящего как сотрудника или начальника, перед пользователем откроется соответствующий интерфейс:
Рис. 3.5. Интерфейс сотрудника
На рисунке 3.5 изображен интерфейс сотрудника. Он включает в себя список текущих задач данного сотрудника и меню действий, производимых над этими задачами. Так сотрудник может либо начать выполнение какой-либо из поставленных задач, либо закончить начатую задачу. Все задачи касаются непосредственно создания электронных образовательных ресурсов.
Рис. 3.6. Интерфейс начальника
На рисунке 3.6 представлен интерфейс начальника. Здесь отображаются уже готовые электронные образовательные ресурсы, готовые для проверки и публикации. Проверив тот или иной ресурс, начальник может опубликовать его, используя меню действий, либо создать назначение на исправление несоответствий, если таковые обнаружатся.
Новое назначение создается при помощи главного меню Файл – Создать – Назначение. После выполнения команды, откроется окно модуля создания нового назначения, которое показано на рисунке 3.7:
Рис. 3.7. Форма создания нового назначения
В данном окне необходимо указать, кому поручается работа, какая работа и над каким ресурсом. Кроме того, можно указать дополнительные сведения и дату, к которой работа должна быть выполнена. Из данного окна так же возможен переход к модулям редактирования таблиц базы данных, например, к модулю создания нового ресурса или к модулю добавления нового сотрудника.
Следует заметить, что пользователь не сможет вернуться в главное окно программы, не закончив работу с активным. Это сделано для того, чтобы пользователь не путался между окнами, и все действия осуществлял последовательно.
Подобным образом выглядит окно для добавления нового образовательного ресурса. После заполнения всех полей и нажатия кнопки «Добавить» ресурс добавляется в базу, в дальнейшем его можно будет назначать на разработку или иные работы и публиковать.
Рис. 3.8. Форма добавления нового образовательного ресурса
Из отображенных в таблице ресурсов можно производить выборку по категории ресурса, а при необходимости и по кафедре, к которой относится дисциплина.
Рис. 3.9. База данных в режиме редактирования
На рисунке 3.8 изображена форма для редактирования таблиц базы данных. Таблицу можно выбрать из соответствующего меню. Значения, хранящиеся в таблице, можно редактировать, а так же добавлять новые записи с помощью кнопки «Создать запись».
Кроме того, в данной системе существует возможность автоматического создания отчетов по выполненным работам и по электронным образовательным ресурсам. Чтобы создать отчет, необходимо выбрать соответствующий пункт главного меню программы и выбрать тип отчета.
Рис. 3.10. Форма для создания отчета по выполненным работам
В появившемся окне необходимо выбрать сотрудника, по работам которого составляется отчет, и указать период времени, за который осуществлялись работы. После нажатия на кнопке «Сформировать отчет» отчет будет автоматически сгенерирован и доступен в таблице, после этого его можно сохранить в формате MS Word для редактирования и печати.
Отчет по ресурсам составляется по тому же принципу, но можно указывать большее количество параметров, по которым будет производиться выборка.
3.3 Контрольный пример
Для того чтобы наглядно продемонстрировать работоспособность созданной системы, выполним следующий пример:
1. Внесем в базу данных информацию как минимум о трех новых образовательных ресурсах;
2. Создадим назначение на разработку данных ресурсов;
3. Имитируем процесс работы над созданием данных ресурсов путем указания даты начала и окончания работы над ресурсами;
4. Создадим повторное назначение на исправление несоответствий в одном из данных ресурсов;
5. После выполнения работ опубликуем ресурсы;
6. И сгенерируем отчет по выполненным работам;
Результатом проделанных действий должно послужить следующее:
1. Таблица базы данных будет содержать информацию о вновь введенных образовательных ресурсах;
2. Назначение на разработку данных ресурсов должно появиться в списке текущих задач указанного сотрудника;
3. В результате указания дат начала и окончания выполнения задачи, данные ресурсы должны появиться в списке готовых к публикации ресурсов в интерфейсе начальника;
4. Новое назначение на исправление несоответствий одного из ресурсов снова появится в списке текущих задач;
5. После завершения работ ресурс должен оказаться доступным для публикации;
6. Отчет должен содержать сведения обо всех работах, произведенных над данными ресурсами.
Итак, используя модуль добавления новых образовательных ресурсов, внесем информацию о следующих ресурсах:
| Номер |
Категория |
Наименование |
Автор |
Кафедра |
| 1 |
Электронный учебный курс |
Базы данных |
Титаренко С.П. |
ПИ |
| 2 |
Электронный учебный курс |
Информационные технологии |
Титаренко С.П. |
ПИ |
| 3 |
Итоговый тест |
Портфельные инвестиции |
Кунташев П.А. |
Ф |
Ресурсы успешно добавились. Это можно увидеть на рисунке 3.11:
Рис. 3.11. Результат добавления новых ресурсов в базу
Как можно видеть на следующем рисунке, теперь введенные ресурсы доступны для того, чтобы создавать назначения на их разработку:
Рис. 3.12. Ресурсы доступны на создания назначений
После того, как назначения созданы, вернемся в интерфейс сотрудника, которому назначения были назначены. После обновления таблицы видно, что все задачи отображаются и доступны для ввода даты начала и окончания работы:
Рис. 3.13. Текущие задачи сотрудника
После указания дат начала и окончания назначенных работ, ресурсы перестают отображаться в списке текущих задач. Теперь ресурсы готовы и ждут публикации в интерфейсе начальника:
Рис. 3.14. Интерфейс начальника с указанными ресурсами
После публикации ресурсы больше недоступны для создания назначений на их разработку или корректировку. Создать назначение можно только на неопубликованный ресурс. При повторном создании назначения ресурс вновь исчезает из таблицы ожидающих ресурсов в интерфейсе начальника.
На заключительном этапе тестирования системы создадим отчет по проделанным работам для сотрудника, которому поручались задачи на создание указанных ресурсов. Введем период, в пределах которого данные работы проводились и нажмем кнопку «Сформировать отчет». Результат представлен на рисунке 3.15:
Рис. 3.15. Сформированный отчет
На рисунке видно, что выполненные задачи по заданным ресурсам присутствуют в отчете, это говорит о том, что разработанная система работает корректно. На примере система доказала свою работоспособность.
Выводы по главе
Третья глава дипломной работы посвящена разработке системы учета работ по созданию электронных образовательных ресурсов. Для разработки системы выбрана программа Borland Developer Studio 2006 от компании Borland. Данный выбор был обусловлен тем, что Delphi обеспечивает высокую скорость разработки, имеет целый ряд средств и инструментов для доступа к базам данных. Для реализации базы данных использовалась файл-серверная СУБД.
Так же в данной главе дипломной работы было проведено тестирование автоматизированной системы. В результате выполнения контрольного примера можно сделать выводы, что тестируемая система полностью соответствует заданным требованиям и выполняет все поставленные перед ней задачи.
Глава 4. Оценка экономической эффективности проекта
Любой разрабатываемый для промышленного использования программный продукт должен способствовать увеличению дохода фирмы или экономии средств в результате внедрения системы.
Эффективность – одно из наиболее общих экономических понятий, не имеющих единого общепризнанного определения. Это одна из возможных характеристик качества системы, а именно ее характеристика с точки зрения соотношения затрат и результатов функционирования системы, т.е. выполнение требуемых функций при минимальных затратах ресурсов.
Произведем расчет экономической эффективности проекта с точки зрения заказного проекта.
Структура экономической части при создании программного обеспечения по заказу фирмы следующая:
1. Технико-экономическое обоснование разработки ПО;
2. Расчет затрат на разработку ПО;
3. Стоимость внедрения ПО Заказчиком;
4. Расходы заказчика при эксплуатации ПО;
5. Эффективность внедрения для Заказчика ПО;
4.1 Технико-экономическое обоснование разработки ПО
Основной целью разработки автоматизированной системы учета работ по созданию электронных образовательных ресурсов является повышение оперативности, производительности и уровня организации труда работников отдела.
Назначение АИС - оперативное получение достоверной информации по текущим работам и по всем видам электронных образовательных ресурсов.
4.2 Расчет единовременных затрат на разработку ПО
К единовременным затратам разработчика относятся:
· теоретические исследования;
· разработка алгоритмов и программ;
· отладка;
· опытная эксплуатация;
· исследование рынка;
· реклама.
Таблица 4.1 представляет фактическую трудоемкость работ по стадиям проектирования.
Таблица 4.1. Содержание стадий научно-исследовательской работы
| Стадия |
Трудоемкость, дн. |
Трудоемкость, % |
| Техническое задание |
14 |
7 |
| Эскизный проект |
25 |
12,5 |
| Технический проект |
61 |
30,5 |
| Рабочий проект |
90 |
45 |
| Внедрение |
10 |
5 |
| Итого |
200 |
100,0 |
К затратам на научно-исследовательские работы относятся:
- материальные затраты;
- основная и дополнительная заработная плата;
- отчисления на социальные нужды;
- стоимость машинного времени на подготовку и отладку программ;
- стоимость инструментальных средств;
- накладные расходы.
1.
Материальные затраты
Под материальными затратами понимают отчисления на материалы, использующиеся в процессе разработки и внедрении программного продукта (в т.ч. стоимость бумаги, картриджей для принтера, дискет, дисков и т.д.) по действующим ценам.
В процессе работы использовались материалы и принадлежности, представленные в таблице 4.2
Таблица 4.2. Использованные материалы и принадлежности
| Наименование |
Цена |
Количество |
Стоимость |
| Бумага |
110 |
1 |
110 |
| Диски CD-RW |
35 |
1 |
35 |
| Flash накопитель |
450 |
1 |
450 |
| Итого |
595 |
||
2.
Основная и дополнительная заработная плата
Основная заработная плата при выполнении научно-исследовательских работ включает зарплату всех сотрудников, принимающих непосредственное участие в разработке программного обеспечения. В данном случае необходимо учитывать основную заработную плату разработчика (студента), дипломного руководителя и консультанта по экономике.
Основная заработная плата (Зосн
) при выполнении научно-исследовательских работ рассчитывается по формуле:
,
где Зсрдн
j
– зарплата j-го сотрудника, руб.;
n – количество сотрудников, принимающих непосредственное участие в разработке программного продукта.
Для расчета заработной платы разработчика (Зраз
) необходимо сразу указать, что всего научно-исследовательские работы производились в течение 190 дней. Среднедневная зарплата разработчика определена из расчета 7000 руб. в месяц и равна:
Заработная плата исполнителя в целом составляет:
Зраз
=200 дн.*350 руб./день=70000 руб.
На консультации запланировано: 23 часов – дипломный руководитель и 3 часа – консультант по экономике.
Заработная плата дипломного руководителя составляет 100 руб./час. Следовательно, среднедневная зарплата дипломного руководителя равна:
Зрук
=23*100=2300 руб.
Заработная плата консультанта по экономике составляет 80 руб./час. Следовательно, среднедневная зарплата равна:
Зконс
=3*80=240 руб.
Получаем, что основная заработная плата при выполнении научно-исследовательских работ равна сумме заработных плат разработчика (студента), дипломного руководителя и консультанта по экономике:
Зосн
=Зраз
+Зрук
+Зконс
=70000+2300+240=72540 руб.
Дополнительная заработная плата составляет 10 % от основной:
Здоп
=0,1*Зосн
=0,1*72540= 7254руб.
Итого основная и дополнительная заработная плата составляют:
Зобщ
=Зосн
+Здоп
=72540+7254=79794 руб.
3.
Отчисления на социальные нужды
Отчисления на социальные нужды составляют 26,2% от общего фонда заработной платы всех работников, получим:
Осоц
=0,262*Зобщ
=79794*0,262=20906,028 руб.
4.
Затраты на оплату машинного времени
Затраты на оплату машинного времени (Зомв
) зависят от времени работы на ЭВМ (Тэвм
), себестоимости машино-часа работы ЭВМ (Смч
) и включают в себя амортизацию ЭВМ и оборудования, затраты на электроэнергию. Стоимость одного машинного часа работы равна:
Смч
=0,24 кВт/час*1,72 руб./кВт=0,4128 руб./час
Время работы ЭВМ:
Тэвм
=0,35*Тэск
+0,6*Ттех пр
+0,8*Траб пр
+0,6*Твн
=
0,35*25+0,6*61+0,8*90+0,6*10=123,35 дней,
где Тэск
, Ттех пр
, Траб пр
, Твн
– фактические затраты времени на разработку эскизного, технического, рабочего проектов и внедрения соответственно, с учетом поправочных коэффициентов, дни.
С учетом того, что ЭВМ работала по восемь часов в сутки, получаем:
Тэвм
=123,35 дней*8ч=986,8 ч.
Себестоимость электроэнергии рассчитывается следующим образом:
Сэл
= Тэвм
*Смч
=986,8*0,4128=407,35104 руб.
Затраты на амортизацию (Ам
) ЭВМ и оборудование – это затраты на приобретение оборудования и его эксплуатацию, причем в статью расходов включают только амортизацию, начисленную за время работы над проектом. Имеем формулу:
Ам
=(Оф
*Нам
*Тэвм
)/(365*100),
где:
Оф
– персональная стоимость оборудования, руб.;
Нам
– норма амортизации, % (принято 20%);
Тэвм
– время использования оборудования, дн.
Таблица 4.3. Себестоимость оборудования и амортизационные отчисления
| Наименование оборудования |
Количество, шт. |
Первоначальная стоимость, руб. |
Общая стоимость, руб. |
| Компьютер Pentium IV (3GHz) |
1 |
25000 |
25000 |
| Принтер Epson Stylus |
1 |
4170 |
4170 |
| Итого |
29170 |
||
Согласно таблице 4.3, первоначальная стоимость оборудования составила 29170 руб. Произведем расчет затрат на амортизацию:
Ам
=(29170*20*123,35)/(365*100)=1971,57 руб.
Затраты на оплату машинного времени (Зовм
) включают:
1. Затраты на оборудование в размере 1971,57 руб.
2. Затраты на электроэнергию в размере 407,35104 руб.
Получаем, что стоимость машинного времени составляет:
Зовм
=1971,57 +407,35104 =2378,92104 руб.
5.
Стоимость инструментальных средств
Стоимость инструментальных средств включает затраты на системное программное обеспечение, использованное при разработке программного продукта в размере износа за этот период. Норма амортизации для системного программного обеспечения – 30%, а время использования 123,35 дней.
Таблица 4.4. Стоимость системного программного обеспечения
| Наименование продукта |
Первоначальная стоимость, руб. |
| Borland Developer Studio 2006 Professional |
30868.80 |
| MS Office Visio 2003 |
6000 |
| Итого |
36868,8 |
Амортизационные отчисления, входящие в стоимость разрабатываемого программного обеспечения, рассчитываются по формуле:
Аис
=(Оф
*Нам
*Тэвм
)/(365*100),
где
Оф
– первоначальная стоимость инструментальных средств, руб.;
Нам
– норма амортизации, % (принято 30%);
Тэвм
– время использования оборудования, дней.
Аис
=(36868,8*30*123,35)/(365*100)=3737,89 руб.
6.
Накладные расходы
Накладные расходы составляют 30% от суммы основной заработной платы:
Рн
=Зосн
*0,3=79794*0,3=23938,2 руб.
Далее в таблицу заносится смета затрат на программное обеспечение.
Таблица 4.5. Смета затрат на программное обеспечение
| Элемент затрат |
Сметная стоимость, руб. |
| Материальные затраты |
595 |
| Основная и доп. заработная плата |
79794 |
| Отчисления на соц. нужды |
20906,028 |
| Затраты на оплату машинного времени |
2378,92104 |
| Амортизация стоимости инструментальных средств |
3737,89 |
| Накладные расходы |
23938,2 |
| Итого затраты: |
131350,04 |
4.3
Стоимость внедрения ПО Заказчиком
К единовременным затратам пользователя программного обеспечения Kобщ
относятся затраты на оплату:
· программного обеспечения Цпо
;
· инструментальных средств Цис
;
· ЭВМ, прочих аппаратных средств и сетевого оборудования Кэвм
;
· обучение персонала Косв
.
Стоимость программного обеспечения
В этом случае стоимость равна себестоимости плюс прибыль разработчика (на практике обычно составляет 20-30% от себестоимости), а также налог на добавленную стоимость 13%. Для расчета можно использовать следующую формулу:
,
где - себестоимость ПО,
- прибыль разработчика,
- налог на добавленную стоимость.
НДС = (Спо
+ П) × 0,13=131350,04*0,13=17075,5 руб.
Прибыль разработчика составит:
П = 131350,04*0,2=26270,008 руб.
Цпо
=
131350,04+26270,008+17075,5=174695,548 руб.
Стоимость инструментальных средств
, необходимых для функционирования системы. В их состав обычно входят операционные системы, а также прикладное программное обеспечение. На предприятии заказчика уже установлены и используются все необходимые инструментальные средства. Поэтому при внедрении не предусматривается расходов по данным статьям.
Стоимость технического обеспечения,
требуемого для развертывания системы. Так как, опять же, в организации установлено все необходимое техническое обеспечение, и при внедрении не требуется никакого дополнительного оборудования, то расходы по данной статье не предусматриваются.
Стоимость обучения персонала организации.
Расчет производится по следующей формуле:
,
где - численность персонала на обучение,
- стоимость обучения одного человека в день,
- время обучения.
Предполагается, что в организации системой будет пользоваться три сотрудника. Время необходимое для обучения предположительно оценивается в два рабочих дня. Стоимость обучения одного человека в день 200 рублей. Затраты на обучение персонала:
= 3*200*2 = 1200 руб.
Общая сумма единовременных капитальных вложений Кобщ
будет равна:
Кобщ
= Цпо
+ Цис
+ Кэвм
+ Косв
+ Кинт
Кобщ
= 174695,548 + 1200 = 175895,548 руб.
Сумма затрат на разработку распределяется по этапам проектирования пропорционально трудоемкости. В результате составляется инвестиционный план, отраженный в таблице 4.6.
Таблица 4.6. План инвестиций
| Этапы реализации проекта |
Полугодия |
|
| 2 полугодие 2007 |
1 полугодие 2008 |
|
| Техническое задание |
12228,69 |
|
| Эскизный проект |
21836,94 |
|
| Технический проект |
53282,248 |
|
| Рабочий проект |
26204,3 |
52408,6 |
| Внедрение |
8734,77 |
|
| Обучение персонала |
1200 |
|
| Оборудование |
||
| ИС |
||
| Итого: |
113552,178 |
62343,37 |
4.4
Расходы заказчика при эксплуатации ПО
Расходы Заказчика по эксплуатации системы в год определяются исходя из следующего (в данном случае не учитываются амортизационные затраты оборудования, электроэнергия, ремонт оборудования и так далее, так как доля этих затрат, связанных непосредственно с функционированием системы, достаточно мала): расходы, связанные с сопровождением системы. Стоимость сопровождения оценивается в 3000 рублей в год.
4.5
Эффективность внедрения для Заказчика ПО
Оценивая предприятие заказчика с большой долей рутинной работы, попытаемся оценить экономический эффект от внедрения системы. Учитывая специфику отрасли Заказчика, попытаемся определить возможные направления повышения прибыли:
1. Повышение производительности труда сотрудников за счет:
· сокращения времени оформления всех типов отчетов;
· сокращения времени назначения новой работы;
· сокращение времени обработки информации;
2. Повышения скорости и качества выполняемой работы за счет строго определенных сроков, и с учетом количества ожидаемых заданий.
Каждый сотрудник обычно тратит, по меньшей мере, час в месяц на формирование отчета по проделанным работам. При использовании АИС на это будет уходить не более трех минут. Оставшееся время можно потратить на выполнение другой, не менее важной работы.
Каждый сотрудник на выполнение одного задания обычно тратит на несколько дней больше, так как не всегда имеет представление о том, какое количество работы его еще ждет. Если сроки явно начинают поджимать, качество работы снижается. Используя АИС, сотрудник всегда сможет правильно рассчитывать время и силы, необходимые ему для полного, своевременного и качественного выполнения рабочего плана.
Основными показателями экономической эффективности являются экономический эффект, срок окупаемости. Экономический эффект – результат внедрения какого-либо мероприятия, выраженный в стоимостной форме, в виде экономии от его осуществления. Срок окупаемости (величина, обратная коэффициенту эффективности) – показатель эффективности использования капиталовложений – представляет собой период времени, в течение которого произведенные затраты на программный продукт окупаются полученным эффектом.
ЭУГ
= ЭГ
– Зтек
, где
ЭУГ
– условно годовая экономия,
ЭГ
– годовая экономия,
Зтек
– текущие затраты после внедрения мероприятия (за год).
Заработная плата сотрудника отдела составляет примерно 500 рублей в день, следовательно, введя повременную оплату, используя систему, можно сэкономить примерно 10500 рублей в месяц. Что составляет 126000 рублей в год. Следовательно, ЭГ
= 126000 руб.,
Зтек
= Ам
+Аим
+Сэл
+Рн
=
1971,57+3737,89+407,35104+23938,2=30055,01104 руб.
ЭУГ
= 126000-30055,01104=95944,98896 руб.
Срок окупаемости капиталовложений:
ТОК
=Кобщ
/ЭУГ
ТОК
=175895,548/95944,98896=1,83 года.
Таким образом, можно сделать вывод, что при затратах на разработку и внедрение 175895,548 руб., срок окупаемости проекта возможен через 1,83 года.
Выводы по главе
В данной главе дипломной работе был проведен анализ показателей, характеризующих экономическую эффективность проекта. В результате анализа были сделаны выводы о его прибыльности.
В ходе вычислений были получены результаты:
· Рассчитаны затраты на разработку – 175895,548 рублей;
· Рассчитан экономический эффект от внедрения - 126000 рублей;
· Срок окупаемости проекта составляет 1,83 года или, примерно, 1 год и 7 месяцев.
Заключение
Центр проектирования контента играет первостепенную роль в производстве электронных образовательных ресурсов для студентов любых форм обучения. Поэтому очень важно скорректировать работу сотрудников данного отдела таким образом, чтобы их деятельность была максимально эффективной, а все работы проводились в качественно и в срок. В этих целях было принято решение разработать автоматизированную систему учета работ по созданию электронных образовательных ресурсов, которая позволила бы достичь ряда целей, например, обеспечить сотруднику оперативный доступ к его текущим и будущим задачам и существенно упростить процесс формирования отчетности. Ее создание помогло бы сотруднику выполнять все работы качественно и во время за счет строго определенных сроков, определенных на ту или иную работу.
В первой главе дипломной работы были произведены исследование и анализ предметной области, анализ других подобных систем, в результате которого была поставлена задача автоматизации и сформулированы основные требования к разрабатываемому программному обеспечению.
Для наиболее правильного анализа функций для последующей разработки системы, отвечающей поставленным требованиям, была спроектирована модель разработанной системы. Для проектирования системы методом балльных оценок была выбрана программа Microsoft Visio 2003. На основании моделирования удалось выделить основные объекты системы и их взаимосвязи, в соответствии с чем, была спроектирована структура базы данных. Разработка системы производилась в среде Borland Developer Studio 2006 компании Borland. Автоматизированная система учета работ по созданию электронных образовательных ресурсов была разработана на основании всех проделанных проектных работ, с учетом поставленных требований к системе.
Разработанная автоматизированная система прошла тестирование, в результате которого доказала свою работоспособность и отказоустойчивость при загрузке, внесении изменений и сохранении данных. При тестировании модуля построения отчетов система так же работала без сбоев, формат и содержание полученного отчета отвечает всем заданным требованиям.
Четвертая глава была посвящена расчету экономической эффективности от внедрения проекта. Полученные результаты говорят о полной окупаемости проекта примерно за 1 год и 7 месяцев.
Автоматизированная система учета работ по созданию электронных образовательных ресурсов разработана для отдела ЦПК, но так же может быть использована любыми небольшими организациями, специализирующимися на производстве учебной или любой другой литературы.
Применение автоматизированной системы позволит максимально упростить и оптимизировать труд работников отдела при назначении и выполнении задач и при формировании отчетов. Качество выполняемой работы возрастет при сокращении сроков выполнения.
Список литературы
1. Delphi 7. С. Бобровский - Питер, 2003 – 735 стр.
2. Delphi. Советы программистов (2-е издание): В.Озеров. – СПб: Символ-Плюс, 2002. – 976 стр.
3. Delphi 2005. Разработка приложений для баз данных и интернета: В. Фаронов. – Питер, 2006. – 602 стр.
4. Delphi. Программирование на языке высокого уровня: В. Фаронов, Учебник для вузов - СПб.: Питер 2005.- 640 стр.
5. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Скотт Ф. Уилсон, Брюс Мэйплс, Тим Лэндгрейв. – М: Русская редакция, 2002. – 736 стр.
6. Проектирование экономических информационных систем: Учебник / Г.Н.Смирнова, А.А.Сорокин, Ю.Ф.Тельнов. – М: Финансы и статистика, 2003. – 512 стр.
7. Вендров А.М. - Проектирование программного обеспечения экономических информационных систем. М.: «Финансы и статистика», 2002.
8. Самоучитель UML. Эффективный инструмент моделирования информационных систем: А. Леоненков. – СПб: BHV, 2001. – 304 стр.
9. Введение в RUP: Ф. Кратчен. – Электронный учебник.
10. Delphi 7 на примерах / Под ред. Ю. С. Ковтанюка — К.: Издательство Юниор, 2003. — 384 стр.
11. Нестандартные приемы программирования на Delphi. — СПб.: БХВ-Петербург, 2005. — 560 стр.
12. Барский А.Б. Нейронные сети: распознавание, управление, принятие решений. - издательство "Финансы и статистика" - 2004 г. - 176 стр.
13. Леонков А.В. Самоучитель UML. – СПб.: БХВ-Петербург, 2005. – 304 стр.
14. Компания Borland. WWW: http://www.borland.com
15. Русскоязычный сайт компании Borland. WWW: http://www.borland.ru
Приложение 1.
Системная диаграмма вариантов использования
Приложение 2.
Общая диаграмма деятельности с дорожками
Приложение 3
. Диаграмма последовательности «Работа с БД ЭОР»
Приложение 4.
Диаграмма последовательности «Назначение задачи»
Приложение 5.
Диаграмма последовательности «Получение задания»
Приложение 6.
Диаграмма последовательности «Формирование отчетной документации»
Приложение 7.
Пример отчета по проделанным работам за месяц
Приложение 8.
Пример отчета по электронным учебным курсам, написанным авторами белгородского филиала МЭСИ