Comments 15
Очень не хватает разбора конкретного примера.
Конкретный пример. Берем два требования:
1. «Представитель заказчика должен иметь возможность редактировать документ на этапе согласования»
2. «Руководитель подразделения должен иметь возможность изменить контрагента на этапе согласования».
Опишем эти два требования в виде концептов, концепты сгруппируем в четыре указанных в топике категории: объект, субъект, действие, условие.
Требование 1:
Объект: документ
Субъект: представитель заказчика
Действие: редактировать
Условие: на этапе согласования
Требование 2:
Объект: контрагент
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования
Попарно сравнивая концепты мы заметим, что совпадают 2 из 4, т.е. семантическое расстояние будет равно 0.5
Предположим, что у нас уже реализовано третье требование: «Руководитель подразделения должен иметь возможность изменить телефон контрагента на этапе согласования».
Здесь видно, что телефон контрагента имеет отношение к контрагенту (телефон является частью сущности контрагент, по большому счету), то между этими концептами можно установить степень «похожести» 0.5 (установим экспертным путем). Рассчитаем семантическое расстояние:
Требование 3:
Объект: телефон контрагента
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования
Оно равняется 0,875
Видим, что требования 2 и 3 более близки, чем требования 1 и 2. Когда реализованных требований больше трех уже можно выбирать, какую реализацию допиливать до нужного функционала.
1. «Представитель заказчика должен иметь возможность редактировать документ на этапе согласования»
2. «Руководитель подразделения должен иметь возможность изменить контрагента на этапе согласования».
Опишем эти два требования в виде концептов, концепты сгруппируем в четыре указанных в топике категории: объект, субъект, действие, условие.
Требование 1:
Объект: документ
Субъект: представитель заказчика
Действие: редактировать
Условие: на этапе согласования
Требование 2:
Объект: контрагент
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования
Попарно сравнивая концепты мы заметим, что совпадают 2 из 4, т.е. семантическое расстояние будет равно 0.5
Предположим, что у нас уже реализовано третье требование: «Руководитель подразделения должен иметь возможность изменить телефон контрагента на этапе согласования».
Здесь видно, что телефон контрагента имеет отношение к контрагенту (телефон является частью сущности контрагент, по большому счету), то между этими концептами можно установить степень «похожести» 0.5 (установим экспертным путем). Рассчитаем семантическое расстояние:
Требование 3:
Объект: телефон контрагента
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования
Оно равняется 0,875
Видим, что требования 2 и 3 более близки, чем требования 1 и 2. Когда реализованных требований больше трех уже можно выбирать, какую реализацию допиливать до нужного функционала.
Судя по отсутствию комментариев, никто не понял, о чем этот топик. Я тоже не понял. Стиль изложения скорее не академический, а «наукобразный». Или Вы под текстом в академическом стиле подразумеваете тот, который никто никогда не дочитает до конца? Лучше бы привели конкретный пример. Без него все это выглядит игрой слов и притянутой за уши математикой.
И вообще какая-то каша:
Как будто без объектно-ориентированного программирования невозможно повторное использование кода.
И вообще какая-то каша:
Возможность повторного использования достигается за счет соблюдения основных принципов объектно-ориентированного программирования: инкапсуляции, наследования и полиморфизма.
…
Для повторного использования разработанных модулей необходимо не только соблюдение принципов объектно-ориентированного программирования,
Как будто без объектно-ориентированного программирования невозможно повторное использование кода.
Таки прочитал :) Довольно интересно. Есть вот такое замечание: статья базируется на такой предпосылке: «Использование современных методологий и парадигм программирования, таких как объектно-ориентированное программирование, позволяет создавать самостоятельные законченные модули, которые могут быть использованы в нескольких проектах». Получается, что успешность применения описанного вами метода напрямую зависит от возможности повторного использования кода. Выявить дубликат и найти подсистему ее реализующую — задача не такая сложная, по крайней мере не в сверх-масштабах. Обычно менеджер запросто выявляется дубликаты. Конечно, хорошо такой процесс автоматизировать, с этим я согласен с вами на 100%. Однако главная проблема кроется в том, что бы выделить самостоятельный законченный модуль, пригодный для повторного использования. Во-первых ООП ортогонально повторному использованию. Для реализации повторного использования актуален компонентный подход. Во-вторых непонятно на какой уровень дробления на компоненты нужно ориентироваться. Один компонент на одно требование? Так слишком избыточно, ведь создание независимого компонента связано с издержками вплоть до денормализации данных. Более крупные модули же помимо нужного требования реализуют еще и массу других. Получается, что нужно будет избыточный модуль еще серьезно дорабатывать… К сожалению до того, что бы сбыться давней мечте программной инженерии — сборки ПО из готовых компонентов, еще слишком далеко.
В целом понятно, что хотел сказать автор. Вводим веса, коэффициенты разные, метрику задаем и ищем похожие требования. Математика тут самая простая, на уровне интуитивно понятных определений. Как я понял данные мысли существуют только «на бумаге». Т.е. на сегодняшний день «живых» систем, реализующих инициализацию всех доменов, концептов и т.д., а также дальнейший поиск по описанной схеме, нет в природе? Хотелось бы поинтересоваться, какие у автора доводы в пользу эффективности представленной методики кроме теоретических?
Ну оооооочень хочется поругать за «академический стиль изложенния»!
Можно поругать. В комментах. =)
Вроде ж в постскриптуме Вы просите об обратном ;)
Я лучше в очередной раз на Нору Галь сошлюсь, она с этого свою книжку начинала. Вот.
Я лучше в очередной раз на Нору Галь сошлюсь, она с этого свою книжку начинала. Вот.
А вообще, сама по себе затея оформлять юз-кейсы и вытекающие из них бизнес-требования в абстрактную семантическую сеть, а затем иметь средство сравнения таких сетей — очень интересна.
Хотя, подозреваю, чисто по человечески нереализуема, пока не будет автоматизирована. А единственная возможная здесь автоматизация — это машинное чтение и интерпретация обычных ТЗ, написанных человеческим языком. Что само по себе и так даст семантическую сеть, и автоматическое сравнение/узнавание…
Вручную регистрировать такие сети — задачка для редких маньяков. Даже если будет удобный графическо-таскательно-связываетльный инструмент для понятий предметной области.
Хотя, подозреваю, чисто по человечески нереализуема, пока не будет автоматизирована. А единственная возможная здесь автоматизация — это машинное чтение и интерпретация обычных ТЗ, написанных человеческим языком. Что само по себе и так даст семантическую сеть, и автоматическое сравнение/узнавание…
Вручную регистрировать такие сети — задачка для редких маньяков. Даже если будет удобный графическо-таскательно-связываетльный инструмент для понятий предметной области.
В целом интересно. очень не хватает примера. Ну или хотябы попытки такой пример дать. Я очень давно думаю про семантику. Очень заманчиво выглядит семантическая работа с требованиями.
Сейчас мы используем только самую примитивную семантику, типо обработки текста после слова (поиск) как запроса и выдача списка документов по внутренней базе маркированным списком. Аналогично слова (задача), имя пользователя. В общем на уровне инструкций, но не требований. И нам и этоу уже очень нравиться.
У нас есть робот который обрабатывает регулярные выражения во всех наших документах. Данные мы храним на гугловском облаке, вспомогательные таблицы и код тоже. Так что по вычислениям потолка особого нет. С удовольствием бы поэкспериментировали.
Сейчас мы используем только самую примитивную семантику, типо обработки текста после слова (поиск) как запроса и выдача списка документов по внутренней базе маркированным списком. Аналогично слова (задача), имя пользователя. В общем на уровне инструкций, но не требований. И нам и этоу уже очень нравиться.
У нас есть робот который обрабатывает регулярные выражения во всех наших документах. Данные мы храним на гугловском облаке, вспомогательные таблицы и код тоже. Так что по вычислениям потолка особого нет. С удовольствием бы поэкспериментировали.
Sign up to leave a comment.
Использование семантической аннотации для идентификации требований