AXForum  
Вернуться   AXForum > Рынок > Рынок труда Microsoft Dynamics
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.12.2010, 14:53   #18  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,342 / 3563 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
2 Lz_ и dmitryul:
У вас обоих разные цели внедрения. Отсюда и разные методологии.
У Lz_ цель - внедрить - некоторую функциональность. Например, функциональность работы с доверенностями. Что она из себя будет представлять - неважно - для этого будет написано руководство пользователя, в котором будет написано что куда нужно жать. От заказчика требуется предоставить лишь общие пожелания (чтобы была возможность учитывать срок жизни доверенностей, кому и когда выданы и т.д. и т.д.). Будет справочник доверенностей с двумя, тремя кнопками или розовыми бантиками - заказчику - неважно - он свои требования выставил и получил оценку - что эта функциональность будет стоить столько-то.
Важно - внедряемая функциональность никак не зависит от наличия ее в системе, т.е. она может присутствовать в системе / быть новой / быть частично реализованной в системе. Руководство пользователя будет содержать описание всего процесса. Просто руководство пользователя будет написано либо по стандартному функционалу, либо по написанному. И здесь функциональный дизайн уже фактически становится ненужным (конечно какие-то крупные задачи могут детализироваться и дополнительно согласовываться, но это уже согласование нужно больше чтобы в процессе разработки уточнить некоторые (возможно пропущенные) непринципиальные по отношению ко всей функциональности детали).
Для реализации этого и подходит ГОСТ34.

У dmitryul цель - сделать то, что хочет заказчик. Т.е. быть по сути - программистом-аутсорсером, которому нужно сформулировать задание заказчиком и дать программировать. Консультант здесь выполняет роль секретаря-машинистки - заказчик диктует, а он записывает, иногда, правда вставляя от себя слова, понятные программисту. Программист же сдает конечный код (с тестированием, переносом начальных данных, оптимизацией БД и т.д.). Для реализации этого и подходит Sure Step. Хочу особо отметить - что Sure Step достаточно четко требует описания функциональных требований, которые реально не нужны заказчику в процессе его работы. Они нужны разработчику для разработки и заказчику в момент принятия работы, но совершенно не нужны ему в дальнейшем. А вот про руководства пользователей, которые нужны заказчику в дальнейшем для обучения новых сотрудников ничего в Sure Step я не нашел написанного. Т.е. Sure Step этого не предполагает - и это логично, т.к. цель Sure Step - сдать работающий код, а не перенести бизнес-процесс заказчика в режим работы в системе.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 26.12.2010 в 15:03.
За это сообщение автора поблагодарили: kALVINS (1), Lz_ (1).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Различия между модулями CRM Vorman Сравнение ERP-систем 15 03.10.2008 13:31
Разница между консультантом и программистом Галина Рынок труда Microsoft Dynamics 28 18.03.2005 03:20
Сделка между Navision и Microsoft может быть сорвана [compulenta.ru] Nikolson Microsoft и системы Microsoft Dynamics 3 30.05.2002 09:21

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 00:00.