[Trump]

Ответ я так понимаю отстал от жизни на много месяцев и решение уже найдено...Хотелось бы услышать мысли автора на эту тему ( в смысле как же документировать ).
P.S. мои собственные мысли примерно такие. Вообще не столь важно в каком стандарте документировать, это будет спор между приверженцами разных технологий и все ( ну аналогично что круче C++ Java или VB ). Вообще очень зависит чего документировать. Если документировать функциональность ( общее описание данных и методов доступа относительно бизнес процессов то проще всего словами.Некий аналог SADT только в словарном выражении с добавлением диаграмм в местах где это кажется необходимым, диаграммы могут быть DFD, IDEF0 или Idef3, ну или ARIS. ) Если нужен более серьезный уровень детализации ( навскидку в голову ничего не приходит, ну например документирование замещения каких то базовых методов доступа к классам меняющие либо интерфейс либо бизнес правила) то тут либо словесно диаграмный подход, либо UML подобные диаграммы в разных разновидностях ( не обязательно UML а скорее чего то в стиле UML, ну или чего то в стиле нотации Буча, нотации Йордана и т.д. ) Сам UML в этом смысле технология достаточно мертвая ( ну то есть ценность UML скорее раскрывается при разработки архитектуры большых заказных приложений, тогда действительно там удобно проектировать классы ).

Еще хотелось бы высказаться о тестировании, хотя,конечно, мои мысли достаточно тривиальны, по крайней мере для тех кто работал в более менее серьезных компаниях разработчиках какого либо софта, не буду говорить умные слова из SEI CMM, ибо здесь ситуация проще чем у компаний разработчиков а попробую высказать мысли о минимальных требованиях к качеству основанных на здравом смысле. При сколько либо значительных обемах кодирования разумно иметь упрощенную модель стандартного двухуровневого тестирования. ( тут это зависит от того какое качество хочется впарить ну и плюс от возможностей чего то сломать их очевидно меньше, ибо минимальная защита от дурака у приложения есть)
Итак при разработке блоков модулей или даже отчетов самим разработчиком пишется план тестирования на основе методов которые он разработал или методов базовых классов которые он замещал ( ну или всего где он поковырялся, особенно с datasource ). Тестировать по хорошему должен другой человек ( либо другой разработчик ) кроме того, минимально необходимое требование это crosover quality test или проверка качества кода которая выполняется другим инженером и документируется в виде отчета о качестве. ( естественно отчет пишется не на каждый маленький модуль а на какие то более менее значительные куски работы ) Такая проверка дает две выгоды, первая выгода это контроль качества кода и его соответствию корпоративным стандартам, плюс соответственно обучающая функция для всех разработчиков которые периодически согласуют стили написания друг с другом и подсматривают друг у друга какие то методы ( хотя здесь влияние этого фактора тоже меньше чем у низкоуровневых разработчиков ) , вторая выгодв это некая дополнительная защита от логических и даже просто глупых ошибок которые могут быть пропущены в самом плане тестирования.
Хотя конечно о тестировании можно долго спорить, но на мой скромный взгляд я написал здесь разумный миниум ( естественно в случае если дописали вручную к системе больше чем один report ).
Вообще, очень хорошо, что затронули вопрос тестирования. Он напрямую связан с другим вопросом, как компании внедренцы занимаются качеством внедрений. Мой однобокий опыт общения с разными внедренцами достаточно интересен, в Российских компаниях внедренцах с которыми я общался ( конечно я общался далеко не со всеми ), просто отсутствуют самые базовые вещи по управлению качеством. SEI CMM начинается с очень разумных вещей ( я легко соглашусь что такой громоздкий стандарт качества совсем не нужен для компаний внедренцев, но какие то базовые вещи должны присутствовать) Например в компании внедренце должна быть как миниум продекларирована и озвучена политика управления качеством внедрения.
А политика управления качеством внедрения начинается с озвучивания того, что является качественным продуктом, и каких либо стандартов качества(измеримых результатов качества и методов их проверки),при этом стандарты качества должны быть не только в кодировании ( как раз это не самая mission critical часть во внедрении ERP) а здесь типичная ситуация сапожник без сапог. Я думаю не секрет что с консультанты из некоторых внедренческих компаний считают заказчиков достаточно отсталыми, себя продвинутыми и просто даже никогда не задумывались о каких то мерах и стандартах по обеспечению качества внедрения и формализации собственных процессов могущих влиять на качество, чего настоятельно рекомендует и ISO900x и CMM.
Trump