47
2.2.2. Характеристика нормативно-справочной, входной и
оперативной информации.
Описании входных документов
План спринта. План спринта это событие в scrum, которое обозначает
старт спринта. В ходе планирования определяется объём работы на спринт и
методы для выполнения этой работы. Источником данных являются
требования заказчика.
SCRUM мастер, владелец продукта вносит:
1. Имя руководителя
2. Имя команды
3. Время спринта
4. Перечень задач на планируемый спринт
48
Экранная форма планирования спринта представлена на схеме 5.
Схема 5 Экранная форма планирования спринта
49
Журнал продукта. Включает в себя в себя все требования и пожелания к
разрабатываемому продукту. Иногда в журнал записывают задачи, которые
косвенно касаются создания продукта. Это может быть улучшения процессов
работы над создаваемым проектом. Источником данных являются требования
заказчика.
Владелец продукта вносит:
1. Требования к продукту
Экранная форма журнала спринта представлена на схеме 6.
Схема 6 Экранная форма журнала спринта
50
В системе используются справочники, представленные в таблице 8.
Таблица 8
Перечень используемых справочников
№
Название
справочника
Отечественный
за ведение
Средний объём
справочника в
записях
Средняя
частота
актуализаци
и
Средний
объем
актуализа
ции в %
1
Журнал
продукта
SCRUM мастер,
владелец
продукта
1235
1 раз /мес
20
2
План спринта
SCRUM мастер,
владелец
продукта
863
1 раз в
месяц
20
Реквизиты входной информации, которая используются системе,
представленные в таблице 9.
Таблица 9
Реквизиты входной информации
Наименование
справочника
Реквизиты
SprintMagazine
sprintId:
teamId:
sprintTime:
taskId:
Task
taskId:
parentTaskId:
textTask
isDone:
backlog:
type:
asignUser
asigneSprint:
sprintName:
В таблице 10 представлена оперативная информация.
51
Таблица 10
Оперативная информация
№
Название
таблицы
Отечественный
за ведение
Средний объём
справочника в
записях
Средняя
частота
актуализации
Средний объем
актуализации в
%
1
Task
SCRUM
мастер,
владелец
продукта
4000
ежедневно
100
В таблице 11 приведены реквизитный состав.
Таблица 11
Реквизитный состав
№
Наименование
Перечень реквизитов
1
User
userId:
firstName: string
surName: string
mail: string
passord: string
teamId: int||string
2
Team
teamId
nameTeam
userId
owner
3
SprintMagazine
sprintId
teamId
sprintTime
taskId
52
4
Task
taskId:
parentTaskId
textTask
isDone
backlog
type
asignUser
asigneSprint
sprintName
label
53
2.2.3. Характеристика результатной информации
К итогам работы разработанной информационной системы относится:
Выходные экранные формы «Документация прототипа»;
Файл, содержащий информацию о пользователях системы.
Макет экранной формы «Документация прототипа», где пользователь
может составить перечень выполненных задач и их описание. Макет
представлен на рисунке 4.
Рисунок 4 Макет экранной формы «Документация прототипа»
54
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Дерево функций это иерархическая модель видов деятельности
предприятия, обеспечивающих достижение дерева целей. Вершиной дерева
функций является главная цель предприятия, ветви дерева представляют
собой функции (или работы), которые необходимо реализовать для
достижения главной цели предприятия и подчиненных ей целей нижнего
уровня.
Диалог – это процесс взаимодействия между пользователем и
персональным компьютером, через сообщения, во время которой
осуществляется постоянная смена ролей информатора и пользователя,
принимающего информацию, причем скорость смена ролей достаточно
высокая.
В процессе диалога возможно:
двустороннее управление на базе языка типа «запрос-ответ»,
одностороннее управление со стороны ИС с языком общения типа
«меню», «заполнения шаблона», ответа по «подсказке»,
одностороннее управление со стороны пользователя с использованием
языка директив (команд).
Сценарий диалога пользователя с приложением приведён в схеме 7.
Схема 7 сценарий диалога пользователя с приложением
55
2.3.2. Характеристика базы данных
В отличие от реляционных баз данных MongoDB предлагает документо-
ориентированную модель данных, благодаря чему MongoDB работает
быстрее, обладает лучшей масштабируемостью, ее легче использовать.
Формат данных в MongoDB
Одним из популярных стандартов обмена данными и их хранения
является JSON (JavaScript Object Notation). JSON[14] эффективно описывает
сложные по структуре данные. Способ хранения данных в MongoDB в этом
плане похож на JSON, хотя формально JSON не используется. Для хранения
в MongoDB применяется формат, который называется BSON (БиСон) или
сокращение от binary JSON.
BSON позволяет работать с данными быстрее: быстрее выполняется
поиск и обработка. Хотя надо отметить, что BSON в отличие от хранения
данных в формате JSON имеет небольшой недостаток: в целом данные в
JSON-формате занимают меньше места, чем в формате BSON, с другой
стороны, данный недостаток с лихвой окупается скоростью.
Кроссплатформенность
MongoDB написана на C++, поэтому ее легко портировать на самые
разные платформы. MongoDB может быть развернута на платформах
Windows, Linux, MacOS, Solaris. Можно также загрузить исходный код и
самому скомпилировать MongoDB, но рекомендуется использовать
библиотеки с офсайта.
Документы вместо строк
Если реляционные базы данных хранят строки, то MongoDB хранит
документы. В отличие от строк документы могут хранить сложную по
структуре информацию. Документ можно представить как хранилище
ключей и значений.
Ключ представляет простую метку, с которым ассоциировано
определенный кусок данных.
56
Однако при всех различиях есть одна особенность, которая сближает
MongoDB и реляционные базы данных. В реляционных СУБД встречается
такое понятие как первичный ключ. Это понятие описывает некий столбец,
который имеет уникальные значения. В MongoDB для каждого документа
имеется уникальный идентификатор, который называется _id. И если явным
образом не указать его значение, то MongoDB автоматически сгенерирует
для него значение.
Каждому ключу сопоставляется определенное значение. Но здесь также
надо учитывать одну особенность: если в реляционных базах есть четко
очерченная структура, где есть поля, и если какое-то поле не имеет значение,
ему (в зависимости от настроек конкретной бд) можно присвоить
значение NULL. В MongoDB все иначе. Если какому-то ключу не
сопоставлено значение, то этот ключ просто опускается в документе и не
употребляется. ER-модели базы данных, представленной на схеме 8.
Схема 8 ER модель базы данных