Отчет по практике: Автоматизация процессов на предприятии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Обоснование проектных решений

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

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

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

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

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

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

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

4. Статус;

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

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