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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


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


дипломная работа Базы данных по анкетам детей, оставшихся без попечения родителей для ОГОУ Центра психолого-медико-социального сопровождения

Информация:

Тип работы: дипломная работа. Добавлен: 23.05.2012. Сдан: 2011. Страниц: 37. Уникальность по antiplagiat.ru: < 30%

Описание (план):


Содержание 

 

Введение
     Потоки  информации, циркулирующие в мире, который нас окружает, огромны. Во времени они имеют тенденцию  к увеличению. Поэтому в любой организации, как большой, так и маленькой, возникает проблема такой организации управления данными, которая обеспечила бы наиболее эффективную работу. Некоторые организации используют для этого шкафы с папками, но большинство предпочитают компьютеризированные способы – базы данных, позволяющие эффективно хранить, структурировать и систематизировать большие объемы данных. И уже сегодня без баз данных  невозможно представить работу большинства финансовых, промышленных, торговых и прочих организаций. Не будь баз данных, они бы просто захлебнулись в информационном потоке. 
     Существует  много  веских причин  перевода существующей информации на компьютерную основу. Сейчас стоимость хранения информации в файлах ЭВМ дешевле, чем на бумаге. Базы данных позволяют хранить, структурировать информацию и извлекать оптимальным для пользователя образом. Использование клиент/серверных технологий позволяют сберечь значительные средства, а главное и время для получения необходимой информации, а также упрощают доступ и ведение, поскольку они основываются на комплексной обработке данных и централизации их хранения. Кроме того ЭВМ позволяет хранить любые форматы данных текст, чертежи, данные в рукописной форме, фотографии, записи голоса и т.д.
     Для использования столь огромных объемов  хранимой информации, помимо развития системных устройств, средств передачи данных, памяти, необходимы средства обеспечения диалога человек-ЭВМ, которые позволяют пользователю вводить запросы, читать файлы, модифицировать хранимые данные, добавлять новые данные или принимать решения на основании хранимых данных.
     Целью данного дипломного проекта являлось создание базы данных по анкетам детей, оставшихся без попечения родителей для ОГОУ “Центра психолого-медико-социального сопровождения”.
     Реализация  данной задачи проводится в системе  программирования Delphi7.0, располагающей широкими возможностями по созданию приложений баз данных, необходимым набором драйверов для доступа к самым известным форматам баз данных, удобными и развитыми средствами для доступа к информации, расположенной как на локальном диске, так и на удаленном сервере, а также большим коллекцией визуальных компонент для построения отображаемых на экране окон, что необходимо для создания удобного интерфейса между пользователем и исполняемым кодом.
 

Глава 1. Описание предметной области объекта автоматизации

1.1. Постановка задачи

     База  данных предназначена для хранения информации о детях выпускниках, оставшихся без родительского попечения. Подразумевается, что эта информация может изменяться в течение всего периода адаптации и может быть затребована в любое время за период адаптации ребенка и даже после окончания его адаптации или участвовать в формировании статистических данных о назначенных выплатах или сведений о закреплении жилого помещения за любой временной промежуток. База данных носит характер фактографической информационной системы и должна выдавать однозначные сведения на поставленные запросы. Конечными пользователями базы данных являются работники центра психолого-медико-социального сопровождения, которые относятся к категории пользователей, не посвященных в вопросы ведения, администрирования баз данных и поддержании их в рабочем состоянии. Это накладывает определенные требования на разработку базы данных, при которой все методы доступа и некоторые функций администрирования не будут доступны обычным пользователям, но будут включены в администраторскую панель, которой будет управлять системный администратор организации.
     Информация  о детях поступает в организацию  в виде анкет. Анкета состоит из трех разделов.
     Первый раздел: учреждение (учреждение, адрес), регистрационная информация (дата заполнения, дата первичной регистрации, дата поступления в учреждение, дата завершения обучения/убытия из учреждения), сведения о выпускнике (ФИО, пол, дата рождения, гражданство, документ удостоверяющий личность (номер, серия), место рождения, этническое происхождение, приметы, особенности характера, медицинское заключение о состоянии здоровья, место нахождения до поступления в детское учреждение, учреждение в котором обучался, количество оконченных классов, место учебы/работы в настоящее время, место жительства в настоящее время), сведенья о родителях: мать (ФИО, дата рождения, гражданство, место нахождения/жительства), отец (ФИО, дата рождения, гражданство, место нахождения/жительства), несовершеннолетние и совершеннолетние родственники (ФИО, дата рождения, место нахождения/жительства), юридический статус выпускника (причины отсутствия родительского попечения, назначенные выплаты, сведенья о закреплении жилого помещения, сведенья о подаче документов для получения жилого помещения, дополнительная информация).
     Второй  раздел: постановка анкеты на учет (дата постановки на учет, фамилия сотрудника зарегистрировавшего анкету, информация о мерах предпринятых региональным оператором).
     Третий  раздел: снятие анкеты с учета (ФИО  выпускника, причины прекращения  учета сведений о выпускнике, дата прекращения учета, реквизиты документов устанавливающих основания прекращения учета, дополнительная информация).
     Также необходимо обеспечить программу следующими функциями:
        1) создать стандартный поиск по ФИО и расширенный поиск по следующим условиям (назначенные выплаты, сведенья о закреплении жилого помещения, сведенья о подаче документов для получения жилого помещения);
        2) экспорт выбранной анкеты из базы данных в приложение Excel;
        3) постановка/снятие созданной анкеты на учет;
        4) создание архива снятых с учета анкет;
        5) создание справочников, позволяющих ускорить заполнение анкеты;
        6) ведение истории изменения анкеты;
        7) создание администраторской панели для разграничения прав доступа к базе.

1.2. Описание предметной области задачи

1.2.1. История ОГОУ ЦПМСС

     “Центр психолого-медико-социального сопровождения” (ОГОУ ЦПМСС) является областным государственным образовательным учреждением для детей-сирот и детей, оставшихся без попечения родителей, имеющих проблемы в развитии, обучении, социальной адаптации. Учредителем и главным распорядителем средств областного бюджета Центра является министерство образования Иркутской области. Центр в своей деятельности руководствуется Конвенцией о правах ребенка, Законом Российской Федерации «Об образовании», «Типовым положением об образовательном учреждении для детей, нуждающихся в психолого-педагогической и медико-социальной помощи», утвержденным постановлением Правительства Российской Федерации № 867 от 31 июля 1998 г., Уставом.
     Центр является юридическим лицом, имеет собственное имущество, самостоятельный баланс, лицевые счета в финансовом органе Иркутской области, гербовую печать, иные печати и штампы, бланки со своим наименованием, логотип.

1.2.2. Направление деятельности ОГОУ ЦПМСС

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

     Виды  деятельности:
    комплексная диагностика уровня психического развития детей с проблемами в обучении и определение индивидуального образовательного маршрута (дети от рождения до 18 лет);
    индивидуально-ориентированная и групповая коррекционно-развивающая работа с детьми, нуждающимися в помощи (дети от 5 до 18 лет);
    централизованный региональный учет выпускников детских домов и школ-интернатов Иркутской области и их сопровождение (выпускники интернатных учреждений от 14 до 23 лет);
    осуществление индивидуальной педагогической, психологической, социальной, медицинской и юридической помощи детям (подростки в возрасте от 13 до 18 лет);
    оказание помощи специалистам образовательных учреждений по вопросам социализации детей-сирот и детей, оставшихся без попечения родителей (педагоги, психологи, социальные педагоги интернатных учреждений, учреждений НПО и СПО);
    консультирование родителей (лиц, их заменяющих) по выбору образовательного маршрута.

1.2.3. Структура ОГОУ ЦПМСС

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

1.2.4. Описание компьютерной сети

     В организации имеется локальная  сеть. Назначение сети заключается в предоставлении доступа к периферийным устройствам, облегчения обмена файлами между участниками сети и общего доступа в интернет с помощью сервера учреждения.
     В состав сети входит 21 рабочая станция. Физический уровень представлен следующими компонентами сети: сетевой интерфейс - сетевая карта, сетевая среда передачи данных - UTP неэкранированная витая пара, узловые элементы - свич, топология соединения – «звезда-шина»   (см. рис. 1), скорость соединения - 100 Мбит/с.

     Рисунок 1. Схема соединения «звезда-шина»
     Соединение  осуществляется по протоколу TCP/IP. Диапазон IP адресов используемых в сети: от 192.168.0.1 до 192.168.0.255. Сеть одноранговая, в которой все компьютеры имеют равные права, каждый из которых имеет установленную операционную систему платформы Microsoft Windows XP Professional. Пользователь компьютера самостоятельно решает вопрос о предоставлении доступа к своим ресурсам другим пользователям сети. Все компьютеры входят в рабочую группу workgroup. Имеется доступ в интернет по технологии ADSL, организованный через proxy сервер.

1.2.5. Декомпозиция бизнес-процессов

      Прежде, чем создавать информационную систему  необходимо понять и описать бизнес-логику предметной области в выбранных границах. Обследование осуществляется путем проведения цикла интервью со специалистами предметных областей, изучения документации и других материалов строится функциональная модель предметной области.
      На  начальных этапах создания информационной системы необходимо понять, как работает организация, деятельность, которой собираемся автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания информационной системы. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что твориться на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватно предметной области, следовательно она должна содержать в себе знания всех участников бизнес-процессов организации.
      Наиболее  удобным языком моделирования бизнес-процессов  является   IDEF0, предложенный более 20 лет назад Дугласом Россом и называвшийся первоначально SADT – Structured Analysis and Design Technique. В IDEF0 системе представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
      Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые вопросы.
      Моделируемая  система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем рассматривать его как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что преобразовывается или используется системой), выход (результат деятельности системы), управление (стратегия и процедуры, под управлением которых производиться работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением система преобразует входы в выходы, использую механизмы.
      Процесс моделирования какой-либо системы  в IDEF0 начинается с определения контекста, то есть  наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
      Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами нужно определить, что в дальнейшем будет рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы существенно влияет позиция, с которой рассматривается система, и цель моделирования – вопросы, на которые построенная модель должна дать ответ. То есть первоначально необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. При формулировании области необходимо учитывать два компонента – широту и глубину. Широта подразумевает определение границ модели – определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. После определения границ модели предполагается, что новые объекты не должны вносится в моделируемую систему; поскольку все объекты взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом.
     При построении модели необходимо четко  определить границы системы. Отделенная от окружающей среды система с  этой средой называется контекстом системы. Контекст системы изображается в виде «черного ящика», имеющего входы и выходы, которые отображают взаимодействие с окружающей средой. Каждая из стрелок имеет свое название и назначение.
     Стрелка слева Вход отображает необходимые для исполнения процесса входы (например, документы, инструменты, необходимые для осуществления процессов системы)
     Стрелка справа Выход отображает результаты исполнения процесса.
      Стрелки сверху Управление отображает объекты, диктующие правила исполнения процесса. Это могут быть должностные инструкции, законы, положения.
      Стрелка снизу Механизм отображает, с помощью чего и кого выполняется процесс, то есть механизмы – это те объекты, которые собственно и исполняют данный процесс. Например: оператор, рабочий, автоматизированная система предприятия и т.п.
Построение  контекста системы
     А-0: Контекстная диаграмма процесса. Основная схема, представляющая деятельность всей организации (см. рис. 2).

Рисунок 2. Основная схема, представляющая деятельность всей организации
     Входными  данными являются: школьники, нуждающиеся  в помощи, практиканты без опыта  работы, дети сироты.
     Выходными данными являются: адаптированные школьники, адаптированные сироты, опытные практиканты.
     Механизмами являются: инвентарь центра, персонал, программное обеспечение.
     Управляющие воздействие оказывают: учебный  план, документы, правила по технике  безопасности.
     Далее рассмотрим систему, более подробно проведя декомпозицию бизнес процессов.
     Построение  схемы декомпозиции системы
     А0: ОГОУ «ЦПМСС» включает в себя следующие виды деятельности: организация учебного процесса, учебный процесс, административная деятельность, деятельность профсоюза, деятельность педагогического коллектива, деятельность обслуживающего отдела (см. рис. 3).

Рисунок 3. Схема декомпозиции системы
Организация учебного процесса состоит
     Входные данные: принятые (профсоюзом) права  и обязанности.
     Выходные  данные: расписание занятий.
     Механизмами являются: персонал (директор и его заместители), вспомогательное техническое оборудование, программное обеспечение.
     Управляющее воздействие оказывает: учебный  план.
Учебный процесс состоит
     Входные данные: дети сироты, школьники, нуждающиеся в помощи, практиканты без опыта работы.
     Выходные  данные: адаптированные школьники, адаптированные сироты, практиканты с опытом работы.
     Механизмами являются: персонал (учителя, психологи, психиатры, дефектологи, логопеды, социальные педагоги), инвентарь центра, программное обеспечение.
     Управляющее воздействие оказывает: расписание занятий, документы (правила внутреннего распорядка).
Административная деятельность состоит
     Входные данные: отчеты деятельности (учебного процесса), отчеты по АХЧ.
     Выходные  данные: договор.
     Механизмами являются: персонал (директор, заместители директора), программное обеспечение.
     Управляющее воздействие оказывает: документы (закон об образовании РФ, программа для общеобразовательных школ).
Деятельность  профсоюза состоит
     Входные данные: договор, предложения (по проведению мероприятий)
     Выходные  данные: принятые предложения
     Механизмами являются: персонал
     Управляющее воздействие оказывает: документы
Деятельность  педагогического коллектива состоит
     Входные данные: принятые предложения, практиканты  без опыта работы.
     Выходные  данные: план уборки, предложения (по проведению мероприятий).
     Механизмами являются: персонал, программное обеспечение.
     Управляющее воздействие оказывает: документы (программа для ОГОУ «Центр ПМСС»).
Деятельность обслуживающего отдела состоит
     Входные данные: план уборки.
     Выходные  данные: отчет по АХЧ.
     Механизмами являются: персонал (зам. директора по АХЧ, тех. персонал), инвентарь центра.
     Управляющее воздействие оказывает: документы (должностные  инструкции), правила по технике  безопасности.

1.2.6. Построение объектной модели задачи

     При проведении различных этапов, связанных  с проектированием, используют различные CASE-средства (сокращение от Computer Aided Software Engineering), которые позволяют автоматизировать процесс разработки информационных систем на протяжении всего жизненного цикла (жизненный цикл системы – непрерывный процесс, который начинается с момента решения о необходимости ее создания и заканчивается в момент полного изъятия системы из эксплуатации).
     Для разработки объектной модели рекомендуется  использовать одно из наиболее развитых в настоящее время CASE-средств – пакет объектного моделирования Rational Rose, предназначенный для построения объектной модели предметной области задачи.
     Унифицированный язык моделирования (Unified Modelling Language, UML) позволяет создавать несколько типов визуальных диаграмм. Rational Rose поддерживает разработку большинства этих моделей, а именно:
    диаграммы сценариев (Use Case);
    диаграммы классов (Classes);
    диаграммы последовательности (Sequence) и другие.
     Вначале определяются действия (функции) и действующие  лица задачи. Полученные диаграммы Use Case можно показать будущим пользователям. Затем эти диаграммы могут уточняться.
     Диаграммы сценариев позволяют отобразить, описать и документировать желаемое поведение системы с точки зрения взаимодействия с ней внешних объектов (действующих лиц). Сценарием также можно назвать какой-либо набор логически связанных между собой действий, приводящих к какому-то «логическому состоянию» системы. То есть это описание того, какие случаи, ситуации обрабатывает ваше приложение, какие реально действующие лица взаимодействуют с системой (см. рис. 4).

     Рисунок 4. Диаграмма вариантов использования
     Диаграммы классов отображают статическую  структуру классов. Классами могут быть сущности, которые впоследствии отображаются в таблицы базы данных (см. приложение 2), и элементы интерфейса - формы будущего приложения (см. приложение 3).
     На  диаграмме взаимодействия отображают один из процессов обработки информации в функции. Таких диаграмм для  каждой функции может быть несколько. Диаграммы взаимодействия визуализируют объекты и сообщения (с помощью сообщений один объект запрашивает у другого выполнения конкретной функции). Рассмотрим один из видов диаграмм взаимодействия – диаграммы последовательностей (Sequence).
     Традиционно диаграммы последовательностей  отображают типы объектов, взаимодействующих в сценариях, сообщения, которые они посылают друг другу. Объекты (экземпляры классов) в UML отображаются подчеркнутыми, чтобы отличить их от классов. Основная идея – это то, что диаграмма последовательности показывает «прохождение» логики выполнения в сценарии, позволяя документировать проект приложения. Прямоугольники на вертикальных линиях показывают «время жизни» объекта. Линии со стрелками и надписями названий методов означают вызов метода объекта (см. рис. 5).

Рисунок 5. Диаграмма последовательности администрирования
     Таким же образом строятся диаграммы последовательности для функций (см. рис. 6-9):
    операций с анкетами;
    поиск анкет в БД;
    экспорт анкеты в Excel;
    заполнения справочников.

      Рисунок 6. Диаграмма последовательности операций с анкетами

      Рисунок 7. Диаграмма последовательности поиск анкет в БД

      Рисунок 8. Диаграмма последовательности экспорт анкеты в Excel

Рисунок 9. Диаграмма последовательности заполнения справочников

Глава 2. Проектирование базы данных и реализация приложения

  2.1. Программные средства, используемые 

  при реализации проекта

     При создании данного проекта использовались следующие программные средства:
    Rational Rose
    ERWin Data Modeler;
    IBExpert;
    Delphi 7.0.
     Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.
     В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах :
    Use case diagram (диаграммы прецедентов);
    Deployment diagram (диаграммы топологии);
    Statechart diagram (диаграммы состояний);
    Activity diagram (диаграммы активности);
    Interaction diagram (диаграммы взаимодействия);
    Sequence diagram (диаграммы последовательностей действий);
    Collaboration diagram (диаграммы сотрудничества);
    Class diagram (диаграммы классов);
    Component diagram (диаграммы компонент).
     ERwin Data Modeler - программный продукт в области реализации средств CASE-технологий.  Появился этот продукт где-то в середине 1990-х. Позволяет проводить описание, анализ и моделирование модели данных - построитель мета-моделей данных. Занимает одно из лидирующих мест в своём сегменте рынка. В настоящее время выпускается компанией Computer Associates.
     IBExpert - GUI-оболочка, предназначенная для разработки и администрирования баз данных InterBase и Firebird, т.е. реляционная система управления базами данных.
     Основные достоинства IBExpert:
    поддержка InterBase версий 4.х, 5.х, 6.х, 7.х; Firebird 1.х, 2.x; Yaffil 1.х;
    работа одновременно с несколькими базами данных;
    отдельные редакторы для всех объектов БД с синтаксической подсветкой;
    мощный SQL редактор с историей запросов и возможностью фонового выполнения запросов;
    отладчик хранимых процедур и триггеров;
    поиск в метаданных;
    полное и частичное извлечение данных и метаданных;
    анализатор зависимостей объектов баз данных;
    отчеты по метаданным;
    менеджеры пользователей и пользовательских привилегий;
    экспорт данных в различные форматы.
     IBExpert обладает множеством облегчающих  работу компонентов: визуальный редактор для всех объектов базы данных, редактор SQL и исполнитель скриптов, отладчик для хранимых процедур и триггеров, построитель области, собственный скриптовый язык, а также дизайнер баз данных и т. д.
     Borland Delphi 7 - это интегрированная, объектно-ориентированная среда разработки приложений, значительно повышающая скорость создания дружественного интерфейса, удобного и понятного пользователю. В реальном мире разработчикам необходимо создавать приложения, которые работают на различных платформах, а не только самых последних и наиболее распространенных. Сейчас большинство новых машин поставляется с Windows Vista, в то время как существующие персональные компьютеры продолжают работать на Windows 2000, XP или 98. Разработчики должны поддерживать подобную «смешанную» среду, поскольку выпущенный программный продукт должен быть рассчитан на все группы пользователей системы.
     Основные  достоинства:
    содержит специализированные библиотеки, позволяющие достичь максимальной производительности при работе с InterBase благодаря прямому доступу к базе данных;
    компактность и скорость выполнения исходных кодов выше таких сред как C++ Builder, JBuilder 2005, VisualBasic и VisualFoxPro;
    скорость и удобство разработки интерфейса значительно превосходит любые аналогичные системы, что особенно важно при создании программ для ведения баз данных, так как они должны содержать множество разнообразных форм для отображения, добавления и редактирования записей базы и формирования отчетов;
    позволяет в минимальные сроки вносить изменения и производить доработку программных продуктов;
    поддерживает эффективную работу как в современных версиях Windows 7, Vista, 2000, XP, так и в Windows 98.

2.2. Базы данных

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

2.2.1. Классификация баз данных

     По  технологии обработки данных базы данных подразделяются на централизованные и  распределенные.
     Централизованная  база данных хранится в памяти одной  вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК.
     Распределенная  база данных состоит из нескольких, возможно пересекающихся или даже дублирующих  друг друга частей, хранимых в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных (СУРБД).
     По  способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.
     Системы централизованных баз данных с сетевым  доступом предполагают различные архитектуры подобных систем.
     Файл-сервер. Архитектура систем БД с сетевым  доступом предполагает выделение одной  из машин сети в качестве центральной (сервер, файлов). На такой машине хранится совместно используемая централизованная БД. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользовательской системы к централизованной базе данных. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также на рабочих станциях локальные БД, которые используются ими монопольно.
     Клиент-сервер. В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных.
     Запрос  на данные, выдаваемый клиентом (рабочей  станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SOL. В данном дипломном проекте была использована эта архитектура.

2.2.2. Структурные элементы баз данных

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

2.3. Проектирование базы данных

     Проектирование  БД связанно с разрешением проблем представления данных между конечными пользователями. Они продиктованы различными потребностями и задачами лиц, которые используют эти данные. Пользователи могут быть выделены в отдельные группы. Каждая из групп воздействует на результаты проектирования в разных направлениях. Необходимо собрать информацию о реальных и потенциальных приложениях, а также о пользователях базы данных, чтобы устранить все противоречия ещё на начальном этапе, так как многолетний мировой опыт использования информационных систем, построенных на основе баз данных, показывает, что недостатки проекта допущенные на этапе проектирования невозможно устранить любыми ухищрениями в программах приложений.
     Проектирование  обычно поручается человеку – администратору базы данных. Им может быть как специально выделенный сотрудник, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.
     В основу проектирования БД должны быть положены представления конечных пользователей конкретной организации — концептуальные требования к системе. Именно конечный пользователь в своей работе принимает решения с учетом получаемой в результате доступа к базе данных информации. От оперативности и качества этой информации будет зависеть эффективность работы организации. Данные, помещаемые в базу данных, также предоставляет конечный пользователь. Кроме того, БД должна предоставлять доступ к данным пользователям, которые практически не имеют или не хотят иметь представления о физическом размещении в памяти данных и их описаний, о механизмах поиска запрашиваемых данных или о поддержании баз данных в актуальном состоянии.
     Прикладные  программисты хотели бы иметь в одном месте (например, в одной таблице) все данные, необходимые им для реализации запроса из прикладной программы или с терминала.
     Администратор баз данных заботятся об исключении возможных искажений хранимых данных при вводе в базу данных новой  информации и обновлении или удалении существующей. Для этого они удаляют  из базы данных дубликаты и нежелательные  функциональные связи между таблицами, разбивая базу данных на множество маленьких таблиц.
     Чтобы различать представления данных конечными пользователями, программистами и администраторам баз данных создаются разные уровни моделей  данных.
     Основное  различие между тремя типами моделей данных (концептуальной, логической и физической) состоит в способах представления взаимосвязей между объектами. При проектировании БД требуется различать взаимосвязи между объектами, между свойствами одного объекта и между свойствами различных объектов. Рассмотрим каждую из них более подробно.

2.3.1. Проектирование инфологической модели

     Рассмотрев  внешние модели задачи, переходят  к их объединению в единую информационно-логическую модель, называемую концептуальной.
     Одним из основополагающих принципов проектирования данных является нормализация, позволяющая существенно сократить объем хранимой информации и устраняющая аномалии в организации хранения данных.
     Результатом нормализации является модель данных, которую легко поддерживать, не содержащая неопределенностей в данных и повторений данных.
      Проектирование  инфологической (концептуальной) модели проведено с помощью метода «Сущность-связь».
      В данном методе рассматриваются объекты, имеющие экземпляры, обладающие набором  свойств - атрибутов. Объекты допускают однозначную идентификацию.
      Атрибут или набор атрибутов, однозначно идентифицирующий объект, называется ключом объекта.
      Между объектами существуют связи. В дальнейшем будут рассматриваться только бинарные связи.
      Каждая  связь характеризуется степенью связи, которая определяет, сколько экземпляров одного объекта связано с экземплярами другого объекта.
      В соответствии с этим определением существуют бинарные связи  степеней:
    1: 1 (каждый экземпляр одного объекта связан не более чем с одним экземпляром другого), обозначается <----->;
    1: N (каждый экземпляр одного объекта связан с несколькими экземплярами   другого, но каждый экземпляр второго объекта связан не более чем с одним экземпляром первого), обозначается <---->>;
    M: N (каждый экземпляр первого объекта связан с несколькими экземплярами второго и наоборот), обозначается <<---->>.
      При любой степени связи класс принадлежности каждого объекта может быть обязательным или необязательным.
      Класс принадлежности объекта является обязательным, если все экземпляры объекта участвуют  в связи, и необязательным в противном  случае.
      Будем записывать возможные варианты классов  принадлежности в виде
О-О, О-Н, Н-О, Н-Н.
      Указание  * вместо О или Н означает, что класс принадлежности    несущественен.
      Сочетание степени связи и класса принадлежности может быть любым и зависит  от условий функционирования предметной области.
      Проектирование  концептуальной модели состоит в  построении реляционных отношений  и их первичных ключей на основе анализа ER - диаграмм и применении следующих правил, учитывающих степень связи и класс принадлежности объектов:
        ПРАВИЛО 1. Если степень связи 1:1 и классы принадлежности О-О, то требуется только одно отношение, ключом которого может быть ключ любого объекта;
        ПРАВИЛО 2. Если степень связи 1:1 и классы принадлежности О-Н, то необходимо построение двух отношений. Каждому объекту соответствует одно отношение, при этом ключ объекта является ключом соответствующего отношения. Кроме того, ключ второго объекта добавляется в качестве атрибута в первое отношение;
        ПРАВИЛО 3. Если степень связи 1:1 и классы принадлежности Н-Н, то необходимо построение трех отношений: по одному на каждый объект, причем  ключи отношений совпадают с ключами объектов, и связующего отношения, ключом которого будет комбинация ключей объектов;
        ПРАВИЛО 4. Если степень связи 1:N и классы принадлежности *-О, то достаточным является использование двух отношений, соответствующих объектам, причем ключами будут ключи объектов, но дополнительно ключ первого объекта должен быть атрибутом второго отношения;
        ПРАВИЛО 5. Если степень связи 1:N и классы принадлежности *-Н, то необходимо построение трех отношений: по одному на каждый объект, причем ключи отношений совпадают с ключами объектов, и связующего отношения,  ключом которого будет комбинация ключей объектов;
        ПРАВИЛО 6. Если степень связи M:N, то необходимо построение трех  отношений: по одному на каждый объект, причем ключи отношений совпадают с ключами объектов, и связующего отношения, ключом которого будет комбинация ключей объектов.
      После этого все неключевые атрибуты распределяются по отношениям (см. приложение 4).

2.3.2. Проектирование логической и физической модели

     Проектирование  данных гораздо удобнее производить, используя современные средства проектирования баз данных, и в частности CASE-средства, так как с их помощью можно автоматизировать рутинную работу по созданию собственно объектов базы.
     Описание  информационной модели базы данных проведено  с использованием CASE-средства ERwin.
     Реализация  моделирования в ERwin базируется на теории реляционных баз данных и на методологии IDEF1X. Методология IDEF1X была разработана для ВВС США и теперь используется, в частности, в правительственных, аэрокосмических и финансовых учреждениях, а также в большом числе частных компаний.
     Методология IDEF1X определяет стандарты терминологии, используемой при информационном моделировании, и графического изображения типовых  элементов на диаграммах. Возможны две точки зрения на информационную модель и, соответственно, два уровня модели. Первый - логический (точка зрения пользователя) - описывает данные, задействованные в бизнесе предприятия. Второй - физический - определяет представление информации в БД. ERwin объединяет их в единую диаграмму, имеющую несколько уровней представления. Процесс построения информационной модели состоит из следующих шагов:
        1) определение сущностей; 
        2) определение зависимостей между сущностями;
        3) задание первичных  и альтернативных ключей;
        4) определение атрибутов сущностей.
     ERwin создает визуальное представление  (модель данных) для решаемой задачи.
     Это представление может использоваться для детального анализа, уточнения  и распространения как части  документации, необходимой в цикле  разработки.
     Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).
     В качестве системы управления БД выбран InterBase 6.5. Пакет Erwin преобразовал логическую модель БД в физическую модель для данной СУБД.
     При построении логической и физической модели (последняя привязана к  конкретной системе управления базами данных СУБД InterBase) введем в качестве первичного ключа, однозначно определяющего каждую запись сущности, поле id_X, где X – сокращение от названия сущности.
     Это упростит и ускорит поиск необходимой  информации, т.к. будут отсутствовать  составные ключи и данное поле принадлежит целому типу.
     Построение  логической и физической моделей проводилось с использованием CASE-средства ErWin (см. рис. 10-11).
      Отсутствие  связи таблицы use_acc с основной базой заключается в том, что в ней хранятся учетные записи пользователей приложения и используются только для доступа к самой программе.
      Это необходимо для предотвращения несанкционированного доступа к анкетам хранящихся на сервере организации, т.к. данная информация является конфиденциальной. 


      Рисунок 10. Логическая модель базы данных 


      Рисунок 11. Физическая модель базы данных

2.4. Описание серверной части клиент-серверного приложения

     При помощи CASE-средства ErWin сгенерирован SQL скрипт БД, (см. приложение 5).
     Для каждой таблицы было создано по одному генератору (generator), находящемуся в триггере (trigger), которые служат для генерации уникальных значений первичного ключа. Для этих целей использовалась утилита IBExpert (см. рис. 12).

Рисунок 12. Генератор первичного ключа, созданный  в IBExpert
     Триггер – это запоминающий элемент с двумя устойчивыми состояниями, изменение которых происходит под действием входных сигналов и предназначен для хранения одного бита информации.
     Генератор – это механизм для создания уникальных значений первичных ключей при добавлении строк к таблицам.
     Все остальные SQL запросы (хранимые процедуры, исключения и т.д.) реализованы в коде клиентского приложения. Это связанно с тем, чтобы исправлять ошибки, возникающие в ходе тестирования, не изменяя при этом саму базу, а только клиентское приложение.

2.5. Описание клиентской части

клиент-серверного приложения

     Клиентская  часть клиент-серверного приложения выполнена с использованием среды  визуального программирования Borland Delphi 7 (см. приложение 6).
     Структура получившего клиент-серверного приложения (см. рис. 13).

 

 
 
 

Рисунок 13. Структура клиент-серверного приложения
     Все не визуальные компоненты объединены в модуль данных «Data Module» (см. рис. 14).

Рисунок 14. Модуль данных с не визуальными компонентами
     При запуске системы на экране отображается форма авторизации пользователя (см. рис. 15).

Рисунок 15. Форма авторизации пользователей
     При успешной авторизации становится доступно главное окно приложения с меню (см. рис. 16), через которое доступны остальные формы спроектированного приложения (см. приложение 7) в соответствии с правами доступа, которые определяются именем пользователя и паролем.

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

2.6. Проектирование тестов и тестирование

     Тестирование – это процесс исполнения программы с целью обнаружения ошибок. Исходя из термина «тестирование» можно сделать вывод, что программа тестируется не для того, чтобы показать, что она работает, а наоборот тестирование начинается с того, что делается предположение, что в программе есть ошибки (это предположение справедливо практически для любой программы).
     Под тестированием понимается процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.
     Одним из способов изучения поставленного  вопроса является исследование метода тестирования:
     Метод «черного ящика», тестирование с управлением по данным или тестирование с управлением по входу – выходу. При использовании этой стратегии программа рассматривается как «черный ящик». Иными словами, такое тестирование имеет целью выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Тестовые же данные используются только в соответствии со спецификацией программы (т. е. без учета знаний о ее внутренней структуре). При таком подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если в качестве тестовых наборов использовать все возможные наборы входных данных. Если такое испытание представляется сложным, то еще сложнее создать исчерпывающий тест для большой программы. Построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами: во-первых, нельзя создать тест, гарантирующий наличие ошибок; во-вторых, разработка таких тестов противоречит экономическим требованиям. Поскольку исчерпывающее тестирование исключается, целью тестирующего должна стать максимизация числа ошибок, обнаруживаемых одним тестом. Для этого можно рассматривать внутреннюю структуру программы и делать достоверные предположения.
     Другим  способом тестирования является метод  «белого ящика», управляемого логикой программы. Данный способ позволяет исследовать внутреннюю структуру программы. В этом случае тестирующий получает тестовые данные путем анализа логики программы (к сожалению, здесь часто не используется спецификация программы). Сравним способ построения тестов при данном методе с исчерпывающим входным тестированием стратегии «черного ящика». Не  знающему может показаться, что достаточно построить такой набор тестов, в котором каждый оператор выполняется хотя бы один раз, но это предположение ошибочно. Не вдаваясь в детали, укажем лишь, что исчерпывающему входному тестированию может быть поставлено в соответствие исчерпывающее тестирование маршрутов. Подразумевается, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам ее потока передач управления.
     Последнее утверждение имеет два слабых пункта. Первый из них состоит в  том, что число не повторяющих  друг друга маршрутов в программе  очень велико. Второй слабый пункт  утверждения заключается в том, что, хотя исчерпывающее тестирование маршрутов является полным тестом, и хотя каждый маршрут программы может быть проверен, сама программа будет содержать ошибки. Это объясняется следующим образом:
        Во-первых, исчерпывающее  тестирование маршрутов не может дать гарантии того, что программа соответствует описанию. Например, вместо требуемой программы сортировки по возрастанию случайно была написана сортировка по убыванию. В этом случае ценность тестирования маршрутов невелика, поскольку после тестирования в программе окажется одна ошибка, т. е. программа неверна.
        Во-вторых, программа  может быть неверной в силу того, что пропущены некоторые маршруты. Исчерпывающее тестирование маршрутов  не обнаружит их отсутствия.
        В-третьих, исчерпывающее  тестирование маршрутов не может обнаружить ошибок, появление которых зависит от обрабатываемых данных.
     Кроме вышеперечисленных методов тестирования существуют также следующие:
    монолитный метод (или метод большого удара);
    метод пошагового тестирования;
    метод восходящего тестирования;
    метод нисходящего тестирования;
    метод большого скачка;
    метод сандвича;
    модифицированный метод сандвича.
     Монолитный  метод – каждый модуль тестируется отдельно, а затем их комбинируют и формируют рабочую программу.
     Метод пошагового тестирования – модули тестируются не отдельно друг от друга, а подключаются поочередно для выполнения теста к набору уже ранее оттестированных модулей. Пошаговый процесс продолжается до тех пор, пока к набору оттестированных модулей не будет подключен последний модуль.
     Монолитный  метод и метод пошагового тестирования являются подходами к комбинированию модулей. Рассмотрим особенности этих методов:
      монолитное тестирование требует больших затрат труда. При пошаговом же тестировании «снизу-вверх» затраты труда сокращаются;
      расход машинного времени при монолитном тестировании меньше;
      использование монолитного метода предоставляет большие возможности для параллельной организации работы на начальной фазе тестирования (тестирования всех модулей одновременно). Это положение может иметь важное значение при выполнении больших проектов, поскольку численность персонала, участвующего в проекте, максимальна на начальной стадии;
      при пошаговом тестировании раньше обнаруживаются ошибки в интерфейсах между модулями, поскольку раньше начинается сборка программы. В противоположность этому при монолитном тестировании модули «не видят друг друга» до последней фазы процесса тестирования;
      отладка программ при пошаговом тестировании легче. Если есть ошибки в межмодульных интерфейсах, а обычно так и бывает, то при монолитном тестировании они могут быть обнаружены лишь тогда, когда собрана вся программа. В этот момент локализовать ошибку довольно трудно, поскольку она может находиться в любом месте программы. Напротив, при пошаговом тестировании ошибки такого типа в основном связаны с тем модулем, который подключается последним;
      результаты пошагового тестирования более совершенны.
     По  вышеперечисленным пунктам напрашивается  вывод, что пошаговое тестирование является наиболее предпочтительным из этих двух методов.
     Далее исследуем две возможные стратегии  тестирования: нисходящее и восходящее.
     При «восходящем тестировании» программа собирается и тестируется «снизу - вверх».
     Только  модули самого нижнего уровня тестируются  изолированно, автономно.
     Затем тестируются модули более высокого уровня вместе с уже проверенными модулями более низкого уровня. Процесс продолжается до тех пор, пока не буде достигнута вершина.
     «Нисходящий метод» имеет как достоинства, так и недостатки по сравнению с «восходящим». Самое значительное достоинство – то, что этот метод совмещает тестирование модуля, тестирование сопряжений и частично тестирование внешних функций. С этим же связано и другое его достоинство: когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде. Нисходящий подход выгоден также в том случае, когда есть сомнения осуществимости программы в целом или когда в проекте программы могут оказаться серьезные дефекты. Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах; вместо драйверов просто следует написать «заглушки». Нисходящий метод тестирования имеет некоторые недостатки. Основным из них является то, что модуль редко тестируется досконально сразу после его подключения. Второй недостаток состоит в том, что данный подход может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. При использовании метода «большого скачка» каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу (имеет много недостатков).
     Тестирование  методом «сандвича» представляет собой компромисс между восходящим и нисходящим тестированием. Тестирование начинается одновременно сверху и снизу. Точка встречи зависит от конкретной тестируемой программы и должна быть заранее определена при изучении ее структуры.
     В данном дипломном проекте приводится тестирование системы по методу «черного» и «белого ящика».
      Тестированию  подверглись все хранимые процедуры через соответствующие функции клиентского приложения (некорректный ввод, повторяющиеся поля и др.). Также проведена проверка правильности формирования всех выходных документов. Особой проверке подлежал контроль за доступностью некоторых пунктов меню и операций над данными, хранящимися в таблицах.
      Тестирование  на доступность пунктов  меню:
        1) администратору доступны все пункты меню, включая таблицу пользователей;
        2) сотрудник, заполняющий БД может вводить данные из анкет детей, доступно изменение «Справочников», «Анкет», получение выходных документов. Так же доступна постановка и снятие анкеты с учета;
        3) сотрудникам ОГОУ «ЦПМСС» доступно получение выходных документов, поиск анкет в БД, просмотр анкет.
      Тестирование  на ввод записей, уже имеющейся в таблице БД
      Если  в таблицу вводится запись, в которой  поля повторяются с уже имеющимися (например, вводится в таблице «Гражданство»  одно и то же наименование), то выдается сообщение об ошибке.
      Тестирование  на правильность выходных документов
      Данные  всех выходных документов должны соответствовать действительности. По результатам тестирования можно сказать, что они совпали с ожидаемыми.
      Проведенное тестирование показывает, что разработанная  система соответствует тем требованиям, которые были предъявлены к ней  в постановке задачи.
 

Глава 3. Организационно-экономическая  часть

3.1. Оценка затрат  на разработку  АС

      Оценка  затрат на разработку АС предполагает выполнение следующих шагов:
    оценка размера проекта, этапов работы, выявление необходимых ресурсов для каждого этапа;
    составление таблицы, в которой указывается для каждой работы графика ее продолжительность и требуемы ресурсы;
    составление календарного графика в виде сетевой модели (для крупных проектов) или графика Ганнта (для небольших проектов);
    оценка стоимости проекта.
     В определении ресурсов наиболее сложным  является определение затрат труда. Общей практикой оценки трудозатрат  является экспертные оценки исполнителей с выделением резервов от 30 до 50%.
     В стоимость программного продукта включаются все затраты, связанные с выполнением работы, независимо от источников финансирования:
    материальные затраты;
    основная заработная плата;
    дополнительная заработная плата;
    страховые взносы;
    затраты на электроэнергию;
    затраты на эксплуатацию и обслуживание средств ВТ;
    амортизационные отчисления;
    накладные расходы.
     Основные  виды работ, выполнение которых необходимо для разработки данного программного продукта (см. таблица 1).
     График  Ганнта для планирования работ (см. приложение 8).
 

     
     Таблица 1.
Календарный график
Содержание  этапа Квалификация  исполнителя Кол-во исполнителей Длит-сть работы (в  днях)
Трудо-сть этапа (чел./днях) Используемое  оборудование и ПО Машинное  время
1. Изучение литературы Информатик-экономист 1 12 12   15
2. Декомпозиция бизнес-процессов Информатик-экономист 1 4 4 BPWin 7.1, Windows XP 10
3. Построение объектной модели  задачи Информатик-экономист 1 8 8 Rational Rose 2000, Windows XP 16
4. Проектирование концептуальной  модели Информатик-экономист 1 3 3 MS Word, Windows XP 8
5. Выбор средств программирования и установка ПО Информатик-экономист 1 1 1 Windows XP 3
6. Создание логической модели данных Информатик-экономист 1 2 2 ERWin 4.1, Windows XP 5
7. Создание физической модели данных Информатик-экономист 1 1 1 ERWin4.1, Windows XP 3
8. Создание серверной части приложения Информатик-экономист 1 11 11 IBExpert, InterBase 6.5, Windows XP 36
9. Разработка клиентской части  приложения Информатик-экономист 1 15 15 Delphi 7.0, Windows XP professional 60
10. Описание форм и выходных документов Информатик-экономист 1 1 1 Delphi 7.0, MS Word, Windows XP 2
11. Проведение тестов и их описание Информатик-экономист 1 7 7 Delphi 7.0, MS Word, Windows XP 24
12. Расчет экономической части Информатик-экономист 1 3 3 MS Excel, MS Word, MS Visio, Windows XP 6
13. Оформление дипломного проекта Информатик-экономист 1 14 14 MS Word, Windows XP 26
Итого:     82 82   214
 


3.1.1. Материальные затраты

     К материальным затратам относятся различные  расходные материалы (см. таблица 2).
       Таблица 2.
Материальные  затраты
Виды  затрат Кол-во Ед. изм. Стоимость ед. Общая стоимость руб.
Бумага (A4) 1 пачка 250,00 250,00
Диск CD-R 1 шт. 10,00 10,00
Заправка  картриджа принтера 1 шт. 230,00 230,00
Итого:       490,00

3.1.2. Затраты на оплату труда

      В этой статье затрат учитывается оплата труда всех участников проекта, являющихся непосредственными исполнителями работ, включенных в график проекта.
      Исходя  из данных графика Ганнта рассчитаем основную заработную плату:
Осн.зп = Дн_ст * От.вр.,
где
     От.вр - отработанное время (кал. дни);
       Дн_ст - дневная ставка (руб.).
     Осн.зп=168,92*70
     Осн.зп=11824,40
     Дневная ставка берется из расчета:
     Дн_ст = Зар.пл_мес. / Ч_раб.дней,
где 
     Зар.пл_мес - месячная заработная плата исполнителя;
     Ч_раб.дней - число календарных дней в месяце, равное 29,6.
     Дн_ст =5000,00/29,6
     Дн_ст =168,92

3.1.3. Дополнительная заработная плата

     Учитываются выплаты, предусмотренные законодательством  за непроработанное (неявочное) время: оплата очередных и дополнительных отпусков, перерывов, сборов, оплата времени, связанного с выполнением государственных и общественных обязанностей, выплаты вознаграждений за выслугу лет и другие.
Доп.зп = Осн.зп * К_доп,
где
     К_доп = 12-15 %  -  коэффициент дополнительной заработной платы.
       Доп.зп = 11824,40*0,12
       Доп.зп = 1418,93
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.