676
Конференции Семинары и Тренинги / Re: Семинар по прецедентам - Подготовка
« : 06 Июня 2007, 11:52:12 »Ориентир по дате - последняя неделя июня.
Вот по дате нужно будет согласовать отдельно ...
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Ориентир по дате - последняя неделя июня.
http://ignatovaolga.moikrug.ru/
1. Цели - расти в профессиональном плане
2. Помощь - чем смогу, помогу. Могу поделиться материалами, мыслями, проблемами и их решениями
Даже не знаю с какой стороны подойти к написанию таких тестов, это больше уже психология ...
Есть еще вариант - не приглашение независимого от вендора консультанта (вопрос его компетенции в системе, как заметил Денис, весьма сомнителен), а работа с консультантом, обладающий экспертизой во всех основных ERP.
Например, мы (GMCS) - партнеры всех 4 основных вендоров ERP - SAP, Oracle, Microsoft, BAAN (SSA). У нас практикуются проекты по консалтингу БП и выбору системы, в которых участвуют специалисты всех 4 практик. Таким образом, повышается вероятность оптимального выбора системы.
Интерес клиента в том, что он получает независимый консалтинг по выбору системы, а наш интерес в том, что при выборе любой из систем, велика вероятность, что проект по внедрению останется за нами
Я же пишу - типичные артефакты не задают контекста использования. Из скриншотов не очевидны эргономические требования. Если человек работает с формой, тут у него заплакал ребёнок, он отошёл и вернулся через 15 минут, а система ему - говорит - "ваша сессия закончилась, введите данные заново", то такие исключительные ситуации гораздо проще выявить через механизм обыгрывания комиксов, чем через шаблон Use-Case.
1 Речь идет не о подмене спецификаций GUI сценариями. Речь идет о сценариях, опирающихся на элементы GUI.
Один из тезисов статьи, если я правильно понял, "чем больше уровень абстракций, тем лучше". Вот с этим я не согласен. Я исхожу из того, что цель аналитика, как и любого другого в команде, быстро и качественно реализовать проект. Если для этого требуется отходить от Коберновских стандартов - это нужно делать.
А на счет поддержки таких требований - это опять же по обстоятельствам. Если в проекте три аналитика, то почему бы и нет. К тому же, большой вопрос на что потратишь больше времени: на поддержку детальных требований или на объяснение программистам, как это хотелось бы видеть.
Практика показывает, что если ты что-то не прописываешь, то это додумывают за тебя. И обычно это не совпадает с твоим видением.
2 Согласен - демонстрация картинок это не решение проблем заказчика. Однако, сами понимаете, что большинство ориентируются на визуальную сторону. Так проще, хотя бы, начать разговор.
GUI как пример я выбрал, т.к. это самая банальная вещь. Можно привести пример другой ситуации: системе необходимо по запросу пользователя скачать файлы с удаленного сервера и проверить их целостность.
Писать можно и так:
1) Пользователь активирует загрузку
2) Система копирует объекты, взаимодействуя с системой N
3) Система проверяет целостность объектов
Это скорее всего вызовет больше вопросов. Если знаешь, что здесь лучше использовать протокол ftp - пиши ftp. Используй термины вроде "загрузка", "логин", "пароль", "адрес сервера" и всем будет проще.
Да, это твой выбор, и в этом есть некий риск неоптимального решения. Но, еще раз повторюсь, нечестно утверждать, что аналитик собирает "чистые" требования, не влияя на реализацию.