Те цитаты, которые приводите Вы, похоже, из последних лекций (11-12), посвящённых UML, в котором возможно Грекул не имеет такого обширного опыта, как в SADT. Я не вижу ничего дурного в том, что человек знает что-то лучше, что-то хуже, как говорил тут Александр - нет гуру в своём отечестве.
Да знать или не знать ... это одно, выносить в качестве публикации ... это другое. Дурное, в первую очередь в том, что не следует сравнивать вещи, которые таки разные. И незнание не освобождает от ответственности, тем более ответственности при обучениии. А это уже не цитаты, а его собственные рассуждения. И это две разницы.
Во-первых, коим образом это относится с бизнес-процессам? Во-вторых, сколько я помню, именно в такой форме Потребности и описываются, даже у мажоров требований типа Вигерса-Лефингвелла-Коберна, т.к. "насколько надёжно" - это не уровень потребностей, а уровень требований к системе, определяемый совместно архитектором и аналитиком. См. мою таблицу уровней требований. Какие точные требования к атрибутам качества может предъявлять Заказчик??? Это скорее исключение, чем правило.
1. Коберна и Вигерса вы напрасно поставили в один ряд с Леффингвеллом говоря о user&stakeholder needs. Кроме этого что-то я не увидал их в списке литературы которые приводит автор лекции :-).
2. Связь с бизнес-процессами очевидна, при условии понимания причины -- ЗАЧЕМ в конкретном случае мы занимаемся описанием БП -- если делаем автоматизацию (читай создаем систему), то очевидно. что БП/Потребности/Требования -- будут связаны.
3. Серьезного формализма в описании needs нет, достаточно почитать апологета их выделения - Лефингвелла, (не важно какое 1 или 2 издание). И тем более ПРЕДЪЯВЛЕНИЯ к user needs "не вводить необоснованных ограничения на имплементацию". Это, пардон, характеристика требований, а никак не needs, не так ли? Остается открытым вопрос, на основании чего автор это утверждает, собственное IMHO? Тогда ценность этого утверждения невелика.
4. Что касается вашей "таблицы уровней требований". Не могли бы вы более детально описать, что вы вкладываете в понятие "Требования к системе" (вид требования в вашей таблице)? И как он связан с источниками "Стандарты, Архитектурные шаблоны" и документом SAD?
А что плохого в том, чтобы взять всё лучше, скомпилировать и переработать? Аутентичность текста - насколько важная ценность в контексте задачи накопления и передачи знаний?
Согласитесь, но я в тексте своего постинга не давал оценки "компиляция это хорошо или плохо", я просто сделал утверждение, что это компиляция. С моей т.з. в тех моментах которые я отметил, эта компиляция не совсем удачна, и я пояснил почему. Аутентичность меня в данном случае не заморачивает абсолютно, важна передача сути, и она должна быть неискаженной. А собственные размышления автор должен видимо был как то выделять.
Посмотрев на их драфт 1.6 меня уже одно то смущает, что у них там ни одной диаграммы - хороши мастера представления знаний.
О каких диаграммах идет речь? Какие диаграммы есть в других BOK, выражающие "представление знаний", которые не преведны в этом?
Просмотр сообщений