Дано: Большое предприятие с сильно социалистическим прошлым, и сейчас остающееся государственным (ФГУП). Существует ИТ-подразделение (Управление Информационных Технологий и Связи), в составе которого находятся служба разработки и служба сопровождения. По большей части, все организовано на основе типовой структуры ИВЦ, существовавшей еще в начале 70-х. Разработка ПО регламентируется внутренними стандартами, основанными все на тех же ГОСТах на создание АСУ 80-х годов. Процесс разработки чрезвычайно формализован, но строгость формальностей компенсируется необязательностью их исполнения .
Я — руководитель низшего звена, впрочем, имеющий значительный авторитет у начальства и влияние на некоторые принимаемые решения.
Как я понимаю, предприятий, подобных тому, на котором я работаю, на просторах России осталось много. Кто-нибудь пытался внедрить новые методологии? RUP, например. Вообще, существуют ли подобные предприятия, где внедрен RUP? С чего посоветуете начать мне?
Здравствуйте, dfbag7, Вы писали:
D>Как я понимаю, предприятий, подобных тому, на котором я работаю, на просторах России осталось много. Кто-нибудь пытался внедрить новые методологии? RUP, например. ... С чего посоветуете начать мне?
Прежде всего подумать, отличается ли чем-нибудь RUP от процесса, регламентированного нашими ГОСТ, которые фактически создавались на основе модели Ройса старшего. Результаты анализа будут весьма неожиданными.
AL>Прежде всего подумать, отличается ли чем-нибудь RUP от процесса, регламентированного нашими ГОСТ, которые фактически создавались на основе модели Ройса старшего. Результаты анализа будут весьма неожиданными.
Ага. Очень неожиданными. Чтобы внедрить RUP на предприятии, который работал по ГОСТ
потребуется _полная_ перетряска всего подразделения IT — на что вряд ли пойдет руководство.
Процесс сопровождения ПО, который решается нормальным образом через ГОСТы, через RUP
вообще никак не выглядит. Также надо учесть, что на госпредприятиях чрезвычайно раздуты
штаты, а внедрение формализованного и ясного процесса потребует многих передвижек, увольнений.
Здравствуйте, dfbag7, Вы писали:
D>Дано: Большое предприятие с сильно социалистическим прошлым, и сейчас остающееся государственным (ФГУП). Существует ИТ-подразделение (Управление Информационных Технологий и Связи), в составе которого находятся служба разработки и служба сопровождения. По большей части, все организовано на основе типовой структуры ИВЦ, существовавшей еще в начале 70-х. Разработка ПО регламентируется внутренними стандартами, основанными все на тех же ГОСТах на создание АСУ 80-х годов. Процесс разработки чрезвычайно формализован, но строгость формальностей компенсируется необязательностью их исполнения . D>Я — руководитель низшего звена, впрочем, имеющий значительный авторитет у начальства и влияние на некоторые принимаемые решения. D>Как я понимаю, предприятий, подобных тому, на котором я работаю, на просторах России осталось много. Кто-нибудь пытался внедрить новые методологии? RUP, например. Вообще, существуют ли подобные предприятия, где внедрен RUP? С чего посоветуете начать мне?
Начни с простого, а от него будет проще перейти к сложному. вот http://nat.naumen.ru/new/Main
За подробной информацией — обращайся (там есть реквизиты) расскажу подробнее
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, dfbag7, Вы писали:
D>>Как я понимаю, предприятий, подобных тому, на котором я работаю, на просторах России осталось много. Кто-нибудь пытался внедрить новые методологии? RUP, например. ... С чего посоветуете начать мне?
AL>Прежде всего подумать, отличается ли чем-нибудь RUP от процесса, регламентированного нашими ГОСТ, которые фактически создавались на основе модели Ройса старшего. Результаты анализа будут весьма неожиданными.
Во-первых, давайте определимся о каком ГОСТ идет речь ... если о 19 и 34 сериях, то оличия имеются, если говорим о 12207 (суть ISO) то тут уже можно и подумать .
ГОСТ 19/34 по большому счету процесс описывает весьма общё, не детализируя роли и их работы. Акцент в большей степени на унифицированную документацию. Если 12207 оперирует терминами процессы ЖЦ, разделяя на основные и вспомогательные. То 19/34 -- нет. Например, где описывается конфигурационное управление в ГОСТах этих серий?
Здравствуйте, dfbag7, Вы писали:
D>Дано: Большое предприятие с сильно социалистическим прошлым, и сейчас остающееся государственным (ФГУП). Существует ИТ-подразделение (Управление Информационных Технологий и Связи), в составе которого находятся служба разработки и служба сопровождения. По большей части, все организовано на основе типовой структуры ИВЦ, существовавшей еще в начале 70-х. Разработка ПО регламентируется внутренними стандартами, основанными все на тех же ГОСТах на создание АСУ 80-х годов. Процесс разработки чрезвычайно формализован, но строгость формальностей компенсируется необязательностью их исполнения . D>Я — руководитель низшего звена, впрочем, имеющий значительный авторитет у начальства и влияние на некоторые принимаемые решения. D>Как я понимаю, предприятий, подобных тому, на котором я работаю, на просторах России осталось много. Кто-нибудь пытался внедрить новые методологии? RUP, например. Вообще, существуют ли подобные предприятия, где внедрен RUP? С ПОчего посоветуете начать мне?
1. Не корректно говорить о внедрении RUP как таковом. Можно говорить о tailoring RUPа. По большому счету, вы должны кастомизировать RUP под себя. Но при этом тоже нужно понимать, что выхолащивать его до только шаблонов документов не имеет смысла. В первую очередь начните с целей ... т.е. определите ПОЧЕМУ вы хотите изменить процессы в вашей организации, и что это даст ОРГАНИЗАЦИИ в первую очередь и вам лично ...
2. Имеет смысл опираясь на лучшие практики которые описаны в RUP подумать о рациональном зерне заложенном в них. Следует осторожно и постепенно вводить изменения в процессы и регламенты, особенно для организаций с "богатыми традициями" , четко понимая, какое value дает те или иные практики.
3. Итеративная модель ЖЦ ПО -- одна из основнопологающих практик RUP. Про это следует помнить, кастомизируя RUP.
4. Одна из самых важных дисциплин -- Управление требованиями. Не самая простая дисциплина, но очевидно, если требования качественны, то это дает определенную гарантию, что и ПО будет удовлетворять потребностям заинтересованных лиц. Рекомендовання RUP практика -- использование юзкейсов. Нужно быть очень аккуратным в применении юзкейсов, чтобы это было эффективно ... часто юзкейсы используются для описания движений по пользовательскому интерфейсу, хотя они отнюдь не для этого предназначены, что лишний раз подтвердил сам Jacobson, выступая на SECR 2005. Не стоит забывать, что это лишь рекоммендованная практика ... и не для всех систем юзкейсы будут useful. Говоря о требованиях к ПО как таковых, важным является понимание того, что требования сами по себе это не то же самое, что и документы требований (те же ТЗ). Что они должны быть "атомарны" ("разделяй и властвуй") и по отдельности ими легче урпавлять, чем целым документом. Важно то, КАК требования сформулированы. Как поставлен контроль ИЗМЕНЕНИЯ требований. Это все важные вопросы, которым следует уделять более пристальное внимание, чем используемым шаблонам документации требований.
5. Одна из самых "простых" дисциплин RUP -- это конфигурационное управление. Подумайте насчет управления запросами на изменения и версионном контроле, планировании релизов ПО. Обычно начинают именно с Управления требованиями и Конфигурационного управления.
Здравствуйте, byur, Вы писали:
D>>>Как я понимаю, предприятий, подобных тому, на котором я работаю, на просторах России осталось много. Кто-нибудь пытался внедрить новые методологии? RUP, например. ... С чего посоветуете начать мне?
AL>>Прежде всего подумать, отличается ли чем-нибудь RUP от процесса, регламентированного нашими ГОСТ, которые фактически создавались на основе модели Ройса старшего. Результаты анализа будут весьма неожиданными.
B>Во-первых, давайте определимся о каком ГОСТ идет речь ... если о 19 и 34 сериях, то оличия имеются, если говорим о 12207 (суть ISO) то тут уже можно и подумать . B>ГОСТ 19/34 по большому счету процесс описывает весьма общё, не детализируя роли и их работы. Акцент в большей степени на унифицированную документацию. Если 12207 оперирует терминами процессы ЖЦ, разделяя на основные и вспомогательные. То 19/34 -- нет. Например, где описывается конфигурационное управление в ГОСТах этих серий?
В исходном сообщении я имел ввиду ГОСТы на проектирование, разработку и документирование АСУ 80-х годов издания. Конкретные номера не помню, но точно знаю, что эти ГОСТы являются несколько обновленными вариантами еще более ранних (60-70х годов).
Что касается последних ГОСТов на разработку (12207 и др.) — они действительно являются переводом соответствующих стандартов ISO, и это уже совсем другая история. Стандарты ISO достаточно просто совмещаются с RUP — уже хотя бы потому, что и там, и там используется процессный подход.
В старых советских ГОСТах нет ни понятия "процесс", ни даже понятия "проект"; а переходы между этапами разработки настолько формализованы, что это фактически навязывает "водопадную" модель.
Здравствуйте, byur, Вы писали:
D>>Дано: Большое предприятие с сильно социалистическим прошлым, и сейчас остающееся государственным (ФГУП). D>>С чего посоветуете начать мне?
B>1. Не корректно говорить о внедрении RUP как таковом. Можно говорить о tailoring RUPа.
Совершенно очевидно, что глупо внедрять какой бы то ни было стандарт "как есть". Любой стандарт нужно "тайлорить", тем более, что RUP сам по себе определяет таку возможность. Действительно, мне следовало написать о внедрении методологии разработки, основанной на RUP.
B>2. Имеет смысл опираясь на лучшие практики которые описаны в RUP подумать о рациональном зерне заложенном в них. Следует осторожно и постепенно вводить изменения в процессы и регламенты, особенно для организаций с "богатыми традициями" , четко понимая, какое value дает те или иные практики.
Конечно, я все это прочитал. Потому и голова кругом идет — не знаю, за что хвататься.
B>3. Итеративная модель ЖЦ ПО -- одна из основнопологающих практик RUP. Про это следует помнить, кастомизируя RUP.
С этим я безусловно согласен. Более того — де-факто эта практика используется. Но без соответствующего документооборота эта практика только добавляет бардака.
B>4. Одна из самых важных дисциплин -- Управление требованиями.
Очевидно, в этом и состоит самая главная особенность RUP как стандарта.
B>5. Одна из самых "простых" дисциплин RUP -- это конфигурационное управление. Подумайте насчет управления запросами на изменения и версионном контроле, планировании релизов ПО. Обычно начинают именно с Управления требованиями и Конфигурационного управления.
На самом деле кое-что (очень мало) уже сделано. Например, внедрено использование системы контроля версий (вы будете смеяться, но еще два года назад ничего подобного не было). Начато использование bug-tracking системы. Есть планы перейти на человеческое планирование, внедрить unit testing и т.д. Так что, похоже, я выбрал правильную последовательность. Это радует.
B>>4. Одна из самых важных дисциплин -- Управление требованиями.
D>Очевидно, в этом и состоит самая главная особенность RUP как стандарта.
Позвольте немного подкорректировать ... RUP это методология, а не стандарт ... стандартом является тот же ISO 12207 ... но это так, из области "уже почти 2 часа ночи, но точным в формулировках таки хочется быть" .
Здравствуйте, Strix, Вы писали:
D>>С чего посоветуете начать мне?
S>Начни с простого, а от него будет проще перейти к сложному. вот http://nat.naumen.ru/new/Main S>За подробной информацией — обращайся (там есть реквизиты) расскажу подробнее
Большое спасибо! Очень интересный ресурс, огромное количество информации именно по тем вопросам, которые интересны мне. В частности, по подбору инструментария.
Если не секрет, сколько сколько человеко-часов было потрачено на составление этой документации, и сколько еще планируется потратить (сайт, как я понимаю, не закончен)?. Так или иначе, аналогичные исследования придется выполнить и у нас.
.
.