Уважаемый All поделитись опытом или ссылками на документацию по subj pls !
Раньше когда в проекте участвовало 3-4 человека стыковка модулей происходила достаточно безболезненно, но при рарзростании колектива до 10-12 человек(правда и сложность проектов возрасла) огромное количество времени стало уходить именно на стыки модулей. Где-то читал что на западе принято что модуль делает один разработчик а тест для него пишет другой! Кто нибудь использовал данную методику ? Пишет ли кто-нибудь поведенчискую модель системы целиком?

Для управления бальшими проектами
используется version menegment, например CVS.
Сейчас MG интегрировала CVS в FPGAdv (HDL Designer).

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

Именно с такой ситуацией столкнулись сейчас. Делаем большое устройство, коллектив разработчиков - 7 человек. Вопрос синхронизации кодов, учета версий, и project issues backtracking реализовали проработкой политики ведения документации по проекту (ввели трехуровневую модель) и систему CVS, как единственно бесплатную.

Из предыдущего опыта работы в канадской компании NORTEL Networks (проектировали и верифицировали ASICs трафиковых процессоров на 10 млн. вентилей по технологии IBM Cu11) могу сказать следующее. Обычно существует две параллельно работающие команды: RTL-дизайнеры и верификаторы. Для их работы необходимо существование написанного документа (General Specifications), в котором описана структура и работа проектируемого устройства. RTL-дизайнеры разрабатывают RTL-модель устройства, а верификаторы - поведенческую модель, верификационную среду и обширный набор тестовых программ (testcases), которые заранее разрабатываются в соответствии с Conformance Test Plan, сочетающего в себе описание прямых (Direct Testcases) и рандомизированных (Constrained Randomization Testcases) проверок.

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

Золотое правило разработки аппаратуры - никогда не доверять разработку и тестирование одному и тому же человеку (коллективу). Дела не будет.

Мы использовали Synchronicity DesignSync и ProjectSync для синхронизации кодов VERA-программ и Verilog-моделей. ProjectSync использовалась для ведения Issues DataBase, в которую заносились все сбои и проблемы, обнаруженные на регрессии, и которые требовали от соответствующих ответственных лиц реакции.

В Российской действительности все идентично, но денег нет на "крутые системы", поэтому легко обходимся Aldec Active-HDL как интегральной средой FPGA-проектирования и верификации, а WinCVS - как средство синхронизации кодов.

Лично мне Synchronicity больше по вкусу пришлась. Четче работа и функции получше реализованы. Но, за это и деньги требуют...

Огромное спасибо! Хотелось бы узнать присутсвует ли некоторый формализм при разработке ? Т.е. когда разработчику дают задание на модуль , то к ниму прилагаються временные диагарамы или он делает их под себя?

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

oleg_rudakov
А где можно скачать WinCVS? или он платный?
И где можно почитать книжку или руководства по работе в коллективе например прогрммистов? Основные принципы?

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

Выдержка из руководства по CVS
You can get cvs in a variety of ways, including free download from the internet. For
more information on downloading cvs and other cvs topics, see:
http://www.cvshome.org/
http://www.loria.fr/~molli/cvs-index.html

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

WinCVS - это бесплатное ПО.

Вот некоторые полезные ссылки по WinCVS:

1) http://mesh.dl.sourceforge.net/sourceforge...WinCvs13b20.zip - скачивайте отсюда.

http://www.thathost.com/wincvs-howto/ - полезная документация по WinCVS.

Кстати, при установке WinCVS потребуется еще и Python, который можно залить отсюда: http://www.activestate.com/Products/ActivePython/

oleg_rudakov
Спасибо

TortoiseCVS(h__p://www.tortoisecvs.org/) — великолепная система версий для Windows на базе известной open-source системы CVS. Интегрируется в оболочку Windows, работать с ней очень удобно из обычного «проводника» Windows.

Как вы считаете, какие системы помимо непосредственно САПР и системы контроля версий должны использоваться на предприятии?

Я бы добавил к системе контроля версий:
1) Программу планирования проекта (Microsoft Project).
2) Многопользовательскую базу знаний технической информации по САПР/языкам и т.д. (MediaWiki)
3) Многопользовательскую систему учета багов (Bugzilla, Project Sync).
4) На больших проектах - систему для общения разработчиков (Skype - голосовое общение).


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

Может кто то из собравшихся расскажет в общих чертах как пользоваться WinCVS? так сказать dataflow...

Я бы не советовал сейчас использовать CVS. Лучше посмотрите в сторону Subversion. На форуме он активно обсуждается.

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

советую посмотреть в сторону ASSERTIONs (языки PSL\подходит как для ВХДЛ так и Верилог интеграции\ или assertions из SystemVerilog) для формальной спецификации интерфейсов (собственные интерфейсы должны быть детально проработаны и подробнейшим образом описаны - иначе потом пойдёт "стрелочнество")

PS между прочим Vera сейчас встроена в SystemVerilog

мы начали использовать http://trac.edgewall.org/ бесплатно, написана на питоне. Работает на большинстве платформ. Пока нравиться.

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

А разбираться и не зачем http://trac.edgewall.org/ документирован сам собой. Те вы поднимаете trac сервер на какой-либо машине и ходите к нему через сеть. Выглядит trac один в один как на сайте.

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

Вот набор пакетов требуемых для установки, последовательность установки на сайте:
clearsilver-0.9.14.win32-py2.4.exe
pysqlite-2.3.5.win32-py2.4.exe
SilverCity-0.9.7.win32-py2.4.exe
svn-python-1.4.4.win32-py2.4.exe
trac-0.10.4.win32.exe

итого 5 мегабайт, не считая интерпретатора питона(9.5МБ) + пакета докутилс (1.2МБ)

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

Для создания документов используется технология reStructuredText. Затем с помошью скрипта-конвертера получается документ в формате HTML.

Для устранения багов/модификаций использует систему тикетов, при этом позволяет связать правки, модификации кода (SVN) с тикетом и по запросу отображает это.

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

Используем на уровне отдела, коллектив 8 человек, сервером занимается 1 гуру, остальные только пользуют.

Думаю ответил на ваш вопрос.

яволь. исчерпывающе. спасибо

Попробовал Trac - показался очень ограниченным.
Из всего opse-source понравился Mantis.
Преимущества:
- возможность создавать иерархию проектов
- русифицированный интерфейс и поддержка русского языка (utf8 )
- настраиваемые области для каждого проекта для хранения вложеных файлов к задачам.
- Настроаиваемый workflow
- Настроиваемые кастом-поля
- Отношения между задачами
- Интеграция с Eclipse и др. системами через SOAP API
- простота настройки - есть пакет Instant mantis - скачал, запустил bat-файл и можно заходить создавать проекты.

Escorial
ну всёже продукты немного разного толка
Mantis- насколько я понимаю, баг-трекинг и планирование
Trac - как и писал топикстартер - "Организация работы в коллективе разработчиков". Т.е. минимальные инструменты есть: и тот же багтрекинг через систему тикетов и привязку к svn commit, и roadmap'ы & mileston'ы для планирования, и вики-движок для совместного писания документации (тут конечно больше подходит для опенсорц-проектов в веб), и удобный frontend для навигации по репозитарию со всеми нужными юазовыми функциями.
насчёт UTF-8: так сейчас оно просто повсеместно!
насчёт русского интерфейса: оно там есть, просто надо немного топором поработать, чтобы прикрутить.
и потом - проект молодой и динамичный - и даже несмотря на это получил весьма широкое распространение (видимо большей частью из-за всеже своей простоты)
сейчас активно тестируется версия 0.11, в которой кардинально переработан движок и добавлены в ядро многие функции ,которые раньше шли как опциональные плагины.

CaPpuCcino
кстати, в федоровских репозитариях есть trac, достаточно дать команду "yum install trac*" и он поставится со всеми нужными зависимостями - потом останется только настроить. ;-)

.

Посмотрите в сторону продуктов Atlassian - Jira, Confluence, Bamboo и т.д. www.atlassian.com Очень мощные и настраиваемы продукты.

Для тех кто еще не нашел для себя ничего подходящего, посмотрите redmine, очень похож по смыслу на TRAC, только поддерживает локализацию (русский есть в поставке), иерархичность проектов + есть еще какие-то отличия от TRAC-a.
Redmine написан на Ruby, для тех, кому трудно настраивать все руками есть дистрибутив все в одном: http://bitnami.org/stack/redmine (там есть такой же и для TRAC). Дистрибутив включает в себя subversion, mysql, apache и redmine. Инсталлятор для Win ставит все службами, настроек практически ноль. Жалко я его нашел не сразу, убил полдня, чтобы запустить все это хозяйство как службы руками.

CVS вещь морально устаревшая, для новых проектов лучше использовать GIT или SVN.

Недостатки:
1) Мягко говоря заманаешся ставить это на машину (под винду). Еслибы поставлялся в виде подобном AppServ (уже настроенная связка Apache + PHP + MySQL - минимум настроек).
2) Недоделан интерфейс администрирования/управления правами доступа разработчиков
(моглибы веб- интерфейс сделать а не через команды командной строки)
3) Вроде как нет встроенного просмотрщика комментариев к ревизиям SVN (надо подключать внешний, который должен быть заточен под версию Truc)

В общем на мой взгляд поект должен поразвиваться какоето время чтобы принять более дружелюбную для пользователя форму. Пока - сплошная потеря времени. Да ещёлюдей надо приучить.
Я к SVN не могу никого приучить. 3 года уже пытаюсь...




http://bitnami.org/stack/redmine Вот это классный ресурс. Зайдите. Там и Вики поднятая в двух конфигурациях есть: с MySQL и без неё

//извините за флуд

Редмаин в отличие от трака использует базу данных MySQL (как и большинство web - серверов), имеет очень приятный внешний вид (как этот форум, а не серо-бордовые тона как TRAC)
В общем вот ссылка на демо- проект http://demo.redmine.org
У меня виды на редмаин. Кто может сказать чего плохого об этом продукте?

вопрос армянскому радио:
-можно ли работать отбойным молотком без сжатого воздуха?
-можно. но вы быстро устанете
под правильной операционкой все зависимости ставятся автоматически.
пример тестового конфига апач - рабочий. всё что надо - созать окружение tracadmin'om

Он есть в качестве плагина (webadmin). Начиная с версии 0.11 он будет входить в стандартную поставку

развивается... принимает... =)

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


веб-серверы сами по себе не используют ничью БД. Приложения, крутящиеся на веб-серверах, те - да. используют. TRAC текущей версии использует SQLite. TRAC 0.11, который уже доступен в виде беты может использовать SQLite, PostgreSQL, MySQL. И что?
имхо, это преимущество/недостаток только при ситуации установки продукта на коммерческий хостинг. на своем сервере внутри ораганизации вы можете позволить себе поднять любую БД, на основании личных предпочтений либо корпоративных стандартов.

и что? на вкус и цвет товарищей нет.. Мне , к примеру, очень импонирует цветовая гамма TRAC =)

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

Не нашел пока в редмаине простановку зависимостей работ друг от друга

коллеги, обсуждение технических особенностей redmine в отдельной теме: http://electronix.ru/forum/index.php?showtopic=49208

Добрый день!

Интересует субж при разработке электронных устройств (в основном только железо, без ПО).
Посоветуйте пожалуйста статьи/ресурсы по инженерному менеджменту, а также планированию.

есть и конкретные вопросы, мож кто ответит, если не трудно (расскажите как это всё у вас устроено)

1 пишутся ли у вас понедельные отчеты (отчеты о выполненной работе за каждый день)?
2 зависит ли зп от объёма выполненной работы?
3 (работаю на совдепиевском предприятии) у нас в плане "разработка схемы" стоит одной строкой и не подлежит дальнейшей детализации, мне кажется это не очень верно)) а какая детализация этого у вас?

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

2. Зарплата зависит не от объема, а от времени проведенного на работе. Перерабатывает человек ежедневно, ему дают премию за переработки, уходит вовремя, не дают. Зато есть возможность сорвать сроки, и они регулярно срываются. Потому что фиг угадаешь, как там на самом деле выйдет.
3. Детализация "разработки схемы" вещь хорошая но бесполезная. Так как одно дело, разработать схему из готовых "кубиков" предыдущих проектов, другое, сваять нечто пусть не совсем но новое, подобрать решения, провести расчеты. Затраты по времени тут нереально большие, угадать невозможно. Обсуждение детализации сходит к разговору "чего так долго? а кто ж знал что столько всего вылезет".
А вот с разработкой платы все гораздо лучше. В среднем есть цифра, которая с 90% точностью дает время разводки. Надо засечь момент когда схема закончена и начата расстановка деталей, и засечь момент когда идет отгрузка герберов производителю. Делим на число net или число pad для данной платы на число дней, получаем цифру для данного человека.

Формучане! Кто-нибудь едет?
Семинар «Управление проектами разработки электронной аппаратуры» состоится 28 ноября в Москве в гостинице «Оксана» (ст. метро ВДНХ)

Присоединяюсь к вопросу: Кто-нить был там? Можно ли где-то посмотреть материалы с того семинара?

Вставлю свои "пять копеек".
У нас (конструкторский отдел радиозавода, по сути, порядки остались "совдеповские") для соблюдения формальной стороны вопроса, и как дань традиции, пишутся месячные планы, потом отчеты. Хотя они, чаще всего, только для великого начальства и живут немного в параллельной реальности. (начальству об этом говорить не принято) Сначала меня это жутко нервировало, потом, как и все, махнул рукой и перестал обращать внимание.
Для реальной работы, по ряду проектов, где-то с 2011г. стали применять Atlassian Jira,как систему управления заданиями, в связке с SubVersion для хранения документации.
Вся документация по проекту хранится в репозитории SVN (дерево папок повторяет структуру и состав изделия с разбивкой по блокам, платам и т.п.) Под контролем версий лежат схемы, PCB, чертежи DWG, исходники программ, и документация (в форматах RTF или Word). Конечно, большинство этих файлов SVN воспринимает как просто бинарные и "не умеет" отслеживать и сливать их изменения. Тут уж приходится чисто организационно решать вопрос чтоб один и тот же файл не правили два исполнителя одновременно. На практике таких проблем не возникало. Большинство документации и текстовых файлов (когда нужна групповая работа над документом) писалась в GoogleDoc, а потом результат вставлялся в репозиторий уже в RTF или DOC.
Теперь по заданиям.
Хотя Jira и не идеальный инструмент для работы с железом - все же он "родом" из багтрекера - но ее использование сильно упростило жизнь и позволило хоть как-то упорядочить работу.
Для проекта в Jir'е создавался набор компонентов с разбивкой по блокам, платам, ПО и т.д. Все задания привязываются к компоненту, с которым они связаны. Устанавливаются логические связи между задачами, которые соответствуют реальной связи узлов/плат/блоков в изделии.
Пример набора задач, например, для платы:
* Предварительный расчет (если какие-либо узлы требуют расчета для выбора той или иной схемотехники)
* Разработка схемы (тут, если схема сложная и может быть разделена на логически законченные куски, для каждого могут быть созданы отдельные подзадачи)
* Разработка печатной платы
* Сопровождение комплектования платы. (Комплектование ведет отдел снабжения, но все вопросы с которыми они обращались к нам, конструкторам фиксировались тут)
* Монтаж платы или Сопровождение монтажа платы (т.к. у нас собственно монтажный участок в систему вовлечен не был, эту задачу вел конструктор, отвечающий за плату. Тут фиксировались все вопросы возникающие при проведении монтажа, все обнаруженные ошибки в документации и пр.)
* Ну и собственно, запуск и регулировка платы - журналируется весь процесс с указанием возникших проблем и пути которым они решались.

В каждой задаче, в ленте комментариев, пишется своего рода журнал работы: Сделал то-то, получилось так-то, параметры нас не удовлетворяют - варианты решения, проверил такой-то вариант - не получилось, проверил второй вариант - параметры нормальные и т.п. В результате имеем ход работы, фиксацию проблем с которыми столкнулся исполнитель и почему он принял то или иное решение. Бывали случаи, что разрабатывал схему один, а запускать пришлось другому человеку - вот тут и была оценена вся полезность подобной системы.
Исполнитель, в процессе выполнения работы, желательно ежедневно, проставляет затраченное время на конкретную задачу. Процессы разработки схемы или запуска платы, зачастую, трудно прогнозируются по времени, но исполнитель имеет возможность сам ставить процент готовности по его мнению. Для руководителя это удобно для быстрой оценки состояния дел по проекту. Если возникают сомнения, то просмотр журнала затраченного времени совместно с лентой комментариев (где описан ход работы) очень легко вычисляется если исполнитель "вешает лапшу" или действительно столкнулся с проблемой которая с ходу не решилась. В любом случае, при любых разборках, разговор становится аргументированный - есть четка хронология работы и временных затрат.

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

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

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

Цифра результат опыта?
Просто как-то странно...
Ибо даже платы с одинаковым числом падов\цепей могут иметь очень большую разность в плане выравнивания трасс, места и кучи других противных факторов. //К примеру, выравнивание 6 групп шин внутригруппно и между собой... И это не считая выравнивания свч части... //~Грустно вздыхает.
Да и размещение иногда занимает больше времени, чем трассировка...
Наконец, никогда нельзя исключать того, что из-за человеческого ли фактора или из-за какой другой причины, схема "ну чуток же поменялась, чего ты, тут делов то на пару дней"... А тебе, чтобы впихнуть этот чуток нужно будет неделю-другую попыхтеть, дабы впихнуть невпихуемое так, чтобы оно не мешало работать...
Вообщем, не надо так жестко вычислять время работы трассировщика
Всякое бывает

Согласн.
Тут формально нельзя подходить.
Бывает над схемой из 3-х типов деталей думаешь полгода.
А бывает за день придумавыешь схему из 9-ти типов деталей

Поэтому сложность трассировки платы измерять кол-вом падов не совсем корректно

если под вашим началом группа из 5-7 человек или более - рекомендую к прочтению:
Herding Cats: A Primer for Programmers Who Lead Programmers by J. Hank Rainwater

для более мелких групп - исключительно индивидуальный face-to-face подход.

на мой взгляд универсальности или совершенной модели ведения разработки нет...
Здесь как говорится на вкус и цвет товарищей нет (имеется ввиду вкусы руководства)...