Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: Kavalsky от 10 Марта 2013, 00:44:49
-
В виду того что на данный момент не все теории и практики охвачены моим познанием хотел бы структурировать имеющиеся методологии, теории, стандарты и иже с ними.
Правильно ли я понимаю, что:
Следует разделять «сущности» (не исключено что я их перемешал)
1. Нотация (Методология?) сбора/анализа/моделирования (или это три разных подразделения)
SADT, UseCase, UML, есть еще популярные ?
2. Методологию разработки ПО
RUP, Iconix, Agile, XP, и т.п.
3. Стандарты представление документации
ГОСТ, IEEE, есть еще популярные ?
В итоге
1. мы используем методологию моделирования для сбора/моделирования/представления/хранения данных
2. с помощью методологии разработки мы управляем процессом создания продукта
3. с помощью стандарта представления документации мы передаем заказчику информацию о данных и о продукте
Т.е. в зависимости от проекта
- Эти три сущности могут комбинироваться в любом порядке
- Какой-то из них может отсутствовать
- В рамках одной сущности могут быть полное, частичное, и смешанное следование методологии(ям).
Как следствие:
1. Понятие о «Спецификации требований» у каждой компании может быть свое, как и состав документов, но если это ГОС проект то смотрим соответствующий 34-ый стандарт и никаких вам спецификаций.
2. По большому счету ВИ есть ФТ и наоборот. Т.е. одно порождает другое и уже от нас и проекта зависит от чего мы пляшем. Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ? Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?
-
Kavalsky, за несколько лет я пришёл к тому, что слово методология — вредное.
В большинстве случаев его спокойно можно заменить на «правила работы».
При организации работ в проекте нужно договориться о правилах.
Правила бывают разного рода.
RUP предполагает использование UML для моделирования и определённые виды документов (Vision, Use Case Model, Supplementary Specification), которые являются стандартами в его рамках.
Если перечитать Коберна с его «каждому проекту — своя методология», станет понятно, что набор правил не сводится к вектору из (нотация моделирования, стандарт документирования, процессный фреймворк).
-
2. По большому счету ВИ есть ФТ и наоборот. Т.е. одно порождает другое и уже от нас и проекта зависит от чего мы пляшем.
Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ?
Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?
хороший вопрос, про который есть отдельные темы.
Под ФТ понимаются функциональные требования 3-х уровней — бизнесового, пользовательского и технического.
Отсюда и всё месиво.
Способ применения (use case) — это структура, содержащая 1 пользовательское ФТ и N технических.
-
В виду того что на данный момент не все теории и практики охвачены моим познанием хотел бы структурировать имеющиеся методологии, теории, стандарты и иже с ними.
Правильно ли я понимаю, что:
Следует разделять «сущности» (не исключено что я их перемешал)
1. Нотация (Методология?) сбора/анализа/моделирования (или это три разных подразделения)
SADT, UseCase, UML, есть еще популярные ?
2. Методологию разработки ПО
RUP, Iconix, Agile, XP, и т.п.
3. Стандарты представление документации
ГОСТ, IEEE, есть еще популярные ?
Посмотрите тут http://yurybuluy.blogspot.ru/2013/03/blog-post.html на эту тему сделал некоторое рассуждение. Может поможет структурировать мысли.
Как следствие:
1. Понятие о «Спецификации требований» у каждой компании может быть свое, как и состав документов, но если это ГОС проект то смотрим соответствующий 34-ый стандарт и никаких вам спецификаций.
2. По большому счету ВИ есть ФТ и наоборот. Т.е. одно порождает другое и уже от нас и проекта зависит от чего мы пляшем. Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ? Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?
Более корректно (если мы принимаем классификацию Вигерса) говорить, что ВИ - это формат/нотация описания пользовательских требований. И если говорить про то, что под ФТ Вигерс понимает два разных уровня классификации (но с одинаковым названием), т.е. у него все требования делятся на функциональные и нефункциональные требования. Функциональные в свою очередь делятся на бизнес-, пользовательские и (да, да) функциональные. Исходя из этого, ВИ <> ФТ. Но входят в состав ФТ как классификационной единицы :-).
О разнице м/у ВИ и функциями можно почитать тут http://yurybuluy.blogspot.ru/2010/12/use-cases.html.
-
хороший вопрос, про который есть отдельные темы.
Под ФТ понимаются функциональные требования 3-х уровней — бизнесового, пользовательского и технического.
Отсюда и всё месиво.
Способ применения (use case) — это структура, содержащая 1 пользовательское ФТ и N технических.
Денис, поясни пож-та что понимается под "техническими" требованиями?
-
Денис, поясни пож-та что понимается под "техническими" требованиями?
Требования, которые не относятся напрямую к цели пользователя, а только помогают в её реализации.
Например, «Система должна показать список контактов под полем ввода адреса» как шаг сценария реализации требования «Система должна позволять Пользователю отправлять письма».
-
Посмотрите тут http://yurybuluy.blogspot.ru/2013/03/blog-post.html на эту тему сделал некоторое рассуждение. Может поможет структурировать мысли.
Юра, если уж ты упомянул SWEBOK, спрошу — вы будете с Орликом обновлять перевод по результатам выхода SWEBOK v3?
http://computer.centraldesktop.com/swebokv3review/
-
Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ? Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?
Способы применения удобны для планирования разработки, оценивания и организации сдачи/приёмки на уровне проекта менеджеру проекта, команде и заказчику.
Технические функциональные требования в виде списка удобны для планирования разработки, контроля и сдачи разработчику подсистемы/компонента, потому что его подсистема может обслуживать несколько способов применения.
-
Юра, если уж ты упомянул SWEBOK, спрошу — вы будете с Орликом обновлять перевод по результатам выхода SWEBOK v3?
http://computer.centraldesktop.com/swebokv3review/
Пока не обсуждали, Сергей сильно загружен работой.
-
Коллеги спасибо!
Юрий, я нашел еще один Ваш документ, еще не прочел, но думаю он "в тему" -
http://2006.secr.ru/upload/files/63.pdf
-
Что касается понятия "методология". Может будет интересно http://www.methodolog.ru/.
-
[Сначала несколько уточнений.]
Уравнение в заголовке подвергается сильной критике довольно давно. Например, в agile manifesto (http://www.agilemanifesto.org/iso/ru/). Можно добавить слева как минимум ещё три слагаемых: навыки + знания + коллектив.
Нотация -- система обозначений -- не всегда жестко привязана к методике или методологии. Т. е. UML -- не методология моделирования. И не часть методологии RUP (многие участники OMG приложили достаточно усилий, чтобы это не было так). UML создавался как общая нотация для нескольких методов разработки.
Методология RUP содержит в себе техники моделирования. Методология разработки ПО может включать в себя методики моделирования, и чаще всего включает.
[Теперь по существу.]
Нотации дают возможность участникам проекта невербально обмениваться идеями и принятыми решениями.
Стандарты фиксируют соглашения, которых придерживаются участники проекта.
Методологии упорядочивают работу участников проекта.
-
Мне нравится такая штука:
-
Этой нотации поболее полусотни лет, но она, на мой взгляд, лучше и RUP-а, и PMBoK, и прочих. Нестареющая классика.
-
Этой нотации поболее полусотни лет, но она, на мой взгляд, лучше и RUP-а, и PMBoK, и прочих. Нестареющая классика.
А это нотация?
-
Коллеги спасибо!
Юрий, я нашел еще один Ваш документ, еще не прочел, но думаю он "в тему" -
http://2006.secr.ru/upload/files/63.pdf
Да, было дело ... там единственный "стремный" момент - сравнивая SRS и ТЗ по ГОСТ 34 - нужно принимать во внимание, что ГОСТ 34 на АС, а не на Программное средство. Но ввиду популярности именно ГОСТ 34 "в народе" использовался для соответствия именно он.
-
Этой нотации поболее полусотни лет, но она, на мой взгляд, лучше и RUP-а, и PMBoK, и прочих. Нестареющая классика.
А что это за нотация?
-
Г.П. Щедровицкого http://www.fondgp.ru/
Я был тренинге по управлению в 91 году у его последователя. С тех пор (22 года) ни один тренинг даже близко не подошел к этому уровню. Я до сих пор пользуюсь теми знаниями, навыками и терминологией.
-
Г.П. Щедровицкого http://www.fondgp.ru/
Я был тренинге по управлению в 91 году у его последователя. С тех пор (22 года) ни один тренинг даже близко не подошел к этому уровню. Я до сих пор пользуюсь теми знаниями, навыками и терминологией.
Ты всегда что-то говоришь в превосходной степени и почти никогда не отвечаешь на вопрос. Где элементы нотации, почему это нотация так хороша? Почему, если она так хороша, о ней мало кто знает?
-
Ты всегда что-то говоришь в превосходной степени и почти никогда не отвечаешь на вопрос. Где элементы нотации, почему это нотация так хороша? Почему, если она так хороша, о ней мало кто знает?
Похоже ты прав. Попробую исправиться.
1. Литературу смотри на сайте http://www.fondgp.ru/ Там ее много.
2. Несколько лет назад их тренинги очень активно покупали в Европе. В РФ - нет. Почему так - не знаю, врать не буду.
-
Похоже ты прав. Попробую исправиться.
1. Литературу смотри на сайте http://www.fondgp.ru/ Там ее много.
2. Несколько лет назад их тренинги очень активно покупали в Европе. В РФ - нет. Почему так - не знаю, врать не буду.
Спасибо, но легче не стало. Скорее всего я просто проигнорирую существование такой нотации (речь то о нотации была. а не о методологии ;)).
Судя по тому как ты ярко себя проявляешь в мире. можно ли сказать "То, заслуга Щедровицкого?"