Разработка программного обеспечения

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

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

1.1 Модели жизненного цикла программного обеспечения

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

Стандарт ISO/IEC 12207 не предлагает конкретную модель жизненного цикла и методы разработки ПО. Под моделью жизненного цикла понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики информационной системы и специфики условий, в которых последняя создается и функционирует. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов жизненного цикла ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

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

1) каскадная модель (70-85 гг.);

2) спиральная модель (86-90 гг.).

Также существуют V-образная модель, инкрементная и итеративная.

Каскадная модель

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

Каскадная модель жизненного цикла ПО изображена на рисунке 1.1.

Рис. 1.1. Каскадная схема разработки программного обеспечения

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

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

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

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

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

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



Рис. 1.2. Реальный процесс разработки программного обеспечения по каскадной схеме

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

V-образная модель

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



Рис. 1.3. V-образный жизненный цикл

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

Инкрементная модель

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

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

Спиральная модель

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

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

Рис. 1.4. Спиральная модель жизненного цикла ПО

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

Итеративная модель

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

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

Рис. 1.5. Итеративная модель

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

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

1.2 Описание системы мониторинга задач и отслеживания ошибок

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

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

1) сообщившего о проблеме;

2) дату и время, когда была обнаружена проблема;

3) серьёзность(критичность) проблемы;

4) описание неправильного поведения программы;

5) кто занимается устранением (разрешением) проблемы;

6) состояние проблемы.

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

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

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

Таким образом, программной ошибкой может быть:

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

2) несоответствие между работой программы и общепринятыми стандартами;

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

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

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

Обычно используется следующий план описания:

1) Название теста (кратко отражающее его суть).

2) Шаги воспроизведения (описание действий, производимых тестеровщиком при проведении теста) с последующей нумерацией каждого шага.

3) Ожидаемые результаты (что вы ждете от программы при проведении ваших действий).

4) Полученные результаты (что получилось на самом деле).

5) Отметка о прохождении и дата проведения теста.

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

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

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

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

1.3 Описание задач и программных ошибок

Для описания задач и программных ошибок предлагается учитывать следующее:

Регистрационная информация:

1) Название проекта.

2) Описание (краткое описание задачи или дефекта, касающееся его сути). Желательно, чтобы описание было коротким (несколько слов), уникальным, отражающим суть.

3) Идентификационный номер (уникальный для каждого дефекта или задачи).

4) Приоритет (позволяющий разработчику оценить очередность исправления данной ошибки).

5) Классификационную принадлежность.

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

7) Имя и дату сообщившего об ошибке, давшего задание.

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

Рапорт - подразумевает подробное сообщение о том, в чем именно заключается программная ошибка.

Шаги воспроизведения - подробное пошаговое описание действий тестера, которые приводят к появлению описываемой ошибки.

Обходной путь - описание пути обхода ошибки, если таковой имеется.

Конфигурация - описание аппаратной и программной конфигурации, а также конфигурационных установок в самом тестируемом программном продукте.

1.4 Классификация задач и программных ошибок

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

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

1) ошибки пользовательского интерфейса;

2) ошибки функциональности;

3) ошибки логики программирования;

4) ошибки инсталляции;

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

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

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

1) Рушащие дефекты - название говорит само за себя. Под ним объединяют все те ошибки в программе, которые могут вызвать крах или зависание всей системы, нарушить стабильность ее работы, требуют немедленного исправления.

2) Косметический - под этим понятием объединяют ошибки дизайна (например, не тот цвет линии или шрифт, грамматические и орфографические ошибки), пользовательского интерфейса и т.п. Иными словами все те баги, которые не мешают работать программе, но портят ее «товарный вид».

3) Критический - все то, что ведет к зависанию или краху самой программы, не затрагивая операционной системы в целом.

4) Дефекты в обработке ошибок.

5) Ошибки в функциональности программы.

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

7) Малый - теоретически малозначимые, либо дефекты не уточненного генеза. Чаще является следствием отсутствия полноценного документооборота.

8) Предложение - предложение по улучшению качества, но к ним лучше всего относить новые свойства.

Также программные ошибки как и задачи классифицируются по приоритету:

1) Нормальный - приоритет данного дефекта (или нового свойства) является нормальным (срочность исправления оценивается самим разработчиком). Исправляется в порядке основной очереди. Нечто среднее между низким и высоким.

2) Низкий - приоритет низкий, не требует срочного выполнения, возможно «откладывание» исправления на определенный срок. Нечто среднее между очень низким и нормальным.

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

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

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

1.5 Состояния задач и программных ошибок

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

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

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

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

В случае, если ошибка не является «ошибкой» (тестеровщик ошибся), то дефект превращается в «решенный-неверный» и переправляется тестеровщику обратно.

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

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



Рис. 1.5. Жизненный цикл заданий и программных ошибок

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

Если ошибка в состоянии «решенный-неверный», то тестеровщик обязан еще раз убедиться, ошибка была или нет. Другими словами перетестировать.

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

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

«Проверенное» задание или ошибка исправлена и перетестирована на тестовой машине.

«Закрытая» - ошибка исправлена, перетестирована и исправленный код помещен на живую систему, или новая сборка выпущена.

Также существуют и такие формулировки статусов программных ошибок и задач:

1) «Добавлено» - этот статус имеют те новые запросы, которые были внесены разработчиком по просьбе бета-тестера. Предшествующий статус: «новый», «в процессе», «отложено», «поручено», «переделать», «поиск условий», «обновлен».

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

3) «Не возможно воспроизвести» - статус дефекта, который воспроизводится у бета-тестера, но не воспроизводится у разработчика (или наоборот) по ряду причин. Предшествующий статус: «новый», «обновленный».

4) «Отложено» - исправление ошибки ил выполнение задания отложено до выхода новой версии, апдейта, или на определенный / неопределенный срок. Предшествующий статус: любой.

5) «Поручено» - исправление поручено конкретному лицу (разработчику). Предшествующий статус: любой.

6) «Исправлено» - дефект исправлен. Предшествующий статус: «новый», «в процессе», «отложено», «поручено», «переделать», «поиск условий», «обновлен».

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

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

9) «Более не относящийся к делу» - ошибка, которая более не нуждается в исправлении. Предшествующий статус: любой.

10) «Переделать» - ошибка, который был объявлен как «исправлено», оказавшаяся при проверке не исправленной в следствие тех или иных причин. Предшествующий статус: «добавлено», «исправлено».

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

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

13) «Проверено» или «закрыто» - статус тех ошибок, которые были исправлены разработчиком и перепроверены бета-тестером. Предшествующий статус: «добавлено», «исправлено».

14) «Не может быть исправлен» - дефект, который по различным причинам не может быть исправлен ответственным разработчиком. Предшествующий статус: «новый», «в процессе», «обновлено», «поиск условий».

15) «Не ошибка» - то, что описано как дефект на самом деле им не является. Как правило, это касается тех черт программы, которые не были описаны в документации как ее черты и / или были восприняты бета-тестером как ошибки.

1.6 Существующие системы сопровождения разработки программного обеспечения

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

Bugzilla - свободная система отслеживания ошибок (багтрекинга) с веб-интерфейсом.

В 1998 году Bugzilla была выпущена как открытое программное обеспечение компанией Netscape. В настоящее время система разрабатывается «The Mozilla Organization».

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

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

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

Для работы Bugzilla требуются:

1) веб-сервер (например, Apache);

2) поддержка языка Perl;

3) база данных MySQL.

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

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

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

Для работы программы требуется:

1) веб-сервер (например, Apache, IIS и др.);

2) поддержка языка PHP;

3) база данных (например, MySQL).

Преимущества системы:

1) бесплатная;

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

3) весь код на PHP - можно исправлять;

4) удобно написанный код - удобно править;

5) удобная цветовая индикация по статусу ошибки;

6) есть настраиваемые пользователем поля;

7) удобные фильтры.

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

Atlassian JIRA - система отслеживания ошибок, предназначенная для организации общения с пользователями, хотя в некоторых случаях систему можно использовать для управления проектами. Разработана компанией Atlassian Software Systems. Платная. Имеет веб-интерфейс. Название системы (JIRA) было получено путем модификации названия конкурирующего продукта - Bugzilla. JIRA создавалась в качестве замены Bugzilla и во-многом повторяет архитектуру Bugzilla. Система позволяет работать с несколькими проектами. Для каждого из проектов создаёт и ведёт схемы безопасности и схемы оповещения.

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

TrackStudio - это мощная и гибкая система управления задачами для разработчиков программного обеспечения и IT-отделов компаний.

В отличие от Atlassian JIRA, ориентированной на работу с внешними клиентами, TrackStudio создана для организации работы внутри компании (например, для обработки обращений клиентов). Ее клиентами являются сотни организаций из 33 стран мира: производители ПО и электронного оборудования, телекомы, IT-отделы банков и страховых компаний, исследовательские институты и государственные структуры.

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

Ниже описаны возможности TrackStudio.

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

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

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

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

Фильтры поддерживают поиск задач по параметрам, содержанию и хронологической информации. Есть полнотекстовый поиск и поиск похожих задач. Система содержит встроенный генератор отчетов (включая статистические и исторические отчеты). Есть экспорт данных в MS Project.

Система поддерживает оповещение пользователей по e-mail, а также создание задач и сообщений через e-mail.

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

Недостатки:

1) отсутствие интеграции с другими средствами разработки;

2) перегруженность интерфейса.

2. Характеристика предприятия ИП «ЭПАМ Системз»

2.1 Общая характеристика предприятия

EPAM Systems является крупнейшей компанией, представляющей отечественную программную индустрию на мировом рынке.

Головной офис EPAM Systems расположен в США, подразделения - в Великобритании, Центральной Европе и СНГ; разработки компании внедряются более чем в 30 странах мира.

Созданная в 1993 году, сегодня компания имеет 17 представительств в 8 странах мира, в штате более 4500 высококвалифицированных специалистов, и компания продолжает стабильно расти.

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

- разработка по заказам крупнейших производителей ПО программного обеспечения для систем корпоративного планирования (ERP), управления жизненным циклом изделий (PLM); корпоративных информационных порталов (EIP), систем управления отношениями с клиентами (CRM), серверов интеграции приложений (EAI), систем управления контентом (CMS), систем управления знаниями (KMS);

- разработка приложений, соответствующих требованиям новейших сервис-ориентированных архитектур (SOA - service oriented architecture);

- создание и развертывание электронных систем управления закупками и сбытом;

- построение порталов крупных предприятий и холдингов с развитыми средствами анализа данных и управления знаниями;

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

- внедрение ERP, PLM, CRM, SCM решений и систем аналитики, стратегического планирования и бюджетирования в ряде отраслей;

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

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

Рисунок 2.1 - Основные виды услуг

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

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

Сотрудничество с ведущими фирмами-разработчиками программного обеспечения, консалтинговыми компаниями и исследовательскими институтами помогает EPAM Systems поставлять своим клиентам решения мирового уровня.

EPAM Systems занимается разработками для многих компаний, производителей программного обеспечения. Учитывая риск и сложность вопросов, связанных с интеллектуальной собственностью компании-разработчика ПО, EPAM обеспечивает полную надёжность инфраструктуры и соответствие строгим техническим и квалификационным стандартам, чтобы работать с такими компаниями, как, Knova, Microsoft, SAP Labs, и SAP AG.

Компания EPAM Systems объединяет более 4500 высококвалифицированных ИТ-профессионалов: программистов, руководителей проектов и бизнес-аналитиков, специалистов по обеспечению качества программных продуктов, архитекторов программного обеспечения, переводчиков и дизайнеров.

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

Организационная структура управления персоналом на предприятии EPAM Systems в Республике Беларусь представлена на рисунке 2.2.



Рисунок 2.2 - Организационная структура управления EPAM Systems

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

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

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

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

Таблица 2.1 - Основные технико-экономические показатели деятельности предприятия за 2006-2008 гг. (млн. руб.)

Показатели	Суммы по годам	Изменение, %
	2006	2007	2008	2007/ 2006 г.	2008/ 2007 г.
1	2	3	4	5	6
Выручка от реализации товаров, продукции, работ, услуг (без налогов)	155290	192337	243233	123,86	126,46
Себестоимость реализованных товаров, продукции, работ, услуг	117564	140386	169171	119,41	120,50
Валовая прибыль	37726	51951	74062	137,71	142,56
Управленческие расходы	5678	4330,1	8427	76,26	194,61
Расходы на реализацию	155,3	153,7	270,3	98,97	175,86
Прибыль от реализации товаров, продукции, работ, услуг	31 893	47467	65365	148,83	137,71
Прибыль (убыток) от операционных доходов и расходов	456,4	508,8	1701,3	111,48	334,38
Прибыль (убыток) от внереализационных доходов и расходов	-5674	-11443	-16992	201,67	148,49
Прибыль (Убыток)	26 675	36533	50074	136,96	137,07
Чистая прибыль	19 224	21661	30597	112,68	141,25

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

В 2008 году выручка от реализации продукции в оптовых ценах (без учета налогов и отчислений) составила 243233 млн. руб., что на 26,5% превышает аналогичный показатель в 2007 году. В течение анализируемого периода наблюдается увеличение чистой прибыли на 41,25% до значения 30597 млн. руб.

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

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

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

В январе 2007 г. EPAM Systems второй год подряд была признана компанией №1 в категории «Пять ведущих аутсорсинг-компаний в Центральной и Восточной Европе» рейтинга «Global Services 100». Деятельность компании также регулярно получает высокие оценки и в других мировых рейтингах и конкурсах.

2.2 Анализ организации работы над проектами в компании «ЭПАМ Системз»

программный мониторинг ошибка

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

Реалии последних лет показали, что для систем, требования к которым изменяются достаточно часто, необходимо еще больше уменьшить длительность витка спирального жизненного цикла. В связи с этим сейчас стали весьма популярными быстрые жизненные циклы разработки, такие как жизненный цикл в методологии eXtreme Programming (XP).

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

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

Сравнение различных типов жизненного цикла разработки программных продуктов показано в таблице 2.2.

Таблица 2.2. Сравнение различных типов жизненного цикла

Тип жизненного цикла	Длина цикла	Верификация и внесение изменений	Интеграция отдельных компонент системы
Каскадный	Все этапы разработки системы. Длинный	В конце разработки всей системы. Изменения вносятся редко	Четко определенные до начала кодирования интерфейсы
V-образный	Все этапы разработки системы. Длинный	В конце полной разработки каждого из этапов системы. Изменения вносятся со средней частотой	Редко изменяемые интерфейсы
Спиральный	Разработка одной версии системы. Средний	В конце разработки каждого из этапов версии системы. Изменения вносятся со средней частотой	Периодически изменяемые интерфейсы, редко меняемые в пределах версии

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

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

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

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

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

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

Выбранные истории являются основой для планов итераций.

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

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

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

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

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

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

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

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

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

Таким образом, процесс разработки программного продукта происходит по следующей схеме.

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

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

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

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