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

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

Модель жизненного цикла разработки программного обеспечения (ПО) является единственным видом процесса, в котором представлен порядок его осуществления. Модель жизненного цикла разработки ПО (Software Life Cycle Model, SLCM) схематически объясняет, каким образом будут выполняться действия по разработке программного продукта, посредством описания «последовательности» этих действий. Такая последовательность может быть или не быть линейной, поскольку фазы могут следовать друг за другом, повторяться или происходить одновременно. На рисунке 5 представлена простая обобщенная схема процесса.

Рисунок 5 - Обобщенная схема процесса

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

Жизненный цикл - это своего рода «карта-путеводитель» для всех участников проекта, которая помогает им понять, не выходят ли они за определенные для них границы. Для управления программным проектом возникает необходимость в некотором роде карты для планирования действий и хронологий их выполнения.

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

· Улучшение и обеспечение качества:

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

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

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

· Возможность проверки затрат на выполнение полного жизненного цикла:

- упрощает процесс создания стандартов разработки для определенного проекта и его оценка;

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

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

- в случае применения стандартизированной процедуры становятся «прозрачными» универсальные подходы к методам решения, а следовательно, их можно использовать повторно;

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

- уменьшаются затраты на подготовку персонала.

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

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

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

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

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

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

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

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

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

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

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

Цель определения организационной структуры процесса заключается в разработке и сопровождении стандартного процесса разработки ПО для данной организации.

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

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

2.1.1 Каскадная методология

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

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

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

Рисунок 7 - Классическая каскадная модель с обратной связью

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

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

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

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

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

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

Приведенная ниже характеристика представляет собой краткое описание каждой фазы каскадной модели (включая фазы интеграции):

· исследование концепции -- происходит исследование требований на системном уровне с целью определения возможности реализации концепции;

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

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

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

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

· процесс установки -- включает установку ПО, его проверку и официальную приемку заказчиком для операционной среды;

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

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

· процесс вывода из эксплуатации -- вывод существующей системы из ее активного использования либо путем прекращения ее работы, либо благодаря ее замене новой системой или модернизированной версией существующей системы;

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

Но при использовании каскадной модели для проекта, который трудно назвать подходящим для нее, проявляются следующими недостатки:

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

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

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

· она может создать ошибочное впечатление о работе над проектом. Выражение типа "35 процентов выполнено" -- не несет никакого смысла и не является показателем для руководительа проекта;

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

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

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

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

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

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

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

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

· возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;

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

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

· отсутствует возможность учесть переделку и итерации за рамками проекта.

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

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

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

2.1.2 Экстремальная методология

Отцом-идеологом экстремального программирования (XP) считают Кента Бека (Kent Beck). XP является достаточно молодой методологией, оценки которой весьма противоречивы -- от восторженных до резко негативных. Основными принципами являются:

- Простота решений (simplicity).

- Интенсивная разработка малыми группами (не больше 10 человек), активное общение в группе и между группами (communication).

- Обратная связь с клиентом (feedback), который фактически вовлечен в процесс разработки.

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

Первый фактор ускорения разработки -- итеративность: разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. XP -- это итеративный процесс разработки, который сам по себе не является революционным. Итерации как таковые предлагается делать короткими, рекомендуемая длительность -- 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории (user story). Пользовательские истории в данном случае являются начальной информацией, на основании которой создается модуль. Пользовательские истории отличаются от прецедентов (use case): пользовательская история коротка -- 1-2 абзаца, тогда как прецеденты обычно пишут достаточно подробными, с основным и альтернативными потоками -- таким образом, получается примерно страница плюс схема (наиболее распространенная формализация в настоящее время предложена в UML); истории пользователей пишутся самими пользователями (которые в XP являются частью команды) в отличие от прецедентов, которые обычно пишет системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать посредством активного включения в процесс разработки заказчика как полноправного члена команды и за счет наличия постоянного контакта с заказчиком (активное общение и непрерывная поддержка обратной связи). В данном случае extreme -- это степень привлечения заказчика к программистской кухне, что обусловлено стремлением сжать сроки разработки за счет коммуникации и обратной связи.

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

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

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

- Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Набор свойств определяется пользовательскими историями. XP-трудоемкость каждого свойства определяется самими программистами.

- Тесное взаимодействие с заказчиком (feed-back, on-site customer). Заказчик должен быть членом XP-команды (on-site customer). Он пишет пользовательские истории, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Заказчик должен быть экспертом в автоматизируемой предметной области. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).

- Метафора системы (system metaphor). Хорошая метафора системы означает простоту именования классов и переменных. В реальной жизни поиск метафоры -- крайне сложное занятие; найти хорошую метафору непросто. В любом случае команда должна иметь единые правила именования.

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

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

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

- Парное программирование (pair programming) -- одна из самых известных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте, что легче всего сделать на территории заказчика (все необходимые члены команды географически находятся в одном месте); XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.

- 40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы (overtime) -- это четкий индикатор проблемы на данном конкретном направлении разработки; к тому же заказчик не платит за сверхурочную работу в XP. Поиск причин сверхурочной работы и их скорейшее устранение -- одно из основных правил.

- Коллективное владение кодом (collective code ownership). Каждый программист в коллективе XP должен иметь доступ к коду любой части системы и вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некорректно, то именно этот программист должен исправить ошибки. В противном случае работа системы уподобится тотальному хаосу.

- Частая смена версий (small releases). Минимальная итерация -- один день, максимальная -- месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется (на основании тех же пользовательских историй). Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю плюс feedback. На основании этого определяется следующая итерация: каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.

- Непрерывная интеграция (continuous integration). Интеграция новых частей системы должна происходить как можно чаще, как минимум раз в несколько часов. Основное правило интеграции следующее: интеграцию можно производить, если все тесты проходят успешно. Если тесты не проходят, то программист должен либо внести исправления и тогда интегрировать составные части системы, либо вообще не интегрировать их. Правило это жесткое и однозначное -- если в созданной части системы имеется хотя бы одна ошибка, то интеграцию производить нельзя. Частая интеграция позволяет быстрее получить готовую систему, вместо того чтобы тратить на сборку неделю.

- Тестирование (testing). В отличие от большинства остальных методологий тестирование в XP -- одно из важнейших составляющих. Экстремальный подход заключается в том, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test -- тест данного модуля; таким образом, в XP осуществляется regression testing (возвратное тестирование, «неухудшение качества» при добавлении функциональности). Большинство ошибок исправляются на стадии кодирования. Тесты пишут сами программисты; любой программист имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (такой подход носит название test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается.

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

б) Существующие риски применения методологии

Следует выделить риски XP, способные завалить проект, если не учитывать и не предотвращать их.

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

- Постоянное участие заказчика (on-site customer). Представитель заказчика в период работы над системой находится в команде разработчиков, причем требования к квалификации этого человека или команды весьма высоки. Если заказчик не согласился предоставить персонал уровня экспертов, то проект попадает в группу наиболее высокого риска.

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

- Простая архитектура (simple design). В каждый момент времени разрабатываемая система выполняет все тесты и поддерживает все взаимосвязи, определяемые программистом, не имеет дубликатов кода и содержит минимально возможное количество классов и методов. Это правило кратко можно выразить так: «Каждую мысль формулируй один и только один раз». Данный принцип вступает в противоречие с быстротой написания кода. Без наличия высокой самодисциплины и жестких стандартов кода система немедленно попадает в группу риска.

- Частая смена версий (small releases). Систему запускают в эксплуатацию уже через несколько месяцев после начала реализации, не дожидаясь окончательного разрешения всех поставленных проблем. Периодичность выпуска новых версий может варьироваться от ежедневной до ежемесячной. Протестировать за такой срок более-менее сложный компонент невозможно; заказчик фактически выступает в роли бета-тестера. Системы, к которым предъявляется требование непрерывной надежной работы (так называемое требование 24Ѕ7), входят в группу риска.

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

- Непрерывная интеграция (continuous integration). Новый код интегрируется в существующую систему не позднее чем через несколько часов. После этого система вновь собирается в единое целое и прогоняются все тесты. Если хотя бы один из них не выполняется корректно, внесенные изменения отменяются. В данном случае не всегда понятно, кто именно будет исправлять ошибки, причем не только локальные, но и наведенные неправильным кодом. Проведение комплексных тестов на данном этапе не предполагается; кроме того, изменения сохраняются даже в том случае, когда ошибка обнаружена.

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

- 40-часовая неделя (40-hour weeks). Объем сверхурочных работ не может превышать по длительности одну рабочую неделю. Даже отдельные случаи сверхурочных работ, повторяющиеся слишком часто, служат признаком серьезных проблем, которые требуют безотлагательного решения. Как показывает практика применения экстремального программирования (несмотря на целый ряд положительных примеров, приводимых сторонниками данного метода), сверхурочная работа при таком подходе -- это правило, а не исключение, и борьба с проблемами в данном случае -- явление постоянное. Усиливается она в период замены текущей сырой версии продукта очередной -- менее сырой. Если заказчик не получает постоянных доказательств улучшения системы, значит, у вас возникли серьезные проблемы.

- Коллективное владение (collective ownership). Каждый программист имеет возможность при необходимости в любое время усовершенствовать любую часть кода в системе. Без стандарта контроля исходного кода процесс разработки приобретает абсолютно неконтролируемый характер.

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

- Тесты (tests). Программисты постоянно пишут тесты для модулей (unit tests). Собранные вместе, эти тесты должны работать корректно. Для этапов итерации заказчики пишут функциональные тесты (functional tests), от которых также требуется правильная работа. Однако на практике это не всегда достижимо. Чтобы принять верное решение, необходимо понять, во что обойдется сдача системы с заранее известным дефектом, и сравнить это с ценой задержки на его устранение. Тесты, написанные самими программистами (особенно в условиях сверхурочных работ), не являются полнофункциональными и уж тем более не учитывают особенностей многопользовательской работы. На более продвинутые тесты у разработчиков обычно не хватает времени. Решается данная проблема путем привлечения на определенный срок контакторов, что связано с большой ролью человеческого фактора: поскольку техническая документация изначально отсутствует, то информация передается посредством общения программистов. Хотя, конечно, можно построить систему разработки таким образом, что от начала до конца всем будут заниматься одни и те же люди. К сказанному необходимо добавить, что тестирование системы вовсе не исчерпывается тестами компонентов (units); не менее важны тесты взаимодействия между ними, это же относится и к тестам надежности работы. И тем не менее метод экстремального программирования не предусматривает создания тестов данного класса. Это объясняется тем, что сами подобные тесты могут представлять достаточно сложный код (особенно это касается тестов -- имитаторов реальной работы системы). В данной технологии также никак не учитывается еще один важный класс тестов -- тесты поведения системы при росте объемов обрабатываемой информации. При высокой частоте изменения версий выполнить такой тест технологически невозможно, поскольку его проведение требует стабильного и неизменного кода проекта, например в течение недели. В таком случае придется или приостанавливать разработку компонентов, или создавать на время проведения теста параллельную версию проекта, которая будет сохраняться неизменной, тогда как другая при этом будет изменяться. Затем нужно будет выполнить процесс слияния кода. Но в этом случае тест придется создавать заново, так как методы экстремального программирования просто не предусматривают разработку средств, позволяющих прогнозировать поведение системы при тех или иных изменениях. Решать данные проблемы в XP предлагается посредством все того же человеческого фактора и самодисциплины.

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

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

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

2.2 Выбор инструментальных средств

В качестве единой среды разработки, как для транслятора партий так и для регистратора была выбрана среда NetBeans IDE. NetBeans IDE -- свободная интегрированная среда разработки приложений (IDE) на языке программирования Java, Ruby, C++ и ряде других. Среда разработки NetBeans по умолчанию поддерживает разработку для платформ J2SE и J2EE. Для разработки программ в среде NetBeans и для успешной инсталляции и работы самой среды NetBeans должен быть предварительно установлен Sun JDK или J2EE SDK подходящей версии. Для поддержки разработки в среде NetBeans для мобильных платформ (J2ME) необходимо установить отдельно распространяемый (и также бесплатный) NetBeans Mobility Pack (доступен только для Linux и Windows). Проект NetBeans IDE поддерживается и спонсируется фирмой Sun Microsystems, однако разработка NetBeans ведется независимо сообществом разработчиков-энтузиастов (NetBeans Community) и компанией NetBeans Org. По качеству и возможностям последние версии NetBeans IDE не уступают лучшим коммерческим (платным) интегрированным средам разработки для языка Java, таким, как IntelliJ IDEA, поддерживая рефакторинг, профилирование, выделение синтаксических конструкций цветом, автодополнение набираемых конструкций на лету, множество предопределённых шаблонов кода и др. В версии NetBeans IDE 6.0 декларируется поддержка UML, SOA, языка программирования Ruby (включая поддержку Ruby on Rails), а также средства для создания приложений на J2ME для мобильных телефонов (Linux, Windows). NetBeans IDE поддерживает плагины, позволяя разработчикам расширять возможности среды. На идеях, технологиях и в значительной части на исходном коде NetBeans IDE базируются предлагаемые фирмой Sun коммерческие интегрированные среды разработки для Java -- Sun Java Studio Creator, Sun Java Studio Enterprise и Sun Studio (для ведения разработки на C, C++ или Фортран). Сравнительно недавно Sun стала предлагать эти среды разработки бесплатно для зарегистрировавшихся в Sun Developer Network (SDN) разработчиков, сама же регистрация на сайте бесплатна и не требует никаких предварительных условий, кроме согласия с лицензией CDDL. NetBeans IDE доступна в виде готовых дистрибутивов (прекомпилированных бинарников) для платформ Microsoft Windows, GNU/Linux, FreeBSD, Mac OS X и Solaris (как для SPARC, так и для x86 -- Intel и AMD). Для всех остальных платформ доступна возможность собрать NetBeans самостоятельно из исходных текстов.

Корпорация Sun Microsystems добавила поддержку Ruby к своей интегрированной среде разработки NetBeans и расширила платформу JRuby. Первая версия NetBeans Ruby Pack содержит подключаемый модуль для свободно распространяемой среды разработки NetBeans, поддерживающей Ruby и JRuby. Последний представляет собой Java-реализацию Ruby, которая работает с виртуальной машиной Java. Платформа NetBeans в первую очередь ориентирована на Java, но может быть расширена и до Ruby. Как правило, разработчики, которые пишут программы на этом языке, не используют интегрированные среды разработки. Однако, как подчеркнул Тор Норби, старший инженер Sun, «предложенное корпорацией решение представляет собой значительно более производительную среду, чем все, что существовало для Ruby ранее».

2.3 Содержательная постановка задачи создания СШПО

Предметная область

Специализированное шахматное программное обеспечение (СШПО) предназначено для переноса играющихся шахматных партий в электронную форму, трансляции игр для присутствующей на соревнованиях аудитории и в сети Интернет. Пользователями СШПО будет являться персонал структурного подразделения «Шахматный клуб» ГОУ ВПО «СибГИУ» и персонал МУДОД «СДЮСШОР по шахматам».

Дано:

Действующая ИС «Шахматный клуб».

Прототипы информационной системы.

Множество моделей жизненного цикла (МЖЦ) разработки программного обеспечения.

Инструментальные средства разработки ПО.

Общие требования к СШПО:

– работоспособность во всех современных операционных системах (ОС),

– непрерывность работы в ходе всего соревновательного процесса,

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

– накопление и сохранение информации по соревновательному процессу,

– экономия времени и средств на перенос партий в электронную форму,

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

– учет возможности исправления неправильного течения игрового процесса.

Ограничения:

При выборе МЖЦ ограничиться каскадной и экстремальной МЖЦ разработки программного обеспечения.

1. При выборе инструментальных средств разработки СШПО ограничиться следующими программными продуктами: NetBeans IDE 6.0, MySQLAdministrator.

2. В ходе функционирования СШПО во время соревновательного процесса должны выполняться следующие условия:

– СШПО должно функционировать без простоев в течении всего игрового дня.

– Отображаемый ход должен полностью соответствовать ходу, сделанному на электронной шахматной доске.

– Временная задержка трансляции, если она заранее не предусмотрена, не должна превышать 0,5 секунды.

– Временная задержка переноса игрового процесса в электронную форму не должна превышать 0,5 секунды.

Требуется

Реализовать СШПО с учетом всех требований и ограничений

2.4 Разработка алгоритма решения задачи

Регистратор шахматных партий (РШП) реализуется на языке Java (j2se). РШП реализует протокол обмена данных DGT шахматных электронных досок, который в свою очередь базируется на прокотоле обмена через последовательный порт RS-232. В качестве компонента для работы с последовательным портом в Java была выбрана библиотека rxtx версии 1.72. Протокол DGT приведен в приложении 6 в виде заголовочного C файла (header). Задача РШП осуществлять трансляцию партий, при этом изменения позиции партий сохраняются в базу данных, откуда эти данные получает Транслятор шахматных партий (ТШП). Формат записи, в котором записываются шахматные ходы в базу данных, следующий:

[фигура{K(король),Q(ферзь),N(конь),B(слон),R(ладья),' '(пешка)}][вертикаль исходного поля][горизонталь исходного поля]-[вертикаль поля назначения][горизонталь поля назначения].

Например:

Kg8-g7

Ng1-f3

e2-e4

Данные, получаемые РШП от электронной доски, интерпретируются согласно описанию в протоколе DGT. Например, дамп доски получается в виде 64 ASCII символов (информативная часть сообщения) - `rnbqkbnrpppppppp PPPPPPPPRNBQKBNR' преобразуется в вид:

Рисунок 8 - Результат преобразования информативной части сообщения от ЭШД

ТШП реализован на технологии Ruby on Rails. Rails -- это полноценный, многоуровневый фреймворк для построения веб-приложений, использующих базы данных, который основан на архитектуре Модель-Представление-Контроллер (Model-View-Controller, MVC). Динамичный AJAX-интерфейс, обработка запросов и выдача данных в контроллерах, предметная область, отраженная в базе данных, -- для всего этого Rails предоставляет однородную среду разработки на Ruby. Все, что необходимо для начала -- база данных и веб-сервер. Rails отлично работает со многими веб-серверами и СУБД. В качестве веб-сервера можно использовать Apache или lighttpd как с FastCGI, так и с SCGI. В качестве СУБД можно использовать MySQL, PostgreSQL, SQLite, Oracle, SQL Server, DB2 или Firebird. Использовать Rails можно на практически любой операционной системе.

Задача ТШП создавать трансляции и вещать шахматные партии. В ТШП предусмотрена система авторизации, что позволяет гибко настраивать права пользователей зарегистрированных в системе, по умолчанию существуют три профиля пользователей: Администратор (права на все), Руководитель (ему принадлежат права на создание/редактирование online трансляций, турниров, комментирование партий и т.д.) и Гость (только просмотр партий).

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

Листинг модуля вещания партий представлен в приложении 10.

2.5 Описание разработанного программного комплекса

2.5.1 Транслятор шахматных партий

В общем виде транслятор шахматных партий (ТШП) представляет собой следующие структуры:

- модели данных (models);

- представления (views);

- контроллеры (controllers);

- помощники (helpers).

Модели данных содержат объектные представления, задачи в виде классов бизнес-логики. Здесь описываются классы, к которым будут отнесены реальные данные. Бизнес-логика управляется одноименным контроллером, например, класс Cities (города) управляется одноименным контроллером cities_controller.rb. Модель может иметь одно или несколько представлений, которые отвечают за то, в каком виде будут отображаться данные. Помимо контроллеров всех классов существует главный контроллер main_controller.rb (в качестве главного может быть назначен любой контроллер). Он выполняет все функции по обслуживанию шахматного интернет-портала:

- отображение главной веб-страницы;

- возврат к предыдущей веб-странице;

- показ партий в режиме реального времени (online) и архива турнирных партий (offline);

- авторизация пользователей;

- вход в личный кабинет пользователя;

- напоминание при потере пароля или логина;

- показ трансляции;

- выгрузка шахматных партий в формате pgn (portable game notation);

- выход пользователя;

- интерфейс регистрации и т.д.

Снимки экрана (Screenshots) главной страницы rDGT-сервера, страницы авторизации пользователя, страницы просмотра текущих online трансляций и страницы просмотра шахматных партий представлены в приложении 5.

Скрипт трансляции шахматной партии реализован на языке Javascript. Обновление позиции осуществляется через асинхронные javascript-запросы к rDGT-серверу при использовании технологии Ajax без обновления всей страницы.

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

Веб-интерфейс реализован на платформе Ruby on Rails, в соответствии с идеологией изложенной в разделе 2.4 . Портал можно разделить на несколько узловых разделов:

- Раздел трансляций партий (online режим).

- Раздел просмотра партий, сохраненных на сервере (offline режим).

- Раздел редактирования данных портала, подразумевает авторизацию пользователя, которому доступны:

· добавление, удаление, изменение турниров;

· добавление, удаление, изменение игроков;

· добавление, удаление, изменение трансляций;

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

Общая структура транслятора шахматных партий, все атрибуты и методы его структурных элементов представлены в приложении 7

2.5.2 Регистратор шахматных партий

Алгоритм работы:

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

· Название последовательного порта (serial port), к которому подключены доски, с которых будет происходить трансляция шахматных партий («COM1», «COM2» и т.п. для операционной системы Windows и «/dev/ttyS0», «/dev/ttyS1» для операционной системы Linux).

· Время начала трансляции.

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

· Ассоциирует данную трансляцию с заранее заданным турниром.

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

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

2.6 Тестовые испытания и анализ результатов

Тестовые испытания проводились в помещении СП «ШК» в сроки с 5 июня по 11 июня 2008 года на Чемпионате области по шахматам среди юношей до 12 лет. Количество используемых в испытаниях ЭШД и электронных шахматных часов - 5 штук,. Трансляция соревновательного процесса осуществлялась в течение всего указанного срока с 11:00 до 15:00, что соответствует длительности игрового дня. Схема подключения ЭШД и электронных шахматных часов аналогична рисунку 3 пункта «Обзор шахматных систем-прототипов» с той лишь разницей, что трансляция шахматных партий осуществлялась не только для присутствующей аудитории, но и в сети Интернет.

Анализ результатов тестовых испытаний представлен в приложении 9.

В качестве сравнительного показателя используется общее число шахматных ходов, сделанных на всех досках в течение всего соревновательного процесса. Так как число игровых дней - 7, число учитываемых досок - 5, а среднее число ходов в шахматной партии 30, то общее число шахматных ходов равно равно 1050.

В данном технико-экономическом обосновании рассматривается специализированное шахматное программное обеспечение, разработанное для автоматизации деятельности информационной системы структурного подразделения «Шахматный клуб» в рамках внедрения комплексной информационной системы структурного подразделения «Шахматный клуб» ГОУ ВПО «Сибирский государственный индустриальный университет».

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

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

Страницы: 1, 2