Почитал обсуждение на UML2.RU, по его мотивам решил немного порассуждать по этой теме. Собственно вопрос в том, что иногда возникает в головах путаница что есть что и как эти понятия с собой соотносятся. По-хорошему для того, чтобы бы не путаться следует создавать глоссарий (или использовать готовые, англоязычные, только иногда имеет смысл делать их value added перевод :-) ).
Если подходить формально, то МЕТОДОЛОГИЯ - это некий мета уровень, т.е. учение о конкретных методах познания объекта познания (по данным Википедии, другие источники не смотрел). Но в практике ИТ как правило "так не заморачивваются" и под методологией часто понимают, что-то близкое к определению, которое дает глоссарий BABOK (A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context). В этом определении смело можно заменить фразу "business analysis, solution development and implementation" на что-то что более релевантное (вот словечко "подцепил", работая в MS ;-)) к конкретной области и оно станет универсально (в этом определении говорится скорее про методологию создания "РЕШЕНИЯ вообще", контекстом которого в нашем случае может быть и заказное ПО, т.н. интеграционное решение иди Enterprise Architecture - как вполне себе решение). Это определение, на мой взгляд, очень даже жизнеспособное. Примерами методологий вполне можно считать тот же SADT, и более специфично - в области создания "преимущественно программных решений" - условно RUP, ну и Agile (обобщенно). Тут конечно сразу же возникает термин "процессный фреймворк", к которому скорее можно отнести тот же RUP. И это название даже более точно отражает его суть, чем термин "методология". Думаю, что в данном конкретном случае принимая за основу определение от BABOK, вполне можно называть тот же RUP - методологией. В любом случае, исходя из вышесказанного, можно считать, что методология нас направляет на конечный результат, и говорит каким образом его можно достичь. При этом в большинстве случаев степень детализации описания методологии может различаться от МЕТОДОЛОГИИ к МЕТОДОЛОГИИ. А конкретный набор шагов, состав результатов и их содержимое могут быть подвержены существенной "кастомизации" при работе в конкретных условиях, на конкретном проекте и это отдельная работа.
Говоря о СВОДЕ ЗНАНИЙ, примерами которого являются тот же BABOK, SWEBOK, PMBOK, ... следует понимать, что свод знаний как правило менее конкретен (специфичен). Он выполняет роль сбора в одном месте всего, что мы знаем об определенной области деятельности. Вполне может быть, что на основании свода знаний может быть построена МЕТОДОЛОГИЯ. Другой вопрос, что зачастую методологии и своды знаний имеют множество "пересечений", но это просто нужно "принимать как есть", т.к. "nobody care about it".
Теперь мы добрались до НОТАЦИЙ. Если подходить неформально, то под нотацией обычно понимается некий язык (чаще - графический), или структура, позволяющая унифицированным образом описать статическую и/или динамическую модель системы или ее части (в качестве системы может выступать и целая предметная область). Графическими нотациями является например семейство языков IDEF, или тот же UML, или BPMN. Нотации часто являются составной частью МЕТОДОЛОГИЙ, или МЕТОДОЛОГИИ используют для описания тот или иной язык (нотацию). Например, RUP использует UML, SADT - устойчиво ассоциирован с IDEF и т.п.
Говоря о вариантах использования (use cases) - следует четко определять контекст - о чем мы говорим, т.е. мы говорим о части языка UML или же о текстовых описаниях. Во избежании путаницы, далее речь пойдет о вариантах использования как о текстовых структурированных описаниях. Тот же К. Вигерс отводит место вариантам использования, как некой нотации, которая позволяет описывать пользовательские требования. Следует отметить, что пользовательские требования могут быть описаны разными способами, одним из которых (и достаточно эффективным в определенных ситуациях) являются варианты использования. В этом случае вполне можно согласиться с точкой зрения Вигерса о юзкейсах, как фактически о нотации.
Рассматривая СТАНДАРТЫ - тут все хуже ... :-). Стандартом в принципе может являться все из выше перечисленного. Другой вопрос СТАНДАРТОМ какого уровня - международным, государственным, отраслевым, корпоративным ... Говоря о требованиях и стандартизации, можно сказать, что в большинстве случаев имеются стандарты на содержание ДОКУМЕНТАЦИИ, которые содержат в себе требования. Тот же IEEE 830 или ГОСТ 34.602. Иногда даются рекомендации, как следует формулировать требования и как их следует разделять в документах.
Если подходить формально, то МЕТОДОЛОГИЯ - это некий мета уровень, т.е. учение о конкретных методах познания объекта познания (по данным Википедии, другие источники не смотрел). Но в практике ИТ как правило "так не заморачивваются" и под методологией часто понимают, что-то близкое к определению, которое дает глоссарий BABOK (A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context). В этом определении смело можно заменить фразу "business analysis, solution development and implementation" на что-то что более релевантное (вот словечко "подцепил", работая в MS ;-)) к конкретной области и оно станет универсально (в этом определении говорится скорее про методологию создания "РЕШЕНИЯ вообще", контекстом которого в нашем случае может быть и заказное ПО, т.н. интеграционное решение иди Enterprise Architecture - как вполне себе решение). Это определение, на мой взгляд, очень даже жизнеспособное. Примерами методологий вполне можно считать тот же SADT, и более специфично - в области создания "преимущественно программных решений" - условно RUP, ну и Agile (обобщенно). Тут конечно сразу же возникает термин "процессный фреймворк", к которому скорее можно отнести тот же RUP. И это название даже более точно отражает его суть, чем термин "методология". Думаю, что в данном конкретном случае принимая за основу определение от BABOK, вполне можно называть тот же RUP - методологией. В любом случае, исходя из вышесказанного, можно считать, что методология нас направляет на конечный результат, и говорит каким образом его можно достичь. При этом в большинстве случаев степень детализации описания методологии может различаться от МЕТОДОЛОГИИ к МЕТОДОЛОГИИ. А конкретный набор шагов, состав результатов и их содержимое могут быть подвержены существенной "кастомизации" при работе в конкретных условиях, на конкретном проекте и это отдельная работа.
Говоря о СВОДЕ ЗНАНИЙ, примерами которого являются тот же BABOK, SWEBOK, PMBOK, ... следует понимать, что свод знаний как правило менее конкретен (специфичен). Он выполняет роль сбора в одном месте всего, что мы знаем об определенной области деятельности. Вполне может быть, что на основании свода знаний может быть построена МЕТОДОЛОГИЯ. Другой вопрос, что зачастую методологии и своды знаний имеют множество "пересечений", но это просто нужно "принимать как есть", т.к. "nobody care about it".
Теперь мы добрались до НОТАЦИЙ. Если подходить неформально, то под нотацией обычно понимается некий язык (чаще - графический), или структура, позволяющая унифицированным образом описать статическую и/или динамическую модель системы или ее части (в качестве системы может выступать и целая предметная область). Графическими нотациями является например семейство языков IDEF, или тот же UML, или BPMN. Нотации часто являются составной частью МЕТОДОЛОГИЙ, или МЕТОДОЛОГИИ используют для описания тот или иной язык (нотацию). Например, RUP использует UML, SADT - устойчиво ассоциирован с IDEF и т.п.
Говоря о вариантах использования (use cases) - следует четко определять контекст - о чем мы говорим, т.е. мы говорим о части языка UML или же о текстовых описаниях. Во избежании путаницы, далее речь пойдет о вариантах использования как о текстовых структурированных описаниях. Тот же К. Вигерс отводит место вариантам использования, как некой нотации, которая позволяет описывать пользовательские требования. Следует отметить, что пользовательские требования могут быть описаны разными способами, одним из которых (и достаточно эффективным в определенных ситуациях) являются варианты использования. В этом случае вполне можно согласиться с точкой зрения Вигерса о юзкейсах, как фактически о нотации.
Рассматривая СТАНДАРТЫ - тут все хуже ... :-). Стандартом в принципе может являться все из выше перечисленного. Другой вопрос СТАНДАРТОМ какого уровня - международным, государственным, отраслевым, корпоративным ... Говоря о требованиях и стандартизации, можно сказать, что в большинстве случаев имеются стандарты на содержание ДОКУМЕНТАЦИИ, которые содержат в себе требования. Тот же IEEE 830 или ГОСТ 34.602. Иногда даются рекомендации, как следует формулировать требования и как их следует разделять в документах.
