Здравствуйте, Программер, Вы писали:
П>Здравствуйте, господа девелоперы, админы, юзеры.
П>Собственно в ближайшее время буду писать ситему управления разработкой приложения, и собственно очень бы хотелось провести небольшое исследование.
Ты один?
П>Вопрос таков: как вы офорляете требования?
В "ворде". Документы с требованиями помещаются в систему управления версиями.
Документы проходят review и утверждаются.
Сейчас пытаемся внедрить систему управления требованиями,
которая в том числе позволяет связывать требования с другими частями системы.
Пока что внедрение идет не очень то успешно.
Слишком много усилий от многих людей требуется.
П>1) Вы вообще занимаетесь этим?
Да, конечно.
П>2) Что вы вносите в требование?
То, что и должно быть. Описание того, что должна делать система.
Вообще похоже что ты взялся за неподъемную задачу.
В принципе ничего плохого в этом нет.
Как минимум в итоге будешь хорошо разбираться в этом вопросе.
Но систему ты свою, особенно если ты один, до конца не доведешь.
Программер -> "Как вы оформляете требования" :
П> Здравствуйте, господа девелоперы, админы, юзеры.
П> Собственно в ближайшее время буду писать ситему управления П> разработкой приложения, и собственно очень бы хотелось провести П> небольшое исследование.
а зачем писать, когда есть готовые решения?
П> Вопрос таков: как вы офорляете требования?
П> 1) Вы вообще занимаетесь этим? П> 2) Что вы вносите в требование?
RequisitePro, из минусов — дорогой.
Yury Kopyl aka hrg | http://id.totem.ru | Все вышесказанное является моим
личным мнением и может быть использовано против вас
Здравствуйте, Программер, Вы писали:
П>Здравствуйте, господа девелоперы, админы, юзеры.
П>Собственно в ближайшее время буду писать ситему управления разработкой приложения, и собственно очень бы хотелось провести небольшое исследование.
П>Вопрос таков: как вы офорляете требования?
П>1) Вы вообще занимаетесь этим? П>2) Что вы вносите в требование?
П>Заранее благодарен всем, кто откликнется. Если что, то можно писать и на мыло: intersys@yandex.ru.
Общепринятый подход — написание UseCases( Вариантов испльзования системы)ю Что туда писать — тема не одной книги )
Здравствуйте, bkat, Вы писали:
B>В "ворде". Документы с требованиями помещаются в систему управления версиями. B>Документы проходят review и утверждаются. B>Сейчас пытаемся внедрить систему управления требованиями, B>которая в том числе позволяет связывать требования с другими частями системы. B>Пока что внедрение идет не очень то успешно. B>Слишком много усилий от многих людей требуется.
А если не секрет как называется эта система и почему вы выбрали именно ее ?
Большое спасибо всем за ответы.
B>Вообще похоже что ты взялся за неподъемную задачу.
Любая задача подъемна — если подходить по этому принципу делается все. Есть мудрая русская пословица "Глаза — боятся, а руки — делают". Если же начать анализировать проект, то все не так уж и сложно, но муторно.
B>В принципе ничего плохого в этом нет. B>Как минимум в итоге будешь хорошо разбираться в этом вопросе.
Согласен. В любом случае я ничего не потеряю.
B>Но систему ты свою, особенно если ты один, до конца не доведешь.
Если подходить философски, то довести софтину до конца — значит похоронить. Все развивается, и софт должен тоже не стоять на месте.
А на счет числа программеров, да сейчас я один. Но очень часто бывает, что после первых версий к гордому одиночке присоединяются друзья, коллеги. В результате проект идет в гору. Так что все не так уж плохо.
Здравствуйте, Программер, Вы писали:
B>>Но систему ты свою, особенно если ты один, до конца не доведешь. П>Если подходить философски, то довести софтину до конца — значит похоронить. Все развивается, и софт должен тоже не стоять на месте. П>А на счет числа программеров, да сейчас я один. Но очень часто бывает, что после первых версий к гордому одиночке присоединяются друзья, коллеги. В результате проект идет в гору. Так что все не так уж плохо.
Много чего можно одному делать,
но вот именно такую систему лучше сразу делать в команде.
Тогда она будет ближе к жизни.
Здравствуйте, bkat, Вы писали:
B>Много чего можно одному делать, B>но вот именно такую систему лучше сразу делать в команде. B>Тогда она будет ближе к жизни.
Здравствуйте, Программер, Вы писали:
П>Здравствуйте, bkat, Вы писали:
B>>Много чего можно одному делать, B>>но вот именно такую систему лучше сразу делать в команде. B>>Тогда она будет ближе к жизни.
П>Пока команды, к сожалению, нет.
Как вариант, можно попытаться устроиться работать в компанию,
которая заинтересована в таких системах для своего собственного процесса.
Здравствуйте, Программер, Вы писали:
П>Здравствуйте, bkat, Вы писали:
B>>Много чего можно одному делать, B>>но вот именно такую систему лучше сразу делать в команде. B>>Тогда она будет ближе к жизни.
П>Пока команды, к сожалению, нет.
Давно уже испытываю нехватку действительно практичного инструмента, совмещающего следующие деятельности:
1) Управление требованиями;
2) Баг-трэкинг + автоматизация тестирования;
3) Планирование;
4) Контроль хода работ;
5) Версионный контроль;
6) Управление конфигурациями;
7) Анализ (регрессионный, корреляционный, кластерный, сравнительный) — т.н. "разбор полетов", без которого немыслимо обучение.
Для всех вышеперечисленных деятельностей требуются различные представления одних и тех же данных. Поэтому их обязательно необходимо интегрировать в одну систему — иначе ни о какой серьезной автоматизации не может быть и речи.
Инструмент должен быть практичным, чтобы его могли использовать все участники процесса разработки программного продукта. Соответственно должно использоваться несколько специализированных клиентских приложений, работающих с единой БД — отдельно для каждой должности внутри организации. При этом следует для каждого пользователя системы оставить возможность оперативного контроля, планирования, и управления требованиями в рамках его компетенций. Т.е. в процессе планирования и т.п. должны _активно_ принимать участие все члены команды, а не только манагер.
Виды деятельности определяются процессом. Процесс в свою очередь определяется в основном архитектурой. Архитектура в основном определяется доступными технологиями программирования. Требования определяют лишь допустимость той или иной архитектуры, т.к. разработка уникальной архитектуры исходя из требований — слишком дорогое и рискованное мероприятие. Соответственно, тулза должна быть рефлексивным отражением типичных процессов, определяемых хорошо изученными архитектурами.
Хотелось бы узнать Вашу концепцию. Если она не противоречит тому, что меня интересует, то я с удовольствием составлю Вам компанию в этом безумном начинании. Хотя, конечно, двоих да еще и на общественных началах может хватить разве что на составление ТЗ с очень низкой степенью детализации. Для чего-нибудь большего нужны серьезные деньги.
Здравствуйте, Dimonka, Вы писали:
D>Здравствуйте, hrg, Вы писали:
hrg>>RequisitePro, из минусов — дорогой.
D>А есть что-нибудь недорогое (идеально бесплатное) на небольшую команду? D>Чтобы можно было трэкинг изменений делать.
Здравствуйте, lextasy, Вы писали:
L>Хотелось бы узнать Вашу концепцию. Если она не противоречит тому, что меня интересует, то я с удовольствием составлю Вам компанию в этом безумном начинании. Хотя, конечно, двоих да еще и на общественных началах может хватить разве что на составление ТЗ с очень низкой степенью детализации. Для чего-нибудь большего нужны серьезные деньги.
Дело в том, что пока проект находится на начальной стадии (сборе этих самых требований). По моим идеям концепция похожа на то, что вы привели: сбор требований, планирование програмного продукта, планирование процесса разработки, контроль версий, багов и фиксов. Все это естественно будет в единой БД, а распределение по привилегиям — неотъемлемая часть большинства современных систем.
Здравствуйте, Программер, Вы писали:
П>Здравствуйте, господа девелоперы, админы, юзеры.
П>Собственно в ближайшее время буду писать ситему управления разработкой приложения, и собственно очень бы хотелось провести небольшое исследование.
П>...
DemAS -> "Re[4]: Как вы оформляете требования" :
kig>> Главный минус по сравнению с RPro — не трассабилити между kig>> требованиями.
D> Если коротко, что это такое ?
Как одно требование завист от другого. Задается матрицей связей.
Здравствуйте, bkat, Вы писали:
B>Как вариант, можно попытаться устроиться работать в компанию, B>которая заинтересована в таких системах для своего собственного процесса.
Здравствуйте, lextasy, Вы писали:
L>Здравствуйте, bkat, Вы писали:
B>>Как вариант, можно попытаться устроиться работать в компанию, B>>которая заинтересована в таких системах для своего собственного процесса.
L>Напимер?
Любая крупная контора, в которой вообще занимаются своим процессом.
Как признак может быть подоготовка конторы к сертификациям по всевозможным стандартам качества.
Сергей Орлик -> "Re[2]: Как вы оформляете требования" :
СО> Карл Вигерс "Разработка требований к программному обеспечению", СО> вторая редакция СО> MicrosoftPress Русская Редакция, 2004 СО> ISBN5-7502-0240-2
СО> На англ. уже вышла третья редакция этой книги.
Здравствуйте, Алексей, Вы писали:
L>Давно уже испытываю нехватку действительно практичного инструмента, совмещающего следующие деятельности:
L>1) Управление требованиями; L>2) Баг-трэкинг + автоматизация тестирования; L>3) Планирование; L>4) Контроль хода работ; L>5) Версионный контроль; L>6) Управление конфигурациями; L>7) Анализ (регрессионный, корреляционный, кластерный, сравнительный) — т.н. "разбор полетов", без которого немыслимо обучение.
L>...Соответственно должно использоваться несколько специализированных клиентских приложений, работающих с единой L>БД — отдельно для каждой должности внутри организации. При этом следует для каждого пользователя системы оставить L>возможность оперативного контроля, планирования, и управления требованиями в рамках его компетенций. Т.е. в L>процессе планирования и т.п. должны _активно_ принимать участие все члены команды, а не только манагер.
Если говорить о Borland — есть связка CaliberRM+StarTeam. При этом, если досточно управления требованиями на уровне их фиксирования и работы с ними в рамках общего workflow с запросами на изменения (Change Request/Bug Report) задачами (task — синхзронизируются с MS Project) и т.п. — можно обойтись только StarTeam.
Из того что Вы перечислили, эта связка обеспечивает следующее:
1) Управление требованиями;
2) Баг-трэкинг
+ автоматизация тестирования (интеграция с Mercury TestDirector); L>3) Планирование — есть встроенные tasks (+интеграция с MS Project); L>4) Контроль хода работ — с точки зрения Project Management см. п.3; если речь идет о "статусе" (например CR) — workflow с возможностью его "кастомизации"; L>5) Версионный контроль; L>6) Управление конфигурациями;
если нужны детали — готов ответить как здесь, так и по e-mail: sorlik@borland.ru
Здравствуйте, bkat, Вы писали:
B>Любая крупная контора, в которой вообще занимаются своим процессом. B>Как признак может быть подоготовка конторы к сертификациям по всевозможным стандартам качества.
Отсюда напрашивается вывод: все производители массово распространяемого ПО аналогичного предназначения — суть попросту "лохотронщики", т.к. собственный процесс можно автоматизировать только собственными силами.
Доказательство от противного (т.е. меня ):
Если бы это было не так, то нашлась бы по крайней мере одна крупная контора, использующая массово распространяемый продукт стороннего производства для покрытия львиной доли всех нужд автоматизации своего стандартного процесса.
Здравствуйте, Сергей Орлик, Вы писали:
СО>Здравствуйте, bralgin, Вы писали:
B>>советую вот эти книги: СО>[... skipped ...]
СО>Если говорить о первоисточниках Requirement Management как дисциплины (конечно, без привязки к продуктам), я бы очень рекомендовал:
СО>Карл Вигерс СО>"Разработка требований к программному обеспечению", вторая редакция СО>MicrosoftPress Русская Редакция, 2004 СО>ISBN5-7502-0240-2
СО>На англ. уже вышла третья редакция этой книги.
Как вариант -- для начала имеет смысл нучиться работать с юзкейсами, а потом можно варьировать -- где их использовать а где нет . Книгу Вигерса вполне можно читать, но после Леффингуэлла и Кберна IMHO.
Здравствуйте, Программер, Вы писали:
П>Здравствуйте, господа девелоперы, админы, юзеры.
П>Собственно в ближайшее время буду писать ситему управления разработкой приложения, и собственно очень бы хотелось провести небольшое исследование.
П>Вопрос таков: как вы офорляете требования?
П>1) Вы вообще занимаетесь этим? П>2) Что вы вносите в требование?
П>Заранее благодарен всем, кто откликнется. Если что, то можно писать и на мыло: intersys@yandex.ru.
В 80% бизнес-приложений я пишу юзкейсы -- и это мне здорово упрощает жизнь. Иногда просто списки в RequsuitePro a-la SRS, но это там где сценарии неявны или фреймворки.
Здравствуйте, lextasy, Вы писали:
L>Хотелось бы узнать Вашу концепцию. Если она не противоречит тому, что меня интересует, то я с удовольствием составлю Вам компанию в этом безумном начинании. Хотя, конечно, двоих да еще и на общественных началах может хватить разве что на составление ТЗ с очень низкой степенью детализации. Для чего-нибудь большего нужны серьезные деньги.
Если нужен будет делфист, то тоже присоединюсь....
):
. Книгу Вигерса вполне можно читать, но после Леффингуэлла и Кберна IMHO.
