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

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

Министерство образования и науки Украины

Черниговский государственный технологический университет

Кафедра информационных и компьютерных систем

Квалификационная работа специалиста

по специальности 7.05010201 “Компьютерные системы и сети”

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

Исполнитель студент гр. КС-082

Т.В.Зинченко

Руководитель ст. преподаватель

В.В. Соломаха

Консультанты по разделам

Разработка аппаратной подсистемы

ст. преподаватель А.В. Хижняк

Чернигов 2013

РЕФЕРАТ

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

Объектом разработки является информационная компьютерная система отдела тестирования программного обеспечения.

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

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

– архитектура информационно-компьютерной системы;

– структура и реализация программной подсистемы;

– локальная вычислительная сеть.

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

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

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

Введение

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

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

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

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

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

1 . Анализ задачи проектирования ИКС отдела тесирования программного обеспечения

1.1 Исследование предметной области

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

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

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

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

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

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

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

Поскольку заявка связана с несколькими сотрудниками, то следует выделить их основные роли.

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

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

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

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

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

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



Рисунок 1.1 - Концептуальная модель предметной области

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

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

Сущность «Пользователь» используется для хранения информации о сотрудниках. Сущность содержит поля email, адрес, пол, и ФИО сотрудника.

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

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

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

Сущность «Клиент» используется для хранения информации о клиентах организации. Содержит поля название фирмы, ФИО директора, контактные данные клиента.

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

1.3 Обзор существующих систем

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

1.3.1 Система учета заданий «Mantis»

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

Система является веб-приложением и работает на стороне сервера, поэтому не требует для своей работы установки специального программного обеспечения на стороне клиента. Для установки потребуется веб-сервер (Apache, IIS и др.) и база данных MySQL. Данный подход обеспечивает кроссплатформенность, для непосредственной работы с системой требуется только веб-браузер.

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

Рисунок 1.2 - Интерфейс системы учета заданий «Mantis»

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

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

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

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

1.3.2 Система учета заданий «Bugzilla»

Bugzilla -- система контроля заданий и ошибок с веб-интерфейсом. Bugzilla является свободным програмным обеспечением и распространяется по Mozilla Public License.

Bugzilla обычно инсталлируется на Unix или Linux, но может работать и на Windows, но для этого необходимо приложить немало усилий. Bugzilla написана на языке Perl и использует MySQL или PostgreSQL в качестве СУБД. Инсталляция, настройка и выполнение прочих администраторских задач - не совсем тривиальная задача, требуется хорошая квалификация, знание платформы и сравнительно много времени на изучение всех тонкостей и настроек.

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

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

Интерфейс стандартного веб-клиента можно считать неудачно реализованным.



Рисунок 1.3 - Интерфейс системы учета заданий «Bugzilla»

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

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

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

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

1.3.3 Система учета заданий «Trac»

Trac - это открытое программное обеспечение, являющиеся одновременно системой учета заданий и отслеживания ошибок. Проект Trac разрабатывается компанией Edgewall Software и распространяется по Modified BSD license. Trac был написан на Python и является кроссплатформенной системой.

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

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

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

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



Рисунок 1.4 - Интерфейс системы учета заданий «Trac»

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

1.4 Сравнение характеристик существующих систем

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

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

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

Критерии оценки	Система «Mantis»	Система «Bugzilla»	Система «Trac»
Наличие СУБД	+	+	+
Работа по сети	+	+	+
Управление доступом пользователей к системе	+	+	+
Фильтрация данных при поиске	-	+	+
Удобный интерфейс	-	-	+
Поддержка Юникода	-+	+	+
Открытый исходный код	+	+	+
Описание шагов воспроизведения ошибки	+	-	-
Многопользо- вательский режим	+	+	+
Учет зависимостей между заданий	-	+	+

1.5 Выводы

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

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

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

2 . Разработка ИКС отдела тестирования программного обеспечения

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

2.1 Выбор технологий и инструментальных средств разработки

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

2.1.1 Выбор языка реализации

Существуют клиентские и серверные языки web-программирования. Клиентские языки используются для написания программ, выполняемых на стороне клиента (браузер), а серверные - для программ, выполняемых на сервере.

Среди клиентских языков программирования стоит выделить JavaScript, которые, также как и HTML, лежит в основе многих веб-технологий.

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

При выборе языка программирования была рассмотрена возможность проектирования приложения под языки C# и Java. C# - объектно-ориентированный язык программирования спроектированный как язык разработки приложений для платформы Microsoft .NET Framework и впоследствии был стандартизирован. Если говорить о языке програмирования С#, то здесь лучше всего и быстрее всего работает технология ASP .NET, разработанная компанией Microsoft. С помощью ASP .NET можно создавать сайты любого уровня сложности - от самых простых, состоящих из нескольких страниц, до очень сложных, обрабатывающих миллионы запросов в день. Сайты Microsoft, написанные на ASP .NET, являются одними из самых посещаемых в Интернет.

Java -- объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems (в последующем приобретённой компанией Oracle). Приложения Java обычно компилируются в специальный байт-код, поэтому они могут работать на любой виртуальной машине вне зависимости от компьютерной архитектуры. Достоинство подобного способа выполнения программ состоит в полной независимости байт-кода от операционной системы и оборудования, что позволяет выполнять Java-приложения на любом устройстве, для которого существует соответствующая виртуальная машина. Другой важной особенностью технологии Java является гибкая система безопасности благодаря тому, что исполнение программы полностью контролируется виртуальной машиной. Любые операции, которые превышают установленные полномочия программы (например, попытка несанкционированного доступа к данным или соединения с другим компьютером) вызывают немедленное прерывание.

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

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

2.1.2 Выбор хранилища данных

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

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

При проектировании системы управления базами данных были рассмотрены следующие серверы баз данных: MySQL и PostgreSQL.

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

Основное преимущество MS SQL Server заключается в тесной интеграции ее с другими программными продуктами от Microsoft. MS SQL Server активно использует решения на базе СОМ технологии, в частности источники данных OLEDB и компоненты ActiveX. Данная СУБД отлично интегрируется как с MS Exchange, так и с Microsoft Internet Information Server.

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

Основными преимуществами PostgreSQL являются широкие функциональные возможности, сравнимые с лучшими коммерческими СУБД, мощные и надёжные механизмы транзакций и репликации, легко расширяемая система типов, поддержка со стороны многих языков программирования -- C, Java, Perl, PHP, Python и др. Язык запросов PostgreSQL соответствует стандартам ANSI SQL92 и SQL99.

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

2.1.3 Инструментальные средства для проектирования слоя представления

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

ASP.NET -- технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформы Microsoft.NET и развитием более старой технологии Microsoft ASP.

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

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

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

2.1.4 Инструментальные средства для проектирования слоя бизнес-логики

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

ADO.NET предоставляет согласованный доступ к таким источникам данных, как SQL Server и XML, а также к источникам данных, предоставляемым при помощи OLE DB и ODBC. Пользовательские приложения, использующие общие данные, могут использовать ADO.NET для соединения с этими источниками данных и для получения, обработки и обновления имеющихся в них данных. ADO.NET разделят доступ к данным и обработку данных на дискретные компоненты, которые могут использоваться отдельно или совместно. ADO.NET включает поставщиков данных .NET Framework для соединения с базой данных, выполнения команд и получения результатов.

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

2.1.5 Инструментальные средства для проектирования слоя интеграции

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

NHibernate - это ORM-система, позволяющая создавать абстрагированный от конкретной базы данных объектно-ориентированный data access layer. Связи между data objects и таблицами базы данных определяются через mappings, прописываемые программистом в XML-файле.

Fluent NHibernate - надстройка над NHibernate, позволяющая прописывать mappings вместо XML через .NET-классы посредством лямбда-выражений, т.е. более удобным и защищенным от ошибок способом.

2.2 Разработка архитектуры приложения

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

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

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

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

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

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

Подсистема отображения отвечает за отображение графического интерфейса системы.

На рисунке 2.1 изображена архитектура разрабатываемой системы.

Рисунок 2.1 - Архитектура ИКС отдела тестирования програмного обеспечения

2.3 Разработка структуры программной подсистемы

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

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

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

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

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

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

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

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

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

– модуль управления заявками;

– модуль управления дефектами;

– модуль управления воспроизведения дефекта;

– модуль управления пользователями;

– модуль управления клиентами;

– модуль управления проектами.

Рисунок 2.2 - Структура программной подсистемы ИКС отдела тестирования программного обеспечения

Модуль управления заявками позволяет создавать, удалять, редактировать заявки. Также он осуществляет поиск по заданным критериям. Данный модуль взаимодействует с модулями управления дефектами и проектами.

Модуль управления дефектами предназначен для создания, изменения информации о дефектах, их важности, к какому проекту относиться дефект. Данный модуль взаимодействует с модулем воспроизведения дефектов.

Модуль управления воспроизведения дефектами предназначен для описания шагов воспроизведения дефекта и результата данных действий.

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

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

Модуль управления клиентами позволяет добавлять, удалять информацию о клиентах.

2.4 Разработка классов сущностей системы

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

Рисунок 2.3 - Диаграмма классов основных сущностей системы

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

Класс User предназначенный для хранения абстрактной сущности представляющей пользователя. Класс содержит поля описывающие ФИО пользователя, адрес, стать, логин, пароль и электронный адрес.

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

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

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

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

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

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

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

Рисунок 2.4 - Реляционная схема базы данных

2.5 Определение вариантов использования данной системы

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

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

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

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

2.5.1 Варианты использования для сущности «Гость»

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

Рисунок 2.5 - Диаграмма вариантов использования для сущности «Гость»

2.5.2 Варианты использования для сущности «Автор задания»

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

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

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

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

Диаграмма вариантов использования для сущности «Автор задания» системы представлена на рисунке 2.6.

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

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

Рисунок 2.6 - Диаграмма вариантов использования для сущности «Автор задания»

2.5.3 Диаграмма вариантов использования для сущности «Исполнитель задания»

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

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

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

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

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

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

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

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

Диаграмма вариантов использования для сущности «Автор задания» системы представлена на рисунке 2.7



Рисунок 2.7 - Диаграмма вариантов использования для сущности «Исполнитель задания»

2.5.4 Диаграмма вариантов использования для сущности «Руководитель»

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

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

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

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

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

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

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

Диаграмма вариантов использования для сущности «Руководитель» системы представлена на рисунке 2.8

Рисунок 2.8 - Диаграмма вариантов использования для сущности «Руководитель»

2.5.5 Диаграмма вариантов использования для сущности «Администратор»

Администратор - тот, на кого возложена обязанность администрирования системы. Это может быть как отдельный сотрудник, так и руководитель задания. Он использует эту систему для добавления новых пользователе и ее редактирования.

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

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

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

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

Рисунок 2.9 - Диаграмма вариантов использования для сущности «Администратор»

2.6 Разработка аппаратной подсистемы

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

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

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

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

ЛВС - это совместное подключение нескольких отдельных компьютерных рабочих мест к единому каналу передачи данных. ЛВС в наши дни встречаются почти повсеместно. Этим обусловлена актуальность данной работы.

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

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

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

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

- организация общего доступа в сеть Интернет;

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

2.6.1 Описание целей и сферы деятельности компании

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

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

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

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

План здания отображен на рисунке 2.10

2.6.2 Разработка архитектуры локальной вычислительной сети

Разбиение сети на сегменты было проведено с целью оптимизации сетевого трафика и/или повышения безопасности сети в целом. Каждый физический сегмент сети ограничен сетевым устройством уровня 2 модели OSI (таким как коммутатор), обеспечивающим соединение узлов сегмента с остальной сетью.

Как правило, сеть разделяют на демилитаризованную зону и основную приватную сеть c помощью «внешнего» маршрутизатора. Если необходима защита отдельных отделов предприятия от остальных, то дополнительно вводится безопасная внутренняя сеть, которая отделяется от основной приватной сети «внутренним» маршрутизатором.