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

ОГЛАВЛЕНИЕ

• ВВЕДЕНИЕ
• 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
• 1.1 Структура студии, ее описание, цели, функции и задачи
• 1.2 Общие требования к системе
• 1.3 Формирование критериев оценки
• 1.4 Обзор существующих информационных систем
• 1.5 Сравнительный анализ существующих и разрабатываемой ИС
• 2. СИСТЕМНОЕ ИССЛЕДОВАНИН ОБЪЕКТА ПРОЕКТИРОВАНИЯ
• 2.1 .Обзор и выбор CASE средств для построения модели
• 2.1.1 Обзор case-средств
• 2.1.2 Формирование критериев оценки case-средств
• 2.1.3 Обоснование выбора case-средства
• 2.2 Основные объекты web студии
• 2.3 Построение модели предметной области «Как есть» (AS-IS)
• 2.4 Построение оптимизированной модели предметной области «Как надо» (TO-BE)
• 2.5 Построение модели информационной системы на языке «ДРАКОН»
• 3. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ ЗАКАЗМИ
• 3.1 Модель информационной системы в объектно-ориентированных нотациях языка UML
• 3.2 Выбор архитектуры информационной системы
• 3.3 Разработка логической и физической структуры БД
• 4. РЕАЛИЗАЦИЯ ВЫБРАННОГО ВАРИАНТА РЕШЕНИЯ
• 4.1 Обоснование выбора СУБД
• 4.2 Обоснование выбора средств реализации
• 5. СОЦИАЛЬНАЯ ЗНАЧИМОСТЬ ПРОЕКТА
• 6. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА
• 6.1 Расчет затрат на проектирование
• 6.2 Расчет эксплуатационных расходов
• 6.3 Расчет экономии от увеличения производительности труда пользователя
• 6.4 Расчет экономического эффекта от использования системы
• 6.5 Сопоставление технико-экономических характеристик разработки с аналогом
• 7. БЕЗОПАСНОСТЬ И ЭКОЛОГИЧНОСТЬ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ
• 7.1 Электробезопасность
• 7.2 Требования к уровню шума и вибрации
• 7.3 Микроклимат
• 7.4 Эргономичность проекта
• 7.4.1 Принципы эргономики, используемые при создании ПО АСОИиУ
• 7.4.2 Организация рабочего места оператора
• 7.4.3 Эргономические требования к рабочему месту
• 7.5 Экологичность проекта
• ЗАКЛЮЧЕНИЕ
• СПИСОК ЛИТЕРАТУРЫ

ВВЕДЕНИЕ

Успешная практическая деятельность человека всё в большей степени зависит от эффективной организации обмена информацией.

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

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

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

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

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

2. Увеличение объема заказов приводит к появлению необходимости в расширении штата. В свою очередь, увеличение штата усложняет контроль над каждым сотрудником, подбор команды разработчиков на новые проекты, корректировку текущих проектов, в случае ухода сотрудников из компании.

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

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

Разрабатываемая система предполагает автоматизацию следующих процессов:

1. Определение сложности и стоимости проекта.

2. Подбор команды разработчиков.

3. Управление сотрудниками.

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

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Структура студии, ее описание, цели, функции и задачи

Индустрия разработки Web приложений сравнительно молодая, но её роль в российской и мировой экономике, и жизни общества неуклонно растет. Данная отрасль включает фирмы, занимающиеся разработкой, поддержкой и издательством программного обеспечения, используя при этом любую бизнес-модель. Индустрия включает также такие сервисы, связанные с программным обеспечением, как обучение, документирование и консультирование.

В данной работе будет рассматриваться деятельность Web студии, занимающейся разработкой в сфере IT технологий и Web по индивидуальному заказу, в частности:

· Разработка web-сайтов

· Разработка web-приложений

· Разработка библиотек и модулей

· Доработка существующих и заброшенных проектов

· Сопровождение и поддержка пользователей и клиентов

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

1. Получение запроса на разработку

2. Принятие/отклонение заказа

3. Назначение руководителя проекта

4. Подбор команды разработчиков

5. Выполнение заказа

6. Ввод продукта в эксплуатацию

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

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

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

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

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

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

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

На рис. 1.1 представлена управленческая структура рассматриваемой web студии.

Рис. 1.1 Управленческая структура web-студии

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

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

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

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

На основе проведенного анализа документов web студии и опроса ее сотрудников выделим основные задачи, которые должна решать разрабатываемая информационная система:

· Своевременное и качественное выполнение заказов;

· Совершенствование технологий разработки;

· Повышение квалификации коллектива фирмы в целом;

· Повышение квалификации каждого работника;

· Привлечение новых сотрудников в фирму;

· Обеспечение работой всех работников фирмы;

В соответствии с основными задачами отделы выполняют следующие функции:

· Связь с текущими и потенциальными заказчиками;

· Принятие решения о выполнении заказа;

· Подготовка общих требований к проекту;

· Назначение руководителя проекта;

· Подбор команды разработчиков;

· Привлечение сторонних разработчиков;

· Разработка проектных планов;

· Учет текущих проектов;

· Разработка программного продукта;

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

· Подготовка продукта к эксплуатации;

· Сопровождение и поддержка выпущенных программных продуктов;

· Ведение учета за развитием сотрудников, подведение ежегодных итогов о проделанной ими работе.

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

1.2 Общие требования к системе

На основе выводов сделанных в пункте 1.1 определим перечень требований к разрабатываемой ИС:

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

2. Сформировать единую информационную базу предприятия по сотрудникам, проектам, заказчикам, договорам, отчетным документам;

3. Сократить время, затрачиваемое на поиск и изменение данных;

4. Реализовать подсистему определения сложности проектов для дальнейшего использования этого показателя при наборе разработчиков;

5. Реализовать подсистему фильтрации сотрудников для выявления наиболее подходящих кандидатур на новые проекты;

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

7. Обеспечить связь между сотрудниками;

8. Обеспечить разделенный доступ к данным информационной системы.

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

1.3 Формирование критериев оценки

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

· Удобство интерфейса. Система должна обладать дружественным интерфейсом или, как минимум, иметь настраиваемый интерфейс;

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

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

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

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

1.4 Обзор существующих информационных систем

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



Devprom

DEVPROM - Профессиональный инструмент для управления проектами и сообщество разработчиков, пользователей, заказчиков, консультантов и инвесторов, заинтересованных в успешном создании программных продуктов. [8]

Возможности инструмента:

· поддержка полного цикла разработки проекта: от первоначальной идеи заказчика до работающего продукта

· проектное планирование, управление требованиями и тестированием, отчетность

· полная трассировка между всеми артефактами проекта

· гибкая настройка проектной методологии

· многоязычный интерфейс (русский, английский)

Помимо реализации функций, стандартных для большинства систем управления проектами, Devprom предлагает набор «уникальных» возможностей, которые были заложены в систему:

· Управление разработкой - управление проектом по разработке программного обеспечения это совсем не тоже, что управление задачами, заложенное в большинство систем управления проектом. Существующие планировщики задач не учитывают специфики итерационной разработки, состоящей из фаз анализа, проектирования, разработки, тестирования и документирования. Конечно, вы можете расписать все задачи вручную, постараться ничего не упустить и потратить на это массу времени, большую часть работы DEVPROM выполнит за вас. [8]

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

· Управление журналами (backlogs) - большое внимание в DEVPROM уделено работе с журналами пожеланий. Журнал входящих пожеланий позволяет вам отсортировать мусор, неизбежно образующийся при работе с пользователями, крупным заказчиком или в крупной команде. Журналы релизов позволяют строить планы на будущее. Журнал итерации - иметь представление о разрабатываемом функционале в текущий момент. При помощи тэгов вы можете формировать журналы пожеланий по нужному вам признаку, например, предварительно согласовывать с заказчиком скоуп на ближайшую итерацию. [8]

· Гибкая методология - в систему заложена настраиваемая методология ведения проекта, включающая практики из Agile, Scrum и классических методологий. По мере развития проекта вы сами определяете что нужно команде в настоящий момент. Можете превратить DEVPROM в баг-трекер или планировщик задач, отключить неиспользуемую фазу анализа или тестирования, если вам это нужно. [8]

· Совместная работа над артефактами - требования, справочная документация и тестовые наборы представляют собой Wiki-страницы. Это простой, но эффективный способ создания необходимой документации, который переносит фокус с внешнего вида страницы на ее содержание. История изменений позволит понять, что было изменено и вернуться к нужной версии документа. [8]

· Обильная коммуникация внутри команды - особенное внимание в DEVPROM уделено коммуникации между участниками команды. Участники могут оставлять свои вопросы и комментарии практически под каждым объектом системы, будь то пожелание, требование или веха проекта. Участникам всегда доступна информация о текущих и будущих планах, контрольных точках проекта. DEVPROM позволяет проводить опросы мнения участников, хранить информацию о встречах и публиковать новости проекта в блоге проекта. [8]

· Трассировка изменений - все артефакты, создаваемые командой в процессе разработки, связаны между собой. Пожелание, проходя по всем этапам разработки, обрастает необходимыми артефактами, например, требованиями или тестовыми наборами. В DEVPROM всегда можно понять, что послужило причиной изменения требования, и каким образом это изменение необходимо отразить в связанных артефактах, то есть система подсказывает какие разделы документации или тестовые наборы необходимо привести в соответствие с требованиями. [8]

· Единое информационное пространство проекта - DEVPROM специально разрабатывался для того, чтобы сформировать общее информационное поле для участников проекта. Общие правила, заметки и полезные материалы располагаются в базе знаний проекта. Участникам доступны требования, тестовые наборы, файлы справки и любые другие артефакты проекта, загружаемые на сервер в виде обычных файлов, например, модели. [8]

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

· Функциональное тестирование - помимо написания тестовых наборов и сценариев, при помощи DEVPROM, вы можете выполнять тесты по сценариям, составлять и просматривать отчет по тестированию, из которого делать вывод о качестве итерации или релизе. Заказчик видит ваши отчеты по тестированию и понимает, как и что вы проверяете. [8]

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

· Целевая аудитория - система подходит под нужды практически любого проекта: заказного, своего личного, продуктового или сервисного. Система полезна для стартапов и шароварщиков и в целом для быстрого старта проекта. [8]

Microsoft Visual Studio Team System

Microsoft Visual Studio Team System 2008 представляет собой интегрированное решение для управления жизненным циклом приложений, в состав которого входят программные средства, процессы и руководства, помогающие каждому члену группы усовершенствовать навыки и повысить эффективность совместной работы с другими членами группы. С помощью Visual Studio Team System члены рабочей группы могут выполнять указанные ниже задачи. [9]

· Более эффективно работать и взаимодействовать с другими членами группы и заинтересованными лицами в сфере бизнеса.

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

· Обеспечить прозрачность проекта и приоритетов, чтобы принимать взвешенные решения на основе данных реального времени.

Visual Studio Team System 2008 Team Suite предоставляет участникам группы, обладающим различными специализациями, интегрированный набор средств для создания архитектуры, проектирования, разработки и тестирования приложений и баз данных. Участники группы могут не прекращать совместной работы и использовать полный набор средств и руководств на каждом этапе жизненного цикла приложения. [9]

Visual Studio Team System 2008 Team Suite предлагает участникам группы средства, необходимые для преодоления трудностей, возникающих при создании современного программного обеспечения, повышения качества программного обеспечения, прозрачности проектов и эффективности совместной работы. Используя полный набор функций Visual Studio Team System, участники группы разработчиков Visual Studio Team System 2008 Team Suite могут вносить изменения на этапе создания архитектуры, проектирования, написания кода, разработки базы данных и тестирования.

· Контроль над изменениями баз данных. Повысьте степень контроля над изменениями, вносимыми в базы данных, с помощью средств контроля версий и оптимизации кода выпуска Database Edition, теперь интегрированного с Team Suite.

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

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

Visual Studio Team System 2008 Team Suite - это пакет программ, каждая из которых решает конкретные задачи, такие, как тестирование или управление требованиями. Рассмотрим подробнее каждый из пакетов.

Microsoft Visual Studio Team System 2008 Architecture Edition - программа, предназначенная для улучшения процесса проектирования и верификации распределенных систем. Она предоставляет архитекторам, руководителям проектов и разработчикам возможность визуального построения ориентированных на службы решений и их проверки в операционных средах перед внедрением.

Microsoft Visual Studio Team System 2008 Database Edition предоставляет расширенные средства для управления изменениями и тестированием баз данных, а также содержит инструменты, позволяющие разработчикам и администраторам баз данных оптимизировать производительность и повышать качество приложений на уровне баз данных.

Microsoft Visual Studio Team System 2008 Development Edition предоставляет разработчикам расширенный набор средств для определения неэффективного, небезопасного или низкокачественного кода, указания рекомендаций по его написанию и автоматизации блочного тестирования. Эти средства помогают командам разработчиков в написании высококачественного кода, уменьшении количества ошибок, связанных с безопасностью, а также позволяют избежать ошибок, возникающих позднее в цикле разработки.

Microsoft Visual Studio Team System 2008 Test Edition предоставляет полный пакет инструментов, интегрированных в среду Visual Studio, для тестирования веб-приложений и служб. Эти средства позволяют специалистам по тестированию разрабатывать, выполнять, а также управлять процессом и задачами тестирования - и все это в среде Visual Studio.

1.5 Сравнительный анализ существующих и разрабатываемой ИС

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

Первым этапом применения МАИ является структурирование проблемы выбора в виде иерархии или сети. В наиболее элементарном виде иерархия строится с вершины (цели), через промежуточные уровни-критерии (технико-экономические параметры) к самому нижнему уровню, который в общем случае является набором альтернатив. [3] На рис. 1.2 представлена схема, структурирующая проблему в виде иерархии.

Рис. 1.2 Структурирование проблемы выбора в виде иерархии

Итак, даны три информационные системы: “Devprom”, “Microsoft Visual Studio Team System” и «Разрабатываемая система». Определены критерии, по которым должно быть проведено сравнение систем и выбрана наиболее подходящая для описываемой предметной области. Проведем общее сравнение систем по выбранным критериям. Результаты сравнения сведены в табл. 1.1.

Таблица 1.1

Общее сравнение систем-аналогов

Критерии	Devprom	Microsoft Visual Studio Team System	Разрабатываемая система
Удобство интерфейса	Низкое	Среднее	Высокое
Скорость передачи данных	Средняя	Средняя	Высокая
Требования к аппаратуре	Средние	Высокие	Низкие
Уровень защищенности	Низкий	Средний	Высокий
Надежность	Средняя	Средняя	Высокая

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

Таблица 1.2

Сравнение критериев по значимости

	Удобство интерфейса	Скорость передачи данных	Требования к аппаратуре	Уровень защищен-ности	Надеж-ность	Оценка компонентов собственного вектора	Нормализо-ванные оценки вектора приоритета	Max
Удобство интерфейса	1	1/5	1/3	1/9	1/7	0,254	0,032	0,810
Скорость передачи данных	5	1	3	1/5	1/5	0,903	0,115	1,328
Требования к аппаратуре	3	1/3	1	1/7	1/5	0,491	0,063	1,023
Уровень защищенности	9	5	7	1	3	3,936	0,502	0,897
Надежность	7	5	5	1/3	1	2,255	0,288	1,307
Сумма						7,840		5,366



Рис. 1.3 Сравнение критериев оценки ИС

Относительная сила, величина или вероятность каждого отдельного объекта в иерархии определяется оценкой соответствующего ему элемента собственного вектора матрицы приоритетов, нормализованного к единице. Процедура определения собственных векторов матриц поддается приближению с помощью вычисления геометрической средней. Заполнив табл. 1.2, сначала определяются оценки компонент собственного вектора, которые получаются как произведение относительных весов критерия по горизонтали, возведенного в степень 1/5 (где 5 - количество критериев). Например, рассчитаем оценку собственного вектора для критерия «Удобство интерфейса»: (1*1/5*1/3*1/9*1/7*)^1/5 = 0,254

Аналогично определяю остальные критерии.

Для того же критерия «Удобство интерфейса» рассчитаем нормализованные оценки вектора приоритета, разделив оценки собственного вектора на их сумму 0,254/7,840 = 0,032

Так же рассчитываем остальные критерии.

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

ИС = (l_max-n)/(n-1)

где lmax - максимальное собственное значение матрицы, n - размерность матрицы.

ИС = (5,366-5)/(5-1) = 0,091

Разделив ИС на число, соответствующее случайной согласованности матрицы пятого порядка, равного 1,12, получим отношение согласованности (ОС). Величина ОС должна быть порядка 10% или менее, чтобы быть приемлемой. В некоторых случаях допускается ОС до 20%, но не более, иначе надо проверить свои суждения.

ОС = 0,091/1,12 = 0,082 = 8,2% < 10%,

т.е. пересматривать суждения нет необходимости.

Согласно проведенному анализу и расчетам, сведенным в таблицу, а так же диаграмме, можно сделать вывод, что наибольшее внимание уделяется критерию «Защищенность».

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

Построим матрицу сравнений, сравнивая попарно альтернативу из строки с альтернативой из столбца по отношению к критерию «Удобство интерфейса». Сравнительные оценки систем по критерию «Удобство интерфейса» сведены в табл. 1.3. Никакие другие критерии при этом не учитываются. Результаты расчётов представлены на рис. 4.

Таблица 1.3

Сравнение систем по удобству интерфейса

	Devprom	MS VTS	Разрабаты-ваемая ИС	Оценка компонентов собственного вектора	Нормализованные оценки вектора приоритета	Max
Devprom	1	1/3	1/3	0,644	0,202	0,336
MS VTS	3	1	1/3	1,00	0,313	1,356
Разрабатыва-емая ИС	3	3	1	1,552	0,486	3,399
Итог				3,196		5,090

Рис. 1.4 Сравнение систем по «Удобству интерфейса»

ИС = 0,023ОС = 0,02 = 2% < 10%

Далее так же построю матрицу сравнений, сравнивая попарно альтернативу из строки с альтернативой из столбца по отношению к критерию «Скорость передачи данных». Сравнительные оценки систем по критерию «Скорость передачи данных» сведены в табл. 1.4. Никакие другие критерии при этом не учитываю. Результаты расчётов представлены на рис. 1.5.

Таблица 1.4

Сравнение систем по скорости передачи данных

	Devprom	MS VTS	Разрабатываемая ИС	Оценка компонентов собственного вектора	Нормализованные оценки вектора приоритета	Max
Devprom	1	1/3	1/3	0,644	0,202	0,336
MS VTS	3	1	1/3	1,00	0,313	1,356
Разрабатываемая ИС	3	3	1	1,552	0,486	3,399
Итог				3,196		5,090



Рис. 1.5 Сравнение систем по «Скорости передачи данных»

ИС = 0,023ОС = 0,02 = 2% < 10%

Далее так же построю матрицу сравнений по отношению к критерию «Требования к аппаратным средствам». Сравнительные оценки систем по критерию «Требования к аппаратным средствам» сведены в табл. 1.5. Аналогичные действия проведем для остальных критериев (см. рис. 1.6, 1.7).

Таблица 1.5

Сравнение систем по требованию к аппаратным средствам

	Devprom	MS VTS	Разрабатываемая ИС	Оценка компонентов собственного вектора	Нормализованные оценки вектора приоритета	Max
Devprom	1	3	1/3	1,00	0,313	1,356
MS VTS	1/3	1	1/3	0,644	0,202	0,336
Разрабатываемая ИС	3	3	1	1,552	0,486	3,399
Итог				3,196		5,090

Рис. 1.6 Сравнение систем по «Требования к аппаратным средствам»

ИС = 0,023ОС = 0,02 = 2% < 10%

Таблица 1.6

Сравнение систем по критерию «Защищенность»

	Devprom	MS VTS	Разрабатываемая ИС	Оценка компонентов собственного вектора	Нормализованные оценки вектора приоритета	Max
Devprom	1	3	1/3	1,00	0,313	1,356
MS VTS	1/3	1	1/3	0,644	0,202	0,336
Разрабатываемая ИС	3	3	1	1,552	0,486	3,399
Итог				3,196		5,090

Рис. 1.7 Сравнение систем по «Защищённости»

ИС = 0,023ОС = 0,02 = 2% < 10%

Таблица 1.7

Сравнение систем по критерию «Надёжность»

	Devprom	MS VTS	Разрабатываемая ИС	Оценка компонентов собственного вектора	Нормализованные оценки вектора приоритета	Max
Devprom	1	3	1/3	1,00	0,313	1,356
MS VTS	1/3	1	1/3	0,644	0,202	0,336
Разрабатываемая ИС	3	3	1	1,552	0,486	3,399
Итог				3,196		5,090

Рис 1.8 Сравнение систем по «Надёжности»

ИС = 0,023ОС = 0,02 = 2% < 10%

Результаты оценок информационных систем по всем критериям сведены в табл. 1.8. Т.е. в самую верхнюю строку перенесены значения вектора приоритета для каждого критерия (см. табл. 1.2).

Для каждой из альтернатив заполняю столбцы критериев значениями локальных векторов приоритета, полученных соответственно в табл. 1.3, 1.4, 1.5, 1.6, 1.7. Далее подсчитываю значения глобального приоритета для каждой из альтернатив как сумму произведений значения вектора приоритета для критерия и значения вектора локального приоритета этой альтернативы в отношении данного критерия.

Таблица 1.8

Сравнение систем по всем критериям

Альтернативы	Удобство интерфейса	Скорость обработки запросов	Требования к аппаратным средствам	Уровень защищён-ности	Надёж-ность	Глобальные приоритеты
	Численное значение вектора приоритета
	0,032	0,115	0,063	0,502	0,288
Devprom	0,313	0,313	0,313	0,313	0,313	0,313
MS VTS	0,202	0,202	0,202	0,202	0,202	0,202
Разарабатываемая система	0,486	0,486	0,486	0,486	0,486	0,486



Рис. 1.9 Сравнение систем по глобальному критерию

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



2. СИСТЕМНОЕ ИССЛЕДОВАНИЕ ОБЪЕКТА ПРОЕКТИРОВАНИЯ

2.1 Обзор и выбор CASE средств для построения модели

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

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

Стратегия развития ИСУ для каждого предприятия определяется, в первую очередь, целями ее функционирования, а также существующими возможностями и ограничениями предприятия. Данные цели, возможности и ограничения лежат в основе стратегии развития всего предприятия. Таким образом, стратегия бизнеса и стратегия развития ИСУ являются взаимозависимыми и взаимодополняющими инструментами управления предприятием. Система ЖКХ во многом заинтересована в автоматизации и реорганизации своей работы, появляющиеся новинки на рынке программного обеспечения рассматриваются муниципалитетом на предмет пригодности и перспективной выгоды. Как правило, такие попытки не приводят к ожидаемым результатам из-за несовместимости с узконаправленной и специфичной областью применения в структуре ЖКХ.

Системные аналитики, проектировщики и разработчики перешли на автоматизированное проектирование систем в интересах автоматизации разработки программного обеспечения CASE-средства (Computer-Aided Software Engineering -- CASE).

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

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

Использование CASE - средств позволяет:

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

Упростить проектирование системы и построение модели данных.

Быстро вносить изменения в проект, если в процессе проектирования произошли изменения внешних условий.

Уменьшить время разработки.

2.1.1 Обзор case-средств

В России для моделирования и анализа бизнес-процессов достаточно широко используются следующие средства:

AllFusion Modeling Suite;

Rational Rose;

ARIS

Рассмотрим их характеристики более подробно:

1. All Fusion Modeling Suite - пакет инструментальных средств разработанный компанией Computer Associates International, Inc. (CA), пакет поддерживает все этапы разработки информационных систем, в этот пакет входит пять продуктов:

All Fusion Process Modeler - «BPwin» (позволяет облегчить проведение обследования предприятия и построить функциональные модели).

All Fusion ERwin Data Modeler - «ERwin» (позволяет создавать модели данных и генерировать схему баз данных).

All Fusion Data Model Variator - «ERwin Examiner» (позволяет производить поиск и исправление ошибок модели данных).

All Fusion Model Manager - «Model Mart» (система организации коллективной работы и хранилище моделей BPwin и ERwin).

All Fusion Component Modeler - «Paradigm Plus» (инструмент создания объектных моделей).

Рассмотрим продукты которые нам понадобятся в проектировании:

All Fusion Process Modeler - «BPwin»: основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Методология IDEF, являющаяся официальным федеральным стандартом США, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Возможности BPwin: поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ).

Эти три основных ракурса позволяют:

Описывать предметную область наиболее комплексно.

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

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

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

All Fusion ERwin Data Modeler - «ERwin»: это средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм "сущность - связь". В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов.

Возможности ERWin:

Поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEF1x для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных - Dimensional.

Поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных.

Интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.

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

Возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью All Fusion Model Manager).

Позволяет переносить структуру БД (не сами данные!) из СУБД одного типа СУБД в другой.

Позволяет документировать структуру БД.

BPwin и ERwin компании Соmputer Associates. Computer Associates International, Inc. (CA) входит в пятерку ведущих производителей программного обеспечения, предлагая средства моделирования, резервного копирования, управления инфраструктурой предприятия (сетями, серверами и т.д.), информационной безопасности, business intelligence и т.д. [1].

2. Rational Rose: компании IBM. IBM Rational Rose - входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Rational Rose является одним из ведущих инструментов визуального моделирования в программной индустрии, благодаря полноценной поддержке языка UML и многоязыковой поддержке командной разработки. Инструмент полностью поддерживает компонентно-ориентированный процесс создания ИС. Для бизнес аналитиков средство Rational Rose дает возможность детально описать и проанализировать бизнес-процессы данной предметной области. Для аналитиков, специализирующихся в области разработки баз данных, Rational Rose дает возможность визуально проектировать и генерировать базы данных любого размера.

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

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

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

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

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности, ER и UML. Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - "функция", "событие", "структурное подразделение", "документ" и т.п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа.

2.1.2 Формирование критериев оценки case-средств

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

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

Наличие большинства поддерживаемых стандартов;

Наличие средств графического отображения модели;

Удобство работы по созданию моделей;

Интеграция с Case-средствами;

Возможность декомпозиции объекта;

Простота освоения продукта.

2.1.3 Обоснование выбора case-средства

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

Таблица 2.1

Сравнительный анализ по базовым функциям

№	Функциональные возможности, среда	ARIS	AllFusion Modeling Suite	Rational Rose
1	Поддерживаемый стандарт	eEPS (расширение IDEF3), ERD, UML	IDEF0, IDEF3, DFD, IDEF1х.	UML
2	Наличие средств графического отображения модели	Высокая	Средняя	Низкая
3	Удобство работы по созданию моделей	Сложно	Просто	Просто
4	Интеграция с Case-средствами	Да	Да	Частично
5	Возможность декомпозиции объекта	Да	Да	Да
6	Простота освоения продукта	Сложно	Просто	Сложно

На основе опроса экспертов оценим по 10-ти больной шкале каждое CASE-средство по выделенным критериям.



№	Функциональные возможности, среда	ARIS	All Fusion Modeling Suite	Rational Rose
1	Поддерживаемый стандарт	6	6	4
2	Наличие средств графического отображения модели	8	6	4
3	Удобство работы по созданию моделей	3	8	5
4	Интеграция с Case-средствами	2	2	1
5	Возможность декомпозиции объекта	1	1	1
6	Простота освоения продукта	3	6	3
Сумма	23	29	18

Исходя из поставленных задач, предстоящих условий моделирования и произведенных сравнительных характеристик делаем вывод, что по доступности, простоте использования и распространению поддерживаемых стандартов наиболее подходящим программным средством для моделирования бизнес-процессов является All Fusion Modeling Suite фирмы Computer Associates.

2.2 Основные объекты web студии

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

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

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