Методология Scrum

Размещено на http://www.allbest.ru

Методология Scrum

Введение

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

Термин Scrum был впервые озвучен в работе Хиротаки Такеучи и Икуджиро Нонака, опубликованной в Harvard Business Review, где авторы отметили успешность проектов, использующих небольшие команды без жесткой специализации. Такие команды чем-то напоминают конструкцию схватки (scrum) в регби, которая назначается при нарушении правил или остановке игры. Джеф Сазерленд использовал эту работу при создании методологии для корпорации Easel в 1993 году, которую по аналогии и назвал Scrum, а Кен Швабер формализовал процесс для использования в индустрии разработки программного обеспечения, представив в 1995 году работу на конференции Object-Oriented Programming Systems, Languages & Applications.

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

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

1. Концепция Scrum

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

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

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

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

2. Роли

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

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

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

3. Практики

спринт связь scrum

Подготовка к первой итерации, называемой спринт (Sprint), начинается после того, как владелец продукта разработал план проекта, определил требования и отсортировал их в количестве, достаточном для наполнения одной итерации. Такой список требований называется журналом продукта (Product Backlog). При планировании итерации происходит детальная разработка сессий планирования спринта (Sprint Planning Meeting), который начинается с того, что владелец продукта, Scrum-команда и Scrum-мастер проверяют план развития продукта, план релизов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основываясь на размере команды, доступном времени и производительности. Важно, чтобы Scrum-команда выбирала первые по приоритету требования из журнала продукта. После того как Scrum-команда обязуется реализовать выбранные требования, Scrum-мастер начинает планирование спринта. Scrum-команда разбивает выбранные требования на задачи, необходимые для его реализации. Эта активность в идеале не должна занимать больше четырех часов, и ее результатом служит список требований, разбитый на задачи, -- журнал спринта (Sprint Backlog). Необходимо, чтобы все участники команды приняли на себя обязательство по реализации выбранной цели.

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

В конце каждого спринта проводится демонстрационный митинг (Sprint Review Meeting) продолжительностью не более четырех часов. Сначала Scrum-команда демонстрирует владельцу продукта сделанную в течение спринта работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных заказчиков. Владелец продукта определяет, какие требования из журнала спринта были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в журнале продукта для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда ищет использованные в последнем спринте положительные и отрицательные способы совместной работы, анализирует их, делает выводы и принимает важные для дальнейшей работы решения. Scrum-команда также определяет программы, которые могут работать лучше, и ищет пути для увеличения эффективности дальнейшей работы. Затем цикл замыкается, и начинается планирование следующего спринта (рис. 1).

Рис. 1 Схема Scrum

4. Документы

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

Рис. 2 Фрагмент журнала продукта

После того как команда во время сессии планирования выбрала и обязалась реализовать набор требований из журнала продукта, эти требования разбиваются на более мелкие задачи, составляющие детализированный список требований -- журнал спринта (рис. 3). Разбивка на задачи должна быть сделана таким образом, чтобы выполнение одной задачи занимало не больше двух дней (считается, что менее детальная, например, полдня, разбивка приводит к более грубой оценке, чем приемлема в большинстве проектов, использующих методологию Scrum). Разбивка на задачи поможет так спланировать итерацию, чтобы в конце не осталось ни одной невыполненной задачи и, соответственно, достичь ее цели. После завершения детализации оценка журнала спринта сравнивается с первичной оценкой в журнале продукта. Если существует значительное расхождение, команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем будет перенесен на следующую. Менее важные и мало влияющие на цель итерации задачи выносятся из журнала спринта.

Рис. 3 Журнал спринта

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

5. Стабильность

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

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

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

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

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

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

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

6. Компания Exigen Services StarSoft

Компания Exigen Services специализируется на разработке ИТ-решений, предоставлении услуг аутсорсинга и системной интеграции. В феврале 2007 года компания Exigen Services объединилась с компанией StarSoft Development Labs, ведущим разработчиком заказного программного обеспечения, и сегодня Exigen Services является крупнейшим поставщиком услуг ИТ-аутсорсинга в Центральной и Восточной Европе. Штаб-квартира Exigen Services StarSoft находится в США (Сан-Франциско), а центры разработки -- в США (Бостон), России (Санкт-Петербург, Москва, Казань), Украине (Днепропетровск, Одесса), Латвии (Рига), Литве (Вильнюс).

Работа с клиентами, разбросанными по всему миру, невозможна без применения в Exigen Services StarSoft специальных инструментальных средств и методологий, предназначенных для уменьшения стоимости и длительности разработки, а также ускорения внедрения новых приложений. В компании применяется производственный процесс, сертифицированный по системе управления качеством CMMI Level 5, ISO- 9001, а также методологии разработки?-- экстремальное программирование (XP) и Scrum. На сегодняшний день компания выполнила более ста различных agile-проектов создания специализированных решений (автоматизация и реинжиниринг бизнес-процессов) в сфере финансовых услуг, телекоммуникаций, страхования, здравоохранения и государственного управления, а также разработки коммерческих программных продуктов для клиентов в сфере ИТ.

Scrum-проекты

Несмотря на то что Scrum, как и ряд других методологий, ориентируется на локальную разработку, опыт компании Exigen Services (StarSoft) показал, что она может быть с успехом применена и в условиях работы большой и географически распределенной команды. Методология Scrum была использована совместно с американской компанией SirsiDynix при разработке новой библиотечной системы в рамках совместного проекта Horizon 8.0.

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

Компания SirsiDynix начала разработку проекта своими силами, используя подход для масштабирования Scrum, называемый Scrum of Scrums (рис. I). При этом вся проектная команда делится на несколько небольших Scrum-команд, синхронизирующих свою работу на регулярных совещаниях. Как правило, производится вертикальное деление на команды, чтобы минимизировать зависимости между командами. В случае SirsiDynix, эти команды занимались разработкой различных функциональных модулей продукта.

В течение первого года разработки давление со стороны рынка и необходимость выведения продукта в более короткий срок вынудили компанию SirsiDynix в условиях ограниченного бюджета удвоить производительность команды -- было принято решение о партнерстве с Exigen Services (StarSoft). Классический способ ускорения работ над проектом в условиях аутсорсинга части проекта -- применение схемы Scrum of Scrums, в которой команды географически удалены друг от друга. К сожалению, данный подход потребовал бы передачи большой части знаний, что в случае SirsiDynix требовало больших временных затрат и, следовательно, привело бы к потере темпов разработки. Кроме того, к недостатку данной модели следует отнести тот факт, что, несмотря на наличие общих стандартов кодирования, каждая удаленная команда обладает своим стилем работы и применяет свои подходы к решению задач, что в будущем может привести к сложности поддержки продукта.

Для проекта Horizon была выработана схема, серьезно отличающаяся от классического варианта распределенного Scrum of Scrums -- каждая команда была укомплектована из разработчиков SirsiDynix и Exigen Services (StarSoft) поровну (рис. II). При такой организации передача знаний происходит постепенно, а сама модель помогает сделать разработку полностью прозрачной.

Учитывая, что отдельные Scrum-команды распределены, может показаться, что Scrum-совещания перегружены коммуникациями и средствами координации усилий между участниками, однако это происходит только на начальном этапе. Встречи на начальном этапе помогали преодолеть культурные и языковые барьеры и прийти к одинаковому пониманию задач и общему стилю работы, что в дальнейшем позволило удержать хороший темп разработки и облегчить поддержку продукта. Для достижения максимальной эффективности при синхронизации работ между командами все Scrum-мастера и владельцы продукта физически находятся рядом друг с другом в центре разработки SirsiDynix в штате Юта, США.

Выбранная модель позволила нарастить команду проекта Horizon 8.0, причем увеличение производительности команды оказалось линейным: в очень короткий для данного проекта срок (три недели) увеличение команды вдвое увеличило суммарную производительность всей команды в два раза.

Методология Scrum использовалась при разработке графического онлайнового редактора MediaFACEonline для американской компании Neato -- лидера в области производства упаковки и наклеек для различных типов электронных носителей. С помощью этого редактора пользователи сайта www.mediaface.com имеют возможность создавать уникальные наклейки для компакт-дисков. Кроме того, программа позволяет делать свой собственный дизайн вкладышей в футляры для различных видов носителей.

Многофункциональный графический редактор поддерживает технологии Direct-to-CD printing и LightScribe, позволяющие непосредственно в браузере разрабатывать дизайн наклеек на медианосители, распечатывать их с помощью домашнего струйного принтера на специальной самоклеющейся бумаге или наносить созданные с помощью этой программы картинки непосредственно на компакт-диски (если устройство поддерживает технологию LightScribe).

Технологическая основа проекта: Adobe Flash, .Net и С++. Мощная программа-дизайнер с интуитивно понятным интерфейсом и большим набором графических инструментов совместима со всеми популярными браузерами, а специализированные модули расширяют возможности дизайна путем взаимодействия с ресурсами, физически расположенными на компьютере пользователя: файловыми каталогами, плейлистами плейеров Windows Media Player и iTunes, названиями песен на компакт-диске, вставленном в привод.

Инструментарий для Scrum

Сегодня имеется множество инструментальных средств, используемых при разработке проектов по методологии Scrum: RallyDev, JIRA, AgileTrack, TargetProcess и др. Практически все они имеют богатую функциональность, хотя и не обеспечивают поддержки всех ролей в разработке. Инструменты различаются реализациями: Internet-приложение, клиент-сервер. Инструмент для каждого проекта нужно выбирать индивидуально, уделяя внимание деталям, специфичным для определенного проекта.

В нескольких проектах Exigen Services StarSoft, выполняемых по методологии Scrum, применяется инструмент RallyDev. Он прост в использовании, но требует постоянного доступа к Internet -- все данные о проекте хранятся на сервере компании RallyDev. У инструмента есть интерфейс планирования и трекинга времени разработчиков, однако с точки зрения тестирования RallyDev имеет некоторые недостатки: неудобный ввод и представление описания тестов, отсутствует функция планирования проектных ресурсов, ограниченные возможности предоставления отчетности. Внешний программный интерфейс этого инструмента реализован в виде Web-сервиса, который может быть использован для адаптации функциональности под конкретные прикладные требования, например, для построения специализированных отчетов, импорта или экспорта данных из другой системы.

В качестве инструмента в Exigen Services StarSoft применяется также собственная программа X-Man (Extreme Manager), которая бесплатно распространяется через сайт www.offshoreagile.com. Данная программа предназначена для управления agile-проектами и поддержки командной работы. Имеется экспорт данных в Microsoft Excel.

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

7. Практическая часть работы

Проектирование ИС библиотеки ВУЗа

Контекстная диаграмма представляет собой общее описание системы и ее взаимодействия с внешней средой (Рис.1)

Рис. 1

Основные информационные потоки:

- Входящие потоки:

Данные о читателях (паспортные данные читателей);

Данные о книгах (название, издательство, год издания и др.).

- Управляющие потоки:

Законодательство РФ (законы, ГОСТ, правила);

Методика формирования статистики посещения библиотеки читателями;

Методика подсчета рейтинга книг.

- Ресурсные потоки:

База данных библиотеки (БД «Библиотека ВУЗа»);

Библиотекарь.

- Выходящие потоки:

Статистика посещения клиентами библиотеки (график);

Рейтинг книг (график).

Созданная модель описывает деятельность библиотеки.

Объектом моделирования является библиотека.

Диаграммы декомпозиции

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

Рис. 2 Диаграммы декомпозиции «Библиотека ВУЗа»

Управление личными карточками читателей контролируется законами и приказами РФ. На основании документов идентифицирующих читателей в базе данных в специальные формы для ввода вносятся данные (ФИО, Телефон, Адрес, № читательского билета и др.) Добавление, редактирование данных и удаление пациента из БД осуществляется библиотекарем, что, соответственно отражается в БД в виде записей (какому читателю, когда и насколько была выдана книга).

Управление карточками книг контролируется законами РФ и методическими рекомендациями по управлению карточками книг. В базе данных в специальные формы для ввода вносятся данные о поступивших книгах: (Название книги, уникальный шифр, библиотечно-библиографическая классификация, раздел, автор, издательство, место издания (город), (год издания).

Выдача/прием книг. Регулируется также нормативно-правовыми актами о деятельности библиотеки. При выдаче книг в базе данных необходимо фиксировать: (название книги, дату выдачи, ФИО читателя, которому выдается книга, ФИО сотрудника библиотеки, выдающему книгу читателю, ФИО сотрудника хранилища, который передал книгу (непосредственно из хранилища) сотруднику библиотеки по заявке читателя, срок, на который выдается книга)

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

Получение рейтинга книг, рейтинг - понятие, характеризующее соотносительные значимость, место, вес, позицию данного объекта (книги) по сравнению с другими объектами этого класса (типа). В данном случае составляется и формируется в виде графика (например, 20 самых популярных книг) для обеспечения администрации библиотеки информации о наиболее читаемых книгах. Основные статистические показатели: (учет читателей, учет выдачи книг). Получение статистики посещений. Методика формирования статистики посещения библиотеки читателями. Регулируется ГОСТ 7.20-2000 «Библиотечная статистика».

Рис. 3 Детализированная диаграмма работы «Выдача и прием книг»

Рис. 4 Детализированная диаграмма работы «Получение рейтинга книг»

Рис. 5 Иерархия диаграмм

Заключение

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

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

Список использованных источников

1. Федеральный закон о библиотечном деле №78-ФЗ от 29 декабря 1994.

2. Федеральный закон «Об информации, информатизации и защите информации» от 25 января 2005.

Размещено на Allbest.ru