Здравствуйте, LaFlour, Вы писали:
LF>Здравствуйте, <Аноним>, Вы писали:
А>>Какие методологии разработки ПО существуют? А>>И где можно найти сравнительную характеристику?
LF>1) waterflow LF>2) циклическая(RUP).. LF>ну XP еще
waterflow, циклическая модель, различные инкрементные модели — это модели жизненного цикла
процесса разработки программ.
Автора интересуют методологии.
Осталось узнать, что он под этим понимает.
Вопрос автору
ООП — это одна из методологий в твоем понимании или нет?
Здравствуйте, Аноним, Вы писали:
А>Какие методологии разработки ПО существуют? А>И где можно найти сравнительную характеристику?
А>Спасибо!
Если основные типы (популярнейшие нотации) то:
1)структурная (DFD, SADT, ERD)
2)ООриентированная (UML)
Модели жизненных циклов с методологией связаны, но естественно ими не являются.
Что касается информации — надо спросить LaptevVV — он знаток книжек вообще и по проектированию и всяким разным методологиям в частности.
Здравствуйте, Morgun, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Какие методологии разработки ПО существуют? А>>И где можно найти сравнительную характеристику?
M>Если основные типы (популярнейшие нотации) то: M>1)структурная (DFD, SADT, ERD) M>2)ООриентированная (UML)
[offtopic] Нда. Лаптеву позор. Перечисленные вещи являются только нотациями и к методологиям непосредственного отношения не имеют.
Методология говорит, как правильно (в том или ином смысле) построить процесс разработки, чтобы достичь наилучшего (опять же в некотором субъективном смысле) результата. Ни одна из широко известных методологий не навязывает какую-либо натацию, как единственно правильную. Максимум — рекомендует использовать ту или иную нотация. Но не запрещает подменить ее аналогичной, возможно, даже своей разработки.
M>Модели жизненных циклов с методологией связаны, но естественно ими не являются.
Это ты к чему? "SDL не является языком для моделирования схем БД, но все же очень неплохой язык" — очень полезное высказывание, неправда ли?
M>Что касается информации — надо спросить LaptevVV — он знаток книжек вообще и по проектированию и всяким разным методологиям в частности.
Круто послал!
P.s. извини, что немного жестко, но сам спровацировал.
Здравствуйте, Morgun, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Какие методологии разработки ПО существуют? А>>И где можно найти сравнительную характеристику?
M>Если основные типы (популярнейшие нотации) то: M>1)структурная (DFD, SADT, ERD) M>2)ООриентированная (UML)
[offtopic] Нда. Лаптеву позор. Перечисленные вещи являются только нотациями и к методологиям непосредственного отношения не имеют.
Методология говорит, как правильно (в том или ином смысле) построить процесс разработки, чтобы достичь наилучшего (опять же в некотором субъективном смысле) результата. Ни одна из широко известных методологий не навязывает какую-либо натацию, как единственно правильную. Максимум — рекомендует использовать ту или иную нотация. Но не запрещает подменить ее аналогичной, возможно, даже своей разработки.
M>Модели жизненных циклов с методологией связаны, но естественно ими не являются.
Это ты к чему? "SDL не является языком для моделирования схем БД, но все же очень неплохой язык" — очень полезное высказывание, неправда ли?
M>Что касается информации — надо спросить LaptevVV — он знаток книжек вообще и по проектированию и всяким разным методологиям в частности.
Круто послал!
P.s. извини, что немного жестко, но сам спровацировал.
Здравствуйте, mikkri, Вы писали:
M>Здравствуйте, Morgun, Вы писали:
M>>Здравствуйте, Аноним, Вы писали:
А>>>Какие методологии разработки ПО существуют? А>>>И где можно найти сравнительную характеристику?
M>>Если основные типы (популярнейшие нотации) то: M>>1)структурная (DFD, SADT, ERD) M>>2)ООриентированная (UML)
M>[offtopic] Нда. Лаптеву позор. Перечисленные вещи являются только нотациями и к методологиям непосредственного отношения не имеют.
Лаптева не примешивай. Он за меня не в ответе.
M>Методология говорит, как правильно (в том или ином смысле) построить процесс разработки, чтобы достичь наилучшего (опять же в некотором субъективном смысле) результата. Ни одна из широко известных методологий не навязывает какую-либо натацию, как единственно правильную. Максимум — рекомендует использовать ту или иную нотация. Но не запрещает подменить ее аналогичной, возможно, даже своей разработки.
Зря ты так — Объектно ориентированной нотации нет — есть объектно-ориентированная методология разработки по (есть структурная). В скобках у меня нотации — это так. Ну так это наверху у меня и написано.
Могу сказать что "процесс разработки" (RUP например) — часть методологии. Нотации — тоже некоторые тоже частью считают, не все конечно. Но по крайней мере — за нотацией всегда стоит методология.
M>>Модели жизненных циклов с методологией связаны, но естественно ими не являются.
M>Это ты к чему? "SDL не является языком для моделирования схем БД, но все же очень неплохой язык" — очень полезное высказывание, неправда ли?
Непонял, что ты имел ввиду цитатой. Хотел сказать что модель жизненного цикла — напрямую к методологии не относятся. Но в RUPе например ориентируются на циклическую модель жизненного цикла.
M>P.s. извини, что немного жестко, но сам спровацировал.
Да ничего. Но все-таки будь поосторожней, оценивая знания людей по высказыванием их учеников. И повнимательней читай сообщения. Я на самом деле не совсем глупый.
Здравствуйте, Morgun, Вы писали:
M>Здравствуйте, mikkri, Вы писали:
M>>Здравствуйте, Morgun, Вы писали:
M>>>Здравствуйте, Аноним, Вы писали:
А>>>>Какие методологии разработки ПО существуют? А>>>>И где можно найти сравнительную характеристику?
M>>>Если основные типы (популярнейшие нотации) то: M>>>1)структурная (DFD, SADT, ERD) M>>>2)ООриентированная (UML)
M>Зря ты так — Объектно ориентированной нотации нет — есть объектно-ориентированная методология разработки по (есть структурная). В скобках у меня нотации — это так. Ну так это наверху у меня и написано.
ОО — это не методология, а подход, ну или в крайнем случае идеология.
Т.е. ОО и структурный — два широко известных подхода к разработке ПО. Причем они не имеют ничего общего ни с методологие, не с нотациями, ни с жизненным циклом ПО.
Путаться в терминологии — плохо .
M>Могу сказать что "процесс разработки" (RUP например) — часть методологии. Нотации — тоже некоторые тоже частью считают, не все конечно. Но по крайней мере — за нотацией всегда стоит методология.
M>>>Модели жизненных циклов с методологией связаны, но естественно ими не являются.
Верно. В качестве примера, можно привести MSF и MOF. Первая — подобие методологии, вторая — рекомендации по определению жизненного цикла ПО (и т.п.).
M>>Это ты к чему? "SDL не является языком для моделирования схем БД, но все же очень неплохой язык" — очень полезное высказывание, неправда ли?
M>Непонял, что ты имел ввиду цитатой. Хотел сказать что модель жизненного цикла — напрямую к методологии не относятся. Но в RUPе например ориентируются на циклическую модель жизненного цикла.
В RUP ориентируются на циклическую модель разработки ПО, а не на циклическую модель жизни ПО. Извини, но это разные вещи.
В текущий момент практически все применяемые методологии ориентируются на циклическую модель разработки (в частности, MSF, RUP, XP).
Здравствуйте, mikkri, Вы писали:
M>ОО — это не методология, а подход, ну или в крайнем случае идеология. M>Т.е. ОО и структурный — два широко известных подхода к разработке ПО. Причем они не имеют ничего общего ни с методологие, не с нотациями, ни с жизненным циклом ПО. M>Путаться в терминологии — плохо . M>В RUP ориентируются на циклическую модель разработки ПО, а не на циклическую модель жизни ПО. Извини, но это разные вещи. M>В текущий момент практически все применяемые методологии ориентируются на циклическую модель разработки (в частности, MSF, RUP, XP).
Извини — терминология, правда не мой конек, иногда я подменяю слова. Я хотел помочь человеку — дать направление поиска, (с чем это связано), к кому обратиться.
Если решил бы посоревноваться кто правее — заглянул бы в справочники.
Здравствуйте, Аноним, Вы писали:
А>Какие методологии разработки ПО существуют? А>И где можно найти сравнительную характеристику?
А>Спасибо!
Несколько мыслей к сравнительной характеристике Методологий. Так, навеяло.
Цитата из Джоела о Методологиях. http://russian.joelonsoftware.com/Articles/BigMacsvs.TheNakedChef.html
"В чем мораль этой истории? Опасайся Методик. Они представляют собой отличный способ привести всех к жалкому, но удовлетворительному, уровню выполнения, но в то же время они раздражают более талантливых людей, которым досаждают ограничения, наложенные на них. Мне очевидно, что талантливый повар не будет счастлив, делая бургеры в Макдональдсе, именно из-за правил. Так почему же консультанты по ИТ так много восхваляют свои Методики (Никак не пойму)."
Цитата из речи PSP/TSP тренера (об основах Методологии PSP):
"сначала вы должны оформить требования, потом делать дизайн, после этого закодировать, только после этого скомпилировать, и только потом приступить к тестированию. ПО ДРУГОМУ — НЕЛЬЗЯ!". Смешной он все-таки парень этот тренер. Прям "Детства моего чистые глазенки". Уговорил. После долгих дискуссий решили не тестировать наш софт до компиляции, и, — ни в коем случае! — до кодирования. А то что же это такое получится?! Бардак ведь, бардак!
Приблизительная цитата из ДеМарко — Листера "Peopleware" (о проблемах Методологий. Они, как и Джоел, делают разницу между методологией и Методологией; СMM — это пример big "M" methodology):
"В целом, идеи и цели, декларируемые Методологиями хороши и правильны. Но вот способы их достижения, предлагаемые Методологиями — нет. Ну, или почти всегда нет."
А вот в PSP/TSP даже девиз смешной: "Quality for free". Так и хочется добавить "Money for nothing". А какие у них методы достижения, о! — это надо, обязательно надо попробовать на себе.
Подчас поражаешься упорству автора Методологий. Вот например в статье с бестолковым названием "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения" размещенной на этом сайте автор совершенно правильно заметил (о проблемах внедрения Методологий):
"Проблема 1. Людям, занятым в проекте, совершенно неинтересно изучать нашу систему.
Проблема 2. Они вполне могут обойтись и без нас, и при этом успешно создавать программное обеспечение."
Самое смешное, что, как он пишет, он ТРИЖДЫ сталкивался с этой проблемой , и это его не остановило от написания вышеозначеной статьи (№4). Тяжелый случай.
Здравствуйте, Gaperton, Вы писали:
G>Приблизительная цитата из ДеМарко — Листера "Peopleware" (о проблемах Методологий. Они, как и Джоел, делают разницу между методологией и Методологией; СMM — это пример big "M" methodology): G>"В целом, идеи и цели, декларируемые Методологиями хороши и правильны. Но вот способы их достижения, предлагаемые Методологиями — нет. Ну, или почти всегда нет."
Как человек, немного разбирающийся в SW СMM позволю себе поправить
SW СMM от SEI не говорит ни слова о том, как цели должны достигаться.
Т.е. в СMM нет описания того, КАК надо делать.
Она ставит именно цели, про которые ты кстати говоришь, что они "хороши и правильны".
Как достичь целей — это проблема каждой конкретной конторы.
Кстати, отрицая методологии ты отрицаешь саму проблему.
Ведь ты же не споришь, что есть огромная проблема, как организовать
производство качественного софта большой группой программеров.
Известные методологии — это то, что смогли придумать на текущий момент времени.
У тебя есть нечто другое, которое действительно работает?
Если да, то не скрывай это от нас
PS И не надо путать типографии, с работой художника.
Нужны и те и те...
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
G>>Приблизительная цитата из ДеМарко — Листера "Peopleware" (о проблемах Методологий. Они, как и Джоел, делают разницу между методологией и Методологией; СMM — это пример big "M" methodology): G>>"В целом, идеи и цели, декларируемые Методологиями хороши и правильны. Но вот способы их достижения, предлагаемые Методологиями — нет. Ну, или почти всегда нет."
B>Как человек, немного разбирающийся в SW СMM позволю себе поправить B>SW СMM от SEI не говорит ни слова о том, как цели должны достигаться. B>Т.е. в СMM нет описания того, КАК надо делать. B>Она ставит именно цели, про которые ты кстати говоришь, что они "хороши и правильны". B>Как достичь целей — это проблема каждой конкретной конторы.
Ок, то есть предполагается что я защищаю и представляю точку зрения ДеМарко. Ладно.
Чтобы с ней спорить, я предлагаю тебе для начала ознакомиться с их книгой, где подробно изложена их критика CMM.
Если вкратце, то основное положение CMM о снижении уровня риска разработки по мере продвижения вверх по уровням
представляется ДеМарко и Листеру очень спорным.
B>Кстати, отрицая методологии ты отрицаешь саму проблему.
Кстати, я не отрицаю методологии. Я вообще ничего не отрицаю , я привел пару цитат весьма уважаемых в индустрии людей. Кроме того, эти люди делают разницу между методологией и Методологией. Разница, может, и слишком тонка для человеческого слуха но она есть, и эти понятия смешивать не стоит
B>Ведь ты же не споришь, что есть огромная проблема, как организовать B>производство качественного софта большой группой программеров. B>Известные методологии — это то, что смогли придумать на текущий момент времени.
Не спорю, что есть проблема. Но мне кажется (и я не одинок в этом убеждении), что известные Методологии это не самое лучшее, что смогли придумать на этот момент времени для ее решения.
B>У тебя есть нечто другое, которое действительно работает? B>Если да, то не скрывай это от нас
Ну что вы, как можно Вот, например, очень свежая идея:
"Они вполне могут обойтись и без нас, и при этом успешно создавать программное обеспечение."
B>PS И не надо путать типографии, с работой художника. B>Нужны и те и те...
Да? Может, "типографы" и нужны кому-то (но не мне). Только почему-то никто не горит желанием променять работу художника на работу типографа. А те, кому все равно, — так их дешевле вообще на работу не брать, чем снабжать подробными методологическими инструкциями. Иначе выдет все как описано у Джоела.
Cтатья Джоела действительно интересна.
Но пользуясь аналогией с ресторанами и поварами
он, на мой взгляд, уводит от проблемы.
Нет в индустрии ПО проблемы растиражировать результат
труда "программиста-художника" (назовем его так).
Есть проблема, как эффективно работать большой группе программистов.
В ресторанном бизнесе проблема звучала бы примерно следующим образом.
Как организовать пару сотен поваров, чтобы сделать ОДНО очень
навороченное и очень сложное блюдо?
Так что аналогия Джоела не очень по делу.
Немного в сторону.
Как-то читал, как делаются европейские аэробусы (airbus).
Вовлечены в это дело многие тысячи спецов с разных стран.
В разных странах проектируют и делают разные части самолета.
Потом разные части свозятся на сборочные заводы в Германии
и все это дело очень неплохо стыкуется и потом самолеты от airbus летают
и уже бьют боинги.
Вот туда надо смотреть и с ними сравнивать, а не с макдональдсами.
Здравствуйте, bkat, Вы писали:
B>Cтатья Джоела действительно интересна. B>Но пользуясь аналогией с ресторанами и поварами B>он, на мой взгляд, уводит от проблемы.
B>Нет в индустрии ПО проблемы растиражировать результат B>труда "программиста-художника" (назовем его так).
Верно. Согласен.
B>Есть проблема, как эффективно работать большой группе программистов. B>В ресторанном бизнесе проблема звучала бы примерно следующим образом. B>
B>Как организовать пару сотен поваров, чтобы сделать ОДНО очень
B>навороченное и очень сложное блюдо?
B>Так что аналогия Джоела не очень по делу.
Хорошее наблюдение, я не обратил на этот момент внимания. Но после некоторых
раздумий мне кажется, что не все так плохо.
По сути, что делает Джоел: он "на яблоках" доказывает тезис о вреде инструкций
для человека творческой специальности вообще (пока аналогия с софтом не требуется).
А потом этот тезис переносится на софтверную индустрию как на частный случай.
При этом его обоснование не является прямой (структурной) аналогией с производством софта,
но это вроде как и не требуется при его схеме (хотя, конечно, было бы желательно).
Я думаю, Джоел сознательно выбрал этот вариант, т.к. здесь нет проблем с доказательством его тезиса,
он очевиден. На примере софта все не так наглядно.
B>Немного в сторону. B>Как-то читал, как делаются европейские аэробусы (airbus). B>Вовлечены в это дело многие тысячи спецов с разных стран. B>В разных странах проектируют и делают разные части самолета. B>Потом разные части свозятся на сборочные заводы в Германии B>и все это дело очень неплохо стыкуется и потом самолеты от airbus летают B>и уже бьют боинги.
B>Вот туда надо смотреть и с ними сравнивать, а не с макдональдсами.
А вот с этим как-раз и нельзя сравнивать. Дело вот в чем.
Когда детали стыкуются и самолет сразу летит, подробные спецификации на детали уже готовы,
технология их производства уже отлажена, испытания опытных образцов самолетов уже прошли.
В программировании прямой аналогией такого процесса является... компиляция (изготовление "деталей" .obj
по "чертежам/спецификациям" в виде исходников), и сборка ("изготовление" .exe из готовых "деталей"). И
с этим у нас вообще проблем никаких, как вы понимаете.
Написание программного комплекса больше напоминает изобретение новой модели пассажирского самолета. Он же не сразу взял и полетел. Инженеры думают, делают прототипы деталей, испытывают их, собирают прототип сомолета, продувают его в трубах, занимаются компьютерным моделированием, делают опытные образцы, "отлаживают" их, направляя заказы на доработку деталей заводам производителям, и т.д. Бардак тот еще.
Но им проще. У них интерфейсы между деталями более стандартны, детали от разных самолетов очень похожи по принципиальному устройству, количество возможных видов деталей и их функционал известны заранее (двигатель он и есть
двигатель, известно что он делает и как). И главное, компоненты слабо связанны друг с другом. Например, известно, что к двигателю надо подвести крепление, трубу с топливом, и управление. В програмных же комплексах интерфейсы между компонентами на порядок сложнее, предполагают сложные сценарии взаимодействия со множеством состояний. Это затрудняет разделение задач и разработку, так как такие непростые интерфейсы приходится разрабатывать заново каждый раз, определяя их функционал. А с двигателями все стандартно.
Плюс ко всему, современные программные комплексы превосходят по количеству деталей самолеты. Современный софт — это самые сложные инженерные системы за всю историю человечества. Известно, например, что операционная система OS/360 превосходит по инженерной сложности ракету "Сатурн" с "Аполлоном" и лунным модулем вместе взятыми.
Так что, это они должны удивлятся почему у нас хоть что-то работает
Re[3]: Облажался - исправляюсь.
От:
Аноним
Дата:
07.10.03 22:22
Оценка:
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
G>>Приблизительная цитата из ДеМарко — Листера "Peopleware" (о проблемах Методологий. Они, как и Джоел, делают разницу между методологией и Методологией; СMM — это пример big "M" methodology): G>>"В целом, идеи и цели, декларируемые Методологиями хороши и правильны. Но вот способы их достижения, предлагаемые Методологиями — нет. Ну, или почти всегда нет."
B>Как человек, немного разбирающийся в SW СMM позволю себе поправить B>SW СMM от SEI не говорит ни слова о том, как цели должны достигаться. B>Т.е. в СMM нет описания того, КАК надо делать. B>Она ставит именно цели, про которые ты кстати говоришь, что они "хороши и правильны". B>Как достичь целей — это проблема каждой конкретной конторы.
Да... Все верно. Понимаю, что верно, поэтому и заглянул в книгу сам — цитата ОЧЕНЬ приблизительная. Я бы даже сказал, это уже не ДеМарко.
Облажался, есть такое дело. У них там две главы было, одна про CMM и process improvement programs, а другая про Методологии (она была написана до появления CMM), и все смешалось в моей памяти. На самом деле вот как:
"Парадокс CMM состоит в том, что само по себе улучшение процесса это хорошо, а программы улучшения процесса плохи, по крайней мере чаще всего."
Они критикуют в первую очередь не сам СММ (он не является Методологией), а программы по его достижению (они являются Методологиями).
СММ подвергается критике за тезис о снижении риска при повышении уровня.
Здравствуйте, Аноним, Вы писали:
А>Они критикуют в первую очередь не сам СММ (он не является Методологией), а программы по его достижению (они являются Методологиями).
Я тоже не в восторге от того, как СММ насаждается.
Сам был непосредственным участником такого процесса внедрения СММ.
Меня лично раздирают противоречие между пониманием того, что цели,
декларируемые тем же СММ вроде верны и очень даже по делу,
а вот методы достижения целей могут запросто похоронить благие намерения.
Так что согласен, что не все так просто, как могут заявлять компании,
помогающие достичь определенный уровень по CMM.
Здравствуйте, bkat, Вы писали:
B>Я тоже не в восторге от того, как СММ насаждается. B>Сам был непосредственным участником такого процесса внедрения СММ. B>Меня лично раздирают противоречие между пониманием того, что цели, B>декларируемые тем же СММ вроде верны и очень даже по делу, B>а вот методы достижения целей могут запросто похоронить благие намерения. B>Так что согласен, что не все так просто, как могут заявлять компании, B>помогающие достичь определенный уровень по CMM.
Кстати, а не мог бы ты поделиться своей историей о внедрении CMM? Чертовски интересно.
Здравствуйте, Gaperton, Вы писали:
G>Кстати, а не мог бы ты поделиться своей историей о внедрении CMM? Чертовски интересно.
Если очень кратко, не называя паролей и явок , то получится примерно следующее.
Дело происходило в одной российской фирме, довольно успешно работающей на одну очень крупную
западную фирму.
Поскольку сама западная фирма имела некий уровень СММ, то в соотвествии с одним из КРА 2-го уровня
она обязана была заботиться о том, как фирмы, которым она поручает свою работу, выполняют эту самую работу.
В общем, как я понял, эта крупная западная фирма решила потратить деньги и силы
на то, чтобы вытянуть своих субподрядчиков на определенный уровень СММ.
Альтернативой, как я понял, был разрыв контрактов с теми, кто по ряду
причин не сможет (не захочет) работать над своим процессом.
Такие вот были исходные данные.
Когда я появился в этой российской компании, уже было принято решение, что компания через 2 года должна иметь 3-й уровень. Начальным естественно был классический 1-й уровень со всеми своими прелестями.
Описывать, как все происходило уж слишком долго.
Было все. Были нудные тренинги. Мы написали кучу документов. Очень долго спорили
по поводу того, а что же имел ввиду SEI в своем отчете о CMM.
Во всем этом принимали участие практически все сотрудники компании.
Западная фирма устраила 2 пробные аттестации и только когда убедилась, что да, мы готовы, тогда
организовала саму аттестацию. В итоге 3-й уровень был получен. Сейчас у этой компании 4-й уровень
Я для себя уяснил, что 3-й уровень за 2 с небольшим года – это слишком быстро.
Если бы не было бы гонки, то все прошло бы куда лучше.
Моя личная оценка – 4 года это реальный срок, при котором народу не прошлось гнаться непонятно за чем.
Нужно время на то, чтобы осознать необходимость того, что требует СММ
и реализовать все разумно, а не формально.
Молодые программеры, которые только что с универов, воспринимают идеи СММ
с большим пониманием и при этом не жалуются на то, что он убивает в них творцов.
Более того, это вроде даже круто, работать по процессу и быть частью команды, которая
разрабатывает сложный продукт (тут я опять вспомню про airbus).
Тяжелее всего с теми, кто уже имеет опыт, причем богатый опыт работы в одиночку.
Некоторые вещи из СММ лучше спустить на тормозах и реализовать их формально.
Это сэкономит и время и нервы. Это относится к некоторым вещам из 3-го уровня.
СММ, кстати, еще критикуют за то, что он слишком негибок и прямолинеен в оценке компаний.
Если есть более конкретные вопросы, то спрашивай.
Правда я не обещаю, что отвечу на все вопросы.
Здравствуйте, bkat, Вы писали: B>Более того, это вроде даже круто, работать по процессу и быть частью команды, которая B>разрабатывает сложный продукт (тут я опять вспомню про airbus).
Это точно. У нас до СММ вроде бы не дошло, но внедрение "картошки на руси" я помню. Постепенно проникаешься, и видишь преимущества наличия методики. Когда каждый релиз — это не подвиг, а результат скоординированных усилий группы людей. B>Тяжелее всего с теми, кто уже имеет опыт, причем богатый опыт работы в одиночку.
Это точно. Начиная от "зачем мне рисовать эту модельку?" до "да когда этот инструктор в школу ходил, я уже ентерпрайзы автоматизировал!"
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Спасибо за ответ. Одно не понятно — что изменилось у вас? Стали сдавать продукты быстрее/медленнее,
дороже/дешевле, качество стало выше или ниже, итд. Каковы твои субъективные оценки оверхэда от следованию процессу.
B>Молодые программеры, которые только что с универов, воспринимают идеи СММ B>с большим пониманием и при этом не жалуются на то, что он убивает в них творцов. B>Более того, это вроде даже круто, работать по процессу и быть частью команды, которая B>разрабатывает сложный продукт (тут я опять вспомню про airbus).
Ну это-то понятно. Я после университета тоже верил в силу формальных методологий и процессов.
Мне казалось, что я знаю как масштабируется разработка на большие коллективы. Теоретически. Я был готов с удовольствием пробовать новые "формальные" методы на себе, по собственной инициативе, и наблюдать за "магией научных формул" в действии. Что мы и делали.
Ничего. Это не навсегда.
Однажды я беседовал с руководителем группы бизнес-консультантов, который набирал себе команду. Мы с ним имели разговор о технологих реорганизации бизнес-процессов, в котором он в частности отметил: "не придавайте большого значения формальным методам. Гораздо важнее здравый смысл, понимание задачи и умение объясняться простым и понятным языком". Тогда я с ним до конца не согласился, но фразу запомнил. Она настолько неожиданно и общо прозвучала, что аргументов как-то сразу не нашлось.
Теперь я уверен, что _не_ знаю, как правильно организовать разработку большого продукта. В любой команде больше 2 человек возникает проблема с эффективной организацией разработки, и я не знаю как ее можно принципиально решить. По моему ощущению, Методологии не решают этой проблемы. Они вообще гроша ломаного не стоят при их формальном применении, а при неформальном они не есть необходимость. "Гораздо важнее здравый смысл, понимание задачи и умение объясняться простым и понятным языком". До меня это в конце концов дошло. Года за три.
Есть и еще одно, очень простое наблюдение. Наличие "The Right People" в гораздо большей степени влияют на качество результата чем используемые процессы или Методологии.
B>Тяжелее всего с теми, кто уже имеет опыт, причем богатый опыт работы в одиночку.
А еще тяжелее с теми, у кого богатый опыт успешной работы в команде. С такими просто концы. Они, видите-ли, слишком много понимают, умные все стали. Пробовать не хотят все подряд, статистике не верят(!), и занимаются демагогией. Например:"по статистике в среднем у каждого человека на земле одно яйцо!"
Здравствуйте, Gaperton, Вы писали:
G>Спасибо за ответ. Одно не понятно — что изменилось у вас? Стали сдавать продукты быстрее/медленнее, G>дороже/дешевле, качество стало выше или ниже, итд. Каковы твои субъективные оценки оверхэда от следованию процессу.
Тут мне сложно ответить, потому что я в этой фирме уже не работаю
Но кое-что я могу сказать.
1)
Больше всего, наверное, выиграли руководители проектов
и те люди, которые непосредственно общаются с заказчиком.
Скажем, если у тебя есть план, который ты создал по науке
с привлечением скажем COCOMO, провел все формальные review плана
и заказчик подписал его, то это защищает самого руководителя
проекта и его команду.
Аналогично со спецификациями системы.
Т.е. когда руководитель проекта начинает внятно и аргументированно
объяснять, что на изменение требований ему нужно дополнительные 2 недели,
то это дает ему гораздо больше шансов выбить эти самые 2 недели.
Т.е. руководителям проектов точно стало понятней как поступать
и что вообще делать.
2)
Качество продукта тоже стало лучше, потому что нормальные внятные
документированные требования позволили писать хорошие тесты.
Найденные баги гарантированно исправлялись и ни о чем не забывалось.
Хотя конечно же полностью от багов избавляться не удавалось,
и после релиза заказчик иногда находил новые баги
3)
Насчет сроков. Где-то я читал статистику, что в целом достижение
уровней СММ не дает заметного снижения сроков разработки.
Сроки остались в среднем такими же. Но, если раньше срыв первоначальных сроков
приводил к проблемам с заказчиком, то потом эти проблемы стали гораздо менее
острыми, потому что все именения сроков происходили с ведома
и согласия заказчика (см. пункт 1).
Т.е. в итоге при тех же сроках недовольство заказчика стало значительно меньше
плюс качество продука стало объективно выше.
4)
Про "дороже/дешевле" я ничего сказать не смогу.
Скорей всего осталось так же.
5)
Про оверхэд следования процессу.
Если не учитывать начальные затраты на создания самого процесса,
то на мой взгляд получается примерно следующее.
У руководителя проекта никакого оверхеда в общем то нет.
Процесс просто расставил все на свои места и стало понятно зачем вообще нужны
руководители и менеджеры и чем они должны заниматься
Для разработчиков. Тут трудно, потому что нужно определиться,
что есть оверхэд.
Из явного — это заполнение метрик и отчетов.
На это может уходить минут 30 в неделю.
Затем, работа над улучшением процесса — на это предусматривалось пару часов в неделю.
Реально человек мог ничего месяц не делать, а потом один день этому посвятить.
Участие в формальных инспекциях и обсуждениях — это я не считаю оверхедом.
Это просто части работы.
G>Есть и еще одно, очень простое наблюдение. Наличие "The Right People" в гораздо большей степени влияют на качество G>результата чем используемые процессы или Методологии.
Конечно же "The Right People" — это очень важно.
Но если эти самые "The Right People" забывают просмотреть
базу дефектов и исправить баг, найденный тестерами на system testing,
а потом никто не проверил что баг был исправлен, то это проблема.
Это очень глупая, обидная, но очень вероятная ситуация,
когда работают не по процессу...
Я просто хочу подчеркнуть, что процесс сам по себе не отрицает
"The Right People" а наоборот, очень нуждается в них.
Спасибо, в целом все ясно. Складывается впечатление что у вас было все не так плохо, я бы даже сказал "имели место быть отдельные недостатки", и всего-то. Молодцы.
Отдельные комментарии.
B>Т.е. руководителям проектов точно стало понятней как поступать B> и что вообще делать.
B>Процесс просто расставил все на свои места и стало понятно зачем вообще нужны B>руководители и менеджеры и чем они должны заниматься
Есть на эту тему ИМХО.
Года 4 назад я зашел на brainbench (там еще было все бесплатно) и увидет там тест для менеджеров проектов.
О как! — подумал я.
Ну ка глянем!
Глянул.
"2.7 баллов, не хватает на сертификат, вы, в целом, полный лох, сэр."
"Да, кстати, при этом вы круче чем 90% всех экзаменованых на данный момент." Смешно. И, к сожалению, симптоматично.
Менеджеры проектов часто наименее компетентные в своем деле специалисты в команде. Руководитель проекта, который не знает, в чем состоит его работа, относит к плюсам внедрения Методологии те элементы управления проектами, которые неизбежно там содержатся (и которые таки в результате худо-бедно вбили ему в голову). В то время как это не плюс Методологии, это минус менеджеру. И еще не понятно, хорошо это или плохо: заставь дурака богу молиться — он себе лоб расшибет до затылка. Вот так плавно мы переходим к The Right People на своих местах.
G>>Есть и еще одно, очень простое наблюдение. Наличие "The Right People" в гораздо большей степени влияют на качество G>результата чем используемые процессы или Методологии. B>Конечно же "The Right People" — это очень важно. B>Но если эти самые "The Right People" забывают просмотреть B>базу дефектов и исправить баг, найденный тестерами на system testing, B>а потом никто не проверил что баг был исправлен, то это проблема. B>Это очень глупая, обидная, но очень вероятная ситуация, B>когда работают не по процессу... B>Я просто хочу подчеркнуть, что процесс сам по себе не отрицает B>"The Right People" а наоборот, очень нуждается в них.
Right People по крайней мере хоть интересный продукт сделают и бабок нарежут. Пусть они разгилдяи и сорвут сроки и забьют болт на пару багов. Зато продажи пойдут (как насчет Doom3? Ждем-с? А сроки-то сорваны больше чем на год). А вот Кто Попало сделает вам по процессу с отменным качеством и в срок продукт, который никому не нужен и вызывает зевоту на рынке. Имеем: наличие Right People (вне зависимости от наличия процесса) критично для рыночного успеха, их отсутствие (даже при наличии процесса) — фатально. Так кто кому нужен и кто важнее, люди или Процесс?
Я категорически против формулировки "процесс нуждается в людях". Процесс создается людьми потому что они нуждаются в процессе, а когда он уже не нужен, — он больше не применяется. А не наоборот.
The Right People потому и Right, что в состоянии сами идентифицировать проблему (не идиоты, все-таки),
и смогут разработать и внедрить необходимый процесс, который не связан рамками Методологий и нацелен
на решение конкретных проблем учитывая личные особенности и склонности, текущую ситуацию, возможности и желание. Потому как при отсутствии желания он просто не сработает, можно увнедряться до посинения. Right People ведь тоже не отрицают процесса (ма-аленького такого, над которым они имеют контроль), но только если они ему не нужны, он их не хочет, не ищет, и не собирается поиметь
Ну в общем, я думаю, наши позиции не столь уж и разнятся.
Просто тут на РСДН действительно обменяться мнениями довольно
тяжело. По крайней мере мне (я не писатель )
Спасибо за интересные мысли
B>>Тяжелее всего с теми, кто уже имеет опыт, причем богатый опыт работы в одиночку. G>А еще тяжелее с теми, у кого богатый опыт успешной работы в команде. С такими просто концы. Они, видите-ли, слишком много понимают, умные все стали. Пробовать не хотят все подряд, статистике не верят(!), и занимаются демагогией. Например:"по статистике в среднем у каждого человека на земле одно яйцо!"
Немного офтопика...
Даже в этой метрике "количество яиц на душу населения" тоже есть смысл.
Если не дай бог по статистике в среднем у каждого человека на земле будет по 2 яйца,
то это означает что случилось что-то страшное и надо уже давно бить в набат и разбираться
что не так.
Тот же СММ говорит, что метрики должны сбираться, но в нем нет списка обязательнных метрик.
А вот на то, чтобы решить какие и зачем, на это нужно много времени
и каждая контора должна изобрести свой велосипед.
Главное не торопиться и гнать. Спешка — это, на мой взгляд, самый главный враг всех Методолий...
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
G>>Кстати, а не мог бы ты поделиться своей историей о внедрении CMM? Чертовски интересно.
B>Если очень кратко, не называя паролей и явок , то получится примерно следующее.
) ?
B>Описывать, как все происходило уж слишком долго. B>Было все. Были нудные тренинги. Мы написали кучу документов. Очень долго спорили B>по поводу того, а что же имел ввиду SEI в своем отчете о CMM. B>Во всем этом принимали участие практически все сотрудники компании.
все сотрудники??? Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)?
B>Некоторые вещи из СММ лучше спустить на тормозах и реализовать их формально. B>Это сэкономит и время и нервы. Это относится к некоторым вещам из 3-го уровня.
Можешь поподробнее? Что именно и из каких соображений?
IMHO это имеет смысл делать только с Training Programm и (если фирма небольшая) Intergroup Coordination.
Или что-то еще?
Ничего добавить не смогу. Действительно рынок труда для таких спецов очень мал.
Про конторы, которые делают аудит и готовят конторы к сертификациям,
я не слышал . Вернее слышал, но в глаза не видел...
B>>Описывать, как все происходило уж слишком долго. B>>Было все. Были нудные тренинги. Мы написали кучу документов. Очень долго спорили B>>по поводу того, а что же имел ввиду SEI в своем отчете о CMM. B>>Во всем этом принимали участие практически все сотрудники компании.
C>все сотрудники??? Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)?
SEPG + 1-2 эксперта организуют и координируют работу. Они же генераторы идей.
Но если "могучая кучка" просто напишет хороший процесс и затем руководство спустит
его просто вниз, то ничего работать не будет.
Опять же совместная работа учит всю команду и шансы пройти сертификацию сильно
повышаются, потому что на сертификации народ рассказывает о том,
что сами придумали и реализовали.
B>>Некоторые вещи из СММ лучше спустить на тормозах и реализовать их формально. B>>Это сэкономит и время и нервы. Это относится к некоторым вещам из 3-го уровня.
C>Можешь поподробнее? Что именно и из каких соображений? C>IMHO это имеет смысл делать только с Training Programm и (если фирма небольшая) Intergroup Coordination. C>Или что-то еще?
Я имел ввиду не целые KPA а некоторые цели из некоторых KPA.
Чтобы ответить точнее, мне надо лезть в сам СММ, смотреть точные формулировки
и вспоминать, что делали мы.
Может позже я это сделаю, но не обещаю
Здравствуйте, bkat, Вы писали:
B>>>по поводу того, а что же имел ввиду SEI в своем отчете о CMM. B>>>Во всем этом принимали участие практически все сотрудники компании.
C>>все сотрудники??? Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)?
B>SEPG + 1-2 эксперта организуют и координируют работу. Они же генераторы идей. B>Но если "могучая кучка" просто напишет хороший процесс и затем руководство спустит B>его просто вниз, то ничего работать не будет. B>Опять же совместная работа учит всю команду и шансы пройти сертификацию сильно B>повышаются, потому что на сертификации народ рассказывает о том, B>что сами придумали и реализовали.
Оно конечно так, но когда в комманде >50 человек, это не возможно просто физически. Приходится ограничиться только SQA, которым без хорошо осознаного понимания процесса вообще никак и различными Senior SWE в качестве экспертов иногда даже для разных активностей в рамках одного процесса. А для остальных только Role-based trainings и полуформальная передача знаний внутри проэктных комманд.
B>>>Некоторые вещи из СММ лучше спустить на тормозах и реализовать их формально. B>>>Это сэкономит и время и нервы. Это относится к некоторым вещам из 3-го уровня.
C>>Можешь поподробнее? Что именно и из каких соображений? C>>IMHO это имеет смысл делать только с Training Programm и (если фирма небольшая) Intergroup Coordination. C>>Или что-то еще?
B>Я имел ввиду не целые KPA а некоторые цели из некоторых KPA. B>Чтобы ответить точнее, мне надо лезть в сам СММ, смотреть точные формулировки B>и вспоминать, что делали мы. B>Может позже я это сделаю, но не обещаю
Это был вопрос уже скорее академический, можно и не отвечать.
Но есть другой, который меня действительно очень интересует.
Мне, в частности, пришлось очень активно заниматься Configuration & Change Management и после интервью с Lead Assessor, Я очень сильно озадачен его интерпретацией некоторых вещей, относящихся к Traceability (SPE C1(3), AC 10).
Во первых он утверждал, что не только "software requirements, design, code, and test cases" "should be traced to the source" (что само собой разумеется), но и другие документы, которые вообще обычно не включаются в baseline и не поставляются заказчику, причем вторые тоже должны ссылаться на source unique id (причем крайне желательны двусторонние ссылки) а текстовые ссылки типа фразы в history — "reestimated, features X & Y considered, feature Z removed" описывающие соответствующий (и зарегистрированый change request) не катят .
В фирме, где ты работал этого придерживались?
Во вторых "Reason of ANY change should be documented and traced" очень плохо согласуется с cooperative development, когда на реализацию одного CR могут приходиться десятки check-in/check-out (и соответственно записей в history). С кодом это проблем не вызывает, т.к. необходимую информацию можно поместить в комментарий к метке. А вот по поводу документации сьехать на cooperative development и на то, что revision history в первую очередь дла разработчиков, а соотв. требования CMM выполняются благодаря наличию необходимой информации в Release Description не удалось
Как решалась эта проблема? (ложить документацию в Source Control System не предлагать, т.к. тогда придется отказаться от массы полезных фич, предоставляемых системой документооборота и выбросить на мусор все усилия и время потраченые на ее кастомизацию).
Надеюсь не слишком загрузил и Заратустра (NDA, котнракт, etc.) позволяют ответить?
Заранее спасибо
Здравствуйте, Gaperton, Вы писали:
B>>Немного в сторону. B>>Как-то читал, как делаются европейские аэробусы (airbus). B>>Вовлечены в это дело многие тысячи спецов с разных стран. B>>В разных странах проектируют и делают разные части самолета. B>>Потом разные части свозятся на сборочные заводы в Германии B>>и все это дело очень неплохо стыкуется и потом самолеты от airbus летают B>>и уже бьют боинги.
B>>Вот туда надо смотреть и с ними сравнивать, а не с макдональдсами. G>А вот с этим как-раз и нельзя сравнивать.
Полностью согласен.
Поинтересуйтесь — сколько времени разрабатывается какой-нибудь самолёт, сколько при этом задействовано людей и во сколько это обходится. Где то читал, что, в среднем — разработка самолёта это 1.5-2.5 тыс человек, 1-1.5 млрд $, и 7-9 лет работы. Вот почему сегодня весь мир летает на самолётах, разработанных в начале 70-х и лишь слегка усовершенствованых (в основном в области электроники и обивки салона ). B57 летают с 1960-х годов. Если такие деньги, время и кол-во людей задейстовать при разработке ПО — этот софт можно будет как эталон высекать в граните.
Другой пример — с архитектурой. Там сроки разработки проектов — вполне сопоставимы с самолётными (3-7 лет). Кроме того, не один архитектор (крупное здание) с нуля не ваяет — есть куча стандартных СНИПов, ГОСТов, ТУ и прочей дребедени, которой он ДОЛЖЕН пользоваться (это Вам не выбирать STL или свой контейнер использовать — там палкой по пяткам — и вперёд — совершенствоваться у них даже то, как провода по стенкам пускать — строго регламентировано). И занимается подобным проектом в общей сложности от 100 до 300 человек. Стоимость $5M — $15M. Теперь берём, и оцениваем — хотя бы по количеству различных элементов — чему эквивалентен подобный проект в IT... Так вот — по разным оценкам, проект аналогичной сложности делает команда из 6-20 человек в течение 1-2 лет (как видите разброс в оценках Ч-Ч в 7 раз), стоимость проекта оценивается в $100K-$500K. Не бросается в глаза лёгкое несоответствие?
Вот потому то говорить о методологиях в разработке ПО — как о систематическом и надёжном методе организовать процесс разработки с таким же качеством, как разработка самолётов — как минимум — смешно, как максимум — глупо, просто потому, что при разработке ПО ни один работадатель, кроме, возможно, пентагона (вспомним язык ADA, Internet, UDF, RPC и кое-что ещё), оплачивать методологию по-настоящему (как это делается в крупных инженерных проектах) — просто не намерен. (Вы где нибудь видели проект — в котором вся проектная документация подготваливалась бы вовремя и в нужном объёме???)
А без этого методологии разработки (как и всё прочее) — являются минимум — набором "правильных идей" (читай "Благих Намерений" — что-то по их поводу в Библии упоминалось... ) — как максимум — набором полезных инструментов, которым ещё нужно суметь воспользоваться. В таких условиях — всё определяется личностями людей (начальством, программистами, архитекторами...)
Кроме того именно в программировании есть существенная психологическая ловушка, в которую попадается большинство начальников и проектировщиков (особенно если они давно перестали заниматься разработкой). Эта ловушка заключается в том, что сами программы — почти ничего не стоят. То есть когда у вас весь офис завален ворованным софтом (или в случае буржуев — Try&Buy софтом), начальство не сильно задумывается, а сколько будет стоить тот или иной вариант проекта, с использованием "готовых деталей". Но, обычно, они начианют об этом задумываться на этапе внедрения. И тут могут возникнуть пёрлы, с заменой одних модулей — другими. Хотел бы я посмотреть на самолёт — в котором меняют винтовые двигатели — на реактивные... А в софте это бывает довольно часто.
G>Когда детали стыкуются и самолет сразу летит, подробные спецификации на детали уже готовы, G>технология их производства уже отлажена, испытания опытных образцов самолетов уже прошли.
Поговорите с Любым авиаконструктором (или хотя бы послушайте их по ТВ). Когда детали стыкуются — первый раз — и не было исключений в истории авиации — самолёт нормально никогда не летит. Его первый полёт — всегда большой риск. Всегда выясняется, что толи с электрикой проблемы, толи маслопровод (замерзает/перегревается), толи в крыле вибрации выше нормы... Потому уже готовый проект самолёта меняют и доделывают, откуда и набегает такая дикая сумма стоимости разработки нового самолёта... (У нас это называется отладка , а ещё говорят, что в других областях её нет... )
G>В программировании прямой аналогией такого процесса является... компиляция (изготовление "деталей" .obj G>по "чертежам/спецификациям" в виде исходников), и сборка ("изготовление" .exe из готовых "деталей"). И G>с этим у нас вообще проблем никаких, как вы понимаете.
G>Написание программного комплекса больше напоминает изобретение новой модели пассажирского самолета. Он же не сразу взял и полетел. Инженеры думают, делают прототипы деталей, испытывают их, собирают прототип сомолета, продувают его в трубах, занимаются компьютерным моделированием, делают опытные образцы, "отлаживают" их, направляя заказы на доработку деталей заводам производителям, и т.д. Бардак тот еще.
При изготовлении самолётов, каждая деталь — отдельный проект. А уж про такие детали, как двигатель — говорить не приходится...
G>Но им проще. У них интерфейсы между деталями более стандартны, детали от разных самолетов очень похожи по принципиальному устройству, количество возможных видов деталей и их функционал известны заранее (двигатель он и есть G>двигатель, известно что он делает и как). И главное, компоненты слабо связанны друг с другом. Например, известно, что к двигателю надо подвести крепление, трубу с топливом, и управление. В програмных же комплексах интерфейсы между компонентами на порядок сложнее, предполагают сложные сценарии взаимодействия со множеством состояний. Это затрудняет разделение задач и разработку, так как такие непростые интерфейсы приходится разрабатывать заново каждый раз, определяя их функционал. А с двигателями все стандартно.
Конечно. У них все детали стоят в десятки раз дороже, потому тут хочешь не хочешь — придётся пользоваться стандартными "интерфейсами". Им то не скажешь — ребятки, а ну её нафиг программу рассылки почты, за неделю напишем свою...
G>Плюс ко всему, современные программные комплексы превосходят по количеству деталей самолеты. Современный софт — это самые сложные инженерные системы за всю историю человечества. Известно, например, что операционная система OS/360 превосходит по инженерной сложности ракету "Сатурн" с "Аполлоном" и лунным модулем вместе взятыми.
А сама эта ОС — уступает по сложности всего-лишь COM инфораструктуре Windows.
G>Так что, это они должны удивлятся почему у нас хоть что-то работает
Согласен целиком и польностью!!!
> Как решалась эта проблема? (ложить документацию > в Source Control System не предлагать
Source Control System в общем случае не обязано
быть представлено одной программой (CVS, VSS, etc.),
а может включать себя и вашу систему документооборота,
главное, чтобы обеспечивались одно- или двусторонние
ссылки на ревизии кода/документа. Хотя бы просто по дате.
Здравствуйте, Candle645, Вы писали:
C>Здравствуйте, bkat, Вы писали:
B>>>>по поводу того, а что же имел ввиду SEI в своем отчете о CMM. B>>>>Во всем этом принимали участие практически все сотрудники компании.
C>>>все сотрудники??? Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)?
B>>SEPG + 1-2 эксперта организуют и координируют работу. Они же генераторы идей. B>>Но если "могучая кучка" просто напишет хороший процесс и затем руководство спустит B>>его просто вниз, то ничего работать не будет. B>>Опять же совместная работа учит всю команду и шансы пройти сертификацию сильно B>>повышаются, потому что на сертификации народ рассказывает о том, B>>что сами придумали и реализовали.
C>Оно конечно так, но когда в комманде >50 человек, это не возможно просто физически. Приходится ограничиться только SQA, которым без хорошо осознаного понимания процесса вообще никак и различными Senior SWE в качестве экспертов иногда даже для разных активностей в рамках одного процесса. А для остальных только Role-based trainings и полуформальная передача знаний внутри проэктных комманд.
У нас как раз было чуть больше 50 человек.
На самом деле работы, когда процесс только формируется, хватает всем.
Если учесть, что тех, кто был занят на "горящих" проектах не трогали,
то народу нам явно не хватало...
Вот если было бы больше 100 человек, то всех занять было бы тяжелее
C>Но есть другой, который меня действительно очень интересует. C>Мне, в частности, пришлось очень активно заниматься Configuration & Change Management и после интервью с Lead Assessor, Я очень сильно озадачен его интерпретацией некоторых вещей, относящихся к Traceability (SPE C1(3), AC 10). C>Во первых он утверждал, что не только "software requirements, design, code, and test cases" "should be traced to the source" (что само собой разумеется), но и другие документы, которые вообще обычно не включаются в baseline и не поставляются заказчику, причем вторые тоже должны ссылаться на source unique id (причем крайне желательны двусторонние ссылки) а текстовые ссылки типа фразы в history — "reestimated, features X & Y considered, feature Z removed" описывающие соответствующий (и зарегистрированый change request) не катят . C>В фирме, где ты работал этого придерживались?
Да, мы старались этого придерживаться.
Скажем, если в плановом документе есть ссылка на документ по стандарту кодирования,
то эта ссылка приводится по всем правилам (нами же установленными).
Это означает, что мы указываем UID документа со стандартом кодирования
и версию этого документа. На сам документ навешивается baseline метка и заказчик,
при желании, может добраться до любого документа на который есть ссылки из проектных документов.
В общем это было головной болью для СМ инженера.
Задачей человека, отвественного за "кастомизацию" процесса для нужд проекта было
подготовить список всех документов, которые определют процесс,
а СМ инженер должен был аккуратно навешивать baseline метки метки
Правда вот до двусторонних ссылок дело не дошло (слава богу
C>Во вторых "Reason of ANY change should be documented and traced" очень плохо согласуется с cooperative development, когда на реализацию одного CR могут приходиться десятки check-in/check-out (и соответственно записей в history). С кодом это проблем не вызывает, т.к. необходимую информацию можно поместить в комментарий к метке. А вот по поводу документации сьехать на cooperative development и на то, что revision history в первую очередь дла разработчиков, а соотв. требования CMM выполняются благодаря наличию необходимой информации в Release Description не удалось C>Как решалась эта проблема? (ложить документацию в Source Control System не предлагать, т.к. тогда придется отказаться от массы полезных фич, предоставляемых системой документооборота и выбросить на мусор все усилия и время потраченые на ее кастомизацию).
Мы ложили документацию в Source Control System
Но даже если этого и не делать, а использовать, например, Documentum,
то я тоже проблем не вижу...
Какая разница, где физически лежит документ?
Здравствуйте, bkat, Вы писали:
B>Скажем, если в плановом документе есть ссылка на документ по стандарту кодирования, B>то эта ссылка приводится по всем правилам (нами же установленными). B>Это означает, что мы указываем UID документа со стандартом кодирования
В общем примерно то-же самое, только было мнение, что ссылки "по всем правилам" для документов "которые вообще обычно не включаются в baseline и не поставляются заказчику" являются optional — т.е. весма полезны с точки зрения usability, но не являются обязательными с т.з. CMM.
B>и версию этого документа. На сам документ навешивается baseline метка и заказчик, B>при желании, может добраться до любого документа на который есть ссылки из проектных документов. B>В общем это было головной болью для СМ инженера.
Я б даже сказал CM это вообще главный источник головной боли для девелоперов. А ISM и SPTO для PM/PL
C>>А вот по поводу документации сьехать на cooperative development и на то, что revision history в первую очередь дла разработчиков, а соотв. требования CMM выполняются благодаря наличию необходимой информации в Release Description не удалось Как решалась эта проблема? (ложить документацию в Source Control System не предлагать,
B>Мы ложили документацию в Source Control System B>Но даже если этого и не делать, а использовать, например, Documentum, B>то я тоже проблем не вижу... B>Какая разница, где физически лежит документ?
С технической стороны — есть немного. Используемая система документооборота не поддерживает метки . В общем придется ужесточить условия перевода документов в Approved состояние и давать к нему (в обязательном порядке) "правильные" комментарии.
Спасибо за помощь. Приятно было пообщаться со знающим человеком.
Много ли людей в вашей конторе?
Были ли уже формальные сертификации и какой уровень получен?
Сколько времени ушло на подготовку с момента, когда решили "Да — это нужно".
Как долго вообще зрело решение начать работу в этом направлении?
Были ли серьезные трения SQA с разработчиками и PL?
Здравствуйте, bkat, Вы писали:
B>Может и ты расскажешь о своем опыте
Попытаюсь (в рамках разумного)
B>Много ли людей в вашей конторе?
Здесь (http://www.miratech.ua/company.jsp) утверждается, что >100. Более точной информации дать не могу.
B>Были ли уже формальные сертификации и какой уровень получен?
CMM — Не было. В начале 2002 был получен ISO9001:2000.
B>Сколько времени ушло на подготовку с момента, когда решили "Да — это нужно".
Сложно сказать. Работа над процессом и его внедрением в нашем (аутсорцинговом) отделе началась где-то с средины 2000 (RUP в качестве основной модели разработки, более-менее формализированый Project Management, обучение). В 2001 уже велась целенаправланая работа в направлении ISO9000, и подразумевалась в перспективе CMM. Если говорить не о Process Improvement вообще, а о CMM, то почти 2 года.
B>Как долго вообще зрело решение начать работу в этом направлении?
4 года назад, когда я только пришел сюда работать уже существовало понимание преимуществ в глазах заказчиков которые даст наличие соотв. сертификаций.
B>Были ли серьезные трения SQA с разработчиками и PL?
С разработчиками — нет т.к. SQA напрямую с ними не работает (только консультируем в случае необходимости). С PM/PL иногда случаются споры по поводу интерпретации CMM или адекватности планируемого Project-defined project но серьезных трений нет. (может быть потому, что большинство SQA являются PM/PL ).
B>Заранее спасибо!
B>>Были ли серьезные трения SQA с разработчиками и PL?
C>С разработчиками — нет т.к. SQA напрямую с ними не работает (только консультируем в случае необходимости). С PM/PL иногда случаются споры по поводу интерпретации CMM или адекватности планируемого Project-defined project но серьезных трений нет. (может быть потому, что большинство SQA являются PM/PL ).
У нас SQA выделенный и на проектах ничем другим не занимается.
Но все-таки будь поосторожней, оценивая знания людей по высказыванием их учеников. И повнимательней читай сообщения. Я на самом деле не совсем глупый.
.
Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)? 
. 
А ISM и SPTO для PM/PL 
