Разработка программного обеспечения – это групповой процесс. Большинство программных продуктов рождается в результате коллективных усилий. Люди являются одной из главных составляющих, необходимых для производства программного продукта. При организации работы программистов важно учитывать не только их технические навыки, но и взаимодействие между ними.
Существует две основные модели организации коллектива при разработке ПО:
– Иерархическая модель. определяет начальников и подчиненных, т.е – это структура с вертикальной формой управления (контроля) элементами, входящими в неё. Фактически это пирамида, каждым уровнем которой управляет более высокий уровень. Можно выделить следующие недостатки иерархической модели:
§ нехватка информации на различных уровнях;
§ невозможность учесть все особенности проекта;
§ отсутствие полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении – вверх по иерархии, к главному менеджеру;
§ трудность освоения новых технологий, необходимых при создании кроссплатформенных приложений;
§ сложность расстановки приоритетов.
– Модель проектной группы. В проектной группе предусматривается распределение обязанностей руководителя между членами коллектива. При этом за проект отвечает не один человек, а все члены группы - каждый за свой участок.
Можно выделить следующие недостатки модели группы:
§ разрозненная связь с внешними источниками информации;
§ несогласованное представление о разных сторонах проекта;
§ несогласованность личных планов членов группы;
§ отсутствие опыта, снижающее эффективность коллективной работы.
При разработке программного обеспечения выполняемые задачи распределяются по семи ролевым группам и шести ролям. Участники команды, выполняющие конкретную роль, должны рассматривать проект с точки зрения своей специализации и обладать необходимой квалификацией.
Рисунок 1 – Роли в модели проектной группы
Каждая ролевая группа выполняет свои задачи:
«Архитектура»
§ формулирует спецификацию решения и разрабатывает его архитектуру;
§ определяет структуру развертывания (внедрения) решения.
«Разработка»
§ определяет детали физического дизайна;
§ оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна;
§ разрабатывает или контролирует разработку элементов;
§ подготавливает продукт к внедрению;
§ консультирует команду по технологическим вопросам.
«Тестирование»
§ обеспечивает обнаружение всех дефектов;
§ разрабатывает стратегию и планы тестирования;
§ осуществляет тестирование.
«Управление выпуском»
§ представляет интересы отделов поставки и обслуживания продукта;
§ организует снабжение проектной группы;
§ организует внедрение продукта;
§ вырабатывает компромиссы в управляемости и удобстве сопровождения продукта;
§ организует сопровождение и инфраструктуру поставки.
«Удовлетворение потребителя»
§ представляет интересы потребителя в команде;
§ организует работу с требованиями пользователя;
§ определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта;
§ определяет требования к системе помощи и её содержание;
§ разрабатывает учебные материалы и осуществляет обучение пользователей.
«Управление продуктом»
§ выступает в роли представителя заказчика;
§ организует работу с требованиями заказчика;
§ формирует ожидания заказчика;
§ формирует общее видение и рамки проекта;
§ определяет компромиссы между параметрами "возможности продукта / время / ресурсы";
§ организует маркетинг;
§ разрабатывает, поддерживает и исполняет план коммуникаций.
Влияние на успех группы такого важного фактора, как состав команды, выявили М. Белбин и его коллеги. Было проведено исследование нескольких сотен небольших групп в процессе их деятельности. Учёные определили, что поведение членов групп соответствует одной из девяти выделенных ими в ходе исследования ролей (Таблица 1).
Таблица 1 – Типология командных ролей М. Белбина
| Виды командных ролей | Необходимые личностные качества и вклад в деятельность команды | Допустимые недостатки |
| Мыслитель (генератор идей) | Творческая направленность, богатое воображение, неординарность мышления. Стремление к новаторству. Источник оригинальных идей для команды. | Недостаточность опыта межличностного общения. Психологическая неустойчивость. Может долго задерживаться на рассмотрении "интересных идей". |
| Исполнитель | Претворяет идеи в практические действия. Превращает решения в легко выполнимые задания. Вносит упорядоченность в деятельность команды. | Недостаточная гибкость. Неприязнь к фантастическим идеям. Неприязнь к частым изменениям планов. |
| Доводчик | Усердие и добросовестность. Следит за тем, чтобы задания выполнялись полностью. Отслеживает своевременность выполнения заданий. | Чрезмерная обеспокоенность состоянием дел. Склонность к внутренним переживаниям. Нежелание перепоручать свои обязанности. Неприятие несерьезного отношения к его обязанностям со стороны других. |
| Оценщик (эксперт) | Исповедует беспристрастный критический анализ ситуации. Стратегический подход и проницательность в оценках. Точность суждений, стремление рассматривать все возможные варианты решения. | Недооценка факторов стимулирования и воодушевления. Недостаточность вдохновения и творческого воображения. Способность сбивать других, подавляя их инициативу. |
| Исследователь ресурсов | Владение искусством проведения переговоров, разнообразие контактов. Талант импровизатора, изучает благоприятные возможности. Энтузиазм, коммуникабельность. | Теряет интерес по мере угасания энтузиазма. Перескакивает от одной задачи к другой. Нуждается в повышенном внешнем давлении. |
| Формирователь | Постоянная ориентированность на решение поставленной задачи; стимулирует работу всей команды. Способствует реализации принятых решений; побуждает сотрудников работать интенсивнее. Энергичность, стремление к превосходству и работе с полной отдачей сил. | Легко переходит к состоянию раздражительности. Импульсивность и нетерпеливость. Нетерпимость к нечетким формулировкам и нерешительности в поведении. Результат - любой ценой. |
| Коллективист | Способствует гармонизации отношений в команде и устранению разногласий. Внимательно выслушивает собеседника; опирается на мнения других. Чуткость, отсутствие чрезмерной самоуверенности. | Нерешительность в кризисных ситуациях. Стремление избегать обострения ситуаций. Может воспрепятствовать совершению действий в решающий момент. |
| Председатель (координатор) | Четко формулирует цели; хорошо выполняет функции ведущего во время дискуссий. Способствует эффективному принятию решений. Имеет хорошие коммуникативные навыки; социальный лидер. | Может производить впечатление человека, склонного к манипуляциям. Склонность к переложению своих обязанностей на других. Может приписывать себе заслуги всей команды. |
| Специалист | Обладает редко встречающимися навыками и знаниями. Целеустремленность и способность концентрировать усилия. Инициативность и способность всецело отдаваться работе. | Полезен только в узкой профессиональной сфере. Зачастую слабые коммуникативные навыки. Иногда, образно выражаясь, "не видит леса за деревьями". |
В равной степени важными для эффективной командной работы их можно считать лишь при условии, что они применяются в надлежащее время и наилучшим образом. Например, в тот период, когда команда только приступает к рассмотрению проблемы или к разработке проекта, обычно требуются инновационные идеи (т.е. нужен «мыслитель»). Затем возникает необходимость оценки того, как эти идеи могут быть претворены в практически выполнимые задачи (т.е. нужен «исполнитель»). Успех достигается при условии, что в команде есть хороший координатор («председатель»), задача которого - обеспечить наибольшую отдачу от членов команды в нужное время. Движущую силу и стимул команда обретает в лице энергичного «формирователя». Когда возникает необходимость в проведении сложных переговоров с другими группами, большое значение приобретают качества, которыми обладает «исследователь ресурсов». Чтобы сдерживать чрезмерные проявления энтузиазма, отвлекающие от главной цели, в составе команды должен быть «оценщик» (т.е. «эксперт»). Всевозможные трения и недоразумения между членами команды устраняются усилиями «коллективиста». Благодаря наличию «специалиста» команда имеет редко встречающиеся навыки и знания, в которых периодически возникает необходимость. Роль «доводчика» состоит в том, чтобы не упустить из виду даже мельчайшие детали реализации всех намеченных планов.
Однако для успешной разработки программного обеспечения недостаточно просто распределить среди участников проектной команды роли и обязанности. Необходимо, чтобы все участники команды понимали и соблюдали следующие базовые принципы коллективной работы:
– Единое понимание целей проекта. Данное условие является важнейшим фактором успеха как при разработке ПО, так и при любой совместной деятельности. На начальных этапах работы каждый участник команды имеет собственное мнение и представление о продукте. Необходимо обсудить частные мнения и по итогам обсуждения выработать концепцию проекта – единый документ, который содержит:
§ описание возможностей продукта (что продукт позволяет сделать);
§ конкретизацию продукта (описание функциональных возможностей данной версии);
§ описание путей реализации проекта.
– Равенство, свободный обмен информацией, общая ответственность и четкие ролевые функции. В группе разработчиков важна каждая роль. Только такой подход позволяет наладить свободный обмен информацией между проектными группами и отдельными разработчиками и сформировать общую ответственность за качество продукта проекта.
– Ориентация на продукт и понимание целей заказчика, нацеленность на результат.
– Постоянное коллективное обучение. Обучение людей является одной из важнейших составляющих успеха проекта и всей компании. Постоянное коллективное обучение позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. На разных этапах реализации проекта применяются следующие виды обучения:
§ обучение на опыте других проектов;
§ изучение методологии;
§ изучение технологий.
– Эффективное взаимодействие с внешними группами. Проектная группа должна эффективно взаимодействовать с внешними группами – с заказчиком, пользователями, другими разработчиками. За эффективность внешних взаимодействий отвечают менеджер проекта, менеджер продукта, специалист по внедрению и логистик. В их обязанности входят как внутренние, так и внешние контакты.
Можно выделить следующие этапы развития команды:
1. Первый этап – формирование (или шумиха) – характеризуется избытком энтузиазма. Люди должны преодолеть внутренние противоречия, переболеть конфликтами прежде, чем сформируется действительно спаянный коллектив. На этом этапе многое зависит от лидера: он должен четко поставить цели членам команды, верно определить их роли в проекте.
2. Второй этап – бурление (или неразбериха) – самый сложный и опасный период. Мотивация новизны уже исчезла, а сильные и глубокие стимулы у команды еще не появились. Неизбежные сложности или неудачи порождают конфликты, «поиск виновных». На этом этапе важно обеспечить открытую коммуникацию в команде – конфликты не следует прятать или разрубать. Споры необходимо разруливать – спокойно, терпеливо и тщательно.
3. Третий этап – становление. В команде растет доверие, люди начинают замечать в коллегах не только проблемные, но и сильные стороны. На смену битве амбиций приходит продуктивное сотрудничество. Четче становится разделение труда, исчезает дублирование функций. Лидер перестает находиться в состоянии постоянного аврала, работа по построению команды на этом этапе – уже не тушение пожара, а скрупулезный труд по отработке общих норм и правил.
4. Четвертый этап – отдача. Наконец-то можно получить дивиденды за потраченные усилия. Команда работает эффективно, высок командный дух, люди хорошо знают друг друга и умеют использовать сильные стороны коллег. Высок уровень доверия. Это лучший период для раскрытия индивидуальных талантов. Люди хотят и могут совершенствоваться, они более всего заинтересованы в профессиональном росте. Растет значение нематериальной мотивации сотрудников, а оценивать и поощрять материально лучше команду в целом. Если четвертый этап достигнут, значит, команда создавалась не зря.
Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:
– групповая работа над кодом, документами;
– учет проблем, ошибок, требований;
– документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;
– организация правильного тестирования.
Работа средств коллективной разработки основана на выполнении двух базовых функций:
– Ведение общей для всех разработчиков базы данных проекта, содержащей историю изменений в каждом файле проекта.
– Автоматизация следующих операций:
§ доступа к общей базе данных;
§ обработки конфликтующих версий файла;
§ именования различных версий файла;
§ ввода и сохранения комментариев к изменениям.
Формирование рабочих коллективов и выбор программного проекта вещи взаимосвязанные. В данном курсе даётся возможность студентам сначала «собрать команду», а потом выбрать проект. Группы, работающие над проектом должны состоять из 3-5 человек. Группы менее 3 человек, не позволят студентам получить навыки коллективной работы над проектом. Группы более 5 человек требуют более сложной координации и допустимы для уже сложившихся творческих коллективов.
При формировании групп следует учитывать психологическую совместимость, входящих в них студентов. Задача преподавателя помочь студентам получить навыки конструктивной работы в коллективе. При формировании и утверждении групп следует избегать как существующих, так и потенциальных конфликтов внутри одной группы.
В сильные сформированные группы преподаватель может по собственному усмотрению добавить студента, не нашедшего группу самостоятельно. Студенты, не сумевшие сформировать группы, разделяются на группы преподавателем, либо вводятся в уже существующие группы.
Сформированные группы утверждаются преподавателем. Если преподаватель считает, что с точки зрения освоения практических навыков, предусмотренных программой ТРПО, данная группа малоэффективна, то он вправе расформировать или переформировать такую группу. Использовать данное право следует только в исключительных случаях, предварительно проконсультировавшись с лектором.
Студенты на основе своих личных предпочтений и желаний организуют рабочие команды. Следует выбирать тех людей, с которыми приятно и интересно работать. После выбора темы проекта рекомендуется распределить роли между участниками, договориться о способах взаимодействия, а так же определить количество часов в неделю, выделяемых на работу над проектом каждым участником. Данный момент является очень важным, поскольку одной из распространенных причин провала проекта является невыполнение рабочих обязательств одним или несколькими членами группы.
Следует определить схему и частоту проведения собраний. Встреча коллектива, совместно работающего над проектом должна проходить не реже одного раза в неделю. Собрание является точкой интеграции полученных результатов проекта и определения дальнейших действий проекта. На собрании обсуждаются и вырабатываются различные решения, касающиеся проекта. Например, распределение задач, определение приоритетов, назначение ответственных, изменение плана и т.п.
1. Руководитель проекта назначает секретаря и оглашает заранее подготовленную повестку собрания и краткий отчет о текущем состоянии проекта. (~5 минут).
2. Участники собрания вносят замечания. В результате формируется окончательная повестка собрания. (~5 минут).
3. Собрание идет согласно выработанной повестке. Заслушиваются отчеты разработчиков о проделанной работе, включая отчеты об исправлении замечаний, и выполняется анализ текущей документации и других артефактов. Обсуждаются и определяются дальнейшие направления и задачи. (~35–70 минут).
4. Подведение итогов. Распределение задач, назначение ответственных и т.п. (~10 минут).
В случае недостаточности еженедельных собраний для командной работы разработчиков, команда может использовать дополнительное время. Например, это полезно на начальных этапах проекта в случае активной работы с заказчиком
Разработчики сочетают командную работу с индивидуальной. В процессе разработки каждому из разработчиков должны поручаться конкретные задачи для решения. Зоны ответственности, роли разработчиков и другие правила, регулирующие индивидуальную работу и ее сочетание с командной, фиксируются в плане проекта. Текущее распределение задач отражается в протоколах собраний и индивидуальных журналах разработчиков.
30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. 3 Июль 2015, 11:03
30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. В нем приняли участие сотрудники ФПИ, ООО «Рексофт», ЗАО «Топ Системы», АО «Системы управления», АО «Объединенная приборостроительная корпорация», ОАО «Объединенная авиастроительная корпорация», ГК "Росатом", АО «Вертолеты России», ОАО «Объединенная ракетно-космической корпорация», ИТ кластера Сколково и других научных и производственных организаций ОПК, научные сотрудники институтов РАН, МГУ им.М.В.Ломоносова, ведущих технических ВУЗов, представители Минкомсвязи и Минпромторга России.
Участники совещания отметили, что задачами общественного совета являются научно-техническая и технико-экономическая экспертиза планируемых и выполняемых проектов коллективной разработки ПО, участие в приёмке и подготовка предложений по внедрению результатов, полученных при выполнении проектов коллективной разработки ПО, подготовка предложений в органы исполнительной власти Российской Федерации, общественные и другие организации по вопросам повышения эффективности выполнения работ в области коллективной разработки ПО, подготовка предложений в организации по стандартизации, связанных с подготовкой новых и корректировкой существующих нормативных документов в области коллективной разработки ПО. Целью деятельности общественного совета является повышение эффективности выполнения проектов, направленных на решение проблем импортозависимости и обеспечения технологического лидерства страны на основе коллективной разработки отечественного программного обеспечения.
На заседании были утверждены: положение об общественном совете по реализации проектов в области коллективной разработки ПО, план заседаний общественного совета, сформирована рабочая группа по стандартизации, а также группы потребителей и образовательных учреждений. Участники совещания одобрили технологические принципы, заложенные в основу интегрированной инженерной программной платформы. Председателем общественного совета был избран заместитель генерального директора – руководитель направления информационных исследований Фонда перспективных исследований Сергей Гарбук. Заместителем председателя был избран заместитель генерального директора АО «Объединённая приборостроительная корпорация» Андрей Чендаров.
Кроме того, участники совещания решили, что требуется регулярное доведение информации по проекту «Гербарий» до заинтересованных сторон. В ходе проработки вопросов управления НСИ следует рассмотреть возможность использования современных международных стандартов и сформировать профиль требований, предъявляемых к ИПО, а также предложить инструментарий для управления требованиями. В части квалификационного тестирования поступило предложение проанализировать возможность использования сторонних продуктов, а также включить в сценарии нагрузочное тестирование. Замечено, что при лицензировании продуктов необходимо обеспечить вариант лицензирования по АРМ, а не только по пользователям. Также отмечено, что изложенные в ходе выступлений принципы являются актуальными и могут эффективно использоваться при разработке других типов программного обеспечения. Гарантией работоспособности решений на технологической платформе «Гербарий» являются обязательные для всех без исключения разработчиков механизмы валидации и квалификационного тестирования модулей. Предложенные к реализации механизмы коммерциализации и лицензирования призваны увеличить заинтересованность разработчиков и потребителей в переходе на данную технологическую платформу. Для реализации планов по импортозамещению в области инженерного ПО разработку программных средств управления полным жизненным циклом высокотехнологической продукции целесообразно осуществлять на базе предложенных технологических решений и принципов коллективной разработки.
Коллективные разработки часто сталкиваются с проблемами разделения ресурсов - файлов и каталогов и необходимости синхронизации времени и места.
Системы разделения файлов
Для поддержки коллективной работы с файлами применяются три основных класса систем.
Системы управления версиями файлов.
Системы управления пространствами пользователей.
Системы синхронизации удаленных пространств.
Если три класса систем выпускаются одним производителем, то часто каждая последующая система в этом списке использует предыдущую систему, выступая в качестве надстройки.
О системах управления версиями файлов следует использовать не только при коллективной, но и при индивидуальной (авторской) разработке для решения задачи отслеживания изменений между различными версиями. Мы помещаем информацию об этих системах в данном разделе лишь с целью подчеркнуть их полную незаменимость при коллективных разработках.
Поскольку данные системы действительно очень важны, их реализации существуют в большом количестве практически для всех операционных систем. Приведем два стека таких систем (табл. 5.2).
Таблица 5.2. Примеры средств поддержки коллективной разработки
Система управления версиями файлов
Система управления версиями файлов предназначена для отслеживания изменений между различными версиями файлов и разделения доступа к ним. Файлы обычно содержат программы на языках программирования и тексты.
Обратим внимание на то, что системой отслеживаются именно изменения (дельты) между версиями, а не сами полные версии, что позволяет занимать небольшое количество дискового пространства. Каталог SCCS часто называют репозиторием проекта.
Как и все широко распространенные программы утилита SCCS имеет надстройки в виде графического интерфейса, например утилиту vertool.
Система управления пространствами
Система управления рабочими пространствами пользователей предназначена для обмена результатами работы между отдельными разработчиками через объединение результатов в выделенном рабочем пространстве. Система работает на основе модели "копирование-изменение-слияние" и понятия "рабочее пространство".
Рабочее пространство - специальным образом выделенная совокупность каталогов с файлами, переданными системе управления версиями файлов. Кстати, на профессиональном жаргоне разработчики называют свои рабочие пространства - песочницами.
Модель "копирование-изменение-слияние" отражает схему организации работы с пространствами. Основная последовательность действий такова:
Создается основное мастер-пространство, от которого разработчики порождают свои рабочие пространства.
После внесения изменений в своем рабочем пространстве разработчик передает их в мастер-пространство.
Все разработчики периодически обновляют свои рабочие пространства из мастер-пространства.
Основная проблема, которая может при этом возникнуть, - это конфликт изменений в том случае, когда разработчик передает измененные файлы в мастер-пространство, но они уже оказываются измененными другим разработчиком. Можно попытаться избежать такой ситуации, выполняя обновления как можно Чаще или установив регламент для внесений изменений.
Тем не менее если такая ситуация возникла, то требуется выполнить под управлением разработчика слияние файлов, в ходе которого конфликт будет разрешен. Процесс слияния в большинстве случаев требует интеллектуального подхода при принятии решений в формировании итогового файла. Автоматизировать можно лишь сам процесс формирования файла, например, используя утилиту слияния файлов filemerge.
Система синхронизации удаленных пространств
В ряде случаев может оказаться, что пространства некоторых разработчиков находятся на значительном удалении друг от друга. Очень часто пространства находятся в различных локальных сетях, каждая из которых имеет выход в Интернет. Возникают две проблемы - организация пересылки изменений и их синхронизация.
Для осуществления пересылки можно воспользоваться стандартными средствами Интернета - электронной почтой или утилитой ftp. Для облегчения синхронизации следует завести два дополнительных пространства-порта и выполнять их синхронизацию (например, при помощи семафоров). Утилиты, выполняющие пересылку, должны тщательно сверять контрольные суммы, чтобы убедиться в корректности полученной информации. Естественно, в пересылаемый пакет информации входят только инкрементальные изменения (дельты), а не измененные файлы целиком.
Системы поддержки работы виртуальных групп
Общение в виртуальных группах очень часто осуществляется через Интернет, а в качестве средств общения выступают традиционные и хорошо известные средства, такие как:
видеоконференции;
аудиоконференции;
средства группового общения в реальном времени (чаты);
средства группового общения с разным временем подключения (доски объявлений, форумы);
электронная почта (включая списки рассылки, архивы и поиск по ним). Однако все перечисленные средства имеют определенные недостатки. Например, видео- и аудиоконференции не позволяют передавать файлы, а средства группового общения в Интернете не обеспечивают секретности от доступа любых других пользователей с одной стороны и позволяют разработчикам выступать анонимно с другой стороны.
Системы поддержки работы виртуальных групп должны хранить и обрабатывать информацию, а также помогать разработчикам осуществлять общение друг с другом. Сформулируем некоторые общие требования к таким системам.
Необходимость регистрации пользователя при его входе в систему.
Сохранение всей переписки и прочих данных в архиве.
Использование системы управления версиями текстов для программ и документации.
Классификация систем поддержки работы групп по предоставляемым ими возможностям общения была предложена Бобом Йохансеном (Bob Johansen).
система упорядочивания доступа к данным для показов видеозаписей, слайдов и других документов;
система проведения мозговых штурмов и процедур принятия решений. Система дает возможность вносить идеи в список сразу после их возникновения. Как правило, такие системы обладают возможностями для быстрого голосования.
В одно и то же время, в одном и том же месте (same time, same place).. Это классический случай, когда разработчики имеют возможность встречаться в одном помещении в определенное время. Здесь оказываются полезными следующие системы поддержки:
В одно и то же время, в разных местах (same time, different place). Системы должны обеспечивать общение в реальном времени. Для этого обычно применяются средства аудио- и видеоконференций.
В разное время, в одном и том же месте (different time, same place). Это довольно редкая ситуация, когда существует комната группы, но разработчики не имеют возможности собраться в ней в одно и то же время. Разработчику должна быть предоставлена возможность доступа к репозиторию проекта и всей информации, доступной на данном этапе проекта.
В разное время, в разных местах (different time, different place). Системы реализуют возможности ведения конференций, форумов и чатов с асинхронным подключением, возможность доступа к репозиторию проекта.
Неограниченные возможности доступа к данным (anytime, anyplace). Эта категория оставлена автором классификации на дальнейшее развитие коммуникационных технологий, когда возможности доступа к данным станут практически неограниченными.
Обратим внимание на то, что часто тип систем поддержки работы виртуальных групп зависит от рода их деятельности.
Группы управления. Управляющие работники компаний, находящиеся в удаленных друг от друга подразделениях, обычно используют видеоконференции.
Группы проекта. Разработчикам требуется максимально возможное количество средств общения и доступа к репозиториям.
Группы сопровождения. Группам необходимы средства связи и быстрый доступ к данным из любого места.
Приведем несколько наиболее известных систем поддержки виртуальных групп:
Facilitate.com (компании Facilitate.com (http://www.facilitate.com/ ));
Лекция 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 немногочисленны и едины для любых разработок и систем управления версиями.
- Любые рабочие, тестовые или демонстрационные версии проекта собираются только из репозитория системы. «Персональные» сборки, включающие ещё незафиксированные изменения, могут делать только разработчики для целей промежуточного тестирования. Таким образом, гарантируется, что репозиторий содержит всё необходимое для создания рабочей версии проекта.
- Текущая версия главной ветви всегда корректна. Не допускается фиксация в главной ветви неполных или не прошедших хотя бы предварительное тестирование изменений. В любой момент сборка проекта, проведённая из текущей версии, должна быть успешной.
- Любое значимое изменение должно оформляться как отдельная ветвь. Промежуточные результаты работы разработчика фиксируются в эту ветвь. После завершения работы над изменением ветвь объединяется со стволом. Исключения допускаются только для мелких изменений, работа над которыми ведётся одним разработчиком в течение не более чем одного рабочего дня.
- Версии проекта помечаются тэгами. Выделенная и помеченная тэгом версия более никогда не изменяется.
Самые известные, которые чаще всего упоминаются - CVS, Subversion (SVN), Perforce. Все системы, что я перечислила, объединяет то, что это системы с одним, выделенным сервером, на котором и находится репозиторий с кодом. Скорее всего вы работали с какой-то из них. Если ни с какой не работали, то очень рекомендую поставить Subversion. Его легко и непринужденно можно погонять на одной локальной машине и получить полное представление о работе систем контроля версий.
Небольшой словарик для понимания дальнейшего. Переводами народ себя обычно не утруждает:-).
Транк (trunk) - основная ветка кода
Бранч (branch) - ответвления (для экспериментов, например)
Чекин (Check in (submit, commit)) - отправка кода в репозиторий
Чекаут (Check out) - получение изменения из репозитория.
Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешать
Патч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом
Список литературы
В основе разработки и дальнейшего применения программного обеспечения пользователем лежит понятие жизненного цикла, который, в сущности, является моделью его создания и использования, отражающей различные состояния, начиная с момента осознания необходимости появления данного ПО и заканчивая моментом...Ускорение разработки программного обеспечения. Методология 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). Интегрированная среда разработчика позволяет повысить производительность и эффективность работы программиста. Одной из интегрированных сред...(Программирование на языке высокого уровня. Программирование на языке С++)