У нас небольшая команда (~10 программеров и еще немного электронщиков, разводчиков монтажников и т.д.). Все производимые нами продукты направлены на рынок телекоммуникаций. Под продуктами подразумеваются программно-аппаратные изделия (не чисто программные системы). Делаем все сами, проектируем, разводим платы и пишем софт. Работаем без всяких технологий, минимум документооборота, практически все на словах. Начали немного расширяться и сразу же начал расти "бардак" на фирме. Хотим поднять эффективность, а также как-то унифицировать процессы разработки. Мне поручено изучить имеющиеся решения и выбрать дальнейшую стратегию развития с последующим внедрением одного из решений.
На данный момент читаю книгу Якобсон, Буч, Рамбо "Унифицированный процесс разработки программного обеспечения". Честно говоря читается немного туговато. Кроме того, выбрали некий пилотный проект (многоуровневый стек протоколов), для которого реализовали один из подуровней, используя UML и Rhapsody 6.0. Выглядит довольно таки интересно и привлекательно. Особенно подкупает возможность анимирования работы системы.
Посоветуйте:
1. Нужно ли все на фирме перевернуть вверх дном (или наоборот ) и сразу всех заставить изучать этот самый унифицированный процесс? Или же возможен вариант постепенного, мягкого, поэтапного перехода?
2. Что знающие могут сказать по инструментарию Phapsody? Нам понравился тот факт, что генерится приемлимый код и можно в режиме анимации изучать поведение системы. А также нравится наглядное предстваление классов и интерфейсов взаимодействия.
3. На что в общем то нужно обратить внимание, на какие решения? Если учесть специфику нашего предприятия.
Благодарю за внимание!
Re: Нужны советы по внедрению унифицированного проц. разрабо
Здравствуйте, _SAV, Вы писали:
_SA>Посоветуйте: _SA>1. Нужно ли все на фирме перевернуть вверх дном (или наоборот ) и сразу всех заставить изучать этот самый унифицированный процесс? Или же возможен вариант постепенного, мягкого, поэтапного перехода?
_SA>3. На что в общем то нужно обратить внимание, на какие решения? Если учесть специфику нашего предприятия.
Нет, революции вам не нужны, вы же не в кризисе . Имеет смысл постепенно все внедрять. Можно подисциплинно. Часто начинают внедрять с Управления требовниями и Конфигурационного управления. Проектирование вещь более сложная, подходить к внедрению этой дисциплины нужно аккуратно, а то есть риск потом сказать что RUP это ерунда.
Следует обратить внимание, что RUP и UML ЭТО НЕ ОДНО И ТО ЖЕ! Нужно в первую очередь понять в чем корни имеющихся проблем и подбирать эффективные практики (из разных методологий, не обязательно только из RUP) для их решения. Пробовать, адаптировать и оценивать резульататы. Не нужно делать процесс ради процесса ...
Re: Нужны советы по внедрению унифицированного проц. разрабо
Здравствуйте, _SAV, Вы писали:
_SA>У нас небольшая команда (~10 программеров и еще немного электронщиков, разводчиков монтажников и т.д.). Все производимые нами продукты направлены на рынок телекоммуникаций. Под продуктами подразумеваются программно-аппаратные изделия (не чисто программные системы). Делаем все сами, проектируем, разводим платы и пишем софт. Работаем без всяких технологий, минимум документооборота, практически все на словах. Начали немного расширяться и сразу же начал расти "бардак" на фирме. Хотим поднять эффективность, а также как-то унифицировать процессы разработки. Мне поручено изучить имеющиеся решения и выбрать дальнейшую стратегию развития с последующим внедрением одного из решений.
_SA>На данный момент читаю книгу Якобсон, Буч, Рамбо "Унифицированный процесс разработки программного обеспечения". Честно говоря читается немного туговато. Кроме того, выбрали некий пилотный проект (многоуровневый стек протоколов), для которого реализовали один из подуровней, используя UML и Rhapsody 6.0. Выглядит довольно таки интересно и привлекательно. Особенно подкупает возможность анимирования работы системы.
_SA>Посоветуйте: _SA>1. Нужно ли все на фирме перевернуть вверх дном (или наоборот ) и сразу всех заставить изучать этот самый унифицированный процесс? Или же возможен вариант постепенного, мягкого, поэтапного перехода? _SA>2. Что знающие могут сказать по инструментарию Phapsody? Нам понравился тот факт, что генерится приемлимый код и можно в режиме анимации изучать поведение системы. А также нравится наглядное предстваление классов и интерфейсов взаимодействия. _SA>3. На что в общем то нужно обратить внимание, на какие решения? Если учесть специфику нашего предприятия.
_SA>Благодарю за внимание!
У нас подобная ситуация. То есть, мы занимаемся телекоммуникациями и программеров порядка 10-ти человек. В плане документооборота не знаю. Мы используем инструмент TAU SDL. Он реально помогает реализовывать сложные проекты. Причем мы использует полноценную генерацию кода. В принципе Рапсодия — прямая замена TAU SDL (кстати и тем и другим продуктом сейчас владеет Telelogic и говорят что делается ставка в будующем именно на Рапсодию), плюс функциональность намного шире TAU. Вопрос как Вы хотите использовать эти продукты. Для создания документов или же для генерации кода? И всех людей бросать на штурм таких продуктов не стоит. Для начало желательно одному из команды стать "гуру", чтобы потом остальным легче было влиться в процесс Для синхронизации кодов кстати очень помогает CVS.
П.С. Мое личное мнение SDL более удобен для реализации конечных автоматов, хотя это может быть вопрос привычки.
Re[2]: Нужны советы по внедрению унифицированного проц. разр
Здравствуйте, grg, Вы писали:
grg>У нас подобная ситуация. То есть, мы занимаемся телекоммуникациями и программеров порядка 10-ти человек. В плане документооборота не знаю. Мы используем инструмент TAU SDL. Он реально помогает реализовывать сложные проекты. Причем мы использует полноценную генерацию кода. В принципе Рапсодия — прямая замена TAU SDL (кстати и тем и другим продуктом сейчас владеет Telelogic и говорят что делается ставка в будующем именно на Рапсодию), плюс функциональность намного шире TAU. Вопрос как Вы хотите использовать эти продукты. Для создания документов или же для генерации кода? И всех людей бросать на штурм таких продуктов не стоит. Для начало желательно одному из команды стать "гуру", чтобы потом остальным легче было влиться в процесс Для синхронизации кодов кстати очень помогает CVS. grg>П.С. Мое личное мнение SDL более удобен для реализации конечных автоматов, хотя это может быть вопрос привычки.
В основном конечно же подкупает и привлекает генерация кода, да и диаграмы состояний и другие артефакты из Рапсодии довольно таки наглядны и читаемы даже не для программистов. Как-то слышал такое высказыывание, мол SDL придумали связисты для связистов, а UML программисты для программистов. Проблема в общем-то стоит не совсем в конкретном инструментарии, а в подходе к проэктированию вцелом.
CVS кстати тоже используем уже несколько лет. Кто из ребят сидит на винде, используют WinCVS оболочку — удобно.
Re: Нужны советы по внедрению унифицированного проц. разрабо
Здравствуйте, _SAV, Вы писали:
_SA>Посоветуйте: _SA>1. Нужно ли все на фирме перевернуть вверх дном (или наоборот ) и сразу всех заставить изучать этот самый унифицированный процесс?
Ни в коем случае. 1) Вы парализуете разработку, и 2) внедрение при таком подходе окончится провалом — 10 против 1.
Впрочем, можете попробовать.
_SA>Или же возможен вариант постепенного, мягкого, поэтапного перехода?
Хотите быстро? Есть вариант.
1) Возьмите на работу 1-2 человек, отработавших по RUP на должности не менее ведущего инженера (senior software developer) не менее 3 лет в составе групп не менее 4-6 человек, чтобы общий коллектив у них был не менее 10-20 человек. При найме отдавайте предпочтение специалистам, отработавшим в американских компаниях.
2) Сделайте этих людей руководителями групп.
3) Они сами наведут у вас в разработке порядок, так как к нему привыкли.
Общий совет — возьмите описание модели CMM, и начинайте внедрять процессы постепенно, в порядке возрастания уровней, RUP, как и любые процессы, ложатся на CMM, так как CMM это набор критериев зрелости процесса разработки, и от процесса не зависит. Также, надо иметь в виду, что RUP является по сути библиотекой шаблонов, из которых строится процесс. Вы можете и должны его кастомизировать под себя.
_SA>2. Что знающие могут сказать по инструментарию Phapsody? Нам понравился тот факт, что генерится приемлимый код и можно в режиме анимации изучать поведение системы. А также нравится наглядное предстваление классов и интерфейсов взаимодействия.
Я не сторонник инструментов UML, в особенности тех, которые генерируют код, так что ничего не скажу. Но это вообще отдельная дискуссия, к процессам разработки на прямую не относящаяся.
_SA>3. На что в общем то нужно обратить внимание, на какие решения? Если учесть специфику нашего предприятия.
1) Система контроля версий — SVN, CVS, или что вам нравится, главное чтоб не SourceSafe.
2) Средства unit-тестирования.
3) Автоматические ночные билды и unit-tests свежей версии репозитория.
4) Интегрированная система учета дефектов и задач (tasktracker) — рекомендую JIRA. Все активности должны проходить через нее.
5) Система проектной документации — выберите что вам подходит. Желательно генерировать документацию из кода, автоматически во время ночных билдов.
Это программа минимум.
Далее — еженедельные совещания о статусе работ, поставить процесс планирования и контроля выполнения планов разработки, контроля качества софта и тестирования, передать часть управляющих функций тим-лидам (назначить их).
Это, в принципе, тоже программа минимум, чтобы навести мало-мальский порядок и обеспечить контроль. И заметьте, ни слова про RUP и системы работы с диаграммами.
Re[2]: Нужны советы по внедрению унифицированного проц. разр
Здравствуйте, Gaperton, Вы писали:
G>Хотите быстро? Есть вариант. G>1) Возьмите на работу 1-2 человек, отработавших по RUP на должности не менее ведущего инженера (senior software developer) не менее 3 лет в составе групп не менее 4-6 человек, чтобы общий коллектив у них был не менее 10-20 человек. При найме отдавайте предпочтение специалистам, отработавшим в американских компаниях. G>2) Сделайте этих людей руководителями групп. G>3) Они сами наведут у вас в разработке порядок, так как к нему привыкли.
К сожалению этот вариант невозможен. Т.к. во-первых у нас (в нашем городе) специалистов такого класса просто нет. Да и для руководства такой вариант также неприемлем, т.к. эти специалисты дорого стоят.
G>Общий совет — возьмите описание модели CMM, и начинайте внедрять процессы постепенно, в порядке возрастания уровней, RUP, как и любые процессы, ложатся на CMM, так как CMM это набор критериев зрелости процесса разработки, и от процесса не зависит. Также, надо иметь в виду, что RUP является по сути библиотекой шаблонов, из которых строится процесс. Вы можете и должны его кастомизировать под себя.
Извините за невежество, а что такое СММ?
Re[2]: Нужны советы по внедрению унифицированного проц. разр
Здравствуйте, grg, Вы писали:
grg> Для синхронизации кодов кстати очень помогает CVS.
ИМХО
лучше все таки svn + tortouse именно эта сцепка проще в эксплуатации и привыкании.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[3]: Нужны советы по внедрению унифицированного проц. разр
CMM — это набор критериев, которые позволяют оценивать процесс разработки.
Например, CMM утверждает, что обязательно надо управлять требованиями.
Если вы это не делаете, то говорить о какой-то зрелости с точки зрения CMM вообще не приходится...
Re[3]: Нужны советы по внедрению унифицированного проц. разр
Здравствуйте, _SAV, Вы писали:
_SA>Да и для руководства такой вариант также неприемлем, т.к. эти специалисты дорого стоят.
Да, кстати...
Качество и поставленный процесс сами по себе дорого стоят.
Так что если руководство по быстренькому и дешево желает поиметь RUP,
то это вариант не пройдет...
) и сразу всех заставить изучать этот самый унифицированный процесс? Или же возможен вариант постепенного, мягкого, поэтапного перехода?
