Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации. Вопрос не в том, насколько полно и точно мы выявляем цели, потребности, мотивы и установки пользователей, а в том насколько точно и полно разрабатываемое ПО маппируется на существующие БП. Т.е. насколько полно разрабатываемое ПО автоматизирует БП (функции, задачи и операции). Пользователь является связующим элементом между БИЗНЕС-ПРОЦЕССОМ (любым) и ПО.А вот это большая и типичная ошибка всех автоматизаторов. Описали БП и все. Получили кучу ненужной макулатуры. Да БП важны никто не спорит и их надо учитывать при выявлении цели, но все-таки цели отдельно, а потом уже БП если надо.
Имея представление об интересах мы не можем точно вывести, какой будет деятельность. Речь идет о том, что нужны и цели и интересы, но цели - опора протекающих процессов, интересы - источник ограничений.Ок. Возможно я пошел уже не в ту степь, но я имел ввиду, что надо указать, когда надо делать декомпозицию целей (полное целеполагаение), а когда можно ограничиться интересами/нуждами. И вообще у меня складывается цеткое представление, что нужно целеполагание при реинжиниринге БП, внедрении и катомзации продукта, большой новый продукт. Для маленьких и средних - достаточно интересов.
Речь идет не о целях пользователя при создании спецификации требований. Речь идет о целеполагании вообще при любой деятельности.Ну хорошо, какие можно тогда поставить цели, которые важны программисту?
Важность интересов заключается в том, что они являются источником остальных требований к системе.Здрасти, а цели тогда откуда берутся?? Сами вырастают и интересы тут не причём??
Я не вижу, где я себе противоречу. Ты спросил, откуда берется требование про 2 сек, тебе ответили. Но никто не утверждал, что для сбора требований достаточно описать цели. И даже наоборот.Я имел ввиду то, что абзац "цели нужны Разработчику" - притянут за уши. Они ему не нужны. А если ему они нужны, то значит требования описаны неполно Аналитиком.
1. Определения из ГОСТ мне не подходят. Во первых хочется копать глубже - в философские основы, во вторых теперь более четко вырисовалось направление: мне нужно исследование свойств декомпозиции целей.Ну хотя бы привести мне кажется нужно
2. На это просто ответить. Цели являются организующим началом деятельности - они не описывают ее полностью, не содержат исчерпывающую информацию, но являются тем скелетом, который объединяет все остальное. В использовании этого свойства целей и есть заслуга техники Use Case.Так ты сам говоришь в статье, что цели вытекают из инетересов. Описываем интересы и все, цели там будут внутри.
3. Цели всплыли, как средство ничего не забыть и как средство верификации нарисованных бизнес-процессов. В свою очередь для верификации самих целей отцы Use Case уже предлагают следующий шаг - рассматривать интересы. Про 2 сек. это вылазит, обычно, из двух вещей: описывается интерес пользователя "работать должно быть удобно, чтобы не тормозило", требование измеряемости требований трансформирует в конкретную характеристику - время открытия формы (кстати, не совсем в удачную, на мой взгляд).Так ты сам себе противоречишь. Говоришь, что 2сек. вылезает из интереса, а не из цели, так:
Лично мне понравился TPL Balanced.Мне тоже понравилось
Пытаюсь посмотреть тему "Анекдоты в жизнь", а меня неведомые силы перенаправляют на форму, в которой предлагается пожаловаться Модераторам (Администраторам) на оскарбления.. . .Опять началось ...
Наверное нех анекдоты в рабочее время смотреть)))))
Саша, я тебе имеет смысл писать грамотно, ты уж прости за замечание, но в голосовании там совсем немного слов...Хорошо, исправил, спешил просто ...
