Размещено на http://www.allbest.ru/

58

Оглавление

Введение 3

1. Разработка требований к програмному обеспечению 6

1.1 Анализ решений по автоматизации предметной области 6

1.2 Анализ предметной области 9

1.3 Выбор методологии проектирования информационной системы 13

1.4 Спецификация требований 16

1.5 Аттестация требований 17

Выводы к разделу 20

2. Проектирование информационной системы 21

2.1 Архитектурное проектирование 21

2.2 Проектирование интерфейса информационной системы 24

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

2.4 Обоснование выбора платформы создания информационной системы 29

2.5 Проектирование модулей 30

Выводы к разделу 35

3. Реализация и аттестация информационной системы 36

3.1 Реализация приложения 36

3.2 Взаимодействие приложения с источниками данных 38

3.3 Тестирование приложения 40

3.4 Методика развертывания приложения 41

Выводы к разделу 42

4. Управление информационным проектом 43

4.1 Выбор жизненного цикла разработки 43

4.2 Определение цели и области действия программного проекта 46

4.3 Создание структуры пооперационного перечня работ 47

Список сокращений 50

Список литературы 51

Приложение А. Спецификация требований к программному обеспечению 54

Приложение Б. Прототиты пользовательского програмного интерфейса 59

Приложение В - Атрибуты управляющих таблиц проектируемой подсистемы ЛИС 60

Приложение Г - DDL сценарий создания объектов базы данных 62

Приложение Д - Тексты программ 75

Приложение Е - ОБОСНОВАНИЕ МОДЕЛИ ВЫБОРА ЖИЗНЕННОГО ЦИКЛА 82

Введение

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

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

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

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

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

Целью настоящего дипломного проекта является разработка и внедрение информационной системы по автоматизации риэлтерской деятельности фирмы МУП «Недвижимость» города Невинномысска.

Для достижения вышеуказанной цели необходимо решить следующие задачи:

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

- осуществить бизнес-моделирование процессов фирмы;

- провести анализ требований к системе и ее проектирование;

- реализовать базу данных и серверную часть информационной системы;

- реализовать информационную систему, удовлетворяющую требованиям заказчика;

- провести оценку эффективности технологии разработки.

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

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

1. Разработка требований к программному обеспечению

1.1 Анализ решений по автоматизации предметной области

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

ѕ приватизация жилья;

ѕ срочная приватизация;

ѕ все операции на вторичном рынке жилья: покупка, продажа, дарение, наследство (по доверенности);

ѕ жилищные сертификаты;

ѕ обмены муниципального жилья и жилья на праве собственности;

ѕ оформление документов в земельном комитете для всех сделок с землей (частные дома, гаражи, дачи);

ѕ подбор вариантов на куплю-продажу и обмен недвижимости;

ѕ сдача жилья в аренду.

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

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

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

Таблица 1.1 - Сравнительная стоимость программного обеспечения

Название программы	Цена	Описание
РентЭксперт	4500 руб	http://www.arent.ru/rentexpert/
Идеальный вариант: недвижимость	от $160 на одно рабочее место	http://idealvariant.com.ua/index.html
WinМаклер	$198	http://wmakler.chat.ru/
Сталкер	Тестовый вариант бесплатно	http://www.malushevsky.ru/prog/download.php
RealtyX	нет информации	http://www.realtyx.ru/

В таблице 1.2 приведено сравнение наиболее популярных информационных систем для риэлтора.

Таблица 1.2 - Сравнение риэлтерских информационных систем

	WinМАКЛЕР	Агентство недвижимости	Система HOUSE 4	АИС «Недвижимость»	Система «УАН»	«Идеальный вариант»
Возможность привязки объектов к карте пунктов и районам	+	-	+	-	-	+
Возможность автоматической публикации заявок в Интернете	+	+	+	+	+	+
Настраиваемый многооконный интерфейс	-	-	+	-	-	-
Безопасность Разграничение прав пользователей на операции для каждого типа недвижимости	-	+	+	-	-	+
Комплексное описание объектов имущества	+	+	+	+	+	+
Интеграция с различными бизнес-приложениями и офисными системами	-	-	-	+	+	-
При вводе нового объекта в базу данных происходит автоматическая проверка на дубликаты.	+	-	+	-	-	-
Возможность формирования статистических и аналитических выборок для анализа состава базы и активности отдельных агентов и диспетчеров	-	-	-	+	+	-

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

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

2. Постановка каждой квартиры на рекламу в один или несколько источников: «Из рук в руки», «ЭН-СК», Интернет-сайт и др. Автоматический учет и снятие квартир с рекламы по сроку.

3. Автоматическое формирование файлов рассылки для разных источников в требуемых форматах.

4. Выборка по любому набору условий квартир из внутренней базы данных.

5. При организации схемы работы агентства с диспетчерским телефоном и локальной АТС выдается разнообразная статистика:

– -хронология телефонных звонков по каждой рекламируемой квартире;

– -эффективность того или иного источника рекламы;

– -распределение использованных рекламных ресурсов агентами и группами.

6. Выдача разнообразной управленческой информации для руководства и менеджерского звена.

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

Определены основные функциональные характеристики и возможности подобных ИС. Стало понятно: какие функции должна поддерживать создаваемая ИС.

В результате анализа интерфейсов существующих ИС будет затрачено меньше времени и усилий, чтобы разработать собственный интерфейс ИС.

В результате анализа рынка программных средств определен диапазон стоимости ИС для риэлторов. В результате чего стало понятным сколько примерно должна стоить будущая ИС и на какие стоимостные затраты (себестоимость) нужно рассчитывать.

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

Информационная система разрабатывается для Муниципального унитарного предприятия «Недвижимость». Учредителем Предприятия от имени города Невинномысска является комитет по управлению муниципальным имуществом администрации города Невинномысска. Почтовый адрес Учредителя: 357100, Россия, Ставропольский край, г. Невинномысск, ул. Гагарина, 74 А.

Предприятие находится в оперативном подчинении первого заместителя главы города Невинномысска.

На рис. 1.1 представлена диаграмма основных категорий сотрудников предприятия. В данном проекте основной интерес представляет анализ деятельности участка по приватизации, продаже и оценке недвижимости (УППОН).



Рисунок 1.1 - Диаграмма основных категорий сотрудников МУП «Недвижимость»

Основные направления деятельности предприятия представлены на рис. 1.2.

Рисунок 1.2 - Направления деятельности предприятия

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

В соответствии с учредительными документами предприятия МУП «Недвижимость» осуществляет следующие виды деятельности:

– выполнение работ по приватизации жилья на основании Закона РФ «О приватизации жилищного фонда в Российской Федерации» от 04.06.91. № 1541-1;

– выполнение консультационных услуг по вопросам регистрации прав на недвижимое имущество и сделок с ним в соответствии с законодательством РФ;

– оказание риэлтерских услуг: по подготовке документов на куплю - продажу недвижимости, обмен, дарение, аренду;

– оценочную деятельность;

– на выполнение работ по изготовлению технической документации

– подготовку проектно-сметной документации на объекты недвижимости.

В соответствии с этими направлениями были предметно рассмотрены работы по осуществлению каждого из указанных видов деятельности. На диаграммах бизнес-вариантов использования представлены основные направления деятельности сотрудников участка по приватизации, продаже и оценке недвижимости УППОН (рис. 1.3-1.5)].



Рисунок 1.3 - Бизнес-варианты использования по оценке стоимости помещения

Рисунок 1.4 - Бизнес-варианты использования по приватизации жилья



Рисунок 1.5 - Бизнес-варианты использования по купле продаже

1.3 Выбор методологии проектирования информационной системы

Сбор требований - это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований [2, 6, 7].

На этапе формирования и анализа требований в соответствии с технологией разработки программного обеспечения Microsoft Solution Framework (MSF):

- осуществляется сбор требований;

- составляются профили заинтересованных лиц;

- разрабатываются варианты использования.

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

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

Основными требованиями к ИС для предприятия МУП «Недвижимость» являются следующие:

- система должна обеспечивать защиту информационной базы данных от несанкционированного доступа;

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

- система должна иметь возможность наращивания в программной части.

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

– какова предметная область работы ИС;

– каковы способы накопления информации;

– кто является пользователем системы и каковы виды принимаемых ими решений.

Предметная область разрабатываемой ИС является рынок недвижимости. На рынке недвижимости происходят операции купли, продажи, инвестирования (например, долевое строительство) и обмена объектов и групп объектов, откуда можно сделать вывод, что во всех операциях фигурируют объекты недвижимости и финансовые средства. Для принятия решений: необходима полная информация об актуальных предложениях, ранее проданных объектах недвижимости, объектах, продажей которых занимается предприятие в данный момент, а также детальное, предельно формализованное описание каждого объекта.

Успешное функционирование ИС подразумевает накопление и анализ максимально большого объёма информации, что требует поступления данных в систему из как можно большего числа источников. Наиболее полным регулярно обновляемым источником информации об актуальных предложениях на рынке недвижимости являются текстовые объявления, публикуемые в специализированных газетах. Таким образом, возникает: задача анализа данных, изначально существующих в виде неформализованных текстовых объявлений на русском языке. Тем не менее, часть данных может поступать в формализованном виде в процессе ручного ввода информации или путем импорта данных из других информационных систем (например, из баз данных строительных организаций, продающих новое жильё).

Пользователями рассматриваемой ИС являются сотрудники риэлторского предприятия, осуществляющие маркетинг объектов недвижимости. Персонал, использующий ИС, может быть разделен на несколько групп:

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

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

– эксперты, осуществляющие анализ текущего состояния, проведение сегментации рынка недвижимости и настройку подсистемы оценки объектов недвижимости.

– эксперты, осуществляющие настройку вспомогательных данных системы.

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

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

1.4 Спецификация требований

Спецификация требований (Software Requirements Specification, SRS) используется для текущего сопровождения проекта и представления требований, сформулированных по отношению к проекту [2]. SRS позволяет определить предметную область программного продукта, рассматриваемого относительно трех его основных составляющих: данных, процесса и поведения. Спецификация SRS позволяет от определения предметной области проекта перейти к области решений, определив три модели требований, отображающие характеристики данных, процесса и поведения.

По стандарту IEEE 830-1998 основными требованиями к спецификации являются:

- корректность;

- однозначность;

- завершенность;

- согласованность;

- упорядочение элементов согласно их важности;

- возможность верификации;

- способность к изменению

- возможность трассировки.

Разработанная спецификация для подсистемы кадрового учета и расчета заработной платы ЛИС представлена в приложении А.

1.5 Аттестация требований

Аттестация требований определяет степень соответствия программного продукта (ПП) установленным требованиям [2, 8].

Существует набор методов аттестации, которые можно использовать как вместе, так и по отдельности:

1. Обзор требований - процесс просмотра системной спецификации на предмет неточных описаний и ошибок.

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

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

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

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

Рассмотрим диаграмму состояний подсистемы кадрового учета и нагрузки, разработанную на основе предъявляемых требований к системе (см. рисунок 1.14).

Рисунок 1.14 - Диаграмма состояний проектируемой подсистемы

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

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

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

Рисунок 1.15 - Прототип меню кадрового учета

Прототипы основных рабочих форм подсистемы приведены в приложении Б.

Выводы к разделу

В первом разделе дипломного проекта были проанализированы существующие информационные системы лабораторной диагностики.

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

Далее был проведен анализ требований подсистеме кадрового учета ЛИС. Для определения требований был проведён опрос заведующей лабораторией и старшего лаборанта, как основных пользователей будущей подсистемы. Результаты моделирования требований представлены в виде разработанных вариантов использования системы. Осуществлён процесс специфицирования требований. Итоговым шагом данного этапа стало выполнение аттестации требований посредством прототипирования. В результате проведенного анализа выявлено, что на первом этапе проектирования целесообразно, используя методологию проектирования предметной области осуществить проектирование основных компонентов подсистемы, входящих в предметную область учета кадров.

2. Проектирование информационной системы

2.1 Архитектурное проектирование

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

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

Рисунок 2.1 - Примерная архитектура ЛИС.

Основной сервер ЛИС, поддерживающий функционирование базы данных системы может быть совмещен либо с автоматизированным рабочим местом (АРМ) заведующего лабораторией, либо с АРМ старшего лаборанта. Данные два рабочих места функционируют на персональных компьютерах (ПК) с конфигурацией достаточной для установки полнофункционального программного обеспечения проектируемой ЛИС в соответствии со спецификацией требований (см. Приложение А). АРМ врачей и среднего медперсонала устанавливаются на карманные ПК (КПК) [9] в конфигурации достаточной для выполнения функциональных обязанностей данного сотрудника КДЛ.

Основными программными архитектурами, реализуемыми в настоящее время являются:

- файл-серверная;

- клиент-серверная;

- многоуровневая.

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

Одной из ведущих технологий предлагаемых корпорацией Microsoft для реализации таких приложений является технология COM/DCOM. При этом бизнес процессы системы реализуются как отдельные COM модули, которые осуществляют доступ к данным [10]. Архитектура доступа к данным представлена на рисунке 2.3. Так как темой дипломного проекта является реализация подсистемы кадрового учета и учета рабочего времени, то подробнее рассмотрим архитектуру реализации данных модулей ЛИС.



Рисунок 2.2 - Развитие клиент-серверной технологии

Рисунок 2.3 - Универсальная архитектура доступа к данным.

Данная подсистема, как указано в спецификации требований (см. Приложение А), реализуется для трех категорий пользователей: заведующего отделением, старшего лаборанта и персонала. Так как на первоначальном этапе разработки реализуется версия ЛИС только для работы с АРМ заведующего лабораторией и АРМ старшего лаборанта, модули для получения справочной информации персоналом лаборатории, устанавливаемые на АРМ врачей и лаборантов ЛИС, не разрабатываются.

В целом ЛИС разрабатывается на базе технологии клиент-сервер как многоуровневая система. При этом основное приложение ЛИС реализуется как тонкий клиент, поддерживающий загрузку необходимых модулей системы в зависимости от типа пользователя, загрузившегося в систему. Модули проектируемой подсистемы разрабатываются как ActiveX-элементы, обеспечивающие взаимодействие с соответствующими таблицами и/или запросами базы данных ЛИС на основе технологии OLE DB.

2.2 Проектирование интерфейса информационной системы

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

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

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

Данный модуль является сервером для клиентского приложения, обеспечивающего управление объектами предметной области, а с другой стороны, выступает как клиент при взаимодействии с SQL Server. Интерфейс взаимодействия с сервером БД реализован на базе технологии OLE DB, основанной на COM технологии доступа к источникам данных.

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

Основными целями проектирования базы данных являются [13-15]:

1. представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей;

2. создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;

3. разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы -- например, ко времени реакции системы.

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

При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее [15, 16]:

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

- ?База данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности.

- ?База данных должна удовлетворять выявленным и вновь возникающим требованиям конечных пользователей.

- ?База данных должна легко расширяться при реорганизации и расширении предметной области.

- ?База данных должна легко изменяться при изменении программной и аппаратной среды.

- ?Загруженные в базу данных корректные данные должны оставаться корректными.

- ?Данные до включения в базу данных должны проверяться на достоверность.

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

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

На концептуальном уровне определяются основные сущности, сохраняемые в виде таблиц реляционной базы данных. В нашем случае к таким сущностям относятся: Персонал, Сотрудник, Должность, Отделы и т.д. Концептуальная схема данных подсистемы представлена на рисунке 2.4.



Рисунок 2.4 - Концептуальная модель данных подсистемы

Разработка концептуальной модели данных была осуществлена с использованием Case-средства Rose Data Modeler [17] в рамках среды Rational Rose 2002.

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

Физической СУБД для проекта ЛИС была выбрана СУБД Microsoft SQL Server 2005. Данный выбор был обусловлен наличием у этой версии СУБД развитых средств многомерного анализа данных, усовершенствованной OLAP системы и развитой среды разработки отчетности предприятия Reporting Service [18, 19]. На данном этапе проектирования подсистемы кадрового учета эти средства не использовались, но они необходимы для разработки системы в целом. Кроме того, СУБД Microsoft SQL Server 2005 в настоящий момент является одной из наиболее мощных СУБД, обеспечивающих эффективную систему хранения информации и доступа к данным.

Рисунок 2.5 - Логическая модель данных подсистемы

Разработанная схема данных для подсистемы кадрового учета и начисления заработной платы представлена на рисунке 2.6. Сценарий создания объектов базы данных представлен в приложении Г.

Рисунок 2.6 - Структура данных подсистемы кадрового учета

2.4 Обоснование выбора платформы создания информационной системы

В качестве среды разработки системы бала выбрана Visual Studio 2005 и подсистема Analysis Services от СУБД Microsoft SQL Server 2005. В данной конфигурации Visual Studio позволяет в полной мере использовать средства проектирования предоставляемые корпорацией Microsoft, для полнофункционального проектирования ИС от этапов разработки БД и интерфейсов пользователя до мощных средств отладки распределенных приложений, хранимых процедур и создания инсталлятора системы.

Дополнительно на этапе проектирования использовалась среда Rational Rose 2002 [17], позволяющая документировать основные этапы проектирования ИС средствами UML.

2.5 Проектирование модулей

Основная задача проектирования заключается в том, чтобы превратить модели анализа в документы детализированного проектирования, на основе которых реализуется система. Логическая модель проектируемой подсистемы строится на основе технологии Rational [17], используя основные объектно-ориентированные подходы языка UML [20, 21].

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

Основными функциями, реализуемыми над этими сущностями, являются функции ввода нового элемента, удаления и модификации существующих элементов.

Пример диаграммы деятельности для реализации функции приема сотрудника приведен на рисунке 2.7.

Представленные на данной диаграмме деятельности по вводу данных на сотрудника, зачислению на должность и т.д. предполагают при традиционном подходе к проектированию разработку диалоговых окон для ввода соответствующих данных. При компонентном построении ИС в данном случае разрабатывается соответствующий ActiveX-элемент. Управляющий компонент передает проектируемому элементу основные входные параметры через функции его интерфейсов. Со стороны клиента диаграмма классов проектируемого компонент выглядит, как представлено на рисунке 2.8 для компонента PersonalDlg, реализующего функциональность сущности Персонал.



Рисунок 2.7 - Диаграмма деятельности приема сотрудника



Рисунок 2.8 - Диаграмма классов компонента PersonalDlg

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

Для реализации функциональности сервера, взаимодействующего с клиентом, реализованном на произвольном языке программирования, данные элементы наследуются от интерфейса IDispatch. Для взаимодействия с сервером БД используются модуль стандартной динамической библиотеки stdole.dll. Диаграмма классов данного модуля, обеспечивающего функциональность COM, представлена на рисунке 2.9.



Рисунок 2.9 - Диаграмма классов, используемая ActiveХ-элементом

Основной особенностью технологии проектирования ActiveX-элементов, элементов COM, является множественное наследование. Диаграмма классов для реализации данного компонента представлена на рисунке 2.10.

Рисунок 2.10 - Диаграмма класса реализации CPersonalDlg

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

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

Рисунок 2.11 - Диаграмма компонентов подсистемы

Таблица 3.1 - Соответствие сущностей предметной области и реализуемых компонентов

Сущность	Компонент	ActiveX-элемент	Таблица в БД
Персонал	PersonalATLLib Ver 1.0 (PersonalATL 1.0 Type Library)	PersonalDlg	dbo.[Персонал]
Образование	EducationAtlLib Ver 1.0 (EducationAtl 1.0 Type Library)	EducationDlg	dbo.[Образование]
Учебное заведение	educationalAtlLib Ver 1.0 (educationalAtl 1.0 Type Library)	educationalDlg	dbo.[Учебное заведение]
Специальность	SpecialityAtlLib Ver 1.0 (SpecialityAtl 1.0 Type Library)	SpecialityDlg	dbo.[Специальность]

Выводы к разделу

Во втором разделе выполнено проектирование подсистемы кадрового учета ЛИС.

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

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

3. Реализация и аттестация информационной системы

3.1 Реализация приложения

информационный интерфейс программный

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

Разработка ActiveX-элементов подсистемы осуществлялась на C++ [21 _ 26] с использованием библиотеки шаблонов ATL [27].

Разработка набора ActiveX-элементов осуществляется в едином рабочем пространстве. Рабочее пространство проекта подсистемы представлено на рисунке 3.1 и содержит набор проектов, реализующих, как проектируемые компоненты системы, так и проекты для проведения комплексного тестирования работоспособности компонентов.

Рисунок 3.1 - Рабочее пространство проекта подсистемы

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

Разработка ActiveX-элемента осуществляется с использованием специализированных мастеров Visual Studio для ATL-проектов. В результате работы мастера проекта реализуется каркас ATL-проекта, включающий определение основных глобальных функций проекта, определение уникального номера (CLSID) проектируемой динамической библиотеки. Далее вновь с использованием мастера реализуется шаблон проекта компонента. На этом этапе мастер создает интерфейс компонента, выделяет уникальный номер UUID интерфейса (рисунок 3.2) и создает класс реализации (рисунок 3.3), проектируемого интерфейса.

Рисунок 3.2 - Определение интерфейса IPersonalDlg в файле PersonalATL.idl



Рисунок 3.3 - Определение заголовка класса реализации PersonalDlg

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

Рисунок 3.4 - Процедуры передачи текстовой строки управляющим элементам ControlEdit по их идентификаторам

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

Рисунок 3.5 - Определение заголовка класса реализации PersonalDlg

3.2 Взаимодействие приложения с источниками данных

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

Взаимодействие компонента с источником в БД осуществляется через мастера «ATL OLE DB Consumer», обеспечивающего соединение с источником данных. Сгенерированный код программы для класса выборки строк возвращаемой в результате запроса к таблице БД, представлен в Приложении Д. Текст запроса показан на рисунке 3.6, а строка определяющая источник данных - на рисунке 3.7.

Рисунок 3.6 - Запрос к таблице Персонал



Рисунок 3.7 - Строка источника данных

Класс CDataRowset является наследником от шаблонного класс CCommand, осуществляющего взаимодействие с БД. Код с примером использования переменной типа CDataRowset представлен на рисунке 3.8.

Рисунок 3.8 - Строка источника данных

3.3 Тестирование приложения

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

Как известно, аттестация и верификация - это процесс, благодаря выполнению которого гарантируется, что программа, которая находится в стадии разработки или подвергается изменениям, будет отвечать функциональным или другим требованиям [2]. Для осуществления тестирования разрабатывается набор тестовых случаев, позволяющий выявить ошибки, присущие разрабатываемому ПО [28? 29].

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

Тестирование ActiveX компонентов на стадии разработки компонента осуществляется с использованием специального средства visual Studio - «ActiveX control Test Container». Пример запуска компонента под управлением «ActiveX control Test Container» представлен на рисунке Б.2 Приложения Б. Удобство этого средства тестирования заключается в возможности его использования в режиме отладки приложения под управлением встроенного отладчика Visual Studio.

Основным недостатком тестирования с использованием программы «ActiveX control Test Container» является невозможность модификации данных поступающих от приложения клиента, т. к. данная программа посылает компоненту только те сообщения и запросы, которые входят стандартный состав сообщений Windows/ В этой связи, для отладки взаимодействия компонента с клиентским приложением разрабатывается программа контейнер, позволяющая как внедрять проектируемый компонент, так и осуществлять к нему доступ в формате соответствующем интерфейсам разработанного компонента.

3.4 Методика развертывания приложения

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

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

Выводы к разделу

В третьем разделе дипломного проекта рассмотрен пример реализации, тестирования и развертывания компонента из предметной области проектируемой подсистемы. В разделе приведено описание разработки компонента в среде Visual Studio и основных методов его тестирования и отладки.

Продемонстрирована реализация взаимодействия компонента с СУБД и с клиентским приложением.

4. Управление информационным проектом

4.1 Выбор жизненного цикла разработки

В соответствии с определением, приведенным в [2], модель жизненного цикла разработки ПО (software life cycle model, SLCM) схематически объясняет, в каком порядке будут выполняться действия по разработке программного продукта. Такая последовательность может быть не линейной, так как фазы могут следовать последовательно, повторяться или происходить одновременно. Организацией ISO\IEC 12207 перечислено 12 действий по инжинирингу составляющих типичную модель SLCM.

- анализ системных требований;

- проектирование архитектуры системы;

- анализ программных требований;

- разработка проекта программной архитектуры;

- рабочий план разработки ПО;

- кодирование ПО;

- интеграция ПО;

- тестирование ПО;

- интеграция системы;

- тестирование системы;

- установка ПО;

- тестирование и приемка ПО.

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

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

Матрицы, предназначенные для осуществления процесса выбора модели жизненного цикла, представлены в приложении Е.

В таблице 4.1 представлены итоговые результаты процесса выбора модели жизненного цикла.

Таблица 4.1 - Определение оптимальной модели жизненного цикла

Характеристика	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Требования	3	2	4	4	4	2
Участники команды разработчиков	3	2	8	7	3	4
Коллектив пользователей	3	4	7	10	3	6
Типы проектов и рисков	4	4	1	4	1	4
Итого	13	10	20	25	11	16

Таким образом, наиболее подходящими моделями жизненного цикла являются «Спиральная» и «Эволюционного прототипирования».

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

- отсутствие адекватной документации;

- низкое качество ПО в целом;

- незапланированные итерации прототипирования.

Использование спиральной модели при проектировании ЛИС позволяет:

- «увидеть» систему на ранних этапах;

- определить возможность непреодолимых рисков без особых дополнительных затрат;

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

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

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

- реализовать преимущества инкрементной модели, а именно выпуск инкрементов, сокращение графика посредствам перекрывания инкрементов, рассортированных по версиям, и неизменяемость ресурсов при постепенном росте системы,

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

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

- повышается продуктивность благодаря использованию пригодных для повторного использования свойств;

- повышается вероятность предсказуемого поведения системы с помощью уточнения поставленных целей;

- при использовании спиральной модели не нужно распределять заранее все необходимые для выполнения проекта финансовые ресурсы;

- можно выполнять частую оценку совокупных затрат, а уменьшение рисков связано с затратами.

4.2 Определение цели и области действия программного проекта

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

На начальном этапе планирования проекта необходимо определить цель проекта и интерпретировать ее для всех участников проекта.

Программный продукт, разрабатываемый в рамках данного дипломного проекта, является частью ЛИС для больниц скорой помощи. Проектируемая система позволит автоматизировать процесс учета кадров и рабочего времени сотрудников КДЛ ГБСМП №2. Цель данного проекта создание демонстрационной версии подсистемы кадрового учета и учета рабочего времени.

Задачи проекта:

- выполнить сбор, спецификацию и аттестацию требований

- выполнить проектирование информационного и программного обеспечения системы;

- разработать скрипты описания базы данных и программные коды приложения;

- провести тестирование программного продукта;

Программный проект должен быть:

- продуктом для внутреннего использования в КДЛ ГБСМП №2;

- проектом для осуществления многопользовательского доступа;

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

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

Программный проект не должен быть: