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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. ОС: Windows 8.

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

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

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

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

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

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

В некоторый момент времени студент решает отослать отчет разработчикам. В этот момент в БД добавляется запись о появлении новой версии, причем в поле "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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

1. Автоматизация тестирования: выбор инструмента. // OpenQuality.ru. Качество программного обеспечения [Электронный ресурс] [Режим доступа: http://blog. openquality.ru/tool-choice/] [Проверено: 25.03.2014]

2. Аджиев В. "Мифы о безопасном ПО: уроки знаменитых катастроф" // Открытые системы [Электронный ресурс] [Режим доступа: http://www.osp.ru/os/ 1998/06/179592/] [Проверено: 26.04.2014].

3. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем. - СПб.: Питер, 2004. - 318с.

4. Защита информации. Основные термины и определения [Текст]: ГОСТ Р 50922_2006. - М.: Стандартинформ, 2008.

5. Инструменты Borland Silk Portfolio для тестирования приложений // Interface.ru [Электронный ресурс] [Режим доступа: http://www.interface.ru/home. asp? artId=35624] [Проверено: 26.04.2014]

6. Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными [Текст]: ГОСТ 34.321-96. - М.: Издательство стандартов, 2001.

7. Коробейник А. Краткие основы тестирования программного обеспечения. - Киев, 2012 // Hints for Software Testing [Электронный ресурс] [Режим доступа: http://arturk. weebly.com/uploads/1/1/7/4/11740715/testirovaniepo. pdf] [Проверено: 01.06.2014].

8. Обзор Microsoft Solutions Framework (MSF) // Microsoft Developer Network [Электронный ресурс] [Режим доступа: http://msdn. microsoft.com/ru-ru/library/jj161047. aspx] [Проверено: 27.03.2014].

9. Работа в Microsoft Visual Studio // Intuit [Электронный ресурс] [Режим доступа: http://www.intuit.ru/studies/courses/499/355/lecture/8453? page=2] [Проверено: 27.03.2014].

10. Тренды в автоматизированном тестировании в 2013 году - часть 3/3 // QA Platform [Электронный ресурс] [Режим доступа: http://qapl.net/тренды-в-тестировании-3/] [Проверено: 27.03.2014]

11. Цена программной ошибки. // СиСофт [Электронный ресурс]. [Режим доступа: http://www.cusoft.ru/error. php] [Проверено: 12.04.2014]

12. Югов А.С. Навигатор процесса стабилизации // Материалы VIII Студенческого регионального конкурса инновационных проектов по программе УМНИК 5-6 декабря 2013г. - Пермь: ООО "Интер-ЕС", 2013. - 115 с.

13. Югов А.С. О необходимости и способе улучшения процесса стабилизации программного обеспечения // Теория и практика системного анализа: Труды III Всероссийской научной конференции молодых ученых с международным участием. - Т.I. - Рыбинск: РГАТУ имени П.А. Соловьева, 2014. - 200с.

14. Югов А.С., Плаксин М.А. ИС для обучения технологии нефункционального тестирования // Современные проблемы математики и её прикладные аспекты - 2013: сб. тез. науч. - практ. конф. (Пермь, 29 - 31 октября 2013 г.) / гл. ред.В.И. Яковлев; Перм. гос. нац. исслед. ун-т. - Пермь, 2013. - 179 с.

15. 2013 Trends in Automated Testing For Enterprise Systems. Market Research Report // WorkSoft [Электронный ресурс] [Режим доступа: http://www.worksoft.com/files/ resources/Worksoft-Research-Report-2013-Trends-in-Automated-Testing. pdf] [Проверено: 27.04.2014]

16. CHAOS Manifesto 2013: Think Big, Act Small // VersionOne: Agile Made Easier [Электронный ресурс] [Режим доступа: http://www.versionone.com/assets/img/files/ CHAOSManifesto2013. pdf] [Проверено: 04.06.2014]

17. Glossary of Software Engineering Terminology [Text]: IEEE 729-1983. - New York: Inst. of Electrical and Electronics Engineers, 1984

18. Information System // Business Dictionary [Электронный ресурс] [Режим доступа: http://www.businessdictionary.com/definition/information-system.html] [Проверено: 01.06.2014]

19. M. Lezoche. Coherence problem between Business Rules and Business Processes: Doctor of Philosophy in Computer Science and Engineering Thesis утв.25.02.2009/prof. Michele Missikoff [Электронный ресурс] [Режим доступа: http://tel. archives-ouvertes. fr/docs/00/65/66/83/PDF/Lezoche_PhD_Thesis. pdf] [Проверено: 03.06.2014]

20. N. Leveson, C. Turner "An Investigation of the Therac-25 Accidents", - Computer, Vol.26, N.7, July 1993, p.18-41.

21. MSF Process Model v.3.1 // Microsoft Download Center [Электронный ресурс] [Режим доступа: http://download. microsoft.com/download/A/D/E/ADEC63C9-6235-4242-B7DE-00AF0FE7BADC/MSFProcessModelv3.1 pdf] [Проверено: 23.04.2014]

22. R. Mayer, P. deWitte. Delivering results: evolving BPR from art to engineering // Integrated Definition Methods [Электронный ресурс] [Режим доступа: http://www.idef.com/pdf/bpr. pdfhttp://download. microsoft.com/download/A/D/E/ADEC63C9-6235-4242-B7DE-00AF0FE7BADC/MSFProcessModelv3.1 pdf] [Проверено: 01.06.2014]

23. Myers, Glenford J. The art of software testing / Glenford J. Myers; Revised and updated by Tom Badgett and Todd Thomas, with Corey Sandler. - 2nd ed. p.6.

24. Software Testing - Bug Life Cycles // Buzzle [Электронный ресурс] [Режим доступа: http://www.buzzle.com/editorials/4-6-2005-68177. asp] [Проверено: 27.04.2014]

25. The ADO.net Entity Framework Overview // Microsoft Developer Network [Электронный ресурс] [Режим доступа: http://msdn. microsoft.com/en-us/library/aa697427%28v=vs.80%29. aspx] [Проверено: 26.05.2014]

26. Valacich, Joseph S. Information systems today: managing in the digital world/ Joe Valacich, Christoph Schneider. - 5^th ed. New Jersey: Pearson Education, Inc., 2012.

27. Haux R LA, Knaup P., Schmьcker P., Winter A. Management von Informationssystemen: Analyse, Bewertung, Auswahl, Bereitstellung und Einfьhrung von Informationssystemkomponenten am Beispiel von Krankenhausinformationssystemen: B. G. Teubner Stuttgart; 1998.

Приложения

Подробная диаграмма классов

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

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

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

a. Опытный пользователь.

b. Профессионал.

c. Хакер.

d. Новичок.

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

a. Администратор.

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

c. Гость.

3. Размер БД:

a. Малый: 0.499.

b. Небольшой: 500.999.

c. Средний: 1000.4999.

d. Выше среднего: 5000.14999.

e. Большой: 15000.49999.

f. Промышленный: 50000.149999.

g. Большие данные: >150000.

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

a. docx/xlsx.

b. ЦХД.

c. doc/xls.

d. CSV.

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

a. 32-разрядная.

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

6. SP:

a. 0 (без SP).

b. 1.

c. 2.

d. 3.

7. ОС:

a. Windows 8 (Windows 8.1 - SP1 для Windows 8).

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

c. Windows 7 (всего 4 SP).

8. Функционал:

a. Учет производства продукции.

b. Подготовка отчета для ежегодного собрания пайщиков.

c. Подготовка годового отчета для налоговой инспекции.

d. Проверка целостности информационной базы и восстановление ее в случае необходимости.

e. Учет отгрузки товара.

f. Учет поступления/расхода сырья.

g. Организация производства нового вида продукции.

h. Прекращение производства вида продукции.

i. Подготовка аналитического отчета по производству/отгрузке продукции за указанный промежуток времени.

j. Учет работников.

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

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

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

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

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

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

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

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

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

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

Цель игры:

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

Новое и опыт:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поле	Тип данных	Ограничения	Источник (таблица)	Значение
idTester	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. Наименование программы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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