Организация работы программистов

[mazzy]

Смотря с чем сравнивать

Если с "бесплатным" Citrix'ом или Windows TE, то конечно дорогой.
Если выбирать между ПОКУПКОЙ того или иного варианта, то трехзвенка обходится дешевле.

[Андре]

Хорошо. Новая функциональность написана и вроде бы можно устанавливать ее пользователям. Или рано еще - надо ее протестировать.

1. Как Вы осуществляете тестирование вновь написанной или модифицированной функциональности ?

Да в какой-то степени программист разрабатывающий эту часть системы, ее уже протестировал, но он никогда не будет до конца уверен (по крайне мере у меня еще нет такой уверенности), что изменения внесенные в систему не повлияют на ее работу в совершенно неожиданном месте. Так например измененный метод класса может вызываться из модуля, от которого Вы этого совсем не ожидали (.

Осуществляется ли полная проверка функциональности системы после каждого добавления функциональности ? Каким образом Вы осуществляете тестирование: пробуете выполнить основные операции, как это указано в руководстве пользователя, или используете какие-либо инструменты упрощающие процесс тестирования ? Кто осуществляет тестирование: программист или нет, если программист, то какой - тот, кто писал эту функциональность или лучше, если это будет другой человек ?

И второй вопрос: должен ли быть в организации человек, через которого проходит ВЕСЬ написанный код, который изучает и проверяет его и "дает добро" на внесение этого кода в работающую систему ? Или это необязательно: каждый программист выполняет свое задание и собственно за него отвечает. Но в таком случае, как мне кажется, возможна такая ситуация - однажды, после внесения обнавления функциональности, работающая система перестанет работать. Ситуация и так не приятная, а в данном случае просто катастрофическая. Вполне возможно, что ни один программист не признает себя виноватым и все будут говорить, что ошибка ол у кого угодно, но не у меня. В связи с этим, мне кажется разумным, чтобы был человек, который отслеживает все изменения функциональности (вплоть до контроля и проверки каждой строки кода), одобряет их и соответственно уже он несет ответственность за работоспособность системы. Или я не прав ?

[mazzy]

Я опишу тестирование, которое мы выполняем на работах у клиента.
Уверен, что этот механизм нельзя применять при разработке типовых решений. Типовые решения должны тестироваться гораздо тщательнее.

Цитата:

Изначально опубликовано Андре
1. Как Вы осуществляете тестирование вновь написанной или модифицированной функциональности ?

На тестовой базе.

Цитата:

Изначально опубликовано Андре
Да в какой-то степени программист разрабатывающий эту часть системы, ее уже протестировал, но он никогда не будет до конца уверен (по крайне мере у меня еще нет такой уверенности),

100% уверенности никогда и ни в чем не бывает. В этом я уверен на 100%
Для практической деятельности обычно бывает достаточно следовать принципу 80-20.

Цитата:

Изначально опубликовано Андре
что изменения внесенные в систему не повлияют на ее работу в совершенно неожиданном месте. Так например измененный метод класса может вызываться из модуля, от которого Вы этого совсем не ожидали

Как это? А перекрестные ссылки?
Что значит "не ожидали от модуля"?
Это всего лишь значит, что ты не посмотрел и не проверил.

Цитата:

Изначально опубликовано Андре
Осуществляется ли полная проверка функциональности системы после каждого добавления функциональности ?

Это идеальное решение.
К сожалению, идельные решения требуют бесконечных ресурсов.
Поэтому опять же следуем правилу 80-20.

Цитата:

Изначально опубликовано Андре
Каким образом Вы осуществляете тестирование

Первичное тестирование осуществляет тот, кто писал. Т.е. "написал - проверь, что нет явных ляпов". Если ляпов нет, то этим же выполняется более тщательное тестирование на пяти-десяти примерах (если на тестирование есть время). Задача все та же - на 80% быть уверенным в корректности кода.

Дальнейшее тестирование выполняет уже сам оператор. Его предупреждают, что код новый - посмотри на его поведение, проверь несколько цифр/документов. Если все нормально, то код считается правильным.

Естественно, что такой подход не гарантирует полную проавильность и корректность кода. Однако для практических целей он вполне подходит и на практике приносит хорошие результаты.

Еще раз оговорюсь, что для типовых решений тестирование должно быть другим.

Цитата:

Изначально опубликовано Андре
И второй вопрос: должен ли быть в организации человек, через которого проходит ВЕСЬ написанный код, который изучает и проверяет его и "дает добро" на внесение этого кода в работающую систему ?

Для типовых решений скорее всего да.
Для внедрений "для себя" это излишне, IHMO. Так как увеличивает количество требуемых ресурсов, а эфект не так заметен.

Цитата:

Изначально опубликовано Андре
Но в таком случае, как мне кажется, возможна такая ситуация - однажды, после внесения обнавления функциональности, работающая система перестанет работать.

Отдельный человек не решит эту проблему.
Если эта проблема является критичной, то периодически делайте архивы логики.

Цитата:

Изначально опубликовано Андре
Вполне возможно, что ни один программист не признает себя виноватым и все будут говорить, что ошибка ол у кого угодно, но не у меня.

Кроме того в Аксапте записывается кто какие объекты правил.
Что значит не "признает"?
У объекта прописан логин?
В архивных копиях есть? Какие пролемы?
Только искать виноватого - это очень затратный путь. Гораздо эффективнее создать команду, которая работает на одну цель.

Цитата:

Изначально опубликовано Андре
В связи с этим, мне кажется разумным, чтобы был человек, который отслеживает все изменения функциональности (вплоть до контроля и проверки каждой строки кода), одобряет их и соответственно уже он несет ответственность за работоспособность системы.

Я конечно могу ошибаться.
Мне кажется, что это один из возможных путей.
Мне кажется, что это самый затратный путь.
Мне кажется, что для создания типовых решений этот путь можно рассматривать.
Мне кажется, что для внедрений "для себя" (или "для клиента") этот путь неприемлим.

[artem]

Цитата:

Изначально опубликовано mazzy
100% уверенности никогда и ни в чем не бывает. В этом я уверен на 100%
Для практической деятельности обычно бывает достаточно следовать принципу 80-20.

а что за принцип 80-20, если не секрет?

[mazzy]

= 80% пива выпивает всего лишь 20% людей.
= 80% всех проблем доставляет 20% кода.
= 80% всей работы выполняется за 20% от всего времени.
= 80% уверенности в правильности достигается за счет выполняения 20% от всех мероприятий.

А также.
= оставшиеся 20% от работы занимают 80% от всего времени.
= для того, чтобы быть быть уверенным в оставшихся 20% надо выполнить оставшиеся 80% мероприятий.

И т.п.

[Андре]

mazzy большое спасибо за развернутый ответ. Хотелось бы уточнить, что Вы подразумеваете под "типовым решением". Как я понял, это функциональность, которую разрабатывают для использования в нескольких организациях, а не для одного конкретного клиента ?

[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

[Алексей Контев]

Разрешите вернуться к теме совместной работе над разработкой в Аксапте.
Но ситуация несколько иная.
Есть компания, осуществляющая сопровождение Аксапты.
Есть собственная команда программистов.
И те, и другие делают разработки и модификации.
Вопрос, кто предложит оптимальный механизм взаимосвязи двух команд?
Как мне кажется, возможны два варианта работы:
1. Работа в разных слоях (VAR и USR) и перенос слоев. Но каков механизм тестирование и определения пересекающихся методов.
Например, компания сопровождения модифицирует метод, тестирует, все работает
Но при переносе в рабочую базу возникает ошибка. Сопровожденцы кричат, что у них
все работает (и это действительно так . ). Т.е. необходимо выверять все изменения (с какого периода?) и как-то реагировать (анализировать) на возможные нестыковки.
Как решать проблему кто прав, кто виноват?
2. Передача проектов. Но при этом как-то надо договариваться, чтобы в течение какого- либо времени не вносить изменения в оговоренные классы и методы (как их заранее определить). Кроме того, при этом работы будут производиться в одном слое
(USR) и существует опасность непреднамеренной перезаписи методов, и потеря контроля за модификациями.

Хотелось бы услышать Ваши предложения и реально работающие решения этой задачи.

[mazzy]

К Андре:
да

К Алексей Контев:
1. Все же постарайтесь организовать работу в одной сети. Удаленная работа привносит больше административных вопросов, чем технических
2. выделите технического руководителя с каждой стороны
3. используйте блокировку ОБЪЕКТОВ. К сожалению, блокировки методов нет. (и наверное, это правильно)
4. постарайтесь максимально ускорить рабочий цикл обмена проектами.

[SA]

интересный ход обсуждения...позволю пару замечаний, так чтоб не обидеть особо одаренных
У проекта (проектов) бывает менеджер - отвечающий за график, представление результатов, соотвестствие результата ТЗ и,в том числе, согласованую работу. Ну, иногда не бывает - и перечиленные вещи отсутвуют.Как например у уважамой фирмы, указаной на этом сервере в одном из ее проектов.
"Что делает эта волосатая обезьяна за 50 к$ в углу? -
Мы не знаем, но остальные зовут ее менеджер проекта"

Это все относится ВООБЩЕ к программированию, а не к Аксапте. Рекомендую внимательно посмотреть на конторы офшорного програмирования. Ребята управляют своими ресурсами, строят графики работ и т.д.
Что касается средств Аксапта, то они средненькие. но никто не мешает вести документацию и блокировку на бумажке в клеточку - на крайний случай.
Сухой остаток: болезнь не в Аксапта, а в том, что программист и менеджер проекта две разные профессии. Быть хорошим танкистом мало для командования бригадой. А пять очень самостоятельных танков - еще не боевая единица.

[komar]

Цитата:

Изначально опубликовано Trump

Вообще, очень хорошо, что затронули вопрос тестирования. Он напрямую связан с другим вопросом, как компании внедренцы занимаются качеством внедрений. Мой однобокий опыт общения с разными внедренцами достаточно интересен, в Российских компаниях внедренцах с которыми я общался ( конечно я общался далеко не со всеми ), просто отсутствуют самые базовые вещи по управлению качеством. SEI CMM начинается с очень разумных вещей ( я легко соглашусь что такой громоздкий стандарт качества совсем не нужен для компаний внедренцев, но какие то базовые вещи должны присутствовать) Например в компании внедренце должна быть как миниум продекларирована и озвучена политика управления качеством внедрения.
Trump

Есть и компании, в которых система управления качеством существует. Пример - IBS, использующий ISO9000.

[macklakov]

Я бы добавил еще один пункт:
5. Просматривать изменения, внесенные противоположной стороной и задавать друг другу глупые вопросы типа: "Ты добавил в эту таблицу поле, а мы храним те же данные в другой таблице, или не совсем те же... :-( "

[Trump]

Да никто не спорит, конечно есть. Особенно среди компаний работающих также на зарубежных рынках.
Правда IBS если я не ошибаюсь не занимается axapta ( вроде как они специализируются из navision продуктов только в Attain ).
Но для большинства "внедренческих" компаний это "филькина грамота".
И кроме того ISO это больше управление качеством поточных продуктов, для проектных решений существует CMM и PMBOK ( хотя это немного из другой оперы ).

[komar]

Цитата:

Изначально опубликовано Trump
Да никто не спорит, конечно есть. Особенно среди компаний работающих также на зарубежных рынках.
Правда IBS если я не ошибаюсь не занимается axapta ( вроде как они специализируются из navision продуктов только в Attain ).
Но для большинства "внедренческих" компаний это "филькина грамота".
И кроме того ISO это больше управление качеством поточных продуктов, для проектных решений существует CMM и PMBOK ( хотя это немного из другой оперы ).

Занимается в том числе и axapta.
А какая из систем управления качеством больше подходит - вопрос философский

[Aleck]

Видели мы, c чьей Аксаптой занимается IBS ...

Главное Navision в курсе http://www.navision.ru/main.asp?IDR=362