Создание автоматизированной системы создания и ведения адресных справочников и справочников объектов теплоснабжения

4.5.2. Концепция модуля

Необходимость разработки модуля настройки маршрутизации запросов образовалась в процессе внедрения в систему АСОТ технологии мультизапросов. В первоначальной версии системы у каждого справочника была своя схема маршрутизации запросов. Такая структура программы не позволяла разнотипным объектам проходить по одной и той же схеме маршрутизации в рамках одного запроса, что исключало возможность использования технологии мультизапросов. Также, стоит отметить, что на 35 справочников существовало всего лишь 4 уникальные схемы маршрутизации, что говорит об избыточности данных. Также изменение одинаковых схем являлось довольно трудоёмким и неудобным процессом. Эти факторы тоже повлияли на решение о смене структуры программной части по маршрутизации запросов.



Рис 4.4 Модуль настройки схем маршрутизации

Часть, выделенная голубым фоном (рис. 4.4), показывает структуру разрабатываемого модуля настройки схем маршрутизации. Модуль разбит на три логических элемента: «Настройка схем маршрутизации», «Маршрутизация запросов» и «Запись в БД». Также на схеме изображены компоненты, с которыми модуль настройки схем маршрутизации обменивается данными. С помощью интерфейса создания и редактирования запросов пользователи формируют информацию об изменении данных и отправляют её по настроенной схеме. В ядре АСОТ реализованы все базовые функции работы программы, в том числе и обмен данными с БД.

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

«Маршрутизация запросов» выполняет функцию распределения запросов по ролям по предварительно настроенной схеме маршрутизации.

«Запись в БД» осуществляет запись изменённой информации в базу данных с помощью функций описанных в ядре АСОТ. Перед непосредственной записью данных программа выполняет несколько операций, для проверки полноправности вносимых изменений.

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

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

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

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

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



4.5.3 Описание правил на метаязыке

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

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

Общие положения.

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

Условие - выражение, сравнивающее значение некоторого поля объекта запроса с заданным пользователем или проверяющее определённые параметры запроса.

Описание условий.

Условие может проверять следующее:

Операция над объектом

Изменение значения поля

Наличие изменённых полей кроме заданного

Пустое поле

Вложение

Значение поля

Интерпретатор распознаёт следующие служебные слова: «операция», «изменено», «пустое», «приложен файл». Нераспознанные слова интерпретатор будет воспринимать как название поля.

Проверка операции над объектом.

Для того чтобы задать проверку операции над объектом необходимо написать служебное слово «операция» (без кавычек), далее через пробел задать оператор сравнения: либо «=» либо «<>» и после этого обозначить тип операции - один из: «добавление», «редактирование» или «удаление».

Пример: операция = удаление

операция <> редактирование

операция=добавление - ошибка

Примечание: очень важно соблюдать пробелы между словами и операторами, так как слитно написанную строку интерпретатор воспримет как одно слово и выдаст ошибку. Регистр в свою очередь не имеет значения, поэтому пользователь может написать «Операция» или «УДАЛЕНИЕ». Эти правила распространяются на все остальные служебные слова и конструкции, в том числе и на логические операторы.

Проверка изменённого или пустого значения поля.

Служебными словами для проверки изменённого или пустого значения поля являются «изменено» и «пустое» соответственно. Следующее слово после служебного будет определено как названия поля объекта. Важно, чтобы название поля являлось одним словом (т.е. без пробелов) и соответствовало имени атрибута объекта в базе данных.

Пример: изменено number

пустое street_name

изменено full address - ошибка

Проверка наличия изменённых полей кроме заданного.

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

Пример: изменено кроме graphics

изменено_кроме street_name - ошибка

Проверка наличия приложенного файла.

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

Пример: Приложен файл

приложенФайл - ошибка

Сравнение значений полей.

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

= - равно

<> - не равно

> - больше

< - меньше

>= больше или равно

<= - меньше или равно

Пример: number <> “20”

street_name = “ул. Арбат”

full_number = 10/17 - ошибка

Примечание: При описании правил запрещено использовать символы «~» и «|», так как они являются служебными и требуются для разбора строки правил.

Описание правил.

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

При вычислении логического выражения сначала вычисляется отрицание («не»), затем конъюнкция («и»), и последней - дизъюнкция («или»). Порядок действий вычисляется слева направо.

В выражении «изменено graphics или version = “2” и операция <> удаление» будет следующий порядок действий:

version = “2” и операция <> удаление = результат

изменено graphics или результат = конечный_результат

Если в это выражение добавить скобки: «(изменено graphics или version = “2”) и операция <> удаление», порядок действий изменится:

изменено graphics или version = “2” = результат

результат и операция <> удаление = конечный_результат

Далее следуют несколько примеров описания правил:

не пустое structure или full_number = “20а”

(изменено graphics или version = “2”) и операция <> удаление

(Приложен файл и version > 1) не пустое number - ошибка (между закрывающей скобкой и отрицанием должен стоять оператор)

И операция = удаление и не приложен файл - ошибка (логический оператор «и» не может стоять в начале выражения)

4.5.4 Структура служебной базы данных

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

Рис. 4.5 Структура служебной БД

Схема разбита на несколько цветовых категорий:

Красная - описание схем маршрутизации;

Зелёная - администрирование пользователей;

Синяя - таблицы связей;

Жёлтая - остальные сущности, модуля настройки и выполнения маршрутизации запросов.

Описание схем маршрутизации

Данные о схемах маршрутизации распределены между несколькими таблицами базы данных. Schemes - таблица, в которой хранятся идентификаторы и названия схем маршрутизации. Также здесь содержится файл графического изображения схемы: состояния и переходы, их положение относительно друг друга. States - таблица состояний. В этой таблице хранится название состояния, схема, которой принадлежит состояние, роль, которая работает в данном состоянии, а также правило остановки в этом состоянии. Правило остановки является строкой, перечисляющей все условия, разделённые служебными символами. В State_types перечислены типы состояний. На данный момент таких типа 4: «начальное», «в процессе», «обработан», «отклонён». Transitions - таблица переходов. Помимо информации о входном и выходном состоянии здесь хранятся значения двух флагов: обязательное указание пользователя при переходе, комментарий обязателен. Transition_types содержит типы переходов. Таких перехода всего 3: «Направить» (Forward), «уточнить» (Back), «отклонить» (Abort). Более подробно они описаны в пункте 4.5.1.

Администрирование пользователей

Для предоставления пользователям доступа к системе в АСОТ реализована система авторизации пользователей. Администрирование пользователей выполняет функцию обеспечения безопасности данных, с которыми работают пользователи следующим образом:

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

Ограничение прав доступа к ресурсам и выделение полномочий индивидуально каждому пользователю;

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

Используемая таблица Users. В этой таблице хранятся идентификатор пользователя, его авторизационные данные, контактные данные (ФИО, e-mail), а также время последнего входа в систему и количество активных запросов, в которых он участвует. В таблице Users_processes_actors хранятся связи пользователей и ролей для конкретного бизнес-процесса в определённой схеме.

Сущности схем маршрутизации

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

Справочники, используемые для схем маршрутизации, добавляются в таблицу Refbooks. У справочника должна быть обязательно главная физическая таблица. Все необходимые физические таблицы регистрируются администратором и хранятся в Physical_tables. У справочника есть также связанные таблицы. Для реализации связей между Refbooks и Physical_tables типа N:N (много ко многим) используется таблица связей Refbooks_physical_tables. В схеме маршрутизации может использоваться определённый набор зарегистрированных в системе справочников. Данные о зарегистрированных в схеме справочниках хранятся в таблице связей Refbooks_schemes.

Бизнес-процессы перечислены в таблице Processes. В ней хранится название бизнес-процесса и его принадлежность схеме. Для определения допустимых операций со справочниками в конкретном бизнес-процессе существует таблица Processes_refbooks. Можно создать бизнес-процесс, который допускает только удаление объектов конкретного справочника. Набор допустимых ролей определяет те атрибуты объекта, которые может редактировать пользователь. Информация об этих наборах хранится в Field_sets. Сами же названия полей вынесены в отдельную таблицу Field_sets_fields. У этой таблицы есть также связь с Refboooks, так как имя поля является атрибутом справочника.

Ещё в базе данных есть две таблицы связей Processes_actors_field_sets и Users_processes_actors. Первая описывает связь ролей и наборов полей в бизнес-процессе, а вторая связь пользователей и ролей в бизнес процессе. Это означает, что у одной роли может быть несколько наборов полей, а у одного пользователя может быть несколько ролей и наоборот.



5. Конструкторско-технологическая часть

5.1 Технология программирования

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

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

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

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

Основные идеи гибких методик разработки:

Личности и их взаимодействия важнее, чем процессы и инструменты;

Работающее программное обеспечение важнее, чем полная документация;

Сотрудничество с заказчиком важнее, чем контрактные обязательства;

Реакция на изменения важнее, чем следование плану.

Гибкая методология разработки придерживается следующих принципов:

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

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

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

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

рекомендуемый метод передачи информации - личный разговор (лицом к лицу);

работающее программное обеспечение - лучший измеритель прогресса;

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

постоянное внимание улучшению технического мастерства и удобному дизайну;

простота - искусство не делать лишней работы;

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

постоянная адаптация к изменяющимся обстоятельствам.

Рассмотрим несколько методов более конкретно.

5.1.1 Экстремальное программирование

Экстремальное программирование (англ. Extreme Programming, XP) - это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований. Авторами методологии являются Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Цели экстремального программирования.

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

Принципы экстремального программирования.

Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность - 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.

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

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

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

Достаточная степень смелости и желание идти на риск.

Основные приемы экстремального программирования.

Двенадцать основных приёмов экстремального программирования [2] могут быть объединены в четыре группы:

Короткий цикл обратной связи (Fine scale feedback)

Разработка через тестирование (Test driven development)

Игра в планирование (Planning game)

Заказчик всегда рядом (Whole team, Onsite customer)

Парное программирование (Pair programming)

Непрерывный, а не пакетный процесс

Непрерывная интеграция (Continuous Integration)

Рефакторинг (Design Improvement, Refactor)

Частые небольшие релизы (Small Releases)

Понимание, разделяемое всеми

Простота (Simple design)

Метафора системы (System metaphor)

Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

Стандарт кодирования (Coding standard or Coding conventions)

Социальная защищенность программиста (Programmer welfare):

40-часовая рабочая неделя (Sustainable pace, Forty hour week)

5.1.2 Методология SCRUM

Scrum - одна из самых популярных методологий гибкой разработки. Главным преимуществом этой методологии является её простота [18].

В Scrum существуют всего три роли:

Scrum Master

Product Owner

Team

Скрам Мастер (Scrum Master)

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

Основные обязанности Скрам Мастера таковы:

Создает атмосферу доверия,

Участвует в митингах в качестве человека, обеспечивающего легкую коммуникабельность между участниками митинга

Устраняет препятствия

Делает проблемы и открытые вопросы видимыми

Отвечает за соблюдение практик и процесса в команде

Ведущий проекта (Product Owner)

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

Обязанности ведущего проекта таковы:

Отвечает за формирование концепции продукта

Управляет ожиданиями заказчиков и всех заинтересованных лиц

Координирует и приоритизирует бэклог продукта

Предоставляет понятные и тестируемые требования команде

Взаимодействует с командой и заказчиком

Отвечает за приемку кода в конце каждой итерации

Ведущий проекта ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течение спринта.

Команда (Team)

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

Обязанности команды таковы:

Отвечает за оценку элементов бэклога

Принимает решение по дизайну и имплементации

Разрабатывает софт и предоставляет его заказчику

Отслеживает собственный прогресс (вместе со Скрам Мастером).

Отвечает за результат перед ведущим проекта

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

Спринт (Sprint)

В Scrum итерация называется спринт (sprint). Ее длительность обычно составляет 1 месяц (30 дней). Результатом спринта является готовый продукт, который можно передавать заказчику (по крайней мере, система должна быть готова к показу заказчику). Короткие спринты обеспечивают быстрый отзыв проектной команде от заказчика. Заказчик получает возможность гибко управлять возможностями системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в бэклог продукта, получают приоритет наравне с прочими требованиями и могут быть запланированы на один из следующих спринтов. В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Требования к спринту должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что бэклок спринта никем не может быть изменен, кроме команды.

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

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

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

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

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

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

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



5.1.3 Методология Kanban

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

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

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

Цели проекта:

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

Очередь задач:

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

Проработка дизайна:

В этом состоянии производится разработка дизайна интерфейса или архитектура программного кода.

Разработка:

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

Тестирование:

В этом состоянии производится тестирование разработки. В случае если при тестировании были обнаружены ошибки, задача перемещается обратно в состояние «разработка».

Развертывание:

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

Закончено:

Сюда задача попадает, как только завершены все предыдущие работы по этой задаче.

Неотложно:

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

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

Всю методологию Канбан можно описать всего тремя основными правилами:

Визуализировать производство

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

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

Главными отличиями Канбан от Скрам являются:

Отсутствие лимитов времени ни на задачи, ни на спринты

Задачи больше и их меньше

Оценки сроков на задачу опциональные или вообще их нет

«Скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи

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

Выбор методологии разработки программного обеспечения:

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

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

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

5.2 Выбор используемого программного обеспечения

5.2.1 MySQL-сервер

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

Система управления база MySQL использует язык SQL (Structured Query Language - Структурированный язык запросов). SQL является наиболее распространённым стандартизированным языком, используемым для работы с базами данных. Для работы с MySQL можно вводить запросы на SQL напрямую, вставлять сформулированные тексты запросов в текст кода, написанного на любом другом языке или использовать различные библиотеки функций для работы с MySQL, чтобы не обращаться к синтаксису SQL.

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

MySQL сервер отлично работает как на настольных компьютерах, так и на ноутбуках, не затрудняя работу других приложений или веб-серверов, а также не требует особого обслуживания. Если под работу СУБД выделяется отдельный компьютер, то программное обеспечение можно настроить таким образом, чтобы вся память и ресурсы процессора выделялись для нужд MySQL. Это актуально в том случае, когда с базой данных работает большое количество пользователей одновременно. MySQL сервер был специально разработан для быстрой работы с большими базами данных в сравнении с предоставленными на тот момент решениями. На сегодняшний день MySQL обладает широким набором функций. Простота подключения, скорость работы и высокий уровень безопасности делают эту СУБД максимально пригодной для решения любых задач, связанных с доступом и работой с базами данных.

Система управления базами данных MySQL имеет клиент-серверную архитектуру и состоит из многопотокового SQL сервера, который поддерживает различные модификации, разнообразных клиентов и библиотек, инструментов администрирования и широкого спектра интерфейсов программирования приложений (APIs).

5.2.2 MySQL Workbench

MySQL Workbench - инструмент для визуального проектирования баз данных, интегрирующий проектирование, моделирование, создание и эксплуатацию БД в единое окружение для системы баз данных MySQL. MySQL Workbench предоставляет комплекс инструментов для настройки сервера, администрирования пользователей и многое другое. Программа доступна для работы с операционных системах: Windows, Linux и Mac OS.

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

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

MySQL Workbench упрощает разработку и поддержку баз данных, автоматизирует выполнение наиболее долгих и сложных задач и улучшает взаимодействие между разработчиками и администраторами баз данных. Программа позволяет проектировщикам данных наглядно предоставить требования и, связавшись с коллегами, быстро решить проблему до того как будет потрачено большое количество рабочих ресурсов и времени. С помощью MySQL Workbench можно легко создавать надёжные, хорошо структурированные базы данных и в то же время достаточно гибкие, для того чтобы изменяться и улучшаться, отвечая новым требованиям бизнес задач. Утилиты для проверки моделей данных и структур таблиц обеспечивают высокую надёжность при разработке. Это избавляет разработчика от ошибок по время моделирования новой ER-диаграммы или создания физической MySQL базы данных.

Главные преимущества программы:

Позволяет наглядно представить модель базы данных в графическом виде;

Наглядный и функциональный механизм установки связей между таблицами, в том числе «многие ко многим» с созданием таблицы связей;

Reverse Engineering - восстановление структуры таблиц из уже существующей на сервере БД;

Удобный редактор SQL запросов, позволяющий сразу же отправлять их серверу и получать ответ в виде таблицы;

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

5.2.3 SQLyog Community

SQLyog - это графический интерфейс пользователя для популярной системы реляционных баз данных MySQL. Программа создана компанией Webyog Softworks Pvt. Ltd. Основная задача, которую решает SQLyog - это удобная работа с MySQL базами данных посредством наглядных графических элементов.

Главные функции SQLyog:

Конструктор запросов

Умное автозавершение

Интеллектуальное дополнение кода

Туннелирование HTTP и HTTPS

Туннелирование SSH

Соединения

Инструмент миграции в виде wizard.

Синхронизация Структуры/Данных

Полноценная поддержка Юникода.

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

Благодаря автозавершению количество ошибок при составлении запросов существенно снижается, а скорость набора текста запроса сильно вырастает. В сложных структурах баз данных обычно содержится большое количество таблиц. Поэтому для разграничения назначения таблиц их именуют таким образом, чтобы из названия можно было однозначно определить функцию таблицы. Из-за этого длина имён таблиц иногда достигает свыше 50 символов, например: «ext_st_lnk_heat_sources_asot_expert_history_changelog». При составлении запроса имя такой таблицы довольно долго набирать, а ошибиться очень просто. Автозавершеие решает эту проблему.

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

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

5.2.4 Borland Delphi 7

Borland Delphi 7 - это интегрированная среда разработки программного обеспечения для операционной системы Microsoft Windows на языке Delphi.

Интерфейс этой среды представляет собой несколько отдельных окон. Каждое из окон выполняет свою функцию. Здесь есть: панель инструментов, редактор программного кода, просмотрщик объектов, редактор графического интерфейса приложения, окно стека вызовов и так далее. Каждое окно может иметь произвольный размер и располагаться в любом удобном для разработчика месте. Delphi 7 позволяет сохранить такое расположение окон для того, чтобы использовать такую рабочую поверхность в дальнейшем. Эту функцию среды очень удобно использовать для работы в двух наиболее часто используемых режимах: разработка и отладка. При разработке нужны такие окна как: редактор кода, редактор графического интерфейса, просмотрщик объектов. Во время отладки обычно редактируется код и просматривается стек вызовов, а остальные окна можно скрыть. Функция рабочих поверхностей позволяет сделать рабочий процесс максимально комфортным в зависимости от режима, в котором работает разработчик. Рассмотрим функциональность основных окон среды подробнее.

Панель инструментов

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

Но самым необходимым элементом на панели инструментов является набор компонентов. Набор компонентов содержит список установленных в среде компонентов, объекты которого можно использовать в разрабатываемом приложении. Delphi 7 предоставляет довольно большой спектр стандартных компонентов, но при желании можно установить дополнительные. Компонент Delphi представляет собой библиотеку классов. Классы, описанные в компоненте, могут являться графическими элементами, которые вы можете использовать в своём приложении, просто перетащив иконку элемента к себе на редактор графического интерфейса. Также там могут содержаться запрограммированные алгоритмы, которые можно использовать для реализации определённой части вашего приложения, например: поиск кратчайшего пути. В сети Интернет есть множество компонентов, распространяющихся как на платной, так и на бесплатной основе. Это предоставляет широкий инструментарий для разработчиков и позволяет сократить большое количество время на программировании уже готовых решений.

Редактор кода

Редактор кода является, по сути, текстовым редактором с множеством дополнительных функций. Редактор кода отображает текущее положение курсора в тексте кода - номер строки и столбца. Это очень удобно, особенно когда размер кода одного файла превышает тысячу строк. Индексация положения курсора сильно облегчает навигацию разработчика по коду программы. Редактор кода в Delphi 7 поддерживает контекстную подсветку. Это означает, что текст будет принимать определённое форматирование в зависимости от своего назначения. Например, служебные лексемы выделяются жирным, а комментарии окрашиваются в синий цвет и приобретают атрибут курсива. Форматирование текста можно произвольно менять. Можно окрашивать не только цвет шрифта, но и его фона. Также в данной среде поддерживается система шаблонов текста. Разработчик может предварительно установить шаблон для определённого заменяемого значения и по нажатию определённого сочетания клавиш описанный шаблон вставится в текст кода. Эта функция помогает поддерживать единый стиль кода приложения, а также сократить количество времени на наборе распространённых конструкций циклов, условий, заголовка функций и процедур и так далее. В Delphi 7 есть функция перехода от объявления функции в классе к её описанию в коде, а также история перемещения по тексту, которая позволит возвращаться в предыдущие места редактирования кода программы.

Редактор графического интерфейса и просмотрщик объектов

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

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

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

5.2.5 WinCVS

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

Хранение истории изменения файла для возможности отката к предыдущей версии;

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

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

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

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

6. Охрана труда

6.1 Основные положения

Охрана труда - система сохранения жизни и здоровья работников в процессе трудовой деятельности, включающая в себя следующие мероприятия [30]:

правовые

организационно-технические

социально-экономические

лечебно-профилактические

санитарно-гигиенические

реабилитационные

Система управления охраной труда (СУОТ) - часть общей системы управления организации, обеспечивающая управление рисками в области охраны здоровья и безопасности труда, связанными с деятельностью организации (ГОСТ 12.0.230-2007).

Система включает:

организационную структуру;

распределение ответственности;

деятельность по планированию;

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

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

6.2 Безопасность труда при работе с персональным компьютером

В соответствии с Санитарными правилами СанПиН 2.2.2/2.4.1340-03 «Гигиенические требования к персональным электронно-вычислительным машинам (ПЭВМ) и организации работы» осуществляется за производством и эксплуатацией ПЭВМ.

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

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

Помещения оборудованы защитным заземлением (занулением) в соответствии с техническими требованиями по эксплуатации.

Шумящее оборудование (печатающие устройства, серверы и т.п.), уровни шума которого превышают нормативные, размещены вне помещений с ПЭВМ. Расстояния между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора), составляет 2,5 метра. Расстояние между боковыми поверхностями видеомониторов - 1,2 м. Использованы рабочие столы, отвечают современным требованиям эргономики. Рабочий стул (кресло) оборудовано подъемно-поворотным устройством, регулируемым по высоте и углам наклона сидения и спинки, а также расстоянию спинки от переднего края сидения. Экран видеомонитора находится от глаз пользователя на расстоянии 670 мм, клавиатура располагается на поверхности стола на расстоянии 200 мм от края, обращенного к пользователю. Клавиатура оборудована специальной накладкой для ладоней, для снижения изгиба запястья и снижения напряжения рук при работе за ПЭВМ.

...