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

/>/>Содержание

Введение. 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), а так же конкретной технологии проектирования иразработки;

ü MicrosoftSolutionFramework (MSF) представляет общую методологию разработки ивнедрения решений в сфере информационных технологий (Information Technologies, IT). Особенность этой модели состоит в том, что благодаря своейгибкости и отсутствию жестко навязываемых процедур она может быть применена приразработке весьма широкого круга IT-проектов.Последняя версия модели дополнена еще одним инновационным аспектом: онапокрывает весь жизненный цикл создания решения и включает пять фаз: анализ,проектирование, разработка, стабилизация и внедрение, является итерационной, предполагаетиспользование объектно-ориентированного моделирования. MSF в сравнении с RUP вбольшей степени ориентирована на разработку бизнес-приложений;

ü ApplicationLifecycleManagement (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.  Бизнес-моделирование (Businessmodeling);

2.  Управление требованиями(Requirements);

3.  Анализ и Проектирование (Analysis andDesign);

4.  Реализация (Implementation);

5.  Тестирование (Test);

6.  Развертывание (Deployment).

И три вспомогательные:

1.  Управление проектом (Projectmanagement);

2.  Управление изменениями (Changemanagement);

3.  Среда (Environment).

Каждый цикл, в своюочередь, разбивается на 4 стадии:

1.  начальная стадия (Inception),

2.  стадия разработки (Elaboration),

3.  стадия конструирования (Construction),

4.  стадия ввода в действие – (Transition).

Каждая стадия завершаетсяв четко определенной точке (milestone). В этот момент времени должны достигается важные результаты иприниматься критически важные решения для дальнейшей разработки.

Основными принципами RUP являются:

1.  Итерационный и инкрементный(наращиваемый) подход к созданию программного обеспечения;

2.  Планирование и управление проектом наоснове функциональных требований к системе – вариантов использования;

3.  Построение системы на базеархитектуры программного обеспечения.

RationalUnifiedProcessподдерживаетобъектно-ориентированную технологию. Моделирование по методологии RUP являетсяобъектно-ориентированным и базируется на понятиях объектов, классов изависимостей между ними. Эти модели, подобно многим другим техническимискусственным объектам (артефактам), в качестве единого стандарта дляорганизации взаимодействия участников проекта используют Unified ModellingLanguage™ (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 и объектно-ориентированный подход,являются:

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

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

ü BorlandTogetherArchitectпредставляет собой платформувизуального моделирования, предназначенную для архитекторов, проектировщиков,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 Телефон e-mail 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, поэтому дляреализации базы данные будет использоваться файл-серверная СУБД.

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

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

Таблицы БД создаются спомощью утилиты DatabaseDesktop. Тип таблицы – 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общ<sub/>относятся затраты на оплату:

·  программного обеспечения Цпо;

·  инструментальных средств Цис;

·  ЭВМ, прочих аппаратных средств исетевого оборудования Кэвм;

·  обучение персонала Косв.

Стоимость программногообеспечения

В этом случае стоимостьравна себестоимости плюс прибыль разработчика (на практике обычно составляет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. Delphi2005. Разработка приложений для баз данных и интернета: В. Фаронов. – Питер,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: www.borland.com

15.  Русскоязычный сайткомпании Borland. WWW: www.borland.ru


Приложение1. Системнаядиаграмма вариантов использования

/>


Приложение 2. Общая диаграмма деятельности сдорожками

/>


Приложение 3. Диаграмма последовательности«Работа с БД ЭОР»

/>


Приложение 4. Диаграмма последовательности«Назначение задачи»

/>


Приложение 5. Диаграмма последовательности«Получение задания»

/>


Приложение 6. Диаграмма последовательности«Формирование отчетной документации»

/>


Приложение 7. Пример отчета по проделанным работамза месяц

/>


Приложение 8. Пример отчета по электронным учебнымкурсам, написанным авторами белгородского филиала МЭСИ

/>

еще рефераты
Еще работы по информатике, программированию