Здравствуйте, 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.
Но все-таки будь поосторожней, оценивая знания людей по высказыванием их учеников. И повнимательней читай сообщения. Я на самом деле не совсем глупый.
.
