Здравствуйте, byur, Вы писали:
I>>Буча (или бутча) читал... Также кое что на эту тему читал. Но так толком и не понял как планировать время, как писать нормальное ТЗ, как увидеть все ньюансы будущего проекта
B>Нигде не пишут о том, как писать ТЗ. Про требования -- можно найти несколько книг на русскм. Это книга К. Вигерса, Д. Лефингвелла и А. Коберна ... Все ньюансы -- не увидишь ... все ньюансы -- это в модели дизайна или в исходном коде .
спасибо всем выступившим... НАсчет ТЗ разобрался, буду и правда рисовать листик с пожеланиями
А вот с управлением проектом... Тут хуже, все сразу расплылись вилами по воде И я стал отставать...
Можно ли проще?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, speedballer, Вы писали:
S>>Здравствуйте, Слава, Вы писали:
S>>Насчёт того, что в RUP много бумаги — это, собственно, либо заблуждение, либо следствие ошибок, допущенных при разработке и внедрении процесса. Есть основополагающие принципы, без которых RUP — не RUP. Но к этим принципам не относится, например, требование «документируйте каждый ваш чих».
А>О, раз пошли вопросы по RUP ... вот если на основе RUP делается свой процесс и он не use-case driven ... можно ли говорить что это RUP ?
Думаю, что нет, т.к. среди шести (кажется) принципов РУП есть:
— управление требованиями,
— моделирование на UML.
Отсюда, видимо, и UC автоматически вылазят.
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, ironwit, Вы писали:
I>спасибо всем выступившим... НАсчет ТЗ разобрался, буду и правда рисовать листик с пожеланиями I>А вот с управлением проектом... Тут хуже, все сразу расплылись вилами по воде И я стал отставать... I>Можно ли проще?
Если попытаться изучить RUP по официальной документации, то начинающему ИМХО расхочется разрабатывать IT-системы. Посоветовал бы купить книжку (тут выше что-то рекомендовали), в которой изначально проводится мысль, что всегда следует работать в рамках некоторого подмножества РУП (т.е. некоторого упрощенного варианта), но при этом следуя базовым принципам,декларируемым РУП. Все принципы не берусь точно воспроизвести, тем не менее, это: итерационность, управление на основе требований, модульная архитектура системы, использование моделирования (UML), сквозное тестирование, [забыл].
I>Чтобы посоветовали по этому поводу?
Имхо Лармана посмотреть стоит — весьма неплохо и компактно описывает rup-ообразный процесс. С управлением требованиями и прочим и прочим.
Здравствуйте, аноним, Вы писали:
> О, раз пошли вопросы по RUP ... вот если на основе RUP делается свой > процесс и он не use-case driven ... можно ли говорить что это RUP > ?
Это гипотетический вопрос, или вы считаете, что вам удалось разработать на основе RUP свой процесс, и этот процесс не use-case driven (и чем он тогда, с позволения сказать, driven)?
Теоретически, нигде не декларируется, что use case является основополагающим для RUP. Вот, например, цитата из RUP (имеется в виду продукт):
Our recommended (выделено мной — s.) method for organizing your functional requirements is using use cases.
С другой стороны:
The RUP employs a "use-case driven approach", which means that use cases defined for a system are the basis for the entire development process.
Там же приводится довольно длинный список тех ролей, которые играют юз-кейсы в различных дисциплинах и видах деятельности, подразумеваемых RUP как процессом. Из этого можно сделать вывод, что вряд ли удастся адаптировать RUP настолько, чтобы исключить из процесса use-case как таковые.
McSpace -> Re[4]: управление проектом начинающими
M> Спасибо за поддержку. А то я уж подумал, что в UML кем-то включено M> графическое представление упраления проектами и рисками...
:
При больщом желании там таки можно план-график построить
<!-- Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно
гармонист -->
byur -> Re: управление проектом начинающими
b> Ой, не надо за ТЗ ничего говорить . Попробуйте для начала просто b> сформулировать ТРЕБОВАНИЯ к вашей системе. Просто хотябы в виде b> списка "Система должна ...", нарисвать картинку "Ваша система и те с b> кем/чем она взаимодействует", и это будет более информативно, чем ТЗ b> . Да, создание ТЗ не относиться к управлению проектом по-большому b> счету.
Еще проще взять шаблон Vision из RUP и писать по нему
Здравствуйте, speedballer, Вы писали:
S>Здравствуйте, аноним, Вы писали:
>> О, раз пошли вопросы по RUP ... вот если на основе RUP делается свой >> процесс и он не use-case driven ... можно ли говорить что это RUP >> ?
S>Это гипотетический вопрос, или вы считаете, что вам удалось разработать на основе RUP свой процесс, и этот процесс не use-case driven (и чем он тогда, с позволения сказать, driven)?
можно утверждать, что существует класс систем, для которых разработка UC не очень эффективна. Это например разработка фреймворков, где упор на дизайн в большей степени. В этом случае требования описываются, например, в виде иерархических списков. Каркас процесса может быть взят из RUP (роли, работы,артефакты ..). Этими требованиями и будет этот процесс driven . Why not?
S>Теоретически, нигде не декларируется, что use case является основополагающим для RUP. Вот, например, цитата из RUP (имеется в виду продукт):
S>
S>Our recommended (выделено мной — s.) method for organizing your functional requirements is using use cases.
Кстати это появилось в нем недавно ... а до этого, кажись у Кратчена мелькало про spirit of RUP .. и use-case driven
Здравствуйте, hrg, Вы писали:
hrg>byur -> Re: управление проектом начинающими
b>> Ой, не надо за ТЗ ничего говорить . Попробуйте для начала просто b>> сформулировать ТРЕБОВАНИЯ к вашей системе. Просто хотябы в виде b>> списка "Система должна ...", нарисвать картинку "Ваша система и те с b>> кем/чем она взаимодействует", и это будет более информативно, чем ТЗ b>> . Да, создание ТЗ не относиться к управлению проектом по-большому b>> счету.
hrg>Еще проще взять шаблон Vision из RUP и писать по нему
Vision, это только часть ТЗ. ТЗ это Vision + UC spec./SRS + Supplementary Spec + Test Plan (Как методика испытаний ). Например в Vision пишутся features, а это еще не требования.
Здравствуйте, byur, Вы писали:
b> можно утверждать, что существует класс систем, для которых разработка b> UC не очень эффективна. Это например разработка фреймворков, где упор b> на дизайн в большей степени. В этом случае требования описываются, b> например, в виде иерархических списков. Каркас процесса может быть b> взят из RUP (роли, работы,артефакты ..). Этими требованиями и будет b> этот процесс driven . Why not?
У меня нет совершенно никакого опыта разработки framework'ов, поэтому ни соглашаться, ни возражать не стану.
S>>
S>>Our recommended (выделено мной — s.) method for
S>>organizing your functional requirements is using use cases.
b> Кстати это появилось в нем недавно ... а до этого, кажись у b> Кратчена мелькало про spirit of RUP .. и use-case driven
Кстати, это было ещё в самом первом RUP — 1998-го года издания.
Здравствуйте, byur, Вы писали:
hrg>>Еще проще взять шаблон Vision из RUP и писать по нему
b> Vision, это только часть ТЗ. ТЗ это Vision + UC spec./SRS + b> Supplementary Spec + Test Plan (Как методика испытаний ). Например b> в Vision пишутся features, а это еще не требования.
Давайте избегать термина ТЗ, говоря о RUP, — по той простой причине, что RUP не имеет ни малейшего понятия о том, что такое ТЗ, а ГОСТ 34.602-89 не имеет ни малейшего понятия о том, что такое RUP.
Здравствуйте, speedballer, Вы писали:
b>> Кстати это появилось в нем недавно ... а до этого, кажись у b>> Кратчена мелькало про spirit of RUP .. и use-case driven
S>Кстати, это было ещё в самом первом RUP — 1998-го года издания.
Под "это", я подразумевал изменение тона с категоричного "use-case driven", на дипломатичное "recommended" ... это они вроде как после торжества XP ввели.
Здравствуйте, speedballer, Вы писали:
S>Здравствуйте, byur, Вы писали:
hrg>>>Еще проще взять шаблон Vision из RUP и писать по нему
b>> Vision, это только часть ТЗ. ТЗ это Vision + UC spec./SRS + b>> Supplementary Spec + Test Plan (Как методика испытаний ). Например b>> в Vision пишутся features, а это еще не требования.
S>Давайте избегать термина ТЗ, говоря о RUP, — по той простой причине, что RUP не имеет ни малейшего понятия о том, что такое ТЗ, а ГОСТ 34.602-89 не имеет ни малейшего понятия о том, что такое RUP.
Оно то конечно да, но ... в наших условиях они живут бок о бок, и AFAIU именно об этом хотел сказать автор, говоря о Vision ... пример: http://www.cmcons.com/gost_34_19.htm.
Вздорная статейка. Никогда, ни при каких условиях RUP не может соответствовать требованиям ГОСТ 34.601-90, и не может быть никакого соответствия между фазами RUP и стадиями указанного ГОСТ (разве только в воспалённом воображении авторов указанной статьи, по всей видимости, слышавших о RUP от знакомых в курилке) — по той простой причине, что первый подразумевает итеративный процесс, а второй — каскадный.
Здравствуйте, speedballer, Вы писали:
S>Здравствуйте, byur, Вы писали:
b>> пример: http://www.cmcons.com/gost_34_19.htm.
S>Вздорная статейка. Никогда, ни при каких условиях RUP не может соответствовать требованиям ГОСТ 34.601-90, и не может быть никакого соответствия между фазами RUP и стадиями указанного ГОСТ (разве только в воспалённом воображении авторов указанной статьи, по всей видимости, слышавших о RUP от знакомых в курилке) — по той простой причине, что первый подразумевает итеративный процесс, а второй — каскадный.
Я спрашивал об этом г. Позина, он согласился с тем, что сравнивать ПРОЦЕССЫ, которые регламентированы RUP и ГОСТ абсурд из-за их разной природы... и сказал, что они как раз ориентировались на то, что у некой конторы был процесс на базе RUP, итеративный, как они утверждают. Но заказчик требует ТЗ по ГОСТ ... отсюда и родилась эта статья. На почему они стали показывать переделанную картинку RUP о фазах и впихнули названия о стадиях -- я не понимаю ...
Здравствуйте, byur, Вы писали:
S>>Советую использовать RUP — очень настраиваемая вещь, есть хорошие книги, которые помогут понять и настроить процесс для конкретной работы. Главное не зарыться в бумажной работе, а чувствовать грань между анархией и рутиной. Наличие документации по проекту значительно облегчает разработку больших проектов, их дальнейшее сопровождение, способствует хорошей устойчивости к потерям в команде.
B>Насчет хороших книг по RUP -- не так уж их и много .
Да, их не много, но их качество (первоисточника, перевод иногда совсем убитый) очень высоко для тех, кто только начинает свое движение в этом направлении.
S>>ХР мне лично не нравится большой свободой членов команды и трудностью соблюдения принципов ХР. В результате через некоторое время команда постепенно начинает переходить к анархии. На небольшой команде может очень сильно чувствоваться потеря одного из игроков команды.
B>XP декларирует в т.ч. коллективное владение кодом ... и если использовать парное программирование, то потеря одного не должна приводить к катастрофам.
Такую схему я описывал в применении к RUP и считаю ее лучше, чем использование ХР.
... << RSDN@Home 1.1.4 beta 4 rev. 309>>
Re[8]: управление проектом начинающими :)
От:
Аноним
Дата:
10.02.05 15:48
Оценка:
B>Я спрашивал об этом г. Позина, он согласился с тем, что сравнивать ПРОЦЕССЫ, которые регламентированы RUP и ГОСТ абсурд из-за их разной природы... и сказал, что они как раз ориентировались на то, что у некой конторы был процесс на базе RUP, итеративный, как они утверждают. Но заказчик требует ТЗ по ГОСТ ... отсюда и родилась эта статья. На почему они стали показывать переделанную картинку RUP о фазах и впихнули названия о стадиях -- я не понимаю ...
У меня такое ощущение, что вы неправильно поняли ответ Позина
Жизненный цикл по РУП и по ГОСТ — это РАЗНЫЕ жизненные циклы
В статье и в ответе было сказано лишь про то, что работать можно по РУП, а ДОКУМЕНТАЦИЮ ВЫПУСКАТЬ В ФОРМАТЕ ГОСТ...
Оцените разницу!!!
Заказчику по барабану как мы работаем, он хочет видеть результат, а план работ и описание в привычном формате — формате гост.
Здравствуйте, ironwit, Вы писали:
I>Ситауция такова. I>Небольшой город, хочется расти над собой, но нужен опыт работы над проектом. I>Задача\проект придуманы. 3 человека собраны I>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>Чтобы посоветовали по этому поводу? I>Типа пример ТЗ, как 3 человекам контролировать процесс разработки... I>В общем поклоняюсь гуру.
Если вы начинаете новый проект или поддерживаете уже существующий, статья содержит практические советы о том, как сделать ваш проект узнаваемым, как мотивировать остальных присоединиться к вашему проекту, и как сделать так, чтобы ваш проект оставался долгожителем и активным на долгое время. Распланируйте свой opensource проект.
Здравствуйте, ironwit, Вы писали:
I>Ситауция такова. I>Небольшой город, хочется расти над собой, но нужен опыт работы над проектом. I>Задача\проект придуманы. 3 человека собраны I>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>Чтобы посоветовали по этому поводу? I>Типа пример ТЗ, как 3 человекам контролировать процесс разработки... I>В общем поклоняюсь гуру.
По поводу написания сопутствующей проекту документации — логичнее использовать RUP.
Но RUP никакого отношения не имеет к управлению проектами.
Чтобы составить план трудозатрат проекта, оценить риски и спланировать бюджет существуют
специальные дисциплины и стандарты — например PMI.
Рекомендую к прочтению книгу:
Управление проектами: стандарты, методы, опыт.
2-е изд.
Авторы: Товб А. С., Ципес Г. Л.
М.: ЗАО «Олимп—Бизнес», 2005. — 240 с.: ил. ISBN 5-9693-0039-1
Автор(ы): Алистер Коберн
Тут хуже, все сразу расплылись вилами по воде 
?
