Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
А куцесть и бедность средств разработки требований отчасти компенсируется встроенной интеграцией с SharePoint и дополнительной интеграцией с MS Office от ALM Rangers....А также тем, что можно легко делать свою интеграцию почти с чем угодно. У нас, например, сделана интеграция с Enterprise Architect, т.е. требования, созданные в EA автоматически становятся воркайтемами TFS и переезжают под управление используемого в данном проекте TFS воркфлоу.
Тогда сформулирую задачу еще раз:ИМХО вы путаете задачу со способом ее решения.
Нужно к UML-модели модифицируемой программы добавить новую диаграмму.
На этой диаграмме будет отображена интересующая нас процедура программы и ее связи с другими методами, которые ее вызывают.
Это нужно для изменения этой процедуры, чтобы учесть влияние этих изменений на методы, которые ее вызывают.
Затем для каждого метода, изображенного на диаграмме и связанного с изменяемой процедурой (прямо или опосредованно через другие методы), будет проводиться оценка: нужно ли переделывать этот вызывающий метод в связи с изменением процедуры.
Диаграмма должна быть выполнена в стандарте UML.
Вчера встречались с IBM - нашли они способ поженить RRC и TFS - есть малоизвестная буржуйская контора - TaskTop - они разработали шину для интеграции RRC и TFS.Ага, ну тогда расскажите потом, как оно на практике синтегрировалось, и сколько времени и человеко-месяцев понадобилось. Будет интересен ваш опыт.
Каждый метод - это состояние моей программы. Переход из одного состояния в другие - будет показывать какие методы могут быть вызваны из текущего метода.Если суть решаемой вами задачи (которую вы пока не объяснили) требует показать программу, как конечный автомат, состояние которого полностью характеризуется выполняемым в данный момент методом, то да.
Как вам такое решение?
извините, разве вы не согласны, что в ТФС работа с требованиями совершенно неудобна, или скорее невозможна, ибо ничего с этими ворк айтемами больше сделать нельзя. ни матрицу трассирования создать, ни вменяемое дерево трассировок, кроме как классические чайльд-парент.Для этого линки типа Affects / Affected by рекомендуется использовать.
а плодить айтемы под каждую хотелку, а потом таски под каждый реквайрмент - мы с нашей спецификой только месяцев пять будем тратить на заведение и манагерство всей этой эпичной структуры.Т.е вы не ведете атомарный учет каждого требования? Вы принимаете от заказчика единый документ с набором требований, и отлеживаете жизненный путь всего документа в целом?
может, это работает для сравнительно небольших проектов с явными границами автоматизации. у нас своя специфика - в год мы выпускаем 2-3 релиза, в которые набиваются все задачки, которые заказчик смог пропихнуть за оговоренный бюджет и срок. соответственно поток хотелок и требований у нас мощн, порывист и беспощаденТак ведь поток требований и его беспощадность вроде бы не уменьшается и не увеличивается от того, в какую систему вы его записываете? Он только от бюджета зависит...в виду того, что OSS/BSS решение одного немаленького оператора связи - очень и очень сложная система и релизы, как правило, затрагивают комплексно все подсистемы.
мелкософт сами признаются, что полноценного функционала СУТ в ТФС нет.Ну, они обычно так признаются, когда их просят показать, как реализован функционал, например IBMовской линейки FocalPoint -> Doors. Если с чем попроще сравнивать, то спорят
признаться вы меня своим вопросом про process guide поставили в тупик. поковырялся, что-то не нашёл. бегло в инете тоже не нашёл.Это я ошибся, конечно, не process guide, а Process Guidance. Самая нижняя ссылка в левой колонке сайта проекта TFS, после Team Web Access, Dashboards и т.д.
представим, что инженер-электронщик в ответ на предсталенную для него принципиальную схему электронного устройства говорит проектировщику: "Ты лучше по простому нарисуй и на пальцах объясни".Принципиальная схема электронного устройства является, в отличие от диаграмм UML, точной однозначной моделью устройства. Эта схема может быть через интернет загружена в САПРовскую систему любого китайского заводика, и на выходе технологической линии через сутки выползет готовая работающая печатная плата со всеми распянными компонентами. Подключил, и работает (в идеале, если отвлечься от исправления ошибок).
нарисовав "по-простому", такие программисты вряд ли друг друга поймут _однозначно_ и _правильно_.UML однозначность и "правильность" не обеспечивает.
...
Неточная семантика. ... Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций
...
UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
...
языка моделирования UML, признанного как наиболее удобного языка моделированияПризнанного кем?
подписанный с заказчиком КП делется на requirements, каждый проект живёт под requirement, под ним задачи на предложение по реализации, HLA, ПМИ, разработку по модулям, подсистемам и прочее формируются в виде leadtask.Мне кажется, что разработчики TFS не предполагали такого его применения. TFS хорошо работает, когда КП (это же "комплексный проект", да, или что-то в таком роде?) - это Project Collection, проект - это Project, требование - это Requirement, если вы работаете по CMMI, или User Story, если по Agile. В вашем случае, судя по всему - CMMI.
ахаха)))ТФС совершенно не заточена под анализ и не предполагает управление требованиями. политика ТФС в том, что аналитики и архитекторы выступают для разработки и тестирования в роли заказчиков и формируют "требования" - таски на разработку.Ссылки интересные, спасибо, почитаем.
И мне хотелось бы, чтобы составленную мной диаграмму могли читать другие программисты, чтобы я ее мог показать им, и обсудить предлагаемое мной решение.Тут такой вопрос: цель в том, чтобы продемонстрировать читателю диаграммы знание UML, или в том, чтобы читатель понял, как это должно работать?
существуют системы управления требованиями. в них есть такая архиполезнейшая вещь, как матрицы трассировки требованийВроде бы TFS включает в себя систему управления требованиями, трассировки требований там реализованы.
...
а если вы используете в разработке долбанный ТФС, то выбор таких систем очень сужается.
существуют разные документы, предназначенные для:, и тем что
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.
"обвинениям в кривомозгости" свойственно возникать, когда скоуп проекта бесконтрольно расширяется и сроки начинают срываться.
