Здравствуйте, Программер, Вы писали:
П>Здравствуйте, господа девелоперы, админы, юзеры.
П>Собственно в ближайшее время буду писать ситему управления разработкой приложения, и собственно очень бы хотелось провести небольшое исследование.
Ты один?
П>Вопрос таков: как вы офорляете требования?
В "ворде". Документы с требованиями помещаются в систему управления версиями.
Документы проходят 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
СО> На англ. уже вышла третья редакция этой книги.
