Рефлексия Вотинцевой Ксении.
Я думаю, эта игра наглядно демонстрирует реальный процесс стабилизации. Однако не могу сказать, что теперь я всё поняла в этом процессе. Кое-что я усвоила (например, уточнение всех-всех-всех деталей ещё на этапе написания ТЗ), но кое-что до сих пор мне не ясно (например, наша игра расходилась с трактовкой стабилизации от MSF и это привело к непониманию того, как на самом деле должна проходить стабилизация).
Игра сама по себе - удачное решения для обучения процессу создания (в частности стабилизации) проекта. Я бы хотела, что бы в дальнейшем проводились подобные игры. Во-первых, это интересно, во-вторых нескучно. Но чтобы игра прошла успешно, нужны строго установленные правила. В данной игре они постоянно менялись, а из-за этого возникало много непонятных мне моментов. Понятна цель игры, непонятны её правила, а следовательно и способы достижения цели.
Рефлексия Капгер Анны.
В ходе игры в Стабилизацию мы вновь убедились в том, что ТЗ очень важно научиться писать грамотно, Тестировать каждую функцию необходимо заново, после исправления каждой ошибки.
Игра была очень интересной и очень полезной для того, что бы понять суть стабилизации б более крупных масштабах. Сложным оказался лишь переход к новому формату тестирования, вместо + и – появились номера сообщений и действия к программисту, для этого пришлось переделывать снова все практически с нуля. По-моему, лучше было сразу начинать с этого.
Рефлексия Красноперовой Анастасии.
Скорее всего, у данной игры было несколько целей. Во-первых, она показала нам, что тестирование можно продолжать вечно, поэтому действовать «в лоб» крайне неэффективно. Во-вторых, мы попытались составлять план тестирования для промышленной системы, хоть и вымышленной. Также участники игры приобрели очередной опыт работы в команде.
Организация игры не всегда удовлетворяла. Я не уверена, все ли сразу поняли, что необходимо продумать стратегию для тестирования, возможно, кто-то не извлек уроков, а просто получил опыт в тестировании. На сколько мне известно, попыток оптимизировать процесс практически не было. Также не всегда был хорошо продуман ход самих занятий, большое количество времени тратилось впустую или на решение организационных вопросов. Игру можно было бы сделать менее монотонной, чтобы как-то дополнительно заинтересовать студентов. Необходимо более подробно продумать ее процесс, возможно, есть потребность в большем количестве людей, которые сообщают командам найденные ошибки.
В целом подобные игры полезны для отработки полученных на лекциях знаний, можно было бы повысить их эффективность, если бы они требовали применения как можно большего объёма изученного материала.
Рефлексия Филатова Данила.
Цель данной игры – научиться составлять план тестирования, находить ошибки и недочеты в ТЗ, понять некоторые сокровенные тайны тестирования, которые раньше были недоступны нашему взору. В рамках игры была новая ситуация намного более реалистичная предыдущих. Узнали, что от ТЗ и от его понимания зависит многое и что полного тестирования не бывает и надо чем-то жертвовать.
С точки зрения организации самой игры не всегда понятны цели игры и способы их достижения. Результат пока нулевой, ¿но все ещё впереди? Не хватило понимания того, чего от нас хотят. Для оптимального результата, как мне кажется, нужно увеличить скорость игры, а то после всех пыток мы даже не узнали результат, что в итоге то?
По сравнению с традиционными методами обучения такой способ обучения лучше, но намного дольше. Такие игры просто так не выпадают из памяти в отличии от лекций, но зато требуют больше времени.
Предложения по усовершенствованию: ускорить игру в несколько раз. 1 неделя – 1 пара это как то слишком медленно.
Рефлексия Шилова Юрия.
Игра в стабилизацию была проведена для того, чтобы показать зависимость правильного составления ТЗ и степени мучений, которые потом испытают тестировщики на стадии стабилизации. Введение сроков заставило задуматься над тем, как нужно правильно использовать время тестирования и разрабатывать специальную стратегию по которой может быть достигнут лучший результат. Также был получен опыт насчет составления ТЗ, а именно: не писать там чушь, выполнить которую невозможно по техническим, временным или другим параметрам.
Целью игры на мой взгляд было показать то, что составление ТЗ подобно копанию могилы самому себе: чем больше невыполнимых, неоднозначных и туманных пунктов пишешь, тем глубже яма.
Сама идея проведения таких тренингов понравилась, ведь любая практика, пусть даже имитированная, приносит намного больше пользы, чем сухие лекции "о том как надо и не надо делать". Учиться на чужих ошибках в такой среде, на мой взгляд, крайне трудно, поэтому нужно было самому столкнуться с этими проблемами, самому найти способы их преодоления и выработать стратегию поведения, при которой в дальнейшем количество таких столкновений сводится к минимуму.
Точно определить, что понравилось, а что нет не могу, т.к. половину игры я даже не мог понять чего от нас хотят и что конкретно надо делать (статья о стабилизации совсем не помогла).
Что касается усовершенствований, я бы попробовал ввести соревновательную составляющую: составил примерную шкалу выполнения стабилизации и на каждой паре показывал всем студентам кто насколько продвинулся (своеобразный рейтинг). Это может не только мотивировать отстающих пересмотреть свою работу, но и поможет определить примерный курс действий для тех, кто делает правильные шаги. Например, можно составить возможный список вопросов по ТЗ, которые могут задать студенты, список критически важных тестирований, и по мере того, как группы будут выполнять эти действия, увеличивать степень выполнения стабилизации по 100-бальной шкале и демонстрировать эти результаты на каждой паре в открытом режиме.
Также неплохо было бы ввести открытую систему штрафов, да и вообще с самого начала игры опубликовать критерии оценивания работы, которые бы как раз и опирались на степень выполнения задания из идеи, описанной выше. К примеру, команда, имеющая наибольший рейтинг получает 10 в рейтинг НИСа, вторая - 9 и т.д. На мой взгляд, проект никак не использует свое преимущество в плане оценивания перед другими проектами типа "напиши и сдай", а именно растяженность во времени. Народ должен знать что теряет!
6.Отзывы студентов о программе
Отзыв Бушуева Романа.
Программа хороша для первого курса, чтобы они поняли, что протестировать все тесты нереально. Программу желательно использовать на самых ранних этапах первого курса, они должны почувствовать, что такое тестирование на себе.
Программа работает, но количество вариантов для ошибок слишком малы. Количество возможных вариантов, которые необходимо рассмотреть равно приблизительно 52000, а количество вариантов, в которых возникают ошибки равно 200. Вероятность слишком мала. Если предположить, что на каждый тест уйдет 1 секунда, то на все около 15 часов. Легче запустить написать программу, которая будет генерировать все возможные варианты, чем прогонять все в ручную.
После того, как ошибка найдена, и мы составили отчет об ошибке, а программисты исправили, то ведь у нас могут возникнуть ошибки на ранее пройденных тестах.
Отзыв Красноперовой Анастасии.
В целом система полезная, верится, что она позволит автоматизировать процесс обучения студентов процессу стабилизации. Скорее всего, заполнение формы параметрами тестирования будет способствовать усвоению студентами, что именно нужно учитывать при тестировании функций продукта. Тем не менее, программу можно сделать эффективнее, если дать студентам возможность самим предварительно подумать, с учетом каких параметров необходимо производить тестирование.
Отзыв Котельниковой Надежды.
Программа полезная и многообещающая. В рабочей среде станет мощнейшим инструментом для студентов и преподавателей. Нам больше не надо составлять свои тесты, теперь пакеты тестов строятся по единому удобному шаблону, также отпадает проблема нехватки свободных консультантов, когда нужно проверить готовый пакет тестов. На мой взгляд, это автоматизирует процесс обучение, что помогает сохранить время.
7.Описание таблиц БД
В приложении представлено описание таблиц PPS и соответствующих им сгенерированных классов.
Таблица «Functions» содержит описание функционала «разрабатываемой» системы (см. табл. 2.1.).
Таблица 7.1.1.1. Структура таблицы «Functions»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idFunction
|
uniqueidentifier
|
Уникальное
|
Functions
|
Идентификатор записи
|
FunctionName
|
Строка(200)
|
|
Functions
|
Наименование функции
|
Таблица «OperatingSystemNames» содержит перечень операционных систем, на которых впоследствии будет использоваться система «ОбалдеИТ» (см. табл. 2.2).
Таблица 7.1.1.2. Структура таблицы «OperatingSystemNames»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idOperatingSystem
|
uniqueidentifier
|
Уникальное
|
OperatingSystemNames
|
Идентификатор записи
|
OSName
|
Строка(50)
|
|
OperatingSystemNames
|
Наименование функции
|
Таблица «FileExtensions» содержит информацию о форматах входных данных для функций системы «ОбалдеИТ» (см. табл. 2.3).
Таблица 7.1.1.3. Структура таблицы «FileExtensions»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idFileExtension
|
uniqueidentifier
|
Уникальное
|
FileExtensions
|
Идентификатор записи
|
ExtensionLine
|
Строка(50)
|
|
FileExtensions
|
Линия расширений, характерных для определенных программных продуктов.
|
Таблица «ServicePacks» содержит информацию о наличии в ОС пакета обновления с соответствующим номером (см. табл. 2.4). Если на ОС ни один пакет обновления не установлен, ставится «0».
Таблица 7.1.1.4. Структура таблицы «ServicePacks»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idServicePack
|
uniqueidentifier
|
Уникальное
|
ServicePacks
|
Идентификатор записи
|
SequenceNumber
|
Целое
|
|
ServicePacks
|
Порядковый номер SP.
|
Таблица «TesterRoles» содержит информацию о доступных специалисту по тестированию ролях (различаются права доступа) для входа в систему (см. табл. 2.5).
Таблица 7.1.1.5. Структура таблицы «TesterRoles»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idTesterRole
|
uniqueidentifier
|
Уникальное
|
TesterRoles
|
Идентификатор записи
|
RoleDescription
|
Строка(50)
|
|
TesterRoles
|
Описание роли и доступных прав.
|
Таблица «DbSize» содержит информацию о доступных базах данных с различным объемом данных (см. табл. 2.6).
Таблица 7.1.1.6. Структура таблицы «DbSize»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idDbSize
|
uniqueidentifier
|
Уникальное
|
DbSize
|
Идентификатор записи
|
Description
|
Строка(30)
|
|
DbSize
|
Описание (название) БД.
|
NumberOfRowsFrom
|
Целое
|
Положительное
|
DbSize
|
Нижняя граница диапазона значений количества строк.
|
NumberOfRowsTo
|
Целое
|
Положительное
|
DbSize
|
Верхняя граница диапазона значений количества строк.
|
Таблица «Qualifications» содержит информацию о возможных квалификациях пользователей (специалистов по тестированию) (см. табл. 2.7).
Таблица 7.1.1.7. Структура таблицы «Qualifications»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idQualification
|
uniqueidentifier
|
Уникальное
|
Qualifications
|
Идентификатор записи
|
Description
|
Строка(50)
|
|
Qualifications
|
Описание квалификации (умений) пользователя.
|
Таблица «Testers» содержит информацию о тестировщиках, доступных для использования в процессе стабилизации (см. табл. 2.8).
Таблица 7.1.1.8. Структура таблицы «Testers»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idTester
|
uniqueidentifier
|
Уникальное
|
Testers
|
Идентификатор записи.
|
Description
|
Строка(30)
|
|
Testers
|
ФИО тестировщика.
|
idQualification
|
uniqueidentifier
|
|
Qualifications
|
Ссылка на квалификацию тестировщика.
|
Таблица «Messages» содержит информацию о сообщениях, выводимых студентам в процессе тестирования (см. табл. 2.9).
Таблица 7.1.1.9. Структура таблицы «Messages»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idMessage
|
uniqueidentifier
|
Уникальное
|
Messages
|
Идентификатор записи.
|
MessageText
|
Строка(MAX)
|
|
Messages
|
Текст сообщения.
|
Таблица «Configurations» содержит информацию о начальном состоянии программного продукта «ОбалдеИТ» (см. табл. 2.10).
Таблица 7.1.1.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).
Таблица 7.1.1.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).
Таблица 7.1.1.12. Структура таблицы «Teams»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idTeam
|
uniqueidentifier
|
Уникальное
|
Teams
|
Идентификатор записи.
|
Members
|
Строка(50)
|
|
Teams
|
Состав команды.
|
Таблица «TestingLog» содержит информацию о конфигурациях, которые были проверены (см. табл. 2.13).
Таблица 7.1.1.13. Структура таблицы «TestingLog»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
idLogItem
|
uniqueidentifier
|
Уникальное
|
Teams
|
Идентификатор записи.
|
idTestReport
|
uniqueidentifier
|
|
TestReports
|
Ссылка на ситуацию для проверки.
|
idBuild
|
uniqueidentifier
|
|
Builds
|
Ссылка на версию программы.
|
Таблица «Builds» содержит информацию о «билдах» – версиях тестируемой системы «ОбалдеИТ» (см. табл. 2.14).
Таблица 7.1.1.14. Структура таблицы «Builds»
Поле
|
Тип данных
|
Ограничения
|
Источник (таблица)
|
Значение
|
IdBuild
|
uniqueidentifier
|
Уникальное
|
Builds
|
Идентификатор записи.
|
Team_idTeam
|
uniqueidentifier
|
|
Teams
|
Ссылка на команду, для которой был выпущен «билд».
|
BuildNumber
|
Целое
|
Положительное
|
Builds
|
Порядковый номер версии.
|
TimeToAccomplishment
|
Целое
|
Положительное
|
Builds
|
Время до выпуска текущей версии. Если значение равно «0», то версия выпущена.
|
Приложение F. Техническое задание
ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
Пермский филиал
федерального государственного автономного образовательного
учреждения высшего профессионального образования
"Национальный исследовательский университет
"Высшая школа экономики"
Факультет бизнес-информатики
|
Кафедра информационных технологий в бизнесе
|
Информационная система связи факультета вуза с работодателями
Техническое задание
|
|
|
Работу выполнил студент
группы БИ-10-1
4 курса факультета бизнес-информатики
Югов А.С.
Руководитель практики:
Доцент кафедры информационных технологий в бизнесе, к.ф-м.н., доцент
Плаксин М.А.
“_____” 20__ г.
|
Пермь 2014
|
|
