Комментарии 56
блокнот и ручка:)
не думаю, что в таком виде удобно их анализировать, комментировать описывать функционал, рисовать схемы взаимодействия и т.д.
Да, согласен. Но в основном у меня не очень большие проекты попадаются (учусь я еще:) Но когда проект вырастает за переделы двух-трех листиков – то переношу наработки на комп в программу Enterprise Architect. Вот ещё скрины и прямая ссылка.
наворочено. =)
Я предпочитаю Mindjet MindManager.
Вы уже определитесь: это требования или что-то другое? Что означает "описывать функционал требования"? Или "рисовать схему взаимодействия требований"?
ну просто товарищ не отделяет моделирование от требований. мне кажется, это простительно - главное, что интерес есть )
Ну, тогда, что можно посоветовать? Навереное, хватать книгу К.Лармана, и знакомиться
с основами. Основной инструмент для сбора требований — блокнот и ручка. Плюс MS Word,
в редких случаях MS Excel. :)
и анализа требований
с основами. Основной инструмент для сбора требований — блокнот и ручка. Плюс MS Word,
в редких случаях MS Excel. :)
и анализа требований
Вы уж меня простите, возможно я неправильно сформулировал :)
А интерес действительно большой.
+1, для _сбора_ требований - это самое удобное.
А уж вести список можно где угодно. Кто-то предпочитает в Экселе, мы обычно ведем это как список в SharePoint'е.
А уж вести список можно где угодно. Кто-то предпочитает в Экселе, мы обычно ведем это как список в SharePoint'е.
большой и сложный DOORS или Rational Requisite Pro
Rational Requisite Pro - читал про него. Пишут что есть много недостатков, причем в тех вещах, которые по сути очевидны. Типа "нельзя прикреплять файл к требованию" и т.д. Что скажите? Мне бы по проще... (=
разные бывают требования, и разные подходы работы с ними... кто-то может сказать, что наличие прикрепленного файла в требованиях, равносильно нарушению нормальных форм в базах данных... все зависит от размера проекта... и от того насколько известны требования... мне приходилось работать с requisitePro... и действительно все приходится подгонять под него... но он прекрасно справлялся.... DOORS для меня идеал в случае больших проектов... и вообще отлично используется как база требований в организации... но все эти инструменты очень дороги... можно жить и Excel...
TrackStudio ?
А что можете сказать о Caliber RM?
Я сейчас пользую совместно-редактируемую таблицу в гуглдоксах.)
Но тоже непрочь бы найти что-либо более заточенное под задачу.
Только желательно онлайновое что-то для упр. проектами... и по-русски.
Но тоже непрочь бы найти что-либо более заточенное под задачу.
Только желательно онлайновое что-то для упр. проектами... и по-русски.
MS OneNote + Hamachi будут удобнее гуглдоксов :)
Расскажите по подробнее, если можно со ссылками.
управление проектами.... http://www.devprom.net
[реклама]
TrackStudio смотрели ? Онлайновое, по-русски, есть иерархии (в том числе и требований)
[/реклама]
TrackStudio смотрели ? Онлайновое, по-русски, есть иерархии (в том числе и требований)
[/реклама]
Удобно, когда он-лайн. Особенно если проект связывает разные компании.
начал использовать _http://www.teamer.ru для "домашних" проектов. В основном тех, которые не касаются работы. Если проект небольшой, то удобно, но очень многого не хватает. С указанными программами даже сравнивать нельзя, но преимущество, что онлайн и можно совместно работать. В общем смотри, для рассмотрения требований, их обсуждения - ничо. А все остальное в нормальных прогах надо :)
начал использовать _http://www.teamer.ru для "домашних" проектов. В основном тех, которые не касаются работы. Если проект небольшой, то удобно, но очень многого не хватает. С указанными программами даже сравнивать нельзя, но преимущество, что онлайн и можно совместно работать. В общем смотри, для рассмотрения требований, их обсуждения - ничо. А все остальное в нормальных прогах надо :)
Видел этот проект. Возможно удобно. Но как ты и описал, многого не хватает. Меня интересуют именно профессиональные программы, которые можно использовать для сбора требования под сложные интернет проекты. Ведь Teamer.ru родился не просто так ;)
А как родился и почему?
На мой взгляд, проект родился на основе как раз какой существующей программы.
да там и программы то нет.
в основу поставлено - постановка задачи, выполнение сроков, ответственный исполнитель, закрытие задачи. фсе.
т.е. использовать его при "мозговом штурме", когда все просто пишут мысли, а потом кто-то резюмирует - очень удобно. Или расписать какой-то проект по планам, типа, что надо сделать в порядке очередности и ничего не забыть - поможет. Но вот для бОльшего - уже не ахти.
Я хочу сказать, что это основы основ и таких программ не онлайн нет. Скорее всего была взята идея о том, что _это_ надо, реализована основная часть. А уж потом, думаю. допишут все остальное. Если допишут :)
в основу поставлено - постановка задачи, выполнение сроков, ответственный исполнитель, закрытие задачи. фсе.
т.е. использовать его при "мозговом штурме", когда все просто пишут мысли, а потом кто-то резюмирует - очень удобно. Или расписать какой-то проект по планам, типа, что надо сделать в порядке очередности и ничего не забыть - поможет. Но вот для бОльшего - уже не ахти.
Я хочу сказать, что это основы основ и таких программ не онлайн нет. Скорее всего была взята идея о том, что _это_ надо, реализована основная часть. А уж потом, думаю. допишут все остальное. Если допишут :)
тимер, выглядит заманчиво и просто. тоже спс.)
по мне лучше ручки и бумаги (карточек) нет ничего.
Ну со мной-то все ясно, я фанат Agile.
А для любителей компьютерных программ....в московском офисе Люксофта будет семинар в следующий четверг, 29-го ноября, посвященный компьютерным средствам поддержки проекта.
http://livents.ru/msk/event/2007/11/29/a…
Приходите, пообщаемся
Ну со мной-то все ясно, я фанат Agile.
А для любителей компьютерных программ....в московском офисе Люксофта будет семинар в следующий четверг, 29-го ноября, посвященный компьютерным средствам поддержки проекта.
http://livents.ru/msk/event/2007/11/29/a…
Приходите, пообщаемся
Спасибо за информацию. Я бы сходил, но регистрация закончена. =( реально попасть?
О, у нас тоже пользуются Agile.
Ещё shairpoint, mind manager, ms visio и ms word в некоторых случаях.
Пробовали Together Architect, но из нас им пользуется только один человек из всего отдела.
семинар любопытен, может, действиетльно схожу, пообщаемся. спасибо за ссылку :)
Ещё shairpoint, mind manager, ms visio и ms word в некоторых случаях.
Пробовали Together Architect, но из нас им пользуется только один человек из всего отдела.
семинар любопытен, может, действиетльно схожу, пообщаемся. спасибо за ссылку :)
Непонятно наличие BPWin/ERWin в списке.
Остальные субъективно являются монстрами, от которых проблем значительно больше, чем пользы.
Issue tracking с JIRA или Trac - наш путь.
Остальные субъективно являются монстрами, от которых проблем значительно больше, чем пользы.
Issue tracking с JIRA или Trac - наш путь.
Указанный перечень средств предназначен не для анализа требований, а для управления ими. Сбор и анализ требований - это практически всегда ручная/мозговая деятельность.
Методы сбора и анализа требований прекрасно описаны в книгах Вигерса, Лефингвелла, Халла/Джексона, Хольцблатт, Дика.
Информацию о сборе требований можно найти у нас на форуме. Если есть вопросы - задавайте, ответим.
Кстати, про сбор требований планируется отдельный семинар.
Методы сбора и анализа требований прекрасно описаны в книгах Вигерса, Лефингвелла, Халла/Джексона, Хольцблатт, Дика.
Информацию о сборе требований можно найти у нас на форуме. Если есть вопросы - задавайте, ответим.
Кстати, про сбор требований планируется отдельный семинар.
а почему из управлеения требованиями, вы, исключили сбор и тем более их анализ? Безусловно, поиск требований может происходить без использования перечисленных средств... можно тут говорит а разных методиках, таких как опросники, интервью, JAD сессии и т.д., но все эти требования на бумажках ничего не стоят, пока они не систематизированы... а для этого эти инструменты подходят лучше всего...
потому что удобно разделять разработку и управление требованиями
а как может происходить поиск требований С ИСПОЛЬЗОВАНИЕМ перечисленных средств?
систематизация - это не сбор
систематизация (классификация) может происходить с помощью программных инструментов, но анализ, производимый при классификации, выполняется в сознании аналитика, а не представляет собой автоматическую функцию
под средствами управления требованиями обычно понимаются инструменты учёта, классификации и установления зависимостей требований, а это совсем не сбор и не анализ
а как может происходить поиск требований С ИСПОЛЬЗОВАНИЕМ перечисленных средств?
систематизация - это не сбор
систематизация (классификация) может происходить с помощью программных инструментов, но анализ, производимый при классификации, выполняется в сознании аналитика, а не представляет собой автоматическую функцию
под средствами управления требованиями обычно понимаются инструменты учёта, классификации и установления зависимостей требований, а это совсем не сбор и не анализ
сбор информации в wiki
схемы в visio
и MainManager для анализа
MSPM для составления плана проекта
схемы в visio
и MainManager для анализа
MSPM для составления плана проекта
OSRMT попробуйте - подходит хорошо для долгосрочных проэктов.
Вообще с требованиями какая-то беда, больше чем с другими инструментами разработки :( Одно из требований к системе управления требованиями - это traceability, чтобы можно было легко замапить требования на архитектуру и далее на план тестирования, и прослеживать все изменения с верхнего уровня (требования) на все остальные. Проблема в том, что здесь требуется интеграция нескольких инструментов (requirements, UML modeler, issue tracker, version control, test management system).
Можно конечно взять монстрокид вроде Rational где есть все, но продукты у них как будто лет 8 не развиваются - для каждого по отдельности продукта есть существенно более удобный конкурент на рынке. Другие продукты пытаются засунуть весь функционал внутри себя, например в Mercury (софт для тестирования), где есть и требования и issue management, но опять же если это софт для тестирование то остальные аспекты у него реализованны хуже, и нет связи с архитектурой.
В моделерах типа Enterprise Architect или Power Designer управление требованиями тоже присутствует, однако выглядит оно с точки зрения именно моделирования, в результате чего сбор требований или совместная работа или генерация документа выглядит не удобной.
Так что пока у нас основное средство управления требованиями - это MS Word.
Можно конечно взять монстрокид вроде Rational где есть все, но продукты у них как будто лет 8 не развиваются - для каждого по отдельности продукта есть существенно более удобный конкурент на рынке. Другие продукты пытаются засунуть весь функционал внутри себя, например в Mercury (софт для тестирования), где есть и требования и issue management, но опять же если это софт для тестирование то остальные аспекты у него реализованны хуже, и нет связи с архитектурой.
В моделерах типа Enterprise Architect или Power Designer управление требованиями тоже присутствует, однако выглядит оно с точки зрения именно моделирования, в результате чего сбор требований или совместная работа или генерация документа выглядит не удобной.
Так что пока у нас основное средство управления требованиями - это MS Word.
Использую DOORS, после того как попробовал писать требования в нем, уже в word меня писать не заставишь:)
Удобная продуманная система, сохраняет время и нервы, как мои так и разработчиков.
Удобная продуманная система, сохраняет время и нервы, как мои так и разработчиков.
Что то не могу найти, где можно посмотреть почитать про эту систему. =( Только текст, интерфейс тоже хочется глянуть. Спасибо.
http://www.telelogic.com/products/doors/doors/index.cfm
официальное описание, кстати есть и он-лайн версия.
или на русском: http://www.telelogic.ru/
Так же есть хорошая книга "Разработка и управления требованиями" (автор Джереми Дик и другие), которая описывает процесс разработки требованийс помощью DOORS
официальное описание, кстати есть и он-лайн версия.
или на русском: http://www.telelogic.ru/
Так же есть хорошая книга "Разработка и управления требованиями" (автор Джереми Дик и другие), которая описывает процесс разработки требованийс помощью DOORS
А чем плохи Wiki-системы?
Скажу по поводу того как я собираю требования, вне зависимости от ПО. В сборе требований самое важное, мне кажется, - делать максимально короткие итерации при формулировании требований и их уточнении, при возможности надо сделать прототип. Тогда можно реально приблизиться к решению бизнес задач, а не делать работу, котрая потом будет переделана, лишь потому, что она решает не те задачи (а не потому, что сделана некачественно). Я делаю так: встречи, use-case's, рисование интерфейсов, исследование бизнес-процесса заказчика. Вобщем-то это agile в требованиях.
Кстати в Software Book of Knowledge есть глава посвященная управлению требованиями - она как бы резюмирует изложенное в "Разработка и управления требованиями" (автор Джереми Дик и другие) от Doors. Достаточно полна и не очень большая.
Кстати в Software Book of Knowledge есть глава посвященная управлению требованиями - она как бы резюмирует изложенное в "Разработка и управления требованиями" (автор Джереми Дик и другие) от Doors. Достаточно полна и не очень большая.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сбор требований к проекту