Принципы и методы коллективной разработки программных продуктов. Технология коллективной разработки

В основе разработки и дальнейшего применения программного обеспечения пользователем лежит понятие жизненного цикла, который, в сущности, является моделью его создания и использования, отражающей различные состояния, начиная с момента осознания необходимости появления данного ПО и заканчивая моментом...
  • Ускорение разработки программного обеспечения. Методология RAD
    В связи с развитием CASE-технологий в рамках спиральной модели жизненного цикла ПО в последнее время широкое распространение получила методология быстрой разработки приложений RAD (Rapid Application Development). Процесс разработки при этом содержит три элемента : небольшую команду программистов...
     (Технология разработки программного обеспечения)
  • Пакеты прикладных программ
    Классификация пакетов прикладных программ (ППП) приведена на рис. 1.8. Проблемно-ориентированные ППП. Для некоторых предметных областей возможна типизация функций управления, структуры данных и алгоритмов обработки. Это вызвало разработку значительного количества ППП одинакового функционального назначения:...
     (Технология разработки программного обеспечения)
  • Пакет прикладных программ Microsoft Office
    Прикладные программы часто объединяются в пакеты по роду деятельности пользователя. Наиболее популярным пакетом, предназначенным для решения задач автоматизации офиса, является Microsoft Office. Он представляет собой семейство прикладных программных продуктов, которое объединяет различные приложения...
     (Информатика)
  • Система контроля версий Subversion
    Subversion - свободно распространяемая система управления версиями с открытым кодом. Subversion разработана специально для замены CVS, самой распространенной открытой системы управления версиями. Она обладает всеми основными функциями CVS (хотя некоторые из них выполняет другими способами) и лишена ряда...
     (Технология разработки программного обеспечения)
  • ОСНОВЫ РАБОТЫ В СРЕДЕ РАЗРАБОТКИ STUDIO 2010 ИНТЕГРИРОВАННОЙ MICROSOFT VISUAL
    В настоящее время для разработки программного обеспечения используются интегрированные среды разработчика - ИСР (англ. IDE - Integrated development environment). Интегрированная среда разработчика позволяет повысить производительность и эффективность работы программиста. Одной из интегрированных сред...
     (Программирование на языке высокого уровня. Программирование на языке С++)

    • 3. menu – меню. Реализовано в виде списка, причем каждый пункт может содержать подменю, которое тоже представляет собой список. Каждый элемент списка обязательно содержит текст (часто с горячей клавишей) и может содержать иконку 32*32, сочетание «горячих клавиш» для вызова элемента без вхождения в меню или символ 4. Сочетание icon+menu = Tool panel (Панель инструментов)

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

    Разработчик и архитектор в больших программах – разные люди.

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

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

    19. Требования к программистам. Формирование команды программистов.

    Требование к программистам и их оценка
    1. Уровень образования

    По учреждению выясняются возможности

    Тестирование знаний

    Резюме – представление опыта программистов, характеризующее его возможное применение.

    На производительность влияют:

    1. Наличие амбиций человека (собственная оценка своих качеств и себя в коллективе)
    2. Уровень притязания. Самооценка может быть источником конфликтов в коллективе.
    3. Коммуникабельность! при сдаче проекта.

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

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

    Осуществляет руководитель проекта.

    Опытный руководитель распараллеливает работы. Идет пересечение этапов.

    По каждому этапу четко сформулирован результат. Если результата нет, то этап не завершен.

    Документирование процесса работы. Все, что делается - оформляется.

    Документация создается с начала реализации проекта. Оформляется в соответствии с ГОСТом (ISO) или с корпоративными стандартами документациями.

    Удобно использовать маршрутный лист.

    Достоинства подхода:

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

    2. документация отражает текущее состояние работы над проектом

    3. при окончании проекта требуется минимум усилий для оформления документации для передачи заказчику.

    Организация персональной работы программиста

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

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

    Организация коллективной работы

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

    «Рабочая тетрадь». Все проектные решения документируются в рабочую тетрадь. Иногда размер всех рабочих тетрадей по проекту достигал толщины в 1 м.

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

    Версия 0 является версией, готовой в бета-тестированию.

    Согласование работ:

    1. Распараллеливание работ

    2. Сетевое планирование

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

    1. MS Outlook
    2. Time manager
    3. MS Project – управление ресурсами, планирование с дискретностью от часа до месяца. Позволяет работать удаленным пользователям надо удаленным проектом.

    21. Планирование работы команды программистов. Эффект второй системы.

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

    1. Шифр, номер работы
    2. Описание выполнения
    3. Время окончания
    4. Результат, если работа окончена.

    Отслеживает эту информацию менеджер группы.

    По оценкам 28-33% времени программист пишет программу. Остальное – совещания, согласования, поиск литературы, обучение, координация с программистами, пишущими совместные с его модулями – 60%.

    Задача менеджера – минимизировать 60% так, чтобы увеличить время работы программиста над программой. Если менеджер хороший, то он сможет снизить 60% до 50%.

    Критическая ситуация – проект не успевает по срокам:

    В этом случае возможны следующие шаги:

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

    Часть фирм планируют разработку системы на «выброс», чтобы получить представление о трудностях, ошибках, проверить основные идеи, а после разрабатывать вторую систему.


    22. Работа с заказчиком.

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

    1. 1 Заказчик, 1 Разработчик
    2. Заказчик объявляет тендер на разработку. Выигрывает фирма, которая либо уменьшает стоимость разработки, либо за эту же сумму предоставляет больше возможностей. Играет роль имидж компании (участие и завершение аналогичных разработок, участие в семинарах, совещаниях по теме, открытость компании).

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

    Заказчик в курсе всей работы

    Тестирование параллельно с написанием

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

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

    Вопрос в том, как построить модель отношений заказчика и разработчика с учетом интересов обеих сторон и без потери качества?

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

    Итак, сторона заказчика имеет следующие ключевые роли: менеджер продукта и бизнес-аналитик.

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

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

    Сторона разработчика : менеджер программы, аналитик, программист, тестировщик.

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

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

    Программист — непосредственно кодировщик.

    Тестировщик — специалист по тестированию, он отвечает за соответствие системы ее спецификации.

    Сторона качества : бизнес-аналитик и технолог.

    Бизнес-аналитик — специалист по предметной области вообще, независимо от конкретного предприятия.

    Технолог — специалист по технологии, контролирующий правильность ее использования.

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

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

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

    Решением этой проблемы может стать организация бригад , например бригады главного программиста ,если рассматривать на примере программистов.


    Бригададолжна включать от 3 до 7 человек. Число 10 является верхней границей численности бригады. Это обусловлено требованием максимальной управляемости коллектива.

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

    Руководитель бригады (например, главный программист) — это превосходно подготовленный, творчески мыслящий, наделенный организацион­ными способностями специалист. Он выполняет работу верхнего уровня, в том числе распределение работы внутри бригады.

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

    Непосредственно исполнители (например, младшие программисты) — два или три "менее опытных" (но не "менее способных") специалиста. Они выполняют работу нижнего уровня, определенную руководителем бригады.

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

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

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

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

    Секретарь выполняет обычную работу секретаря.

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

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

    Рис. 12.1. Группы специалистов, занятых в разработке ПО

    (n — количество функций ПО)

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

    Результатом стадии должны быть:

    Общая информационная модель системы;

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

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

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

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

    Все множество разработок в зависимости от количества участников и типов взаимоотношений между ними может быть сведено к триаде разработок, приведенной на рис. 3.21.

    Люблю одиночество, даже когда я один.
    Ж. Ренар

    Этот принцип был достаточно широко распространен в 70-80-е годы XX века. Сейчас он применяется редко.

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

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

    Объем программного продукта, выполненного методом авторской разработки, в 5-20 раз меньше по сравнению с индустриальными аналогами.

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

    2. Коллективная разработка

    Собрать стадо из баранов легко, трудно собрать стадо из кошек.
    С. П. Капица

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

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

    2.1. Технические командные роли

    Равноправные соисполнители

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

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

    Тип работы определяет содержание и природу выполняемой работы. Приведем список типов работ и областей специализации на основе классификации Конгер .

    • Разработка приложений.
      • Программист.
      • Специалист по инженерии программирования.
      • Специалист по инженерии знаний.
    • Работа с приложениями.
      • Специалист по приложениям.
      • Администратор данных.
      • Администратор базы данных.
    • Техническая поддержка.
      • Системный администратор.
      • Сетевой администратор.
      • Администратор коммуникаций,
    • Обеспечение качества продукта.
      • Технический писатель.
      • Инженер тестирования.
      • Инженер качества.
    • Маркетинг.
      • Специалист по сопровождению продукта.
      • Специалист по продажам продукта.
    • Системное интегрирование.

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

    Бригада главного программиста

    - Почему бригада скорой помощи состоит из двух врачей?
    - Один знает - куда ставить клизму, а другой - зачем!
    Анекдот о специализации в команде

    Харлан Миллз [Брукс 1999] предложил организовывать команды (бригады) главного программиста (chief programmer teams), подобные хирургическим бригадам. Лишь один участник команды занимается основной работой, остальные оказывают ему всевозможную поддержку. Бригада главного программиста включает десять человек, выполняющих специализированные роли в команде (рис. 3.22).


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

    • Главный программист. Лично выполняет анализ и проектирование, создание и отладку кода, написание документации. Должен обладать талантом, большим опытом работы и существенными знаниями.
    • Дублер. Может выполнять любую работу главного программиста, но менее опытен. Подстраховывает главного программиста, может заниматься написанием кода, но не несет ответственности за проект.
    • Администратор, он же - менеджер. Под его контролем - деньги, люди, помещения, машинные ресурсы, контакты с другими группами и руководством.
    • Редактор. Фактически, это технический писатель. Его задача - критически переработать черновики документации (созданные главным программистом), снабдить их ссылками и библиографией и обеспечить публикацию или помещение в Интернете.
    • Языковед. Эксперт в тонкостях языков программирования. Может найти эффективные способы использования языка для решения сложных задач. Обычно работает с несколькими бригадами.
    • Инструментальщик. Разработчик специализированных инструментов - утилит и скриптов. Поддерживает основной инструментарий и оказывает по нему консультации. При необходимости может осуществлять администрирование операционной системы.
    • Отладчик. Разработчик тестов и организатор тестирования программного продукта.
    • Делопроизводитель. Отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта. Благодаря делопроизводителю, активные программисты освобождались от рутинных работ. Заметим, что в настоящее время функции делопроизводителя автоматизированы и переданы репозиторию проекта.

    2.2. Психологические командные роли

    Роб Томсет (Rob Thomsett) предложил восемь ключевых ролей в проекте (рис. 3.23).


    • Председатель. Выбирает путь, по которому команда движется вперед к общим целям. Умеет обнаружить сильные и слабые стороны команды и обеспечить наибольшее применение потенциала каждого ее участника.
    • Архитектор. Он же оформитель. Придает законченную форму действиям команды. Имеет четкое представление о проблемах и их возможных решениях.
    • Генератор идей. Предлагает радикально новые идеи и стратегии, новые подходы к решению проблем, с которыми сталкивается группа. Особое внимание уделяет главным проблемам.
    • Критик. Он же скептик, оценивающий проблемы с прагматической точки зрения. Ищет недостатки, изъяны и недоделки. Компенсирует оптимизм генератора идей.
    • Исполнитель. Работник, собственно занимающийся написанием кода. Как правило, он не обладает широтой кругозора.
    • Завершающий. Поддерживает в команде настойчивость в достижении цели. Играет доминирующую роль на завершающих стадиях разработки.
    • Дипломат. Поддерживает силу духа в участниках проекта. Оказывает им помощь в трудных положениях. Пытается улучшить взаимоотношения в команде.
    • Организатор. Обнаруживает и сообщает о новых идеях, разработках и ресурсах. Имеет много друзей и связей в своей организации, с помощью которых можно выпросить или одолжить необходимые ресурсы.

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

    2.3. Типы совместной деятельности

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

    • Мандатная деятельность, обычно представленная формальными собраниями, проводимыми на регулярной основе. Обычно собрания планируются заранее, а присутствие на них обязательно. Статистика показывает, что программисты проводят около 4% своего рабочего времени на собраниях.
    • Созываемая деятельность, которая имеет место в случае решения двух или более программистов собраться вместе для решения некоторого технического вопроса. Такие собрания обычно не планируются заранее и в них участвуют только действительно заинтересованные в решении проблемы программисты. На эту деятельность уходит около 14% рабочего времени.
    • Естественная совместная деятельность имеет место, когда как минимум двое программистов работают над одной и той же задачей одновременно и обмениваются информацией о выполняемой работе. Эта деятельность занимает около 41% рабочего времени.
    • Индивидуальная деятельность имеет место, когда программист работает над задачей, которая не выполняется в то же самое время никаким другим программистом и поэтому маловероятно его взаимодействие по этому предмету с любыми другими программистами группы. Эта деятельность занимает также около 41% рабочего времени.

    3. Общинная модель разработки

    Совершенство в проекте достигается не тогда, когда нечего добавить,
    а тогда, когда нечего убрать.
    Антуан де Сент-Экзюпери

    Идеология общинной ("базарной") модели разработки сформулирована в программной статье Эрика Раймонда (Eric Raymond) "Собор и Базар". Общинная модель характеризуется тремя основными факторами.

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

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

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

    Есть системные пометки.

    Лекция 2. Групповая разработка Программного обеспеченья (ПО).

    Структурная формула всего механизма

    Строение групп Асcура

    Степень подвижности механизма

    Кинематические пары

    Обозначение на структурной схеме Соединяемые звенья Вид Тип пары Индекс пары
    Характер соприкосновения Степень подвижности

    Число одноподвижных кинематических пар p 1 =7 , число двух подвижных кинематических пар р 2 =0.

    а).Последняя группа Асcура

    б).Предпоследняя группа Асcура

    в).Начальный механизм

    7.Класс всего механизма II , так как наивысший класс группы Ассура, входящей в данный механизм II.

    • изучение инструментария коллективной разработки
    • изучение принципов организации процесса разработки и управления коллективом разработчиков

    Определения:

    Source control (revision control, source code management (SCM)) - по-русски это все обычно называют системами контроля версий. Контролировать ими можно много чего, но меня они, конечно, интересуют в плане работы с кодом. Основная идея систем контроля версий - запоминать все внесенные изменения с комментариями . Понятно кто когда что менял, зачем. Главное - можно все эти изменения откатить. Ну а кроме этого систему контроля версий можно обвешать дополнительными фишками и рюшечками.

    Репозиторий, хранилище - место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети. Существуют репозитории для хранения программ, написанных на одном языке (например, CPAN для Perl) или предназначенных для одной платформы. Многие современные операционные системы, такие как OpenSolaris, FreeBSD и большинство дистрибутивов Linux, имеют официальные репозитории, но также позволяют устанавливать пакеты из других мест. Большинство репозиториев бесплатны, однако некоторые компании предоставляют доступ к собственным репозиториям за платную подписку. Репозитории используются в системах управления версиями, в них хранятся все документы вместе с историей их изменения и другой служебной информацией. Русское сообщество Subversion рекомендует использовать вместо термина репозиторий термин хранилище, поскольку он полностью соответствует как прямому переводу слова «repository», так и его понятию. Существуют различные автоматизированные системы создания репозиториев. Один из типов репозиториев: хранилища на CD/DVD - установочные диски для пакетов того или иного ПО.



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

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

    Пример, Redmine BUGS - the Bug Genie Bugzilla eTraxis GNATS

    Базовые принципы разработки ПО в VCS

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

    1. Любые рабочие, тестовые или демонстрационные версии проекта собираются только из репозитория системы. «Персональные» сборки, включающие ещё незафиксированные изменения, могут делать только разработчики для целей промежуточного тестирования. Таким образом, гарантируется, что репозиторий содержит всё необходимое для создания рабочей версии проекта.
    2. Текущая версия главной ветви всегда корректна. Не допускается фиксация в главной ветви неполных или не прошедших хотя бы предварительное тестирование изменений. В любой момент сборка проекта, проведённая из текущей версии, должна быть успешной.
    3. Любое значимое изменение должно оформляться как отдельная ветвь. Промежуточные результаты работы разработчика фиксируются в эту ветвь. После завершения работы над изменением ветвь объединяется со стволом. Исключения допускаются только для мелких изменений, работа над которыми ведётся одним разработчиком в течение не более чем одного рабочего дня.
    4. Версии проекта помечаются тэгами. Выделенная и помеченная тэгом версия более никогда не изменяется.

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

    Небольшой словарик для понимания дальнейшего. Переводами народ себя обычно не утруждает:-).
    Транк (trunk) - основная ветка кода
    Бранч (branch) - ответвления (для экспериментов, например)
    Чекин (Check in (submit, commit)) - отправка кода в репозиторий
    Чекаут (Check out) - получение изменения из репозитория.
    Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешать
    Патч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом

    Список литературы