Назрела острая необходимость в упорядочивании огромного количества проектной документации, накопленной в течении 10 лет. Новые сотрудники не могут разобраться в скоплении директорий на файловом сервере, где хранится: проектная, эксплуатационная документация, сметы, договоры, официальные письма заказчикам и партнерам и прочая и прочая.
Информация где-то каталогизирована по проектам, где-то по годам-месяцам. В общем, привет. Также бардак с версиями документов, затруднено одновременное редактирование документов, при добавлении новой информации те, кому она нужна, не узнают об этом вовремя.
В связи с этим вопрос: кто-нибудь озадачивался такой проблемой, и как ее решал?
Продукты типа Microsoft Sharepoint Portal/Services реально могут помочь в этой ситуации?
Я понимаю, что правильная организация информации все-равно должна обеспечиваться людьми, однако было бы неплохо иметь:
1)Несколько альтернативных представлений (по проектам, по годам, по заказчикам),
2)Автоматизированный контроль версий по примеру систем типа CVS;
3)Настравиваемая навигация;
4)Оповещения об изменениях;
5)Возможно механизмы реуензирования;
Здравствуйте, gfn, Вы писали:
g> Здравствуйте,
g> Назрела острая необходимость в упорядочивании огромного количества g> проектной документации, накопленной в течении 10 лет. g> В связи с этим вопрос: кто-нибудь озадачивался такой проблемой, и как g> ее решал? g> Продукты типа Microsoft Sharepoint Portal/Services реально могут g> помочь в этой ситуации?
Могут, но я голосую за VSS (или тот версионник, что используется в вашей компании). В этом случае проектная документация хранится вместе с исходными кодами и прочими рабочими файлами.
g> 1)Несколько альтернативных представлений (по проектам, по годам, по g> заказчикам),
Мы разработали для себя структуру хранения проектных файлов, которая пока представляется нам приемлемой. На верхнем уровне иерархии — заказчики (вернее, соответствующие им каталоги). Под заказчиком — его проекты. Внутри проекта структура определяется сферой применения файлов/документов, находящихся в каталоге — примерно следующая:
требования (с подкаталогами для хранения артефактов, предоставленных заказчиком, и артефактов, относящихся к управлению изменениями);
исходные коды и прочие артефакты, относящиеся к разработке;
артефакты, относящиеся к внедрению и развёртыванию;
артефакты, относящиеся к сопровождению и поддержке;
артефакты, относящиеся к управлению проектом;
артефакты, используемые при продаже решения;
артефакты, относящиеся к урегулированию юридических аспектор проекта;
etc.
Такая структура, на наш взгляд, неплохо подходит для проектов заказной разработки. Хуже — для консалтинговых.
g> 2)Автоматизированный контроль версий по примеру систем типа CVS;
Совершенно необходимая вещь!
g> 3)Настравиваемая навигация;
Не совсем понятно, что имеется в виду. Мы выбрали для себя некий «стандарт» и стараемся его придерживаться — это сильно упрощает поиск документа.
g> 4)Оповещения об изменениях;
VSS такого не позволяет (или, допускаю, я об этом не знаю), но нам это и не требуется.
g> 5)Возможно механизмы реуензирования;
Это, насколько я понимаю, должно определяться вашим процессом.
g> Заранее спасибо за любой ответ.
Этим занимается CM (Configuration Management).
Собственно для СМ нет больших различий между кодом и документами.
Нужно определить сами документы, где вы их храните,
как идентифицируете версии и как и кого оповещаете о выходе новых версий.
Хорошо иметь план (CM Plan), в котором это все расписано.
Если вы у себя утвердите стандартную структуру каталогов
и будете ее придерживаться, то это тоже поможет.
Очень полезно переодически проводить проверки
чтобы убедиться что все еще лежит на своих местах,
помечено метками и в целом соответствует плану.
Насчет оповещений.
Достаточно, если человек, выпустивший новую версию,
сам лично послал бы всем письмо.
Заодно пусть раскажет чуть подробнее о новых вещах,
которые нет смысла помещать в "историю изменений".
Ты абсолютно прав, что хороший СМ поддерживается именно людьми.
Я видел абсолютно отвратный СМ при неплохих системах типа Documentum.
И в то же время видел превосходный СМ, где все просто хранилось под CVS.
Documentum в целом не плох, но мне больше нравится хранить доки
рядом с кодом и использовать для этого обычную систему контроля версий.
Здравствуйте, speedballer, Вы писали:
S>VSS такого не позволяет (или, допускаю, я об этом не знаю), но нам это и не требуется.
У нас ClearCase и он это позволяет. Можно приделать perl скрипт,
который на каждый чих будет спамить всех кого надо и кого не надо.
Но лучше все же это ручками делать.
За документ всегда есть ответственный (лучше есть он есть),
который сам должен решать, когда документ готов для выпуска
и когда нужно народ об этом оповестить.
Здравствуйте, gfn, Вы писали:
gfn>Здравствуйте,
gfn>В связи с этим вопрос: кто-нибудь озадачивался такой проблемой, и как ее решал?
Собственно bkat уже все описал — унифицированняя структура каталогов и система идентификации документов (как минимум по проэктам и типам) + система контроля версий + правила работы, которых все придерживаются.
gfn>Продукты типа Microsoft Sharepoint Portal/Services реально могут помочь в этой ситуации?
Sharepoint Portal Server — может, все нижеперечисленное (и намного больше) он умеет, если чего нехватает, то можно дописать, API (СDO, CDOWF, MAPI) у него открыт.
Но связываться с ним не стоит. (IMHO основаное на опыте).
— В конечном итоге его система документооборота он работает на MS Access (SPS->Exchange->Jet), со всеми вытекающими отсюда проблемами масштабируемости и быстродействия.
— Сам Microsoft на SPS как систему документооборота уже забил — в STS2003 его поддержка это просто backward compatibility фича и дальнейшего развития не предвидится.
Sharepoint Team Services — не поможет — это совсем другой продукт, и, как минимум, контроля версий и (полноценнго) рецензирования там нет.
В данной ситуации из решений близкого мне Rational можно использовать связку ClearCase и ClearQuest.
CC отвечает за хранение версий, проектные срезы
CQ отвечает за уведомления
Поддерживаю мнение, что СМ — это прежде всего люди
Добавлю от себя, что не только люди, но и процесс. Очень многие считают, что достаточно одних инструментов для решения проблем. Вот чем хороша область СМ так это тем, что без процесса и людей здесь делать нечего
