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

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

Введение. 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

Введение

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

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

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

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

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

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

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

Столичный муниципальный институт экономики, статистики и информатики является одним из фаворитов на рынке образовательных услуг в сфере дистанционного образования. Направление на развитие ДО, данное головным университетом, реализуется и на уровне филиалов. Белгородский филиал МЭСИ первым в Белгородской области применил дистанционные технологии для получения высшего образования. Таковая комфортная, прогрессивная форма обучения пользуется спросом и уже завлекла сотки студентов.

В рамках снабжения студентов новенькими учебными материалами, белгородскому филиалу МЭСИ пришлось столкнуться с таковыми задачками как подготовка высококачественного и довольно информативного контента, что, в свою очередь, привело к возникновению такового подразделения как отдел РЦПК, который принял на себя всю ответственность по решению данной задачки.

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

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

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

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

Глава 1. исследование предметной области

1.1 Центр проектирования контента белгородского филиала МЭСИ

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

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

Столичный муниципальный институт экономики, статистики и информатики (МЭСИ) является флагманом движения русских вузов к электрическому обучению. В вузе практикуется смешанная форма обучения с постепенным повышением толики электрического обучения. На любом факультете МЭСИ выбираются учебные программки, педагоги по которым готовы перейти в режим электрического взаимодействия со своими студентами. Фактически любая группа студентов университета попадает хотя бы на один курс, в каком лекции и семинары проводятся в интерактивном режиме: студент без помощи других изучает лекционный материал, делает лабораторные работы, сдает испытания, разговаривает в дискуссионных форумах и чатах с сокурсниками и педагогом. Переводом обычных учебных курсов в электрическую форму занимается особое подразделение — Центр проектирования контента (ЦПК). Курс разбивается на темы, включающие в себя советы по обучению, фактически учебное пособие, короткое содержание по теме, практикум, тест и общую презентацию.

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

В собственной деятель региональный центр проектирования контента управляется работающим законодательством, Уставом Столичного муниципального института экономики, статистики и информатики, Положением о филиале МЭСИ и положением о отделе РЦПК.

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

Можно выделить главные функции Центра проектирования контента:

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 анализ имеющихся разработок

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

Посреди схожих систем, имеющих распространение, можно выделить программный модуль «БЭРОН» («Банк электрических ресурсов образовательного предназначения»).

БЭРОН — программный модуль, обеспечивающий хранение, классификацию и следующее внедрение электрических ресурсов создаваемых преподавателями; интеграцию и ассимиляции готовых электрических ресурсов.

Ресурс, заносимый в БЭРОН, быть может также позиционирован по виду и предназначению.

БЭРОН реализуется в виде 3-х самостоятельных рабочих мест: юзера, создателя, админа. Пользовательское рабочее пространство обеспечивает способности поиска требуемых ресурсов по классификатору, по атрибутам. Производит формирование выборок и сортировку данных снутри выборок.

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

Разглядим данный продукт исходя из убеждений решения намеченных целей:

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-проектов. Крайняя версия модели дополнена еще одним инноваторским нюансом: она покрывает весь актуальный цикл сотворения решения и включает 5 фаз: анализ, проектирование, разработка, стабилизация и внедрение, является итерационной, подразумевает внедрение объектно-ориентированного моделирования. 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, дозволяет гарантировать выработку и предстоящее развитие в организации нужных для этого способностей.

Но внедрение методологии – не настолько уж обычной процесс, как это может показаться на 1-ый взор. Весьма принципиально, стремясь к наиболее действенному ведению проектов, не повредить то, что уже достигнуто. Изюминка методологии 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 — это графическое системы с различных точек зрения. Диаграмма — в неком смысле одна из проекций системы. Обычно, кроме более очевидных случаев, диаграммы дают свернутое один и этот же элемент может находиться во всех диаграммах, либо лишь в нескольких (самый всераспространенный вариант), либо не находиться ни в одной (весьма изредка). На теоретическом уровне диаграммы могут содержать любые композиции сущностей и отношений. На практике, но, применяется сравнимо маленькое количество типовых композиций, соответственных 5 более употребительным видам, которые составляют архитектуру программной системы.

Таковым образом, в 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 Спецификация вариантов использования

На данном шаге любой вариант использования специфицируется средством построения 1-го либо 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НФ).

Проведем нормализацию данных в рассматриваемой концептуальной модели.

1-ая обычная форма
просит, чтоб каждое поле таблицы БД было неразделимым, не содержало циклических групп.

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

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

· В категориях ресурсов – ID группы,

· В ЭОР – ID ресурса,

· В Кафедрах – ID кафедры,

· В Сотрудниках – ID сотрудника,

· В Задачках – ID задачки,

· В Назначенных задачках – ID предназначения,

· В Отчетах – Номер.

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

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

Рис. 2.2. структура базы данных

Выводы по главе

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

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

Глава 3. Разработка автоматической системы учета работ по созданию электрических образовательных ресурсов

3.1 Выбор средств реализации системы
3.1.1 Выбор СУБД

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

системы управления базами данных (СУБД) – это программные средства, созданные для сотворения, заполнения, обновления и удаления баз данных.

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

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

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

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

Наибольшее распространение получили модели доступа данных ADO.NET, OLE DB, потому для реализации базы данные будет употребляться файл-серверная СУБД.

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

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

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

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

Рис. 3.2. Поиск базы данных

Опосля того, как директория с базой данных будет указана, 1-ая форма, которую увидит юзер при запуске системы, будет форма авторизации, которая представлена на рис. 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. Внесем в базу данных информацию как минимум о 3-х новейших образовательных ресурсах;

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

3. Имитируем процесс работы над созданием данных ресурсов методом указания даты начала и окончания работы над ресурсами;

4. Сделаем повторное предназначение на исправление несоответствий в одном из данных ресурсов;

5. Опосля выполнения работ опубликуем ресурсы;

6. И сгенерируем отчет по выполненным работам;

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

1. Таблица базы данных будет содержать информацию о вновь введенных образовательных ресурсах;

2. Предназначение на разработку данных ресурсов обязано показаться в перечне текущих задач обозначенного сотрудника;

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

4. Новое предназначение на исправление несоответствий 1-го из ресурсов опять покажется в перечне текущих задач;

5. Опосля окончания работ ресурс должен оказаться легкодоступным для публикации;

6. Отчет должен содержать сведения обо всех работах, сделанных над данными ресурсами.

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

Номер

Категория

Наименование

Создатель

Кафедра

1

электрический учебный курс

Базы данных

Титаренко С.П.

ПИ

2

электрический учебный курс

Информационные технологии

Титаренко С.П.

ПИ

3

Итоговый тест

Портфельные Инвестиции

Кунташев П.А.

Ф

Ресурсы удачно добавились. Это можно узреть на рисунке 3.11:

Рис. 3.11. Итог прибавления новейших ресурсов в базу

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

Рис. 3.12. Ресурсы доступны на сотворения предназначений

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

Рис. 3.13. Текущие задачки сотрудника

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

Рис. 3.14. интерфейс начальника с обозначенными ресурсами

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

На заключительном шаге тестирования системы сделаем отчет по проделанным работам для сотрудника, которому поручались задачки на создание обозначенных ресурсов. Введем период, в границах которого данные работы проводились и нажмем клавишу «Сформировать отчет». Итог представлен на рисунке 3.15:

Рис. 3.15. Сформированный отчет

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

Выводы по главе

3-я глава дипломной работы посвящена разработке системы учета работ по созданию электрических образовательных ресурсов. Для разработки системы выбрана программка 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.
Издержки на оплату машинного времени

Издержки на оплату машинного времени (Зомв
) зависят от времени работы на ЭВМ (Тэвм
), себестоимости машино-часа работы ЭВМ (Смч
) и содержат в себе амортизацию ЭВМ и оборудования, Издержки на электроэнергию. Стоимость 1-го машинного часа работы равна:

Смч
=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 руб.

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

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

Стоимость обучения персонала организации.
Расчет делается по последующей формуле:

,

где — численность персонала на обучение ,

— стоимость обучения 1-го человека в денек,

— время обучения.

Предполагается, что в организации системой будет воспользоваться три сотрудника. время нужное для обучения предположительно оценивается в два рабочих денька. Стоимость обучения 1-го человека в денек 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. Увеличения скорости и свойства выполняемой работы за счет строго определенных сроков, и с учетом количества ожидаемых заданий.

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

Любой сотрудник на выполнение 1-го задания обычно растрачивает на некоторое количество дней больше, потому что не постоянно имеет работы понижается. Используя АИС, сотрудник постоянно сумеет верно рассчитывать время и силы, нужные ему для полного, своевременного и высококачественного выполнения рабочего плана.

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

ЭУГ
= ЭГ
– Зтек
, где

ЭУГ
– условно годичная экономия,

ЭГ
– годичная экономия,

Зтек
– текущие Издержки опосля внедрения мероприятия (за год).

Зарплата сотрудника отдела составляет приблизительно 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. Автоматическая система учета работ по созданию электрических образовательных ресурсов была разработана на основании всех проделанных проектных работ, с учетом поставленных требований к системе.

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

4-ая глава была посвящена расчету экономической эффективности от внедрения проекта. Приобретенные результаты молвят о полной окупаемости проекта приблизительно за 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.
Пример отчета по электрическим учебным курсам, написанным создателями белгородского филиала МЭСИ

]]>