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

Системы разделения файлов

Для поддержки коллективной работы с файлами применяются три основных класса систем.

Системы управления версиями файлов.

Системы управления пространствами пользователей.

Системы синхронизации удаленных пространств.

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

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

Поскольку данные системы действительно очень важны, их реализации существуют в большом количестве практически для всех операционных систем. Приведем два стека таких систем (табл. 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/ ));

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

Подготовка начинается с четкого определения целей, однако это не так просто, как кажется на первый взгляд. Роджер Ричардсон (Roger Richardson), президент компании Delta Sigma Corp., которая занимается разработкой производственных систем для аэрокосмической отрасли, отмечает, что "владельцы бизнеса знают свои производственные процессы гораздо лучше нас. Они знают, что сложно и что легко, а также им известны все "подводные камни". То, что они не знают – это как автоматизировать процесс".

"К сожалению, за последние 30 лет во внутренней среде компаний, наших клиентов, произошли изменения", говорит Рэнди Дженнингс (Randy Jennings), вице-президент по развитию бизнеса системного интегратора Transbotics Corp, который специализируется на системах производства, складирования и дистрибуции. "Оказывается, целый слой менеджмента и технических специалистов в американской промышленности сейчас отсутствует. В результате у клиентов есть потребности и желания, но у них нет персонала, необходимого для четкой постановки задачи".

Планирование проекта непременно развивается сверху вниз. Это означает, что всё начинается с определения полной архитектуры – общей картины – затем начинают уточняться детали. Реализация, однако, развивается снизу вверх – вы сначала пишите код модулей и покупаете или создаёте аппаратную часть, а лишь затем интегрируете их в единую систему. Если детали вашего проекта не были определены до начала реализации, то вам придётся переделывать практически всё, тратя в несколько раз больше усилий, чем при наличии четкого представления. Если быть более точным, то в несколько раз больше усилий будет тратить ваш системный интегратор!

Часто обменивайтесь информацией – но не слишком часто

Боб Гамбургер (Bob Hamburger), менеджер по развитию бизнеса системного интегратора Bloomy Controls (системы сбора и управления данными), говорит, что, по их опыту, большинство вещей, которые крадут время – это элементы пользовательского интерфейса в программном обеспечении. "Один из вопросов, который наши опытные специалисты сразу спрашивают – это „Есть ли у вас какие-либо пожелания к виду и работе пользовательского интерфейса?”"

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

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

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

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

Источник: Transbotics

Автоматизировать или не автоматизировать

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

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

Гари Кэш (Gary Cash), вице-президент по продукции и маркетингу поставщика распределительных систем FKI Logistex, утверждает, что при автоматизации процессов возрастает их точность, однако это не является причиной, по которой компании запускают подобные проекты. "Когда компания мала, все операции на складе производятся вручную. Автоматизация начинается тогда, когда становится понятно, что нельзя нанять больше людей и впихнуть их в одно здание, иначе они начнут сидеть друг у друга на головах. То есть когда не хватает производительности, начитается автоматизация. Некоторые функции автоматизируются раньше других. Перевозки, к примеру, как правило, идут первыми в этом списке".

Выполните сначала домашнее задание

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

"Составьте четкое представление о своих потребностях", говорит Дженнингс. "Вам не нужно находить решения, но вам нужно понять свои потребности – не желания, а именно потребности".

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

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

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

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

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

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

Гари Кэш из FKI говорит, что "мы должны понять ваш бизнес для того, чтобы помочь вам. Поэтому вам надо рассказать нам, как он работает, и мы придумаем, как заставить здание работать, как спроектировать его, как всё реализовать, и заставить всё работать как надо".

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

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

Источник: Kuka Robot Group

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

"Вероятно 75% веб-интерфейсов, которые мы сделали", отмечает Гамбургер, "находятся в локальных сетях. Они доступны только с компьютеров, находящихся внутри защищенной сети. Остальные 25% потребовали от нас кооперации с ИТ специалистами клиента для того, чтобы они открыли доступ в своём файрволе или поставили выделенный сервер у себя в сети. Это, кстати, довольно просто – установить аппаратный файрвол с недорогим роутером для защиты веб-сервера от атак злоумышленников".

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

30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. 3 Июль 2015, 11:03

30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. В нем приняли участие сотрудники ФПИ, ООО «Рексофт», ЗАО «Топ Системы», АО «Системы управления», АО «Объединенная приборостроительная корпорация», ОАО «Объединенная авиастроительная корпорация», ГК "Росатом", АО «Вертолеты России», ОАО «Объединенная ракетно-космической корпорация», ИТ кластера Сколково и других научных и производственных организаций ОПК, научные сотрудники институтов РАН, МГУ им.М.В.Ломоносова, ведущих технических ВУЗов, представители Минкомсвязи и Минпромторга России.

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

На заседании были утверждены: положение об общественном совете по реализации проектов в области коллективной разработки ПО, план заседаний общественного совета, сформирована рабочая группа по стандартизации, а также группы потребителей и образовательных учреждений. Участники совещания одобрили технологические принципы, заложенные в основу интегрированной инженерной программной платформы. Председателем общественного совета был избран заместитель генерального директора – руководитель направления информационных исследований Фонда перспективных исследований Сергей Гарбук. Заместителем председателя был избран заместитель генерального директора АО «Объединённая приборостроительная корпорация» Андрей Чендаров.

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

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. Заказчик объявляет тендер на разработку. Выигрывает фирма, которая либо уменьшает стоимость разработки, либо за эту же сумму предоставляет больше возможностей. Играет роль имидж компании (участие и завершение аналогичных разработок, участие в семинарах, совещаниях по теме, открытость компании).

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

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

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

Лекция 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) - получение изменения из репозитория.
Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешать
Патч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом

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