Области знаний (методология + нотация + стандарт = проект)(Прочитано 22585 раз)
В виду того что на данный момент не все теории и практики охвачены моим познанием хотел бы структурировать имеющиеся методологии, теории, стандарты и иже с ними.
Правильно ли я понимаю, что:
Следует разделять «сущности» (не исключено что я их перемешал)
1.   Нотация  (Методология?) сбора/анализа/моделирования (или это три разных подразделения)
SADT, UseCase, UML, есть еще популярные ?
2.   Методологию разработки ПО
RUP, Iconix, Agile, XP, и т.п.
3.   Стандарты представление документации
ГОСТ, IEEE, есть еще популярные ?

В итоге
1. мы используем методологию моделирования для сбора/моделирования/представления/хранения данных
2. с помощью методологии разработки мы управляем процессом создания продукта
3. с помощью стандарта представления документации мы передаем заказчику информацию о данных и о продукте

Т.е.  в зависимости от проекта
- Эти три сущности могут комбинироваться в любом порядке
- Какой-то из них может отсутствовать
- В рамках одной сущности могут быть полное, частичное, и смешанное следование методологии(ям).

Как следствие:
1.   Понятие о «Спецификации требований» у каждой компании может быть свое, как и состав документов, но если это ГОС проект то смотрим соответствующий 34-ый стандарт и никаких вам спецификаций.
2.   По большому счету ВИ есть ФТ и наоборот. Т.е. одно порождает другое и уже от нас и проекта зависит от чего мы пляшем. Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ? Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?
no fear



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.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



хороший вопрос, про который есть отдельные темы.

Под ФТ понимаются функциональные требования 3-х уровней — бизнесового, пользовательского и технического.
Отсюда и всё месиво.

Способ применения (use case) — это структура, содержащая 1 пользовательское ФТ и N технических.

Денис, поясни пож-та что понимается под "техническими" требованиями?
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Денис, поясни пож-та что понимается под "техническими" требованиями?
Требования, которые не относятся напрямую к цели пользователя, а только помогают в её реализации.
Например, «Система должна показать список контактов под полем ввода адреса» как шаг сценария реализации требования «Система должна позволять Пользователю отправлять письма».



Посмотрите тут 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/

Пока не обсуждали, Сергей сильно загружен работой.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Коллеги спасибо!

Юрий, я нашел еще один Ваш документ, еще не прочел, но думаю он "в тему" -
http://2006.secr.ru/upload/files/63.pdf

no fear



Что касается понятия "методология". Может будет интересно http://www.methodolog.ru/.



[Сначала несколько уточнений.]
Уравнение в заголовке подвергается сильной критике довольно давно. Например, в agile manifesto. Можно добавить слева как минимум ещё три слагаемых: навыки + знания + коллектив.
Нотация -- система обозначений -- не всегда жестко привязана к методике или методологии. Т. е. UML -- не методология моделирования. И не часть методологии RUP (многие участники OMG приложили достаточно усилий, чтобы это не было так). UML создавался как общая нотация для нескольких методов разработки.
Методология RUP содержит в себе техники моделирования. Методология разработки ПО может включать в себя методики моделирования, и чаще всего включает.

[Теперь по существу.]
Нотации дают возможность участникам проекта невербально обмениваться идеями и принятыми решениями.
Стандарты фиксируют соглашения, которых придерживаются участники проекта.
Методологии упорядочивают работу участников проекта.
« Последнее редактирование: 12 Марта 2013, 12:09:12 от Виктор Малышко »



Мне нравится такая штука:

Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Этой нотации поболее полусотни лет, но она, на мой взгляд, лучше и RUP-а, и PMBoK, и прочих. Нестареющая классика.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Этой нотации поболее полусотни лет, но она, на мой взгляд, лучше и RUP-а, и PMBoK, и прочих. Нестареющая классика.

А это нотация?
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19