Дипломная (вкр): Информационная система отдела кадров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Артефакты:

−   Product Backlog;

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

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

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

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

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

Планирование спринта

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

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

) планирование спринта, митинг первый

Участники: команда, Product Owner, Scrum Master, пользователи, менеджемент

Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.

Артефакт: Sprint Backlog

) планирование спринта, митинг второй

Участники: Скрам Мастер, команда

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

Артефакт: в Sprint Backlog появляются задачи

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

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

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

После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и начинаются работы.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.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 - Краткое описание вариантов использования.