Анализ существующих разработок и выбор стратегии автоматизации «КАК ДОЛЖНО БЫТЬ»

3. Анализ существующих разработок и выбор стратегии автоматизации «КАК ДОЛЖНО БЫТЬ»

  3.1 Анализ существующих разработок для автоматизации задачи

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

1.  Microsoft Visual Studio 2010 Test Professional

Microsoft® Visual Studio® 2010 Test Professional – специализированный набор средств для групп контроля качества, который упрощает планирование и выполнение ручных тестов. Test Professional используется вместе со средой Visual Studio, что обеспечивает эффективную совместную работу разработчиков и тестеров в течение всего цикла разработки приложения.

Преимущества:

·  Эффективное координирование совместной деятельности групп;

·  Более широкое покрытие кода тестами благодаря произвольному тестированию;

·  Полная прозрачность процесса тестирования;

·  Информативные отчеты об ошибках для разработчиков;

·  Автоматизация повторяющихся задач;

·  Встроенные средства приоритезации тестов;

·  Упрощенное управление виртуальной лабораторией тестирования;

·  Управление рабочими элементами;

·  Полная прослеживаемость действий;

·  Отчёты:

2.  Atlassian JIRA

3.  Atlassian JIRA – коммерческая система отслеживания ошибок, предназначена для организации общения с пользователями, хотя в некоторых случаях систему можно использовать для управления проектами. Разработана компанией Atlassian Software Systems. Платная.

Движения задач / дефектов:

Отчёты и диаграммы

4.  Разработка собственного АРМ специалиста по тестированию

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

В основу конструирования АРМ положены следующие основные принципы:

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

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

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

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

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

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

3.2 Выбор и обоснование стратегии автоматизации задачи

Обычно разработка систем автоматизации специалистами осуществляется в несколько этапов:

-  Определение типа автоматизированной системы;

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

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

-  Разработка внешнего оформления (дизайна), согласование;

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

-  Тестирование всех модулей, и внедрение;

Существует четыре варианта стратегии автоматизации:

o  хаотичная;

o  по участкам;

o  по направлениям;

o  полная;

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

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

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

Полная автоматизация предполагает автоматизацию абсолютно всех бизнес-процессов компании.

Компания ООО «Вип Ай Ти Маркет» имеет небольшой размер и довольно высокие темпы развития. Поэтом наиболее целесообразной стратегией принято использовать вторую модель автоматизации: автоматизации по участкам (отдел тестирования). С возможностью расширить систему до автоматизации по направлению (полная разработка).

Разработка и внедрение автоматизированной системы документооборота отдела тестирования в компании ООО «Вип Ай Ти Маркет» будет осуществляться следующим образом:

1.  Предпроектный аудит.

2.  Компания-разработчик вместе с Заказчиком проводят предпроектное исследование автоматизируемого участка. Определяются функциональные требования.

3.  Выбор оптимального решения.

На втором этапе Заказчик с Разработчиком выбирают максимально эффективный вариант реализации системы автоматизации.

4.  Разработка технического задания.

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

5.  Кодирование.

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

6.  Тестирование.

Проверка работоспособности программы на платформе Заказчика. Все выявленные ошибки отправляются Разработчику на доработку.

7.  Сдача проекта.

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

 

3.3 Выбор и обоснование способа приобретения ИС для автоматизации комплекса задач

Существуют различные варианты разработки и внедрения автоматизированных систем документооборота:

·  Разработка системы собственными ресурсами.

·  Использование стороннего разработчика.

·  Использование прототипов.

·  Приобретение готовой системы.

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

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

Использование прототипов – довольно гибкий вариант. Но в настоящее время системы управления тестированием не сильно распространены. А использование прототипов сторонней тематики может обернуться непониманием специалистов терминологии системы.

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

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

4. Обоснование проектных решений   4.1 Обоснование проектных решений по информационному обеспечению

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

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

Предлагается отображать в списке дефектов следующие атрибуты:

1.  ID рабочего элемента;

2.  Заголовок;

3.  Кому назначен дефект;

4.  Статус;

5.  Дата создания;

Каталог тестовых сценариев должен быть удобен для восприятия пользователем. Для этого его следует структурировать. Предлагается построить иерархическую модель тестов. В корне дерева будет находиться проект. Далее идёт разбиение по типам тестирования. У каждого типа подкаталоги объектов тестирования. Объекты тестирования могут быть любой вложенности. Самым младшим элементом является тестовый сценарий.

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

1.  ID рабочего элемента;

2.  Заголовок;

3.  Статус;

4.  Связанные дефекты;

5.  Дата выполнения;

 

4.2 Обоснование проектных решений по программному обеспечению

Программное обеспечение предлагается разрабатывать с использованием языка C#. Компилятор этого языка поставляется в составе Microsoft Visual Studio 2010. При выборе языка программирования учитывались функциональные возможности C#, его доступность и простота интеграции с Windows-приложениями. Для C# существует множество библиотек с уже готовыми объектами. Написано много учебной и научной литературы, в том числе на русском языке.

Чтобы не разрабатывать приложение «с нуля» рекомендуется использовать прототип в виде Microsoft Test Manager 2010.

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

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