Информационная система отдела кадров

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

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

1. Информационная система отдела кадров

1.1 Анализ предметной области

1.1.1 Общее описание предметной области

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

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

? автоматизации работы с документами;

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

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

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

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

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

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

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

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

? паспорт или иной документ, удостоверяющий личность;

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

? страховое свидетельство государственного пенсионного страхования;

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

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

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

1.1.2 Обзор и анализ возможных альтернатив

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

Первую группу образуют свободно распространяемые программы, написанные непрофессионалами. («WDATEOK», «Кадры», «Отдел кадров и ДОУ», «Табель»). Они обеспечивают автоматизацию отдельных функций и не сопровождаются авторами.

Во вторую группу входят программы, которые разрабатываются собственными программистами для своей организации с целью экономии средств. Можно упомянуть такие системы, как «SLS-Кадры», «STAFF-Кадры», «Triamant» и др. Однако опыт показал, что сама по себе система непрерывно развивалась и совершенствовалась, а затраты на ее эксплуатацию и сопровождение превышали затраты на приобретение готового программного обеспечения. Ситуация не изменилась при переносе данной концепции в среду Windows.

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

Наиболее яркими представителями систем такого класса являются «1С Зарплата и кадры», «Platinum», «Ultima-S», «Scala», «Галактика», «БОСС-Кадровик» и др. Для систем этой группы характерна узость базовой версии, что требует достаточно большой доработки и ведет к несовместимости с новыми версиями системы. Сюда же можно отнести системы автоматизации деятельности предприятий с включенными в них модулями «Кадры».

И, наконец, четвертая группа представлена комплексными системами автоматизации деятельности предприятия, основанными на использовании системы баз данных, охватывающих все сферы деятельности предприятия. Среди предлагаемых на рынке систем на первый план выдвигаются «Orakl-Кадры» и «NS2000», представляющие собой системы четвертого поколения и достаточно полно отражающие современный уровень развития программно-аппаратного обеспечения автоматизации деятельности предприятий. Основные отличия зарубежных интегрированных систем управления предприятием от российских заключаются в следующем:

? ориентация на хорошо структурированную иерархическую систему процессов, выполняемых на предприятии;

? опора на наборы стандартов, которым процессы должны удовлетворять, например стандарт ММAS;

? поддержка полного набора управляющих функций (в рамках процесса или предприятия): планирование — контроль отклонений (учет) — регулирование;

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

Система корпоративного учета NS2000 отвечает требованиям функциональной полноты и является лауреатом шестого Международного конкурса программного обеспечения в области финансов и бизнеса. Система спроектирована и разработана с использованием средств BP-WIN, ER-WIN, PROGRESS 4GL.

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

В состав системы R/3 входит модуль «Управление персоналом Oracle Applications» (Oracle Human Resources), который позволяет добиться максимальной отдачи от сотрудников за счет эффективного набора персонала, управления кадрами, обучения, оплаты труда и планирования карьеры. На сегодняшний день в своем классе продуктов модуль «Управление персоналом Oracle Applications» является одной из наиболее функционально полных систем для организации работы отдела кадров современного предприятия.

Его использование позволяет решать следующие задачи:

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

? планирование структурных подразделений, описание разряда, должности, позиции, ведение справочников и т. д.;

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

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

Системе «Orakl-Кадры» присущи все достоинства предыдущих систем. Однако она имеет и ряд дополнительных преимуществ. В системе предусмотрена возможность работы с системой баз данных (штатные сотрудники, уволенные сотрудники, архив, кадровый резерв, временные сотрудники и т. д.), что значительно сокращает время обработки запросов. Вторым несомненным преимуществом является содержимое учетной карточки, включающей 102 темы (согласно постановлению Госкомстата карточка должна содержать не менее 55 тем).

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

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

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

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

? наличие реально работающих версий 1.04 «Oracle-Кадры» в среде Windows 2000/XP.

1.1.3 Модель предметной области в языке UML

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

Рисунок 1.1 — Модель предметной области в языке UML

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

Классы Командировка и Отпуск хранят данные о командировках и отпусках сотрудников с привязкой к конкретному сотруднику.

1.1.4 Модель предметной области в нотации IDEF1X

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

Основные элементы IDEF1X-диаграммы.

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

Сущность — это, например, человек, место, вещь, событие, концепция, о которых хранится информация. Сущности именуются обычно существительными, такими как «покупатель», «компьютер», «служащий», «продажа» .

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

Связь — это функциональная зависимость между сущностями. Например, СЛУЖАЩИЙ совершает ПРОДАЖИ.

Каждая сущность обладает атрибутами. Атрибут — это свойство объекта, характеризующее его экземпляр. Сущность СЛУЖАЩИЙ может иметь атрибуты Имя, Дата рождения и т. д.

На рисунке 1.2 представлена диаграмма предметной области в нотации IDEF1X.

Рисунок 1.2 — Диаграмма предметной области в нотации IDEF1X

Описание сущностей информационной системы приведено в таблице 1.2.

Таблица 1.2 — Описание сущностей информационной системы

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

Таблица 1.3 — Описание сущности employee

Таблица 1.4 — описание сущности business_trip

Таблица 1.5 — описание сущности trip_organizations

Таблица 1.6 — описание сущности holyday

Таблица 1.7 — описание сущности authentication

Таблица 1.8 — описание сущности education_orgs

Таблица 1.9 — описание сущности education_type

Сущность «employee» предоставляет хранилище для личной информации о сотрудниках. Первичным ключом является emp_id. На него ссылаются внешние ключи из сущности «authentication», «holyday», «business_trip». Внешние ключи: «type_id» — ссылается на первичный ключ сущности «education_type», в которой хранятся типы образования; «education_id» — ссылается на первичный ключ сущности «education_orgs», в которой хранятся образовательные учреждения.

Сущность «holyday» предназначена для хранения отпускных приказов сотрудников. Первичным ключом является holyday_id. Сущность «business_trip» предназначена для хранения командировочных приказов сотрудников. Первичным ключом является «trip_id». Внешним ключом является org_id, который ссылается на первичный ключ сущности «trip_organizations», которая хранит командировочные организации.

1.1.5 Выбор технологии проектирования

1.1.5.1 Метод проектирования

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

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

? степень автоматизации проектных работ;

? принятая методология процесса разработки.

? По степени автоматизации проектирования алгоритмов и программ можно выделить:

? методы традиционного (неавтоматизированного) проектирования;

? методы автоматизированного проектирования (CASE-технология и ее элементы).

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

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

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

? структурное проектирование программных продуктов;

? информационное моделирование предметной области и связанных с ней приложений;

? объектно-ориентированное проектирование программных продуктов.

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

В зависимости от объекта структурирования различают:

? функционально-ориентированные методы;

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

? методы структурирования данных.

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

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

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

Структурный подход использует:

? диаграммы потоков данных (информационно-технологические схемы) — показывают процессы и информационные потоки между ними с учетом «событий», инициирующих процессы обработки;

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

? диаграммы декомпозиции — структура и декомпозиция целей, функций управления, приложений;

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

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

Один из основоположников информационной инженерии — Дж. Мартин выделяет следующие составляющие данного подхода:

? информационный анализ предметных областей (бизнес — областей);

? информационное моделирование — построение комплекса взаимосвязанных моделей данных;

? системное проектирование функций обработки данных;

? детальное конструирование процедур обработки данных.

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

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

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

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

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

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

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

? использование специальным образом организованного хранилища проектных метаданных (репозитория).

? Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

? графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

? средства разработки приложений, включая языки 4GL и генераторы кодов;

? средства конфигурационного управления;

? средства документирования;

? средства тестирования;

? средства управления проектом;

? средства реинжиниринга.

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

? Vantage Team Builder (Westmount I-CASE);

? Designer/2000;

? Silverrun;

? ERwin+BPwin;

? S-Designor;

? CASE.Аналитик.

Ещё одной широко распространённой методологией проектирования является технология Scrum[14].

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

Рис. 1.3 — Основа Scrum

Роли. В методологии Scrum всего три роли:

? scrum master;

? product owner;

? team.

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

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

1) создает атмосферу доверия;

2) участвует в митингах в качестве фасилитатора;

3) устраняет препятствия;

4) делает проблемы и открытые вопросы видимыми;

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

Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. ScrumMaster может также помогать Product Owner создавать Backlog для команды.

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

Обязанности Product Owner таковы:

1) отвечает за формирование product vision;

2) управляет ROI;

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

4) координирует и приоритизирует Product backlog;

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

6) взаимодействует с командой и заказчиком;

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

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

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

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

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

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

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

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

5) отвечает за результат перед Product Owner.

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

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

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

Артефакты:

? Product Backlog;

? Sprint Backlog.

Product Backlog — это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.

Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т. д. Product backlog также включает задачи, важные для команды, например «провести тренинг», «добить всем памяти». На рисунке 1.4 приведён пример Product Backlog.

Рис. 1.4 — Пример Product Backlog

Product Backlog постоянно пересматривается и дополняется — в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.

Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

Рисунок 1.5 — Пример Spint Backlog

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.

Рис. 1.6 — Пример Sprint Burndown chart

Спринт (Sprint). В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).

Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов.

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

Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Планирование спринта В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.

Планирование спринта состоит из двух последовательных митингов:

1) планирование спринта, митинг первый Участники: команда, Product Owner, Scrum Master, пользователи, менеджемент Цель: Определить цель спринта (Sprint Goal) и Sprint Backlogфункциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.

Артефакт: Sprint Backlog

2) планирование спринта, митинг второй Участники: Скрам Мастер, команда Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.

Артефакт: в Sprint Backlog появляются задачи Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.

Остановка спринта (Sprint Abnormal Termination)

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

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

Daily Scrum Meeting. Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга — поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга.

Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды:

? что сделано вчера?

? что будет сделано сегодня?

? с какими проблемами столкнулся?

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда.

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

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

Подготовка к митингу не должна занимать у команды много времени (правило — не более двух часов). В частности, именно поэтому запрещается использовать презентации в Power Point. Подготовка к митингу не должна занимать у команды более 2-х часов.

1.1.5.2 Средства проектирования

C# работает на платформе. NetFramework, которая разрабатывалась таким образом, что её можно использовать из любого языка программирования (С#, C++, VisualBasic, Jscript и более старых языков, типа COBOL). Совершенно нормальной является ситуация, когда разработчики используют в C# код, написанный на VisualBasic.Net, и наоборот. Всё это обеспечивает немыслимый доселе уровень гибкости и является одной из причин, по которой использование. NetFramework представляется таким перспективным. [8]

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

Иногда код на C# оказывается объёмнее, чем на С++. Это следствие того, что в C# (в отличие от С++) осуществляется контроль безопасности использования типов (если некоторые данный отнесены к определённому типу, то они не могут самостоятельно преобразоваться к другому типу). Существуют строгие правила, по которым следует осуществлять преобразование из одного типа в другой. Это часто приводит к необходимости писать на C# код более объёмный, чем на С++. Однако в замен мы получаем то преимущество, что программа становится более надёжной и её отладка упрощается.

Хранение информации в базе данных было выбрано вместо файлового хранения, так как:

1) БД минимально избыточна

2) Независимость данных и прикладных программ. Каждая прикладная программа видит БД по своему, т. е. использует те данные, которые программе нужны.

3) Более низкие затраты на хранение данных, создание и сопровождение программ.

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

В таблице 1.10 проведён сравнительный анализ СУБД SQLServer 2008 и Oracle 11g.

Таблица 1.10 — Сравнение возможностей SQLServer 2008 и Oracle 11g. 9]

Преимущества Microsoft SQL Server 2008 по сравнению с Oracle 11g:

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

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

· Управляемость. Оболочка SQL Server PowerShell, платформа Policy Management Framework.

Исходя из вышесказанного, в качестве инструментальных средств разработки были выбраны C# и SQL Server 2008 R2. В качестве средства проектирования выбран ERWIN.

1.2 Анализ требований

1.2.1 Требования к разрабатываемому программному обеспечению

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

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

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

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

Информационная система строится в архитектуре «клиент-сервер», в качестве сервера базы данных необходимо использовать СУБД SQL Server 2008 R2. Для разработки клиентского приложения выбрана среда разработки Visual Studio 2010.

1.2.2 Модель вариантов использования

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

Рисунок 2.1 — Диаграмма вариантов использования В таблице 2.1 приведено краткое описание вариантов использования. Это описание частично раскрывает функциональность разработанной системы.

Таблица 2.1 — Краткое описание вариантов использования.

Полное описание вариантов использования Вариант использования: контроль доступа к системе.

Область действия: используемая программа.

Уровень: цель администратора.

Основное действующее лицо: администратор.

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

Минимальные гарантии: наличие учётной записи администратора в таблице аутентификации.

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

Основной сценарий:

1) администратор входит в систему;

2) использует кнопки для добавления или удаления пользователей;

3) сделав необходимые изменения он завершает работу с системой.

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

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

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

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

Гарантия успеха: при вводе данных не осталось пустых полей и нажата кнопка добавления данных о новых сотрудниках.

Основной сценарий:

1) пользователь проходит аутентификацию;

2) вносит данные о новом сотруднике;

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

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

Основной сценарий:

1) пользователь проходит аутентификацию;

2) открывает поиск и находит необходимого сотрудника;

3) открывает форму сотрудника и вносит изменения;

4) сохраняет результаты работы.

Вариант использования: занести и редактировать информацию о командировках сотрудника.

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

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

Минимальные гарантии: пользователь находится в системе.

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

Основной сценарий:

1) пользователь находится в системе;

2) пользователь определяет условия для поиска сотрудника;

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

4) пользователь производит добавление командировки для сотрудника.

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

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

Предусловие: пользователь находится в системе.

Минимальные гарантии: пользователь находится в системе.

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

Основной сценарий:

1) пользователь находится в системе;

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

3) пользователь находит необходимого сотрудника

4) пользователь добавляет приказ об отпуске в базу.

Вариант использования: составить график отпусков и контролировать его исполнение.

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

Предусловие: программа должна быть загружена, пользователь в системе.

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

Гарантия успеха: пользователь без ошибок выполняет запрос на сортировку данных по отпускным приказам сотрудников.

Основной сценарий:

1) пользователь находится в системе;

2) выбирает функцию составления графика отпусков;

3) выбирает период, за который необходимо составить график;

4) по сформированному графику появляется возможность проконтролировать исполнения графика.

Вариант использования: найти и просмотреть необходимую информацию по сотрудникам.

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

Предусловие: программа должна быть загружена, пользователь в системе.

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

Гарантия успеха: пользователь без ошибок выполняет запрос на поиск сотрудников.

Основной сценарий:

1) пользователь находится в системе;

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

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

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

5) пользователь выводит в отдельное окно данные по требуемому сотруднику.

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

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

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

1.2.3 Модель анализа вариантов использования

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

В реализации варианта использования «Контроль доступа к системе» участвую классы «FromPass» и «TextBox». Объекты класса «TextBox» позволяют заполнить поля для логина и пароля. Объект класса «FormPass» позволяет провести проверку подлинности логина и пароля.

Сама проверка правильности введённого логина и пароля проверяется методом класса «FormPass» — «get_auth ()». Модель данного варианта использования представлена на рисунке 2.4.

Рисунок 2.4 — Анализ варианта использования «Контроль доступа к системе»

В реализации варианта использования «Занести новых сотрудников в базу» участвуют классы «MainForm», «Button», «TextBox», «NumericUpDown». Объект класса «Button» позволяtт добавить сотурдника в базу данных. Объекты классов «TextBox» и «NumericUpDown» позволяют вводить информацию о сотруднике. Само же добавление выполняется методом класса «MainForm» — «save_employee ()».