Вход

Проектирование информационной системы поддержки процесса тестирования интернет-порталов

Рекомендуемая категория для самостоятельной подготовки:
Дипломная работа*
Код 233913
Дата создания 10 июня 2016
Страниц 64
Мы сможем обработать ваш заказ (!) 28 марта в 13:00 [мск]
Файлы будут доступны для скачивания только после обработки заказа.
2 880руб.
КУПИТЬ

Описание

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

Содержание

Введение 3
Глава 1. Анализ процесса тестирования интернет-порталов и формирование требований к информационной системе «Инвентос» 6
1.1 Описание ЗАО «Инвентос». Виды услуг, оказываемых предприятием 6
1.2 Описание существующих бизнес-процессов в ЗАО «Инвентос» 14
1.3 Анализ успешных ИТ-проектов в сфере тестирования интернет-порталов 18
1.4 Постановка задачи проектирования системы поддержки процесса тестирования интернет-порталов. Определение требований к системе 23
Глава 2. Проект информационной системы поддержки процесса тестирования интернет-порталов 27
2.1 Проектирование процесса тестирования в методологии IDEF0 27
2.2 Техническое задание на создание ИС поддержки процесса тестирования интернет-порталов 34
2.3 Проектирование прав доступа пользователей ИС поддержки процесса тестирования интернет-порталов в нотации языка UML 40
2.4 План проекта по созданию ИС поддержки процесса тестирования интернет-порталов 47
Заключение 52
Библиографический список 54
Приложение А 57
Приложение Б 58
Приложение В 59
Приложение Г 61

Введение

В течение последних десятилетий компьютерные системы и использу-емое на них программное обеспечение стало вовлечено во все области человеческой деятельности. Повсеместное использование программных средств привело к такому положению дел, когда мы уже не представляем себе эффективного и удобного рабочего процесса без их применения.
То же самое можно сказать и про сеть Интернет – в последние годы она стремительно развивается, проникая как в общественную и культурную жизнь, так и в подавляющее большинство сфер бизнеса. На данный момент количество зарегистрированных доменов в сети находится на уровне 145 миллионов [31], и их число каждый день увеличивается. Создание собственных сайтов играет существенную роль в большинстве сфер бизнеса; более того, монетизационная модель множества компаний, так их как Яндекс и Google, заключается исключительно в получении прибыли от интернет-сервисов за счет рекламы [20], платного контента, пожертвований пользователей и т. п.
Интернет-сервисы могут приносить существенную прибыль, что влечет высокую конкуренцию в этой сфере деятельности. Но, в то же время, даже небольшие ошибки, допущенные при разработке, могут повлиять на выбор пользователя относительно того, какой из конкурирующих сервисов ему предпочесть.
Поэтому, как и во многих других областях, тестирование играет очень важную роль в процессе создания веб-сайтов и разработке интернет-сервисов. Разработка сайта подразумевает под собой решение множества задач из совершенно разных областей, таких как: работа с большими объемами данных, вычислительные системы, сетевая безопасность, дизайн и прочее. Контроль надежности и безопасности вновь создаваемых или улучшения существующих сайтов должен сопровождать весь их жизненный цикл [5]. Следовательно, сайты нужно тестировать на протяжении всех этапов их разработки и применять различные методы и виды тестирования. В данной работе будет затронута проблема тестирования сайтов только на завершающем этапе их разработки.
Безусловно, тестирование сайта на завершающем этапе его разработки имеет чрезвычайную важность для IT-компании, занимающейся созданием сайтов, поскольку она несет ответственность за выполнение условий договора с заказчиком, и может понести убытки в том случае, если конечный продукт не будет соответствовать оговоренным требованиям. Зачастую ошибки, возникающие в процессе создания сайта, не видны невооруженным глазом, но при определенных действиях пользователей могут вызвать сбои в его функционировании. Кроме того, сайт может иметь уязвимости безопасности, которые позволят злоумышленникам завладеть конфиденциальной информацией. К тому же, качество сайта в современном мире определяет лицо компании, а недостаточно хорошо проведенное тестирование впоследствии может вызвать недовольство потенциальных клиентов.
Целью данной работы является проектирование информационной системы (ИС) поддержки процесса тестирования интернет-порталов для соблюдения очередности проведения тестирования в соответствии с планом тестирования и оптимизации затрат времени на отдельных его этапах.
Задачи:
1) рассмотреть виды услуг, оказываемых предприятием;
2) исследовать и сравнить ИС поддержки процесса тестирования ин-тернет-порталов, предлагаемые на рынке, аналогичные используемой на предприятии;
3) выполнить функциональное моделирование процесса тестирования сайтов на основе методологии IDEF0 и объектно-ориентированное на основе методологии UML;
4) осуществить оптимизацию бизнес-процесса «Подготовить тестовые случаи»;
5) написать техническое задание на разработку ИС поддержки процесса тестирования интернет-порталов;
6) рассчитать затраты на разработку ИС поддержки процесса тестирования интернет-порталов;
7) разработать план проекта по созданию ИС поддержки процесса тестирования интернет-порталов.
Объектом исследования в текущей работе является процесс тестирова-ния сайтов в ЗАО «Инвентос».
Предмет исследования – информационные технологии поддержки процесса тестирования интернет-порталов.
Работа состоит из введения, двух глав, заключения, библиографического списка и приложений.
Во введении обоснована актуальность темы исследования, определены объект и предмет исследования, сформулирована цель и основные задачи, описана структура работы.
В первой главе описывается организация, рассматриваются оказываемые ею услуги, описывается бизнес-процесс «Разработка сайта», принятый в организации. Также глава содержит теоретические сведения по вопросам тестирования сайтов, в ней анализируются существующие на рынке программные решения, и на их основе предлагается оптимизация процесса «Подготовить тестовые случаи».
Во второй главе работы производится проектирование, осуществляется построение необходимых диаграмм с помощью методологии описания бизнес-процессов IDEF0 и создание диаграмм в нотации UML, рассчитываются затраты на разработку ИС, пишется техническое задание и план по управлению проектом.
В заключении подведены основные итоги работы.
Библиографический список включает перечень источников, которые были использованы при написании работы.
В приложении представлен бизнес-процесс разработки сайтов в «Ин-вентос», сравнительные характеристики современных систем управления тестированием и перечень задач для составления временного графика работ.

Фрагмент работы для ознакомления

Testlink — это инструмент для управления тест-кейсами (test case managment), распространяемый по лицензии GPL.К сущностям TestLink относятся: - Test Case – описание тест-кейса в виде последовательности шагов и ожидаемых результатов. - Test Suite – набор тест-кейсов, позволяющий структурировать все тесты в логичной форме.- Test Plan – создается при переходе к выполнению тестов. Тест-планы состоят из какого-либо набора тест-кейсов или Test Suite текущего проекта. - Test Project – проект, который существует на протяжении всего цикла тестирования и соответствует тестируемому приложению. Тестовый проект в течение жизненного цикла может сменить несколько версий и развиваться вместе с приложением. - Build – Соответствует билду, или серьезной модификации тестируемого приложения. - Platform – платформа, на которой производится тестирование. В качестве платформы может выступать операционная система (Windows, Linux etc.), браузер для веб-приложений (Chrome, Firefox etc.), различные варианты серверов (Apache, Tomcat etc.) и баз данных (MySql, MSSQL etc.) - Keyword – ключевые слова, предназначенные для группировки тест-кейсов по какому-либо признаку.- Requirements – требования к приложению, которые необходимо покрыть тестами [7]. К ним осуществляется привязка тест-кейсов, на основании которой производится формирование отчета о покрытии требований. Набор отчетов включает:- метрики выбранной сборки, в которые входят таблицы результаты-по-приоритету, результаты-по-компоненту, результаты-по-категории, результаты-по-ключевому-слову- отчеты по пройденным тест кейсам для каждого билда, компонента, ключевого слова. Отчет для каждого тест кейса по выявленным багам. Отчет о выполнении требований: какие тест кейсы каких требований прошли, какие не проверялись, какие провалились, какие заблокированы.В Testlink имеются роли пользователей, которые обладают разными правами. Планы тестирования (Test Suite) имеют отдельные права, которые надо выдавать, и в этом случае права на чтение/запись зависят от роли пользователя. Права на Test Suite могут выдавать администраторы или лидеры (роли admin, leader). Создание и конфигурирование продуктов, компонентов и ролей пользователей осуществляется администратором.К достоинствам TestLink можно причислить:- распространение по лицензии GPL, т. е. бесплатно,- удобное распределение тестов между тестировщиками,- импорт/экспорт тестов в формате .xml,- возможность гибкой настройки прав пользователей.К недостаткам TestLink относятся:- интерфейс, основанный на использовании фреймов, что влечет отсутствие ссылок на отдельные страницы внутри системы. Навигация производится путем выбора проекта, группы тестов и номера теста,- отсутствие возможности создавать фиксированный набор отчетов сразу по нескольким планам тестирования,- привязка тестовых случаев к проекту,- отсутствие настраиваемых полей.Сравнение исследуемых систем управления тестированием производилось по следующим критериям и их производным:- стоимость лицензии, под которой распространяется система,- поддержка разных видов и версий браузеров,- функционал управления тестами (наличие удобного создания тест-кейсов, ведение статистики прохождения и возможность получения наглядной отчетности),- наличие элементов тест-менеджмента,- удобство использования системы.Информация по ключевым характеристикам перечисленных систем управления тестированием наглядно представлена в приложении В.1.4 Постановка задачи проектирования системы поддержки процесса тестирования интернет-порталов. Определение требований к системеС учетом характера своей деятельности, «Инвентос» каждодневно сталкивается с проблемой выбора оптимального объема тестирования своих продуктов, балансируя на грани между недостаточным и избыточным тестированием. Внедрение системы управления тестированием поможет более точно определять сроки и объемы проведения тестирования, которые требуются для того или иного продукта [14].С нашей точки зрения, к наиболее важным критериям, которые определяют потребности «Инвентос» в тестировании своих продуктов, нужно отнести следующие:- соблюдение очередности проведения тестирования в соответствии с планом тестирования, принятым в «Инвентос» для конкретного задания заказчика,- возможность загрузки системы в облако, чтобы команда тестирования могла получать к ней доступ в любом месте и в любое время,- возможность использования системы как в локальной сети, так и в облаке,- надежность и безопасность системы,- гибкий интерфейс, который позволит настроить систему под конкретные требования членов команды тестирования,- стоимость лицензии системы управления тестированием, соизмеримую с частотой ее использования и полнотой ее функционала,- возможность получения наглядных и подробных отчетов по каждому из проектов,- возможность в будущем связать систему с автоматическим тестированием и запуском написанных авто-тестов.Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт «хорош» с точки зрения заинтересованных сторон, таких как заказчик продукта, спонсор, конечный пользователь, разработчики и тестировщики продукта, инженеры поддержки, сотрудники отделов маркетинга, обучения и продаж. Каждый из участников может иметь различное представление о продукте и о том, насколько он хорош или плох, то есть о том, насколько высоко качество продукта. Таким образом, постановка задачи обеспечения качества продукта выливается в задачу определения заинтересованных лиц, их критериев качества и затем нахождения оптимального решения, удовлетворяющего этим критериям. Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения и входит в набор эффективных средств современной системы обеспечения качества программного продукта [5]. С технической точки зрения, тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам.В конечном счете, целью работ по тестированию является выявление и исправление ошибок в программном продукте до того, как он попадет к конечному пользователю.Результат анализа выбранных систем управления тестированием из предыдущих параграфов показал, что на данный момент ни один из существующих программных продуктов не удовлетворяет полностью поставленным критериям.Использование TestRail и Sitechco подразумевает покупку лицензий пропорционально количеству членов команды тестирования, что в долгосрочной перспективе влечет существенные материальные затраты, возможности TestRail в получении разнообразных отчетов весьма ограничены. TestLink имеет излишне запутанный и неудобный интерфейс, отсутствует возможность создавать фиксированный набор отчетов сразу по нескольким планам тестирования, нет возможности работы с чек-листами. Sitechco поддерживает не все популярные браузеры, что может отрицательно сказаться на предпочтениях группы тестирования. Тем не менее, некоторые функциональные особенности и программные решения рассмотренных систем могут послужить достойным образцом при проектировании новой системы.В ходе практического применения этих систем и выполнения заданий по тестированию сайтов, было отмечено, что использование чек-листов вместо тестовых случаев было бы более удобным как для тест-писателя, так и для тестировщика.Составление тестового случая предполагает детализацию каждого из шагов, а также описание начального состояния и результата, который следует ожидать от его выполнения. Это исключает возможность выполнения шагов не по порядку, а также увеличивает количество затрачиваемого тестировщиком времени на фиксацию промежуточных результатов каждого шага.К преимуществам применения тестовых случаев следует отнести подробность описания функций, которые необходимо протестировать, что значительно упрощает работу новых членов коллектива и дает им руководство к действию [21]. На рис. 1 представлена существующая модель подготовки тестовых случаев тест-писателем для дальнейшего использования тестировщиком.Рисунок 1 – Диаграмма AS IS «Подготовить тестовые случаи» A24Тест-писатель создает проект тестирования, в котором с помощью технического задания и принятого регламента тестирования определяет детализацию тестовых случаев. Далее создаются тестовые наборы, и пишутся тестовые случаи с разделением каждого из них по шагам. После этого тест-писатель распределяет тестовые случаи по тестовым наборам, которые уже пригодны для использования тестировщиком.В связи с этим было решено спроектировать собственную систему поддержки процесса тестирования, которая будет иметь функционал, удовлетворяющий всем требованиям «Инвентос». Преимуществом данного выбора является то, что все функциональные возможности системы будут выполнены под требования фирмы и будут иметь должные уровни надежности и безопасности, не исключая возможности ее дальнейшей модернизации.Глава 2. Проект информационной системы поддержки процесса тестирования интернет-порталов2.1 Проектирование процесса тестирования в методологии IDEF0Для того чтобы понять, как работает система, которую требуется автоматизировать, и как распределены обязанности между участниками, необходимо построить ее модель. Было решено сделать это с использованием вербального описания и диаграмм в методологии IDEF0. Проектирование проведено с помощью программного продукта Ramus Educational.Целью проектирования является упорядочение процесса тестирования, оптимизация затрат времени и автоматизация ведения отчетности. Диаграммы построены с точки зрения менеджера отдела тестирования.Как видно из контекстной диаграммы верхнего уровня A-0 (рис. 2), вход функционального блока представлен сайтом, который подается заказчиком для тестирования и получения отчета. Рисунок 2 – Контекстная диаграмма верхнего уровня A-0В состав команды участников процесса тестирования входят менеджер, тест-лидер, тест-писатели и тестировщики, деятельность которых непосредственно связана с работой в программе поддержки процесса тестирования. Заказчик, техническое задание, а также регламент тестирования и регламент компании, выступая со стороны управления, определяют условия, необходимые команде тестирования, чтобы произвести надлежащий отчет о тестировании.Содержание контекстной диаграммы верхнего уровня раскрывает дочерняя диаграмма A0 (рис. 3), в которой пошагово представлена вся деятельность команды тестирования сайта в ходе его тестирования.Рисунок 3 – Диаграмма процесса тестирования сайта A0Дальнейшая декомпозиция диаграммы A0 позволяет достаточно подробно описать каждый из этапов процесса тестирования сайта.На первом этапе менеджер получает от заказчика задание по тестированию сайта, после чего, совместно с тест-лидером и тест-писателями, изучает и уточняет детали технического задания (рис. 4). Далее принимается решение о предполагаемых сроках тестирования и дате его начала. Итогами первого этапа становятся подписание договора заказчиком и решение менеджера о начале тестирования [4].Рисунок 4 – Диаграмма «Изучить предстоящее задание» A1На втором этапе тест-лидер определяет перечень тестируемых компонентов сайта, способы и стратегию тестирования, а также условия достижения целей тестирования, используя программу поддержки процесса тестирования (рис. 5).Далее тест-писатели формируют список тестовых случаев и определяют роли участников процесса тестирования и график их работ. Итогом этапа является тест-план, согласно которому будет продвигаться ход тестирования сайта.На третьем этапе тестировщики выполняют тестовые случаи и вносят полученные результаты в программу поддержки процесса тестирования (рис. 6).Если при выполнении тестовых случаев обнаруживаются ошибки в компонентах, не оговоренных в тест-плане, они также подлежат фиксации. Итогом этапа являются результаты тестирования сайта.Рисунок 5 – Диаграмма «Написать тест-план» A2Рисунок 6 – Диаграмма «Прогнать тесты» A3На четвертом этапе тест-лидером производится оценка результатов тестирования: оценивается достаточность количества протестированных компонентов сайта, степень тестового покрытия, степень достижения целей тестирования и степень выполнения тест-плана (рис. 7). В случае если результат удовлетворителен, осуществляется переход к следующему этапу. Для неудовлетворительного результата производится возврат ко второму этапу и внесение изменений в тест-план.Рисунок 7 – Диаграмма «Оценить результаты тестирования» A4Пятый этап включает в себя подготовку отчета о тестировании, в котором указывается состав команды тестирования, описываются произведенные процессы, изменения и дополнения тестовой модели (если таковые имели место), процент пройденных тестовых случаев и подробное описание найденных ошибок, хронология пройденных этапов и общая оценка результатов тестирования (рис. 8).Рисунок 8 – Диаграмма «Подготовить отчеты» A5С применением программы поддержки процесса тестирования тест-лидер формирует, просматривает и редактирует отчет, который в дальнейшем передается заказчику.Использование чек-листов на этапе написания тест-плана подразумевает составление тест-писателем пунктов, по которым впоследствии необходимо протестировать сайт [4]. Это позволит избежать перечисленных выше недостатков, присущих тестовым случаям, а также сократить затраты времени опытных членов команды тестирования.Как видно из рис. 9, использование чек-листов вместо тестовых случаев значительно упростило бы процесс работы тест-писателя. Тест-писатель также создает проект тестирования, в котором с помощью технического задания и принятого регламента тестирования определяет детализацию тестовых случаев. После этого он формирует чек-лист, состоящий из пунктов, которые следует протестировать. Также следует отметить, что внедрение прогона тестов по чек-листам ускоряет работу тестировщика (рис. 10).Рисунок 9 – Диаграмма AS TO BE «Подготовить тестовые случаи» A24Рисунок 10 – Диаграмма AS TO BE «Прогнать тесты» A3Тестировщик выполняет тестирование согласно требованиям, указанным в пунктах, после чего вносит в программу поддержки процесса тестирования полученную информацию об обнаруженных багах. Затем он присваивает этому пункту значение, соответствующее уровню степени прохождения, и переходит к следующему.Таким образом, использование системы поддержки процесса тестирования, основанной на чек-листах, поможет более рационально использовать временные ресурсы отдела тестирования и избежать простоев в работе. Преимуществом данного выбора также является то, что все функциональные возможности системы будут выполнены под требования фирмы и будут иметь должные уровни надежности и безопасности, не исключая возможности ее дальнейшей модернизации.2.2 Техническое задание на создание ИС поддержки процесса тестирования интернет-порталов1. Общие сведения1.1. Наименование системы1.1.1. Полное наименование.Информационная система поддержки процесса тестирования интернет-порталов.1.1.2. Краткое наименование системы.TMS: Инвентос.2. Назначение и цели создания системы2.1. Назначение системыTMS: Инвентос предназначена для упорядочения и автоматизации процесса тестирования сайтов отделом тестирования.Основным назначением TMS: Инвентос является автоматизация процесса тестирования сайтов, оптимизация бизнес-процесса «Тестировать сайт» и автоматизация ведения отчетности.2.2. Цели создания системыTMS: Инвентос создается с целями:•соблюдение очередности проведения тестирования в соответствии с планом тестирования, принятым в «Инвентос» для конкретного задания заказчика;•возможность загрузки системы в облако;•возможность использования системы исключительно в локальной сети;•широкий функционал (наличие шаблонов, автосохранения, импорта/экспорта, окружения/сборки/требований, подсказок, горячих клавиш, печати, ссылок на разделы системы, планировщика задач, кроссбраузерности, e-mail уведомлений, потенциальной поддержки авто-тестов);•гибкий настраиваемый интерфейс (наличие конструктора графического интерфейса пользователя, фреймов, графических тем, панели навигации, изменение параметров шрифта и масштаба);•возможность получения наглядных и подробных отчетов по каждому из проектов (по дате и времени выполнения, окружениям, сборкам, компонентам, пользователям, покрытию требований, по результату, по статусу тестирования).Результатами создания системы управления тестированием должны стать следующие изменения:-уменьшение затрат времени на тестирование сайтов;-улучшение качества работы отдела тестирования и выходных результатов;-повышение удобства процесса тестирования,-увеличение объемов продаж благодаря ускорению процесса тестирования.3. Характеристика объектов автоматизацииСтруктурное подразделениеНаименование процессаВозможность автоматизацииРешение об автоматизации в ходе проектаОтдел тестированияТестирование сайтаВозможнаБудет автоматизирован4. Требования к системе4. Требования к системе в целом.4.1. Требования к структуре и функционированию системы.Система должна быть централизованной, т.е. все данные должны располагаться в центральном хранилище с возможностью использования, как в локальной сети, так и в глобальной.4.2. Требования к численности персонала.В состав персонала, необходимого для обеспечения эксплуатации системы в рамках соответствующих подразделений Заказчика, необходимо выделение следующих ответственных лиц:- Администратор системы - 1 человек.- Специалист технической поддержки - 3 человека.Данные лица должны выполнять следующие функциональные обязанности:- Администратор системы - на всем протяжении функционирования TMS обеспечивает штатную работу системы и информационную безопасность организации.- Специалист технической поддержки - на всем протяжении функционирования TMS обеспечивает поддержку пользователей.4.3. Требования к квалификации персонала.К квалификации персонала, эксплуатирующего Систему, предъявляются следующие требования:- Менеджер должен заниматься поиском потенциальных заказчиков, заключать договора на разработку системы, отвечать за планирование сроков и ресурсов, заниматься управлением и контролем над ходом выполнения проекта, взаимодействовать с заказчиком [3];- Тест-лидер должен распределять ресурсы отдела между различными проектами, отвечать за сроки тестирования новых версий продуктов, принимать решение о соответствии продуктов принятым в компании стандартам качества [16].- Тест-писатель должен формировать содержание чек-листов для прогона тестировщиками по каждому тестируемому сайту.- Тестировщик должен выполнять тесты с учетом тестового плана и документировать выявленные дефекты.4.4. Функциональные возможности пользователей системы.Заказчик:1.Операции с техническим заданием.а)Добавление.б)Просмотр/редактирование.в)Удаление.2.Операции с отчетами.а)Просмотр.Менеджер:1.Операции с текущими делами.а)Создание.б)Принятие решения о начале тестирования.в)Определение сроков.г) Отправка в архив.2.Операции с техническим заданием.а)Просмотр.б)Уточнение деталей.Тест-лидер:1.Операции с техническим заданием:а)Просмотр.б)Уточнение деталей.2.Операции с тест-планом:а)Создание.б)Просмотр/редактирование.в) Удаление.3.Операции с отчетами.а)Создание.б)Просмотр/редактирование.в) Удаление.Тест-писатель:1.Операции с тест-планом.а)Просмотр.2.Операции с чек-листами.а)Добавление.б)Просмотр\редактирование.в)Удаление.3.Операции с техническим заданием:а)Просмотр.б)Уточнение деталей.Тестировщик:1.Операции с чек-листами:а)Прогон.б)Присвоение значения степени прохождения.в) Просмотр.г)Внесение информации о дополнительно обнаруженных багах.1.Операции с тест-планом.а)Просмотр.4.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.

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

1. Аалст, В. Управление потоками работ: модели, методы и системы. Пер. с англ. [текст] / В. Аалст, К. Хей. – М.: ФИЗМАТЛИТ, 2011. – 320 с.
2. Бариленко, В. Бизнес-анализ как важный вид консалтинговых услуг / В.И. Бариленко. – М.: РИСК: Ресурсы, Информация, Снабжение, Конкуренция [текст] , 2012. – 207 с.
3. Баронов, В. Информационные технологии и управление предприятием [текст] / В. В. Баронов. – М.: Академия АйТи, 2013. – 326 с.
4. Бек, К. Экстремальное программирование: разработка через тестирование [текст] / К. Бек. – СПб.: Питер, 2010 г. – 224 с.
5. Блюмин, А. Проектирование систем информационного, консульта-ционного и инновационного обслуживания: учеб. пособие [текст] / А. М. Блюмин, Л. Т. Печеная, Н. А. Феоктистов. – М.: Дашков и К°, 2008. – 348 с.
6. Буч, Г. Язык UML. Руководство пользователя [текст] / Г. Буч, Д. Рамбо. – М.: ДМК Пресс, 2012. – 381 с.
7. Вигерс, К. Разработка требований к программному обеспечению. Пер. с англ. [текст] / К. И. Вигерс. – М.: Издательско-торговый дом «Русская редакция», 2014. – 416 с.
8. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Си-стемная и программная инженерия. Процессы жизненного цикла программных средств. Введ. 01.03.2012. – М.: Стандартинформ, 2011. – 106 с.
9. ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств». – М.: ГОССТАНДАРТ РОССИИ, 2000. – 76 с.
10. ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды»
11. ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. Введ. 01.01.92. М.: Стандартинформ, 1992. – 6 с.
12. ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Введ. 01.01.90. – М.: Стандартинформ, 2009. – 12 с.
13. Гультяев, А. Microsoft Office Project 2003 [текст] / А.К. Гультяев. – СПб.: Корона-принт, 2004. – 245 c.
14. Калбертсон, Р. Быстрое тестирование [текст] / Р. Калбертсон, К. Браун, Г. Кобб. – М.: Вильямс, 2014. – 384 с.
15. Карлберг, К. Бизнес-анализ с использованием Excel. Решение бизнес-задач, 4-е издание [текст] / К. Карлберг. – М.: Вильямс, 2013. – 576 с.
16. Липаев, В. Качество программных средств. Методические рекомендации. Под общей ред. проф., д. т. н. А.А. Полякова [текст] / В. В. Липаев. – М.: Янус-К, 2009. – 400 с.
17. РД 50.1.028-2001. Методология функционального моделирования IDEF0. – М.: ИПК Издательствово стандартов, 2000. – 75 с.
18. Савин, Р. Тестирование Дот Ком. [текст] / Р. Савин. – М.: Дело, 2008. – 312 с.
19. Смирнова, Г. Проектирование экономических информационных систем: Учебник для студентов экономических вузов, обуч. по спец.: «При-кладная информатика в экономике», «Прикладная информатика в менедж-менте», «Прикладная информатика в юриспруденции». [текст] / Г. Н. Смирнова. – М.: Финансы и статистика, 2013. – 511 с.
20. Уиттакер, Д. Как тестируют в Google [текст] / Д. Уиттакер, Д. Ар-бон, Д. Каролло. – СПб: Питер, 2014. – 320 с.
21. Фёдоров, Н. Проектирование информационных технологий на основе современных CASE-технологий. [текст] / Н.В. Федоров. – М.: МГИУ, 2007. – 113 с.
22. Шаллоуей, А. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию. Пер. с англ. [текст] / А. Шаллоуей, Трот, Р. Джеймс – М.: Издательский дом «Вильямс», 2012. – 288 с.
23. ISO/IEC 2382-1:1993. Information technology – Vocabulary – Part 1: Fundamental terms
24. ISO 9001:2008-12 Quality management systems - Requirements
25. Государственный университет – учебно-научно-производственный комплекс [Электронный ресурс] // Сайт: http://gu-unpk.ru – режим доступа: http://gu-unpk.ru/pk/deserve/material04
26. Инвентос [Электронный ресурс] // Сайт: http://inventos.ru/ – режим доступа: http://inventos.ru/about/#top
27. Портал специалистов по тестированию и обеспечению качества ПО [Электронный ресурс] // Сайт: http://software-testing.ru/ – режим доступа: http://www.software-testing.ru/library/testing/general-testing?layout=default
28. Портал TMGURU: Стартовая страница успешных тест-менеджеров [Электронный ресурс] // Сайт: http://tmguru.ru – режим доступа: http://tmguru.ru/baza-znanij/upravlenie-testami/instrumenty-dlya-planirovaniya/testrail/
29. Спецификация UML [Электронный ресурс] // Сайт: http://www.uml.org/ – режим доступа: http://www.omg.org/gettingstarted/what_is_uml.htm
30. Хабрахабр [Электронный ресурс] // Сайт: http://habrahabr.ru – режим доступа: http://habrahabr.ru/post/242025/
31. Whois, Domain Counts & Internet Statistics [Электронный ресурс] // Сайт: http://www.whois.sc – режим доступа: http://www.whois.sc/internet-statistics/
Очень похожие работы
Пожалуйста, внимательно изучайте содержание и фрагменты работы. Деньги за приобретённые готовые работы по причине несоответствия данной работы вашим требованиям или её уникальности не возвращаются.
* Категория работы носит оценочный характер в соответствии с качественными и количественными параметрами предоставляемого материала. Данный материал ни целиком, ни любая из его частей не является готовым научным трудом, выпускной квалификационной работой, научным докладом или иной работой, предусмотренной государственной системой научной аттестации или необходимой для прохождения промежуточной или итоговой аттестации. Данный материал представляет собой субъективный результат обработки, структурирования и форматирования собранной его автором информации и предназначен, прежде всего, для использования в качестве источника для самостоятельной подготовки работы указанной тематики.
bmt: 0.00535
© Рефератбанк, 2002 - 2024