Технологии создания программного обеспечения

Оглавление

 

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

Введение

Обзор сферы тестирования программного обеспечения

Статистические данные о рынке ПО

Стоимость ошибки

Рынок инструментов тестирования

Процесс жизненного цикла программной ошибки

Стадия стабилизации в Microsoft Solution Framework

Виды нефункционального тестирования

Разработка навигатора процесса стабилизации

Описание игры в стабилизацию

Разработка пространства программного продукта

Логика работы приложения

Навигатор процесса стабилизации как бизнес-инструмент

Заключение

Библиографический список

Приложения

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

АО - аппаратное обеспечение.

БД - база данных.

ЖЦ - жизненный цикл.

ИС - информационная система.

ИТ - информационные технологии.

ПО - программное обеспечение.

ПП - программный продукт.

ТЗ - техническое задание.

ЭВМ - электронно-вычислительная машина.- Microsoft Solution Framework.- Program Product Space, пространство программного продукта.- Service Pack, пакет обновления.- Test Driven Design, тест-ориентированная разработка.

Введение

Microsoft Solutions Framework (MSF) - методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки программного продукта. В методологии MSF в целом и на стадии стабилизации, в особенности, большое внимание уделяется таким параметрам ИС, как кроссплатформенность, кроссбраузерность, совместимость с различными форматами данных, версиями ПО, удобство использования, производительность при работе на ЭВМ различной мощности, с БД больших объемов, с доступом через глобальную сеть по имеющимся каналам связи и т.д.

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

Основная проблема состоит в том, что на текущий момент не существует ИС, моделирующей поведение программы во время тестирования.

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

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

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

Для достижения цели были поставлены следующий задачи:

.        Изучить технологию нефункционального тестирования.

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

нефункциональное тестирование программное обеспечение

3.      Изучить ИС, способствующие проведению нефункционального тестирования.

4.      Спроектировать ИС обучения нефункциональному тестированию.

.        Реализовать ИС обучения нефункциональному тестированию.

.        Провести практическую апробацию разработанной ИС.

Обзор сферы тестирования программного обеспечения

Ключевые понятия

Рассмотрим основные понятия, позволяющие в наибольшей мере раскрыть содержание работы. Первое из ключевых понятий: тестирование. В международном стандарте IEEE дается обобщенное определение этому понятию, которое можно применить не только к сфере ИТ, но и к любой другой системе: "Тестирование - это процесс выполнения или оценки системы или компонента системы вручную или с помощью автоматизированных средств для подтверждения ее соответствия заранее заданным требованиям или для обнаружения различий между ожидаемыми и действительными результатами работы системы (the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements or to identify differences between expected and actual results)" [17].

Г. Майерс (Glenford J. Myers) рассматривает термин тестирование, как процесс выполнения программы с целью обнаружения ошибок: "Testing is the process of executing a program with the intent of finding errors" [23]. Похожее определение дает А. Коробейник: "тестирование - это процесс направленный на выявление расхождений между поведением программы и ожиданиями заинтересованных лиц" [7]. Запуск программы непосредственно с целью нахождения ошибки предполагает, в первую очередь, тестирование потенциально ошибкоопасных мест ("отлавливание багов"), до которых пользователь может в принципе не добраться в процессе эксплуатации системы. А в процессе тестирования наиболее важно проверить те места программной системы, которые будут чаще остальных использоваться, особенно в условиях ограниченности времени и ресурсов, когда полная проверка программы невозможна.

Немного отстраненное определение дает Б. Бейзер. Тестирование - проектирование, отладка и выполнение тестов [3]. Данное определение может быть понято лишь непосредственно в контексте работы, соответственно принять ее в рамках нашего исследования мы не можем

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

Другим ключевым понятием является понятие "Информационная система". В электронном словаре BusinessDictionary.com информационная система определяется как "комбинация программного обеспечения, аппаратного обеспечения, инфраструктуры и специально обученного персонала, созданная с целью улучшения функций планирования, контроля, координации и принятия решений в организации. (a combination of hardware, software, infrastructure and trained personnel organized to facilitate planning, control, coordination, and decision making in an organization)" [18].

Похожее определение дают Дж. Валасич (J. Valacich) и К. Шнейдер (C. Schneider). Information systems are combinations of hardware, software, and telecommunications networks that people build and use to collect, create, and distribute useful data, typically in organizational settings [26]. Информационная система - это такая система, состоящая из АО, ПО и системы коммуникаций, созданная людьми для сбора, создания и распространения необходимых данных, в особенности в корпоративном секторе.

В Российских стандартах ГОСТ приводятся различные определения в зависимости от типа и спецификации стандарта. Информационная система - это:

·        система, которая организует хранение и манипулирование информацией о предметной области [6].

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

В данной работе для определения понятия "Информационная система" будем использовать определение, предлагаемое электронным ресурсом BusinessDictionary.com.

Третьим из понятий, определяющих работу, является понятие "бизнес-процесс". В немецкой литературе часто дается следующее определение этому понятию. Бизнес-процесс - это набор специфичных для предприятия и направленных на достижение определенной цели активностей, расположенных в хронологическом порядке. Ein Geschдftsprozess ist eine Menge von unternehmensspezifischen und zielgerichteten Aktivitдten besteht, welche in einem logischen und zeitlichen Zusammenhang stehen [27].

Можно встретить и другие определения:

-       бизнес-процесс - это модель, построенная из набора связанных, структурированных действий или задач, которые производят определенный продукт или определенную услугу (преследуют конкретную цель) для конкретного покупателя или потребителя (a business process, or business method, is a model composed by a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers) [19];

-       бизнес-процесс - это набор шагов, нацеленных на производство продукта или услуги. Он включает в себя любые виды активностей, дающие определенный результат для конкретного потребителя (внешнего или внутреннего) (a business process is a series of steps designed to produce a product or a service. It includes all the activities that deliver particular results for a given customer (external or internal)) [22].

Во всех представленных определениях понятия "бизнес-процесс" выделяется несколько ключевых моментов: процесс состоит из последовательности действий, процесс имеет конечную цель (конечный результат), есть потребитель, результат выполнения процесса нужен какому-либо конкретному потребителю. В данной работе будет использоваться обобщенное понятие, соответствующее каждому из приведенных определений.

 

Статистические данные о рынке ПО

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

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

Однако, результаты исследования, проведенного The Standish Group, [16] показывают, что всего чуть больше трети (39%) проектов были завершены успешно, 43% проектов были завершены с превышение бюджета или сроков, либо была сокращена функциональность приложения (см. рис. 1.1). И почти пятая часть (18%) проектов были "провалены".

Успешность реализации ИТ-проектов в 2013 г.

С исторической точки зрения процент успешно завершенных ИТ-проектов растет (см. табл. 1.1), но растет медленно, а их доля остается очень малой. К тому же, количество "проваленных" ИТ-проектов не опускалось ниже уровня 2004 года.

Успешность ИТ-проектов с 2004 по 2012

	2004	2006	2008	2010	2012
Успешно	29%	35%	32%	37%	39%
Провалено	18%	19%	24%	21%	18%
С превышением	53%	46%	44%	42%	43%

Очевидно, компании стремятся улучшить качество создаваемых программных продуктов. Согласно отчету компании WorkSoft: "2013 Trends in Automated Testing" [15] почти половина (45,1%) ошибок остаются незамеченными специалистами по тестированию (см. рис. 1.2).

Соотношение ошибок, найденных в процессе тестирования и в процессе эксплуатации.

Из 594 респондентов, участвовавших в исследовании Worksoft, 204 компании (34,3%) указали, что в 2013 году планируется увеличение инвестиций в автоматизацию тестирования и обеспечение качества. Только четверть респондентов ответили, что не планируют дополнительных инвестиций.

Остальные ответившие не знают о планах в отношении инвестиций в автоматизацию тестирования. Результаты опроса представлены на рис.1.3.

Результаты ответов на вопрос: "Планирует ли ваша компания увеличить инвестирование в автоматизацию тестирования в ближайшие 12 месяцев?".

Учитывая большое число не определившихся с выбором (41, 1%), можно предположить, что некоторые из этих компаний всё же планируют дополнительные инвестиции. Это значит, что настоящее число фирм, планирующих увеличение инвестиций в автоматизацию тестирования в 2013 году, скорее всего больше 34% [10].

В любом случае, исследование показывает увеличение интереса к автоматизации тестирования, которое наблюдается с 2012 года. На текущий момент 74% организаций не используют решения для автоматизированного тестирования, а 53% до сих пор работают при помощи программ общего назначения, таких как Word или Excel [5].

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

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

Стоимость ошибки

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

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

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

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

)        оплата времени работы специалиста по тестированию;

2)      оплата времени работы программиста, который реализовал модуль, содержащий ошибку, а затем исправил ее;

)        стоимость реализации "неправильного" модуля;

)        стоимость тестирования "неправильного" модуля;

)        стоимость исправления ошибки и проблем, появившихся из-за ее наличия.

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

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

)        время службы поддержки;

2)      компенсации пользователю понесенных затрат;

)        иски против компании;

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

Такие убытки, как правило, не поддаются объективной оценке.

Но от "неправильных" программ страдают не только производители, но и пользователи, а иногда даже люди, которые не имеют совершенно никакого отношения к программе.

Часто в качестве примера ПО с наиболее губительными последствиями эксплуатации приводятся катастрофа Ariane 5 и инциденты с Therac-25. Ariane 5 - ракета-носитель, запуск которой был произведен 4 июня 1996 года. Полет продлился неполные 40 сек., после чего произошел взрыв [2].

Из-за ошибок в программной части медицинского комплекса Therac-25 минимум шесть человек получили передозировки радиации, некоторые пациенты получили дозы в десятки тысяч рад. Как минимум двое умерли непосредственно от передозировок [20].

В истории РФ также были примеры катастрофических последствий ошибок в программном обеспечении. Например, 5 декабря 2010 года три спутника, критически важные для завершения составления группировки российской навигационной системы ГЛОНАСС - упали в Тихий океан недалеко от Гавайских островов вскоре после их запуска ракетой "Протон-М". Финансовые потери оцениваются в 4 миллиарда рублей. В результате расследования виной аварии была признана ошибка в программировании, которая привела к тому, что в ракету залили неправильное количество топлива. [11]

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

 

Рынок инструментов тестирования

Рынок инструментов тестирования, в основном, состоит из систем автоматического тестирования.

На рынке присутствуют программные продукты трех видов:

)        коммерческий продукт (WinRunner, Rational Robot, SilkTest, TestComplete и др.);

2)      бесплатные и условно-бесплатные инструменты (freeware, shareware);

)        собственные утилиты компаний (написанные в ходе работы над проектами).

Рассмотрим недостатки и преимущества продуктов этих видов. Для сравнения существующих систем были выделены следующие критерии:

)        функциональность;

2)      стоимость;

)        гибкость настройки продукта под нужды компании;

)        возможность самостоятельно дорабатывать продукт;

Коммерческие продукты

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

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

2)      как правило, такие инструменты поставляются со своей собственной средой разработки, которая предоставляет хорошие возможности для написания и отладки автотестов.

Недостатки:

1)      высокая стоимость таких продуктов;

2)      нет доступа к исходному коду:

a.       Если в инструменте обнаруживается ошибка, то его исправление силами поставщика может занять существенное время.

b.      Нет возможности оперативно настраивать продукт под нужды компании.

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

Собственные инструменты:

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

1)      иногда такие инструменты являются побочным результатом создания приложения, особенно в случае TDD (достались бесплатно);

2)      о них известно "от и до", их достаточно легко использовать;

)        доступен исходный код.

Недостатки:

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

2)      доработка до полноценной системы тестирования и её поддержка может быть дорогостоящей.

Бесплатные и условно-бесплатные инструменты:

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

1)      разумная стоимость владения. Продукт доступен либо бесплатно, либо за небольшую, как правило, плату;

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

)        зачастую у подобных утилит доступен исходный код.

Недостатки:

1)      функциональность таких продуктов может оказаться недостаточной для решения поставленных задач;

2)      существует риск остаться без поддержки со стороны разработчика продукта.

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

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

Сравнение продуктов автоматизированного тестирования

Разработчик	Продукт	Функциональное тестирование	Нагрузочное тестирование	Качество кода	Управление тестами
IBM	Rational Robot	+	+	+	+
Borland	SilkTest	+	+	-	+
AutomatedQA	TestComplete	+	+	-	+
HP	WinRunner	+	+	+	+
Open-source		Abbot, Selenium, Watir	Grinder, Jmeter, OpenSTA	GCT, NCover, Cobertura	FitNesse, TestLink

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

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

 

Процесс жизненного цикла программной ошибки

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

С момента обнаружения до того момента, когда ошибка будет исправлена и закрыта, она (ошибка) проходит через несколько стадий: обнаружение, исправление, откладывание, ожидание повторного тестирования, повторное тестирование [25].

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

Стоит отметить, что после обнаружения несоответствия между спецификацией программы и ее поведением, ошибка может быть отклонена в том случае, если тестировщик ошибся при проведении тестирования, либо если ошибка присутствует, но не в программном коде, а в описании приложения (ТЗ).

Существует 6 различных сценариев прохождения жизненного цикла (см. рис. 1.4).

Сценарий № 1:

.        Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

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

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

Сценарий № 2:

.        Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

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

ЖЦ программной ошибки.

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

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

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

Сценарий № 3:

.        Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

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

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

.        Руководитель команды разработки (или определенный член команды разработки) проверяет, действительно ли ошибка присутствует в программном коде. Если наличие ошибки подтверждается, руководитель назначает разработчика для исправления. Статус ошибки изменяется на "Назначена".

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

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

.        Руководитель отдела тестирования изменяет статус ошибки на "Повторное тестирование" и передает ее тестировщику для проведения повторного тестирования.

.        Тестировщик проверяет функционирование программы. Если программа работает корректно, он закрывает ошибку, т.е. устанавливает статус "Закрыта".

Сценарий № 4:

.        Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

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

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

.        Руководитель команды разработки (или определенный член команды разработки) проверяет, действительно ли ошибка присутствует в программном коде. Если наличие ошибки подтверждается, руководитель назначает разработчика для исправления. Статус ошибки изменяется на "Назначена".

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

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

.        Руководитель отдела тестирования изменяет статус ошибки на "Повторное тестирование" и передает ее тестировщику для проведения повторного тестирования.

.        Тестировщик проверяет функционирование программы. Если ошибка не была исправлена, тестировщик отправляет ее на доработку в отдел разработки.

Сценарий № 5:

.        Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

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

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

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

.        Тестировщику также не удается повторить описанную ситуацию, и ошибка отклоняется.

Сценарий № 6:

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

Таким образом, ошибка проходит по одному из описанных сценариев, в итоге, завершает прохождение ЖЦ с одним из статусов: "Закрыта", "Отложена" или "Отклонена".

Описание Microsoft Solution FrameworkSolutions Framework (MSF) представляет собой гибкий подход, который позволяет быстрее создавать технологические решения, задействуя меньшее количество людей, снижая риски и повышая уровень качества. MSF помогает командам направлять силы непосредственно на наиболее распространенные причины неудач технологических проектов, а значит, улучшать показатели успеха проектов, качество решения и бизнес-результаты [8].

Одной из особенностей модели MSF является подход, основанный на вехах (см. рис. 1.5). Вехи - это моменты жизненного цикла проекта, когда полученные на той или иной фазе результаты синхронизируются членами проектной группы друг с другом и с ожиданиями заказчика [21]. В этот момент заказчиком, заинтересованными сторонами и проектной группой производится формальный анализ достигнутого прогресса.

Процесс разработки ПО состоит из 5 стадий (см. рис. 1.5):

)        стадия выработки концепции;

2)      стадия планирования;

)        стадия разработки;

)        стадия стабилизации;

)        стадия внедрения.

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

Фазы и вехи модели процессов MSF.

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

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

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

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

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

Проектная группа MSF состоит из 6 ролевых кластеров - это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции и связанные с ними цели и задачи. Подробное описание ролевых кластеров приведено в табл. 1.3.

Описание ролевых кластеров MSF

Ролевой кластер	Цель	Область компетенции	Функции
Управление продуктом	Удовлетворенные заказчики	Маркетинг Бизнес-отдача (бизнес-приоритеты) Представление интересов заказчика Планирование продукта	Выступает в роли представителя заказчика Формирует общее видение/рамки проекта Организует работу с требованиями заказчика Развивает сферы применения в бизнесе Формирует ожидания заказчика Определяет компромиссы между параметрами "возможности продукта / время / ресурсы" Организует маркетинг, PR и евангелизацию Разрабатывает, поддерживает и исполняет план коммуникаций
Управление программой	Достижение результата в рамках проектных ограничений	Управление проектом Выработка архитектуры решения Контроль производственного процесса Административные службы	Управляет процессом разработки с целью получения готового продукта в отведенные сроки Формулирует спецификацию продукта и разрабатывает его архитектуру Регулирует взаимоотношения и коммуникацию внутри проектной группы Следит за временным графиком проекта и готовит отчетность о его состоянии Проводит в жизнь важные компромиссные решения Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта Организует управление рисками
Разработка	Создание продукта в соответствии со спецификацией	Технологическое консультирование Проектирование и осуществление реализации Разработка приложений Разработка инфраструктуры	Определяет детали физического дизайна Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна Разрабатывает или контролирует разработку элементов Подготавливает продукт к внедрению Консультирует команду по технологическим вопросам
Тестирование	Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены	Планирование тестов Разработка тестов Отчетность по тестам	Обеспечивает обнаружение всех дефектов Разрабатывает стратегию и планы тестирования Осуществляет тестирование
Удовлетворение потребителя	Повышение эффективности пользователя, увеличение потребительской ценности продукта	Обеспечение технической поддержки Обучение Эргономика Графический дизайн Интернационализация Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)	Представляет интересы потребителя в команде Организует работу с требованиями пользователя Проектирует и разрабатывает системы поддержки производительности Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта Определяет требования к системе помощи и её содержание Разрабатывает учебные материалы и осуществляет обучение пользователей
Управление выпуском	Беспроблемное внедрение и сопровождение продукта	Инфраструктура Сопровождение Бизнес-процессы Управление выпуском готового продукта	Представляет интересы отделов поставки и обслуживания продукта Организует снабжение проектной группы Организует внедрение продукта Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта Организует сопровождение и инфраструктуру поставки Организует логистическое обеспечение проектной группы

 

Стадия стабилизации в Microsoft Solution Framework

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

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

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

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

Суть точки конвергенции.

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

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

Точка достижения нуля.

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

К вехе "Контрольное тестирование завершено" проектная группа должна:

.        Оценить результаты тестирования в соответствии с имеющимися критериями успешности.

2.      Подготовить среду внедрения.

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

.        Иметь готовые учебные материалы.

.        Обеспечить условия для сопровождения решения.

.        Создать и протестировать план "отката".

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

Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения [21].

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

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

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

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

.        Тестирование версий-кандидатов, проходящее внутри проектной группы, требует высокой степени концентрации и интенсивности работы и фокусируется на выявлении критических "накладок".

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

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

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

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

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

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

Общим для всех этих форм предварительно выпуска является максимальное приближение тестирования к реальным условиям.

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

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

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

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

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

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

.        Шаг вперед: пилотное внедрение нового релиза.

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

.        Приостановка: пилотная версия "замораживается".

.        Исправление и продолжение: пилотная группа получает "заплату" к существующему коду.

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

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

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

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

Фаза стабилизации завершается вехой "Готовность решения утверждена". К моменту наступления этой вехи проектная группа завершает разрешение всех существенных проблем и производится выпуск или внедрение решения. Ответственность за непрерывное управление и поддержку решения формально переходит от проектной группы к командам сопровождения.

 

Виды нефункционального тестирования

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

Перечень нефункционального тестирования, составленный на основе ISO/IEC 9126, представлен на рис. 1.8.

Компоненты нефункционального тестирования.

Тестирование интерфейса пользователя (UI testing).

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

Пример первого: проверяем максимальное количество символов, которые можно напечатать в поле "Имя" на странице "Регистрация", т.е. проверяем, отвечает ли конкретный элемент интерфейса, называющийся "однострочное текстовое поле" (textbox), требованию спецификации, которая указывает на максимальное количество символов, которое в этом поле можно напечатать.

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

Тестирование локализации (localization testing).

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

Тестирование скорости и надежности. (load/stress/performance testing)

Это проверка поведения программы (или ее отдельных частей) при одновременном использовании множеством пользователей.

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

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

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

Тестирование безопасности (security testing)

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

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

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

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

Также при юзабилити-тестировании проверяется интуитивность интерфейса.

Тестирование совместимости (compatibility testing).

Тестирование совместимости - это проверка того, как программа взаимодействует с:

)        аппаратным обеспечением;

2)      ПО (браузерами/операционными системами) пользователей.

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

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

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

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

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

Кроме того, в этой главе была рассмотрена методология MSF и стадия стабилизации и приведено обоснование перехода от оперирования термином "тестирование" к использованию термина "стабилизация".

 

Разработка навигатора процесса стабилизации

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

 

Описание игры в стабилизацию

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

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

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

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

Специалист по тестированию (студент) тестирует программу (см. рис. 2.1): подготавливает конфигурацию, прогоняет набор тестов, получает некоторый ответ.

Процесс тестирования с точки зрения деловой игры в стабилизацию.

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

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

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

Проведение игры в стабилизацию.

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

"Бумажный" прототип являлся моделью пространства программного продукта (в виде многомерного куба) в программе Excel. Все операции проводились "вручную".

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

По итогам проведения деловой игры были получены следующие результаты:

)        Были выявлены недостатки "бумажной" модели:)   составление пространства программного продукта требует значительных трудозатрат;

b)      проверка (запуск набора тестов и получение результатов) проходит довольно медленно, что приводит к формированию очередей и потере большого количества времени;)   отслеживание версионности (поставки версий программ) отдельно для каждой команды практически невозможно;

2)      количество измерений гиперкуба увеличилось примерно в 2 раза;

3)      определен механизм взаимодействия программы со студентами;

)        определен способ представления результатов тестирования (в частности, внедрен и апробирован механизм сообщений).

С точки зрения образовательного процесса можно выделить несколько положительных итогов:

)        студенты на практике поняли, что такое тестирование и как надо действовать при тестировании программ;

2)      студенты на практике ощутили, к чему приводят допущенные в ТЗ неточности спецификации программного продукта;

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

Однако, были и отрицательные моменты:

)        количество организаторов меньше, чем количество студентов, из-за чего участники игры иногда оставались незадействованными, а непосредственно игра затягивалась;

2)      игра дорабатывалась по ходу ее проведения, вводимые изменения иногда приводили студентов в замешательство.

Рефлексии студентов приведены в приложении С.

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

 

Разработка пространства программного продукта

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

Тестируемый программный продукт представляется в виде многомерного пространства ("program product space" - PPS) [14]. Измерения пространства характеризуют многообразие применения стабилизируемой программы: измерение "Функции", измерение "Операционные системы", измерение "Пакеты обновления", измерение "Форматы хранения данных", измерения "Производительность", "Нагрузка", "Интерфейс", "Юзабилити", "Документация", "Требования к процессору", "Требования к памяти", "Требования к месту на диске" и т.д. Полный перечень измерений и их значений представлен в приложении B.

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

Точки этого пространства задают некоторые конкретные ситуации, которые должны быть проверены [13].

Каждая точка пространства характеризуется рядом параметров:

)        частота использования (для отделения часто используемых частей программы от редко используемых);

2)      обязательность использования (для выделения обязательных сценариев);

)        стоимость исправления ошибки, связанной с этим компонентом;

)        стоимость неисправленной ошибки для пользователя (стоимость проявления ошибки на этапе эксплуатации программы);

)        важность исправления ошибки с точки зрения текущей версии программы (можно ли оставить эту ошибку неисправленной до следующей версии);

)        оценка вероятности ошибки по данному измерению или для данного значения (возможна на основе предыдущего опыта работы; может быть грубой: низкая - средняя - высокая);

)        оценка серьезности ошибки (для отделения фатальной ошибки в работе программы от орфографической в руководстве пользователя). Значение каждого параметра лежит в некотором диапазоне (например, от 0 до 10)

PPS моделируется с помощью реляционной БД (см. рис.2.2.).

Модель пространства программного продукта.

Диаграмма классов PPS.

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

 

Логика работы приложения

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

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

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

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

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

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

2.      Уровень прав доступа: администратор.

.        Размер БД: малый.

.        Формат входных данных: doc/xls.

.        Формат выходных данных: doc/xls.

.        ОС: Windows 8.

.        Разрядность ОС: x64.

.        SP: последний для выбранной ОС

.        Функция: учет производства продукции.

Параметры по умолчанию соответствуют персоналу и программному и аппаратному обеспечению фирмы-разработчика ИС.

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

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

В некоторый момент времени студент решает отослать отчет разработчикам. В этот момент в БД добавляется запись о появлении новой версии, причем в поле "TimeToAccomplishment" записывает число, равное сумме времени необходимого для исправления каждой из указанных в отчете ошибок.

На "прогон" набора тестов в каждой конфигурации тратится определенное количество модельного времени (поле "TestRunTime" в таблице "Configurations"). При проверке конфигурации модельное время продвигается, что, в частности, приближает момент выпуска новой версии: из значения поля "TimeToAccomplishment" таблицы "Builds" вычитается значение поля "TestRunTime" таблицы "Configurations". Когда "TimeToAccomplishment" становится равным нулю, изменения, содержащееся в данной версии, вступают в силу, т.е. учитываются при последующей проверке конфигураций.

Интерфейс приложения

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

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

На странице "О разработчике" (см. рис.2.5) указаны официальные данные о разработчике и контактная информация для обращения.

Преподавателю доступна возможность просмотра и изменения содержимого ИС. Для этого преподаватель должен выбрать, что именно он хочет просмотреть или изменить (см. рис.2.6), после чего он будет перенаправлен к странице просмотра (см. рис.2.7).

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

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

Для того, чтобы убрать "эффект подсказок" было решено перейти к интерфейсу другого вида (см. рис. 2.9), когда студент сам вводит параметры и их значения на естественном языке, а система распознает эти значения.

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

Выбор конфигурации с помощью естественного языка.

Выдача результатов запуска набора тестов.

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

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

Апробация информационной системы

Представленная ИС прошла апробацию 11.06.2014. Апробация проходила следующим образом. Отзывы студентов о проведении игры в стабилизацию с использованием НПС представлены в приложении D.

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

Деятельность студентов включала следующие задачи:

)        выбрать конфигурацию;

2)      запустить набор функциональных тестов на выбранной конфигурации;

)        изучить результат запуска набора тестов;

)        принять решение о дальнейших действиях в зависимости от полученных результатов: продолжить тестирование, или составить отчет о найденной ошибке;

)        отправить отчет разработчикам;

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

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

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

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

)        возможно отслеживание версионности (поставки версий программ отдельно для каждой команды);

Работа была представлена на двух конференциях: "Современные проблемы математики и её прикладные аспекты" (Пермь, 2013) и "Теория и практика системного анализа" (Рыбинск, 2014), а также на VIII студенческом региональном конкурсе инновационных проектов по программе УМНИК (Пермь, 2013).

 

Навигатор процесса стабилизации как бизнес-инструмент

Для бизнес-среды идея повышения качества ПО заключается в создании инструмента, предназначенного для управления процессом стабилизации сложного программного продукта. Он позволяет определить наилучший (по заданным критериям) порядок тестирования и оценить "степень проверенности" продукта [12].

Для обеспечения гибкости в обучающую программу вводятся следующие модификации:

)        возможность деление на более мелкие измерения или наоборот их укрупнение ("Кроссплатформенность", "Конфигурация аппаратуры").

2)      конкретный набор измерений уточняется для каждого конкретного продукта.

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

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

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

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

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

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

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

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

Таким образом, Навигатор представляет интерес для всех разработчиков программного обеспечения от программистов-одиночек до крупнейших фирм. Отличия будут в масштабах применения, в объемах и сложности PPS.

Проблемы и перспективы.

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

Во-первых, жесткость структуры PPS. Требования могут изменяться для каждого конкретного программного продукта. Для этого структура PPS должна быть максимально гибкой, чтобы предоставить пользователям возможность задания гиперкуба любого (или почти любого) вида. Требование гибкости особенно актуально для бизнес-приложения.

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

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

Заключение

Исследования по теме "Навигатор процесса стабилизации" относятся к сфере повышения качества создаваемых программных продуктов.

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

На основе результатов изучения видов нефункционального тестирования и опыта проведения деловой игры было спроектировано многомерное пространство программного продукта, измерения которого характеризуют многообразие применений стабилизируемой ИС: "Функции", "Платформы", "Размер БД" и т.д. Точки этого пространства задают некоторые конкретные ситуации, которые должны быть проверены.

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

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

Была проведена апробация разработанного прототипа НПС. Применение программной системы при проведении деловой игры уменьшает трудозатраты организаторов по подготовке игры, сокращает время на ее проведение и позволяет разнообразить деловую игру путем введения версионности.

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

Работа была представлена на конференциях: "Современные проблемы математики и её прикладные аспекты" и "Теория и практика системного анализа", а также на VIII студенческом региональном конкурсе инновационных проектов по программе УМНИК.

Библиографический список

1.      Автоматизация тестирования: выбор инструмента. // OpenQuality.ru. Качество программного обеспечения [Электронный ресурс] [Режим доступа: #"878087.files/image014.gif">

Рисунок А.1. Подробная диаграмма классов PPS.

Перечень измерений и значений по ним

.        Квалификация тестировщика:.      Опытный пользователь.

b.      Профессионал..  Хакер..       Новичок.

2.      Уровень прав доступа:.        Администратор.

b.      Пользователь..   Гость.

3.      Размер БД:.         Малый: 0.499.

b.      Небольшой: 500.999.. Средний: 1000.4999..  Выше среднего: 5000.14999..         Большой: 15000.49999..       Промышленный: 50000.149999..  Большие данные: >150000.

4.      Форматы данных:.       docx/xlsx.

b.      ЦХД..         doc/xls..      CSV.

5.      Разрядность ОС:.         32-разрядная.

b.      64-разрядная.

6.      SP:.   0 (без SP).

b.      1..     2..     3.

7.      ОС:.  Windows 8 (Windows 8.1 - SP1 для Windows 8).

b.      Windows XP (всего 3 SP)..    Windows 7 (всего 4 SP).

8.      Функционал:.      Учет производства продукции.

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

Рефлексия проведения игры в стабилизацию

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

)        С какой целью была проведена игра в Стабилизацию?

2)      Что было внове? Какой опыт приобрели?

)        Что узнали? Чему научились?

)        С точки зрения организации самой игры:

a.       Понятна ли цель? Понятны ли способы ее достижения? Насколько они результативны?

b.      Что понравилось? Что не понравилось? Чего не хватило? Что надо делать не так?. Насколько полезны/вредны такие методы обучения по сравнению с традиционной системой лекций-практик?

Рефлексия Бушуева Романа.

Цель игры:

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

Новое и опыт:

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

Что узнали? Чему научились:

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

Организация самой игры:

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

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

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

. Написать документ-концепцию (vision document), который будет определять, что необходимо сделать в общем, что должна делать каждая часть, что должен сделать каждый в это части.

. Было бы замечательно, если была бы написана некая программа.

Рефлексия Барминой Елены.

С какой целью была проведена игра в Стабилизацию?

Что было внове? Какой опыт приобрели?

Что узнали? Чему научились?

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

С точки зрения организации самой игры:

Понятна ли цель? Понятны ли способы ее достижения? Насколько они результативны?

Что понравилось? Что не понравилось? Чего не хватило? Что надо делать не так?

Насколько полезны/вредны такие методы обучения по сравнению с традиционной системой лекций-практик?

Предложения по усовершенствованию игры

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

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

Рефлексия Вотинцевой Ксении.

Я думаю, эта игра наглядно демонстрирует реальный процесс стабилизации. Однако не могу сказать, что теперь я всё поняла в этом процессе. Кое-что я усвоила (например, уточнение всех-всех-всех деталей ещё на этапе написания ТЗ), но кое-что до сих пор мне не ясно (например, наша игра расходилась с трактовкой стабилизации от MSF и это привело к непониманию того, как на самом деле должна проходить стабилизация).

Игра сама по себе - удачное решения для обучения процессу создания (в частности стабилизации) проекта. Я бы хотела, что бы в дальнейшем проводились подобные игры. Во-первых, это интересно, во-вторых нескучно. Но чтобы игра прошла успешно, нужны строго установленные правила. В данной игре они постоянно менялись, а из-за этого возникало много непонятных мне моментов. Понятна цель игры, непонятны её правила, а следовательно и способы достижения цели.

Рефлексия Капгер Анны.

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

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

Рефлексия Красноперовой Анастасии.

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

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

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

Рефлексия Филатова Данила.

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

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

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

Предложения по усовершенствованию: ускорить игру в несколько раз.1 неделя - 1 пара это как то слишком медленно.

Рефлексия Шилова Юрия.

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

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

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

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

Что касается усовершенствований, я бы попробовал ввести соревновательную составляющую: составил примерную шкалу выполнения стабилизации и на каждой паре показывал всем студентам кто насколько продвинулся (своеобразный рейтинг). Это может не только мотивировать отстающих пересмотреть свою работу, но и поможет определить примерный курс действий для тех, кто делает правильные шаги. Например, можно составить возможный список вопросов по ТЗ, которые могут задать студенты, список критически важных тестирований, и по мере того, как группы будут выполнять эти действия, увеличивать степень выполнения стабилизации по 100-бальной шкале и демонстрировать эти результаты на каждой паре в открытом режиме.

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

Отзывы студентов о программе

Отзыв Бушуева Романа.

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

Программа работает, но количество вариантов для ошибок слишком малы. Количество возможных вариантов, которые необходимо рассмотреть равно приблизительно 52000, а количество вариантов, в которых возникают ошибки равно 200. Вероятность слишком мала. Если предположить, что на каждый тест уйдет 1 секунда, то на все около 15 часов. Легче запустить написать программу, которая будет генерировать все возможные варианты, чем прогонять все в ручную.

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

Отзыв Красноперовой Анастасии.

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

Отзыв Котельниковой Надежды.

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

Описание таблиц БД

В приложении представлено описание таблиц PPS и соответствующих им сгенерированных классов.

Таблица "Functions" содержит описание функционала "разрабатываемой" системы (см. табл. 2.1.).

Структура таблицы "Functions"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idFunction	uniqueidentifier	Уникальное	Functions	Идентификатор записи
FunctionName	Строка (200)		Functions	Наименование функции

Таблица "OperatingSystemNames" содержит перечень операционных систем, на которых впоследствии будет использоваться система "ОбалдеИТ" (см. табл. 2.2).

Структура таблицы "OperatingSystemNames"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idOperatingSystem	uniqueidentifier	Уникальное	OperatingSystemNames	Идентификатор записи
OSName	Строка (50)		OperatingSystemNames	Наименование функции

Таблица "FileExtensions" содержит информацию о форматах входных данных для функций системы "ОбалдеИТ" (см. табл.2.3).

Структура таблицы "FileExtensions"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idFileExtension	uniqueidentifier	Уникальное	FileExtensions	Идентификатор записи
ExtensionLine	Строка (50)		FileExtensions	Линия расширений, характерных для определенных программных продуктов.

Таблица "ServicePacks" содержит информацию о наличии в ОС пакета обновления с соответствующим номером (см. табл.2.4). Если на ОС ни один пакет обновления не установлен, ставится "0".

Структура таблицы "ServicePacks"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idServicePack	uniqueidentifier	Уникальное	ServicePacks	Идентификатор записи
SequenceNumber	Целое		ServicePacks	Порядковый номер SP.

Таблица "TesterRoles" содержит информацию о доступных специалисту по тестированию ролях (различаются права доступа) для входа в систему (см. табл. 2.5).

Структура таблицы "TesterRoles"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idTesterRole	uniqueidentifier	Уникальное	TesterRoles	Идентификатор записи
RoleDescription	Строка (50)		TesterRoles	Описание роли и доступных прав.

Таблица "DbSize" содержит информацию о доступных базах данных с различным объемом данных (см. табл. 2.6).

Структура таблицы "DbSize"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idDbSize	uniqueidentifier	Уникальное	DbSize	Идентификатор записи
Description	Строка (30)		DbSize	Описание (название) БД.
NumberOfRowsFrom	Целое	Положительное	DbSize	Нижняя граница диапазона значений количества строк.
NumberOfRowsTo	Целое	Положительное	DbSize	Верхняя граница диапазона значений количества строк.

Таблица "Qualifications" содержит информацию о возможных квалификациях пользователей (специалистов по тестированию) (см. табл. 2.7).

Структура таблицы "Qualifications"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idQualification	uniqueidentifier	Уникальное	Qualifications	Идентификатор записи
Description	Строка (50)		Qualifications	Описание квалификации (умений) пользователя.

Таблица "Testers" содержит информацию о тестировщиках, доступных для использования в процессе стабилизации (см. табл. 2.8).

Структура таблицы "Testers"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение	uniqueidentifier	Уникальное	Testers	Идентификатор записи.
Description	Строка (30)		Testers	ФИО тестировщика.
idQualification	uniqueidentifier		Qualifications	Ссылка на квалификацию тестировщика.

Таблица "Messages" содержит информацию о сообщениях, выводимых студентам в процессе тестирования (см. табл. 2.9).

Структура таблицы "Messages"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idMessage	uniqueidentifier	Уникальное	Messages	Идентификатор записи.
MessageText	Строка (MAX)		Messages	Текст сообщения.

Таблица "Configurations" содержит информацию о начальном состоянии программного продукта "ОбалдеИТ" (см. табл.2.10).

Структура таблицы "Configurations"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idConfiguration	uniqueidentifier	Уникальное	Configurations	Идентификатор записи.
idOperatingSystem	uniqueidentifier		OperatingSystem Names	Ссылка на текущую ОС.
idServicePack	uniqueidentifier		ServicePacks	Ссылка на установленный SP.
idFileExtension	uniqueidentifier		FileExtensions	Ссылка на выбранный формат входных данных
idFunction	uniqueidentifier		Functions	Ссылка на выбранную функцию.
HasError	Булево		Configurations	Показывает, содержит ли выбранная конфигурация ошибку.
TestRunTime	Целое	Положительное	Configurations	Время "прогона" тестов для выбранной конфигурации.
Criticality	Целое	0.10	Configurations	Серьезность ошибки.
CorrectionTime	Целое	0.10	Configurations	Время на исправление ошибки в единицах модельного времени.
idMessage	uniqueidentifier		Messages	Ссылка на сообщение, выдаваемое при тестировании текущей конфигурации.
Checked	Булево		Configurations	Показывает, проверена ли данная конфигурация при тестировании текущей версии системы, т.е. необходимо ли включать конфигурацию в следующую версию.
idTester	uniqueidentifier		Testers	Ссылка на текущего тестровщика.
idDbSize	uniqueidentifier		DbSize	Ссылка на выбранный размер БД.
idTesterRole	uniqueidentifier		TesterRoles	Ссылка на роль, под которой работает тестировщик.

Таблица "TestReports" содержит информацию об изменениях состояния системы относительно начального, т.е. данные для проведения регрессионного тестирования (см. табл.2.11).

Структура таблицы "TestReports"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idTestReportItem	uniqueidentifier	Уникальное	TestReports	Идентификатор записи.
idSourceConfiguration	uniqueidentifier		Configurations	Исправляемая конфигурация.
idInfluencesConfiguration	uniqueidentifier		Configurations	Конфигурация, на которую повлияли изменения.
HasError	Булево		TestReports	Новые данные о содержании ошибки.
TestRunTime	Целое	Положительное	TestReports	Новые данные о времени "прогона" тестов для выбранной конфигурации.
Criticality	Целое	0.10	TestReports	Новые данные о серьезности ошибки.
CorrectionTime	Целое	0.10	TestReports	Новые данные о времени на исправление ошибки.
idMessage	uniqueidentifier		Messages	Ссылка на сообщение, выдаваемое при тестировании текущей конфигурации.
Stage	Целое	Положительное	TestReports	Порядковый номер обращения к текущей конфигурации.

Таблица "Teams" содержит информацию о студентах или командах студентов, участвующих в деловой игре в стабилизацию (см. табл.2.12).

Структура таблицы "Teams"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idTeam	uniqueidentifier	Уникальное	Teams	Идентификатор записи.
Members	Строка (50)		Teams	Состав команды.

Таблица "TestingLog" содержит информацию о конфигурациях, которые были проверены (см. табл.2.13).

Структура таблицы "TestingLog"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idLogItem	uniqueidentifier	Уникальное	Teams	Идентификатор записи.
idTestReport	uniqueidentifier		TestReports	Ссылка на ситуацию для проверки.
idBuild	uniqueidentifier		Builds	Ссылка на версию программы.

Таблица "Builds" содержит информацию о "билдах" - версиях тестируемой системы "ОбалдеИТ" (см. табл.2.14).

Структура таблицы "Builds"

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
IdBuild	uniqueidentifier	Уникальное	Builds	Идентификатор записи.
Team_idTeam	uniqueidentifier		Teams	Ссылка на команду, для которой был выпущен "билд".
BuildNumber	Целое	Положительное	Builds	Порядковый номер версии.
TimeToAccomplishment	Целое	Положительное	Builds	Время до выпуска текущей версии. Если значение равно "0", то версия выпущена.

Техническое задание

Введение

.1.     Наименование программы

Навигатор процесса стабилизации.

1.2.   Область применения

Настоящая ИС предназначена для применения на семинарских занятиях по тестированию ПО.

1.3.   Объект, в котором используют программу

Предполагается использование ИС при работе со студентами факультета бизнес-информатики НИУ ВШЭ - Пермь.

Основание для разработки

1.4.   Основание для проведения разработки

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

Разработчиком системы выступает студент 4 курса факультета бизнес-информатики Югов Александр. Заказчиком системы является факультет бизнес-информатики.

Работа выполняется на основании учебного плана и темы выпускной квалификационной работы, определенной научным руководителем и утвержденной приказом от 25.11.2013 №8.2.6.2-06/698 "Об утверждении тем и руководителей выпускных квалификационных работ студентов факультета бизнес-информатики".

1.5.   Наименование и условное обозначение темы разработки

Наименование темы разработки - "Навигатор процесса стабилизации" (далее по тексту - Система).

Назначение разработки

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

Система предназначена для решения следующих задач:

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

2.      Отслеживание и контроль действий студентов.

.        Сбор базы знаний о процессе тестирования, проводимого студентами.

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

Система должна включать авторизацию пользователей со следующими ролями:

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

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

.        Студент. Имеет права на прохождение стабилизации, при этом доступ к полному просмотру конфигурации PPS запрещен.

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

Требования к программе или программному изделию

1.6.   Требования к функциональным характеристикам

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

Функциональные возможности пользователей с ролью "Студент" определены в таблице А.1.

Таблица А.1. Требования к составу выполняемых функций для роли "Студент"

Наименование функции	Входные данные	Выходные данные	Комментарий
Проверка текущей конфигурации	Значение следующих атрибутов: функция, ОС, SP, формат данных, размер БД, тестировщик (квалификация, роль)	Сообщение, номер версии программы
Переустановка ОС	Наименование ОС	Сообщение об успехе или неудаче проведения операции.
Установка SP	−	Сообщение об успехе или неудаче проведения операции.
Резервирование тестировщика	Значение атрибута "Квалификация"	ФИО тестировщика
Изменение роли тестировщика	Наименование роли	Сообщение об успехе или неудаче проведения операции.
Установка подключения к БД	Имя БД	Сообщение об успехе или неудаче проведения операции.
Запрос новой версии программы	−	Новая версия программы
Установка новой версии программы	−	Установленная версия программы
Отправка заявки на исправление	Заявка на исправление (с указанием конфигурации, содержащей ошибку)	−	Заявка выполняется, результат исправления приходит со следующей версией программы

Функциональные возможности пользователей с ролью "Преподаватель" определены в таблице А.2.

Таблица А.2. Требования к составу выполняемых функций для роли "Преподаватель"

Наименование функции	Входные данные	Выходные данные
Просмотр конфигурации PPS (в общем)	−	Список строк конфигурации PPS
Просмотр детальной информации о конфигурации PPS (конкретной)	Строка конфигурации	Детальная информация строки конфигурации
Редактирование строк конфигурации	Строка конфигурации	Измененная информация строки конфигурации
Удаление строк конфигурации	Строка конфигурации	Отсутствие строки конфигурации в БД
Просмотр информации о командах (студентах)	Команда	Информация о команде
Просмотр журнала стабилизации	−	Записи из журнала стабилизации

Функциональные возможности пользователей с ролью "Администратор" определены в таблице А.3.

Таблица А.3. Требования к составу выполняемых функций для роли "Преподаватель"

Наименование функции	Входные данные	Выходные данные
Просмотр конфигурации PPS (в общем)	−	Список строк конфигурации PPS
Просмотр детальной информации о конфигурации PPS (конкретной)	Строка конфигурации	Детальная информация строки конфигурации
Редактирование строк конфигурации	Строка конфигурации	Измененная информация строки конфигурации
Удаление строк конфигурации	Строка конфигурации	Отсутствие строки конфигурации в БД
Просмотр информации о командах (студентах)	Команда	Информация о команде
Редактирование информации о командах (студентах)	Команда	Измененная информация о команде
Удаление информации о командах (студентах)	Команда	Отсутствие информации о команде в БД.
Просмотр журнала стабилизации	−	Записи из журнала стабилизации
Редактирование записей журнала стабилизации	Запись в журнале стабилизации	Измененная запись в журнале стабилизации
Удаление записей журнала стабилизации	Запись в журнале стабилизации	Отсутствие записи в журнале стабилизации

.7.     Требования к надежности

1.7.1. Требования к обеспечению надежного (устойчивого) функционирования программы

Надежное (устойчивое) функционирование ИС должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, а именно:

)        организацией бесперебойного питания серверного и коммуникационного оборудования;

2)      использованием лицензионного программного обеспечения;

)        регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 Г. "Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств››;

)        регулярным выполнением требований ГОСТ 51188-98. "Защита информации. Испытания программных средств на наличие компьютерных вирусов".

1.7.2. Время восстановления после отказа

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

1.7.3. Отказы из-за некорректных действий оператора

Возможными считаются отказы Системы (нарушение штатного режима функционирования) вследствие некорректных действий персонала, обслуживающего СУБД, операционную систему, под управлением которой работает Система. Защита от подобных действий настоящим Техническим заданием не предусматривается. Меры безопасности по недопущению некорректных действий персонала должны определяться соответствующими должностными инструкциями.

1.8.   Условия эксплуатации

Для эксплуатации и поддержания Системы определены следующие группы:

.        Системный администратор.

2.      Администратор БД.

.        Обычные пользователи.

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

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

Основными обязанностями системного администратора являются:

.        Установка, обновление и конфигурирование программного обеспечения технических средств.

2.      Поддержание в работоспособном состоянии программного обеспечения серверов и рабочих станций.

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

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

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

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

Пользователи систем должны иметь опыт работы в браузерах: Internet Explorer, и/или Opera, и/или Yandex, и/или Mozila FireFox, и/или Google Chrome.

1.9.   Требования к составу и параметрам технических средств

1.9.1. Рекомендуемые требования

Для обеспечения работы системы рекомендуется использовать:

Сервер баз данных.

Объем оперативной памяти - не менее 2 Гб.

Объем жесткого диска - не менее 80 Гб.

Сетевая карта - с поддержкой скорости не менее 1 Гбит/сек.

Сервер приложений.

Процессор - 4 х 3 ГГц.

Объем оперативной памяти - не менее 2 Гб.

Объем жесткого диска - не менее 40 Гб.

1.9.2. Минимальные требования

Минимальные требования для работы приложения:

Сервер баз данных.

Процессор - 1 х 3 ГГц.

Объем оперативной памяти - не менее 1 Гб.

Объем жесткого диска - не менее 60 Гб.

Сервер приложений.

Процессор - 1 х 3 ГГц.

Объем оперативной памяти - не менее 1 Гб.

Объем жесткого диска - не менее 20 Гб.

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

1.9.3. Требования к рабочему месту пользователя

Процессор Intel-совместимый, тактовая частота не ниже 500 МН2, оперативная память не менее 256 Мб, свободного дискового пространства не менее 100 Мб.

1.10. Требования к информационной и программной совместимости

1.10.1.        Требования к исходным кодам и языкам программирования

Для разработки системы необходимо основываться на паттерне MVC. Основной средой для разработки должна быть Visual Studio. Для средств хранения данных следует использовать SQL Server Express версии 2012 и позднее.

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

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

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

1.11. Требования к защите информации и программ

Хранение и организация данных в системе должны осуществляться на основе реляционной СУБД. Обеспечение целостности данных должно быть достигнуто за счет встроенных средств СУБД. Доступ к данным должен предоставляться только авторизованным пользователям с учетом их роли в системе.

1.12. Требования к маркировке и упаковке

Требования к маркировке и упаковке не предъявляются.

1.13. Требования к транспортированию и хранению

Требования к транспортированию и хранению не предъявляются.

1.14. Требования к эргономике и технической эстетике

При разработке визуальной составляющей системы необходимо ориентироваться на требования, указанные в стандарте ГОСТ 21829-76 Система "Человек-машина" кодирование зрительной информации.

Общие эргономические требования.

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

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

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

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

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

1.15. Специальные требования

Корректное отображение Системы не может быть гарантировано при несоответствии любого из параметров ПО пользователя приведенным ниже требованиям.

.        Минимальное разрешение экрана пользователя:

·        Для настольных компьютеров и ноутбуков (основная версия сайта) - 1024х768 пикселей.

·        Для устройств типа планшет и смартфон (мобильная версия) - 320х480 пикселей.

2.      Масштаб просмотра страницы в браузере:

·        Корректное отображение страниц сайта гарантируется при установленном в браузере пользователя масштабе в 100%.

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

3.      Тип браузера для основной версии:

·        Internet Explorer 9 и выше.

·        Mozilla Firefox 28 и выше.

·        Opera 12 и выше.

·        Safari 5 и выше.

·        Google Chrome 32 и выше.

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

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

Требования к программной документации

Для системы должна быть сформирована следующая документация:

)        Схема базы данных и описание отдельных таблиц.

2)      Исходные тексты программ в виде приложения с открытым исходным кодом.

)        Тестовые сценарии в электронной форме.

)        Руководства пользователей (студента, сотрудника факультета, работодателя и администратора) в электронной форме.

)        Руководство разработчика в электронной форме.

Технико-экономические показатели

Ориентировочная экономическая эффективность не рассчитывается.

Стадии и этапы разработки

Этапы работы, их состав и содержание приведены в таблице А.4.

Таблица А.4. Состав и содержание работ

Название этапа	Содержание работ	Результаты работы
Анализ текущей ситуации	Обзор аналогичных систем. Изучение литературы. Разработка моделей бизнес-процессов.	Отчет по аналогичным системам. перечень требований к проектируемой системе. Определения терминов, применяемых в системе. Модели бизнес-процессов и документация к моделям.
Проектирование приложения	Определение функций системы. Моделирование процессов. Формирование структур данных. Разработка макета приложения.	Список функциональных требований к системе. Модели бизнес-процессов и документация к моделям. Модель базы данных. Макеты приложения.
Разработка	Создание базы данных. Создание модели данных. Создание репозитория для доступа к данным. Дизайн представлений. Реализация бизнес-логики на серверной и клиентской частях приложения.	Локальная версия приложения.
Документирование	Разработка документации к приложении.	Документация к базе данных. Документация пользователя. Документация разработчика. Документация администратора.
Тестирование	Проверка правильности выполнения функций системы.	Отлаженное приложение.
Развертывание